Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

Redistribution routing loop not forming when it should....

I am running the following network to test a redistribution routing loop:

                   network diagram.png

OSPF on router 1 and 2 is taking RIP routes and redistributing them into the OSPF domain.

R1#show run | s router

router ospf 1

router-id 1.1.1.1

log-adjacency-changes

redistribute rip subnets

network 172.16.13.1 0.0.0.0 area 0

router rip

version 2

network 172.50.0.0

default-metric 2

no auto-summary

R2#show run | s router

router ospf 1

router-id 2.2.2.2

log-adjacency-changes

redistribute rip subnets

network 172.16.23.1 0.0.0.0 area 0

router rip

version 2

network 172.50.0.0

default-metric 2

no auto-summary

From my understanding, both Router1 and 2 should create Type 5 LSAs with an administrative distance of 110 for all of the RIP networks.

When R1 looks at what to put in the routing table it sees that the AD to reach any given RIP network is better through R2 because this route will have an AD of 110 - as opposed to the route it learns directly from RIP which has an AD of 120.

R2 does the same thing with respect to R1.

Thus, if I ping a RIP subnet form R3, R1 and R2 should endlessly pass the between each other... voila! a loop.

BUT THAT ISN'T HAPPENING.

If I look at the LSDB I notice that only one of the two ASBRs is advertising the Type 5 LSAs for the RIP networks.

If I shutdown the OSPF interface on the router that is doing the advertising, the other takes over. When I bring the interface back up.... there is a breif period where the LSDB shows BOTH advertising the Type 5 LSAs. However this only lasts for a second and then the newly connected router's Type 5 LSAs disappear from the LSDB.  It is as if the routers are aware that this behavour will cause a loop and are opting for only one of the two to advertise Type 5 LSAs.

My output from Router 3 here shows two quick views (within 1 second of each other) of the LSDB just after the interface has been restored:


R3#show ip ospf database

            OSPF Router with ID (3.3.3.3) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         4           0x80000006 0x0016E1 2
2.2.2.2         2.2.2.2         1138        0x80000006 0x001FBC 2
3.3.3.3         3.3.3.3         1137        0x80000003 0x0078C1 8

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
10.41.0.0       1.1.1.1         5           0x80000001 0x005910 0
10.41.0.0       2.2.2.2         1168        0x80000001 0x003B2A 0
10.42.0.0       1.1.1.1         5           0x80000001 0x004D1B 0
10.42.0.0       2.2.2.2         1168        0x80000001 0x002F35 0
10.43.0.0       1.1.1.1         5           0x80000001 0x004126 0
10.43.0.0       2.2.2.2         1168        0x80000001 0x002340 0
10.44.0.0       1.1.1.1         5           0x80000001 0x003531 0  
10.44.0.0       2.2.2.2         1168        0x80000001 0x00174B 0
172.50.14.0     1.1.1.1         119         0x80000002 0x00FBB5 0
172.50.24.0     1.1.1.1         7           0x80000001 0x008F19 0
172.50.24.0     2.2.2.2         1297        0x80000001 0x007133 0

R3#show ip ospf database

            OSPF Router with ID (3.3.3.3) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         14          0x80000006 0x0016E1 2
2.2.2.2         2.2.2.2         1148        0x80000006 0x001FBC 2
3.3.3.3         3.3.3.3         1147        0x80000003 0x0078C1 8

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
10.41.0.0       2.2.2.2         1179        0x80000001 0x003B2A 0
10.42.0.0       2.2.2.2         1179        0x80000001 0x002F35 0
10.43.0.0       2.2.2.2         1179        0x80000001 0x002340 0
10.44.0.0       2.2.2.2         1179        0x80000001 0x00174B 0
172.50.14.0     1.1.1.1         128         0x80000002 0x00FBB5 0
172.50.24.0     2.2.2.2         1305        0x80000001 0x007133 0

Can anyone explain why this is happening? I'm studying for CCNP ROUTE but nothing I have read explains ths behaviour.

Thanks in advance.

Everyone's tags (4)
1 ACCEPTED SOLUTION

Accepted Solutions
Bronze

Redistribution routing loop not forming when it should....

Hi Steven,

Lets assume that both R1 and R2 have the RIP routes before you activate OSPF.   When you activate OSPF, you are correct that both routers will advertise a Type-5 LSA with the R4 Loopback routes.  This is why you briefly see both in the OSPF database on R3.  During the OPSF convergence however, R3 will eventually settle on a route through, I believe, whichever router provided updates first (since in this case all the route parameters are equal). Once that happens, it advertises those routes out to the other router, and this router will eventually replace it's RIP routes with the OSPF routes.

