Kevin Dorrell, CCIE #20765

30 Mar 2008

13.12 Router QoS

Filed under: QoS — dorreke @ 11:27

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.
Advertisements

26 Mar 2008

NMC Lab 13

Filed under: General, IP Routing Protocols — dorreke @ 23:39

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.

24 Mar 2008

QoS study week

Filed under: Frame Relay, QoS — dorreke @ 12:33

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 BC+BE, and the bucket overflows at BC+BE, 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.

23 Mar 2008

FRTS : Frame-Relay Traffic-Shaping

Filed under: Frame Relay, QoS, WAN — dorreke @ 20:10

Cisco Documentation

Cisco Tech Notes

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

 

21 Mar 2008

CHECKiT result

Filed under: General — dorreke @ 10:00

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!

18 Mar 2008

CHECKiT tests and Don Juan

Filed under: General — dorreke @ 23:00

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.

17 Mar 2008

More “Gotchas”

Filed under: General — dorreke @ 09:04

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.

16 Mar 2008

NMC Lab 12.7.5 : EIGRP uneven load-balancing

Filed under: EIGRP — dorreke @ 18:15

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

Filed under: EIGRP, IP Routing Protocols, OSPF, Redistribution — dorreke @ 17:44

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.
 

15 Mar 2008

NMC Lab 11 : Role-Based CLI Access

Filed under: IOS features, Security — dorreke @ 16:21

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.

Older Posts »

Create a free website or blog at WordPress.com.