13.12 Router QoS

Notes to self:

• When making a policy-map, there is no need to include a class-default clause unless the default requires a policy.  The class-default is transmitted by default.
• When doing single threshold policing, the default actions are confirm=transmit, exceed =drop.  There is no need to specify thos explicitly.  In that case, the command is simply police <cir-bps> <burst-bytes>
• I wonder if it would have been acceptable to specify the access list only on the top level policer.  After all, the lower level policers are applied only within classes that are already contingent on the access-list.

NMC Lab 13

It is week 13, so I should be doing Lab 13.  I have done this one before, way back in 2006 week 43.  I don’t remember much about it, but according to my notes I did it on a remote rack last time.  This time I am doing it on my own rack.

I am quite pleased that I achieved full IGP connectivity in two hours, 21:00 to 23:00.  However, I wasn’t happy with my summarisation.  This lab has lots of summarisation and filtering, and in particular I wasn’t happy about sections 13.4.5, 13.4.6 and 13.5.5.  So I spent an extra half hour whittling down a solution and checking it out with the TCL scripts.  Essentially, they were all about not being allowed to summarize in the obvious router, but leveraging summarizations that had already been done elsewhere.

QoS study week

This week, I want to concentrate some effort on understanding QoS, particularly shaping and policing.  I am fed up with losing 2 to 8 points every time I do a mock lab because I have not got a firm grasp of the subject.  Sometimes I muddle through.  I know the commands, and usually I can match up the parameters in the requirements with the parameters of some command or other, but I am not confident.

I read the chapter in the Wendell Odom book this morning.  It all seemed to make sense, but it left me wondering about two points:

1. If you are traffic-shaping, and you have a frame in the queue that is longer than B_C+B_E, and the bucket overflows at B_C+B_E, how do you ever get enough tokens in the bucket to transmit it?
2. If CB policing replenishes the bucket(s) with a prorata number of tokens according to how long ago was the last frame transmitted, if there is a long silence so the last frame transmitted was a very long time ago, then is the bucket replenished with an enormous number of tokens.  Doesn’t that make the traffic very very bursty?
3. On page 566, he states “FRTS cannot classify traffic in order to shape a subset of traffic on a particular VC.”  But you can specify a service-policy within a map-class.  And in the corresponding policy map, you can specify policing under the class-default.  So what happens if you try and specify other classes in the policy map?

No doubt these things will become clearer as I read more.

FRTS : Frame-Relay Traffic-Shaping

Cisco Documentation

• Cisco IOS WAN Configuration Guide : Frame Relay
• Cisco IOS QoS Configuration Guide : Shaping and Policing

Cisco Tech Notes

• Configuring Frame Relay Traffic Shaping on 7200 Routers and Lower Platforms.

• Configuring Packet Marking on Frame Relay PVCs

Books and Course Notes

• CCIE R&S Exam Certification Guide, Wendel Odom, 2nd edition, pages 565 – 570.
• CCIE Practical Studies Volume I, Karl Solie, pages 363-369
• Cisco : “Implementing Cisco QoS”, version 2.1, module 7 “Understanding Traffic Policing and Shaping”, esp. Lesson 4 “Configuring Class-Based Shaping on Frame Relay Interfaces”

Practical examples 

• DOiT Labs 6, 8, 18, 20
• CCIE Practical Studies Volume I, Karl Solie, Lab 14 on pages 382 – 391

 

CHECKiT result

Well, the new strategies paid off.  I got the equivalent of a pass, which is way above what I got on my last two attempts.  I am really really pleased.  The hard study seems to be paying off as well.  Of course, I cannot rest on my laurels, and I shall have to look hard at the bits I missed.  There is still a long way to go.  But I am encouraged by the headway.

As it turned out, opening the scenario an hour before the official start time was not cheating at all.  Guess what … the US has gone onto summertime already and so my start time was an hour before I thought it was!

CHECKiT tests and Don Juan

On Thursday I shall do a NMC CHECKiT to see if I have made any progress over the last few weeks.  I am apprehensive.  Every time I do a CHECKiT, I start off confident: “I think I have finally cracked it.”  Every time, something crops up in the test to throw me off course.  (I cannot go into detail because, understandably, there is an NDA to be respected.)  This time I am confident, as usual.

I am going to change my strategy slightly this time.   One thing I shall do is to stop doing any labs for the two days before the test.  Last time, I lost a few points stupidly ‘cos I got confused between the DOiT labs I was currently following and the CHECKiT test.  I was imagining some general constraints in the CHECKiT test that simply were not there.  (You know, of the “no ip default-network”, “no 0.0.0.0/0 route”, “no policy routing” type.)  Of course, if a general constraint is usually there but is missing from the particular lab, that is a pretty fair indication you will need it somewhere.  Is that strategy tantamount to cheating?

The other thing I am going to do will look like cheating myself, but I shall try not to make it so.  I have a problem with time management.  I start reading the scenario, but my fingers get so itchy that I start configuring stuff before I know properly what I am doing.  I have a problem with self-discipline.  So this time I intend to open the scenario one hour before my official rack start time, and stop one hour before the end fo the official rack time.  In that way I will be forced to spend an hour reading the scenario.  I shall have to stop early anyway ‘cos I have to pick my son up from school near the end of my rack time.

So, no labs this evening.  Instead, I spent part of the evening trying to follow Richard Strauss “Don Juan” from the score.  My wife has to write an essay about it.  I cannot help her with the essay (for obvious reasons, and also because such an analysis is anyway outside my mindset).  But at least I can help follow the music on the page.  It’s a good way of re-booting the brain ready for Thursday.

More “Gotchas”

After yesterday’s debacle, I realise I need to make a list of redistribution behaviors that have caught me out.  For now, I have added them to my IOS gotchas page.

NMC Lab 12.7.5 : EIGRP uneven load-balancing

This section is a study in unequal load balancing in EIGRP using the variance command.  We have R5 that is being fed identical routes from R2 and R3.  It is load-sharing 1:1.  We have to change that ratio 6:1 in favour of R2.  The way they do it in the AK is to increase the delay on the interface towards R3 until it gets only 1/6 share of the traffic.  We end up with something like this on R5:

R5#show ip route 151.10.104.0
Routing entry for 151.10.104.0/24
  Known via "eigrp 100", distance 170, metric 20537600, type external
  Redistributing via eigrp 100
  Last update from 151.10.25.2 on Serial1/0, 00:14:14 ago
  Routing Descriptor Blocks:
  * 151.10.35.3, from 151.10.35.3, 00:14:14 ago, via Serial1/1
      Route metric is 123225600, traffic share count is 1
      Total delay is 4032250 microseconds, minimum bandwidth is 128 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
    151.10.25.2, from 151.10.25.2, 00:14:14 ago, via Serial1/0
      Route metric is 20537600, traffic share count is 6
      Total delay is 21000 microseconds, minimum bandwidth is 128 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

R5#show ip eigrp topology 151.10.104.0/24
IP-EIGRP (AS 100): Topology entry for 151.10.104.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 20537600
  Routing Descriptor Blocks:
  151.10.25.2 (Serial1/0), from 151.10.25.2, Send flag is 0x0
      Composite metric is (20537600/1732096), Route is External
      Vector metric:
        Minimum bandwidth is 128 Kbit
        Total delay is 21000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
      External data:
        Originating router is 151.10.102.1
        AS number of route is 12
        External protocol is OSPF, external metric is 66
        Administrator tag is 0 (0x00000000)
  151.10.35.3 (Serial1/1), from 151.10.35.3, Send flag is 0x0
      Composite metric is (123225600/1732096), Route is External
      Vector metric:
        Minimum bandwidth is 128 Kbit
        Total delay is 4032250 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
      External data:
        Originating router is 151.10.103.1
        AS number of route is 12
        External protocol is OSPF, external metric is 65
        Administrator tag is 0 (0x00000000)
R5# 

The original metric was 20537600 on both of these routes, but by adding to the delay on the interface, we have loaded the route via 151.10.35.3 until it is 6 times that through 151.10.25.2.

I thought I would be clever and try and do it another way, using an offset list.  So I removed the loading on the interface, and added offset-list 1 input 102688000, where access-list 1 defines the OSPF routes we want to re-balance.  That should bring the metric to 123225600.  Trouble is, it doesn’t work.  The route disappears altogether.  Why?

