Kevin Dorrell, CCIE #20765

16 Mar 2008

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, which is in OSPF.  We are redistributing OSPF into EIGRP, and watching the routes turn up through EIGRP on R5:

router eigrp 100 
 redistribute ospf 12 metric 1500 100 255 1 1500 

On R5, we can see a route to

R5#show ip route 
Routing entry for 
  Known via "eigrp 100", distance 170, metric 123225600, type external 
  Redistributing via eigrp 100 
  Last update from on Serial1/1, 00:00:45 ago 
  Routing Descriptor Blocks: 
  *, from, 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 

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

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

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.

14 Mar 2008

NMC Lab 11 : Redistribution

Filed under: EIGRP, IP Routing Protocols, OSPF, Redistribution, RIP — dorreke @ 05:23

Here is my redistribution diagram:

NMC Lab 11 Redistribution

 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

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 
Routing entry for 
  Known via "ospf 11", distance 130, metric 20 
  Tag 12, type extern 2, forward metric 64 
  Redistributing via eigrp 12, rip 
  Last update from on Serial0/0.10, 00:01:38 ago 
  Routing Descriptor Blocks: 
  *, from, 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 

That would tell R1 to treat any route that originated on R2 as AD=180.  The trouble is that it would also affect  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 
R1(config)#router ospf 11 
R1(config-router)#distance 180 16 
R1#show ip route 
Routing entry for 
  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 on FastEthernet0/0.60, 00:00:19 ago 
  Routing Descriptor Blocks: 
  *, from, 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 
Routing entry for 
  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 on Serial0/0.10, 00:00:26 ago 
  Routing Descriptor Blocks: 
  *, from, 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.”

13 Mar 2008

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

Filed under: Redistribution — dorreke @ 05:07

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 
 network area 0 
 distance ospf external 180 
 redistribute ospf 100 include-connected 
ipv6 router ospf 100 
 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 

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 

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 
 redistribute eigrp 12 
 network area 0 
 distance ospf external 180 
 redistribute ospf 100 include-connected 
ipv6 router ospf 100 
 redistribute connected 
 redistribute bgp 100 metric 20 

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.

05 Mar 2008

NMC Lab 10 Redistribution

Filed under: Redistribution — dorreke @ 05:59

 Here is my redistribution scheme for Lab 10:

Lab 10 Redistribution

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

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

25 Feb 2008

NMC Lab 09 – The Golden Moment

Filed under: IP Addressing Services, OSPF, Redistribution — dorreke @ 23:48

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 at R3.  (The 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.

23 Feb 2008


Filed under: IP Routing Protocols, Redistribution — dorreke @ 06:47

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.

20 Feb 2008

NMC Lab 8

Filed under: BGP, Frame Relay, IP Routing Protocols, PPP, Redistribution, RIP, WAN — dorreke @ 14:31

Took a day out of work today to see what I could get out of Lab 8.  Once again, the lab caught me unawares in several places.  Here are some of the lessons:

8.1.4. PPP over Frame Relay

I had not done a PPP over Frame Relay before.  It is an interesting technique involving configuring a Virtual-Template interface that then spawns a Virtual-Access interface when it connects.  Here for the Cisco Configuration guide.

One configuration “gotcha” caught me out.  I have tripped over so many “gotchas” in the past that I have decided to make a list of them (top right, under “pages”) and write a small posting on each.

It is interesting that the example in the Cisco doument has three levels of interface: a physical interface, a point-to-point subinterface that defines the DLCI, and the PPP Virtual-Template.  The NMC answer key has only two: they go straight from the physical interface to the Virtual-Template.  Pros and Cons of each approach? 

One thing I did not manage to do: to get R3 and R4 to ping their own addresses on the PPP link.  They could each ping their partner’s address, but not their own.  I spent a long time trying to get this to work before giving up and looking at the AK.  Then I find that their solution doesn’t reach those addresses either.  They might have said so!  I have asked the question on the DISCUSSiT forum, but there seems to be less and less activity there.

Redistribution into RIP

Beware any border router that has two interfaces in the RIP domain; there could be an internal loop within the RIP domain.  In particular, beware of injecting any external route that has an AD more than 120.  The injected route will go round the loop, and appear at the other interface with a greater hop count, but an AD of 120, where it will overwrite the original injected route.  The route can thrash.  Or not … if you are lucky, the updates will go both ways round the loop and meet on some other non-border router, where they are safe.  There is a similar lesson in Lab 23, but with a rather simpler loop.

8.7. BGP

I have already had a good rant about the apalling contradictory requirements of this section.  Now I must concentrate of what I can learn from this section:

  • A BGP speaker, even if a route reflector, will not send a prefix to a neighbor that is in that same cluster as the one he learned it from.  The scenario leverages this behavior in an unusual way by deliberately using the feature to break reachability.
  • A route reflector will not touch next-hop information.  Eeven if it has next-hop-self configured, that does not apply to reflected routes.  (The scenario was not intended to teach that but a screw-up in my topology led me down that path.)
  • Interestingly, because next-hop is not touched as the route propagates along the AS 100 chain, the traffic itself takes a shortcut CAT1-R3-R4-CAT2.

I implemented the solution proposed in the AK, and it seemed to work OK.  Then, just to be perverse, I looked around for other solutions that ignored various bits of the requirements.  (Well, their solution ignores requirement 8.7.4., so I felt at liberty to keep 8.7.4 and to ignore something else instead.)  BTW, this section won’t make much sense unless you have the scenario in front of you.

I thought I would try peering R3-CAT2 and R4-CAT1.  That should inject the routes into AS 100 by two different ways, and is not expressly forbidden by the scenario.  My problem was which addresses to peer.  I had no luck peering the loopback addresses, because those have multiple paths, some going back the way you came.  I tried peering with the addresses on the link, but had not luck with that either.  For some reason it does not like peering from a Virtual-Template address:

Feb 20 15:57:15.760: BGP: active open failed - update-source Virtual-Template1 
is not available, open active delayed 25730ms (35000ms max, 28% jitter)

So, I settled on these peerings:

  • CAT1 ( <–> R4 (
  • CAT2 ( <–> R3 (

Really perverse, I know.  It almost worked as well.  The only thing that didn’t work was that if I take down the peering R5<–>R3, then R5 can no longer reach  Conversely, if I take down the peering R2<–>R4, then R2 can no longer reach  R2 is rejecting the route to because it has the same cluster-id.  Or maybe FRS is not sending it, I’m not sure.

I’ve had enough of this BGP scenario for now.  If I get time I shall try some other techniques.  I thought of making AS100 a confederation with a different AS on each router in the chain, and give R2 and R5 the same AS number.  That should do the 8.7.7. trick.  Another possiblity is to mark the route with a community that would make R2 / R5 drop it.  But that’s enough for now.

8.8. VPN

Got this bit OK, but 20 minutes was a little longer than I should have taken over it.  I must be geting tired.  The issue was to keep the infrastructure RIP routes seperate form the VPN RIP routes in R3.  (I thought they were going to implement virtual routers at some point?)  They defined the infrastructure routes as everything except the sepcific VPN routes.  I defined the infrastructure as and the VPN as  Six of one and half-a dozen of the other I suppose.



14 Feb 2008

NMC Lab 07 Redistribution

Filed under: Redistribution — dorreke @ 22:49

I was reading Ethan’s posting about Lab 07 and his useful work on redistribution, and was gratified to find that there was someone else was taking the same path as me, although I think Ethan’s ideas are a bit further down the path than mine.  I rather like the diagrams in the NMC Answer Key, but I really don’t think I would have time to draw anything so sophisticated in a lab test.

Here is my version of the diagram for lab 7 – compare it with Ethan’s.  The idea I shall steal from Ethan from now on is to mark the AD on each circle, perhaps next to its intersection with a router.

(Not sure I shall get the size right here.)


What strikes me about this scenario is there are no redistribution loops, but there are two redistribution “kisses” on R1 and R3.  That makes life easier because we don’t need to think too much about filtering.  But we might need to think about the AD’s of the various alternate routes at R1 and R3.

I think we are OK at R1.  EIGRP has an AD of 90 for internal routes, lower than RIP, while it has an AD of 170 for external routes, higher than RIP.  So R1 will prefer the EIGRP side for native EIGRP routes, and RIP for everything else.  Unfortunately “everthing else” includes the two loopback interfaces that came from EIGRP 103 and EIGRP 106.  Clearly the optimal routing for those is through EIGRP.  So we might have to give EIGRP a distance command just to treat those two prefixes with AD 90 as if they were internal to EIGRP 30.

The other kiss point is R3, which touches both OSPF and EIGRP 30.  (We can ignore EIGRP 103, because that was just a cheap trick to inject a remote external into EIGRP and OSPF.)  R3 will route all native EIGRP 30 prefixes through EIGRP because of the AD 90.  If we want the EIGRP 106 prefix to be optimally routed, we might want to distance that at 90 too.

I have still a way to go on this thought process, and I shall probably post-edit this posting.

Blog at