> ^ 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 <jwbens...@gmail.com> wrote: > On 15 May 2018 at 02:51, Nikolas Geyer <n...@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 <s...@ytti.fi<mailto:s...@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 <n...@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@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp