09-06-2011 06:31 AM - edited 03-07-2019 02:04 AM
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.
09-06-2011 09:13 AM
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
09-06-2011 09:39 AM
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.
09-06-2011 10:14 AM
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.
09-06-2011 02:02 PM
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
09-06-2011 07:24 PM
Please apply the command, it's part of the QoS Best Practice on Catalyst switches.
09-07-2011 01:29 AM
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
09-07-2011 02:12 AM
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.
09-07-2011 02:33 AM
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
09-07-2011 04:06 AM
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
09-07-2011 04:30 AM
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
09-07-2011 05:24 AM
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.
09-07-2011 08:53 AM
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.
09-07-2011 09:00 AM
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
09-07-2011 09:34 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide