From: Mas Kato (tealp729@xxxxxxxx)
Date: Tue Apr 24 2001 - 04:56:00 GMT-3
My comment was in reference to the fact that the link-state database
must be synchronized throughout the area. OSPF routes are taggable, so
there must be some data structure keeping track of this (and perhaps
other) information along with the LSdb.
...A quick scan of RFC-2328 yielded the following tidbits:
Externally derived routing data (e.g., routes learned from an Exterior
Gateway Protocol such as BGP; see [Ref23]) is advertised throughout the
Autonomous System. This externally derived data is kept separate from
the OSPF protocol's link state data. Each external route can also be
tagged by the advertising router, enabling the passing of additional
information between routers on the boundary of the Autonomous System.
All LSAs have an 'Options' field and Type 5 LSAs also have an 'External
Route Tag' field which is undefined by the RFC...
So a contrived scenario, I guess, would involve, perhaps, a way to hide
routes from certain routers--'Opaque' routes perhaps?
-----Original Message-----
From: Curtis Call [mailto:curtiscall@home.com]
Sent: Monday, April 23, 2001 7:26 PM
To: Mas Kato
Cc: ccielab@groupstudy.com
Subject: RE: Re: summary-address in ospf and redistribution
I don't think this is a correct assumption. I don't believe there is
any
field in LSA type 5's that would convery the necessary information to
other
routers to keep that particular LSA in the database but not in their
routing tables. If this particular observation is valid then it would
most
likely be localized to the router in particular.
At 12:08 PM 4/23/01, you wrote:
>This might provide an interesting option--although the route will not
>appear in the routing table, it *should* appear in all of the
link-state
>DBs throughout the area, right? Hmmm... I wonder in what sort of
>contrived scenario might we need to deploy that feature into?... ;-)
>
>Mas Kato
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
>Mannan Venkatesan
>Sent: Monday, April 23, 2001 7:41 AM
>To: Michel GASPARD
>Cc: ccielab@groupstudy.com
>Subject: Re: Re: summary-address in ospf and redistribution
>
>
>Hi,
>I was playing with scenario(OSPF -> IGRP redistribution with
>summary-address) last night and found the following.
>
>When I used summary-address command with 'not-advertise' option, the E2
>summary route (170.100.2.0) appeared only in the OSPF database but not
>in
>the routing table (R3). I didn't use any filter on the redistribution
>router.
>
>Mannan
>
>----- Original Message -----
>From: "Michel GASPARD" <mgaspard@cisco.com>
>To: "Mannan Venkatesan" <venkat_m@ins.com>
>Cc: "Connary, Julie Ann" <jconnary@cisco.com>;
<ccielab@groupstudy.com>;
>"Mannan Venkatesan" <mv70@lucent.com>
>Sent: Friday, April 20, 2001 2:29 AM
>Subject: OSPF: Re: summary-address in ospf and redistribution
>
>
> > Mannan,
> >
> > 1) According to Doyle (p723-724), OSPF "summary-address" can only be
> > used for summarization of external routes, in the ASBR, INTO the
OSPF
> > process.
> >
> > 2) From:
> >
> >
>http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/
n
>p1_r
>/1rprt1/1rospf.htm#xtocid677242
> >
> > we have:
> >
> > "
> > Using this command for OSPF causes an OSPF autonomous system
boundary
> > router (ASBR) to advertise one external route as an aggregate for
all
> > redistributed routes that are covered by the address. For OSPF, this
> > command summarizes only routes from other routing protocols that are
> > being redistributed into OSPF.
> > "
> >
> >
> > 3) Well, that is the official version. Some people claims it is also
> > working the other way around (OSPF => other). I will test that this
> > afternoon.
> >
> > 4) A quick check on groupstudy's archive with "summary-address" give
>you
> > PLENTY of more stuff to read!!
> >
> > Regards,
> >
> > Michel
> >
> > Mannan Venkatesan wrote:
> > >
> > > Julie,
> > > Thanks for the response. I tried it and found the following. I
would
>like to
> > > confirm whatever I understand is right. Let me re-draw my
scenario.
> > > I have used class B address, 170.100.0.0
> > >
> > > I I/O O
> > > ------- r1----------r2-----------r3-------------
> > > 1.0/24 4.0/24 2.4/30 /29,/28,27 subnets
> > >
> > > I configured everything without redistribution, worked fine. Then,
I
> > > configured redistribution from IGRP to OSPF on R2, worked as
>expected.
>Then
> > > I typed 'summary address 170.100.2.0 255.255.255.0' under ospf
>process
>(for
> > > OSPF -> IGRP redistribution) which created a summary address
>170.100.2.0 -
> > > >null 0 on R2 routing table. On R3 routing table it appeared as E2
>route.
> > > But note that I haven't configured OSPF -> IGRP redistribution
yet.
> > > So, the E2 route was inserted by OSPF process. It is not coming
back
>from
> > > IGRP because there was no OSPF -> IGRP redistribution. I had a
>impression
> > > that the E2 route is because of route loop.
> > > So, I can't filter that summary router on r2. If I do, OSPF ->
IGRP
>red.
> > > wouldn't work which is happening when I used distribution-list
out.
> > >
> > > Is it a normal behavior of OSPF? Or am I missing some OSPF basic?
> > >
> > > Thanks,
> > > Mannan
> > >
> > > ----- Original Message -----
> > > From: "Connary, Julie Ann" <jconnary@cisco.com>
> > > To: "Mannan Venkatesan" <venkat_m@ins.com>
> > > Sent: Thursday, April 19, 2001 9:40 AM
> > > Subject: Re: summary-address in ospf and redistribution
> > >
> > > > Mannan,
> > > >
> > > > it is pratically impossible to tell from your diagram what your
>topology
> > > > is. I am assuming that igrp is running between routers r1 and
r2.
>R2
>is
> > > the
> > > > re-distribution router and area 0 is between r2 and r3, area 1
is
>between
> > > > r3 and r4. The OSPF area is variably subnetted of the Ip address
> > > > 170.100.2.0 and 170.100.4.0? And the IGRP area is
170.100.1.0/24?
>So
>you
> > > > are trying to summarize the 170.100.2.0 network to a class 24
>boundary
>to
> > > > redistribute into EIGRP? And why are you not redistributing OSPF
>into
> > > > IGRP? I think this is part of your problem. Try that and let me
>know.
> > > >
> > > > Unfortunately the example at the bottom, upon closer inspection
is
> > > > backwards. I thinkthe two access-lists should be swapped. I
edited
>this
> > > > below.
> > > >
> > > > Julie Ann
> > > >
> > > >
> > > > At 10:14 PM 4/18/2001 -0400, you wrote:
> > > > >Hi,
> > > > >I was trying this scenario. Have a question for you. Where did
>you
>use
> > > > >route-map? When I used route-map on the redistribution router,
>the
> > > summary
> > > > >route( 170.100.2.0 ->null0) disappeared from the routing table
>and I
> > > > >couldn't ping OSPF networks from IGRP router.
> > > > >
> > > > > IGRP
>IGRP/OSPF
> > > > >Area 0 OSPF Area 1
> > > >
> >
> -------------------R1------------------------R2---------------------
-- >---- > > > R > > > > >3----------------------R4-- > > > > > 170.100.1.0/24 170.100.4.0/25 >170.100.2.4/30 > > > > >/29, /28, /30 networks > > > > > > > > > > > > > > >R2 Config: > > > > >router ospf 10 > > > > > summary-address 170.100.2.0 255.255.255.0 > > > > > redistribute igrp 10 metric-type 1 subnets route-map sum > > > > > network 170.100.2.4 0.0.0.3 area 0 > > > > >! > > > > >router igrp 10 > > > > > network 170.100.0.0 > > > > >! > > > > >no ip classless > > > > >access-list 1 permit 170.100.2.0 0.0.0.255 > > > > >route-map sum deny 10 > > > > > match ip address 1 > > > > >! > > > > >route-map sum permit 20 > > > > >! > > > > > > > > > >I could able to filter that E1 route on R3 by using >distribution-list >in. > > > > >But the OSPF database still had that E1 route which is the normal > > > behavior > > > > >of OSPF. > > > > > > > > > >I would like to filter it on the redistribution router. Any >advice? > > > > > > > > > >Thanks, > > > > >Mannan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >----- Original Message ----- > > > > >From: "Connary, Julie Ann" <jconnary@cisco.com> > > > > >To: <SherefMohamed@cdh.org> > > > > >Cc: <ccielab@groupstudy.com>; <nobody@groupstudy.com> > > > > >Sent: Tuesday, January 23, 2001 12:31 PM > > > > >Subject: Re: summary-address in ospf and redistribution > > > > > > > > > > > > > > >I tested a similar theory with route-maps and worked > > > > >like a champ. > > > > >Beware - the fatkid lab posted solution > > > > >(http://www.fatkid.com/html/501_expert_redistribution_-_ro.html) > > > > > does not use route-maps - and the posted routing tables - >however > > > reflect > > > > >that route-map were used. > > > > > > > > > >Julie Ann > > > > > > > > > >At 09:55 AM 1/23/2001 -0600, SherefMohamed@cdh.org wrote: > > > > > > > > > > >You need to do mutual redistribution between OSPF and IGRP, > > > > > >the idea is to not allow IGRP send back to OSPF the summary >address >! > > > > > >Here is how I will do it: > > > > > > > > > > > >! > > > > > >router igrp 2 > > > > > >.......... > > > > > >distribute-list 11 out ospf --- key here is to distribute the > > > > > 172.10.2.0 subnet into igrp. Of course this example will only > > > > > > > > distribute the 172.10.2.0 >subnet >and > > > no > > > > others. > > > > > > > > > >.......... > > > > > >! > > > > > >router ospf 1 > > > > > >........... > > > > > >distribute-list 10 out igrp --- key here is not to redistibute >it >back > > > > > into OSPF. > > > > > >........... > > > > > >! > > > > > > > > > > > >access-list 10 deny 170.10.2.0 0.0.0.255 > > > > > >access-list 10 permit 0.0.0.0 255.255.255.255 > > > > > >! > > > > > >access-list 11 permit 172.10.2.0 0.0.0.255 > > > > > >access-list 11 deny 0.0.0.0 255.255.255.255 > > > > > > > > > > > >Please test it & tell me how it works ! > > > > > > > > > > > >Thanks > > > > > >Sheref > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Connary, > > > > > > > > > > > > Julie > > > > > > Ann" To: ccielab@groupstudy.com > > > > > > > > > > > > <jconnary@cis cc: > > > > > > > > > > > > co.com> Subject: >summary-address > > > in > > > > > > ospf and redistribution > > > > > > Sent > > > > > > by: > > > > > > > > > > > > nobody@groups > > > > > > > > > > > > tudy.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 01/23/2001 > > > > > > > > > > > > 08:37 > > > > > > AM > > > > > > > > > > > > Please > > > > > > > > > > > > respond > > > > > > to > > > > > > > > > > > > "Connary, > > > > > > > > > > > > Julie > > > > > > Ann" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >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 > > > > > > > > > > > > > > > >----------------------------------------------------------------------- >- > > > > > >----------------------------------------------------------------------- >- > > > > > 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 > > > > > > > > > > >----------------------------------------------------------------------- >- > > > > > ---------------------------------------------------------------------- >-- > > > > 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 > > > > > > > > > ---------------------------------------------------------------------- >-- > > > **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:29:54 GMT-3