From: Greg Ferro (gferro@xxxxxxxxxxxxxxxxxxx)
Date: Thu Jan 25 2001 - 23:04:40 GMT-3
I have been using the ospf summary-address x.x.x.x y.y.y.y not-advertise or
area x range not-advertise which seem to work well. (Although I did not
expect them to, I will spend more time on this later).
This result is that the summary does not get advertised through the OSPF AS
but is used in the redistribution to IGRP. I think that this is a 12.0
command. This would be used when the OSPF masks are longer than IGRP
At 10:02 AM 24/01/2001 -0500, you wrote:
>Nigel,
>
>I struggled with this too. Here are my secret tools for trying to figure
>it out:
>
>1. debug ip igrp events, debug ip igrp transactions. Then do a clear ip
>ospf redistribution and a clear ip route * and watch what
>IGRP is sending in it's packets to neighbors.
>
>2. show ip ospf database and look at the external lsa's. This will tell you
>when you redistribute igrp into ospf if you are
>getting any unwanted routes.
>
>3. If on the same router - then I have found that IGRP will automatically
>announce any connected interfaces of the
>same subnet length and same major network. Your's however are of different
>networks - so summarization or something is needed.
>
>If the routes are in the same major network these techniques work:
>
>4. If the OSPF longer subnet masks are on ABR's that are not the
>redistribution router - use area x range command.
>5. If the OSPF longer subnet mask are on the ASBR - i.e. the redistributing
>router, then you have three choices:
> use a summary-address to the igrp subnet mask length and
>then filter it from going back into OSPF as an E2 route
> use a ip route xxxx xxxx to null 0 (with a subnet mask
>equal to that of your IGRP subnet mask) and redistribute static
> use a default-route to another non-related network.
>
>But in your case - two different major networks -
>
> I would think a summary-address to the classfull boundary.
> Or a default-route to this network at the classfull boundary - as
>it is a different major network.
> Or a static-route to the classfull boundary to null 0 and then
>redistribute static.
>
>What was the summary-address that you used? Did you then do a redistribute
>ospf 1 metric x x x x under
>your igrp process?
>
>Julie Ann
>
>
>At 07:14 PM 1/23/2001 -0500, you wrote:
> >Julie Ann,
> > I was working a lab like this over the past weekend and let
> >me say I've still not solved how to get the OSPF domain routed into the IGRP
> >domain. In my case the interface to the IGRP domain was given as
> >171.68.62.93/26 and all the OSPF connected interfaces were assigned address
> >on the 172.17.59.x subnet making use of address with /28 /29 /30 subnets.
> >The lab specified only the use of the 172.17.59.x. I tried the
> >summary-address and got nothing to work...
> >
> >I'm still looking for answers.....
> >
> >Nigel..
> >
> >----- Original Message -----
> >From: Connary, Julie Ann <jconnary@cisco.com>
> >To: <ccielab@groupstudy.com>
> >Sent: Tuesday, January 23, 2001 9:37 AM
> >Subject: summary-address in ospf and redistribution
> >
> >
> > > Hi All,
> > >
> > > I ran across a practice lab and another fat-kid lab that use the ospf
> > > summary-address to overcome
> > > vlsm to fsm issues when redistributing ospf into igrp:
> > >
> > >
> > >
> > > situation: The ospf connected interface has a longer mask than the IGRP
> > > connected interface.
> > > area-range does not work because it is on the same router.
> > >
> > > The Fatkid lab - expert redistribution - solves this with a
> >summary-address.
> > >
> > > Question - does this not inject E2 routes back into your OSPF domain?
> > >
> > >
> > > OSPF area 2
> > > 170.10.128.4 - 255.255.255.192
> > > |
> > > |
> > > |
> > > R4 -----------IGRP - 170.10.2.4 255.255.255.0
> > >
> > > To redistribute the ospf interface into IGRP a summary-address is
> > > used: summary-address 170.10.128.0 255.255.255.0
> > >
> > > But then in the ospf domain you get an E2 route to 170.10.128.0 in your
> > > ospf domain.
> > >
> > > So how do you prevent this E2 route into OSPF - can you filter it?
> > >
> > > Thoughts?
> > >
> > > remember - no static, no default.
> > >
> > > Julie Ann
> > >
> > >
> > >
> > >
> > > ------------------------------------------------------------------------
> > > Julie Ann Connary
> > > | | Network Consulting Engineer
> > > ||| ||| Federal Support Program
> > > .|||||. .|||||. 13635 Dulles Technology
> Drive,
> > > Herndon VA 20171
> > > .:|||||||||:.:|||||||||:. Pager: 1-888-642-0551
> > > c i s c o S y s t e m s Email: jconnary@cisco.com
> > >
> > > ------------------------------------------------------------------------
> > >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:27:44 GMT-3