[j-nsp] "show ip cef exact-route"
jwbensley at gmail.com
Tue May 15 04:47:49 EDT 2018
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;
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 at 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
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
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.
More information about the juniper-nsp