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=============================>>>> _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp