CCIE Blog

Classification, Policing and Marking on the 3560 model.

As we remember, 3560 uses the concept of internal QoS label, which contains both the CoS and DSCP values for a packet. Only one value is actually taken (trusted) from the packet or interface (either CoS or DSCP), and the other one is deduced using the configurable mapping tables. As it has been described previously, we are allowed to map CoS/DSCP values to queues/thresholds separately. This allows for different service policies to be configured with respect to non-IP and IP traffic. The value that has been trusted (CoS/DSCP) is used as the key selector to either the CoS or DSCP based mapping tables.

What are the available classification options? You can match an access-list (MAC, IP or IPv6), an input interface (only for hierarchical policy-maps to be discussed later) and IP DSCP or Precedence values. Note that CoS value could not be matched, you may configure to trust them. You can trust either CoS, DSCP or IP precedence values from IP/IPv6 or non-IP packet. If a packet has no CoS assigned, the default CoS value is set when interface is set to trust CoS.

Now for the “set” operation – you can only set either IP/IPv6 DSCP or Precedence fields, but not CoS field directly. Does that mean we are not allowed to change the CoS value? No, it is still possible to change the CoS value by using “set dscp” command and DSCP to CoS mapping table – the indirect way. This is a way to extend DSCP-based operations to CoS only bearing packets by use of mapping tables. For example the following configuration will change CoS value of any non-IP packet to “5” (equivalent to DSCP EF):

!
! Match any ether-type, e.g. IPX packets
!
mac access-list extended TEST
 permit any any 0x0 0xFFFF
!
class-map match-all TEST
  match access-group name TEST

!
! Match the Non-IP packets and set DSCP value
!
policy-map TEST
  class TEST
   set dscp ef

!
! Connected to R1
!
interface FastEthernet 0/1
 service-policy input TEST

Verification – configure IPX on R1 and R3, e.g. using the IPX network “135” and SNAP encapsulation.

Rack21R1#ping 135.0011.920e.5620
Type escape sequence to abort.
Sending 5, 100-byte IPX Novell Echoes to 135.0011.920e.5620, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

Rack21SW1#show mls qos interface fastEthernet 0/3 statistics
FastEthernet0/3

  cos: incoming
——————————-

  0 -  4 :         175            0            0            0            0
  5 -  7 :           0            0            0
  cos: outgoing
——————————-

  0 -  4 :         664            0            0            0           11
  5 -  7 :           5            0            1
Policer: Inprofile:            0 OutofProfile:            0

For example, with policer markdown action, we use the configurable mapping table to map DSCP value to a new policed-down equivalent. When the markdown action is applied to a CoS-marked packet (non-IP) the CoS-to-DSCP mapping table is used to deduce the DSCP value, then the other table (DSCP to Policed DSCP) is used mark the DSCP value down, and finally the marked-down DSCP value is mapped back to the CoS value (DSCP to CoS map).

!
! DSCP to Policed-DSCP map
!
mls qos map policed-dscp 0 to 8

!
! Match the Non-IP packets and set DSCP value
!
policy-map TEST
  class TEST
   police 64000 8000 exceed policed
!
! Connected to R1
!
interface FastEthernet 0/1
 service-policy input TEST

As with the 3550 model, 3560 allows policers to be applied ingress on any port. The limit is 64 policers per port ingress, and 256 policers per ASIC. However, no egress policers are available on this platform. Aggregate policers could also be configured, with the same restrictions as the 3550 had.

Another feature, known on the 3550 models as the Per-Port Per-VLAN classification is implemented using the hierarchical policy-maps. The concept is better illustrated using an example:

!
!  Any non-IP traffic
!
mac access-list extended MAC_ANY
 permit any any 0x0 0xFFFF

!
! Any IP traffic
!
ip access-list extended IP_ANY
 permit ip any any

!
! Class for any non-IP traffic
!
class-map MAC_ANY
 match access-group name MAC_ANY

!
! Class for any IP traffic
!
class-map IP_ANY
 match access-group name IP_ANY

!
! Class to match the port connected to R1
!
class-map PORT_R1
 match input-interface FastEthernet 0/1

!
! Class to match the port connected to R3
!
class-map PORT_R3
 match input-interface FastEthernet 0/3

!
! Inteface-level policy-maps, limit rate per-port (R1 & R3)
!
policy-map PORT_R1
 class PORT_R1
  police  64000 8000

!
policy-map PORT_R3
  class PORT_R3
   police 512000 64000

!
! VLAN policy-map; two levels
!
policy-map VLAN_POLICY
 class IP_ANY
  set dscp 24
  service-policy PORT_R1
 class MAC_ANY
  set dscp ef
  service-policy PORT_R3
!
! Attach a switch-wide VLAN policy
!
interface VLAN 1
 service-policy input VLAN_POLICY
!
! Enabe VLAN based-QoS on some ports
!
interface range FastEthernet 0/1, FastEthernet 0/3
 mls qos vlan-based

What is that configuration intended to do? It defines two VLAN-wide classes, which apply to all ports belonging to this VLAN (including trunks) that has VLAN-based QoS enabled. Therefore, for any IP traffic on VLAN1 we set DSCP to 24, and for any non-IP traffic we set CoS to 5 (implicitly, using the “set dscp” command). Additionally, for IP traffic only, we limit port Fa 0/1 to 64Kbps, and for non-IP traffic we limit port Fa0/3 to 512Kbps. The policing is the only thing that is allowed to be configured on the “child” policy-map, and you can only match input-interfaces as a classification criteria for second-level policy-maps. The “child” (second-level) policy maps are unnecessary, and could be omitted from your configuration (i.e. you can use only a single-level policy-map). However, you must enable vlan-based QoS on the ports that needs to be affect by SVI-level policy-map.

The biggest difference from the 3550 model is that per-port, per-VLAN classification is now switch-wide (not port-wide), so it’s better called “per-VLAN” classification. You still may control which ports are affected, and use second-level policy-map to control the incoming rate per-class/per-port. For example, you may use the same range of ports under all class-maps and specify different rates for different types of traffic.

And finally, for verification techniques. The most used command to verify your QoS implementation is probably show mls qos interface x/y statistics which displays the number of packets with respective DSCP/CoS values entering/leaving a given port.

Rack21SW1#show mls qos interface fastEthernet 0/3 statistics
FastEthernet0/3

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

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

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

  0 -  4 :        5914            0            0            0            0
  5 -  7 :           0            0            0
  cos: outgoing
——————————-

  0 -  4 :        7991            0            0           98           11
  5 -  7 :        2762            0            2
Policer: Inprofile:            0 OutofProfile:            0

The other show commands are also useful, like show policy-map, show class-map, show access-list, show mls qos interface. There are also «esoteric» commands under the show platform but those are «deep technical» and are not well documented on the DocCD.

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

Read the rest of this entry »

Catalyst QoS configuration for IP Telephony endpoints is one of the CCIE Voice labs topics. Many people have issues with that one, because of need to memorize a lot of SRND recommendations to do it right. The good news is that during the lab exam you have full access to the QoS SRND documents and UniverCD content. The bad news is that you won’t probably have enough time to navigate the UniverCD with comfort plus the reference configurations often have a lot of typos and mistakes in them.

Read the rest of this entry »

QoS features available on Catalyst switch platforms have specific limitations, dictated by the hardware design of modern L3 switches, which is heavily optimized to handle packets at very high rates. Catalyst switch QoS is implemented using TCAM (Ternary Content Addressable Tables) - fast hardware lookup tables - to store all QoS configurations and settings. We start out Catalyst QoS overview with the old, long time available in the CCIE lab, the Catalyst 3550 model.

Read the rest of this entry »

Within the scope of Metro Ethernet services, it is often beneficial to provide customers “point-to-point” VLAN service, where VLAN (multipoint service in essence) is effectively set up to emulate ethernet “pseudowire”, by disabling MAC-address learning. The benefit comes from saving metro switches CAM tables address space, thus improving overall scalability (which is far from perfect with Ethernet). There is special command, mac address-table learning available on Cisco Metro swtiches (e.g. ME 3400) which allows to disable MAC-address learning per specific VLAN. However, many commonly used switches does not have this feature implemented. Still, there is a way to disable MAC-address learning on a group of ports, by using RSPAN VLAN feature. By it’s functional design, RSPAN VLAN does not learn MAC addresses. However, we are not allowed to assign this type of VLAN directy to switch access ports. Still, we may overcome this issue by configuring switchports as trunk with a single allowed VLAN (RSPAN VLAN) which is also configured as native:

vtp mode transparent
!
vlan 555
 remote-span
!
interface range Fa 0/1 - 3
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport trunk allowed vlan 555
 switchport trunk native vlan 555

This configuration is applicable to any switch that supports RSPAN functionality. Specifically, it was verified on Catalyst 3550 series.

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