|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] memory leaks resolved?
I think I may have fixed my memory leaks, and it may be that it was
nothing to do with xen... the machine has been up for 10 days now which
is the longest it has lasted in quite a while.
I changed the way the bridges and vlans worked together, previously I
had it configured thus:
trunk = renamed Ethernet interface
br0 = bridge of trunk and any domU I wanted on vlan1
br0.2 = vlan 2 on trunk
br1 = bridge of br0.2 and any domU I wanted on vlan2
but now I have it configured thus:
trunk = renamed Ethernet interface
trunk.2 = vlan 2 on trunk
br0 = bridge of trunk and any domU I wanted on vlan1
br1 = bridge of trunk.2 and any domU I wanted on vlan2
The latter config makes much more sense, but I could never get it
working, nothing on br1 would ever work. Recently though I discovered I
needed the following rule for ebtables:
ebtables -t broute -D BROUTING -p 802_1Q -i trunk -j DROP
which selects packets using dot1q encapsulation on interface trunk, and
DROPs them from the broute table, which means they don't get routed
through the bridge. Because the bridge interface then doesn't pick them
up, they are available for the vlan logic and so appear on trunk.X
One of the side effects of my former config was that any domU on br0
would see trunked packets too, which is inefficient, and also packets of
1504 bytes are possible which the domU kernel complained about in great
volumes of log messages (note that this was the domU kernel, which never
leaked memory).
So maybe the bug is in the kernel, and affects people who have combined
bridging and vlans and don't know what they are doing (eg me :)?
Is anyone else still seeing memory leaks?
Thanks
James
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread> |
- [Xen-devel] memory leaks resolved?,
James Harper <=
|
|
|
|
|