4.11 - redistribution nightmare

I apologize for the length of this post, this task really got the better of me and I wanted to show my train of thought while I was doing this. 


So there has been considerable discussion on the old board and here as to the solution to this task.  To finish this task, I confess I had to look through both the Solution Guide as well as think about it for quite some time.  Hopefully that time was worth it! :)

I believe the following is how we can approach this task.

First, I started by compiling a list of the networks in use, and what protocol they "belong" to natively.  This all assumes we're using rack1.

RIP:
150.1.7.0/24
150.1.8.0/24
204.12.1.0/24
132.1.8.0/24

OSPF:
132.1.0.0/24
132.1.255.0/24
132.1.3.0/24
132.1.33.0/24
150.1.1.0/24
150.1.4.0/24


EIGRP:
132.1.26.0/24
132.1.23.0/24
54.1.2.0/24
132.1.35.0/24
132.1.45.0/24
150.1.2.0/24
150.1.3.0/24
150.1.5.0/24
150.1.6.0/24
200.0.0.0/22 *summary from R6

EIGRP (external):
132.1.6.0/24
132.1.5.0/24
192.10.1.0/24

I think that's all of them.

Looking at the task list, the first item seems pretty simple.  Redistribute RIP into OSPF, and OSPF into RIP.  Our configurations should look like this:

SW1:
router ospf 1
redistribute rip subnets

router rip
redistribute ospf 1 metric 1

That's it, we're done here for now.


Now we move on to the tough part, the mutual redistribution of OSPF->EIGRP and EIGRP->OSPF.  For the most part, this is pretty straight forward.  We send our OSPF routes into EIGRP, where they'll show up as External, so a distance of 170.  This is fine, as any router with both the OSPF and EIGRP route for these will use OSPF at 110.  Any EIGRP-only router (R5, R6) will send to their closest eigrp router (R5 to R3, R6 to R2) which will push the traffic to OSPF.  What happens in EIGRP, stays in EIGRP.  No problems here.  Our configurations on each of R2, R3, and R4 look like this:

router eigrp 10
 redistribute ospf 1 metric 1 1 1 1 1
router ospf 1
 redistribute eigrp 10 subnets

Traceroutes to/from various networks appear to work:

EIGRP->RIP
Rack1R6#trace 150.1.8.8

Type escape sequence to abort.
Tracing the route to 150.1.8.8

  1 132.1.26.2 176 msec 104 msec 16 msec
  2 132.1.0.1 260 msec 60 msec 104 msec
  3 132.1.17.7 108 msec 84 msec 124 msec
  4 204.12.1.8 176 msec *  220 msec
Rack1R6#

RIP->EIGRP Internal:
Rack1SW2#trace 150.1.5.5

Type escape sequence to abort.
Tracing the route to 150.1.5.5

  1 204.12.1.7 228 msec 108 msec 32 msec
  2 132.1.17.1 88 msec 64 msec 48 msec
  3 132.1.0.2 124 msec 100 msec 136 msec
  4 132.1.23.3 196 msec 80 msec 88 msec
  5 132.1.35.5 308 msec 716 msec *
Rack1SW2#

RIP->EIGRP External:
Rack1SW2#trace 132.1.5.5

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 204.12.1.7 80 msec 136 msec 76 msec
  2 132.1.17.1 72 msec 76 msec 64 msec
  3 132.1.0.3 104 msec 84 msec 64 msec
  4 132.1.35.5 152 msec *  276 msec
Rack1SW2#

So far, so good.  Let's take a whack at our third task, dropping R5.  Here's where the fun starts.

Rack1R5#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Rack1R5(config)#int S1/0.1
Rack1R5(config-subif)#no  frame-relay interface-dlci 513  

This causes issues:
Rack1R6#trace 132.1.5.5

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 132.1.26.2 192 msec 136 msec 48 msec
  2 132.1.0.3 124 msec 276 msec 48 msec
  3 132.1.23.2 96 msec 108 msec 52 msec
  4 132.1.0.3 184 msec 72 msec 180 msec
  5 132.1.23.2 136 msec 132 msec 100 msec
<rinserepeat>

So we need to put something in place to fix that.  The problem is, the EIGRP external routes are losing to the OSPF routes that should be used to get from R2 to R4.  R4 actually wants to send this back to the OSPF domain:

Rack1R4#sh ip route 132.1.5.5
Routing entry for 132.1.5.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 64

So we want to change the external OSPF distance to something higher than what we want to win, external EIGRP at 170.

Rack1R2|3|4(config-if)#router ospf 1
Rack1R2|3|4(config-router)#distance ospf ext 171
Rack1R2|3|4(config-router)#

But this does something bad to our RIP routes, which are also external OSPF routes.  This updates the Type-5 LSA on SW1 to point back toward the cloud, rather than toward SW2 for the RIP routes:

