mpls label sniffing should work w/ RITE?

[ashirel]

for instructional purposes, i need to show the mpls label in packets via wireshark.

i have 4 physical routers (2911's +1900) config'd for mpls. the 'show mpls ldp discover',

'sho mpls forward', 'sho mpls ldp bindings' all look ok.

i config'd RITE (traffic export)  and i see all the traffic and ldp packets.

HOWEVER, when i do a simple ping from end to end, i don't see the mpls label

between layer 2 and layer 3.

any reason why RITE w/ wireshark will miss this?

this is not a php issue because i'm monitoring a router port which does not connect to

an edge router.

should i be using the 'monitor capture' feature instead of RITE?

i enabled 'debug mpls packet' and i see the labels as they should be.

any ideas would be appreciated.

i've seen multiple examples on the net showing the mpls label field in wireshark.

these examples though, all used network emulators which had tie-in's to wireshark.

they didn't need any  traffic export nor capture feature in the router.

it is upon me to demo this in hardware, not with simulators.

tnx in advance,

ams

avraham@jct.ac.il

972-2-671-1163

[Akash Agrawal]

Hi,

Try to send ping with command "ping mpls ipv4 <dest-ip/mask>". It would definitely send ping with mpls label and then do wireshark capture and if still you dont see label, please share pcap file

-Akash

[ashirel]

i see the mpls-ec packets loud and clear, but no mpls label.

in the examples i've seen on the net, it was clear right in between layer 2&3, just as expected.

the question is- if RITE is not mpls aware, they why would we expect to see the label

being exported?

perhaps some form of the router's 'monitor capture' would be useful here?

cisco wouldn't allow me to attach/upload the pcap file from wireshark, but

wireshark can save it as a txt, so that's what i uploaded.

tnx

ams

[bhnegi]

There was no testing done with mpls on RITE and it is unsupported. Both monitored interfaces must be pure IP in order for this feature to work.

With unsupported feature you may see unexpected results.

Please see link below.

https://supportforums.cisco.com/discussion/11671136/mpls-l2vpn-packet-capture

Best Regards,

Bheem

[bhnegi]

This is expected. Right is not mpls aware.

Best Regards,

Bheem

[bhnegi · Accepted solution]

correction.. RITE is is not mpls aware. it only supports IP.

Best Regards,

Bheem

[ashirel]

thanks lot's bheem,

i shutdown the serial lines connecting the 2  non-edge routers, applied thier ip addresses to ethernet

ports. i then connected those ethernet ports to each other via a hub (yes, a hub not a switch).

on that hub i have a station running wireshark.

now i see the mpls label fields as should be.

question-

is it documented anyplace in the RITE docs that it doesn't recognize packets with mpls labels as ip packets?

when u say 'it only supports ip', well, i'm looking only at ip packets. telnet, icmp,...

this as as 'ip' as u can get.  ok, it expects to see the ip packet header right inside the ethernet frame.

it finds something which is not ip, namely mpls, but after the tag, is the ip header.

i'd call this a bug. these are ip packets no matter how u cut it.  someone decided that it's not

important for RITE to support ip packets with an mpls tag though.

anyway,

thanks again for the info,

ams

[bhnegi]

You are welcome Ams!

We have an enhancement request open for this but I don't see any road map.

CSCtt16200    

RITE support for MPLS Tagged traffic
Internally found enhancement (Sev6) bug: N-New

If you need this feature you can work with your Cisco accounts team.

Best Regards,

Bheem

[ashirel]

the link, https://cdetsng.cisco.com/webui/#view=CSCtt16200 gives me

"Server not found"

for internal cisco use only?

just curious when the request is from.

i understand that the relevance of this problem is diminished these days that serial lines are

used less, in favor of fiber optics directly to the telcom supplier connected to a local 100/1000ethernet port.

tnx,

ams

btw, just curious where u'r located.

[bhnegi]

Hi Ams,

Yes the enhancement request was made internally and is not externally visible.

Best Regards,

Bheem