INE Blog | 3560

Apr

How well do you know VTP?

60 Comments

Posted by INE Instructor in 3550, 3560, ccie, CCIE 4.0, CCIE General, CCIE R&S, CCIE R&S Written, CCIE Security, CCNA General, CCNP, Cisco Certification General, exam, Switches, Switching

Here ye, here ye, VTP experts. (We are not referring to the Vandenberg Test Program, although they are very likely experts in their field as well. :))

Can you predict the results of a 3 switch VTP client/server scenario?

SW1-3, are connected, as shown in the diagram.

VTP question for Blog

Here is the initial output of show VTP status, and show VLAN brief on each. Note that SW1 and SW3 are servers, while SW2 is a client. We will be adding a failure to the network in just a moment.

SW1#show vtp status
VTP Version : 2
Configuration Revision : 3
Maximum VLANs supported locally : 1005
Number of existing VLANs : 8
VTP Operating Mode : Server
VTP Domain Name : INE
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x2C 0x04 0x21 0x2B 0x10 0xFE 0x03 0x50
Configuration last modified by 0.0.0.0 at 3-1-93 00:05:40
Local updater ID is 0.0.0.0 (no valid interface found)
SW1#show vlan brief

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/11, Fa0/12
Fa0/13, Fa0/14, Fa0/15, Fa0/16
Fa0/17, Fa0/18, Fa0/19, Fa0/20
Fa0/21, Fa0/22, Fa0/23, Gig0/1
Gig0/2
2 VLAN0002 active
3 VLAN0003 active
4 VLAN0004 active
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
SW1#

SW2#show vtp status
VTP Version : 2
Configuration Revision : 3
Maximum VLANs supported locally : 1005
Number of existing VLANs : 8
VTP Operating Mode : Client
VTP Domain Name : INE
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x2C 0x04 0x21 0x2B 0x10 0xFE 0x03 0x50
Configuration last modified by 0.0.0.0 at 3-1-93 00:05:40
SW2#show vlan brief

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/2, Fa0/3, Fa0/4, Fa0/5
Fa0/6, Fa0/7, Fa0/8, Fa0/9
Fa0/10, Fa0/11, Fa0/12, Fa0/13
Fa0/14, Fa0/15, Fa0/16, Fa0/17
Fa0/18, Fa0/19, Fa0/20, Fa0/21
Fa0/22, Fa0/23, Gig0/1, Gig0/2
2 VLAN0002 active
3 VLAN0003 active
4 VLAN0004 active
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
SW2#

SW3#show vtp status
VTP Version : 2
Configuration Revision : 3
Maximum VLANs supported locally : 1005
Number of existing VLANs : 8
VTP Operating Mode : Server
VTP Domain Name : INE
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x2C 0x04 0x21 0x2B 0x10 0xFE 0x03 0x50
Configuration last modified by 0.0.0.0 at 3-1-93 00:05:40
Local updater ID is 0.0.0.0 (no valid interface found)
SW3#show vlan brief

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/2, Fa0/3, Fa0/4, Fa0/5
Fa0/6, Fa0/7, Fa0/8, Fa0/9
Fa0/10, Fa0/11, Fa0/12, Fa0/13
Fa0/14, Fa0/15, Fa0/16, Fa0/17
Fa0/18, Fa0/19, Fa0/20, Fa0/21
Fa0/22, Fa0/23, Fa0/24, Gig0/1
Gig0/2
2 VLAN0002 active
3 VLAN0003 active
4 VLAN0004 active
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
SW3#

So here is the scenario for the question. The Fa0/24 connection is suddenly broken between SW1 and SW2, and while that is down, a new VLAN (we will use 999) is created on SW3 like this:

<strong>SW3(config)#vlan 999</strong>

And then, a few minutes later, SW3 is completely powered off, shipped to another city, and removed completely from this network forever.

If we then restore the Fa0/24 connection between SW1 (the server) and SW2 (the client) what will happen to the VTP/VLAN information on the two switches? Will there be an update on either switch, will SW1 wait for a Server advertisement or will something else happen all together?

Take a moment, and let us know what you think.

Best wishes.

PS We’ll post the results as a after you have had some time to consider the results.

A few hours have passed, and we have had over 50 comments , ideas and theories.

I appreciate you taking the time to work through this. May your hard work pay off with a successful lab.

And the correct answer is:

SW1, will see that its configuration revision number is lower than SW2, and even though SW2 is a "client" SW1 will use the updated information in the VTP advertisement from SW2 to update to its VLAN database, and get in "sync" with the rest of the VTP domain, including knowing about VLAN 999. The configuration revision number would also move to 4.

Here is SW1, after the connection to SW2 is restored:

SW1#show vtp status
VTP Version : 2
Configuration Revision : 4
Maximum VLANs supported locally : 1005
Number of existing VLANs : 9
VTP Operating Mode : Server
VTP Domain Name : INE
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x45 0x1D 0x6E 0xF0 0xB7 0xC2 0x84 0xFA
Configuration last modified by 0.0.0.0 at 3-1-93 00:11:43
Local updater ID is 0.0.0.0 (no valid interface found)
SW1#show vlan brief

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/11, Fa0/12
Fa0/13, Fa0/14, Fa0/15, Fa0/16
Fa0/17, Fa0/18, Fa0/19, Fa0/20
Fa0/21, Fa0/22, Fa0/23, Gig0/1
Gig0/2
2 VLAN0002 active
3 VLAN0003 active
4 VLAN0004 active
999 VLAN0999 active
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
SW1#

Here is SW2:

SW2#show vtp status
VTP Version : 2
Configuration Revision : 4
Maximum VLANs supported locally : 1005
Number of existing VLANs : 9
VTP Operating Mode : Client
VTP Domain Name : INE
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x45 0x1D 0x6E 0xF0 0xB7 0xC2 0x84 0xFA
Configuration last modified by 0.0.0.0 at 3-1-93 00:11:43
SW2#show vlan brief

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/11, Fa0/12
Fa0/13, Fa0/14, Fa0/15, Fa0/16
Fa0/17, Fa0/18, Fa0/19, Fa0/20
Fa0/21, Fa0/22, Fa0/23, Gig0/1
Gig0/2
2 VLAN0002 active
3 VLAN0003 active
4 VLAN0004 active
999 VLAN0999 active
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
SW2#

Thanks again everyone, and happy studies!

Oct

Traffic Classification in the 3550/3560 Switches

7 Comments

Posted by Petr Lapukhov, 4xCCIE/CCDE in 3550, 3560, classification, cos, diff-serv, dscp, marking, mqc, QoS, Switching

In this post we will look at the basic classification and marking features available in the 3550 and 3560 switches. Basic features include packet marking using port-level settings and port-level policy-maps. Discussing Per-VLAN classification is outside the scope of this document.

The Catalyst QoS implementation bases on Differentiated Services model. In a few words, the ideas of this model could be outlined as follows:

1) Edge nodes classify ingress packets based on local policy and QoS label found in packets.
2) Edge nodes encode traffic classes using a special field (label) in packets to inform other nodes of the classification decision.
3) Core and edge nodes allocate resources and provide services based on the packet class.

Note that each node acts independently on its own, as instructed by the local policy. In order for the QoS policy to be consistent end-to-end, the network administrator must ensure that all nodes use the same classification and resource allocation policy.

The following are the marking types found in IP/Ethernet networks:

1) ToS byte in IP packet or Traffic Class byte in IPv6 packet. The switch may interpret this field in two different ways:
1.1) Interpret the topmost six bits of the byte as DSCP code point. This is in full compliance with Diff-Serv model.
1.2) Interpret the topmost three bits of the byte as IP Precedence value. This complies with the old, “military-style” QoS model, where higher precedence traffic preempts the lower precedences. Note that IP Precedence numbers form a “subspace” of DSCP numbers.
2) The CoS bits (three bits) in 802.1q/ISL header of a tagged Ethernet frame. These bits are also known as 802.1p priority bits, and should be interpreted as relative traffic priorities.

As we can see, the marking types could be either Layer 3 (IP/IPv6 fields) or Layer 2 (802.1p bits). Naturally, the latter option is only applicable on trunk links.

The Catalyst switches have no special intelligence to implement any of these QoS models by themselves. It’s up to you to define policy and encode classes using any marking you find more suitable for your task. Due to numerous markings types, Catalyst switches assign a special internal QoS label to all packets and use this label for internal QoS processing. In the 3550 this label is simply a special “internal” DSCP value. However, in the 3560 the QoS label format is more complicated, and allows storing either CoS or DSCP information.

Now recall the distinction made by the multilayer switches between IP and non-IP packets. As we know, Layer 3 switches are hardware optimized to route IP or IPv6 packets using their ASICs for optimum performance. This results in differences of handling the IP and non-IP packets. You may use MAC-based ACLs (matching MAC addresses, Ether-types or LSAPs) only with non-IP packets (e.g. ARP, DECNet, IPX). The MAC ACLs will not match any of IP packets, even if you specify a matching MAC addresses. Also, note that the 3560 models treats IPv6 as “IP” traffic, while the 3550 treats IPv6 packets as “non-IP” and matches them with MAC ACLs.

QoS processing pipeline

The following diagram displays stages of QoS processing in a typical Catalyst switch.

We are now considering the Classification and Marking stage. The switch uses local policy configuration to classify input packets. The local policy may be as simple as port QoS settings or more complicated, such as policy-maps with QoS ACLs. The result of classification stage is the internal QoS label (e.g. internal DSCP value with the 3550). At this stage, the switch uses special globally configurable QoS mapping tables. The tables map one QoS marking “type” to another, e.g. CoS values to DSCP, or DSCP to CoS. You can display the tables using the command show mls qos map.

The switch uses these tables for two major purposes:

a) To “synchronize” different types of QoS markings present in a packet. For example, if you instruct the switch to set CoS field to “3”, the switch will look up through the CoS-to-DSCP mapping table and rewrite the DSCP value in the IP packet header accordingly.

b) To translate the ingress marking (e.g. CoS, or IP Precedence) into the values used in the QoS label. For example with the 3550 switch, the CoS to DSCP mapping table is used when you trust ingress CoS marking to find the resulting internal DSCP value.

You may classify using either interface level settings or by applying a pre-configured policy-map to the interface. These two options are mutually exclusive: that is, if you configure interface level classification settings and later apply a service-policy, then the latter removes interface-level QoS classification settings (there are some exceptions though).

Classification Options

1) Trust one of the marking types already present in packet (mls qos trust {dscp|ip-precedence|cos}). For IP packets, it is possible to trust either IP Precedence or DSCP value. Of course, doing so makes sense only for IP packets. If the switch trust IP marking and incoming packet is non-IP, the switch will attempt to classify based on CoS value in the Ethernet header. If there is a CoS value in the packet (i.e. the port is trunk) the switch uses this value to build the QoS label. However, if the packets bears no CoS field, the switch will look at the default CoS value configured on the interface (mls qos cos x). The switch computes corresponding DSCP value for the label using the CoS to DSCP table. When you trust IP precedence, the switch builds DSCP value using the IP-Precedence to DSCP mapping table and the CoS value using the DSCP to CoS mapping table.

2) Trusting CoS (mls qos trust cos) is a bit different. First, it works for both IP and non-IP packets, since they both may bear CoS bits in the Ethernet header. Thus, when the switch trusts CoS on interface, it attempts to build the QoS label based on the CoS bits. If there is no 802.1q/ISL header, the default CoS value from the interface settings is used instead (not the IP/DSCP value from the packet header!). This procedure works for both IP and non-IP packets: the switch does not take in account the IP Precedence/DSCP values. The corresponding mapping table allows the switch to compute the internal DSCP value/QoS lable and rewrite the DSCP values in the IP/IPv6 packet header.

3) You may explicitly assign a specific CoS value to all packets, either marked or not, entering the interface using the mls qos cos override command. This command will force the use of CoS value specified by the mls qos cos x command for all IP and non-IP packets. Note that this feature only works with CoS values, and the switch deduces actual DSCP marking using the CoS to DSCP mapping table. Also, note that any “trust” configuration on an interface conflicts with the “override” settings and thus the switch removes the former commands.

4) The most flexible option is to use QoS ACLs to perform classification and we are going to discuss the use of QoS ACLs in a separate topic below.

A special type of trust is conditional trust. That means trusting QoS marking only if the switch detects certain device connected to the port - for example, if the switch senses Cisco IP Phone CDP announces. The command for conditional trust is mls qos trust device and it instructs the switch to trust the packet marking only if the certain device reports itself via CDP.

The automatic rewrite feature ensures the uniform marking - that is, it takes care of synchronizing L2 and L3 code points. Is it possible to trust DSCP and built the internal QoS label based on its value, but retain the CoS bits in the packet? Alternatively – trust CoS bits and retain the DSCP values? You may need this capability occasionally, if you want to “tunnel” one type of QoS marking through your network, while using the other type for your needs.

QoS Pass-Through feature

In the Catalyst 3550, you may set one type of marking as “pass-through”. For example, when you trust CoS you may enable DSCP pass-through with the interface-level command mls qos trust cos pass-through dscp. The command with reverse logic is naturally mls qos trust dscp pass-through cos.

On the 3560 switches, you only have option to disable DSCP rewrite in IP headers, when you trust the CoS values, using the global command no mls qos rewrite ip dscp

Classification using QoS ACLs

Even though they are called QoS ACLs (the term borrowed from CatOS) you actually apply these using MQC syntax by configuring class-maps and policy-maps. You may define MQC traffic classes by matching one of the following:

1) MAC or IP/IPv6 access-list. The MAC access-list matches non-IP packets and IP/IPv6 matches IP or IPv6 packets respectively. Of course, you can only match IPv6 packets on the 3560. As mentioned above, you cannot use MAC ACLs to match IP traffic (though you can use MAC ACLs on the 3550 to match IPv6 traffic).

2) DSCP and IP Precedence values. Note that you cannot match CoS value in Ethernet headers (like you can do in routers).

3) Additional platform-specific matches like match input-interface and match vlan. These are used by the 3560 hierarchical policy maps or the 3550 per-port per-VLAN classification.

The classification criteria are very limited, compared to IOS routers. You cannot match packet size or packet payload. Additionally, you cannot do hierarchical matching, with exception for per-VLAN classification feature. These limitations are result of tight hardware optimization in the Layer 3 switches.

Pay attention to the behavior of the class “class-default” with the Catalyst QoS. This class works fine in the 3560 switches, matching both IP and non-IP traffic. However, it seems to work inconsistently or does not work at all with the 3550 switches. In the latter model, as a workaround, create special classes to match either all IP or all non-IP traffic using IP/MAC ACLs:

ip access-list standard ALL_IP

 permit any

!

mac access-list extended ALL_MAC

 permit any any 0x0 0xFFFF

!

class-map ALL_IP

 match access-group ALL_IP

!

class-map ALL_MAC

 match access-group ALL_MAC

Under a class in the policy-map you can either trust (CoS, DSCP, IP Precedence) or set (DSCP, IP Precedence) the respective QoS marking. Note that you cannot set CoS value directly in the 3560 switches, but you can set DSCP for non-IP packets. The switch translates DSCP into CoS using the DSCP-to-CoS mapping table. The same holds true for the 3550 switches – you can set DSCP on the non-IP packets and it is translated to the CoS. Note the special feature of the 3560 switches: the QoS marking you trust or set is later used to look up the DSCP or CoS to queue/threshold mapping tables. This is because the 3560 defines two egress mapping tables: one for DSCP and other for CoS values, based on the complex structure of the QoS label.

In the 3550 switches you can set CoS value directly in one special case. First, you need the global command mls qos cos policy-map. Using this feature, you must trust DSCP marking and set Layer 2 marking using the set cos command. This simulates the behavior of “CoS pass-through” feature available at the interface-level settings. The set cos feature only works when you trust DSCP. Furthermore, the 3550 performs all QoS processing and deduces internal DSCP based on the trusted dscp value, not the CoS value set with the policy map.

With both switch models, you can either configure set dscp or set ip precedence but not at the same time, of course – the one configured later erases the previous one. Also, if a class contains ”trust” and “set” statements for the same type of marking (e.g. L3 or L2) the trust statement takes precedence over explicit set.

Aside from that, trust feature works the same way as it works on the interface but has scope limited to the class defined by ACL.

Remember that applying a service-policy will remove any interface-level QoS settings on the interface, with exception to the default CoS (which is used by the policy map when you trust CoS inside a class). If the input packet doest not match any class in the service-policy, the switch will set all marking to zero. If you trust CoS for IP or non-IP packets and there is no 802.1q/ISL header the switch will take the default CoS value from the interface settings or use zero markings.

Sep

Comparing Traffic Policing Features in the 3550 and 3560 switches

5 Comments

Posted by Petr Lapukhov, 4xCCIE/CCDE in 3550, 3560, catalyst, catalyst-qos, CCIE R&S, mqc, per-vlan, policing, QoS, Switching, vlan-based

People are often confused with per-VLAN classification, policing and marking features in the Catalyst 3550 and 3560 models. The biggest problem is lack of comprehensive examples in the Documentation CD. Let's quickly review and compare traffic policing features available on both platforms. The material below is a condensed excerpt of several Catalyst QoS topics covered in the “QoS” section of our IEWB VOL1 V5. You will find more in-depth explanations and large number of simulation-based verifications in the upcoming section of the workbook.

Per-Port QoS ACL based classification in the 3550 and 3560

This feature works the same in both switches. Even though it is common to see this method named as “QoS ACLs” classification, it actually uses MQC syntax with class-maps and policy-maps. The term “QoS ACL” comes from the Catalyst OS PFC-based QoS model where you apply QoS ACLs directly to ports. In IOS-based switches, you use the familiar MQC syntax.

Look at the following example. Here we mark IPX packets (classified based on SNAP Protocol ID) with CoS value of 5, ICMP packets with IP Precedence 2 and ICMP packets with DSCP value of 24 (CS3). All remaining traffic, be it IP or non-IP, matches class-default and the system trusts the CoS values in the frame header. If a packet matches “class-default” but has no CoS value in the header, the system uses the default value from the interface, specified with mls qos cos 1

Example 1:

!

! Access-Lists. IPX SNAP Protocol ID is 0x8137

!

mac access-list extended IPX

 permit any any 0x8137 0x0

!

ip access-list extended ICMP

 permit icmp any any

!

ip access-list extended TELNET

 permit tcp any any eq telnet

 permit tcp any eq telnet any
!

! Class Maps

!

class-map match-all TELNET

  match access-group name TELNET

!

class-map match-all ICMP

  match access-group name ICMP

!

class-map match-all IPX

  match access-group name IPX
!

! Note that we set DSCP under non-IP traffic class. The switch computes

! the respective CoS value using DSCP-to-CoS table.

!

policy-map CLASSIFY

  class IPX

   set dscp ef

  class ICMP

   set dscp cs3

  class TELNET

   set precedence 2

  class class-default

    trust cos
!

! Apply the policy

!

interface FastEthernet 0/6

 mls qos cos 1

 service-policy input CLASSIFY

Note the use of set dscp command on non-IP packet. You cannot set CoS value directly, with one special case for the 3550 switches. Therefore, you should use the command set dscp for both IP and non-IP packets if you want to change the CoS field.

You may apply the same policy in the 3550 models, but with one special limitation. The “class-default” should be split into two user-defined classes matching IP and non-IP traffic. I never seen "class-default" working properly in the 3550 models, so if you have a working example with verifications, please let me know :). Here is a workaround, that shows how to police both IP and non-IP traffic simultaneously in the 3550 model:

Example 2:

!

! All IP traffic

!

ip access-list standard IP_ANY

 permit any

!

! All non-IP traffic

!

mac access-list extended MAC_ANY

 permit any any 0x0 0xFFFF

!

class-map IP_ANY

 match access-group name IP_ANY

!

class-map MAC_ANY

 match access-group name MAC_ANY

!

mls qos aggregate-policer AGG256 256000 32000 exceed-action drop

!

policy-map AGGREGATE_LIMIT

 class IP_ANY

  police aggregate AGG256

 class MAC_ANY

  police aggregate AGG256

Per-Port Per-VLAN Classification in the 3550 switches

This feature is unique to the 3550 switches. You may configure traffic classification that takes in account VLAN for input traffic. Unfortunately, you can only apply it at a port-level. There is no option to classify the traffic entering VLANs on any port using a single policy, like there is in the 3560 model. Note that you can apply per-port per-VLAN policy on a trunk or an access port. Of course, in this case the access port must be in a VLAN matched by the policy-map. Here is an example of per-VLAN classification and marking in the 3550 models. What it does, is sets different DSCP and CoS values for IPX and ICMP packets coming from VLAN146 only. Other VLANs on a trunk port will remain intact.

Example 3:

mls qos

!

! Acess-Lists

!

ip access-list extended ICMP

 permit icmp any any

!

mac access-list extended IPX

 permit any any 0x8137 0x0
!

! Second-level class-maps

!

class-map ICMP

 match access-group name ICMP

!

class-map IPX

 match access-group name IPX
!

! First-level class-maps

!

class-map VLAN_146_ICMP

 match vlan 146

 match class-map ICMP

!

class-map VLAN_146_IPX

 match vlan 146

 match class-map IPX
!

! Policy-maps. Note that we set DSCP for IPX packets

! In fact, this is the internal DSCP value, not the IP DSCP.

! You cannot set CoS directly – only when trusting DSCP.

! DSCP 16 translates to CoS 2 by the virtue of the

! default DSCP-to-CoS table.

!

policy-map PER_PORT_PER_VLAN

 class VLAN_146_ICMP

   set dscp CS3

 class VLAN_146_IPX

   set dscp 16 
!

! Apply the policy-map

!

interface FastEthernet 0/4

  service-policy input PER_PORT_PER_VLAN

Note the special syntax used by this features. All classes in the policy-map must use match vlan statement on their first line and match another class in their second line. The second-level class-map should use only one statement, e.g. match access-group name. The access-group itself may have variable number of entries.

Per-Port Per-VLAN Policing in the 3550

The following example is just a demonstration of applying policing inside VLAN-based policy-map in the 3550. This feature is a regular policer, just the same you can use in a per-port policy-map. You can either drop packet or re-mark the internal DSCP. With the 3550 it is even possible to use aggregate policer shared between several VLANs on a single port.

The example remarks IP traffic exceeding the rate of 128Kbps with DSCP value of CS1. Prior to metering, the policy map marks traffic with AF11. The policy map marks non-IP traffic with a CoS value of three, and drops packets that exceed 256Kbps. All classification and policing procedures apply only to packets in VLAN146.

Example 4:

mls qos

mls qos map policed-dscp 10 to 8
!

! Acess-Lists

!

ip access-list extended IP_ANY

 permit IP any any

!

mac access-list extended NON_IP_ANY

 permit any any 0x0 0xFFFF
!

! Second-level class-maps

!

class-map IP_ANY

 match access-group name IP_ANY

!

class-map NON_IP_ANY

 match access-group name NON_IP_ANY
!

! First-level class-maps

!

class-map VLAN_146_IP

 match vlan 146

 match class-map IP_ANY

!

class-map VLAN_146_NON_IP

 match vlan 146

 match class-map NON_IP_ANY
!

! Since we are not limited, we use any burst values

! Policy map matches first-level class-maps

!

policy-map POLICE_PER_PORT_PER_VLAN

 class VLAN_146_IP

   set dscp af11

   police 128000 16000 exceed-action policed-dscp-transmit

 class VLAN_146_NON_IP

   set dscp cs3

   police 256000 32000  
!

! Apply the policy-map

!

interface FastEthernet 0/4

  service-policy input POLICE_PER_PORT_PER_VLAN

Per-VLAN Classification in the 3560

Switch-wide per-VLAN classification is feature specific to the 3560. You can apply a service-policy to SVI, listing class-map and respective mark actions in the policy-map. Note that you cannot usethe police command in a service-policy applied to SVI. All packets in the respective VLAN entering the switch on the ports enabled for VLAN-based QoS are subject to inspection by service-policy on the SVI. The effect is that QoS marking policy is now switch-wide on all ports (trunks or access) having the respective VLAN activated (allowed and STP forwarding state).

The following example sets DSCP EF in the TCP packets entering VLAN146 and CoS 4 in the IPX packet transiting the switch across VLAN 146. Note that all ports with VLAN146 that are configured for VLAN QoS will be affected by this configuration.

Example 5:

mls qos

!

! Enable VLAN-based QoS on interfaces

!

interface FastEthernet 0/1

 mls qos vlan-based
!

! Enable VLAN-based QoS on the trunks

!

interface range FastEthernet 0/13 - 21

 mls qos vlan-based
!

! Access-Lists

!

ip access-list extended TCP

 permit tcp any any

!

mac access-list extended IPX

 permit any any 0x8137 0x0
!

! First-level class-maps

!

class-map TCP

 match access-group name TCP

!

class-map IPX

 match access-group name IPX
!

! VLAN-based policy-map

!

policy-map PER_VLAN

 class TCP

  set dscp ef

 class IPX

  set dscp 32
!

! Apply the policy-map to SVI

!

interface VLAN 146

 service-policy input PER_VLAN

As mentioned above, you cannot use policing in SVI-level policy map. This eliminates the possibility of having policer aggregating traffic rates for all ports in a single VLAN. However, you can still police per-port per-VLAN in the 3560 using the following feature.

Per-Port Per-VLAN Policing in the 3560

This feature uses second-level policy-maps. The second-level policy-map must list class-maps satisfying specific restrictions. The only “match” criterion supported in those class-maps is match input-interface. You can list several interfaces separated by spaces, or use interface ranges, separating interfaces in a range by hyphen. The only action supported in the second-level policy-map is the police command. As usual, you can drop exceeding traffic or configure traffic remarking using policed DSCP map. The police action applies individually to every port in the range.

You cannot use aggregate policers in the second-level policy-maps. Another restriction – if you apply a second-level policy-map (interface-level map) inside “class-default” it will have no effect. You need to apply the second-level policy-map inside user-defined classes.

The following example restricts IP traffic rate in VLAN146 on every trunk port to 128Kbps and limits the IP traffic in VLAN146 on the port connected to R6 to 256Kbps.

Example 6:

mls qos map policed-dscp 18 to 8
!

! For 2nd level policy you can only match input interfaces

!

class-map TRUNKS

 match input-interface FastEthernet 0/13 -  FastEthernet 0/21
!

! The second class-map matches a group of ports or a single port

!

class-map PORT_TO_R6

 match input-interface FastEthernet 0/6
!

! IP traffic: ACL and class-map

!

ip access-list extended IP_ANY

 permit ip any any

!

class-map IP_ANY

 match access-group name IP_ANY
!

! Second-level policy-map may only police, but not mark

!

policy-map INTERFACE_POLICY

 class TRUNKS

  police 128000 16000 exceed policed-dscp-transmit

 class PORT_TO_R6

  police 256000 32000
!

! 1st level policy-map may only mark, not police

! VAN aggregate policing is not possible in the 3560

!

policy-map VLAN_POLICY

 class IP_ANY

  set dscp af21

  service-policy INTERFACE_POLICY

!

interface Vlan 146

 service-policy input VLAN_POLICY
!

! Enable VLAN-based QoS on the ports

!

interface FastEthernet 0/6

 mls qos vlan-based
!

! Enable VLAN-based QoS

!

interface range FastEthernet 0/13 - 21

 mls qos vlan-based

This is it for the comparison of most common policing features on the 3550 and 3560 platforms. Digging deeper in the areas of Catalyst QoS would probably takes us far beyond the size of a post the a normal human can read :)

Jul

Private VLANs Revisited

61 Comments

Posted by Petr Lapukhov, 4xCCIE/CCDE in 3560, Advanced Security, arp, ccie, community, isolated, level2, private-vlan, promiscuous, Security, Switching, vlan

Due to the non-decreasing interest to the post about Private VLANs, I decided to make another one, more detailed – including a diagram and verification techniques.

Introduction

To begin with, recall that VLAN is essentially a broadcast domain. Private VLANs (PVANs) allow splitting the domain into multiple isolated broadcast "subdomains", introducing sub-VLANs inside a VLAN. As we know, Ethernet VLANs can not communicate directly with each other - they require a L3 device to forward packets between separate broadcast domains. The same restriction applies to PVLANS - since the subdomains are isolated at Level 2, they need to communicate using an upper level (L3/packet forwarding) device - such as router.

In reality, different VLANs normally map to different IP subnets. When we split a VLAN using PVLANs, hosts in different PVLANs still belong to the same IP subnet, yet now they need to use a router (L3 device) to talk to each other (for example, by using Local Proxy ARP). In turn, the router may either permit or forbid communications between sub-VLANs using access-lists. Commonly, these configurations arise in "shared" environments, say ISP co-location, where it's beneficial to put multiple customers into the same IP subnet, yet provide a good level of isolation between them.

Private VLANs Terminology

The following is the reference diagram that we are going to use to illustrate Private VLAN concepts and functionality.

For our sample configuration, we take VLAN 1000 and divide it into three PVLANs - sub-VLAN 1012 (R1 and R2), sub-VLAN 1034 (R3 and R4) and sub-VLAN 1055 (router R5 only). Router R6 will be used as layer 3 device, to resolve the layer 3 communication issue. We name VLAN 1000 as “Primary” and classify the ports, assigned to this VLAN, based on their types:

Promiscuous (“P”) port: Usually connects to a router. This port type is allowed to send and receive L2 frames from any other port on the VLAN.
Isolated (“I”) port: This type of port is only allowed to communicate with “P”-ports - i.e., they are "stub" port. You commonly see these ports connecting to hosts.
Community (“C”) port: Community ports are allowed to talk to their buddies, sharing the same community (group) and to “P”-ports.

In order to implement sub-VLAN behavior, we need to define how packets are forwarded between different types of ports. We group the VLANs in "Primary" and "Secondary".

Primary VLAN (VLAN 1000 in our example). This VLAN is used to forward frames downstream from “P”-ports to all other port types (“I” and “C” ports) in the system. Essentially, Primary VLAN embraces all ports in the domain, but only transports frames from the router to hosts (from “P” to “I” and “C”).
Secondary Isolated VLAN: forwards frames from "I" ports to "P" ports. Since Isolated ports do not exchange frames with each other, we can use just ONE isolated VLAN to connect all I-Port to the P-port.
Secondary Community VLANs: Transport frames between community ports (C-ports) within to the same group (community) and forward frames upstream to the P-ports of the primary VLAN.

How Private VLANs Work

Here are the key aspects of Private VLAN functioning:

The Primary VLAN delivers frames downstream from the router (promisc port) to all mapped hosts.
The Isolated VLAN transports frames from the stub hosts upstream to the router
The Community VLANs allow bi-directional frame exchange withing a single group, in addition to forwarding frames upstream towards "P"-ports.
Ethernet MAC address learning and forwarding procedure remain the same, as well as broadcast/multicast flooding procedure within boundaries of primary/secondary VLANs.

Private VLANs could be trunked. The secondary VLAN numbers are used to tag frames, just as with regular VLANs, and the primary VLAN traffic is trunked as well. However, you need to configure Private VLAN specific settings (bindings, mappings) on every participating swtich, as it's not possible to use VTPv2 to dissiminate that information . This due to the fact that VTPv2 has no TLVs to carry private VLANs information. VTPv3 was designed to overcome this limitation among others.

Configuring Private VLANs

We have primary VLAN 1000, Isolated VLAN 1005 (R5) Community VLAN 1012 (R1, R2) and Community VLAN 1034 (R3, R4).

Step 1:

First, disable VTP, i.e. enable VTP transparent mode. After disabling VTP, create Primary and Secondary VLANs and bind them into PVLAN domain:

SW1:
vtp mode transparent
!
! Creating primary VLAN, which is shared among secondary’s
!
vlan 1000
private-vlan primary

!
! Community VLAN for R1 and R2: allows a “subVLAN” within a Primary VLAN
!
vlan 1012
private-vlan community
!
! Community VLAN for R3 and R4
!
vlan 1034
private-vlan community

!
! Isolated VLAN: Connects all stub hosts to router.
! Remember - only one isolated vlan per primary VLAN.
! In our case, isolates R5 only.
!
vlan 1055
private-vlan isolated

!
! Associating the primary with secondary’s
!
vlan 1000
private-vlan association 1012,1034,1055

This step is needed is to group PVLANs into a shared domain and establish a formal association (for syntax checking and VLAN type verifications). Repeat the same operations on SW2, since VTP has been disabled.

Step 2:

Configure host ports and bind them to the respective isolated PVLANs. Note that a host port belongs to different VLANs at the same time: downstream primary and upstream secondary. Also, enable trunking between switches, to allow private VLANs traffic to pass between switches.

SW1:
!
! Community port (links R1 to R2 and “P”-ports)
!
interface FastEthernet0/1
description == R1
switchport private-vlan host-association 1000 1012
switchport mode private-vlan host
spanning-tree portfast

!
! Community port (links R3 to R4 and “P”-ports)
!
interface FastEthernet0/3
description == R3
switchport private-vlan host-association 1000 1034
switchport mode private-vlan host
spanning-tree portfast

!
! Isolated port (uses isolated VLAN to talk to “P”-ports)
!
interface FastEthernet0/5
description == R5
switchport private-vlan host-association 1000 1055
switchport mode private-vlan host
spanning-tree portfast

!
! Trunk port
!
interface FastEthernet 0/13
switchport trunk encapsulation dot1q
switchport mode trunk

SW2:
interface FastEthernet0/2
description == R2
switchport private-vlan host-association 1000 1012
switchport mode private-vlan host
spanning-tree portfast
!
interface FastEthernet0/4
description == R4
switchport private-vlan host-association 1000 1034
switchport mode private-vlan host
spanning-tree portfast

!
! Trunk port
!
interface FastEthernet 0/13
switchport trunk encapsulation dot1q
switchport mode trunk

Next, Verify the configuration on SW1:

Rack1SW1#show vlan id 1012

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1012 VLAN1012 active Fa0/13

VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1012 enet 101012 1500 - - - - - 0 0

Remote SPAN VLAN
----------------
Disabled

Primary Secondary Type Ports
------- --------- ----------------- ------------------------------------------
1000 1012 community Fa0/1

Rack1SW1#show vlan id 1034

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1034 VLAN1034 active Fa0/13

VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1034 enet 101034 1500 - - - - - 0 0

Remote SPAN VLAN
----------------
Disabled

Primary Secondary Type Ports
------- --------- ----------------- ------------------------------------------
1000 1034 community Fa0/3

Rack1SW1#show vlan id 1055

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1055 VLAN1055 active Fa0/13

VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1055 enet 101055 1500 - - - - - 0 0

Remote SPAN VLAN
----------------
Disabled

Primary Secondary Type Ports
------- --------- ----------------- ------------------------------------------
1000 1055 isolated Fa0/5

Rack1SW1#show interfaces fastEthernet 0/13 trunk

Port Mode Encapsulation Status Native vlan
Fa0/13 desirable 802.1q trunking 1

Port Vlans allowed on trunk
Fa0/13 1-4094

Port Vlans allowed and active in management domain
Fa0/13 1,1000,1012,1034,1055

Port Vlans in spanning tree forwarding state and not pruned
Fa0/13 1,1000,1012,1034,1055

Verify on SW2:

Rack1SW2#show vlan id 1000

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1000 VLAN1000 active Fa0/13

VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1000 enet 101000 1500 - - - - - 0 0

Remote SPAN VLAN
----------------
Disabled

Primary Secondary Type Ports
------- --------- ----------------- ------------------------------------------
1000 1012 community Fa0/2, Fa0/6
1000 1034 community Fa0/4, Fa0/6
1000 1055 isolated Fa0/6

Rack1SW2#show vlan id 1012

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1012 VLAN1012 active Fa0/13

VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1012 enet 101012 1500 - - - - - 0 0

Remote SPAN VLAN
----------------
Disabled

Primary Secondary Type Ports
------- --------- ----------------- ------------------------------------------
1000 1012 community Fa0/2, Fa0/6

Rack1SW2#show vlan id 1034

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1034 VLAN1034 active Fa0/13

VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1034 enet 101034 1500 - - - - - 0 0

Remote SPAN VLAN
----------------
Disabled

Primary Secondary Type Ports
------- --------- ----------------- ------------------------------------------
1000 1034 community Fa0/4, Fa0/6

Rack1SW2#show vlan id 1055

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1055 VLAN1055 active Fa0/13

VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1055 enet 101055 1500 - - - - - 0 0

Remote SPAN VLAN
----------------
Disabled

Primary Secondary Type Ports
------- --------- ----------------- ------------------------------------------
1000 1055 isolated Fa0/6

Rack1SW2#show interface fastEthernet 0/13 trunk

Port Mode Encapsulation Status Native vlan
Fa0/13 desirable 802.1q trunking 1

Port Vlans allowed on trunk
Fa0/13 1-4094

Port Vlans allowed and active in management domain
Fa0/13 1,1000,1012,1034,1055

Port Vlans in spanning tree forwarding state and not pruned
Fa0/13 1,1000,1012,1034,1055

Step 3:

Create a promiscuous port and configure downstream mappings. Here we add secondary VLANs for which traffic is received by this particular “P”-port. Primary VLAN is used to send traffic downstream to all “C” and “I” ports per their associations.

SW2:
!
! Promiscuous port, mapped to all secondary VLANs
!
interface FastEthernet0/6
description == R6
switchport private-vlan mapping 1000 1012,1034,1055
switchport mode private-vlan promiscuous
spanning-tree portfast

Verify the promiscuous port configuration:

Rack1SW2#show int fa 0/6 switch | beg private
Administrative Mode: private-vlan promiscuous
Operational Mode: private-vlan promiscuous
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: 1000 (VLAN1000) 1012 (VLAN1012) 1034 (VLAN1034) 1055 (VLAN1055)
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk private VLANs: none
Operational private-vlan:
1000 (VLAN1000) 1012 (VLAN1012) 1034 (VLAN1034) 1055 (VLAN1055)

If you need to configure an SVI on a switch to communicate with private VLAN members, you should add an interface corresponding to Primary VLAN only. Obviously that's because all secondary VLANs are "subordinates" of primary. After an SVI has been created, you have to map the required secondary VLANs to the SVI (just like with a promiscuous port) in order to make communications possible. You may exclude some mappings from SVI interface, and limit it to communicating only with certain secondary VLANs.

SW1:
!
! SW1 SVI is mapped to all secondary VLANs
!
interface Vlan 1000
ip address 10.0.0.7 255.255.255.0
private-vlan mapping 1012,1034,1055

SW2:
!
! SW2 SVI is mapped to 1012/1034 only, so it’s cant communicate with R5
!
interface Vlan1000
ip address 10.0.0.8 255.255.255.0
private-vlan mapping 1012,1034

Now to verify the configuration, configure R1-R6 interfaces in subnet “10.0.0.0/24” and ping broadcast addresses.

Rack1R1#ping 10.0.0.255 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.0.0.255, timeout is 2 seconds:

Reply to request 0 from 10.0.0.7, 4 ms
Reply to request 0 from 10.0.0.2, 4 ms
Reply to request 0 from 10.0.0.6, 4 ms
Reply to request 0 from 10.0.0.8, 4 ms

Rack1R3#ping 10.0.0.255 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.0.0.255, timeout is 2 seconds:

Reply to request 0 from 10.0.0.7, 4 ms
Reply to request 0 from 10.0.0.4, 4 ms
Reply to request 0 from 10.0.0.6, 4 ms
Reply to request 0 from 10.0.0.8, 4 ms

Rack1R5#ping 10.0.0.255 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.0.0.255, timeout is 2 seconds:

Reply to request 0 from 10.0.0.7, 1 ms
Reply to request 0 from 10.0.0.6, 1 ms

Rack1R6#ping 10.0.0.255 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.0.0.255, timeout is 2 seconds:

Reply to request 0 from 10.0.0.1, 4 ms
Reply to request 0 from 10.0.0.7, 4 ms
Reply to request 0 from 10.0.0.2, 4 ms
Reply to request 0 from 10.0.0.5, 4 ms
Reply to request 0 from 10.0.0.3, 4 ms
Reply to request 0 from 10.0.0.4, 4 ms
Reply to request 0 from 10.0.0.8, 4 ms

Lastly, there is another feature, called protected port or “Private VLAN edge”. The feature is pretty basic and is available even on low-end Cisco switches. It allows isolating ports in the same VLAN. Specifically, all ports in a VLAN, marked as protected are prohibited from sending frames to each other (but still allowed to send frames to other (non-protected) ports within the same VLAN). Usually, ports configured as protected are also configured not to receive unknown unicast (frame with destination MAC address not in switch's MAC table) and multicast frames flooding for added security.

Example:

interface range FastEthernet 0/1 - 2

 switchport mode access

 switchport protected

 switchport block unicast

 switchport block multicast

Jul

802.3x Flow-Control

9 Comments

Posted by Petr Lapukhov, 4xCCIE/CCDE in 3550, 3560, 802.1p, CCIE R&S, legacy, pause, QoS, Switching

Generally, flow-control is a mechanics allowing the receiving party of a connection to control the rate of the sending party. You may see many different implementations of flow-control technologies at different levels of OSI model (e.g. XON/XOFF for RS232, TCP sliding window, B2B credits for Fibre Channel, FECN/BECN for Frame-Relay, ICMP source-quench message, etc). Flow-Control allows for explicit feedback loop and theoretically implementing loss-less networks that avoid congestion.

For the original Ethernet technology on half-duplex connections there was no possibility of implementing explicit flow control, since only one side could send frames at time. However, you may still remember the Cisco's so-called "back-pressure" feature on some of the older switches, e.g. Cisco Catalyst 1924. The idea was that switch may send barrage of dummy frames on a half-duplex link, effectively preventing the attached station from transmitting information at given moments of time.

Things changed with full-duplex point-to-point connections. The idea of IEEE 802.3X flow-control was to allow a station on a point-to-point link sending a special "PAUSE" frame (destined to a reserved multicast MAC address 01:80:C2:00:00:01). This frame would signal the other end of the connection to pause transmission for a certain amount of time, which was is specified in the frame. (Note that the PAUSE frame uses MAC LLC encapsulation). The attached device could be a host station or another switch - it does not matter. Upon receiving the PAUSE frame, the sender should stop the traffic flow and either buffer the packets or drop them. The paused switch may in turn propagate the PAUSE frame further upstream toward the sending node, and thus congestion notification will propagate end-to-end.

There were two main problems with the 802.3x flow-control. Firstly, there were interoperability problems with different vendors implementing the PAUSE functionality. Secondly, the PAUSE frame mechanics was too simple to implement granular policies, for example based on per-VLAN or per-class basis. This being said, mixing PAUSE functionality with per-class services was impossible - it would stop sending of all traffic, regardless of QoS marking. This is why it's typically advised to turn off 802.3X flow control whether you enable MLS QoS on a Cisco switch be it 3550 or 3560. By default flowcontrol is disabled and you can only enable a Cisco switch to receive PAUSE frames, but not to send them.

Use the following commands to set up and verify your current flow-control settings:

SW1:
interface GigabitEthernet0/1
flowcontrol receive on

giga1-sw-ats64#show interfaces gigabitEthernet 0/1 flowcontrol
Port Send FlowControl Receive FlowControl RxPause TxPause
admin oper admin oper
--------- -------- -------- -------- -------- ------- -------
Gi0/1 Unsupp. Unsupp. on on 0 0

Even though the simple 802.3X flow-control idea did not work out well, the evolving body of DCB (data-center bridging) standards uses similar, yet more granular mechanism to implement lossless Ethernet transmissions. Lossless Ethernet is important for storage transportation protocols such as FCoE and is one of the cornerstones of the evolving data-center Ethernet standard.

Jul

UDLD Modes of Operation

14 Comments

Posted by Petr Lapukhov, 4xCCIE/CCDE in 3550, 3560, CCIE R&S, stp, Switching, udld

UDLD (Unidirectional Link Detection) is Cisco proprietary extension for detecting a mis-configured link. The idea behind it is pretty strighforward - allow two switches to verify if they can both send and receive data on a point-to-point connection. Consider a network with two switches, A and B connected by two links: "A=B". Naturally, if "A" is the root of spanning tree, one of the ports on "B" will be blocking, constantly receiving BPDUs from "A". If this link would turn uni-directional and "B" would start missing those BPDUs, the port will eventually unblock, forming a loop betwen "A" and "B". Note that the problem with unidirectional links usually occurs on fiber-optical connections and is not common on UTP (wired) connections, where link pulses are used to monitor the connection integrity.

The confusion about UDLD is that Cisco provides quite unclear description of the feature operations be it on CatOS or IOS platform. So here is a short overview of how UDLD works.

1) Both UDLD peers (switches) discover each other by exchanging special frames sent to well-known MAC address 01:00:0C:CC:CC:CC. (Naturally, those frames are only understood by Cisco switches). Each switch sends it's own device ID along with the originator port ID and timeout value to it's peer. Additionally, a switch echoes back the ID of it's neighbor (if the switch does see the neighbor). Since some versions of CatOS and IOS you can change UDLD timers globally.

2) If no echo frame with our ID has been seen from the peer for a certain amount of time, the port is suspected to be unidirectional. What happens next depends on UDLD mode of operations.

3) In "Normal" mode, if the physical state of port (as reported by Layer 1) is still up, UDLD marks this port as "Undetermined", but does NOT shut down or disable the port, which continues to operate under it's current STP status. This mode of operations is informational and potentially less disruptive (though it does not prevent STP loops). You can review the "undetermined" ports using CLI show commands when troubleshooting the STP issues though.

3) If UDLD is set to "Agressive" mode, once the switch loses it's neighbor it actively tries to re-establish the relationship by sending a UDLD frame 8 times every 1 second (surpisingly this coincides with TCP keepalives retry values used by FCIP on Cisco MDS storage switches :). If the neighbor does not respond after that, port is considered to be unidirectional and brought to "Errdisable" state. (Note that you can configure "errdisable recovery" to make switch automatically recover from such issues)

4) UDLD "Aggressive" will only brings link to errdisable state when it detects "Bidirectional" to "Unidirectional" state transition. In order for a link to become "Bidirectional", UDLD process should first hear an echo packet with it's own ID from a peer on the other side. This prevents link from becoming errdisabled when you configure "Aggressive" mode just on one side. The UDLD state of such link will be "Unknown".

5) UDLD "Aggressive" inteoperates with UDLD "Normal" on the other side of a link. This type of configuration means that just one side of the link will be errdisabled once "Unidirectional" condition has been detected.

To complete this overview, remember that UDLD is designed to be a helper for STP. Therefore, UDLD should be able to detect an unidirectional link before STP would unblock the port due to missed BPDUs. Thus, when you configure UDLD timers, make sure your values are set so that unidirectional link is detected before "STP MaxAge + 2xForwardDelay" expires. Additionally, notice that UDLD function is similar to STP Loopguard and Bridge Assurance feature found in newer switches. The benefit of UDLD is that it operates at physical port-level, whereas STP may not be able to detect a malfunctioning link bundled in an Etherchannel. This is why you normally use all features together - they don't replace but truly complement each other.

Jun

Quick Notes on the 3560 Egress Queuing

19 Comments

Posted by Petr Lapukhov, 4xCCIE/CCDE in 3560, example, policing, QoS, queuing, shaping, srr, Switching, weights

The goal of this article is to discuss how would the following configuration work in the 3560 series switches:

interface FastEthernet0/13

 switchport mode access

 load-interval 30

 speed 10

 srr-queue bandwidth shape 50 0 0 0

 srr-queue bandwidth share 33 33 33 1

 srr-queue bandwidth limit 20

Before we begin, let’s recap what we know so far about the 3560 egress queuing:

1) When SRR scheduler is configured in shared mode, bandwidth allocated to each queue is based on relative weight. E.g. when configuring "srr-queue bandwidth share 30 20 25 25" we obtain the weight sum as 30+20+25+25 = 100 (could be different, but it’s nice to reference to “100”, as a representation of 100%). Relative weights are therefore “30/100”, “20/100”, “25/100”, “25/100” and you can calculate the effective bandwidth *guaranteed* to a queue multiplying this weight by the interface bandwidth: e.g. 30/100*100Mbps = 30Mbps for the 100Mbps interface and 30/100*10Mbps=3Mbps for 10Mbps interface. Of course, the weights are only taken in consideration when interface is oversubscribed, i.e. experiences a congestion.

2) When configured in shaped mode, bandwidth restriction (policing) for each queue is based on inverse absolute weight. E.g. for “srr-queue bandwidth shape 30 0 0 0” we effectively restrict the first queue to “1/30” of the interface bandwidth (which is approximately 3,3Mbps for 100Mbps interface and approximately 330Kbps for a 10Mbps interface). Setting SRR shape weight to zero effectively means no shaping is applied. When shaping is enabled for a queue, SRR scheduler does not use shared weight corresponding to this queue when calculating relative bandwidth for shared queues.

3) You can mix shaped and shared settings on the same interface. For example two queues may be configured for shaping and others for sharing:

interface FastEthernet0/13

 srr-queue bandwidth share 100 100 40 20

 srr-queue bandwidth shape  50  50  0  0

Suppose the interface rate is 100Mpbs; then queues 1 and 2 will get 2 Mbps, and queues 3 and 4 will share the remaining bandwidth (100-2-2=96Mbps) in proportion “2:1”. Note that queues 1 and 2 will be guaranteed and limited to 2Mbps at the same time.

4) The default “shape” and “share” weight settings are as follows: “25 0 0 0” and “25 25 25 25”. This means queue 1 is policed down to 4Mbps on 100Mpbs interfaces by default (400Kbps on 10Mbps interface) and the remaining bandwidth is equally shared among the other queues (2-4). So take care when you enable “mls qos” in a switch.

5) When you enable “priority-queue out” on an interface, it turns queue 1 into priority queue, and scheduler effectively does not account for the queue’s weight in calculations. Note that PQ will also ignore shaped mode settings as well, and this may make other queues starve.

6) You can apply “aggregate” egress rate-limitng to a port by using command “srr-queue bandwidth limit xx” at interface level. Effectively, this command limits interface sending rate down to xx% of interface capacity. Note that range starts from 10%, so if you need speeds lower than 10Mbps, consider changing port speed down o 10Mbps.

How will this setting affect SRR scheduling? Remember, that SRR shared weights are relative, and therefore they will share the new bandwidth among the respective queues. However, shaped queue rates are based on absolute weights calculated off interface bandwidth (e.g. 10Mbps or 100Mbps) and are subtracted from interface “available” bandwidth. Consider the example below:

interface FastEthernet0/13

 switchport mode access

 speed 10

 srr-queue bandwidth shape 50 0 0 0

 srr-queue bandwidth share 20 20 20 20

 srr-queue bandwidth limit 20

Interface sending rate is limited to 2Mbps. Queue 1 is shaped to 1/50 of 10Mps, which is 200Kbps of bandwidth. The remaining bandwidth 2000-200=1800Kbps is divided equally among other queues in proportion 20:20:20=1:1:1. That is, in case on congestion and all queues filled up, queue 1 will get 200Kbps, and queues 2-4 will get 600Kbps each.

Quick Questions and Answers

Q: How would I determine which queue will the packet go to? What if my packet has a CoS and DSCP value set at the same time?
A: That depends on what you are trusting at classification stage. If you trust CoS value, then QoS to Output Queue map will be used. Likewise, if you trust DSCP value, then DSCP to Output Queue map will determine the outgoing queue. Use “show mls qos map” commands to find out the current mappings.

Q: What if I’ve configured “shared” and “shaped” srr-queue settings for the same queue?
A: The shaped queue settings will override shared weight. Effectively, shared weight will also be exempted from SRR calculations. Note that in shaped mode queue is still guaranteed it’s bandwidth, but at the same time is not allowed to send above the limit.

Q: What if priority-queue is enabled on the interface? Can I restrict the PQ sending rate using “shaped” weight?
A: No you can’t. Priority-queue will take all the bandwidth if needed, so take care with traffic admission.

Q: How will a shaped queue compete with shared queues on the same interface?
A: Shared queues share the bandwidth remaining from the shaped queues. At the same time, shaped queues are guaranteed the amount of bandwidth allowed by their absolute weight.

Q: How is SRR shared mode different from WRR found in the Catalyst 3550?
A: SRR in shared mode essentially behaves similar to WRR, but is designed to be more efficient. Where WRR would empty the queue up to it’s credit in single run, SRR will take series of quick runs among all the queues, providing more “fair” share and smoother traffic behavior.

Verification scenario diagram and configs

For the lab scenario, we configure R1, R3 and R5 to send traffic down to R2 across two 3560 switches saturating the link between them. All routers share one subnet 172.16.0.X/24 where X is the router number. SW1 will assign CoS/IP Precedence values of 1, 3 and 5 respectively to traffic originated by R1, R3 and R5. At the same time, SW1 will apply egress scheduling on it’s connection to SW2. R2’s function is to meter the incoming traffic, by matching the IP precedence values in packets. Note that SW2 has mls qos disabled by default.

We will use the default CoS to Output Queue mappings with CoS 1 mapped to Queue 2, CoS 3 mapped to Queue 3 and CoS 5 mapped to Queue 1. Note that by the virtue of the default mapping tables, CoS 0-7 map to IP Precedence 0-7 (which become overwritten), so we can match IP precedence’s on R2.

SW1#show mls qos maps cos-output-q

   Cos-outputq-threshold map:

              cos:  0   1   2   3   4   5   6   7

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

  queue-threshold: 2-1 2-1 3-1 3-1 4-1 1-1 4-1 4-1

SW1’s connection to SW2 is set to 10Mbps port rate, and further limited down to 2Mps by the use of “srr bandwidth limit” command. We will apply different scenarios and see how SRR behaves. Here comes the configurations for SW1 and R2:

SW1:

interface FastEthernet0/1

 switchport mode access

 load-interval 30

 mls qos cos 1

 mls qos trust cos

 spanning-tree portfast

!

interface FastEthernet0/3

 switchport mode access

 load-interval 30

 mls qos cos 3

 mls qos trust cos

 spanning-tree portfast

!

interface FastEthernet0/5

 load-interval 30

 mls qos cos 5

 mls qos trust cos

 spanning-tree portfast
R2:

class-map match-all PREC5

 match ip precedence 5

class-map match-all PREC1

 match ip precedence 1

class-map match-all PREC3

 match ip precedence 3

!

!

policy-map TEST

 class PREC5

 class PREC3

 class PREC1

!

access-list 100 deny   icmp any any

access-list 100 permit ip any any

!

interface FastEthernet0/0

 ip address 172.16.0.2 255.255.255.0

 ip access-group 100 in

 load-interval 30

 duplex auto

 speed auto

 service-policy input TEST

To simulate traffic flow we execute the following command on R1, R3 and R5:

R1#ping 172.16.0.2 repeat 100000000 size 1500 timeout 0

In the following scenarios port speed is locked to 10Mbps and additionally port is limited to 20% of the bandwidth, with the effective sending rate of 2Mbps.

First scenario: Queue 1 (prec 5) is limited to 200Kbps while Queue 2 (prec 1) and Queue 3 (prec 3) share the remaining bandwidth in equal proportions:

SW1:
interface FastEthernet0/13
switchport mode access
load-interval 30
speed 10
srr-queue bandwidth share 33 33 33 1
srr-queue bandwidth shape 50 0 0 0
srr-queue bandwidth limit 20

R2#sh policy-map interface fastEthernet 0/0 | inc bps|Class
Class-map: PREC5 (match-all)
30 second offered rate 199000 bps
Class-map: PREC3 (match-all)
30 second offered rate 886000 bps
Class-map: PREC1 (match-all)
30 second offered rate 887000 bps
Class-map: class-default (match-any)
30 second offered rate 0 bps, drop rate 0 bps

Second Scenario: Queue 1 (prec 5) is configured as priority and we see it leaves other queues starving for bandwidth:

SW1:
interface FastEthernet0/13
switchport mode access
load-interval 30
speed 10
srr-queue bandwidth share 33 33 33 1
srr-queue bandwidth shape 50 0 0 0
srr-queue bandwidth limit 20
priority-queue out

R2#sh policy-map interface fastEthernet 0/0 | inc bps|Class
Class-map: PREC5 (match-all)
30 second offered rate 1943000 bps
Class-map: PREC3 (match-all)
30 second offered rate 11000 bps
Class-map: PREC1 (match-all)
30 second offered rate 15000 bps
Class-map: class-default (match-any)
30 second offered rate 0 bps, drop rate 0 bps

Third Scenario: Queues 1 (prec 5) and 2 (prec 1) are shaped to 200Kbps, while Queue 3 (prec 3) takes all the remaining bandwidth:

SW1:
interface FastEthernet0/13
switchport mode access
load-interval 30
speed 10
srr-queue bandwidth share 33 33 33 1
srr-queue bandwidth shape 50 50 0 0
srr-queue bandwidth limit 20

R2#sh policy-map interface fastEthernet 0/0 | inc bps|Class
Class-map: PREC5 (match-all)
30 second offered rate 203000 bps
Class-map: PREC3 (match-all)
30 second offered rate 1569000 bps
Class-map: PREC1 (match-all)
30 second offered rate 199000 bps
Class-map: class-default (match-any)
30 second offered rate 0 bps, drop rate 0 bps

Mar

Bridging the gap between 3550 and 3560 QoS: Part I

21 Comments

Posted by Petr Lapukhov, 4xCCIE/CCDE in 3550, 3560, catalyst-qos, CCIE R&S, features, mapping, per-vlan, policing, QoS, queuing, srr, Switching

The 3560 QoS processing model is tightly coupled with it’s hardware architecture borrowed from the 3750 series switches. The most notable feature is the internal switch ring, which is used for the switch stacking purpose. Packets entering a 3560/3750 switch are queued and serviced twice: first on the ingress, before they are put on the internal ring, and second on the egress port, where they have been delivered by the internal ring switching. In short, the process looks as follows:

[Classify/Police/Mark] -> [Ingress Queues] -> [Internal Ring] -> [Egress Queues]

For more insights and detailed overview of StackWise technology used by the 3750 models, visit the following link:

Cisco StackWise Technology White Paper

Next, it should be noted that the 3560 model is capable of recognizing and processing IPv6 pacekts natively – this feature affects some classification options. Another big difference is the absence of internal DSCP value and the use of QoS label for internal packet marking. This feature allows the 3560 switches to provide different classes of services to CoS or DSCP marked packets, by allowing them to be mapped to different queues/thresholds etc. Many other concepts and commands are different as well, as is some nomenclature (e.g. the number of the priority queue). We will try to summarize and analyze the differences under the following paragraphs. The biggest obstacle is absence of any good information source on the 3750/3560 switches QoS, besides the Cisco Documentation site, which has really poor documents regarding both models.

1. Queue Scheduler: SRR

