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

[adamv0025 at netconsultings.com]

Hi Aaron,

> Aaron
> Sent: Wednesday, November 16, 2016 11:23 PM
> 
> 
> 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=============================>>>>
> 
> 

This article nicely explains all the DiffServ tunnelling modes in MPLS. 
http://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls
/mpls/47815-diffserv-tunnel.html 

I think it all boils down to what the default behaviour on ARS9k and ACX5k
is. 
-If you have the sniffer between ASR and ACX can you see the EF markings
being copied into the EXP field? 
-If yes, then the default is the same as for vanilla IOS. 
-If not and the EXP value is 0 on packets produced by ASR and the default on
ACX is to copy EXP to IP during label disposition (uniform mode), then that
would explain what you see.  
But to be honest I would not expect such defaults. 
 
I actually never tested default imposition behaviour on XR cause I never
used it (in production you always want to set EXP manually on label
imposition) -and I simply assumed the XR default is the same as described in
the article concerning regular IOS defaults. 

Oh and regarding the explicit null, 
It's needed to preserve EXP markings so that the packet can be classified
correctly (using common MPLS QOS)by a receiving PE only in applications
where there's just a single label in the stack (e.g. 6PE or 4PE). 
Because you can set the EXP value on all imposed labels in ingress PE
including the VPN/VC label, which is the label will be exposed after PHP you
don't actually need explicit null label when you are using L2 or L3 VPNs. 

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::