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