10

We have two geographically separate data centers. We are preparing to implement a new WAN connection (dark cloud) that would be used only for backup traffic. The servers will have two NIC cards (production & backup) but what is the best way to ensure that the production and backup traffic doesn't mix? At the moment we are just using static routes to get to the WAN, but looking to implement BGP between our SP and ourselves. Internal RP is a mix of EIGRP and OSPF. Cores are Cisco 6500s and WAN routers will soon be upgraded to ASRs.

Suggestions on solutions? Policy-based routing (PBR)? VRFs?

Network Diagram

  • Without knowing more details, I don't see how mixing backup traffic across the main link between DCs and vice versa is an issue? Assuming the main server LAN and their backup traffic LAN are different subnets, then they can be advertised across your two inter-DC links with different route metrics. I don't see how you can be accidentally mixing them up? You can use VRFs and VLANs, but this seems over complex when you can just change the route metric. Am I missing something? – jwbensley May 9 '13 at 13:29
  • At the moment it is a business requirement that they remain separate. We must also ensure that backups do not fail-over or try and load-balance onto the production links. – Peter May 9 '13 at 16:04
  • Ah OK, well that still isn't too difficult using different route metrics and only advertising one path for each subnet to prevent the unwanted fail-over scenario. VRFs though now become a simple and strait forward solution here as ioshints mentions. – jwbensley May 9 '13 at 18:43
9

Assuming the two NICs on the servers are used to separate production and backup traffic, use VRFs. That's the best traffic separation technique there is. For more scalability (not sure you need it based on the diagram), throw full-blown MPLS/VPN in the mix, it runs on both Cat 6500 and ASRs.

  • Using two NICs does require the creation and maintenance of routing tables on the servers. Unless someone knows some tricks I don't? – Peter May 9 '13 at 20:20
  • Yes. You'd need to set up routes in the servers to point the backup subnets out of the backup interface. If this is too daunting a task then you could always do some interesting things with metrics. Assuming your backup servers are on their own subnet...but then again the MPLS solution assumes that too. If they aren't on their own subnet and you don't have a /32 for the backup servers then I think policy based routing might be your only option. – bigmstone May 11 '13 at 14:16
  • Where there's will, there's a trick ;) Use /16s on the servers and /24s in routers. Proxy ARP will do the routing for you ;) – ioshints May 12 '13 at 7:48
1

For the IGPs, cant you just use the regular metric tuning? EIGRP - just manipulate the delay and for OSPF the cost. Once it hits the BGP core, cant you use BGP meds. For my company (financial intuition) i know thats what we do. We have an A feed and B feed. A feed will have better internal metrics than B. Once it hits our BGP core then its pretty much what I listed above.

0

Another option that could give more flexibility is to use QoS and simply PbR based on the queues, if you design it right you even get automatic failover from the primary to the backup, but not the other way round.

That way you can choose to share, or not share, any link or router with a policy change.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.