We currently have 4 remote offices tied together with P2P T1 lines but not in a full mesh topology. We are being proposed an MPLS solution to replace this existing P2P WAN in order to save us money. I don't know a lot about MPLS and if it has advantages or disadvantages over a P2P WAN. The execs see the cost savings as significant and want to know if moving to MPLS would cause issues or may be better.
Currently on the P2P WAN we do a lot of SQL replication traffic, general Windows file share, and we are thinking about VOIP. Any guidance here would be greatly appreciated.
The advantage of MPLS is that it is not point-to-point so each site does not need a connection to every other site, nor if you have a partial mesh topology does one site have to go via the hub to get to another site. MPLS is an any to any. Each site has a connection into the MPLS cloud and can go direct to each other site.
MPLS is an IP network so it's important to realise if you have legacy protocols such as IPX they will not be supported on MPLS, you would need to use GRE tunnels across the MPLS network and transport IPX down the tunnels.
The MPLS provider will offer differing levels of service depending on your traffic requirements so you need to factor the additional cost of Class of Service for critical traffic into your calculations. Certainly VOIP would need some sort of prioritisation on the WAN.
An issue I have with MPLS, is since it does support full mesh, you can easily find congestion at MPLS egress. If you do encounter congestion there, it's difficult to avoid it happening from your other sites so you rely on whatever the MPLS vendor supports in the way of QoS, which might be rudimentary and not meet your needs.
When it comes to cost savings, they're certainly possible, but understand what you're really being provided. Similar to frame-relay and ATM, not only do you need to buy access bandwidth, but often also need to buy a guarantee of bandwidth. You might have to buy QoS or more complex QoS or special QoS bandwidth (such as to provide special bandwidth guarantee for something like VoIP).
Don't misunderstand, there's nothing inherently "bad" about MPLS, but its differences, and their possible impacts, can be easily overlooked when simple pricing a P2P T1 vs. MPLS T1. If you're working with vendor unmanaged MPLS, there might be some increase in cost and/or complexity supporting it. However, if the technology is understood and properly selected, it's certainly possible to obtain like performance to your existing P2P at reduced cost, although perhaps not as much as MPLS sales might suggest.
Some overlap with Jon's post, but did't see his until I posted mine.
I have attached 2 pictures of my WAN, one current with P2P T1s and the proposed MPLS. I also labeled the offices so you could get a better idea of what they do.
Congestion was a concern to me so I asked them about it and they stated that the 'port size' at each location would be the bottleneck so we should have larger access ports if needed at certain locations. Are you stating that there can also be congestion in the cloud itself?
The two small remote offices currently have dedicated T1 internet circuits but I want to route their internet access through the WAN and out the OHIO location because we are going to have a much larger internet pipe (between 10-20Mbps). The TEXAS corporate office will keep it's own dedicated internet circuits. I'm being told that surfing through OHIO for the remote office will be just as fast for them as it is with the T1 they have now. That doesn't seem right to me but honestly it doesn't need to be blazing fast. It does, however, need to function properly.
I just bought and deployed new routers (listed in the pictures) for each site last year as part of our infrastructure upgrade. Do you see them having an issue connecting through the MPLS? Are they capable of QoS for the different services (i.e. VOIP)?
There can be congestion in the MPLS cloud, but you're unlikely to see it. You should not see it if you're within your contracted bandwidth guarantee.
Yes, congestion forms on access ports connected to cloud, both in and out. Into the cloud you can control; out from the cloud is the issue.
For example, your HQ has a larger access port (10 Mbps) than your remote sites. When it sends to a remote site, you'll likely have congestion at remote access port - out (from cloud).
Even if all access ports are same bandwidth, what if two or more sites send to same other site? Again, congestion access port - out (from cloud).
Because of the possible congestion you might have with cloud egress, their Internet access via another site could be worse than it is now. If there's no congestion, it probably would be about similar. (Better would be local Internet access. Investigate local business Internet via DSL or Cable, or ask your MPLS vendor about local split access.)
All your devices should be okay (not 100% sure about the QoS features of the 1841s, but I think they are similar in features to 2811s).
One issue, the HQ 2811 should be okay at 10 Mbps, but not much room left for bandwidth growth.
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts The ProblemOn traditional
switches whenever we have a trunk interface we use the VLAN tag to
demultiplex the VLANs. The switch needs to determine which MAC ...
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts Introduction: Netdr is a tool
available on a RSP720, Sup720 or Sup32 that allows one to capture
packets on the RP or SP inband. The netdr command can be use...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...