WAN Management/Optimisation

Bakedgoods

Bakedgoods

Bakedgoods

Capodecina
Permabanned
Joined
31 Dec 2003
Posts
5,172
Location
Barrow-In-Furness
I know a few of you are very knowledgeable in the networking department so seems logical to ask...

What would you recommend for WAN Management and traffic sharping/prioritisation?

Currenly using Packeteer? Although a produce by Expand has been mentioned.

Looking to improve the WAN without having to plough loads of money into the connection itself.
 
If you're looking at WAN acceleration I've had good results with Juniper WX kit, in terms of prioritisation you can get very good results just using CoS on a cisco router.
 
As I understand it, the Juniper kit you've mentioned is more for compressing data to effectively allowing more throughput?

We already have Packeteer implemented so it's unlike it will be removed and left just to a Cisco router. I was just trying to establish if anything out there basically does it better?

Just to try further my understanding, could you answer a couple of questions?

If we want to prioritise traffic for certain web applications and business critical systems and split it something like this....

Biz Systems - 45%
Biz Web Apps - 45%
Recreational - 10%

Will it only enforce that under times of heavy load when it's required, or will it take place all the time? When it hits dinner time the number of users browsing the internet (recreational or business related) will increase dramatically, will it still only allow 10% or is it dynamic in that it will allow up to 100% to be used IF the other two priorities were at 0%?

Thanks for any input guys :)
 
Wardie said:
As I understand it, the Juniper kit you've mentioned is more for compressing data to effectively allowing more throughput?

We already have Packeteer implemented so it's unlike it will be removed and left just to a Cisco router. I was just trying to establish if anything out there basically does it better?

Just to try further my understanding, could you answer a couple of questions?

If we want to prioritise traffic for certain web applications and business critical systems and split it something like this....

Biz Systems - 45%
Biz Web Apps - 45%
Recreational - 10%

Will it only enforce that under times of heavy load when it's required, or will it take place all the time? When it hits dinner time the number of users browsing the internet (recreational or business related) will increase dramatically, will it still only allow 10% or is it dynamic in that it will allow up to 100% to be used IF the other two priorities were at 0%?

Thanks for any input guys :)
Click to expand...


Yes, the Juniper kit is optimisation with soem compression technology included. What your describing is very basic prioritisation really. I would seriously do it on a router or a firewall rather than buying additional equipment.

Regarding your question on dynamic priorities, thats possible on pretty much anything, I'd do it by setting guarenteed bandwidth and CoS together rather than creating rigidly defined pipes for each type of traffic.
 
bigredshark said:
Yes, the Juniper kit is optimisation with soem compression technology included. What your describing is very basic prioritisation really. I would seriously do it on a router or a firewall rather than buying additional equipment.

Regarding your question on dynamic priorities, thats possible on pretty much anything, I'd do it by setting guarenteed bandwidth and CoS together rather than creating rigidly defined pipes for each type of traffic.
Click to expand...

Just out of curiosity, how exactly do you set CoS and gaurenteed bandwidth together? I thought they are pretty dissimilar things? If we set CoS for http traffic it would group the Biz Web Apps and Recreational Browsing together. Can you setup gaurenteed bandwidth to function with that so it will still distin guish between a Biz Web App (also http traffic)?

I'm guessing the answer is yes, but as i'm still learning it just seems a little contradictory.

I'm just doing research at the moment, bare in mind my knowledge isn't vast and I have minimal experience, so take it easy :D
 
any reason why you want somthing other than that Packeteer? Work in a number of data centres and many are using them
 
Wardie said:
Will it only enforce that under times of heavy load when it's required, or will it take place all the time? When it hits dinner time the number of users browsing the internet (recreational or business related) will increase dramatically, will it still only allow 10% or is it dynamic in that it will allow up to 100% to be used IF the other two priorities were at 0%?

Thanks for any input guys :)
Click to expand...

Depends on how you have the queueing configured, general Qos on Cisco gear is mostly all about defining traffic classes then treating them in a defined way, whilst perhaps having one class (realtime) which requires very high service.. How the other traffic performs under times of congestion depends mainly on how much bandwidth you have and how you have Qos configured.

In your example, if you were to do this on Cisco kit, you'd most likley be using CBWFQ, and another thing is that most vendor queueing algorithms only allow up to 75% of the link bandwidth to be "guarenteed" and split between classes, for example 30% biz systems, 30% Webapps, 15% Recreational. If you applied this using CBWFQ, any of the traffic classes can use any bandwidth available, that is until congestion starts to occur and the queueing algorithms kick in and starts queuing/dropping from the classes.

Defining a number of traffic classes and running hard policing on each class is the simpliest and easiest way, but it means that no particular class will ever be able to take advantage of free bandwidth.
It all really depends what traffic you have and how you want it to behave, it all becomes highly entertaining when realtime traffic is present!.

As BRS says, most routing platforms do Qos very effectivley indeed, we do it for 99% of our customers, we only really have specialised shapers and subscriber based Qos for the cable modem/DSL network.
 
Wardie said:
Just out of curiosity, how exactly do you set CoS and gaurenteed bandwidth together? I thought they are pretty dissimilar things? If we set CoS for http traffic it would group the Biz Web Apps and Recreational Browsing together. Can you setup gaurenteed bandwidth to function with that so it will still distin guish between a Biz Web App (also http traffic)?
Click to expand...

The first part of any Qos is to classify your traffic, if your Web apps guys and Recreational browsing machines are on different subnets, then its easily distinguishable,
If their all on the same subnet or Vlan, you can match the traffic and queue it depending on the end host address, or if you're really clever and you have decent switches, you can set a DSCP codepoint value for all traffic entering a specific switchport, so traffic gets marked with a specific value as it enters the switch from the user, this value then gets matched by the router which then queues the traffic accordingly depending on the class, for example you could use "DSCP 11" for WebApps, "DSCP 43" for Biz Systems, and "DSCP default" for normal internet traffic, set those values on the switchports where they connect, then have the upstream Layer3 device perform queueing based on those values..
 
jimjamuk said:
any reason why you want somthing other than that Packeteer? Work in a number of data centres and many are using them
Click to expand...

It's mainly just research into if there's any way we can improve or reduce costs.

Good posts V-Spec.

One thing to clear up though, Biz Web Apps aren't people, I mean business web applications.

For example, we have access to a corporate web portal that is remote. This would still be http traffic. When lunch time comes round and all the users jump on BBC News or whatever, access to the corporate web portal can really slow down...

The http traffic will originate from the same source address, so there needs to be a different method to distinguish the data.
 
Wardie said:
It's mainly just research into if there's any way we can improve or reduce costs.

Good posts V-Spec.

One thing to clear up though, Biz Web Apps aren't people, I mean business web applications.

For example, we have access to a corporate web portal that is remote. This would still be http traffic. When lunch time comes round and all the users jump on BBC News or whatever, access to the corporate web portal can really slow down...

The http traffic will originate from the same source address, so there needs to be a different method to distinguish the data.
Click to expand...

I did this most recently on a 3750, so a little different from a pure router. What I did was classify traffic based on an ACL and then set DSCP value (much as v-spec was talking about). The trick you're looking for (i think) to seperate web app and http traffic is differentiating on destination address (unless there's a reason you can't). Simply prioritise traffic to the range of your web application provider would be my approach.
 
Wardie said:
It's mainly just research into if there's any way we can improve or reduce costs.

Good posts V-Spec.

One thing to clear up though, Biz Web Apps aren't people, I mean business web applications.

For example, we have access to a corporate web portal that is remote. This would still be http traffic. When lunch time comes round and all the users jump on BBC News or whatever, access to the corporate web portal can really slow down...

The http traffic will originate from the same source address, so there needs to be a different method to distinguish the data.
Click to expand...

lol! sorry its friday morning :D

In which case its difficult to classify traffic as its basically all exactly the same, the only difference is its ultimate destination, for example the corporate web portal, or google/porn/etc?

The best way would be to define a queueing policy where you specify the destination address(es) of the corporate web portal, and reserve a specific amount of bandwidth for traffic traveling to it from any source address on the LAN,

For example, on a Cisco box the config would look something like:

set access-lists to match traffic going to the corporate web portal, (1.1.1.1 is the web portal in my example)

Outbound
access-list 109 permit ip 172.16.0.0 0.0.255.255 host 1.1.1.1


class-map match-all outboundportal
match access-group 109
!
policy-map outbound
class outboundportal
bandwidth percent 30
!
Interface serial 0
description Wan interface
ip address 1.2.3.4 255.255.255.252
service-policy output outbound


This basically allocates 30% of the link bandwidth to traffic travelling towards the portal based on the speed of the WAN interface.
You can't queue traffic coming inbound to the router from the webportal (only police) you can queue outbound toward the LAN but it won't help because the WAN interface will become congested before the LAN qos policy can drop the packets, to have inbound queueing the upstream router (ISP) would need to queue outbound towards you, or you'd need to use hard policing..
This would be the main issue, I assume that most of the congestion would be caused by people downloading normal webpages/stuff from the internet and not upstream bandwidth.
If the ISP cannot do any form of Qos for your connection back, you could make an opposite qos policy and change the bandwidth of the LAN interface to fool the qos into thinking that its the same speed as the WAN interface, this would allow qos to drop normal web packets outbound towards the LAN, this would cause TCP to throttle back and control the rate somewhat..

Trial and error most likley!
 
V-Spec said:
lol! sorry its friday morning :D

In which case its difficult to classify traffic as its basically all exactly the same, the only difference is its ultimate destination, for example the corporate web portal, or google/porn/etc?

The best way would be to define a queueing policy where you specify the destination address(es) of the corporate web portal, and reserve a specific amount of bandwidth for traffic traveling to it from any source address on the LAN,

For example, on a Cisco box the config would look something like:

set access-lists to match traffic going to the corporate web portal, (1.1.1.1 is the web portal in my example)

Outbound
access-list 109 permit ip 172.16.0.0 0.0.255.255 host 1.1.1.1


class-map match-all outboundportal
match access-group 109
!
policy-map outbound
class outboundportal
bandwidth percent 30
!
Interface serial 0
description Wan interface
ip address 1.2.3.4 255.255.255.252
service-policy output outbound


This basically allocates 30% of the link bandwidth to traffic travelling towards the portal based on the speed of the WAN interface.
You can't queue traffic coming inbound to the router from the webportal (only police) you can queue outbound toward the LAN but it won't help because the WAN interface will become congested before the LAN qos policy can drop the packets, to have inbound queueing the upstream router (ISP) would need to queue outbound towards you, or you'd need to use hard policing..
This would be the main issue, I assume that most of the congestion would be caused by people downloading normal webpages/stuff from the internet and not upstream bandwidth.
If the ISP cannot do any form of Qos for your connection back, you could make an opposite qos policy and change the bandwidth of the LAN interface to fool the qos into thinking that its the same speed as the WAN interface, this would allow qos to drop normal web packets outbound towards the LAN, this would cause TCP to throttle back and control the rate somewhat..

Trial and error most likley!
Click to expand...


Thanks, that makes sense :)

But like I said before, you've used 30% bandwidth as a limit there, i'm guessing that only comes into effect when it needs to if you will, not constantly?

Regarding Packeteer, I think we may be fine with that then and it was seem like a pretty pointless cost to worry about implementing something else.

What about the Juniper acceleration kit though? How much of a benefit do you actually get from the in terms of throughput etc?
 
Wardie said:
Thanks, that makes sense :)

But like I said before, you've used 30% bandwidth as a limit there, i'm guessing that only comes into effect when it needs to if you will, not constantly?

Regarding Packeteer, I think we may be fine with that then and it was seem like a pretty pointless cost to worry about implementing something else.

What about the Juniper acceleration kit though? How much of a benefit do you actually get from the in terms of throughput etc?
Click to expand...

The 30% is basically a reservation, it simply means that anything not matched in the access-list will be queued/dropped, whilst the traffic in the access-list gets the 30% of the total circuit bandwidth offered to it, it can have as much as it likes when there is not much usage, but the moment the default-class traffic starts getting heavy, that 30% will be put to one side.
 
Wardie said:
Cheers :)

Any input about the acceleration kit guys?
Click to expand...

The juniper kit is excellent for what it is. For the right type of traffic it's great, which raises the question what kind of traffic are you dealing with?

It's designed to be deployed with one central site unit and 'client' units at each branch office site, which is great if you have a network design it'll slot into.

The other thing is, it's pretty expensive, the base model is only designed for up to 2MB connections and it's hardly cheap (about £2k).

The WX100F units we use cost a bit less than £15k configured for 20mbit, which means £30k for a pair to accelerate a 20Mbit link, which compared to just upgrading the link is difficult to justify. The lower end units (wx15/20/50) are actually better value probably, especially used with SDSL lines at offices out in the sticks.
 
In some senses that is quite applicable.

When you say a certain type of traffic, what do you mean? I asked my college tutor about WAN acceleration today and he said the same thing, it depends on the type of traffic.

It will mainly be data generated by business systems.

Is there any software/hardware which would be more beneficial than an implementation of this?

http://www.packeteer.com/products/packetshaper/
 
Last edited:
Wardie said:
In some senses that is quite applicable.

When you say a certain type of traffic, what do you mean? I asked my college tutor about WAN acceleration today and he said the same thing, it depends on the type of traffic.

It will mainly be data generated by business systems.
Click to expand...

WAN accelerators love http traffic as a starting point, lots of connections, lots of compressable data and plenty of pattern recognition possible.

By contrast, rich media is less useful, video doesn't get much benefit usually, file transfer sometimes gets a boost sometimes not.

The best use of accelleration is usually something like a remote web portal, that would typically get a big boost in usability from a accelerator.

The worst is difficult to say, I've never got anywhere using accelerators for media streaming and my attempts to boost iSCSI performance over the WAN have been hit and miss.

EDIT: I doubt anything is worth a change from packeteer, Juniper fitted in with our network and existing relationship so it was a good choice but if you already have packeteer and don't have a support or purchasing relationship with juniper, then the small performance difference wouldn't be worth a change.
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom