search for: vepa

Paul, I also think that bridge may not be the right place for VEPA, but rather a simpler sw/hw mux Although the VEPA support may reside in multiple places (I.e. also in the bridge) As Arnd pointed out Or already added an extension to qemu that allow direct guest virtual NIC mapping to an interface device (vs using tap), this was done specifically to address VEPA...

Paul, I also think that bridge may not be the right place for VEPA, but rather a simpler sw/hw mux Although the VEPA support may reside in multiple places (I.e. also in the bridge) As Arnd pointed out Or already added an extension to qemu that allow direct guest virtual NIC mapping to an interface device (vs using tap), this was done specifically to address VEPA...

Paul, I also think that bridge may not be the right place for VEPA, but rather a simpler sw/hw mux Although the VEPA support may reside in multiple places (I.e. also in the bridge) As Arnd pointed out Or already added an extension to qemu that allow direct guest virtual NIC mapping to an interface device (vs using tap), this was done specifically to address VEPA...

This patch adds basic Virtual Ethernet Port Aggregator (VEPA) capabilities to the Linux kernel Ethernet bridging code. A Virtual Ethernet Port Aggregator (VEPA) is a capability within a physical end station that collaborates with an adjacent, external bridge to provide distributed bridging support between multiple virtual end stations and external networks....

This patch adds basic Virtual Ethernet Port Aggregator (VEPA) capabilities to the Linux kernel Ethernet bridging code. A Virtual Ethernet Port Aggregator (VEPA) is a capability within a physical end station that collaborates with an adjacent, external bridge to provide distributed bridging support between multiple virtual end stations and external networks....

This patch adds basic Virtual Ethernet Port Aggregator (VEPA) capabilities to the Linux kernel Ethernet bridging code. A Virtual Ethernet Port Aggregator (VEPA) is a capability within a physical end station that collaborates with an adjacent, external bridge to provide distributed bridging support between multiple virtual end stations and external networks....

This patch adds basic Virtual Ethernet Port Aggregator (VEPA) capabilities to the Linux Ethernet bridging utilities. The patch provides functionality that depends on the Linux kernel patch 'net/bridge: add basic VEPA support'. This patch relies on the patch 'bridge-utils: fix sysfs path for setting bridge configuration parameters'. A Vir...

This patch adds basic Virtual Ethernet Port Aggregator (VEPA) capabilities to the Linux Ethernet bridging utilities. The patch provides functionality that depends on the Linux kernel patch 'net/bridge: add basic VEPA support'. This patch relies on the patch 'bridge-utils: fix sysfs path for setting bridge configuration parameters'. A Vir...

This patch adds basic Virtual Ethernet Port Aggregator (VEPA) capabilities to the Linux Ethernet bridging utilities. The patch provides functionality that depends on the Linux kernel patch 'net/bridge: add basic VEPA support'. This patch relies on the patch 'bridge-utils: fix sysfs path for setting bridge configuration parameters'. A Vir...

1. Does vepa mode in libvirt use sr-iov ? 2. How can I do port mirroring with sr-iov? vepa This network uses a macvtap "direct" connection in "vepa" mode to connect each guest to the network (this requires that the physical interfaces used be connected to a vepa-capable hardware...

This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others have found out before me requires significant changes not only to macvlan but also to the common transmit path. I've seen...

This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others have found out before me requires significant changes not only to macvlan but also to the common transmit path. I've seen...

This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others have found out before me requires significant changes not only to macvlan but also to the common transmit path. I've seen...

...es two devices being connected (this virtual link exists purely in the kernel, so performance should be fine). As there is still no connectivity I reduced the setup to the bare minimum, I kickstarted the server, installed QEMU and defined two Debian-based KVM with a 'direct' device in 'vepa' mode and a VETH between them. When started, both KVM create a MACVTAP assigned to each end of the VETH. Both KVM can ping each other (without any additional route configured) and the VETH is LOWER_UP and UP even when no KVM is running. I then replaced one Debian-based KVM with pfSense and bot...

...urrent? > > https://libvirt.org/formatnetwork.html#examplesDirect > > Yes. None of that has changed in any major way in many years. > kernelNewbies documents mactap bridge as VMs can host can all talk to each other without an external bridge External bridge/switch is only needed for VEPA mode with hairpin. https://virt.kernelnewbies.org/MacVTap Perhaps the original development of macvtap to support VEPA influenced the early docs and was never reviewed after bridge mode matured? > > > > I have been able to get host to guest network traffic without any > > spec...

...a look and ack if you are happy so we can get it into 2.6.33. --- Version 1 description: This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others have found out before me requires significant changes not only to macvlan but also to the common transmit path. I've test...

...a look and ack if you are happy so we can get it into 2.6.33. --- Version 1 description: This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others have found out before me requires significant changes not only to macvlan but also to the common transmit path. I've test...

...a look and ack if you are happy so we can get it into 2.6.33. --- Version 1 description: This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others have found out before me requires significant changes not only to macvlan but also to the common transmit path. I've test...

...of questions around macvtap direct usage: 1) is the document here current? https://libvirt.org/formatnetwork.html#examplesDirect I have been able to get host to guest network traffic without any special configuration or switch since Fedora 28 when I first started using it. Using <forward mode=vepa> requires switch port mirroring, but just using <forward mode=bridge> doesn't. 2) do any of the language libraries make assumptions that libvirt networks must have a <bridge name=xx> attribute? Foreman's Ruby interface to libvirt errors out with attempting to build a VM on a...

...a look and ack if you are happy so we can get it into 2.6.33. --- Version 1 description: This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others have found out before me requires significant changes not only to macvlan but also to the common transmit path. I've test...