I used to have few problems with redistribution so more practice was due. As I practiced, I have also developed a logical approach to which I thought it could benefit others. Do keep in mind however that my approach might not be the best and might not work in all cases but it has worked for me so far.

What I will do next is, lab a new redistribution scenario and will document it as I go along. So this may end-up quite a long blog – I’d say, get a coffee and sit tight! ūüôā

Maybe, it’s not a bad idea to print the diagrams and have them aside while you follow the text.

Before I start, below is a list of rules you must follow to become a successful redistributor ūüôā

  1. Classfull protocols caveats when sending & receiving updates – the same ideas applies to redistribution as well. Particularly, you should pay attention to whenever masks are different – see this excellent article for more details
  2. You must know the Administrative Distances РEIGRP Summary: 5, EIGRP Redistributed/External: 170, EIGRP Internal: 90; OSPF: 110; RIP: 120;  IS-IS: 115; IGRP: 100; EIGRP: 90; Static: 1; Directly Connected: 0
  3. A route is redistributed from protocol A into protocol B *only if* the route exists in the routing table source from protocol A
  4. Routing Loops – it is very likely you’d create loops when redistributing; they normally occur when you redistribute from one protocol, into another and then back into the same protocol from which the route originally originated. You would normally avoid this by using filters, route tags, tweaking administrative distance and metrics.
  5. Following up point 3 above, do keep in mind that should you choose to filter routes, you may loose network redundancy
What I, sometimes, find  difficult with redistribution is that you must also think in advance. For example, if you are redistributing protocol A into protocol B, but you have protocol C & D also running in your network, one must plan the configuration accounting for impact of the other routing protocols Рthis, in some topologies, is quite difficult.

The topology I will be working on is the one posted by Daniel on his blog:

Go to Daniel’s Website Topology & Configuration

 

Redistribution

1st STEP :: OVERVIEW

I notice here 3 routing domains – RIPv2, EIGRP 1 & OSPF 1 – I will therefore consider them as 3 routers where each BR (Border router) will be represented by a link. This new, high-level diagram will help identifying where the potential routing loops might occur. Furthermore, by treating each domain as a router, I think the redistribution process becomes more logical and intuitive.

In my new high-level diagram I will then have some routers connected twice between each-other – I will consider these links as backup and primary (thicker lines) respectively. I will also redistribute routes between the different routers so that the least number of hops is always preferred. I also decide to leave RIP as the last protocol into which I will setup redistribution.

At last, in most cases, I will have to account for the fact that imported external¬†routes could be returning, local routes via a different path from the one initially advertised out … For example, I could get a route advertised *out* from OSPF into RIP, following into EIGRP and back into OSPF, via R2 or R3. In such cases I will be filtering these routes out using different techniques explained here – Link-1 & Link-2.

redistrib7

2nd STEP :: Mutual EIGRP and OSPF Redistribution (routers R2 & R3)

  • redistribute internal OSPF/EIGRP routes & set domain route-tag respectively
  • redistribute¬†¬†external OSPF/EIGRP routes (here I will assign higher metric)
  • do not redistribute routes with tag matching destination domain’s tag (do not send routes into originating domain)
  • always prefer the shortest path via hop-count; each hop is a routing domain (optimising¬†routing via metric manipulation)

3rd STEP :: Mutual OSPF and RIP Redistribution (routers R7 & R8)

  • redistribute internal RIP/OSPF routes & set domain route-tag¬†respectively
  • redistribute¬†¬†external OSPF routes¬†and “external”¬†RIP routes (match routes with tag: 200, the only tag different from its own 300) and assign higher metric
  • do not redistribute routes with tag matching destination domain’s tag (do not send routes into originating domain)
  • always prefer the shortest path via hop-count; each hop is a routing domain (optimising¬†routing via metric manipulation)

4th STEP :: Mutual EIGRP and RIP Redistribution (router R5)

  • redistribute internal RIP/EIGRP routes & set domain route-tag¬†respectively
  • redistribute¬†¬†external EIGRP routes¬†and¬†“external”¬†RIP routes (match routes with tag: 100, the only tag different from its own 300) and assign higher metric
  • do not redistribute routes with tag matching destination domain’s tag (do not send routes into originating domain)
  • always prefer the shortest path via hop-count; each hop is a routing domain (optimizing¬†routing via metric manipulation)
The tricky part here is making sure routes are not advertised back … so we will use here a similar technique used by BGP – which uses the AS for loop avoidance.

In this case, I will use route-tags. As I redistribute routes out, I will also mark the *locally originated routes only* with a specific tag value associated to each routing domain – I will use 100, 200 and 300 for OSPF, EIGRP and RIPv2 domains respectively. Once the tag is set, it stays constant even when crossing different routing domain.

Next, I will need to make sure *not* to redistribute routes with the tag matching the destination domain’s tag.

For example, when redistributing into RIP, I will ensure that routes with tag set to 300 do not get redistributed. This is possible because EIGRP, OSPF & RIPv2 support tags Рunlike RIVv1 & IGRP.

Should you not be able to carry tags between the routing protocols involved, ACLs and prefix lists could also be used by specifically matching routes to be filtered.

5th STEP :: The Moment of truth

Ok … so let’s do some testing … Here is the thing: this page has gone far longer than what I was expecting. So I will only show you few ping results. I can also reassure you that full redistribution was successful, including keeping redundancy! You will see below that at some stage, recovery took quite some time … but this is only because RIP is slow, despite having tweaked the timers.

I :: All Links UP

screenshot43

II :: R1-Fa0/1 shut-down

screenshot44

III :: R1-Fa0/0 shut-down

screenshot45

At last, below you can find the configuration changes I’ve made on one of the routers … you could try work-out the rest ūüėČ

screenshot46

 


Thank you,
Signature
View Rafael A Couto Cabral's profile on LinkedIn



Leave a reply

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>