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

shanel@datatorque.com