Last year, 31 May 2012, I failed my first lab exam. That time was pretty rough. I was too emotional and nearly walking out of the building for not knowing enough of the technologies. I came out of the building felling stress out. It could probably be that I went to the exam just couple of days after I finished with Narbik’s Bootcamp. Exhausted and agitated.

Almost a year after that, today, 27 April 2012, I went to the Cisco building with less stress. Not because I know that I’ll pass the exam. On a contrary, I know that I’ll fail this one. Not a good attitude to choose but I’m certainly having quite a few on my plate at the moment and I know I didn’t study well. This is not a case of miracle, you don’t study, you won’t pass!

Surprisingly, I’ve got better score than my previous attempt. Thank God! I thought I’m not making a significant progress but the score tells me otherwise. No, it’s still quite far from the 80% marking but at least knowing that I’m actually making progress does help build my confident.

Now I have another 12 months before my third attempt. Whether it would be August or December this year, I have to make sure that I can invest sufficient time for it.

Egress Queuing

Now, it has come to the part where packets are ready to be sent out. The idea is quite similar with Ingress Queuing but Egress has 4 Queues instead of only 2 for Ingress. Unlike Ingress Queues, Egress Queues has two sets of Queue configuration templates. It is called Queue-set 1 and Queue-set 2. This can be handy if you require to have two different settings for access ports and trunk ports. You will be able to configure Queue-set 1 with particular setup and have another different setup for Queue-set 2.

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
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
mls qos queue-set output 1 buffers 10 10 26 54
mls qos queue-set output 2 buffers 16 6 17 61

SW-3560#sh mls qos queue-set
Queueset: 1
Queue     :       1       2       3       4
----------------------------------------------
buffers   :      10      10      26      54
threshold1:     138     138      36      20
threshold2:     138     138      77      50
reserved  :      92      92     100      67
maximum   :     138     400     318     400
Queueset: 2
Queue     :       1       2       3       4
----------------------------------------------
buffers   :      16       6      17      61
threshold1:     149     118      41      42
threshold2:     149     118      68      72
reserved  :     100     100     100     100
maximum   :     149     235     272     242

Let’s take the example of Queue-set 1. Each Queue has been allocated as much as 10:10:26:54 for Q1, Q2, Q3, and Q4 respectively. Reserved is the maximum amount of the buffers can be used. So, Q4 has been allocated to be able to use 54% but limited to the 67% of the 54%, which is 54*.67=36.18%. But, this is just a reserved value for Q4, which can actually grow up to 400% provided there is enough memory available to borrow.

For T1 and T2, these are the threshold when the packets will start to get dropped (WTD), whichever configured. A little note for WTD here, it would be better to start dropping packets based on its Weighted value when the Queue reaches its threshold rather than waiting for the Queue to reach its maximum limit and dropping any packets, including high priority packets, trying to enter the Queue.

You can choose to use either Queue-set in the interface level using command queue-set <queue_number>

SW-3560(config)#int f0/1
SW-3560(config-if)#queue-set 2
SW-3560(config-if)#^Z
SW-3560#sh mls qos interface f0/1 Queuing
FastEthernet0/1
Egress Priority Queue : enabled
Shaped queue weights (absolute) :  10 0 0 0
Shared queue weights  :  1 10 60 20
The port bandwidth limit : 100  (Operational Bandwidth:100.0)
The port is mapped to qset : 2

From the above result, we can see that on port Fa0/1, the bandwidth is shared 10:60:20 for Q2, Q3, and Q4 respectively. You probably will think that Q1 is shaped to 10 and prioritized. No, Q1 can either be prioritized or shaped. If Q1 is prioritized, then the shaped 10 is irrelevant. We might as well to clean the config by making the shape to 0 0 0 0. This also means that once the Q1 is prioritized, there is no limit on how much Q1 can use up the bandwidth and might starve other traffic.

You can use the command below to set the SRR and the priority queue.

SW-3560(config)#int f0/1
SW-3560(config-if)#srr-queue bandwidth share 1 10 60 20
SW-3560(config-if)#srr-queue bandwidth shape 10 0 0 0
SW-3560(config-if)#priority-queue out
SW-3560(config-if)#do sh mls qos int f0/1 queue
FastEthernet0/1
Egress Priority Queue : enabled
Shaped queue weights (absolute) :  10 0 0 0
Shared queue weights  :  1 10 60 20
The port bandwidth limit : 100  (Operational Bandwidth:100.0)
The port is mapped to qset : 2 

SW-3560(config-if)#srr-queue bandwidth shape 0 0 0 0
SW-3560(config-if)#do sh mls qos int f0/1 queue
FastEthernet0/1
Egress Priority Queue : enabled
Shaped queue weights (absolute) :  0 0 0 0
Shared queue weights  :  1 10 60 20
The port bandwidth limit : 100  (Operational Bandwidth:100.0)
The port is mapped to qset : 2

Egress Queues also have cos-output-q and dscp-output-q for L2 and L3 queue mapping, respectively.

mls qos srr-queue output cos-map queue 1 threshold 3 5
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
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
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

SW-3560#sh mls qos maps cos-output-q
   Cos-outputq-threshold map:
              cos:  0   1   2   3   4   5   6   7
              ------------------------------------
  queue-threshold: 4-3 4-2 3-3 2-3 3-3 1-3 2-3 2-3 

