So I was thinking the other day about QoS… tell me if this makes sense…
Currently we do like so :
SMs < - > AP Cluster < - > CMM < - > 20Mbit BH < - > Cisco Router/WAN
It seems to me that for QoS the following makes sense…
SMs <-> APs <-> CMM <-> Cisco <-> BH <-> Cisco
The reason for throwing that extra router in there is that the CMM is a 100mbit link, and the BH is effectively a 10mbit full duplex link. It would seem to me that you would want your QoS implemented at the point where the bandwidth shrinks. I realize the extra hop may add a couple ms to my ping, but that aside, is this a good or bad idea?
it makes sense but depending on exactly what you are trying to do there may be a better way of doing it…
if you just want to give a particular customer/customers high priority you can use the priority channel…
if its voice you can use diffserve…
if you want to tackle something like p2p/mail/http then use a traffic shaping using a Mikrotik/packeteer/linux it will be better then CISCO
also remember that if the traffic is TCP then you don’t need to put the shaper at the POP, you can put it at your central NOC… once you throttle it at the NOC TCP will automatically slow down based on how it works (back-off protocol), UDP u need to be at the pop
I see what you are getting at, but you will be double NAT’ing…May or may not be a problem for your customers.
I assume that you are wanting to improve VoIP performance?
Unless your network is running near capacity, implementing QoS may not be much benefit on your network as there is enough BW for all traffic.
Usually the problem with VoIP is at the customer LAN as VoIP traffic is contending for the same BW as HTTP, FTP, etc. The issue is that VoIP uses so many ports there is no way to prioritize customer traffic by port.
A CPE router that does BW shaping by LAN MAC and/or LAN IP allows you to put priority on specific devices (ie VoIP adapter, VoIP phones, etc). This works very well, and keeps QoS management at the customer site.
If you do want to implement QoS to improve VoIP, you would need a CPE router that can tag traffic by LAN MAC and/or LAN IP rather than port. Then DiffServe can be applied at CPE, SM, AP, and BH, and those packets will be prioritized across the network regardless of where the bottle neck is.
The real VoIP killer is infected computers flooding the customer LAN and no amount of QoS is going to fix that.
Yes the purpose is to improve VoIP quality, and that is all. I have the cisco doing that currently using NBAR. I would not be using NAT in adding the router, so I don’t see an issue there.
Its just that the BH is pretty good most of the time, but does drop packets or have pings over 1000ms on occasion, and I would like these hiccups to effect VoIP as little as possible…
I’m getting into a whole new topic here, but i was wondering if i had a router on each end of the BH, if there was a way to perhaps set the TTL low over the BH, so dropped packets are retransmitted quickly.
I have runed a test to a cluster similar like yours, wich is running at the maximum of its capacity from 17:00 to 01:00 o’clock. Maximum - 3000 pps and latency of 200-300 ms in the peak time.
I have implemented the build in QoS settings on the BHs and the SMs I was testing. I was talking on the voip phone for hours, it worked perfectly.
My BH is P8. No QoS :-’