Xen users - Nov 2011 - dom0 - oom-killer - memory leak somewhere ?

Hello,

I work in a hosting company, we have tens of Xen dom0 running just fine, 
but unfortunately we do have a few that get out of control.

Reported behaviour :
- dom0 uses more and more memory
- no process can be found using that memory
- at some point, oom killer kicks in, and kills everything, until even 
ssh the box becomes hard
- when there is really no more process to kill, it crashes even more, 
and we are forced to reboot

Configuration summary :
- dom0 with debian/stable, xen 4.0.1
- 512MB, or up to 2GB after some crash


I have tryed to find something that differs between a working dom0 and a 
buggy one, but didn''t manage to find anything. Install from the same 
template, same packages, same hardware (but serials and mac addresses).


I didn''t manage to find anything about leak in dom0 ending up with oom 
killer without doubt.

I tried to gather as much log as i thought could be helpful in attachments.
Host bk - about to get a reboot, as xend already got killed
Host sw - 800MB/2GB used for nothing,

Attachments contains :

- memory graph (by munin) - it might help to see the pattern of memory usage

cat from :
- grub.cfg
- /proc/meminfo
- /proc/slabinfo
- /proc/vmstat
- /var/log/kern.log
- /var/log/xen/xend.log

Result from :
- dmesg
- dpkg -l
- free
- lsmod
- top
- vmstat
- xm info
- xm info -c


I''d appreciate any feedback about such behaviour, and would be happy to
provide additional information.
Those are productions servers, the only thing i''d really like to avoid 
as much as possible is rebooting them for tests.


Regards,

-- 
Adrien URBAN




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

Hello,

I work in a hosting company, we have tens of Xen dom0 running just fine,
but unfortunately we do have a few that get out of control.

Reported behaviour :
- dom0 uses more and more memory
- no process can be found using that memory
- at some point, oom killer kicks in, and kills everything, until even
ssh the box becomes hard
- when there is really no more process to kill, it crashes even more,
and we are forced to reboot

Configuration summary :
- dom0 with debian/stable, xen 4.0.1
- 512MB, or up to 2GB after some crash


I have tried to find something that differs between a working dom0 and a
buggy one, but didn''t manage to find anything. Install from the same
template, same packages, same hardware (but serials and mac addresses).


I didn''t manage to find anything about leak in dom0 ending up with oom
killer without doubt.

I tried to gather as much log as i thought could be helpful in
attachments[1].
Host bk - about to get a reboot, as xend already got killed
Host sw - 800MB/2GB used for nothing,

Attachments[1] contains :

- memory graph (by munin) - it might help to see the pattern of memory
usage

cat from :
- grub.cfg
- /proc/meminfo
- /proc/slabinfo
- /proc/vmstat
- /var/log/kern.log
- /var/log/xen/xend.log

Result from :
- dmesg
- dpkg -l
- free
- lsmod
- top
- vmstat
- xm info
- xm info -c


I''d appreciate any feedback about such behaviour, and would be happy to
provide additional information.
Those are productions servers, the only thing i''d really like to avoid
as much as possible is rebooting them for tests.


Regards,

-- 
Adrien URBAN

[1] Sent an email with files as attachments a few days ago, but it never
made the list.
Files can be found here : http://www.hagtheil.net/xen/oom/


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

On Sun, Nov 13, 2011 at 4:29 PM, Adrien Urban
<adrien.urban@nbs-system.com> wrote:
>
> Hello,
>
> I work in a hosting company, we have tens of Xen dom0 running just fine,
> but unfortunately we do have a few that get out of control.
>
> Reported behaviour :
> - dom0 uses more and more memory
> - no process can be found using that memory
Does the dom0 also serve as some kind of file server (e.g. nfs, web)
with lost of files (e.g. several hundred GBs)?

If yes, you might need to set /proc/sys/vm/vfs_cache_pressure to 1000
(or any value over 100). More details:
http://rackerhacker.com/2008/12/03/reducing-inode-and-dentry-caches-to-keep-oom-killer-at-bay/

-- 
Fajar

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

On 11/13/11 12:19, Fajar A. Nugraha wrote:
> > On Sun, Nov 13, 2011 at 4:29 PM, Adrien Urban
> > <adrien.urban@nbs-system.com> wrote:
>> >>
>> >> Hello,
>> >>
>> >> I work in a hosting company, we have tens of Xen dom0 running
just
fine,
>> >> but unfortunately we do have a few that get out of control.
>> >>
>> >> Reported behaviour :
>> >> - dom0 uses more and more memory
>> >> - no process can be found using that memory
> >
> > Does the dom0 also serve as some kind of file server (e.g. nfs, web)
> > with lost of files (e.g. several hundred GBs)?
> >
> > If yes, you might need to set /proc/sys/vm/vfs_cache_pressure to 1000
> > (or any value over 100). More details:
> >
http://rackerhacker.com/2008/12/03/reducing-inode-and-dentry-caches-to-keep-oom-killer-at-bay/
> >
Hello,

Thanks to point it out, unfortunately, it doesn''t seem to be the case.

The Dom0 don''t have anything running but xen, lvm, and some monitoring
services (munin, and nrpe).

I tried to do what is mentioned on this page, but didn''t get any real
down in memory usage.


I tried to check slabs and compare between 2 hosts, one working, and the
other not. Couldn''t find anything off the chart for our memory leak.


Checking /proc/slabinfo, header states :

# name            <active_objs> <num_objs> <objsize>
<objperslab>
<pagesperslab> : tunables <limit> <batchcount>
<sharedfactor> : slabdata
<active_slabs> <num_slabs> <sharedavail>


I tried to take :
- pagesperslab * active_slabs
- sum up all lines

That should get a total of pages in slabs.



Working host :
# free
             total       used       free     shared    buffers     cached
Mem:        520028     478308      41720          0      72792     204828
-/+ buffers/cache:     200688     319340
Swap:      1044472       6380    1038092


Total pages in slabs: 8416


Non-working host :
# free
             total       used       free     shared    buffers     cached
Mem:       2092892    1501968     590924          0       2296      25200
-/+ buffers/cache:    1474472     618420
Swap:      1998840          0    1998840

Total pages in slabs : 5855


I think those pages are 4k pages. That means slabs are using 34M or 24M
on those hosts. Nothing like the 1GB i can''t find.


Regards,
Adrien

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

hello,

I experienced and sometimes still experience the same. But I think I found a 
reason...or at least one cause of possibly more.

If a domu uses swap and swaps out too much and theres much io on the backend 
(tap, file or isci in my configs) the concerned xenstrored consumes the ram 
for writing to the backend..which starts lagging ugly.

So, for the buggy domains I first suggest:
a) check available ram/check for swapping
b) for testing purposes disable swap
c) I think its most horrible on tap:aio, and normal loop-diskimages. Try to 
switch the backend if you use one of the mentioned.

Meanwhile I started over with no swap for my domus at all, and if RAM is 
needed (oom killer acts in vm ) I balloon it in, or check for the reason - for 
me this is a possible way and is a good workaround.

My Dom0s are not up-to-date, perhaps the behaviour is
"fixed"/different in
newer versions than mine (at least 4.0 showes this from time to time).

But, as I say this, it may be something totally different on your side.

Cheers,

Holger

Am Donnerstag, 10. November 2011 13:56:03 schrieb Adrien
Urban:
> Hello,
> 
> I work in a hosting company, we have tens of Xen dom0 running just fine,
> but unfortunately we do have a few that get out of control.
> 
> Reported behaviour :
> - dom0 uses more and more memory
> - no process can be found using that memory
> - at some point, oom killer kicks in, and kills everything, until even
> ssh the box becomes hard
> - when there is really no more process to kill, it crashes even more,
> and we are forced to reboot
> 
> Configuration summary :
> - dom0 with debian/stable, xen 4.0.1
> - 512MB, or up to 2GB after some crash
> 
> 
> I have tryed to find something that differs between a working dom0 and a
> buggy one, but didn''t manage to find anything. Install from the
same
> template, same packages, same hardware (but serials and mac addresses).
> 
> 
> I didn''t manage to find anything about leak in dom0 ending up with
oom
> killer without doubt.
> 
> I tried to gather as much log as i thought could be helpful in attachments.
> Host bk - about to get a reboot, as xend already got killed
> Host sw - 800MB/2GB used for nothing,
> 
> Attachments contains :
> 
> - memory graph (by munin) - it might help to see the pattern of memory
> usage
> 
> cat from :
> - grub.cfg
> - /proc/meminfo
> - /proc/slabinfo
> - /proc/vmstat
> - /var/log/kern.log
> - /var/log/xen/xend.log
> 
> Result from :
> - dmesg
> - dpkg -l
> - free
> - lsmod
> - top
> - vmstat
> - xm info
> - xm info -c
> 
> 
> I''d appreciate any feedback about such behaviour, and would be
happy to
> provide additional information.
> Those are productions servers, the only thing i''d really like to
avoid
> as much as possible is rebooting them for tests.
> 
> 
> Regards,
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Hello,

On 11/14/11 19:16, iS-Fun Internet Services GmbH, Holger Diehm
wrote:
> I experienced and sometimes still experience the same. But I think I found
a
> reason...or at least one cause of possibly more.
>
> If a domu uses swap and swaps out too much and theres much io on the
backend
> (tap, file or isci in my configs) the concerned xenstrored consumes the ram
> for writing to the backend..which starts lagging ugly.
>
> So, for the buggy domains I first suggest:
> a) check available ram/check for swapping
> b) for testing purposes disable swap
> c) I think its most horrible on tap:aio, and normal loop-diskimages. Try to
> switch the backend if you use one of the mentioned.
Thanks for sharing your input, I did some check for one of our dom0 that
has few DomU.
- no swap on the domU
- almost no memory used for 2/3 dom0 (like 2/16MB), and like 2/4MB for
the last one.
- no pick in network traffic either

Plus we also have 2 dom0 that behave that way that are diskless (full
iscsi), with domU also having their disk directly on the network (doing
iscsi on their own, with just network from dom0, the dom0 doesn''t know
anything about their disks).
> Meanwhile I started over with no swap for my domus at all, and if RAM is 
> needed (oom killer acts in vm ) I balloon it in, or check for the reason -
for
> me this is a possible way and is a good workaround.
Well, before finding what causes it would be a good start. A way to fix
it and/or having a work around would be something we could consider
*once* we figure what''s generating that problem.
> My Dom0s are not up-to-date, perhaps the behaviour is
"fixed"/different in
> newer versions than mine (at least 4.0 showes this from time to time).
>
> But, as I say this, it may be something totally different on your side.
If yours is definitely from swap usage, ours has to be different... :(

Regards,
Adrien Urban

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

On 11/10/2011 4:56 AM, Adrien Urban wrote:
> Hello,
>
> I work in a hosting company, we have tens of Xen dom0 running just 
> fine, but unfortunately we do have a few that get out of control.
>
> Reported behaviour :
> - dom0 uses more and more memory
> - no process can be found using that memory
> - at some point, oom killer kicks in, and kills everything, until even 
> ssh the box becomes hard
> - when there is really no more process to kill, it crashes even more, 
> and we are forced to reboot
>
> Configuration summary :
> - dom0 with debian/stable, xen 4.0.1
> - 512MB, or up to 2GB after some crash
Adrian,

Were you ever able to determine what was using the memory? I had several 
machines at the same location all enter this state this morning at the 
same time, and I can''t find any clues as to what''s exhausting
the
memory, just as you couldn''t. The circumstances suggest that some sort 
of attack or network event was involved, but I''m not seeing significant
traffic levels. One of the machines was brand new (very latest Xen 4.1, 
very latest xen/next-2.6.32) and had no activity otherwise. It''s very 
puzzling.

-John
<http://git.kernel.org/?p=linux/kernel/git/jeremy/xen.git;a=shortlog;h=refs/heads/xen/next-2.6.32>



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

On Thu, Jan 26, 2012 at 11:09:09AM -0800, John Weekes
wrote:
> Were you ever able to determine what was using the memory? I had several 
> machines at the same location all enter this state this morning at the 
> same time, and I can''t find any clues as to what''s
exhausting the
> memory, just as you couldn''t. The circumstances suggest that some
sort
> of attack or network event was involved, but I''m not seeing
significant
> traffic levels. One of the machines was brand new (very latest Xen 4.1, 
> very latest xen/next-2.6.32) and had no activity otherwise. It''s
very
> puzzling.
Huh.   This happened to me way back in the day, but it hasn''t happened
for
years.  

I completely disabled balooning in the dom0.   dom0_mem=1024m.   
for good measure, (enable-dom0-ballooning no) in xend-config.sxp.
I give the thing a gig because, hey, ram is cheap.  I give the thing a 
two gigs of swap because, hey, disk is even cheaper, but it hasn''t been
used.  Back in the day, I''d give it ten, because I thought that I could
login and check things out; Nope.

But yeah;  my experience?  the dom0 balooning (and really, balooning in 
general) is trouble.  I mean, if you want to baloon guests, that''s
fine;
if they go wonky you reboot them.   but rebooting a dom0 is so much 
pain that it''s got to have fixed ram.

Nearly all of my problems of this nature were a result of accidentally
causing the dom0 to baloon.  

and, in your case, I''d setup a logging screen session or something and
run
''top'' sorted by memory use on the offending hosts.   that
should give
you some idea of what''s eating all the ram if it really is a runaway
process.
and check your logs for the dom0 balooning.   It''s on a serial console,
right?

In my servers now 16g memory. Until such time as did restrictions dom0_mem = 
512M and less, the amount of memory capacity increased. After a 512 MB 
limit - I have a situation where the physical memory is occupied, and 
completely empty swap. In this balooning - I do not cut off.
Basic postulate stable operation - Dom0 should have a minimum of software, 
and most importantly do not use the internet through virbr0. For 
distribution network is used as a gateway DomU. And bridges are created 
manually at boot time.

 LSC> On Thu, Jan 26, 2012 at 11:09:09AM -0800, John Weekes wrote:
 ??>> Were you ever able to determine what was using the memory? I had
 ??>> several machines at the same location all enter this state this
 ??>> morning at the same time, and I can''t find any clues as to
what''s
 ??>> exhausting the memory, just as you couldn''t. The
circumstances suggest
 ??>> that some sort of attack or network event was involved, but
I''m not
 ??>> seeing significant traffic levels. One of the machines was brand new
 ??>> (very latest Xen 4.1, very latest xen/next-2.6.32) and had no
activity
 ??>> otherwise. It''s very puzzling.

 LSC> Huh.   This happened to me way back in the day, but it hasn''t
happened
 LSC> for years.

 LSC> I completely disabled balooning in the dom0.   dom0_mem=1024m.
 LSC> for good measure, (enable-dom0-ballooning no) in xend-config.sxp.
 LSC> I give the thing a gig because, hey, ram is cheap.  I give the thing a
 LSC> two gigs of swap because, hey, disk is even cheaper, but it
hasn''t
 LSC> been used.  Back in the day, I''d give it ten, because I
thought that I
 LSC> could login and check things out; Nope.

 LSC> But yeah;  my experience?  the dom0 balooning (and really, balooning
 LSC> in general) is trouble.  I mean, if you want to baloon guests,
that''s
 LSC> fine; if they go wonky you reboot them.   but rebooting a dom0 is so
 LSC> much pain that it''s got to have fixed ram.

 LSC> Nearly all of my problems of this nature were a result of accidentally
 LSC> causing the dom0 to baloon.

 LSC> and, in your case, I''d setup a logging screen session or
something and
 LSC> run ''top'' sorted by memory use on the offending
hosts.   that should
 LSC> give you some idea of what''s eating all the ram if it really
is a
 LSC> runaway process. and check your logs for the dom0 balooning.  
It''s on
 LSC> a serial console, right?

On 1/26/2012 12:06 PM, Likarpenkov Alexander wrote:
> In my servers now 16g memory. Until such time as did restrictions 
> dom0_mem = 512M and less, the amount of memory capacity increased. 
> After a 512 MB limit - I have a situation where the physical memory is 
> occupied, and completely empty swap. In this balooning - I do not cut 
> off.
> Basic postulate stable operation - Dom0 should have a minimum of 
> software, and most importantly do not use the internet through virbr0. 
> For distribution network is used as a gateway DomU. And bridges are 
> created manually at boot time.
As a result of lessons learned years ago, I keep dom0 small (<2 GB), and 
only stubdom-based HVM and straight PV domains are used. xend is not 
used to manage networking.

To clarify, a machine is still running, and partially usable. It has 
mysterious memory usage (~1.5 GB of it) that does not show in "top" or
"slabinfo", and I am trying to determine what''s consuming it.
This will
in turn hopefully tell me more about how to avoid the situation in the 
future.

-John

On 1/26/2012 11:32 AM, Luke S. Crawford wrote:
> But yeah; my experience? the dom0 balooning (and really, balooning in 
> general) is trouble. 
My experience has been the same, so ballooning is completely disabled on 
this machine.
> run ''top'' sorted by memory use on the offending hosts.
that should
> give you some idea of what''s eating all the ram if it really is a 
> runaway process. 
Unfortunately, top shows nothing eating the memory. /proc/slabinfo also 
does not show any offenders. This is the crux of the problem -- there''s
no indication of where the memory is going.
> and check your logs for the dom0 balooning. It''s on a serial
console,
> right? 
One of the machines is still accessible. I''m logged in, and I can run 
commands. Some of them are killed by the OOM-killer as I execute them, 
since it''s so low on memory. There are no indications of it trying to 
balloon, and ballooning is turned off both in the startup line and in 
/etc/xen/xend-config.sxp (as I am using xend).

Since this seems to be the same situation that Adrien Urban is in, I am 
curious if he was able to ultimately determine what was going on.

-John


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

JW> On 1/26/2012 12:06 PM, Likarpenkov Alexander wrote:
 ??>> In my servers now 16g memory. Until such time as did restrictions
 ??>> dom0_mem = 512M and less, the amount of memory capacity increased.
 ??>> After a 512 MB limit - I have a situation where the physical memory
is
 ??>> occupied, and completely empty swap. In this balooning - I do not
cut
 ??>> off.
 ??>> Basic postulate stable operation - Dom0 should have a minimum of
 ??>> software, and most importantly do not use the internet through
virbr0.
 ??>> For distribution network is used as a gateway DomU. And bridges are
 ??>> created manually at boot time.

 JW> As a result of lessons learned years ago, I keep dom0 small (<2 GB),
 JW> and only stubdom-based HVM and straight PV domains are used. xend is
 JW> not used to manage networking.

 JW> To clarify, a machine is still running, and partially usable. It has
 JW> mysterious memory usage (~1.5 GB of it) that does not show in
"top" or
 JW> "slabinfo", and I am trying to determine what''s
consuming it. This will
 JW> in turn hopefully tell me more about how to avoid the situation in the
 JW> future.

Why do you want 2G of memory in the system? 256-512 - the maximum that must 
be escaped.

JW>> To clarify, a machine is still running, and partially usable. It has
 JW>> mysterious memory usage (~1.5 GB of it) that does not show in
"top" or
 JW>> "slabinfo", and I am trying to determine what''s
consuming it. This
 JW>> will in turn hopefully tell me more about how to avoid the situation
 JW>> in the future.

 LA> Why do you want 2G of memory in the system? 256-512 - the maximum that 
 LA> must be escaped.
Live example:
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   512     6     r----- 312947.7
a1                                       13  2048     4     -b---- 160261.1
b1l                                        20   512     5     -b----   4128.0
c2                                           1  4096     5     -b---- 111375.2
c3                                           4   512     5     -b----   6413.4
d70                                          7  1000     1     -b----  77064.5
d73                                          8   512     1     -b---- 236936.1
d74                                         52   768     1     -b----   9664.8
d75                                         43    96     1     -b----  13285.1
d80                                         22   512     5     -b----  50198.7
d82                                         40   768     5     -b----  17667.6
g2                                          38    80     1     -b----  34024.4
g3                                          18   128     1     -b----  42959.0
g4                                          15    96     1     -b----  15601.3
j2                                          41  1024     5     -b----  67919.5
s1                                       6  1024     2     -b----  19571.0
t1                                          21   256     1     -b---- 140284.5
t2                                          12   512     5     -b----  38573.6
t3                                          53   512     5     -b----   7876.8
v01                                         10    90     1     -b----  48120.0
top - 12:23:16 up 9 days, 11:57,  2 users,  load average: 0.03, 0.02, 0.00
Tasks: 323 total,   1 running, 322 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.3%us,  0.9%sy,  0.0%ni, 98.6%id,  0.0%wa,  0.0%hi,  0.1%si,  0.2%st
Mem:    525116k total,   466624k used,    58492k free,    83524k buffers
Swap:  6291432k total,    77296k used,  6214136k free,    30260k cached
=======================top - 12:37:13 up 99 days,  2:32,  1 user,  load average:
0.00, 0.02, 0.00
Tasks: 167 total,   2 running, 165 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni, 98.2%id,  0.4%wa,  0.0%hi,  0.5%si,  0.9%st
Mem:    396092k total,   345132k used,    50960k free,    26372k buffers
Swap:  4194296k total,    33480k used,  4160816k free,    20776k cached
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   386     4     r----- 841133.3
agw2                                        53    96     2     r-----  68666.4
st3                                     60   600     4     -b----   5390.3
v1                                          59   900     4     -b---- 112234.9
v2                                          37   600     1     -b---- 2453511.2
v3                                          45   768     3     r----- 11108890.7
=======================top - 12:02:01 up 149 days, 22:34,  1 user,  load
average: 0.00, 0.00, 0.00
Tasks: 134 total,   2 running, 132 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.1%sy,  0.0%ni, 99.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    236948k total,   226756k used,    10192k free,    60136k buffers
Swap:  5242872k total,    16072k used,  5226800k free,    45384k cached
Domain-0                                     0   231     4     r----- 388824.6
h1                                      101   800     1     -b----   8025.4
st2                                     90   600     4     -b---- 174170.0
z2                                         100    64     1     r----- 215354.4


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

On 01/26/12 20:09, John Weekes wrote:
> Adrian,
>
> Were you ever able to determine what was using the memory? I had 
> several machines at the same location all enter this state this 
> morning at the same time, and I can''t find any clues as to
what''s
> exhausting the memory, just as you couldn''t. The circumstances
suggest
> that some sort of attack or network event was involved, but I''m
not
> seeing significant traffic levels. One of the machines was brand new 
> (very latest Xen 4.1, very latest xen/next-2.6.32) and had no activity 
> otherwise. It''s very puzzling.
>
> -John

Hello,

We managed to resolve this issue this week. Some extended testing 
allowed us to get back with the following information.


We are running debian, 2.6.32-5-xen-amd64. Not 100% sure which debian 
patch level.
2.6.32-5-xen-amd64 (unknown@Debian) #1 SMP Thu May 19 01:16:47 UTC 2011

- the problem also occurs when booting without Xen Hypervisor
- the specific conditions that made the leak triggered is explained bellow

- upgrading to the lastest Debian/stable kernel (2.6.32-41squeeze2) 
seems to fix the bug
2.6.32-5-amd64 (unknown@Debian) #1 SMP Thu Mar 22 17:26:33 UTC 2012
2.6.32-5-xen-amd64 (unknown@Debian) #1 SMP Thu Mar 22 21:14:26 UTC 2012



The bug was due to improper handling (not sure where) of tagged network 
packet, while linux had no vlan out of it.

Our network configuration :
br142           8000.b499baac423a       no              eth0.142
br173           8000.b499baac423a       no              eth0.173
br21            8000.b499baac423a       no              eth0

But we also have the VLAN 12 with traffic that might arrive to the box.

If we add eth0.12 (via the following configuration), the leak doesn''t
hit :

auto br12
iface br12 inet manual
         bridge_ports eth0.12
         bridge_maxwait 0
         bridge_fd 0


Fix:
upgrade the kernel

Supposed work-around, if upgrading is not an easy option :
configure the switch not to send VLAN not known/configured in the kernel 
(alternatively, configure the kernel with the specific vlans)


Regards,

-- 
Adrien URBAN, Expert Systèmes - Réseaux - Sécurité - Responsable SN3
---
www.nbs-system.com, 140 Bd Haussmann, 75008 Paris
Std: +33 158 566 080 / S.Tech: +33 158 566 088 / Fax: +33 158 566 081
Bargento 2012, le 29 mai 2012 au CNIT : www.bargento.com