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.

srx-flow-routing-asymmetry-symmetry

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!

About: rtoodtoo

Worked for more than 10 years as a Network/Support Engineer and also interested in Python, Linux, Security and SD-WAN // JNCIE-SEC #223 / RHCE / PCNSE


10 thoughts on “How to avoid flow asymmetry on SRX”

  1. I have had a similar issue, not with internet traffic, but between different zones/routing-instance. That case we just imported the interface routes into the rib group.

  2. hey im curious about this symetric and asymetric.

    If i have dual isp connection, dual edge router, 2 local network(LOCALNET_A & LOCALNET_B), have AS number with 1 ip public number /24, and want to do a load sharing internet connection.
    A user browse internet, to do load sharing does it have to consider the return traffic ?
    Or i just config the network that route from LOCALNET_A to Internet Must Through ROUTER_A and route from LOCALNET_B to Internet Must Through ROUTER_B.

    Thx

  3. you are sure that this solution is working? I feel the same on stage in operation and can not afford to make unnecessary network outages.

  4. Victor, it is the current architecture and I don’t think it has been changed. You can also check the KB. If you want to try, you can fire up a vSRX and try it yourself.

  5. Hi Rtoodtoo, I have a exact scenario just like your diagram. In my scenario, g0/0/0 and g0/0/1 are in zone “external”, interface connected to server is in zone “internal”, all these interfaces are in the same routing-instance.

    my question is even if this asymmetry exist, will this cause any problem?

    by the way, I have configured policies between these two zone for both directions.

    thanks!

    1. James, I personally dislike asymmetry. In our scenario, we have NAT so if packet comes from one ISP2 but headed to another ISP1 then your return IP packet will have a source address which belongs to ISP2. This is how I remember. It has been sometime that I haven’t worked with SRX. Then you will have a problem at some point on one of the hops. If not now, later
      and TAC don’t really like asymmetry:)

      Genco.

  6. We have a customer using the any-connect vpn of the remote site to connect to their network. his vpn connection is dropped after the initial success. we are using the Junos FW (node 0 and node 1) facing the internet. what could be the problem?? Do you think the problem with the asyn routing?? I don’t think so, as the two nodes are synchronised.

Leave a Reply to JonathanCancel reply

Discover more from RtoDto.net

Subscribe now to keep reading and get access to the full archive.

Continue reading