Advanced Cisco Routing: Summary Addresses

So this probably isn't really an advanced routing topic, but it's not something I ran into while working on my CCNA, either...

Anyway.

Consider the following network:


On the left, we have our server farm (okay, it's a rather small data center). On the right, we have our desktop users (see previous comment, lol). Because we actually engineer our network, we have divided our network up into logical units, each on its own subnet. R2, R3 and R4 are department routers, each hosting a subnet -- say, 192.168.2.0/24 for R2, 192.168.3.0/24 for R3 and 192.168.4.0/24 for R4. R5 is the data center router, and all of the hosts in the data center are on the 172.16.0.0/24 subnet. R1 is our dist router, and uses 192.168.1.x/30 for each of its links to R2, R3 and R4, as well as using 10.0.0.0/30 for the link to R5. IRL, we should probably be using another 192.168.1.x/30 subnet for the R1 -- R5 link, but I'm actually treating R5 as both an edge and dist router here. I've enabled EIGRP on all five routers.

By default, EIGRP will try to summarize all of the routes by class; i.e., networks from 0.0.0.0 to 127.255.255.255 will be Class-A networks, networks from 128.0.0.0 through 191.255.255.255 will be Class-B networks, and networks from 192.0.0.0 through 223.255.255.255 will be Class-C network, no matter how you've actually subnetted them.

Modern best-practice, however, is not to do that, as free IPv4 address space is becoming increasingly rare, and therefore, you tend to see Class-A, Class-B and even Class-C networks subnetted into smaller blocks of IP space, as we've done on R5's LAN, on the link between R1 and R5, and on each of the links between R1 and R2, R3 and R4 here. Consequently, when using EIGRP in modern production networks, you will typically see the command "no auto-summary" somewhere in the EIGRP configuration.

However, on a large production network, this can be really ugly, as you see /30 network after /30 network listed in the "sho ip route" ouptut:
R5#sho ip route
<...snip...>
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.0.0 is directly connected, Vlan10
D EX 192.168.4.0/24 [170/30976] via 10.0.0.1, 00:00:04, FastEthernet1/0
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
D EX 10.254.254.2/32 [170/158720] via 10.0.0.1, 00:00:04, FastEthernet1/0
D EX 10.254.254.3/32 [170/158720] via 10.0.0.1, 00:00:04, FastEthernet1/0
C 10.0.0.0/30 is directly connected, FastEthernet1/0
D EX 10.254.254.1/32 [170/156160] via 10.0.0.1, 00:00:04, FastEthernet1/0
D EX 10.254.254.4/32 [170/158720] via 10.0.0.1, 00:00:04, FastEthernet1/0
C 10.254.254.5/32 is directly connected, Loopback0
192.168.1.0/30 is subnetted, 3 subnets
D 192.168.1.8 [90/30720] via 10.0.0.1, 00:00:04, FastEthernet1/0
D 192.168.1.0 [90/30720] via 10.0.0.1, 00:00:04, FastEthernet1/0
D 192.168.1.4 [90/30720] via 10.0.0.1, 00:00:04, FastEthernet1/0
D EX 192.168.2.0/24 [170/30976] via 10.0.0.1, 00:00:04, FastEthernet1/0
D EX 192.168.3.0/24 [170/30976] via 10.0.0.1, 00:00:04, FastEthernet1/0
R5#

Notice that there are six 192.168.x.x subnets shown in the output of the "sho ip route" command on this router, and this is a SMALL network, so imagine how it would look on the service-provider network where I work! Not only does it make it more difficult to parse the output of the "sho ip route" command, but EIGRP on R1 has to advertise each of these networks separately to R5, making the update larger than it has to be.

Fortunately, this isn't an all-or-nothing choice. It is possible to have EIGRP summarize some routes, but advertise individual subnets for others. Furthermore, you don't have to summarize into a classful network -- you can use any valid IP subnet to summarize the routes. In the example network shown in this lab, we have 192.168.1.0/30, 192.168.1.4/30, 192.168.1.8/30, 192.168.2.0/24, 192.168.3.0/24 and 192.168.4.0/24 in use. The smallest valid subnet that contains all of these networks would be 192.168.0.0/21 (192.168.0.0 -- 192.168.7.255). If we assume that that IP space is reserved for use by R1 and edge routers hanging off of R1, then we can have R1 summarize the 192.168.x.x subnets into one single route advertisement for this entire range:
R1(config)#int fa0/0
R1(config-if)#ip summary-address eigrp 10 192.168.0.0 255.255.248.0
R1(config-if)#
01:44:20: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 10.0.0.2 (FastEthernet0/0) is down: summary configured
R1(config-if)#
01:44:23: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 10.0.0.2 (FastEthernet0/0) is up: new adjacency
R1(config-if)#

Now, if we look at the routes on R5, we will see that, rather than advertising six 192.168.x.x subnets, R1 is only advertising a single /21 that contains each of the previous six subnets:
R5#sho ip route
<...snip...>
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.0.0 is directly connected, Vlan10
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
D EX 10.254.254.2/32 [170/158720] via 10.0.0.1, 00:03:55, FastEthernet1/0
D EX 10.254.254.3/32 [170/158720] via 10.0.0.1, 00:03:55, FastEthernet1/0
C 10.0.0.0/30 is directly connected, FastEthernet1/0
D EX 10.254.254.1/32 [170/156160] via 10.0.0.1, 00:03:56, FastEthernet1/0
D EX 10.254.254.4/32 [170/158720] via 10.0.0.1, 00:03:55, FastEthernet1/0
C 10.254.254.5/32 is directly connected, Loopback0
D 192.168.0.0/21 [90/30720] via 10.0.0.1, 00:03:55, FastEthernet1/0  <---
R5#

Cool!

Cisco Intro to QoS and CoS, Part 4 -- Shape Average vs. Bandwidth in Policy Maps

If you've poked around at all with the policy-map statement, you've probably noticed that there are several options for configuring how much bandwidth to allocate to different classes within the QoS config. Let's look at two of the options, shape average and bandwidth.

We'll use the following network...:


...and the following configuration:
ip access-list extended PRIORITY-IN
 permit ip 192.168.1.0 0.0.0.255 any
 permit ip any 192.168.1.0 0.0.0.255
 deny ip any any
ip access-list extended SCAVENGER-IN
 permit ip 192.168.2.0 0.0.0.255 any
 permit ip any 192.168.2.0 0.0.0.255
 deny ip any any
!
class-map match-any PRIORITY
 match dscp af41
class-map match-any SCAVENGER
 match dscp cs1
!
class-map match-any PRIORITY-IN
 match access-group name PRIORITY-IN
class-map match-any SCAVENGER-IN
 match access-group name SCAVENGER-IN
!
policy-map REMARK_ALL
 class PRIORITY-IN
  set dscp af41
 class SCAVENGER-IN
  set dscp cs1
policy-map EGRESS-SHAPER
 class PRIORITY
  shape average percent 70
 class SCAVENGER
  shape average percent 5
policy-map EGRESS-BANDWIDTH
 class PRIORITY
  bandwidth percent 70
 class SCAVENGER
  bandwidth percent 5
!

For my first test, I set up the policy-map, "EGRESS-SHAPER," on interface eth3/0 on both routers, and set up the "REMARK_ALL" service policy on the ingress interfaces (fa0/0 on both routers, and fa1/0 on R1):
interface FastEthernet0/0
 service-policy input REMARK_ALL
!
interface FastEthernet1/0
 service-policy input REMARK_ALL
!
interface Ethernet3/0
 service-policy output EGRESS-SHAPER
!

Then, I set up iperf as a service on host "Knoppix" and ran iperf as a client on both Knoppix Clones, using the flags "-i 1 -t 120," finding that Knoppix Clone 1 could send data at a little over 5Mbps, and Knoppix Clone 2 sent data at about 500Kbps. I then re-ran the test using the service policy "EGRESS-BANDWIDTH," where I saw a transfer speed of just over 4Mbps for Knoppix Clone 1 and about 1 1/3Mbps for Knoppix Clone 2. That surprised me; I didn't really understand why my bandwidth decreased in class PRIORITY (Knoppix Clone 1) and increased in class SCAVENGER (Knoppix Clone 2). To understand what was happening, I did some more tests, using both TCP and UDP transfers ("-u -b 10M" for the flags to set a UDP test at up to 10Mbps), and with both hosts in contention for bandwidth as well as with the hosts transferring data one at a time (i.e., run iperf on Knoppix Host 1, and then running it on Knoppix Clone 2 after the test completed on Knoppix Clone 1). Here are the results from all of the tests:

Congested:
  TCP:
    Using EGRESS-SHAPER:
      192.168.1.x: 5.15Mbps
      192.168.2.x: 0.48Mbps

    Using EGRESS-BANDWIDTH:
      192.168.1.x: 4.16Mbps
      192.168.2.x: 1.36Mbps


  UDP:
    Using EGRESS-SHAPER:
      192.168.1.x: 3.07Mbps
      192.168.2.x: 0.16Mbps

    Using EGRESS-BANDWIDTH:
      192.168.1.x: 2.8Mbps
      192.168.2.x: 1.26Mbps


Uncongested:
  TCP:
    Using EGRESS-SHAPER:
      192.168.1.x: 5.76Mbps
      192.168.2.x: 0.50Mbps

    Using EGRESS-BANDWIDTH:
      192.168.1.x: 5.52Mbps
      192.168.2.x: 5.51Mbps

  UDP:
    Using EGRESS-SHAPER:
      192.168.1.x: 5.82Mbps
      192.168.2.x: 0.47Mbps

    Using EGRESS-BANDWIDTH:
      192.168.1.x: 6.03Mbps
      192.168.2.x: 6.14Mbps

What's happening here is that "shape average" tells the router to strictly allocate the specified amount of bandwidth to the various traffic classes. Even if more bandwidth is available through the interface, the allocated bandwidth is all that the traffic class will receive. When using the "bandwidth" statement, however, the router will allow the traffic classes to use all of the available bandwidth. Since class PRIORITY takes, well, priority over class SCAVENGER, when there is traffic in both traffic classes, class SCAVENGER will only receive the allocated bandwidth. However, when there is little or no priority traffic on the interface, the router will allow class SCAVENGER to "borrow" bandwidth from the other traffic classes in the service policy (in this case, class PRIORITY). Consequently, when there was no contention for bandwidth, class SCAVENGER can get the full data rate on the interface*.

*Q: Wait a minute! An Ethernet port runs at 10Mbps, but these results are showing about 6Mbps. What happened to the other 4Mbps?
A: Keep in mind that an Ethernet port runs at half duplex, meaning that the same copper wire is used for both transmit and receive. Therefore, the 10Mbps bandwidth available on the Ethernet port has to be shared between transmit and receive.**

**Q: Okay, so that explains why it's not 10Mbps, but in that case, shouldn't the data rate be lower, like 5Mbps?
A: If both sides were transmitting data at line rate, then yes. However, in this case the flow of data is mostly one-sided, especially with the UDP traffic, where there is no ACK being sent back to the two Knoppix Clones.***

***Q: In that case, should the data rate be higher?
A: The devil is in the details, and there are a lot of details to consider ;) "Customer" data isn't all that is flowing between R1 and R2. R1 and R2 are also sending their own data back and forth, for example, OSPF updates, CDP updates, etc. Consequently, while the flow of data between R1 and R2 is mostly one-sided, it's not completely one sided. If you REALLY want a good understanding of what's happening, replace R2 with the Knoppix host and run wireshark to capture the packets during a test. I'll leave that as an exercise for the reader ;)

