Results 1 to 1 of 1
We have an MPLS network with several remote nodes that route back to a headend network. This network provides internet traffic for approx 100 users on each node. The main ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 12-06-2008 #1
- Join Date
- Jan 2007
TCP/IP optimization/compression under MPLS
We have an MPLS network with several remote nodes that route back to a headend network. This network provides internet traffic for approx 100 users on each node.
The main router is connected to the MPLS cloud via a 6 Meg pipe (moving up to a 10 Meg shortly) and each remote note is linked to the MPLS cloud via a 3 or 6 Meg pipe depending on the size of the site.
Through the MPLS network, we have the boundary routers tagging packets for QOS based on port. We also run two networks (a private network for management of servers and an isolated network for internet access), and assign priority based on subnet.
So in short we have:
subnet A: COS 1
subnet B- port 80,443,ect..: COS 2
subnet B- everything else: COS 3
We are looking for a way to optimize the traffic flowing across the mpls network as much as possible to squeeze every bit out of the circuits, as adding an extra 1.5 Mbit (another bonded T-1) is really costly. I've looked at products like the fatpipe Kompressor, which is a packet compressor, but it is designed to work across a WAN link and not a LAN segment and the encapsulation negates the QOS.
My firewall/default gateway is a DL360 with dual pentium 4's and 2 gig of ram running linux, so I have plenty of spare cycles and memory. Right now the QOS does a fantastic job of shaping traffic and handling high loads, but latency is still a bit of an issue.
Is there any sort of compression or optimization I can implement on the incoming packets to increase my throughput or at least drop my latency? Most of the traffic is standard port 80 web traffic, but there is a fair amount of P2P and we have quite a few users who use VOIP and play online games who would benefit from a lower latency link. I don't currently have another server on the other end of the MPLS cloud, but it wouldn't be hard to implement that if I needed something to run decompression.