With 10 bpf devices, I was no longer able to do a tcpdump on any interface.
#tcpdump -nnnvvvi bnx1 proto pfsync tcpdump: Failed to open bpf device for bnx1: No such file or directory Once I stopped ladvd, the tcpdump started working properly again. #tcpdump -nnnvvvi bnx1 proto pfsync tcpdump: listening on bnx1, link-type EN10MB This is on amd64 (in case it changes anything) On Tue, Feb 1, 2011 at 11:13 AM, Bret S. Lambert <bret.lamb...@gmail.com>wrote: > On Tue, Feb 01, 2011 at 09:23:05AM -0500, Steve Johnson wrote: > > Hi, > > > > I wanted to know what was the restriction on BPF devices and how to > possibly > > go around it. We are currently running a 4.8 GENERIC.MP system with 3 > > dhcrelay processes (and would need to run more very soon), along with > ladvd > > daemon for CDP and they are consuming pretty much all of the 10 BPF > devices > > that I have read the system gives by default. > > Have you actually tried running it to more than 10 devices? My quick > scan of sys/net/bpf.c didn't show a limitation in the open function. > > > > > #fstat|grep bpf > > _dhcp dhcrelay 20698 4 / 52709 crw------- rw bpf8 > > _dhcp dhcrelay 448 4 / 52708 crw------- rw bpf7 > > _dhcp dhcrelay 25248 4 / 52707 crw------- rw bpf6 > > root ladvd 20897 9 / 52702 crw------- rw bpf1 > > root ladvd 20897 10 / 52703 crw------- rw bpf2 > > root ladvd 20897 11 / 52704 crw------- rw bpf3 > > root ladvd 20897 12 / 52705 crw------- rw bpf4 > > root ladvd 20897 13 / 52706 crw------- rw bpf5 > > root ladvd 20897 14 / 52710 crw------- rw bpf9 > > _pflogd pflogd 6391 3 / 52701 crw------- rw bpf0 > > root pflogd 1561 3 / 52701 crw------- rw bpf0 > > > > > > Is there any way to increase that number and if so, would this be a bad > > practice? If need be I can always stop ladvd, but ideally we'd rather > have > > it on. > > > > Thanks, > > Steve Johnson