Cisco Intro to QoS and CoS, Part 3 -- Classifying Traffic with NBAR

In our QoS labs so far, we've had to find some way to identify traffic, usually by creating an ACL to match packets against some criteria, such as source/destination port, source/destination IP address, or protocol (TCP/UDP/ICMP), etc. However, Cisco offers another way to match traffic: NBAR, or "Network Based Application Recognition. I created the following network in GNS3 to start playing with NBAR:

To enable NBAR on a router, you first need to turn on CEF, and then you need to enable NBAR on any interface that will have a service policy to mark and classify traffic. In this network, I am using an NM-16ESW switchport module in slot 0, so while Fa0/0 is technically the ingress port, I would enable NBAR on my VLAN interface (int VLAN10). If you are using a plain FastEthernet port rather than a switch module, then you would enable NBAR on the Fa port. In either case, here is how to do it:
R4(config)#ip cef
R4(config)#int vlan 10
R4(config-if)#ip nbar protocol-discovery

After enabling NBAR, we'll need to design our QoS schema. Let's start by identifying the types of traffic on our network, and by deciding what traffic will take priority over other traffic. I came up with the following (admittedly hokey) schema, ordered by priority:

1. EIGRP
2. HTTP (simulating voice/video with a streaming mp4 file)
3. Telnet
4. SNMP
5. SSH
6. ICMP

