3560 SHARED/SHAPED ROUND ROBIN QUEUEING

In 3560 switches   WRR scheduler is replaced with SRR.  SRR is a scheduling service for specifying the rate at which packets are dequeued. With SRR there are two modes, Shaped and Shared (default). Shaped mode is only available on the egress queues. Shaped egress queues reserve a set of port bandwidth and then send evenly spaced packets as per the reservation. In Shared mode, if a higher priority queue is empty, instead of the servicer waiting for that reserved bandwidth to expire, the lower priority queue can take the unused bandwidth. Shared SRR is used when one wants to get the maximum efficiency out of a queuing system, because unused queue slots can be used by queues with excess traffic. Shaped SRR is used when one wants to shape a queue or set a hard limit on how much bandwidth a queue can use. When one uses Shaped SRR one can shape queues within a ports overall shaped rate. SRR shaped mode always take preference over SRR shared weights. The  port rate-limit feature of  SRR  limits the total port bandwidth to a percentage of port  speed  from 10% to 90%. 

Configuring SRR shared & shaped dequeing.

 

sw3(config)#int fastEthernet 0/1 

sw3(config-if)#srr-queue bandwidth shape 10 10 0 0 

sw3(config-if)#srr-queue bandwidth share 10 20 40 30

 

Configuring priority queueing in 3560 ports. 

sw3(config)#int fastEthernet 0/1 

sw3(config-if)#priority-queue out

 

The weight assigned to the priority queue is simply ignored for SRR calculations. Unlike the 3550, on the 3560, egress priority queue has queue-id 1, not 4. 

In 3560 switches four egress queues are there , in that the 1^st queue will be  the expedite queue. Each of these queues will have 3 threshold values known as explicit drop thresholds . First 2 explicit drop thresholds are configurable the 3^rd threshold represents 100% state / fixed state . 

Configuring egress queues

 

Mapping COS values to 4 queues

 

In the following example Q   Queue 1 is configured with 3 thresholds , COS values 2 & 3 are mapped to threshold 1 of queue 1  , COS value 5 is mapped to threshold 2 of queue 1  and COS value 0 is  mapped to threshold 3 of queue 1 . 

Queue 2 is configured with 3^rd   threshold (100%) & COS value 1 is mapped to this. Queue 3 is configured with 2nd   threshold  & COS value 6 is mapped to this.

Queue 4 is configured with 1^st    threshold  & COS value 7 is mapped to this.

 

sw3(config)#mls qos srr-queue output cos-map queue 1 threshold 1 2 3 

sw3(config)#mls qos srr-queue output cos-map queue 1 threshold 2 5 

sw3(config)#mls qos srr-queue output cos-map queue 1 threshold 3 0 

sw3(config)#mls qos srr-queue output cos-map queue 2 threshold 3 1 

sw3(config)#mls qos srr-queue output cos-map queue 3 threshold 2 6 

sw3(config)#mls qos srr-queue output cos-map queue 4 threshold 1 7 

 

Mapping DSCP values to 4 queues 

 In this dscp values 0 to 7 are mapped to queue 1 threshold 1 , dscp values 8 to 12 are mapped to queue 1 threshold 2  , dscp values 13 to 16 are mapped to queue 1 threshold 3 . 

dscp values 17 to 40 are mapped to queue 2 threshold 3 ,  dscp values 41 to 56 are mapped to queue 3 threshold 2 , dscp values 57 to 63 are mapped to queue 4 threshold 1 .

 

sw3(config)#mls qos srr-queue output dscp-map queue 1 threshold 1 0 1 2 3 4 5 6 7 

sw3(config)#mls qos srr-queue output dscp-map queue 1 threshold 2 8 9 10 11 12 

sw3(config)#mls qos srr-queue output dscp-map queue 1 threshold 3 13 14 15 16 

sw3(config)#mls qos srr-queue output dscp-map queue 2 threshold 3 17 18 19 20 21 22 23 24 

sw3(config)#mls qos srr-queue output dscp-map queue 2 threshold 3 25 26 27 28 29 30 31 32 

sw3(config)#mls qos srr-queue output dscp-map queue 2 threshold 3 33 34 35 36 37 38 39 40 

sw3(config)#mls qos srr-queue output dscp-map queue 3 threshold 2 41 42 43 44 45 46 47 48 

