Bug 192756 - SPAN port on bridge does not span packets originating locally
Summary: SPAN port on bridge does not span packets originating locally
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 8.3-RELEASE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Bugmeister
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-17 17:28 UTC by jbw
Modified: 2025-01-25 01:57 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jbw 2014-08-17 17:28:10 UTC
I have built a firewall/routing box utilizing FreeBSD (8.3-RELEASE) and need to mirror all of the lan-side traffic before it is NATed to another box which will have traffic analysis software running on it.

The firewall box has 4 interfaces: 3 wired (re0, re1, re2) and 1 wireless (ath0).  

re0 is the internet port (WAN), re1 and ath0 are bridged into bridge0 which has my LAN IP (so that both my wired and wireless systems are all on the same physical network), and re2 is a member of bridge0 as a SPAN port.

A tcpdump on the SPAN (and on the analysis box) shows that all packets which enter the system via ath0 and re1 are mirrored appropriately, but if the packets originate either on the WAN  port (re1) or internal to the firewall box (ping a LAN endpoint from the firewall shell) the packets are not present on the SPAN port.  tcpdump on bridge0 captures the packets, so they're definitely on the bridge.

In order to eliminate all possibilities I ran a liveCD of FreeBSD 10-RELEASE on a different box box with 4 interfaces with em0 and em1 bridged together into bridge0 with em3 as a SPAN port for bridge0.  Bridge0 has the IP.  No firewall, no ports, nothing has been installed or configured.  On this box, any packets which physically enter either em0 or em1 (the bridged interfaces) are SPANned, but nothing that originates on the fresh box shows up on the SPAN.  Again, the packets originating on the system show up on a tcpdump of bridge0.  I also tested this on the same system listed here, but with the installed version of 9.0-RELEASE.


When giving the IP to one of the physical interfaces, the SPAN port works correctly, and locally generated packets are SPANned appropriately.  

This isn't ideal as it means that if the physical interface with the IP goes down, clients on the other interfaces will lose connectivity to the system, and when bridging it's ideal to give the IPs to the bridge itself to protect against that possibility.
Comment 1 jbw 2014-08-17 17:30:23 UTC
The ifconfig from the 10-RELEASE box is as follows:

root@:~ # ifconfig
em0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
        ether 00:90:fb:36:78:ec
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
        ether 00:90:fb:36:78:ed
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
em2: flags=8c02<BROADCAST,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
        ether 00:90:fb:36:78:ee
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect
        status: no carrier
em3: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
        ether 00:90:fb:36:78:ef
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether ce:52:1f:48:3f:45
        inet 192.168.6.19 netmask 0xffffff00 broadcast 192.168.6.255
        nd6 options=9<PERFORMNUD,IFDISABLED>
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        member: em1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 2 priority 128 path cost 20000
        member: em0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 1 priority 128 path cost 200000
        member: em3 flags=8<SPAN>
                ifmaxaddr 0 port 4 priority 128 path cost 200000


And the tcpdumps showing the behavior:

From the box (liveCD) in question (with the IP of 192.168.6.19): 

root@:~ # ping 192.168.6.108
PING 192.168.6.108 (192.168.6.108): 56 data bytes
64 bytes from 192.168.6.108: icmp_seq=0 ttl=128 time=0.612 ms
64 bytes from 192.168.6.108: icmp_seq=1 ttl=128 time=0.464 ms
64 bytes from 192.168.6.108: icmp_seq=2 ttl=128 time=0.528 ms

And on the same box:

root@:~ # tcpdump -ni em3 host 192.168.6.108 and icmp
tcpdump: WARNING: em3: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em3, link-type EN10MB (Ethernet), capture size 65535 bytes capability mode sandbox enabled
15:16:07.658004 IP 192.168.6.108 > 192.168.6.19: ICMP echo reply, id 25865, seq 0, length 64
15:16:08.701353 IP 192.168.6.108 > 192.168.6.19: ICMP echo reply, id 25865, seq 1, length 64
15:16:09.763414 IP 192.168.6.108 > 192.168.6.19: ICMP echo reply, id 25865, seq 2, length 64
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2025-01-25 01:57:20 UTC
^Triage: I'm sorry that this PR did not get addressed in a timely fashion.

By now, the version that it was created against is long out of support.
Please re-open if it is still a problem on a supported version.