Solved: L3/L2 interface QoS question

kclark · ‎01-27-2010

I've read about version of this scenario, but have been unable to achieve the desired results from previous examples.

I have a 2811 with an on-board interface on my LAN (L3), and an HWIC-4ESW interface (L2) connecting to a metro Ethernet WAN. Out across the WAN I have a similar scenario: a 3825 with an HWIC-4ESW connecting to the metro Ethernet and an on-board interface connecting to the local LAN. I'm running some audio streams between the sites, and am trying to give these the highest possible service. The endpoints at each location are outputting traffic with DSCP values. I simply want to honor those end-to-end. So far it's only working in one direction.

Using WireShark I can see traffic from site A reach site B with DSCP values intact. Great, just what I wanted. However, traffic from site B to site A appears to leave site B with packets marked appropriately, but the endpoint at site A only sees default DSCP (0x00). I've attached the pertinent pieces of the config from each site. I do not have extensive experience with QoS, but am trying to understand/apply what I can. Thanks for any input/direction.

site A config:

class-map match-any audio-level1
match ip dscp af31
class-map match-any audio-level2
match ip dscp ef
class-map match-any audio_traffic
match access-group name audio_server
!
policy-map mymap
class audio-level2
    priority percent 30
class audio-level1
    priority percent 20
class audio_traffic
set ip dscp ef
    priority percent 30
class class-default
    fair-queue
!

interface GigabitEthernet0/0
description Site A LAN
ip address 172.30.2.231 255.255.255.0
ip flow ingress
ip hello-interval eigrp 1 1
ip hold-time eigrp 1 3
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
service-policy output mymap
!

interface FastEthernet0/0/0
description Metro WAN 55Mb
switchport access vlan 100
switchport trunk native vlan 100
switchport trunk allowed vlan 1-499,501-4094
switchport mode trunk
duplex full
speed 100
!

interface Vlan100
description Metro WAN
bandwidth 55000
ip address 172.30.30.1 255.255.255.0
ip flow ingress
ip flow egress
mls qos trust dscp
!

ip access-list extended audio_server
permit ip any host 172.30.2.46
permit ip any host 172.30.2.49
deny ip any any

site B config:

class-map match-any audio-level1
match ip dscp af31
class-map match-any audio-level2
match ip dscp ef
class-map match-any audio_traffic

match access-group name audio_outbound
!
!
policy-map mymap
class audio-level2
    priority percent 30
class audio-level1
    priority percent 20
class class-default
    fair-queue
policy-map setDSCP
class audio_outbound
set ip dscp ef
!

interface FastEthernet0/1
description Site B LAN
ip address 192.168.250.10 255.255.255.248 secondary
ip address 192.168.42.254 255.255.255.0
ip flow ingress
ip flow egress
ip virtual-reassembly
duplex auto
speed auto
service-policy output mymap

!

interface FastEthernet0/0/0
description Metro Ethernet WAN
switchport access vlan 100
switchport trunk native vlan 100
switchport trunk allowed vlan 1,100,1002-4094
switchport mode trunk
duplex full
speed 10
!

interface Vlan100
description Metro Ethernet
bandwidth 3072
ip address 172.30.30.10 255.255.255.0
ip flow ingress
ip flow egress
mls qos trust dscp
service-policy output setDSCP
!

ip access-list extended audio_outbound

permit ip any host 172.30.2.46
permit ip any host 172.30.2.49
deny ip any any

sachinraja · ‎01-28-2010

Hi Kevin

By the look of the service policy directions, your ACLs looks actually good.. but to keep it simple, it is good to appply service policy on inbound direction on the LAN interfaces and just do marking... policing needs to be done on outbound interfaces, and dont mix policing and marking together on the same policy... if you are not applying any service-policy commands, you can just do a dscp trust on that interface.... ACLs will then need to be modifiedbased on the IN direction of the service policy.. example:

Site A:

interface GigabitEthernet0/0

