Ethernet Switching
Highlighted
Ethernet Switching

Verify LAG Hashing

[ Edited ]
2 weeks ago

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 :slightly_smiling_face: ) ?

9 REPLIES 9
Highlighted
Ethernet Switching

Re: Verify LAG Hashing

2 weeks ago

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

 

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

Highlighted
Ethernet Switching

Re: Verify LAG Hashing

2 weeks ago

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.

Highlighted
Ethernet Switching

Re: Verify LAG Hashing

2 weeks ago
Highlighted
Ethernet Switching

Re: Verify LAG Hashing

2 weeks ago

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

 

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



Thanks,
π00bm@$t€®.
Please, Mark My Solution Accepted if it Helped, Kudos are Appreciated too!!!
Highlighted
Ethernet Switching

Re: Verify LAG Hashing

2 weeks ago

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.

 

Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
Highlighted
Ethernet Switching

Re: Verify LAG Hashing

[ Edited ]
2 weeks ago

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

Highlighted
Ethernet Switching

Re: Verify LAG Hashing

[ Edited ]
2 weeks ago

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

Highlighted
Ethernet Switching
Solution
Accepted by topic author lacko
2 weeks ago

Re: Verify LAG Hashing

2 weeks ago

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

 

 

 

 

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Highlighted
Ethernet Switching

Re: Verify LAG Hashing

2 weeks ago

Awesome details, thank you !

Feedback