advertising same network in different OSPF areas?

c.fuller · ‎11-11-2007

I need to share a network/subnet between my main data center and my DR site for a high availability requirement with our DHCP/DNS infrastructure. The data center and the DR locations are currently in a different OSPF area though. I have a few questions regarding this.

1) Is it possible to advertise the same subnet in two different OSPF areas? if so, what are the implications of doing this?

2) If not, does anyone have any thoughts on how this can be accomplished without getting too messy. I'd prefer to avoid assymetric routing and also having to keep the DR site interfaces shutdown.

Any input is appreciated...

paul.matthews · ‎11-12-2007

What do you want to happen with traffic? How is the lan made up? Is it one lan that is joined up behind the routing, or is it two instances of the same LAN where you want to use the first LAN, but switch over to the second. Do you want failover to be automated or do you want to manually switch over?

It is possible to do it, but without care it would be easy to get traffic from different sources going different ways to it. You also need to think about return traffic.

If I absolutely *had* to share a single lan I would put them into the same area (I would create a small area JUST for this subnet and its links to the backbone, and use cost to influence which way traffic went both in and out.

If it was intended to be a failover, with no link joining, then it depends greatly upon how the failover is meant to happen.

Paul.

c.fuller · ‎11-12-2007

Paul - Basically I will have two DNS masters in a active/standby HA setup. The one in the main datacenter will be the active one. The one in the DR site standby. They need to be on the same subnet. In the event of a main data center failure I would like the standby to handle DNS functionality. Optimally, I would like this to happen dynamically. But because the data center and the DR site exist in different OSPF areas it get's tricky. I know I can cost certain links to avoid asymetric routing. I just don't know if advertising the same subnet in two different areas is "legal". The other option is to keep DR site interfaces shutdown and manually enable upon a failure. Rather avoid that if possible. Thanks for your reply.

Kevin Dorrell · ‎11-12-2007

Advertising the same subnet from two different areas is not a normal legal architecture. Each ABR will be advertising the same prefix into the backbone, each independently of the other.

The backbone would not know which to believe, and in fact would believe they were one and the same network. (Once the Type-3 gets into the backbone, it knows nothing of the originating area, it just knows which ABR originated it.) It would then be a race for which has the best metric, with unpredictable results.

If they really have to be in the same subnet, that does not sound like a very resilient architecture. In that case, really you are constrained to a layer-2 solution.

Kevin Dorrell

Luxembourg

paul.matthews · ‎11-12-2007

"Be on the same subnet" is vague phrasing - is this one actual subnet - ie will a L2 broadcast from one be seen at the other?

If they are one logical subnet, with the two areas being different routes to the same subnet, you may get it to work, care will be needed to make sure the route you want is the preferred route though.

If they are two totally separate networks, you will need to make sure that the DR only gets advertised when the main site is down, and that will probably be manual.

P.

c.fuller · ‎11-12-2007

Yes, both physically on the same subnet (hearing each other's broadcast, same g/w's using HSRP, same subnet mask, etc, etc) . Metro fiber will be used to connect them directly together. If they were separate networks then this would not be a discussion as I would be advertising two different subnets each in a different OSPF area (non-issue). So I am hearing that it is possible to advertise the same subnet from two different areas, but it is not recommended because of unpredictable behavior. Thanks for the input.