From: Simon Wunderlich <sw@simonwunderlich.de>
To: b.a.t.m.a.n@lists.open-mesh.org
Cc: Alessandro Bolletta <abolletta@netter.io>,
Sven Eckelmann <sven@narfation.org>,
Antonio Quartulli <a@unstable.cc>
Subject: Re: Passing VID-aware ethernet frames on plain batX interfaces
Date: Fri, 11 Sep 2020 17:03:01 +0200 [thread overview]
Message-ID: <1893066.IbdV0THItd@prime> (raw)
In-Reply-To: <CADJ1cURdGjW=q91qFw8vCBs38pAPnBp9=e5qS1WgzV7w06Onwg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3388 bytes --]
Hi Alessandro,
to use VLANs in batman-adv, you currently have to explicitly set up VLAN
interfaces, as it was already explained. You can not just listen to bat0 and
expected VLAN tagged frames to go through.
This is a limitation of the current code, which basically exists since we
integrated VLANs into batman-adv. There were some ideas to register VLANs on
the fly inside of batman-adv, but the current implementation relies on the
setup of VLANs on top of bat0 provided by the system.
If you want to use those VLANs, you have to set up VLAN interfaces for each
VLAN ID you want to use. This can get a bit messy if there are many VLANs, but
it works. You can't just bridge bat0 to something else and expect VLAN tagged
traffic to come out of bat0.
I can't say anything about OVS and to which extent bridges can be skipped, but
you'll create VLAN devices in that case too.
We're open to patches to add VLANs on the fly without requiring explicit VLAN
interfaces (maybe by snooping, similar to TT or BLA). I've also run into this
scenario a couple of times, but the pain level wasn't high enough to change it
yet. ;)
Cheers,
Simon
On Friday, September 11, 2020 4:42:52 PM CEST Alessandro Bolletta wrote:
> Hi Sven,
>
> I'm sorry for being not so clear in my statements. You can read my
> last "refactored" mail, which is easier to understand:
>
> Should I must only rely to the related 802.1q interface (eg. bat0.1)
> or can I receive the whole traffic (untagged and tagged) from the
> plain bat0 interface, just listening for the incoming traffic on it?
>
> If the answer is the first choice, is it possible to have an approach
> where I can receive coming from bat0 leveraging on a single interface
> anyway? Could a linux bridge br0 on the top of bat0 interface make it
> possible?
>
> For example, if I connect an openvswitch port, configured as trunk port, to
> a linux bridge br0 that enslaves bat0, could I expect to see the whole
> traffic inside the batman-adv mesh network (so I mean, both tagged and
> untagged traffic) also "flowing" inside the other OvS switch ports that are
> attached to that vlans?
> Moreover, just out of curiosity, is there also another known way to
> get rid of the linux bridge br0 in order to get this done (attaching
> the bat0 directly to the OvS switch, for example)?
>
> Il giorno ven 11 set 2020 alle ore 16:02 Sven Eckelmann
>
> <sven@narfation.org> ha scritto:
> > On Friday, 11 September 2020 15:03:13 CEST Alessandro Bolletta wrote:
> > > I see. Ok for transmission purposes, but what if I have to receive a
> > > tagged
> > > frame?
> >
> > It should not have been send to the other node when there is no TT entry
> > for this mac + VID from the receiver.
> >
> > > Should I only rely to the 8021q interface (eg. bat0.1) or receive the
> > > whole
> > > traffic (untagged and tagged) from the plain bat0 interface?
> >
> > Hm?
> >
> > > If this is not feasible, is it possible to handle in someway this?
> >
> > Hm?
> >
> > > A linux
> > > bridge on the top of bat0 interface could make it possible?
> >
> > No, the bridge must also enable the vlan for this bat0 interface.
> >
> > See also
> > https://www.open-mesh.org/projects/batman-adv/wiki/Faq#BATMAN-Advanced-VLA
> > N-questions
> >
> > Maybe Antonio wants to add more things to this discussion.
> >
> > Kind regards,
> >
> > Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-09-11 15:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-11 10:48 Passing VID-aware ethernet frames on plain batX interfaces Alessandro Bolletta
2020-09-11 12:01 ` Sven Eckelmann
2020-09-11 12:19 ` Alessandro Bolletta
2020-09-11 12:48 ` Sven Eckelmann
2020-09-11 12:50 ` Sven Eckelmann
2020-09-11 13:25 ` dan
2020-09-11 14:12 ` Sven Eckelmann
2020-09-11 13:46 ` Alessandro Bolletta
[not found] ` <CADJ1cUQZ2YqFSVj=SNhPcC_sOjy+AkrEr=dQ=8T_0HegFou=Hw@mail.gmail.com>
2020-09-11 14:02 ` Sven Eckelmann
2020-09-11 14:42 ` Alessandro Bolletta
2020-09-11 14:44 ` Sven Eckelmann
2020-09-11 15:03 ` Simon Wunderlich [this message]
2020-09-14 6:35 ` Antonio Quartulli
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=1893066.IbdV0THItd@prime \
--to=sw@simonwunderlich.de \
--cc=a@unstable.cc \
--cc=abolletta@netter.io \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=sven@narfation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox