Routing for backup Internet service

[Mitchell Theriot]

I am working on a project were internet service will be added to a backup/DR data center to service users in case the internet service at the primary data center goes down.  The two data centers are connected through an ethernet service.  Currently the network default route points to the inside interface of the primary site firewall.  In the case that the Internet Circuit at the primary site fails, how can I configure the internal network so that the default route switches over to the inside interface of the firewall at the backup location without manual configuration.  I would assume I would need to do some sort of SLA monitoring on the firewalls (ASAs) to detect any outages on the circuit.  Can I add a backup default route to the layer 3 switches on the inside (Nexus 7K at primary site, 4500X at backup site) so that when the SLA monitor detects an outage the backup default route is inserted into the routing tables?

[Jon Marshall]

Amit

Scratch that question, it just doesn't make any sense.

I am not even going to look at that link yet. I have so many documents already in my list of things to read i can't afford to get sidetracked

Jon

[Mitchell Theriot]

Thanks for the responses.  I am still gathering information on this as well.  The interconnect between the two sites does use L3 SVI's.  The plan in the future is to run OTV between the two to strech the L2 domains. A route map is already in place to redistribute certain static routes to the backup site. 

[Jon Marshall]

Mitchell

No problem.

If you want to use the proposed solution in the meantime just let me but if you are going to be using OTV i suspect you might need a different solution. The solution i propose would work if the N7k and 4500X were peering with EIGRP and for any interconnect traffic the first device they get to is either the N7k or te 4500X.

Amit may be able to help with that as i have no experience of using OTV.

Jon

[Amit Singh]

Having OTV between the sites does not change much from the overall L3 routing toplogy. The only thing that OTV will bring in this architecture is a bit complexity :-). Not that much but your stretched L2 vlans across site will have to be designed for a proper Egress routing. Either you would end up bringing all the traffic back to main DC and then route it out to the outside world or to some HSRP filtering and let the extended vlans take an egress path from the DR site.

If you are using some L3 BGP peering on the WAN this would complicate the design as to from which site you would adverstise the IP subnet.

We will work with you when you get to that stage and i dont want to over say few thing about the future here. I would be more than happy to assit you with the design and Jon with the troubleshooting :-).

Hope this helps.

-amit singh

[Jon Marshall]

I would be more than happy to assit you with the design and Jon with the troubleshooting :-).

Volunteering my services now

Seriously, happy to help out any way i can.

Quick question Amit. I am, funnily enough, just reading a document on OTV.

Does OTV allow you to extend some vlans and route others ?

If so how is the join interface related to the actual physical links used to connect the DCs ie.

if the join interface terminates the actual physical link then what does it do with normal routed traffic as there is no need to encapsulate it.

Jon

[Amit Singh]

Hi Jon,

Yes, OTV allows you to extend Layer 2 vlans to the remote site. That being said, OTV is typically used as an appliance model design. You stick either OTV VDC on N7K or just Cisco ASR1000 as the dedicated appliance. On N7K, the restriction is that you cannot have the OTV in the same VDC as the SVI hosted for your Vlan traffic. So you stretch your L2 trunks to OTV internal-ports and exit the extended Vlan traffic out of the "Join-Interface" which an L3 port connected back to your routed core network.

OTV join-interface encapsulates (MAC in IP) the MAC's to be forwarded to the other side and forwards it over the OTV overlay. The "join-interface" is just for the encapsulation, as long as its routed and reachable, you would be able to have a OTV tunnel established properly. In current designs on N7K, your join-interface can be a dedicated L3 routed port for Inter-DC connectivity or an L3 routed port connected back to the core router/VDC. Customer prefers the second option of having the join-interface connect back to the routed core just to save extra cost of deploying a dedicated L3 port.

The normal routed traffic is handled by the device hosting your SVI's. The traffic that needs to be routed goes stratight to your SVI/L3 gateway and exit out. The traffic that needs the L2 forwarding to the extended vlans,hits the OTV appliance internal interfaces, get encapsulated over the overlay and get to the remote side depending upon the OTV mac routes existance.

OTV can be deployed as Multicast model or Unicast model depending how the WAN core looks like related to multcast.

Hope this helps.

Cheers,

-amit singh