I then mapped this traffic to the following traffic classes:

Traffic	DSCP Value
EIGRP	CS6
HTTP	EF
Telnet	AF41
SNMP	CS3
SSH	AF21
ICMP	CS2

Cool! Let's start configuring the class-maps on R4, R5 and R6:
R4(config)#class-map match-all EIGRP
R4(config-cmap)#match protocol eigrp
R4(config-cmap)#class-map match-all HTTP
R4(config-cmap)# match protocol http
R4(config-cmap)#class-map match-all SSH
R4(config-cmap)# match protocol ssh
R4(config-cmap)#class-map match-all TELNET
R4(config-cmap)# match protocol telnet
R4(config-cmap)#class-map match-all SNMP
R4(config-cmap)# match protocol snmp
R4(config-cmap)#class-map match-all ICMP
R4(config-cmap)#match protocol icmp

...and now, the policy-map to use these classes:
R4(config-cmap)#policy-map REMARK_ALL
R4(config-pmap)#description policy-map to place traffic into the appropriate traffic class
R4(config-pmap)# class EIGRP
R4(config-pmap-c)# set ip dscp cs6
R4(config-pmap-c)# class HTTP
R4(config-pmap-c)# set ip dscp ef
R4(config-pmap-c)# class SSH
R4(config-pmap-c)# set ip dscp af21
R4(config-pmap-c)# class TELNET
R4(config-pmap-c)# set ip dscp af41
R4(config-pmap-c)# class SNMP
R4(config-pmap-c)# set ip dscp cs3
R4(config-pmap-c)# class ICMP
R4(config-pmap-c)# set ip dscp cs2

Now, just enable the policy map in your ingress interface (VLAN10 in this lab), and you are done:
R4(config-if)#int vlan10
R4(config-if)# service-policy input REMARK_ALL

Pretty easy, huh? To utilize NBAR to identify traffic from various protocols, all you have to do is use the "match protocol <protocol>" statement inside a class-map and NBAR will identify the traffic for you! Keep in mind, however, that NBAR is deep-packet inspection -- it isn't just a simple match for port number and IP address -- and therefore, this functionality comes at a cost of CPU cycles (unless you are using a more recent model switch/router that off-loads the packet inspection to a separate processor). Consequently, if a simple ACL will meet your needs, it MAY be less resource intensive to use the ACL, as we've done in earlier labs. However, if you have a higher-powered router, NBAR certainly makes identifying and classifying traffic much easier on the network admin.

Note:
This is just a really simple example of NBAR, and doesn't even begin to scratch the surface of what NBAR can do for you. For example, when matching the HTTP protocol, you can create multiple classes based upon the host in the HTTP request and you can even use a regex to pattern-match within the URL. You can also extend NBAR with external files to add support for protocols that are not already built in.

For the sake of completeness, here is the rest of the QoS configuration on R4: R4(config)#class-map match-any PRIORITY
R4(config-cmap)# match ip dscp ef
R4(config-cmap)#class-map match-any CONTROL
R4(config-cmap)# match ip dscp cs6
R4(config-cmap)#class-map match-any CRITICAL
R4(config-cmap)# match ip dscp af41
R4(config-cmap)# match ip dscp cs3
R4(config-cmap)#class-map match-any ROUTINE
R4(config-cmap)# match ip dscp cs2
R4(config-cmap)# match ip dscp af21
R4(config-cmap)#class-map match-any SCAVENGER
R4(config-cmap)# match ip dscp CS1
R4(config)#policy-map EDGE_CHILD
R4(config-pmap)# description Core links
R4(config-pmap)# class PRIORITY
R4(config-pmap-c)# priority percent 25
R4(config-pmap-c)# class CONTROL
R4(config-pmap-c)# bandwidth percent 10
R4(config-pmap-c)# class CRITICAL
R4(config-pmap-c)# bandwidth percent 15
R4(config-pmap-c)# random-detect dscp-based
R4(config-pmap-c)# class ROUTINE
R4(config-pmap-c)# bandwidth percent 10
R4(config-pmap-c)# random-detect dscp-based
R4(config-pmap-c)# class SCAVENGER
R4(config-pmap-c)# bandwidth percent 1
R4(config-pmap-c)# random-detect dscp-based
R4(config-pmap-c)# class class-default
R4(config-pmap-c)# fair-queue
R4(config-pmap-c)# random-detect dscp-based
R4(config-pmap-c)#!
R4(config-pmap-c)#policy-map EDGE2CORE
R4(config-pmap)# description Parent policy for Edge-to-Core links
R4(config-pmap)# class class-default
R4(config-pmap-c)# shape average 10000000
R4(config-pmap-c)# service-policy EDGE_CHILD
R4(config-pmap-c)#!
R4(config-if)#int fa1/0
R4(config-if)# service-policy output EDGE2CORE
R4(config-if)#!
R4(config-if)#int fa3/0
R4(config-if)# service-policy output EDGE2CORE
R4(config-if)#!


Cisco Multicast Lesson 1: Introduction to Multicast through an Easy Example

In a lot of my QoS testing, I have used Gnome M-Player to play an MP4 file, served off of a web server. The cool thing about this approach is that I can easily increase the bandwidth coming across the network by connecting additional clients and using M-Player to download new streams.

In the real world, however, you typically want to conserve bandwidth, and so having multiple clients downloading separate instances of the same data is usually a bad thing. Consider the following network as an example:

In this very simple example, we have a CentOS 6 server (Which will be streaming the file), and three Knoppix clients (which will be playing the file with M-Player). When I start up one of the Knoppix clients and begin a unicast stream, I see 270Kbps through Fa2/0:
R1#sho int fa2/0
...
5 minute output rate 270000 bits/sec, 32 packets/sec
...

(yes, I waited 5 minutes after beginning the stream).

What happens if we clear the interface counters and start up a second video stream from another client (and wait 5 minutes for the average to stabilize)? Will we see 540Kbps (2 streams x 270Kbps per stream)?
R1#sho int fa2/0
...
5 minute output rate 650000 bits/sec, 63 packets/sec
...
Huh...a little over the estimate. What if we fire up a third client downloading the same file?

R1#sho int fa2/0
...
5 minute output rate 907000 bits/sec, 92 packets/sec
...
Again, pretty close to what we would expect (3 x 270Kbps = 810Kbps). I'll chalk up the additional bandwidth to OSPF routing updates, CDP, and other network chatter, but the important thing is that this method of streaming data across a large network doesn't scale well.

