From: Mingzhou Nie (mnie@xxxxxxxxx)
Date: Mon Aug 26 2002 - 16:18:55 GMT-3
Omer,
I believe the route is in the "routing table". After all, it's a
connected interface so it should be in routing table anyway. Because
it's a connected route, even though it is in OSPF topology database,
it's still shown as "C" in routing table. If OSPF is allowed to have
its own routing table, I'm pretty sure it's in both router's and ospf's
"routing table".
The routing table = igrp "routing table" + ospf "routing
table"(remember those routing tables are not really but virtual). And
the loopback route is in both igrp "routing table" and ospf "routing
table".
ming
--- Omer Ansari <omer@ansari.com> wrote:
> Colin,
>
> Errata: the example should have been of the same ClassB network used
> on
> both sides.
>
> this is a better example (stolen from a thread)
>
> 135.4.24/27--(r4)--135.4.36/28--<OSPF-(r6)-->IGRP--135.4.56/24--(r5)
>
> ospf on r4 and r6
> igrp on r6 and r5
>
> r6 is where the mutual redist' is happening. ofcourse IGRP is running
> on
> all its interfaces (network 135.4.0.0)
>
>
> . thus create loopbacks on R6:
> int lo1
> ip add 135.4.24.33/27
> int lo2
> ip add 135.4.36.17/28
>
> . ospf not running on the above, but igrp is
> . they then get redist'ed into ospf <---would see them in the ospf
> database but not in the route table.
> . create summary addresses under ospf: 135.4.24/24, 135.4.36/24
> cause summary routes to be created
> . these /24 routes then get redist'ed back into igrp, and get passed
> to r5
>
>
> In my earlier example, 12/8 should be redist'ed to IGRP anyway
> as they are of different classful nets (if igrp was running on the 12
> net)
>
>
>
> On Mon, 26 Aug 2002, Colin Barber wrote:
>
> > I don't understand point 2. Why is this route being put into the
> IGRP db?
> > IGRP should only be running on network 192.168.1.0.
> >
> > Colin
> >
> > -----Original Message-----
> > From: Omer Ansari [mailto:omer@ansari.com]
> > Sent: 26 August 2002 01:48
> > To: Volkov, Dmitry (Toronto - BCE)
> > Cc: 'Omer Ansari'; ccielab@groupstudy.com; 'ccie candidate'
> > Subject: RE: redistribution from eigrp2ospf2igrp
> >
> >
> > Dmitry,
> >
> > remember the thread where we wanted to get a subnetted route (/29)
> through
> > from OSPF to IGRP?
> >
> > e.g.
> >
> > --12.1.1.1/29--->---OSPF--->(R1)---(192.1.1/24)---IGRP---->(R2)
> >
> > to get the 12.1.1.1/29 route to R2,
> >
> > one way is this:
> >
> > 1. to create a subnet of the same 12.0.0.0 network on the R1.
> > e.g.
> > int lo12
> > ip add 12.1.1.9 255.255.255.248
> >
> > 2. the above would automatically put the route into the IGRP db.
> >
> > 3. since there is mutual distribution happening on R1, you would
> see the
> > route 12.1.1.8 as an external LSA in the OSPF table on R1.
> >
> > -----
> > note that this route does not appear in the route table, but is
> only
> > in the ospf database. <---this is what I was talking about
> > -----
> >
> > 4. now if you do a summary-address 12.1.1.0 255.255.255.0 on R1,
> > a summary OSPF route would get created, and b/c this route is /24
> it would
> > also get sent to R2.
> >
> > Omer
> >
> > On Sun, 25 Aug 2002, Volkov, Dmitry (Toronto - BCE) wrote:
> >
> > > Omer,
> > >
> > > Could You please give some examples when this theory doesn't work
> -
> > > i.e. redistribution happens without the appearance of routes in
> RT ?
> > > What thread did You mean ?
> > >
> > > Thank You,
> > >
> > > Dmitry
> > >
> > >
> > > C,
> > >
> > > i used to believe that too, but some scenarios i've done seem to
> negate
> > > this theory.
> > >
> > > i've only seen this hold true when redist'ing RIP into XYZ.
> > >
> > > interestingly enough, you can use this to use advantage in
> VLSM/FLSM
> > > scenarios. there was a nice thread but it was in august and we
> dont have
> > > that yet in the archive.
> > >
> > >
> > > On Sat, 24 Aug 2002, ccie candidate wrote:
> > >
> > > > can we then say that the redistribute command will work on the
> routes
> > > > that shown up in the routing table and not the route that are
> on the
> > > > database of topology .
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > On Sat, 24 Aug 2002 19:12:21
> > > > Colin Barber wrote:
> > > > >We have had a few similar mails to this problem recently.
> Basically if
> > a
> > > > >route is learnt via redistribution that route will not be
> redistributed
> > > into
> > > > >another routing protocol on the same router. For IGRP to learn
> the
> > routes
> > > > >you require you must redistribute EIGRP into IGRP.
> > > > >
> > > > >Colin
> > > > >
> > > > >-----Original Message-----
> > > > >From: walid@gnet.tn [mailto:walid@gnet.tn]
> > > > >Sent: 24 August 2002 17:42
> > > > >To: ccielab groupstudy
> > > > >Subject: redistribution from eigrp2ospf2igrp
> > > > >
> > > > >
> > > > >Hello all
> > > > >if anybody can explain why redistribution cannot happen from
> eigrp to
> > > > >ospf to igrp in this case :
> > > > >
> > > > >RA (runnig igrp)---155.1.56.0/24----RB(runnig igrp with RA,
> ospf with
> > > > >other routers and eigrp with RC)----155.1.23.0/24--RC (runnig
> eigrp)
> > > > >
> > > > >there is redistribution from eigrp and ospf and from ospf to
> igrp on
> > Rb
> > > > >(with default metric, subnets ..)
> > > > >routes learned from RC by eigrp in the same major network as
> 155.1.56.0
> > > > >(155.1.x.x) cannot be redistrubute from ospf to igrp while
> other routes
> > > > >(exp 172.68.x.x) that are learned from eigrp can be
> redistrubute to
> > ospf
> > > > >an then to igrp:
> > > > >
> > > > >RB :
> > > > >sh ip route eigrp
> > > > >RB#sh ip route eigrp
> > > > > 155.1.0.0/16 is variably subnetted, 21 subnets, 3 masks
> > > > >D 155.1.22.0/29 [90/21024000] via 155.1.23.5, Serial0/1
> > > > >D 155.1.55.0/24 [90/20640000] via 155.1.23.5, Serial0/1
> > > > > 176.68.0.0/16 is variably subnetted, 3 subnets, 2 masks
> > > > >D 176.68.4.0/24 [90/287132416] via 155.1.25.10, Async65
> > > > >D 176.68.7.0/24 [90/287132416] via 155.1.25.10, Async65
> > > > >RA
> > > > >RA#sh ip route igrp
> > > > > 155.1.0.0/16 is variably subnetted, 16 subnets, 2 masks
> > > > >I 155.1.24.0/24 [100/1114] via 155.1.56.6, 00:00:02,
> Ethernet0
> > > > >I 155.1.25.0/24 [100/1125568] via 155.1.56.6, 00:00:02,
> Ethernet0
> > > > >I 176.68.0.0/16 [100/1114] via 155.1.56.6, 00:00:04,
> Ethernet0
>
=== message truncated ===
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:48:38 GMT-3