[c-nsp] ME3400 DSCP EF bits stripped.

Sun May 6 01:23:11 EDT 2012

The customer facing UNI ports on the ME3400 don't "trust", to "trust" on
the ME3400 you need to create a policy-map, something like

Policy-map trust-dscp
 Class class-default
   Set dscp dscp

Will do just that, setting your dscp as whatever the customer set, that's
pretty dangerous though, unless the customer is paying for 100% priority
bandwidth.

This would match EF marked packets, allow 10Mbits of EF traffic (marking
10Mbits of EF marked customer traffic as EF) and setting the rest of the
customers EF traffic to 0.  Any non EF traffic will be set to 0 as well,
you don't really need to explicitly do that, but it makes the map easier
to read and understand.

Class-map match-any EF
 Match ip dscp ef

Policy-map trust-ef
  Class EF
   Police 10 m conform-action set-dscp-transmit dscp exceed-action
set-dscp-transmit 0
  Class class-default
    Set dscp 0

You'd want to put this policy-map on the ingress of the customer facing
port, with service-policy input trust-ef

You'll find that the QoS on the ME3400 is somewhat limited but mostly
sufficient for an access device.

Kind regards,
Sibbi

On 6.5.2012 04:06, "ar" <ar_djp at yahoo.com> wrote:

>Try to trust dscp/cos value of incoming packets of the access port.
>
>
>________________________________
> From: ML <ml at kenweb.org>
>To: cisco-nsp at puck.nether.net
>Sent: Sunday, May 6, 2012 11:45 AM
>Subject: Re: [c-nsp] ME3400 DSCP EF bits stripped.
> 
>On 5/4/2012 7:07 PM, Lee Starnes wrote:
>> Hello all,
>>
>> I have been banging my head against the wall for some time now trying to
>> figure out why the DSCP bits are being stripped and replaced with "0" on
>> all packets when coming from a customer connected to one of our ME3400
>> switches. The switch is not doing any routing for them. It is just
>>acting
>> as a L2 transport between their gear and our network.
>>
>> Customer is connected to to port FA0/24 with that port being an access
>> switchport. The VLAN associated with it is not an interface on the
>>switch.
>> The VLAN is simply just trunked via Gig0/1 to a 6509. The customer is
>> setting dscp bit EF on their voice traffic and when that traffic enters
>>the
>> ME3400, those bits change to 0. Is there something that needs to be set
>>to
>> prevent this data from being stripped? We have monitored the traffic
>>with
>> an RSPAN port and are not able to see anything other then dscp 0 on all
>> traffic for this interface. While I have not looked at other
>>interfaces, I
>> suspect this is the same for all of them. Below is the config for this.
>>
>>
>>
>> vlan 800
>>   remote-span
>> !
>> vlan 936
>> !
>> interface FastEthernet0/24
>>   description  ETHERNET - Circuit ID: xxxxxxxxxxxxxx
>>   switchport access vlan 936
>> !
>> interface GigabitEthernet0/1
>>   description uplink to 6509
>>   port-type nni
>>   switchport trunk allowed vlan 32,500-520,800,936
>>   switchport mode trunk
>>   load-interval 30
>>   speed nonegotiate
>>   !
>> monitor session 3 source interface Fa0/24
>> monitor session 3 destination remote vlan 800
>>
>>
>> Any ideas would be greatly appreciated.
>>
>> Thanks,
>>
>> -Lee
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>Is it possible that the 6509 is remarking traffic? Considering you are
>using RSPAN are you capturing traffic upstream?
>
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/