Call Girls in Nagpur Suman Call 7001035870 Meet With Nagpur Escorts
QoS Pre-Classify on Cisco IOS
1. QoS Pre-Classify on Cisco IOS
Quality of Service (QoS) | www.netprotocolxpert.in
2. • When we use tunnelling, your Cisco IOS router will do classification based on
the outer (post) header, not the inner (pre) header. This can cause issues with
QoS policies that are applied to the physical interfaces. I will explain the issue
and we will take a look how we can Fix it. Here’s the topology that we will use:
3. • Using a static route so that R1 and R3 can reach each other’s
loopback interfaces through the tunnel:
• R1(config)#interface Tunnel 0
• R1(config‐if)#tunnel source 192.168.12.1
• R1(config‐if)#tunnel destination 192.168.23.3
• R1(config‐if)#ip address 172.16.13.1 255.255.255.0
• R1(config)#ip route 3.3.3.3 255.255.255.255 172.16.13.3
• The configuration on R3 is similar:
• R3(config)#interface Tunnel 0
• R3(config‐if)#tunnel source 192.168.23.3
• R3(config‐if)#tunnel destination 192.168.12.1
• R3(config‐if)#ip address 172.16.13.3 255.255.255.0
• R3(config)#ip route 1.1.1.1 255.255.255.255 172.16.13.1
4. Default Classification Behaviour
• The tunnel is up and running, before we play with classification and service
policies, let’s take a look at the default classification behaviour of Cisco IOS
• IOS will copy the information in theTOS (Type of Service) byte from the
inner IP header to the outer IP header by default.We can demonstrate this
with a simple ping.
5. • Loose, Strict, Record,Timestamp,
Verbose[none]:
• Sweep range of sizes [n]:
• Type escape sequence to abort.
• Sending 5, 100‐byte ICMP Echos to 3.3.3.3,
timeout is 2 seconds:
• Packet sent with a source address of 1.1.1.1
• !!!!!
• Success rate is 100 percent (5/5), round‐trip
min/avg/max = 1/2/4 ms
• R1#ping
• Protocol [ip]:
• Target IP address: 3.3.3.3
• Repeat count [5]:
• Datagram size [100]:
• Timeout in seconds [2]:
• Extended commands [n]: y
• Source address or interface: 1.1.1.1
• Type of service [0]: 160
• Set DF bit in IP header? [no]:
• Validate reply data? [no]:
• Data pattern [0xABCD]:
6. • This ping between 1.1.1.1 and 3.3.3.3 will go through the tunnel and I marked the TOS
byte of this IP packet with 160 (decimal). 160 in binary is 10100000, remove the last
two bits and you have our 6 DSCP bits. 101000 in binary is 40 in decimal which is the
same as the CS5.
wireshark capture of this ping:
Cont.…
7.
8. • As we can see, Cisco IOS automatically copied the TOS byte from the inner
IP header to the outer IP header. This is a good thing, We are using GRE in
our example so we can see both headers but if this was an encrypted IPSEC
tunnel then we (and any device in between) could only see the outer header.
• When you have QoS policies based on the TOS byte then you will have no
problems at all because the TOS byte is copied from the inner to the outer
header. We will run into issues when you have policies based on access-lists
that match on source / destination addresses and/or port numbers.
9. Post Header Classification
• We are going to create two class-maps, one for telnet traffic and another one for
GRE traffic. Both class-maps will use an access-list to classify traffic:
• R1(config)#ip access‐list extendedTELNET
• R1(config‐ext‐nacl)#permit tcp any any eq telnet
• R1(config)#class‐mapTELNET
• R1(config‐cmap)#match access‐group nameTELNET
• R1(config)#ip access‐list extended GRE
• R1(config‐ext‐nacl)#permit gre any any
• R1(config)#class‐map GRE
• R1(config‐cmap)#match access‐group name GRE
10. The two class-maps will be used in a policy-map:
• R1(config)#policy‐map POLICE
• R1(config‐pmap)#classTELNET
• R1(config‐pmap‐c)#police 128000
• R1(config‐pmap‐c‐police)#exit
• R1(config‐pmap‐c)#exit
• R1(config‐pmap)#class GRE
• R1(config‐pmap‐c)#exit
• R1(config‐pmap)#exit
11. • We’ve added policing for telnet traffic and nothing for GRE. It doesn’t matter
what “actions” we configure here, even without an action the traffic will still be
classified and it will show up in the policy-map. Let’s activate it on the physical
interface:
• R1(config)#interface FastEthernet 0/0
• R1(config‐if)#service‐policy output POLICE
• Something to keep in mind is that when you enable a policy on the physical
interface, it will be applied to all tunnel interfaces.
• Generate some telnet traffic between R1 and R3 so it goes through the tunnel:
• R1#telnet 3.3.3.3 /source‐interface loopback 0
• Trying 3.3.3.3 ... Open
14. • We don’t have any matches for the telnet traffic.
• If this was a real network, it means that telnet traffic will never get policed
(or any other action you configured). The reason that we don’t see any
matches is because Cisco IOS first encapsulates the IP packet and then
applies the policy to the GRE traffic.
15. Encapsulates the IP packet
The blue IP header on top is our original IP packet with telnet traffic, this is
encapsulated and the router adds a GRE header and a new IP header (the red
one).The policy-map is then applied to this outer IP header.
16. Pre Header Classification (Physical Interface)
• The first method to solve this issue is to enable pre-classification on the
tunnel interface. This tells the router to create a copy of the original IP
header and to use that for the policy. Here's how to do this:
• R1(config)#interfaceTunnel 0
• R1(config‐if)#qos pre‐classify
17. • R1#clear counters
• Clear "show interface" counters on all interfaces [confirm]
• R1#telnet 3.3.3.3 /source‐interface loopback 0
• Trying 3.3.3.3 ... Open
18. Now take a look at the policy-map:
• R1#show policy‐map interface FastEthernet 0/0
• FastEthernet0/0
• Service‐policy output: POLICE
• Class‐map: TELNET (match‐all)
•11 packets, 735 bytes
•5 minute offered rate 0 bps, drop rate 0 bps
•Match: access‐group nameTELNET
•police:
•cir 128000 bps, bc 4000 bytes
•conformed 11 packets, 889 bytes; actions:
•transmit
Cont.…
19. • exceeded 0 packets, 0 bytes; actions:
•drop
• conformed 0 bps, exceed 0 bps
• Class‐map: GRE (match‐all)
• 0 packets, 0 bytes
• 5 minute offered rate 0 bps
• Match: access‐group name GRE
• Class‐map: class‐default (match‐any)
• 1 packets, 60 bytes
• 5 minute offered rate 0 bps, drop rate 0 bps
• Match: any
Now we see matches on our
telnet traffic so it can be
policed if needed. We don't
see any matches on our GRE
traffic anymore.
20. When the router encapsulates a packet, it will make a temporary copy of the
header. This temporary copy is then used for the policy instead of the outer
header. When this is done, the temporary copy is destroyed.
We accomplished this with the qos pre-classify command but there is another
method to get the same result.
21. Pre Header Classification (Tunnel Interface)
• Instead of activating the policy on the physical interface we can also
enable it on the tunnel interface:
• R1(config)#interface FastEthernet 0/0
• R1(config‐if)#no service‐policy output POLICE
• R1(config)#interfaceTunnel 0
• R1(config‐if)#no qos pre‐classify
• R1(config‐if)#service‐policy output POLICE
22. • Note that I also removed the qos pre-classify command on the
tunnel interface. Let's give it another try:
• R1#clear counters
• Clear "show interface" counters on all interfaces [confirm]
• R1#telnet 3.3.3.3 /source‐interface loopback 0
• Trying 3.3.3.3 ... Open
25. • If you enable the policy on the tunnel interface then the router will
use the inner header for classification, just like we saw when we
used the qos pre-classify command on the tunnel interface.
• That's all there is to explain. We hope this lesson has been useful to
understand the difference between "outer" and "inner" header
classification and how to deal with this issue.