* Re: [Bridge] Bridge blocking network traffic [not found] ` <20100422130919.70206765@nehalam> @ 2010-06-30 7:50 ` ratheesh k 2010-06-30 19:15 ` Grant Taylor 0 siblings, 1 reply; 5+ messages in thread From: ratheesh k @ 2010-06-30 7:50 UTC (permalink / raw) To: Stephen Hemminger; +Cc: Netfilter mailing list, netdev, bridge >>On Fri, Apr 23, 2010 at 1:39 AM, Stephen Hemminger <shemminger@linux-foundation.org> wrote: >>You are supposed to assign IP address to bridge not the member of the bridge Why is it so ? I have a linux machine with interfaces eth0 (192.168.1.100 ) and eth1 ( 192.168.2.100 ) . . I can connect both eth0 an eth1 to a hardware HUB . How could i do this in linux machine itself using brctl ? Thanks, Ratheesh > On Thu, 22 Apr 2010 10:48:09 +1000 > benno joy <bennojoy@gmail.com> wrote: > >> Dear Team, >> >> I have a strange problem...... This is my problem i have a linux box running >> Xen kernel (2.2). and i have the a bonding interface called bond0.497(eth0 >> and eth1 and also des Vlan tagging). >> the bond0.497 is part of the bridge "xenbrv497", the issue is as soon as i >> make the bond a part of the bridge my network traffic stops to work. >> I did some prelimanary tests and found the following: >> 1) if i assighn an ip to the bond and do a ping to the gateway it works >> (provided it is not part of bridge xenbrv497) >> 2) if i add the bondig interface to the brodge xenbrv497 (brclt addif >> xenbrv497 bond0.497) the ping tests fails. >> 3) i did a tcpdump and found that arp requests are going out of the >> interface and we are getting response also. but soemhow >> the arp entries are not gettign registered. i did some googling and found it >> may be because of filtering so i disabled it by >> echo 0 > in /proc/sys/net/bridge/bridge-nf-*. >> But even this did not help still the arp entries are not getting registered >> due to which my network traffic is gettign dropped. >> This problem can be resolved by a reboot. but i would like to troubleshoot >> it. >> Could you please let me know how i can get more debugging message from the >> bridge calls so i can figure out what exactly is happening. >> >> # uname -a >> Linux vmclkxstgh04.espdev.aurdev.national.com.au 2.6.18-128.2.1.4.13.el5xen >> #1 SMP Mon Dec 7 14:34:40 EST 2009 i686 i686 i386 GNU/Linux >> >> [root@vmclkxstgh04 ~]# brctl show >> bridge name bridge id STP enabled interfaces >> vlan441 8000.0017a4770470 no bond0.441 >> xenbrv205 8000.0017a477046c no bond1.205 >> xenbrv208 8000.0017a477046c no bond1.208 >> xenbrv220 8000.000000000000 no >> xenbrv221 8000.000000000000 no >> xenbrv226 8000.0017a477046c no vif40.1 >> vif39.1 >> vif37.1 >> vif26.1 >> vif25.1 >> vif24.1 >> vif13.1 >> bond1.226 >> xenbrv227 8000.0017a4770470 no vif40.0 >> vif39.0 >> vif37.0 >> vif26.0 >> vif25.0 >> vif24.0 >> vif13.0 >> bond0.227 >> xenbrv420 8000.0017a4770470 no bond0.420 >> xenbrv422 8000.0017a4770470 no vif35.0 >> vif7.0 >> vif6.0 >> vif4.0 >> vif3.0 >> vif2.0 >> tap2.0 >> bond0.422 >> xenbrv425 8000.0017a4770470 no bond0.425 >> xenbrv450 8000.0017a4770470 no bond0.450 >> xenbrv492 8000.0017a4770470 no bond0.492 >> xenbrv493 8000.0017a4770470 no bond0.493 >> xenbrv494 8000.0017a4770470 no bond0.494 >> xenbrv495 8000.0017a4770470 no bond0.495 >> xenbrv496 8000.0017a4770470 no bond0.496 >> xenbrv497 8000.0017a4770470 no bond0.497 >> xenbrv701 8000.0017a477046c no vif44.1 >> bond1.701 >> >> bond0.497 Link encap:Ethernet HWaddr 00:17:A4:77:04:70 >> inet addr:10.12.166.231 Bcast:10.12.166.255 Mask:255.255.255.224 >> UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 >> RX packets:3807595 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:3304 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:0 >> RX bytes:188847200 (180.0 MiB) TX bytes:138768 (135.5 KiB) > > You are supposed to assign IP address to bridge not the member of the bridge. > > > -- > _______________________________________________ > Bridge mailing list > Bridge@lists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/bridge > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bridge] Bridge blocking network traffic 2010-06-30 7:50 ` [Bridge] Bridge blocking network traffic ratheesh k @ 2010-06-30 19:15 ` Grant Taylor 2010-07-01 17:05 ` ratheesh k 0 siblings, 1 reply; 5+ messages in thread From: Grant Taylor @ 2010-06-30 19:15 UTC (permalink / raw) To: Mail List - Netfilter On 06/30/10 02:50, ratheesh k wrote: > Why is it so ? Independent of your scenario, I'd say that binding the IP to the interface will make it more resilient to the individual interfaces going down. At least in such as all the interfaces would have to go down before the IP would go down. > I have a linux machine with interfaces eth0 (192.168.1.100 ) and > eth1 ( 192.168.2.100 ) . . I can connect both eth0 an eth1 to a > hardware HUB . How could i do this in linux machine itself using > brctl ? What netmask are your two IPs using, a /24? If they are, then you are actually using two different subnets, and possibly doing something like a bridging router. Either way, you could bind both IPs to the bridge interface (classic IP alias or "ip add"). With in the Xen context it may be because different things manage various parts of the Xen network differently and having the IP bound in the wrong place might cause a problem if the Xen hypervisor takes something down. There is also the fact that if a cable gets unplugged from an interface (that is a member of a bridge with at least one other member interface) said interface will go down but the bridge will stay up. In doing so, the IP will go down b/c the interface that it was bound to would go down. Conversely if the IP was bound to the bridge interface, the IP would stay up and usable. There is also the possibility that if the IP is bound directly to the interface that filtering (EBTables / IPTables w/ Bridged Netfilter option) will not see the traffic. In some ways, it really depends on the specific use scenario. Grant. . . . ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bridge] Bridge blocking network traffic 2010-06-30 19:15 ` Grant Taylor @ 2010-07-01 17:05 ` ratheesh k 2010-07-01 17:57 ` Pascal Hambourg 0 siblings, 1 reply; 5+ messages in thread From: ratheesh k @ 2010-07-01 17:05 UTC (permalink / raw) To: Grant Taylor; +Cc: Mail List - Netfilter, bridge On Thu, Jul 1, 2010 at 12:45 AM, Grant Taylor <gtaylor@riverviewtech.net> wrote: > On 06/30/10 02:50, ratheesh k wrote: >> >> Why is it so ? > > Independent of your scenario, I'd say that binding the IP to the interface > will make it more resilient to the individual interfaces going down. At > least in such as all the interfaces would have to go down before the IP > would go down. > >> I have a linux machine with interfaces eth0 (192.168.1.100 ) and eth1 ( >> 192.168.2.100 ) . . I can connect both eth0 an eth1 to a hardware HUB >> . How could i do this in linux machine itself using brctl ? > > What netmask are your two IPs using, a /24? If they are, then you are > actually using two different subnets, and possibly doing something like a > bridging router. > > Either way, you could bind both IPs to the bridge interface (classic IP > alias or "ip add"). > > With in the Xen context it may be because different things manage various > parts of the Xen network differently and having the IP bound in the wrong > place might cause a problem if the Xen hypervisor takes something down. > > There is also the fact that if a cable gets unplugged from an interface > (that is a member of a bridge with at least one other member interface) said > interface will go down but the bridge will stay up. In doing so, the IP > will go down b/c the interface that it was bound to would go down. > Conversely if the IP was bound to the bridge interface, the IP would stay > up and usable. > > There is also the possibility that if the IP is bound directly to the > interface that filtering (EBTables / IPTables w/ Bridged Netfilter option) > will not see the traffic. > > In some ways, it really depends on the specific use scenario. > > > > Grant. . . . > -- > To unsubscribe from this list: send the line "unsubscribe netfilter" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > br0 0.0.0.0 | | ----------------------------------------- | | | | eth0 eth1 192.168.1.100/24 192.168.2.100/24 brctl addbr br0 brctl addif eth0 brctl addif eth1 ifconfig br0 0.0.0.0 up The problem was "default brouter policy is accept " . So packets are coming to layer2 only .I applied the below command and every thing seemed to work exactly like connecting eth0 and eth1 to hardware hub . ebtables -t broute -P BROUTING -j DROP Thanks, Ratheesh ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bridge] Bridge blocking network traffic 2010-07-01 17:05 ` ratheesh k @ 2010-07-01 17:57 ` Pascal Hambourg 2010-07-01 18:14 ` ratheesh k 0 siblings, 1 reply; 5+ messages in thread From: Pascal Hambourg @ 2010-07-01 17:57 UTC (permalink / raw) To: Mail List - Netfilter; +Cc: bridge ratheesh k a écrit : > > brctl addbr br0 > brctl addif eth0 > brctl addif eth1 > ifconfig br0 0.0.0.0 up > > The problem was "default brouter policy is accept " . So packets are > coming to layer2 only . Indeed, by default (i.e. no brouting) packets received on a bridge port are intercepted by the bridge. This is the intended behaviour of a bridge, isn't it ? Thus a bridge port is not supposed to be assigned an IP address (or be used by any protocol), because the IP stack (or any other upper protocol layer) won't receive any packet directly from it but from the bridge interface (which should have the IP address). >I applied the below command and every thing > seemed to work exactly like connecting eth0 and eth1 to hardware hub . > > ebtables -t broute -P BROUTING -j DROP I strongly doubt it. This rule forces routing of all packets instead of bridging, so IIUC it effectively totally disables bridging and you are back to two independent interfaces. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bridge] Bridge blocking network traffic 2010-07-01 17:57 ` Pascal Hambourg @ 2010-07-01 18:14 ` ratheesh k 0 siblings, 0 replies; 5+ messages in thread From: ratheesh k @ 2010-07-01 18:14 UTC (permalink / raw) To: Pascal Hambourg; +Cc: Netfilter mailing list, bridge >On Thu, Jul 1, 2010 11:27 PM, Pascal Hambourg <pascal.mail@plouf.fr.eu.org> wrote: > I strongly doubt it. This rule forces routing of all packets instead of > bridging, so IIUC it effectively totally disables bridging and you are > back to two independent interfaces. I am sorry that i made a ambigous statement . what i meant is : We could add rules to BROUTING to selectively bridge and route packets .Previously i was not able to ping eth0 or eth1 from some other machine (in same subnet ) if i attach both to br0 . This got solved when we made default policy as DROP . On Thu, Jul 1, 2010 at 11:27 PM, Pascal Hambourg <pascal.mail@plouf.fr.eu.org> wrote: > ratheesh k a écrit : >> >> brctl addbr br0 >> brctl addif eth0 >> brctl addif eth1 >> ifconfig br0 0.0.0.0 up >> >> The problem was "default brouter policy is accept " . So packets are >> coming to layer2 only . > > Indeed, by default (i.e. no brouting) packets received on a bridge port > are intercepted by the bridge. This is the intended behaviour of a > bridge, isn't it ? Thus a bridge port is not supposed to be assigned an > IP address (or be used by any protocol), because the IP stack (or any > other upper protocol layer) won't receive any packet directly from it > but from the bridge interface (which should have the IP address). > >>I applied the below command and every thing >> seemed to work exactly like connecting eth0 and eth1 to hardware hub . >> >> ebtables -t broute -P BROUTING -j DROP > > I strongly doubt it. This rule forces routing of all packets instead of > bridging, so IIUC it effectively totally disables bridging and you are > back to two independent interfaces. > -- > To unsubscribe from this list: send the line "unsubscribe netfilter" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-07-01 18:14 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <m2nbc9320b91004211748o5548f351z646076fab6744cca@mail.gmail.com>
[not found] ` <20100422130919.70206765@nehalam>
2010-06-30 7:50 ` [Bridge] Bridge blocking network traffic ratheesh k
2010-06-30 19:15 ` Grant Taylor
2010-07-01 17:05 ` ratheesh k
2010-07-01 17:57 ` Pascal Hambourg
2010-07-01 18:14 ` ratheesh k
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox