MPLS with Disaster Recovery

[trackjg24]

Hello,

My company has moved to a MPLS any-to-any network, from Frame Relay. The new services with MPLS is great. However, we have come to a problem when we want to test our Disaster Recovery.

During the DR drill we will do a full recovery at a remote site, this remote site has a MPLS link as well. However, the servers have the same IP addresses as the production servers do in our primary data center.

It would be simple to just shut off the MPLS links at the primary data center for the duration of the drill. However the business requires to stay up. When we do our testing with other remote sites from the DR location, only about 4 or 5 sites need to communicate to that DR site and the rest of the remote sites will need to communicate back to the primary data center and not be impacted by the DR drill. When we had Frame relay all we had to do is take down the DLCI's to the primary data center and bring up the DLCI that points to our DR site. But with any-to-any we can't do that anymore.

So I'm looking for any suggestions that anyone might have on what I can do on my routers to prevent:

* my non-test sites from talking to the DR site.

* my test sites to only talk to the DR drill location and not the primary data center.

Please let me know if you have any suggestions. I have my service provider looking into it as well to see if their is something they can do on their end to make this happen.

Thanks,

Matt

[Wilson Samuel]

Hi Matt,

The situation is pretty interesting, may I request you put some more information regarding the scenario, a diagram would be of great help.

Regards,

Wilson Samuel

[pciaccio]

Matt: Having dealt with Disaster Recovery for some time. With the MPLS senario you can create a DR environment with all new IP addresses and subnets. this way your production can stay up at all times. What you will need to do is provide DHCP and DNS backup environments that forward any requests to the DR backup site. So any user that is requesting production does not have to change anything. If they are requesting the DR site they just redirect their applications to the DR site. ex. If accessing an application called database, they would normally direct to the domain name of "database.abc.com". For the DR environment it will be "databaseDR.abc.com". Your DNS will redirect them to the DR site and your production can stay up. If modifying DNS is not an option then you can create a backup list of IP's that your remote users need to redirect themselves to their respected applications.Hope this helps you....

[trackjg24]

Thanks for the suggestion. I've actully suggested this in past DR events when we just had Frame Relay, but I didn't get a good response from other parts of IT, especially our DNS group. I guess it is all extra work for them. They would rather pop in a tape at the DR site and restore their server and be done. Not redesigning their who DR DNS. But with MPLS, we may be forced into this kind of situation, because I haven't got anything back from my ISP (Sprint) about closing off certain sites from the DR test.

[rais]

If e.g. your DR and Primary DC have subent 10.1.1.1/24, you would still be receiving a single route for the above subnet at each of your remote locations. Correct? You can't prefer one route over the other, can you?

Thanks.

[jarvar832004]

Matt

This can be done with some small changes involved at the SP end. I presume you have taken a L3MPLS service from your SP. In that case you can ask the SP to assign two sets of RT values to the prefixes advertised out of the primary location, say RT1 and RT2. Now those locations that will undergo the DR test will be given one RT of RT1 and those that need to work will be given RT2. When DR drill is being done ask the SP to remove the RT1 from the primary location. The DR location will continue to send the prefixes with RT1 and all the test locations will reach DR.

But this needs to invlove SP during the test period.

[jackyoung]

In addition to Rayma's suggestion. I agreed it is the easy way to create another VPN for the DR purpose. i.e. separate to two networks.

I could like to suggest another solution to tag the primary and DR routes. Let them to flow in the MPLS VPN. And the PE will based on the tag to filter out the unwanted routes. e.g. If a CE wants to reach the primary site, the direct connecting PE will filter out the DR routes by tag. However, it also involve SP to modify their service.

But be careful to avoid any looping or black-hole route.

Moreover, what I think if there is backup link at remote sites, we can make it by using Policy-based routing to select to use which VPN, primary or DR. If there are dual connections, it only involve the change of the CE during the Disater and not require to change in PE or MPLS side.

Hope this helps.

[mheusinger]

Hello,

a slightly different approach: use a Multi-VRF CPE. This will require the SP to change their service only once and you are free to connect your VLANs any time to the different VRFs, i.e. normal or DR environment. It also allows for clear separation of the same IP subnets into separate routing contexts in your network.

Backup might be achieved through either reconfiguration after desaster or with careful routing design at routers connecting to both environments.

Regards, Martin

[jackyoung]

Hi Martin, I also consider this as an option before. But I am afraid not all SP support multi-VRF at CE, so I propose to use dual links.

If the SP supports the multi-VRF at CE, it should be the simplest solution. But it may lead to extra cost to the user of additional VPN.... if they charge by no. of VPN.

Many Thx.