Bonds, also known as "teams" or "link aggregation groups" (LAGS), have
the following significant aspects to their behavior:
- Egress, that is, treatment of packets transmitted through the
bond. The choice of a bond interface is the main question on
egress. Bonds can drop packets on egress (e.g. because LACP
negotations are incomplete or because all of the interfaces are
down).
Load-based rebalancing can change egress behavior over time.
Liveness detection (e.g. via carrier or CFM or BFD) can change
egress behavior over time.
- Ingress, that is, treatment of packets received on one of the
bond interfaces. Usually a bond treats a packet that ingresses
on a bond interface as ingressing on the bond itself, but bonds
can drop packets on ingress (e.g. because LACP negotiations are
incomplete or because the packet arrived on a backup interface
in an active-backup bond).
- Protocol, e.g. LACP negotiations and heartbeats.
- Configuration, e.g. OVSDB.
The existing Open vSwitch bonds work this way:
- Ingress and egress behavior occur only as part of the OpenFlow
"normal" action. (This is the default action if Open vSwitch
isn't configured through an OpenFlow controller.)
This is inflexible in some ways because there is otherwise no
way to obtain the ingress and egress behavior. For ingress, it
is possible to add flows to match on each of the OpenFlow ports
for the interfaces in the bond, and act on those packets, but
this will act on packets that the bond would drop on ingress.
There is no equivalent for egress.
Load-based rebalancing occurs if configured.
Liveness detection moves traffic away from interfaces that are
down.
- The LACP protocol is implemented in C code in Open vSwitch.
- Configuration occurs through OVSDB.
One can build a bond-like construct from an OpenFlow "select" group,
by adding the interfaces as output actions in separate buckets in the
group, with the following result:
- Egress behavior is based on an L4 hash in current OVS releases.
OVS doesn't do load-based rebalancing. OVS does rebalance based
on liveness detection. All of these could be changed, but
OpenFlow doesn't provide a way to configure them (and our
experience is that users do want to configure them), or a good
place to do it.
- Ingress behavior doesn't exist as part of the group, since
OpenFlow groups are one-way. I don't know of a way to get
ingress behavior that resembles OVS bond behavior using the flow
table.
- Groups don't support LACP. (An OpenFlow controller might be
able to implement LACP on top of groups.)
- Configuration (adding or deleting the group) occurs through
OpenFlow. This is somewhat awkward because Open vSwitch
considers groups, like flows, to be "soft state" that disappears
from one run to the next, so that restarting OVS or rebooting
will destroy all of your group-based "bonds".
Both approaches have disadvantages, so a natural question is what
direction should one take to obtain more flexible bond behavior in
Open vSwitch. One could start from either approach. However, the
group approach seems awkward to me, because I do not see a benefit in
having both a port number (for ingress) and a group id (for egress)
assigned to a bond, when a port number could serve both purposes.
So the approach that I would suggest is this. First, for backward
compatibility, keep the current behavior (in which bond ingress and
egress are only applied in the "normal" action) by default. However,
add a configuration parameter in OVSDB that causes OVS to create an
OpenFlow port for a bond in addition to the OpenFlow ports for the
interfaces. Behavior for such a bond would be:
- Output to the bond's OpenFlow port would execute the bond's
egress behavior (either redirecting the packet to one of its
interfaces or dropping it). Load-based and liveness based
rebalancing would occur as currently for OVS bonds.
- Ingress on any of the bond's interfaces would execute bond's
ingress behavior. If this behavior didn't drop the packet, then
the packet would pass through the OpenFlow flow table with the
bond's OpenFlow port as the OpenFlow input port and the original
ingress interface's OpenFlow's port as the (OpenFlow 1.1+)
"physical input port".
- LACP implemented as currently.
- Configuration through OVSDB.
On Thu, Jul 10, 2014 at 10:16:30AM -0700, Raghu Gangi wrote:
> Hi All,
>
> I would like to propose and discuss the bond implementation in OpenVSwitch
> using Group tables below:
>
> Design for Bond implementation in OVS:
>
> Existing implementation (based on OpenFlow 1.0):
>
> 1. Creation of bond interface in OVS is done using add-bond command
> * ovs-vsctl add-bond br0 bond1 eth0 eth1
>
> * There are many configuration options for configuring bond interface like
> hashing, slave,delays etc
>
>
> 2. Creation flow rules treat the bond interface as any other physical port.
> * Can be used as both Flow match field and Flow action field
>
> * Very good abstraction so the applications are not worried about the actual
> type of port
> * Consistent with other logical port creations like VxLAN etc
>
>
> Approach 1:
>
> 1. Create a group entry (select type) with list of ports to be added to bond
> interface
> 2. Use the group action to transmit the packet on bond interface
> 3. For any flows that need to use the bond interface as the IN_PORT, we need
> to create multiple identical flows for each physical port in the bonded
> interface.
> * Not recommended as it results in flow explosion.
>
>
> Approach 2:
>
> 1. Create a group entry (select type) with list of ports to be added to bond
> interface
> 2. Use the group action to transmit the packet on bond interface
> 3. Create a bond interface as in current implementation or using group id
> * ovs-vsctl add-bond br0 bond1 eth0 eth1 OR ovs-vsctl add-bond bra bond1
> group=<group_id>
>
> 4. Creation of flow rules to treat the bond interface as any other physical
> port.
>
> Advantages of Approach2 over Approach 1:
>
> * Bond interface could be used for both Flow Match fields (using logical
> port) and Flow Actions (using Group ID)
> * Backward compatibility with existing implementation
>
> It would be great if you can provide your comments on these different
> approaches.
>
> Thanks,
> Raghu
>
> ---------- Forwarded message ----------
> From: Andy Zhou <az...@nicira.com<mailto:az...@nicira.com>>
> Date: Mon, Jun 16, 2014 at 11:16 PM
> Subject: Re: [ovs-dev] LAG support in OVS
> To: Raghu Ram <raghuramga...@gmail.com<mailto:raghuramga...@gmail.com>>
> Cc: "dev@openvswitch.org<mailto:dev@openvswitch.org>"
> <dev@openvswitch.org<mailto:dev@openvswitch.org>>
>
>
> You are right. Current bond implementation is based on earlier OVS
> that only supports openflow version 1.0 and 1.1.
> As you have pointed out, now that group is supported, it is feasible
> to leverage the group facility to implement bond.
>
> Do you have more detailed suggestions or implementation to contribute?
>
>
>
>
> On Mon, Jun 16, 2014 at 10:30 AM, Raghu Ram
> <raghuramga...@gmail.com<mailto:raghuramga...@gmail.com>> wrote:
> > Hi All,
> >
> > I have a query on LAG (Bonding) support in OpenVswitch.
> >
> > Is the LAG implementation in OVS not based on Group tables?
> >
> > I see that LAG (Bond) interface creation in OVS happens through non-OpenFlow
> > means and not through an "select" group entry.
> >
> > Thanks,
> > Raghu
> >
> > _______________________________________________
> > dev mailing list
> > dev@openvswitch.org<mailto:dev@openvswitch.org>
> > http://openvswitch.org/mailman/listinfo/dev
> >
>
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
