[j-nsp] Explicit Null - IP/MPLS QoS

[Aaron]

HI all, 

 

I've always heard that QoS is a reason why you would need to enable explicit
null on PE's..but I've never had to do it since I've never done QoS
testing/deployment. but I'm working on QoS in my network now so I'm digging
into this in my lab..

 

I had something in the lab where I was I was marking IP header with DSCP 46
(TOS 184) but sniffer on the span shown below was showing that the dscp was
seen as 0 (aka CS0) .also seeing no underlying mpls tag.  I wasn't surprised
about not having an underlying mpls tag since implicit null/php behavior
seems to dictate that.  But what sort of struck me as odd, was that even the
IP layer DSCP marking was seemingly being re-wrote to 0

 

I enabled explicit null on the ME3600, and then suddenly I now see DSCP EF
(46) on the sniffer from those pings from 9k to me3600.  It just seemed
strange to me that this would affect the IP layer marking as it was marked
back on the 9k in the ping utility.

 

So I guess this means that if there is a default PHP / implicit null
behavior causing the ACX5048 to pop the last label, then the ACX5048 will
also clear the IP DSCP/TOS byte to 0 also. Is this your understanding of how
this works also ?

 

- Aaron

 

9k was pinging loopback of ME3600.. Nothing in vrf or l2vpn. just purely via
the default/core vrf and mpls labeled ipv4

 

Lab test...

Cisco asr9k ------------------ juniper acx5048 ---------(sniffer)---------
cisco me3600(loopback 0 is 10.101.12.251)

ping 10.101.12.251 type 184

==================pinging=============================>>>>

 

I also moved sniffer here to make sure dscp 46 EF was seen and it was..

 

Lab test...

Cisco asr9k --------(sniffer)---------- juniper acx5048 ------------------
cisco me3600(loopback 0 is 10.101.12.251)

ping 10.101.12.251 type 184

==================pinging=============================>>>>