Re: summary-address in ospf and redistribution

From: Connary, Julie Ann (jconnary@xxxxxxxxx)
Date: Wed Jan 24 2001 - 12:02:23 GMT-3


   
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:42 GMT-3