Hi!
thanks so much for you mail. As I wrote in my other mail just a
minute ago, it seems I solved the issue (and it works in one of
the most intuitive ways).
Thanks so much, you already helped so much to tackle down
my VLAN problem last year (where to solution was, not to install
package vlan when using VLAN).
On Wed, Jun 4, 2014 at 11:59 PM, Tom H <tomh0...@gmail.com> wrote:
> On Wed, Jun 4, 2014 at 2:00 PM, Steffen Dettmer:
>> Of course everything works as expected when configuring manually
>> with "ip", "brctl" etc.
>
> (By the way, you don't need brctl; "ip link" can create bridges.)
Ohh, I see, man ip-link (not "man ip" as I tried before).
Thanks for pointing that out!
I case someone else also has difficulties to find that, like me,
here an example:
$ ip link add name br1 type bridge
$ ip link set eth0 master br0
$ ip link set eth1 master br0
$ ip link set eth1 nomaster
$ ip link set eth0 nomaster
$ ip link del br1
Do you - or anyone else - know the ip replacement for "brctl show"?
"ip link show br1" is too brief, no information about the slave
devices or STP mode.
How to enable STP (and set timeouts etc) using ip?
>> otherwise no bridge can use it any only gives an error message
>> like "interface eth3.14 does not exist!".
Update: This message appears only if using "ifup br0",
but NOT when booting. Seems networking start is smart
enough to bring slave devices up before the bridge.
The conclusion is that "ifdown <dev> && ifup <dev>" is not suited
for testing.
> I suspect that the bridge-utils-interfaces man page refers to physical
> interfaces. You might want to file an RFE bug for it to work for
> vlan-tagged interfaces so that:
>
> iface br0.100
> bridge_ports eth0.100
Ohh, thanks to bringing this into attention.
This happily creates a bridge called "br0.100" (without VLAN) :-)
so the implicite magic like "eth0.10" creating a VLAN tag 10 does
not apply here, good to know.
For the case that the bridge shall bridge VLAN transparently on
all physical ports, but itself should be in a VLAN 100.
This would be like a fully transparent VLAN switch with a
management interface in a VLAN.
With ip it works straight-forward:
have in /etc/network/interfaces:
# bridge all VLANs
iface br0
bridge_ports eth0 eth1...
and add VLAN interface to the bridge:
$ ip link add link br7 name br7.10 type vlan id 100
I guess (not tested) when one tagged interface such as eth2.101
is in the bridge, it would get the br7.10 traffic with tag 101.
I think at least it should work when using
iface br0
bridge_ports eth0 eth1...
up ip link add link br7 name br7.10 type vlan id 100
> This might work:
Yes, almost. I tried that with minor modifications it does work:
> iface br0 inet static
> address 10.1.1.1
> netmask 255.255.255.248
# NO: gateway 10.1.1.254
# must be in network of course (SCNR :)):
gateway 10.1.1.7
> bridge_ports eth0
> bridge_ports eth1
>
> iface br0 inet static
> address 10.1.1.2
> netmask 255.255.255.248
# NO: gateway - can have only one default route without printing an error
#NO: bridge_ports eth0
#NO: bridge_ports eth1
When bridge_ports appear again, it does not work. It could be
that in such cases the bridge gets created again - thus losing
all previously configured properties.
Regards,
Steffen
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/caobounpzshglojs8-jdbxrjjm8428dq3nfct7gm3fqhcpcb...@mail.gmail.com
