Bug#835420: bridge-utils: enabling rp_filter causes network to hang
Hi! This is starting to be a question on how to to things and not a bugreport. I still cannot understand what you really are trying to do, for interfaces with a name you want you should look at iproute's doc, the ip command can give you aliases with any name you want, for info on how to do this on /etc/network/interfaces the doc of ifupdown starting with man interfaces should guide you. If you still feel you want a bridge and that there is an issue with that on Debian, like you seem to suggest here: > If the original eth0 is brought up first, and then the bridge (say, eth1) > (or br1) is brought up second there are no issues really to begin with. > > However if the eth0 is then brought down, and we test the connection, the > bridge still functions, but eth0 doesn't work anymore. Then, if I bring down > the bridge and bring it back up again, eth0 functions again. I need to know what is broken, like you have just explained here, but also the files that may have implications with the bridge-utils behaviour here, like the full /etc/network/interfaces and also /etc/default/bridge-utils And if you send me the status of the interfaces before and after doing those commands and what commands you are really using then it would be great. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#835420: bridge-utils: enabling rp_filter causes network to hang
Well I am sorry for disrupting your day here. There appear to be more issues as you may have indicated. If the original eth0 is brought up first, and then the bridge (say, eth1) (or br1) is brought up second there are no issues really to begin with. However if the eth0 is then brought down, and we test the connection, the bridge still functions, but eth0 doesn't work anymore. Then, if I bring down the bridge and bring it back up again, eth0 functions again. But I tried -- and I am not trying to turn this into a support request form -- to use virtual interfaces solely (aliases) and the thing that didn't work is that dhcp (dhclient) didn't like being told to use eth0:0. So useing aliases is not without issue either, it seems. It's probably the proper solution but for now my bridge works, no matter how unreliable :p. I just don't know what alternative there is to create a named interface out of some other interface. I assume basing the bridge on the alias would work; that is what it seemed to be doing. Having a bridge with its own IP and a root device with its own IP is not much different from having two aliases with their own IP, right?
Bug#835420: bridge-utils: enabling rp_filter causes network to hang
Santiago Garcia Mantinan schreef op 04-09-2016 1:15: If you only have one network card I don't see why you should use a bridge at all, having two addresses on a network card either using card aliases (eth0:X) or several IPs on the same card using ip commands on a up statement is ok, but that doesn't have to do anything with bridges. I realize that that is probably completely true, my mistake. Without sufficient "schooling" I have to go by what the tutorials say. A bridge seems to be a kind of ready-to-go thing a kind of easy-to-use thing, an easy way to create a virtual named interface to which you can ascribe some other interface's address or port. After all, whether a bridge only has one interface or none at all (one port bound to it, or none at all) doesn't really make a rat's ass difference ;-). You can even create a bridge with no ports and assign it an IP. In the latter case, is there another way to create a virtual interface? I assume there is; the tutorials just only talk about bridges. So my mistake has been to use a port whose real interface already had an IP (not the alias) and I assumed the alias cq. virtual interface would act as a separate thing, when it didn't. The issue I had with the alias was that I cannot rename them, but I can give the bridge any name I want. Also, it already worked save for the rp_filter thing ;-). So my alternative would be to use eth0:0 and eth0:1. Everything I can find about general "virtual interfaces" base them on actual existing non-virtual interfaces. So, for example, how do I create an interface with no attached device that merely acts as a connection point for an internal network? I used a bridge for that. The only purpose this bridge had was to hold an IP address. It appears I cannot just create a random interface, but doing brctl addbr works without flaw. And if I add that to /etc/network/interfaces, I have a random interface without ports or devices and it works to attach an IP to it. So for me the bridge means "create a virtual interfaces without attached devices, and do with it what you want". Please elucidate if that is not so. Regards.
Bug#835420: bridge-utils: enabling rp_filter causes network to hang
> So what if I want two separate "devices" with two separate IP addresses? I > don't want all addresses on that bridge. Sorry, I don't understand, what do you mean by separate? Typically if you are using a bridge it is because you want to link together several network segments on different cards so that all those segments are on the same level 2 network. What are you trying to do? How many cards do you have enslaved to the bridge? > There are a few options that I can see: > > - create two bridges and give each of them an IP, but not the device itself > - don't use bridges, and only use virtual interfaces: eth0:0, eth0:1. > > - or a mixture: eth0:0 == ip address, eth0:1 -> br1 == ip address. > > But that seems like the same thing to me. If you only have one network card I don't see why you should use a bridge at all, having two addresses on a network card either using card aliases (eth0:X) or several IPs on the same card using ip commands on a up statement is ok, but that doesn't have to do anything with bridges. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#835420: bridge-utils: enabling rp_filter causes network to hang
Santiago Garcia Mantinan schreef op 27-08-2016 12:02: On Aug 25 2016, Dryden Personalis wrote: iface eth0 inet dhcp iface eth0:1 inet manual There is a problem here, these two lines shouldn't exist at all. iface br1 inet static bridge_ports eth0:1 bridge_fd 0 address netmask 255.255.255.0 Because you are using at br1 an alias of the interface that DHCP is assigning the IP to. You shouldn't assign an IP to an interface you are using on the bridge, instead assign the IP to the bridge itself: iface br1 inet dhcp bridge_ports eth0 If you want more addresses you can add them later in the same br1 definition with an up statement using ifconfig or ip addr add, for example. The thing here is to assign the IPs to br1, not to its bridged interfaces. So what if I want two separate "devices" with two separate IP addresses? I don't want all addresses on that bridge. There are a few options that I can see: - create two bridges and give each of them an IP, but not the device itself - don't use bridges, and only use virtual interfaces: eth0:0, eth0:1. - or a mixture: eth0:0 == ip address, eth0:1 -> br1 == ip address. But that seems like the same thing to me.
Bug#835420: bridge-utils: enabling rp_filter causes network to hang
On Aug 25 2016, Dryden Personalis wrote: > iface eth0 inet dhcp > iface eth0:1 inet manual There is a problem here, these two lines shouldn't exist at all. > iface br1 inet static > bridge_ports eth0:1 > bridge_fd 0 > address > netmask 255.255.255.0 Because you are using at br1 an alias of the interface that DHCP is assigning the IP to. You shouldn't assign an IP to an interface you are using on the bridge, instead assign the IP to the bridge itself: iface br1 inet dhcp bridge_ports eth0 If you want more addresses you can add them later in the same br1 definition with an up statement using ifconfig or ip addr add, for example. The thing here is to assign the IPs to br1, not to its bridged interfaces. If you do it that way you won't find weird problems. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#835420: bridge-utils: enabling rp_filter causes network to hang
Package: bridge-utils Version: 1.5-9 Severity: important Dear Maintainer, As I was strolling through the nightmares of the Debian and/or real world Well. When you set up a bridge (as far as I can tell, any) based on an existing interface (such as eth0) and then run a firewall that will enable rp_filter for that bridge device, the entire network will hang including the origin device of the bridge. In this case the thing was configured using: /etc/network/interfaces: iface eth0 inet dhcp iface eth0:1 inet manual iface br1 inet static bridge_ports eth0:1 bridge_fd 0 address netmask 255.255.255.0 Each time the firewall would run, the network would block until I found it was basically caused by a single line, saying: echo 1 > /proc/sys/net/ipv4/conf/br1/rp_filter I do not know how this works behind the schemes .. but activiting this on an unrelated bridge (that does not have any ports mapped to it) does not actually kill the connection in the same way. Since br1 is based on eth0:1 which is based on eth0, it apparently just kills that by whatever I don't know, and the system does not have other devices for connecting to it, so I cannot test anything else. I should note that the system runs 3.16.0-4-amd64 from Debian 3.16.7-ckt25-2 on Jessie from (2016-04-08) on x64-64 virtualized within QEMU (i440FX, PIIX, 1996) although that will probably be quite irrelevant. This happens irrespective of any firewall rules being present and also with a default routing table. Meaning, I can kill my network using the above command no matter what the state of my system is. As long as the bridge is activated and put online, I assume. Regards, Dryden. Oh, I can usually (but not always) reverse the situation by echoing 0 into it again. For some reason that never seems to work all that well when more stuff has happened, but I'm not sure. Thus far I have been able to revert it after manually causing it. -- System Information: Debian Release: 8.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages bridge-utils depends on: ii libc6 2.19-18+deb8u4 bridge-utils recommends no packages. Versions of packages bridge-utils suggests: ii ifupdown 0.7.53.1 -- no debconf information
