Re: [Bridge] Bridge blocking network traffic

Re: [Bridge] Bridge blocking network traffic

[ratheesh k]

>>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
>

Re: [Bridge] Bridge blocking network traffic

[Grant Taylor]

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. . . .

Re: [Bridge] Bridge blocking network traffic

[ratheesh k]

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

Re: [Bridge] Bridge blocking network traffic

[Pascal Hambourg]

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.

Re: [Bridge] Bridge blocking network traffic

[ratheesh k]

>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
>