Fortunately, there is a solution for this problem. What if there were a way to reduce the number of data streams that each router had to propagate? In a unicast stream, the router opens up a stream of data for each host that connects to the CentOS server. However, with multicast streams, the router only opens up one channel per outbound path. For example, the route from the CentOS server to Knoppix and Knoppix Clone 2 is identical up to R3 (and if Fa1/0 on R1 is shut down, as it was during my testing, it's identical to Knoppix Clone 1, as well). With multicast, R1 would forward a single datastream to R3; R3 would then split that data stream to R5 and to R4. With Fa1/0 shut down on R1, R4 would split its incoming stream also, sending one stream to Knoppix Clone 2 and one stream to R6. Now, suppose that instead of one client on R4, R5 and R6, suppose there were ten...it's not hard to see how multicast can quickly reduce bandwidth consumption on a large network.

So...how do you configure multicast on a Cisco router?

This is actually very easy to do. First, you globally enable multicast on your router:
R1(config)#ip multicast-routing
R1(config)#

Then, you enable PIM on the interfaces that will be participating in multicast streams:
R1(config)#int fa1/0
R1(config-if)#ip pim sparse-dense-mode
R1(config-if)#int fa2/0
R1(config-if)#ip pim sparse-dense-mode
R1(config-if)#int vlan10
R1(config-if)#ip pim sparse-dense-mode

There's a lot more to multicast -- which we'll get to in later labs -- but for a bare-bones configuration, that's it! Pretty easy, isn't it?

At this point, I'm going to chase down a rabbit trail for a few minutes. This is primarily intended as a Cisco lab, but unlike most of the other labs on this blog, this one requires some additional work on the server side in order to test. I started by installing VLC on the CentOS host. For CentOS6, you can install a binary package like this:
# rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
# rpm -Uvh http://li.nux.ro/download/nux/dextop/el6/i386/nux-dextop-release-0-3.el6.nux.noarch.rpm
# yum install vlc

For CentOS7, the install goes like this:
# rpm -Uvh http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-8.noarch.rpm
# rpm -Uvh http://li.nux.ro/download/nux/dextop/el7/x86_64/nux-dextop-release-0-5.el7.nux.noarch.rpm
# yum install vlc

Once VLC is installed, you will need to start the multicast stream:
$ cvlc -vvv /var/www/localhost/htdocs/ZNKR_Iaido.mp4 --sout '#rtp{mux=ts,dst=239.255.255.1}' --ttl 12

Then on the Knoppix clients, start up Gnome M-Player (the command line version would probably work, but I used the GUI), click "File," click "Open Location" and in the text window, type:
rtp://@239.255.255.1:5004/

So...what did we just do?

On the CentOS server, we added the repositories that allow you to install VLC through the CentOS package manager. Then, we installed VLC. As a NON-ROOT user (VLC will not run as root), start the command-line version of VLC, telling it to use the RTP protocol, and use the multi-cast address of 239.255.255.1 (a full discussion of multicast addressing is outside the scope of this lab, but for now, feel free to substitute any address in the subnet 239.255.0.0/16).

On the client side, we are again saying to use the RTP protocol, we are referencing the same multicast address, and specifying the port 5004 in the URL.

</rabbit-trail>Back to networking...

Now that we have multicast running, what does that do to our bandwidth usage? Let's find out! Start up two Knoppix clients, start the multicast stream on the CentOS server, clear the counters on FA2/0 on R1, and let's see:

R1#sho int fa2/0
...
5 minute output rate 449000 bits/sec, 43 packets/sec
...

That's much better! There's a little overhead for the multicast protocol itself, but it's still around 30% less than the unicast bandwidth utilization with two clients.

One interesting aspect of multicast is that, from the client's perspective, multicast is much more like broadcast television than video-on-demand. That is, with a unicast stream, when you request a resource, you start at the beginning of the video (or audio or...) stream. With multicast, you are joining a stream already in progress, which means you will be watching (or listening or...) to the exact same portion of the stream as other users.

Look at the two following screenshots. In the first screenshot, the videos are obviously playing at different locations in the video stream:

However, in the second screenshot, you can see that the stream on the right has been playing for 13 minutes and 45 seconds and the one on the left has been playing for only 7 minutes and 50 seconds...but both are playing the exact same point in the video stream:

With that, we'll close out this lab, even though we've only scratched the surface of multicast. More to come!

BGP Route Filtering

Consider the network in the following diagram...:

If you apply a simple BGP configuration to each router in this network, something along the lines of...:
#R5 BGP Configuration:
router bgp 500
no synchronization
bgp router-id 10.254.254.5
bgp log-neighbor-changes
network 10.254.254.5 mask 255.255.255.255
network 172.16.0.0 mask 255.255.255.252
network 172.16.0.16 mask 255.255.255.252
neighbor 172.16.0.2 remote-as 100
neighbor 172.16.0.17 remote-as 400
no auto-summary

...BGP will find the "best" route around the network. For example, for R1 to ping R4's loopback address, it would take the route R1, R5, R4, and to ping R3's loopback address, R1 would take the route R1, R2, R3:
R1#sho ip route
<---snip--->
10.0.0.0/32 is subnetted, 5 subnets
B 10.254.254.2 [20/0] via 172.16.0.6, 00:00:10
B 10.254.254.3 [20/0] via 172.16.0.6, 00:00:10
C 10.254.254.1 is directly connected, Loopback0
B 10.254.254.4 [20/0] via 172.16.0.1, 00:00:09
B 10.254.254.5 [20/0] via 172.16.0.1, 00:00:15
R1#

Exactly as you would expect, right?

It could happen, however, that there is some factor of which BGP is unaware that makes this routing less than optimal. Suppose, for example, that you are the administrator of router R5, and while you would like to multi-home your router, you don't want to allow other networks to transit your router. To prevent BGP from advertising routes to other networks, it is possible to filter outbound routes from your router.

Step 1: Create an access list to define the networks you want to allow outbound.
R5(config)#access-list 1 permit 10.254.254.5 0.0.0.0
R5(config)#access-list 1 permit 172.16.0.0 0.0.0.3
R5(config)#access-list 1 permit 172.16.0.16 0.0.0.3

Step 2: Edit the BGP config to filter the routes as defined in your access list.
R5(config)#router bgp 500
R5(config-router)# neighbor 172.16.0.2 distribute-list 1 out
R5(config-router)# neighbor 172.16.0.17 distribute-list 1 out

Step 3: Clear the BGP sessions to reset the routes.
R5#clear ip bgp 100
R5#clear ip bgp 400
R5#
00:49:41: %BGP-5-ADJCHANGE: neighbor 172.16.0.2 Down User reset
R5#
00:49:43: %BGP-5-ADJCHANGE: neighbor 172.16.0.17 Down User reset
R5#

Now, if you look at the routes on R1, it will only transit R1 to reach networks that are directly connected to R1:
R1#sho ip route
<---snip--->
172.16.0.0/30 is subnetted, 5 subnets
B 172.16.0.16 [20/0] via 172.16.0.1, 00:01:28
B 172.16.0.12 [20/0] via 172.16.0.6, 00:09:24
B 172.16.0.8 [20/0] via 172.16.0.6, 00:09:24
C 172.16.0.4 is directly connected, FastEthernet0/0
C 172.16.0.0 is directly connected, FastEthernet3/0
10.0.0.0/32 is subnetted, 5 subnets
B 10.254.254.2 [20/0] via 172.16.0.6, 00:09:24
B 10.254.254.3 [20/0] via 172.16.0.6, 00:09:24
C 10.254.254.1 is directly connected, Loopback0
B 10.254.254.4 [20/0] via 172.16.0.6, 00:02:21
B 10.254.254.5 [20/0] via 172.16.0.1, 00:01:28
R1#

As you can see, to reach R4's loopback address now, R1 now will route traffic through R2 rather than through R5.

Now, what would happen if there was a break somewhere in between R2 and R4?
R2#conf t
R2(config)#int fa0/0
R2(config-if)#shut

R1#ping 10.254.254.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.254.254.4, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#

R5 will not propagate any routes except those that you have explicitly allowed, and as a result, R1 no longer has a route to R4.

Cisco Intro to QoS and CoS, Part 2 -- A Deeper Dive into Marking Traffic

In our last lab, we set up a simple network, and showed how applying a QoS policy to prioritize certain traffic over other traffic could help high-priority, time-sensitive applications work properly, even during times of network congestion. But what did all of the access lists, class maps and policy maps really do? In this lab, we'll take a closer look at what the class maps and policy maps are really doing at the packet layer.

First, we'll start with a new network diagram:


As we stated last time, the first step in designing an effective QoS policy is identifying the traffic on your network, and deciding how you want to prioritize it. On this network, we will sort network traffic into the following classes:

1. Core Control: OSPF, in this case (which is automatically identified and marked by the router itself);
2. VoIP: We will be simulating voice traffic by streaming an MP4 video file from the host CentOS6 to hosts on the "voice" VLAN (VLAN 100);
3. Call Signaling: We will also be simulating call signaling traffic with SSH from the "voice" VLAN (VLAN 100);
4. Routine: Bulk data traffic from the "LAN" VLAN (VLAN 10);
5. default: Anything not otherwise classified.

Here are the access lists that we will use to identify the traffic:
ip access-list extended CALLSIGNALING
 permit tcp 192.168.100.0 0.0.0.255 any eq 22
 permit tcp any eq 22 192.168.100.0 0.0.0.255
 deny ip any any
ip access-list extended ROUTINE
 permit ip 192.168.1.0 0.0.0.255 any
 permit ip any 192.168.1.0 0.0.0.255
 deny ip any any
ip access-list extended VOIP
 permit tcp 192.168.100.0 0.0.0.255 any eq www
 permit tcp any eq www 192.168.100.0 0.0.0.255
 deny ip any any
!

Like I said earlier, the router automatically identifies and marks routing protocol traffic, so we don't need to create a separate ACL for that.

After creating the ACL's to match the network traffic, we will create the class maps:
class-map match-any NETWORK_CONTROL
 match ip dscp cs6
class-map match-any VOIP
 match ip dscp ef
 match access-group name VOIP
class-map match-any CALLSIGNALING
 match ip dscp cs3
 match ip dscp af31
 match access-group name CALLSIGNALING
class-map match-any ROUTINE
 match ip dscp cs2
 match access-group name ROUTINE
!

Let's discuss the class map in a little more detail. First, notice that the first line of each class map contains the phrase "match-any." Take, for example, the class map for CALLSIGNALING. We have a line that states, "match ip dscp cs3," and then we have two other "match..." statements following that line. Since we created the class map using the "match-any" statement, then we are essentially using a logical OR to match either the DSCP marking CS3, the DSCP marking AF31 or the "CALLSIGNALING" access list. If we had used the phrase, "match-all," then we would be performing a logical AND against all of the statements (which would never match, as the DSCP CS3 and DSCP AF31 markings are mutually exclusive...but it can be useful if you are matching on other criteria than DSCP markings).

We will explain why we are matching against either DSCP markings or an access list shortly, but for now, let's proceed to the policy-map:
policy-map EGRESS
 class VOIP
  priority percent 20
 class CALLSIGNALING
  bandwidth percent 5
 class ROUTINE
  bandwidth percent 50
  random-detect dscp-based
 class NETWORK_CONTROL
  bandwidth percent 5
 class class-default
  bandwidth percent 1
  random-detect dscp-based
!
policy-map EGRESS-BW
 class class-default
  shape average 10000000
  service-policy EGRESS
!
policy-map INGRESS
 class VOIP
  set dscp ef
 class CALLSIGNALING
  set dscp af31
 class ROUTINE
  set dscp cs2
 class class-default
  set dscp cs1

We have created three policy-maps in this example: EGRESS, EGRESS-BW, and INGRESS (creative names, no?).

EGRESS-BW is pretty simple: essentially, we are shaping all of the traffic in this policy to 10Mbps, then calling the "EGRESS" policy. This is a pretty common strategy, as it allows you to create a parent policy (EGRESS-BW, in this case) to define the shaper/policer, and then a child policy to break out the bandwidth to the individual traffic classes. This allows for a very flexible approach, since you can create multiple parent policies that call the same child policy, allowing you to quickly make changes to your traffic shaper.

The EGRESS policy matches traffic against the class-maps that we previously defined, then divvies that bandwidth up into the individual traffic classes by percentage. There are two details worth a little extra discussion in the EGRESS policy. First, notice that class VOIP uses "priority percent..." whereas all of the other classes use "bandwidth percent..." This places VOIP traffic on the priority (low-latency) queue. The other classes buffer incoming traffic, placing it on a queue until the router gets a chance to transmit it on the interface; class VOIP, on the other hand is transmitted IMMEDIATELY. This is because VoIP traffic is very sensitive to jitter, and queueing up traffic before transmitting it causes latency. However, be aware that if traffic in class VOIP cannot be transmitted immediately, it will be DISCARDED! Therefore, you don't want to use the "priority" statement unless it is for a traffic class that can tolerate drops, but cannot tolerate jitter. Second, notice how class "ROUTINE" and class "class-default" (a built-in traffic class on Cisco routers) use the statement, "random-detect dscp-based?" This statement tells the QoS policy to enable the "random early detection" scheduler, which will randomly discard packets as the traffic queues become congested. The thresholds at which RED begins to discard traffic are configurable, but in this example, we are using the default settings, as this is beyond the scope of this tutorial. At first, randomly discarding traffic might sound like a bad idea, but the idea behind this strategy is that by randomly discarding the occasional packet before the network becomes fully congested, the service sending the traffic that is being dropped will begin to slow down the rate at which it is transmitted, thus delaying the onset of congestion. However, we do not want to enable this feature in class VOIP or class CALLSIGNALING, as this is priority traffic that you really don't want to drop.

Finally, the INGRESS policy is where the traffic inbound to the router from the network clients (Knoppix_Clone_1 and Knoppix_Clone_2) is identified and marked. The only action taken by the INGRESS policy is applying the DSCP markings to the traffic, based upon the access control lists. In truth, if an incoming packet already had a DSCP marking, the INGRESS policy would happily classify traffic based upon that, unless other configuration items were present in the router config, but for now, let's just assume that all incoming traffic has no DSCP markings, and therefore the only lines in the class-maps that will match are the "match access-group name..." statements.

So...this is great, in theory, but does it actually work? To find out, I ran tcpdump on the CentOS6 host to capture all incoming network traffic. If the router configuration is good, then...:

1. Any traffic coming from 192.168.1.x should be marked with a DSCP value of CS2;
2. Any traffic coming from 192.168.100.x outbound to any host on port 22 should be marked with a DSCP value of AF31;
3. Any traffic coming from 192.168.100.x outbound to any host on port 80 should be marked with a DSCP value of EF;
4. and Any traffic originating on the router itself that is identified as OSPF should be marked with a DSCP value of CS6¹.

After running several tests (streaming the MP4 file on CentOS6 to the Knoppix Clone on the VoIP VLAN, SSH'ing to CentOS6 from the Knoppix host on the VoIP VLAN, and connecting to the HTTP process on CentOS 6 from the Knoppix host on the LAN VLAN), I copied the capture file from CentOS6 to my local desktop, and opened up the file with Wireshark. Let's look at traffic originating on 192.168.1.x:


Yep, "Class Selector 2" is the value of the DSCP marking for traffic originating on 192.168.1.2, so it looks like our QoS policies are correctly identifying traffic on the LAN VLAN, and correctly marking it with a CS2 DSCP marking. Next let's look for traffic originating on the Voice VLAN, outbound for CentOS6 on port 22 (SSH):


Perfect! This screen capture shows that traffic originating on 192.168.100.2, sent to 100.64.1.2 on port 22 was correctly identified and marked with a DSCP value of AF31. Next, let's see if traffic from 192.168.100.2 to 100.64.1.2 on port 80 is properly marked as "EF:"


Yep, this traffic has a DSCP marking of "EF," just as expected. Finally, let's verify that the OSPF multicast traffic from the router is properly marked as CS6:


That looks good, too.

Now that we have verified that traffic is being classified and marked appropriately, let's look at a very useful command for troubleshooting QoS and congestion on a Cisco router. Suppose that one of your users calls to report problems with their voice-over-IP telephones. They've already had the telephone tech look at the phone and the Call Manager, but because the phone tech found nothing wrong, they suspect it is a network problem. How can you tell if your QoS policy is dropping packets, due to excessive traffic in one of your queues?

If I had received a call such as this, I would start by looking at the QoS statistics for the outbound interface on the router -- in this case, FastEthernet1/0:
R1#sho policy-map int fa1/0  
FastEthernet1/0

  Service-policy output: EGRESS-BW

    Class-map: class-default (match-any)
      4298 packets, 316655 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
      Traffic Shaping
           Target/Average   Byte   Sustain   Excess    Interval  Increment
             Rate           Limit  bits/int  bits/int  (ms)      (bytes)  
         10000000/10000000  62500  250000    250000    25        31250    

        Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping
        Active Depth                         Delayed   Delayed   Active
        -      0         4298      316655    0         0         no

      Service-policy : EGRESS

        Class-map: VOIP (match-any)
          1556 packets, 103168 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: ip dscp ef
            1556 packets, 103168 bytes
            5 minute rate 0 bps
          Match: access-group name VOIP
            0 packets, 0 bytes
            5 minute rate 0 bps
          Queueing
            Strict Priority
            Output Queue: Conversation 264
            Bandwidth 20 (%)
            Bandwidth 2000 (kbps) Burst 50000 (Bytes)
            (pkts matched/bytes matched) 0/0
            (total drops/bytes drops) 0/0

        Class-map: CALLSIGNALING (match-any)
          1035 packets, 79610 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: ip dscp cs3
            0 packets, 0 bytes
            5 minute rate 0 bps
          Match: ip dscp af31
            1035 packets, 79610 bytes
            5 minute rate 0 bps
          Match: access-group name CALLSIGNALING
            0 packets, 0 bytes
            5 minute rate 0 bps
          Queueing
            Output Queue: Conversation 265
            Bandwidth 5 (%)
            Bandwidth 500 (kbps)
            (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0
             exponential weight: 9
             mean queue depth: 0

   dscp    Transmitted      Random drop      Tail drop    Minimum Maximum  Mark
           pkts/bytes       pkts/bytes       pkts/bytes    thresh  thresh  prob
   af11       0/0               0/0              0/0           32      40  1/10
   af12       0/0               0/0              0/0           28      40  1/10
   af13       0/0               0/0              0/0           24      40  1/10
   af21       0/0               0/0              0/0           32      40  1/10
   af22       0/0               0/0              0/0           28      40  1/10
   af23       0/0               0/0              0/0           24      40  1/10
   af31    1035/79610           0/0              0/0           32      40  1/10
   af32       0/0               0/0              0/0           28      40  1/10
   af33       0/0               0/0              0/0           24      40  1/10
   af41       0/0               0/0              0/0           32      40  1/10
   af42       0/0               0/0              0/0           28      40  1/10
   af43       0/0               0/0              0/0           24      40  1/10
    cs1       0/0               0/0              0/0           22      40  1/10
    cs2       0/0               0/0              0/0           24      40  1/10
    cs3       0/0               0/0              0/0           26      40  1/10
    cs4       0/0               0/0              0/0           28      40  1/10
    cs5       0/0               0/0              0/0           30      40  1/10
    cs6       0/0               0/0              0/0           32      40  1/10
    cs7       0/0               0/0              0/0           34      40  1/10
     ef       0/0               0/0              0/0           36      40  1/10
   rsvp       0/0               0/0              0/0           36      40  1/10
default       0/0               0/0              0/0           20      40  1/10


        Class-map: ROUTINE (match-any)
          284 packets, 23609 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: ip dscp cs2
            284 packets, 23609 bytes
            5 minute rate 0 bps
          Match: access-group name ROUTINE
            0 packets, 0 bytes
            5 minute rate 0 bps
          Queueing
            Output Queue: Conversation 266
            Bandwidth 50 (%)
            Bandwidth 5000 (kbps)
            (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0
             exponential weight: 9
             mean queue depth: 0

   dscp    Transmitted      Random drop      Tail drop    Minimum Maximum  Mark
           pkts/bytes       pkts/bytes       pkts/bytes    thresh  thresh  prob
   af11       0/0               0/0              0/0           32      40  1/10
   af12       0/0               0/0              0/0           28      40  1/10
   af13       0/0               0/0              0/0           24      40  1/10
   af21       0/0               0/0              0/0           32      40  1/10
   af22       0/0               0/0              0/0           28      40  1/10
   af23       0/0               0/0              0/0           24      40  1/10
   af31       0/0               0/0              0/0           32      40  1/10
   af32       0/0               0/0              0/0           28      40  1/10
   af33       0/0               0/0              0/0           24      40  1/10
   af41       0/0               0/0              0/0           32      40  1/10
   af42       0/0               0/0              0/0           28      40  1/10
   af43       0/0               0/0              0/0           24      40  1/10
    cs1       0/0               0/0              0/0           22      40  1/10
    cs2     284/23609           0/0              0/0           24      40  1/10
    cs3       0/0               0/0              0/0           26      40  1/10
    cs4       0/0               0/0              0/0           28      40  1/10
    cs5       0/0               0/0              0/0           30      40  1/10
    cs6       0/0               0/0              0/0           32      40  1/10
    cs7       0/0               0/0              0/0           34      40  1/10
     ef       0/0               0/0              0/0           36      40  1/10
   rsvp       0/0               0/0              0/0           36      40  1/10
default       0/0               0/0              0/0           20      40  1/10


        Class-map: class-default (match-any)
          1423 packets, 110268 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: any
          Queueing
            Output Queue: Conversation 267
            Bandwidth 1 (%)
            Bandwidth 100 (kbps) Max Threshold 64 (packets)
            (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0
R1#

cough...cough...That's a lot of output...what does it mean?

First, we need a little more information from the user. Were they having problems answering the phone, transferring the call to another number, or hanging up once the call was complete? If so, you would need to look into the call signaling queue. Was the call garbled, or was the audio cutting out during the call? In that case, you would need to look at the VOIP queue. Let's assume that the caller complained of call signaling symptoms. We would narrow our focus to the statistics relating to class CALLSIGNALING. I won't re-copy all of the output from class CALLSIGNALING, since it's so long, but scroll back up and look at the output starting with "Class-map CALLSIGNALING (match-any)." The first thing I would check is how many drops you've had in this queue. See the line that says, "(depth/total drops/no-buffer drops) 0/0/0?" That tells you that you have allocated adequate bandwidth for class CALLSIGNALING. You do not have any packets in the buffer waiting to be transmitted, and you have not dropped any packets since the last time the interface counters were cleared or since the service policy was instated (whichever was later). Also, look at this part of the output:
   dscp    Transmitted      Random drop      Tail drop    Minimum Maximum  Mark
           pkts/bytes       pkts/bytes       pkts/bytes    thresh  thresh  prob
<...snip...>
   af31    1035/79610           0/0              0/0           32      40  1/10
<...snip...>

"Random Drops" are where your random early detection scheduler begins dropping packets before the network becomes fully congested. "Tail Drops" are where your queue has already buffered all the packets it can hold, and new incoming packets are being discarded, since there is no room left on the queue to store them. In this case, both tail drops and random drops are zero, meaning that the QoS policy has not dropped any traffic with the AF31 marking (since that was all that we were marking with our INGRESS policy; typically, you would want to look at both CS3 and AF31 in a call signaling queue).

Since there are no dropped packets in the call signaling queue, you would need to look elsewhere for the problem (for example, look for dropped packets on the router on the other side of the circuit, or make sure that the router is recognizing traffic from the phone as belonging to class VOIP or class CALLSIGNALING, as appropriate). However, suppose you saw output like this:
        Class-map: CALLSIGNALING (match-any)
          2901880 packets, 192238996 bytes
          30 second offered rate 4000 bps, drop rate 0 bps
          Match: ip dscp cs3 (24) af31 (26)
            2901880 packets, 192238996 bytes
            30 second rate 4000 bps
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/12155/0
          (pkts output/bytes output) 2889729/190911691
          bandwidth 320 kbps

In this case, you have dropped 12,155 packets(!) since the last time the counters were cleared (which was about four days ago, although you can't tell that from the output above). This means that you have not allocated adequate bandwidth to class CALLSIGNALING, and either 1) you need to allocate more bandwidth to handle the call volume, or 2) you have traffic on this circuit that is not being marked appropriately. On this router, I strongly suspect that there is traffic on the circuit that is being marked incorrectly, as we have already allocated 320Kbps to class CALLSIGNALING, which is a LOT of bandwidth for call signaling traffic.

Footnotes:
1:Yes, it is silly to run OSPF on this router, since there are no other routers with which it can share routes. The only reason I configured OSPF in this lab is to show that the router does, indeed, automatically mark OSPF traffic with the CS6 DSCP marking.

Cisco Intro to QoS and CoS, Part 1 -- Identifying, Classifying and Marking Traffic

One problem found in any network of reasonable size is how to handle congestion. When there is more bandwidth available than clients require, there is (of course!) no problem. However, some types of network traffic -- such as streaming media -- are particularly bandwidth intensive, and often, very sensitive to variations in delay time. Consider, for example, HTTP traffic: an end user will most likely not notice the variation in transit times ("jitter") of the various packets that make up a requested download. On the other hand, a Voice over IP call is very sensitive to jitter. If the packets making up a Voice over IP call or videoconference don't arrive within a reasonably consistent timeframe, the call quality will suffer, and your end users will not be happy. Even worse, what would happen if your dynamic routing protocols cannot send updates and keepalive traffic in a timely fashion? Clearly, there needs to be a way to prioritize certain types of traffic to ensure that your clients receive sufficient bandwidth for their needs.

Consider the following network:


On the left-hand side of the network drawing, we have three Linux hosts, clients of the server on the right-hand side of the drawing. These three hosts will be in competition with each other for network resources, and because we are running OSPF (or routing protocol of your choice -- and yes, a dynamic routing protocol is overkill on a network this simple, but stay with me...) on R1 and R2, they will be competing with the network clients for bandwidth as well. Making this problem even more apparent, I have connected all of the PC's to the network via FastEthernet interfaces, but only connected R1 and R2 with a single T1 line. Due to the extreme mismatch between LAN and WAN capabilities, any one of the network clients can easily saturate the "WAN" link between R1 and R2. Don't believe me? Let's do some tests...

On the host "CentOS6," I have configured the "echo" service, and on the host "CentOS6_Clone," I have installed a network diagnostic tool called "tcpspray." With no other traffic on the network, let's use tcpspray to see how long it takes to send a flurry of data to the "CentOS6" server:

[root@centos6_clone ~]# tcpspray -e -n 1000 192.168.2.2
Received 1024000 bytes in 25.670507 seconds (30.955 kbytes/s)
Transmitted 1024000 bytes in 25.146152 seconds (39.768 kbytes/s)
[root@centos6_clone ~]#

Also on the host "CentOS6," I am running a web server, and one of the web pages hosted on the server is an image gallery that loads a 5x5 array of JPEG images (get your mind out of the gutter! They're pictures of motorcycles that inspired me while I was building my Cafe Racer project!). How would the tcpspray bandwidth be affected if one of the Knoppix clients was downloading the images to populate the web page at the same time? Let's find out...:

[root@centos6_clone ~]# tcpspray -e -n 1000 192.168.2.2
Received 1024000 bytes in 118.753065 seconds (8.421 kbytes/s)
Transmitted 1024000 bytes in 104.348504 seconds (9.583 kbytes/s)
[root@centos6_clone ~]#

Wow...it took almost five times as long to receive the replies, due to the congestion on the network! Fortunately, quality of service and/or class of service policies can allow us to prioritize certain kinds of traffic, as our network needs dictate.

Keep in mind that nothing is free, however. If we prioritize some kinds of traffic, that necessarily comes at the expense of other traffic. Therefore, you have to have a good idea what kinds of traffic cross your network, and how they should be balanced against each other...which is a good place for us to begin with our policy. Let's define the traffic that we want prioritized.

As I mentioned earlier, the parameters I used for tcpspray specified that we would use the "echo" service for our traffic. Let's include SSH as priority traffic so we can manage our routers (you are using SSH for network management, right?). As I also mentioned earlier, our network control traffic is also high priority. Too keep the discussion simple for now, we'll assume everything else is "best effort."

Now that we have a good idea how we want to prioritize our traffic, we need a way to have the router filter our priority traffic. If you think that sounds like a job for an Access Control List, you're exactly right:

ip access-list extended CORE_GOLD
 permit tcp any eq echo any
 permit tcp any any eq echo
!
ip access-list extended CUST_EF
 permit tcp any eq 22 any
 permit tcp any any eq 22
!

After identifying the priority traffic with an ACL, we then create "class maps" to map that traffic into different classes (kind of sounds like a tautology, sorry!):

class-map match-any CORE_CONTROL
 description Network control OSPF/BGP/etc
 match ip precedence 6
 match ip precedence 7
class-map match-any CUST-EF
 match access-group name CUST_EF
class-map match-any CORE_GOLD
 description Low-latency/priority queue
 match access-group name CORE_GOLD
!

We have now created three classes of priority traffic:

1. CORE_CONTROL, for our network control traffic,
2. CUST-EF, for high priority traffic ("expedited forwarding"), and
3. CORE_GOLD, for low-latency traffic.

Our next step is to use these maps to define how the different classes of traffic will be handled:

policy-map CUST-IN
 class CUST-EF
  set ip dscp ef
 class class-default
  set dscp cs3
policy-map CUST-Generic
 class CORE_GOLD
  priority percent 50
 class CORE_CONTROL
  bandwidth percent 10
 class class-default
  bandwidth percent 1
!

For our "CUST-EF" traffic, we have said that we want to place a special marking, "dscp ef," on the packets that match this traffic. This gives our "CUST-EF" traffic high priority on the network. For "CORE_GOLD" traffic, we have said that we want to give that traffic 50 per cent of the available bandwidth. For "CORE_CONTROL" traffic, we have said that we want to give such traffic 10 per cent of the available bandwidth (network control traffic is typically small-volume, bursty traffic, so it is not necessary to reserve a large amount of bandwidth for this traffic -- we just need to ensure that the traffic isn't starved for bandwidth during times of congestion). Notice that we also have another de facto class of traffic in the policy maps: class-default. This is for traffic that didn't match any of our access control lists. In the "CUST-IN" policy map, we mark it with "dscp cs3" -- a low priority traffic queue, and in the "CUST-Generic" policy map, we don't reserve any bandwidth for this class.

At this point, we have established the framework for our QoS/CoS configuration, but we haven't actually implemented it yet. Just as an access-control list used to filter certain kinds of traffic has to be applied to an interface before it is useful, so does a policy map:

interface Serial1/0
service-policy output CUST-Generic
!

We also will apply the "CUST-IN" policy map to the ingress interface, VLAN 10 on R1 and Fa0/0 on R2:

R1(config)#int vlan 10
R1(config-if)#service-policy input CUST-IN
R1(config-if)#

R2(config)#int fa0/0
R2(config-if)#service-policy input CUST-IN
R2(config-if)#

Now, let's run our tcpspray test again, while the Knoppix client reloads the web page with the 25 JPEG images:

[root@centos6_clone ~]# tcpspray -e -n 1000 192.168.2.2
Received 1024000 bytes in 78.483684 seconds (12.742 kbytes/s)
Transmitted 1024000 bytes in 69.900585 seconds (14.306 kbytes/s)
[root@centos6_clone ~]#

These results are still slower than our initial baseline test, with no congestion on the network. However, it is significantly better than the test with no QoS/CoS and a congested network.