Hello, all. If someone happens to know this off the top of their head, it will save me a few hours of testing. I know that I need to shape each physical interface individually when using bridged interfaces, e.g., shape eth0 and eth1 rather than br0. However, what about bonded interfaces? I have to implement such a scenario under a tight deadline. I am assuming that, unlike bridging, we shape the bond interface and not the physical interfaces, i.e., we shape bond0 and not eth0 and eth1. Is that correct? Less important: This is related to my previous post about 95th percentile shaping. I gather from the lack of response that there is not an easy way to do that so I'm off to develop a script to do so on our bonded Internet interfaces. To try to make it stand alone rather than an integration with the monitoring system, I'm planning on a script to grab the TX and RX byte counts from ip -s link ls <IF>, dump the amount into a file, then subtract the old amount from the current amount, dump the difference to another file and replace the starting value in the first file. Would I be correct to assume that the counters are 32 bits (to account for wrapping)? It appears to be the case in our CentOS 5.7 boxes I do not know if I can assume that for newer kernels. I was originally planning to have two levels of throttling, i.e., when 95th percentile got moderately close, throttle the T3 back to something like 8Mbps so there is not such a drastic drop and, if it got dangerously close, throttle it back to the purchased T1. But I think that will backfire. By slowing down a large transmission, it will spread the elevated level over more samples meaning it is more rather than less likely I'll exceed my bandwidth at 95th percentile. If traffic is bursting, it would seem the faster the better in thiss billing method thus, if I am getting dangerously close, I should drop immediately from T3 to T1. Is that correct? Thanks - John -- To unsubscribe from this list: send the line "unsubscribe lartc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
