From: Erick B. (erickbe@xxxxxxxxx)
Date: Sun Oct 28 2001 - 22:58:25 GMT-3
Brian,
Yea. When I played with it I was using 12.1(8)
mainline I believe (it was a recent release) and
various 12.1T versions and 12.2 mainline and 12.2T.
Actually, when I looked into this I put 12.0(7)T on a
router and it worked, then I went to earliest 12.1
mainline I could find (12.1(1)) and it worked, then to
latest 12.1 mainline at the time and it still worked.
Then I went to earliest 12.1T image which was 12.1(2)T
I think and it stopped working.
The debug ip ospf lsa-gen output shows it is max-aged
when it attempts the redist. Then I scoured several
cisco.com pages, release notes, caveats, etc looking
for something documenting a change, etc and I didn't
find anything. I contacted TAC and they told me 12.1
mainline and earlier acted incorrectly and it was a
bug fixed in 12.1T and higher. I did provide a real
simple scenario to them w/captures and they agreed
this should be documented somewhere and were
forwarding the stuff I gave them to the doc team.
It was a useful bug though :) but there is no sense
having the same network in the OSPF LSDB multiple
times, etc. Plus it also enforces better network
design. I know this is the lab and anything goes
but... the product is made for the real-world.
Also, it's just not redist connected -- its *any*
external route going into OSPF from any source from
the testing I did. I tried redist eigrp, igrp, rip,
etc.
I have posted my results here a few months ago also
which are in the archives, but I tend to respond to
this everytime it comes up because it is important to
know.
I'm aware that 12.1 is fair game after November 1st,
but they don't mention what trains they'll put it in
the lab IOS pool.
Erick
--- Brian Hescock <bhescock@cisco.com> wrote:
> Erick,
> Actually, that part of it I took everyone's word
> on it (several
> people actually) that ospf reacted differently, with
> respect to "redist
> connected", in 12.1 mainline code. So if it's
> actually 12.1T then
> that's great news since I believe the CCIE people
> said they're going to
> 12.1 mainline in November. Perhaps Ken can confirm
> for us which version
> he saw it in.
>
> Brian
>
> Erick B. wrote:
>
> >Which version of 12.1 exactly? When I looked into
> >this a few months back, I found it still worked in
> >12.1 mainline and not 12.1T.
> >
> >--- kenairs <kenairs@hotmail.com> wrote:
> >
> >>HI Ravi ,
> >>I tried that and it works fine for version 12.0 .
> >>But coming this nov , the
> >>routers in the lab will be loaded version 12.1 (
> am
> >>i right ? ) .I try
> >>redistribute connected in version 12.1 but it
> >>doesn't work. So how are we
> >>going to overcome this problem ? The static route
> to
> >>null 0 works but we are
> >>not allow :( .
> >>
> >>Regards
> >>ken
> >>
> >>----- Original Message -----
> >>From: kym blair <kymblair@hotmail.com>
> >>To: <gkats@algosystems.gr>;
> >><s_ravichandran@hotmail.com>;
> >><w.schoots@chello.nl>; <ccielab@groupstudy.com>
> >>Sent: Sunday, October 28, 2001 2:37 PM
> >>Subject: RE: SOLUTION: OSPF Summary-Address (for
> >>redistrib into IGRP)
> >>
> >>
> >>>Yorgos,
> >>>
> >>>Your suggestion to create a static of the /25
> >>>
> >>connected using /24 to null0
> >>
> >>>so it matches the /24 IGRP interface to
> >>>
> >>redistribute into worked great.
> >>
> >>>Thanks.
> >>>
> >>>Kym
> >>>
> >>>
> >>>>From: "Yorgos Katsikogiannis"
> >>>>
> >><gkats@algosystems.gr>
> >>
> >>>>Reply-To: "Yorgos Katsikogiannis"
> >>>>
> >><gkats@algosystems.gr>
> >>
> >>>>To: "'Ravi'" <s_ravichandran@hotmail.com>,
>
> >>>>
> >>"'kym blair'"
> >>
> >>>><kymblair@hotmail.com>, <w.schoots@chello.nl>,
> >>>><ccielab@groupstudy.com>
> >>>>Subject: RE: SOLUTION: OSPF Summary-Address (for
> >>>>
> >>redistrib into IGRP)
> >>
> >>>>Date: Mon, 22 Oct 2001 19:32:21 +0300
> >>>>
> >>>>Hi Ravi,
> >>>>
> >>>>there is one more thing that you possibly could
> >>>>
> >>do to overcome this.
> >>
> >>>>You could create a static route of your
> >>>>
> >>*connected interface* using the
> >>
> >>>>major network subnet of the IGRP to a null
> >>>>
> >>interface (i.e if your IGRP
> >>
> >>>>is using /24, then you will have to use ip route
> >>>>
> >>xx.xx.xx.xx
> >>
> >>>>255.255.255.0 null0 ) and then redistribute
> this
> >>>>
> >>static route into your
> >>
> >>>>IGRP routing protocol.
> >>>>
> >>>>You may check see that your routes are now
> >>>>
> >>advertised correct, but the
> >>
> >>>>bother is that you cannot use this kind of
> >>>>
> >>solution under lab
> >>
> >>>>circumstances.
> >>>>
> >>>>Yorgos
> >>>>
> >>>>
> >>>>-----Original Message-----
> >>>>From: nobody@groupstudy.com
> >>>>
> >>[mailto:nobody@groupstudy.com] On Behalf Of
> >>
> >>>>Ravi
> >>>>Sent: Monday, October 22, 2001 7:02 PM
> >>>>To: kym blair; w.schoots@chello.nl;
> >>>>
> >>ccielab@groupstudy.com
> >>
> >>>>Subject: Re: SOLUTION: OSPF Summary-Address (for
> >>>>
> >>redistrib into IGRP)
> >>
> >>>>
> >>>>Hi Kym,
> >>>>
> >>>>If the connected interface that you are talking
> >>>>
> >>about is not in area 0 ,
> >>
> >>>>you may still use area range command on the
> other
> >>>>
> >>side of the link. OR
> >>
> >>>>You can do redis connected and use summary
> >>>>
> >>address. It works up to IOS
> >>
> >>>>12.0.
> >>>>
> >>>>I found problem when I used the same command on
> >>>>
> >>IOS 12.1. It does not
> >>
> >>>>redistribute the connected interface if the
> >>>>
> >>interface is already in any
> >>
> >>>>of the ospf area. It works for any interface
> >>>>
> >>which are not in any
> >>
> >>>>routing process. Try by using secondary address
> >>>>
> >>to overcome this
> >>
> >>>>problem.
> >>>>
> >>>>Any one has better solution please add.
> >>>>
> >>>>Regards,
> >>>>Ravi
> >>>>
> >>>>
> >>>>----- Original Message -----
> >>>>From: kym blair <kymblair@hotmail.com>
> >>>>To: <w.schoots@chello.nl>;
> >>>>
> >><ccielab@groupstudy.com>
> >>
> >>>>Sent: Monday, October 22, 2001 8:54 AM
> >>>>Subject: SOLUTION: OSPF Summary-Address (for
> >>>>
> >>redistrib into IGRP)
> >>
> >>>>
> >>>>>Willy's solution to use area range at the ABR
> >>>>>
> >>before the ASBR worked;
> >>
> >>>>>both became OSPF IA /24 networks and
> >>>>>
> >>redistributed into IGRP:
> >>
> >>>>>>If you would use an area range command on R5,
> >>>>>>
> >>then it should work:
> >>
> >>>>>>area 0 range 152.1.1.0 255.255.255.0 area 0
> >>>>>>
> >>range 152.1.2.0
> >>
> >>>>>>255.255.255.0
> >>>>>>
> >>>>>Ravi's comment explains:
> >>>>>
> >>>>>Your R6 (ASBR between OSPF and IGRP) routing
> >>>>>
> >>table shows both the
> >>
> >>>>>network
> >>>>>
> >>>>as
> >>>>
> >>>>>IA entry. To summarize a IA route, you can use
> >>>>>
> >>area range command on
> >>
> >>>>>ABRs. Summary address to summarize routes
> >>>>>
> >>learned from another routing
> >>
> >>>>>process, and to be used on ASBRs. As your
> >>>>>
> >>routes are IA routes,
> >>
> >>>>>summary address
> >>>>>
> >>>>will
> >>>>
> >>>>>not work.
> >>>>>
> >>>>>Thanks for the help; also thanks to those who
> >>>>>
> >>offered to recreate this
> >>
> >>>>>scenario on their labs.
> >>>>>
> >>>>>***** This leads to one more question: ******
> >>>>>
> >>>>>If we had a directly connected interface on R6
> >>>>>
> >>(ASBR) with a /25 mask,
> >>
> >>>>>how would we summarize to a /24 to get it into
> >>>>>
> >>IGRP (static works, but
> >>
> >>>>>for
> >>>>>
> >>>>this
> >>>>
> >>>>>scenario cannot be used)? It wouldn't be an
> >>>>>
> >>OSPF IA route, so we
> >>
> >>>>>couldn't use area range at the previous ABR,
> >>>>>
> >>and summary-address
> >>
> >>>>>doesn't work (I tried).
> >>>>>
> >>>>>Kym
This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 22:33:27 GMT-3