Rack1SW1#show ip ospf database | include 150.1.8.0|150.1.7.0|204.12
150.1.7.0       150.1.3.3       165         0x80000001 0x006EF5 0
150.1.8.0       150.1.3.3       146         0x80000001 0x0063FF 0
204.12.1.0      150.1.3.3       275         0x80000001 0x006BBD 0

R3 "wins" as the best/only LSA for those networks.

So we change the distance on RIP to be 109, so that it is preferred to OSPF.

Rack1SW1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Rack1SW1(config)#router rip
Rack1SW1(config-router)#distance 109
Rack1SW1(config-router)#^Z


Rack1SW1#sh ip ospf data | inc 150.1.8.0|150.1.7.0|204.12.1.0
150.1.7.0       150.1.7.7       1491        0x80000004 0x003425 0
150.1.8.0       150.1.7.7       1491        0x80000004 0x00292F 0
204.12.1.0      150.1.7.7       1491        0x80000004 0x0031EC 0


Rack1SW1#sh ip route 150.1.8.8
Routing entry for 150.1.8.0/24
  Known via "rip", distance 109, metric 1
  Redistributing via ospf 1, rip
  Advertised by ospf 1 subnets
  Last update from 204.12.1.8 on Vlan783, 00:00:25 ago
  Routing Descriptor Blocks:
  * 204.12.1.8, from 204.12.1.8, 00:00:25 ago, via Vlan783
      Route metric is 1, traffic share count is 1

So now we've fixed RIP while the R3-R5 link is down, so we restore it.  Checking those routes again from R6:

Rack1R6#trace 150.1.8.8

Type escape sequence to abort.
Tracing the route to 150.1.8.8

  1 132.1.26.2 96 msec 56 msec 32 msec
  2 132.1.0.3 184 msec 156 msec 148 msec
  3 132.1.23.2 60 msec 52 msec 108 msec
  4 132.1.0.3 136 msec 76 msec 184 msec
  5 132.1.23.2 92 msec 80 msec 96 msec

The routers R2 and R3 aren't impacted by any of our distance changes thusfar, so they both still see the routes for the RIP networks as EIGRP or OSPF (both external).  This means a distance of 170 or 171.  This needs to be fixed.

Rack1R2|3|4#config t
Enter configuration commands, one per line.  End with CNTL/Z.
Rack1R2|3|4(config)#ip access-list standard EXTERNAL-RIP
Rack1R2|3|4(config-std-nacl)#permit 132.1.7.0
Rack1R2|3|4(config-std-nacl)#permit 132.1.8.0
Rack1R2|3|4(config-std-nacl)#permit 150.1.7.0
Rack1R2|3|4(config-std-nacl)#permit 150.1.8.0
Rack1R2|3|4(config-std-nacl)#permit 204.12.1.0
Rack1R2|3|4(config-std-nacl)#permit 30.0.0.0 0.255.255.255
Rack1R2|3|4(config-std-nacl)#permit 31.0.0.0 0.255.255.255
Rack1R2|3|4(config-std-nacl)#router ospf 1
Rack1R2|3|4(config-router)#distance 110 0.0.0.0 255.255.255.255 EXTERNAL-RIP
Rack1R2|3|4(config-router)#

Whew.  So far, we've done a ton.  Let's test.

My tcl script is able to ping everything it should.  Let's break the R3-R5 link and test again.

R5 can't hit several addresses on R2 or R6.  Various (external EIGRP) addresses on R5 are still not reachable from other devices. 

Our problem is, routes are originating in EIGRP on R5, being injected into OSPF on R4, and then exiting OSPF to EIGRP again, and bouncing between R2 and R3.  We need to stop this looping.  To do that, we can set a tag on our routes from R5 if they come through R4, and deny it somewhere on either R2 or R3, breaking to circular redistribution.


R2 - 
router ospf 1
 redistribute eigrp 10 subnets

R3 -
router ospf 1
 redistribute eigrp 10 subnets
router eigrp 10
 redistribute ospf 1 metric 1 1 1 1 1 route-map R4R5
route-map R4R5 deny 5
 match tag 45
route-map R4R5 permit 10

R4 -
router ospf 1
redistribute eigrp 10 subnetsroute-map TAG
route-map TAG permit 10
set tag 45


Note, this tag only comes into play if the link from R3-R5 is down, and the routes to R5 are coming to the OSPF domain through R4.  Otherwise, things occur as normal.

A TCL ping to the IP addresses on each device all seem to work correctly when the link between R3 and R5 is up, and when it's down.

Anyone want to check my work and tell me what I've missed?

I think that's a little easier, and hopefully spells out how I eventually got where I ended up.

Comments

Sign In or Register to comment.