QoS tagging on 3750G with existing vrf-lite config

Unanswered Question
Sep 6th, 2011

Hi,

Please I need some help with a vrf-lite deployment which is currently working ok at one of my sites. But the problem I am now facing is ho to tag some interesting traffic sourced from vlans within the two seperate vrfs I am using. The first problem I noticed was that none of the access lists were getting any hits and therefore the policy cannot be applied. I have researched and read a lot of previous discussions on srr and QoS on 3750 from the cisco website but none of the approaches I tried seem to work for the QoS tagging. I am running IOS version c3750-advipservicesk9-mz.122-46.SE.bin and a snapshot of the config is shown below. I tried applying the policy on trunk int gig1/0/1 connected to my ISP CE (also tried applying it on the vlans in the two vrfs).

Any helpful suggestions or solutions will be really appreciated.

system mtu routing 1500
vtp domain test

vtp mode transparent
ip subnet-zero
ip routing
no ip domain-lookup

ip domain-name network.test.net

ip vrf red

  description RED-VRF

rd 10000:1

!

ip vrf blue

description BLUE-VRF

rd 20000:1

!

mls qos

!

spanning-tree mode pvst

spanning-tree extend system-id

!

vlan internal allocation policy ascending

vlan 10

!

vlan 20

!

!

ip ssh version 2

!

class-map match-all CM_QoS_PREC_0

match access-group 100

class-map match-all CM_QoS_PREC_2

match access-group 102

class-map match-all CM_QoS_PREC_4

match access-group 104

class-map match-all CM_QoS_PREC_5

match access-group 105

!

policy-map PM_QoS_PREC

class CM_QoS_PREC_0

  set ip precedence 0

class CM_QoS_PREC_2

  set ip precedence 2

class CM_QoS_PREC_4

  set ip precedence 4

class CM_QoS_PREC_5

  set ip precedence 5

!

!

interface GigabitEthernet1/0/1

description Trunk to ISP

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 10,20

switchport mode trunk

speed 100

duplex full

service-policy input PM_QoS_PREC

!

interface GigabitEthernet1/0/3
description To RED VRF SWITCH

switchport access vlan 10
switchport mode access
speed 100
duplex full
service-policy input PM_QoS_PREC
!
interface GigabitEthernet1/0/4
description TO BLUE VRF SWITCH

switchport access vlan 20
switchport mode access
speed 100
duplex full
service-policy input PM_QoS_PREC

!

interface Vlan1
no ip address
no ip mroute-cache
shutdown
!
interface Vlan10
description CORPORATE_VLAN
ip vrf forwarding red

ip address 172.31.60.1 255.255.255.0
!
interface Vlan20
description BLUE-VRF

ip vrf forwarding blue

ip address 10.44.96.1 255.255.255.240
!

ip classless
ip route vrf red 0.0.0.0 0.0.0.0 172.31.60.14
ip route vrf blue 0.0.0.0 0.0.0.0 10.44.96.14
no ip http server
no ip http secure-server
!
!

access-list 100 permit ip 172.31.60.0 0.0.3.255 any
access-list 100 permit ip 10.44.96.0 0.0.31.255 any
access-list 10 remark SNMP Logging
access-list 10 permit 172.31.3.1

Note: Most of the access lists and other non-relevant part of the config has been removed to focus on main issue I am currently facing. The snmp access-list gets hits on it but any other access list for subnets within vrf red or blue do not get any hits even though those subnets are passing traffic. So my service-policy is not doing anything even when applied to the vlan interface.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (0 ratings)
Edison Ortiz Tue, 09/06/2011 - 09:13

You won't get hits on ACEs with QoS since it's done in hardware and ACEs hits are processed in software.

If you want to test if QoS is working, you can issue the command show mls qos interface stat

joshking1 Tue, 09/06/2011 - 09:39

Thanks Edison for you prompt response to my question.

So I should not bothered with the hits on ACEs for the QoS then.

I do see some stats with the show mls qos interface stat  command but some of the packets are showing up in class of service that I have not used for my QoS tagging. From the Config, I am only using ip precedence 0, 2, 4 and 5. But I seem to be getting stats in other classes. An output example from my switch is attached below:

#sh mls qos interface gigabitEthernet 1/0/1 statistics
GigabitEthernet1/0/1 (All statistics are in packets)

  dscp: incoming
-------------------------------

  0 -  4 :      140841            0            0            0            0
  5 -  9 :           0            0            9            0            0
10 - 14 :           0            0            0            0            0
15 - 19 :           0            0            0            0            0
20 - 24 :           0            0            0            0            0
25 - 29 :           0            0            0            0            0
30 - 34 :           0            0            0            0            0
35 - 39 :           0            0            0            0            0
40 - 44 :        3036            0            0            0            0
45 - 49 :           0            0            0         2263            0
50 - 54 :           0            0            0            0            0
55 - 59 :           0            0            0            0            0
60 - 64 :           0            0            0            0
  dscp: outgoing
-------------------------------

  0 -  4 :      120564            0            0            0            0
  5 -  9 :           0            0            0            0            0
10 - 14 :           0            0            0            0            0
15 - 19 :           0            0            0            0            0
20 - 24 :           0            0            0            0            0
25 - 29 :           0            0            0            0            0
30 - 34 :           0            0            0            0            0
35 - 39 :           0            0            0            0            0
40 - 44 :           0            0            0            0            0
45 - 49 :           0            0            0          217            0
50 - 54 :           0            0            0            0            0
55 - 59 :           0            0            0            0            0
60 - 64 :           0            0            0            0
  cos: incoming
-------------------------------

  0 -  4 :      143910            0            0            0            0
  5 -  7 :           0            0         2263
  cos: outgoing
-------------------------------

  0 -  4 :      120754            0            0            0            0
  5 -  7 :           0          217            2
Policer: Inprofile:            0 OutofProfile:            0

Thanks once more for your help.

Edison Ortiz Tue, 09/06/2011 - 10:14

It looks like your cos-to-dscp maps are not correct, did you modify the default maps with this command?

mls qos map cos-dscp 0 8 16 24 32 46 48 56

I see DSCP 40 listed but nothing for COS 5 which indicates incorrect mapping.

BTW, you will see DSCP 48/COS 6 because that is used for network control/routing protocols between switches.

joshking1 Tue, 09/06/2011 - 14:02

Hi Edison,

I did not use the mls qos map cos-dscp command.

The only commands I used were for the srr-queue which I tested on the trunk interfaace gig1/0/1.

The global srr-queue command I used was:

mls qos srr-queue output dscp-map queue 1 threshold 1  16

mls qos srr-queue output dscp-map queue 2 threshold 1  40

mls qos queue-set output 1 buffers 60 40 0 0

interface GigabitEthernet1/0/1

srr-queue bandwidth share 60 38 1 1
srr-queue bandwidth shape  0  0  0  0
srr-queue bandwidth limit 10

Edison Ortiz Tue, 09/06/2011 - 19:24

Please apply the command, it's part of the QoS Best Practice on Catalyst switches.

Marwan ALshawi Wed, 09/07/2011 - 01:29

Hi Edison,

quick question, why would he need to use the cos to dscp map as he is just remarking the dscp/prec on the interface inbound direction without trusting any cos ?

i understand if the interface (input direction ) trust cos then the dscp will be rewritten based on the cos - to - dscp mapping table only !

- Eric

you could use per vlan classification/marking with 3750 switch

An alternative approach for deploying marking policies on the Catalyst 3560/3750 platforms is to deploy these on a per-VLAN basis. In order to do so, the interfaces belonging to the VLANs need to be configured with the mls qos vlan-based interface command

example

remove the service policy from the physical interfaces

add the bellow:

interface GigabitEthernet1/0/1, interface GigabitEthernet1/0/3 - 4

mls qos vlan-based

interface vlan 10

service-policy input PM_QoS_PREC

interface vlan 20

service-policy input PM_QoS_PREC

HTH

if helpful Rate

joshking1 Wed, 09/07/2011 - 02:12

Hi Edison,

Thanks once more for your prompt response which has been very helpful.

The switch cos-dscp mapping has not changed from the default  as shown below (unless I am still missing something):

#sh mls qos maps cos-dscp

   Cos-dscp map:

        cos:   0  1  2  3  4  5  6  7

     --------------------------------

       dscp:   0  8 16 24 32 40 48 56

Also, thanks Marwanshawi for your suggestion.

I will try the vlan based option although I have other vlans with /25 subnets on the 10.44.x.x network (e.g vlan 50 with subnet 10.44.100.0/25) which are all routed via the BLUE VRF. Will the precedence markings from these vlans also be extended to the ISP considering the vlans are not part of the trunked vlans 10 and 20 connected to the ISP?

Thanks.

Marwan ALshawi Wed, 09/07/2011 - 02:33

the per vlan marking works same as when you apply it to the interface face but the deference are:

