lee.t.starnes at gmail
May 7, 2012, 4:50 PM
Post #5 of 6
(732 views)
Permalink
|
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 <
sigurbjornl [at] vodafone> 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" <ar_djp [at] yahoo> wrote:
>
> >Try to trust dscp/cos value of incoming packets of the access port.
> >
> >
> >________________________________
> > From: ML <ml [at] kenweb>
> >To: cisco-nsp [at] puck
> >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
> >> 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
> >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
> >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
> 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
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
|
