From: Omer Ansari (omer@xxxxxxxxxx)
Date: Mon Aug 26 2002 - 11:24:11 GMT-3
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
> > > >
> > > >redistribution on RB :
> > > >!
> > > >router eigrp 5
> > > > redistribute ospf 1 metric 10000 10 10 10 1500
> > > > network 155.1.23.0 0.0.0.255
> > > > network 155.1.25.0 0.0.0.255
> > > > default-metric 10000 10 10 10 1500
> > > > no auto-summary
> > > >!
> > > >router ospf 1
> > > > redistribute eigrp 5 metric 20 subnets
> > > > network 155.1.6.0 0.0.0.255 area 1
> > > > !
> > > >router igrp 1
> > > > redistribute ospf 1 metric 10000 10 10 10 1500 match internal external
> > > >1 external 2
> > > > passive-interface Async65
> > > > network 155.1.0.0
> > > > default-metric 10000 10 10 10 1500
> > > >!
> > > >---------
> > > >Rb
> > > >sh ip ospf database
> > > > Type-5 AS External Link States
> > > >
> > > >Link ID ADV Router Age Seq# Checksum Tag
> > > >
> > > >155.1.22.0 155.1.6.1 1830 0x8000007E 0xA8AB 0
> > > >155.1.55.0 155.1.6.1 1830 0x8000008C 0x4AD3 0
> > > >176.68.0.0 155.1.2.1 1410 0x80000002 0xC054 0
> > > >176.68.4.0 155.1.6.1 1317 0x80000002 0x592A 0
> > > >176.68.7.0 155.1.6.1 1317 0x80000002 0x3848 0
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:48:38 GMT-3