Changing Policy Map on 4500 switch

[mramj499]

I'm trying to update the policy-map settings for our 4500 switch.  Below is the current config.

class-map match-any VSL-MGMT-PACKETS
match access-group name VSL-MGMT
class-map match-any VSL-DATA-PACKETS
match any
class-map match-any VSL-L2-CONTROL-PACKETS
match access-group name VSL-DOT1x
match access-group name VSL-BPDU
match access-group name VSL-CDP
match access-group name VSL-LLDP
match access-group name VSL-SSTP
match access-group name VSL-GARP
class-map match-any VSL-L3-CONTROL-PACKETS
match access-group name VSL-IPV4-ROUTING
match access-group name VSL-BFD
match access-group name VSL-DHCP-CLIENT-TO-SERVER
match access-group name VSL-DHCP-SERVER-TO-CLIENT
match access-group name VSL-DHCP-SERVER-TO-SERVER
match access-group name VSL-IPV6-ROUTING
class-map match-any VSL-MULTIMEDIA-TRAFFIC
match dscp af41
match dscp af42
match dscp af43
match dscp af31
match dscp af32
match dscp af33
match dscp af21
match dscp af22
match dscp af23
class-map match-any VSL-VOICE-VIDEO-TRAFFIC
match dscp ef
match dscp cs4
match dscp cs5
class-map match-any VSL-SIGNALING-NETWORK-MGMT
match dscp cs2
match dscp cs3
match dscp cs6
match dscp cs7
!
policy-map VSL-Queuing-Policy
class VSL-MGMT-PACKETS
bandwidth percent 5
class VSL-L2-CONTROL-PACKETS
bandwidth percent 5
class VSL-L3-CONTROL-PACKETS
bandwidth percent 5
class VSL-VOICE-VIDEO-TRAFFIC
bandwidth percent 30
class VSL-SIGNALING-NETWORK-MGMT
bandwidth percent 10
class VSL-MULTIMEDIA-TRAFFIC
bandwidth percent 20
class VSL-DATA-PACKETS
bandwidth percent 20
class class-default
bandwidth percent 5

And the interfaces they are applied to:

interface TenGigabitEthernet1/1/15
switchport mode trunk
switchport nonegotiate
no lldp transmit
no lldp receive
channel-group 16 mode on
service-policy output VSL-Queuing-Policy
!
interface TenGigabitEthernet1/1/16
switchport mode trunk
switchport nonegotiate
no lldp transmit
no lldp receive
channel-group 16 mode on
service-policy output VSL-Queuing-Policy

!
interface TenGigabitEthernet2/1/15
switchport mode trunk
switchport nonegotiate
no lldp transmit
no lldp receive
channel-group 15 mode on
service-policy output VSL-Queuing-Policy
!
interface TenGigabitEthernet2/1/16
switchport mode trunk
switchport nonegotiate
no lldp transmit
no lldp receive
channel-group 15 mode on
service-policy output VSL-Queuing-Policy

So this is what I was doing on the CLI:

4500INT-01#conf t
Enter configuration commands, one per line. End with CNTL/Z.
4500INT-01(config)#policy-map VSL-Queuing-Policy
4500INT-01(config-pmap)#class VSL-VOICE-VIDEO-TRAFFIC
4500INT-01(config-pmap-c)#no bandwidth percent 30
4500INT-01(config-pmap-c)#bandwidth percent 5
4500INT-01(config-pmap-c)#class VSL-DATA-PACKETS
4500INT-01(config-pmap-c)#no bandwidth percent 20
4500INT-01(config-pmap-c)#bandwidth percent 45
4500INT-01(config-pmap-c)#end

But then anytime I then run "show run", it doesn't reflect the changes I made.  How do I get these changes to actually apply?

[Giuseppe Larosa]

Hello @mramj499 ,

you should try in a maintenance window the following:

remove all the applications of the policy-map to physical interfaces

int type x/y

no service-policy ouput <policy-name>

make your changes

then re-apply it to all the member interfaces.

