Switching

Expand all | Collapse all

Verify LAG Hashing

Jump to Best Answer
  • 1.  Verify LAG Hashing

    Posted 07-31-2020 08:43

    Is there a way on a QFX5100 or EX4300 running JunOS 18.4R2-S3 to verify if two different sessions hashed to different values or the same, given we have all the parameters for the hash calculation ?

    Ultimately I would like to see if two separate BGP sessions would share the same physical link in a LAG or not ? And if yes, which one (as a bonus 🙂 ) ?



  • 2.  RE: Verify LAG Hashing

     
    Posted 07-31-2020 09:51

    Take a look at this and let me know if it helps

     

    https://kb.juniper.net/InfoCenter/index?page=content&id=KB28946&actp=METADATA



  • 3.  RE: Verify LAG Hashing

    Posted 07-31-2020 09:58

    Thank you for this.

    I also came across this article, but it only explains how the hash value is calculated but does not give a method to verify the actual value for a specific case.



  • 4.  RE: Verify LAG Hashing



  • 5.  RE: Verify LAG Hashing

    Posted 08-01-2020 12:29

    Hi Lacko,

     

    I know what you are looking for. Unfortunately, there is no command available to check the hash result and the physical interface that's been chosen to send the traffic out in EX/QFX devices. However, the command is available for MX and T series routers - https://www.juniper.net/documentation/en_US/junos/topics/reference/command-summary/show-forwarding-options-load-balance-ingress-interface.html

     

    I think there should be an internal debug tool to verify this behaviour in PFE level for EX/QFX devices and the only way to find this out is to raise a technical case with JTAC.

     

    If this is a business requirement and you will be using this day in, day out then I would recommend you to contact your Juniper Accounts Team for filing an Enhancement Request. They will let you know the possibility.

     

    Have a Nice Day!!!



  • 6.  RE: Verify LAG Hashing

    Posted 08-02-2020 08:59

    @π00bm@$t€® : Thank you, I will ask JTAC next time. Anyway a case is open for the issue.



  • 7.  RE: Verify LAG Hashing

     
    Posted 08-02-2020 03:50

    Since you are talking about two bgp sessions between the same neighbors on the same link bundle they are almost certainly on the same physical link since all the parameters used by hashing are the same for both sessions.

     



  • 8.  RE: Verify LAG Hashing

    Posted 08-02-2020 09:04

    @spuluka : What I am talking about are two BGP sessions between different source/destination addresses over irb interfaces. Moreover, only the source is the same box, remote peers are on different MX routers. So I don't really believe the hashing input parameters would match.



  • 9.  RE: Verify LAG Hashing
    Best Answer

    Posted 08-03-2020 00:42

    Hello,

     


    @lacko wrote:

    Is there a way on a QFX5100 or EX4300 running JunOS 18.4R2-S3 to verify if two different sessions hashed to different values or the same, given we have all the parameters for the hash calculation ?

     


     

    The short answer is that locally-generated traffic is NOT hashed and this implementation is common for all JUNOS products.

    The long answer is that Routing Engine builds the complete BGP packet including Ethernet header, encapsulates it in TTP (TNP Tunneling Protocol), adds L2 outgoing interface index and sends the resulting PDU down to linecard CPU.

    The linecard CPU decapsulates this L2 packet inside and uses DMA (direct memory access) to write the complete L2 packet into correct PFE chip memory, from where this L2 packet is put on to correct wire.

     

    Please see below the example TTP packet containing BGP keepalive:

     

    10:08:42.905893 Out 
            Juniper PCAP Flags [Ext], PCAP Extension(s) total length 16
              Device Media Type Extension TLV #3, length 1, value: Ethernet (1)
              Logical Interface Encapsulation Extension TLV #6, length 1, value: Ethernet (14)
              Device Interface Index Extension TLV #1, length 2, value: 64
              Logical Interface Index Extension TLV #4, length 4, value: 3
            -----original packet-----
            IP (tos 0x0, ttl  64, id 2814, offset 0, flags [none], proto: unknown (84), length: 151) 128.0.0.1 > 128.0.0.16: TTP, type L2-tx (2), ifd_output 184, pri unknown (0), length 111
            proto unkwn (0), hint(s) [no key lookup] (0x10001009), queue 3
            ifd_mediatype Unspecfied (0), ifl_encaps unspecified (0), cookie-len 0, payload unknown (0x00)
            -----payload packet-----
              unknown TTP payload
              0x0000: 0000 0161 8000 2c6b f5d5 fec4 2c6b f546 
              0x000f: 7dc0 0800 45c0 005b 0afc 0000 4006 2723 
              0x001f: c0a8 636b c0a8 6302 d192 00b3 0f3c 458c 
              0x002f: f0f2 d2c6 d018 4000 d6df 0000 0101 080a 
              0x003f: a94d de98 27c5 8e6c 0101 1312 d727 8267 
              0x004f: d4f3 6738 5c4a 4b5f 2e90 1af4 ffff ffff 
              0x005f: ffff ffff ffff ffff ffff ffff 0013 04

     

     

    A one can see, L2 interface index is 184, and this corresponds to xe-0/2/1 LAG member:

     

    regress@pre7> show interfaces xe-0/2/1 | grep index 
      Interface index: 184, SNMP ifIndex: 577
    
    regress@pre7> show configuration interfaces xe-0/2/1 | display set 
    set interfaces xe-0/2/1 gigether-options 802.3ad ae4

     

     

    In JUNOS, the "oldest LAG member link" is used to send out the locally-generated packets. Which is an obvious decision - to prevent sessions flapping in case a new and unstable LAG member link is added to the LAG.

     

    So, if You have several BGP peers all reachable via the same LAG (AE interface) then the locally-generated packets belonging to BGP sessions towards those peers will use the same oldest LAG member link.

     

    HTH

    Thx

    Alex

     

     

     

     



  • 10.  RE: Verify LAG Hashing

    Posted 08-03-2020 10:00

    Awesome details, thank you !