| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The man page for ovs-vswitchd.conf explains how ingress policing works.
However, what "ingress" means is a bit confusing depending on the
perspective. For vSwitch, it's from the switch's perspective. This
means on a PIF, it's the rate traffic comes into the box. On a VIF,
it's the rate traffic can be *transmitted* from a VM. This commit
clarifies the man page a bit.
Thanks to Johan for pointing out the problem.
|
|
The controller needs to know various things about virtual interfaces as
they move about the network. This commit sends the VIF, virtual
machine, and network UUIDs associated with the VIF, as well as its MAC
address over the management channel.
Feature #1324
|
|
When a bond slave goes down, all of the MACs that were on it are migrated
to another slave, but this is not apparent to the switch that the bond is
connected to until each MAC sends out a packet. This causes incoming
traffic for a given MAC to be dropped until the MAC sends out a packet.
This is not usually a problem, because traffic is not ordinarily one-way,
and we can't avoid losing some packets in some cases, but we can do a
little better by sending out a gratuitous learning packet on the new slave
as soon as we know about it, and that is what this commit implements.
Bug #1290.
|
|
Whether a bond slave is enabled should be based on whether the device's
PHY sees carrier, not based on whether the device is configured up or down.
(Note that a device that is configured down will always see "no carrier").
Otherwise a device that is up but has no carrier will initially be enabled,
which does not make sense.
This has no effect on interfaces that are not bond slaves, because the
"enabled" setting is used only by bond slaves.
Bug #1247.
|
|
This commit sends information about Xen UUIDs to the controller through
the management connection. Specifically, it sends the XenServer UUID
and a list of network UUIDs associated with each datapath.
|
|
|
