CCIE Pursuit Blog

January 1, 2008

Internetwork Expert Volume III: Lab 3 – Section 4 Part 2

4 Interior Gateway Routing

4.13 IGP Redistribution

The dreaded IGP redistribution task.  In this lab task 4.13 explicitly tells you where and how to perform redistribution.  Task 4.14 then asks you to prevent loops:

“Do not allow the RIP routes redistributed into OSPF on r4 to be passed back into RIP on r5.”
“Use route tagging to accomplish this.”

I have the following points of redistribution:

r3: RIP 120      -> OSPF 110
    OSPF 110     -> RIP 120

r4: RIP 120      -> OSPF 110

r5: RIP 120      -> EIGRP 90
    OSPF 110     -> RIP 120
    OSPF 110     -> EIGRP 90
    EIGRP 90/170 -> OSPF 110

r5 looks ugly.  I’ll do that one last.

r3 has mutual redistribution, but this should not be a problem because it’s on the same router.  There are no routes currently being redistributed on these routers so I shouldn’t break anything.  When I redistribute RIP into OSPF, this will introduce the BB2 routes into OSPF.  I am also using IE’s recommended tagging structure (router + protocol AD):

r3(config)#router os 100
r3(config-router)#redist rip sub tag 3120

I can see the BB2 routes on r1 now:

r1#sh ip ospf data external adv-router 150.1.3.3 | i Link State|Mask|Tag
                Type-5 AS External Link States
  Link State ID: 190.1.3.0 (External Network Number )
  Network Mask: /24
        External Route Tag: 3120
  Link State ID: 192.10.1.0 (External Network Number )
  Network Mask: /24
        External Route Tag: 3120
  Link State ID: 205.90.31.0 (External Network Number )
  Network Mask: /24
        External Route Tag: 3120
  Link State ID: 220.20.3.0 (External Network Number )
  Network Mask: /24
        External Route Tag: 3120
  Link State ID: 222.22.2.0 (External Network Number )
  Network Mask: /24
        External Route Tag: 3120

I can safely redistribute the OSPF routes into RIP on r3.  The only concern is the BB2 routes reflecting back into RIP with a better AD (110 versus 120).  But the router will not install these routes.  [Basically because the RIP route would be replaced by OSPF route which would mean that the RIP route would not have been redistributed in the first place – “The Single Router Redistribution Paradox”  🙂 ]

Before redistribution:
r3#sh ip route | i 220.20.3.0
R    220.20.3.0/24 [120/7] via 192.10.1.254, 00:00:14, FastEthernet0/0 <-bb2 route

r3(config)#route-map OSPF->RIP_SET_TAG permit 10
r3(config-route-map)#set tag 3110
r3(config-router)#redist ospf 100 route-map OSPF->RIP_SET_TAG metric 2

After redistribution, the route is unchanged (as I expected):
r3#sh ip route | i 220.20.3.0
R    220.20.3.0/24 [120/7] via 192.10.1.254, 00:00:14, FastEthernet0/0

On to r4.  We have to redistribute RIP (120) into OSPF (110).  This should not be an issue as it is one-way redistribution (it may become an issue later when we redistribute OSPF into RIP on r5).  This will put the bb3 routes into OSPF.  BUT we do have a possible issue because we are currently redistributing Loop0 into OSPF via connected with a route-map:

route-map LOOP0->OSPF permit 10
 match interface Loopback0
!
router ospf 100
 router-id 150.1.4.4
 log-adjacency-changes
 redistribute connected subnets tag 41 route-map LOOP0->OSPF
 network 190.1.34.4 0.0.0.0 area 34

So we know that redistribution uses a two step algorithm:

1) Take all of the RIP routes in the routing table and advertise them in OSPF.
2) Take all connected interfaces running RIP and advertise them into OSPF (implicit route-map)

In this case we will break the second step with our LOOP0->OSPF map.  We need to include the interfaces running RIP in that route-map.

  Default version control: send version 2, receive version 2
    Interface                    Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       2     2
    FastEthernet0/1       2     2
    Serial0/1                      2     2