You can see this here on R2 (focusing on the 10.41.0.0/24 route):

*Aug  8 07:32:12.155: RIP: received v2 update from 172.50.24.2 on FastEthernet1/0

*Aug  8 07:32:12.159:      10.41.0.0/24 via 0.0.0.0 in 1 hops

*Aug  8 07:32:12.163: RT: add 10.41.0.0/24 via 172.50.24.2, rip metric [120/1]

*Aug  8 07:32:12.167: RT: NET-RED 10.41.0.0/24

...

OSPF Adjacency with R3 forms

...

*Aug  8 07:32:27.719: RT: closer admin distance for 10.41.0.0, flushing 1 routes

*Aug  8 07:32:27.719: RT: NET-RED 10.41.0.0/24

*Aug  8 07:32:27.719: OSPF-RIB-REDIST: Callback for 10.41.0.0/255.255.255.0 redistributed from process OSPF Router

*Aug  8 07:32:27.719: OSPF-RIB-REDIST: 10.41.0.0/255.255.255.0, metric 1, tag 0x0, attributes 0x1000000, will be flushed

*Aug  8 07:32:27.719: RIP:rip_lost_route for 10.41.0.0 255.255.255.0

*Aug  8 07:32:27.719: RT: add 10.41.0.0/24 via 172.16.23.2, ospf metric [110/20]

*Aug  8 07:32:27.719: RT: NET-RED 10.41.0.0/24

*Aug  8 07:32:27.719: OSPF-RIB-GLOBAL: Network update succeeded 10.41.0.0/255.255.255.0, via 172.16.23.2 on FastEthernet1/1, distance 20, flags (None), source 1.1.1.1, tag 0x0, type Ext2, return: 0

*Aug  8 07:32:27.719: OSPF-RIB-LOCAL: Sync'ed 10.41.0.0/255.255.255.0 type Ext2 - added 1 paths, deleted 0 paths, change flag 0xE, spf 82, route instance 82

*Aug  8 07:32:29.319: OSPF: rcv. v:2 t:1 l:48 rid:3.3.3.3

      aid:0.0.0.0 chk:5B70 aut:0 auk: from FastEthernet1/1

Once the RIP routes are replaced, there's nothing to redistribute, therefore R2 stops advertising Type-5 LSAs to R3.

If you catch it, you can see that R3 momentarily installs equal-cost routes through both R1 and R2:

O E2    172.50.24.0 [110/20] via 172.16.23.1, 00:00:00, FastEthernet1/1

                    [110/20] via 172.16.13.1, 00:00:00, FastEthernet1/0

O E2    172.50.14.0 [110/20] via 172.16.23.1, 00:00:00, FastEthernet1/1

                    [110/20] via 172.16.13.1, 00:00:00, FastEthernet1/0

     10.0.0.0/24 is subnetted, 4 subnets

O E2    10.42.0.0 [110/20] via 172.16.23.1, 00:00:01, FastEthernet1/1

                  [110/20] via 172.16.13.1, 00:00:01, FastEthernet1/0

O E2    10.43.0.0 [110/20] via 172.16.23.1, 00:00:01, FastEthernet1/1

                  [110/20] via 172.16.13.1, 00:00:01, FastEthernet1/0

O E2    10.41.0.0 [110/20] via 172.16.23.1, 00:00:01, FastEthernet1/1

                  [110/20] via 172.16.13.1, 00:00:01, FastEthernet1/0

O E2    10.44.0.0 [110/20] via 172.16.23.1, 00:00:01, FastEthernet1/1

                  [110/20] via 172.16.13.1, 00:00:01, FastEthernet1/0

But they quickly disappear after full convergence.

2 REPLIES
Bronze

Redistribution routing loop not forming when it should....

Hi Steven,

Lets assume that both R1 and R2 have the RIP routes before you activate OSPF.   When you activate OSPF, you are correct that both routers will advertise a Type-5 LSA with the R4 Loopback routes.  This is why you briefly see both in the OSPF database on R3.  During the OPSF convergence however, R3 will eventually settle on a route through, I believe, whichever router provided updates first (since in this case all the route parameters are equal). Once that happens, it advertises those routes out to the other router, and this router will eventually replace it's RIP routes with the OSPF routes.

You can see this here on R2 (focusing on the 10.41.0.0/24 route):

*Aug  8 07:32:12.155: RIP: received v2 update from 172.50.24.2 on FastEthernet1/0

*Aug  8 07:32:12.159:      10.41.0.0/24 via 0.0.0.0 in 1 hops

*Aug  8 07:32:12.163: RT: add 10.41.0.0/24 via 172.50.24.2, rip metric [120/1]

*Aug  8 07:32:12.167: RT: NET-RED 10.41.0.0/24

...

OSPF Adjacency with R3 forms

...

*Aug  8 07:32:27.719: RT: closer admin distance for 10.41.0.0, flushing 1 routes

*Aug  8 07:32:27.719: RT: NET-RED 10.41.0.0/24

*Aug  8 07:32:27.719: OSPF-RIB-REDIST: Callback for 10.41.0.0/255.255.255.0 redistributed from process OSPF Router

*Aug  8 07:32:27.719: OSPF-RIB-REDIST: 10.41.0.0/255.255.255.0, metric 1, tag 0x0, attributes 0x1000000, will be flushed

*Aug  8 07:32:27.719: RIP:rip_lost_route for 10.41.0.0 255.255.255.0

*Aug  8 07:32:27.719: RT: add 10.41.0.0/24 via 172.16.23.2, ospf metric [110/20]

*Aug  8 07:32:27.719: RT: NET-RED 10.41.0.0/24

*Aug  8 07:32:27.719: OSPF-RIB-GLOBAL: Network update succeeded 10.41.0.0/255.255.255.0, via 172.16.23.2 on FastEthernet1/1, distance 20, flags (None), source 1.1.1.1, tag 0x0, type Ext2, return: 0

*Aug  8 07:32:27.719: OSPF-RIB-LOCAL: Sync'ed 10.41.0.0/255.255.255.0 type Ext2 - added 1 paths, deleted 0 paths, change flag 0xE, spf 82, route instance 82

*Aug  8 07:32:29.319: OSPF: rcv. v:2 t:1 l:48 rid:3.3.3.3

      aid:0.0.0.0 chk:5B70 aut:0 auk: from FastEthernet1/1

Once the RIP routes are replaced, there's nothing to redistribute, therefore R2 stops advertising Type-5 LSAs to R3.

If you catch it, you can see that R3 momentarily installs equal-cost routes through both R1 and R2:

O E2    172.50.24.0 [110/20] via 172.16.23.1, 00:00:00, FastEthernet1/1

                    [110/20] via 172.16.13.1, 00:00:00, FastEthernet1/0

O E2    172.50.14.0 [110/20] via 172.16.23.1, 00:00:00, FastEthernet1/1

                    [110/20] via 172.16.13.1, 00:00:00, FastEthernet1/0

     10.0.0.0/24 is subnetted, 4 subnets

O E2    10.42.0.0 [110/20] via 172.16.23.1, 00:00:01, FastEthernet1/1

                  [110/20] via 172.16.13.1, 00:00:01, FastEthernet1/0

O E2    10.43.0.0 [110/20] via 172.16.23.1, 00:00:01, FastEthernet1/1

                  [110/20] via 172.16.13.1, 00:00:01, FastEthernet1/0

O E2    10.41.0.0 [110/20] via 172.16.23.1, 00:00:01, FastEthernet1/1

                  [110/20] via 172.16.13.1, 00:00:01, FastEthernet1/0

O E2    10.44.0.0 [110/20] via 172.16.23.1, 00:00:01, FastEthernet1/1

                  [110/20] via 172.16.13.1, 00:00:01, FastEthernet1/0

But they quickly disappear after full convergence.

Community Member

Redistribution routing loop not forming when it should....

Ah I see.

So basically the answers is "you cannt redistribute what is not in your routing table"

Once one of the ASBRs decides to use the lower metric external OSPF routes, it replaces its RIP learned routes with the the E2 routes. It can then no longer redistribute the RIP routes because they are not in the routing table.

This results in only one of the ASBRs creating Type 5 LSAs for the area and only one preferred path out.

Thank you very much

---

My CCNP book (Official Certification Guide)  states that redistributing from RIP into OSPF into can cause potential routing loops.

Based on what I've just done it appears that OSPFs own eligance resolves the issue. Is there something I can do to understand and emulate this routing loop issue? I really want to understand how it can arise.

448
Views
0
Helpful
2
Replies
CreatePlease to create content