From: Erick B. (erickbe@xxxxxxxxx)
Date: Wed Apr 25 2001 - 01:08:59 GMT-3
Okay. I was reading this as someone was trying to
filter out external routes from OSPF after
redistribution/summarization was done.
But... I need to play with the no-advertise option as
I haven't really used it much.
Erick
--- Mannan Venkatesan <venkat_m@ins.com> wrote:
> I may have to disagree with you. I just tested it
> again. 'not-advertise'
> option did the trick. All OSPF routers had this
> external route in their OSPF
> database, but not in their routing table. No
> filters, route-maps. When I
> remove the 'not-advertise' option and did 'cle ip
> ospf red', that external
> route appeared in all router's routing table.
>
> Even I tired to inject /24 IGRP routes into OSPF and
> did a /16 summarize.
> And I observed the same behavior with
> 'not-advertise' option.
>
> Mannan
>
> ----- Original Message -----
> From: "Erick B." <erickbe@yahoo.com>
> To: "Curtis Call" <curtiscall@home.com>; "Mas Kato"
> <tealp729@home.com>
> Cc: <ccielab@groupstudy.com>
> Sent: Tuesday, April 24, 2001 5:48 PM
> Subject: RE: Re: summary-address in ospf and
> redistribution
>
>
> > Curtis is right - There is no way to do a
> route-map to
> > match external routes and deny them from being put
> > into routing table. If you were redistributing
> into
> > OSPF then you have control when the routes go
> into/out
> > of the OSPF process.
> >
> > A workaround to deny external routes from OSPF
> would
> > be to configure another OSPF process and
> redistribute
> > the original OSPF routes into this process and
> only
> > permit internal routes, then allow these to be put
> > into routing table. I know it's not pretty but :)
> >
> > Erick
> >
> > --- Curtis Call <curtiscall@home.com> wrote:
> > > 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
> >
> >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:29:55 GMT-3