As an alternative create a new policy-map with a different name and then change the name of the policy-map in the physical interfaces

using

int type x/y

no service-policy ouput <policy-name>

service-policy output <new-policy-name>

I use the second way most of the times for changes to  QoS policy maps

Hope to help

Giuseppe

[mramj499]

Giuseppe, so I have the new service-policy ready.  If I make this change, will any traffic be lost between the two switches?  This is core switch for our network, so naturally concerned.  I will do this in a maintenance window, but want to warn other engineers of adverse side effects, if any.  Below is the new VSL-Queuing-Policy-1 with the new bandwidth percent allocations.

policy-map VSL-Queuing-Policy-1
class VSL-MGMT-PACKETS
bandwidth percent 5
class VSL-L2-CONTROL-PACKETS
bandwidth percent 5
class VSL-L3-CONTROL-PACKETS
bandwidth percent 5
class VSL-VOICE-VIDEO-TRAFFIC
bandwidth percent 5
class VSL-SIGNALING-NETWORK-MGMT
bandwidth percent 10
class VSL-MULTIMEDIA-TRAFFIC
bandwidth percent 5
class VSL-DATA-PACKETS
bandwidth percent 60
class class-default
bandwidth percent 5
policy-map VSL-Queuing-Policy
class VSL-MGMT-PACKETS
bandwidth percent 5
class VSL-L2-CONTROL-PACKETS
bandwidth percent 5
class VSL-L3-CONTROL-PACKETS
bandwidth percent 5
class VSL-VOICE-VIDEO-TRAFFIC
bandwidth percent 30
class VSL-SIGNALING-NETWORK-MGMT
bandwidth percent 10
class VSL-MULTIMEDIA-TRAFFIC
bandwidth percent 20
class VSL-DATA-PACKETS
bandwidth percent 20
class class-default
bandwidth percent 5

And my command to run to apply the changes:

int te1/1/15
no service-policy output VSL-Queuing-Policy
service-policy output VSL-Queuing-Policy-1
int te2/1/15
no service-policy output VSL-Queuing-Policy
service-policy output VSL-Queuing-Policy-1
int te1/1/16
no service-policy output VSL-Queuing-Policy
service-policy output VSL-Queuing-Policy-1
int te2/1/16
no service-policy output VSL-Queuing-Policy
service-policy output VSL-Queuing-Policy-1

[mramj499]

Found this is the logs:

Service-policy attached to VSL member ports cannot be modified or removed.

How can I make this highly necessary change?

[Georg Pauwen]

You probably have to remove the port channel interface from the VSS first, e.g.:

interface port-channel 1

--> no switch virtual link 1 

[Giuseppe Larosa]

Hello @mramj499 ,

you really need a maintenance window.

If you need to remove the port-channel(s) from VSL as noted by Georg,  you need to have a way to detect Dual Active Detection.

have you deployed a DAD link using one of the possible methods fast hellos, BFD ?

Otherwise without a DAD link the two chassis will become both Active at the same time with very great impact on the network.

Side note:

removing a service policy does not cause traffic drops by itself but in this special case if you need to break the VSL link to be able to change the service policy you need a maintenance time window and you need also to be ready for console access in the worst case to reach the standby chassis.

Edit:

another possible option to be investigated is to check if it is possible to add a second VSL link to the existing one just to avoid to break the VSS pair. But I am afraid this may be not supported.

Hope to help

Giuseppe

[mramj499]

We have multiple VSLs on this pair.

te1/1/15 <-> te2/1/15

te1/1/16 <-> te2/1/16

So I'm thinking try your method first of no service-policy and then service-policy with the new VSL-Queuing-Policy-1.  I would try this first on te1/1/15 and te2/1/15.  If that doesn't work, then I would take down the VSL on 15 <-> 15 and try no service-policy followed by service-policy again.

Since the 16 <-> 16 VSL would still be up, I should be able to take down 15 <-> 15 and still have the VSS working.

Thoughts?