So I need to add interfaces fa0/0, fa0/1, and s0/1 to my route-map.

The IE answer key is a little puzzling at first glance.  They show the following for r4:

router ospf 1
 redistribute rip subnets
!
route-map CONNECTED->OSPF permit 20
!
router rip
 redistribute ospf 1 metric 1  <-WTF???

The route-map CONNECTED->OSPF is what they used for task 4.7 (to get Lo0 into OSPF) so basically they are now adding a “permit all” line at the end of that route-map, so that we are redistributing ALL connected interfaces into OSPF.  Here is what they are effectively doing:

route-map CONNECTED->OSPF permit 10
 match interface loopback0
route-map CONNECTED->OSPF permit 20
!
router ospf 1
 redistribute rip subnets
 redistribute connected subnets route-map CONNECTED->OSPF

That makes sense.  I don’t know why they are redistributing the OSPF routes into RIP though?  The task requires one-way redistribution only.  Here’s my solution (I removed the old route-map and “redistribute connected” configurations):

route-map CONNECTED->OSPF permit 10
 description TASK 4.8 Lo0 into OSPF
 match interface Loopback0
 set tag 41
route-map CONNECTED->OSPF permit 20
 description TASK 4.13 RIP->OSPF redist connected
 match interface FastEthernet0/0 FastEthernet0/1 Serial0/1
 set tag 4120
!
router ospf 100
 router-id 150.1.4.4
 log-adjacency-changes
 redistribute connected subnets route-map CONNECTED->OSPF
 redistribute rip subnets tag 4120
 network 190.1.34.4 0.0.0.0 area 34

Here are the redistributed RIP routes on r1:

r1#sh ip os data | i Tag|4120
Link ID         ADV Router      Age         Seq#       Checksum Tag
10.4.4.0        150.1.4.4       653         0x80000001 0x004482 4120
10.5.5.5        150.1.4.4       653         0x80000001 0x00FAC4 4120
30.0.0.0        150.1.4.4       112         0x80000001 0x009B1F 4120
30.1.0.0        150.1.4.4       112         0x80000001 0x008F2A 4120
30.2.0.0        150.1.4.4       112         0x80000001 0x008335 4120
30.3.0.0        150.1.4.4       112         0x80000001 0x007740 4120
31.0.0.0        150.1.4.4       112         0x80000001 0x008E2B 4120
31.1.0.0        150.1.4.4       112         0x80000001 0x008236 4120
31.2.0.0        150.1.4.4       112         0x80000001 0x007641 4120
31.3.0.0        150.1.4.4       112         0x80000001 0x006A4C 4120
190.1.4.0       150.1.4.4       653         0x80000001 0x003BD9 4120
204.12.1.0      150.1.4.4       653         0x80000002 0x001FDE 4120

This accomplishes the same thing, but with the benefit of unique tags on the routes.

Okay…no more putting it off…on to r5:

r5: RIP 120      -> EIGRP 90
    OSPF 110     -> RIP 120
    OSPF 110     -> EIGRP 90
    EIGRP 90/170 -> OSPF 110

So…mutual redistribution between OSPF and EIGRP as well as one-way redistribution between OSPF and RIP as well as RIP and EIGRP.  Did I already say “yuck”? 🙂

“lower to higher = good”  so OSPF into RIP should be fine.  Let’s start with that one.

Current RIP configuration:
router rip
 version 2
 no validate-update-source
 passive-interface default
 no passive-interface Serial0/1
 network 10.0.0.0
 network 150.1.0.0
 no auto-summary

Before we do this, we need to look at what’s happening with the BB3 routes.  They are being advertised from BB3 to r4 via RIP.  R4 then advertises them to r5 via RIP.

We have redistributed the RIP routes into OSPF on r4 so now they routes flow from BB3 to r4 via RIP.  They then get redistributed into OSPF.  r5 sees the routes from r4 via RIP and from r3 via OSPF.  Since OSPF has the lower AD, the OSPF routes are installed:

Before redistribution on r4:

r5#sh ip route 30.0.0.0
Routing entry for 30.0.0.0/16, 4 known subnets
  Redistributing via rip, ospf 100

R       30.2.0.0 [120/15] via 10.4.4.4, 00:00:00
R       30.3.0.0 [120/15] via 10.4.4.4, 00:00:00
R       30.0.0.0 [120/15] via 10.4.4.4, 00:00:00
R       30.1.0.0 [120/15] via 10.4.4.4, 00:00:00

After redistributing RIP->OSPF on r4:

r5#sh ip route 30.0.0.0
Routing entry for 30.0.0.0/16, 4 known subnets
  Redistributing via rip, ospf 100

O E2    30.2.0.0 [110/20] via 190.1.135.3, 00:00:33, Serial0/0.1
O E2    30.3.0.0 [110/20] via 190.1.135.3, 00:00:33, Serial0/0.1
O E2    30.0.0.0 [110/20] via 190.1.135.3, 00:00:33, Serial0/0.1
O E2    30.1.0.0 [110/20] via 190.1.135.3, 00:00:33, Serial0/0.1

So if we redistribute OSPF into RIP on r5 are we introducing a routing loop for the bb3 routes?  I don’t think so.  We’re really not doing much at all.  r4 and r5 both know all of the OSPF routes because they are running OSPF already.  Even the RIP routes learned from bb2 via r3 are already known by r5 and r3 via OSPF (RIP was redistributed into OSPF on r3 already).  I can’t see any problems with this redistribution.

route-map OSPF->RIP permit 10
 description Tag OSPF routes with 5110
 set tag 5110
!
router rip
 version 2
 no validate-update-source
 redistribute ospf 100 metric 2 route-map OSPF->RIP
 passive-interface default
 no passive-interface Serial0/1
 network 10.0.0.0
 network 150.1.0.0
 no auto-summary

Alright.  Let’s do the other one-way redistribution on r5: RIP 120 into EIGRP 90.

At first this looks like an issue because we’re going from a higher AD protocol (RIP 120) to a lower AD protocol (EIGRP 90), but we need to remember that EIGRP will give external routes an AD of 170 so we don’t need to worry about these routes coming back into RIP.

One other thing…there are no RIP routes in the r5 routing table  🙂

r5#sh ip route rip

r5#

So the only thing that we will be redistributing into EIGRP are the interfaces running RIP (only int s0/1):

Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    Serial0/1             2     2

route-map RIP->EIGRP permit 10
 description Tag RIP routes with 5120
 set tag 5120
!
router eigrp 10
 redistribute rip metric 1 1 1 1 1 route-map RIP->EIGRP

Before redistribution:

r2#sh ip route ei | sec D EX
r2#

After redistribution:

r2#sh ip route ei | sec D EX
D EX    10.5.5.0/24
           [170/2560002816] via 190.1.0.5, 00:04:24, GigabitEthernet0/0
D EX    10.4.4.4/32
           [170/2560002816] via 190.1.0.5, 00:04:24, GigabitEthernet0/0
     150.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
D EX    150.1.5.0/24
           [170/2560002816] via 190.1.0.5, 00:04:24, GigabitEthernet0/0

We can’t ping 10.4.4.4 though:

r2#p 10.4.4.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.4.4.4, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

That’s because there is no path back on r4:

r4#sh ip route 190.1.0.2
% Subnet not in table

Finally…the mutual redistribution on r5:

    OSPF 110     -> EIGRP 90
    EIGRP 90/170 -> OSPF 110

We should be covered here too because the OSPF routes redistributed into EIGRP will appear as D EX routes with an AD of 170.

I would filter any D EX routes from being redistributed back into OSPF

Before mutual redistribution:

r1#sh ip route | i E2
       E1 – OSPF external type 1, E2 – OSPF external type 2
