Heya In the network: OpenBSD Firewall (x2) <--> Metropolitan Layer 2 Network <--> ISP(s)
CARP advertisements are forming some 7% of the 'noise' traffic across the Metro L2 resulting in complaints from other clients of the Metro L2 provider. All production and testing done with: OpenBSD 4.0 release + errata OpenBSD 4.1 release + errata I have read through the 4.1 to 4.2 changes documentation (http://www.openbsd.org/plus42.html). I can see nothing there that would alter the below results. Thanks in advance for all suggestions and/or recommendations. I have some Feature Requests as a result of this testing, but will hold off on those until feedback is received. :) Upon receiving a request from the L2 provider, we thought of or tried the following: * Unicast CARP advertisements; Unlike pfsync, CARP does not currently have support for Unicast communications. * lladdr filtering by the L2 provider; All of the CARP advertisements are coming from the shared lladdr of the carp interface, not from the lladdr of the carpdev's. (True also on the other carp interfaces.) * netstart + pf + ifstated; Start the external facing carpdev's configured and down and the internal facing carpdev's configured and up on boot. Use pf to explicitly allow CARP advertisements on the internal facing carpdev's and block all others (including the external facing carpdev's). Use ifstated to monitor the state changes on the internal facing carp devices. Run 'ifconfig $carp [up|down]' on the external facing carp devices depending upon the state of the internal facing carp devices. /etc/netstart currently does not deal with configuring and then setting an interface to down upon boot. example /etc/hostname.if: inet 192.168.0.1 255.255.255.0 NONE down CARP seems inconsistent in its handling of the carpdev status. Discovered that upon booting with all physical cables unplugged that carp interfaces enter master state despite carpdev's (em - Intel PRO/1000 10/100/Gigabit Ethernet devices) not having physical network connectivity. In general, this setup is not considered an optimal solution anyway. Thanks Again Shane Lazarus Infrastructure Engineer DataTorque +64 21 529278 [EMAIL PROTECTED]