description site-A-LAN
mls qos trust dscp

int vlan 100

Metro link

service-policy output mymap

ip access-list extended audio_server
permit ip host 172.30.2.46 any
permit ip host 172.30.2.49 any
deny ip any any

Site B:

interface fas0/1

Site B LAN

mls qos trust dscp

int vlan 100

Metro link

service-policy output mymap

(have similar policy maps as Site A, and dont have two seperate policy maps)

p access-list extended audio_outbound

permit ip any host 172.30.2.46
permit ip any host 172.30.2.49
deny ip any any

are there any devices which initiate traffic already on EF, CS3 etc (like ip phones etc), or do we need to do marking for all traffic ? as of now we are just marking the traffic outbound and inbound to the servers 172.30.2.46 and 49... if we have both marking and policing on the same policymap, packets might just be marked, and not policed...

Hope this helps.. all the best

Raj

View solution in original post

sachinraja · ‎01-27-2010

Hi Clark

Just ran through the configuration, and saw that the following ACL:

ip access-list extended audio_outbound

permit ip any host 172.30.2.46
permit ip any host 172.30.2.49
deny ip any any

is same both the ends... you probably have to swap the source and destination based on the router in which it is applied... where are the audio servers 172.30.2.46 & 172.30.2.49 located ??

why have you applied "service-policy output setDSCP" on VLAN 100 of site B, and not on site A ? you are already trusting the dscp values on the metro links which is sufficient.. By the way these routers do policing.. where are you marking the packets ? have you configured qos trust on the switches ? Just make sure you need to look at DSCP end to end , since this is a diffserve network...

Hope this helps. all the best..

Raj

kclark · ‎01-27-2010

Hi Raj,

Thanks for your reply. Traffic is marked from the endpoint at Site A and carried modified to endpoints at Site B. That appears to be working correctly. The servers at 172.30.2.46 and 172.30.2.49 are at Site A, so server-to-endpoint DSCP values are intact. The issue is that traffic leaving endpoints at Site B are marked with DSCP values, but when the traffic arrives at Site A the servers only see default values.

This config likely has issues due to the multiple permutations I've tried to make it work. I'll adjust the access list and see if that helps. Thanks again for taking a look.

-Kevin

sachinraja · ‎01-28-2010

Hi Kevin

By the look of the service policy directions, your ACLs looks actually good.. but to keep it simple, it is good to appply service policy on inbound direction on the LAN interfaces and just do marking... policing needs to be done on outbound interfaces, and dont mix policing and marking together on the same policy... if you are not applying any service-policy commands, you can just do a dscp trust on that interface.... ACLs will then need to be modifiedbased on the IN direction of the service policy.. example:

Site A:

interface GigabitEthernet0/0

description site-A-LAN
mls qos trust dscp

int vlan 100

Metro link

service-policy output mymap

ip access-list extended audio_server
permit ip host 172.30.2.46 any
permit ip host 172.30.2.49 any
deny ip any any

Site B:

interface fas0/1

Site B LAN

mls qos trust dscp

int vlan 100

Metro link

service-policy output mymap

(have similar policy maps as Site A, and dont have two seperate policy maps)

p access-list extended audio_outbound

permit ip any host 172.30.2.46
permit ip any host 172.30.2.49
deny ip any any

are there any devices which initiate traffic already on EF, CS3 etc (like ip phones etc), or do we need to do marking for all traffic ? as of now we are just marking the traffic outbound and inbound to the servers 172.30.2.46 and 49... if we have both marking and policing on the same policymap, packets might just be marked, and not policed...

Hope this helps.. all the best

Raj

kclark · ‎01-28-2010

Found the issue. Our 3750 (acting as layer 2 only) was stripping the DSCP value from the router and egressing it with default values. Once I added "mls qos trust dscp" to the switch interface connecting to the site A router, DSCP values from Site B were retained to the servers at Site A.

Thanks again for your time & feedback!