Well, when we add delay to our local interface, we add to the metric sure, but the “advertised distance” to the downstream router, R2, remains unaffected.  In this case it is 1732096.  OTOH, if we use an offset-list, it adds not only to the metric, but also to the “advertised distance”.  In this case, it becomes 104420096.  This is greater than the total metric of the route via R2, so we fail the “feasible successor” test.

Key point: Adding to the interface delay increases the local metric but leaves the neighbor’s apparent advertised distance unchanged.  An offset-list, OTOH, adds to the apparent advertised distance of the neighbor.

NMC Lab12 : Redistribution OSPF–>EIGRP

While I was doing this lab, I came across some strange behavior.  If you redistribute from OSPF to EIGRP through a route-map, and that map specifies the route-type, (local, internal, external, etc.) then there seems to be no way to include the connected interfaces.

For example, using NMC Lab 12 as a test-bed, I removed the redistribution on R2 and concentrated on R3.  R3 is connected to 151.10.43.0/24, which is in OSPF.  We are redistributing OSPF into EIGRP, and watching the routes turn up through EIGRP on R5:

R3#
:
router eigrp 100
 redistribute ospf 12 metric 1500 100 255 1 1500
:

On R5, we can see a route to 151.10.43.0/24:

R5#show ip route 151.10.43.0
Routing entry for 151.10.43.0/24
  Known via "eigrp 100", distance 170, metric 123225600, type external
  Redistributing via eigrp 100
  Last update from 151.10.35.3 on Serial1/1, 00:00:45 ago
  Routing Descriptor Blocks:
  * 151.10.35.3, from 151.10.35.3, 00:00:45 ago, via Serial1/1
      Route metric is 123225600, traffic share count is 1
      Total delay is 4032250 microseconds, minimum bandwidth is 128 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

I have prepared a route-map on R3 to distribute through.  Let us include locally generated routes and internal routes:

R3#show run
:
route-map OSPF-->EIGRP permit 10
 match route-type local
!
route-map OSPF-->EIGRP permit 20
 match route-type internal
!

Now let us apply the route map:

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#router eigrp 100
R3(config-router)#redistribute ospf 12 metric 1500 100 255 1 1500 route-map OSPF-->EIGRP
R3(config-router)#^Z
R3#

Look what happens on R5.  We lose the route to 151.10.43.0/24.  It does not seem to be getting past the route-map.

R5#
*Mar  1 19:29:31.788: RT: delete route to 151.10.43.0 via 151.10.35.3, eigrp metric [170/123225600]
*Mar  1 19:29:31.792: RT: SET_LAST_RDB for 151.10.43.0/24
  OLD rdb: via 151.10.35.3, Serial1/1 *Mar  1 19:29:31.792: RT: no routes to 151.10.43.0
*Mar  1 19:29:31.792: RT: NET-RED 151.10.43.0/24
*Mar  1 19:29:31.792: RT: delete subnet route to 151.10.43.0/24
*Mar  1 19:29:31.796: RT: NET-RED 151.10.43.0/24
R5#

I would have thought the connected interface would at least be counted as a locally generated route.  How do I write a route-map to include the connected interfaces?  (Assuming that, as in this case, the scenario forbids you to redistribute the connecteds directly.)  Well, the only way I can think of is to make an access-list listing the connected prefixes of the source protocol, and add a clause to the route-map that matches the access list.  Normally I am reluctant to use access lists to filter redistributions because it is not scaleable.  However, in this case it is not so bad because it is only the locally connected prefixes you are listing.  It is still scaleable.

Key Point: If you redistribute from OSPF through a route-map, and that route-map filters by route-type, the connected networks are no longer included.

If anyone else has observed this, or can repeat the experiment, could you please leave a comment?  Thanks.
 

NMC Lab 11 : Role-Based CLI Access

I am looking at section 11.12 – Router Management – which I skipped when I did this lab.  This is all about role-based CLI Access.  Using this feature, you can define different views of the CLI for different users, and retrict what they can do in each.  I think it is unlikely to come up in the exam, but it is as well to know about it.  The feature is described in the Security documentation, and not in the Configuration Fundamentals where I first looked for it.