~xnox/ubuntu-z-systems/+git/ovs:vlan-maint

Last commit made on 2012-07-10
Get this branch:
git clone -b vlan-maint https://git.launchpad.net/~xnox/ubuntu-z-systems/+git/ovs

Branch merges

Branch information

Name:
vlan-maint
Repository:
lp:~xnox/ubuntu-z-systems/+git/ovs

Recent commits

a2211ea... by Ben Pfaff

ofproto: Preserve in_port across trips through the datapath.

When a "packet out" sent a packet to the datapath and then the datapath
sent the packet back via ODP_ACTION_ATTR_CONTROLLER, the in_port included
in the "packet out" was lost (it became OFPP_LOCAL) because the datapath's
"execute" operation doesn't accept an in_port.

This commit fixes the problem by including the in_port in the userdata
argument to ODP_ACTION_ATTR_CONTROLLER.

NICS-15.
Reported-by: Zoltan Kiss <email address hidden>
CC: David Tsai <email address hidden>
Signed-off-by: Ben Pfaff <email address hidden>

1f86162... by Ben Pfaff

vswitchd: Make the MAC entry aging time configurable.

NICS-11.
Signed-off-by: Ben Pfaff <email address hidden>

5bba469... by Ben Pfaff

mac-learning: Increase MAC learning timeout to 300 seconds.

When Cisco (and other?) routers are configured in high-availability modes,
they use two different MAC addreses. The router uses MAC 1 only for ARP
replies. The router uses MAC 2 for forwarding IP packets to end hosts.
When a MAC learning switch is attached to the router, therefore, it will
only learn the location of MAC 1 from ARP replies. If the end host's ARP
cache refresh timer is longer than the switch's MAC learning timeout, then
packets to the router will be flooded from the MAC learning timeout until
the next ARP reply.

This commit fixes the problem by increasing the MAC learning timeout from
60 seconds to 300 seconds. According to research by Sanjay Sane, this is
always sufficient, even with operating systems that use ARP timeouts
longer than 300 seconds (such as FreeBSD and Mac OS, which have 1200
seconds ARP timeouts) because the routers that cause this problem send
unsolicited ARP replies every 180 seconds.

NICS-11.
Signed-off-by: Ben Pfaff <email address hidden>

d7332cc... by Ben Pfaff

bridge: Add flow in reconfiguring only after flow translation is possible.

If a bridge is in standalone mode and no controllers are configured, and
then reconfiguration (e.g. ovs-vsctl) adds an SLB or TCP-balanced bond,
and at the moment of reconfiguration active kernel flows exist that output
to the newly added bond, then ovs-vswitchd would segfault because the
bond's 'bond_hash' member is not yet initialized when flows are
retranslated as part of adding the flow that ensures normal standalone
switch behavior.

This commit fixes the problem by adding the flow later, after bonds have
been fully initialized.

NIC-443.
Reported-by: Dominic Curran <email address hidden>
Signed-off-by: Ben Pfaff <email address hidden>

6a65da8... by Ben Pfaff

bond: Only drop packets that indicate moves on SLB bonds.

SLB bonds, for important reasons, drop most incoming packets that indicate
that a MAC has moved to the bond from another port. These reasons do not
apply to active-backup bonds, but until now OVS has still dropped them.

This fixes the problem. Behavior of SLB bonds and TCP bonds in SLB
fallback mode is unaffected.

Cross-port of patch f931a4c93075e from master.

Bug #7928.

a52ae92... by Ben Pfaff

datapath: Add compatibility with sk_buff's vlan_tci before 2.6.33.

Between 2.6.27 and 2.6.32, the vlan_tci member of struct sk_buff was the
raw value of the 802.1Q header's TCI field, without the CFI bit being set.
In 2.6.33 and later, the CFI bit is always set if an 802.1Q header is
present, correcting a corner case.

Until now, OVS has not consistently dealt with this. If a packet arrived
at a datapath from a network device directly, or if it was set with an
ODP_ACTION_ATTR_SET_DL_TCI action, then the CFI bit would not be set in
vlan_tci. In flow_extract(), OVS copies vlan_tci directly to dl_tci in the
flow structure (via vlan_get_tci()), so the CFI bit would also not be set
in dl_tci. But if OVS had to send a packet up to userspace (converting the
vlan_tci back to an 802.1Q header along the way) and got it back, then it
would set the VLAN CFI bit in dl_tci when it parsed the 802.1Q header in
parse_vlan(). This had the effect that a flow set up by userspace (with
the CFI bit set) would never be matched by a packet arriving from a network
device, because they would have different dl_tci values.

This fixes the problem, by making the vlan_get_tci() and vlan_set_tci()
interface consistent across kernel versions. Now, they always accept or
return a value where the VLAN CFI bit is set if an 802.1Q header is
present.

Build-tested only.

Problem isolated by Ethan Jackson <email address hidden>

Signed-off-by: Ben Pfaff <email address hidden>
Acked-by: Jesse Gross <email address hidden>
Reported-by: Ram Jothikumar <email address hidden>
Bug #4915.

d2f723f... by Ben Pfaff

ofproto-dpif: Do not mirror L2 multicast switch protocols to VLANs.

Mirroring certain protocols interpreted by switches to a VLAN can deceive
the switch that receives it. Drop such packets instead of mirroring them.

CC: David Tsai <email address hidden>
NIC-401.

85d5d28... by Ethan Jackson <email address hidden>

mac-learning: Fix serious performance bug in the learning table.

Due to a typo, the mac-learning hash table had dissolved into a
linked list. This caused a significant reduction in performance.

f8d9cc5... by Ethan Jackson <email address hidden>

bond: Drop packets on backup slaves.

Currently, OVS accepts incoming traffic on all slaves participating
in a bond. In Linux active-backup bonding, all traffic which comes
in on backup slaves is dropped. This patch causes OVS to do the
same.

Bug #6125.

f63c7f4... by Horms

datapath: An expanded table should be larger than its predecessor

This resolves what appears to be a think-o in tbl_expand()

* Old Logic: Always create tables with TBL_MIN_BUCKETS buckets
* New Logic: Create tables twice as big as their predecessor

When sending 10,000 flows through ovs-vswitchd:
* Old Logic: CPU bound in tbl_lookup(), significant packet loss
* New Logic: ~10% of one core used, negligible packet loss

Tested with an Intel E5520 @ 2.27GHz,
flows from an ethernet device to to a dummy interface with
no address configured.

Signed-off-by: Simon Horman <email address hidden>
Signed-off-by: Jesse Gross <email address hidden>