QOS on dual uplink and/or internal interface

Hi William,

Setup steps for me:
- Used ADSL router to find actual negotiated bandwidths.  
- Set Astaro up/downlink to that minus 10%.  
- Used LiveLog to ensure ftp=low & RA=high filter rules were triggering.
- Monitored transmitted real audio streams using separate internet connection.  
- Used Astaro to monitor for QOS discarding traffic from low and medium priority queues.

We found the high priority RealAudio transmission for a customer was still dropping out.  This was nothing to do with QOS but everthing to do with a crappy hub.  Its collision lights were flashing on simultaneously whenever we triggered heavy FTP traffic.  Ditched that for a £60 hub.  Problem solved.  No dropouts.  

In Astaro we then throttled back the allowed uplink bandwidth from 200k to 20k to prove the QOS functionality.  The FTP traffic was strangled off to a crawl relative to the RA traffic.  RA traffic happily consumed the same 16k as before.  

My conclusion: QOS does exactly what is says on the tin.  

Caveat: if there is no discarded traffic from your Low and Medium priority queues when you get problems with high priority traffic like VoIP, etc. then you may as well have QOS switched off (or you may just have a crappy hub/router/ISP dropping traffic like we found). 


Still very interested other people's experience of QOS for controlling both up and downlink traffic.  

1. Using it on multiple interfaces? 
2. Using it in both directions?
3. Using it for  Dual Uplink?

Thanks in advance and Best Regards,

[ QUOTE ]
Hi William,

Setup steps for me:
- Used ADSL router to find actual negotiated bandwidths.  
- Set Astaro up/downlink to that minus 10%.  
- Used LiveLog to ensure ftp=low & RA=high filter rules were triggering.
- Monitored transmitted real audio streams using separate internet connection.  
- Used Astaro to monitor for QOS discarding traffic from low and medium priority queues.

We found the high priority RealAudio transmission for a customer was still dropping out.  This was nothing to do with QOS but everthing to do with a crappy hub.  Its collision lights were flashing on simultaneously whenever we triggered heavy FTP traffic.  Ditched that for a £60 hub.  Problem solved.  No dropouts.  

In Astaro we then throttled back the allowed uplink bandwidth from 200k to 20k to prove the QOS functionality.  The FTP traffic was strangled off to a crawl relative to the RA traffic.  RA traffic happily consumed the same 16k as before.  

My conclusion: QOS does exactly what is says on the tin.  

Caveat: if there is no discarded traffic from your Low and Medium priority queues when you get problems with high priority traffic like VoIP, etc. then you may as well have QOS switched off (or you may just have a crappy hub/router/ISP dropping traffic like we found). 


Still very interested other people's experience of QOS for controlling both up and downlink traffic.  

1. Using it on multiple interfaces? 
2. Using it in both directions?
3. Using it for  Dual Uplink?

Thanks in advance and Best Regards, 

[/ QUOTE ]
You said you scaled back the allowed upload.  Could you post a screenie of your QOS settings in your webadin please?

William,

Let me restate what I did to make uplink QOS work:

1. Set uplink BW for QOS to less that the actual effective uplink bandwidth of the ISP. 
2. Made sure the right packet filter rules caught the right traffic types, i.e. the low priority rules caught the low priority traffic, etc.  
3. Then kept reducing the uplink BW for QOS until I saw QOS discarding packets from Low, then the Medium and eventually the high priority queues.

This confirmed that uplink QOS was working as designed.  Once we confirmed this - we started looknig for the real reason for the apparent QOS problem - and found a crappy hub.  Your problem may be PMTU from your server to the internet.  It may be lack of CPU power.  It may be random packet discards in the ISP when your uplink utilisation exceeds, say 30k.  It could be a million reasons.  Your V4 QOS might have worked because it only ever chucked out 29k but the new one can chuck out 120k.  I really dont know. 

Please confirm yourself using similar steps to the above and post your findings. 

Then can we please get back to my orginal questions?

Adrien.

[ QUOTE ]
William,

Let me restate what I did to make uplink QOS work:

1. Set uplink BW for QOS to less that the actual effective uplink bandwidth of the ISP. 
2. Made sure the right packet filter rules caught the right traffic types, i.e. the low priority rules caught the low priority traffic, etc.  
3. Then kept reducing the uplink BW for QOS until I saw QOS discarding packets from Low, then the Medium and eventually the high priority queues.

This confirmed that uplink QOS was working as designed.  Once we confirmed this - we started looknig for the real reason for the apparent QOS problem - and found a crappy hub.  Your problem may be PMTU from your server to the internet.  It may be lack of CPU power.  It may be random packet discards in the ISP when your uplink utilisation exceeds, say 30k.  It could be a million reasons.  Your V4 QOS might have worked because it only ever chucked out 29k but the new one can chuck out 120k.  I really dont know. 

Please confirm yourself using similar steps to the above and post your findings. 

Then can we please get back to my orginal questions?

Adrien. 

[/ QUOTE ]
https://community.sophos.com/products/unified-threat-management/astaroorg/f/61/t/57046

Hi,

Do these assumptions stack up for more experienced people here, please?

1. Any packet filter rule (for say FTP) will mark packets travelling in both directions as Low, Medium or High - default being Medium.  

2. Overload of the ingress port (download QOS) results in randomly selected packets being discarded regardless of whether they may be low(p2p), medium or high(voip) priority.

3. It is only on egress from the firewall (both internal or external interfaces) that the lower priority packets can be discarded in favour of higher priority packets.

4. The QOS policy must be designed to avoid packet discards on ingress(download) in favour of egress(upload) to protect high priority traffic.

5. The QOS setting 1024:512:128:128: sets maximum allowed bandwidths, i.e. it is not bandwidth reservation.  So 1024:512:1024:128 would be valid.... 

6. Its right to enable/set QOS on all the physical ports.


Thanks in advance,

Adrien.
p.s. my current half tested QOS setup in graphic

Hi,

Do these assumptions stack up for more experienced people here, please?

1. Any packet filter rule (for say FTP) will mark packets travelling in both directions as Low, Medium or High - default being Medium.  

2. Overload of the ingress port (download QOS) results in randomly selected packets being discarded regardless of whether they may be low(p2p), medium or high(voip) priority.

3. It is only on egress from the firewall (both internal or external interfaces) that the lower priority packets can be discarded in favour of higher priority packets.

4. The QOS policy must be designed to avoid packet discards on ingress(download) in favour of egress(upload) to protect high priority traffic.

5. The QOS setting 1024:512:128:128: sets maximum allowed bandwidths, i.e. it is not bandwidth reservation.  So 1024:512:1024:128 would be valid.... 

6. Its right to enable/set QOS on all the physical ports.


Thanks in advance,

Adrien.
p.s. my current half tested QOS setup in graphic

[ QUOTE ]
Hi,

Do these assumptions stack up for more experienced people here, please?

1. Any packet filter rule (for say FTP) will mark packets travelling in both directions as Low, Medium or High - default being Medium.  

2. Overload of the ingress port (download QOS) results in randomly selected packets being discarded regardless of whether they may be low(p2p), medium or high(voip) priority.

3. It is only on egress from the firewall (both internal or external interfaces) that the lower priority packets can be discarded in favour of higher priority packets.

4. The QOS policy must be designed to avoid packet discards on ingress(download) in favour of egress(upload) to protect high priority traffic.

5. The QOS setting 1024:512:128:128: sets maximum allowed bandwidths, i.e. it is not bandwidth reservation.  So 1024:512:1024:128 would be valid.... 

6. Its right to enable/set QOS on all the physical ports.


Thanks in advance,

Adrien.
p.s. my current half tested QOS setup in graphic 

[/ QUOTE ]
1. Technically yes
2. no.  downloaded data canot be qosed as this time if ever jsut due to te nature of tcp/ip.
3.  yes
4.  not really.  QOS is only effective on egress not ingress
5.  I don't know on that one.
6.  yes