Is ECMP supposed to work on SRX cluster?

[motd]

After performing some tests, I'll have to correct what I wrote earlier. Route changes do affect sessions but only if no routing-instances are involved.
If a session is established over interface X and a routing change occurs sending the traffic out via interface Y, the following happens:

-All traffic is now sent out via interface Y. if X and Y are in the same zone => no problem. As expected the session can still be matched. Note that in "show security flow session", the egress interface still shows X even though the traffic is now routed through interface Y.

- If X and Y are in different zones => the egress packest are dropped with message "packet dropped, pak dropped since re-route failed". At this time, the session will remain in the session table and all subsequent packets will be dropped with the same error message. If the "route-change-timeout" setting is set, the timeout of the session will be reduced to that value as soon as this error is encountered. It doesn't change when the routing changes, but only when traffic is seen.

- If the sessions exit through another routing-instance, route changes do NOT affect the session. This is why in our setup I can change the default route to another ISP without losing the already established sessions. New sessions follow the new route, the existing ones still use the original route.
I couldn't find a way to cause the session to be re-routed by changing routes in the client-side or server-side routing-instances.

---

Regarding asymmetric routing, do you know if it

works on high-end SRX (3k/5k)? For example, packet comes in NPC1, leaves
through NPC2. The return packet is routed back through NPC3. Assume zone is
the same. The doc says that session is installed in incoming and outgoing
NPC, so it will be 1 and 2, and NPC3 will not know about the session and
drop the traffic. Right? Unfortunately I can't check this in lab...

---

Don't know about that one, I would assume that because NPC3 doesn't know about the session, the packet is send to the CP which knows about the session and installs it in NPC3 as well. But I don't have the lab equipment available to test this either. I know there is a detailed explanation about this in the courseware (I think in AJSEC), but I don't have access to those right now - which I could get them in PDF.

[pk]

Hi motd,

Thanks a lot for that lab results, this is what I really wanted to know but was too lazy (or busy?)

to test myself...

I've got AJSEC book, it has some details about packet processing in the Appendix, but

I could not find a clear answer to asymmetric routing question. It is not obvious for me

if the return packet from different NPC will be sent to CP and if the CP will be able to

unterstand that it belongs to an existing session and new NPCs should be programmed

for the same session...

[rasmus]

pk, reall nice and informative discussion ...

regards

[JJJ]

http://kb.juniper.net/InfoCenter/index?page=content&id=KB23417

SRX support ECMP flow-based forwarding after 12.1.

[pk]

Hi JJJ

Thanks for updating this old thread. Can you confirm that this is also

working on the cluster? Sorry but I lost too much blood with this problem

so I will not mark thread as "solved" until I'm absolutely sure it works... 

[pk]

Hi All

Just an update, I tested ECMP with cluster running 12.1X44-D10.4. It is working if I have several

uplinks on one node, but for uplinks connected to different nodes, there is no load balancing. 

However if load balancing is turned on (export policy to forwarding table, etc), outgoing traffic seems to 

choose the incoming node's uplink, so fabric link forwarding is minimized this way.

So I will mark Motd's first answer a a solution for now.

[asbestos-muffin]

Hi, All.

Given that the SRX would create the session ingress/egress interfaces based on the forwarding table as shown at another thread, how would ECMP influence it now?

If reth0 and reth1 are both ECMP default routes, is there a guaranteed behavior that sessions created for incoming connections at reth0 would not user reth1 for return traffic because of ECMP?

I am migrating our design to multiple VRs for ISPs and came accross the KB for ECMP support on 12.1. It would be great if someone could confirm the SRX behavior in this use case.

- asbestos-muffin