MacVTap Modes
-
Here are two links I found helpful when wrapping my head around the differences between the modes available for macvtap interfaces for my KVM virtual machines.
https://seravo.fi/2012/virtualized-bridged-networking-with-macvtap
They're a bit older, but the information seems good. The one difference is I noticed with virt-manager on Fedora 32 (was also true with 31 and likely older as well) is that the default mode seems to be bridge rather than VEPA.
VEPA talks about reflective relay or hairpin mode being supported on the switch (802.1Qbg)
Juniper Document
Cisco DocumentIt doesn't look like any of the Ubiquiti EdgeSwitch offerings support this.
-
@EddieJennings What is your us case for VEPA?
Why on earth would you want to add hopes to inter-VM communication?
Not to mention dramatically reducing the vailable bandwidth between two virtual machines.
-
@JaredBusch said in MacVTap Modes:
@EddieJennings What is your us case for VEPA?
I don’t have one in particular. I was curious to know what VEPA was.
Why on earth would you want to add hopes to inter-VM communication?
Not to mention dramatically reducing the vailable bandwidth between two virtual machines.
Personally, I wouldn’t (hops, I assume). Perhaps there some use case where you want to mirror the traffic of the port on the external switch to another port and use this mirroring for some kind of traffic monitoring. I’d like to think there would be some reason for this to be a thing, otherwise it would like the development of it was time wasted.
-
@EddieJennings said in MacVTap Modes:
@JaredBusch said in MacVTap Modes:
@EddieJennings What is your us case for VEPA?
I don’t have one in particular. I was curious to know what VEPA was.
Why on earth would you want to add hopes to inter-VM communication?
Not to mention dramatically reducing the vailable bandwidth between two virtual machines.
Personally, I wouldn’t (hops, I assume). Perhaps there some use case where you want to mirror the traffic of the port on the external switch to another port and use this mirroring for some kind of traffic monitoring. I’d like to think there would be some reason for this to be a thing, otherwise it would like the development of it was time wasted.
Just a FYI, if you want to see VMs network interface stats you can use
virsh domifstat. Here's an example.watch -n1 "sudo virsh domifstat --domain popos --interface vnet0" -
@EddieJennings said in MacVTap Modes:
@JaredBusch said in MacVTap Modes:
@EddieJennings What is your us case for VEPA?
I don’t have one in particular. I was curious to know what VEPA was.
Why on earth would you want to add hopes to inter-VM communication?
Not to mention dramatically reducing the vailable bandwidth between two virtual machines.
Personally, I wouldn’t (hops, I assume). Perhaps there some use case where you want to mirror the traffic of the port on the external switch to another port and use this mirroring for some kind of traffic monitoring. I’d like to think there would be some reason for this to be a thing, otherwise it would like the development of it was time wasted.
Yes, I would guess to support mirroring, external packet capture, IDS/IPS, access control, isolated ports and stuff like that. Maybe 802.1x as well.
One option I didn't see in the redhat doc was openvswitch. Don't they support it?
-
One option I didn't see in the redhat doc was openvswitch. Don't they support it?
The link I posted was for RHEL 6. I just now saw that RHEL 8's documentation is online. I glanced through it and didn't see that mentioned. I'll read it more closely tomorrow.
-
@EddieJennings said in MacVTap Modes:
One option I didn't see in the redhat doc was openvswitch. Don't they support it?
The link I posted was for RHEL 6. I just now saw that RHEL 8's documentation is online. I glanced through it and didn't see that mentioned. I'll read it more closely tomorrow.
There's no mention of openvswitch anywhere in that document. I am aware of XenServer and XCP-ng uses it by default. So its possible RHEL just prefers using macvlan/macvtap instead of openvswitch.