SW-3560#sh mls qos maps dscp-output-q
   Dscp-outputq-threshold map:
     d1 :d2    0     1     2     3     4     5     6     7     8     9
     ------------------------------------------------------------
      0 :    04-03 04-03 04-03 04-03 04-03 04-03 04-03 04-03 04-01 04-02
      1 :    04-02 04-02 04-02 04-02 04-02 04-02 03-03 03-03 03-03 03-03
      2 :    03-03 03-03 03-03 03-03 02-03 02-03 02-03 02-03 02-03 02-03
      3 :    02-03 02-03 03-03 03-03 03-03 03-03 03-03 03-03 03-03 03-03
      4 :    01-03 01-03 01-03 01-03 01-03 01-03 01-03 01-03 02-03 02-03
      5 :    02-03 02-03 02-03 02-03 02-03 02-03 02-03 02-03 02-03 02-03
      6 :    02-03 02-03 02-03 02-03

For the Shared and Shaped Round-Robin, we have the option to share the bandwidth and limit (shape) it. srr-queue bandwidth share 10 10 60 20 will share the bandwidth evenly as much as 10:10:60:20 for Q1, Q2, Q3, and Q4, respectively. If either of the Queues not utilizing the shared bandwidth, other Queue can borrow the bandwidth above it’s minimum limit.

For the srr-queue bandwidth shaped 15 0 0 0 will limit the maximum bandwidth of Q1 up to 15 portion (no, this is not a percentage) from the shared X 10 60 20. When we put command srr-queue bandwidth shaped 15 0 0 0 this will render the first value of srr-queue bandwidth share X 10 60 20 useless. It is a good habit to put a minimum value to it to avoid confusion as shown below.

 srr-queue bandwidth share 1 10 60 20
 srr-queue bandwidth shape 10 0 0 0

We can also prioritize the Q1 using command priority-queue out. This command will also render value of Q1 in Share/Shaped value useless. It is also recommended to put the minimum value for Q1 on Share/Shape as shown below.

 srr-queue bandwidth share 1 10 60 20
 srr-queue bandwidth shape 0 0 0 0
 priority-queue out

That’s it from me!

I encourage you to visit this articles. This is where I’ve got so much understanding of it. Vikram Malhi explained this MLS QOS in a very easy way to understand.

Related Links
Cisco 3560 MLS QOS – Part 1
Cisco 3560 MLS QOS – Part 2
Cisco 3560 MLS QOS – Part 3 – Final

For this second part, I’ll try to explain about the Ingress Queueing mechanism and how can we modify this to prioritize traffic.

Ingress Queueing.

Once the traffic being marked and classified, packets go into Queues. There are cos-input-q for L2-based marking queue and dscp-input-q for L3-based marking queue as shown below.

SW-3560# sh mls qos maps cos-input-q
   Cos-inputq-threshold map:
              cos:  0   1   2   3   4   5   6   7
              ------------------------------------
  queue-threshold: 1-3 1-2 2-1 2-3 2-2 2-3 2-2 2-2

To change the cos-input-q map use command mls qos srr-queue input cos-map queue <Queue_Number> threshold <Threshold_Number> <COS_value>. Look at the example below.

! put COS 1 to Q1T2
mls qos srr-queue input cos-map queue 1 threshold 2 1

! put COS 0 to Q1T3
mls qos srr-queue input cos-map queue 1 threshold 3 0

! put COS 2 to Q2T1
mls qos srr-queue input cos-map queue 2 threshold 1 2

! put COS 4, 6, and 7 to Q2T2
mls qos srr-queue input cos-map queue 2 threshold 2 4 6 7

! put COS 3 and 5 to Q2T3
mls qos srr-queue input cos-map queue 2 threshold 3 3 5

SW-3560# sh mls qos maps cos-input-q
   Cos-inputq-threshold map:
              cos:  0   1   2   3   4   5   6   7
              ------------------------------------
  queue-threshold: 1-3 1-2 2-1 2-3 2-2 2-3 2-2 2-2

SW-3560#sh mls qos maps dscp-input-q
   Dscp-inputq-threshold map:
     d1 :d2    0     1     2     3     4     5     6     7     8     9
     ------------------------------------------------------------
      0 :    01-03 01-03 01-03 01-03 01-03 01-03 01-03 01-03 01-01 01-02
      1 :    01-02 01-02 01-02 01-02 01-02 01-02 02-01 02-01 02-01 02-01
      2 :    02-01 02-01 02-01 02-01 02-03 02-03 02-03 02-03 02-03 02-03
      3 :    02-03 02-03 01-03 02-02 02-02 02-02 02-02 02-02 02-02 02-02
      4 :    02-03 02-03 02-03 02-03 02-03 02-03 02-03 02-03 02-02 02-02
      5 :    02-02 02-02 02-02 02-02 02-02 02-02 02-02 02-02 02-02 02-02
      6 :    02-02 02-02 02-02 02-02

To Change the dscp-input-q use command mls qos srr-queue input dscp-map queue <Queue_Number> threshold <Threshold_Number> <DSCP_DECIMAL_value>. Look at the example below.

! put DSCP decimal 32 to Q2T3
mls qos srr-queue input dscp-map queue 1 threshold 3 32

! put DSCP decimal 16, 17, 18, 19, 20, 21, 22, and 23 to Q2T1
mls qos srr-queue input dscp-map queue 2 threshold 1 16 17 18 19 20 21 22 23

SW-3560#sh mls qos maps dscp-input-q
   Dscp-inputq-threshold map:
     d1 :d2    0     1     2     3     4     5     6     7     8     9
     ------------------------------------------------------------
      0 :    01-03 01-03 01-03 01-03 01-03 01-03 01-03 01-03 01-01 01-02
      1 :    01-02 01-02 01-02 01-02 01-02 01-02 02-01 02-01 02-01 02-01
      2 :    02-01 02-01 02-01 02-01 02-03 02-03 02-03 02-03 02-03 02-03
      3 :    02-03 02-03 01-03 02-02 02-02 02-02 02-02 02-02 02-02 02-02
      4 :    02-03 02-03 02-03 02-03 02-03 02-03 02-03 02-03 02-02 02-02
      5 :    02-02 02-02 02-02 02-02 02-02 02-02 02-02 02-02 02-02 02-02
      6 :    02-02 02-02 02-02 02-02

Now let see what are those Q1 and Q2 are.

SW-3560#sh mls qos input-queue
Queue     :       1       2
----------------------------------------------
buffers   :      67      33
bandwidth :      90      10
priority  :       0      10
threshold1:       8      34
threshold2:      16      66

From the above input-queue details, Q1T2 means that the Queue 1 can hold as much as Threshold 2 (which is 16 in this case) of Queue 1 Buffers 67. Once it reaches more than Threshold 16% of 67 Buffers, packets will be dropped. Buffers are the percentage value for each Queue.

For Q1T1, it will starts dropping packets once it reaches 8% of 67 Buffers.

So, what is the Threshold value For Q2T3? Threshold 3 will have 100% as default. Any Q uses T3 means that the packets will never get droppped. This makes sense why putting the DSCP EF packets or any other delay sensitive packets here.

Next is the Bandwidth parameters. This is the composition of how much of Q1 and Q2 can be transfered to the internal ring for the next process. Packets will be alternately taken from Q1 and Q2 and 90:10 described the weight composition for each Queue (not a percentage). This means the same with 18:2 or 9:1. For example, both Queue 1 and Queue 2 can take 1000 packets each, 900 will be transfered to the internal ring and 100 will be transfered to the internal ring. If Q1 is not fully occupied (e.g not using the 90 portion of it), the Q2 can transfer more than 10 portion from Q2.

The Priority however, will change the amount of packets taken from Q1 and Q2. Q2 (int this scenario) will be prioritized until it reaches maximum packets (100). Then the rest 900 will be shared between Q1 and Q2 for 810:90 as per 90:10 ratio.

Below are the example if you want to modify the input-queue.

mls qos srr-queue input buffers 67 33
mls qos srr-queue input bandwidth 90 10
! NOTE.
! - max PQ BW is 40.
! - We can use Q2 or Q2 as PQ.
mls qos srr-queue input priority-queue 2 bandwidth 10
mls qos srr-queue input threshold 1 8 16
mls qos srr-queue input threshold 2 34 66

SW-3560#sh mls qos input-queue
Queue     :       1       2
----------------------------------------------
buffers   :      67      33
bandwidth :      90      10
priority  :       0      10
threshold1:       8      34
threshold2:      16      66

Related Links
Cisco 3560 MLS QOS – Part 1
Cisco 3560 MLS QOS – Part 2
Cisco 3560 MLS QOS – Part 3 – Final

I’ll start with this Classification and Marking and let see how deep the rabbit hole goes for the next few parts.

Enjoy!

Classification and Marking.

Let’s just say that you have a switchport Fa0/1 configured for Vlan 100 and want to mark it as DSCP CS1 (Decimal 8).

SW-3560(config)#mls qos
SW-3560(config)#int f0/1
SW-3560(config-if)#switchport access vlan 100
SW-3560(config-if)#mls qos ?
  cos            cos keyword
  dscp-mutation  dscp-mutation keyword
  trust          trust keyword
  vlan-based     vlan-based keyword

We only left with COS option and no DSCP option available. COS field can only be found in 802.1q/ISL traffic which is the traffic on the trunk interface, and switchport access is not a trunk interface. In this case, we can use the COS option and then the switch will use the COS-DSCP mapping table to mark the packet as DSCP CS1 (Decimal 8).

SW-3560# sh mls qos maps cos-dscp
   Cos-dscp map:
        cos:   0  1  2  3  4  5  6  7
     --------------------------------
       dscp:   0  8 16 24 32 40 48 56

We can actually change this mapping. For example, for most implementation we would like to set COS 5 = DSCP EF (Decimal 46). This is to keep the uniformity from end-to-end that DSCP EF (mostly for VOICE RTP) is mapped to COS 5.

SW-3560(config)#mls qos map cos-dscp 0 8 16 24 32 46 48 56
SW-3560(config)#mls qos map cos-dscp 0 8 16 24 32 46 48 56
SW-3560(config)#do sh mls qos map cos-dscp
   Cos-dscp map:
        cos:   0  1  2  3  4  5  6  7
     --------------------------------
       dscp:   0  8 16 24 32 46 48 56

Based on the COS-DSCP map, to mark the packet to DSCP CS1 (Decimal 8), we can use mls qos cos 1.

SW-3560(config)#mls qos
SW-3560(config)#int f0/1
SW-3560(config-if)#switchport access vlan 100
SW-3560(config-if)#mls qos cos 1
!
SW-3560#sh mls qos int f0/1
FastEthernet0/1
trust state: not trusted
trust mode: not trusted
trust enabled flag: ena
COS override: dis
default COS: 1
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none
qos mode: port-based

we can combine the mls qos cos 1 with several commands below.

If the host is capable of marking the packets entering the switchport Fa0/1, we can also honour its value by trusting its DSCP or IP-PRECEDENCE or COS marking.

For IP packets, we can use mls qos trust dscp or mls qos trust ip-precedence. If the packets are NON-IP but we are trusting IP packets (via DSCP or IP-PRECEDENCE), then the switch will have no choice but to check other than DSCP or IP-PRECEDENCE. It will check the COS marking, which again, only available on trunk port. If there is no COS field available or if it is not an 802.1q/ISL, the packets will be marked with whatever the value in mls qos cos command, look at the COS-DSCP table, then mark it with the appropriate DSCP value. In this case DSCP CS1 (Decimal 8).

SW-3560#sh mls qos int f0/1
FastEthernet0/1
trust state: trust dscp
trust mode: trust dscp
trust enabled flag: ena
COS override: dis
default COS: 1
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none
qos mode: port-based

On the other hand, mls qos trust cos will works for both IP and NON-IP packets marking. If there is a COS value in it, int this case has to be an 802.1q/ISL, it will uses that COS value. If there is no COS value, it will use the mls qos cos 1 despite whatever DSCP/IP-PRECEDENCE value it already has. The switch will rewrite this DSCP/IP-PRECEDENCE based on the new COS value (COS 1).

SW-3560#sh mls qos int f0/1
FastEthernet0/1
trust state: trust cos
trust mode: trust cos
trust enabled flag: ena
COS override: dis
default COS: 1
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none
qos mode: port-based

If we just want to override the existing COS or DCSCP/IP-PRECEDENCE value we can use mls qos cos override. This will override any COS value and deduce the DSCP value based on the COS-DSCP mapping table.

SW-3560#sh mls qos int f0/1
FastEthernet0/1
trust state: cos override
trust mode: cos override
trust enabled flag: ena
COS override: ena
default COS: 1
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none
qos mode: port-based

Besides having mls qos cos command, we can use the MQC framework to perform the marking. This can be done as below

policy-map PM_QOS_MARKING
 class class-default
  set dscp cs1

int f0/1
 switchport access vlan 100
 service-policy in PM_QOS_MARKING

SW-3560#sh mls qos int f0/1
FastEthernet0/1
Attached policy-map for Ingress: PM_QOS_MARKING
trust state: not trusted
trust mode: not trusted
trust enabled flag: ena
COS override: dis
default COS: 1
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none
qos mode: port-based

As shown above, we can use the MQC to mark any packet to DSCP CS1. Using this scenario we cannot use it to mark it as COS 1. Instead we can use DSCP CS1 and use DSCP-COS mapping table

SW-3560#sh mls qos maps dscp-cos
   Dscp-cos map:
     d1 :  d2 0  1  2  3  4  5  6  7  8  9
     ---------------------------------------
      0 :    00 00 00 00 00 00 00 00 01 01
      1 :    01 01 01 01 01 01 02 02 02 02
      2 :    02 02 02 02 03 03 03 03 03 03
      3 :    03 03 04 04 04 04 04 04 04 04
      4 :    05 05 05 05 05 05 05 05 06 06
      5 :    06 06 06 06 06 06 07 07 07 07
      6 :    07 07 07 07

In this DSCP-COS map, we can see that DSCP CS1, read as decimal 08, has COS 1 mapped to it. Therefore, if the packet has 802.1q/ISL header, then the switch will rewrite it to COS 1.

We can alter this map like we alter cos-dscp map, but now we actually alter the dscp-cos map. Please note that changing cos-dscp map doesn’t automatically change dscp-cos map. These two maps are not linked to each other and keep its own mapping

the DSCP-COS map above shows that DSCP EF (Decimal 46) has COS value of 5. We can change this value using the command below

SW-3560(config)#mls qos map dscp-cos  46 to 4
SW-3560(config)#do sh mls qos map dscp-cos
   Dscp-cos map:
     d1 :  d2 0  1  2  3  4  5  6  7  8  9
     ---------------------------------------
      0 :    00 00 00 00 00 00 00 00 01 01
      1 :    01 01 01 01 01 01 02 02 02 02
      2 :    02 02 02 02 03 03 03 03 03 03
      3 :    03 03 04 04 04 04 04 04 04 04
      4 :    05 05 05 05 05 05 0405 06 06
      5 :    06 06 06 06 06 06 07 07 07 07
      6 :    07 07 07 07

Let see another example below:

int f0/1
 switchport access vlan 100
 switchport voice vlan 200
 mls qos trust device cisco-phone

SW-3560#sh mls qos int f0/37
FastEthernet0/37
trust state: not trusted
trust mode: not trusted
trust enabled flag: ena
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: cisco-phone
qos mode: port-based

The command mls qos trust device cisco-phone will trust the marking if the port can sense a Cisco-phone via CDPv2 or LLDP-Med. The port itself turns into a pseudo-trunk which caries 802.1q header and contains COS value. Again, this can also alter the DSCP value based on COS-DSCP mapping table. However, the switch will not trust the PC on the vlan 100 thus will rewrite it to COS 0 based on the switchport default COS value.

This also means that once you enable the mls qos globally, the switchport will rewrite any packets to COS 0 or DSCP default (decimal 0). If you want, you can change this default COS 0 value to mls qos cos 2 to mark the traffic that are not from known Cisco-phone

MQC

We can actually use MQC inline with the mls qos. This is when you need to differentiate several different traffic on vlan 100 and mark those traffic differently.

ip access-list ext ACL_HTTP
 permit tcp any any eq www
ip access-list ext ACL_TELNET
 permit  tcp any any eq telnet

class-map CM_HTTP
 match access-group name ACL_HTTP
class-map CM_TELNET
 match access-group name ACL_TELNET

policy-map PM_QOS_MARKING
 class CM_HTTP
  set dscp cs1
 class CM_TELNET
  set dscp af41
 class class-default
  set dscp cs1

int f0/1
 switchport access vlan 100
 switchport voice vlan 200
 mls qos trust device cisco-phone
 service-policy input PM_QOS_MARKING

The above combination will trust the DSCP marking from the Cisco-phone and mark any HTTP packets on vlan 100 as CS1, TELNET as CS3, and the rest will be marked as DSCP cs1. Note that any other packet will not be marked as CS 0 as per the default COS value, this is because the matched class-default inside PM_QOS_MARKING is acting as a catch all. Unless there is no class-default inside the PM_QOS_MARKING, CS 0 will be used.

Also remember on the early paragraph I’ve showed that we cannot use mls qos dscp command, the only available marking is mls qos cos

The moral of this DSCP/IP-PRECEDENCE/COS confusion is basically quite simple. It doesn’t really matter what marking you’re trusting, as long as you have the map correctly adjusted then the switch can use both L2 and L3 marking.

Of course, it will make more sense if you trust COS on trunk ports and DSCP/IP-Prec on non-trunk port for efficiency, but again it doesn’t really matter as long as you have the mapping correctly adjusted.

Another example, you can trust DSCP (instead of COS) on your ingress trunk L2 switch from the dot1q WAN router interface. The reason for this is just merely because packet from the WAN doesn’t have any COS value in it.

This is it so far for Marking and Classification.

Related Links
Cisco 3560 MLS QOS – Part 1
Cisco 3560 MLS QOS – Part 2
Cisco 3560 MLS QOS – Part 3 – Final

Initial configuration below

hostname R2
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface Loopback1
 ip address 22.22.22.22 255.255.255.255
!
interface FastEthernet0/0
 ip address 12.12.12.2 255.255.255.0
!
router eigrp 12
 network 0.0.0.0
 no auto-summary

hostname R3
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface Loopback1
 ip address 33.33.33.33 255.255.255.255
!
interface FastEthernet0/0
 ip address 13.13.13.3 255.255.255.0
!
router eigrp 13
 network 0.0.0.0
 no auto-summary

hostname R1
!
interface FastEthernet0/0
 ip address 12.12.12.1 255.255.255.0
!
interface FastEthernet1/0
 ip address 13.13.13.1 255.255.255.0
!
interface FastEthernet2/0
 ip address 14.14.14.1 255.255.255.0
!
router eigrp 12
 network 12.12.12.1 0.0.0.0
 auto-summary
!
router eigrp 13
 network 13.13.13.1 0.0.0.0
 no auto-summary

hostname R4
!
interface FastEthernet0/0
 ip address 14.14.14.4 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 14.14.14.1

At this stage, SITE_A doesn’t know network 14.14.14.0/24 and SITE_B doesn’t know network 14.14.14.0/24 either. R4 won’t have reachability to SITE_A nor SITE_B.

Let introduce NAT on R1 by NAT-ing 14.14.14.0/24 to R1 f0/0 – 12.12.12.1.

ip access-list st ACL_14.14.14.0/24
 permit 14.14.14.0 0.0.0.255
!
ip nat inside source list ACL_14.14.14.0/24 interface f0/0 overload

This will give R4 reachbility to SITE_A.

R4#ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/67/104 ms

R1#sh ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 12.12.12.1:5      14.14.14.4:5       2.2.2.2:5          2.2.2.2:5

Inside local address 14.14.14.0/24 being translated to 12.12.12.1 to reach 2.2.2.2. Since SITE_A has the routing information for 12.12.12.0/24, SITE_A is now able to send return traffic to 14.14.14.0/24.

What about SITE_B, can we do the same to R1 Fa1/0 like what we did to R1 Fa0/0?

In order to be able to NAT both Fa0/0 and Fa1/0, we cannot use standar ACL anymore. This can only be done via route-map and extended ACL.

ip access-list extended ACL_FROM_14.14.14.0/24_TO_SITE_A
 permit ip 14.14.14.0 0.0.0.255 host 2.2.2.2
 permit ip 14.14.14.0 0.0.0.255 host 22.22.22.22
 permit ip 14.14.14.0 0.0.0.255 12.12.12.0 0.0.0.255
!
ip access-list extended ACL_FROM_14.14.14.0/24_TO_SITE_B
 permit ip 14.14.14.0 0.0.0.255 host 3.3.3.3
 permit ip 14.14.14.0 0.0.0.255 host 33.33.33.33
 permit ip 14.14.14.0 0.0.0.255 13.13.13.0 0.0.0.255
!
no route-map RM_FROM_14.14.14.0/24_TO_SITE_A permit 10
route-map RM_FROM_14.14.14.0/24_TO_SITE_A permit 10
 match ip address ACL_FROM_14.14.14.0/24_TO_SITE_A
!
no route-map RM_FROM_14.14.14.0/24_TO_SITE_B permit 10
route-map RM_FROM_14.14.14.0/24_TO_SITE_B permit 10
 match ip address ACL_FROM_14.14.14.0/24_TO_SITE_B
!
ip nat inside source route-map RM_FROM_14.14.14.0/24_TO_SITE_A interface FastEthernet0/0 overload
ip nat inside source route-map RM_FROM_14.14.14.0/24_TO_SITE_B interface FastEthernet1/0 overload
!
int f0/0
 ip nat outside
int f1/0
 ip nat outside
int f2/0
 ip nat inside

R4#ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/69/80 ms
R4#ping 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/68/92 ms

R1#sh ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 12.12.12.1:25     14.14.14.4:25      2.2.2.2:25         2.2.2.2:25
icmp 13.13.13.1:26     14.14.14.4:26      3.3.3.3:26         3.3.3.3:26

I’ve actually tried the combination of using two different route-maps with the same 1 standard ACL or the same 1 extended ACL. This just doesn’t work. The reason being is that the translation will need two distinct ACLs to differentiate between one translation exit point to another.

R1#sh ip nat tran verbose
Pro Inside global      Inside local       Outside local      Outside global
icmp 12.12.12.1:31     14.14.14.4:31      3.3.3.3:31         3.3.3.3:31
    create 00:00:07, use 00:00:07 timeout:60000, left 00:00:52, Map-Id(In): 16,
    flags:
extended, use_count: 0, entry-id: 22, lc_entries: 0, Entry type : 0
icmp 12.12.12.1:32     14.14.14.4:32      2.2.2.2:32         2.2.2.2:32
    create 00:00:04, use 00:00:04 timeout:60000, left 00:00:55, Map-Id(In): 16,
    flags:
extended, use_count: 0, entry-id: 23, lc_entries: 0, Entry type : 0

For each NAT configuration statement ip nat inside source route-map RM_FROM_14.14.14.0/24_TO_SITE_A interface FastEthernet0/0 overload or ip nat inside source route-map RM_FROM_14.14.14.0/24_TO_SITE_B interface FastEthernet1/0 overload the NAT will generate a Map-Id. Having the same Map-Id for both exit points will only confuses the mapping.

The entry below, however, created when we use two route-maps with two different ACLs. It shows different Map-Id for each exit points.

R1#sh ip nat translations ver
Pro Inside global      Inside local       Outside local      Outside global
icmp 12.12.12.1:38     14.14.14.4:38      22.22.22.22:38     22.22.22.22:38
    create 00:00:17, use 00:00:17 timeout:60000, left 00:00:42, Map-Id(In): 16,
    flags:
extended, use_count: 0, entry-id: 28, lc_entries: 0
icmp 12.12.12.1:39     14.14.14.4:39      2.2.2.2:39         2.2.2.2:39
    create 00:00:14, use 00:00:14 timeout:60000, left 00:00:45, Map-Id(In): 16,
    flags:
extended, use_count: 0, entry-id: 29, lc_entries: 0
icmp 13.13.13.1:40     14.14.14.4:40      3.3.3.3:40         3.3.3.3:40
    create 00:00:11, use 00:00:11 timeout:60000, left 00:00:48, Map-Id(In): 17,
    flags:
extended, use_count: 0, entry-id: 30, lc_entries: 0
icmp 13.13.13.1:41     14.14.14.4:41      33.33.33.33:41     33.33.33.33:41
    create 00:00:07, use 00:00:07 timeout:60000, left 00:00:52, Map-Id(In): 17,
    flags:
extended, use_count: 0, entry-id: 31, lc_entries: 0

Let’s say that you have a scenario to create Q-in-Q which requires you to alter the default MTU to 1504 using system mtu 1504. The verification also shows that your system MTU is indeed 1504.

SWITCH-3560#sh system mtu

System MTU size is 1504 bytes
System Jumbo MTU size is 1504 bytes
Routing MTU size is 1500 bytes

Suddenly, your OSPF adjacency went down, re-initialized, and then stuck in EXSTART/EXCHANGE. In this state, both sides will try to exchange the DBD packets. This problem can occurs when the MTU attribute between peers doesn’t match. (Also, you can check for Unicast traffic – if any, ACL, or even NAT)

Well, isn’t that you have your switches MTU’s adjusted to 1504 using command system mtu 1504? Yes, the SYSTEM MTU is 1504, which was configured for Q-in-Q.

OSPF, however, uses ROUTING MTU instead of SYSTEM MTU. Therefore, to change the ROUTING MTU we need to use command system mtu routing 1504.

Another way to fix this issue is to disable the MTU checking during adjacency process. You can use ip ospf mtu-ignore. This can be handy if you don’t have the option to change the MTU value.

SWITCH-3560#sh system mtu

System MTU size is 1504 bytes
System Jumbo MTU size is 1504 bytes
Routing MTU size is 1500 bytes
SWITCH-3560#
*Mar  1 00:03:16.050: OSPF: Rcv DBD from 10.4.4.4 on Port-channel14 seq 0x1995 opt 0x52 flag 0x2 len 52  mtu 1504 state EXSTART
*Mar  1 00:03:16.050: OSPF: Nbr 10.4.4.4 has larger interface MTU
*Mar  1 00:03:20.974: OSPF: Send hello to 224.0.0.5 area 0 on Port-channel14 from 163.17.0.1
*Mar  1 00:03:21.058: OSPF: Send DBD to 10.4.4.4 on Port-channel14 seq 0x1995 opt 0x52 flag 0x7 len 32
*Mar  1 00:03:21.058: OSPF: Retransmitting DBD to 10.4.4.4 on Port-channel14 [20]
*Mar  1 00:03:21.058: OSPF: Rcv DBD from 10.4.4.4 on Port-channel14 seq 0x1995 opt 0x52 flag 0x2 len 52  mtu 1504 state EXSTART
*Mar  1 00:03:21.058: OSPF: Nbr 10.4.4.4 has larger interface MTU
*Mar  1 00:03:21.460: OSPF: Rcv hello from 10.4.4.4 area 0 from Port-channel14 163.17.0.4l
SWITCH-3560#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SWITCH-3560(config)#system mtu ?
  <1500-1998>  MTU size in bytes
  jumbo        Set Jumbo MTU value for GigabitEthernet or TenGigabitEthernet
               interfaces
  routing      Set the Routing MTU for the system

SWITCH-3560(config)#system mtu routing 1504
*Mar  1 00:03:46.492: %SYS-5-CONFIG_I: Configured from console by console
*Mar  1 00:03:51.106: %OSPF-5-ADJCHG: Process 1, Nbr 10.4.4.4 on Port-channel14 from EXSTART to DOWN, Neighbor Down: Too many SWITCH-3560(config)#int port 14
SWITCH-3560(config-if)#shut
SWITCH-3560(config-if)#no shut
SWITCH-3560(config-if)#
*Mar  1 00:04:02.162: %OSPF-5-ADJCHG: Process 1, Nbr 10.4.4.4 on Port-channel14 from DOWN to DOWN, Neighbor Down: Interface down or detached
*Mar  1 00:04:03.135: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel14, changed state to down
SWITCH-3560(config-if)#
SWITCH-3560(config-if)#
*Mar  1 00:04:04.133: %LINK-3-UPDOWN: Interface Port-channel14, changed state to down
SWITCH-3560(config-if)#
*Mar  1 00:04:05.106: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/20, changed state to down
*Mar  1 00:04:05.123: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/21, changed state to down
SWITCH-3560(config-if)#
*Mar  1 00:04:06.574: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/21, changed state to up
*Mar  1 00:04:06.650: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/20, changed state to up
SWITCH-3560(config-if)#^Z
SWITCH-3560#
*Mar  1 00:04:07.572: %LINK-3-UPDOWN: Interface Port-channel14, changed state to up
SWITCH-3560#sh ip os
*Mar  1 00:04:08.369: %SYS-5-CONFIG_I: Configured from console by console
*Mar  1 00:04:08.588: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel14, changed state to up
*Mar  1 00:04:17.563: OSPF: Rcv hello from 10.4.4.4 area 0 from Port-channel14 163.17.0.4
*Mar  1 00:04:17.563: OSPF: 2 Way Communication to 10.4.4.4 on Port-channel14, state 2WAY
*Mar  1 00:04:17.563: OSPF: End of hello processing
*Mar  1 00:04:17.572: OSPF: Send hello to 224.0.0.5 area 0 on Port-channel14 from 163.17.0.1
*Mar  1 00:04:17.572: OSPF: will poll [count 10] interface status for Port-channel14
*Mar  1 00:04:27.563: OSPF: Rcv hello from 10.4.4.4 area 0 from Port-channel14 163.17.0.4
*Mar  1 00:04:27.563: OSPF: End of hello processing
*Mar  1 00:04:27.579: OSPF: Send hello to 224.0.0.5 area 0 on Port-channel14 from 163.17.0.1
*Mar  1 00:04:27.579: OSPF: will poll [count 9] interface status for Port-channel14
*Mar  1 00:04:37.562: OSPF: Rcv hello from 10.4.4.4 area 0 from Port-channel14 163.17.0.4
*Mar  1 00:04:37.562: OSPF: End of hello processing
*Mar  1 00:04:37.579: OSPF: Send hello to 224.0.0.5 area 0 on Port-channel14 from 163.17.0.1
*Mar  1 00:04:37.579: OSPF: will poll [count 8] interface status for Port-channel14
*Mar  1 00:04:47.569: OSPF: Rcv hello from 10.4.4.4 area 0 from Port-channel14 163.17.0.4
*Mar  1 00:04:47.569: OSPF: Backup seen Event before WAIT timer on Port-channel14
*Mar  1 00:04:47.569: OSPF: DR/BDR election on Port-channel14
*Mar  1 00:04:47.569: OSPF: Elect BDR 0.0.0.0
*Mar  1 00:04:47.569: OSPF: Elect DR 10.4.4.4
*Mar  1 00:04:47.569:        DR: 10.4.4.4 (Id)   BDR: none
*Mar  1 00:04:47.569: OSPF: Send DBD to 10.4.4.4 on Port-channel14 seq 0x12F3 opt 0x52 flag 0x7 len 32
*Mar  1 00:04:47.569: OSPF: End of hello processing
*Mar  1 00:04:47.569: OSPF: Rcv DBD from 10.4.4.4 on Port-channel14 seq 0x1041 opt 0x52 flag 0x7 len 32  mtu 1504 state EXSTART
*Mar  1 00:04:47.569: OSPF: First DBD and we are not SLAVE
*Mar  1 00:04:47.569: OSPF: Rcv DBD from 10.4.4.4 on Port-channel14 seq 0x12F3 opt 0x52 flag 0x2 len 92  mtu 1504 state EXSTART
*Mar  1 00:04:47.569: OSPF: NBR Negotiation Done. We are the MASTER
*Mar  1 00:04:47.569: OSPF: Send DBD to 10.4.4.4 on Port-channel14 seq 0x12F4 opt 0x52 flag 0x3 len 52
*Mar  1 00:04:47.578: OSPF: Rcv DBD from 10.4.4.4 on Port-channel14 seq 0x12F4 opt 0x52 flag 0x0 len 32  mtu 1504 state EXCHANGE
*Mar  1 00:04:47.578: OSPF: Send DBD to 10.4.4.4 on Port-channel14 seq 0x12F5 opt 0x52 flag 0x1 len 32
*Mar  1 00:04:47.578: OSPF: Send LS REQ to 10.4.4.4 length 36 LSA count 3
*Mar  1 00:04:47.578: OSPF: Rcv LS REQ from 10.4.4.4 on Port-channel14 length 36 LSA count 1
*Mar  1 00:04:47.578: OSPF: Send UPD to 163.17.0.4 on Port-channel14 length 40 LSA count 1
*Mar  1 00:04:47.578: OSPF: Rcv DBD from 10.4.4.4 on Port-channel14 seq 0x12F5 opt 0x52 flag 0x0 len 32  mtu 1504 state EXCHANGE
*Mar  1 00:04:47.578: OSPF: Exchange Done with 10.4.4.4 on Port-channel14
*Mar  1 00:04:47.578: OSPF: Rcv LS UPD from 10.4.4.4 on Port-channel14 length 156 LSA count 3
*Mar  1 00:04:47.578: OSPF: Synchronized with 10.4.4.4 on Port-channel14, state FULL
*Mar  1 00:04:47.578: %OSPF-5-ADJCHG: Process 1, Nbr 10.4.4.4 on Port-channel14 from LOADING to FULL, Loading Done
SWITCH-3560#sh system mtu

System MTU size is 1504 bytes
System Jumbo MTU size is 1504 bytes
Routing MTU size is 1504 bytes

• This will make the interface become a layer 2 switchport or non-routeable port.
• There is no 802.1q/ISL tagging involvement in this port as the traffic will be received and sent as untagged.
• Because there is no tagging involved, the port has no clue what VLAN this frame should be. Therefore, any packets passing this port is assumed to belong to the VLAN assigned to this port. In this case vlan 20.
• If you add the configuration with switchport mode access this will make the interface turned to nontrunking permanently and also negotiates or telling the other end of the link to be a nontrunk link. This interface will permanently become nontrunk interface regardless the other end is trunk or nontrunk link. With this in mind, if one port is configured with switchport mode access and other end port happens to be configured with switchport mode dynamic auto or switchport mode dynamic desirable
  

  sw3#sh run int f0/19
  Building configuration...
  
  Current configuration : 58 bytes
  !
  interface FastEthernet0/19
   switchport mode access
  end
  
  sw3#sh int f0/19 status
  
  Port      Name               Status       Vlan       Duplex  Speed Type
  Fa0/19                       connected    1          a-full  a-100 10/100BaseTX
  sw3#sh spann      
  
  VLAN0001
    Spanning tree enabled protocol ieee
    Root ID    Priority    32769
               Address     a8b1.d45b.3b80
               Cost        19
               Port        21 (FastEthernet0/19)
               Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
  
    Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
               Address     aca0.1644.b180
               Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
               Aging Time  300 sec
  
  Interface           Role Sts Cost      Prio.Nbr Type
  ------------------- ---- --- --------- -------- --------------------------------
  Fa0/19              Root FWD 19        128.21   P2p 
  
  sw3#sh int f0/19 sw
  Name: Fa0/19
  Switchport: Enabled
  Administrative Mode: static access
  Operational Mode: static access
  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: none
  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 associations: none
  Administrative private-vlan trunk mappings: none
  Operational private-vlan: none
  Trunking VLANs Enabled: ALL
  Pruning VLANs Enabled: 2-1001
  Capture Mode Disabled
  Capture VLANs Allowed: ALL
  
  Protected: false
  Unknown unicast blocked: disabled
  Unknown multicast blocked: disabled
  Appliance trust: none
  
  sw4#sh run int f0/19
  Building configuration...
  
  Current configuration : 34 bytes
  !
  interface FastEthernet0/19
  end
  
  sw4#sh int f0/19 status
  
  Port      Name               Status       Vlan       Duplex  Speed Type
  Fa0/19                       connected    1          a-full  a-100 10/100BaseTX
  sw4#sh spann 
  
  VLAN0001
    Spanning tree enabled protocol ieee
    Root ID    Priority    32769
               Address     a8b1.d45b.3b80
               This bridge is the root
               Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
  
    Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
               Address     a8b1.d45b.3b80
               Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
               Aging Time  300 sec
  
  Interface           Role Sts Cost      Prio.Nbr Type
  ------------------- ---- --- --------- -------- --------------------------------
  Fa0/19              Desg FWD 19        128.21   P2p 
  
  sw4#sh int f0/19 sw
  sw4#sh int f0/19 switchport
  Name: Fa0/19
  Switchport: Enabled
  Administrative Mode: dynamic auto
  Operational Mode: static access
  Administrative Trunking Encapsulation: negotiate
  Operational Trunking Encapsulation: native
  Negotiation of Trunking: On
  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: none
  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 associations: none
  Administrative private-vlan trunk mappings: none
  Operational private-vlan: none
  Trunking VLANs Enabled: ALL
  Pruning VLANs Enabled: 2-1001
  Capture Mode Disabled
  Capture VLANs Allowed: ALL
  
  Protected: false
  Unknown unicast blocked: disabled
  Unknown multicast blocked: disabled
  Appliance trust: none
  

• You can actually peer this with a trunk port as configured below

  ! SW3
  interface FastEthernet0/19
   switchport access vlan 20
   switchport mode access
   spanning-tree portfast
   spanning-tree bpdufilter enable
  int vlan 10
   ip addr 10.10.10.3 255.255.255.0
  exit
  
  ! SW4
  interface FastEthernet0/19
   switchport trunk encapsulation dot1q
   switchport trunk native vlan 20
   switchport mode trunk
   switchport nonegotiate
   spanning-tree portfast trunk
  int vlan 10
   ip addr 10.10.10.4 255.255.255.0
  exit
  
  sw4#ping 10.10.10.3      
  
  Type escape sequence to abort.
  Sending 5, 100-byte ICMP Echos to 10.10.10.3, timeout is 2 seconds:
  !!!!!
  Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms
  

  Since switchport access vlan 20 will send and receive frame without tagging it and neither the other end (the trunk port), this peering will successfully send and receive frame and assume that it is belong to vlan 20.

Enough for the rant, I’m starting my INE WB from the beginning and it feels like things are keep unlocking itself and I have lots of Aha moments. I guess whatever I read before still inside, somewhere.

Previously I studied like a running train and tried to read as much as I could but not necessarily trying to understand it. That’s why I failed. I can be efficient to read more but it wasn’t effective enough to make me to understand it. This time is different, I have that eagerness to know more and don’t really care about the time, as long as I can learn 1-2 hours a day and make it count, it will be much better rather than learning until 2am in the morning but understand nothing.

Just before the exam, I was quite lucky to be able to attend Narbik’s 5-day Bootcamp, for those who wants to know what is it like in details, please visit this article. From my own point of view, this training has opened my eyes that CCIE is not for the faint-hearted, no shortcuts and you have to walk the process. I’m planning to join his 5-day bootcamp again in December 2011.

For all of those CCIE candidates out there, it’s hard but not impossible.