- it is easier if you have many interfaces in the same vlan or differnt vlans with differnt vrfs

- if you have a trunk that passes differnt vlans by using this way you can mark based on input interface and vlan as the marking is being done on the vlaninterface for each corsponding vlan

HTH

joshking1 Wed, 09/07/2011 - 04:06

Hi Marwanshawi,

I have just applied the mls qos vlan-based policy on vlan 10 and I lost connectivity to one of my servers within the 172.31.60.x subnet and the access-list for the QoS policy already permits that subnet which are tagged with precedence 0 with the access list 100 shown below:

Extended IP access list 100

    10 permit ip any any

    20 permit ip 172.31.60.0 0.0.3.255 any

    30 permit ip 10.44.96.0 0.0.31.255 any

I removed the policy from the vlan 10 and it restored back the remote access to my server. Any idea why it could be happening since it is exactly same policy that was applied on the physical ports that has now been moved up to the vlans and this does not happen when applied to the physical ports.

Thanks

Marwan ALshawi Wed, 09/07/2011 - 04:30

this is really strange as it is QoS only and not policing or any dropping actions in the policy

have you applied the bellow commands on the physical interfaces:

mls qos vlan-based

joshking1 Wed, 09/07/2011 - 05:24

It is very strange indeed.

I have applied the mls qos vlan-based command on all physical ports and the applied the policy on vlan 10 for test.

Not sure why it happened but immediately I removed the policy from vlan 10, access to the server was restored.

Edison Ortiz Wed, 09/07/2011 - 08:53

Marwan,

I recommend modifying the maps to follow QoS standards. If there is a router upstream expecting a packet with voice, more than likely the router will match on DSCP46. As you see from the switch, the value is being tagged as DSCP40 and that is due to the incorrect mappings.

joshking1 Wed, 09/07/2011 - 09:00

Hi Edison,

I am wondering if this is the case for Cisco routers only or will it also apply if my upstream router is a Juniper cpe which is the case here?

So I should still apply the command

mls qos map cos-dscp 0 8 16 24 32 46 48 56

Edison Ortiz Wed, 09/07/2011 - 09:34

Yes, you must apply this command and once you do, please post the output from show mls qos maps

It doesn't matter the type of router but the QoS configuration on it. The standards dictate that voice traffic should be tagged as DSCP46/COS5/IP-Prec5

joshking1 Wed, 09/07/2011 - 09:52

Ok, I will apply the command and send the result of the show mls qos maps

joshking1 Thu, 09/08/2011 - 07:18

Here is the output of show mls qos maps after applying the map command

Cos-dscp map:

        cos:   0  1  2  3  4  5  6  7

     --------------------------------

       dscp:   0  8 16 24 32 46 48 56

   IpPrecedence-dscp map:

     ipprec:   0  1  2  3  4  5  6  7

     --------------------------------

       dscp:   0  8 16 24 32 40 48 56

Edison Ortiz Thu, 09/08/2011 - 07:22

Since you are using ip-precedence for marking, you should modify that map as well.

joshking1 Thu, 09/08/2011 - 07:29

Both Ip-Prec and Cos maps are now thesame.

Cos-dscp map:
        cos:   0  1  2  3  4  5  6  7
     --------------------------------
       dscp:   0  8 16 24 32 46 48 56

  

IpPrecedence-dscp map:
     ipprec:   0  1  2  3  4  5  6  7
     --------------------------------
       dscp:   0  8 16 24 32 46 48 56

Edison Ortiz Thu, 09/08/2011 - 08:24

You are set, if you are tagging IP Prec 5, you should see DSCP 46 counters incrementing.

joshking1 Tue, 09/27/2011 - 05:08

Hi,

Sorry for the long silence which was not intended....got lots of other stuff I was doing.

I have retested the policy both with the port based policy and the vlan-based option but it still does not seem to be working ok.

I still don't see packets being queued properly with the assigned precedence and also the ACL used for the classification seem to be blocking or stopping some traffic even though I have a permit ip any any statement for cos 0 packets.

I am still not sure of what or where the problem could be.

Thanks

Actions

Login or Register to take actions

This Discussion

Posted September 6, 2011 at 6:31 AM
Stats:
Replies:21 Avg. Rating:
Views:1374 Votes:0
Shares:0
Tags: No tags.
Categories: Switches
+

Discussions Leaderboard

Rank Username Points
1 14,997
2 8,150
3 7,720
4 7,078
5 6,723
Rank Username Points
175
80
60
59
55