Begin to write down lpm problem

4 years ago · f4372580c4
2 changed files with 165 additions and 16 deletions
--- a/doc/plan.org
+++ b/doc/plan.org
@ -123,6 +123,13 @@
 |            | Parsing on wrong field detected by unset fields in wireshark               |       |
 |            | Correcting parser->leads to incorrect checksum                             |       |
 |            | - NDP is answered to, but icmp6 echo request isn't -> extend table         |       |
+|            | Problem with multiple LPM keys in table                                    |       |
+|            | - logical problem, overlapping length matches                              |       |
+|            | - priority / ordering would be helpful                                     |       |
+|            |                                                                            |       |
+|            |                                                                            |       |
+| 2019-03-25 |                                                                            |       |
+|            |                                                                            |       |
 |            |                                                                            |       |
 |            |                                                                            |       |
 | 2019-03-28 | Meet Laurent #4                                                            |       |
@ -1155,17 +1162,28 @@ rtt min/avg/max/mdev = 3.055/3.055/3.055/0.000 ms
 p4@ubuntu:~/master-thesis/p4app$

 **** Requirements
-**** Development mode/loop
-Code - commit - push - pull - restart switch - restart controller -
-check whether tables are applied correctly (type conversion
-problems) - start tcpdump - start test program - stop tcpdump - add
-pcap to git repo - git add-commit-push - git pull - start wireshark -
-debug packets - analyse code - goto 1
 **** Static NAT64
 Asymmetric maps: v6->v4 can match whole IPv4 Internet (/96)
 But v4->v6 can only map sub range!
 Using /24s (for convience) in IPv4
+**** Development mode/loop
+Code - commit - push - pull -
+restart switch - check whether all tables are present (missing .apply())
+restart controller - check whether tables are applied correctly (type conversion problems) -
+start tcpdump - start test program - stop tcpdump - add
+pcap to git repo - git add-commit-push - git pull - start wireshark -
+debug packets - analyse code - goto 1

+**** Setting up a system for working on P4 on devuan
+***** Scripts in the wild
+      https://github.com/nsg-ethz/p4-learning/blob/master/vm/bin/update-p4c.sh
+      https://github.com/jafingerhut/p4-guide/blob/master/bin/install-p4dev-p4runtime.sh
+      https://github.com/nsg-ethz/p4-learning/tree/master/vm/bin
+***** mininet
+***** bmv2
+ [21:24] line:~% sudo apt install libthrift-dev
+ [21:26] line:~% sudo apt install thrift-compiler
+ libnanomsg-dev libjudy-dev
 *** Performance comparison
 *** Feature/Functionality difference / overview / CHALLENGES / LIMITATIONS in P4
 **** P4: cannot read key from table
@ -1238,6 +1256,31 @@ Exists!
     - TYPE_CPU for ethernet
     - Port ingress offset (9 vs. 16 bit)

+**** Only one LPM key supported in tables (2019-03-23)
+#+BEGIN_SRC
+../p4src/static-mapping.p4(121): error: MyIngress.nat64, Multiple LPM keys in table
+    table nat64 {
+          ^^^^^
+Compilation Error
+#+END_SRC
+
+Code:
+#+BEGIN_SRC
+    table nat64 {
+        key = {
+            hdr.ipv6.src_addr: lpm;
+            hdr.ipv6.dst_addr: lpm;
+        }
+        actions = {
+            controller_debug;
+            nat64_static;
+            NoAction;
+        }
+        size = NAT64_TABLE_SIZE;
+        default_action = controller_debug;
+    }
+#+END_SRC
+
 **** (current) Limitations
 ***** No fragmentation support (yet)
 ***** No session handling (yet)
@ -1249,16 +1292,6 @@ has already been solved in a different domain - could even do
 transparent / in network modification
 ***** Incomplete NDP
      Very limited option support
-*** Setting up a system for working on P4 on devuan
-**** Scripts in the wild
-     https://github.com/nsg-ethz/p4-learning/blob/master/vm/bin/update-p4c.sh
-     https://github.com/jafingerhut/p4-guide/blob/master/bin/install-p4dev-p4runtime.sh
-     https://github.com/nsg-ethz/p4-learning/tree/master/vm/bin
-**** mininet
-**** bmv2
-[21:24] line:~% sudo apt install libthrift-dev
-[21:26] line:~% sudo apt install thrift-compiler
-libnanomsg-dev libjudy-dev
 *** References / Follow up
 **** RFC 2460 IPv6 (Checksum https://tools.ietf.org/html/rfc2460#section-8.1)
 **** RFC 3810 MLD2 https://tools.ietf.org/html/rfc3810
--- a/p4debug/double-lpm.md
+++ b/p4debug/double-lpm.md
@ -0,0 +1,116 @@
+## What I want to do: NAT64 static mapping
+
+I want to use different mapped IPv4 networks for (possibly) the same
+destination IPv6 network.
+
+In other words:
+
+* Network A, 2001:db8::/64, sends to an address in 64:ff9b::/96
+* The 8 bit sub network ("range") of 2001:db8::/64, 2001:db8::/120
+  should be mapped to 10.1.0.0/24
+* Network B, 2001:db8:1::/64, sends to an address in 64:ff9b::/96
+* The 8 bit sub network ("range") of 2001:db8:1::/64, 2001:db8:1::/120
+  should be mapped to 10.1.1.0/24
+
+## What I tried to do
+
+### 2 LPM keys
+
+I tried to use one table with two LPM keys, which I would like to
+match "in order":
+
+```
+    table nat64 {
+        key = {
+            hdr.ipv6.src_addr: lpm;
+            hdr.ipv6.dst_addr: lpm;
+        }
+        actions = {
+            controller_debug;
+            nat64_static;
+            NoAction;
+        }
+        size = NAT64_TABLE_SIZE;
+        default_action = controller_debug;
+    }
+```
+
+So matching hdr.ipv6.src_addr first and then if the destination packet
+is in 64:ff9b::/96, then do NAT64.
+
+This results into the compiler problem
+
+```
+../p4src/static-mapping.p4(121): error: MyIngress.nat64, Multiple LPM keys in table
+    table nat64 {
+          ^^^^^
+```
+
+### 2 tables (recommendation of Nate)
+
+It does not work, when matching the source address first:
+
+```
+    table nat64_src {
+        key = {
+            hdr.ipv6.src_addr: lpm;
+        }
+        actions = {
+            NoAction;
+        }
+        size = NAT64_TABLE_SIZE;
+        default_action = NoAction;
+    }
+
+
+    table nat64_dst {
+        key = {
+            hdr.ipv6.dst_addr: lpm;
+        }
+        actions = {
+            controller_debug;
+            nat64_static;
+            NoAction;
+        }
+        size = NAT64_TABLE_SIZE;
+        default_action = controller_debug;
+    }
+
+    ...
+
+    apply {
+        if (nat64_src.apply().hit) {
+            nat64_dst.apply();
+        }
+    }
+
+```
+
+The entries of nat64_dst.apply() will be all the same, i.e. there will
+be many 64:ff9b::/96 entries and thus this approach does not work.
+
+Trying to match the destination address first:
+
+```
+    ...
+
+    apply {
+        if (nat64_dst.apply().hit) {
+            nat64_src.apply();
+        }
+    }
+
+```
+
+This way repeating destination addresses will still not be set, but
+this is not a problem as one is enough to proceed into the nat64_src
+table.
+
+Disadvantage of this approach is that entries from the nat64_dst table
+cannot be deleted safely anymore, as repeating destination addresses
+of other networks might be deleted. So while this approach works for
+testing / development, it does not work for a production setup.
+
+### Ternary matching (recommendation of Andy)
+
+    - Have to investigate