Re: LAG/ECMP and 'exact-route'

[Pedro Prado via NANOG <nanog () lists nanog org>]

Hey James, the command is “show load-balance”. This is the article I linked for Saku:


https://www.arista.com/en/support/toi/eos-4-17-0f/13816-ecmp-hash-visibility

show load-balance destination ip ingress-interface <interface>
{ src-ipv4-address <ipv4-address> dst-ipv4-address <ipv4-address> | src-ipv6-address <ipv6-address> dst-ipv6-address 
<ipv6-address> flow-label <label> } 
ip-protocol <protocol> [ ip-ttl <ttl> ]
{ { inner src-ipv4-address <ipv4-address> inner dst-ipv4-address <ipv4-address> inner ip-protocol <proto> } | { inner 
src-ipv6-address <ipv6-address> inner dst-ipv6-address <ipv6-address> inner ip-protocol <proto> }
[src-l4-port <port#> dst-l4-port <port#> ] [vlan-id <vlan>]

It does use the hardware and as far as I can tell it indeed doesn’t support MPLS as of now.

HTH,


Pedro Martins Prado
pedro.prado () gmail com / +353 83 036 1875

> On 14 Aug 2025, at 13:36, James Bensley via NANOG <nanog () lists nanog org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On Thursday, August 14th, 2025 at 08:26, Saku Ytti via NANOG <nanog () lists nanog org> wrote:
>
> Hi Saku,
>
> > Thanks to Pedro Prado for sharing that Arista has a command for this,
> > and indeed in Arista like in Juniper packet is actually injected to
> > the hardware to get the result.
>
> I'm curious to know what command was provided.
>
> On EOS one can use "show ip hardware ale routes x.x.x.x/xx" to see the next-hop + adjacency details. If I use "show 
> ip hardware ale routes vrf XXX x.x.x.x/xx" (seeing as you're talking about MPLS) then I can also see the egress MPLS 
> encap details that will be used. For example:
>
> L2Adj Id: 114, Adjs: 1, State: Installed, Plat. FEC: 91904, 
> Hierarchy Depths: 0, 
>    Via nextHopHierarchical, Weight: 1,
>        EncapType: MPLS, Operation: push, Label Stack: 116384,
>        L3Intf: IS-IS SR tunnel index 3 (DyTun7340032.3, FecId 432468709529878531),
>        Via L2Adj: 209
>
>
> This uses L2 adj 114, that then recuses via another adj 209, so I need to dig through the recursion stack using "show 
> ip hardware ale adj x" until I get to the bottom to see the whole thing.
>
> One can also use "show ip hardware fib vrf XXX routes x.x.x.x/xx". The first command provides the related adjacency, 
> this second only returns the route without the related adjacency.
>
> This isn't querying hardware AFAIK, but there is the command "show ip hardware fib diff" which shows me there is no 
> diff between software and hardware, so the output is as reliable as it can get (you can never know if the output of a 
> command is 100% correct because it's all closed source).
>
> Neither of these let me query for any input tuple I want though, I'm just specifying the destination address only.
>
> There is the command "show forwarding destination" which allows you to specify some of the header fields, but it 
> expects quite a specific set of headers (e.g. it must be VLAN tagged), doesn't support MPLS, doesn't allow you to 
> specify a VRF (so you can only query the default routing table as far as I can see), and it produces the result of an 
> incoming packet lookup, it doesn't tell you what egress port + encap would be used, so it needs to be executed on the 
> receiving device, not the sending device.
>
> I would be interested to know if anyone has used this command with success, as it does seem to be querying the 
> hardware.
>
> There is also the command "show port-channel load-balance jericho2 fields" (replace jericho2 with your chip name) and 
> "show load-balance port-channel sand fields" (aliases of each other), but this only tells you which fields are 
> parsed, you can't "ask" a question for a user provided tuple.
>
> I think what you actually want to achieve (your original question) is possible if you drop into a BASH shell and use 
> the various debug tools there that aren't documented. I haven't had time to work out the exact syntax yet, but I 
> believe all the required commands are there (you'd need to string a few things together, you can't just write the 
> interface name, and source/dest IP etc, into a single command and get the result). I would be interested to know if 
> anyone has already taken the time to do this. I have already managed to capture the lookup of packets transiting the 
> hardware, so lookups can be captured, just need to get control of triggering that lookup.
>
>
> Cheers,
> James.
>
>
> > I think none of them allow giving MPLS stack though? So mostly useful
> > for cloudy people, not SP people. RFC5837 would more reliably give us
> > the correct answer.
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: ProtonMail
>
> wsG5BAEBCgBtBYJondhHCZCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0
> aW9ucy5vcGVucGdwanMub3JnjXc3oKk7iaDKl5cz5Zari4ZBJElUSllQvUAr
> MkLlvJkWIQQ+k2NZBObfK8Tl7sKoEx+igX+A+wAANqsP/jD9gSxMUGCio8Gw
> X3aaquZYCuRtTUouxNIuivaIAn5eorgiy6dNrAzq7cTpY6VJswCGTlyezMaj
> YpgzXYCr0HB4oALaOLb1ZoL6OHMGlmZXy7nl1isYPefMP13piiEh9xNBhTGb
> E96wEsfb9MF3AJww2W73zxoNEgNZpR3zZf/vXxyZ3+4ao2+JiLYqP17ojBzi
> aB0LsFE74/LjYGap/gH2mCpG7IXai+/jyRgVL2d+LSbYOoKhuYnERZajPjhI
> R1FwoQhWsGjS8CjpWN6fbWHZdqVXXW8i90i0MhDAHYC50CwUouDY5DOhj9UM
> Jv2J3x1inPew66xmR6F0BfA07+ttrT17kpVOA690/98ejxFJzEG/tPG7lW0v
> dKCpvPVS0lMjX8ZBxAb/l4HhrBSRHWzPNtZY4nIuOxt7TGWOrX3dgfoyCb6/
> NbkJV9jgdsCTIASDv/LVE4Md5JS+q7lOnsofTjl8WNBhcP21RdRmxVraQdUV
> nIQYwHZ0ygQNv9nGZl03lAfP7jjsUbZBOiLPmKgPl4gTNqYTgRWViFyOASFP
> yvqV7xeKhKdCBHYXTy2vNoeKRdK0BIz4HPB1FXa4xmbLRpggb0bQBiEnvdVQ
> 7aLe/2v1+B0u90hJYYE7CfnsrL/BGz4OXrq/2Jvznyamr4Tq487OGEF60lR6
> wYB5zNE4
> =ceCY
> -----END PGP SIGNATURE-----
> <publickey - lists+nanog () bensley me - 0x3E936359.asc.sig>_______________________________________________
> NANOG mailing list 
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/UYPLZZOIOR3ZBVRYZWNCQ5YUQBGOCUL6/

_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/ERLDHGPJD3U4FCDOIMAPZXJTARI2KTEA/