Re: [j-nsp] SRX, UDP traffic, routing asymmetry (selective packet mode, 1/2)
;
}
}
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-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Dale Shaw
Sent: den 3 december 2012 04:49
To: juniper-nsp@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX, UDP traffic, routing asymmetry
On 12/07/2012 05:05 AM, Michel de Nostredame wrote: On Thu, Dec 6, 2012 at 7:13 PM, 叶雨飞 sunyuc...@gmail.com wrote: downgrade to 9.3R4.4 then Unfortunately 9.3 is already EOLed ( http://www.juniper.net/support/eol/junos.html ) Tuning J/SRX into packet-mode will lost several valuable functions such as IPsec, Jflow... those are very important for small business. Selective-packet-mode is also a huge pain from operation point of A huge pain? Really? Awkward I'll grant. view, also the Jflow will have problem under this. I believe the best solution is to keep pushing Juniper to bring packet-mode OS back to J-series with full functionality. That would be nice, I agree. At this moment, Juniper does not have product, my personal opinion, to head-to-head compete against Cisco ISR. J-series could be the most closed product line to fill this gap. Personally, I have the exact opposite opinion. The packet mode / flow mode has some hassles. But the J/SRX devices absolutely *annihilate* the Cisco ISR in terms of performance, and also in terms of price/performance. Cisco quoted performance for a 2951 is ~300Mbps, which an SRX210, at a fraction of the cost, will easily beat. A J series just flattens it. The ISR is a lacklustre platform IMO. It's amazingly slow for the cost, and about the only thing it can do which a J/SRX in packet mode can't is Netflow (which is a real lack) and IPSec (which you can do with a flow-mode VR). You could argue the flow-mode VR for IPSec is awkward, but it can mostly be templated (which JunOS is good at, but IOS has no concept of). Would the SRX with packet-mode JFlow IPSec be even more awesome - totally. But I think it holds its own against the ISR just on price/performance. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX, UDP traffic, routing asymmetry
On 12/07/2012 02:47 AM, Caillin Bathern wrote: This just becomes long and painful when you want to run the box as an MPLS device primarily and as an IPSec/Crypto box for some traffic.. I agree the config syntax for a flow mode VR and lt-* interfaces is a bit messy. But it's not exactly *huge* and when I tried it, it looked like it could be templated pretty easily. Is there something specific that makes it so painful? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX, UDP traffic, routing asymmetry
To follow up my own post (even more to follow), here is the config you use
on a J-series router to put it in router-mode. Nothing magic, just some
configuration. This will work with SRX as well, there is nothing J-series
specific in here. This config is found in
/etc/config/jsr-series-routermode-factory.conf, and the box I picked it from
was running Junos 10.2R4.8
It is a starting point, you the modify it to your taste. This will give you
(almost) routing properties, with IPsec available.
One of the problems that might hit you if you have lots of unrelated
traffic, is that you run out of sessions. You are still running in flow
mode, there are still sessions created, but you allow any packet to start a
new session. If you have asymmetric flows, the existing flows are never
closed properly, but always time out instead.
/Per
Here is the config:
adm_perw@segotrt01 file show /etc/config/jsr-series-routermode-factory.conf
| no-more
## This configuration is used to transition a box to router mode.
##
system {
syslog {
file messages {
any any;
}
}
services {
telnet;
ssh;
web-management {
http {
interface [ ge-0/0/0.0 ];
}
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
}
security {
flow {
allow-dns-reply;
tcp-session {
no-syn-check;
no-syn-check-in-tunnel;
no-sequence-check;
}
}
forwarding-options {
family {
iso {
mode packet-based;
}
inet6 {
mode packet-based;
}
}
}
policies {
default-policy {
permit-all;
}
}
zones {
security-zone trust {
tcp-rst;
host-inbound-traffic {
system-services {
any-service;
}
protocols {
all;
}
}
interfaces {
all;
}
}
}
alg {
dns disable;
ftp disable;
h323 disable;
mgcp disable;
real disable;
rsh disable;
rtsp disable;
sccp disable;
sip disable;
sql disable;
talk disable;
tftp disable;
pptp disable;
msrpc disable;
sunrpc disable;
}
}
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Per Westerlund
Sent: den 3 december 2012 06:57
To: Dale Shaw
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] SRX, UDP traffic, routing asymmetry
SRX as router with IPsec?
Have you tried Router Context? Most docs talk about J-series, but it works
with SRX as well.
If you need security (as in policies and zones) as well, there is selective
packet mode. I have done some work in that area, and can give details later
(right now I'm off-line and soon asleep).
/Per
Sent from my iPad, please ignore stupid spelling corrections!
3 dec 2012 kl. 04:48 skrev Dale Shaw dale.shaw+j-...@gmail.com:
cheers,
Dale (..on the never-ending quest to make SRXs behave like routers
w/IPsec)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX, UDP traffic, routing asymmetry
03.12.2012 07:48, Dale Shaw wrote: 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. SRX always performs a reverse wind route lookup (to the source IP address) when processing the first packet of the session and installs the next-hop to the session table. Subsequent reverse packets fall under the session context and are forwarded using this next-hop without route lookups. But when the reverse wind lookup is performed, SRX checks that the outgoing interface is in the same security zone as the interface through which the first packet came from. If zones do not match, traffic is dropped. So in practice there is no problem with asymmetric flows through a single device but you must place the both interfaces into a single zone (a reasonable security constrain, I would say). Last time I cared SRX did not support artificial symmetrization, based on using the cached next-hop, though which the packet came from. I would say the right approach is to readjust the OSPF link costs assigned to st0.x interfaces to make forward and reverse flows follow the same tunnel. If, for whatever reason, you really need to forward traffic so that forward and reverse flows follow different links/routers, you need to influence the outer header routing, e. g. playing with the underlying IGP/BGP/TE/ISP manager/etc. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX, UDP traffic, routing asymmetry
On 06/12/12 10:58, Per Westerlund wrote: To follow up my own post (even more to follow), here is the config you use on a J-series router to put it in router-mode. Nothing magic, just some configuration. This will work with SRX as well, there is nothing J-series specific in here. This config is found in /etc/config/jsr-series-routermode-factory.conf, and the box I picked it from was running Junos 10.2R4.8 Is this *actually* in router mode, or is it just in a permit-all flow mode? In particularly, you seem to be missing a packet-mode statement for IPv4 or MPLS (which also disables flow mode for IPv4) What does show security flow status say? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX, UDP traffic, routing asymmetry
This is a flow mode configuration (Juniper calls it router mode, not packet mode), that emulates pure packet mode by allowing all packets to start a flow, and having a default permit-all for all flows. The sole reason for having this is to enable flow-mode things like IPsec and NAT at the same time as having almost the same behavior as pure packet mode. I am working on another mail or two with examples of selective packet mode that I believe might solve Dale's original problem (and perhaps his quest for pure routing with IPsec). /Per 6 dec 2012 kl. 14:15 skrev Phil Mayers: On 06/12/12 10:58, Per Westerlund wrote: To follow up my own post (even more to follow), here is the config you use on a J-series router to put it in router-mode. Nothing magic, just some configuration. This will work with SRX as well, there is nothing J-series specific in here. This config is found in /etc/config/jsr-series-routermode-factory.conf, and the box I picked it from was running Junos 10.2R4.8 Is this *actually* in router mode, or is it just in a permit-all flow mode? In particularly, you seem to be missing a packet-mode statement for IPv4 or MPLS (which also disables flow mode for IPv4) What does show security flow status say? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX, UDP traffic, routing asymmetry
Sigh.. If only there was selective flow mode on the SRX/J... -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Per Westerlund Sent: Friday, 7 December 2012 4:24 AM To: Phil Mayers; Dale Shaw Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX, UDP traffic, routing asymmetry This is a flow mode configuration (Juniper calls it router mode, not packet mode), that emulates pure packet mode by allowing all packets to start a flow, and having a default permit-all for all flows. The sole reason for having this is to enable flow-mode things like IPsec and NAT at the same time as having almost the same behavior as pure packet mode. I am working on another mail or two with examples of selective packet mode that I believe might solve Dale's original problem (and perhaps his quest for pure routing with IPsec). /Per 6 dec 2012 kl. 14:15 skrev Phil Mayers: On 06/12/12 10:58, Per Westerlund wrote: To follow up my own post (even more to follow), here is the config you use on a J-series router to put it in router-mode. Nothing magic, just some configuration. This will work with SRX as well, there is nothing J-series specific in here. This config is found in /etc/config/jsr-series-routermode-factory.conf, and the box I picked it from was running Junos 10.2R4.8 Is this *actually* in router mode, or is it just in a permit-all flow mode? In particularly, you seem to be missing a packet-mode statement for IPv4 or MPLS (which also disables flow mode for IPv4) What does show security flow status say? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX, UDP traffic, routing asymmetry
you can run your main routing instance in flow mode , and apply filters to send those into other VRs (flow or not) for further processing. On Thu, Dec 6, 2012 at 4:45 PM, Caillin Bathern caill...@commtelns.com wrote: Sigh.. If only there was selective flow mode on the SRX/J... -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Per Westerlund Sent: Friday, 7 December 2012 4:24 AM To: Phil Mayers; Dale Shaw Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX, UDP traffic, routing asymmetry This is a flow mode configuration (Juniper calls it router mode, not packet mode), that emulates pure packet mode by allowing all packets to start a flow, and having a default permit-all for all flows. The sole reason for having this is to enable flow-mode things like IPsec and NAT at the same time as having almost the same behavior as pure packet mode. I am working on another mail or two with examples of selective packet mode that I believe might solve Dale's original problem (and perhaps his quest for pure routing with IPsec). /Per 6 dec 2012 kl. 14:15 skrev Phil Mayers: On 06/12/12 10:58, Per Westerlund wrote: To follow up my own post (even more to follow), here is the config you use on a J-series router to put it in router-mode. Nothing magic, just some configuration. This will work with SRX as well, there is nothing J-series specific in here. This config is found in /etc/config/jsr-series-routermode-factory.conf, and the box I picked it from was running Junos 10.2R4.8 Is this *actually* in router mode, or is it just in a permit-all flow mode? In particularly, you seem to be missing a packet-mode statement for IPv4 or MPLS (which also disables flow mode for IPv4) What does show security flow status say? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX, UDP traffic, routing asymmetry
This just becomes long and painful when you want to run the box as an MPLS device primarily and as an IPSec/Crypto box for some traffic.. -Original Message- From: 叶雨飞 [mailto:sunyuc...@gmail.com] Sent: Friday, 7 December 2012 12:21 PM To: Caillin Bathern Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX, UDP traffic, routing asymmetry you can run your main routing instance in flow mode , and apply filters to send those into other VRs (flow or not) for further processing. On Thu, Dec 6, 2012 at 4:45 PM, Caillin Bathern caill...@commtelns.com wrote: Sigh.. If only there was selective flow mode on the SRX/J... -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Per Westerlund Sent: Friday, 7 December 2012 4:24 AM To: Phil Mayers; Dale Shaw Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX, UDP traffic, routing asymmetry This is a flow mode configuration (Juniper calls it router mode, not packet mode), that emulates pure packet mode by allowing all packets to start a flow, and having a default permit-all for all flows. The sole reason for having this is to enable flow-mode things like IPsec and NAT at the same time as having almost the same behavior as pure packet mode. I am working on another mail or two with examples of selective packet mode that I believe might solve Dale's original problem (and perhaps his quest for pure routing with IPsec). /Per 6 dec 2012 kl. 14:15 skrev Phil Mayers: On 06/12/12 10:58, Per Westerlund wrote: To follow up my own post (even more to follow), here is the config you use on a J-series router to put it in router-mode. Nothing magic, just some configuration. This will work with SRX as well, there is nothing J-series specific in here. This config is found in /etc/config/jsr-series-routermode-factory.conf, and the box I picked it from was running Junos 10.2R4.8 Is this *actually* in router mode, or is it just in a permit-all flow mode? In particularly, you seem to be missing a packet-mode statement for IPv4 or MPLS (which also disables flow mode for IPv4) What does show security flow status say? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX, UDP traffic, routing asymmetry
downgrade to 9.3R4.4 then On Thu, Dec 6, 2012 at 6:47 PM, Caillin Bathern caill...@commtelns.com wrote: This just becomes long and painful when you want to run the box as an MPLS device primarily and as an IPSec/Crypto box for some traffic.. -Original Message- From: 叶雨飞 [mailto:sunyuc...@gmail.com] Sent: Friday, 7 December 2012 12:21 PM To: Caillin Bathern Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX, UDP traffic, routing asymmetry you can run your main routing instance in flow mode , and apply filters to send those into other VRs (flow or not) for further processing. On Thu, Dec 6, 2012 at 4:45 PM, Caillin Bathern caill...@commtelns.com wrote: Sigh.. If only there was selective flow mode on the SRX/J... -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Per Westerlund Sent: Friday, 7 December 2012 4:24 AM To: Phil Mayers; Dale Shaw Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX, UDP traffic, routing asymmetry This is a flow mode configuration (Juniper calls it router mode, not packet mode), that emulates pure packet mode by allowing all packets to start a flow, and having a default permit-all for all flows. The sole reason for having this is to enable flow-mode things like IPsec and NAT at the same time as having almost the same behavior as pure packet mode. I am working on another mail or two with examples of selective packet mode that I believe might solve Dale's original problem (and perhaps his quest for pure routing with IPsec). /Per 6 dec 2012 kl. 14:15 skrev Phil Mayers: On 06/12/12 10:58, Per Westerlund wrote: To follow up my own post (even more to follow), here is the config you use on a J-series router to put it in router-mode. Nothing magic, just some configuration. This will work with SRX as well, there is nothing J-series specific in here. This config is found in /etc/config/jsr-series-routermode-factory.conf, and the box I picked it from was running Junos 10.2R4.8 Is this *actually* in router mode, or is it just in a permit-all flow mode? In particularly, you seem to be missing a packet-mode statement for IPv4 or MPLS (which also disables flow mode for IPv4) What does show security flow status say? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX, UDP traffic, routing asymmetry
On Thu, Dec 6, 2012 at 7:13 PM, 叶雨飞 sunyuc...@gmail.com wrote: downgrade to 9.3R4.4 then Unfortunately 9.3 is already EOLed ( http://www.juniper.net/support/eol/junos.html ) Tuning J/SRX into packet-mode will lost several valuable functions such as IPsec, Jflow... those are very important for small business. Selective-packet-mode is also a huge pain from operation point of view, also the Jflow will have problem under this. I believe the best solution is to keep pushing Juniper to bring packet-mode OS back to J-series with full functionality. At this moment, Juniper does not have product, my personal opinion, to head-to-head compete against Cisco ISR. J-series could be the most closed product line to fill this gap. -- Michel~ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX, UDP traffic, routing asymmetry
J-series is still using P4 class cpu ,ddr2 memory, where as it is really cheap to upgrade them for now (I bought ~50$ from ebay , 3G cpu, 2.5G ram and it handles several copies of full bgp feed just fine) , it is clear that is not going to last long, they are heading for EOL really soon in my opinion. Forcing j-series to be a security router is a joke, i totally agree though. Speaking of 9.3, i have been running them for almost 2 years now, and it is working great, all the features are there(only ipesc v1 though and it is buggy) and given 10.4 is so horribly slow, I simply have 0 intend to upgrade them. Cheers. On Thu, Dec 6, 2012 at 9:05 PM, Michel de Nostredame d.nos...@gmail.com wrote: On Thu, Dec 6, 2012 at 7:13 PM, 叶雨飞 sunyuc...@gmail.com wrote: downgrade to 9.3R4.4 then Unfortunately 9.3 is already EOLed ( http://www.juniper.net/support/eol/junos.html ) Tuning J/SRX into packet-mode will lost several valuable functions such as IPsec, Jflow... those are very important for small business. Selective-packet-mode is also a huge pain from operation point of view, also the Jflow will have problem under this. I believe the best solution is to keep pushing Juniper to bring packet-mode OS back to J-series with full functionality. At this moment, Juniper does not have product, my personal opinion, to head-to-head compete against Cisco ISR. J-series could be the most closed product line to fill this gap. -- Michel~ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX, UDP traffic, routing asymmetry
On Thu, Dec 6, 2012 at 10:31 PM, 叶雨飞 sunyuc...@gmail.com wrote: J-series is still using P4 class cpu ,ddr2 memory, where as it is really cheap to upgrade them for now (I bought ~50$ from ebay , 3G cpu, 2.5G ram and it handles several copies of full bgp feed just fine) , it is clear that is not going to last long, they are heading for EOL really soon in my opinion. Forcing j-series to be a security router is a joke, i totally agree though. Speaking of 9.3, i have been running them for almost 2 years now, and it is working great, all the features are there(only ipesc v1 though and it is buggy) and given 10.4 is so horribly slow, I simply have 0 intend to upgrade them. Cheers. It looks like Juniper is going to replace J-series by SRX and we heard about that for a long time from our SE, although they used the word possibly. If that really come true, it will be an even huge loss for Juniper on Enterprise routing / small CE market. Hardware wise should be easy to put more powerful CPU/RAM etc to J-series. The question is if Juniper really want to put a router to its portfolio instead a firewall there. -- Michel~ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX, UDP traffic, routing asymmetry
On 12/03/2012 03:48 AM, Dale Shaw wrote: 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). How does this even work? Surely TCP flows through the device just won't go? 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. What kind of special were you thinking of? Obviously each flow will appear as a separate uni-directional session to the SRX, since each device only sees half the traffic. It's possible something funny happens in this situation e.g. if the flow runs for X seconds without a packet in the other direction, drop it. But that's purely speculation. This is probably not what you want to hear, but OSPF is a nightmare in this situation; you end up balancing route metrics constantly (if you want multiple devices forwarding) or just running one device active at a time. We used to do it, and I hated it... cheers, Dale (..on the never-ending quest to make SRXs behave like routers w/IPsec) I feel your pain. It's a mystery to me why vendors seem to be abandoning traditional IPSec on routers in favour of small firewalls with all their attendant problems re: flow symmetry. That said: we run flow-based devices in dual-active mode using BGP rather than OSPF. The reason this works is that judicious use of BGP communities and routing policy can be used to ensure both sides of a flow route via the same path in the steady state - though not in every topology, I'm afraid. The other option is to stick a load-balancer in front of the IPSec terminators. All very yucky. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX, UDP traffic, routing asymmetry
Perhaps these are useful: http://kb.juniper.net/InfoCenter/index?page=contentid=KB25094 http://kb.juniper.net/InfoCenter/index?page=contentid=KB24566 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. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX, UDP traffic, routing asymmetry
SRX as router with IPsec? Have you tried Router Context? Most docs talk about J-series, but it works with SRX as well. If you need security (as in policies and zones) as well, there is selective packet mode. I have done some work in that area, and can give details later (right now I'm off-line and soon asleep). /Per Sent from my iPad, please ignore stupid spelling corrections! 3 dec 2012 kl. 04:48 skrev Dale Shaw dale.shaw+j-...@gmail.com: cheers, Dale (..on the never-ending quest to make SRXs behave like routers w/IPsec) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
