Hi Joe,
That keeps per-connection state. Be aware of the repercussions!
Adrian
We replaced our OpenBSD routers with these SRXes since they were supposed to
be multifunction devices (gateways and routers at the same time) which was
the selling point. So we expected them to do asymmetric routing and were
told they could, easily, but apparently they are not acting normally and
also the configuration is perfect according to JTAC.
It sounds like a mis-communication on everyones' parts.
I've come across plenty of systems-oriented people who believe the behaviour
of network edge devices is what you've said - because various hosts (eg
Linux) treat sockets, routing, ethernet active/standby, etc a specific way
and this is not how "traditional" routing/edge devices behave. 
Adrian
Ken Gilmour wrote:
Strangely, BGP actually works without issues. The only issue is with statically routed ranges.
Same rules apply, just without control on your end. If a packet hits ISP2, ISP2 will send it to you by most ISP standards (prefer direct customers over peers). Outbound, you will send your normal route (you prefer ISP1).
There are methods of handling session based routing in some products from what I gather, but in traditional routing, each direction of a session is independent (session = 2 flows) and the router is unaware of actual sessions.
Some real world examples I've dealt with which reduces asymmetric routing, though not always eliminates it.
1) full backup ISP (we don't use it unless there's no other options)
a. AS prepend (tell the outside world we prefer them not to come this way)
b. community to ISP setting local pref (if the packet does hit provider, tell the provider we prefer them to use their external peer over sending direct to us).
c. set local pref on received routes so they are least preferred.
2) backup with partial traffic (generally we want to receive and send packets via this ISP if the customer is directly connected to them).
a. AS prepend (least preferred way to reach me)
b. set local pref on received routes based on providers communities (perhaps we'll only send this way if it's a non-bgp customer, or to any network which didn't come through exchange points; very ISP dependent).
The goal of the second is to reduce asymmetric traffic, while allowing us to use the backup link to reach the ISP's networks and their directly connected customers. Some multihomed customers may still go asymmetric. Primarily used in cases where ISP has piss poor exchange connectivity at times, so you want to reach their customers without going the long way around through the exchanges.
The first I've used before with split network scenarios, where one provider handles some networks, and the other provider handles other networks. Setting the local pref forces traffic even on ISP2 (backup ISP for specific network) to make it's way to ISP1 (primary ISP for the specific network) instead of coming direct (suboptimal, but symmetric). Source address based policy rules pushed traffic back out the correct path for that network so long as it was available.
Jack
Gonna really highlight my ignorance here, but....
Given the terminology (primary" and "secondary" or "standby" (I forget
the exact terms used) in the OP, is it true that traffic arriving on the
secondary when the primary is up is a bad thing?
Given that to be true, is there no way in BGP to make the secondary look
poorer than the primary?
Or something.
Then you should look at your IGP, right?
* Ken Gilmour:
ISP1 is the default gateway, ISP2 is a backup provider but which is always
active. Client comes in on ISP1's link, traffic goes back out on ISP1s link.
Client comes in on ISP2's link (non default gateway) but for some reason,
the packets seem to be going back out through the link for ISP1.
You cannot use Juniper's software forwarding platforms in this
scenario. This may sound like a drastic verdict, but I think it's a
pretty accurate summary of the situation.
Perhaps you can coax the software forwarding platforms into packet
mode (instead of flow mode), but from the documentation, I get the
feeling that Juniper doesn't want you to do that (at least on
J-series). You also lose some functionality if you do that. Moving
the filters to a different box doesn't help, either.
So you either have to buy real Juniper routers (and the necessary
service modules to implement this), or switch vendors.
This is perfectly normal and acceptable. The problem you are having (the traffic ultimately disappearing) is that bad behaviour is happening, caused by flow-mode. It does not work. Juniper trying to force flow-mode in J-series since 9.4 has helped our Cisco mid-range hardware sales no end. Are you reading Juniper ? It does not work !
Anyway, I digress.
You need to put a filter on your interfaces that references a filter later on to not session track a flow. I think you need to be running Junos-jsr[0] 10.0 or 10.1 to use this :
interfaces {
ge-0/0/X {
family inet {
filter {
input [ packet-mode-in ....... ]
output [ packet-mode-out ......... ]
}
}
}
}
firewall {
family inet {
filter packet-mode-out {
term stuff {
from {
something
}
then {
packet-mode;
accept;
}
}
}
}
}
When we were trying to make this work reliably in the <Junos-jsr 10 days, there were guides on juniper.net advising the following too, which we have preserved :
security {
alg {
dns disable;
ftp disable;
h323 disable;
mgcp disable;
msrpc disable;
sunrpc disable;
real disable;
rsh disable;
rtsp disable;
sccp disable;
sip disable;
sql disable;
talk disable;
tftp disable;
pptp disable;
}
flow {
allow-dns-reply;
tcp-session {
no-syn-check;
no-syn-check-in-tunnel;
no-sequence-check;
}
}
}
Best wishes,
Andy Davidson
[0] "One Operating System, One Big Advantage" ?
You need to put a filter on your interfaces that references a filter later on to not session track a flow. I think you need to be running Junos-jsr[0] 10.0 or 10.1 to use this :
The same goes for 9.x, just be sure to except traffic to the router
(like BGP session) from the packet-mode, they need to be in flow mode.
Traffic routed from one interface to another can be in packet mode.
Rubens
* Rubens Kuhl:
You need to put a filter on your interfaces that references a
filter later on to not session track a flow. I think you need to
be running Junos-jsr[0] 10.0 or 10.1 to use this :The same goes for 9.x, just be sure to except traffic to the router
(like BGP session) from the packet-mode, they need to be in flow mode.
Traffic routed from one interface to another can be in packet mode.
And that's totally broken because your perfectly fine multihop BGP
session could break when rerouting occurs. *sigh*
your perfectly fine multihop BGP session could break when rerouting
occurs.
one of the many reasons that there are no perfectly fine multi-hop bgp
sessions.
randy
* Randy Bush:
your perfectly fine multihop BGP session could break when rerouting
occurs.one of the many reasons that there are no perfectly fine multi-hop bgp
sessions.
Uhm, is there a way around them when building the iBGP mesh?
your perfectly fine multihop BGP session could break when rerouting
occurs.one of the many reasons that there are no perfectly fine multi-hop bgp
sessions.Uhm, is there a way around them when building the iBGP mesh?
nope
Not using flow-based devices as datagram routers when they aren't ?
Rubens
* Rubens Kuhl: