From: Aidan Marks (amarks@cisco.com)
Date: Sat Jan 04 2003 - 21:21:01 GMT-3
I got (4) going as well. In fact, I think this is a cool solution. It
means you can isolate your summary addresses to a single process/box, you
don't have to mess around with the rest of your topology with area
range/summary-address statements and you don't have summarisation happening
in your VLSM nets where you probably don't need it (if just trying to solve
the FLSM problem specifically).
It seemed that with my version of code, you needed to stick a network in
the second ospf process to kick start it as just redistributing anything in
did not show anything in the ospf database.
Aidan
At 10:56 AM 30/12/2002, Jason Greenberg wrote:
>I'm sorry I meant #4, the multiple OSPF process solution. I tried that
>and it did not work.
>
>
>On Sun, 2002-12-29 at 16:40, Aidan Marks wrote:
> > The tunnel solution works quite nicely, and in doing so remember:
> >
> > 1) multiple GRE tunnels using the same encap between 2 routers need
> > different source/dest addresses, i.e. one loopback per tunnel
> >
> > 2) be careful about route recursion,
> > http://www.cisco.com/warp/public/105/gre_flap.html (instead of doing
> > statics in this document, you can just filter the routes being learnt by
> > the protocol).
> >
> > I got this going with RIPv1/OSPF, 2 tunnels (e.g. /24, /25) with
> physical a
> > /30, in a matter of minutes.
> >
> > Aidan
> >
> > At 08:04 PM 29/12/2002, kym blair wrote:
> >
> > >Jay and Yong,
> > >
> > >When you are doing mutual redistribution between OSPF and RIP, there are
> > >several ways to get the OSPF routes into RIP:
> > >
> > >(1) Use RIP version 2
> > >
> > >(2) Create a /30 secondary address on the R2-R3 link so R3 will learn the
> > >/24 AND /30 routes (repeat for other masks)
> > >
> > >(3) Create a tunnel between R2 and R3 with a /30 mask (repeat for
> other masks)
> > >
> > >(4) My favorite if you can't use RIPv2: Create another OSPF process on
> R2;
> > >redistribute OSPF 1 into OSPF 2; add summary-address statements under
> OSPF
> > >2; redistribute OSPF 1 and OSPF 2 into RIP.
> > >
> > >HTH, Kym
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >>From: @L?k?l <dragain@samsung.com>
> > >>Reply-To: @L?k?l <dragain@samsung.com>
> > >>CC: ccielab@groupstudy.com
> > >>Subject: Re: RIP to OSPF redistribution
> > >>Date: Sat, 28 Dec 2002 22:21:55 +0900
> > >>
> > >>I have a similar question.
> > >>If R2 don't have some area about 140.100.2.0/24
> > >>I think R1 also don't have "140.100.2.0/24" route.
> > >>How can R1 have route of "140.100.2.0/24"
> > >>
> > >>
> > >>
> > >>------- ?x:; 8^<<Av -------
> > >> :83=;g6w : Jay Greenberg <groupstudylist@execulink.com>
> > >> 3/ B% : 20023b 12?y 28@O 16=C 06:P
> > >> A& 8q : RIP to OSPF redistribution
> > >>
> > >>I'm sure this question has been asked a million times, but the archives
> > >>aren't giving me the answer I'm looking for. How do you summarize OSPF
> > >>type 3 LSAs into RIP when there is no ABR to summarize on?
> > >>
> > >>R1-----(ospf)-----R2------(rip)------R3
> > >>
> > >>R1 - R2 is subnet 140.100.1.0/30
> > >>R2 - R3 is subnet 140.100.2.0/24
> > >>
> > >>How can R3 learn about 140.100.1.0/30 without using static routes?
> > >>There is no ABR to use "area range", and there is no inbound ASBR to use
> > >>ospf "summary-address", nor are these type 5/7 LSAs.
> > >>
> > >>Answers I've heard so far are:
> > >>
> > >>"use the ip summary-address rip" command on R2, but I tried that in the
> > >>lab and nothing happened. Maybe I was doing something wrong?
> > >>
> > >>"use a default-network" on R2, and I have used this in a practice lab,
> > >>and it worked, but I'm worried that a real lab won't allow default
> > >>routes.
> > >>
> > >>Any comments would be greatly appreciated.
> > >>.
> > >>.
> > >_________________________________________________________________
> > >The new MSN 8: smart spam protection and 3 months FREE*.
> > >http://join.msn.com/?page=features/junkmail&xAPID=42&PS=47575&PI=7324&D
> I=7474&SU=
> > >http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_smarts
> pamprotection_3mf
> > >.
> > .
.
This archive was generated by hypermail 2.1.4 : Sat Feb 01 2003 - 07:33:41 GMT-3