From: Curtis Call (curtiscall@xxxxxxxx)
Date: Tue Apr 24 2001 - 11:54:46 GMT-3
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:54 GMT-3