Thanks Sibbi. This worked and we are seeing their voice traffic now passed correctly. Not too concerned with the amount of traffic they can send as they are paying for a full 100Mbps.
Thanks for your help. -Lee On Sat, May 5, 2012 at 10:23 PM, Sigurbjörn Birkir Lárusson < [email protected]> wrote: > 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" <[email protected]> wrote: > > >Try to trust dscp/cos value of incoming packets of the access port. > > > > > >________________________________ > > From: ML <[email protected]> > >To: [email protected] > >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 [email protected] > >> 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 [email protected] > >https://puck.nether.net/mailman/listinfo/cisco-nsp > >archive at http://puck.nether.net/pipermail/cisco-nsp/ > >_______________________________________________ > >cisco-nsp mailing list [email protected] > >https://puck.nether.net/mailman/listinfo/cisco-nsp > >archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
