Switching

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 🙂 ) ?

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

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

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.

Maybe BGP traceoptions:

https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/traceoptions-edit-protocols-bgp.html

https://www.juniper.net/documentation/en_US/junos/topics/reference/command-summary/show-forwarding-options-enhanced-hash-key-ex-series.html

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!!!

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

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.

@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.

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

Awesome details, thank you !