Bridge configuration confusion, or my understanding of Bridge use?

T

T_P_H_Beastie

I'd like to use a bridge to do a packet capture on a Bacnet IP network we are having issues with to see where the problem is, but I can't seem to get the bridge to do what I'd like it to.
It's probably my confusion.
I've got FreeBSD on a laptop and am using two USB Ethernet adapters for the two ends of the bridge.
I set it up exactly as instructed in the handbook and connected one Ethernet cable to the network jack at my workstation into one adapter.
The other ethernet cable I connected from the other USB adapter to another laptop.
I can't seem to get the laptop with the bridge to allow the other computer to get online.
When I replace the laptop running the bridge with a small unmanaged switch I have, the test computer gets online with no issues.
According to the handbook it sounds like a bridge could be used like an unmanaged switch, but it doesn't seem to be the case.
If anyone can help me see where my confusion is, please let me know.
Merci.
 
I was hoping to get SirDice to have time to take a look.

ifconfig output -
Code: 
em0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
   options=481249b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LRO,WOL_MAGIC,VLAN_HWFILTER,NOMAP>
   ether f0:de:f1:ae:35:6c
   inet 172.21.227.52 netmask 0xffffff00 broadcast 172.21.227.255
   media: Ethernet autoselect (1000baseT <full-duplex>)
   status: active
   nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
ue0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
   options=8000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE>
   ether 00:50:b6:27:2e:c4
  media: Ethernet autoselect (100baseTX <full-duplex>)
  status: active
  nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
ue1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
  options=8000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE>
    ether 00:0a:cd:29:77:a9
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    ether 58:9c:fc:10:ff:f8
    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: ue1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            ifmaxaddr 0 port 5 priority 128 path cost 20000
    member: ue0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            ifmaxaddr 0 port 4 priority 128 path cost 200000
    groups: bridge
    nd6 options=9<PERFORMNUD,IFDISABLED>

And my rc.conf -
Code: 
hostname="FreeBSDX220"
ifconfig_em0="DHCP"
sshd_enable="YES"
ntpdate_enable="YES"
ntpd_enable="YES"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"


#ifconfig_ue0="DHCP"
#ifconfig_ue1="DHCP"

#########

kld_list="i915kms"

# Bridge Interface

cloned_interfaces="bridge0"
ifconfig_bridge0="addm ue0 addm ue1 up"
ifconfig_ue0="up"
ifconfig_ue1="up"

Thanks, SirDice.
 
This looks good:
Code: 
cloned_interfaces="bridge0"
ifconfig_bridge0="addm ue0 addm ue1 up"
ifconfig_ue0="up"
ifconfig_ue1="up"

ifconfig(8) output looks appropriate too. The only 'oddness' I see is that ue0 is a 100Mbit/s connection and ue1 a 1Gb/s. Obviously not the best but it should work nonetheless (connection would be capped at 100Mbit).
 
Thanks for taking a look.
They are different adapters, one I bought some time ago, the other is newer.
Also, is my understanding correct that it should be functioning as an unmanaged switch?
Basically plug and play.
Merci.
 
T_P_H_Beastie said:
Also, is my understanding correct that it should be functioning as an unmanaged switch?
Click to expand...
A bridge(4) is a layer 2 connection. So yes, it basically works exactly like a switch.

One thing I can think of, any firewalls running on the laptop? That might block the traffic on ue0 and/or ue1.
 
I did a sysctl net.link.bridge and the output is the following:
Code: 
net.link.bridge.ipfw: 0
net.link.bridge.allow_llz_overlap: 0
net.link.bridge.inherit_mac: 0
net.link.bridge.log_stp: 0
net.link.bridge.pfil_local_phys: 0
net.link.bridge.pfil_member: 1
net.link.bridge.ipfw_arp: 0
net.link.bridge.pfil_bridge: 1
net.link.bridge.pfil_onlyip: 1

Maybe the pfil variable?
 
try to bridge between em0 and one of the usb adapters, then the other em with the other one
see if any of these combination works
there *might* be some usb to ether drivers that don't implement promiscuous mode
 
The manual says, "A bridge works by learning the MAC addresses of the devices on each of its network interfaces. It forwards traffic between networks only when the source and destination MAC addresses are on different networks."

Is it possible the laptop MAC address is still in the main LAN tables? Clear the ARP tables after connecting your bridge?
 
covacat said:
try to bridge between em0 and one of the usb adapters, then the other em with the other one
see if any of these combination works
there *might* be some usb to ether drivers that don't implement promiscuous mode
Click to expand...
This might be on the right path.

I added the em0 interface (the internal NIC) to the bridge and it would connect, I got an IP address from the DHCP server on the test laptop and I could ping my FreeBSD workstation on my desk from the lab I am working in.
However, I could not browse the web anymore.
 
dave said:
The manual says, "A bridge works by learning the MAC addresses of the devices on each of its network interfaces. It forwards traffic between networks only when the source and destination MAC addresses are on different networks."

Is it possible the laptop MAC address is still in the main LAN tables? Clear the ARP tables after connecting your bridge?
Click to expand...

Dave might be right.
Thus the ping working, but the internet not any more.
 
Phishfry said:
You never assigned either an IP or DHCP on your bridge interface.
Click to expand...
And finally, I am understanding that the bridge just passes the frames between the two segments of the network and it didn't get an IP address.
I could be wrong, and am wrong often.
Merci
 
The proper way is to use managed L2 switch with port mirroring or port tap so you can clone and capture the traffic that is going on specific port that you want to debug.
 
covacat said:
try to bridge between em0 and one of the usb adapters, then the other em with the other one
see if any of these combination works
there *might* be some usb to ether drivers that don't implement promiscuous mode
Click to expand...
covacat
I think the USB driver is the issue.
I added the em interface and I could connect.
I have to sort out the issue with losing outside connectivity. i.e. I can connect to my workstation on the same subnet, but can't connect to the internet anymore.
Merci
 
The bridge(4) interface doesn't need an IP address. All it's supposed to do is pass frames from one side of the bridge to the other. It doesn't need an IP address for this as it's layer 2 traffic we're talking about.

Code: 
[switch]<------>[ue0; bridge; ue1]<------>[monitored host]
                          X
[switch]<------>[em0; laptop]

em0 is NOT part of the bridge. The em0 connection is only there for the laptop itself. The traffic to/from the monitored host passes the bridge to the switch directly (both sides of the bridge are the same layer 2 network). That provides a direct connection from the monitored host to the switch. Those ue* interfaces may not like to spoof MAC addresses though. As it's layer2 the switch should see the MAC address of the monitored host, not the MAC address of ue0, ue1 or the bridge.
 
I always thought you had to have an end point for your bridge. (Static or Dynamic)
On one side all your combined interfaces, on the other side of the bridge is your endpoint.
With no network address how does the bridge know where to send its packets? Seems like a bridge to nowhere.
Does STP handle this? What is letting the packets flow to an unknow endpoint?
 
Thanks guys for your help.
I was able to test again this morning when I got to work.
It works perfectly with a much newer USB-Eth that I brought from home, TP-Link using the rgephy driver.
The ones I had at work and was testing Friday use the axe driver.
I did have to do a - service netif restart - before it was functional.
And it does NOT work using both USB-Eth adapters for the bridge, I have to use the built in Intel as one of the bridge connections.

No biggie, but with a proper switch you just have to plug in both ethernet cables and it starts working.
I'm not sure why that would be.
 
To conclude:
After a couple more iterations of the bridge setup it seems that the fault lies in the particular USB - Eth adapter I was using.
The axe driver is fine, the adapter I had been using that did NOT work correctly has an RJ45 port and a USB port on it.
I tested the adapter that doesn't have the USB port, using the same axe driver and it works correctly.

And actually Alain:
Alain De Vos said:
For a physical hub it happens with a table of MAC-Addresses. Maybe it's the same but in "software".
Click to expand...

A proper hub (not many out there anymore) just is a repeater with many ports.
It just sends the electrical pulses out on all the ports except the port it came in on.
A switch has a MAC address table where it keeps track of which port has which address connected to it.
When you first plug it in and it hasn't built the table yet, it does act like a hub, it sends every frame out to each port and learns where everything is connected.
But once it knows where everything is, it sends the frames out on the correct ports.
Merci
 
You must log in or register to reply here.
Back
Top