From: Mannan Venkatesan (venkat_m@xxxxxxx)
Date: Tue Apr 24 2001 - 23:50:21 GMT-3
I used 4 routers.
10.2/16 10.1/16 11.1.1/24 11.1.2/24
-----------r1------------r2--------------r3------------r4----
I I/O Area 0 O Area 1 O
Here are the r2 config, IP routing table and OSPF database of r3 with and
without 'not-advertise'.
r2#
!
hostname r2
!
!
!
interface Loopback2
ip address 11.2.1.1 255.255.0.0
!
interface Ethernet0
no ip address
shutdown
!
interface Serial0
no ip address
encapsulation frame-relay
!
interface Serial0.1 point-to-point
ip address 10.1.1.2 255.255.0.0
frame-relay interface-dlci 101
!
interface Serial0.2 point-to-point
ip address 11.1.1.1 255.255.255.0
frame-relay interface-dlci 103
!
interface Serial1
no ip address
shutdown
!
interface BRI0
no ip address
shutdown
!
router ospf 10
summary-address 11.1.0.0 255.255.0.0
summary-address 10.0.0.0 255.0.0.0
redistribute igrp 10 subnets
network 11.1.1.0 0.0.0.255 area 0
!
router igrp 10
redistribute ospf 10 metric 1000 100 255 1 1500
network 10.0.0.0
network 11.0.0.0
!
no ip classless
!
!
line con 0
line aux 0
line vty 0 4
login
!
end
With 'not-adverise'
--------------------------
r3#sh ip ospf dat
OSPF Router with ID (11.1.2.1) (Process ID 10)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
11.1.1.1 11.1.1.1 837 0x80000005 0x2830 2
11.1.2.1 11.1.2.1 903 0x80000004 0x1A3E 2
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
11.1.2.0 11.1.2.1 885 0x80000002 0xC61B
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
11.1.2.1 11.1.2.1 885 0x80000005 0xF066 2
11.1.2.2 11.1.2.2 778 0x80000003 0xE572 2
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
11.1.1.0 11.1.2.1 886 0x80000002 0xE3FB
Summary ASB Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
11.1.1.1 11.1.2.1 887 0x80000002 0xCB12
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
10.0.0.0 11.1.1.1 64 0x80000005 0x9880 0
11.1.0.0 11.1.1.1 64 0x80000007 0x7B99 0
11.2.0.0 11.1.1.1 176 0x80000003 0xC3BF 0
r3#sh ip rou
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate
default
U - per-user static route, o - ODR
Gateway of last resort is not set
O E2 10.0.0.0/8 [110/20] via 11.1.1.1, 00:00:00, Serial0.1
11.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
C 11.1.2.0/30 is directly connected, Serial0.2
O E2 11.2.0.0/16 [110/20] via 11.1.1.1, 00:00:00, Serial0.1
C 11.1.1.0/24 is directly connected, Serial0.1
r3#
Without 'not-adverise'
-------------------------
r3#
r3#
r3#sh ip ospf dat
OSPF Router with ID (11.1.2.1) (Process ID 10)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
11.1.1.1 11.1.1.1 122 0x80000008 0x2233 2
11.1.2.1 11.1.2.1 66 0x80000007 0x1441 2
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
11.1.2.0 11.1.2.1 48 0x80000005 0xC01E
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
11.1.2.1 11.1.2.1 48 0x80000008 0xEA69 2
11.1.2.2 11.1.2.2 1741 0x80000005 0xE174 2
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
11.1.1.0 11.1.2.1 48 0x80000005 0xDDFE
Summary ASB Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
11.1.1.1 11.1.2.1 50 0x80000005 0xC515
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
10.0.0.0 11.1.1.1 62 0x80000001 0xEC9B 0
11.1.0.0 11.1.1.1 62 0x80000001 0xD3B2 0
11.2.0.0 11.1.1.1 62 0x80000001 0xC7BD 0
r3#sh ip rou
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate
default
U - per-user static route, o - ODR
Gateway of last resort is not set
O E2 10.0.0.0/8 [110/20] via 11.1.1.1, 00:01:55, Serial0.1
11.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
C 11.1.2.0/30 is directly connected, Serial0.2
O E2 11.2.0.0/16 [110/20] via 11.1.1.1, 00:01:55, Serial0.1
O E2 11.1.0.0/16 [110/20] via 11.1.1.1, 00:01:55, Serial0.1
C 11.1.1.0/24 is directly connected, Serial0.1
----- Original Message -----
From: "Curtis Call" <curtiscall@home.com>
To: "Mannan Venkatesan" <venkat_m@ins.com>
Cc: <ccielab@groupstudy.com>
Sent: Tuesday, April 24, 2001 9:55 PM
Subject: Re: Re: summary-address in ospf and redistribution
> 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