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.

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 : Redistribution

Here is my redistribution diagram:

 It looks complicated, but in fact it isn’t.  It looks complicated ‘cos I added a lot of information to the diagram as I want along.

Since this lab contains multiple loops and no less than four active redistribution points, we have to be careful with filtering and Administrative Distances.   I look at the filtering first, which prefixes get passed from which domain to which other, then I look at the Administrative Distance to control which routes are preferred at the border routers.  I prefer not to rely on AD to control redistribution; I find the filtering tools such as route maps are better for that.  AD is only relevant at border routers, and I use it to control forwarding preferences.

Controlling redistribution with tags 

Everything gets tagged as it is redistributed, to say where it originally came from.  Once a prefix is tagged, it usually keeps its tag, even through subsequent redistributions.  That way, I can base my filters on the tags.  Any prefix that is not yet tagged must be internal to the domain we are in.  (I use that property later to distinguish RIP native prefixes, rather than have to list them explicitly.)  Here are the tags I have used in this lab:

• Tag 12 = EIGRP 12 native prefixes
• Tag 34 = EIGRP 34 native prefixes
• Tag 110 = OSPF native prefixes
• Tag 120 = RIP native prefixes

Routing domains

Looking at the diagram, we have two transit domains (RIP and OSPF) and two edge domains (EIGRP 10 and EIGRP 34). 

The edge domains only have to send out their native prefixes into the RIP and OSPF.  At first, they will only receive prefixes that are not their own natives.  (Later, I shall look at the possibility of them receiving their own fed-back prefixes to repair them if they are broken.)

Traffic between the edge domains will pass through either RIP or OSPF.  RIP and OSPF will have to pass prefixes through from one edge domain to the other.  One thing I shall not attempt to do (at least for now) is to get the transit domains to repair each other if they are broken.  That would really make it complicated.

Redistribution rules

R1 has no less than six redistribution route-maps.  Only the listed prefixes get redistributed, everything else is implicitly denied.

• RIP–>EIGRP : RIP natives get tagged 120, EIGRP 34 natives keep thier tag.
• OSPF–>EIGRP : OSPF internals get tagged 110, EIGRP 34 natives keep their tag.
• EIGRP–>RIP : EIGRP internals get tagged 12
• OSPF–>RIP : OSPF internals get tagged 110
• EIGRP–>OSPF : EIGRP internals get tagged 12
• RIP–>OSPF : RIP internals get tagged 120

Everything gets tagged, or gets to keep its existing tag. 

I prefer to set redistribution metrics inside the route-map rather than as a default or in the redistribute command.  It is more granular and controllable. 

OSPF and EIGRP have tools to distinguish internal prefixes: match route-type internal.  RIP does not.  How can we distinguish the RIP native prefixes from its externals?  Most NMC answers do this with an access list or prefix list.  I prefer to do it by match tag 0.  They must be RIP natives because they have not been tagged yet.

Since this router touches all three domains (EIGRP 12, RIP, OSPF) there is no point in any of these domains redistributing each others’ prefixes.  The only external prefixes taht need to be redistributed are EIGRP 34 prefixes from the transit domains (RIP and OSPF) to EIGRP 12.

There is an important point to make about “EIGRP 34 natives keep their tag”.  In this particular case, I could get away with:

match tag 34
  set metric 1500 50 255 1 1500

That is, the tag is automatically preserved as you redistribute.  But here is a “gotcha”: that does not apply to prefixes redistributed into RIP.  They lose the tag on the way, so the route-map has to regenerate it.  I make a habit of regenerating the tag in all cases anyway:

match tag 34
  set tag 34
  set metric 1500 50 255 1 1500

The situation at R3 is exactly the converse of R1:

• RIP–>EIGRP : RIP natives get tagged 120, EIGRP 12 natives keep thier tag.
• OSPF–>EIGRP : OSPF internals get tagged 110, EIGRP 12 natives keep their tag.
• EIGRP–>RIP : EIGRP internals get tagged 34
• OSPF–>RIP : OSPF internals get tagged 110
• EIGRP–>OSPF : EIGRP internals get tagged 34
• RIP–>OSPF : RIP internals get tagged 120

I have treated R2 and R4 as warm-standby redistribution points.  Each has only two redistributions.  R4 is the converse of R2, which looks like this:

• OSPF–>EIGRP : OSPF internals get tagged 110, EIGRP 34 natives keep their tag.
• EIGRP–>OSPF : EIGRP internals get tagged 12

Note that the diagram does not show “EIGRP 34 natives keep their tag”, except as “OSPF ext ?”.  This is because I added it as a refinement during testing.

Administrative Distances at Border Routers

Once I have decided what to redistribute at the active border routers, I then have to look at the routes on the border routers themselves.  This includes both the active border routers (i.e. ones that are doing redistribution) and passive border routers (i.e. ones where two or more routing protocols meet, but that are not doing any redistribution).  The routes at the border routers can be optimised using the Administrative Distances.

Let us look first at the ADs on R1.  I have:

• 90 = EIGRP 12 internal prefixes (default)
• 110 = OSPF internal prefixes (default)
• 120 = RIP prefixes, and EIGRP 34 prefixes via RIP (default)
• 130 = OSPF external prefixes (EIGRP 34 prefixes via OSPF)
• 170 = EIGRP external prefixes (from R2 via EIGRP)

The last of these is the only one that needs to be configured explicitly: distance ospf external 130.  This ensures that R1 uses RIP to get to the EIGRP prefixes rather than going through OSPF, and also ensures that the RIP prefixes do not get dispaced out of R1’s routing table by the same prefix as an OSPF external.  The rest are defaults.  None of the AD=170 prefixes will find their way into the forwarding table unless somethong is broken, because there will always be a better route.

On R3, we have exactly the converse:

• 90 = EIGRP 34 internal prefixes
• 110 = OSPF internal prefixes
• 120 = RIP prefixes, and EIGRP 12 prefixes via RIP
• 130 = OSPF external prefixes (EIGRP 12 prefixes via OSPF)
• 170 = EIGRP external prefixes (from R4 via EIGRP)

Now to look at R2.  As I have already said, R4 is just the converse of R2.  These are the ADs that I chose on R2:

• 90 = EIGRP 12 internal prefixes
• 110 = OSPF internal prefixes
• 170 = EIGRP external prefixes (EIGRP 12 and RIP prefixes via R1) 
• 180 = OSPF external prefixes (EIGRP 12 and RIP prefixes via OSPF)

By putting the OSPF external prefixes down at 180, R2 will prefer to go through EIGRP over the same external prefixes over OSPF.

So, that’s my design for the redistribution scenario.

Additional Challenges

The scenario AK throws out some additional challenges.  The first is “How would it complicate matters if the loopbacks on R6, CAT1 and CAT2 were redistributed into EIGRP as connected routes?”  So let’s try.  Instead of reconfiguring Lo106, I am going to add Lo116 141.11.116.1/24.

As I have been careful about what I redistribute, I am going to have to add it to the route maps EIGRP–>OSPF and EIGRP–>RIP on R1 and R2.  So I shall tag it with 116 as I inject it into EIGRP in the first place, and then use the tag to insert it into the route-maps.  When passing it into RIP and OSPF, I shall re-tag it as 12 because it is effectively part of EIGRP by proxy.

First, let me predict what will happen.  I think the route will get redistributed into OSPF on R1 and end up at AD=180 on R2.  That is fine, because it will have an AD of 170 within EIGRP.  It will also get redistributed into OSPF on R2, and end up on R1 with an AD=130.  That is not so fine, because it means that R1 will prefer to go though OSPF and R2 to get to it.  That is exactly what happened:

R1#show ip route 141.11.116.0
Routing entry for 141.11.116.0/24
  Known via "ospf 11", distance 130, metric 20
  Tag 12, type extern 2, forward metric 64
  Redistributing via eigrp 12, rip
  Last update from 141.11.10.2 on Serial0/0.10, 00:01:38 ago
  Routing Descriptor Blocks:
  * 141.11.10.2, from 141.11.102.1, 00:01:38 ago, via Serial0/0.10
      Route metric is 20, traffic share count is 1
      Route tag 12

The problem is that we have redundant border routers between EIGRP and OSPF.  They should be told not to use each others’ redistrubuted routes.  What I would like to do is this:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#router ospf 11
R1(config-router)#distance 180 141.11.102.1 0.0.0.0
R1(config-router)#exit
R1(config)#exit

That would tell R1 to treat any route that originated on R2 as AD=180.  The trouble is that it would also affect 141.11.102.1/24.  That means we would have to solve it by listing the prefix.  Ugh!

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#access-list 16 permit 141.11.116.0 0.0.0.255
R1(config)#router ospf 11
R1(config-router)#distance 180 141.11.102.1 0.0.0.0 16
R1(config-router)#^Z
R1#

R1#show ip route 141.11.116.0
Routing entry for 141.11.116.0/24
  Known via "eigrp 12", distance 170, metric 537602560
  Tag 116, type external
  Redistributing via ospf 11, eigrp 12, rip
  Advertised by ospf 11 subnets route-map EIGRP-->OSPF
  Last update from 141.11.16.6 on FastEthernet0/0.60, 00:00:19 ago
  Routing Descriptor Blocks:
  * 141.11.16.6, from 141.11.16.6, 00:00:19 ago, via FastEthernet0/0.60
      Route metric is 537602560, traffic share count is 1
      Total delay is 1000100 microseconds, minimum bandwidth is 5 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
      Route tag 116 R1#show ip route 141.11.102.0
Routing entry for 141.11.102.0/24
  Known via "ospf 11", distance 110, metric 65, type inter area
  Redistributing via eigrp 12, rip
  Advertised by eigrp 12 route-map OSPF-->EIGRP
                rip route-map OSPF-->RIP
  Last update from 141.11.10.2 on Serial0/0.10, 00:00:26 ago
  Routing Descriptor Blocks:
  * 141.11.10.2, from 141.11.102.1, 00:00:26 ago, via Serial0/0.10
      Route metric is 65, traffic share count is 1

But yuk!  An access-list!  Now, I have always said that what I would really like to do is to determine the AD of a route according to its tag.  This is an example where it would have been useful.  I should be able to tell R1 “If OSPF tells you about external routes with a tag of 12 (or perhaps 116), then mark them down to AD=180 because you should already have a better route to them via EIGRP.”

IOS Gotcha : no redistribute eigrp 12 subnets route-map EIGRP–>OSPF

This has to be  my favorite IOS gotcha.  I already struggle enough with redistribution without throwing this into the mix.  Here goes …

The story so far is that this lab has multiple loops and no less than four active redistribution points.  I have already redistributed OSPF onto EIGRP, and I have prepared a filter route-map for distributing EIGRP into OSPF.  This is what I have so far:

R2#show run | sec ospf
 ip ospf network point-to-point
 ip ospf 11 area 2
 ip ospf network point-to-multipoint
 ipv6 ospf 100 area 25
 redistribute ospf 11 route-map OSPF-->EIGRP
router ospf 11
 router-id 141.11.102.1
 log-adjacency-changes
 network 141.11.10.0 0.0.0.255 area 0
 distance ospf external 180
 redistribute ospf 100 include-connected
ipv6 router ospf 100
 router-id 141.11.102.1
 log-adjacency-changes
 redistribute connected
 redistribute bgp 100 metric 20

(BTW, I have done another posting about the dangers of the “section” filter.)

So let’s do the redistribution:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router ospf 11
R2(config-router)# redistribute eigrp 12 subnets route-map EIGRP-->OSPF
R2(config-router)#^Z
R2#

So far so good.  So I go off and have a look at the routes on the other routers, and I see I have got it almost right, but not quite.  Let’s remove the redistribution while I think about it.  As you know, to negate a command, you just put “no” in front of it.  So up-arrow through the config commands, and do this:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router ospf 11
R2(config-router)#no redistribute eigrp 12 subnets route-map EIGRP-->OSPF
R2(config-router)#^Z
R2#

Suddenly all hell breaks loose on the other routers.  All the routes go unstable, and I have lots and lots of output fom my debug ip routing.  What has happened?  Here’s what:

R2#show run | sec ospf
 ip ospf network point-to-point
 ip ospf 11 area 2
 ip ospf network point-to-multipoint
 ipv6 ospf 100 area 25
 redistribute ospf 11 route-map OSPF-->EIGRP
