Hi Steve,

Thanks for that, yes it does appear to be all untagged (and non-IP) frames 
which get assigned ‘unwanted’ EXP values. This seems to occur despite the 
trust/untrust/mutate state of the xconnect interface.

There is no control over the downstream traffic, the xconnect is to encapsulate 
and carry EoMPLS to a remote location but the EXP should be statically set for 
all frames in order to comply with the core QoS policies.

Any further ideas beyond that? A similar setup on our own 9k platform works as 
expected, so this appears to be a specific 6500 feature.

All the best,

Robert Williams
Custodian Data Centres
From: Steve Dodd [mailto:sd...@salesforce.com]
Sent: 09 February 2018 16:02
To: Robert Williams <rob...@custodiandc.com>
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] MPLS EXP on STP Frames (6500)

IIRC the EXP values for non-IP traffic are mapped directly from the .1p COS 
values. Depending on your flavor of STP this field may not even exist, in which 
case I suspect it is being treated as COS0. Is it possible to have the 
downstream device push a .1q tag?


On Fri, Feb 9, 2018 at 8:41 AM, Robert Williams 
<rob...@custodiandc.com<mailto:rob...@custodiandc.com>> wrote:
Hi all,

Is anyone aware of a feature which allows the EXP value on an STP frame to be 
set when it is encapsulated by a xconnect on a 6500?

Example config:

int gi1/1
  description Customer Port
  xconnect 666 encapsulation mpls
  service-policy input set-exp-3

policy-map set-exp-3
 class class-default
   set mpls experimental imposition 3

I would expect all traffic which ingresses on that customer port to be set to 
EXP 3 when it is encapsulated. This is, unfortunately, not the case....

When the traffic egresses the 6500, it is 'mostly' set to EXP 3 - except - a 
few special things, like the STP frames, LLDP and some other control-type 
stuff. Basically, only the IP stuff gets set to EXP 3.

Control things get various values, STP for example goes to EXP 0 - and nothing 
changes this as far as I can find. I have also noticed some other types of 
traffic are set to other values (like EXP 5,6,7) so clearly there are more 
exceptions than just STP, but I figure that they are probably controlled by the 
same knob/feature, somewhere...

Platform is Cat6500 with S720-10G, X6748 cards and IOS 15.1(2)SY6

It's a specific customer requirement so changing platform isn't an option in 
this case. I've also tried re-writing it (to EXP 3) on egress out of the box 
towards the MPLS core, but this isn't supported on this platform. I also tried 
setting it on the tunnel, but again that is only supported in ingress, not 

So - any ideas anyone?


Robert Williams
Custodian Data Centres

cisco-nsp mailing list  
archive at http://puck.nether.net/pipermail/cisco-nsp/

cisco-nsp mailing list  cisco-nsp@puck.nether.net
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to