All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Taylor <gtaylor@riverviewtech.net>
To: Mail List - Netfilter <netfilter@vger.kernel.org>
Subject: Re: [Bridge] Bridge blocking network traffic
Date: Wed, 30 Jun 2010 14:15:24 -0500	[thread overview]
Message-ID: <4C2B97CC.8090007@riverviewtech.net> (raw)
In-Reply-To: <AANLkTimPiriAOGpHHrAoEyFGuuyn1g8vFqW6Pimdz9CQ@mail.gmail.com>

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

  reply	other threads:[~2010-06-30 19:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-22  0:48 [Bridge] Bridge blocking network traffic benno joy
2010-04-22 20:09 ` Stephen Hemminger
2010-06-30  7:50   ` ratheesh k
2010-06-30  7:50     ` ratheesh k
2010-06-30 19:15     ` Grant Taylor [this message]
2010-07-01 17:05       ` ratheesh k
2010-07-01 17:05         ` ratheesh k
2010-07-01 17:57         ` Pascal Hambourg
2010-07-01 18:14           ` ratheesh k
2010-07-01 18:14             ` ratheesh k

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C2B97CC.8090007@riverviewtech.net \
    --to=gtaylor@riverviewtech.net \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.