router ospf 11
 router-id 141.11.102.1
 log-adjacency-changes
 redistribute eigrp 12
 network 141.11.10.0 0.0.0.255 area 0
 distance ospf external 180
 redistribute ospf 100 include-connected
ipv6 router ospf 100
 router-id 141.11.102.1
 log-adjacency-changes
 redistribute connected
 redistribute bgp 100 metric 20
R2#

We are still redistributing EIGRP 12 into OSPF, but we have removed the route-map filter.

The correct way to remove the redistribution would have been no redistribute eigrp 12.

P.S. Re-reading this, I can see that I have chosen a less-than-ideal example.  But it still illustrates the point that the no redistribute protocol route-map route-map command does not remove the redistribution but simply opens it up.  The example is less than ideal because in this case it has also removed the “subnets” keyword, and so is unwittingly quite benign.  If I had chosen an EIGRP or RIP example, it would have been much more of a problem.

Frame-Relay multipoint or physical interfaces

 If you want to skip the blah-blah, you may want to go directly to the table below.  You will then want to read the blah blah to see what it is about.

 I’m not sure how much sense I made in yesterday’s posting.  The point was that we had a Frame Relay multipoint interface with a bridge-group on it.  Spanning Tree assumes that all devices on a segment can see each other’s broadcasts.  But this is not so with FR-MP or physical.

It got me thinking.   Frame Relay multipoint and physical interfaces are great for CCIE scenario writers.  They have so many issues.  That is because they are NBMA.  Many many protocols assume a multi-access segment is a broadcast segment.  NBMA breaks this rule because as often as not there is no visibility from spoke to spoke.  Most of the literature says “Here is a technology X.  This is how you configure it.  BTW, there is a special requirement for NBMA networks, and you have to do this … “.

I want to look at it from a different angle.  I want to make a list the things that NBMA cannot do, and how you can get round it for each technology.  I want to be able to say “OK, we have a FR multipoint.  They have obviously specified that in order to mess something up.  Which technologies are likely to be impacted?

So here is the list:

Technology	Gotcha	Solution
RIP	RIP will not normally advertise out an interface it received the route on.  Not a problem in Frame Relay because split-horizon is disabled by default, but is a problem in other NBMA technologies such as X.25.	1. no ip split-horizon on interface (by default in FR) 2. Static neighbor spoke to spoke (TTL=2)
EIGRP	EIGRP will not advertise out an interface it received the route on	1. no ip split-horizon eigrp nn on interface 2. Static neighbor spoke to spoke (TTL=2)
OSPF network	No LSAs seen spoke-to-spoke	1. ip ospf priority 0 on spokes to force DR on hub 2. ip ospf network point-to-multipoint throughout
OSPF NSSA	If one spoke is an ASBR and talks OSPF to the hub, but another spoke does not talk OSPF but has a route to the the prefix, what can happen to the forward address.  Might be unreachable?	Still thinking about this !
bridge-group	No visibility spoke-to-spoke	There will usually be some alternate route between the STP root and the spoke.  Contrive Spanning Tree to block all but one of the circuits on the multipoint and therefore use alternate route.
PIM dense-mode	If multicast source is behind the hub, then a prune from one spoke will prune all of them.  If multicast source is on a spoke, then it will not be routed out the same interface to another spoke.	Find an alternate route for all but one of the spokes, or even for all of them.  Usually, this can be done with a tunnel, or by leveraging some alternate path to the source.  Use static ip mroute
PIM sparse-mode	If multicast source is on a spoke, then it will not be routed out the same interface to another spoke.	ip pim nbma-mode.  Or treat in same way as dense mode above.

Can anyone suggest anything to add to the list?

These issues are not limited to Frame Relay multipoint.  I have seen NMC labs where they contrive to turn an Ethernet segment into a NBMA segment, typically by creating unicast peering between routers on the Ethernet, and therefore not allowing them full-mesh.

NMC Lab 10 Redistribution

 Here is my redistribution scheme for Lab 10:

Looking at the diagram, there do not seem to be any active feedback paths, so I should get away without having to tag or filter.  The routing domains are in a straight line:

EIGRP 200 <–> EIGRP 100 <–> OSPF <–> RIP

