From: Volkov, Dmitry (Toronto - BCE) (dmitry_volkov@xxxxxxxxx)
Date: Tue Aug 06 2002 - 00:55:12 GMT-3
Omer,
Sure loopback - easiest solution as soon it's allowed by proctor.
I think nothing prevents here to make s1 passive, because it will only stops
IGRP adverts from S1 - nothing more. IGRP will still be running on S1.
Dmitry
-----Original Message-----
From: Omer Ansari [mailto:omer@ansari.com]
Sent: Monday, August 05, 2002 6:55 PM
To: Denise Donohue
Cc: Volkov, Dmitry (Toronto - BCE); ccielab@groupstudy.com
Subject: Re: secondary on IGRP, redistr classless/IGRP
Denise,
good point, but wouldnt a cleaner way to do this would be to just create
loopback interfaces with the requisite networks instead of using S1?
That way we can passive S1 in igrp to stop it from barking on the ospf
network, while achieving the same results.
thus
loopback(r6)--->into IGRP---->into OSPF--->(summary-address on
OSPF)--->back to IGRP
Omer
On Mon, 5 Aug 2002, Denise Donohue wrote:
> My favorite way to do this is to assign secondary addresses to the
> interfaces that have subnet masks different from IGRP's. In your example
> below, you'd assign a secondary to S1 of R4. Of course, you can only do
> this if it won't overlap any other addresses on the router. Don't try to
> assign the secondaries to the IGRP link - that leads to the issues you've
> outlined
>
> Denise
> #9566
>
> ----- Original Message -----
> From: "Volkov, Dmitry (Toronto - BCE)" <dmitry_volkov@ca.ml.com>
> To: <ccielab@groupstudy.com>
> Sent: Monday, August 05, 2002 8:48 PM
> Subject: secondary on IGRP, redistr classless/IGRP
>
>
> > Hello,
> >
> > Thinking about secondaries in IGRP as way to redistribute classles to
> > classfull routing protocols,
> > I came to intersting conclusion:
> >
> > Let say we have the following:
> >
> > 1) case r8(s0)-----igrp---/24----(s0)r4(s1)-----ospf--/29---- or even
vice
> > versa:
> > 2) case r8(s0)-----igrp---/29----(s0)r4(s1)-----ospf--/24----
> >
> > several methods exist:
> > 1) ospf piggy back on r4 - drawback - second routing process
> > 2) tunnel between r8 & r4 with the same mask as ospf - drawback -
> additional
> > interfaces
> > 3) secondary addresses between r8 & r4 ro reflect ospf prefix lengths -
> > drawback - split horizon issue
> > 4) making r4 ABR and use area range - not always possible...(ABR must be
> > connected to area 0...)
> > 5) summarize somewhere inside ospf if it possible...- not always
possible
> or
> > permitted
> > 6) static routes - usually not allowed in the lab.
> >
> > Usually in such scenarios we do mutual redistribution igrp <--> ospf...
> > Taken into consideration that after 12.1(3) redistribute connected will
> not
> > work, because ospf is running on s1(r4),
> > we can do the following : assign secondary address on s0(r4) ONLY !!!
> > We can put many secondary there actually.
> >
> > Igrp is running on this secondary address, redistributes it to OSPF, it
> > appears as LSA 5,
> > after that we can put summary-address with any mask we want - shorter or
> > longer than original ospf network -
> > depending on which case we have 1) or 2) , no discard route external if
> You
> > want, and this summary will be
> > redistributed to IGRP. Now R8 will know required network.
> > Care should be taken to avoid black holes on R4.
> >
> > I think this way more clean than using tunnels or piggy back...
> >
> > I tried it using 12.1(15) - works fine.
> >
> > What do You think about it ? Did I miss something ??
> >
> >
> > Thanks,
> >
> > Dmitry
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:48:17 GMT-3