Begin to write down lpm problem
This commit is contained in:
parent
d0f4f11aaa
commit
f4372580c4
2 changed files with 165 additions and 16 deletions
65
doc/plan.org
65
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
|
||||
|
|
116
p4debug/double-lpm.md
Normal file
116
p4debug/double-lpm.md
Normal 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
|
Loading…
Reference in a new issue