Re: OSPF NSSA problems

From: Hong Chan (howard.chan34@gmail.com)
Date: Thu Sep 25 2008 - 01:17:51 ART


I guess the forward address = 0.0.0.0 cause this. The forward address SW4
looking for the external route is 0.0.0.0, so it forward the traffic base on
the default route.

Please try:
1: Disable the default route in area 0, then see what will happen

2: add a static route on R3 and redistribute it into ospf. Then check the
ospf database in SW4 to find out the forward address and see how will the
routing go on.

Regards,
Howard

2008/9/25 Bogdan Sass <bogdan.sass@catc.ro>

> Hong Chan wrote:
>
> I have no idea what make this happen.........but I want to have more info
> about this lab because I want to know why also
>
> OK, here it goes. Sorry about the delay!
>
> 1: debug ip ospf lsa-gen on R3
> Just make sure the "no-redistribute" in nssa is working
>
>
> Here it is. As expected, R3 withdraws the type-5 LSA when the link is
> shut down, and generates it again when the link comes back up. No type-7
> LSAs are generated.
>
> Rack1R3(config)#int s1/0
> Rack1R3(config-if)#sh
> *Mar 1 00:02:36.839: %LINK-5-CHANGED: Interface Serial1/0, changed state
> to administratively down
> *Mar 1 00:02:36.843: %LINK-3-UPDOWN: Interface Virtual-Access1, changed
> state to down
> *Mar 1 00:02:36.851: %LINK-3-UPDOWN: Interface Virtual-Access2, changed
> state to down
> *Mar 1 00:02:36.963: OSPF: Generate external LSA 158.1.0.0, mask
> 255.255.255.0, type 5, age 3600, metric 16777215, tag 0, metric-type 2,
> seq 0x80000002
> *Mar 1 00:02:36.971: OSPF: Generate external LSA 158.1.0.4, mask
> 255.255.255.255, type 5, age 3600, metric 16777215, tag 0, metric-type 2,
> seq 0x80000002
>
> Rack1R3(config-if)#no sh
> *Mar 1 00:02:50.367: %LINK-3-UPDOWN: Interface Serial1/0, changed state to
> up
> *Mar 1 00:02:50.391: %LINK-3-UPDOWN: Interface Virtual-Access1, changed
> state to up
> *Mar 1 00:02:50.395: %LINK-3-UPDOWN: Interface Virtual-Access2, changed
> state to up
> Rack1R3(config-if)#
> *Mar 1 00:02:50.675: OSPF: Generate external LSA 158.1.0.4, mask
> 255.255.255.255, type 5, age 0, metric 20, tag 0, metric-type 2, seq
> 0x80000001
> *Mar 1 00:02:50.687: OSPF: Generate external LSA 158.1.0.0, mask
> 255.255.255.0, type 5, age 0, metric 20, tag 0, metric-type 2, seq
> 0x80000001
>
> 2: Provide more information between R3 & R1 (and R2 relationship), just
> for complete the story
>
> Tell me what info you need, and I will be glad to provide it :) . I
> have posted practically the entire config, so I do not know what else I
> could post...
>
> The topology looks something like this (I really hope my ASCII art makes
> it through :) )
>
> external net===R3--------R1-------SW4
> | |
> |----SW2-----SW3---|
>
> R3-SW2-SW3-SW4 is area 38 (totally NSSA), R3-R1-SW4 is area 0. The
> "external network" is 158.1.0.0/24, redistributed in OSPF by R3
> ("redistribute connected").
>
>
> 3: if there is no "redistribute route" in nssa, then it should be caused by
> the routing on SW4 look back to R3. I guess it maybe caused by the forward
> address = 0.0.0.0. Does there any default route in area 0 and area
> 38?(no-redistribute + no-summary should generate a default route into the
> NSSA area, correct me if I am wrong)
>
> I assumed the same thing (that the problem is caused by SW4 having two
> routes to the ASBR). However, notice that in the routing table of SW4 you
> only have one route to 150.1.3.3 (R3's RID).
> There is no default route in area 0, but there are default routes in
> area 38, injected by both ABRs (R3 and SW4).
>
>
> Thank you,
>
>
>
> --
> Bogdan Sass
> CCAI,CCNP,CCSP,JNCIA-ER
> Information Systems Security Professional
> "Curiosity was framed - ignorance killed the cat"
>
>
>
>
>
>
> 2008/9/23 Bogdan Sass <bogdan.sass@catc.ro>
>
>> Peter Wolter wrote:
>>
>>> 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
>>>
>>>
>> I already replied to this - but just in case the reply didn't make it,
>> here it is again:
>>
>> Of course - the subnet is redistributed by R3 (the router at the other
>> end of the two areas), using a "redistribute connected" statement (in the
>> original lab, the subnet was redistributed from EIGRP, with the same
>> result).
>>
>> /Rack1SW4#sh ip ospf data ex 158.1.0.0
>>
>> OSPF Router with ID (150.1.10.10) (Process ID 1)
>>
>> Type-5 AS External Link States
>>
>> Routing Bit Set on this LSA
>> LS age: 131
>> Options: (No TOS-capability, DC)
>> LS Type: AS External Link
>> Link State ID: 158.1.0.0 (External Network Number )
>> Advertising Router: 150.1.3.3
>> LS Seq Number: 80000001
>> Checksum: 0x5310
>> Length: 36
>> Network Mask: /24
>> Metric Type: 2 (Larger than any link state path)
>> TOS: 0
>> Metric: 20
>> Forward Address: 0.0.0.0
>> External Route Tag: 0/
>> The route is advertised by 150.1.3.3 (R3), with a forwarding address
>> of 0.0.0.0 .
>>
>> SW4 has only one routing table entry for 150.1.3.3 (as expected, it
>> only uses the intra-area route):
>> /
>> Rack1SW4#sh ip ro 150.1.3.3
>> Routing entry for 150.1.3.3/32
>> Known via "ospf 1", distance 110, metric 66, type intra area
>> Last update from 158.1.1.1 on Vlan110, 00:03:07 ago
>> Routing Descriptor Blocks:
>> * 158.1.1.1, from 150.1.3.3, 00:03:07 ago, via Vlan110
>> Route metric is 66, traffic share count is 1/
>>
>> However, it still installs two routes for the external address:
>>
>> /Rack1SW4#sh ip ro 158.1.0.0 255.255.255.0
>> Routing entry for 158.1.0.0/24
>> Known via "ospf 1", distance 110, metric 20, type extern 2, forward
>> metric 65
>> Last update from 158.1.1.1 on Vlan110, 00:05:03 ago
>> Routing Descriptor Blocks:
>> * 158.1.34.1, from 150.1.3.3, 00:05:03 ago, via FastEthernet1/13
>> Route metric is 20, traffic share count is 1
>> 158.1.1.1, from 150.1.3.3, 00:05:03 ago, via Vlan110
>> Route metric is 20, traffic share count is 1
>>
>> / If you need any additional details/output, please let me know (I
>> would also draw a diagram, but I really don't know how I could put this
>> topology in ASCII format :) ).
>>
>> Thank you for your help,
>>
>>
>>
>> --
>> 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
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html

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