Internet Traffic

[DeeReal_99]

Hi Community,

I am tasked with taking our single internet connection (4Gbps) and carve in two lanes.  One lane will service normal traffic; internet, vpn, remote access, telephony, etc. The second lane would be dedicated to send backups data to the cloud.  I'd like to take a 75/25 approach where 75% of the bandwidth is dedicated to normal traffic and 25% to backup traffic to the cloud.  I have some ideas in mind but was hoping to get pointed in the right direction. 

Thanks in advance,

DeeReal_99

[Georg Pauwen]

Hello,

what kind of routing do you have in place ? With static routes, you could configure multiple default routes achieving the 75 to 25 ratio...

[DeeReal_99]

Thanks for responding Georg.  Internal - EIGRP and static to the Firewall /Internet.

[Georg Pauwen]

Hello,

if you have only one Internet link, you can use policy based routing on the Internet facing interface. What firewall do you have ?

[DeeReal_99]

Palo Alto

[Georg Pauwen]

This is how static routes would work. Let's say the nexr hop IP address for the 75% link is 1.1.1.1, and for the 25% link is 2.2.2.2.

You would create four static host routes using dummy IP addresses:

ip route 10.10.10.1 255.255.255.255 1.1.1.1

ip route 10.10.10.2 255.255.255.255 1.1.1.1

Ip route 10.10.10.3 255.255.255.255 1.1.1.1

Ip route 10.10.10.4 255.255.255.255 2.2.2.2

Then configure four static default routes with the dummy addresses as the next hop. This results im 75/25 load balancing,:

ip route 0.0.0.0 0.0.0.0 10.10.10.1

Ip route 0.0.0.0 0.0.0.0 10.10.10.2

ip route 0.0.0.0 0.0.0.0 10.10.10.3

ip route 0.0.0.0 0.0.0.0 10.10.10.4

[Joseph W. Doherty]

I would suggest you "carve" your lanes using QoS.

Many Cisco switches or routers would support two classes, and for egress to the Internet you could "guarantee" your backup traffic your 25% and allow remaining traffic 75%.  (BTW, unless you have a specific reason to "guarantee" your backup traffic a certain percentage, I would suggest trying an allocation of 1%, for backup traffic.  As a minimum "guarantee", backup traffic could still obtain up to 100% of the bandwidth, but, generally, would allow other traffic "priority" for egress yet not be totally starved of bandwidth.)

If you need to "carve" inbound (i.e. from Internet and/or backup restore) bandwidth, that's much, much more difficult to manage (at the end or your Internet connection/link).

[DeeReal_99]

I kind of thought QoS (hard gulp) was gonna be the way.  I wanted to specify a guarantee for the backup traffic because historically, when mixed in with normal prod traffic, backup jobs failed due to lack of bw.

I need to know now where to apply being that I have a mixture of vendors in my Internet Services block.  I have a Palo alto leveraging FW and internet filtering.  Also an external Cisco L2 switch and an IS router on deck for future use.  My assumption is that this will land on my firewall - .  Thanks for suggestion Joseph

[Richard Burts]

Several of the suggestions seem to be based on an assumption that you will have 2 links to the Internet. If that is the case then either the multiple static routes or PBR to steer backup traffic to the other link would work. But my reading of the original post suggests that there will continue to be a single link to the Internet and that the two lanes is virtual.

If there is to be a single link to Internet then I agree that QOS is the better solution. You would want to implement QOS on a single device which passes both the backup traffic and the other Internet traffic and I assume that probably would be your firewall.

[DeeReal_99]

Yes, Richard I will be utilizing a single connection to the provider.  

[Joseph W. Doherty]

"I kind of thought QoS (hard gulp) was gonna be the way."

"hard gulp", laugh, QoS really isn't that difficult, although reading some "how to" QoS documentation does make it seem that way.

". . . backup jobs failed due to lack of bw."

Interesting!  Do you know what protocol(s) your backup traffic uses?  Generally, applications only fail for lack of bw when they are pretty much deprived of any or are, shall we say, not well designed to run across a network (sharing bw).

Hmm, QoS, possibly on a FW (hard gulp).  Don't have much experience there (like none, specifically QoS on a FW).  Generally, there are devices inline of traffic flow, before and/or after, FW.  Depending on FW QoS capabilities, it might even be better, if possible, to add another device.

BTW, possibly a cause of your backup failing, for lack of bw, might be because you mention having 4 Gbps, but is this on, for example, a 10g interface?  If so, then you might have "burst" 10G going to your provider, who, for the overrun, drops some traffic on an "unknown" basis.  I have seen network applications "die" not so much for lack of bw, but because, during some time period, too much of their traffic is fully lost (rather than delayed).

If you do have 4 Gbps on a 10 Gbps interface, normally you first want to "shape" for your allowed rate, and then, if that congests, you determine how to "meter" out your traffic.

On a Cisco router, something like the following would "shape" for 4 Gbps, and split your traffic 3:1, yet allow either class to use otherwise unused bw.

E.g.:

class-map match-any BackupTraffic
match . . . !various ways to match traffic, including using ACLs

policy-map CIR
class class-default
shape average 4000000000
service-policy Regulate

policy-map Regulate
class BackupTraffic
bandwidth percent 25 !adjust percentage, as needed (for backup, recommend going as low as possible)
fair-queue !optional
class class-default
bandwidth remaining percent 100
fair-queue !optional

As mentioned in my prior post, dealing with ingress traffic is much, much more difficult, but there are a few tricks that can be used.

[DeeReal_99]

Joseph,

This has yet to be implemented (scheduled for EOM).  Not entirely sure what protocol was being used.  Also, when we last performed this, we were using a smaller pipe  <1Gbps. I am having our Sys Admin get some more data for me now. 

Nevertheless, I may be just a tad bit paranoid about this.  Upping our pipe to 4Gbps may be sufficient enough to not have the same problems.  I want to be prepared just in case we run into an issue.

Thanks for your wealth of information.  It's very much appreciated

DeeReal_99 

[Joseph W. Doherty]

". . . we were using a smaller pipe <1Gbps."

Well, again, if your were contracted for less bandwidth than the interface permits, it can be easy to "flood" over your contracted limit and have your provider drop traffic.  Also, again, if enough of that happens, some applications just give up.

If you do try QoS, it's best correlated to the end-to-end bottleneck, either the physical interface or a limit further downstream.