Re: NetBSD 5 partly freezing, may be related to 802.1Q

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sun, Jun 03, 2012 at 10:35:17AM +0200, iMil wrote:
> Hi,
> 
> My home gateway is running NetBSD for ages, for about 2 years it's working
> with NetBSD 5, and as we speak, NetBSD 5.1_STABLE.
> 
> Since 5.1.2, I made that server 802.1Q-aware in the way the NIC connected
> to my private networks has 2 tagged VLANs, served by a Foundry ServerIron
> switch.
> 
> Regularly, this machine will partly freeze, in the way that established
> connections within my network and the outside world still work as of
> incoming NAT, but no new connection is able to be made.
> The server itself does not panic, and when I try to physically type
> something, the first keystroke will appear but no more than that. Pressing
> the power button will show the ACPI state going on but the process will
> not complete, it will stop most of time at "syncing disks".
> 
> That behaviour started when I splitted the private interface into 2
> tagged VLANs, and it seems to happen faster when more traffic is made. One
> of those VLANs actually serve my own network, and the other one is
> dedicated for an open wireless network, which obviously is more active in
> terms of DHCP connections and PF-based filtering.
> 
> First I thought it was related to the Intel card (fxp0 i82558 Ethernet),
> so I changed it in favour of a RealTek 8169/8110 Gigabit Ethernet (re0),
> unfortunately I have the exact same issue.
> 
> The setup is a bit more complex that just 2 networks NATted to the
> Internet:
> 
> . The first VLAN is mostly NATted to my real public IP address, but some
>   IPs from this LAN would be routed through a tunneled (openvpn) iface.
> 
> . The second VLAN has no right to communicate with the first one (pf), and
>   has its default route going through a GRE tunnel which is connected
>   throught an IPsec tunnel. This network also has basic QoS rules.
> 
> Unfortunately, no logs are available, no panic trace, no kernel dump,
> which makes it pretty hard to investigate.
> 
> Does this behaviour ring a bell for anyone?

watch the number of mbuf clusters (with vmstat -m this is mclpl) and check
that you're not reaching the limit. 

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--