Network Loop / Duplicate Name Exists On Network after 2.01 Upgrade
-
We recently upgraded to PFSense 2.01-RELEASE from 1.2.3 and immediately began receiving NetBios errors related to duplicate network names.
This was previously asked here (http://forum.pfsense.org/index.php?topic=36641.0;prev_next=prev) and our setup is identical, but the resolution to delete the WAN/OPT1 bridge will mean our servers with public IP addresses will be unreachable outside the network. From what I've read in the PFSense book there is no way around not having this bridge for our setup.
The OPT1 connects to another switch which connects to several mail and web servers and STP appear to be enabled on both PFsense and the switch.
Obviously there is something wrong with our configuration but I cannot for the life of me figure out where it could be. I'm clearly not a network master by any means but if someone could just point us in the right direction it would be greatly appreciated.
-
has to be a loop somewhere, what interfaces are in the bridge? Interfaces>assign, bridges tab.
-
Thanks for replying, the only interfaces bridged are WAN and OPT1, which we need for several severs inside the office with public addresses. There is a page here for advanced SPT settings, but none of our attempts to configure it correctly have worked.
My understanding is that SPT would automatically kick in and filter the traffic that would cause these sorts of loops but clearly that isn't happening. We downgraded back to release 1.2.3 today and even though the interfaces and configuration are the same the loop is no longer showing up on our network.
-
would need to see the ifconfig output to tell more. You don't have a layer 2 loop of the type STP would protect, you'd have far more issues (your entire network would be melted down) if that were the case.
-
Here is a basic ifconfig output of our primary firewall with the first few bytes of each address set altered altered for security concerns. This is the sans-loop configuration with the downgraded software, but if we upgrade to 2.01 with the same settings, as just confirmed inside our testing environment, the loop will immediately re-appear.
$ ifconfig
em0: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
options=19b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,tso4>ether 00:25:42:3q:0e:b4
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
em1: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=198 <vlan_mtu,vlan_hwtagging,vlan_hwcsum,tso4>ether 00:25:42:3q:0e:b5
inet6 gh14::164:19kk:rt65:ty5%em1 prefixlen 64 scopeid 0x2
inet 161.28.2.1 netmask 0xffffff00 broadcast 161.28.2.255
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
em2: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=198 <vlan_mtu,vlan_hwtagging,vlan_hwcsum,tso4>ether 00:25:42:3q:0e:b6
inet6 gh14::164:19kk:rt65:ty6%em2 prefixlen 64 scopeid 0x3
inet 13.14.254.1 netmask 0xffffff00 broadcast 13.14.254.255
media: Ethernet autoselect (1000baseTX <full-duplex>)
status: active
em3: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
options=98 <vlan_mtu,vlan_hwtagging,vlan_hwcsum>ether 00:25:42:3q:0e:b7
inet6 gh14::164:19kk:rt65:ty7%em3 prefixlen 64 scopeid 0x4
media: Ethernet autoselect (1000baseTX <full-duplex>)
status: active
bge0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=98 <vlan_mtu,vlan_hwtagging,vlan_hwcsum>ether 00:7b:43:6e:ac:eb
inet6 fe80::25p:83hf:fe9u:aceb%bge0 prefixlen 64 scopeid 0x5
inet 80.25.1.1 netmask 0xffffff00 broadcast 80.25.1.255
media: Ethernet autoselect (1000baseTX <full-duplex>)
status: active
bge1: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
options=98 <vlan_mtu,vlan_hwtagging,vlan_hwcsum>ether 00:7b:43:6e:ac:ec
inet6 fe80::25p:83hf:fe9u:acec%bge1 prefixlen 64 scopeid 0x6
inet 23.114.201.234 netmask 0xfffffffc broadcast 23.114.201.235
media: Ethernet 10baseT/UTP <full-duplex>status: active
lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7
enc0: flags=41 <up,running>metric 0 mtu 1536
pfsync0: flags=41 <up,running>metric 0 mtu 1460
pfsync: syncdev: lo0 syncpeer: 224.0.0.240 maxupd: 128
pflog0: flags=100 <promisc>metric 0 mtu 33204
bridge0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
ether b1:47:9c:6e:49:d1
id 00:25:42:3q:0e:b4 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
root id 00:25:42:3q:0e:b4 priority 32768 ifcost 0 port 0
member: bge1 flags=1e7 <learning,discover,stp,edge,autoedge,ptp,autoptp>ifmaxaddr 0 port 6 priority 128 path cost 2000000 proto rstp
role designated state forwarding
member: em3 flags=1c7 <learning,discover,stp,autoedge,ptp,autoptp>ifmaxaddr 0 port 4 priority 128 path cost 20000 proto rstp
role designated state forwarding</learning,discover,stp,autoedge,ptp,autoptp></learning,discover,stp,edge,autoedge,ptp,autoptp></up,broadcast,running,simplex,multicast></promisc></up,running></up,running></up,loopback,running,multicast></full-duplex></vlan_mtu,vlan_hwtagging,vlan_hwcsum></up,broadcast,running,promisc,simplex,multicast></full-duplex></vlan_mtu,vlan_hwtagging,vlan_hwcsum></up,broadcast,running,simplex,multicast></full-duplex></vlan_mtu,vlan_hwtagging,vlan_hwcsum></up,broadcast,running,promisc,simplex,multicast></full-duplex></vlan_mtu,vlan_hwtagging,vlan_hwcsum,tso4></up,broadcast,running,simplex,multicast></full-duplex></vlan_mtu,vlan_hwtagging,vlan_hwcsum,tso4></up,broadcast,running,simplex,multicast></full-duplex></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,tso4></broadcast,simplex,multicast> -
Shameless self-bump.
-
Is the duplicate name identified? Can you find associated MAC addresses? Are they yours?
Noting you have WAN and OPT1 bridged I wonder if you have a broadcast segment on the WAN side (e.g. cable) and if the bridge is forwarding NETBIOS traffic from the WAN to your OPT1 and the "duplicate" name is coming from the WAN side. But I know next to zilch about NETBIOS and I replied only because no one else seemed to want to have a go.
-
I know next to zilch about NETBIOS and I replied only because no one else seemed to want to have a go.
If we're all having a go then… ;)
Some things I note:
Bridging is handled slightly differently in 2.0.X compared to 1.2.3.
Here we have two cases of a bridged WAN producing exactly the same symptoms after an upgrade.
You have STP enabled on your bridge member interfaces, it isn't enabled by default on either 2.0.X or 1.2.3.
You have bge1 set to 10baseT full duplex rather than auto. Is that intentional?Since bridging is handled slightly differently are all the settings correctly translated to the new config? The other post mentions a flag setting of some kind. The ifconfig output you have provided is from the working 1.2.3 install, it be good to have a similar output from 2.0.X working or not.
What sort of firewall rules do you have in place?
Steve