There are three active border routers, show by the arrows: CAT1, CAT2, and R1.  As there are no active feedback paths, they should not require any special treatment.  There are a further three passive border routers: R2, R3, and R6.  I can adjust the Administrative Distances at those, to ensure optimal routing.

Looking at R2, here are the priorities:

• 90 = (default) EIGRP 200 internal prefixes
• 110 = (default) OSPF internal prefixes
• 120 = (configured) OSPF external prefixes from R1 only.  Practically, all the RIP prefixes.
• 170 = (default) EIGRP externals.  Practically Lo102, Lo105, EIGRP 100 prefixes
• 180 = (configured) other OSPF externals.  Practically, this could only be EIGRP 100 prefixes coming back through OSPF, and then only if CAT1 or R5 fails.

I know the scenario does not ask to repair the EIGRP 200 prefixes if CAT1 or R5 fails, but I reckon it’s easier to slap a penalty on them rather than filter them on R2.  I think I can achieve that on R2 like this:

router ospf 10
  distance ospf external 180
  distance 120 172.16.101.1 0.0.0.0

Now for R3 and R6.  These are identical.  The first thing I notice is that they will perfer the OSPF routes to anything else.  The 172.16.10.0 prefix is OK, because it is firmly “connected” on both R3 and R6.  What else is in RIP, and should not be seen via OSPF on R3 and R6.  Well, Lo101 and Lo103 for a start.  My first stab at solving this was:

router ospf 10
  distance ospf external 130

Rethinking, that would cause a problem to the EIGRP 100 routes; they are external to OSPF too, and they should definitely be seen at R3 and R6 through OSPF.  So, abandon that idea.  I guess I am going to have to admit defeat and make an access list on each of R1, R3, and R6 to give RIP priority over OSPF for prefixes Lo101 and Lo103.  I hate using access-lists or prefix-lists to optimise routing.  It feels much too unscalable.  I prefer a generic solution.  But needs must, and this is a CCIE lab, not the real world.  

I can’t wait to try it all out.  No, I promised myself I would wait until tomorrow before I try anything.

Wendell Odom’s CCIE R&S Certification Guide

Took my 15-year-old to his Blues School (guitar club) in Differdange.  It wasn’t worth driving all the way home again and then all the way back to collect him, so I sat in the car for a couple of hours reading Wendell Odom’s CCIE Cert Guide.  What a great book it is!  When I was doing my CCNA back in 1999 I wasn’t such a fan of his CCNA Cert Guide.  But the CCIE book is one of the most relevant, pithy, and challenging books I have on my bookshelf.  No doubt the CCNA guide has also improved in the intervening 8 years.

I have the second edition of the CCIE book.  Every time I dip into the book it comes up with a new way of looking at something I thought I knew.  Today’s subjects were:

• Default routes and the various ways to introduce them into RIP, EIGRP, OSPF (pages 345 – 251) and BGP (pages 381 – 382).  It goes into the differences in behavior between the different protocols with the different techniques.  For example, whether the default route must already be in the table for default-information originate to work.  (RIP: yes, but not if static; OSPF: yes, unless you have keyword always; EIGRP: not supported; BGP: yes for global version of the command, no for neighbor specific command)
    
• QoS MQC for marking.  I didn’t realise that a class-map can have multiple match lines for the same attribute.  For example, you could accidentally have match cos 3 and match cos 5 in the same match-all class definition, which would match nothing at all.  That’s a good gotcha!
   
• BGP Route Reflectors (pages 404 – 409).  I hadn’t appreciated the rules about what happens when you have some RR clients and some non-RR clients on the same hub, and more importantly, why.  The answer is that all routes are reflected except non-RR-client to non-RR-client.  For the why, you’ll have to read the book.  Suddenly the concept of cluster-ids became crystal clear. 

[Warning! Off Topic! Warning!] 

Next week, he wants me to go into the Blues School with him, which would mean I would miss all that reading.  Or am I just afraid of revealing how rusty my guitar technique really is?

Talking of guitars, isn’t Andy McKee incredible?  I was lucky enough to see him in concert here in Luxembourg a few weeks ago, and he really can play this stuff:

Amazing!  There are so many great guitarists around at the moment that I don’t know who gets my vote for the best guitarist in the world today: Andy McKee, Antoine Dufour, or Don Ross.

I also wanted to see if I could embed a YouTube clip in my blog.  Seems I can.

NMC Lab 09 – The Golden Moment

It’s week 9, so I’m doing NMC Lab 09.  This time I think I have reach the full reachability as fast as I can: 2 hours and 20 minutes.  I was cautious – maybe over cautious – about the redistribution, only redistributing internal routes of each protocol.  (Except for RIP, which is out on a limb and therefore can be redistributed blindly.)  Of course, that left me with a lot of redistributing connected, but that was allowed by the scenario.

R4-Lo104 was the joker in the pack, because there were no instructions.  I redistributed it into both OSPF and EIGRP just for good measure.  I then looked at R3 and decided the 104 subnet would be better handled by EIGRP than OSPF.  In fact, if the R3 chooses the OSPF route to Lo104, then R6 never sees it.  So I punished every OSPF LSA coming from R4 with distance 180 172.16.104.1 0.0.0.0 at R3.  (The 172.16.104.1 being the router ID of R4 … it is only coincidence that it is also the subnet we are trying to manipulate.)  Probably would have been easier if I had just sent it into EIGRP and not to OSPF.

I suspect they wanted me to put the R2-R5 link into OSPF area 12, and use the R2-S1/0 address for the unnumbered reference on the Tunnel.  So just to be perverse, I didn’t do it that way.  Insead, I based my tunnel on R1-L101 and R2-L102, and I activated the OSPF on it with the interface command ip ospf 9 area 12.  That left me free to use whatever area I chose for the R2-R5 link.  I chose area 25, and made a string of virtual links across area 25 and area 51.

 There is something that makes me want to put a virtual link between R1 and R2 across area 12 to leverage that nice fast Ethernet segment rather than going through the Frame Relay.  I’ll bear that in mind if there is any RPF issue in the multicast.

More tomorrow.  The IPv6 and Cat 3560 sections look a bit heavy.  But it’s late now, the rest of the family are in bed already (one with ‘flu) and I need my sleep.

Redistribution

One topic that wastes a lot of my time during CCIE practice labs is redistribution.  The issues often catch me unawares.  I wonder whether I can improve my performance by changing my approach.

So far, my method has been “detect, diagnose, and fix”.  Detect by setting debug ip routing and by examining routing tables.  Diagnose by looking at the symptoms to try and to figure out what is going on.  Fix by filtering and by manipulating distances.   It is the diagnose bit that takes the time.

Many people emphasise prevention.  This is largely based on making sure you don’t redistribute more than is absolutely necessary.  That helps, but it does not guarantee there will be no issues.

I want to see if I can benefit from a topology-based issue-spotting approach.  I’m sure that the successful CCIE condidates have a wide experience to draw on: that they can recognise certain situations and instinctively know how to deal with them.  I would like to build up a repertoire of issues that I can address before they trip me up.

For each case, I want to list:

• the alarm bells that should have alerted me to the impending issue
• the contributary factors, the circumstancial evidence
• the modus operandi of the issue
• the tools and techniques for fixing it.

For example, I tripped over an issue in NMC Lab 08 that could briefly described like this:

Name: RIP border loop 

Alarm bell: Border router with two “neighbors” (i.e. next-hops) in RIP domain

Contributary factors: Route injected into RIP at AD > RIP (120)

Modus operandi: Bidirectional route feedback within RIP, leading to race condition, and possibly overwriting the injected route at the border router.

Tools and techniques: Try not to inject route at AD > RIP.  If that is not possible, filter routes coming into border router from the RIP neighbors to allow only RIP native routes.

 Here is another one:

Name: OSPF<–>RIP, redundant BR (I need a more succinct name for this one)

Alarm bell: Two border routers between OSPF and RIP

Contributary factors: None – this situation is already the issue itself

Modus operandi: Bistable sub-optimal routing for RIP-native routes. (One border router will route RIP routes correctly, the other will route them via the OSPF external route.)  Possible race condition if both are redistributing OSFP<–>RIP.

Tools and techniques:  Each border router punishes OSPF external routes from the other by setting AD > RIP (120).  Filter redistributed routes to prevent RIP routes finding their way back into RIP.

For each of these cases, I would like to write a posting with a lot more detail under each of the four headings.