Those are network interfaces, not IP addresses. A network interface can have packets from any protocol exchanged on them, including IPv4 or IPv6, in which case they can be given one or more IP addresses.
virbr
are bridge interfaces. They are virtual in that there's no network interface card associated to them. Their role is to act like a real bridge or switch, that is switch packets (at layer 2) between the interfaces (real or other) that are attached to it just like a real ethernet switch would.
You can assign an IP address to that device, which basically gives the host an IP address on that subnet which the bridge connects to. It will then use the MAC address of one of the interfaces attached to the bridge.
The fact that their name starts with vir
doesn't make them any different from any other bridge interface, it's just that those have been created by libvirt
which reserves that name space for bridge
interfaces
vnet
interfaces are other types of virtual interfaces called tap
interfaces. They are attached to a process (in this case the process runnin the qemu-kvm
emulator). What the process writes to that interface will appear as having been received on that interface by the host and what the host transmits on that interface is available for reading by that process. qemu
typically uses it for its virtualized network interface in the guest.
Typically, a vnet
will be added to a bridge interface which means plugging the VM into a switch.
mangle
is for mangling (modifying) packets, while filter
is intended to just filter packets.
A consequence of this, is that in LOCAL_OUT
, after traversing the tables and getting the filtering decision, mangle
may try to redo the routing decision, assuming the filtering decision is not to drop or otherwise take control of the packet, by calling ip_route_me_harder
, while filter
just returns the filtering decision.
Details at net/ipv4/netfilter/iptable_mangle.c
and net/ipv4/netfilter/iptable_filter.c
.
Best Answer
There are difference between an interface which is administratively up but disconnected or administratively down.
Disconnected
The interface gets a carrier down status. Its proper handling might depend on the driver for the interface and the kernel version. Normally it's available with
ip link show
. For example with a virtual ethernet veth interface:vetha which is itself administratively UP, displays
NO-CARRIER
and the equivalent operstateLOWERLAYERDOWN
flags: it's disconnected.Equivalent
/sys/
entries exist too:In usual settings, for an interface which is administratively up the carrier and operstate match (NO-CARRIER <=> LOWERLAYERDOWN or LOWER_UP <=> UP). One exception would be for example when using IEEE 802.1X authentication (advanced details of operstate are described in this kernel documentation: Operational States, but it's not needed for this explanation).
ethtool
queries a lower level API to retrieve this same carrier status.Having no carrier doesn't prevent any layer 3 settings to stay in effect. The kernel doesn't change addresses or routes when this happens. It's just that in the end a packet that should be emitted won't be emitted by the interface and of course no reply will come either. So for example trying to connect to an other IPv4 address will sooner or later trigger again an ARP request which will fail, and the application will receive a "No route to host". Established TCP connections will just bid their time and stay established.
Administratively down
Above vethb has operstate DOWN and doesn't display any carrier status (since it has to be up to detect this. A physical Ethernet interface of course behaves the same).
When the interface is brought down (
ip link set ... down
), the carrier can't be detected anymore since the underlying hardware device was very possibly powered off and the operstate becomes "down".ethtool
will just say there's no link too, so can't be used reliably for this (it will surely display a few unknown entries too but is there a reliable scheme for this?).This time this will have an effect on layer 3 network settings. The kernel will refuse to add routes using this interface and will remove any previous routes related to it:
proto kernel
) LAN routes added when adding an addressscope link
) or on other previous deleted routes (probably thenscope global
) . As these won't reappear when the interface is brought back up (ip link set ... up
) they are lost until an userspace tool adds them back.Userspace interactions
When using recent tools like NetworkManager, one can get confused and think a disconnect is similar to an interface down. That's because NM monitors links and will do actions when such events happen. To get an idea the
ip monitor
tool can be used to monitor from scripts, but it doesn't have a stable/parsable output currently (no JSON output available), so its use gets limited.So when a wire is disconnected, NM will very likely consider it's not using the current configuration anymore unless a specific setting prevents it: it will then delete the addresses and routes itself. When the wire is connected back, NM will apply its configuration again: adds back addresses and routes (using DHCP if relevant). This looks like the same but isn't. All this time the interface stayed up, or it wouldn't even have been possible for NM to be warned when the connection was back.
Summary
It's easy to distinguish the two cases:
ip link show
will displayNO-CARRIER
+LOWERLAYERDOWN
for a disconnected interface, andDOWN
for an interface administratively brought down.setting an interface administratively down (and up) can lose routes
losing carrier and recovering it doesn't disrupt network settings. If the delay is short enough it should not even disrupt ongoing network connections
but applications managing network might react and change network settings, sometimes with a result similar to administratively down case
you can use commands like
ip monitor link
to receive events about interfaces set administratively down/up or carrier changes, orip monitor
to receive all the multiple related events (including address or route changes) that would happen at this time or shortly after.Most
ip
commands (but notip monitor
) have a JSON output available withip -json ...
to help scripts (along withjq
).Example (continuing from the first veth example):
vethb is still down:
Set vethb up, which now gets a carrier on both:
This tells about the 3 usual states: administratively down, lowerlayerdown (ie: up but disconnected) or up (ie: operational).