RE: Redistribute ospf external route into igrp

From: ying chang (ying_c@xxxxxxxxxxx)
Date: Thu May 09 2002 - 01:32:51 GMT-3


   
After went through a few tests, I don't think the issue is not on
split-horizon but on whose route is more trustworthy:

Since mutual redistribution is always causing confusion, and this problem
can be simulated without mutual redistribution, so I set up an environment
like the following:

        R4<--igrp---R3<---rip---R5--172.16.155.0/24
                     |
                   ospf
                     |
                    R1<--rip----R2--172.16.125.0/24

and below is what I got:

Two external routes in R3:

r3#sio d | b -5 <<<- both 125.0/24 and 155.0/24 are in ospf external db
                Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
172.16.125.0 172.16.200.1 48 0x80000001 0xC013 12
172.16.155.0 172.16.146.1 610 0x80000002 0x8E45 35

Only 172.16.155.0 is redistributed into igrp:

r3#debug ip igrp tra <<<--sending 125.0/24 but not 155.0/24
IGRP protocol debugging is on
r3#
13:28:22: IGRP: sending update to 255.255.255.255 via Ethernet0
(172.16.52.3)
13:28:22: subnet 172.16.144.0, metric=501
13:28:22: subnet 172.16.145.0, metric=501
13:28:22: subnet 172.16.146.0, metric=501
13:28:22: subnet 172.16.53.0, metric=1100
13:28:22: subnet 172.16.10.0, metric=8476
13:28:22: subnet 172.16.125.0, metric=158250 <<<<----
r3#
r3#sh ip rip data <<<- r3 has 155.0/24 but not 125.0/24
172.16.0.0/16 auto-summary
172.16.145.0/24 directly connected, Loopback1
...
172.16.149.0/24
    [1] via 172.16.10.1, 00:00:08, Serial0
172.16.155.0/24 <<<<------
    [1] via 172.16.53.1, 00:00:09, Ethernet1
...
r3#

I think the reason 172.16.155.0/24 was not sending to IGRP is because from
R3's point of view, 172.16.155.0/24 is in its rip database (know it by first
hand), it also knows 172.16.155.0/24 is in ospf - but that's learn from some
other protocol (second hand stuff), so the route is not cannot be trusted,
and that's why when you redistribute ospf into igrp, you only see R1's rip
routes but not R4's rip routes. 172.16.125.0/24 did not have this problem,
because it's not in R3's local rip database.

The moral for this problem: when you run more than two protocols in a router
like this, not only you have to redistribute ospf into igrp, you also need
to redistribute directly connected rip routes into igrp.

Chang

>From: "Jenkins, Buddy" <buddy.jenkins@csfb.com>
>Reply-To: "Jenkins, Buddy" <buddy.jenkins@csfb.com>
>To: ccielab@groupstudy.com
>Subject: RE: Redistribute ospf external route into igrp
>Date: Thu, 9 May 2002 07:25:00 +0900
>
>Jeff,
>
>Refer to Doyle Volume1 Chapter 11 on redistribution. In the questions at
>the end of the chapter there is a question (I don't have the book with me
>right now so I can't tell you the specific question) that has the same
>scenario that you have. Doyle says that the reason for that type of
>behaviour is because of the rule of split horizon. This makes sense for
>you scanario below because IGRP would use split horizon and OSPF does not
>use split horizon. However this is the part that still confuses me. I do
>not know why split horizon is applied to a redistribution process. I
>always though split horizon was implemented to not advertise a route out an
>interface from which that route was learned. Can any of the guru's out
>there explain why split horizon is applied during mutual redistribution?
>
>Buddy
>
>-----Original Message-----
>From: Jeff Szeto [mailto:jytszeto@hotmail.com]
>Sent: Wednesday, May 08, 2002 5:20 PM
>To: ccielab@groupstudy.com
>Subject: Redistribute ospf external route into igrp
>
>
>Hi,
>
>A router runs IGRP, OSPF and RIP. Mutual redistribution exist between
>OSPF---RIP and OSPF---IGRP. But no redistribution between IGRP and RIP.
>From the debug message I found that IGRP is no advertising the RIP routes
>that are redistributed into OSPF while the OSPF routes are advertised
>normally.
>On the other hand, the IGRP routes are advertised into RIP through OSPF.
>
>Could someone explain the concept behind or point me to a document.
>
>Thanks in advance.
>
>Jeff



This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:58:53 GMT-3