Archives for category: Switching

I was asked question about MPLS labels within a VRF. Well the question was ” when I type the command ‘show mpls ldp bindings vrf xxx‘ ” I don’t see any labels for my remote site prefixes.

In this case these labels aren’t assigned by LDP they are assigned by BGP.

The command he was looking for was “show ip bgp vpnv4 vrf xxx labels” I think a light went on in his head when i explained this to him!

If your still confused , imagine the LSP (unidirectional) R1 -> R4 is basically a virtual connection if you like , where R4 is the egress LSR for the packet. The packet will travel via R1 -> R2 -> R3 -> R4. The next hop actually is listed as R4 even though it has to pass through R2 and R3. Which by the way has it own labels to add on top of bottom of stack label for R4.


R1 pushes on the label 1234 for R4 and another label on top for R2 which is 22, next R2 removes its own label (22) and adds the label for R3 which is 33, R3 removes its own label (33) and forwards the packet with the label 1234 to R4. Bottom of stack bit is set to 1, R4 removes the label and forwards.



It’s worth making some notes on this subject to clear up a few misconceptions I found online.

Firstly I setup a lab to confirm what i’m about to say, the reason we use this command is to allow QoS to correctly classify or view the packets based on the original header, if the packet is encapsulated  it’s  treated the same as any other encapsulated packet. The original header and its QoS value is now unknown to the forwarding device.

So by enabling this command we can apply the classification before the encapsulation or tunneling happens.

Apply the command “qos pre-classify” to a tunnel interface, a crypto-map or a virtual tunnel interface.

Classification based on layer3 and layer4 information is the exact reason we would consider using this feature, classification based on TOS or DSCP values do not need to use this feature, that’s because of TOS byte preservation inherently built into IPSEC.

Once you’ve added the pre-classify command, apply a service-policy to the physical interface outbound, then all IP packets will be classified pre-encapsulation on any tunnels egressing that physical interface. In other words you will see hits on the policy-map individual classes.

A really great resource I found online is this QoS values calculator check it out………….


This post will show you how to configure a DHCP scope on your Cisco device.

DHCP uses the transport layer protocol UDP. DHCP server uses port 67 and the client uses port 68. DHCP would fall into layer 7 application layer protocols.

Create your pools just like below and add any options in you require i’ve shown 2 different option types one is IP and one is ASCII. You can add as many options as you need.

ip dhcp pool vlan10
update dns both override
option 137 ascii
option 150 ip
lease 3
ip dhcp pool vlan16
update dns both override
option 150 ip
option 137 ascii
lease 3

To add static DHCP reservations you need to add the MAC address as below. Note they start with ’01’ and in dotted hexadecimal. The ’01’ means that its Ethernet media type.

ip dhcp pool static-user1
client-identifier 01bb.cccc.dddd.ff
ip dhcp pool staticuser2
client-identifier 01xx.yyyy.zzzz.aa

The above configuration would be added to your switch that contains your SVI’s.

Confirm your configuration by using these commands below.

show ip dhcp binding – This will show all assigned IP’s and MAC address.
show ip dhcp pool [pool name] – This will show information on number of IP’s leased.
show ip dhcp conflict – This will show any conflicts in your pools.
clear ip dhcp binding | conflict [x.x.x.x] | * – This will clear the pool of the address you specify or all in the case of *.



The last item on our list is the service-policy, this is the part where we apply our policy-map to an interface and specify the direction for the policy.

To help you visualise how the command is used and which direction see the picture below.


QOS is being applied to traffic coming from inside our network going outbound to the WAN.

Your interface will look something like this.

interface FastEthernet0/0
 description WAN_interface
 bandwidth 20000
 ip address
 ip nbar protocol-discovery
 service-policy output QOS_Egress

To confirm the QOS is working you would use the command “show policy-map interface fastethernet 0/0” this will give you a whole bunch of information, see below for an example of how this might look.

Service-policy output: QOS_Egress

queue stats for all priority classes:

queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 331150787/112001702019

Class-map: voice_traffic (match-all)
266055005 packets, 57655712122 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp ef (46)
Priority: 7% (1400 kbps), burst bytes 35000, b/w exceed drops: 0
QoS Set
dscp ef
Packets marked 266055059

Class-map: voip_signal (match-any)
78149834 packets, 7487646866 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match:  dscp cs3 (24) af31 (26)
78149834 packets, 7487646866 bytes
5 minute rate 0 bps
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 78149832/7487645664
bandwidth 3% (600 kbps)
QoS Set
dscp af31
Packets marked 78149834

Class-map: class-default (match-any)
9073254895 packets, 3302249852254 bytes
5 minute offered rate 998000 bps, drop rate 0 bps
Match: any
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/16751970/0
(pkts output/bytes output) 569664615/3424829483864
QoS Set
dscp default
Packets marked 9071570170
shape (average) cir 16000000, bc 160000, be 160000
target shape rate 16000000

As you can see it gives lots of information on how your QOS is performing, the default-class shows some drops that means its had to drop some packets when the link was congested and in fact means your QOS policy is doing its job if the drops were excessive you would increase the values or decrease whichever suits your network.

If you just want to view an indivdual class then you would use the command “show policy-map interface fastethernet 0/0 output class web_traffic” for example.

When using the “service-policy input QOS_Egress” you will receive an error stating that you cannot apply this to the interface, this is becuase CBWFQ is a mechanism for traffic queuing in the outbound direction, never for the inbound direction.

I hope my 3 part blog has gone some way to helping you understand QOS.


My last blog covered class-map’s, which were used to identify traffic to our device, the next part of QOS covers what the device does with the traffic after its been identified. This is called a policy-map.

So you create your policy with the following command

R1#conf t
R1#(config)policy-map QOS_Egress

Next you need to reference each class-map then tell the device what to do with that traffic. Here’s an example

class voice_traffic
priority percent 7
set ip dscp ef
class voip_signal
bandwidth percent 3
set ip dscp af31
class SQL_App
bandwidth 20000
set ip dscp 26
class telnet_traffic
bandwidth percent 3
set ip dscp af21
class citrix_traffic
bandwidth percent 10
set ip dscp af41
class my_desktop
bandwidth percent 40
set ip dscp 18
class web_traffic
police rate percent 15
set ip dscp 10
class class-default
set ip dscp default
shape average percent 80

I’ve used some different actions on my policy map, “priority” and “bandwidth” are worth some discussion.

The idea with priority is just as it sounds, that’s your most important traffic class hence why it’s used for voice, so in my policy-map I’ve reserved 7% bandwidth, on a 20mbps circuit that would mean when the link is saturated, any voice traffic upto 1400kbps would be given priority over all other traffic. The difference that priority has over bandwidth is built-in policer, provides low latency, manages delay and jitter.

For your environment you may need more or less than 7% depending on what codecs you use between your IP phones.

Bandwidth defines the minimum bandwidth guarantee to that class, this can be specified in percentage of the interface bandwidth or in kbps. With CBWFQ the excess bandwidth is divided up amongst the remaining classes if it’s not already being used by the default-class.

Traffic shaping can be applied to the default-class as a way of ensuring your link is never fully utilized by unimportant traffic, what it does in this case is only ever allows maximum outbound traffic for the default-class to reach 80% of the interface rate.

Police means the maximum rate that is always applied to that class, the difference between police and shape is that police will drop packets and shape will buffer them, policing the traffic is alot more complicated than what I’ve explained, this is just simple terms.

DSCP values are set on my policy-map for  inbound traffic to my WAN, so in advance I would speak with my WAN provider and break up all the different DSCP values into classes like gold, silver, bronze then once the WAN provider receives a layer 3 packet with a DSCP value assigned it can decide how to process the packet when the link is congested.

There are lots of variations you can use with policy-maps, you can use nested policy-maps aswell, but this is just a brief overview of what you can achieve with QOS.

Remember you need to have end to end QOS, that means determining trust boundaries. For example from IP phone to IP Phone would be end to end QOS, if you don’t mark the packets coming from your IP Phone then the router will classify them as default traffic, by default your IP phone will send voice traffic marked as EF, You need to connect it to a switchport that at the very least has the command “trust cos


Quality Of Service is one of my favourite subjects the more I learn about it, the more I realise what i don’t know!

So the idea with QOS is you can classify different types of traffic using a class-map, then you can create a policy-map and specify what to do with that traffic, Next you apply the service-policy to an interface either inbound or outbound.

QOS really comes into its own in a  VoIP system, when your WAN link bandwidth is saturated you need to make sure that your VoIP traffic skips to the front of the queue giving the user the clear and uninterrupted call they expect. Remember that QOS only works when its deployed end to end.

My assumption here is you know what DSCP values are.

So lets look at a class-map this is the first part of our configuration, what a class-map does is identify traffic to your router, traffic can be identified at layer 3, layer 4 or layer 7.

This class-map matches DSCP EF (expedited forwarding) which is what voice traffic is marked, this is the most important and should be given top priority. I’ve included is voice_signal traffic which is marked as cs3 or af31, next matches applications, this is used in conjunction with NBAR, below we’ve matched some well known ones SQL, Telnet & Citrix. I’ve thrown in a class-map that can match ip address’s specified in access-list 10 and an extended access-list for matching tcp traffic.

Your router will parse each line sequentially, this is the same with your policy-map.

class-map match-all voice_traffic
 match ip dscp ef
class-map match-any voip_signal
 match ip dscp cs3 af31
class-map match-any SQL_App
match protocol sqlserver
class-map match-all telnet_traffic
  match protocol telnet
class-map match-all citrix_traffic
  match protocol citrix
class-map match-any my_desktop
 match ip access-group 10
class-map match any web_traffic
 match ip access-group 101
access-list 10 permit  
access-list 101 permit tcp any any eq www

Now you have your class-map your router can now identify traffic that passes through it.

So part 1 of this blog has covered identifying traffic to your router next we will cover policy-maps which decide what the router does with the traffic, so the class-map identifies the traffic and the policy-map defines the action for that traffic.

See you soon for my next part!


A common scenario you might come across is having a device on your network that needs to be restricted. So for example a third party PC that doesn’t meet your security requirements but needs to access a production server.

If your network can support it then you would segment this part of your network with a VLAN then route between them on a layer 3 switch or at the router. So in my example its a layer 3 switch, write the access list then apply it at the VLAN interface either inbound or outbound.

Below is the basic config for VLAN 10, anything in this VLAN will only be able to access the production server at which happens to be on VLAN 20, this would apply to devices or whole subnets on a different switch or even across the WAN. I’ll make this interesting and allow the clients only access on TCP port 80, and also allow the clients to lookup DNS on the same server this is UDP port 53.


Create your ACL
ip access-list extended 100
permit ip any
permit tcp any host eq www
permit udp any host eq domain
deny ip any any log 

Apply your ACL to the VLAN interface
interface vlan 10
ip access-group 100 in

That’s all you have to do to restrict the traffic, its very simple the inbound and outbound commands are hard to understand at first but just imagine yourself standing on top of the switch and think of traffic direction, so in my case its inbound to the switch.