Current configuration : 230 bytes
!
interface TenGigabitEthernet1/1/15
description Uplink to 4500INT-02
switchport mode trunk
switchport nonegotiate
no lldp transmit
no lldp receive
channel-group 16 mode on
service-policy output VSL-Queuing-Policy
end

4500INT-01#sh run int po16
Building configuration...

Current configuration : 152 bytes
!
interface Port-channel16
description Uplink to 4500INT-02
switchport
switchport mode trunk
switchport nonegotiate
switch virtual link 1
end

4500INT-01#sh run int te2/1/15
Building configuration...

Current configuration : 192 bytes
!
interface TenGigabitEthernet2/1/15
switchport mode trunk
switchport nonegotiate
no lldp transmit
no lldp receive
channel-group 15 mode on
service-policy output VSL-Queuing-Policy
end

4500INT-01#sh run int po15
Building configuration...

Current configuration : 153 bytes
!
interface Port-channel15
description Uplink to 4500-INT-02
switchport
switchport mode trunk
switchport nonegotiate
switch virtual link 2
end

[Giuseppe Larosa]

Hello @mramj499 ,

be careful you have the ports of port-channel 15 terminated on the ports of port-channel 16

This is the way that a VSS is configured a different channel-group is used on the two chassis.

in the moment that you remove the commmand switch virtual link2 under po15 you break the whole VSL

and you have dual Active

check if you have a DAD link between the two chassis.

Hope to help

Giuseppe

[mramj499]

Right, the VSLs are actually:

15 Po15(SU) - Te2/1/15(P) Te2/1/16(P)
16 Po16(SU) - Te1/1/15(P) Te1/1/16(P)

ACR-4500INT-01#sh run int po15
Building configuration...

Current configuration : 153 bytes
!
interface Port-channel15
description 4500-INT-02
switchport
switchport mode trunk
switchport nonegotiate
switch virtual link 2
end

!
interface Port-channel16
description 4500INT-02
switchport
switchport mode trunk
switchport nonegotiate
switch virtual link 1
end

As far as DAD, I see it on te1/1/14 and te2/1/14:

interface TenGigabitEthernet1/1/14
description --VSL--Dual Active Detection link (Fast-Hello)
dual-active fast-hello

interface TenGigabitEthernet2/1/14
description --VSL--Dual Active Detection link (Fast-Hello)
dual-active fast-hello

[Giuseppe Larosa]

Hello @mramj499 ,

you have the DAD link between the two chassis so this should avoid to have the dual active in the network.

However, the standby chassis will isolate itself from the network using the DAD link to know the master is alive.

The real issue I see is that by breaking the VSL you break also the control plane communication between the two supervisors on the two chassis as far as I know.

So the real problem becomes how to make the changes on the standby chassis and how to reconfigure the VSL link on its side po15.

I'm not even sure that connecting to the console of the supervisor on the standby chassis will allow you to make configuration changes.

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/XE3-9-0E/15-25E/configuration/guide/xe-390-configuration/vss.html#86656

>> "When a physical port is configured as a member of a VSL port-channel, a queuing policy is automatically attached to the VSL member ports. This queuing policy provides a dedicated queue for VSS Management, VSLP, BFD, Layer 2 and Layer 3 control protocols, and voice and video data traffic. Each queue is provided with a minimum bandwidth, ensuring that VSS management and control protocol packets are not dropped when congestion occurs on the VSL. The bandwidth assigned to a class of traffic is the minimum bandwidth that is guaranteed to the class during congestion. The VSL link uses Transmit Queue Sharing, where the output link bandwidth is shared among multiple queues of a given VSL port. Any modification or removal of VSL Queuing policy is restricted in a VSS system."

So I would suggest you to open a Cisco TAC ticket to ask if it is possibile to change the VSL QoS policy or you need to rebuild the VSS system (that is the worst possibile case).

Most of VSS systems I have seen on customer networks do not use an explicit QoS configuration on VSS member links and I have never tried to change it.

another option is to evaluate again if you really need this change or not.

Hope to help

Giuseppe