From: Padhu (LFG) (padhu@xxxxxxxxxxxx)
Date: Thu May 24 2001 - 00:14:21 GMT-3
million thanks to Mas Kat who helped me understand this after his series of
tearing this part of the ospf lab apart.
I am also under the impression that summary address should be used for
summarising routes coming "into" ospf not from ospf. So basically can be
used ONLY at the ASBR. However,the directly connected serial which is a /28
and also part of ospf area is actually not an "OSPF route with a O"
in the show ip route on the ASBR. So redistribute connected helps here to
bring in the locally attached serial /28 and makes this router an ASBR. Now
there "is" an external route which is a pre-requisite for the summary
address command. So using summary address makes sense here even though the
direction of summarization is kinda different from the "usual way" its been
used.
Cheers,Padhu
-----Original Message-----
From: Andrew Lennon
To: Sandro Ciffali; YOUNG, DANIEL (SBCSI); Devender Singh; Mohamed Heeba;
ccielab@groupstudy.com
Sent: 5/23/01 7:17 PM
Subject: RE: OSPF summary and redistribution
Hi all,
General thoughts. Ignore if you like
To redistribute a longer mask from OSPF to RIPv1/IGRP use a summary
address
on the OSPF router etc. Apart from using static routes to fudge it(no
extra
OSPF processes thank you), I know of no other way to do it (if you do,
email
me directly, with working configs). Contrary to public belief there are
IOS
bugs ("really?" says the man at the back). The summary-address will
work
fine. If it does not, strip your configs down to the bare minimum and
work
from there. If you find that it doesn't work after adding extras, one
bit
at a time, then be sure before you post (check the archives/books) and
then
look to http://www.cisco.com/support/bugtools/bugtool.shtml . If you
have
other technologies incorporated into your configs, its probably worth
cross
checking there too.
A few things sping to mind:
http://www.groupstudy.com/cgi-bin/wilma/ccielab
Good troubleshhoting practice
The CCIE proctors at your lab should be aware of IOS issues. The labs
that
you receive should not include scenarios where bugs would appear in your
IOS
Version.
IOS is version 12.0 GD - thats not breaking NDA!
Sending a valid bug request ensures later IOS version stability and
helps to
get rid of bugs.
Andy
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Sandro Ciffali
Sent: 23 May 2001 22:45
To: YOUNG, DANIEL (SBCSI); Devender Singh; Mohamed Heeba;
ccielab@groupstudy.com
Subject: Re: OSPF summary and redistribution
Daniel,
There was one more idea braught up in the discussion which redistributes
/28
to /24 without introducing E2 route, that was to create another loop
back
interface with a subnet of same major network as /28 (for example if you
had
133.4.10.16/28 as backbone, then create a loopback 133.4.10.32/28 on one
of
the nonasbr spoke) keep this loopback on an entire different area and
summarize this area into the backbone as a /24, So backbone will have a
/24
IO route and /28 connected route, /24 will get redistributed in igrp.
Sandro
----- Original Message -----
From: "YOUNG, DANIEL (SBCSI)" <dy3519@sbc.com>
To: "Sandro Ciffali" <sandyccie@yahoo.com>; "Devender Singh"
<devender.singh@cmc.cwo.net.au>; "Mohamed Heeba" <MAHeeba@itqan.co.ae>;
<ccielab@groupstudy.com>
Sent: Wednesday, May 23, 2001 4:47 PM
Subject: RE: OSPF summary and redistribution
>
> I believe that the "correct" way is per Cisco documentation:
> http://www.cisco.com/warp/customer/105/52.html
>
> Add a static route in the OSPF ASBR that points to the OSPF domain
with a
> /24 mask, but with a next hop of null0. Then, redistribute static
routes
> into RIP. This allows the OSPF addressed to be advertised to the RIP
domain.
> The ASBR Router would still have more specific routes learned from
OSPF in
> its routing table, so the best routing decisions will be made. This
prevents
> black holes.
>
> The summary-address solution is another way, but it is inefficient as
it
> creates addtional entries on the link-state database.
Summary-addresses
are,
> per Devender, supposed to be used to summarize external routes (type 5
LSAs)
> -- not the other way around. However, if you are prohibited from
creating
> static routes, then this is your only other viable option.
>
> Can I get yeas or nays on this?
>
> Daniel
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Sandro Ciffali
> Sent: Tuesday, May 22, 2001 4:39 PM
> To: Devender Singh; Mohamed Heeba; ccielab@groupstudy.com
> Subject: Re: OSPF summary and redistribution
>
>
> Devender,
> I agree with you completly on this, This is the way i plan to
distribute
/28
> to /24 on asbr from ospf to rip or igrp, But i have heard through
couple
of
> guys that it is makred as modifying ospf database hence lost points, I
> seriously hope someone would tell us the correct way of doing this.
>
> Sandro
> ----- Original Message -----
> From: "Devender Singh" <devender.singh@cmc.cwo.net.au>
> To: "Mohamed Heeba" <MAHeeba@itqan.co.ae>; <ccielab@groupstudy.com>
> Sent: Tuesday, May 22, 2001 7:02 PM
> Subject: RE: OSPF summary and redistribution
>
>
> > Hai Mohammad,
> > Sorry to come the subject a bit late.
> >
> > I agree this is Scary and I agree with what ever you said. What if
this
> > situation
> > arises in the lab :-(((. I wish to discuss this bit futher.
> >
> > This my understanding:
> >
> > Normally summary-address used create a summary from type 5 LSA on
ASBR
> (Say
> > rip to ospf ). But what happens when we use it to summarise the
other
way
> > around. When we redistribute ospf into say RIP, by rules it will get
> > redistributed into RIP, but if the mask on the outgoing RIP
interface
> does
> > not match routes will not be progated into rip. The mask on the
outgoing
> > interface does not have anything to do with basic process of
> redistribution.
> > Now if we redistribute RIP back into ospf without any route-map or
> > distribute-lists all this route will be inserted back into ospf but
they
> > will not bother ospf because internal routes have preference over
external
> > routes. Now the summary command ( our hack) does its job and pushes
it
> back
> > to RIP with the mask we want also into ospf domain as external. Rest
> > everything is normal.
> >
> > Does this make sense to you.
> >
> > Best regards
> >
> > Devender Singh
> > BE(Hons), CCNP
> > IP Solution Specialist
> >
> >
> > -----Original Message-----
> > From: Mohamed Heeba [mailto:MAHeeba@itqan.co.ae]
> > Sent: Saturday, 12 May 2001 9:04
> > To: 'ccielab@groupstudy.com'
> > Subject: OSPF summary and redistribution
> >
> >
> > guys ;
> > i have reached a conculation about the problem of the OSPF and
> summarization
> > /redistribution and wanted to share it with you who are interested .
> > i have revised Doyles chapter of redistribution ,there is an example
of
> > redistributing RIP into IS-IS and at the end of this chapter ,(RIP
is
/24
> > and ISIS is /24 and /28 )
> > CLEARLY ,he NEVER use the command summary-address to summarize the
ISIS
> > routes to the RIP and clearly also mentioned that ISIS /28 routes
should
> be
> > summarized to RIP by using STATIC ROUTES !!!!.
> > so the point is the summary command should only be used to summarize
> > extrenal routes INTO ISIS or OSPF .but our problem is that we were
trying
> to
> > go around this problem to avoid the use of static routes ,while in
fact
it
> > is an easy way to solve this problem.
> > going around the problem can may be done by a command like ip
> > default-network ,but this will require the major class network to be
> > different in both domains.
> > well...i guess in the real lab there should be way to avoid using
the
> > summary address in opposite way and create more problems ....or they
may
> > allow to use just single static route somewhere :))))))
> >
> >
> > hope someone can comment on this
> > Mohamed
> > **Please read:http://www.groupstudy.com/list/posting.html
> > **Please read:http://www.groupstudy.com/list/posting.html
> **Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:30:51 GMT-3