From: Stephen Hemminger <stephen@networkplumber.org>
To: ratheesh kannoth <ratheesh.ksz@gmail.com>
Cc: bridge@lists.linux-foundation.org
Subject: Re: [Bridge] linux brigde query
Date: Fri, 8 May 2015 09:57:02 -0700 [thread overview]
Message-ID: <20150508095702.5f6caf37@urahara> (raw)
In-Reply-To: <CAGZFCEHrB5awRa4qaMgwriW_x9qXOMUjG-Nom+aWQ_TWXA040Q@mail.gmail.com>
On Mon, 4 May 2015 15:34:17 +0530
ratheesh kannoth <ratheesh.ksz@gmail.com> wrote:
> br0
> |
> --------------------------------------------
> | | |
> eth0 eth1 eth2
> | |
> Machine A machine B
>
> suppose there is a UDP bidirectional traffic between machine A and B.
> Then there will be bridge port
> info in "brctl showmacs br0" command output. After some time, UDP
> traffic becomes only uni directional( say
> only from machine A to B , there is no traffic from B to A ). Then
> before bridge ages out , B got removed ; but link eth2
> is not going down ( no link down message at eth2, it can be achieved
> if eth2 to a harware switch , and machine
> was connected to one port of that switch ). Then traffic will flood or
> will black hole till ageing timer expire.
When eth2 is removed or goes down then, all forwarding table
entries related to eth2 are removed. All packets for Ethernet
address of machine B will then be processed according to the
standard flooding model BUM (Broadcast, Unknown, Mulicast_)
This is standard learning switch behavior described in IEEE standard
and lots of text books.
In real world, it is possible that machine B is often re-connected
to another switch (eth1 for example), and this allows transparent
rediscovery.
With recent (like last 2 years) version of Linux switch there
are flags to control allow disabling flooding and learning behavior
which are often used in virtualization environments to control
packet leakage.
prev parent reply other threads:[~2015-05-08 16:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-04 10:04 [Bridge] linux brigde query ratheesh kannoth
2015-05-08 16:57 ` Stephen Hemminger [this message]
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=20150508095702.5f6caf37@urahara \
--to=stephen@networkplumber.org \
--cc=bridge@lists.linux-foundation.org \
--cc=ratheesh.ksz@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox