Using 2 nic's in bonding mode

mstriebeck

Member
Jul 4, 2021
7
0
6
56
Hi,

I know VERY little about networking, so please excuse if this is a trivial question...
I have a server that has 2 network cards. The switch that it is connected to does not support link aggregation.

a) can I still use the two nic's in bonding mode?

b) ip -a shows the following:
2: enp65s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
link/ether fc:34:97:b1:7d:9c brd ff:ff:ff:ff:ff:ff
3: enp65s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether fc:34:97:b1:7d:9d brd ff:ff:ff:ff:ff:ff
4: enxb2b7f1fd5486: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether b2:b7:f1:fd:54:86 brd ff:ff:ff:ff:ff:ff

I am not sure what the enxb2b7f1fd5486 adapter is. If and how do I use it in my network config?

Thanks for any help or pointers (and patience!)
Mark
 
Don't forget to add "bridge-ageing 0" in the configuration stanza for your bridge - for me, it doesn't work (properly) without it.
 
@spirit, I read the same somewhere, but... (a) my use case is limited and (b) I don't see it happening (or I am not checking the right things).
(a) Limited use case - this is a private network, used for a homelab. No risk of collision / flooding / eavesdropping. I do like to do things neatly though.
(b) I actually checked this. In my very limited understanding, with a hub, every packet is sent to every port. Those who are interested (i.e. IP/MAC match) keep it, the others discard it. Conversely, listening on one host connected to the hub should reveal the traffic of other hosts connected to the same hub. Am I right so far?

Where it doesn't happen (in my experiments):
I tested this with my 3 PVE hosts, all connected to the same unmanaged switch, all with "bridge-ageing 0" set on their respective vmbr0 interface (which sits atop a bond0 in balance-rr):
- ran a ping from node1 to node2 and ran "tcpdump -ni any | grep -i icmp" on node3; result: no packets captured
- same as above, but ran tcpdump on another host, not connected to the same switch (but still in the same LAN); result: no packets captured
- ran a ping from node1 to node2 and ran the above tcpdump from a VM on node1; result: no packets captured
- re-ran the two tests above setting every interface (vmbr0 on each host, eth0 on the VM) to promisc mode manually; result: no packets captured
- ran a "tcpdump -ni any | grep node1_IP | grep -v node3_ip" on node3 (with every single interface in promisc mode), to see if it gets any packet at all from node1 which isn't destined for node3; result: no packets captured

The only traffic I was able to capture was in the node1 tcpdump when pinging from the VM on node1 (which is IMHO normal, as the VM has a tapXXXXX interface on that exact host).

Where it does happen (in my experiments):
Further testing did find something though, at guest level.
If the VMs are in the same VLAN and on the same host (so basically using the same vmbr0 as a switch/hub), then they can see each other's traffic indeed. It doesn't happen across VLANs (i.e. VMs on the same host, but different VLANs), or across hosts (VMs in the same VLAN, but on different hosts). I suppose this is indeed what @spirit was referring to and I misunderstood.

Bottom line - use at your own risk. I would definitely NOT advise using this in a production environment at this point.
 
Last edited:

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!