From: Curtis Call (curtiscall@xxxxxxxx)
Date: Tue Apr 24 2001 - 23:28:39 GMT-3
After looking over the OSPF spec I can only come up with one theory about
why this is happening. When you look at the LSA in particular, is it's age
3600 by chance? I'm guessing that the router flushed the LSA 5 from the
database after being equipped with the "not-advertise" option and thereby
set the age to maxage and reflooded. It will stay in the database of the
other routers momentarily, then it will be dropped. Otherwise I have no
idea why this is happening and will have to try it out in the lab tomorrow.
>I don't have a way to test this at the moment, but I'm curious, when you
>look at the database using the extensive option, do the LSAs appear
>normal? I'm just trying to imagine how this is communicated via the
>LSA. How many routers were you using?
>
>At 07:37 PM 4/24/01, you 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