From: Mas Kato (tealp729@xxxxxxxx)
Date: Tue Apr 24 2001 - 15:40:55 GMT-3
Okay, I'll drop the oddball scenario. The fact remains that the
link-state databases are supposed to remain synchronized throughout an
area--all of the OSPF routers have to have the same view of the area to
start their SPF calculations with. It would be remarkable if the
'not-advertise' option of the 'summary-address' command broke this rule.
And just because an LSA exists in the database doesn't mean a route
derived from it automatically makes it into the routing table. It may
not be the best route. Or maybe some other criteria... perhaps a
'not-advertise' flag.
-----Original Message-----
From: Curtis Call [mailto:curtiscall@home.com]
Sent: Tuesday, April 24, 2001 7:55 AM
To: Mas Kato
Cc: ccielab@groupstudy.com
Subject: RE: Re: summary-address in ospf and redistribution
It's true that Type 5's have an External Route Tag, but Cisco has no way
to
use that to prevent other router's from injecting that route into their
table. There are no options that would do this either. All I'm saying
is
that there is no reason to try to think up scenarios where you would be
asked to do this, because with OSPF it simply isn't possible.
At 01:56 AM 4/24/01, you wrote:
>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:55 GMT-3