03-21-2012 06:05 PM
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.
03-21-2012 07:04 PM
03-21-2012 08:33 PM - edited 03-21-2012 09:17 PM
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.
03-21-2012 09:15 PM
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?
03-21-2012 09:26 PM - edited 03-21-2012 10:28 PM
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.
03-23-2012 05:15 AM
03-23-2012 11:35 AM
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
05-09-2012 12:32 PM
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.