One significant change is replacement of WRR scheduler with SRR, where latter stands for either Shared Round Robin or Shaped Round Robin – which are two different modes of operation for the scheduler. As we remember, what WRR does is simply de-queue the number of packets proportional to the weight assigned to a queue walking through queues in round-robin fashion. SRR performs similar in shared more: each output queue has a weight value assigned, and is serviced in proportion to the assigned weight when interface is under congestion.

The implementation details are not documented to open public by Cisco; however, so far we know that Shared Round Robin tries to behave more “fairly” than WRR does. While on every scheduler round WRR empties each queue up to the maximum number of allowed packet, before switching to the next queue, SRR performs a series of quick runs each round, deciding on whether to de-queue a packet from the particular queue (based on queue weights). In effect, SRR achieves more “fairness” on per-round basis, because it does not take the whole allowed amount each time it visits a queue. On the “long run” SRR and WRR behave similarly.

The shaped mode of SRR is something not available with WRR at all. With this mode, each queue has weight that determines the maximum allowed transmission rate for a queue. That is, interface bandwidth is divided in proportions of queue weights, and each queue is not allowed to send packets above this “slice” of common bandwidth. The details of the implementation are not provided, so we can only assume it’s some kind of effective policing strategy. Pay special attention, that SRR weight values are *absolute*, not relative. That is, the proportion of interface bandwidth give to a particular queue is "1/weight*{interface speed}. So for a weight of "20" the limit is "1/20*Speed" and equals to 5Mbps with 100Mbps interface. Also, by default, queue 1 has SRR shaped weight 1/25, so take care when you turn MLS QoS on.

An interface could be configured for SRR shared and shaped mode at the same time. However, SRR shaped mode always take preference over SRR shared weights. Finally, SRR provides support for priority queue but this queue is not subject to SRR shaping limits as well. The weight assigned to the priority queue is simply ignored for SRR calculations. Note that unlike the 3550, on the 3560, egress priority queue has queue-id 1, not 4. Here is an example:

!

!  By settings shape weight to zero we effectively disable shaping for the particular queue

!

interface gigabitethernet0/1

 srr-queue bandwidth shape 10 0 0 0

 srr-queue bandwidth share 10 10 60 20

 !

 !  As expedite queue (queue-id 1) is enabled, it’s weight is no longer honored by the SRR scheduler

 !

 priority-queue out

Another interesting egress feature is port rate-limit. SRR could be configured to limit the total port bandwidth to a percentage of physical interface speed – from 10% to 90%. Don’t configure this feature if there is no need to limit overall port bandwidth.

!

! Limit the available egress bandwidth to 80% of interface speed

!

interface gigabitethernet0/1

 srr-queue bandwidth limit 80

Note that the resulting port rate depends on the physical speed of the port - 10/100/1000Mbps.

2. Egress Queues

The 3550 has four egress queues identified by their numbers 1-4 available to every interface,. Queue number 4 could be configured as expedite. On the 3560 side, we have the same four egress queues, but this time for expedite services we could configure queue-id 1.

With the 3550, for “class-to-queue” mapping only CoS to queue-id table is available on a per-port basis. Globally configurable DSCP to CoS mapping table is used to map an internal DSCP value to the equivalent CoS. As for the 3560 model, DSCP and CoS values are mapped to queue-ids separately. That means IP and non-IP traffic could be mapped/serviced separately. What if an IP packet comes with DSCP and CoS values both set? Then the switch will use the marking used for classification (e.g. CoS if trust cos or set cos were used) to assign the packet to a queue/threshold.

The 3550 supports WTD and WRED as queue drop strategy (the latter option available on Gigabit ports only). The 3560 model supports WTD as the only drop strategy, allowing for three per-queue drop thresholds. Only two of the thresholds are configurable – called explicit drop thresholds - and the third one is fixed to mark the full queue state (implicit threshold).

Finally, the mentioned mappings are configured for queue-id and drop threshold simultaneously in global configuration mode - unlike the 3550 where you configured CoS to Queue-ID and DSCP to Drop-Threshold mappings separately (and on per-interface basis).

!
! CoS values are mapped to 4 queues. Remember queue-id 1 could be set as expedite
!

!
! The next entry maps CoS value 5 to queue 1 and threshold 3 (100%)
!
mls qos srr-queue output cos-map queue 1 threshold 3 5
!
! VoIP signaling and network management traffic go to queue 2
!
mls qos srr-queue output cos-map queue 2 threshold 3 3 6 7
mls qos srr-queue output cos-map queue 3 threshold 3 2 4
mls qos srr-queue output cos-map queue 4 threshold 2 1
mls qos srr-queue output cos-map queue 4 threshold 3 0

!
! DSCP to queue/threshold mappings
!
mls qos srr-queue output dscp-map queue 1 threshold 3 40 41 42 43 44 45 46 47

mls qos srr-queue output dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31
mls qos srr-queue output dscp-map queue 2 threshold 3 48 49 50 51 52 53 54 55
mls qos srr-queue output dscp-map queue 2 threshold 3 56 57 58 59 60 61 62 63

mls qos srr-queue output dscp-map queue 3 threshold 3 16 17 18 19 20 21 22 23
mls qos srr-queue output dscp-map queue 3 threshold 3 32 33 34 35 36 37 38 39

!
! DSCP 8 is CS1 – Scavenger class, mapped to the first threshold of the last queue
!
mls qos srr-queue output dscp-map queue 4 threshold 1 8
mls qos srr-queue output dscp-map queue 4 threshold 2 9 10 11 12 13 14 15
mls qos srr-queue output dscp-map queue 4 threshold 3 0 1 2 3 4 5 6 7

Next, what we need to know is how to configure egress queue buffer spaces along with the threshold settings. With the 3550 we had two options: first, globally configurable buffer levels for FastEthernet ports, assigned per interface; second, one shared buffer pool for each of gigabit ports, with proportions (weights) configured on per-interface level too. With the 3560 things have been changed. Firstly, all ports are now symmetrical in their configurations. Secondly, a concept of queue-set has been introduced. A queue-set defines buffer space partition scheme as well as threshold levels for each of four queues. Only two queue-set are available in the system, and are configured globally. After a queue-set has been defined/redefined it could be applied to an interface. Of course, default queue-set configurations exist as well.

As usual, queue thresholds are defined in percentage of the allocated queue memory (buffer space). However, the 3560 switch introduced another buffer pooling model. There exist two buffer pools – reserved and common. Each interface has some buffer space allocated under the reserved pool. This reserved buffer space, allocated to an interface, could be partitioned between egress interface queues, by assigning a weight value (this resembles the gigabit interface buffer partitioning with the 3550):

!

! Queue-sets have different reserved pool partitioning schemes

!  Each of four queues is given a weight value to allocate some reserved buffer space

!

mls qos queue-set output 1 buffers 10 10 26 54

mls qos queue-set output 2 buffers 16 6 17 61

!

interface gigabitEthernet 0/1

 queue-set 1

What about the common buffer pool? Let’s take a look at the threshold setting command first:

mls qos queue-set output qset-id threshold queue-id drop-threshold1 drop-threshold2 reserved-threshold maximum-threshold

We see two explicitly configured thresholds 1 and 2 – just as with the 3550. However, there is one special threshold called reserved-threshold. What it does, is specifies how much of reserved buffer space is allocated to a queue – i.e. how much of reserved buffers are actually “reserved”. As we know, with the 3560 model every queue on every port has some memory allocated under reserved buffer pool. The reserved-threshold tells how much of this memory to allocate to a queue – from 1 to 100%. The unused amount of the reserved buffer space becomes available to over queues under the common buffer pool mentioned above. The common buffer pool could be used by any queue to borrow buffers above the queue’s reserved space. That allows to set drop-thresholds to values greater than 100%, meaning it’s allowable for queue to take more credit from common pool to satisfy it needs. The maximum-threshold specifies the “borrowing limit” – how much a queue is allowed to grow into the common pool.

Look at the command “mls qos queue-set output 1 threshold 1 138 138 92 138”. It says we shrink reserved buffer space for queue 1 to 92% sending the exceeding space to common pool. All the three drop-thresholds are set to 138% of the queue buffer space (allocated by buffer command), meaning we allow the queue to borrow from the common pool up to the levels specified. Drop thresholds may be set as large as 400% of the configured queue size.

Now we see that this model is a bit more complicated than it was with the 3550. We don’t know the actual sizes of reserved buffer pool, but we are allowed to specify the relative importance of each queue. Additionally, we may give up some reserved buffer space out to a common buffer pool to share with the other queues. Here is a detailed example from AutoQoS settings:

!
! Set thresholds for all four queues in queue-set 1
!
mls qos queue-set output 1 threshold 1 138 138 92 138
mls qos queue-set output 1 threshold 2 138 138 92 400
mls qos queue-set output 1 threshold 3 36 77 100 318
mls qos queue-set output 1 threshold 4 20 50 67 400

!
! Set thresholds for all four queues in queue-set 2
!
mls qos queue-set output 2 threshold 1 149 149 100 149
mls qos queue-set output 2 threshold 2 118 118 100 235
mls qos queue-set output 2 threshold 3 41 68 100 272
mls qos queue-set output 2 threshold 4 42 72 100 242

interface gigabitEthernet 0/1
queue-set 1
!
interface gigabitEthernet 0/2
queue-set 2

An finally, if you are not sure what you’re doing, don’t play with thresholds and buffer space partitioning – leave the to the default values, or use AutoQoS recommendations. So says the DocCD!

3. Ingress Queues

The unique feature of the 3560 switches is possibility to configure two ingress queues on every port. Of these queues, you may configure any to be an expedite queue, with queue 2 being the default. The priority queue is guaranteed access to the internal ring when the ring is congested. SRR only serves the ingress queues in shared mode. All the weights are configured globally, not per-interface as it was with the egress queues:

!

! Disable the default priority queue and share the bandwidth on the ring in 1/4 proportion

!

mls qos srr-queue input priority-queue 2 bandwidth 0

mls qos srr-queue input bandwidth 25 75

The UniverCD has a very shallow description of how actually SRR algorithm serves the two queues, when one of them is configured as expedite. So far, it looks like that you should configure one queue as expedite, assign the priority bandwidth value to it (from 1 to 40% of the internal ring bandwidth), and also assign the bandwidth values to both of the ingress queues as usual:

mls qos srr-queue input priority-queue 1 bandwidth 10

mls qos srr-queue input bandwidth 50 50

What’s that supposed to mean? Seems like queue 1 is partially serviced as an expedite queue, up the limit set by priority-queue bandwidth. As this counter exhausts, it is then being served on par with the non-expedite queue, using the bandwidth weights assigned. With the example about that mean we have 10% of bandwidth dedicated to priority queue services. As soon as this counter exhausts (say on a per-round basis) SRR continues to service both ingress queues using the remaining bandwidth counter (90%) shared in the proportions of the weights assigned (50 & 50) – that means 45% of the ring bandwidth to each of the queues. Overall, it looks like SRR simulates a policer for priority queue, but rather than dropping the traffic it simply changes the scheduling mode, until enough credits are accumulated to start expedite services again. Now go figures how to use that in real life! Too bad Cisco does no give out to public any internal details on their SRR implementation.

Now, two things remain to consider for the ingress queues: class mappings to the queues, and buffer/threshold settings. The class mapping uses the same syntax as for the egress queues, allowing configuring global mapping of CoS and DSCP do queue-ids and thresholds.

!
! CoS to queue-id/threshold
!
mls qos srr-queue input cos-map queue 1 threshold 3 0
mls qos srr-queue input cos-map queue 1 threshold 2 1
mls qos srr-queue input cos-map queue 2 threshold 1 2
mls qos srr-queue input cos-map queue 2 threshold 2 4 6 7
mls qos srr-queue input cos-map queue 2 threshold 3 3 5

!
! DSCP to queue-id/threshold
!
mls qos srr-queue input dscp-map queue 1 threshold 2 9 10 11 12 13 14 15
mls qos srr-queue input dscp-map queue 1 threshold 3 0 1 2 3 4 5 6 7
mls qos srr-queue input dscp-map queue 1 threshold 3 32
mls qos srr-queue input dscp-map queue 2 threshold 1 16 17 18 19 20 21 22 23
mls qos srr-queue input dscp-map queue 2 threshold 2 33 34 35 36 37 38 39 48
mls qos srr-queue input dscp-map queue 2 threshold 2 49 50 51 52 53 54 55 56
mls qos srr-queue input dscp-map queue 2 threshold 2 57 58 59 60 61 62 63
mls qos srr-queue input dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31
mls qos srr-queue input dscp-map queue 2 threshold 3 40 41 42 43 44 45 46 47

As it seems reasonable, the classification option (CoS, DSCP) used determines that mapping table for ingress queue.

The buffer partitioning is pretty simple – there is no common pool, and you only specify the relative weight for every queue. Thresholds are also simplified – you configure just two too of them, in percentage of queue size. The third threshold is implicit, as usual.

!

!  Thresholds are set to 8% and 16% for queue 1; 34% and 66% for queue-2 

!  Buffers are partitioned in 67/33 proportion

!

mls qos srr-queue input threshold 1 8 16

mls qos srr-queue input threshold 2 34 66

mls qos srr-queue input buffers 67 33

So far we covered enough for a single post. In the next post we will discuss how classification policing and marking techniques differ between the 3550 and 3560 models.

Jan

Understanding Private VLANs

44 Comments

Posted by Petr Lapukhov, 4xCCIE/CCDE in 3550, 3560, Advanced Security, arp, association, ccie, CCIE R&S, CCIE Security, community, isolated, mapping, private-vlan, promiscuous, Switching

You may want to see the updated version of this post at:

http://blog.internetworkexpert.com/2008/07/14/private-vlans-revisited/

---

Private VLAN concepts are quite simple, but Cisco's implemenation and configuration steps are a bit confusing - with all the "mappings" and "associations" stuff. Here comes a short overview of how private VLANs work.

To begin with, let's look at the concept of VLAN as a broadcast domain. What Private VLANs (PVANs) do, is split the domain into multiple isolated broadcast subdomains. It's a simple nesting concept - VLANs inside a VLAN. As we know, Ethernet VLANs are not allowed to communicate directly, they need L3 device to forward packets between broadcast domains. The same concept applies to PVLANS - since the subdomains are isolated at level 2, they need to communicate using an upper level (L3 and packet forwarding) entity - such as router. However, there is difference here. Regular VLANs usually correspond to a single IP subnet. When we split VLAN using PVLANs, hosts in different PVLANs still belong to the same IP subnet, but they need to use router (another L3 device) to talk to each other (for example, by means of local Proxy ARP). In turn, router may either permit or forbid communications between sub-VLANs using access-lists.
Why would anyone need Private VLANs? Commonly, this kind of configurations arise in "shared" environments, say ISP co-location, where it's beneficial to put multiple customers into the same IP subnet, yet provide a good level of isolation between them.

For our sample configuration, we will take VLAN 100 and divide it into two PVLANs - sub-VLANs 101 and 102. Take the regular VLAN and call it primary (VLAN 100 in our example), then divide ports, assigned to this VLAN, by their types:

Promiscuous (P): Usually connects to a router - a type of a port which is allowed to send and receive frames from any other port on the VLAN
Isolated (I): This type of port is only allowed to communicate with P-ports - they are "stub". This type of ports usually connects to hosts
Community (C): Community ports are allowed to talk to their buddies, sharing the same group (of course they can talk to P-ports)

In order to implement sub-VLAN behavior, we need to define how packets are forwarded between different port types. First comes the Primary VLAN - simply the original VLAN (VLAN 100 in our example). This type of VLAN is used to forward frames downstream from P-ports to all other port types (I and C ports). In essense, Primary VLAN entails all port in domain, but is only used to transport frames from router to hosts (P to I and C). Next comes Secondary VLANs, which correspond to Isolated and Community port groups. They are used to transport frames in the opposite direction - from I and C ports to P-port.

Isolated VLAN: forwards frames from I ports to P ports. Since Isolated ports do not exchange frames with each other, we can use just ONE isolated VLAN to connect all I-Port to the P-port.
Community VLANs: Transport frames between community ports (C-ports) within to the same group (community) and forward frames uptstream to the P-ports of the primary VLAN.

This is how it works:

Primary VLANs is used to deliver frames downstream from router to all hosts; Isolated VLAN transports frames from stub hosts upstream to the router; Community VLANs allow frames exchange withing a single group and also forward frames in upstream direction towards P-port. All the basic MAC address learning and unknown unicast flooding princinples remain the same.

Let's move to the configuration part (Primary VLAN 100, Isolated VLAN 101 and Community VLAN 102).

Step 1:

Create Primary and Secondary VLANs and group them into PVLAN domain:

!
! Creating VLANs: Primary, subject to subdivision
!
vlan 100
private-vlan primary

!
! Isolated VLAN: Connects all stub hosts to router
!
vlan 101
private-vlan isolated

!
! Community VLAN: allows a subVLAN within a Primary VLAN
!
vlan 102
private-vlan community

!
! Associating
!
vlan 100
private-vlan assoc 101,102

What this step is needed for, is to group PVLANs into a domain and establish a formal association (for syntax checking and VLAN type verifications).

Step 2:

Configure host ports and bind them to the respective isolated PVLANs. Note that a host port belongs to different VLANs at the same time: downstream primary and upstream secondary.

!
! Isolated port (uses isoalated VLAN to talk to P-port)
!
interface FastEthernet x/y
switchport mode private-vlan host
switchport private-vlan host-association 100 101

!
! Community ports: use community VLAN
!
interface range FastEthernet x/y - z
switchport mode private-vlan host
switchport private-vlan host-association 100 102

Step 3:

Create a promiscuous port, and configure downstream mapping. Here we add secondary VLANs for which traffic is received by this P-port. Primary VLAN is used to send traffic downstream to all C/I ports as per their associations.

!

! Router port

!

interface FastEthernet x/y

 switchport mode private-vlan promisc

 switchport private-vlan mapping 100 add 101,102

if you need to configure an SVI on the switch, you should add an interface correspoding to Primary VLAN only. Obviously that's because of all secondary VLANs being simply "subordiantes" of primary. In our case the config would look like this:

interface Vlan 100

 ip address 172.16.0.1 255.255.255.0

Lastly, there is another feature, worths to be mentioned, called protected port or Private VLAN edge. The feature is pretty basic and avaiable even on low-end Cisco switches, allows to isolate ports in the same VLAN. Specifically, all ports in a VLAN, marked as protected are prohibited from sending frames to each other (but still allowed to send frames to other (non-protected) ports within the same VLAN). Usually, ports configurated as protected, are also configured not to receive unknown unicast (frame with destination MAC address not in switch's MAC table) and multicast frames flooding for added security.

Example:

interface range FastEthernet 0/1 - 2

 switchport mode access

 switchport protected

 switchport block unicast

 switchport block multicast

How well do you know VTP?

And the correct answer is:

Traffic Classification in the 3550/3560 Switches

Comparing Traffic Policing Features in the 3550 and 3560 switches

Private VLANs Revisited

Introduction

Private VLANs Terminology

How Private VLANs Work

Configuring Private VLANs

802.3x Flow-Control

UDLD Modes of Operation

Quick Notes on the 3560 Egress Queuing

Quick Questions and Answers

Verification scenario diagram and configs

Bridging the gap between 3550 and 3560 QoS: Part I

Understanding Private VLANs

Subscribe to INE Blog Updates

New Blog Posts!

Questions? Contact a Training Specialist

Resources

Let's talk!

+1-877-224-8987

+1-775-826-4344 (Outside US)

Connect with INE

And the correct answer is:

Introduction

Private VLANs Terminology

How Private VLANs Work

Configuring Private VLANs

Quick Questions and Answers

Verification scenario diagram and configs

Subscribe to INE Blog Updates

New Blog Posts!

Questions? Contact a Training Specialist

Resources

Let's talk!

+1-877-224-8987

+1-775-826-4344 (Outside US)

Connect with INE

BE IN THE KNOW