Steve Litt <slitt@???> wrote:

> The vast majority of documents I've read tell me that once you make the
> bridge, the hardware NIC must be robbed of its IP addresses. So that's
> what I did.

That is the correct way to do it - though from memory it does seem to still work for host-LAN communications if you use an IP address on the physical NIC. By putting IP address(es) on the bridge, it's functionally identical to having a host virtual NIC which connects to that bridge and hence via another NIC to the LAN. To a certain extent I think the relationship between a host physical NIC and a virtual bridge it's connected to can be a bit schizophrenic as I notice that my bridge has the same MAC address as the physical NIC it's connected to - possibly it just gets the MAC address of the first NIC to be connected to it though I've never tested that.


There is one thing I'm unclear about in your document, and that's the object you refer to as mybridge0.

My experience is with Xen, which is configured almost identically to how you show it, and I believe uses QEMU for some functions. What you call mybridge0 and describe as a bridge, in the Xen world is (by default) called vifn.m‡ and is a virtual NIC. I'm suspecting that what you call mybridge0 is in fact a virtual NIC which connects to the bridge br0.
Thus what you have is the bridge (analogous to a network switch), with a virtual NIC (mybridge0) connected to it - then there's a virtual point-point network link between that and eth0 in the guest.

I'm guessing that "brctl show" will probably show something like this :
bridge name     bridge id               STP enabled     interfaces
br0             8000.2cf05d7a5c1d       no              enp40s0
                                                        mybridge0

‡ Where n is the id (number) of the guest, and m is the interface number starting with 0 for the first and incrementing if multiple VIFs are created. I forget how many I've got to with one guest, I don't think it was double digits although it must have been close !
I don't actually use the vifm.n format - I prefer to manually specify "meaningful" names (specified in the network section for creating a Xen guest) that make it easier to see what's connected to what.

If you do see that, then it would avoid a lot of confusion to do a global find & replace to rename mybridge0 to something more like a NIC.

https://wiki.xenproject.org/wiki/Xen_Networking#Paravirtualised_Network_Devices may help

Oh yes, and use a different name for each guest - having two guests configured to use the same name for the host end of their virtual link produces "interesting" results.



Lastly, there is a definite point of correction to be made.
A bridge/switch is **NOT** "kinda-sorta like a network router in that it connects two distinct IP address ranges into one network", and nor is it a hub (though it does behave at the most basic level in the same way). A switch is IP address, and even protocol, agnostic - unless you apply filtering (e.g. ebtables on Linux) then it simply forwards packets without caring what is in them. In this respect, it is mostly definitely in no way "kinda-sorta like a network router" !
The difference between a bridge/switch and a hub is that a switch is clever about which ports it sends traffic out on. It keeps track of what MAC addresses are connected to each port, and will only send a packet out of the appropriate port. Thus point-point traffic does not appear on other links - which means that (e.g.) A can talk at full wire speed to B, while C can talk to D at full wire speed assuming that A-D are connected to different switch ports.
A hub is "dumb" - every packet it receives is simply repeated out of every other port with no buffering or delay. Thus every node in the network sees all traffic, and the entire network is one flat collision domain. With a switch, it will queue packets destined for a port that is already carrying a packet - and thus splits the collision domain up.
https://en.wikipedia.org/wiki/Network_switch

On Linux, you can see the MAC forwarding table (for bridge br0) with "brctl showmacs br0" which should produce output like :
port no    mac addr                is local?       ageing timer
  1     00:16:3e:xx:xx:xx       no                24.96
  4     00:16:3e:xx:xx:xx       no                 0.13
  1     00:1e:0b:xx:xx:xx       yes                0.00
...
00:16:3e is the OUI prefix used by Xen - so those first two lines are virtual machines

Simon