Redundant Datacenter Connectivity

Datacenter Connectivity

Goals

• Create redundant datacenters. For now, 2 of them.
• Redundant, diverse, physical circuits/paths
• Allow simple movement of services between datacenters => support the same IP address ranges in either location

An example:  http://connect.iltanet.org/ILTANET/Go.aspx?c=BlogViewer&BlogKey=d671b21d-b20a-4b07-84d5-3d4357723f0a

Issues/Discussion Items
Layer 2
to allow the same IP address ranges

• Circuits are different vendors taking very different paths with unknown infrastructure in between the datacenters. A failure could occur within the service provider, but all my ports show "up." 
• So, Spanning Tree and Port Channels will not work for "in between" failures
• UDLD, Unidirectional Link Detection, doesn't seem work on a "virtual circuit" over a provider network like Metro Ethernet.
• Cisco's OTV is supposed to accomplish a big part of this, but it seems that a much less overblown solution could at least provide the Layer 2 redundancy.

Routing Redundancy

• For routing to work, the (outbound)default route must be configured to go out through the same datacenter where the inbound traffic will be arriving. 
• So any kind of automatic redundancy that fails the inbound route to the secondary datacenter needs to also initiate a change to the default route of all machines in the "shared" networks.
• A compromise would be a "one button push" method to switch inbound and outbound routing to change between datacenters.
• Does OTV address this?

Nuts & Bolts

• A traditional solution would possibly involve 2 circuits each with a router at each end.  L3 redundancy between the 2 links using HSRP/GLBP, some kind of IP tracking to expose a service provider outage, and somehow create L2 tunnels over each one and use them via a port aggregation at the core switch.  The question remains whether this solution can be designed to show a link as down even if the failure is in between.
• There seems to be little in the way of configuration help or reference material for GRE/MGRE tunnels.  Even less for L2 tunneling.  I suppose the motivation for helping users do that is even less now that there is a nebulous thing called OTV that involves a big spend on monster Nexus 7K core switches.
• I haven't been able to get into the guts of this and do any testing.  Thinking it through on paper I always get bogged down with the L2 tunnel.  A possible example L2TP configuration is:

Router A:

pseudowire-class test
encapsulation l2tpv3
protocol none
ip local interface Loopback0
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/1
description LAN
no ip address
speed 100
full-duplex
xconnect 2.2.2.2 1 encapsulation l2tpv3 manual pw-class test
l2tp id 1 2


Router B:

pseudowire-class test
encapsulation l2tpv3
protocol none
ip local interface Loopback0
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!interface FastEthernet0/1
no ip address
duplex auto
speed auto
xconnect 1.1.1.1 1 encapsulation l2tpv3 manual pw-class test
l2tp id 2 1