From: Hong Chan (howard.chan34@gmail.com)
Date: Mon Sep 22 2008 - 06:56:52 ART
Dear Bogdan,
Thanks your remind and I agree it's strange also.
Can you show the result of
show ip ospf database externa 158.1.0.0
on SW4? I wanna to know which router redistribute this route to SW4
Regards,
Howard
2008/9/22 Bogdan Sass <bogdan.sass@catc.ro>
> 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 & E0 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>
>
>> 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 is variably subnetted, 8 subnets, 3 masks
>> O 158.1.23.0/24 [110/2] via 158.1.34.1, 00:00:54, FastEthernet1/13
>> O E2 158.1.0.4/32 [110/20] via 158.1.34.1, 00:00:54, FastEthernet1/13
>> [110/20] via 158.1.1.1, 00:00:54, Vlan110
>> *O E2 158.1.0.0/24 [110/20] via 158.1.34.1, 00:00:54, FastEthernet1/13
>> [110/20] via 158.1.1.1, 00:00:54, Vlan110*
>> O 158.1.38.0/24 [110/3] via 158.1.34.1, 00:00:54, FastEthernet1/13
>> O 158.1.123.1/32 [110/1] via 158.1.1.1, 00:03:16, Vlan110
>> O 158.1.123.3/32 [110/65] via 158.1.1.1, 00:03:16, Vlan110
>> 150.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
>> O 150.1.3.3/32 [110/66] via 158.1.1.1, 00:03:16, Vlan110
>> O 150.1.1.1/32 [110/2] via 158.1.1.1, 00:03:16, Vlan110
>> O N2 150.1.9.0/24 [110/20] via 158.1.34.1, 00:00:54, FastEthernet1/13
>> O N2 150.1.8.0/24 [110/20] via 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) (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 (External Network Number )
>> Advertising Router: 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 (External Network Number )
>> Advertising Router: 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