Tuesday, August 13, 2013

Zone-Based Policy Firewall, Part 2

In my previous post I touched on the four parts (Zones & Zone Members, Class Maps, Policy Maps and Zone Pairs) which make up a ZFW configuration. In this post I will explain the "actions" which are used to tell the router how to handle inbound and outbound traffic flows.

Actions

Actions are applied to Class Maps which as they're being nested in Policy Maps. (Don't worry if that sentence confuses you, it'll all become clear when I show you an example a little later on). As per Cisco's website, there are three actions to choose from:
  • Drop - Drops packets which are matched by the Class Map.
  • Pass - Allows packets which are matched by the Class Map through in one direction
  • Inspect - Works exactly like CBAC.

Drop

The "drop" action does exactly what its name implies - it drops traffic which is matched by a Class Map. A great place to use this action is the connection between your WAN interface and the router's "self" zone. You might recall at the end of my last post I mentioned that all traffic destined for and sourced from the router (aka the "self" zone) is allowed by default. By implementing the "drop" action you can close off this security hole.

Pass

Out of the three, the "pass" action is the most difficult to comprehend. It's not so bad, it's just that the other two are just really simple to understand.

The "pass" action allows traffic to flow in one direction only. If you'd like the return traffic to make it through the firewall, you must implement another "pass" rule which matches the return traffic. For example, if your PCs are connected to Fa0/0 ("LAN" zone) and your internet is connected to Fa0/1 ("WAN" zone), and you wanted to allow the PCs to access websites only, you'd need to do the following:

Source Zone: LAN-Zone
Destination: WAN-Zone
Match Criteria: Any Source IP & Any TCP Port Number to Any Destination IP & TCP Port Number 80

Source Zone: WAN-Zone
Destination: LAN-Zone
Match Criteria: Any Source IP & TCP Port Number 80 to Any Destination IP & Any TCP Port Number

As you can see, the two rules are mirrors of each other. The first rule allows the web request to go out and the next rule allows the web server's response back in. If you only implement one of the above rules the web browsing would not work.

You may be wondering why anyone would bother using the "pass" action when it would seem that the "inspect" action (see below) does exactly the same thing, but it only requires half the effort! Well, there are two reasons that I can think of off the top of my head.

The first reason is that "pass" uses less resources than the "inspect". This is because "pass" simply allows the traffic to go through, whereas "inspect" needs to track each and every connection and its state.

The second reason is that "inspect" cannot be used on traffic sourced from or destined for the router's "self" zone. This therefore means that if you want to control traffic to and from the router (rather than permitting it all as is the default), you can "pass" traffic which specifically matches your Class Maps. Doing this gives you the best of both worlds - it drops the traffic which is not supposed to be sent and received and passes the traffic which is.

Inspect

Finally we have "inspect". Inspect does exactly what a lot of people expect out of their firewalls after dealing with home-grade routers which do SPI (Stateful Packet Inspection). It "watches" the traffic that goes out and only allows the specific return traffic back in. All other inbound traffic is dropped. Further to this, once the connection is closed the return traffic will no longer be allowed through the firewall and it too will be dropped.

To put it simply, specific firewall rules are dynamically created and removed as needed to ensure only requested traffic is allowed through the firewall. This provides a level of security which the "pass" action does not. This is because "pass", if configured in the Outside to Inside direction will allow all traffic in, regardless of whether it is return traffic which was requested by an Inside host or if it is new traffic which was initiated by an Outside host.

Now let's take a look at the example we saw in the "pass" section above. Again, let's say your PCs are connected to Fa0/0 ("LAN" zone) and your internet is connected to Fa0/1 ("WAN" zone), and you want to allow the PCs to access websites only. This is how you'd do it:

Source Zone: LAN-Zone
Destination: WAN-Zone
Match Criteria: Match Protocol HTTP

Here we can see two things - The first is that the required configuration is half the size of the "pass" configuration. The second thing is that there is a "match protocol" statement instead of an ACL-like statement. By using "match protocol" the router will is able to perform protocol specific firewalling where required - for example, where FTP is concerned. (If you're not too sure what I mean, have a quick read about Passive and Active FTP connections and the port numbers which they use).

Summary

In conclusion there is no "best" action out of the three. They each have their uses and more often than not you may find that you use a combination of the three in all of your setups.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Monday, August 12, 2013

Zone-Based Policy Firewall, Part 1

Cisco's Zone-Based Policy Firewall (ZFW) can be quite confusing when you first start looking in to it, so over the next couple of blog posts I hope to provide readers with some useful information. Having said that, I'll do my best to avoid reinventing the wheel given that Cisco has already done a great job of documenting ZFW.

ZFW Parts

ZFW is made up of several "parts", which, once all put together form a fully functional firewall. These parts are:
  • Zones & Zone Members
  • Class Maps
  • Policy Maps
  • Zone Pairs

Zones & Zone Members

As the name suggests, ZFW requires that you put interfaces in to zones. The idea is that you put your interfaces in to zones and then apply inter-zone firewall rules which will permit or deny traffic flows.
There are two types of you need to be aware of:
  • User Configurable
  • "self"
User Configurable zones are zones which you configure yourself (dah!). How many you create, what you name them and how many interfaces you assign to the zones to is totally up to you. For example, if you have three interfaces which are used for LAN traffic and one interface which is used for WAN traffic, you may want to create a "LAN" zone and a "WAN" zone and put the interfaces in to their corresponding zones. Alternatively, you may use one interface for your LAN, another for your Servers and another for your WAN. You could then create a "Server" zone along with the "LAN" and "WAN" zone and have each interface allocated to its own zone.

The "self" zone is completely different to the User Configurable zone. For starters, you cannot rename it and you cannot allocate any interfaces to it. Instead, the "self" zone is a system zone which is dedicated to permitting and denying traffic destined for the router itself. For example, telnetting or SSH'ing in to the router to configure it.

Finally, a Zone Member is a the term used to describe an interface which has been put in to a zone. For example, if you put Fa0/0 in the "LAN" zone, it is a member of the "LAN" zone.

Zone Traffic

Cisco's "Rules For Applying Zone-Based Policy Firewall" explains what happens when traffic flows through these zones. However, I feel that their explanations may be a little too techy for those who are new to the subject so below I have provided my translations:

  • A zone must be configured before interfaces can be assigned to the zone.
  • An interface can be assigned to only one security zone.

You must define zones that you want to use (e.g "SERVER", "LAN", "WAN" etc). Once you have done that, you need to put your interfaces in to their corresponding zones. Note, interfaces can only be put in to a single zone.

  • All traffic to and from a given interface is implicitly blocked when the interface is assigned to a zone, except traffic to and from other interfaces in the same zone, and traffic to any interface on the router.
  • Traffic is implicitly allowed to flow by default among interfaces that are members of the same zone.

If you put Fa0/0 in the "LAN" zone and Fa0/1 in the "WAN" zone, hosts connected to these two interfaces will not be able to communicate by default. However, if both interfaces were in the same zone (e.g "WAN"), they will be able to communicate by default.

  • In order to permit traffic to and from a zone member interface, a policy allowing or inspecting traffic must be configured between that zone and any other zone.

To allow two hosts who reside in different zones (e.g  Fa0/0 in the "LAN" zone and Fa0/1 in the "WAN" zone) you need to configure a policy.

  • The self zone is the only exception to the default deny all policy. All traffic to any router interface is allowed until traffic is explicitly denied.

Unlike the situation mentioned above where traffic between Fa0/0 in the "LAN" zone and Fa0/1 in the "WAN" zone is not allowed by default, traffic which is destined for the router itself is allowed by default. In other words, hosts connected to Fa0/0 and Fa0/1 can telnet, ping, SSH, SNMP poll, etc the router without having to configure any policies.

  • Traffic cannot flow between a zone member interface and any interface that is not a zone member. Pass, inspect, and drop actions can only be applied between two zones.

As mentioned previously, if Fa0/0 and Fa0/1 are in the same zone, they can communicate with one another by default. If they are in different zones they cannot communicate by default, but a policy can be configured to allow it. However, this dot point explains that if Fa0/0 is in the "LAN" zone and F0/1 has not been put in to any zone, hosts connected to these interfaces will not be able to communicate at all.

  • If it is required that an interface on the box not be part of the zoning/firewall policy. It might still be necessary to put that interface in a zone and configure a pass all policy (sort of a dummy policy) between that zone and any other zone to which traffic flow is desired.
  • From the preceding it follows that, if traffic is to flow among all the interfaces in a router, all the interfaces must be part of the zoning model (each interface must be a member of one zone or another).

Situations may arise where you want to use ZFW on some interfaces but not others. For example, you want to use ZFW on your WAN interface but you don't deem it necessary to use it on your LAN and Server interfaces. As mentioned above you can't simply put your WAN interface in a ZFW zone and leave your LAN and Server interfaces without zone configurations as zoned and non-zoned interfaces cannot communicate. The solution to this problem is to put your LAN and Server interfaces in to a zone and configure it to "pass" all traffic. (I will expand on this point in my next blog post).

  • The only exception to the preceding deny by default approach is the traffic to and from the router, which will be permitted by default. An explicit policy can be configured to restrict such traffic.

I'm not too sure why Cisco put this dot point at the end of the list given that it appears that they're making reference to the "self" zone dot point earlier on in the list. Anyway, this point is saying that "although traffic to and from the self zone is enabled by default, a policy can be implemented to restrict the traffic which is destined for the router.

Before I wrap this section up I must stress the importance of implementing a policy on the "self" zone. As mentioned above, all traffic sourced from and destined for the router (aka the "self" zone) is permitted by default. This means that if you've got telnet, SSH, HTTP, HTTPS, SNMP, FTP, etc enabled on your router, be aware that by default people on the internet can also attempt to exploit these protocols.

Class Maps

Class Maps are used to to define the firewall rules. You can create as many as you like and use them on as many zones as you like (through the use of a Policy Map). Further to this, using the the "match-any" and "match-all" statements in your Class Maps allows for very granular rules.

Policy Maps

Policy Maps are used to group multiple Class Maps in to a single policy. (More on this in my next blog post).

Zone Pairs

In order to apply your firewall rules, you must attach a Policy Map to a Zone Pair. (This will also be expanded on in my next blog post).

Update 

Part 2 of this series has been published.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Sunday, August 4, 2013

Subnetting Made Easy, Part 3

Note: For the previous post in this series, please see the "Subnetting Made Easy, Part 2" post.

Recently I received an e-mail from a reader who was having trouble with one of their labs. The lab required them to write an ACL which matches only part of a subnet, as opposed to the whole subnet which is what is commonly seen in lab environments. The details are as follows:

Network Address: 192.168.0.192 /27
Usable Addresses: 192.168.0.193 - 192.168.0.222
Subnet Mask: 255.255.255.224
Wildcard Mask: 0.0.0.31

The range of addresses inside the subnet which need to be matched are:

Match Addresses: 192.168.0.193 - 192.168.0.206

In order to create the ACL, the author needs to find out which wildcard mask matches only the above mentioned addresses.

The Solution

The solution I use to answer this question is the same one I use when I'm summarising routes. I convert the necessary octet to binary and then find the least significant bit that matches both the lowest IP address and highest IP address in the range. In this case the details are as follows:

Octet: 4th (given that the network address is a /27)
Lowest IP: 192.168.0.193
Highest IP: 192.168.0.206

            /25 /26 /27 /28 /29 /30 /31 /32
            128  64  32  16   8   4   2   1
Network:     1    1   0   0   0   0   0   0  = 192
Lowest IP:   1    1   0   0   0   0   0   1  = 193
Highest IP:  1    1   0   0   1   1   1   0  = 206

As highlighted above, first, second third and fourth most significant bits match. The fifth bit however, does not. This therefore means the fourth bit is the one we're looking for. From this we can deduce the following:

Network Address: 192.168.0.192 (the 192 is because of the 128 + 64 as shown above)
Subnet Mask: 255.255.255.240 (/28) - (This is because the four most significant bits match)
Wildcard Mask: 0.0.0.15 - (Inverse of the Subnet Mask - 255 - 240 = 15)

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Tuesday, July 30, 2013

Shape Average Vs Shape Peak - Part 3

In my previous post in this series I covered the difference between Shape Average, Shape Peak and Shape with no Excess. Now that that's out of the way, let's get down to configuration examples. I'll use similar specifications to the ones I used last time:
  • CIR = 512kbps (512,000 bps)
  • Bc = 5,120 bps
  • Tc = 10ms (0.001 seconds)
  • Be = 5,120 bps for Shape Average and Shape Peak. (Shaping with no Excess will be covered in my next post).

Shape Average

Below is a basic Shape Average policy map with a 512kb shaper applied.

R1(config)#policy-map ShapeAverage-512k
R1(config-pmap)# class class-default
R1(config-pmap-c)#shape average 512000
R1(config-pmap-c)#interface fa0/0
R1(config-if)#service-policy output ShapeAverage-512k
R1(config-if)#do sh policy-map int f0/0

 FastEthernet0/0

  Service-policy output: ShapeAverage-512k

    Class-map: class-default (match-any)
      0 packets, 0 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)
           512000/512000    3200   12800     12800     25        1600

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

Shape Peak

Below is a basic Shape Peak policy map with a 512kb shaper applied.

R1(config)#policy-map ShapePeak-512k
R1(config-pmap)#class class-default
R1(config-pmap-c)# shape peak 512000
R1(config-pmap-c)#interface fa0/0
R1(config-if)#  service-policy output ShapePeak-512k
R1(config-if)#do sh policy-map int f0/0

 FastEthernet0/0

  Service-policy output: ShapePeak-512k

    Class-map: class-default (match-any)
      0 packets, 0 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)
          1024000/512000    3200   12800     12800     25        3200

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

Analysis

The first thing to note is that I did not have to configure the Bc and Be values myself, the router did it for me. In fact, as mentioned in my previous post, Cisco do not recommend choosing these values manually.

The next thing to note is the interval. As there is no configuration command which allows me to manually set the Tc, it would appear that I'm stuck using the router's default 25ms. This therefore means that our Bc and Be figures are incorrect too. (More on this in my next post).

The final thing to note is the two parts of the "show" outputs which I underlined. The "Rate" and the "Interval". The Shape Average policy map has a Target/Average of 512,000/512,000. This is because as described previously, unused Shape Average tokens are put in to the Be bucket for use by future Tc intervals. This allows the router to still reach (but not exceed) its 512k/sec even when it encounters Tc intervals which do not use all of the Bc tokens.

On the other hand the Shape Peak policy map has a Target/Average of 1,024,000/512,000. This is because (as also described previously), Shape Peak allows the router to use Bc + Be every interval, regardless of whether there were unused Bc tokens in the previous Tc or not. Therefore, as Be = Bc by default, this allows the router to send traffic up to 1mb/sec.

Configuring a shaper with no excess burst requires manually setting the Bc and Be values so it will be covered in my next post, as will changing the Tc interval.

Note: See the Understanding MQC Series for more information.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Saturday, July 20, 2013

EIGRP No Auto Summary Command, Part 2

A few years ago I wrote a blog post about EIGRP and the "auto-summary" command, which I have now renamed EIGRP No Auto Summary Command, Part 1 (to make room for this post to be called Part 2). In that post I provided a brief description of what "auto-summary" does and demonstrated how it works by creating a basic lab. Now that you've seen the basics though, it is time to dig a little deeper.

In the previous post we saw that R1 and R2 were both automatically summarising the 10.45.100.0/24 and 10.16.0.0/24 networks respectively and therefore R3 and R4 could not reach one another. That's seems normal enough seeing as though the command is called "auto-summary". However, things aren't that simple unfortunately.

For example, take a look at this topology:


Both routers are running EIGRP, but only R1 has the "auto-summary" command enabled, as per the configurations below:

R1:

R1(config-router)#do sh run | s router ei
router eigrp 1
 network 10.1.1.1 0.0.0.0
 network 10.2.2.2 0.0.0.0
 network 10.10.10.2 0.0.0.0
 network 172.16.1.1 0.0.0.0
 auto-summary

R2:

R2(config-router)#do sh run | s router ei
router eigrp 1
 network 10.10.10.1 0.0.0.0
 no auto-summary

Due to the "auto-summary" command being used it would be easy to assume that R1 would advertise two summary addresses - 10.0.0.0/8 and 172.16.0.0/16 to R2 instead of its /24 routes. However, this is not the case:

R2:

R2(config-router)#do sh ip route | b Gate
Gateway of last resort is not set

D    172.16.0.0/16 [90/409600] via 10.10.10.2, 00:17:22, FastEthernet0/0
     10.0.0.0/24 is subnetted, 3 subnets
C       10.10.10.0 is directly connected, FastEthernet0/0
D       10.2.2.0 [90/409600] via 10.10.10.2, 00:17:22, FastEthernet0/0
D       10.1.1.0 [90/409600] via 10.10.10.2, 00:17:22, FastEthernet0/0


Above we see two different things:
Highlighted in Blue we see the 172.16.0.0/16 summary route which we were expecting given that R1 is using the "auto-summary" command.
Highlighted in Green we see the individual 10.x.x.x/24 addresses being advertised from R1 instead of the /8 summary route we were expecting.

So this leaves us with the question - why is it that the 172.16.1.0/24 network was successfully summarised but the 10.x.x.x/24 networks weren't? The answer is that when "auto-summary" is enabled, routes are only summarised when both of the following requirements are met:

1) The router is directly connected to two differing IP address classes.
2) An advertisement must go from one class to the other.

Further to this, only these directly connected networks' addresses will be summarised. All non-directly connected networks which are advertised to this router ARE NOT summarised (I will provide more information on this in a future blog post).

Let me expand on the two requirements (forget the part in red for now as it may be too confusing to try to comprehend it all in one hit) - In the above diagram we can see that R1 has addresses which belong to two classful boundaries:

10.0.0.0/8 (Class A) which consists of the following networks -
10.1.1.0 /24
102.2.0 /24
10.10.10.0 /24

172.16.0.0/16 (Class B) which consists of the following networks -
172.16.1.0 /24

Given that R1 has direct connections to Class A and Class B addresses, this means that the first requirement has been met.

Next, we see that R1 and R2 have formed an adjacency over their Class A addresses. This means that the 10.x.x.x /24 networks do not conform to the second requirement, however, it also means that the  172.16.1.0 network does. This is because the 172.16.1.0 network (Class B) is being advertised to a neighbour who is on a Class A network.


As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Friday, May 24, 2013

MTU Vs MSS - Part Two

Previously I published a blog post called MTU Vs MSS - Part One. At the time the plan was to follow it up with Part Two a short time later, however, here it comes over a year late :) I do apologise for that.

What prompted me to get back to writing Part Two was an e-mail from a reader who asked how I came to the conclusion that using the "ip tcp adjust-mss" command affects a SYN packet's MSS regardless of whether it is applied to the inbound or outbound interface. The reader also asked if I have any links to documentation that describes this. The way in which I came to the conclusion was by labbing it up. Unfortunately though I do not have any documentation that backs me up.

This blog post will demonstrate the lab I used to come to the above conclusion.

Here is the topology that I used. I have marked each link with a letter to mark the points at which the proceeding packet captures were done. (Note that PC1 and PC2 are GNS3 routers with their icons changed).


No MSS Change

Before making any changes to the MSS, I'll first initiate a telnet session from PC1 to PC2.

Packet Capture from PC1's F0/0 interface ("A"):


Packet Capture from R2's F0/1 interface ("B"):





Looking at the above captures we can see that the PC1 sent an MSS of 536 in its SYN packet, and PC2 responded with an MSS of 536 in its SYN/ACK packet.


R2 F0/0 MSS Change

Now that we've done our benchmark test, let's see what happens when we set an MSS of 500 on R2's F0/0 interface.

R2(config)#int f0/0
R2(config-if)#ip tcp adjust-mss 500

Now let's repeat the telnet test:

Packet Capture from PC1's F0/0 interface ("A"):


Packet Capture from R2's F0/1 interface ("B"):




Here we can see that when the packet leaves PC1, it is sending its SYN packet with an MSS of 536, but when the packet leaves R2, the MSS has changed to 500.


R2 F0/1 MSS Change

Now I'll remove the "ip tcp adjust-mss" command from R2's F0/0 interface and will apply it to R2's F0/1, this time using an MSS of 510.

R2(config)#int f0/1
R2(config-if)#ip tcp adjust-mss 510

Now let's repeat the telnet test:

Packet Capture from PC1's F0/0 interface ("A"):




Packet Capture from R2's F0/1 interface ("B"):




Here we can see the results are the same as the ones seen when the "ip tcp adjust-mss" command was put on R2's F0/0 interface.


MSS on Both Interfaces

As you might expect, if you set the  "ip tcp adjust-mss" command on both of the router's interfaces, it will use the lower of the two.


As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Saturday, May 18, 2013

Understanding MQC Series

Series Index

I am in the process of writing a series of blog posts which will cover:
  • Modular QoS CLI (MQC)
  • Weighted Fair Queue (WFQ)
  • Class-Based Weighed Fair Queuing (CBWFQ)
  • Low Latency Queuing (LLQ)
To assist readers in keeping track of these posts, I will update this page each time a new entry is published.

Series Entries

Here are the links to the posts which have been published to date:

Understanding MQC, Part 1: The Basics
Understanding MQC, Part 2: Basic Configuration
Understanding MQC, Part 3: Output Analysis

Other Reading

Before you jump in to the above posts though, you may want to have a read of these first:

Shape Average Vs Shape Peak - Part 1
Shape Average Vs Shape Peak - Part 2
Shape Average Vs Shape Peak - Part 3

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Understanding MQC, Part 3: Output Analysis

In my previous blog post I implemented a basic QoS configuration. In this post I will demonstrate how the "bandwidth" and "priority" commands treat their respective classes, as well as how to interpret the "show policy-map interface" command output.

Parent Shaper 

Below is the output seen when the "show policy-map interface" command is issued. The Parent Policy's class-default Class Map (at the top of the output seen below) represents all of the Child Class Maps' counters put together.

For example, if 5 packets are dropped from the "MATCH-Voice" Class Map and 10 packets are dropped from the "MATCH-BulkData" Class Map, 15 drops will be shown under the Parent Policy. 

Router#sh policy-map int gi 0/1
 GigabitEthernet0/1

  Service-policy output: PARENT-EGRESS-Shaper

    Class-map: class-default (match-any)
      1 packets, 68 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 2/158
      shape (average) cir 1024000, bc 4096, be 4096
      target shape rate 1024000

      Service-policy : CHILD-EGRESS-BandwidthAllocation

        queue stats for all priority classes:
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0

        Class-map: MATCH-BulkData (match-any)
          0 packets, 0 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match:  dscp af33 (30)
            0 packets, 0 bytes
            30 second rate 0 bps
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0
          bandwidth 300 kbps

        Class-map: MATCH-Voice (match-any)
          0 packets, 0 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match:  dscp ef (46)
            0 packets, 0 bytes
            30 second rate 0 bps
          Priority: 150 kbps, burst bytes 3750, b/w exceed drops: 0
         

        Class-map: class-default (match-any)
          1 packets, 68 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match: any
         
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 1/98


Offered & Dropped Rate 

 The "Offered Rate" and "Dropped Rate" figures are important figures to take note of. It gives you an average of how many bits per second each class has Class has sent and dropped respectively for an interval (the default interval is 5 minutes, however, I have changed it to 30 seconds using the load-interval 30 command). 

As demonstrated below, if a Class or multiple Classes do not use their allocated bandwidth, their "Offered Rate" will be less than their allocated bandwidth. This unused bandwidth can then be used by other Classes who require it. Due to this there will be times where you will see a Class' "Offered Rate" being higher than their allocated bandwidth.

Note: It is important to keep in mind that the "Offered" and "Dropped" rates are an average. This means that if you're using a 5 minute interval and there is a traffic one minute traffic spike, it is very likely that you won't see it in the "Offered" and "Dropped" rate figures.

Bandwidth command

This demonstration shows how the router treats the "Bulk Data" traffic when there is no load coming from any other sources.

iperf test:

[1912] local 192.168.10.101 port 1265 connected with 192.168.20.101 port 5001
[ ID] Interval       Transfer     Bandwidth
[1912]  0.0- 1.0 sec   128 KBytes  1.05 Mbits/sec
[1912]  1.0- 2.0 sec   120 KBytes   983 Kbits/sec
[1912]  2.0- 3.0 sec   128 KBytes  1.05 Mbits/sec
[1912]  3.0- 4.0 sec   120 KBytes   983 Kbits/sec
[1912]  4.0- 5.0 sec   120 KBytes   983 Kbits/sec
[1912]  5.0- 6.0 sec   120 KBytes   983 Kbits/sec
[1912]  6.0- 7.0 sec   120 KBytes   983 Kbits/sec
[1912]  7.0- 8.0 sec   120 KBytes   983 Kbits/sec
[1912]  8.0- 9.0 sec   120 KBytes   983 Kbits/sec
[1912]  9.0-10.0 sec   120 KBytes   983 Kbits/sec
[1912] 10.0-11.0 sec   120 KBytes   983 Kbits/sec
[1912] 11.0-12.0 sec   120 KBytes   983 Kbits/sec
[1912] 12.0-13.0 sec   120 KBytes   983 Kbits/sec
[1912] 13.0-14.0 sec   120 KBytes   983 Kbits/sec
[1912] 14.0-15.0 sec   120 KBytes   983 Kbits/sec
[1912]  0.0-15.2 sec  1.78 MBytes   984 Kbits/sec


Policy Map output:

Router(config-if)#do sh policy-map int gi 0/1
 GigabitEthernet0/1

  Service-policy output: PARENT-EGRESS-Shaper

    Class-map: class-default (match-any)
      1494 packets, 1970729 bytes
      30 second offered rate 118000 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 1533/1980890
      shape (average) cir 1024000, bc 4096, be 4096
      target shape rate 1024000

      Service-policy : CHILD-EGRESS-BandwidthAllocation

        queue stats for all priority classes:
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0

        Class-map: MATCH-BulkData (match-any)
          1372 packets, 1941896 bytes
          30 second offered rate 114000 bps, drop rate 0 bps
          Match:  dscp af33 (30)
            1372 packets, 1941896 bytes
            30 second rate 114000 bps
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 1372/1941896
          bandwidth 300 kbps

        Class-map: MATCH-Voice (match-any)
          0 packets, 0 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match:  dscp ef (46)
            0 packets, 0 bytes
            30 second rate 0 bps
          Priority: 150 kbps, burst bytes 3750, b/w exceed drops: 0
         

        Class-map: class-default (match-any)
          122 packets, 28833 bytes
          30 second offered rate 4000 bps, drop rate 0 bps
          Match: any
         
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 122/28787
 

Analysis

Looking at the iperf test, we can see that average speed achieved as 984kb/sec. This may seem strange seeing as though we specifically assigned 300kb to this class. However, as mentioned above, MQC Classes are allowed to use other Classes' bandwidth if it is not being used.

Looking at the MATCH-BulkData section of the router output, we can confirm that the packets are being matched and prioritised correctly.

Priority command

This demonstration shows how the router treats the "Voice" traffic when there is no load coming from any other sources.

iperf test:

[1912] local 192.168.10.101 port 1266 connected with 192.168.20.101 port 5002
[ ID] Interval       Transfer     Bandwidth
[1912]  0.0- 1.0 sec   184 KBytes  1.51 Mbits/sec
[1912]  1.0- 2.0 sec  0.00 Bytes  0.00 bits/sec
[1912]  2.0- 3.0 sec   768 KBytes  6.29 Mbits/sec
[1912]  3.0- 4.0 sec   136 KBytes  1.11 Mbits/sec
[1912]  4.0- 5.0 sec  72.0 KBytes   590 Kbits/sec
[1912]  5.0- 6.0 sec   144 KBytes  1.18 Mbits/sec
[1912]  6.0- 7.0 sec   112 KBytes   918 Kbits/sec
[1912]  7.0- 8.0 sec  80.0 KBytes   655 Kbits/sec
[1912]  8.0- 9.0 sec   160 KBytes  1.31 Mbits/sec
[1912]  9.0-10.0 sec  72.0 KBytes   590 Kbits/sec
[1912] 10.0-11.0 sec  8.00 KBytes  65.5 Kbits/sec
[1912] 11.0-12.0 sec  0.00 Bytes  0.00 bits/sec
[1912] 12.0-13.0 sec  8.00 KBytes  65.5 Kbits/sec
[1912] 13.0-14.0 sec  8.00 KBytes  65.5 Kbits/sec
[1912] 14.0-15.0 sec  16.0 KBytes   131 Kbits/sec
[1912] 15.0-16.0 sec  0.00 Bytes  0.00 bits/sec
[1912]  0.0-16.9 sec  1.73 MBytes   862 Kbits/sec


Policy Map output:

Router(config-if)#do sh policy-map int gi 0/1
 GigabitEthernet0/1

  Service-policy output: PARENT-EGRESS-Shaper

    Class-map: class-default (match-any)
      1555 packets, 2131519 bytes
      30 second offered rate 61000 bps, drop rate 6000 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/138/0
      (pkts output/bytes output) 1418/1927733
      shape (average) cir 1024000, bc 4096, be 4096
      target shape rate 1024000

      Service-policy : CHILD-EGRESS-BandwidthAllocation

        queue stats for all priority classes:
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 1298/1899284

        Class-map: MATCH-BulkData (match-any)
          0 packets, 0 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match:  dscp af33 (30)
            0 packets, 0 bytes
            30 second rate 0 bps
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0
          bandwidth 300 kbps

        Class-map: MATCH-Voice (match-any)
          1436 packets, 2103396 bytes
          30 second offered rate 57000 bps, drop rate 4000 bps
          Match:  dscp ef (46)
            1436 packets, 2103396 bytes
            30 second rate 57000 bps
          Priority: 150 kbps, burst bytes 3750, b/w exceed drops: 138
         

        Class-map: class-default (match-any)
          119 packets, 28123 bytes
          30 second offered rate 4000 bps, drop rate 0 bps
          Match: any
         
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 119/28351

 

Analysis

Looking at the iperf test, we can see that average speed achieved as 862kb/sec. Like the "bandwidth" command, the "priority" command also allows the use of extra bandwidth should it be available.

Looking at both the iperf test and the MATCH-Voice outputs we can see that multiple packets were dropped. The reason why we see drops when performing the Voice test but not the Bulk Data test is due to the "priority" and "bandwidth" commands. While the "bandwidth" command allows packets to be queued and sent when there is bandwidth available, the "priority" command (which uses Low Latency Queuing (LLQ)) sends the data straight away or it drops it. This is because, despite its name, LLQ does not queue packets. The reason for this is simple. When using a time-sensitive application, queuing packets would introduce too much delay which would result in packets arriving too late to be used. The queuing would then cause subsequent packets to be queued too and therefore they would be delayed as well, meaning that the router will always be trying to catch up. Instead, by dropping packets instead of delaying them, subsequent packets will be able to be delivered on time.

Another interesting thing to note here is that as per the MATCH-Voice output above, 138 packets were dropped. If you look at the router's interface counters, you will see that the drops also appear there too:

Interface output: 

Router(config-if)#do sh int gi0/1 | i drops
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops:
138
  Output queue: 0/1000/138 (size/max total/drops)


Multiple Streams

When there are multiple streams of data (Voice traffic, Bulk Data traffic and Unclassified traffic) being sent simultaneously, the policy output looks like this:

Router(config-if)#do sh policy-map int gi 0/1
 GigabitEthernet0/1

  Service-policy output: PARENT-EGRESS-Shaper

    Class-map: class-default (match-any)
      6630 packets, 9284598 bytes
      30 second offered rate 932000 bps, drop rate 39000 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 51/239/0
      (pkts output/bytes output) 6413/8931702
      shape (average) cir 1024000, bc 4096, be 4096
      target shape rate 1024000

      Service-policy : CHILD-EGRESS-BandwidthAllocation

        queue stats for all priority classes:
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 963/1395762

        Class-map: MATCH-BulkData (match-any)
          1839 packets, 2606098 bytes
          30 second offered rate 281000 bps, drop rate 0 bps
          Match:  dscp af33 (30)
            1839 packets, 2606098 bytes
            30 second rate 281000 bps
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 17/0/0
          (pkts output/bytes output) 1839/2606098
          bandwidth 300 kbps

        Class-map: MATCH-Voice (match-any)
          1202 packets, 1754308 bytes
          30 second offered rate 121000 bps, drop rate 38000 bps
          Match:  dscp ef (46)
            1202 packets, 1754308 bytes
            30 second rate 121000 bps
          Priority: 150 kbps, burst bytes 3750, b/w exceed drops: 239
         

        Class-map: class-default (match-any)
          3589 packets, 4924192 bytes
          30 second offered rate 530000 bps, drop rate 0 bps
          Match: any
         
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 32/0/0
          (pkts output/bytes output) 3589/4924428


Analysis

When situations like this occur, you will find that each Class will have an "offered" rate which is very close to the the Class' allocated bandwidth amount. If one or more of the Classes drops below their allocated bandwidth amount you will see their "offered rate" drop, however, you will also see one or more of the other classes' "offered rate" rate increase. This is because, as demonstrated previously, Classes can consume more than their allocated bandwidth should it be available.


Unallocated Bandwidth

All bandwidth which has not been allocated to a Class is given to the Child Policy's "class-default".

Also, as mentioned in my previous post, anything which does not match a manually configured Class (which in this example are the MATCH-BulkData and MATCH-Voice classes) will automatically be sent to the "Class-Default" class. In other words, unless traffic and bandwidth is specifically assigned to a Class, it will be assigned to the Class-Default class.

To verify this, let's take another look at the "show policy-map int gi 0/1" output under the "Multiple Streams" above -

We can see that MATCH-BulkData and MATCH-Voice have an offered rate of 281000 bits (274kb) and 121000 bits (118kb) respectively which is just below their allocated bandwidths of 300kb and 150kb respectively. As we're using a 1mb shaper, this means that we should have about 574kb left over. Looking at the class-default class we can see that it has an offered rate of 530000 bits (517kb) - which is very close to the 574kb we were looking for.

Sharing Unused Bandwidth

In the above sections I've talked about and demonstrated the fact that Classes can use more bandwidth than they're allocated if there is additional unused bandwidth available.What I have not explained yet though is how the router decides which classes to give the additional bandwidth to should more than one need it.

It is actually very simple - The router uses each Classes' original bandwidth configuration as a weight. The more bandwidth the Class has been configured with, the more "weight" it has, and therefore it will be allocated a larger amount of the unused bandwdith.

For example, above we used the MATCH-BulkData and MATCH-Voice classes, giving them 300kb and 150kb respectively. This means that MATCH-BulkData has twice the amount of "weight" that MATCH-Voice has, and therefore should be allocated twice has much unused bandwidth. Let's run a test and see if that is true:

Router(config-if)#do sh policy-map int gi 0/1
 GigabitEthernet0/1

  Service-policy output: PARENT-EGRESS-Shaper

    Class-map: class-default (match-any)
      6347 packets, 8861862 bytes
      30 second offered rate 920000 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 33/0/0
      (pkts output/bytes output) 6348/8862106
      shape (average) cir 1024000, bc 4096, be 4096
      target shape rate 1024000

      Service-policy : CHILD-EGRESS-BandwidthAllocation

        Class-map: MATCH-BulkData (match-any)
          4136 packets, 5867664 bytes
          30 second offered rate 610000 bps, drop rate 0 bps
          Match:  dscp af33 (30)
            4136 packets, 5867664 bytes
            30 second rate 610000 bps
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 17/0/0
          (pkts output/bytes output) 4136/5867664
          bandwidth 300 kbps

        Class-map: MATCH-Voice (match-any)
          2084 packets, 2955204 bytes
          30 second offered rate 307000 bps, drop rate 0 bps
          Match:  dscp ef (46)
            2084 packets, 2955204 bytes
            30 second rate 307000 bps
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 14/0/0
          (pkts output/bytes output) 2084/2955204
          bandwidth 150 kbps

        Class-map: class-default (match-any)
          127 packets, 38994 bytes
          30 second offered rate 6000 bps, drop rate 0 bps
          Match: any
         
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 127/39178


As we can see above, MATCH-BulkData has an Offered Rate of 610000 bits (310000 additional bits taken from the unused "Class-Default" class). We can also see that  MATCH-Voice has an Offered Rate of 307000 bits (157000 additional bits taken from the unused "Class-Default" class). This confirms that MATCH-BulkData was allocated very close to double the amount of bits which MATCH-Voice was given.

Note: You may have noticed that I changed MATCH-Voice to a "bandwidth 150" in the last output above. The reason for this is because as shown above, using the "priority" command with iperf results in quite a lot of packet loss, therefore it would affect the "Offered Rate" shown.

Below is another test which demonstrates the splitting of unused bandwidth. MATCH-BulkData again uses the "bandwidth 300" statement but this time MATCH-Voice has used the "bandwidth 100" command. This therefore means that MATCH-BulkData should be allocated three times as much unused bandwidth as compared to MATCH-Voice:

BO1-RTR-2951(config-pmap-c)#do sh policy-map int gi 0/1
 GigabitEthernet0/1

  Service-policy output: PARENT-EGRESS-Shaper

    Class-map: class-default (match-any)
      6267 packets, 8720258 bytes
      30 second offered rate 897000 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 35/0/0
      (pkts output/bytes output) 6288/8725874
      shape (average) cir 1024000, bc 4096, be 4096
      target shape rate 1024000

      Service-policy : CHILD-EGRESS-BandwidthAllocation

        Class-map: MATCH-BulkData (match-any)
          4580 packets, 6497848 bytes
          30 second offered rate 669000 bps, drop rate 0 bps
          Match:  dscp af33 (30)
            4580 packets, 6497848 bytes
            30 second rate 669000 bps
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 17/0/0
          (pkts output/bytes output) 4580/6497848
          bandwidth 300 kbps

        Class-map: MATCH-Voice (match-any)
          1544 packets, 2188764 bytes
          30 second offered rate 226000 bps, drop rate 0 bps
          Match:  dscp ef (46)
            1544 packets, 2188764 bytes
            30 second rate 226000 bps
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 16/0/0
          (pkts output/bytes output) 1544/2188764
          bandwidth 100 kbps

        Class-map: class-default (match-any)
          143 packets, 33646 bytes
          30 second offered rate 4000 bps, drop rate 0 bps
          Match: any
         
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 143/33908


As we can see above, MATCH-BulkData has an Offered Rate of 669000 bits and MATCH-Voice has an Offered Rate of 226000 bits. This confirms that MATCH-BulkData was allocated very close to three times the amount of bits which MATCH-Voice was given.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Understanding MQC, Part 2: Basic Configuration

In my previous post I mentioned the six steps which are required in order to implement a QoS solution. In this post I'll use those steps to create an example implementation. Before I do though, I'll first cover the "bandwidth" and "priority" commands.

Priority & Bandwidth Commands

In Step 3 of the process you must assign a a portion of bandwidth to the Class Map. The two main options used here are "priority"and "bandwidth". Details on these two options can be found here.

In short though, the "priority" command is used for time sensitive applications where packets need to be sent ASAP, for example, VoIP calls. To ensure that these packets are sent as soon as possible, the router uses a special queuing process called Low Latency Queuing (LLQ) whereby all priority packets are sent immediately, even if there are other packets which on the router first.

The "bandwidth" command is used for non-time sensitive traffic, such as large file backups.

Basic Configuration

Now that we've covered the basics, let's jump in to a Basic Configuration example using the Six Steps outlined in my previous post.

I'll be using iperf to generate traffic in my lab network. The two traffic flows I will prioritise are:

Interface Shape: 1mb

Bulk Data Traffic:
Source IP:  192.168.10.101
Destination IP: 192.168.20.101
Destination Port: 5001
DSCP Marking: AF33
Bandwidth: 300kb

Voice Traffic:

Source IP:  192.168.10.101
Destination IP: 192.168.20.101
Destination Port: 5002
DSCP Marking: EF
Priority: 150kb

Step 1 - Classify Class Map

Note: I'll be using ACLs to match the desired traffic, however, protocols can also be matched through the use of NBAR.

The "classify" ACLs look like this:

ip access-list extended BULK_DATA
permit tcp host 192.168.10.101 host 192.168.20.101 eq 5001
 

!
ip access-list extended VOICE
permit tcp host 192.168.10.101 host 192.168.20.101 eq 5002


Now we need to create the "classify" Class Maps and tie them to the above ACLs:

class-map match-any  MARK-BulkData
match access-group name BULK_DATA
!

class-map match-any  MARK-Voice
match access-group name VOICE


Step 2 - Inbound Policy Map

Next, we have to tie the above "classify" Class Maps to a Policy Map and assign the DSCP values to each of the Classes:

policy-map INGRESS-Mark-DSCP
  class MARK-BulkData
    set dscp af33 

!
  class MARK-Voice
    set dscp ef
 

Now we apply the Policy Map in the inbound direction on the router's LAN facing interface:

interface gi0/2.10
  desc LAN Port - Ingress Packet Marking 
  service-policy input INGRESS-Mark-DSCP

Step 3 - Prioritisation Class Map

Note: These Class Map names do not need to match the ones used in Step 1.

Here we match the DSCP values which were configured in Step 2:

class-map match-any MATCH-BulkData
  match dscp af33

class-map match-any MATCH-Voice
  match dscp ef

 

Step 4 - Bandwidth Allocation Policy Map (Child)

Now we allocate the bandwidth to each of the above Class Maps using another Policy Map.

Recall that this Policy Map will not be applied to an interface and will instead be applied underneath another Policy Map. That is why this Policy Map is known as a "Child" Policy Map:

policy-map CHILD-EGRESS-BandwidthAllocation
  class MATCH-BulkData
    bandwidth 300
!
  class MATCH-Voice
    priority 150


Step 5 & 6 - Shaper Policy Map (Parent)

Here we create the Parent Policy Map as well as apply the 1mb shaper. We then attach the Child Policy Map to it.

policy-map  PARENT-EGRESS-Shaper
  class class-default
    shape average 1024000
    service-policy CHILD-EGRESS-BandwidthAllocation
 

Now we apply the Parent Policy Mapoutbound on the router's WAN facing interface:

interface gi 0/1
  service-policy output PARENT-EGRESS-Shaper


Class-Default

Before I end this post I thought I should quickly mentioned the "Class-Default" class. Anything which does not match a manually configured Class (which in this example are the MATCH-BulkData and MATCH-Voice classes) will automatically be sent to the "Class-Default" class. The same goes for unallocated bandwidth. Both of these scenarios are discussed in my next post.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.