From: Bogdan Sass (bogdan.sass@catc.ro)
Date: Mon Sep 22 2008 - 06:34:41 ART
Hong Chan wrote:
> area 38 nssa no-redistribution no-summary only block the route which
> are going to redistribute on that router but won't block the external
> routes which are redistributed by other routers.
> http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfospf.html#wp1017551
> Used when the router is an NSSA Area Border Router (ABR) and you want
> the *redistribute* command to import routes only into the normal
> areas, but not into the NSSA area.
Yes - and according to that documentation, the "no-redistribution"
option should block the 158.1.0.0/24 route (redistributed by R3) from
going into the NSSA.
However, you can see that the router at the other end (SW4) does
actuallly learn that route (158.1.0.0/24) through the NSSA. And I cannot
imagine why that happens, and how I could prevent it.
>
> The subnets on R3, such as lo0 150.1.3.3/32 <http://150.1.3.3/32> & E0
> 158.1.38.3/24 <http://158.1.38.3/24>, are not redistributed into NSSA
> already. only the external route from R1 are learned from NSSA. But I
> have a question about your lab. Why such external routes are learned
> from NSSA(inter area) rather than area 0 (intra area)??
Actually, since the routes are external, it doesn't really matter if
they are intra- or inter-area (they do not belong to a particular area).
The problem is that they are somehow being learned across the NSSA, and
I do not know why.
This happened to me on "real" routers and switches (during a rack
rental), and I also managed to reproduce it on dynamips. So it seems to
be normal behaviour, not related to a particular IOS version or hardware
type.
If anyone can shed some light on this, I would be very grateful!
-- Bogdan Sass CCAI,CCNP,CCSP,JNCIA-ER Information Systems Security Professional "Curiosity was framed - ignorance killed the cat"> 2008/9/22 Bogdan Sass <bogdan.sass@catc.ro <mailto:bogdan.sass@catc.ro>> > > I came across this problem while doing one of the IE labs. > > I have 2 routers (R3 and SW4), connected over two paths. One of the > paths is R3-R1-SW4, running OSPF area 0, while the other is > R3-SW2-SW3-SW4, running OSPF area 38. Area 38 is configured as totally > NSSA no-redistribute, on both endpoints (R3 and SW4). > > The problem: routes that are being redistributed by R3 show up with > two next hops in SW4's routing table. One path goes through area 0, > while the other goes through area 38 (creating a routing loop in the > process, because devices in area 38 have a default route pointing back > to SW4). > > Rack1SW4#sh ip ro ospf > 158.1.0.0/16 <http://158.1.0.0/16> is variably subnetted, 8 > subnets, 3 masks > O 158.1.23.0/24 <http://158.1.23.0/24> [110/2] via > 158.1.34.1 <http://158.1.34.1/>, 00:00:54, FastEthernet1/13 > O E2 158.1.0.4/32 <http://158.1.0.4/32> [110/20] via 158.1.34.1 > <http://158.1.34.1/>, 00:00:54, FastEthernet1/13 > [110/20] via 158.1.1.1 <http://158.1.1.1/>, > 00:00:54, Vlan110 > *O E2 158.1.0.0/24 <http://158.1.0.0/24> [110/20] via > 158.1.34.1 <http://158.1.34.1/>, 00:00:54, FastEthernet1/13 > [110/20] via 158.1.1.1 <http://158.1.1.1/>, > 00:00:54, Vlan110* > O 158.1.38.0/24 <http://158.1.38.0/24> [110/3] via > 158.1.34.1 <http://158.1.34.1/>, 00:00:54, FastEthernet1/13 > O 158.1.123.1/32 <http://158.1.123.1/32> [110/1] via > 158.1.1.1 <http://158.1.1.1/>, 00:03:16, Vlan110 > O 158.1.123.3/32 <http://158.1.123.3/32> [110/65] via > 158.1.1.1 <http://158.1.1.1/>, 00:03:16, Vlan110 > 150.1.0.0/16 <http://150.1.0.0/16> is variably subnetted, 5 > subnets, 2 masks > O 150.1.3.3/32 <http://150.1.3.3/32> [110/66] via 158.1.1.1 > <http://158.1.1.1/>, 00:03:16, Vlan110 > O 150.1.1.1/32 <http://150.1.1.1/32> [110/2] via 158.1.1.1 > <http://158.1.1.1/>, 00:03:16, Vlan110 > O N2 150.1.9.0/24 <http://150.1.9.0/24> [110/20] via 158.1.34.1 > <http://158.1.34.1/>, 00:00:54, FastEthernet1/13 > O N2 150.1.8.0/24 <http://150.1.8.0/24> [110/20] via 158.1.34.1 > <http://158.1.34.1/>, 00:00:51, FastEthernet1/13 > > As far as I understand NSSAs, this shouldn't happen - the > "no-redistribute" keyword on R3 should prevent the redistributed > routes > from being sent into area 38 as Type-7 LSAs. And a look at the OSPF > database from that area confirms the fact that they actually do not > enter area 38: > > Rack1SW4#sh ip ospf data nssa-ex > > OSPF Router with ID (150.1.10.10 <http://150.1.10.10/>) > (Process ID 1) > > Type-7 AS External Link States (Area 38) > > Routing Bit Set on this LSA > LS Type: AS External Link > Link State ID: 150.1.8.0 <http://150.1.8.0/> (External Network > Number ) > Advertising Router: 150.1.8.8 <http://150.1.8.8/> > Network Mask: /24 > > Routing Bit Set on this LSA > LS Type: AS External Link > Link State ID: 150.1.9.0 <http://150.1.9.0/> (External Network > Number ) > Advertising Router: 150.1.9.9 <http://150.1.9.9/> > Network Mask: /24 > > The only two type 7 LSAs in the area are the two loopbacks > redistributed on SW2 and SW3. > > However, somehow the updates from R3 make their way to SW4 through > area 38. > > Does anybody know why this is happening, and how I could prevent > it? ( I have added all the relevant configs at the end of this > message) > > Thank you, > > -- > Bogdan Sass > CCAI,CCNP,CCSP,JNCIA-ER > Information Systems Security Professional > "Curiosity was framed - ignorance killed the cat"
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sat Oct 04 2008 - 09:26:19 ART