[j-nsp] "show ip cef exact-route"

[Zsolt Hegyi]

> ^ After running "jsim run" I receive lots of output that is going to
> take a long time to reverse engineer and work out what it all means. I
> haven't got the time right now so I was hoping JTAC would help but I
> guess I'll just have to work out it for myself.

In case you haven't read it yet, there is a free book called *This Week: An
Expert Packet Walkthrough on the MX Series 3D* by David Roy, it has a bunch
of examples on using *jsim* and other FPC/PFE commands, including what I
think might be your exact use-case. Might come in handy.

Zsolt

On Tue, May 15, 2018 at 10:47 AM, James Bensley <jwbensley at gmail.com> wrote:

> On 15 May 2018 at 02:51, Nikolas Geyer <nik at neko.id.au> wrote:
> > Someone at Juniper has kindly reached out and advised that a similar
> command was added in 17.1R1 for the MX;
> >
> > https://www.juniper.net/documentation/en_US/junos/
> topics/reference/command-summary/show-forwarding-
> options-load-balance-ingress-interface.html
>
> I should have been clearer I guess - although the example link I
> provided was to find the outgoing interface when using ECMP, I simply
> wanted to supply ingress details and find the egress details, for a
> single link. This is what I can do with "show ip cef exact-route...".
> I can specify the ingress/input details as apposed to commands like
> "show route ...." which show egress information without considering
> any ingress information.
>
>
> > On 14 May 2018, at 7:32 pm, Saku Ytti <saku at ytti.fi<mailto:saku at ytti.fi>>
> wrote:
> >
> > Have you found cef exact-route to be correct?
> >
> > Last time I used this (ASR9000), it was giving wrong results to me. I
> > think there is entirely separate piece of code for LAG result in
> > software code and the CSCO EZChip microcode, and different people code
> > IOS-XR than ezchip, so I think there is failure mode where one code is
> > updated, and another is not, I hope I'm wrong.
>
> In the case of non-ECMP/LAG which is what I was referring to - "what
> is the egress interface AND egress encapsulation details when a
> packing ingresses with details X?". That is what I get from "show ip
> cef exact-route ..." on IOS/IOS-XE/IOS-XR. In this single egress/path
> case - yes "show ip cef " works fine for me.
>
> With regards to ECMP/LAG you need to run some extra commands that are
> often platform specific. For ASR9K for example use the "bundle-hash"
> command - I haven't used it in a while but I think that is what you're
> looking for (e.g. "bundle-hash bundle-ether 1 location 0/0/CPU0").
>
> > But if I'm right, then the only way to do this, is actually ask the
> > microcode 'hey i have this packet, do a lookup for it', or like in
> > CAT7600/ELAM, get lookup results for real traffic.
>
> Yes, 7600 ELAM is great - all platforms should have this. This is
> exactly what I want. The reason is that I can match any ingress packet
> (by specifying a mask in hex to match the packet headers) and it will
> not only tell me the egress details for "good" paths but also for bad
> paths it shows me the egress drop interface which might be a drop/null
> interface ID, hardware policer, or that the packet was recirculated,
> etc. So when packets aren't passing through the device as expected I
> can see whats happening in hardware - this is what I'm interested,
> when things don't work properly, how can I ask the hardware what it's
> doing with the packet in Junos.
>
>
> > On 15 May 2018 at 02:27, Nikolas Geyer <nik at neko.id.au<mailto:nik@
> neko.id.au>> wrote:
> > Unless it’s changed in newer releases there is no equivalent which is
> annoying.
> >
> > I believe you can drop to the FPC vty and extract the information card
> by card similar to the link you shared, but it’s not exactly a workable
> solution, nor “officially supported” by Juniper.
> >
> > The lack of this command is literally my biggest frustration with
> Juniper.
>
> I believe it is there - it's just a private/internal tool. JSIM is
> like 7600 ELAM, we can build a parcel and sent it to the PFE/PPE and
> get the response. JTAC closed my case asking how to use it, they
> refused to provide any documentation or explanation, which is very
> unhelpful.
>
> NPC0(abr2-ld5slo.core vty)# set jsim input-port wan
>
> NPC0(abr2-ld5slo.core vty)# set jsim ipsrc 10.0.0.50
>
> NPC0(abr2-ld5slo.core vty)# set jsim ipdst 10.0.0.20
>
> NPC0(abr2-ld5slo.core vty)# set jsim ip-protocol 1
>
> NPC0(abr2-ld5slo.core vty)# show jsim packet
> 0000000000000000
> 0000000000000000
> 0000080045000032
> 0001000020018685
> 0a0000320a000014
> 0000000000000000
> 0000000000000000
> 0000000000000000
> 000000000000
>
>
> NPC0(abr2-ld5slo.core vty)# jsim run 1
> [May 11 12:22:10.114 LOG: Info] TTRACE PPE14 Context2 now in-active.
>
>
> ^ After running "jsim run" I receive lots of output that is going to
> take a long time to reverse engineer and work out what it all means. I
> haven't got the time right now so I was hoping JTAC would help but I
> guess I'll just have to work out it for myself.
>
> Cheers,
> James.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>