Screen OS

Hi, all, I am new to Netscreen OS, I am having an OSPF problem with Netscreen (ScreenOS 6.3), I have an existing hub site (called hub1) and a bunch of remote sites running p2mp OSPF over route-based VPN, p2mp interface is placed in normal area 100, all worked well. Now I am adding a new hub (called hub2), OSPF area 0 is running on a point2point tunnel interface between hub1 and hub2, hub2 advertes a summary network 10.128.0.0/16 from area 128, spoke is getting 10.128.0.0/16 from hub1 correctly. Now I am establing a new p2mp OSPF adjacency over route-based VPN from hub2 to spokes, OSPF area is set to 200 for the p2mp tunnel interface. As soon as OSPF adjacency comes up between the spoke and hub2, spoke immediately loses network to 10.128.0.0/16,

I see the summary LSA for 10.128.0.0/16 in area 200 database on the spoke, yet spoke does not install this route, why is that?

spoke#1-> get vrouter trust-vr pro ospf database summary link-state-id 10.128.0.0
VR: trust-vr RouterId: 10.122.65.1
----------------------------------

                        Summary LSA(s) for area 100
  Link-State-Id   Adv-Router-Id      Age  Sequence# CheckSum
--------------------------------------------------------------------------------
     10.128.0.0   66.94.142.130     1434 0x8000003b   0x3f73 <== This is from hub1


                        Summary LSA(s) for area 200
  Link-State-Id   Adv-Router-Id      Age  Sequence# CheckSum
--------------------------------------------------------------------------------
     10.128.0.0   10.128.255.18     1613 0x8000000b   0x9a65 <== this is from hub2

spoke#1-> get route ip 10.128.0.0
--------------------------------------------------------------------------------------
trust-vr       : => 10.0.0.0/8 (id=8) via 10.122.255.240 (vr: trust-vr) <== this is a supernet statically configured
 Dest for 10.128.0.0
                    Interface tunnel.10 , metric 1 

Relavent debug ospf route output for this specific prefix shows that this route was deleted by ospf,

## 2012-03-21 19:14:59 : ospf: delete route 10.128.0.0/16 next-hop 10.122.255.240 on tunnel.10 flag 0x24021100 area 0.0.0.0
## 2012-03-21 19:14:59 : ospf: delete route 10.128.0.0/16 -> 10.122.255.240, level 2, area 0.0.0.0 

tunnel.10 is from hub1,  since hub2 has better metric to 10.128.0.0/16, seems reasonable to me that OSPF deleted the route 10.128.0.0/16 with next hop tunnel.10, but ospf did not add route to the tunnel pointing to hub2.

Note that hub1 and hub2 are symetric, any inter-area routes advertised from hub1 are also gone when spoke's both OSPF adjacencies with hub1 and hub2 are up. When either tunnel to hub1 or hub2 is shut down, spoke will install the route correctly, so definately it is not because next-hop is not reachable, looks like when the firewall learns the same route from two different regular areas, then this route will be purged from routing table.

I did a simulation on Cisco IOS,  spoke installs this routes to hub2 correctly.

Configuration wise there is nothing special on all devices.

Did I do something terribly wrong?

Thanks,

Anybody has something to say? anything? 🙂

Hi,

I have seen simil;ar behavior earlier but never got a chance to get to the root of it.

Can you share the complete database output (of one branch and 2 hubs) and rough network diagram?

Thanks.

Hardeep

What specific types of LSAs will you need? both hubs and spoke have correct LSA database, both hubs installed correct route entries ... Could you please confirm whether ScreenOS will perform inter area SPF calculation if it has multiple areas but not an ABR? if this is a un-supported configuration, I wish ScreenOS would warn users. Please refer to the other thread "OSPF problem -- where is my route?" where I explained in more detail why I need this configuration to work.

Hi,

Please note, I am not an expert on routing and so you may want to double check the credibility of my analysis mentioned below. It is purely based on my interpretation of what I have read in last few days.


I tried to have better understanding of ABR route calculation and understood that an ABR will only process type3 LSAs from a backbone area.
Please refer the below link:
http://tools.ietf.org/html/draft-ietf-ospf-abr-alt-05

In your setup, the spokes act as ABR (because they have more than one areas) but they dont have link to Area0 (backbone area).
The reason it works after shutting down OSPF on hub2 is because then the spokes just have one active area and so are no longer an ABR and hence will process type3 LSAs from non-backbone areas as well.

So I dont think of this as a ScreenOS problem, but rather a design behavior of OSPF.
A workaround that I can think of is to create multiple virtual routers (one for each area on spoke)

Hope this helps.

Regards.
Hardeep

Hi, Thanks, I agree this is not a standard design but our specific scenario is unique (mostly due to P2MP OSPF), what harm would it cause if ScreenOS does SPF calculation of inter-area routes (like Cisco IOS will do) even if it is not an ABR?

I am reading VR documentation, seems that it is a work around for the problem I am having, so the idea would be redistribute spoke connected network to OSPF in existing area in default trust-vr, export this connected routes to new VR and on new VR redistribute this imported, connected network to OSPF, then again import OSPF routes from new VR to trust-vr? I am trying to set preference on the new VR such that imported connected route will be preferred over the external route learned from OSPF domain, seems that ScreenOS is ignoring my configuration, in the new VR's routing table, OSPF External route is still prefrred because imported connected route has default preference of 140.

Hi, guys, virtual router is the way to go, my problem is completely resolved! although I had to do a lot of extra configuration and spoke pratically now has to keep an extra copy of routing table, this solution is obviously better than changing the P2MP OSPF area to backbone area in which case we would need to take down all spokes.

I still wish ScreenOS had a knob such that it can still do SPF calculations when it is connected to two normal areas, in which case my configuration would be much simpler!

That was exactly what I did ... on the other hand, screenOS should not just ignore summary LSA processing when it has two areas but not an ABR, in stead it should pick one area, in doing so, at least network connectivity is maintained.

I'm not a fan of letting the firewalls pick anything. Asymmetric traffic is such a pain.