Thats interesting. I'll see what I can find tomorrow, I'm quite sure this was working in my lab setup. But that could have been with reth interfaces (we didn't use non-reth because before 10.2R3 we experienced issues with packet loss on the FAB link).
All good questions, juniper should write some KB articles about all this. This is where the SRX is different from the routers because it is stateful and because you can also use per-packet filters on SRX (for example for FBF), this can get really confusing.
How is the routing table consulted for the reverse route during session init (routing instances, zones, etc - what matters?)
Each interface is in exactly one virtual-router. Either the default one or a routing-instance of type virtual-router. When the first packet of a session arrives on an interface, a route lookup is performed in the corresponding table, for both source and destination.
Say you have something like this:
Client ---- [reth1] (Client-VR) (Server-VR) [reth2] ---- Server
If the client sets up a connection to the server, a destination route lookup is performed in Client-VR and a session is created. When the server responds, the SRX performs a session lookup, finds the existing session and will lookup up the reverse route in Client-VR again. Server-VR doesn't even need a route back to the client. Any FBF filters you may have applied on reth2 are ignored as well!
I use this behavior a lot to connect multiple ISPs to the SRX, each with its own PA address space. If a client connects to an IP from ISP1, it is important that the response is routed back through that same ISP because ISP2 would simply drop the traffic. So place each ISP in its own virtual-router and everything will work fine.
How exactly do routing changes propagate into the session
We have had quite a few discussions about this and it is on my list of things to test. Here are some things I do know:
- the route can't change to another egress zone. That would require a new policy lookup which simply doesn't happen.
- if the original route is still valid, nothing changes and the traffic is still routed that way. I often change route preferences to redirect traffic and this only affects new sessions, existing sessions still use the old path.
Sometimes this can be a problem. This is a good example: http://geogeeks.net/blog/2010/12/juniper-srx-udp-problem/
Questions still to be answered:
- Can a session failover be done from one interface to another if both interfaces are in the same zone?
- Can a session failover by done from an ethernet to a VPN interface? ScreenOS always had a problem with this but its possible in the more recent versions.
I need more time for labs 🙂