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 [email protected] / +353 83 036 1875 > On 14 Aug 2025, at 13:36, James Bensley via NANOG <[email protected]> > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On Thursday, August 14th, 2025 at 08:26, Saku Ytti via NANOG > <[email protected]> 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 - [email protected] - > 0x3E936359.asc.sig>_______________________________________________ > NANOG mailing list > https://lists.nanog.org/archives/list/[email protected]/message/UYPLZZOIOR3ZBVRYZWNCQ5YUQBGOCUL6/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/ERLDHGPJD3U4FCDOIMAPZXJTARI2KTEA/
