Screen OS

I have the following topology in my lab:

3 Devices: A, B, C

Device A:
eth0/0 is in area 0 -> trust interface 10.101.1.0/24
tunnel.1 is in area 1
tunnel.2 is in area 2

Device B:
tunnel.1 is in area 1
tunnel.2 is in area 2

Device C:
tunnel.1 is in area 1
tunnel.2 is in area 2

As long as I have ospf disabled on tunnel.2 on device B and C I have the route 10.101.1.0/24 learned from OSPF.

When I enable OSPF on tunnel.2 the route is gone, but why?

Hi,

'

Can you show some ospf status output in both situations?

 

like:

 

get vr trust-vr protocol ospf config

get vr trust-vr protocol ospf neigbor

get vr trust-vr protocol ospf database

 

That might give clues.

 

Hi Screenie,

 

thanks for your help. Please see the lab diagram in the attached jpg file.

 

I have also uploaded the output of the commands when ospf is enabled on all two tunnel interfaces.

 

As soon as I disable ospf on any of the tunnel interfaces I see the expected route from area 0.

 

OSPF on tunnel.2 disabled

 

#get vr trust-vr protocol ospf config
B-> get vr trust-vr protocol ospf config
VR: trust-vr RouterId: 172.20.2.1
----------------------------------
set protocol ospf
set enable
set area 0.0.0.1
set area 0.0.0.2
exit
set interface tunnel.1 protocol ospf area 0.0.0.1
set interface tunnel.1 protocol ospf link-type p2mp
set interface tunnel.1 protocol ospf enable
set interface tunnel.1 protocol ospf cost 40
set interface tunnel.2 protocol ospf area 0.0.0.2
set interface tunnel.2 protocol ospf link-type p2mp
set interface tunnel.2 protocol ospf cost 10


#get vr trust-vr protocol ospf neighbo
B-> get vr trust-vr protocol ospf neighbo
VR: trust-vr RouterId: 172.20.2.1
----------------------------------
                Neighbor(s) on interface tunnel.1 (Area 0.0.0.1)
IpAddr/IfIndex  RouterId        Pri State    Opt  Up           StateChg
------------------------------------------------------------------------------
10.50.1.3       172.20.3.1        1 Full     E    00:14:19     (+6 -0)
10.50.1.1       172.20.1.1        1 Full     E    00:38:14     (+6 -0)
10.50.1.4       127.0.0.4         1 Full     E    00:56:14     (+6 -0)


#get vr trust-vr protocol ospf database
B-> get vr trust-vr protocol ospf database
VR: trust-vr RouterId: 172.20.2.1
----------------------------------

                        Router LSA(s) for area 0.0.0.1
  Link-State-Id   Adv-Router-Id      Age  Sequence# CheckSum
--------------------------------------------------------------------------------
      127.0.0.4       127.0.0.4      786 0x80000008   0x45ec
     172.20.1.1      172.20.1.1      792 0x80000006   0xc23d
     172.20.2.1      172.20.2.1      202 0x8000000b   0x 8ee
     172.20.3.1      172.20.3.1      781 0x80000005   0x787e

                        Summary LSA(s) for area 0.0.0.1
  Link-State-Id   Adv-Router-Id      Age  Sequence# CheckSum
--------------------------------------------------------------------------------
      10.50.2.1      172.20.1.1      201 0x80000004   0xc671
      10.50.2.1      172.20.3.1      787 0x80000001   0x230c
      10.50.2.3      172.20.1.1      201 0x80000002   0x1b13
      10.50.2.3      172.20.3.1      793 0x80000003   0xa68e
     10.101.1.0      172.20.1.1      201 0x80000004   0x7f86

 

 

OSPF on tunnel.1 disabled

 

get vr trust-vr protocol ospf config
B-> get vr trust-vr protocol ospf config
VR: trust-vr RouterId: 172.20.2.1
----------------------------------
set protocol ospf
set enable
set area 0.0.0.1
set area 0.0.0.2
exit
set interface tunnel.1 protocol ospf area 0.0.0.1
set interface tunnel.1 protocol ospf link-type p2mp
set interface tunnel.1 protocol ospf cost 40
set interface tunnel.2 protocol ospf area 0.0.0.2
set interface tunnel.2 protocol ospf link-type p2mp
set interface tunnel.2 protocol ospf enable
set interface tunnel.2 protocol ospf cost 10

#get vr trust-vr protocol ospf neighbo
B-> get vr trust-vr protocol ospf neighbo
VR: trust-vr RouterId: 172.20.2.1
----------------------------------
                Neighbor(s) on interface tunnel.1 (Area 0.0.0.1)

                Neighbor(s) on interface tunnel.2 (Area 0.0.0.2)
IpAddr/IfIndex  RouterId        Pri State    Opt  Up           StateChg
------------------------------------------------------------------------------
10.50.2.3       172.20.3.1        1 Full     E    00:00:55     (+6 -0)
10.50.2.1       172.20.1.1        1 Full     E    00:00:56     (+6 -0)

#get vr trust-vr protocol ospf database
B-> get vr trust-vr protocol ospf database
VR: trust-vr RouterId: 172.20.2.1
----------------------------------

                        Router LSA(s) for area 0.0.0.2
  Link-State-Id   Adv-Router-Id      Age  Sequence# CheckSum
--------------------------------------------------------------------------------
     172.20.1.1      172.20.1.1       89 0x80000008   0xcb63
     172.20.2.1      172.20.2.1       81 0x80000002   0xeb46
     172.20.3.1      172.20.3.1       90 0x80000006   0x1613

                        Summary LSA(s) for area 0.0.0.2
  Link-State-Id   Adv-Router-Id      Age  Sequence# CheckSum
--------------------------------------------------------------------------------
      10.50.1.1      172.20.1.1       86 0x80000005   0xcf68
      10.50.1.1      172.20.3.1     1212 0x80000001   0x5bb6
      10.50.1.3      172.20.1.1       86 0x80000003   0x51be
      10.50.1.3      172.20.3.1     1217 0x80000003   0xb184
      10.50.1.4      172.20.1.1       86 0x80000005   0x43c9
      10.50.1.4      172.20.3.1     1207 0x80000002   0x3bd2
     10.101.1.0      172.20.1.1       86 0x80000005   0x7d87

 

Maybe you can point out what's wrong.

 

 

 

Hi Hagbard,

 

I think I see what's going on. When you design a ospf network with multiple area's every area must have a connection to the backbone, area 0. It seems to me you only configured none backbone area's. As soon a you enable another area on the same ssg it does know how to calaculate the spf because the backbone is missing. Given the relative low numbers of devices in the network my advise would be to use a one area (0 of course) design. If you have other consideration make sure there also is a backbone area, where every other area at least has one connection to. (So the ethernet interfaces in the central site could be your area 0).

 

 

Sorry, I reread your post and saw you want you trust interface in area 0. But I don't see this in the configs. Forgot to enable ospf on the interface maybe? If you dont want it to for adjancies on the lan you could make it passive. It's route will be in the the ospf table then, but no adjancies will be formed.

I enabled OSPF on the trust interface on my main site (A). So in my opinion all devices have a connection to area 0 via the main site.

 

What I don't understand is why I cant see the route 10.101.1.0/24 for example on device B (it is in the database).

 

In my lab I have a small number of devices. However I plan to migrate from static routing to OSPF in an environment with 30+ sites.

 

I will configure the passive option on the trust int of the main site (A) since I don't need adjacensies there.

 

 

Ok, the A device isn't in the config output, That's the one with the backbone connection I presume.

 

Then why are there two area's on the other device? When you only need to make vpn's to a remote network without any other ospf routers setting up a complex area structure isn't neccesary. The trick with multiple area's is the so sumarize area routes at the router to the backboe (ABR). This reduces the total number of routes in database. When you only have one network to reach behind a vpn You're only converting the LSA type from 2 to 3  (I think) but keep the same database sizes.

All tunnel.1 interfaces are used for a full mesh VPN over internet.

 

All tunnel.2 interfaces are used for a full mesh VPN over MPLS.

 

I thought it is a good idea to separate these in two areas since the MPLS network has really nothing to do with the internet.

 

One area makes the configuration easier - maybe I will use it in production - however currently I don't see too much complexity in using three areas (which makes sense - regarding the structure).

 

The strange thing for me is still why this doesn't work... Meanwhile I have configured the trust interface passive.

 

I also attached the configuration of the A device. -> Maybe I just forgot something to configure

 

 

 

 

 

 

 

 

 

I've now bound all tunnel interfaces to the same area. This works well.

 

Issue seems resolved.

 

Thanks Screenie for your support.

 

You're wellcome!

Sorry to revive this thread, this is exactly what happened in my situation (see the thread I recently initiated), I agree that for a non-ABR router that in regular area it is simpler to debug when there is only one area configured. But there is situation in production network that a spoke site has to be in multiple regular areas. Here is my situation, we have an exsiting P2MP OSPF over tunnel interfaces network, all spoke sites are in the same area, only spoke-hub traffic is allowed. Now we need to add redundancy to the network, such that when one hub goes away, we can still have connection to all spokes, if I simply configure a new P2MP OSPF network and put the new network in the same area, it won't work,  as soon as the first spoke site is on both networks, traffic from the new hub to other spokes will break, because the new hub will always prefer intra area routes. So I will need to put the new P2MP OSPF network in a different area and advertise networks behind each spoke as external routes such that I can bring up the redudant VPN to each spoke one bye one without breaking exsiting connectivity.

 

In the case, both regular areas have connection to area 0 which exists on both hubs, not sure why in this case SSG will stop calculating inter-area routes.

What i suspect is:-

The issue is due to Auto Virtual link configuration enabled on the
firewall which voids the functionality of the device connected to Area 0
to act as a ABR due to which the routes would be present in the routing
table but would not be imported. Also due to the configuration a virtual
circuit would be created to connect to Area 0 even with the Area X (x=non zero area) having
access to Area 0.

A Brief Note on Virtual Circuits:

A virtual circuit is a configuration for which a Area which does not have
direct link to Area 0 uses a transit link to establish connectivity as in
a OSPF design all Area's should have connectivity to the Backbone Area
i.e. Area 0.

So to disable, kindly remove the following configuration below and clear
the SA's to restart the VPN's this would help import the routes into the
routing table correctly.

> unset vr <VR> proto ospf auto-vlink

After the above operation, the failovers would import the routes into the
routing table correct no manual intervention would be required.

We use iBGP and route reflectors for a similar setup

Could you please elaborate on what you mean when you say traffic from new hub to spokes will break? I've come across dual-hub-and-spoke network running single-area (0) OSPF, and it works quite alright provided that costs are configured carefully.

Very good question! imagine that hub1 and hub2 has high bandwidth connection in area 0, when hub2 with the first spoke's VPN comes up, hub2 will use intra route to reach other spoke sites with next hop being the first spoke,  traffic from hub2 (originated from another regular area) to other spokes will need to traverse Internet 3 times (to spoke1, to hub1 and then to spoke2), when return traffic hits hub1, hub1 will use the backbone connection to hub2, this is un-symetric routing right there, more over, policy will need to be modified to allow traffic initiated from VPN zone to the zone between hub1 and hub2, our exsiting application only requries connection initiated from the hub. Anyhow, theoretically this should still work, but in reality, it did not ... plus, with this kind of configuration, any spoke drops one tunnel to either hub, that hub will have sub-optimal routing to this spoke.

 

Compared to if I can get two areas on spoke to work(At least it works on IOS), during first spoke transition, hub2 and other spokes can maintain the same routing/policy as before, and if either tunnel from the spoke is dropped, optimal routing from hubs is maintained. (note that I redistribute connected routes on spokes), hub will never use intra-area to reach this spoke.

 

I can certainly put all links in area 0 to solve the problem because the routing will be purely based on metric, but I am not sure this is a good solution in our case.

Well, hold on a second ... If you have hub1-spoke links in area 100, and you're forced to have hub2-spoke links in area 100 (since you mentioned in your other thread that if you put hub2-spoke links into different area, the firewalls don't install routes), then why not keep your hub1-hub2 link into area 100, too???

 

Also, a little besides the point, but if you build hub2 for redundancy, would hub2 be connected to all spokes hub1 is?

 

I understand that multiple areas make things look neater, but I wonder ... at what point does that justify the added complexity?

Thanks for your quick reply, maybe I did not explain clearly in the other thread, I wanted to put hub2-spoke links into different area in order for me to have a transparent migration to due-hub topology, I could not do so becase spoke immediate stopped install inter-area routes once the adjacency to hub2 comes up -- this is the very problem I want to get help with.

 

Yes, hub2 will be connected to all spokes hub1 is. I can not put inter-hub link to regular area, because I need full-mesh backbone connections among hubs and major offices, each hub and major offices have multiple networks in regular areas, if I move inter-hub link to area 100, then routing between networks behind two hubs will be sub-optimal.

 

Running spoke tunnels in area 0 can potentially turn spokes to be transit, which we don't want. I guess our requirement is unique, the spokes are in remote DCs across the global, we use the VPN to remote-manage hosts from two hub sites.

I wonder ... What would happen if you enable ECMP on the spokes? Would both routes from the OSPF database(s) get installed in the routing table? ...

Checked, ECMP with maximum paths of 4 is enabled by default.

How about, as a workaround, we create another VR at the spoke, and place the connection with the 2nd hub in there, then use route maps to control exactly what routes the two VRs exchange?

Hi,

 

Trying 2 virtual routers (one for each area) can be tried.

Reason being an ABR can only process type3 LSAs from backboe areas.

Details mentioned in another thread

 

http://forums.juniper.net/t5/ScreenOS-Firewalls-NOT-SRX/ScreenOS-not-install-inter-area-routes-if-summary-LSAs-are/m-p/134821/highlight/false#M20928

 

 

Thanks.

Hardeep