>
> Unfortunately the 'show forwarding-options load-balance' doesn't allow
> giving MPLS label stack to it which greatly limits utility for SP
> networks.


I *think* that you can use the packet-dump option to paste a packet in hex
and it will give the proper result with the label stack considered. It was
a couple years ago I tried this, and my memory is fuzzy if it did work
correctly or not. Even if it did work it's obvious clunky as hell to have
to slap a hex decode in there.

I did find a note that I asked for an ER to allow label IDs on the CLI, but
I can't find anything further if they said yes/no. I'll ask.

On Thu, Aug 14, 2025 at 2:26 AM Saku Ytti via NANOG <[email protected]>
wrote:

> Thanks Nitzan, that was what I was thinking, that is quite recent (to
> me) and I suspect it is syntactical sugar for 'jsim'?
>
> Unfortunately the 'show forwarding-options load-balance' doesn't allow
> giving MPLS label stack to it which greatly limits utility for SP
> networks.
>
> Steinar, in your experience does the bundle-hash give correct results?
> Is it actually injecting packets to ezchip/lightspeed and getting
> results from the HW (cef exact-route is not doing this at least).
>
> 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 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.
>
> On Thu, 14 Aug 2025 at 09:10, Nitzan Tzelniker via NANOG
> <[email protected]> wrote:
> >
> > For JUNOS I think that you are looking for
> > user@lab> show forwarding-options load-balance ?
> > Possible completions:
> >   destination-address  Destination IP address
> >   destination-port     Destination port
> >   family               Layer 3 family
> >   ingress-interface    Ingress Logical Interface
> >   packet-dump          Raw packet dump in hex without '0x'
> >   source-address       Source IP address
> >   source-port          Source port
> >   tos                  Type of Service field
> >   transport-protocol   Transport layer protocol
> >
> > Nitzan
> >
> > On Tue, Aug 12, 2025 at 5:58 PM Saku Ytti via NANOG <
> [email protected]>
> > wrote:
> >
> > > Hey-o,
> > >
> > >
> > > Which platform/software has a command to show which interface will be
> > > used for forwarding with given keys?
> > >
> > > ASR9k has a cef exec-route, and I see references to this in c-nsp,
> > > reddit and cisco.com forums, stressing how useful debugging tool it
> > > has been. Despite it not actually working, since it's just RE
> > > software, it doesn't talk to the EZchip/lightspeed, unless it has been
> > > fixed in the past couple of years, certainly hasn't worked in the
> > > timeline of various forums finding it useful.
> > >
> > > MX has 'jsim'
> > >
> https://www.juniper.net/documentation/en_US/day-one-books/TW_MX3D_PacketWalkthrough.pdf
> > > which I think actually works, but it is quite involved. I have some
> > > (false?) memory that I saw in some release note this being a bit more
> > > productised into CLI command, but I'm failing to find anything to
> > > support this memory.
> > >
> > > There is also RFC5837, which is actually implemented in QFX5k, but not
> > > for TTL exceeded, we've opened ER to get it supported on MX and PTX
> > > and for TTL exceeded. This RFC will allow programmatic platform
> > > agnostic discovery of the actual interface used, without relying on
> > > platform specific magic. So please do ask your vendors to implement
> > > it.
> > >
> > > --
> > >   ++ytti
> > > _______________________________________________
> > > NANOG mailing list
> > >
> > >
> https://lists.nanog.org/archives/list/[email protected]/message/65IZUIUM3WTM56W3CLM6HOGK2T7DCEKF/
> > >
> > _______________________________________________
> > NANOG mailing list
> >
> https://lists.nanog.org/archives/list/[email protected]/message/HHWSKHAH2RWUUZN5XMLUCOKMCCLXCK77/
>
>
>
> --
>   ++ytti
> _______________________________________________
> NANOG mailing list
>
> https://lists.nanog.org/archives/list/[email protected]/message/DMC65GBTZVZXSWB3NBCCOO7YRBWAXLGS/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/[email protected]/message/YQQFFLNGNQUVPKOR7QCFQUSI445NO2K6/

Reply via email to