CARP over Linux bridge interface

[froggie]

Ik heb twee Xen Server 5.5 systemen, onderling verbonden met een switch. Op beide systemen draait dmv hardware virtualisatie een virtuele machine met pfSense 1.2.3 (FreeBSD 7.2 met een sausje) welke dienst doen als gevirtualiseerde firewalls voor andere VM's. Tussen deze firewalls is dmv CARP een aantal virtuale ip adressen geconfigureerd zodat beide fw's een enkel high available cluster vormen. Dit laatste blijkt echter problematisch doordat de CARP advertisements van beide firewalls elkaar niet bereiken. Onderstaande is een wat grafischer voorstelling van het scenario:

code:

+--------+ +--------+       +--------+ +--------+
|  fw01  | |  vm 2  |       |  fw02  | |  vm 4  |
+---+----+ +----+---+       +---+----+ +----+---+
    |           |               |           |
+---+----+ +----+---+       +---+----+ +----+---+ 
| tap1.0 | | vif2.0 |       | tap3.0 | | vif4.0 |
+---+----+ +----+---+       +---+----+ +----+---+
    |           |               |           |
+---+-----------+---+       +---+-----------+---+
|      xenbr0       |       |      xenbr0       |
+---------+---------+       +---------+---------+
          |                           |
    +-----+-----+               +-----+-----+
    |  bond0.4  |               |  bond0.4  |
    +-----+-----+               +-----+-----+
          |                           |
    +-----+-----+               +-----+-----+
    |   bond0   |               |   bond0   |
    +-----+-----+               +-----+-----+
          |        +---------+        |
          +--------+ 3C4200G +--------+
                   +---------+

Enige toelichting: beide firewalls zijn dmv een tap interface verbonden met een Linux bridge, xenbr0. Op beide servers zijn vlan interfaces beschikbaar in de vorm van bond0.x interfaces welke gebruik maken van bond0 als uitgaande interface.

Wanneer ik op beide firewalls een tcpdump doe op hun lokale interfaces zie ik het volgende:

op fw01:

# tcpdump -i re1 -e -n vrrp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re1, link-type EN10MB (Ethernet), capture size 96 bytes
15:03:07.347837 00:00:5e:00:01:fe > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.101.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 254, prio 0, authtype none, intvl 1s, length 36

op fw02:

# tcpdump -i re1 -e -n vrrp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re1, link-type EN10MB (Ethernet), capture size 96 bytes
15:03:08.006842 00:00:5e:00:01:fe > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.101.12 > 224.0.0.18: VRRPv2, Advertisement, vrid 254, prio 100, authtype none, intvl 1s, length 36

Beide firewalls zien dus alleen hun eigen, uitgaande advertisements. Wanneer ik echter op beide Xen servers een tcpdump doe op interface bond0.4 zie ik de advertisements van beide firewalls. Kortom, ze worden wel verstuurd, komen ook goed door de switch, maar lijken bij het binnenkomen op xenbr0 te worden gedropt. Wanneer ik met 'brctl showmacs xenbr0' naar de mac table kijk van beide bridges zie ik het door beide fw's gebruikte sources adres 00:00:5e:00:01:fe achter de bridge port zitten waar ik ze verwacht (die van de tap device van de firewall op de betreffende Xen server).

Om wat meer inzicht te krijgen in het probleem heb ik met verschillende bridge configuraties zitten prutsen. Hieruit blijkt dat wanneer ik beide fw's op dezelfde Xen server draai, en ze dus verbonden zijn met dezelfde bridge de advertisements wel netjes aankomen en CARP werkt zoals verwacht. Wanneer in dit scenario echter geen echt ethernet device met de bridge verbonden is (dus alleen de tap devices), dan komt meestal van een van beide fw's de advertisements aan. Vaak is dit de backup firewall waardoor CARP op beide fw's de virtual ip's actief maakt. In het laatste scenario zijn de resultaten echter niet altijd te voorspellen, soms komen de juiste advertisements door en werkt CARP goed, maar meestal gaat het verkeerd.

Kortom; is het mogelijk om de advertisments betrouwbaar over de bridge interfaces te krijgen zodat CARP kan werken zoals het bedoelt is? Kan het zijn dat bij het binnenkomen van de bridge het source adres van een pakket bekeken wordt en wanneer deze van een andere port komt dan de port die in de mac table bekend is deze gedropt wordt? Zo ja, waarom werkt het scenario van een fysiek device en beide tap devices aan dezelfde bridge wel en andere scenario's niet? Iemand een idee waar ik naar kan kijken?