nico/master-thesis
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Begin to write down lpm problem

Browse source
This commit is contained in:
Nico Schottelius 2019-03-25 11:13:21 +01:00
commit f4372580c4
2 changed files with 165 additions and 16 deletions
Download patch file Download diff file Expand all files Collapse all files

65
doc/plan.org
View file

@ -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

116
p4debug/double-lpm.md Normal file
View file

@ -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