Hello,
@sarahr202 wrote:
Thanks Alex,
Totally agreed why ECMP ( when anti -replay is on) can be diastrous because it may cause packets to arrive out of order , potentially triggering anti-replay attack on the receiver site . But only if we are sending one packet one path, 2nd packet on the other path.
It's more complex than that with anti-replay window but let's assume it for simplicity.
@sarahr202 wrote:
Below are my thougths:
1) We can still encode some value in IPSEC imposed IP header that will help to distinguish the flow.
For example:
1)IPSEC end point 1.1.1.1 receives IP packet PA associated with flow1, PA carries CS1 ( TOS), IPSEC end point simply reflect CS1 value in IPSEC imposed IP header. Thus CS1 is exposed in outer ip header
2)IP sec end point 1.1.1.1 receives IP packet PB associated with flow2, PB is carries CS2 ( TOS), IPSEC end point simply reflects CS2 in IPSEC imposed ip header. Thus CS2 is exposed in outter ip header
3) MX1 is configured to factor in TOS values in calulating the hash ( enhanced hash).
MX1 can now see two different hash values for flow1 and flow 2, because TOS is different. If these two hash values are mapped to to different equal path, flow1 can be sent on one link, flow2 can be sent over other. If those hash values happen to be mapped to same link, we can use hash seed .
Again, it's more complex than that. Juniper hash algorithm is not round robin, it's CRC31+CRC13, making it 44 bits long, and then 9 bits of it are actually used to select the outgoing link. So, You are bound to try 2^3 x 2^3 = 64 permutations of IP TOS for 2 tunnels until You arrive at hash values that result in tunnel1 taking link 1 and tunnel2 taking link 2, and that's not guaranteed since 3 bits of entropy may be not enough for 9 hash bits to be sufficiently different.
Also, when link 1 drops, tunnel1 would take the remaining link2 anyway. Ditto for link2.
In fact, using FBF based on IP TOS is going to get You acceptable results much sooner.
HTH
Thx
Alex