Someone asked about this, and I've learned a little bit more since: The real problem was caused by the loading of the sip nat and conntrack kernel modules. I assume that disabling the bridge-nf* sysctls helped because they took those modules out of the path of the bridge traffic. So: rmmod ip_nat_sip ip_conntrack_sip John John Morris wrote: > Too early to say for sure, but this may have been a case where I should've > done better at RTFMing. > > http://www.linuxfoundation.org/en/Net:Bridge#No_traffic_gets_trough_.28except_ARP_and_STP.29 > > Disabling the /proc/sys/net/bridge/bridge-nf* sysctls may have worked. I > don't understand how this could cause some, but not other traffic to be > dropped. > > At any rate, if this turns out not to be the fix after all, I'll report back. > > John > > > On Wed, March 18, 2009 6:56 pm, John Morris wrote: >> Same problem again here, this time with phone from a different vendor. >> The dom0 had been running VLANs, but these are removed and the eth0 device >> directly connected to the bridge for testing. >> >> Here are some tcpdumps that help illustrate the problem. In this output, >> sipura1 is the phone, and pbx0 is the domU. Pbx0 is connected through the >> interface vif8.0. Sergey is the dom0, with a bridge 'bo1br'. >> >> [root@sergey ~]# jobs >> [7]- Running tcpdump -i vif8.0 -l -A host sipura1 and not port 5061 \ >> | sed 's/^/vif8.0-s: /' & >> [8]+ Running tcpdump -i bo1br -l -e -A host sipura1 and not port 5061 >> \ >> | sed 's/^/bo1br-s: /' & >> >> Here are some sample packets that are never forwarded from the bridge to >> vif8.0: >> [...] >> bo1br-s: 18:30:37.948378 00:0e:08:ab:6a:78 (oui Unknown) \ >> > 00:16:ee:68:03:13 (oui Unknown), ethertype IPv4 (0x0800), \ >> length 543: sipura1.zultron.com.sip > pbx0.zultron.com.sip: \ >> SIP, length: 501 >> bo1br-s: [...]REGISTER sip:pbx0.zultron.com SIP/2.0 >> bo1br-s: Via: SIP/2.0/UD >> bo1br-s: 18:30:39.948675 00:0e:08:ab:6a:78 (oui Unknown) \ >> > 00:16:ee:68:03:13 (oui Unknown), ethertype IPv4 (0x0800), \ >> length 543: sipura1.zultron.com.sip > pbx0.zultron.com.sip: \ >> SIP, length: 501 >> bo1br-s: [...]REGISTER sip:pbx0.zultron.com SIP/2.0 >> bo1br-s: Via: SIP/2.0/UD >> [...] >> >> A ping from pbx0 to sipura1 makes it through just fine, however: >> [...] >> vif8.0-s: 18:39:40.986555 IP pbx0.zultron.com > \ >> sipura1.zultron.com: ICMP echo request, id 2318, seq 5, length 64 >> bo1br-s: 18:39:40.986555 00:16:ee:68:03:13 (oui Unknown) \ >> > 00:0e:08:ab:6a:78 (oui Unknown), ethertype IPv4 (0x0800), \ >> length 98: pbx0.ablesky.com > sipura1.ablesky.com: ICMP echo \ >> request, id 2318, seq 5, length 64 >> bo1br-s: 18:39:40.987507 00:0e:08:ab:6a:78 (oui Unknown) \ >> > 00:16:ee:68:03:13 (oui Unknown), ethertype IPv4 (0x0800), \ >> length 98: sipura1.ablesky.com > pbx0.ablesky.com: ICMP echo \ >> reply, id 2318, seq 5, length 64 >> vif8.0-s: 18:39:40.987516 IP sipura1.ablesky.com > \ >> pbx0.ablesky.com: ICMP echo reply, id 2318, seq 5, length 64 >> >> The relevant entries in the MAC table: >> [root@sergey ~]# brctl showmacs bo1br | grep -e 6a:78 -e 03:13 >> 1 00:0e:08:ab:6a:78 no 26.80 >> 9 00:16:ee:68:03:13 no 3.38 >> >> Strangest of all, sipura1, an ATA, has two phone ports, and the software >> registers them separately, one from port 5060, the other from port 5061. >> The registration from port 5061 works just fine. What's more, immediately >> after a reboot of sergey, the dom0, the phones register fine; it is after >> some time that the traffic suddenly begins being dropped. >> >> Should I be suspecting packet corruption? Tcpdump seems to be able to >> recognize the packets just fine. Are the packets being forwarded out >> another port? The dest MACs aren't duplicated on the network, and I've >> put a tcpdump on each switch port interface just to be sure. Is it the >> physical switch that sergey is connected to? I've moved sergey to another >> switch to test. Is it the phone itself? But different phones from >> different vendors exhibit the same problem, and sipura1 has the problem on >> one line, but not the other. Obviously, I'm missing something here. >> Thanks for any and all wild suggestions. >> >> John >> >> >> On Tue, March 3, 2009 7:04 pm, John Morris wrote: >>> We have about 20 IP phones connecting to a Xen-based PBX, and in the >>> past >>> month or two, a problem has been popping up. >>> >>> About once a week, some, but not all, of the phones lose their >>> registration with the PBX. The PBX can ping the unregistered phones, >>> and >>> the phone ARP requests for the PBX IP are answered. However, the UDP >>> 5060 >>> registration traffic originating from those phones enters the dom0's >>> bridge and is then dropped; it is never forwarded onto the vif >>> associated >>> with the pbx. >>> >>> Rebooting the dom0 is the only way I've found to fix it so far. >>> Reloading >>> the bridge kernel module doesn't seem to solve the problem, though the >>> set >>> of phones that are unable to register changes (I haven't looked closely >>> to >>> see if there's a pattern to it). >>> >>> There's no packet filtering going on here, and this problem seems to pop >>> up after random, infrequent intervals. I've verified that there are no >>> hosts with duplicate MAC addresses. I can't for the life of me think of >>> why some packets from some IPs would be forwarded correctly and others >>> would not. Another post in the archives described some similar-sounding >>> symptoms, but the OP found it to be an MTU-related problem; these >>> packets >>> are all 356 bytes long, too short to be the problem. >>> >>> Thanks- >>> >>> John >>> >>> _______________________________________________ >>> Bridge mailing list >>> Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx >>> https://lists.linux-foundation.org/mailman/listinfo/bridge >>> >> _______________________________________________ >> Bridge mailing list >> Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx >> https://lists.linux-foundation.org/mailman/listinfo/bridge >> > > _______________________________________________ > Bridge mailing list > Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linux-foundation.org/mailman/listinfo/bridge _______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge
