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.