Subject: bridge and ARP reply mac address issue
To: None <tech-net@netbsd.org>
From: Manuel Bouyer <bouyer@antioche.eu.org>
List: tech-net
Date: 06/10/2006 16:41:58
Hi,
I've a very strange issue with a ipf-enabled bridge and arp replies:
The setup:
bridge6: flags=41<UP,RUNNING>
        Configuration:
                priority 32768 hellotime 2 fwddelay 15 maxage 20
                ipfilter enabled flags 0x1
        Interfaces:
                xvif16.0 flags=3<LEARNING,DISCOVER>
                        port 97 priority 128
                xvif14.1 flags=3<LEARNING,DISCOVER>
                        port 78 priority 128
                xvif13.1 flags=3<LEARNING,DISCOVER>
                        port 70 priority 128
                vlan6 flags=3<LEARNING,DISCOVER>
                        port 5 priority 128
xvif16.0: flags=8963<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        address: aa:01:00:01:02:00
        inet6 fe80::a801:ff:fe01:200%xvif16.0 prefixlen 64 scopeid 0x61
xvif14.1: flags=89e3<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        address: aa:01:00:01:01:01
        inet6 fe80::a801:ff:fe01:101%xvif14.1 prefixlen 64 scopeid 0x4e
xvif13.1: flags=8963<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        address: aa:01:00:01:03:02
        inet6 fe80::a801:ff:fe01:302%xvif13.1 prefixlen 64 scopeid 0x46
vlan6: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        vlan: 6 parent: wm0
        address: 00:13:72:54:ee:13
        inet a.b.c.d netmask 0xfffffff0 broadcast a.b.c.31
        inet6 fe80::213:72ff:fe54:ee13%vlan6 prefixlen 64 scopeid 0x5


The problem is that arp replies for a.b.c.d either give mac address of
vlan6 or xvif14.1. This cause issues with ipf (as the packets for a.b.c.d comes
from the wrong interface it's filtered) and I can't see why this happens
anyway. I've seen it happen only for xvif14.1. I tried setting -arp on
xvif14.1 but it didn't help. arp requests for a.b.c.d can come from
either interface, and the address in the reply isn't related to the
interface the request came from.

Anyone else seen this ? Any idea what could cause this to happen ?

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--