O E2 222.22.2.0/24 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2 204.12.1.0/24 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2 220.20.3.0/24 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    190.1.4.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    190.1.3.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    10.4.4.0/24 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    10.5.5.5/32 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2 192.10.1.0/24 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    31.3.0.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    31.2.0.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    31.1.0.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    31.0.0.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    150.1.5.0 [110/20] via 190.1.135.5, 00:56:24, Serial0/0.1
O E2    150.1.4.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2 205.90.31.0/24 [110/20] via 190.1.135.3, 00:56:25, Serial0/0.1
O E2    30.2.0.0 [110/20] via 190.1.135.3, 00:56:25, Serial0/0.1
O E2    30.3.0.0 [110/20] via 190.1.135.3, 00:56:25, Serial0/0.1
O E2    30.0.0.0 [110/20] via 190.1.135.3, 00:56:25, Serial0/0.1
O E2    30.1.0.0 [110/20] via 190.1.135.3, 00:56:25, Serial0/0.1

r2#sh ip route | sec D EX
D EX    10.5.5.0/24
           [170/2560002816] via 190.1.0.5, 00:18:48, GigabitEthernet0/0
D EX    10.4.4.4/32
           [170/2560002816] via 190.1.0.5, 00:18:48, GigabitEthernet0/0
     150.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
D EX    150.1.5.0/24
           [170/2560002816] via 190.1.0.5, 00:18:48, GigabitEthernet0/0

We don’t have any D EX routes on r5:

r5#sh ip route ei | i D EX
r5#

We’re not redistributing connected under either protocol, so we should be good to go:

router eigrp 10
 redistribute rip metric 1 1 1 1 1 route-map RIP->EIGRP
 network 190.1.0.5 0.0.0.0
 network 190.1.5.5 0.0.0.0
 no auto-summary
 eigrp router-id 150.1.5.5
!
router ospf 100
 router-id 150.1.5.5
 log-adjacency-changes
 redistribute rip subnets tag 5120 route-map LOOP0->RIP-OSPF
 network 190.1.135.5 0.0.0.0 area 135
 neighbor 190.1.135.3
 neighbor 190.1.135.1

r1#sh ip os data | i Tag|590|5170
Link ID         ADV Router      Age         Seq#       Checksum Tag
54.1.1.0        150.1.5.5       42          0x80000001 0x001F57 590
150.1.2.0       150.1.5.5       42          0x80000001 0x002AEB 590
150.1.6.0       150.1.5.5       42          0x80000001 0x00FD14 590
150.1.8.0       150.1.5.5       42          0x80000001 0x00E728 590
190.1.0.0       150.1.5.5       42          0x80000001 0x003BB3 590
190.1.5.0       150.1.5.5       42          0x80000001 0x0004E5 590
200.0.0.0       150.1.5.5       42          0x80000001 0x00C421 590
200.0.1.0       150.1.5.5       42          0x80000001 0x00B92B 590
200.0.2.0       150.1.5.5       42          0x80000001 0x00AE35 590
200.0.3.0       150.1.5.5       42          0x80000001 0x00A33F 590

Sweet.  I’m seeing EIGRP routes, but no D EX routes redistributed into OSPF.

Now the final step.  OSPF into EIGRP.  We should be fine because the OSPF routes will become D EX routes and not reflect back into OSPF.

So now we have a ton of D EX routes on r2:

r2#sh ip route | i D EX
D EX 222.22.2.0/24
D EX 204.12.1.0/24
D EX 220.20.3.0/24
D EX    190.1.135.0
D EX    190.1.34.0
D EX    190.1.17.0
D EX    190.1.4.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    190.1.3.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    10.5.5.0/24
D EX    10.4.4.0/24
D EX    10.4.4.4/32
D EX 192.10.1.0/24
D EX    31.3.0.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    31.2.0.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    31.1.0.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    31.0.0.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    150.1.7.0/24
D EX    150.1.5.0/24
D EX    150.1.4.0/24
D EX    150.1.3.0/24
D EX    150.1.1.0/24
D EX 205.90.31.0/24
D EX    30.2.0.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    30.3.0.0 [170/2560002816] via 190.1.0.5, 00:00:20, GigabitEthernet0/0
D EX    30.0.0.0 [170/2560002816] via 190.1.0.5, 00:00:20, GigabitEthernet0/0
D EX    30.1.0.0 [170/2560002816] via 190.1.0.5, 00:00:20, GigabitEthernet0/0

But still none on R5:

r5#sh ip route | i D EX
r5#

We can ping 10.4.4.4 from the EIGRP domain now:

r2#p 10.4.4.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms 

We can make one more sanity check.  Let’s create a new loopback on r2 and redistribute it into EIGRP.  This will create an external route that should show up in the OSPF domain.  We can then verify that our 5170 tags are working.

r2(config)#int lo1
r2(config-if)#ip add 2.2.2.2 255.255.255.0
r2(config-if)#route-map LOOP1->EIGRP perm 10
r2(config-route-map)#match int lo1
r2(config-route-map)#router eig 10
r2(config-router)#redist conn route-map LOOP1->EIGRP met 1 1 1 1 1

It shows up on r5:

r5#sh ip route | i D EX
D EX    2.2.2.0 [170/2560002816] via 190.1.0.2, 00:00:15, FastEthernet0/0

It should now appear on r1 as an E2 OSPF route with a tag of 5170:

r1#sh ip route 2.2.2.0
Routing entry for 2.2.2.0/24
  Known via “ospf 100”, distance 110, metric 20
  Tag 5170, type extern 2, forward metric 65
  Last update from 190.1.135.5 on Serial0/0.1, 00:01:46 ago
  Routing Descriptor Blocks:
  * 190.1.135.5, from 150.1.5.5, 00:01:46 ago, via Serial0/0.1
      Route metric is 20, traffic share count is 1
      Route tag 5170

Sweet!!!  My tagging system works.  Let’s remove that configuration and then work on task 4.14

4.14 Redistribution Loop Prevention

“Do not allow the RIP routes redistributed into OSPF on r4 to be passed back into RIP on r5.”
“Use route tagging to accomplish this.”

The RIP routes redistributed into OSPF on r4 should be tagged with 4120 (and lo0 will be tagged 41).  Let’s see if they show up on r5:

r5#sh ip os data | i Tag|41
Link ID         ADV Router      Age         Seq#       Checksum Tag
10.4.4.0        150.1.4.4       971         0x80000005 0x003C86 4120
10.5.5.5        150.1.4.4       971         0x80000005 0x00F2C8 4120
30.0.0.0        150.1.4.4       692         0x80000001 0x009B1F 4120
30.1.0.0        150.1.4.4       691         0x80000001 0x008F2A 4120
30.2.0.0        150.1.4.4       691         0x80000001 0x008335 4120
30.3.0.0        150.1.4.4       691         0x80000001 0x007740 4120
31.0.0.0        150.1.4.4       691         0x80000001 0x008E2B 4120
31.1.0.0        150.1.4.4       691         0x80000001 0x008236 4120
31.2.0.0        150.1.4.4       691         0x80000001 0x007641 4120
31.3.0.0        150.1.4.4       691         0x80000001 0x006A4C 4120
150.1.4.0       150.1.4.4       971         0x80000005 0x005FD8 41
190.1.4.0       150.1.4.4       971         0x80000005 0x0033DD 4120
204.12.1.0      150.1.4.4       971         0x80000006 0x0017E2 4120

Here’s my OSPF->RIP redistribution on r5:

router rip
 redistribute ospf 100 metric 2 route-map OSPF->RIP
!
route-map OSPF->RIP permit 10
 description Tag OSPF routes with 5110
 set tag 5110

So basically, we just need to create a deny statement for routes tagged 4120 or 41:

route-map OSPF->RIP deny 10
 description Filter OSPF routes tagged 4120 or 41
 match tag 4120 41
route-map OSPF->RIP permit 20
 description Tag OSPF routes with 5110
 set tag 5110

Whew!!!  These two tasks took me awhile, but I feel like I had a very good understanding of what was going on.  I’m still painfully slow, but I the basics of route redistribution are finally baking into my brain.  🙂

Advertisements

1 Comment »

  1. Hey just wanted to say this is a great Blog. This brings back all the good memories of studying for the lab exam. Nice work.
    -Brad

    Comment by Brad — January 2, 2008 @ 2:33 pm | Reply


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

Create a free website or blog at WordPress.com.

%d bloggers like this: