SDFAB-193 Fix routing of GTP End Marker packet-outs on fabric-v1model
This change introduces three fixes:
1) We have observed an issue with p4lang/PI and BMv2 where in presence of
multiple metadata fields, the PI implementation for BMv2 provides an
erroneous serialization of the packet-out header, hence affecting the
parsing/forwarding behavior. As a workaround, since we cannot control
the order of fields in the p4runtime.PacketOut message, we modify the
interpreter to only add one field, egress_port or do_forwarding. Both
fields are treated as mutually exclusive by the P4 pipeline, so the
operation is safe. This is against the P4Runtime spec (all fields should
be provided), but supported by BMv2 (unset fields are initialized to
zero).
2) CPU port was not initialized when calling Pipeliner.init()
3) GTP End Marker were being parsed as GTP-U packets with inner IPv4,
causing a parser error (packet too short).
Change-Id: I406870b4a9aa044b5d0b35a56b0bfde4e601a4f6
(cherry picked from commit ffa7fed9eb3b30221cbc5e23b58c9ac322f8b7f9)
diff --git a/pipelines/fabric/impl/src/main/resources/include/header.p4 b/pipelines/fabric/impl/src/main/resources/include/header.p4
index ce6fcf8..4b4e315 100644
--- a/pipelines/fabric/impl/src/main/resources/include/header.p4
+++ b/pipelines/fabric/impl/src/main/resources/include/header.p4
@@ -125,7 +125,7 @@
bit<64> timestamp;
}
-#ifdef WITH_SPGW
+
// GTPU v1
header gtpu_t {
bit<3> version; /* version */
@@ -139,6 +139,7 @@
teid_t teid; /* tunnel endpoint id */
}
+#ifdef WITH_SPGW
struct spgw_meta_t {
bit<16> ipv4_len;
teid_t teid;