++doc ++helper scripts

This commit is contained in:
Nico Schottelius 2019-08-16 12:23:35 +02:00
parent 0dedb40ca7
commit b50c46970f
8 changed files with 91 additions and 62 deletions

18
bin/benchmark-prepare-jool.sh Executable file
View File

@ -0,0 +1,18 @@
#!/bin/sh
set -x
sudo /etc/init.d/tayga stop
sudo sysctl -w net.ipv4.conf.all.forwarding=1
sudo sysctl -w net.ipv6.conf.all.forwarding=1
sudo modprobe jool_siit
sudo jool_siit instance add "example" --iptables
sudo jool_siit -i example eamt add 2001:db8:42::/120 10.0.1.0/24
sudo ip6tables -t mangle -A PREROUTING -s 2001:db8:42::/120 -d 2001:db8:23::/120 -j JOOL_SIIT --instance example
sudo iptables -t mangle -A PREROUTING -s 10.0.0.0/24 -d 10.0.1.0/24 -j JOOL_SIIT --instance example
sudo ip addr add 2001:db8:42::77/64 dev eth2
sudo ip link set eth2 up
sudo ip addr add 10.0.0.77/24 dev eth1
sudo ip l s eth1 up

View File

@ -0,0 +1,7 @@
#!/bin/sh
set -x
# Required for NAT64 going into the other side
sudo ip route add 10.0.1.0/24 via 10.0.0.77
sudo ip route add 2001:db8:23::/96 via 2001:db8:42::77

View File

@ -3,50 +3,52 @@
% document. What are the highlights of your work.
% It should conclude by a conclusion.
Sum up what you have done and recapitulate your key findings.
p4 potential
Many possibilities
Protocol independent
Easy architecture
NDP parsing support
Can be deployed using the netpfga. Or Barefoot or Arista.
OUTLOOK What are the consequences of your work for future work?
Different HW
Speed only limited to line speed. Could be running at 100 Gbit/s
without modifications.
PMTU
handling error cases
% General / Review
The objective of implementing high speed NAT64 in P4 has been
achieved. The implementation at hand has been shown to be portable
between 2 different P4 targets. It should be portable with minor
target specific changes to faster hardware to support NAT64 at much
higher line speeds, without any logic changes.
Our algorithm uses the IPv4-Compatible IPv6 Address\cite{rfc4291} to
embed IPv4 addresses. However RFC6052\cite{rfc6052} defines different
embeddings depending on the prefix size. A future version should
support these schemes to be compatible to other implementations.
PMTU
handling error cases
No fragmentation
No address / mac learning
**** No DNS64
has already been solved in a different domain - could even do
transparent / in network modification. DNSSEC.
supporting migration to IPv6 only networks
**** Incomplete NDP
Very limited option support
% P4
P4 has been proven for us as a suitable programming language for
network equipment with great potential. However in the current state
the tooling and frameworks are still immature and need significant
work to become usable for solving day-to-day challenges or supporting
large scale projects. Even with the current state drawbacks, P4 is a
very convincing language that has wide range of applications due to
its protocol independence and easy to understand architecture.
No resolution of hardware addresses
% NetPFGA
The NetFGPA platform is a good showcase for the capabilities of
P4, demonstrating almost line speed P4 programs.
However the supporting code immaturity, logging ambiguity
and enormous complexity of the development process.
Very time intensive development due to usability problems and
uncertainty of functionality (compare sections
\ref{results:netpfga:usability} and \ref{results:netpfga:stability}).
While the port to NetPFGA was significantly more effort then expected,
the learnings of the different layers were very much appreciated / liked
It was a
% Outlook OUTLOOK What are the consequences of your work for future work?
The availability of protocol independent programmable network
equipment opens up many possibilities for in network
programming. While this thesis focused on NAT64, the accompying
technologie DNS64\cite{rfc6147} could also be implemented in P4, thus
completing the translation mechanism.
NetFGPA - conclusion here
Very time intensive development due to usability problems and
uncertainty of functionality (compare sections
\ref{results:netpfga:usability} and \ref{results:netpfga:stability}).
Proxies / higher level protocols could be next level

View File

@ -55,7 +55,7 @@ Tayga & 3.36 & 3.29 & 3.11 \\
\hline
Jool & 8.24 & 8.26 & 8.29\\
\hline
P4 / NetPFGA & 8.43 & 9.29 & 9.29\\
P4 / NetPFGA & 9.28 & 9.29 & 9.29\\
\hline
\end{tabular}
\end{minipage}
@ -160,6 +160,17 @@ table entries.
Jool and tayga are supported by
Trace files
\begin{verbatim}
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1555-h1.pcap
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1555-h3.pcap
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1557-h1.pcap
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1558-h3.pcap
\end{verbatim}
% ----------------------------------------------------------------------
\section{\label{results:netpfga}NetFPGA}
The reduced feature set of the NetPFGA implementation is due to two
@ -382,15 +393,6 @@ Renaming variables in the declaration of the parser or deparser lead
to compilation errors. Function syntax is not supported. For this
reason our implementation uses \texttt{\#define} statements instead of functions.
Trace files
\begin{verbatim}
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1555-h1.pcap
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1555-h3.pcap
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1557-h1.pcap
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1558-h3.pcap
\end{verbatim}
\begin{verbatim}
*** DONE 2019-07-21: Proof of v6->v4 working delta based
@ -490,34 +492,34 @@ Integration with iptables
% ----------------------------------------------------------------------
\section{\label{results:p4}P4}
All planned features could be realised with P4 and a controller.
The language has some limitations on where if/switch statements can be
used.\footnote{In general, if and switch statements in actions lead to
errors, but not all constellations are forbidden.}
For this thesis the parsing capabilities of P4 were adequate. However
P4 at the time of writing cannot parse ICMP6 options, as the upper
level protocol does not specify the number of options that follow and
parsing of 64 bit blocks is required.
P4/BMV2 does not support for multiple LPM keys in a table, however it
supports multiple keys with ternary matching.
When developing P4 programs, the reason for incorrect behaviour was
most often found in checksum problems. If frame checksum errors where
displayed by tcpdump, usually the effective length of the packet was
incorrect.
NDP parsing problem
checksumming a frequent problem and helper
if in action limitations
switch cannot be used in actions
python2 only - unicode errors
IPv6: NDP: not easy to parse, as unknown number of following fields
No support for multiple LPM keys in a table, can be solved with
ternary matching.
if things don't work, often a checksum problem.
if frame checksum, then length of packet is broken
\begin{verbatim}
p4c --target bmv2 --arch v1model --std p4-16 "../p4src/static-mapping.p4" -o "/home/p4/master-thesis/p4src"
../p4src/static-mapping.p4(366): error: Program is not supported by this target, because table MyIngress.v6_networks has multiple successors
table v6_networks {
^^^^^^^^^^^
\end{verbatim}
\begin{verbatim}
ipaddress.ip_network("2001:db8:61::/64")
IPv6Network(u'3230:3031:3a64:6238:3a36:313a:3a2f:3634/128')
@ -536,7 +538,6 @@ or missing features (\cite{schottelius:github745},
Hitting expression bug
retrieving information from tables
\begin{verbatim}
Key and mask for matching destination is in table. We need this

Binary file not shown.

View File

@ -1,6 +1,6 @@
\documentclass[10pt,final,a4paper,twoside]{book}
\newcommand{\watermark}{DRAFT} % a watermark is included on all pages if \watermark is defined here
%\newcommand{\watermark}{DRAFT} % a watermark is included on all pages if \watermark is defined here
%** preamble.tex: here all the document-wide settings
% are defined

View File

@ -3355,6 +3355,7 @@ https://en.wikipedia.org/wiki/IPv4_header_checksum
CLOSED: [2019-08-13 Tue 10:36]
*** DONE Setup / Benchmark tayga
CLOSED: [2019-08-13 Tue 10:36]
*** Redo Jool
* TODO Thesis documentation
** Introduction
*** Related work