This is to cope with the situation where an ICMP reply is generated
by the tunneling code in the datapath in which case the input port
will be a tunnel tundev which has no bundle.
Cc: Kyle Mestery <kmest...@cisco.com>
Signed-off-by: Simon Horman <ho...@verge.net.au>
---
v5
* No Change
v4
* No Change
v3
* Initial posting
---
ofproto/ofproto-dpif.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index cccaea5..dc050bf 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofproto-dpif.c
@@ -6116,6 +6116,12 @@ lookup_input_bundle(const struct ofproto_dpif *ofproto,
uint16_t in_port,
return &ofpp_none_bundle;
}
+ if (ofport->tun) {
+ VLOG_WARN("bridge %s: received packet on tundev "
+ "port %"PRIu16, ofproto->up.name, flow->in_port);
+ return &ofpp_none_bundle;
+ }
+
/* Odd. A few possible reasons here:
*
* - We deleted a port but there are still a few packets queued up
@@ -6161,7 +6167,7 @@ is_admissible(struct ofproto_dpif *ofproto, const struct
flow *flow,
return false;
}
- if (in_bundle->bond) {
+ if (in_bundle && in_bundle->bond) {
struct mac_entry *mac;
switch (bond_check_admissibility(in_bundle->bond, in_port,
--
1.7.10.2.484.gcd07cc5
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
