Using a strategic Approach to Redistribution: An example
Here is a scenario I cooked up for redistribution. I’ve tried to make it as complex as possible but addressing is kept simple.
We have EIGRP between R1 and R2 over network 150.1.10/24
We have RIP running on Ethernet between R2 and R3, on serial link (150.1.3.0/24) between R3 and R4 and Ethernet Network between R4 and R5.
OSPF is running on two frame relay networks between R3, R4 and R6, Serial link between R6 and R7 and frame relay link between R 7 and R9.
Also we have RIP on R8’s two networks to R6 and R7
And EIGRP between R9 and R10 Ethernet network and R9 and R7’s frame relay link.
We have to redistribute between EIGRP and RIP at R2, RIP and OSPF at R3, R6, R7, EIGRP and OSPF at R9
According to the strategic approach
1) We first identify our core domain.
Its easy. OSPF sits in the middle, and connects to most other domains.
2) Now we start redistribution
At R2
The methodology is to first do the redistribution if necessary between non core domains.
Hmmm R2 is a single rendezvous point between RIP and EIGRP. SO no problems we can safely have mutual redistribution.
After this step we should have reachability between R1 and R5.
Well all other points involve core domains. Let’s start with single point of redistribution among domains.
At R3:
At R3 we redistribute between OSPF and RIP.
There should be no problem right because a single point of redistribution right?
Well LOOK again.
As a rule we should prefer the native routes. R3 has a RIP route to 150.1.1.0/24 network, which was redistributed in RIP. Now this route is redistributed in OSPF and will reach R4 via OSPF and get installed there.
Immediately we’ll have a loop.
The exact same scenario for networks 150.1.4.0/24 and beyond will occur. R3 had that as RIP route from R4 and redistributed them in OSPF, and they will get fed back at R4 at OSPF routes.
So again we should remember that
“If two routing domains have more that one rendezvous points, even if redistribution is done at a single point make sure that both domains prefer their native routes.”
So with a little foresight, all we need to do is to tag routes going to OSPF on R3 and filter them in OSPF process on R4. ( Distribute-list route-map)
We can also match the routes and lower the admin distance to 109 on R4, but simple tagging seems easier to understand here. Also we can just lower the admin distance of all RIP routes on R4, but as personal rule, I stay away from that. If I know what route is going to cause problem, that’s the route I’ll play with.
At the end of this step R1 and R5 should have reach ability to all OSPF routes.
Lets go to R9 now because a single point of redistribution.
At R9:
Hmmm similar scenario but EIGRP and OSPF here.
Unlike last time we wont have a problem unless EIGRP has an external route.
In that case, we have to filter that in OSPF so that at R7, we prefer or native routes of EIGRP.
Remember HIGHER to LOWER we need to take care, if domains have more than one meeting points.
At the end of this step, we’ll have reachability between R10->R5->R1 and vice versa.
Now we go to double point of redistribution.
At R6 and R7:
Lets say R6 loop back is running RIP as well.
If we understand the problem we faced at R3 we should have no problem here.
On both routers we tag routes during the redistribution and deny those routes getting back into. starting with R6, a simple redistribution would mean that apart from connected routes, now R7 would prefer the route to R6 loopback through R6. We don’t want that, as we always prefer native routes. We can just match the route, make its admin distance less than ospf on both R6 and R7 and we'll be ok.
One thing haven’t added here, is that if we redistribute any network/connected route prior to the redistribution question, we should always remember that we are breaking “Inherent redistribute connected of redistribution process.”
We should always modify our route maps to make the process complete.
For example, if at R2 we redistributed a loop back network into rip, the connected interface running EIGRP will not be redistributed here. We should modify the route map we used to redistribute the loop back and add serial interface in that.
P.S
This is a document for self reference.
But if anyone reads it and maybe have a redistribution problem, I’ll be glad rather thankful to look at that and use this approach to see how things work.
I used the same approach on IEWB labs 5 – 15 (no I haven’t completed those), just by looking at the diagram and question and then looking at the solution. Each time, I found that though my methods may be different, solution essentially takes the same loop prevention measures.
We have EIGRP between R1 and R2 over network 150.1.10/24
We have RIP running on Ethernet between R2 and R3, on serial link (150.1.3.0/24) between R3 and R4 and Ethernet Network between R4 and R5.
OSPF is running on two frame relay networks between R3, R4 and R6, Serial link between R6 and R7 and frame relay link between R 7 and R9.
Also we have RIP on R8’s two networks to R6 and R7
And EIGRP between R9 and R10 Ethernet network and R9 and R7’s frame relay link.
We have to redistribute between EIGRP and RIP at R2, RIP and OSPF at R3, R6, R7, EIGRP and OSPF at R9
According to the strategic approach
1) We first identify our core domain.
Its easy. OSPF sits in the middle, and connects to most other domains.
2) Now we start redistribution
At R2
The methodology is to first do the redistribution if necessary between non core domains.
Hmmm R2 is a single rendezvous point between RIP and EIGRP. SO no problems we can safely have mutual redistribution.
After this step we should have reachability between R1 and R5.
Well all other points involve core domains. Let’s start with single point of redistribution among domains.
At R3:
At R3 we redistribute between OSPF and RIP.
There should be no problem right because a single point of redistribution right?
Well LOOK again.
As a rule we should prefer the native routes. R3 has a RIP route to 150.1.1.0/24 network, which was redistributed in RIP. Now this route is redistributed in OSPF and will reach R4 via OSPF and get installed there.
Immediately we’ll have a loop.
The exact same scenario for networks 150.1.4.0/24 and beyond will occur. R3 had that as RIP route from R4 and redistributed them in OSPF, and they will get fed back at R4 at OSPF routes.
So again we should remember that
“If two routing domains have more that one rendezvous points, even if redistribution is done at a single point make sure that both domains prefer their native routes.”
So with a little foresight, all we need to do is to tag routes going to OSPF on R3 and filter them in OSPF process on R4. ( Distribute-list route-map)
We can also match the routes and lower the admin distance to 109 on R4, but simple tagging seems easier to understand here. Also we can just lower the admin distance of all RIP routes on R4, but as personal rule, I stay away from that. If I know what route is going to cause problem, that’s the route I’ll play with.
At the end of this step R1 and R5 should have reach ability to all OSPF routes.
Lets go to R9 now because a single point of redistribution.
At R9:
Unlike last time we wont have a problem unless EIGRP has an external route.
In that case, we have to filter that in OSPF so that at R7, we prefer or native routes of EIGRP.
Remember HIGHER to LOWER we need to take care, if domains have more than one meeting points.
At the end of this step, we’ll have reachability between R10->R5->R1 and vice versa.
Now we go to double point of redistribution.
At R6 and R7:
Lets say R6 loop back is running RIP as well.
If we understand the problem we faced at R3 we should have no problem here.
On both routers we tag routes during the redistribution and deny those routes getting back into. starting with R6, a simple redistribution would mean that apart from connected routes, now R7 would prefer the route to R6 loopback through R6. We don’t want that, as we always prefer native routes. We can just match the route, make its admin distance less than ospf on both R6 and R7 and we'll be ok.
We wont even need tagging and denying here even.
As Both routers will prefer their native OSPF paths by design, and the RIP native paths because we changed the AD.
When Rip routes are fed into OSPF for example at R6, at R7 it wont be fed back because the route wont be in routing table as an OSPF route but rather as a RIP route.
Btw, being paranoid, I always tag and deny at dual point of redistribution anyway :)
One thing haven’t added here, is that if we redistribute any network/connected route prior to the redistribution question, we should always remember that we are breaking “Inherent redistribute connected of redistribution process.”
We should always modify our route maps to make the process complete.
For example, if at R2 we redistributed a loop back network into rip, the connected interface running EIGRP will not be redistributed here. We should modify the route map we used to redistribute the loop back and add serial interface in that.
P.S
This is a document for self reference.
But if anyone reads it and maybe have a redistribution problem, I’ll be glad rather thankful to look at that and use this approach to see how things work.
I used the same approach on IEWB labs 5 – 15 (no I haven’t completed those), just by looking at the diagram and question and then looking at the solution. Each time, I found that though my methods may be different, solution essentially takes the same loop prevention measures.
This is when I haven’t even configured the network. :P
And apart from IEWB lab 2 scenario, (which involves a backup link), I think the approach will always work. I need to lab that scenario again, but the backup links just adds a whole new level of complexity because in that case, we have to be aware of a route that isn't there :D
Just by looking at the diagram and question and having a little foresight we can already predict and avoid potential problems before they occur.
Just by looking at the diagram and question and having a little foresight we can already predict and avoid potential problems before they occur.