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/UYPLZZOI...