Bandwidthd always promiscuous?



  • Thought I'd have a go with bandwidthd, to keep an eye on things, but whenever I install, then copy a file from my fileserver, CPU on pfSense hits the roof even though it has no part in the traffic ???

    Note: I am running pfSense in a VM (VMWare server) on the fileserver box, the LAN interface (that I have asked bandwidthd to monitor) is bridged straight to the internal LAN that the fileserver is using.

    Apart from this small  ;) problem, it behaves fine.



  • i noticed that too
    p.s. using exactly the same configuration



  • I think this is a vmware problem. Networkperformance of vmware is not that good and running an interface in promiscous mode will add additional load.



  • @hoba:

    I think this is a vmware problem. Networkperformance of vmware is not that good and running an interface in promiscous mode will add additional load.

    Hoba, the VMWare load I understand, I was just surprised that monitoing the traffic that hit pfsense from the LAN (not all traffic on the network) set the interface into promiscuous mode.  The VMware hit for broadband levels of traffic is trivial, going promiscuous on a busy Gb LAN is a problem!



  • @Pootle:

    Thought I'd have a go with bandwidthd, to keep an eye on things, but whenever I install, then copy a file from my fileserver, CPU on pfSense hits the roof even though it has no part in the traffic ???

    Because in promiscuous mode it's going to see that file server traffic (assuming it's another VM on the same segment) because all VM's on a segment act like a hub. You're pegging the box because it's seeing and monitoring all that traffic.

    bandwidthd may require promiscuous mode to function, though it would be worth investigating if that's really required if someone cares to do so.



  • It is required unfortunately.



  • It's not that big of a deal. It'll only happen if you:

    1. Use a hub - Seriously, nobody should ever be using hubs anymore unless they actually do want to see all traffic.
    2. Use VM's on the same segment - putting your firewall on a separate VM network should be feasible and fix this
    3. have your firewall on a SPAN port - don't do that.

Log in to reply