This topic is to discuss the following lesson:
1 Like
Thank you very much. This is really very good topic and it is very clear to me.
Thanks Renee! I’m gaining some traction on QOS
Hello Renee
Thanks for your excellent introduction!
Here I have one concern, which “Tool” is better to identify the specific traffic? For example, If want to perform QoS for one of applications named ABC, how does router know which traffic is for Application - ABC?
Â
Thanks
Dong
Hi Dong,
If it’s a well known application like HTTP, HTTPS, SMTP, POP3, IMAP, SQL, etc. then NBAR can recognize them. Otherwise, it’s best to use an access-list to match the port numbers of your application.
Rene
Hello Rene
Thanks for your feedback, and then, what’s the best way to get the port numbers of some particular applications?
Â
Thanks
Dong
Hi Dong,
If you have “well known” applications like HTTP, FTP, telnet, SSH, etc. then it’s easy to look them up. You can google for the RFCs to find the official documentation. Here’s an example for HTTP:
https://tools.ietf.org/html/rfc2616
If it’s an application from some vendor, contact them…most of them offer an overview with addresses / protocols / port numbers that should be allowed. Here’s a good example from Airwatch:
Hope this helps.
Rene
Hi, Rene,
my question is, how can I classify the encrypted traffic of a certain traffic category? If I want to classify all streaming video traffic and I don’t know the ports or IP addresses of the video streaming sources. And we know that great deal of traffic is encrypted (https) nowadays.
Is there a possibility?
Thanks.
Primoz
Hi Primoz,
If your traffic is encrypted with IPsec then you could use QoS pre-classify. You’ll have to mark the non-encrypted traffic before it enters the tunnel:
If it’s HTTPS traffic then it will be difficult. From the outside, you can’t really tell what kind of traffic you are transmitting. If possible, see if your application can be configured to mark your traffic. If this is possible then you don’t have to classify/mark on the router, you can queue right away.
Rene
Hi Rene,
Can you give me an example of using match not classification ?? and in situation we used it ??
Hello Hussein.
The match not criterion for a class map matching statement essentially says “anything that doesn’t match what follows”. It is similar to “not equal to” in programming or logic. If we use the example in the lesson, and the command entered was:
R2(config-cmap)#match not access-group name TELNET
then the result would be that the policy map would match everything EXCEPT what is found in the access-list named TELNET.
In other words, the policy would match everything and would not match anything using port 23.
It is just another tool to be able to express what you require to be matched in the policy map and can be useful to more specifically define your requirements.
I hope this has been helpful!
Laz
2 Likes
Hi Laz ,
In simple term what’s the difference between class map and policy-map ?
Class-map is to make the marking and classification of interesting traffic
Policy-map is to make the action effective that define in class map by placing in inbound / outbound interface.
is the above statement correct ?
Thanks.
Tanmoy
Hello Tanmoy
Policy maps and class maps are two different components that function together to get a result. They are two different parts of the same hierarchy. If we include access lists, the hierarchy can be seen like so:
Policy Map
Class Map
Access list
Policy maps contain class maps which reference access lists.
A policy map is a container inside which class maps reside. Policy maps are applied to things like interfaces. Class maps contain actions or instructions to be carried out. These depend on conditions that are evaluated using access lists, which are referenced by the class maps.
Is that simple enough? If you want further clarification let me know.
I hope this has been helpful!
Laz
Hello Laz ,
That’s nice explanation .
I have also a simple doubt
what’s the difference between policing and shaping ?
From service assurance point of view which is better among them ??
Thanks
Tanmoy
Hello Tanmoy
Both policing and shaping have the same goal: to limit the rate of traffic on a particular interface. But they do it in different ways, and have different results.
Policing will limit the traffic by dropping packets that exceed the configured rate. Any resulting errors in affected transmissions are dealt with using any error correction mechanisms that may exist at higher Layers, such as at the Transport Layer or the Application Layer.
Shaping on the other hand will limit traffic by attempting to buffer excess packets in a queue and then scheduling the sending of those queued packets for later transmission over increments of time. This results in few or no lost packets (depending on how well the queues function, and how much excess traffic arrives), thus alleviating the upper layers from performing excess error recovery.
An excellent illustration of how this affects traffic can be seen in the following image:
Which is better? Policing takes fewer resources than shaping, as no extra CPU and memory are necessary to orchestrate the queuing, but shaping gives you better quality network services. If you’re an ISP enforcing the limitation of bandwidth on a customer’s connection, you would probably choose policing. If you are configuring the edge router of the enterprise network to function at a specific WAN speed, you would choose shaping in order to provide better network quality to the services being served.
I hope this has been helpful!
Laz
By default Router marks some routing protocol traffic to a value …does router forward them first when there is a congestion even if i have not enabled the QOS on router ??
Hello Narad
There are some platforms that have some default control plane QoS features. These platforms include the Nexus series of devices for example. Because these are datacenter-oriented devices, they have a baseline QoS and security policy that is built into their config by default. If you take a look at their default config, you will see many default class-maps preconfigured, and applied.
A device that has been configured like this by default will also act on these configs by default. Note that lower-end devices don’t have any QoS features preconfigured, and QoS must be manually enabled and configured to operate.
I hope this has been helpful!
Laz
Guys, in case you know what may be going on…
I’m running Cisco IOSV images on GNS3 to simulate the commands in the lesson.
I enabled NBAR into R2:
R2(config)#interface g0/0
R2(config-if)#ip nbar protocol-discovery
And run some tests from R1:
R1#ping 192.168.12.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R1#telnet 192.168.12.2
Trying 192.168.12.2 ...
% Connection refused by remote host
R1#ssh -l admin 192.168.12.2
% Connection refused by remote host
However, while NBAR classifies the icmp traffic, it doesn’t classify the telnet and ssh traffics.
R2#show ip nbar protocol-discovery interface g0/0
GigabitEthernet0/0
Last clearing of "show ip nbar protocol-discovery" counters 00:21:40
Input Output
----- ------
Protocol Packet Count Packet Count
Byte Count Byte Count
5min Bit Rate (bps) 5min Bit Rate (bps)
5min Max Bit Rate (bps) 5min Max Bit Rate (bps)
------------------------ ------------------------ ------------------------
icmp 9 9
1026 1026
0 0
0 0
Total 9 9
1026 1026
0 0
0 0
R2#show policy-map interface g0/0
GigabitEthernet0/0
Service-policy input: CLASSIFY
Class-map: NBAR-TELNET (match-all)
0 packets, 0 bytes
5 minute offered rate 0000 bps
Match: protocol telnet
Class-map: class-default (match-any)
10 packets, 889 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
All telnet packets increment the class-map class-default, not the NBAR-TELNET class-map. Also, the packets do NOT increment the “Total” counters from the show ip nbar protocol-discovery command, so it means NBAR is not even trying to classify them.
For curiosity, I observed that my Cisco IOSV image has the correct protocol-pack, where both telnet and ssh definitions exists:
R2# show ip nbar protocol-pack active
Active Protocol Pack:
Name: Standard Protocol Pack
Version: 14.0
Publisher: Cisco Systems Inc.
NBAR Engine Version: 23
State: Active
R2# show ip nbar protocol-pack active taxonomy
[...]
<protocol>
[...]
<common-name>Telnet</common-name>
<enabled>true</enabled>
[...]
<name>telnet</name>
<ports>
<tcp>23</tcp>
<udp>23</udp>
</ports>
[...]
</protocol>
Questions: Why NBAR is not classifying telnet/ssh traffic to me (while correctly classifying ICMP)? Am I doing anything wrong? What can be occurring?
Hello Rarylson
Thanks for your detailed post! Hmm, that’s interesting. The first thing I can think of right off the bat is that for both the telnet and SSH attempts, the connection was refused by the remote host. Remember, NBAR is used to classify and regulate bandwidth for network applications to ensure that available resources are utilized as efficiently as possible.
It may be that for applications that use TCP (such as telnet and SSH), in order to do that, a session for that application must be established. This is just a guess, and will only be proved if tested. A quick and dirty test you could do is to configure telnet or SSH connectivity on the router and successfully establish a session. Send some commands, and then check the results using the same show command you did before.
Let us know how you get along so that we can continue helping in your troubleshooting process.
I hope this has been helpful!
Laz
Hi Lazaros, you are correct!!!
I enabled both telnet and SSH, and now NBAR classifies the traffic.
R2#show ip nbar protocol-discovery
GigabitEthernet0/0
Last clearing of "show ip nbar protocol-discovery" counters 00:07:49
Input Output
----- ------
Protocol Packet Count Packet Count
Byte Count Byte Count
5min Bit Rate (bps) 5min Bit Rate (bps)
5min Max Bit Rate (bps) 5min Max Bit Rate (bps)
------------------------ ------------------------ ------------------------
ssh 27 32
3927 2976
0 0
1000 1000
telnet 16 19
1629 1146
0 0
0 0
icmp 5 5
570 570
0 0
0 0
Total 48 56
6126 4692
0 0
1000 1000
It totally makes sense. BEFORE the 3-way handshake, the telnet or SSH protocols are not even being used (we didn’t send any packet with telnet/SSH information at the application layer), so NBAR doesn’t classify the traffic. In my previous test, it was just a TCP SYN followed by a ICMP “connection refused” message, by no application-level message was being sent at any moment.
NBAR is used to classify packets based on application layer, while extended ACLs can be used to classify based on just layer-4 protocol and port. Let’s take the SSH example. This is why I was able to classify the traffic using extended ACLs (matches TCP at port 22) but not using NBAR (no SSH layer-7 message was sent at any time, because the TCP connection wasn’t even opened).