cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1028
Views
8
Helpful
5
Replies

Choosing a WAN Solution

visitor68
Level 4
Level 4

I have a question regarding design considerations. Can someone with personal experience please help me with this?

Lets say I have a centralized location that must connect to many remote sites - a hub and spoke kind of architecture. The hub will be located at the data center and the spokes around the metro area of a city. So, this is a very typical set up.

My question concerns the WAN technology to use to connect these sites.

I can use an FRF.8 ATM-to-Frame-Relay model.

I can use an MPLS solution.

I can use point-to-point circuits between each spoke and the hub.

I can use IPSec VPNs over public Internet connections.

This design is a greenfield situation, so there is nothing to work with.

What are the considerations I should make when choosing a WAN technology?


Which is typically the cheapest of all the solutions above?

If you had to choose a design, which would you choose?

==============================================================================================================

What I think is a nice robust solution is to have dual hubs at the data center and dual edge routers at each spoke site.

-- Spoke router 1 will use an BGP MPLS VPN technology to connect to hub 1.

-- Spoke router 1 will have an iBGP peering with spoke router 2.

-- Spoke router 2 will use a BGP peering with hub router 2 over an IPSec tunnel as a back-up.

-- If spoke router 1's connection to the MPLS network fails, it will lose its primary route to the hub and fallback to its iBGP connection through spoke router 2, which will provide connjectivity back to the data center through its IPSec connection to hub router 2.

Can someone comment on the sanity, advantages/disadvantages of this proposed solution?

Thank you!

5 Replies 5

visitor68
Level 4
Level 4

Any one of the heavy hitters like to field this one?

paul.popour
Level 1
Level 1

I can use an FRF.8 ATM-to-Frame-Relay model.

Not familiar with it.  We had a lot of ATM WAN circuits up until about 3 years ago but I was a couple of slots away from having to deal with it except on rare occasions.  The only thing I'd be cautious of would be the vendors commitment to the technology.

I can use an MPLS solution.

Good mesh connections and typically cheaper than point-to-point setup. You can use DMVPNs to provide the tunnelling between the sites.

I can use point-to-point circuits between each spoke and the hub.

Could introduce a site to site SPOF unless you connect each site to at least one other site. Depending on the distance from site to site you could dramatically increase cross site latency compared to an MPLS but on a metro scale the issue is probably mute and site to site traffic may be minimal.

I can use IPSec VPNs over public Internet connections.

Any security concerns about the remote office having an available unfiltered Internet connection?  Bandwidth guarentee between sites.

I'm far from a heavy weight unless we're talking physical mass but those are a few of my thoughts.

Thanks for your input, Paul...

Jon Marshall
Hall of Fame
Hall of Fame

ex-engineer wrote:

I have a question regarding design considerations. Can someone with personal experience please help me with this?

Lets say I have a centralized location that must connect to many remote sites - a hub and spoke kind of architecture. The hub will be located at the data center and the spokes around the metro area of a city. So, this is a very typical set up.

My question concerns the WAN technology to use to connect these sites.

I can use an FRF.8 ATM-to-Frame-Relay model.

I can use an MPLS solution.

I can use point-to-point circuits between each spoke and the hub.

I can use IPSec VPNs over public Internet connections.

This design is a greenfield situation, so there is nothing to work with.

What are the considerations I should make when choosing a WAN technology?


Which is typically the cheapest of all the solutions above?

If you had to choose a design, which would you choose?

==============================================================================================================

What I think is a nice robust solution is to have dual hubs at the data center and dual edge routers at each spoke site.

-- Spoke router 1 will use an BGP MPLS VPN technology to connect to hub 1.

-- Spoke router 1 will have an iBGP peering with spoke router 2.

-- Spoke router 2 will use a BGP peering with hub router 2 over an IPSec tunnel as a back-up.

-- If spoke router 1's connection to the MPLS network fails, it will lose its primary route to the hub and fallback to its iBGP connection through spoke router 2, which will provide connjectivity back to the data center through its IPSec connection to hub router 2.

Can someone comment on the sanity, advantages/disadvantages of this proposed solution?

Thank you!

Joe

1) Point to point connectivity - can be limiting in that if you have a requirement further down the line for a spoke to talk directly to a spoke you have to either

i) put in a new line

ii) go via the hub thus increasing traffic at hub simply to go between spokes

One of the big disadvantges is if you looked to migrate your DC to another location. Suddenly you have to repoint all your spoke links. Compare this with MPLS where you simply need to provision a new circuit to the new DC location, no need to reconfig the spokes.

Advantages, being a dedicated line you have guaranteed SLAs etc.

2) IPSEC VPNs over Internet -  main disadvantage here is SLAs/QOS ie. you can't have any across the internet. So you would be limited in prioritising applications within your company.

Security is also an issue - not so much security of data but availability of data which is related but not the same as QOS ie. a major world event and suddenly the internet has slowed to a snails pace.

3) MPLS - certainly more flexible than P2P in terms of site relocation, any-to-any model which you don't have to use but is available if you need spokes to go to spokes without going via the hub in future.

You can have SLAs/QOS on an MPLS network.

For costings you need to talk to the providers. A lot of providers have invested a lot of money to move to an MPLS architecture so often they will offer incentives to use it.

Personally unless you can find an overwhelming reason not to go for it i would recommend MPLS for your primary WAN connection.

As for redundancy, there are many ways to provide this and a lot of will come down to cost. There is nothing wrong with your solution although i'm a little unsure what you envisage the backup connection to be ie. if it is a internet connection running IPSEC then you probably won't be running BGP across it. And you wouldn't need to ie.

if the only 2 network devices at each site were the routers you could run HSRP on the LAN interfaces and track the external connections. If the external MPLS connection went down then move the active gateway to the backup router. Each router would have a default-route pointing out of it's WAN interface.

If there is an internal L3 switch simply redistribute the BGP learned routes into the interior routing protocol from the primary router and have the backup send a default route. If the MPLS link goes down the default-route will be used.

It's a difficult question to answer on a forum like this because there are so many variables and each company has specific application requirements together with different business priorities ie. for some companies security is paramount, for others cost and for others flexibility and speed to add new sites etc etc.

So all i have done is given a general answer. It's not necessarily what you should do but it might give you a good starting point.

Jon

Jon:

It is indeed a difficult question to answer and I appreciate your thoughtful comments. There are a lot of variables to factor in, but what I wanted was just some general direction and an opinion on my approach.

Thank you for providing both.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco