WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] Linux Traffic Shaping concept for Xen

On Sun, 2007-01-07 at 12:39 +0100, Timo Benk wrote:
> Tim Post wrote:
> >>> And a handy place to stick SNORT and others. I've tried this kind of
> >>> setup but it's been 'choppy' at best. I'm also rather new to ebtables,
> >>> I'm assuming you would use ebtables to craft this, do you have some
> >>> scripts that you'd like to share?
> >> why choppy? It works on my side. BTW, no ebtables is needed to achieve
> >> traffic shaping. You can stick your tc rules inside Dom0 at the
> >> vif-Interfaces of the gateway domain. It is nothing more than tc-magic;-)
> >>
> > 
[ snip ]
> 
> Do you have set the mtu/burst/cburst Parameters for your tc rules? They
> are necessary cause of some giant packet problem i stumbled across some
> time ago.
> 
> E.g.:
> tc class add dev eth0 parent 1:0 \
> classid 1:101 htb                \
> rate 1000kbit mtu 16000 cburst 16000 burst 16000
> 

No, I just left them at default assuming tc would just use sane/senisble
values. Specifying them helped immensely. I'm playing with it now on my
home lab with 3.0.4, and its working better.

I'm assuming the latency was also due to CPU (i/o), it was most
noticeable during backup cycles, and I had paranoid logging set while
testing it. 

Adding mtu/burst/cburst seems to have cleared that up (and a much lower
loglevel).

I'm trying to build a paravirtualized appliance similar to a webmux,
with some extra added security features offered by snort, as well as the
URL sanatizing possible with pound and its load balancing capabilities.
If I come up with something half way useful I'll send it to jailtime so
others can play with it.

> Or do you use HVM domains? HVM domains are quite unusable at the current
> state 'cause of the heavy IO-overhead of the qemu drivers.

A few of them were, I later ended up using all para-virtualized guests
for simplicity and reliability. The biggest problem however was
malformed tc commands, which you so thoughtfully helped me fix :) Much
appreciated!

Best,
--Tim



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users