Routing HTTP, HTTPS & FTP traffic over one link.

Unanswered Question
Mar 23rd, 2009

I have two routers at one site. I want to route all Web traffic (Http, Https & FTP) over one link while sending all my corporate (All other traffic) over the other link. What is the best way to route this traffic?

Thank you

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
thotsaphon Mon, 03/23/2009 - 11:30

Hi Leo,

Policy Base routing is what you are looking for. Which device is behind those 2 wan routers? Let's check at it first. It can support PBR or not. If not, You may send all traffic to just one primary router and do PBR on it to send only all your corporate traffic to the another router.

Let's understand what PBR does for us first!



Joseph W. Doherty Mon, 03/23/2009 - 13:25

Another totally different approach, rather than direct certain traffic to certain links, might be to manage traffic bandwidth allocations on both links. This approach is especially nice if one link fails, and the remaining link is required to carry all traffic.

l-durocher Tue, 03/24/2009 - 05:15

OK. I have two routers 2811 and they are doing HSRP. Router 1 is the primary router connected to my WAN Router 2 is the backup router connected to my HQ via IPVPN and we are paying for this backup link. And my WAN link is heavily utilized. So we want to move all the Internet traffic (Web and FTP)over the Router 2. This will leave my WAN bandwidth available to my business applications. Router 1 is the sites default gateway.

Again thank you for all your help

Joseph W. Doherty Tue, 03/24/2009 - 07:49

Yes, understand, but besides using both links, it's possible to configure your business applications to obtain priority over your non-critical traffic (again on both links). Besides your corporate traffic not being degraded by your non-critical traffic, it would have both links bandwidth availalble to it. I.e., it might perform even better than dedicating links to specific traffic.

NB: managing your traffic bandwidth reservations, may also permit an immediate performance boost to your business applications before you utilize your backup VPN:


class-map match-any nonbusiness

!don't recall whether http also matches https

match protocol http

match protocol ftp

policy-map managebandwidth

class nonbusiness

!non-critical applications obtain "available bandwidth" from minimum allocaton

bandwidth percent 1

class class-default


interface x

service-policy output managebandwidth

As to the HSRP issue, easiest solution might be, if you want to utilize both links for all traffic, might be to utilize GLBP, which the 2811s should support. (If the links offer different bandwidths, GLBP can weight their usage.)

John Blakley Tue, 03/24/2009 - 07:55


In the scenario that you gave above, would this configuration change if he was using NAT?



Joseph W. Doherty Tue, 03/24/2009 - 08:48

John, for just IP address NAT, probably not. If something like PAT is involved, perhaps yes.

John Blakley Tue, 03/24/2009 - 08:58


This falls back into what I had asked last week, and I realized that PAT/NAT was done before QoS on outgoing traffic. So the return traffic in that case would need to reference the public address, which in turn would affect everything and not just the certain classes for that policy map, right?

That's where I get confused.



Joseph W. Doherty Tue, 03/24/2009 - 09:23

John, yes if you're doing some inbound analysis of packets that relied on IP addresses, and those addresses had been NAT'ed, then you would have a problem, if you're "outside".

However, similar to ACLs, that can be placed in or out on an interface, some QoS can perform the same function in a different location. For instance, we might rate limit on interface ingress, but we might also be able to accomplish the same by rate limiting on interface egress. If we have such a choice, we can target analysis before/after NAT/PAT. (Similar issues often arises when working with VPN traffic.)

With QoS, we also have the option to limit analysis to ToS, which often isn't impacted by NAT/PAT/VPN, etc. One of the reasons for the ToS, is a label, or tag, that helps us avoid every hop performing packet inspection to determine its QoS treatment. I.e., ideally we want to replace is it FTP or VoIP, with is it CS1 or EF.

Putting this together, we might classify and mark traffic as close to the source as possible, but generally classication would be on the "inside" of NAT/PAT/VPN. We then treat the traffic based on its ToS, which can be independent of "inside" or "outside".


This Discussion