How to avoid flow asymmetry on SRX

One of the challenges for those who are new to SRX and deploy a dual ISP scenario is to keep the symmetry of the packet flow. One picture worths thousand words so let’s have a look at what I am trying to say.

I will explain each steps to see how things may go different than your expectations;

• 1 – A user somewhere on Internet sends a request e.g UDP request for port 53 towards IP 2.2.2.10 which is further NATted to the internal server 172.16.1.2. Request arrives ISP2 due to normal routing.
• 2 – ISP2 router passes this UDP datagram to SRX device
• 3 – When SRX receives this first packet, it needs to create a flow session. During session creation, SRX needs to know how it can reach the source address of the packet which is done by reverse route lookup. SRX here consults its routing table and finds that default routing is via ISP1 1.1.1.1 and installs the session with this information.
• 4 – When 172.16.1.2 replies the UDP request, SRX this time doesn’t perform any route lookup as it has already got the next hop during session creation and sends the packet to ISP1 instead of ISP2 where the packet originally came from.

Now the question we must ask is why this is happening. Why it doesn’t detect that packet should be forwarded via the same PATH i.e ISP2. The thing is that route lookup must be done on a specific context and SRX chooses this as the packet’s incoming routing instance or more specifically, it does the route lookup on the routing instance to which the ingress interface of the first packet belongs. In our default example, all interfaces are on the default routing instance at which the reverse route lookup is performed.

In order to provide symmetry, we can put the ge-0/0/1.0 interface in a different routing instance which is something like this;

ISP2 {
    instance-type virtual-router;
    interface ge-0/0/1.0;
    routing-options {
        static {
          route 0.0.0.0/0 next-hop 2.2.2.2;
        }
    }
}

By doing this, flow will perform the reverse route lookup on this new routing instance and sends the return packet through the ingress PATH but there is one missing item in this scenario. If we put the interface in a different routing instance, during forward lookup of the session creation, flow won’t be able to find the destination route 172.16.1.2 properly as it is on default routing instance. Because of this you must import routes e.g by using rib-groups from default to the custom routing instance ISP2. Configuration like below should work I believe.

[edit]
root@SRX# show routing-options 
interface-routes {
    rib-group inet master-to-instance;
}
rib-groups {
    master-to-instance {
        import-rib [ inet.0 ISP2.inet.0 ];
    }
}

Theory behind this logic is well explained at this KB if you want to get more information.

You have got an experience with asymmetric flow, then drop here a comment about it!