I don’t trust MPLS. ATT used to run ours and claimed they honored our QoS and CoS tags…which they never did. I’ve found an SDN a-la Cisco IWAN which is encrypted as part of the appliance.
If your MPLS provider really provides QoS, encrypting will make it so the MPLS cannot QoS things as it can’t tell what type of traffic is in the packet to prioritize.
A great reason not to is QoS. Do you have voip running over that MPLS that you need to prioritize?
We run MPLS between head office and office in China. Sd-wan for all the other things.
Latency/packet-loss lover the normal internet in China is terrible.
You can get internet connections from a few isps in China that don’t have these issues. But is you look in to how they work, they have an mpls connection to Hong Kong then break out to the internet from there.
Mpls still has its place where a sla is required.
Because we have always done it that way?
In most mpls/vpn deployments you would copy the dscp markings from the original packet to the encrypted packet so that qos should be unaffected.
Well you still can do that. It may even be easier depending on how you do it.
We use, for ease of remote working OpenVPN client with yealink devices. It’s AES-CBC 128 bits, but that’s good enough.
There has not been a need to implement QoS yet, but it would be extremely easy if it became necessary, just prioritize the traffic targetting this port and ip.
Alternatively, if doing it at router level, you could deploy a speciffic tunel for the VoIP VLAN, or just use IPsec without tunneling.
Interesting but makes sense. In metro Detroit, all of the mpls clients I was aware of switched to either p2p or regular wan fiber
You should check out Aryaka. I used to work for an O&G fortune 100 and we used them to resolve latency and get around the great firewall. We too broke out our connections in HK and other places. You can also get accelerated connects to O365 etc.
Sure, but the IPSEC on top is outside of the SLA (except for complete outages) and your ISP will not honor any QoS enforcement/quality for those tunnels on top of MPLS.
Oh that’s cool. It’s been about 10 years since I set such a thing up, good to know
most? I have not personally seen this happen. Awesome if it can actually do this.
Interesting, the only requirement I have encountered for sla is correct dscp markings. Where in the world are you that ipsec (with proper dscp markings) would fall out of the sla?
"When a new header is added (encapsulated), any QoS marking in the inner header is copied to the outer header. For example, when an IP datagram is encapsulated with an MPLS header, the default behavior is to copy the IP Precedence bits from the IP header to the MPLS EXP bits in the newly-imposed header.
Regarding header disposition, we typically do not copy any outer marking(s) to the inner header. For example, at the endpoint for a GRE tunnel, let’s say that we receive a packet with different DSCP values in the outer and inner IP headers. When we remove the outer header we do ~not~ copy its DSCP value to the inner header."
This is standard behavor on Cisco routers for as long as I can remember. All the ISR series, but I think the 29xx’s did this as well. (For Route-Based VPNs, I think policy based was different.)
you realize encapsulation <> to encryption right? I’m not not trying to argue. MPLS is wrapping the packet, its not encrypting.
Correct, there is a table on that page that lists the supported mappings. Normally I’m using something like dmvpn on the mpls and that supports it.