vMX

Expand all | Collapse all

ECMP over GRE tunnels for ESP traffic

Jump to Best Answer
  • 1.  ECMP over GRE tunnels for ESP traffic

    Posted 03-26-2020 19:21

    Hi everybody,

    Please consider following scenario:

     

     1.1.1.1 --ge0/0/0 MX1  gr-0/0/0.10-----------------gr-0/0/0.10  MX2 ge0/0/0---2.2.2.2

                                             gr-0/0/0/.20-----------------gr0/0/0./20

     

    Above MX1 receives ESP encrypted traffic with outer IP header SRC IP 1.1.1.1, DST 2.2.2.2 on ge-0/0/0.

    MX1 is configured for ECMP for 2.2.2.2, it can reach 2.2.2.2 over two GRE tunnels.

    Since MX1 can see only SRC IP 1.1.1.1, DST 2.2.2.2. other IP header fileds, not the payload which is ESP ( encrypted), therefore only SRC IP and DEST IP will be factored in calculating hashing for ECMP . Does it not mean only single gre tunnel will be used to route to 2.2.2.2 as hash value will be same because SRC IP/DST IP are not changing?

     

    Have a good weekend!!

     

     

     

     

     

     

         



  • 2.  RE: ECMP over GRE tunnels for ESP traffic
    Best Answer

    Posted 03-26-2020 22:52

    Hello,

     


    @sarahr202 wrote:

    Does it not mean only single gre tunnel will be used to route to 2.2.2.2 as hash value will be same because SRC IP/DST IP are not changing?

     

     


     

    Correct. And this is actually a good thing if You recall that IPSEC anti-replay is ON by default.

    In plain English - ECMP load-balancing for IPSEC when anti-replay is ON is bound to wreak havoc on packet order and result in slow t'put as a result.

    HTH

    Thx

    Alex

     

     

     



  • 3.  RE: ECMP over GRE tunnels for ESP traffic

    Posted 04-03-2020 12:49

    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. 

    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 .

     

    What are your thoughts?

     

    Thanks and have a good weekend!!

     

     

     

     

     

     

     

     

     

     

     

     

     



  • 4.  RE: ECMP over GRE tunnels for ESP traffic

    Posted 04-03-2020 21:40

    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