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,