Future proofing - MPLS and Datacenter IP design.

[fahim]

Hi Guys..Pls help me understand this para, excerpted from a link, talking about benefits to be achieved out of deploying MPLS for WAN connectivity:

------------------------------

"..They (MPLS attributes) also position MPLS to support a host of applications, including the ones that most leading-edge enterprises are actively assessing or deploying, including:

* Data center connectivity. Any-to-any connectivity is particularly important as data centers consolidate, because it makes it easy for remote sites to switch seamlessly to a back-up data center during an outage. With frame relay and ATM, backup requires provisioning "shadow," permanent virtual circuits or deploying switched virtual circuits, both of which add cost and complexity.

http://www.networkworld.com/research/2006/010906-mpls-hot.html

----------------------------

We are in the middle of designing a new datacenter for a client and I am planning on IP Schema. The client will have an MPLS backbone running soon, as they shift from current ATL/Frame relay links across continents. Also in the near future is a Single Forest/Single Domain design based upon Windows 2003/Exchange 2003.

Is there anything I should consider in my Datacenter 'backup/disaster recovery design' at this stage in order make it seamlessly integrate with MPLS later?

Anything you guys can think of??

[Jon Marshall]

Hi

What it is basically saying is

If you use ATM / Frame Realy you must provision separate circuits if you want to connect to 2 different remote sites eg. with ATM you could have an access class of 155 and with a 50Mbps PVC to your primary data centre and then a 20Mbps PVC to your backup data centre but you have to have separate PVC's because ATM connections are point-to-point.

With MPLS you would need only one connection to the MPLS cloud, technically the Service Provider PE (Provider Edge) router. From there the Service Provider can route your packets to any of your remote locations. This is what is meant by any to any connectivity ie. you are not setting up circuits from one endpoint to the other endpoints (endpoints being your locations), your setting up one circuit between you and the SP and they will then route traffic to your other endpoints.

As for IP schema it depends on the routing protocol used to peer with your service providers PE routers. To give you an example our major sites run EIGRP internally and use BGP to peer with the PE routers. Each EIGRP AS is contained within the major site and is summarisable. So we advertise that summary address via BGP to the PE routers and they get propogated via the MPLS cloud to our other sites. We receive these routes from the PE routers via BGP and then redistribute into EIGRP.

Hope that makes sense and has answered some of your question

Jon

[fahim]

Hi Jon,

The time I read your answer to this posting, I was only gathering a few pointers on how to go about it. Now we are at a design stage.

Would you pls explain the concept in some form of graphics/network diagram?

Say, we have three branch offices in UK, India and Malaysia each connected via a MPLS backbone. Suppose I need to design a common DR site for any of the three locations, I mean, DR for India is in Malaysia and vice versa, Uk in India.

What all factors would I need to take into consideration in general? what would be the ISP involvement?

[Joseph W. Doherty · Accepted solution]

Unclear whether you're just going to run across a MPLS backbone on the WAN and/or whether you might extend MPLS into the data centers. The following is oriented toward the former.

With regard to you questions about the advantages of MPLS backbone for the WAN, for the first, as to attributes, the most important is usually MPLS's support for some form of QoS. Often today's providers provide 4 or 5 classes of varying performance within their MPLS QoS model. Usually they encompass a real-time class (for traffic like voice), gold or mission critical (might be more than one), best effort (for routine traffic) and sometimes a scavenger class (can be used for server backup, etc.).

With regard to the second point's mention of any-to-any connectivity, Jon's posting has additional details, but if it seems hard to understand, it might be because it's more like a LAN than like a traditional WAN.

Imagine LAN distribution routers running across a switched core. Multiple routers, each with networks behind them, all with an interface on the same Ethernet segment/subnet, and all routing peers; you're looking too at what MPLS WAN backbones often provide. Each router can direct traffic to any other router directly, each can receive traffic from any other router directly.

Compared to the pain of adding sites to traditional WANs using point-to-point links, whether dedicated or virtual, adding a site to a MPLS WAN is more like adding another router peer to the shared LAN segment.

With regard to IP planning for MPLS WAN backbones, the most important point, also mentioned by Jon, is address summarization; i.e. having each site covered by a single address block. With classless addressing the address blocks can differ in size. For example, large data center site might use a /20, a small branch site only a /24. (Allow for growth. Even if a small site, today, only needs a /24, you might assign it a /22 address space block.)