sw3(config)#mls qos srr-queue output dscp-map queue 3 threshold 2 49 50 51 52 53 54 55 56 

sw3(config)#mls qos srr-queue output dscp-map queue 4 threshold 1 57 58 59 60 61 62 63 

Buffer allocation in egress queues.

 

By using a queue-set you can do buffer allocation in egress queues , only 2 queue sets can be configured in a 3560 switch .

  

sw3(config)#mls qos queue-set output 1 buffers 10 20 30 40 

sw3(config)#int fa 0/2 

sw3(config-if)#queue-set 1

 

Ingress Queues 

    In 3560 switches 2 ingress queues can be configured & any of them can be configures as priority queue & up to 40% of bandwidth can be reserved for this. By default queue 2 is the priority queue.

 

sw3(config)#mls qos srr-queue input priority-queue 1 bandwidth 20 

Bandwidth configuration of input queues can be done in the following way .     

sw3(config)#mls qos srr-queue input bandwidth 30 70 

The buffer allocation to each of the input queues can also be changed . 

sw3(config)#mls qos srr-queue input buffers 35 65 

 

In the following example cos mapping is done for input srr queues.  COS values 0 , 1 & 2 are mapped to queue 1 threshold 1 , COS values 3 is  mapped to queue 1 threshold 2 , COS values 4 is  mapped to queue 1 threshold 3 , & finally COS values 5 , 6 & 7 are mapped to queue 2 threshold 1 . 

 

sw3(config)#mls qos srr-queue input cos-map queue 1 threshold 1 0 1 2 

sw3(config)#mls qos srr-queue input cos-map queue 1 threshold 2 3 

sw3(config)#mls qos srr-queue input cos-map queue 1 threshold 3 4 

sw3(config)#mls qos srr-queue input cos-map queue 2 threshold 1 5 6 7

 

 

In the following example dscp  mapping is done for input srr queues DSCP values 0-7 are mapped to queue 1 with a threshold of 1 , DSCP values 8-15  are mapped to queue 1 with a threshold of 2 , rest of the DSCP values are mapped to queue 2 with a threshold of 2.

 

sw3(config)#mls qos srr-queue input dscp-map queue 1 threshold 1 0 1 2 3 4 5 6 7 

sw3(config)#mls qos srr-queue input dscp-map queue 1 threshold  2 8 9 10 11 12 13 14 15 

sw3(config)#mls qos srr-queue input dscp-map queue 2  threshold  2 16 17 18 19 20 21 22 23 

sw3(config)#mls qos srr-queue input dscp-map queue 2 threshold  2 24 25 26 27 28 29 30 31 

sw3(config)#mls qos srr-queue input dscp-map queue 2 threshold  2 32 33 34 35 36 37 38 39 

sw3(config)#mls qos srr-queue input dscp-map queue 2 threshold  2 40 41 42 43 44 45 46 47 

sw3(config)#mls qos srr-queue input dscp-map queue 2 threshold  2 48 49 50 51 52 53 54 55 

sw3(config)#mls qos srr-queue input dscp-map queue 2 threshold  2 56 57 58 59 60 61 62 63

 

 

Verification commands: 

sw3#sh mls qos input-queue

sw3#sh mls qos interface fastEthernet 0/1 

sw3#sh mls qos queue-set 1

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

QinQ in CCIE LAB

IEEE  802.1Q TUNNELING 

     It’s been a bit since I last updated the blog.( 2 days only ): ). Today I was reviewing some switching topics with my 3560 configuration guide . The bad news with switching is that we may forget key features of some of  the technologies if we are not reviewing it frequently  .     QinQ is such a topic for me .

QinQ tunneling is a feature that is  asked  occassionaly in CCIE LAB . Though the chances of getting this task in CCIE lab is rare  ,  you are supposed to be familiar with this one also. 

Cisco 802.1Q Tunneling enables service providers to use a single VLAN to securely transport most or all of a single customer’s VLANs across their MAN or WAN backbone. In this case, the software adds an extra 802.1Q tag to customer traffic in the switch at the edge of the service provider’s network. This tag assigns a unique VLAN ID number to each customer to keep each customer’sVLAN traffic segregated and private.

                                     

Points to remember.

1. Use the vlan dot1q tag native global configuration command to configure the edge switch so that all packets going out an IEEE 802.1Q trunk, including the native VLAN, are tagged. 

2.A tunnel port cannot be a routed port.

3.Tunnel ports do not support IP access control lists (ACLs).

4.Layer 3 quality of service (QoS) ACLs and other QoS features related to Layer 3 information are not supported on tunnel ports. MAC-based QoS is supported on tunnel ports.

5.EtherChannel port groups are compatible with tunnel ports as long as the IEEE 802.1Q configuration is consistent within an EtherChannel port group.

6.Port Aggregation Protocol (PAgP) and Unidirectional Link Detection (UDLD) Protocol are not supported on IEEE 802.1Q tunnel ports.

7.Dynamic Trunking Protocol (DTP) is not compatible with IEEE 802.1Q tunneling because you must manually configure asymmetric links with tunnel ports and trunk ports.

8.Loopback detection is supported on IEEE 802.1Q tunnel ports.

9.When a port is configured as an IEEE 802.1Q tunnel port, spanning tree bridge protocol data unit (BPDU) filtering is automatically disabled on the interface.

Configuration Example:

Switch1(config)# interface gigabitethernet0/4

Switch1(config-if)# switchport access vlan 40

Switch1(config-if)# switchport mode dot1q-tunnel

Switch1(config-if)# exit

Switch1(config)# vlan dot1q tag native

Switch1(config)# end

Verification:

Switch1# show vlan dot1q tag native

Switch1# show dot1q-tunnel interface gigabitethernet0/7

Layer 2 Protocol Tunneling

Points to remember.

1.Layer 2 protocol tunneling can be used independently or can enhance IEEE 802.1Q tunneling.

2.If protocol tunneling is not enabled on IEEE 802.1Q tunneling ports, remote switches at the receiving end of the service-provider network do not receive the PDUs and cannot properly run STP, CDP, and VTP.  It also supports PAgP, LACP, and UDLD protocols. 

 3.You cannot enable Layer 2 protocol tunneling on ports configured in either switchport mode dynamic auto (the default mode) or switchport mode dynamic desirable.

4.DTP is not compatible with layer 2 protocol tunneling.

5.Loopback detection is not supported on Layer 2 protocol tunneling of PAgP, LACP, or UDLD packets.

6.When protocol tunneling is enabled on an interface, you can set a per-protocol, per-port, drop threshold for the PDUs generated by the customer network. If the limit is exceeded, the port drops PDUs until the rate at which it receives them is below the drop threshold.

Configuration Example:

Switch1(config)# interface fastethernet0/5

Switch1(config-if)# l2protocol-tunnel cdp

Switch1(config-if)# l2protocol-tunnel stp

Switch1(config-if)# l2protocol-tunnel vtp

Switch1(config-if)# l2protocol-tunnel shutdown-threshold 1500

Switch1(config-if)# l2protocol-tunnel drop-threshold 1000

Switch1(config-if)# exit

Switch1(config)# l2protocol-tunnel cos 5

Verification:

Switch1# show l2protocol

VOICE VLAN CONFIGURATION

 

Points to remeber :

When the voice VLAN feature is enabled, all untagged traffic is sent according to the default CoS priority of the port.

The CoS value is not trusted for IEEE 802.1p or IEEE 802.1Q tagged traffic.

Voice VLAN configuration is only supported on switch access ports; voice VLAN configuration is not supported on trunk ports.You can configure a voice VLAN only on Layer 2 ports.

The voice VLAN should be present and active on the switch for the IP phone to correctly communicate on the voice VLAN.

Do not configure voice VLAN on private VLAN ports.

Before you enable voice VLAN, it is recommended that you enable QoS on the switch by entering the mls qos global configuration command and configure the port trust state to trust by entering the mls qos trust cos interface configuration command.

You cannot configure static secure MAC addresses in the voice VLAN.

The Port Fast feature is automatically enabled when voice VLAN is configured. When you disable voice VLAN, the Port Fast feature is not automatically disabled.

Resources:

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_46_se/configuration/guide/swvoip.html

Configuration Example :

This example shows how to configure a port connected to a Cisco IP Phone to use the CoS value to classify incoming traffic, to use IEEE 802.1p priority tagging for voice traffic, and to use the default native VLAN (VLAN 0) to carry all traffic:

Switch# configure terminal
Switch(config)# mls qos
Switch(config)# interface gigabitethernet0/5
Switch(config-if)# mls qos trust cos
Switch(config-if)# switchport voice vlan dot1p
Switch(config-if)# end



This example shows how to configure a port connected to a Cisco IP Phone to not change the priority of frames received from the PC or the attached device:


Switch# configure terminal
Switch(config)# interface gigabitethernet0/7
Switch(config-if)# switchport priority extend trust
Switch(config-if)# end

VERIFICATION

Switch# show interfaces interface-id switchport

STORM CONTROL MECHANISM OF 3560

Points to remember:

1. Storm control is supported in physical interfaces .It can be applied also on etherchannel.

2.When storm control feature is applied to etherchannel the storm control settings propagate to the physical interfaces.

3.The rising threshold level can be specified in percentage level ( 0.00 to 100.00 ) , bps or pps

4.storm-control action shutdown command will error-disable the port during a storm.

5.storm-control action trap command will generate an snmp trap during a storm.

6. When the rate of multicast threshold exceeds the value all incoming tarffic is blocked untill the level falls below the value & only STP packets are forwarded.

6. When the rate of unicast or broadcast threshold exceeds the value only that particular type of tarffic is blocked.

Resources:

1.Univercd

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_44_se/configuration/guide/swtrafc.html#wp1063295



SAMPLE CONFIGURATION.

Unicast storm control

SWITCH#configure terminal
SWITCH(config)#int fa 0/7
SWITCH(config-if)#storm-control unicast level 75 65

In this example 75 percent is the rising threshold & 65 percent is the falling .
threshold.

Verification:
SWITCH# show storm-control fa 0/7 unicast

CCIE R&S LAB FRAME-RELAY configuration

Today we are going to discuss few things about  CCIE R&S LAB  FRAME-RELAY  configuration .

Topics to Cover :

The important Frame-Relay topics that you have to cover for CCIE R&S lab are .

1.  FR hub & spoke configuration with point to point subinterfaces  & multipoint subinterfaces.

2. FR full mesh configuration with point to point subinterfaces  & multipoint subinterfaces.

3. FR hub & spoke or full mesh configuration without subintefaces.

4. Disabling inverse-arp & clearing dynamically learned maps.

5. Configuration of FREEK ( FR end to end keepalives. )

6.PPP Authentication over FR.

Resources :

1. univercd

http://www.cisco.com/en/US/docs/ios/wan/configuration/guide/wan_cfg_frm_rly_ps6350_TSD_Products_Configuration_Guide_Chapter.html

2. Internetwork Experts COD.

3.Internetwork Experts  volume 1 advanced technoligies lab.

4.Narbiks soup to nut labs.

Points to remember.

1. If you are asked to configure FR hub & spoke by limiting broadcasts b/w spoke routers do not use the " broadcast " key word for FR Map commands from spokes to spokes.

Ex :

                             R1

           R2                             R3

R1 is the hub router have look at R2 configuration.

Rack1R2(config)#int s1/0
Rack1R2(config-if)#en fr
Rack1R2(config-if)#no sh
Rack1R2(config-if)#frame-relay map ip 145.1.12.1 201 broadcast 
Rack1R2(config-if)#frame-relay map ip 145.1.12.3 201

2. In case of FREEK attach the map-class to proper subinterface or proper DLCI  & after FREEK configuration verify EEK status .

Eg:  

Rack1R2#SH FRAMe-relay PVc 

PVC Statistics for interface Serial1/0 (Frame Relay DTE)

  Active Inactive Deleted Static
  Local 0 1 0 0
  Switched 0 0 0 0
  Unused 0 3 0 0

DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE (EEK UP ), INTERFACE = Serial1/0

3. Always use  "no frame-relay inverse-arp"  command before applying " no sh " if you are asked to do so.

4. You can change the full status polling interval of FR VC without changing the keepalive by using the interface level  " frame-relay lmi-n391dte  ---- " command.

5. The virtual template interface created for PPP authentication over FR  does not need

  " encapsulation frame-relay"  command.

Verification Commands.

   sh frame-relay map 

   sh frame-relay pvc 201

   sh frame-relay end-to-end

   sh frame-relay end-to-end keepalive 

   debug ppp authentication 

   sh frame-relay multilink