Archive for March, 2008

Mar
26

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.

Mar
25

A common question that I get from students in class is what are the options to resolve spoke to spoke reachability in a Frame-Relay network. Below are your “standard” choices in order of preference:

1) Use point-to-point subinterfaces on the spokes.  This option is preferred as all IP addresses on the subnet will automatically be mapped to the DLCI that is bound to the subinterface.
2) Multipoint interfaces (physical or multipoint subinterfaces) on the spokes with Frame-Relay mappings pointing to the hub’s DLCI to reach the other spokes.
3) Multipoint interfaces on the spokes along with using the OSPF point-to-multipoint network type on all routers on the subnet. Each end point will advertise out a /32 and this advertisement will be relayed to the other spokes by the hub. This is exactly what the OSPF point-to-multipoint network type was designed for (full layer 3 reachability in a network that doesn’t have full layer 2 connectivity.
4) Use PPP over Frame-Relay (PPPoFR). By using PPPoFR IP will now be running over PPP and not directly over Frame-Relay. This means that IP sees everything as point-to-point links and no layer 3 to layer 2 mappings are needed.
5) Static /32 routes on the spokes point to the hub to reach the other spokes. Not a pretty solution but it will resolve the reachability issue.

Tags: , , ,

Mar
17

UPDATE: For more information on Redistribution see the video series Understanding Route Redistribution – Excerpts from CCIE R&S ATC

Please, refer to the previous parts of this article, for information on the diagram and terms. For this scenario, called “dual-core”, we want the “fast” Ethernet connections (VLAN 356) to be used as primary transport for packet exchange between the routing domains. The Frame-Relay cloud should only be traversed, if the primary (“fast”) connections fail for some reason. That obviously means we will need to configure two transit domains: the OSPF and EIGRP 356. Plus, routes traversing EIGRP 356 should be given higher preference inside other routing domains, since it’s going to be the primary transit path.

Continue Reading

Mar
03

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

Continue Reading

Tags: , , , , , , , ,

Categories

CCIE Bloggers