Kevin Dorrell, CCIE #20765

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

Advertisements

3 Comments »

  1. Kevin, thank you for this excellent blog. I am running similiar Redistribution scenario but can not figure out how to TAG only internal routes. For example, you mention how RIP/OSPF/EIGRP internal routes get tagged with a specific value. Could you post or email me the code of what that looks like? I can not figure out how to only tag the internal routes. I end up tagging internal and external routes.

    !**** EIGRP->OSPF

    route-map EIGRP->OSPF deny 10
    match tag 300

    route-map EIGRP->OSPF permit 20
    set tag 110

    !*** RIP->OSPF

    route-map RIP->OSPF deny 10
    match tag 120

    route-map RIP->OSPF permit 20
    set tag 110

    Thank you!

    Comment by Rick — 05 Feb 2009 @ 05:00

  2. Hi Rick, sorry it took so long to get back to your question. The way to distinguish between internal and external routes is by using the “match route-type” command, http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_pi1.html#wp1014646

    For external routes, you may have to use this in conjunction with “match tag”, where the tag has been set when you imported the route into the protocol. In fact, with RIP this in the only way you can do it, because RIP itself cannot distinguish between internal and external routes.

    Here is a short example:

    route-map OSPF–>EIGRP permit 10
    match route-type internal
    set metric 128 50 255 1 1500
    set tag 110
    !
    route-map OSPF–>EIGRP permit 20
    match tag 34
    set metric 128 50 255 1 1500
    !
    route-map EIGRP–>OSPF permit 10
    match route-type internal
    set metric 20
    set tag 12

    Good luck!

    Comment by dorreke — 09 Feb 2009 @ 03:53

  3. Thanks for the reply, this information is very helpful. I did find a way to filter out RIP natives into OSPF. Since RIP doesn’t support tags I did something like this:

    route-map RIP->OSPF deny 10
    match metric 1 (RIP Natives can only have a metric of 1 !!!)
    set metric 5
    set metric-type type-1
    set tag 120

    Comment by Rick — 11 Feb 2009 @ 17:09


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: