I seem to have got myself confused with QoS / CoS (Class of Service) over MPLS etc and downstream network locations not on our MPLS cloud. The idea was to bring either Cisco WAAS or Riverbed WAN optimisers (yes guys, it's not yet decided) at each sites and see if we can get out of the cycle of constantly upgrading our BT provided MPLS links.
Now, I was wondering, in a post WAN Optimiser scenario, For example, if we have users in London and users in Berlin who want to videoconference with each other, a perfectly natural thing for users to want to do, it will be fine and dandy because we will have Qos/CoS on the MPLS and that will deliver the packets in a timely manner. But, CoS is about getting the packets there fast, not about partitioning the bandwidth, so if the guys doing the video conference decide they want to run it in High Definition at 2Mbps, then all of the bandwidth will disappear as they have consumed it all (assuming a 2Mbps pipe in London) and all other applications regardless of class will stop, if video is classfied as higher than say, our E-Business Suite.
So, here is the question, do we need our WAN Optimisers to be (some thing like) Packeteers also? Something like a Traffic Shaping capability? The two devices are mutually exclusive as we cant allocate bandwidth if WAN Optimiser has allocated it all to get it to go fast.
Am I clear??
This will be more acute on the Intra site connections that are made up of internet VPN and point to point leased lines as these cant do CoS (unless we fancy programming some Cisco routers to do CoS (I dont)), so for these non MPLS connected sites, should we be considering Packeteer instead of Riverbed????
Do you see what I am getting at? And what the answer is?
I guess it depends on your MPLS provider but here in UK you buy different classes of service on a bandwidth basis so within the provider MPLS network if you have only purchased 1Mb of EF traffic and you choose to map this to video-conferencing then you can't exceed that within the MPLS provider cloud.
However on the connection into the provider cloud then yes you would need to implement some sort of bandwidth allocation/shaping/policing to ensure that if the outbound traffic matches what you have purchased from the provider. So if you have purchased 1Mb of EF traffic then you need to ensure you restrict that traffic on your outbound link to 1Mb. If you don't you are righ, you could overwhelm the link although it is important to note that the provider will drop the excess anyway.
I looked at WAN acceletors a while back Riverbed/Juniper/Expand (Cisco didn't have a product at the time) and from memory i'm sure they all claimed to be able to not only honour any QOS/CoS markings but also queue/shape etc. based on the markings. But that is from memory so you may want to check with vendor.
Thanks Jon. Indeed you're answered the most pertinant points.
To elaborate a bit more, our MPLS provider is BT and currently we are running on DEFAULT CoS, i.e no CoS. Running at peak of our 2MB , it's thought that it's abut time we bring in CoS and some sort of a WAN optimiser appliance.
How do we really evaluate WAN optimisation vendors, ranging from Riverbed, Juniper, Cisco etc? Can we believe in the Gartners and Forresters?
Are there any gotchas, in buying different CoS services from MPLS provider?
I too dealt with BT in may last role. I believe they have migrated most customers across but make sure you get the 6 CoS model rather than the 3 CoS model as this gives you more flexibility. I'd be surprised if you got anything but the 6 CoS model.
As for evaluating WAN optimisation i guess a lot depends on your existing infrastructure in terms of vendor, what additional features you would like with the device eg. Web proxying/caching and also ease of support ie. how easy would it be within your organisation to introduce a new vendors networking equipment.
Don't forget about the footprint of the device, for us that was ruled out Riverbed at the time but it may be different for you.
Licensing was also one of the big differences between vendors ie. was the licensing per device, per tunnel, per users behind the device etc..
It was a couple of years ago that we evaluated WAN accelerators so a lot could have changed now.
The last company i worked for was Network Rail and we had offices ranging from full blown campus setups with controlled LAN rooms to a portacabin by the side of the railway. To meet our requirements we needed a range of WAN accelarators in terms of size and quite a few of our locations did not have the racking to take a server type device.
Riverbed, who at the time i have to say we were very impressed with, only did their devices with server hardware and we couldn't get anything smaller from them so this eventually ruled them out for us. If we had only been looking at LAN rooms for our WAN accelerators this would not have been an issue.
As i say though, this was a while back so Riverbed may well have a smaller device now.
Introduction: The "external-out enable" command is available for
configuration under the "router ospf process" in case of the IOS-XR
operating system. This command basically enables advertisement of
intra-area routes on the device as external routes in th...
Introduction Basic configuration for netflow Scale parameters for
netflow Netflow support Architecture Packet flow for netflow Inside the
LC CPU Netflow Cache size, maintenance and memory Sample usage Cache
Size Aging Permanent cache Characteristics Which...