[j-nsp] SRX, UDP traffic, routing asymmetry (selective packet mode, 1/2)
Per Westerlund
p1 at westerlund.se
Tue Dec 11 03:34:36 EST 2012
We are running a similar setup, sites with SRXs running OSPF over IPsec
(tunnel mode, st0.x). Right now we have a hub-and-spoke setup, but plan to
implement direct IPsec connections between some of our spoke sites, opening
the possibility of asymmetric routing (and subsequent failure in the SRX
flow handling).
We are actively using the firewalling capabilities of the SRXs, putting them
in routing mode (se earlier response) is not an option for us.
Selective packet mode will let you use the flow engine (IPsec, FW policies,
NAT, ...) for some packets, and bypass it (pure routing) for others.
Below is a configuration example that works in the lab. This kind of setup
(or perhaps the next one I will show
later) I plan to use in production Real Soon Now.
All flow-mode handling is done in the default routing instance (Master), and
packet-mode transport is handled by a VR called "packet-mode". These two
instances are connected with a local tunnel (lt-interface). Pure transit
traffic, from one spoke site to another, never enters flow-mode and can be
asymmetric without a problem.
Selective packet mode requires an input filter. IPsec tunnel interfaces
(st0.x) cannot have filters, why we must run GRE tunnels as well (which can
have input filters).
Note: Selective packet mode only works with branch SRX.
Note: The example I use in this mail won't work with clusters of branch SRX
(no lt-interfaces).
Note: st0.x interfaces must be present in the same VR as the corresponding
GRE interfaces (the knob "interfaces gr-0/0/0.x tunnel routing-instance
source <vr-name>" is missing).
Note: We only run IGP over the GRE tunnels, IPsec tunnels are only used to
transport GRE packets.
Link networks for IPsec tunnel interfaces (st0.x): 100.63.x.0/24
Link networks for GRE and local tunnel interfaces (gr-0/0/0.x and
lt-0/0/0.x): 100.64.x.0/24
interfaces {
gr-0/0/0 {
unit 41 {
description "remote site 1";
tunnel {
source 100.63.14.4;
destination 100.63.14.1;
routing-instance {
destination packet-mode-vr;
}
}
family inet {
mtu 1400;
filter {
input packet-mode;
}
address 100.64.14.4/24;
}
}
unit 43 {
description "remote site 3";
tunnel {
source 100.63.34.4;
destination 100.63.34.3;
routing-instance {
destination packet-mode-vr;
}
}
family inet {
mtu 1400;
filter {
input packet-mode;
}
address 100.64.34.4/24;
}
}
}
lt-0/0/0 {
unit 0 {
description "In default router";
encapsulation ethernet;
peer-unit 1;
family inet {
address 100.64.44.1/24;
}
}
unit 1 {
description "In packet-mode VR";
encapsulation ethernet;
peer-unit 0;
family inet {
filter {
input packet-mode;
}
address 100.64.44.2/24;
}
}
}
lo0 {
unit 0 {
description "In default router";
family inet {
address 100.64.0.4/32;
}
}
unit 1 {
description "In packet-mode VR";
family inet {
address 4.4.4.4/32;
}
}
}
st0 {
unit 41 {
description "remote site 1";
family inet {
address 100.63.14.4/24;
}
}
unit 43 {
description "remote site 3";
family inet {
address 100.63.34.4/24;
}
}
}
}
protocols {
ospf {
area 0.0.0.0 {
interface lt-0/0/0.0 {
interface-type p2p;
}
interface lo0.0 {
passive;
}
}
}
}
security {
zones {
security-zone trust {
host-inbound-traffic {
.
.
}
interfaces {
lt-0/0/0.0;
lo0.0;
}
}
security-zone packet-mode-zone {
host-inbound-traffic {
.
.
}
interfaces {
st0.41;
st0.43;
lt-0/0/0.1;
gr-0/0/0.41;
gr-0/0/0.43;
lo0.1;
}
}
}
}
firewall {
family inet {
filter packet-mode {
term local-address-flow-mode {
from {
destination-address {
4.4.4.4/32;
}
}
then accept;
}
term default-packet-mode {
then packet-mode;
}
}
}
}
routing-instances {
packet-mode-vr {
instance-type virtual-router;
interface lt-0/0/0.1;
interface gr-0/0/0.41;
interface gr-0/0/0.43;
interface lo0.1;
interface st0.41;
interface st0.43;
routing-options {
router-id 4.4.4.4;
}
protocols {
ospf {
area 0.0.0.0 {
interface lt-0/0/0.1 {
interface-type p2p;
}
interface gr-0/0/0.41;
interface gr-0/0/0.43;
interface lo0.1 {
passive;
}
}
}
}
}
}
-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Dale Shaw
Sent: den 3 december 2012 04:49
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] SRX, UDP traffic, routing asymmetry
Hi all,
I'm at the start of troubleshooting a strange problem we've
experienced recently with voice signalling (UNIStim) traffic.
Our WAN is based upon a carrier L3VPN but we build IPsec tunnels
(st0.x) over the top and we do not have a full mesh. The end result is
that traffic between "branch" sites needs to "hair-pin" on an
intermediate device (a J or SRX box).
Sometimes (due to OSPF's route selection process when presented with
equal cost routes) the path traffic takes from "A" to "B" is not the
same as the path from "B" to "A" -- the intermediate device to
hair-pin on (for A->B and B->A) is different. In performance terms,
the difference is insignificant. Most of the time the intermediate
devices are sitting next to each other in a rack (e.g. primary and
secondary routers).
Does the SRX do something "special" with asymmetric UDP flows? When I
say UDP I mean UDP generically, because I'm aware of special cases
like "set security flow allow-dns-reply". I have an ever-growing
suspicion that we are throwing packets on the floor in certain
circumstances.
cheers,
Dale (..on the never-ending quest to make SRXs behave like routers w/IPsec)
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
More information about the juniper-nsp
mailing list