Compare commits
36 Commits
f80fa95cf5
...
main
| Author | SHA1 | Date | |
|---|---|---|---|
|
c0d67ceec0 | ||
|
|
c3202e229a | ||
|
|
958e0b9ef0 | ||
|
|
9962ec0738 | ||
|
|
67b40fe8af | ||
| bd47073bf4 | |||
|
|
29b6a69a70 | ||
|
|
2ba65bb11c | ||
|
|
000d0b90fb | ||
|
|
3ac91d6da8 | ||
| 5085b3e2e8 | |||
| b454089ca1 | |||
| 62b89bae2f | |||
|
|
cab7babbb1 | ||
|
|
6d14b30e89 | ||
| 3d18ba261b | |||
| 5c4f2b8b93 | |||
| aae17bb238 | |||
| 91b8601a1e | |||
| 308085d03f | |||
| 3e1acd6282 | |||
| eb97ca67da | |||
|
|
9daba5a289 | ||
|
|
7fb4a4b780 | ||
| e0f8f0bfe2 | |||
| 4de1e3ad96 | |||
| 67d0131521 | |||
| 9b7e7bfb1c | |||
| 2c21b002fd | |||
| b01f59cc93 | |||
| b9388e579e | |||
| c6e384433b | |||
| d640abcdb2 | |||
| c3ff61a558 | |||
| 8ee261064b | |||
| fb600dc1e3 |
3
.gitignore
vendored
3
.gitignore
vendored
@@ -11,4 +11,5 @@ main.out
|
||||
main.pdf
|
||||
main.run.xml
|
||||
main.synctex.gz
|
||||
main.toc
|
||||
main.toc
|
||||
.DS_Store
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
BIN
Blatt01/PDFsam_merge.pdf
Normal file
BIN
Blatt01/PDFsam_merge.pdf
Normal file
Binary file not shown.
BIN
Blatt01/assets/Screenshot 2024-11-02 095616.png
Normal file
BIN
Blatt01/assets/Screenshot 2024-11-02 095616.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
BIN
Blatt01/assets/automaton.drawio.png
Normal file
BIN
Blatt01/assets/automaton.drawio.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 62 KiB |
BIN
Blatt01/assets/image-20241102101523676.png
Normal file
BIN
Blatt01/assets/image-20241102101523676.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 40 KiB |
BIN
Blatt01/assets/image-20241102152521592.png
Normal file
BIN
Blatt01/assets/image-20241102152521592.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 44 KiB |
BIN
Blatt01/assets/image-20241102153117886.png
Normal file
BIN
Blatt01/assets/image-20241102153117886.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 36 KiB |
BIN
Blatt01/assets/image-20241102171139781.png
Normal file
BIN
Blatt01/assets/image-20241102171139781.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 61 KiB |
BIN
Blatt01/assets/image-20241104210518954.png
Normal file
BIN
Blatt01/assets/image-20241104210518954.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 172 KiB |
158
Blatt01/automaton.drawio
Normal file
158
Blatt01/automaton.drawio
Normal file
@@ -0,0 +1,158 @@
|
||||
<mxfile host="Electron" agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/24.7.17 Chrome/128.0.6613.36 Electron/32.0.1 Safari/537.36" version="24.7.17">
|
||||
<diagram name="Page-1" id="c7488fd3-1785-93aa-aadb-54a6760d102a">
|
||||
<mxGraphModel dx="1728" dy="998" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="1100" pageHeight="850" background="none" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0" />
|
||||
<mxCell id="1" parent="0" />
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-6" value="" style="shape=table;startSize=0;container=1;collapsible=0;childLayout=tableLayout;fontSize=16;" vertex="1" parent="1">
|
||||
<mxGeometry x="200" y="90" width="160" height="160" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-7" value="" style="shape=tableRow;horizontal=0;startSize=0;swimlaneHead=0;swimlaneBody=0;strokeColor=inherit;top=0;left=0;bottom=0;right=0;collapsible=0;dropTarget=0;fillColor=none;points=[[0,0.5],[1,0.5]];portConstraint=eastwest;fontSize=16;" vertex="1" parent="ARffzCTJVVxupl663M9X-6">
|
||||
<mxGeometry width="160" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-9" value="<font style="font-size: 10px;">Determine Prefix Length&nbsp;</font>" style="shape=partialRectangle;html=1;whiteSpace=wrap;connectable=0;strokeColor=inherit;overflow=hidden;fillColor=none;top=0;left=0;bottom=0;right=0;pointerEvents=1;fontSize=16;" vertex="1" parent="ARffzCTJVVxupl663M9X-7">
|
||||
<mxGeometry width="160" height="30" as="geometry">
|
||||
<mxRectangle width="160" height="30" as="alternateBounds" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-11" value="" style="shape=tableRow;horizontal=0;startSize=0;swimlaneHead=0;swimlaneBody=0;strokeColor=inherit;top=0;left=0;bottom=0;right=0;collapsible=0;dropTarget=0;fillColor=none;points=[[0,0.5],[1,0.5]];portConstraint=eastwest;fontSize=16;" vertex="1" parent="ARffzCTJVVxupl663M9X-6">
|
||||
<mxGeometry y="30" width="160" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-13" value="<p style="text-align: left; line-height: 90%; font-size: 10px;"><font style="font-size: 10px;">Input: IP address with CIDR prefix length (e.g., <code style="">/24</code>, <code style="">/16</code>)</font></p><p style="text-align: left; line-height: 90%; font-size: 10px;"><font style="font-size: 10px;">output: Prefix length</font></p><p></p>" style="shape=partialRectangle;html=1;whiteSpace=wrap;connectable=0;strokeColor=inherit;overflow=hidden;fillColor=none;top=0;left=0;bottom=0;right=0;pointerEvents=1;fontSize=16;" vertex="1" parent="ARffzCTJVVxupl663M9X-11">
|
||||
<mxGeometry width="160" height="60" as="geometry">
|
||||
<mxRectangle width="160" height="60" as="alternateBounds" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-15" value="" style="shape=tableRow;horizontal=0;startSize=0;swimlaneHead=0;swimlaneBody=0;strokeColor=inherit;top=0;left=0;bottom=0;right=0;collapsible=0;dropTarget=0;fillColor=none;points=[[0,0.5],[1,0.5]];portConstraint=eastwest;fontSize=16;" vertex="1" parent="ARffzCTJVVxupl663M9X-6">
|
||||
<mxGeometry y="90" width="160" height="70" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-17" value="<p style="line-height: 90%; font-size: 10px;"><font face="Helvetica">Parse the CIDR prefix to understand the network range. For instance, <code>192.168.1.0/24</code> has a prefix length of 24 bits.</font></p>" style="shape=partialRectangle;html=1;whiteSpace=wrap;connectable=0;strokeColor=inherit;overflow=hidden;fillColor=none;top=0;left=0;bottom=0;right=0;pointerEvents=1;fontSize=16;align=left;" vertex="1" parent="ARffzCTJVVxupl663M9X-15">
|
||||
<mxGeometry width="160" height="70" as="geometry">
|
||||
<mxRectangle width="160" height="70" as="alternateBounds" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-19" value="" style="shape=table;startSize=0;container=1;collapsible=0;childLayout=tableLayout;fontSize=16;" vertex="1" parent="1">
|
||||
<mxGeometry x="460" y="90" width="160" height="160" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-20" value="" style="shape=tableRow;horizontal=0;startSize=0;swimlaneHead=0;swimlaneBody=0;strokeColor=inherit;top=0;left=0;bottom=0;right=0;collapsible=0;dropTarget=0;fillColor=none;points=[[0,0.5],[1,0.5]];portConstraint=eastwest;fontSize=16;" vertex="1" parent="ARffzCTJVVxupl663M9X-19">
|
||||
<mxGeometry width="160" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-21" value="<font style="font-size: 10px;"> Read Network ID</font>" style="shape=partialRectangle;html=1;whiteSpace=wrap;connectable=0;strokeColor=inherit;overflow=hidden;fillColor=none;top=0;left=0;bottom=0;right=0;pointerEvents=1;fontSize=16;" vertex="1" parent="ARffzCTJVVxupl663M9X-20">
|
||||
<mxGeometry width="160" height="30" as="geometry">
|
||||
<mxRectangle width="160" height="30" as="alternateBounds" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-22" value="" style="shape=tableRow;horizontal=0;startSize=0;swimlaneHead=0;swimlaneBody=0;strokeColor=inherit;top=0;left=0;bottom=0;right=0;collapsible=0;dropTarget=0;fillColor=none;points=[[0,0.5],[1,0.5]];portConstraint=eastwest;fontSize=16;" vertex="1" parent="ARffzCTJVVxupl663M9X-19">
|
||||
<mxGeometry y="30" width="160" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-23" value="<p style="text-align: left; line-height: 90%; font-size: 10px;"><font style="font-size: 10px;">Input: IP address and CIDR prefix length</font></p><p style="text-align: left; line-height: 90%; font-size: 10px;"><font style="font-size: 10px;">output: Network ID</font></p><p></p>" style="shape=partialRectangle;html=1;whiteSpace=wrap;connectable=0;strokeColor=inherit;overflow=hidden;fillColor=none;top=0;left=0;bottom=0;right=0;pointerEvents=1;fontSize=16;" vertex="1" parent="ARffzCTJVVxupl663M9X-22">
|
||||
<mxGeometry width="160" height="60" as="geometry">
|
||||
<mxRectangle width="160" height="60" as="alternateBounds" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-24" value="" style="shape=tableRow;horizontal=0;startSize=0;swimlaneHead=0;swimlaneBody=0;strokeColor=inherit;top=0;left=0;bottom=0;right=0;collapsible=0;dropTarget=0;fillColor=none;points=[[0,0.5],[1,0.5]];portConstraint=eastwest;fontSize=16;" vertex="1" parent="ARffzCTJVVxupl663M9X-19">
|
||||
<mxGeometry y="90" width="160" height="70" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-25" value="<p style="line-height: 90%; font-size: 10px;">Extract the network ID from the IP address based on the prefix length.&nbsp;<br></p>" style="shape=partialRectangle;html=1;whiteSpace=wrap;connectable=0;strokeColor=inherit;overflow=hidden;fillColor=none;top=0;left=0;bottom=0;right=0;pointerEvents=1;fontSize=16;align=left;" vertex="1" parent="ARffzCTJVVxupl663M9X-24">
|
||||
<mxGeometry width="160" height="70" as="geometry">
|
||||
<mxRectangle width="160" height="70" as="alternateBounds" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-26" value="" style="shape=table;startSize=0;container=1;collapsible=0;childLayout=tableLayout;fontSize=16;" vertex="1" parent="1">
|
||||
<mxGeometry x="200" y="310" width="160" height="160" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-27" value="" style="shape=tableRow;horizontal=0;startSize=0;swimlaneHead=0;swimlaneBody=0;strokeColor=inherit;top=0;left=0;bottom=0;right=0;collapsible=0;dropTarget=0;fillColor=none;points=[[0,0.5],[1,0.5]];portConstraint=eastwest;fontSize=16;" vertex="1" parent="ARffzCTJVVxupl663M9X-26">
|
||||
<mxGeometry width="160" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-28" value="<font style="font-size: 10px;">Longest Prefix Matching</font>" style="shape=partialRectangle;html=1;whiteSpace=wrap;connectable=0;strokeColor=inherit;overflow=hidden;fillColor=none;top=0;left=0;bottom=0;right=0;pointerEvents=1;fontSize=16;" vertex="1" parent="ARffzCTJVVxupl663M9X-27">
|
||||
<mxGeometry width="160" height="30" as="geometry">
|
||||
<mxRectangle width="160" height="30" as="alternateBounds" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-29" value="" style="shape=tableRow;horizontal=0;startSize=0;swimlaneHead=0;swimlaneBody=0;strokeColor=inherit;top=0;left=0;bottom=0;right=0;collapsible=0;dropTarget=0;fillColor=none;points=[[0,0.5],[1,0.5]];portConstraint=eastwest;fontSize=16;" vertex="1" parent="ARffzCTJVVxupl663M9X-26">
|
||||
<mxGeometry y="30" width="160" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-30" value="<p style="line-height: 90%;"></p><div style="text-align: left;"><font style="background-color: initial; font-size: 10px;">Input:&nbsp;</font><span style="background-color: initial;"><font style="font-size: 10px;">Network ID</font></span></div><span style="font-size: 10px; background-color: initial;"><div style="text-align: left;"><span style="background-color: initial;">output: Matching route entry</span></div></span><p></p><p></p>" style="shape=partialRectangle;html=1;whiteSpace=wrap;connectable=0;strokeColor=inherit;overflow=hidden;fillColor=none;top=0;left=0;bottom=0;right=0;pointerEvents=1;fontSize=16;" vertex="1" parent="ARffzCTJVVxupl663M9X-29">
|
||||
<mxGeometry width="160" height="60" as="geometry">
|
||||
<mxRectangle width="160" height="60" as="alternateBounds" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-31" value="" style="shape=tableRow;horizontal=0;startSize=0;swimlaneHead=0;swimlaneBody=0;strokeColor=inherit;top=0;left=0;bottom=0;right=0;collapsible=0;dropTarget=0;fillColor=none;points=[[0,0.5],[1,0.5]];portConstraint=eastwest;fontSize=16;" vertex="1" parent="ARffzCTJVVxupl663M9X-26">
|
||||
<mxGeometry y="90" width="160" height="70" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-32" value="<p style="line-height: 90%; font-size: 10px;">&nbsp;Search the routing table for all matching entries, and select the entry with the longest prefix, ensuring that the CIDR router picks the most specific route.<br></p>" style="shape=partialRectangle;html=1;whiteSpace=wrap;connectable=0;strokeColor=inherit;overflow=hidden;fillColor=none;top=0;left=0;bottom=0;right=0;pointerEvents=1;fontSize=16;align=left;" vertex="1" parent="ARffzCTJVVxupl663M9X-31">
|
||||
<mxGeometry width="160" height="70" as="geometry">
|
||||
<mxRectangle width="160" height="70" as="alternateBounds" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-33" value="" style="shape=table;startSize=0;container=1;collapsible=0;childLayout=tableLayout;fontSize=16;" vertex="1" parent="1">
|
||||
<mxGeometry x="460" y="310" width="160" height="160" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-34" value="" style="shape=tableRow;horizontal=0;startSize=0;swimlaneHead=0;swimlaneBody=0;strokeColor=inherit;top=0;left=0;bottom=0;right=0;collapsible=0;dropTarget=0;fillColor=none;points=[[0,0.5],[1,0.5]];portConstraint=eastwest;fontSize=16;" vertex="1" parent="ARffzCTJVVxupl663M9X-33">
|
||||
<mxGeometry width="160" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-35" value="<font style="font-size: 10px;">Determine Next-Hop</font>" style="shape=partialRectangle;html=1;whiteSpace=wrap;connectable=0;strokeColor=inherit;overflow=hidden;fillColor=none;top=0;left=0;bottom=0;right=0;pointerEvents=1;fontSize=16;" vertex="1" parent="ARffzCTJVVxupl663M9X-34">
|
||||
<mxGeometry width="160" height="30" as="geometry">
|
||||
<mxRectangle width="160" height="30" as="alternateBounds" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-36" value="" style="shape=tableRow;horizontal=0;startSize=0;swimlaneHead=0;swimlaneBody=0;strokeColor=inherit;top=0;left=0;bottom=0;right=0;collapsible=0;dropTarget=0;fillColor=none;points=[[0,0.5],[1,0.5]];portConstraint=eastwest;fontSize=16;" vertex="1" parent="ARffzCTJVVxupl663M9X-33">
|
||||
<mxGeometry y="30" width="160" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-37" value="<p style="line-height: 90%;"></p><div style="text-align: left;"><font style="background-color: initial; font-size: 10px;">Input:&nbsp;</font><span style="background-color: initial; text-align: center;"><font style="font-size: 10px;">Matching route entry</font></span></div><span style="font-size: 10px; background-color: initial;"><div style="text-align: left;"><span style="background-color: initial;">output:&nbsp;</span>Next-hop</div></span><p></p><p></p>" style="shape=partialRectangle;html=1;whiteSpace=wrap;connectable=0;strokeColor=inherit;overflow=hidden;fillColor=none;top=0;left=0;bottom=0;right=0;pointerEvents=1;fontSize=16;" vertex="1" parent="ARffzCTJVVxupl663M9X-36">
|
||||
<mxGeometry width="160" height="60" as="geometry">
|
||||
<mxRectangle width="160" height="60" as="alternateBounds" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-38" value="" style="shape=tableRow;horizontal=0;startSize=0;swimlaneHead=0;swimlaneBody=0;strokeColor=inherit;top=0;left=0;bottom=0;right=0;collapsible=0;dropTarget=0;fillColor=none;points=[[0,0.5],[1,0.5]];portConstraint=eastwest;fontSize=16;" vertex="1" parent="ARffzCTJVVxupl663M9X-33">
|
||||
<mxGeometry y="90" width="160" height="70" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-39" value="<p style="line-height: 90%; font-size: 10px;">Based on the longest prefix match, find the next-hop in the routing table to forward the packet<br></p>" style="shape=partialRectangle;html=1;whiteSpace=wrap;connectable=0;strokeColor=inherit;overflow=hidden;fillColor=none;top=0;left=0;bottom=0;right=0;pointerEvents=1;fontSize=16;align=left;" vertex="1" parent="ARffzCTJVVxupl663M9X-38">
|
||||
<mxGeometry width="160" height="70" as="geometry">
|
||||
<mxRectangle width="160" height="70" as="alternateBounds" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-40" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" edge="1" parent="1" source="ARffzCTJVVxupl663M9X-7" target="ARffzCTJVVxupl663M9X-20">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-41" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.64;entryY=0.438;entryDx=0;entryDy=0;entryPerimeter=0;" edge="1" parent="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="80" y="160" as="sourcePoint" />
|
||||
<mxPoint x="80" y="160" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-42" value="" style="endArrow=classic;html=1;rounded=0;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" edge="1" parent="1" source="ARffzCTJVVxupl663M9X-51" target="ARffzCTJVVxupl663M9X-7">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="80" y="160" as="sourcePoint" />
|
||||
<mxPoint x="130" y="100" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-43" style="rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=1.013;entryY=-0.01;entryDx=0;entryDy=0;entryPerimeter=0;exitX=-0.015;exitY=1.01;exitDx=0;exitDy=0;exitPerimeter=0;" edge="1" parent="1" source="ARffzCTJVVxupl663M9X-24" target="ARffzCTJVVxupl663M9X-27">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="430" y="290" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-44" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" edge="1" parent="1" source="ARffzCTJVVxupl663M9X-29" target="ARffzCTJVVxupl663M9X-36">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-46" style="rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" edge="1" parent="1" source="ARffzCTJVVxupl663M9X-36" target="ARffzCTJVVxupl663M9X-48">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="715.29" y="369.69999999999993" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-50" value="" style="group" vertex="1" connectable="0" parent="1">
|
||||
<mxGeometry x="720" y="350" width="40" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-48" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" vertex="1" parent="ARffzCTJVVxupl663M9X-50">
|
||||
<mxGeometry width="40" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-49" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;fillColor=#000000;" vertex="1" parent="ARffzCTJVVxupl663M9X-50">
|
||||
<mxGeometry x="10" y="10" width="20" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="ARffzCTJVVxupl663M9X-51" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;fillColor=#000000;" vertex="1" parent="1">
|
||||
<mxGeometry x="80" y="130" width="20" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
</mxfile>
|
||||
@@ -1,12 +1,5 @@
|
||||
## router table
|
||||
|
||||
| device | eth | ip |
|
||||
| ------- | ---- | ----------- |
|
||||
| PC1 | eth1 | 10.5.0.1/24 |
|
||||
| PC2 | eth1 | 10.5.1.2/24 |
|
||||
| router1 | eth1 | 10.5.0.0/24 |
|
||||
| router2 | eth1 | 10.5.1.1/24 |
|
||||
|
||||
router -> router
|
||||
|
||||
```
|
||||
@@ -59,9 +52,155 @@ sender # sender eth # receiver # receiver eth # losses #
|
||||
|
||||
```
|
||||
|
||||
## Tcpdump output
|
||||
|
||||
ping
|
||||
|
||||
```
|
||||
tcpdump -i eth1 -e
|
||||
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
|
||||
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
|
||||
14:28:59.207532 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.1 > 10.5.1.2: ICMP echo request, id 8384, seq 23, length 64
|
||||
14:28:59.207566 00:16:3e:00:00:02 (oui Unknown) > 00:16:3e:00:00:08 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.2 > 10.5.1.1: ICMP echo reply, id 8384, seq 23, length 64
|
||||
14:29:00.207639 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.1 > 10.5.1.2: ICMP echo request, id 8384, seq 24, length 64
|
||||
14:29:00.207661 00:16:3e:00:00:02 (oui Unknown) > 00:16:3e:00:00:08 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.2 > 10.5.1.1: ICMP echo reply, id 8384, seq 24, length 64
|
||||
14:29:01.207750 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.1 > 10.5.1.2: ICMP echo request, id 8384, seq 25, length 64
|
||||
14:29:01.207774 00:16:3e:00:00:02 (oui Unknown) > 00:16:3e:00:00:08 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.2 > 10.5.1.1: ICMP echo reply, id 8384, seq 25, length 64
|
||||
14:29:02.207867 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.1 > 10.5.1.2: ICMP echo request, id 8384, seq 26, length 64
|
||||
14:29:02.207892 00:16:3e:00:00:02 (oui Unknown) > 00:16:3e:00:00:08 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.2 > 10.5.1.1: ICMP echo reply, id 8384, seq 26, length 64
|
||||
14:29:03.208087 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.1 > 10.5.1.2: ICMP echo request, id 8384, seq 27, length 64
|
||||
14:29:03.208110 00:16:3e:00:00:02 (oui Unknown) > 00:16:3e:00:00:08 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.2 > 10.5.1.1: ICMP echo reply, id 8384, seq 27, length 64
|
||||
14:29:04.208230 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.1 > 10.5.1.2: ICMP echo request, id 8384, seq 28, length 64
|
||||
14:29:04.208263 00:16:3e:00:00:02 (oui Unknown) > 00:16:3e:00:00:08 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.2 > 10.5.1.1: ICMP echo reply, id 8384, seq 28, length 64
|
||||
14:29:05.211944 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.1 > 10.5.1.2: ICMP echo request, id 8384, seq 29, length 64
|
||||
14:29:05.211969 00:16:3e:00:00:02 (oui Unknown) > 00:16:3e:00:00:08 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.2 > 10.5.1.1: ICMP echo reply, id 8384, seq 29, length 64
|
||||
14:29:06.209458 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.1 > 10.5.1.2: ICMP echo request, id 8384, seq 30, length 64
|
||||
14:29:06.209482 00:16:3e:00:00:02 (oui Unknown) > 00:16:3e:00:00:08 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.2 > 10.5.1.1: ICMP echo reply, id 8384, seq 30, length 64
|
||||
14:29:07.209566 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.1 > 10.5.1.2: ICMP echo request, id 8384, seq 31, length 64
|
||||
14:29:07.209590 00:16:3e:00:00:02 (oui Unknown) > 00:16:3e:00:00:08 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.2 > 10.5.1.1: ICMP echo reply, id 8384, seq 31, length 64
|
||||
14:29:08.209683 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.1 > 10.5.1.2: ICMP echo request, id 8384, seq 32, length 64
|
||||
14:29:08.209706 00:16:3e:00:00:02 (oui Unknown) > 00:16:3e:00:00:08 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.2 > 10.5.1.1: ICMP echo reply, id 8384, seq 32, length 64
|
||||
14:29:09.209803 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.1 > 10.5.1.2: ICMP echo request, id 8384, seq 33, length 64
|
||||
14:29:09.209827 00:16:3e:00:00:02 (oui Unknown) > 00:16:3e:00:00:08 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.2 > 10.5.1.1: ICMP echo reply, id 8384, seq 33, length 64
|
||||
14:29:09.242521 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype ARP (0x0806), length 42: Request who-has 10.5.1.2 tell 10.5.1.1, length 28
|
||||
14:29:09.242541 00:16:3e:00:00:02 (oui Unknown) > 00:16:3e:00:00:08 (oui Unknown), ethertype ARP (0x0806), length 42: Reply 10.5.1.2 is-at 00:16:3e:00:00:02 (oui Unknown), length 28
|
||||
14:29:10.209897 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.1 > 10.5.1.2: ICMP echo request, id 8384, seq 34, length 64
|
||||
14:29:10.209922 00:16:3e:00:00:02 (oui Unknown) > 00:16:3e:00:00:08 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.2 > 10.5.1.1: ICMP echo reply, id 8384, seq 34, length 64
|
||||
14:29:11.210041 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.1 > 10.5.1.2: ICMP echo request, id 8384, seq 35, length 64
|
||||
14:29:11.210079 00:16:3e:00:00:02 (oui Unknown) > 00:16:3e:00:00:08 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.2 > 10.5.1.1: ICMP echo reply, id 8384, seq 35, length 64
|
||||
14:29:12.210112 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.1 > 10.5.1.2: ICMP echo request, id 8384, seq 36, length 64
|
||||
14:29:12.210136 00:16:3e:00:00:02 (oui Unknown) > 00:16:3e:00:00:08 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.2 > 10.5.1.1: ICMP echo reply, id 8384, seq 36, length 64
|
||||
14:29:13.210241 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.1 > 10.5.1.2: ICMP echo request, id 8384, seq 37, length 64
|
||||
14:29:13.210266 00:16:3e:00:00:02 (oui Unknown) > 00:16:3e:00:00:08 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.2 > 10.5.1.1: ICMP echo reply, id 8384, seq 37, length 64
|
||||
14:29:14.210353 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.1 > 10.5.1.2: ICMP echo request, id 8384, seq 38, length 64
|
||||
14:29:14.210378 00:16:3e:00:00:02 (oui Unknown) > 00:16:3e:00:00:08 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.2 > 10.5.1.1: ICMP echo reply, id 8384, seq 38, length 64
|
||||
14:29:15.210490 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.1 > 10.5.1.2: ICMP echo request, id 8384, seq 39, length 64
|
||||
14:29:15.210514 00:16:3e:00:00:02 (oui Unknown) > 00:16:3e:00:00:08 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.2 > 10.5.1.1: ICMP echo reply, id 8384, seq 39, length 64
|
||||
14:29:16.210574 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.1 > 10.5.1.2: ICMP echo request, id 8384, seq 40, length 64
|
||||
14:29:16.210597 00:16:3e:00:00:02 (oui Unknown) > 00:16:3e:00:00:08 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.2 > 10.5.1.1: ICMP echo reply, id 8384, seq 40, length 64
|
||||
14:29:17.210686 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.5.1.1 > 10.5.1.2: ICMP echo request, id 8384, seq 41, length 64
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
tcpdump -i eth1 -e
|
||||
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
|
||||
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
|
||||
14:18:42.413051 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.1 > 172.16.1.100: ICMP echo request, id 7117, seq 39, length 64
|
||||
14:18:42.413085 00:16:3e:00:00:02 (oui Unknown) > 00:de:ad:be:ef:00 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.100 > 172.16.1.1: ICMP echo reply, id 7117, seq 39, length 64
|
||||
14:18:43.413174 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.1 > 172.16.1.100: ICMP echo request, id 7117, seq 40, length 64
|
||||
14:18:43.413199 00:16:3e:00:00:02 (oui Unknown) > 00:de:ad:be:ef:00 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.100 > 172.16.1.1: ICMP echo reply, id 7117, seq 40, length 64
|
||||
14:18:44.413427 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.1 > 172.16.1.100: ICMP echo request, id 7117, seq 41, length 64
|
||||
14:18:44.413450 00:16:3e:00:00:02 (oui Unknown) > 00:de:ad:be:ef:00 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.100 > 172.16.1.1: ICMP echo reply, id 7117, seq 41, length 64
|
||||
14:18:45.413549 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.1 > 172.16.1.100: ICMP echo request, id 7117, seq 42, length 64
|
||||
14:18:45.413573 00:16:3e:00:00:02 (oui Unknown) > 00:de:ad:be:ef:00 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.100 > 172.16.1.1: ICMP echo reply, id 7117, seq 42, length 64
|
||||
14:18:46.413856 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.1 > 172.16.1.100: ICMP echo request, id 7117, seq 43, length 64
|
||||
14:18:46.413879 00:16:3e:00:00:02 (oui Unknown) > 00:de:ad:be:ef:00 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.100 > 172.16.1.1: ICMP echo reply, id 7117, seq 43, length 64
|
||||
14:18:46.650613 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype ARP (0x0806), length 42: Request who-has 172.16.1.100 tell 172.16.1.1, length 28
|
||||
14:18:46.650631 00:16:3e:00:00:02 (oui Unknown) > 00:16:3e:00:00:08 (oui Unknown), ethertype ARP (0x0806), length 42: Reply 172.16.1.100 is-at 00:16:3e:00:00:02 (oui Unknown), length 28
|
||||
14:18:47.413951 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.1 > 172.16.1.100: ICMP echo request, id 7117, seq 44, length 64
|
||||
14:18:47.413975 00:16:3e:00:00:02 (oui Unknown) > 00:de:ad:be:ef:00 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.100 > 172.16.1.1: ICMP echo reply, id 7117, seq 44, length 64
|
||||
14:18:48.414060 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.1 > 172.16.1.100: ICMP echo request, id 7117, seq 45, length 64
|
||||
14:18:48.414084 00:16:3e:00:00:02 (oui Unknown) > 00:de:ad:be:ef:00 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.100 > 172.16.1.1: ICMP echo reply, id 7117, seq 45, length 64
|
||||
14:18:49.414157 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.1 > 172.16.1.100: ICMP echo request, id 7117, seq 46, length 64
|
||||
14:18:49.414179 00:16:3e:00:00:02 (oui Unknown) > 00:de:ad:be:ef:00 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.100 > 172.16.1.1: ICMP echo reply, id 7117, seq 46, length 64
|
||||
14:18:50.031624 00:16:3e:00:00:02 (oui Unknown) > 33:33:00:00:00:02 (oui Unknown), ethertype IPv6 (0x86dd), length 70: fe80::216:3eff:fe00:2 > ip6-allrouters: ICMP6, router solicitation, length 16
|
||||
14:18:50.414247 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.1 > 172.16.1.100: ICMP echo request, id 7117, seq 47, length 64
|
||||
14:18:50.414268 00:16:3e:00:00:02 (oui Unknown) > 00:de:ad:be:ef:00 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.100 > 172.16.1.1: ICMP echo reply, id 7117, seq 47, length 64
|
||||
14:18:51.414380 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.1 > 172.16.1.100: ICMP echo request, id 7117, seq 48, length 64
|
||||
14:18:51.414404 00:16:3e:00:00:02 (oui Unknown) > 00:de:ad:be:ef:00 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.100 > 172.16.1.1: ICMP echo reply, id 7117, seq 48, length 64
|
||||
14:18:52.414495 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.1 > 172.16.1.100: ICMP echo request, id 7117, seq 49, length 64
|
||||
14:18:52.414518 00:16:3e:00:00:02 (oui Unknown) > 00:de:ad:be:ef:00 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.100 > 172.16.1.1: ICMP echo reply, id 7117, seq 49, length 64
|
||||
14:18:53.414667 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.1 > 172.16.1.100: ICMP echo request, id 7117, seq 50, length 64
|
||||
14:18:53.414689 00:16:3e:00:00:02 (oui Unknown) > 00:de:ad:be:ef:00 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.100 > 172.16.1.1: ICMP echo reply, id 7117, seq 50, length 64
|
||||
14:18:54.414802 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.1 > 172.16.1.100: ICMP echo request, id 7117, seq 51, length 64
|
||||
14:18:54.414831 00:16:3e:00:00:02 (oui Unknown) > 00:de:ad:be:ef:00 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.100 > 172.16.1.1: ICMP echo reply, id 7117, seq 51, length 64
|
||||
14:18:55.414903 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.1 > 172.16.1.100: ICMP echo request, id 7117, seq 52, length 64
|
||||
14:18:55.414931 00:16:3e:00:00:02 (oui Unknown) > 00:de:ad:be:ef:00 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.100 > 172.16.1.1: ICMP echo reply, id 7117, seq 52, length 64
|
||||
14:18:56.415029 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.1 > 172.16.1.100: ICMP echo request, id 7117, seq 53, length 64
|
||||
14:18:56.415056 00:16:3e:00:00:02 (oui Unknown) > 00:de:ad:be:ef:00 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.100 > 172.16.1.1: ICMP echo reply, id 7117, seq 53, length 64
|
||||
14:18:57.415140 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.1 > 172.16.1.100: ICMP echo request, id 7117, seq 54, length 64
|
||||
14:18:57.415167 00:16:3e:00:00:02 (oui Unknown) > 00:de:ad:be:ef:00 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.100 > 172.16.1.1: ICMP echo reply, id 7117, seq 54, length 64
|
||||
14:18:58.415250 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.1 > 172.16.1.100: ICMP echo request, id 7117, seq 55, length 64
|
||||
14:18:58.415277 00:16:3e:00:00:02 (oui Unknown) > 00:de:ad:be:ef:00 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.100 > 172.16.1.1: ICMP echo reply, id 7117, seq 55, length 64
|
||||
14:18:59.415362 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.1 > 172.16.1.100: ICMP echo request, id 7117, seq 56, length 64
|
||||
14:18:59.415389 00:16:3e:00:00:02 (oui Unknown) > 00:de:ad:be:ef:00 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.100 > 172.16.1.1: ICMP echo reply, id 7117, seq 56, length 64
|
||||
14:19:00.415485 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.1 > 172.16.1.100: ICMP echo request, id 7117, seq 57, length 64
|
||||
14:19:00.415513 00:16:3e:00:00:02 (oui Unknown) > 00:de:ad:be:ef:00 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.100 > 172.16.1.1: ICMP echo reply, id 7117, seq 57, length 64
|
||||
14:19:01.415591 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.1 > 172.16.1.100: ICMP echo request, id 7117, seq 58, length 64
|
||||
14:19:01.415618 00:16:3e:00:00:02 (oui Unknown) > 00:de:ad:be:ef:00 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.100 > 172.16.1.1: ICMP echo reply, id 7117, seq 58, length 64
|
||||
14:19:02.415680 00:16:3e:00:00:08 (oui Unknown) > 00:16:3e:00:00:02 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.1 > 172.16.1.100: ICMP echo request, id 7117, seq 59, length 64
|
||||
14:19:02.415703 00:16:3e:00:00:02 (oui Unknown) > 00:de:ad:be:ef:00 (oui Unknown), ethertype IPv4 (0x0800), length 98: 172.16.1.100 > 172.16.1.1: ICMP echo reply, id 7117, seq 59, length 64
|
||||
|
||||
```
|
||||
|
||||
|
||||
### 主要工具：`ip`
|
||||
|
||||
## A103
|
||||
|
||||
### router table
|
||||
|
||||
router1
|
||||
|
||||
```
|
||||
ip route show
|
||||
10.5.1.0/24 dev eth1 proto kernel scope link src 10.5.1.2
|
||||
10.5.2.0/24 dev eth2 proto kernel scope link src 10.5.2.1
|
||||
10.5.3.0/24 via 10.5.2.2 dev eth2
|
||||
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.7
|
||||
```
|
||||
|
||||
pc1
|
||||
|
||||
```
|
||||
ip route
|
||||
10.5.1.0/24 dev eth1 proto kernel scope link src 10.5.1.1
|
||||
10.5.3.0/24 via 10.5.1.2 dev eth1
|
||||
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.1
|
||||
```
|
||||
|
||||
router2
|
||||
|
||||
```
|
||||
ip route
|
||||
10.5.1.0/24 via 10.5.2.1 dev eth2
|
||||
10.5.2.0/24 dev eth2 proto kernel scope link src 10.5.2.2
|
||||
10.5.3.0/24 dev eth1 proto kernel scope link src 10.5.3.2
|
||||
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.12
|
||||
```
|
||||
|
||||
pc2
|
||||
|
||||
```
|
||||
root@pc2:~# ip route
|
||||
10.5.1.0/24 via 10.5.3.2 dev eth1
|
||||
10.5.3.0/24 dev eth1 proto kernel scope link src 10.5.3.1
|
||||
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.3
|
||||
```
|
||||
|
||||
|
||||
|
||||
## `ip`
|
||||
|
||||
**`ip`** 是 IPRoute2 工具集中最常用的命令，能够管理和配置 IP 地址、路由、链路等多种网络参数。与旧版的 `ifconfig` 和 `route` 命令相比，`ip` 更加灵活和强大。
|
||||
|
||||
|
||||
BIN
Blatt01/rnpAusarbeitung.pdf
Normal file
BIN
Blatt01/rnpAusarbeitung.pdf
Normal file
Binary file not shown.
48
Blatt01/scripts/checkip.sh
Normal file
48
Blatt01/scripts/checkip.sh
Normal file
@@ -0,0 +1,48 @@
|
||||
#!/bin/bash
|
||||
show_ip(){
|
||||
local output=$1
|
||||
ips=()
|
||||
interfaces=()
|
||||
# echo $output
|
||||
while read -r line; do
|
||||
ip=$(echo "$line" | awk '{print $2}' | cut -d'/' -f1)
|
||||
interface=$(echo "$line" | awk '{print $5}')
|
||||
ips+=("$ip")
|
||||
interfaces+=("$interface")
|
||||
done <<< "$output"
|
||||
for i in "${!ips[@]}"; do
|
||||
echo "${ips[i]} ${interfaces[i]}"
|
||||
done
|
||||
|
||||
}
|
||||
|
||||
filename="output/output_$(date +'%m-%d_%H-%M-%S').txt"
|
||||
echo $(date +'%m-%d_%H-%M-%S')
|
||||
echo ' ' > $filename
|
||||
|
||||
ip_cmd='ip address show | grep 10.5'
|
||||
for num in {1..4}
|
||||
do
|
||||
echo "router$num" >> $filename
|
||||
echo "router$num"
|
||||
ip_output=$(ssh router$num $ip_cmd)
|
||||
ips=()
|
||||
interfaces=()
|
||||
|
||||
result=$(show_ip "$ip_output")
|
||||
echo $result
|
||||
echo $result >> $filename
|
||||
|
||||
|
||||
done
|
||||
|
||||
for num in {1..3}
|
||||
do
|
||||
echo "pc$num" >> $filename
|
||||
echo "pc$num"
|
||||
pc_result=$(ssh pc$num $ip_cmd)
|
||||
result=$(show_ip "$pc_result")
|
||||
echo $result >> $filename
|
||||
echo $result
|
||||
done
|
||||
|
||||
103
Blatt01/scripts/testpc.sh
Normal file
103
Blatt01/scripts/testpc.sh
Normal file
@@ -0,0 +1,103 @@
|
||||
#!/bin/bash
|
||||
|
||||
show_ip(){
|
||||
local output=$1
|
||||
ips=()
|
||||
interfaces=()
|
||||
echo $output
|
||||
while read -r line; do
|
||||
ip=$(echo "$line" | awk '{print $2}' | cut -d'/' -f1)
|
||||
interface=$(echo "$line" | awk '{print $5}')
|
||||
ips+=("$ip")
|
||||
interfaces+=("$interface")
|
||||
done <<< "$output"
|
||||
for i in "${!ips[@]}"; do
|
||||
echo "${ips[i]} ${interfaces[i]}"
|
||||
done
|
||||
|
||||
}
|
||||
|
||||
ip_cmd='ip address show | grep 10.5'
|
||||
sender_ip='10.5.1.1/24'
|
||||
rec_ip='10.5.1.2/24'
|
||||
rec_ip_no_code='10.5.1.2'
|
||||
senders=()
|
||||
recs=()
|
||||
sender_eths=()
|
||||
rec_eths=()
|
||||
losses=()
|
||||
|
||||
sender_type="${1:-router}"
|
||||
receiver_type="${2:-router}"
|
||||
if [ "$sender_type" = "router" ]; then
|
||||
sender_ub=4
|
||||
else
|
||||
sender_ub=3
|
||||
fi
|
||||
if [ "$receiver_type" = "router" ]; then
|
||||
rec_ub=4
|
||||
else
|
||||
rec_ub=3
|
||||
fi
|
||||
for sender in $(seq 1 $sender_ub);
|
||||
do
|
||||
sender_eth_nums=$(ssh $sender_type$sender "ip address show" | grep -c '^.*eth[0-9]:')
|
||||
sender_eth_nums=$(($sender_eth_nums-1))
|
||||
echo "$sender_type$sender has $sender_eth_nums eths"
|
||||
for sender_eth_num in $(seq 1 $sender_eth_nums);
|
||||
do
|
||||
# turn on the device
|
||||
ssh $sender_type$sender "ip link set dev eth$sender_eth_num up"
|
||||
ssh $sender_type$sender "ip address add $sender_ip dev eth$sender_eth_num"
|
||||
# for receiver in {1..4}
|
||||
for receiver in $(seq 1 $rec_ub);
|
||||
do
|
||||
receiver_eth_nums=$(ssh $receiver_type$receiver "ip address show" | grep -c '^.*eth[0-9]:')
|
||||
receiver_eth_nums=$(($receiver_eth_nums-1))
|
||||
echo "$receiver_type$receiver has $receiver_eth_nums eths"
|
||||
if [ "$sender_type" = "$receiver_type" ]; then
|
||||
if [ "$sender" -eq "$receiver" ]; then
|
||||
continue
|
||||
fi
|
||||
fi
|
||||
for receiver_eth_num in $(seq 1 $receiver_eth_nums);
|
||||
do
|
||||
ssh $receiver_type$receiver "ip link set dev eth$receiver_eth_num up"
|
||||
ssh $receiver_type$receiver "ip address add $rec_ip dev eth$receiver_eth_num"
|
||||
echo "sen $sender_type$sender eth$sender_eth_num ip $sender_ip"
|
||||
echo "rec $receiver_type$receiver eth$receiver_eth_num ip $rec_ip"
|
||||
ip_output=$(ssh $sender_type$sender $ip_cmd)
|
||||
result=$(show_ip "$ip_output")
|
||||
echo $result
|
||||
|
||||
# test loss
|
||||
loss=$(ssh $sender_type$sender "ping -c 5 -W 2 -I eth$sender_eth_num $rec_ip_no_code | awk -F', ' '/packet loss/ {print \$3}' | awk '{print int(\$1)}'")
|
||||
echo $loss
|
||||
if [ "$loss" -ne 100 ]; then
|
||||
senders+=("$sender")
|
||||
recs+=("$receiver")
|
||||
sender_eths+=("$sender_eth_num")
|
||||
rec_eths+=("$receiver_eth_num")
|
||||
losses+=("$loss")
|
||||
fi
|
||||
|
||||
|
||||
ssh $receiver_type$receiver "ip address del 10.5.1.2/24 dev eth$receiver_eth_num"
|
||||
done
|
||||
done
|
||||
ssh $sender_type$sender "ip address del 10.5.1.1/24 dev eth$sender_eth_num"
|
||||
done
|
||||
done
|
||||
|
||||
echo "results"
|
||||
|
||||
printf "%-10s %-15s %-12s %-15s %-10s\n" "sender #" "sender eth #" "receiver #" "receiver eth #" "losses #"
|
||||
for i in "${!senders[@]}"; do
|
||||
printf "%-10s %-15s %-12s %-15s %-10s\n" "${senders[i]}" "${sender_eths[i]}" "${recs[i]}" "${rec_eths[i]}" "${losses[i]}"
|
||||
done
|
||||
|
||||
# printf "sender #\t sender eth #\t receiver # \t receiver eth # \t losses # \t\n"
|
||||
# for i in "${!senders[@]}"; do
|
||||
# printf "%s\t%s\t%s\t%s\t%s\n" "${senders[i]}" "${sender_eths[i]}" "${recs[i]}" "${rec_eths[i]}" "${losses[i]}"
|
||||
# done
|
||||
|
||||
384
Blatt01/topology.drawio
Normal file
384
Blatt01/topology.drawio
Normal file
@@ -0,0 +1,384 @@
|
||||
<mxfile host="app.diagrams.net" agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36" version="24.8.3">
|
||||
<diagram name="Page-1" id="hXIMXQSmOo4dZogMPPjO">
|
||||
<mxGraphModel dx="949" dy="622" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="850" pageHeight="1100" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0" />
|
||||
<mxCell id="1" parent="0" />
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-18" value="" style="group" parent="1" vertex="1" connectable="0">
|
||||
<mxGeometry x="380" y="380" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-13" value="router2" style="rounded=1;whiteSpace=wrap;html=1;" parent="s5GVwMxOrdL_uc7FEEtV-18" vertex="1">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-14" value="eth2" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" parent="s5GVwMxOrdL_uc7FEEtV-18" vertex="1">
|
||||
<mxGeometry x="90" y="22.5" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-15" value="eth1" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" parent="s5GVwMxOrdL_uc7FEEtV-18" vertex="1">
|
||||
<mxGeometry x="45" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-16" value="eth3" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" parent="s5GVwMxOrdL_uc7FEEtV-18" vertex="1">
|
||||
<mxGeometry x="45" y="45" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-17" value="eth4" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" parent="s5GVwMxOrdL_uc7FEEtV-18" vertex="1">
|
||||
<mxGeometry y="22.5" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-19" value="" style="group" parent="1" vertex="1" connectable="0">
|
||||
<mxGeometry x="180" y="100" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-20" value="router1" style="rounded=1;whiteSpace=wrap;html=1;" parent="s5GVwMxOrdL_uc7FEEtV-19" vertex="1">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-21" value="eth2" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" parent="s5GVwMxOrdL_uc7FEEtV-19" vertex="1">
|
||||
<mxGeometry x="90" y="22.5" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-22" value="eth1" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" parent="s5GVwMxOrdL_uc7FEEtV-19" vertex="1">
|
||||
<mxGeometry x="45" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-23" value="eth3" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" parent="s5GVwMxOrdL_uc7FEEtV-19" vertex="1">
|
||||
<mxGeometry x="45" y="45" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-24" value="eth4" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" parent="s5GVwMxOrdL_uc7FEEtV-19" vertex="1">
|
||||
<mxGeometry y="22.5" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-28" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=1;entryY=0.5;entryDx=0;entryDy=0;startArrow=classic;startFill=1;" parent="1" source="s5GVwMxOrdL_uc7FEEtV-21" target="s5GVwMxOrdL_uc7FEEtV-14" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-29" value="" style="group" parent="1" vertex="1" connectable="0">
|
||||
<mxGeometry x="630" y="300" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-30" value="router3" style="rounded=1;whiteSpace=wrap;html=1;" parent="s5GVwMxOrdL_uc7FEEtV-29" vertex="1">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-31" value="eth2" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" parent="s5GVwMxOrdL_uc7FEEtV-29" vertex="1">
|
||||
<mxGeometry x="90" y="22.5" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-32" value="eth1" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" parent="s5GVwMxOrdL_uc7FEEtV-29" vertex="1">
|
||||
<mxGeometry x="45" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-33" value="eth3" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" parent="s5GVwMxOrdL_uc7FEEtV-29" vertex="1">
|
||||
<mxGeometry x="45" y="45" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-34" value="eth4" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" parent="s5GVwMxOrdL_uc7FEEtV-29" vertex="1">
|
||||
<mxGeometry y="22.5" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-35" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=1;entryY=0.5;entryDx=0;entryDy=0;startArrow=classic;startFill=1;" parent="1" source="s5GVwMxOrdL_uc7FEEtV-23" target="s5GVwMxOrdL_uc7FEEtV-31" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-36" value="" style="group" parent="1" vertex="1" connectable="0">
|
||||
<mxGeometry x="5" y="240" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-37" value="router4" style="rounded=1;whiteSpace=wrap;html=1;" parent="s5GVwMxOrdL_uc7FEEtV-36" vertex="1">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-38" value="eth2" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" parent="s5GVwMxOrdL_uc7FEEtV-36" vertex="1">
|
||||
<mxGeometry x="90" y="22.5" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-39" value="eth1" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" parent="s5GVwMxOrdL_uc7FEEtV-36" vertex="1">
|
||||
<mxGeometry x="45" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-40" value="eth3" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" parent="s5GVwMxOrdL_uc7FEEtV-36" vertex="1">
|
||||
<mxGeometry x="45" y="45" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-41" value="eth4" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" parent="s5GVwMxOrdL_uc7FEEtV-36" vertex="1">
|
||||
<mxGeometry y="22.5" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-43" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;startArrow=classic;startFill=1;" parent="1" source="s5GVwMxOrdL_uc7FEEtV-24" target="s5GVwMxOrdL_uc7FEEtV-39" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-45" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=1;entryDx=0;entryDy=0;exitX=0.5;exitY=1;exitDx=0;exitDy=0;startArrow=classic;startFill=1;" parent="1" source="s5GVwMxOrdL_uc7FEEtV-16" target="s5GVwMxOrdL_uc7FEEtV-33" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-46" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0;exitY=0.5;exitDx=0;exitDy=0;entryX=1;entryY=0.5;entryDx=0;entryDy=0;startArrow=classic;startFill=1;" parent="1" source="s5GVwMxOrdL_uc7FEEtV-17" target="s5GVwMxOrdL_uc7FEEtV-38" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="s5GVwMxOrdL_uc7FEEtV-48" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=1;entryDx=0;entryDy=0;startArrow=classic;startFill=1;" parent="1" source="s5GVwMxOrdL_uc7FEEtV-30" target="s5GVwMxOrdL_uc7FEEtV-40" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-3" value="" style="group" vertex="1" connectable="0" parent="1">
|
||||
<mxGeometry x="590" y="100" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-1" value="pc1" style="rounded=0;whiteSpace=wrap;html=1;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-3">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-2" value="<font style="font-size: 10px;">eth1</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-3">
|
||||
<mxGeometry x="45" width="30" height="10" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-5" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;exitX=0.5;exitY=0;exitDx=0;exitDy=0;" edge="1" parent="1" source="s5GVwMxOrdL_uc7FEEtV-22" target="e8EGUHU9NlDJmCv5vn1Y-2">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-7" value="" style="group" vertex="1" connectable="0" parent="1">
|
||||
<mxGeometry x="120" y="470" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-8" value="pc2" style="rounded=0;whiteSpace=wrap;html=1;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-7">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-9" value="<font style="font-size: 10px;">eth1</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-7">
|
||||
<mxGeometry x="45" width="30" height="10" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-10" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;exitX=0.5;exitY=0;exitDx=0;exitDy=0;" edge="1" parent="1" source="s5GVwMxOrdL_uc7FEEtV-15" target="e8EGUHU9NlDJmCv5vn1Y-2">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-11" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;exitX=0.5;exitY=0;exitDx=0;exitDy=0;" edge="1" parent="1" source="s5GVwMxOrdL_uc7FEEtV-15" target="e8EGUHU9NlDJmCv5vn1Y-9">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-12" value="" style="group" vertex="1" connectable="0" parent="1">
|
||||
<mxGeometry x="260" y="470" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-13" value="pc3" style="rounded=0;whiteSpace=wrap;html=1;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-12">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-14" value="<font style="font-size: 10px;">eth1</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-12">
|
||||
<mxGeometry x="45" width="30" height="10" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-15" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;exitX=0.5;exitY=0;exitDx=0;exitDy=0;" edge="1" parent="1" source="s5GVwMxOrdL_uc7FEEtV-13" target="e8EGUHU9NlDJmCv5vn1Y-14">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-17" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;exitX=0.5;exitY=0;exitDx=0;exitDy=0;" edge="1" parent="1" source="s5GVwMxOrdL_uc7FEEtV-32" target="e8EGUHU9NlDJmCv5vn1Y-14">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-18" value="" style="group" vertex="1" connectable="0" parent="1">
|
||||
<mxGeometry x="40" y="850" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-19" value="pc1" style="rounded=0;whiteSpace=wrap;html=1;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-18">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-20" value="<font style="font-size: 10px;">eth1</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-18">
|
||||
<mxGeometry x="45" width="30" height="10" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-21" value="" style="group" vertex="1" connectable="0" parent="1">
|
||||
<mxGeometry x="210" y="850" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-22" value="router1" style="rounded=1;whiteSpace=wrap;html=1;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-21">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-38" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;" edge="1" parent="e8EGUHU9NlDJmCv5vn1Y-21" source="e8EGUHU9NlDJmCv5vn1Y-23">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="120" y="140" as="targetPoint" />
|
||||
<Array as="points">
|
||||
<mxPoint x="140" y="30" />
|
||||
<mxPoint x="140" y="140" />
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-23" value="eth2" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-21">
|
||||
<mxGeometry x="90" y="22.5" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-24" value="eth1" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-21">
|
||||
<mxGeometry x="45" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-25" value="eth3" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-21">
|
||||
<mxGeometry x="45" y="45" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-26" value="eth4" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-21">
|
||||
<mxGeometry y="22.5" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-27" value="" style="group" vertex="1" connectable="0" parent="1">
|
||||
<mxGeometry x="40" y="960" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-28" value="pc2" style="rounded=0;whiteSpace=wrap;html=1;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-27">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-29" value="<font style="font-size: 10px;">eth1</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-27">
|
||||
<mxGeometry x="45" width="30" height="10" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-31" value="" style="group" vertex="1" connectable="0" parent="1">
|
||||
<mxGeometry x="210" y="960" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-32" value="router2" style="rounded=1;whiteSpace=wrap;html=1;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-31">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-33" value="eth2" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-31">
|
||||
<mxGeometry x="90" y="22.5" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-34" value="eth1" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-31">
|
||||
<mxGeometry x="45" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-35" value="eth3" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-31">
|
||||
<mxGeometry x="45" y="45" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-36" value="eth4" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-31">
|
||||
<mxGeometry y="22.5" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-37" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;exitX=0.5;exitY=0;exitDx=0;exitDy=0;" edge="1" parent="1" source="e8EGUHU9NlDJmCv5vn1Y-20" target="e8EGUHU9NlDJmCv5vn1Y-24">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-39" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" source="e8EGUHU9NlDJmCv5vn1Y-34" target="e8EGUHU9NlDJmCv5vn1Y-29">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="270" y="940" />
|
||||
<mxPoint x="100" y="940" />
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-41" value="<font style="font-size: 10px;">10.5.1.2</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="280" y="830" width="40" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-40" value="<font style="font-size: 10px;">10.5.1.1</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="45" y="830" width="40" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-42" value="<font style="font-size: 10px;">10.5.2.1</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="330" y="860" width="40" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-43" value="<font style="font-size: 10px;">10.5.2.2</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="330" y="990" width="40" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-45" value="<font style="font-size: 10px;">10.5.3.1</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="940" width="40" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-46" value="<font style="font-size: 10px;">10.5.3.2</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="270" y="940" width="40" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-76" value="" style="group" vertex="1" connectable="0" parent="1">
|
||||
<mxGeometry x="490" y="560" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-77" value="pc1" style="rounded=0;whiteSpace=wrap;html=1;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-76">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-78" value="<font style="font-size: 10px;">eth1</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-76">
|
||||
<mxGeometry x="45" width="30" height="10" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-79" value="" style="group" vertex="1" connectable="0" parent="1">
|
||||
<mxGeometry x="660" y="560" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-80" value="router1" style="rounded=1;whiteSpace=wrap;html=1;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-79">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-81" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;" edge="1" parent="e8EGUHU9NlDJmCv5vn1Y-79" source="e8EGUHU9NlDJmCv5vn1Y-82">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="120" y="140" as="targetPoint" />
|
||||
<Array as="points">
|
||||
<mxPoint x="140" y="30" />
|
||||
<mxPoint x="140" y="140" />
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-82" value="eth2" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-79">
|
||||
<mxGeometry x="90" y="22.5" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-83" value="eth1" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-79">
|
||||
<mxGeometry x="45" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-84" value="eth3" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-79">
|
||||
<mxGeometry x="45" y="45" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-85" value="eth4" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-79">
|
||||
<mxGeometry y="22.5" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-86" value="" style="group" vertex="1" connectable="0" parent="1">
|
||||
<mxGeometry x="490" y="670" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-87" value="pc2" style="rounded=0;whiteSpace=wrap;html=1;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-86">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-88" value="<font style="font-size: 10px;">eth1</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-86">
|
||||
<mxGeometry x="45" width="30" height="10" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-89" value="" style="group" vertex="1" connectable="0" parent="1">
|
||||
<mxGeometry x="660" y="670" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-90" value="router2" style="rounded=1;whiteSpace=wrap;html=1;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-89">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-91" value="eth2" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-89">
|
||||
<mxGeometry x="90" y="22.5" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-92" value="eth1" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-89">
|
||||
<mxGeometry x="45" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-93" value="eth3" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-89">
|
||||
<mxGeometry x="45" y="45" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-94" value="eth4" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-89">
|
||||
<mxGeometry y="22.5" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-95" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;exitX=0.5;exitY=0;exitDx=0;exitDy=0;" edge="1" parent="1" source="e8EGUHU9NlDJmCv5vn1Y-78" target="e8EGUHU9NlDJmCv5vn1Y-83">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-96" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" source="e8EGUHU9NlDJmCv5vn1Y-92" target="e8EGUHU9NlDJmCv5vn1Y-88">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="720" y="650" />
|
||||
<mxPoint x="550" y="650" />
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-97" value="<font style="font-size: 10px;">10.5.1.2</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="730" y="540" width="40" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-98" value="<font style="font-size: 10px;">10.5.1.1</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="495" y="540" width="40" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-99" value="<font style="font-size: 10px;">10.5.2.1</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="780" y="570" width="40" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-100" value="<font style="font-size: 10px;">10.5.2.2</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="780" y="700" width="40" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-101" value="<font style="font-size: 10px;">10.5.3.1</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="500" y="650" width="40" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-102" value="<font style="font-size: 10px;">10.5.3.2</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="720" y="650" width="40" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-103" value="" style="group" vertex="1" connectable="0" parent="1">
|
||||
<mxGeometry x="390" y="850" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-104" value="router4" style="rounded=1;whiteSpace=wrap;html=1;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-103">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-105" value="eth2" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-103">
|
||||
<mxGeometry x="90" y="22.5" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-106" value="eth1" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-103">
|
||||
<mxGeometry x="45" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-107" value="eth3" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-103">
|
||||
<mxGeometry x="45" y="45" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-108" value="eth4" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="e8EGUHU9NlDJmCv5vn1Y-103">
|
||||
<mxGeometry y="22.5" width="30" height="15" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-109" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" source="e8EGUHU9NlDJmCv5vn1Y-22" target="e8EGUHU9NlDJmCv5vn1Y-106">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="180" y="620" as="targetPoint" />
|
||||
<Array as="points">
|
||||
<mxPoint x="190" y="880" />
|
||||
<mxPoint x="190" y="770" />
|
||||
<mxPoint x="450" y="770" />
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-111" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" edge="1" parent="1" source="e8EGUHU9NlDJmCv5vn1Y-116" target="e8EGUHU9NlDJmCv5vn1Y-32">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="180" y="990" />
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-112" value="<font style="font-size: 10px;">10.5.4.1</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="170" y="900" width="40" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-113" value="<font style="font-size: 10px;">10.5.4.2</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="455" y="830" width="40" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-114" value="<font style="font-size: 10px;">10.5.5.1</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="510" y="890" width="40" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-118" value="" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" edge="1" parent="1" source="e8EGUHU9NlDJmCv5vn1Y-105" target="e8EGUHU9NlDJmCv5vn1Y-116">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="510" y="880" as="sourcePoint" />
|
||||
<mxPoint x="210" y="990" as="targetPoint" />
|
||||
<Array as="points">
|
||||
<mxPoint x="560" y="880" />
|
||||
<mxPoint x="560" y="1070" />
|
||||
<mxPoint x="180" y="1070" />
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="e8EGUHU9NlDJmCv5vn1Y-116" value="<font style="font-size: 10px;">10.5.5.2</font>" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="175" y="1002.5" width="40" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
</mxfile>
|
||||
153
Blatt02/101topo.drawio
Normal file
153
Blatt02/101topo.drawio
Normal file
@@ -0,0 +1,153 @@
|
||||
<mxfile host="Electron" agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/24.7.17 Chrome/128.0.6613.36 Electron/32.0.1 Safari/537.36" version="24.7.17">
|
||||
<diagram name="Page-1" id="c7488fd3-1785-93aa-aadb-54a6760d102a">
|
||||
<mxGraphModel dx="1430" dy="826" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="1100" pageHeight="850" background="none" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0" />
|
||||
<mxCell id="1" parent="0" />
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-9" value="" style="group" vertex="1" connectable="0" parent="1">
|
||||
<mxGeometry x="440" y="50" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-2" value="<font color="#00ff00">pc3</font>" style="rounded=0;whiteSpace=wrap;html=1;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-9">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-8" value="eth1" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=10;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-9">
|
||||
<mxGeometry x="45" width="30" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-10" value="" style="group" vertex="1" connectable="0" parent="1">
|
||||
<mxGeometry x="440" y="180" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-1" value="router3" style="rounded=1;whiteSpace=wrap;html=1;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-10">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-4" value="eth1" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=10;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-10">
|
||||
<mxGeometry x="45" width="30" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-5" value="eth4" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=10;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-10">
|
||||
<mxGeometry x="90" y="20" width="30" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-6" value="eth3" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=10;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-10">
|
||||
<mxGeometry x="45" y="40" width="30" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-7" value="eth2" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=10;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-10">
|
||||
<mxGeometry y="20" width="30" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-11" value="" style="group" vertex="1" connectable="0" parent="1">
|
||||
<mxGeometry x="810" y="460" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-12" value="router2" style="rounded=1;whiteSpace=wrap;html=1;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-11">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-13" value="eth1" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=10;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-11">
|
||||
<mxGeometry x="45" width="30" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-14" value="eth4" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=10;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-11">
|
||||
<mxGeometry x="90" y="20" width="30" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-15" value="eth3" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=10;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-11">
|
||||
<mxGeometry x="45" y="40" width="30" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-16" value="eth2" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=10;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-11">
|
||||
<mxGeometry y="20" width="30" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-17" value="" style="group" vertex="1" connectable="0" parent="1">
|
||||
<mxGeometry x="40" y="390" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-18" value="<font color="#33ffff">pc1</font>" style="rounded=0;whiteSpace=wrap;html=1;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-17">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-19" value="eth1" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=10;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-17">
|
||||
<mxGeometry x="45" width="30" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-20" value="" style="group" vertex="1" connectable="0" parent="1">
|
||||
<mxGeometry x="50" y="620" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-21" value="<font color="#00ff00">router4</font>" style="rounded=1;whiteSpace=wrap;html=1;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-20">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-22" value="eth1" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=10;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-20">
|
||||
<mxGeometry x="45" width="30" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-23" value="eth4" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=10;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-20">
|
||||
<mxGeometry x="90" y="20" width="30" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-24" value="eth3" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=10;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-20">
|
||||
<mxGeometry x="45" y="40" width="30" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-25" value="eth2" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=10;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-20">
|
||||
<mxGeometry y="20" width="30" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-26" value="" style="group" vertex="1" connectable="0" parent="1">
|
||||
<mxGeometry x="260" y="460" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-27" value="router1" style="rounded=1;whiteSpace=wrap;html=1;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-26">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-28" value="eth1" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=10;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-26">
|
||||
<mxGeometry x="45" width="30" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-29" value="eth4" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=10;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-26">
|
||||
<mxGeometry x="90" y="20" width="30" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-30" value="eth3" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=10;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-26">
|
||||
<mxGeometry x="45" y="40" width="30" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-31" value="eth2" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=10;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-26">
|
||||
<mxGeometry y="20" width="30" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-32" value="" style="group" vertex="1" connectable="0" parent="1">
|
||||
<mxGeometry x="940" y="450" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-33" value="<font color="#33ffff">pc2</font>" style="rounded=0;whiteSpace=wrap;html=1;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-32">
|
||||
<mxGeometry width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-34" value="eth1" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=10;" vertex="1" parent="vMP_kKZSY3k1futoFF2L-32">
|
||||
<mxGeometry x="45" width="30" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-37" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" source="vMP_kKZSY3k1futoFF2L-29" target="vMP_kKZSY3k1futoFF2L-22">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-38" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=1;entryY=0.5;entryDx=0;entryDy=0;exitX=0.5;exitY=0;exitDx=0;exitDy=0;" edge="1" parent="1" source="vMP_kKZSY3k1futoFF2L-28" target="vMP_kKZSY3k1futoFF2L-18">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-39" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;exitX=0.5;exitY=1;exitDx=0;exitDy=0;" edge="1" parent="1" source="vMP_kKZSY3k1futoFF2L-30" target="vMP_kKZSY3k1futoFF2L-7">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-40" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" source="vMP_kKZSY3k1futoFF2L-2" target="vMP_kKZSY3k1futoFF2L-4">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-41" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=1;entryDx=0;entryDy=0;" edge="1" parent="1" source="vMP_kKZSY3k1futoFF2L-1" target="vMP_kKZSY3k1futoFF2L-15">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="700" y="240" />
|
||||
<mxPoint x="700" y="540" />
|
||||
<mxPoint x="870" y="540" />
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-44" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=0;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" source="vMP_kKZSY3k1futoFF2L-12" target="vMP_kKZSY3k1futoFF2L-34">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="900" y="310" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-45" value="10.5.1.1" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="70" y="350" width="60" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-46" value="10.5.1.3" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="560" y="60" width="60" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-47" value="10.5.1.2" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="990" y="530" width="60" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-48" value="10.5.1.4" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="80" y="690" width="60" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-49" value="10.5.1.5" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="190" y="475" width="60" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="vMP_kKZSY3k1futoFF2L-50" value="10.5.1.6" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="470" y="250" width="60" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
</mxfile>
|
||||
179
Blatt02/A203/arp_packet.c
Normal file
179
Blatt02/A203/arp_packet.c
Normal file
@@ -0,0 +1,179 @@
|
||||
#include "arp_packet.h"
|
||||
|
||||
translation_table_entry translation_table[TB_L];
|
||||
int entry_length = 0;
|
||||
int entry_count = 0;
|
||||
|
||||
int search_entry(translation_table_entry * entry, uint32_t ip, int * table_id){
|
||||
for(size_t i = 0 ; i < entry_length; i++){
|
||||
if(ip == translation_table[i].ar_spa){
|
||||
entry->ar_pro = translation_table[i].ar_pro;
|
||||
entry->ar_spa = translation_table[i].ar_spa;
|
||||
for(size_t j = 0 ; j < MAC_A_S ; j++){
|
||||
entry->ar_sha[j] = translation_table[i].ar_sha[j];
|
||||
}
|
||||
*table_id = i;
|
||||
translation_table[i].count = entry_count;
|
||||
entry_count++;
|
||||
return SUCCESS;
|
||||
}
|
||||
}
|
||||
return FAILED;
|
||||
}
|
||||
|
||||
int update_entry(int table_id, uint8_t * mac_ares){
|
||||
if(table_id >= TB_L) {
|
||||
perror("table_id wrong");
|
||||
return FAILED;
|
||||
}
|
||||
for(size_t j = 0 ; j < MAC_A_S ; j++){
|
||||
translation_table[table_id].ar_sha[j] = mac_ares[j];
|
||||
}
|
||||
return SUCCESS;
|
||||
}
|
||||
|
||||
int insert_entry(translation_table_entry * entry){
|
||||
int final_id = entry_length;
|
||||
if(entry_length == TB_L){
|
||||
int minn = 1<<31;
|
||||
int id = -1;
|
||||
for(size_t i = 0 ; i < entry_length ; i++){
|
||||
if(translation_table[i].count < minn){
|
||||
minn = translation_table[i].count;
|
||||
id = i;
|
||||
}
|
||||
}
|
||||
final_id = id;
|
||||
}
|
||||
translation_table[final_id].ar_pro = entry->ar_pro;
|
||||
translation_table[final_id].ar_spa = entry->ar_spa;
|
||||
for(size_t j = 0 ; j < MAC_A_S ; j++){
|
||||
translation_table[final_id].ar_sha[j] = entry->ar_sha[j];
|
||||
}
|
||||
translation_table[final_id].count = entry_count;
|
||||
entry_count++;
|
||||
return SUCCESS;
|
||||
}
|
||||
|
||||
int parse_arp_packet(mac_hdr * hdr, pkt_data * pkt, uint8_t * buf, size_t size){
|
||||
size_t offset = 0;
|
||||
for(size_t i=offset;i<offset+MAC_A_S;i++) hdr->dest_ares[i-offset]=buf[i]; offset += MAC_A_S;
|
||||
for(size_t i=offset;i<offset+MAC_A_S;i++) hdr->send_ares[i-offset]=buf[i]; offset += MAC_A_S;
|
||||
hdr->pro_T =combine_uint8(buf[offset], buf[offset+1]); offset += 2;
|
||||
pkt->ar_hrd=combine_uint8(buf[offset], buf[offset+1]); offset += 2;
|
||||
pkt->ar_pro=combine_uint8(buf[offset], buf[offset+1]); offset += 2;
|
||||
pkt->ar_hln=buf[offset]; offset += 1;
|
||||
pkt->ar_pln=buf[offset]; offset += 1;
|
||||
pkt->ar_op =combine_uint8(buf[offset], buf[offset+1]); offset += 2;
|
||||
for(size_t i=offset;i<offset+MAC_A_S;i++) pkt->ar_sha[i-offset]=buf[i]; offset += MAC_A_S;
|
||||
pkt->ar_spa = combine_uint8_32(buf+offset); offset+=IP_A_S;
|
||||
for(size_t i=offset;i<offset+MAC_A_S;i++) pkt->ar_tha[i-offset]=buf[i]; offset += MAC_A_S;
|
||||
pkt->ar_tpa = combine_uint8_32(buf+offset); offset+=IP_A_S;
|
||||
}
|
||||
|
||||
int receive_arp_packet(mac_hdr * hdr, pkt_data * pkt, uint8_t * buf, size_t size, uint8_t * local_ip, uint8_t * local_mac){
|
||||
uint32_t local_ip32 = combine_uint8_32(local_ip);
|
||||
|
||||
if(size < 42) {
|
||||
printf("The packet is too short! This is not an ARP packet!\n");
|
||||
return FAILED;
|
||||
}
|
||||
parse_arp_packet(hdr, pkt, buf, size);
|
||||
if(hdr->pro_T != ETHER_T_ARP) {
|
||||
printf("The packet is not ARP packet!\n");
|
||||
return FAILED;
|
||||
}
|
||||
if(pkt->ar_hrd != ARES_HRD_ETHERNET){
|
||||
printf("The hardware is not Ethernet!\n");
|
||||
return FAILED;
|
||||
}
|
||||
if(pkt->ar_pro!= ARES_PRO_IP){
|
||||
printf("The protocol is not IPv4!\n");
|
||||
return FAILED;
|
||||
}
|
||||
|
||||
int merge_flag = FALSE;
|
||||
int table_id = -1;
|
||||
|
||||
translation_table_entry entry;
|
||||
if(search_entry(&entry, pkt->ar_spa, &table_id) == SUCCESS){
|
||||
update_entry(table_id, pkt->ar_sha);
|
||||
merge_flag = TRUE;
|
||||
}
|
||||
if(merge_flag == FALSE){
|
||||
entry.ar_pro = pkt->ar_pro;
|
||||
entry.ar_spa = pkt->ar_spa;
|
||||
for(size_t j = 0 ; j < MAC_A_S ; j++){
|
||||
entry.ar_sha[j] = pkt->ar_sha[j];
|
||||
}
|
||||
}
|
||||
|
||||
if(pkt->ar_op==ARES_OP_REQ){
|
||||
printf("This is a request packet!\n");
|
||||
|
||||
uint32_t tmp_ip;
|
||||
uint8_t tmp_mac[MAC_A_S];
|
||||
tmp_ip = pkt->ar_spa; pkt->ar_spa = pkt->ar_tpa; pkt->ar_tpa = tmp_ip;
|
||||
memcpy(tmp_mac, pkt->ar_sha, MAC_A_S); memcpy(pkt->ar_sha, pkt->ar_tha, MAC_A_S); memcpy(pkt->ar_tha, tmp_mac, MAC_A_S);
|
||||
|
||||
memcpy(pkt->ar_sha, local_mac, MAC_A_S);
|
||||
pkt->ar_spa = local_ip32;
|
||||
|
||||
pkt->ar_op = ARES_OP_REP;
|
||||
memcpy(tmp_mac, hdr->dest_ares, MAC_A_S); memcpy(hdr->dest_ares, hdr->send_ares, MAC_A_S); memcpy(hdr->send_ares, tmp_mac, MAC_A_S);
|
||||
memcpy(hdr->send_ares, local_mac, MAC_A_S);
|
||||
return SUCCESS;
|
||||
}
|
||||
printf("This is a response packet!\n");
|
||||
return SUCCESS;
|
||||
}
|
||||
|
||||
int cv_uint16_to_uint8(uint8_t * tmp, uint16_t number){
|
||||
tmp[1] = number & 0x00FF;
|
||||
tmp[0] = (number >> 8 ) & 0x00FF;
|
||||
return SUCCESS;
|
||||
}
|
||||
|
||||
int cv_arp_packet_to_uint8(uint8_t * resp_buffer, const pkt_data* pkt, const mac_hdr *hdr, size_t length){
|
||||
if( length < sizeof(pkt_data) + sizeof(mac_hdr) ) return FAILED;
|
||||
memcpy(resp_buffer, hdr->dest_ares, MAC_A_S); print_hex(resp_buffer, MAC_A_S); resp_buffer += MAC_A_S;
|
||||
memcpy(resp_buffer, hdr->send_ares, MAC_A_S); print_hex(resp_buffer, MAC_A_S); resp_buffer += MAC_A_S;
|
||||
uint8_t tmp[2];
|
||||
cv_uint16_to_uint8(tmp, hdr->pro_T);
|
||||
memcpy(resp_buffer, tmp, sizeof(uint16_t)); print_hex(resp_buffer, sizeof(uint16_t)); resp_buffer += sizeof(uint16_t);
|
||||
|
||||
cv_uint16_to_uint8(tmp, pkt->ar_hrd);
|
||||
memcpy(resp_buffer, tmp, sizeof(uint16_t)); print_hex(resp_buffer, sizeof(uint16_t)); resp_buffer += sizeof(uint16_t);
|
||||
cv_uint16_to_uint8(tmp, pkt->ar_pro);
|
||||
memcpy(resp_buffer, tmp, sizeof(uint16_t)); print_hex(resp_buffer, sizeof(uint16_t)); resp_buffer += sizeof(uint16_t);
|
||||
|
||||
uint16_t hln_pln = (pkt->ar_hln << 8) | (pkt->ar_pln);
|
||||
cv_uint16_to_uint8(tmp, hln_pln);
|
||||
memcpy(resp_buffer, tmp, sizeof(uint16_t)); print_hex(resp_buffer, sizeof(uint16_t)); resp_buffer += sizeof(uint16_t);
|
||||
|
||||
cv_uint16_to_uint8(tmp, pkt->ar_op);
|
||||
memcpy(resp_buffer, tmp, sizeof(uint16_t)); print_hex(resp_buffer, sizeof(uint16_t)); resp_buffer += sizeof(uint16_t);
|
||||
|
||||
memcpy(resp_buffer, pkt->ar_sha, MAC_A_S); print_hex(resp_buffer, MAC_A_S); resp_buffer += MAC_A_S;
|
||||
|
||||
uint8_t tmp_ip[4];
|
||||
for(size_t i = 0 ; i < 4 ; i++)
|
||||
tmp_ip[3-i] = ((pkt->ar_spa >> i * 8) & 0xFF);
|
||||
memcpy(resp_buffer, tmp_ip, IP_A_S); print_hex(resp_buffer, IP_A_S); resp_buffer += IP_A_S;
|
||||
|
||||
memcpy(resp_buffer, pkt->ar_tha, MAC_A_S); print_hex(resp_buffer, MAC_A_S); resp_buffer += MAC_A_S;
|
||||
|
||||
for(size_t i = 0 ; i < 4 ; i++)
|
||||
tmp_ip[3-i] = ((pkt->ar_tpa >> i * 8) & 0xFF);
|
||||
memcpy(resp_buffer, tmp_ip, IP_A_S); print_hex(resp_buffer, IP_A_S); resp_buffer += IP_A_S;
|
||||
|
||||
return SUCCESS;
|
||||
}
|
||||
|
||||
int send_arp_response(int tun_fd, uint8_t * resp_buffer, size_t length, const pkt_data * pkt, const mac_hdr * hdr){
|
||||
if(cv_arp_packet_to_uint8(resp_buffer, pkt, hdr, length) == FAILED) return FAILED;
|
||||
ssize_t nwrite = write(tun_fd, resp_buffer, length);
|
||||
if(nwrite < 0) return FAILED;
|
||||
return SUCCESS;
|
||||
}
|
||||
|
||||
43
Blatt02/A203/arp_packet.h
Normal file
43
Blatt02/A203/arp_packet.h
Normal file
@@ -0,0 +1,43 @@
|
||||
#ifndef ARP_PACKET_H
|
||||
#define ARP_PACKET_H
|
||||
|
||||
#include <assert.h>
|
||||
#include <arpa/inet.h>
|
||||
#include <sys/ioctl.h>
|
||||
#include <net/if.h>
|
||||
#include <linux/if_tun.h>
|
||||
#include <sys/types.h>
|
||||
#include <sys/stat.h>
|
||||
#include <fcntl.h>
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
#include <string.h>
|
||||
#include <unistd.h>
|
||||
#include <stdint.h>
|
||||
#include "arp_packet_st.h"
|
||||
#include "util.h"
|
||||
|
||||
#define IP_A_S 4
|
||||
#define OP_A_S 2
|
||||
|
||||
#define SUCCESS 0
|
||||
#define FAILED -1
|
||||
#define UNEQUAL 1
|
||||
|
||||
#define ARES_OP_REQ 0x0001
|
||||
#define ARES_OP_REP 0x0002
|
||||
#define ARES_HRD_ETHERNET 0x0001
|
||||
#define ETHER_T_ARP 0x0806
|
||||
#define ARES_PRO_IP 0x0800
|
||||
|
||||
#define TB_L 100
|
||||
|
||||
|
||||
int parse_arp_packet(mac_hdr * hdr, pkt_data * pkt, uint8_t * buf, size_t size);
|
||||
|
||||
int receive_arp_packet(mac_hdr * hdr, pkt_data * pkt, uint8_t * buf, size_t size, uint8_t * local_ip, uint8_t * local_mac);
|
||||
|
||||
int send_arp_response(int tun_fd, uint8_t * resp_buffer, size_t length, const pkt_data * pkt, const mac_hdr * hdr);
|
||||
|
||||
|
||||
#endif
|
||||
36
Blatt02/A203/arp_packet_st.h
Normal file
36
Blatt02/A203/arp_packet_st.h
Normal file
@@ -0,0 +1,36 @@
|
||||
#ifndef ARP_PACKET_ST_H
|
||||
#define ARP_PACKET_ST_H
|
||||
|
||||
#define MAC_A_S 6
|
||||
|
||||
#include<stdint.h>
|
||||
#include<stddef.h>
|
||||
|
||||
typedef struct{
|
||||
uint8_t dest_ares[MAC_A_S];
|
||||
uint8_t send_ares[MAC_A_S];
|
||||
uint16_t pro_T;
|
||||
}mac_hdr;
|
||||
|
||||
typedef struct{
|
||||
uint16_t ar_hrd;
|
||||
uint16_t ar_pro;
|
||||
uint8_t ar_hln;
|
||||
uint8_t ar_pln;
|
||||
uint16_t ar_op;
|
||||
uint8_t ar_sha[MAC_A_S];
|
||||
uint32_t ar_spa;
|
||||
uint8_t ar_tha[MAC_A_S];
|
||||
uint32_t ar_tpa;
|
||||
}pkt_data;
|
||||
|
||||
typedef struct{
|
||||
uint16_t ar_pro;
|
||||
uint32_t ar_spa;
|
||||
uint8_t ar_sha[MAC_A_S];
|
||||
int count;
|
||||
}translation_table_entry;
|
||||
|
||||
#endif
|
||||
|
||||
|
||||
108
Blatt02/A203/tuntap.c
Normal file
108
Blatt02/A203/tuntap.c
Normal file
@@ -0,0 +1,108 @@
|
||||
#include "arp_packet.h"
|
||||
|
||||
#define CLEAR(x) memset(&(x), 0x00, sizeof(x))
|
||||
|
||||
#define IFNAME "tap0"
|
||||
// #define IFNAME "tun0"
|
||||
|
||||
|
||||
#define BUFLEN 1600
|
||||
|
||||
static int tun_alloc(char *dev)
|
||||
{
|
||||
struct ifreq ifr;
|
||||
int fd, err;
|
||||
|
||||
if( (fd = open("/dev/net/tun", O_RDWR)) < 0 ) {
|
||||
perror("Cannot open TUN/TAP dev\n"
|
||||
"Make sure one exists with "
|
||||
"'$ mknod /dev/net/tun c 10 200'");
|
||||
exit(1);
|
||||
}
|
||||
|
||||
CLEAR(ifr);
|
||||
|
||||
/* Flags: IFF_TUN - TUN device (no Ethernet headers)
|
||||
* IFF_TAP - TAP device
|
||||
*
|
||||
* IFF_NO_PI - Do not provide packet information
|
||||
*/
|
||||
ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
|
||||
if( *dev ) {
|
||||
strncpy(ifr.ifr_name, dev, IFNAMSIZ);
|
||||
}
|
||||
|
||||
if( (err = ioctl(fd, TUNSETIFF, (void *) &ifr)) < 0 ){
|
||||
perror("ERR: Could not ioctl tun");
|
||||
close(fd);
|
||||
return err;
|
||||
}
|
||||
|
||||
strcpy(dev, ifr.ifr_name);
|
||||
return fd;
|
||||
}
|
||||
|
||||
// int check_ip(uint8_t * ip, int length){
|
||||
// if(length != TARGET_IP_A_S) return UNEQUAL;
|
||||
// int8_t pc2[4]={10,5,1,2};
|
||||
// for(size_t i = 0 ; i < length ; i++)
|
||||
// printf("%X, %X \n", ip[i], pc2[i]);
|
||||
//
|
||||
// for(size_t i = 0 ; i < length ; i++)
|
||||
// if(ip[i]!=pc2[i]) return FAILED;
|
||||
// return SUCCESS;
|
||||
//}
|
||||
//
|
||||
int main (int argc, char *argv[]){
|
||||
|
||||
char dev[IFNAMSIZ];
|
||||
int tun_fd;
|
||||
|
||||
uint8_t local_ip[4] = {10, 5, 1, 10};
|
||||
uint8_t local_mac[6] = {0xD6,0x74,0x45,0xDC,0x5A,0xCD};
|
||||
|
||||
|
||||
if (argc > 1) {
|
||||
assert(strlen(argv[1]) < IFNAMSIZ);
|
||||
strcpy(dev, argv[1]);
|
||||
} else {
|
||||
strcpy(dev, IFNAME);
|
||||
}
|
||||
|
||||
printf("device name: %s\n", dev);
|
||||
|
||||
tun_fd = tun_alloc(dev);
|
||||
|
||||
int running = 1;
|
||||
|
||||
uint8_t buf[BUFLEN];
|
||||
while (running) {
|
||||
int nread;
|
||||
|
||||
if ((nread = read(tun_fd, buf, BUFLEN)) < 0) {
|
||||
perror("ERR: Read from tun_fd");
|
||||
break;
|
||||
}
|
||||
// buf[nread] = '\0';
|
||||
printf("buf :");
|
||||
print_hex(buf, nread);
|
||||
|
||||
mac_hdr hdr;
|
||||
pkt_data pkt;
|
||||
if(parse_arp_packet(&hdr, &pkt, buf, nread) == FAILED){
|
||||
perror("ERR: Cannot parse the packet");
|
||||
}
|
||||
if(receive_arp_packet(&hdr, &pkt, buf, nread, local_ip, local_mac) == FAILED){
|
||||
perror("ERR: Cannot process the packet");
|
||||
}
|
||||
if(send_arp_response(tun_fd, buf, nread, &pkt, &hdr) == FAILED){
|
||||
perror("ERR: Cannot send the response");
|
||||
}
|
||||
|
||||
printf("Read %d bytes from device %s\n\n", nread, dev);
|
||||
}
|
||||
|
||||
close(tun_fd);
|
||||
|
||||
return EXIT_SUCCESS;
|
||||
}
|
||||
46
Blatt02/A203/util.c
Normal file
46
Blatt02/A203/util.c
Normal file
@@ -0,0 +1,46 @@
|
||||
#include "util.h"
|
||||
void print_hex(uint8_t * array, size_t size){
|
||||
|
||||
for (size_t i = 0 ; i < size; i++){
|
||||
uint8_t high = (array[i] >> 4) & 0x0F;
|
||||
uint8_t low = array[i] & 0x0F;
|
||||
printf("%X", high);
|
||||
printf("%X ", low);
|
||||
}
|
||||
printf("\n");
|
||||
}
|
||||
void print_u16_hex(uint16_t number){
|
||||
uint8_t tmp_a[2];
|
||||
tmp_a[0] = (number >> 8) & 0x00FF;
|
||||
tmp_a[1] = number & 0x00FF;
|
||||
print_hex(tmp_a, 2);
|
||||
return;
|
||||
}
|
||||
void print_u8_hex(uint8_t number){
|
||||
printf("%X", (number >> 4) & 0x0F);
|
||||
printf("%X", number & 0x0F);
|
||||
printf("\n");
|
||||
}
|
||||
|
||||
// void print_packet_info(arp_packet_t * packet){
|
||||
// printf("destination: "); print_hex(packet->destination, DST_S);
|
||||
// printf("source: "); print_hex(packet->source, SRC_S);
|
||||
//
|
||||
// printf("hardware type: "); print_u16_hex(packet->hrd_t);
|
||||
// printf("protocal type: "); print_u16_hex(packet->pro_t);
|
||||
// printf("hardware size: "); print_u8_hex(packet->hrd_s);
|
||||
// printf("protocal size: "); print_u8_hex(packet->pro_s);
|
||||
// printf("op type: "); print_u16_hex(packet->op);
|
||||
//
|
||||
// printf("sender mac address: "); print_hex(packet->sender_mac_a, SENDER_MAC_A_S);
|
||||
// printf("sender ip address: "); print_hex(packet->sender_ip_a, SENDER_IP_A_S);
|
||||
// printf("target mac address: "); print_hex(packet->target_mac_a, TARGET_MAC_A_S);
|
||||
// printf("target ip address: "); print_hex(packet->target_ip_a, TARGET_IP_A_S);
|
||||
// }
|
||||
|
||||
uint16_t combine_uint8(uint8_t high, uint8_t low){
|
||||
return (high << 8 ) | low;
|
||||
}
|
||||
uint32_t combine_uint8_32(uint8_t * arr){
|
||||
return (arr[0] << 24 ) | (arr[1] << 16) | (arr[2] << 8) | (arr[3]);
|
||||
}
|
||||
16
Blatt02/A203/util.h
Normal file
16
Blatt02/A203/util.h
Normal file
@@ -0,0 +1,16 @@
|
||||
#ifndef UTIL_H
|
||||
#define UTIL_H
|
||||
|
||||
#include <stdio.h>
|
||||
#include "arp_packet_st.h"
|
||||
|
||||
#define TRUE 1
|
||||
#define FALSE 0
|
||||
|
||||
void print_hex(uint8_t * array, size_t size);
|
||||
void print_u16_hex(uint16_t number);
|
||||
void print_u8_hex(uint8_t number);
|
||||
uint16_t combine_uint8(uint8_t high, uint8_t low);
|
||||
uint32_t combine_uint8_32(uint8_t * arr);
|
||||
|
||||
#endif
|
||||
87
Blatt02/ARP.drawio
Normal file
87
Blatt02/ARP.drawio
Normal file
@@ -0,0 +1,87 @@
|
||||
<mxfile host="Electron" agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/24.7.17 Chrome/128.0.6613.36 Electron/32.0.1 Safari/537.36" version="24.7.17">
|
||||
<diagram name="Page-1" id="c7488fd3-1785-93aa-aadb-54a6760d102a">
|
||||
<mxGraphModel dx="988" dy="570" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="1100" pageHeight="850" background="none" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0" />
|
||||
<mxCell id="1" parent="0" />
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-5" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=1;exitDx=0;exitDy=0;exitPerimeter=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-3" target="W-n-PndQ-2xYdpGvvika-4" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-3" value="" style="strokeWidth=2;html=1;shape=mxgraph.flowchart.annotation_2;align=left;labelPosition=right;pointerEvents=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="170" y="350" width="50" height="100" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-7" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-4" target="W-n-PndQ-2xYdpGvvika-6" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-4" value="通知caller扔掉包" style="shape=parallelogram;html=1;strokeWidth=2;perimeter=parallelogramPerimeter;whiteSpace=wrap;rounded=1;arcSize=12;size=0;" parent="1" vertex="1">
|
||||
<mxGeometry x="300" y="440" width="100" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-6" value="生成一个Ethernet Packet<div>(type field =<br style="font-size: 8px;">ether_type$ADDR_RESOLUTION</div>" style="shape=parallelogram;html=1;strokeWidth=2;perimeter=parallelogramPerimeter;whiteSpace=wrap;rounded=1;arcSize=12;size=0;fontSize=8;align=center;" parent="1" vertex="1">
|
||||
<mxGeometry x="500" y="435" width="150" height="70" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-11" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-8" target="W-n-PndQ-2xYdpGvvika-10" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-8" value="设置ar$hrd为ares_hrd$Ethernet,<div>ar$pro为protocol type</div>" style="shape=parallelogram;html=1;strokeWidth=2;perimeter=parallelogramPerimeter;whiteSpace=wrap;rounded=1;arcSize=12;size=0;fontSize=8;align=center;" parent="1" vertex="1">
|
||||
<mxGeometry x="500" y="550" width="150" height="70" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-9" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=-0.081;entryDx=0;entryDy=0;entryPerimeter=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-6" target="W-n-PndQ-2xYdpGvvika-8" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-12" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-10" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="575.1111111111111" y="770.0555555555554" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-10" value="设置ar$hrd为ares_hrd$Ethernet,<div>ar$pro为protocol type</div><div>ar$hln为6,MAC地址的字节数</div><div>ar$pln为地址协议的长度</div><div>ar$op为ares_op$REQUEST</div><div>ar$sha为48位网络地址</div><div>ar$spa是协议地址(ipv4)</div><div>ar$tpa是机器尝试访问的协议地址</div><div>ar$tha不需要特别设定</div><div>ar$tha可以设置成广播地址</div>" style="shape=parallelogram;html=1;strokeWidth=2;perimeter=parallelogramPerimeter;whiteSpace=wrap;rounded=1;arcSize=12;size=0;fontSize=8;align=center;" parent="1" vertex="1">
|
||||
<mxGeometry x="500" y="680" width="150" height="110" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-21" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-13" target="W-n-PndQ-2xYdpGvvika-14" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-13" value="有在ar$hrd的硬件类型吗？（支持这个硬件类型吗？）" style="rounded=1;whiteSpace=wrap;html=1;fontSize=10;" parent="1" vertex="1">
|
||||
<mxGeometry x="200" y="110" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-22" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-14" target="W-n-PndQ-2xYdpGvvika-17" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-14" value="这个包的协议是在ar$pro中吗？（支持这个协议类型吗？）（可能检查地址长度" style="rounded=1;whiteSpace=wrap;html=1;fontSize=10;" parent="1" vertex="1">
|
||||
<mxGeometry x="390" y="110" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-15" value="如果Merge_flag是false<div>发送方协议地址，</div><div>发送方硬件地址</div><div>存入ARP</div>" style="rounded=1;whiteSpace=wrap;html=1;fontSize=10;" parent="1" vertex="1">
|
||||
<mxGeometry x="580" y="230" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-24" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-16" target="W-n-PndQ-2xYdpGvvika-15" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-25" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-16" target="W-n-PndQ-2xYdpGvvika-18" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-16" value="这个包是目的协议地址吗？" style="rounded=1;whiteSpace=wrap;html=1;fontSize=10;" parent="1" vertex="1">
|
||||
<mxGeometry x="580" y="110" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-17" value="把标志位Merge_flag设置为False<div>在ARP缓存表中查找发送方协议地址<br>如果存在更新ip-mac表</div><div>把标志位Merge_flag设置为true</div>" style="rounded=1;whiteSpace=wrap;html=1;fontSize=10;" parent="1" vertex="1">
|
||||
<mxGeometry x="390" y="210" width="120" height="100" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-26" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-18" target="W-n-PndQ-2xYdpGvvika-19" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-27" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-18" target="W-n-PndQ-2xYdpGvvika-20" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-18" value="opcode是ares_op$REQUEST吗？" style="rounded=1;whiteSpace=wrap;html=1;fontSize=10;" parent="1" vertex="1">
|
||||
<mxGeometry x="770" y="110" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-19" value="交换硬件和协议部分，把本地硬件和协议地址放到发送区<div>设置ar$op部分为ares_op$REPLY</div>" style="rounded=1;whiteSpace=wrap;html=1;fontSize=10;" parent="1" vertex="1">
|
||||
<mxGeometry x="770" y="230" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-20" value="发送" style="rounded=1;whiteSpace=wrap;html=1;fontSize=10;" parent="1" vertex="1">
|
||||
<mxGeometry x="960" y="110" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-23" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.029;entryY=0.516;entryDx=0;entryDy=0;entryPerimeter=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-14" target="W-n-PndQ-2xYdpGvvika-16" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
</mxfile>
|
||||
87
Blatt02/ARP2.drawio
Normal file
87
Blatt02/ARP2.drawio
Normal file
@@ -0,0 +1,87 @@
|
||||
<mxfile host="Electron" agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/24.7.17 Chrome/128.0.6613.36 Electron/32.0.1 Safari/537.36" version="24.7.17">
|
||||
<diagram name="Page-1" id="c7488fd3-1785-93aa-aadb-54a6760d102a">
|
||||
<mxGraphModel dx="687" dy="394" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="1100" pageHeight="850" background="none" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0" />
|
||||
<mxCell id="1" parent="0" />
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-5" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=1;exitDx=0;exitDy=0;exitPerimeter=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-3" target="W-n-PndQ-2xYdpGvvika-4" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-3" value="" style="strokeWidth=2;html=1;shape=mxgraph.flowchart.annotation_2;align=left;labelPosition=right;pointerEvents=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="170" y="350" width="50" height="100" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-7" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-4" target="W-n-PndQ-2xYdpGvvika-6" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-4" value="通知caller扔掉包" style="shape=parallelogram;html=1;strokeWidth=2;perimeter=parallelogramPerimeter;whiteSpace=wrap;rounded=1;arcSize=12;size=0;" parent="1" vertex="1">
|
||||
<mxGeometry x="300" y="440" width="100" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-6" value="生成一个Ethernet Packet<div>(type field =<br style="font-size: 8px;">ether_type$ADDR_RESOLUTION</div>" style="shape=parallelogram;html=1;strokeWidth=2;perimeter=parallelogramPerimeter;whiteSpace=wrap;rounded=1;arcSize=12;size=0;fontSize=8;align=center;" parent="1" vertex="1">
|
||||
<mxGeometry x="500" y="435" width="150" height="70" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-11" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-8" target="W-n-PndQ-2xYdpGvvika-10" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-8" value="设置ar$hrd为ares_hrd$Ethernet,<div>ar$pro为protocol type</div>" style="shape=parallelogram;html=1;strokeWidth=2;perimeter=parallelogramPerimeter;whiteSpace=wrap;rounded=1;arcSize=12;size=0;fontSize=8;align=center;" parent="1" vertex="1">
|
||||
<mxGeometry x="500" y="550" width="150" height="70" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-9" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=-0.081;entryDx=0;entryDy=0;entryPerimeter=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-6" target="W-n-PndQ-2xYdpGvvika-8" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-12" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-10" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="575.1111111111111" y="770.0555555555554" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-10" value="设置ar$hrd为ares_hrd$Ethernet,<div>ar$pro为protocol type</div><div>ar$hln为6,MAC地址的字节数</div><div>ar$pln为地址协议的长度</div><div>ar$op为ares_op$REQUEST</div><div>ar$sha为48位网络地址</div><div>ar$spa是协议地址(ipv4)</div><div>ar$tpa是机器尝试访问的协议地址</div><div>ar$tha不需要特别设定</div><div>ar$tha可以设置成广播地址</div>" style="shape=parallelogram;html=1;strokeWidth=2;perimeter=parallelogramPerimeter;whiteSpace=wrap;rounded=1;arcSize=12;size=0;fontSize=8;align=center;" parent="1" vertex="1">
|
||||
<mxGeometry x="500" y="680" width="150" height="110" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-21" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-13" target="W-n-PndQ-2xYdpGvvika-14" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-13" value="有在ar$hrd的硬件类型吗？（支持这个硬件类型吗？）" style="rounded=1;whiteSpace=wrap;html=1;fontSize=10;" parent="1" vertex="1">
|
||||
<mxGeometry x="200" y="110" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-22" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-14" target="W-n-PndQ-2xYdpGvvika-17" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-14" value="这个包的协议是在ar$pro中吗？（支持这个协议类型吗？）（可能检查地址长度" style="rounded=1;whiteSpace=wrap;html=1;fontSize=10;" parent="1" vertex="1">
|
||||
<mxGeometry x="390" y="110" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-15" value="如果Merge_flag是false<div>发送方协议地址，</div><div>发送方硬件地址</div><div>存入ARP</div>" style="rounded=1;whiteSpace=wrap;html=1;fontSize=10;" parent="1" vertex="1">
|
||||
<mxGeometry x="580" y="230" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-24" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-16" target="W-n-PndQ-2xYdpGvvika-15" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-25" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-16" target="W-n-PndQ-2xYdpGvvika-18" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-16" value="这个包是目的协议地址吗？" style="rounded=1;whiteSpace=wrap;html=1;fontSize=10;" parent="1" vertex="1">
|
||||
<mxGeometry x="580" y="110" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-17" value="把标志位Merge_flag设置为False<div>在ARP缓存表中查找发送方协议地址<br>如果存在更新ip-mac表</div><div>把标志位Merge_flag设置为true</div>" style="rounded=1;whiteSpace=wrap;html=1;fontSize=10;" parent="1" vertex="1">
|
||||
<mxGeometry x="390" y="210" width="120" height="100" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-26" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-18" target="W-n-PndQ-2xYdpGvvika-19" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-27" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-18" target="W-n-PndQ-2xYdpGvvika-20" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-18" value="opcode是ares_op$REQUEST吗？" style="rounded=1;whiteSpace=wrap;html=1;fontSize=10;" parent="1" vertex="1">
|
||||
<mxGeometry x="770" y="110" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-19" value="交换硬件和协议部分，把本地硬件和协议地址放到发送区<div>设置ar$op部分为ares_op$REPLY</div>" style="rounded=1;whiteSpace=wrap;html=1;fontSize=10;" parent="1" vertex="1">
|
||||
<mxGeometry x="770" y="230" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-20" value="发送" style="rounded=1;whiteSpace=wrap;html=1;fontSize=10;" parent="1" vertex="1">
|
||||
<mxGeometry x="960" y="110" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="W-n-PndQ-2xYdpGvvika-23" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.029;entryY=0.516;entryDx=0;entryDy=0;entryPerimeter=0;" parent="1" source="W-n-PndQ-2xYdpGvvika-14" target="W-n-PndQ-2xYdpGvvika-16" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
</mxfile>
|
||||
504
Blatt02/Blatt02.md
Normal file
504
Blatt02/Blatt02.md
Normal file
@@ -0,0 +1,504 @@
|
||||
|
||||
|
||||
```
|
||||
root@pc1:~# tcpdump -i eth1
|
||||
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
|
||||
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
|
||||
19:35:04.553056 IP6 fe80::216:3eff:fe00:2 > fe80::216:3eff:fe00:4: ICMP6, echo request, id 38058, seq 1, length 64
|
||||
19:35:04.555038 IP6 fe80::216:3eff:fe00:4 > fe80::216:3eff:fe00:2: ICMP6, echo reply, id 38058, seq 1, length 64
|
||||
19:35:05.554500 IP6 fe80::216:3eff:fe00:2 > fe80::216:3eff:fe00:4: ICMP6, echo request, id 38058, seq 2, length 64
|
||||
19:35:05.555265 IP6 fe80::216:3eff:fe00:4 > fe80::216:3eff:fe00:2: ICMP6, echo reply, id 38058, seq 2, length 64
|
||||
19:35:06.555772 IP6 fe80::216:3eff:fe00:2 > fe80::216:3eff:fe00:4: ICMP6, echo request, id 38058, seq 3, length 64
|
||||
19:35:06.556673 IP6 fe80::216:3eff:fe00:4 > fe80::216:3eff:fe00:2: ICMP6, echo reply, id 38058, seq 3, length 64
|
||||
19:35:07.557110 IP6 fe80::216:3eff:fe00:2 > fe80::216:3eff:fe00:4: ICMP6, echo request, id 38058, seq 4, length 64
|
||||
19:35:07.557961 IP6 fe80::216:3eff:fe00:4 > fe80::216:3eff:fe00:2: ICMP6, echo reply, id 38058, seq 4, length 64
|
||||
19:35:08.558528 IP6 fe80::216:3eff:fe00:2 > fe80::216:3eff:fe00:4: ICMP6, echo request, id 38058, seq 5, length 64
|
||||
19:35:08.559256 IP6 fe80::216:3eff:fe00:4 > fe80::216:3eff:fe00:2: ICMP6, echo reply, id 38058, seq 5, length 64
|
||||
19:35:08.722292 IP6 fe80::216:3eff:fe00:4 > fe80::216:3eff:fe00:2: ICMP6, echo request, id 10952, seq 1, length 64
|
||||
19:35:08.722331 IP6 fe80::216:3eff:fe00:2 > fe80::216:3eff:fe00:4: ICMP6, echo reply, id 10952, seq 1, length 64
|
||||
19:35:09.631016 IP6 fe80::216:3eff:fe00:4 > fe80::216:3eff:fe00:2: ICMP6, neighbor solicitation, who has fe80::216:3eff:fe00:2, length 32
|
||||
19:35:09.631064 IP6 fe80::216:3eff:fe00:2 > fe80::216:3eff:fe00:4: ICMP6, neighbor advertisement, tgt is fe80::216:3eff:fe00:2, length 24
|
||||
19:35:09.723566 IP6 fe80::216:3eff:fe00:4 > fe80::216:3eff:fe00:2: ICMP6, echo request, id 10952, seq 2, length 64
|
||||
19:35:09.723596 IP6 fe80::216:3eff:fe00:2 > fe80::216:3eff:fe00:4: ICMP6, echo reply, id 10952, seq 2, length 64
|
||||
19:35:10.724802 IP6 fe80::216:3eff:fe00:4 > fe80::216:3eff:fe00:2: ICMP6, echo request, id 10952, seq 3, length 64
|
||||
19:35:10.724838 IP6 fe80::216:3eff:fe00:2 > fe80::216:3eff:fe00:4: ICMP6, echo reply, id 10952, seq 3, length 64
|
||||
19:35:11.726031 IP6 fe80::216:3eff:fe00:4 > fe80::216:3eff:fe00:2: ICMP6, echo request, id 10952, seq 4, length 64
|
||||
19:35:11.726064 IP6 fe80::216:3eff:fe00:2 > fe80::216:3eff:fe00:4: ICMP6, echo reply, id 10952, seq 4, length 64
|
||||
19:35:12.727250 IP6 fe80::216:3eff:fe00:4 > fe80::216:3eff:fe00:2: ICMP6, echo request, id 10952, seq 5, length 64
|
||||
19:35:12.727282 IP6 fe80::216:3eff:fe00:2 > fe80::216:3eff:fe00:4: ICMP6, echo reply, id 10952, seq 5, length 64
|
||||
```
|
||||
|
||||
|
||||
|
||||
```
|
||||
root@pc1:~# python3 208.py
|
||||
Ether / fe80::216:3eff:fe00:2 > ff02::16 (0) / IPv6ExtHdrHopByHop / ICMPv6MLReport2
|
||||
Ether / fe80::216:3eff:fe00:2 > ff02::16 (0) / IPv6ExtHdrHopByHop / ICMPv6MLReport2
|
||||
Ether / fe80::216:3eff:fe00:4 > ff02::16 (0) / IPv6ExtHdrHopByHop / ICMPv6MLReport2
|
||||
Ether / fe80::216:3eff:fe00:4 > ff02::16 (0) / IPv6ExtHdrHopByHop / ICMPv6MLReport2
|
||||
Ether / IPv6 / ICMPv6 Echo Request (id: 0x3d3d seq: 0x1)
|
||||
Ether / IPv6 / ICMPv6 Echo Reply (id: 0x3d3d seq: 0x1)
|
||||
Ether / IPv6 / ICMPv6 Echo Request (id: 0x3d3d seq: 0x2)
|
||||
Ether / IPv6 / ICMPv6 Echo Reply (id: 0x3d3d seq: 0x2)
|
||||
Ether / IPv6 / ICMPv6 Echo Request (id: 0x3d3d seq: 0x3)
|
||||
Ether / IPv6 / ICMPv6 Echo Reply (id: 0x3d3d seq: 0x3)
|
||||
Ether / IPv6 / ICMPv6 Echo Request (id: 0x3d3d seq: 0x4)
|
||||
Ether / IPv6 / ICMPv6 Echo Reply (id: 0x3d3d seq: 0x4)
|
||||
Ether / IPv6 / ICMPv6 Echo Request (id: 0x3d3d seq: 0x5)
|
||||
Ether / IPv6 / ICMPv6 Echo Reply (id: 0x3d3d seq: 0x5)
|
||||
Ether / IPv6 / ICMPv6 Echo Request (id: 0x6b18 seq: 0x1)
|
||||
Ether / IPv6 / ICMPv6 Echo Reply (id: 0x6b18 seq: 0x1)
|
||||
Ether / IPv6 / ICMPv6 Echo Request (id: 0x6b18 seq: 0x2)
|
||||
Ether / IPv6 / ICMPv6 Echo Reply (id: 0x6b18 seq: 0x2)
|
||||
Ether / IPv6 / ICMPv6 Echo Request (id: 0x6b18 seq: 0x3)
|
||||
Ether / IPv6 / ICMPv6 Echo Reply (id: 0x6b18 seq: 0x3)
|
||||
Ether / IPv6 / ICMPv6 Echo Request (id: 0x6b18 seq: 0x4) Ether / IPv6 / ICMPv6 Echo Reply (id: 0x6b18 seq: 0x4)
|
||||
Ether / IPv6 / ICMPv6 Echo Request (id: 0x6b18 seq: 0x5)
|
||||
Ether / IPv6 / ICMPv6 Echo Reply (id: 0x6b18 seq: 0x5)
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
```
|
||||
buf :255 255 255 255 255 255 174 171 50 9 142 180 8 6 0 1 8 0 6 4 0 1 174 171 50 9 142 180 10 5 1 1 0 0 0 0 0 0 10 5 1 2 0 0 0 0 0 0 0 0 0 0 0 22 58 0 5 2 0 0 1 0 143 0 117 226 0 0 0 1 4 0 0 0 255 2 0 0 0 0 0 0 0 0 0 1 255 9 142 180 0 0 0 0 0 0 0 0 0 0 0 0 0 0 156 111 139 231 79 127 0 0 95 154 127 103 0 0 0 0 1 0 0 0 0 0 0 0 228 77 109 231 79 127 0 0 240 212 138 231 79 127 0 0 9 0 0 0 0 0 0 0 164 115 139 231 79 127 0 0 196 0 0 0 0 0 0 0 16 78 110 231 79 127 0 0 0 112 138 231 79 127 0 0 216 182 6 248 254 127 0 0 212 182 6 248 254 127 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 16 78 110 231 79 127 0 0 224 111 109 231 79 127 0 0 49 217 138 231 79 127 0 0 95 154 127 103 0 0 0 0 105 254 157 1 0 0 0 0 212 182 6 248 254 127 0 0 32 117 138 231 79 127 0 0 160 183 6 248 254 127 0 0 240 212 138 231 79 127 0 0 144 183 6 248 254 127 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 95 154 127 103 0 0 0 0 232 148 141 231 79 127 0 0 49 217 138 231 79 127 0 0 184 184 6 248 254 127 0 0 144 183 6 248 254 127 0 0 160 183 6 248 254 127 0 0 225 124 139 231 79 127 0 0 1 0 0 0 0 0 0 0 168 121 138 231 79 127 0 0 9 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 232 137 141 231 79 127 0 0 48 151 141 231 79 127 0 0 168 121 138 231 79 127 0 0 232 137 141 231 79 127 0 0 0 0 0 0 1 0 0 0 232 148 141 231 79 127 0 0 0 0 0 0 0 0 0 0 216 210 10 248 254 127 0 0 184 209 10 248 254 127 0 0 255 255 255 255 0 0 0 0 83 143 48 104 0 0 0 0 64 130 109 231 79 127 0 0 0 112 138 231 79 127 0 0 88 151 141 231 79 127 0 0 176 184 6 248 254 127 0 0 192 185 6 248 254 127 0 0 3 0 0 0 0 0 0 0 208 184 6 248 254 127 0 0 100 223 139 231 79 127 0 0 217 118 141 231 79 127 0 0 80 223 138 231 79 127 0 0 48 185 6 248 254 127 0 0 7 0 0 0 0 0 0 0 7 0 0 0 8 0 0 0 240 212 138 231 79 127 0 0 232 137 141 231 79 127 0 0 77 146 139 231 79 127 0 0 0 0 0 0 0 0 0 0 216 160 139 231 79 127 0 0 128 184 6 248 254 127 0 0 200 197 110 231 79 127 0 0 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 185 6 248 254 127 0 0 0 0 0 0 0 0 0 0 0 185 6 248 254 127 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 96 215 138 231 79 127 0 0 232 148 141 231 79 127 0 0 132 217 138 231 79 127 0 0 48 212 138 231 79 127 0 0 72 128 141 231 79 127 0 0 0 208 138 231 79 127 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 64 130 109 231 79 127 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 186 183 144 108 127 166 0 0 3 232 138 108 127 166 0 0 128 145 141 231 79 127 0 0 128 145 141 231 79 127 0 0 232 70 140 231 79 127 0 0 208 187 6 248 254 127 0 0 31 27 139 231 79 127 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 64 133 138 231 79 127 0 0 128 144 141 231 79 127 0 0 0 0 0 0 0 0 0 0 1 189 6 248 254 127 0 0 1 151 141 231 79 127 0 0 232 137 141 231 79 127 0 0 184 185 6 248 254 127 0 0 3 232 138 108 127 166 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 24 210 10 248 254 127 0 0 0 0 0 0 32 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 246 117 174 3 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 230 207 6 248 254 127 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 194 0 0 0 0 0 0 0 215 187 6 248 254 127 0 0 149 84 245 242 222 85 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||||
Read 42 bytes from device tap0
|
||||
```
|
||||
|
||||
```
|
||||
buf :FF FF FF FF FF FF AE AB 32 09 8E B4 08 06 00 01 08 00 06 04 00 01 AE AB 32 09 8E B4 0A 05 01 01 00 00 00 00 00 00 0A 05 01 02 00 00 00 00 00 00 00 00 00 00 00 16 3A 00 05 02 00 00 01 00 8F 00 75 E2 00 00 00 01 04 00 00 00 FF 02 00 00 00 00 00 00 00 00 00 01 FF 09 8E B4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9C CF 46 E5 67 7F 00 00 5F 9A 7F 67 00 00 00 00 01 00 00 00 00 00 00 00 E4 AD 28 E5 67 7F 00 00 F0 34 46 E5 67 7F 00 00 09 00 00 00 00 00 00 00 A4 D3 46 E5 67 7F 00 00 C4 00 00 00 00 00 00 00 10 AE 29 E5 67 7F 00 00 00 D0 45 E5 67 7F 00 00 88 E3 64 9A FE 7F 00 00 84 E3 64 9A FE 7F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 AE 29 E5 67 7F 00 00 E0 CF 28 E5 67 7F 00 00 31 39 46 E5 67 7F 00 00 5F 9A 7F 67 00 00 00 00 69 FE 9D 01 00 00 00 00 84 E3 64 9A FE 7F 00 00 20 D5 45 E5 67 7F 00 00 50 E4 64 9A FE 7F 00 00 F0 34 46 E5 67 7F 00 00 40 E4 64 9A FE 7F 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5F 9A 7F 67 00 00 00 00 E8 F4 48 E5 67 7F 00 00 31 39 46 E5 67 7F 00 00 68 E5 64 9A FE 7F 00 00 40 E4 64 9A FE 7F 00 00 50 E4 64 9A FE 7F 00 00 E1 DC 46 E5 67 7F 00 00 01 00 00 00 00 00 00 00 A8 D9 45 E5 67 7F 00 00 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 E8 E9 48 E5 67 7F 00 00 30 F7 48 E5 67 7F 00 00 A8 D9 45 E5 67 7F 00 00 E8 E9 48 E5 67 7F 00 00 00 00 00 00 01 00 00 00 E8 F4 48 E5 67 7F 00 00 00 00 00 00 00 00 00 00 D8 52 6F 9A FE 7F 00 00 B8 51 6F 9A FE 7F 00 00 FF FF FF FF 00 00 00 00 53 8F 30 68 00 00 00 00 40 E2 28 E5 67 7F 00 00 00 D0 45 E5 67 7F 00 00 58 F7 48 E5 67 7F 00 00 60 E5 64 9A FE 7F 00 00 70 E6 64 9A FE 7F 00 00 03 00 00 00 00 00 00 00 80 E5 64 9A FE 7F 00 00 64 3F 47 E5 67 7F 00 00 D9 D6 48 E5 67 7F 00 00 50 3F 46 E5 67 7F 00 00 E0 E5 64 9A FE 7F 00 00 07 00 00 00 00 00 00 00 07 00 00 00 08 00 00 00 F0 34 46 E5 67 7F 00 00 E8 E9 48 E5 67 7F 00 00 4D F2 46 E5 67 7F 00 00 00 00 00 00 00 00 00 00 D8 00 47 E5 67 7F 00 00 30 E5 64 9A FE 7F 00 00 C8 25 2A E5 67 7F 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 E5 64 9A FE 7F 00 00 00 00 00 00 00 00 00 00 B0 E5 64 9A FE 7F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60 37 46 E5 67 7F 00 00 E8 F4 48 E5 67 7F 00 00 84 39 46 E5 67 7F 00 00 30 34 46 E5 67 7F 00 00 48 E0 48 E5 67 7F 00 00 00 30 46 E5 67 7F 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 40 E2 28 E5 67 7F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 33 C8 BC BE A7 00 00 3F 90 B0 BC BE A7 00 00 80 F1 48 E5 67 7F 00 00 80 F1 48 E5 67 7F 00 00 E8 A6 47 E5 67 7F 00 00 80 E8 64 9A FE 7F 00 00 1F 7B 46 E5 67 7F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40 E5 45 E5 67 7F 00 00 80 F0 48 E5 67 7F 00 00 00 00 00 00 00 00 00 00 01 EA 64 9A FE 7F 00 00 01 F7 48 E5 67 7F 00 00 E8 E9 48 E5 67 7F 00 00 68 E6 64 9A FE 7F 00 00 3F 90 B0 BC BE A7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 52 6F 9A FE 7F 00 00 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 F6 75 AE 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E6 EF 64 9A FE 7F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C2 00 00 00 00 00 00 00 87 E8 64 9A FE 7F 00 00 F5 64 7B 22 E1 55 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
Read 42 bytes from device tap0
|
||||
```
|
||||
|
||||
```
|
||||
buf :FF FF FF FF FF FF AE AB 32 09 8E B4 08 06 00 01 08 00 06 04 00 01 AE AB 32 09 8E B4 0A 05 01 01 00 00 00 00 00 00 0A 05 01 02
|
||||
Read 42 bytes from device tap0
|
||||
```
|
||||
|
||||
```
|
||||
buf :FF FF FF FF FF FF AE AB 32 09 8E B4 08 06 00 01 08 00 06 04 00 01 AE AB 32 09 8E B4 0A 05 01 01 00 00 00 00 00 00 0A 05 01 03
|
||||
Read 42 bytes from device tap0
|
||||
```
|
||||
|
||||
|
||||
|
||||
00:16:3e:00:00:04
|
||||
|
||||
52:5e:a1:8f:e3:6a
|
||||
|
||||
|
||||
|
||||
根据提供的 `buf` 内容，可以解析出这是一个 **ARP 请求包**。以下是详细的解析步骤。
|
||||
|
||||
---
|
||||
|
||||
### **1. ARP 数据包结构**
|
||||
|
||||
ARP 请求包的基本结构如下：
|
||||
|
||||
| 字段名称 | 长度（字节） | 说明 |
|
||||
| --------------------- | ------------ | ---------------------------------------------- |
|
||||
| 目标 MAC 地址 | 6 | 广播地址（`FF:FF:FF:FF:FF:FF`） |
|
||||
| 源 MAC 地址 | 6 | 发送方的 MAC 地址 |
|
||||
| 上层协议类型 | 2 | 表示这是一个 ARP 包（值为 `0x0806`） |
|
||||
| 硬件类型 | 2 | 通常为以太网（值为 `0x0001`） |
|
||||
| 协议类型 | 2 | 表示 IP 协议（值为 `0x0800`） |
|
||||
| 硬件地址长度 | 1 | MAC 地址的长度，通常为 6 |
|
||||
| 协议地址长度 | 1 | IP 地址的长度，通常为 4 |
|
||||
| 操作码 | 2 | `0x0001` 表示 ARP 请求，`0x0002` 表示 ARP 响应 |
|
||||
| 发送方硬件地址（SHA） | HLEN（6） | 发送方的 MAC 地址 |
|
||||
| 发送方协议地址（SPA） | PLEN（4） | 发送方的 IP 地址 |
|
||||
| 目标硬件地址（THA） | HLEN（6） | 目标的 MAC 地址，ARP 请求中为全 0 |
|
||||
| 目标协议地址（TPA） | PLEN（4） | 目标的 IP 地址 |
|
||||
|
||||
---
|
||||
|
||||
### **2. 提供的 `buf` 内容**
|
||||
原始数据：
|
||||
```
|
||||
FF FF FF FF FF FF AE AB 32 09 8E B4 08 06 00 01 08 00 06 04 00 01 AE AB 32 09 8E B4 0A 05 01 01 00 00 00 00 00 00 0A 05 01 02
|
||||
```
|
||||
|
||||
**分解字段：**
|
||||
| 偏移 | 字节范围 | 内容 | 解析说明 |
|
||||
| ---- | ------------------- | ------------------------------------------ | -------------------------------------------- |
|
||||
| 0 | `FF FF FF FF FF FF` | 目标 MAC 地址：广播地址 | 目标为全网广播 |
|
||||
| 6 | `AE AB 32 09 8E B4` | 源 MAC 地址：`AE:AB:32:09:8E:B4` | PC2 的 `tap0` MAC 地址 |
|
||||
| 12 | `08 06` | 上层协议类型：ARP 包 (`0x0806`) | 表示这是一个 ARP 包 |
|
||||
| 14 | `00 01` | 硬件类型：以太网 (`0x0001`) | 表示硬件类型为以太网 |
|
||||
| 16 | `08 00` | 协议类型：IPv4 (`0x0800`) | 表示要解析的协议为 IPv4 |
|
||||
| 18 | `06` | 硬件地址长度（HLEN）：6 | MAC 地址长度为 6 字节 |
|
||||
| 19 | `04` | 协议地址长度（PLEN）：4 | IP 地址长度为 4 字节 |
|
||||
| 20 | `00 01` | 操作码（OPER）：请求 (`0x0001`) | 表示这是一个 ARP 请求包 |
|
||||
| 22 | `AE AB 32 09 8E B4` | 发送方硬件地址（SHA）：`AE:AB:32:09:8E:B4` | 发送方 MAC 地址，来自 PC2 的 `tap0` 接口 |
|
||||
| 28 | `0A 05 01 01` | 发送方协议地址（SPA）：`10.5.1.1` | 发送方 IP 地址 |
|
||||
| 32 | `00 00 00 00 00 00` | 目标硬件地址（THA）：`00:00:00:00:00:00` | 目标 MAC 地址为空，全零（未解析） |
|
||||
| 38 | `0A 05 01 02` | 目标协议地址（TPA）：`10.5.1.2` | 目标 IP 地址（PC1 的 `tap0` 接口的 IP 地址） |
|
||||
|
||||
---
|
||||
|
||||
### **3. 分析说明**
|
||||
- **目标 MAC 地址（广播）**：
|
||||
目标 MAC 地址是 `FF:FF:FF:FF:FF:FF`，表示这是一个广播包，发往子网内的所有设备。
|
||||
|
||||
- **源 MAC 地址**：
|
||||
源 MAC 地址是 `AE:AB:32:09:8E:B4`，这对应 PC2 的 `tap0` 接口。
|
||||
|
||||
- **操作类型（请求）**：
|
||||
操作码是 `0x0001`，表明这是一个 ARP 请求包。
|
||||
|
||||
- **发送方 IP 地址和 MAC 地址**：
|
||||
发送方 IP 地址是 `10.5.1.1`，MAC 地址是 `AE:AB:32:09:8E:B4`。
|
||||
|
||||
- **目标 IP 地址**：
|
||||
目标 IP 地址是 `10.5.1.2`，这对应 PC1 的 `tap0` 接口的 IP 地址。
|
||||
|
||||
- **目标 MAC 地址为空**：
|
||||
因为这是一个 ARP 请求，目标的 MAC 地址尚未解析，所以此字段为全零。
|
||||
|
||||
---
|
||||
|
||||
### **4. 整体解析结果**
|
||||
PC1 的 `tap0` 接口收到的 `buf` 是一个 **ARP 请求包**，由 PC2 的 `tap0` 接口发送，目的是解析目标 IP 地址 `10.5.1.2` 对应的 MAC 地址。
|
||||
|
||||
**PC1 的响应：**
|
||||
- PC1 的 `tap0` 应该生成一个 ARP 响应包，包含以下信息：
|
||||
- 目标 MAC 地址：`AE:AB:32:09:8E:B4`（PC2 的 MAC 地址）。
|
||||
- 目标 IP 地址：`10.5.1.1`（PC2 的 IP 地址）。
|
||||
- 源 MAC 地址：PC1 的 `tap0` 的 MAC 地址。
|
||||
- 源 IP 地址：`10.5.1.2`（PC1 的 IP 地址）。
|
||||
|
||||
---
|
||||
|
||||
### **抓包工具验证**
|
||||
你可以使用 `tcpdump` 或 `Wireshark` 来验证 ARP 包的内容：
|
||||
```bash
|
||||
sudo tcpdump -i tap0 -vv arp
|
||||
```
|
||||
或者在 Wireshark 中直接查看 ARP 请求的详细信息，与上述解析进行对比。
|
||||
|
||||
|
||||
|
||||
|
||||
```
|
||||
buf :FF FF FF FF FF FF AE AB 32 09 8E B4 08 06 00 01 08 00 06 04 00 01 AE AB 32 09 8E B4 0A 05 01 01 00 00 00 00 00 00 0A 05 01 02 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
|
||||
```
|
||||
=======
|
||||
|
||||
|
||||
|
||||
|
||||
root@pc1:~# tcpdump -i eth1
|
||||
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
|
||||
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
|
||||
10:53:47.911087 IP6 2001:db8:5::2 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2001:db8:5::1, length 32
|
||||
10:53:47.911189 IP6 2001:db8:5::1 > 2001:db8:5::2: ICMP6, neighbor advertisement, tgt is 2001:db8:5::1, length 32
|
||||
10:53:47.912325 IP6 2001:db8:5::2 > 2001:db8:5::1: ICMP6, echo request, id 56760, seq 1, length 64
|
||||
10:53:47.912349 IP6 2001:db8:5::1 > 2001:db8:5::2: ICMP6, echo reply, id 56760, seq 1, length 64
|
||||
10:53:48.904692 IP6 2001:db8:5::2 > 2001:db8:5::1: ICMP6, echo request, id 56760, seq 2, length 64
|
||||
10:53:48.904719 IP6 2001:db8:5::1 > 2001:db8:5::2: ICMP6, echo reply, id 56760, seq 2, length 64
|
||||
10:53:49.906078 IP6 2001:db8:5::2 > 2001:db8:5::1: ICMP6, echo request, id 56760, seq 3, length 64
|
||||
10:53:49.906103 IP6 2001:db8:5::1 > 2001:db8:5::2: ICMP6, echo reply, id 56760, seq 3, length 64
|
||||
10:53:50.907512 IP6 2001:db8:5::2 > 2001:db8:5::1: ICMP6, echo request, id 56760, seq 4, length 64
|
||||
10:53:50.907538 IP6 2001:db8:5::1 > 2001:db8:5::2: ICMP6, echo reply, id 56760, seq 4, length 64
|
||||
10:53:51.908904 IP6 2001:db8:5::2 > 2001:db8:5::1: ICMP6, echo request, id 56760, seq 5, length 64
|
||||
10:53:51.908929 IP6 2001:db8:5::1 > 2001:db8:5::2: ICMP6, echo reply, id 56760, seq 5, length 64
|
||||
10:53:52.926411 IP6 fe80::216:3eff:fe00:2 > 2001:db8:5::2: ICMP6, neighbor solicitation, who has 2001:db8:5::2, length 32
|
||||
10:53:52.927121 IP6 2001:db8:5::2 > fe80::216:3eff:fe00:2: ICMP6, neighbor advertisement, tgt is 2001:db8:5::2, length 24
|
||||
|
||||
|
||||
|
||||
13:14:32.958532 IP6 2001:db8:5::1 > 2001:db8:5::2: ICMP6, neighbor advertisement, tgt is 2001:db8:5::2, length 32
|
||||
0x0000: 0016 3e00 0004 0016 3e00 0602 86dd 6000 ..>.....>.....`.
|
||||
0x0010: 0000 0020 3aff 2001 0db8 0005 0000 0000 ....:...........
|
||||
0x0020: 0000 0000 0001 2001 0db8 0005 0000 0000 ................
|
||||
0x0030: 0000 0000 0002 8800 484c 6000 0000 2001 ........HL`.....
|
||||
0x0040: 0db8 0005 0000 0000 0000 0000 0002 0201 ................
|
||||
0x0050: 0016 3e00 0602 ..>...
|
||||
|
||||
```
|
||||
13:14:32.958532 IP6 2001:db8:5::1 > 2001:db8:5::2: ICMP6, neighbor advertisement, tgt is 2001:db8:5::2, length 32
|
||||
0x0000: 0016 3e00 0004 0016 3e00 0602 86dd 6000 ..>.....>.....`.
|
||||
0x0010: 0000 0020 3aff 2001 0db8 0005 0000 0000 ....:...........
|
||||
0x0020: 0000 0000 0001 2001 0db8 0005 0000 0000 ................
|
||||
0x0030: 0000 0000 0002 8800 484c 6000 0000 2001 ........HL`.....
|
||||
0x0040: 0db8 0005 0000 0000 0000 0000 0002 0201 ................
|
||||
0x0050: 0016 3e00 0602 ..>...
|
||||
```
|
||||
|
||||
00:16:3e:00:00:02
|
||||
|
||||
|
||||
|
||||
这个包是一个 **ICMPv6 邻居通告（Neighbor Advertisement, NA）** 消息，表明发送方（`2001:db8:5::1`）告知接收方（`2001:db8:5::2`），其目标地址（`tgt`）的链路层（MAC）信息。
|
||||
|
||||
以下是对这个包的逐字段详细分析：
|
||||
|
||||
------
|
||||
|
||||
### **1. 数据包的结构**
|
||||
|
||||
ICMPv6 邻居通告消息由以下几部分组成：
|
||||
|
||||
| **字段** | **长度** | **解释** |
|
||||
| ------------------- | -------- | ------------------------------------------------------ |
|
||||
| **以太网帧头** | 14 字节 | 包括源 MAC 地址、目标 MAC 地址和以太网类型。 |
|
||||
| **IPv6 头** | 40 字节 | IPv6 源地址、目的地址，及与数据包相关的信息。 |
|
||||
| **ICMPv6 头** | 4 字节 | 包括类型（Type）、代码（Code）、校验和（Checksum）。 |
|
||||
| **ICMPv6 数据部分** | 可变长度 | 邻居通告消息的具体内容，包括目标地址和链路层地址选项。 |
|
||||
|
||||
------
|
||||
|
||||
### **2. 分析具体字段**
|
||||
|
||||
#### **以太网帧头**
|
||||
|
||||
```
|
||||
0x0000: 0016 3e00 0004 0016 3e00 0602 86dd
|
||||
```
|
||||
|
||||
| 偏移量 | 字段 | 值 | 解释 |
|
||||
| -------- | ------------- | ------------------- | --------------------------------------- |
|
||||
| `0x0000` | 目标 MAC 地址 | `00:16:3e:00:00:04` | 目标设备的链路层地址（目的 MAC 地址）。 |
|
||||
| `0x0006` | 源 MAC 地址 | `00:16:3e:00:06:02` | 源设备的链路层地址（发送方 MAC 地址）。 |
|
||||
| `0x000c` | 以太网类型 | `0x86dd` | 表示接下来的数据是 IPv6 数据包。 |
|
||||
|
||||
------
|
||||
|
||||
#### **IPv6 头部**
|
||||
|
||||
```
|
||||
0x0010: 6000 0000 0020 3aff 2001 0db8 0005 0000
|
||||
0x0020: 0000 0000 0001 2001 0db8 0005 0000 0000
|
||||
0x0030: 0000 0000 0002
|
||||
```
|
||||
|
||||
| 偏移量 | 字段 | 值 | 解释 |
|
||||
| -------- | ---------------- | --------------- | -------------------------------------------- |
|
||||
| `0x0010` | 版本/流量类/流标 | `6000 0000` | IPv6 版本号（6），流量类别（0），流标（0）。 |
|
||||
| `0x0014` | 载荷长度 | `0020` | 载荷长度 32 字节。 |
|
||||
| `0x0016` | 下一头部类型 | `3a` | 表示下一头部为 ICMPv6（58）。 |
|
||||
| `0x0017` | 跳数限制 | `ff` | 初始跳数设置为 255，避免跨链路转发。 |
|
||||
| `0x0018` | 源地址 | `2001:db8:5::1` | 发送方 IPv6 地址。 |
|
||||
| `0x0028` | 目的地址 | `2001:db8:5::2` | 接收方 IPv6 地址。 |
|
||||
|
||||
------
|
||||
|
||||
#### **ICMPv6 头部**
|
||||
|
||||
```
|
||||
0x0030: 8800 484c
|
||||
```
|
||||
|
||||
| 偏移量 | 字段 | 值 | 解释 |
|
||||
| -------- | ------------ | ------ | ------------------------------------------------ |
|
||||
| `0x0030` | 类型（Type） | `88` | 表示这是一个邻居通告（Neighbor Advertisement）。 |
|
||||
| `0x0031` | 代码（Code） | `00` | 固定为 0（邻居通告无子代码）。 |
|
||||
| `0x0032` | 校验和 | `484c` | 校验和，确保 ICMPv6 数据的完整性。 |
|
||||
|
||||
------
|
||||
|
||||
#### **ICMPv6 数据部分**
|
||||
|
||||
```
|
||||
0x0034: 6000 0000 2001 0db8 0005 0000 0000 0000 0002
|
||||
0x0050: 0201 0016 3e00 0602
|
||||
```
|
||||
|
||||
##### **(a) 邻居通告标志和目标地址**
|
||||
|
||||
```
|
||||
0x0034: 6000 0000 2001 0db8 0005 0000 0000 0000 0002
|
||||
```
|
||||
|
||||
| 偏移量 | 字段 | 值 | 解释 |
|
||||
| -------- | -------- | --------------- | ---------------------------------- |
|
||||
| `0x0034` | 目标地址 | `2001:db8:5::2` | 目标设备的 IPv6 地址，告知请求方。 |
|
||||
|
||||
##### **(b) 链路层地址选项**
|
||||
|
||||
```
|
||||
0x0050: 0201 0016 3e00 0602
|
||||
```
|
||||
|
||||
| 偏移量 | 字段 | 值 | 解释 |
|
||||
| -------- | -------- | ------------------- | ---------------------------------------------------- |
|
||||
| `0x0050` | 选项类型 | `02` | 链路层地址选项（Target Link-Layer Address Option）。 |
|
||||
| `0x0051` | 选项长度 | `01` | 长度为 1（单位：8 字节）。 |
|
||||
| `0x0052` | MAC 地址 | `00:16:3e:00:06:02` | 目标设备的链路层地址（MAC 地址）。 |
|
||||
|
||||
------
|
||||
|
||||
### **3. 总结这个包的含义**
|
||||
|
||||
1. **包类型**：
|
||||
- 这是一个 **ICMPv6 邻居通告（NA）** 数据包。
|
||||
2. **发送方信息**：
|
||||
- IPv6 地址：`2001:db8:5::1`。
|
||||
- MAC 地址：`00:16:3e:00:06:02`。
|
||||
3. **接收方信息**：
|
||||
- 目标 IPv6 地址：`2001:db8:5::2`。
|
||||
- 目标链路层地址（MAC）：`00:16:3e:00:04`。
|
||||
4. **作用**：
|
||||
- 通知目标设备（`2001:db8:5::2`），IPv6 地址 `2001:db8:5::1` 解析为 MAC 地址 `00:16:3e:00:06:02`。
|
||||
5. **网络流程**：
|
||||
- 这是对之前邻居请求（NS）消息的回复，目标设备将更新其邻居表，以便后续通信。
|
||||
|
||||
------
|
||||
|
||||
### **补充**
|
||||
|
||||
- **邻居通告的用途**：
|
||||
- 用于响应邻居请求。
|
||||
- 通知链路上的其他设备该地址的链路层信息。
|
||||
- **校验关键点**：
|
||||
- 确认 IPv6 头部和 ICMPv6 数据是否正确匹配。
|
||||
- 确保链路层地址和目标地址一致。
|
||||
|
||||
如果你需要进一步分析或有其他问题，请随时补充！
|
||||
=======
|
||||
是的，你可以在这个 `tuntap.c` 文件的基础上完成第二问和第三问。以下是如何扩展这个文件来实现处理 ARP 请求和生成 ARP 响应的建议步骤：
|
||||
|
||||
---
|
||||
|
||||
### **扩展步骤**
|
||||
|
||||
#### **1. 增加 ARP 数据包解析和生成的逻辑**
|
||||
- 定义 ARP 数据包的结构。
|
||||
- 添加解析函数，用于从 `buf` 中提取 ARP 请求包的信息。
|
||||
- 添加响应生成函数，用于根据解析结果生成 ARP 响应包。
|
||||
|
||||
#### **2. 在现有的读取逻辑中嵌入 ARP 处理**
|
||||
- 当前的代码已经实现了从 `TUN/TAP` 设备读取数据的功能（`read`）。
|
||||
- 在读取的数据中，检查是否为 ARP 请求包（根据协议类型和操作码）。
|
||||
- 如果是 ARP 请求，则生成响应数据，并通过设备写回。
|
||||
|
||||
#### **3. 实现发送 ARP 响应的逻辑**
|
||||
- 使用 `write` 系统调用，将生成的 ARP 响应包通过 `tap` 接口发送回去。
|
||||
|
||||
---
|
||||
|
||||
### **代码实现（示例）**
|
||||
|
||||
以下是如何在现有代码基础上扩展实现 ARP 请求解析和响应的代码示例。
|
||||
|
||||
#### **(1) 定义 ARP 数据包结构和处理函数**
|
||||
|
||||
在文件顶部增加 ARP 相关的定义和函数：
|
||||
```c
|
||||
#include <stdint.h>
|
||||
#include <string.h>
|
||||
|
||||
// 定义 ARP 包结构
|
||||
typedef struct arp_packet {
|
||||
uint16_t hardware_type;
|
||||
uint16_t protocol_type;
|
||||
uint8_t hardware_len;
|
||||
uint8_t protocol_len;
|
||||
uint16_t opcode;
|
||||
uint8_t sender_mac[6];
|
||||
uint8_t sender_ip[4];
|
||||
uint8_t target_mac[6];
|
||||
uint8_t target_ip[4];
|
||||
} arp_packet_t;
|
||||
|
||||
// 解析 ARP 请求
|
||||
int parse_arp_request(const uint8_t *buf, arp_packet_t *arp_req) {
|
||||
memcpy(arp_req, buf + 14, sizeof(arp_packet_t)); // 跳过以太网头部
|
||||
return ntohs(arp_req->opcode) == 1; // 返回是否为 ARP 请求
|
||||
}
|
||||
|
||||
// 生成 ARP 响应
|
||||
void create_arp_response(const arp_packet_t *arp_req, uint8_t *buf) {
|
||||
memset(buf, 0, 42); // 清空响应缓冲区
|
||||
|
||||
// 填充以太网头部
|
||||
memcpy(buf, arp_req->sender_mac, 6); // 目标 MAC 地址（原请求的发送方）
|
||||
uint8_t mac[6] = {0xDE, 0xAD, 0xBE, 0xEF, 0x00, 0x01}; // 响应方 MAC
|
||||
memcpy(buf + 6, mac, 6); // 源 MAC 地址
|
||||
buf[12] = 0x08; buf[13] = 0x06; // ARP 协议类型 (0x0806)
|
||||
|
||||
// 填充 ARP 数据包部分
|
||||
arp_packet_t *arp_resp = (arp_packet_t *)(buf + 14);
|
||||
arp_resp->hardware_type = htons(1); // 硬件类型 (Ethernet)
|
||||
arp_resp->protocol_type = htons(0x0800); // 协议类型 (IPv4)
|
||||
arp_resp->hardware_len = 6;
|
||||
arp_resp->protocol_len = 4;
|
||||
arp_resp->opcode = htons(2); // ARP 响应
|
||||
memcpy(arp_resp->sender_mac, mac, 6); // 响应方 MAC
|
||||
memcpy(arp_resp->sender_ip, arp_req->target_ip, 4); // 响应方 IP
|
||||
memcpy(arp_resp->target_mac, arp_req->sender_mac, 6); // 请求方 MAC
|
||||
memcpy(arp_resp->target_ip, arp_req->sender_ip, 4); // 请求方 IP
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### **(2) 修改 `main` 函数，添加 ARP 处理逻辑**
|
||||
|
||||
在 `main` 函数的 `while` 循环中扩展读取和处理逻辑：
|
||||
```c
|
||||
uint8_t buf[BUF_LEN];
|
||||
uint8_t response_buf[BUF_LEN]; // 用于存储响应数据
|
||||
arp_packet_t arp_req;
|
||||
|
||||
while (running) {
|
||||
int nread;
|
||||
if ((nread = read(tun_fd, buf, BUF_LEN)) < 0) {
|
||||
perror("ERR: Read from tun_fd");
|
||||
break;
|
||||
}
|
||||
|
||||
printf("Read %d bytes from device %s\n", nread, dev);
|
||||
|
||||
// 检查是否为 ARP 包
|
||||
if (nread >= 42 && buf[12] == 0x08 && buf[13] == 0x06) {
|
||||
printf("ARP packet detected\n");
|
||||
|
||||
// 解析 ARP 请求
|
||||
if (parse_arp_request(buf, &arp_req)) {
|
||||
printf("Processing ARP request from %d.%d.%d.%d\n",
|
||||
arp_req.sender_ip[0], arp_req.sender_ip[1],
|
||||
arp_req.sender_ip[2], arp_req.sender_ip[3]);
|
||||
|
||||
// 生成 ARP 响应
|
||||
create_arp_response(&arp_req, response_buf);
|
||||
|
||||
// 发送 ARP 响应
|
||||
if (write(tun_fd, response_buf, 42) < 0) {
|
||||
perror("ERR: Write to tun_fd");
|
||||
} else {
|
||||
printf("Sent ARP response\n");
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### **功能验证**
|
||||
1. **启动 `tuntap.c` 程序**：
|
||||
```bash
|
||||
sudo ./tuntap mytap0
|
||||
```
|
||||
|
||||
2. **使用 `arping` 测试**：
|
||||
在另一台主机上运行以下命令：
|
||||
```bash
|
||||
arping -I mytap0 <tap0 对应的 IP 地址>
|
||||
```
|
||||
程序应打印检测到 ARP 请求，并生成和发送 ARP 响应。
|
||||
|
||||
---
|
||||
|
||||
### **总结**
|
||||
- 第二问通过定义 `arp_packet_t` 数据结构和解析/生成函数，设计了一个合适的接口。
|
||||
- 第三问通过扩展 `tuntap.c` 文件，增加了 ARP 请求处理和响应功能。
|
||||
- 使用 `arping` 工具可以测试实现的正确性。
|
||||
805
Blatt02/Notes.md
Normal file
805
Blatt02/Notes.md
Normal file
@@ -0,0 +1,805 @@
|
||||
|
||||
|
||||
[toc]
|
||||
|
||||
## 2.1 Bitübertragungsschicht (OSI-Schicht 1) 物理层（OSI模型第1层）
|
||||
|
||||
Bei jeder Interaktion zwischen zwei Rechnern müssen die Daten früher oder später eine physische Distanz überbrücken. Die binären Daten eines Rechners werden für den physischen Transport aufbereitet und anschließend über ein Medium an einen anderen Rechner übertragen. Kann der andere Rechner aus dem Empfangenen die ursprünglichen Daten rekonstruieren, ist es gelungen, binäre Daten von einem Rechner an einen anderen zu übertragen.
|
||||
在两个计算机之间的每次交互中，数据迟早必须跨越物理距离。一个计算机的二进制数据会被处理以便于物理传输，然后通过某种媒介传输到另一台计算机。如果接收方计算机能够从接收到的信号中重构出原始数据，那么数据已成功地从一个计算机传输到另一个计算机。
|
||||
|
||||
Protokolle der Bitübertragungsschicht beschäftigen sich mit genau diesem Problem. Sie legen fest, welches **Medium** benutzt wird und wie binäre Daten (Bits) als Signale auf das physische Medium moduliert werden. Dazu gehören mehrere Aspekted, die sicherstellen, dass alle Endpunkte auf die gleiche Art und Weise Daten übermitteln und interpretieren. Diese Aspekte lassen sich in vier Gruppen unterteilen:
|
||||
物理层协议正是解决这个问题的。它们规定了使用哪种媒介，以及如何将二进制数据（比特）作为信号调制到物理媒介上。这涉及多个方面，以确保所有终端以相同的方式传输和解释数据。这些方面可以分为四组。
|
||||
|
||||
**Physikalische** Aspekte umfassen Eigenschaften des Mediums und der verwendeten Signale.
|
||||
**物理**方面包括媒介的特性和所使用的信号。
|
||||
|
||||
**Mechanische** Eigenschaften spezifizieren u.A. die Bauform der Anschlüsse an das Medium.
|
||||
**机械**方面指定了与媒介连接的接口的结构形式。
|
||||
|
||||
**Funktionale** Spezifikationen definieren die Benutzung des Mediums, z.B. Pin-Belegung und Takt.
|
||||
**功能性**规范定义了媒介的使用方式，例如引脚分配和时钟。
|
||||
|
||||
**Prozedurale** Beschreibungen enthalten Elementarereignisse und deren Bedeutung, z.B. den genauen Ablauf zur Übertragung einer SDU.
|
||||
**过程性**描述包括基本事件及其含义，例如传输一个 [SDU](#SDU) 的确切流程。
|
||||
|
||||
Heute handelt es sich bei dem Medium meist um Kupfer, Lichtwellenleiter oder "Luft". Die Signale werden in der Regel so gewählt, dass sie deutlich voneinander unterscheidbar sind, da Signale durch Störeinflüsse leicht verfälscht werden können. Eine SDU auf Schicht 1 muss nicht genau ein Bit sein. Ein Schicht 1 Protokoll kann auch die parallele Übertragung von mehreren Bits gleichzeitig spezifizieren.
|
||||
如今，媒介通常是铜线、光导纤维或“空气”。信号通常被设计为明显不同，以便于区分，因为信号容易受到干扰的影响而失真。在第 1 层上，一个 SDU 不一定对应于一个比特。第 1 层协议还可以指定多个比特的并行传输。
|
||||
|
||||
Durch äußere Störeinflüsse können Amplitude, Frequenz und Phase eines Signals bei der Übertragung verändert werden. Komponenten der Schicht 1 verarbeiten Signale dahingehend, dass eingehende Signale als Signalzustände entsprechend der Spezifikation aufgefasst werden (Diskretisierung). Die Umwandlung in Bits ist ein weiterer Arbeitsschritt, der in der Regel nur von Komponenten, die auch eine Schicht 2 implementieren, durchgeführt werden muss. Gängige Schicht 1 Komponenten sind Repeater, Multiport-Repeater (Hubs) und Wavelength Division Multiplexer (WDMs).
|
||||
外部干扰可能会改变信号在传输过程中的幅度、频率和相位。第 1 层的组件处理信号的方式是将接收到的信号解释为符合规格的信号状态（离散化）。将信号转换为比特是另一个工作步骤，通常只有那些同时实现第 2 层的组件才需要完成此步骤。常见的第 1 层组件包括中继器、多端口中继器（集线器）和波分复用器（WDMs）。
|
||||
|
||||
|
||||
|
||||
### 2.1.1 Repeater und Hubs 中继器和集线器
|
||||
|
||||
Ein Repeater verfügt über genau zwei Anschlüsse. Ein eingehendes Signal auf einem Anschluss wird verstärkt auf dem anderen Anschluss ausgegeben. Repeater können eingesetzt werden, um das Problem der Dämpfung zu überwinden und Signale über längere Distanzen zu übertragen, als es die Sendeleistung des ursprünglichen Senders erlaubt. Die logische Weiterentwicklung des Repeaters ist der Hub. Dieser verfügt über mehrere Anschlüsse und gibt ein eingehendes Signal an allen anderen Anschlüssen verstärkt wieder aus.
|
||||
中继器（Repeater）通常有两个接口。当一个接口收到信号时，信号会被增强并从另一个接口输出。中继器可以用来解决信号衰减的问题，使信号传输距离超过原始发送器的功率限制。中继器的进一步发展就是集线器（Hub）。集线器具有多个接口，能够将一个接口接收到的信号增强后发送到所有其他接口。
|
||||
|
||||
|
||||
|
||||
### 2.1.2 Wavelength Division Multiplexer 波分复用器
|
||||
|
||||
Implementieren optische Sendestationen das selbe Schicht 1 Protokoll, so verwenden sie meist die selben Wellenlängen zur Signalisierung. Treffen diese Signale in einem gemeinsamen Medium aufeinander, entstehen Überlagerungen (Kollisionen), so dass kein Empfänger die ursprünglichen Daten rekonstruieren kann. Bei einem Aufbau, in dem mehrere Sender Signale auf dem selben Medium versenden, so dass Kollisionen entstehen können, spricht man von einer Kollisionsdomäne.
|
||||
在光学发送站中，若使用相同的第一层协议，通常会使用相同的波长进行信号传输。当这些信号在同一媒介中相遇时，就会产生叠加（碰撞），导致接收端无法还原原始数据。若在同一媒介上多个发送端同时发送信号，造成碰撞的可能性，这种结构被称为碰撞域。
|
||||
|
||||
WDMs bilden mehrere eingehende optische Signale auf unterschiedliche, disjunkte Bereiche des Farbspektrums (Kanäle) einer ausgehenden Leitung ab (Multiplex). Dadurch können alle eingehenden Signale gleichzeitig über eine einzelne ausgehende Leitung übertragen werden, ohne Kollisionen zu erzeugen. Abbildung 2.1 zeigt einen WDM, der drei eingehende Signale A, B und C auf eine ausgehende Leitung moduliert. Diese Technik setzt man häufig ein, wenn der Aufwand zusätzliche Leitungen zu verlegen hoch ist. In Abbildung 2.1 sind A, B und C optische Signale der selben Schicht 1 Implementierung (z.B. 1 Gbps Ethernet, Monomode) und verwenden deshalb die selbe Wellenlänge für die Datenübertragung. Im WDM werden die Wellenlängen der eingehenden Signale modifiziert, so dass keine Überlagerung mehr stattfindet wenn die Signale in der ausgehenden Leitung aufeinander treffen.
|
||||
波分复用器（WDMs）将多个入射光信号映射到不同的、互不重叠的色谱范围（通道）上，通过一条输出线路（复用）。所有传入的信号可以同时通过一条输出线路传输，而不会产生碰撞。图 2.1 显示了一个波分复用器（WDM），它将三个输入信号 A、B 和 C 调制到一条输出线路上。当增加额外线路的成本很高时，通常会使用这种技术。图 2.1 中的 A、B 和 C 是相同的第 1 层实现的光信号（例如 1 Gbps 以太网，单模），因此使用相同的波长进行数据传输。在 WDM 中，输入信号的波长会被调整，以避免当信号进入输出线路时产生重叠。
|
||||
|
||||
Am anderen Ende der Leitung empfängt ein Demultiplexer das zusammengesetzte Signal. Dieser trennt das empfangene Signal auf, moduliert die Teilsignale zurück auf ihre ursprüngliche Form und sendet die Signale auf separaten Leitungen weiter.
|
||||
在线路的另一端，一个解复用器接收组合信号。该设备将接收到的信号分离，将每个子信号调制回其原始形式，并通过独立的线路发送这些信号。
|
||||
|
||||
## 2.2 Sicherungsschicht (OSI-Schicht 2) 数据链路层（OSI模型第 2 层）
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zu den Hauptaufgaben der Sicherungsschicht gehört Rahmenbildung (bzw. Blockbildung). Darunter versteht man die Gruppierung von Bits zu logischen Einheiten, den PDUs der Schicht 2 (Rahmen oder Blöcke, bzw. engl. frames oder blocks). Eine Basiskomponente der Schicht 2 ist die Bridge (bzw. “Brücke”). Eine Bridge ist eine Schicht 2 Komponente, die zwei Teilnetze (mit möglicherweise verschiedenen Übertragungstechniken) miteinander verbindet, also eine Brücke dazwischen bildet. Dazu muss sie eingehende Signale interpretieren und zu Rahmen zusammensetzen. Erst der vollständige Rahmen wird in das andere Teilnetz übertragen. Diese Technik heißt “store and forward”, da die Bridge eingehende Daten (Bits) speichert (store), bis der Rahmen vollständig empfangen wurde und erst im Anschluss daran den Rahmen weiterleitet (forward). Eine Bridge mit mehr als zwei Anschlüssen heißt Switch oder Multiport-Bridge.
|
||||
数据链路层的主要任务之一是帧构建（或称块构建），即将比特分组为逻辑单元，即第 2 层的 PDU（帧或块）。第 2 层的基本组件之一是桥接器（Bridge）。桥接器是第 2 层组件，它连接两个子网（可能使用不同的传输技术），因此在它们之间形成了一个桥。为此，它必须解释接收到的信号并将其组装成帧。只有完整的帧才会被传输到另一个子网。这种技术被称为“存储和转发”（store and forward），因为桥接器会先存储（store）接收到的数据（比特），直到帧完全接收后才转发（forward）该帧。具有两个以上端口的桥接器被称为交换机（Switch）或多端口桥（Multiport-Bridge）。
|
||||
|
||||
### 2.2.1 Vergleich von Komponenten der Schichten 1 und 2 2.2.1 第 1 层和第 2 层组件的比较
|
||||
|
||||
Aufgrund der Hauptaufgaben der Schichten 1 und 2 ergeben sich unterscheidende Merkmale der Komponenten dieser Schichten: Repeater, Hubs, WDM etc. auf der Schicht 1, Bridges und Switches auf der Schicht 2.
|
||||
根据第 1 层和第 2 层的主要任务，这两层的组件特点有所不同：第 1 层包括中继器、集线器、波分复用器（WDM）等，第 2 层则包括桥接器和交换机。
|
||||
|
||||
Im Gegensatz zu einem WDM verarbeitet eine Bridge nicht einzelne eingehende Signale, sondern eingehende Rahmen. Die Bridge muss demnach in der Lage sein aus gespeicherten Informationen Rahmen zu bilden. Der Einsatz von store and forward ermöglicht es der Bridge unterschiedliche Bitübertragungstechniken für die beiden LANs zu verwenden, wogegen die Anschlüsse eines WDM den Festlegungen der physikalischen Signale entsprechen. Der Aufbau in Abbildung 2.2 erlaubt es unterschiedliche Schicht 1 Implementierungen “links” und “rechts” der Bridge zu nutzen.
|
||||
|
||||
与波分复用器（WDM）不同，桥接器不会处理单个输入信号，而是处理输入的帧。因此，桥接器必须能够根据存储的信息构建帧。通过存储和转发（store and forward）技术，桥接器可以为两个局域网使用不同的比特传输技术，而 WDM 的接口则对应物理信号的规定。图 2.2 的结构允许桥接器左右两侧使用不同的第 1 层实现.
|
||||
|
||||
### 2.2.2 Topologien 拓扑结构
|
||||
|
||||
Neben der Rahmenbildung spezifizieren Schicht 2 Protokolle auch die Übertragung von Rahmen. Dazu gehören Vielfachzugriffsverfahren, die den Zugriff auf Schicht 1 bzw. auf gemeinsam genutzte Medien steuern, sowie die Übertragung von Rahmen zu Schicht 2 Endpunkten. Durch die vielfältigen Komponenten und Funktionen der Schichten 1 und 2 ergeben sich verschiedene Möglichkeiten einen physischen Aufbau eines Netzes (LAN) zu realisieren.
|
||||
除了帧构建，第 2 层协议还定义了帧的传输方式。这包括控制对第 1 层或共享媒介的访问的多重访问协议，以及向第 2 层终端传输帧的方式。由于第 1 层和第 2 层组件和功能的多样性，局域网（LAN）的物理构建有多种实现方式。
|
||||
|
||||
Abbildung 2.2 zeigt auf jeder Seite der Bridge ein Netz mit Bustopologie. Dabei sind mehrere Schicht 2 Endpunkte mit einem gemeinsam genutzten Medium verbunden. Ein Problem der Bustopologie ist die aufwändige Wartung. Tritt ein Hardwaredefekt auf, so kommt meistens das gesamte LAN zum Erliegen. Das Aufspüren der defekten Hardware ist schwierig, da jede Komponente für das Problem verantwortlich sein könnte. Das gemeinsam genutzte Kabel erstreckt sich meist über mehrere Räume oder auch Stockwerke und ist sehr aufwändig auszutauschen.
|
||||
图 2.2 显示了桥接器两侧的总线拓扑网络。在这种拓扑结构中，多个第 2 层终端连接到一个共享媒介上。总线拓扑的一个问题是维护难度较大。一旦出现硬件故障，通常会导致整个局域网瘫痪。因为每个组件都可能是问题的根源，所以定位故障硬件相当困难。共享电缆通常跨越多个房间或楼层，更换非常耗时。
|
||||
|
||||
Eine andere Topologie, die bei diesem Problem hilft, ist die Sterntopologie. An die Stelle des gemeinsam genutzten Mediums tritt ein zentraler Hub (vgl. Abbildung 2.3). Da der Hub eingehende Signale auf alle angeschlossene Kabel repliziert, verhält sich ein Netz mit Sterntopologie genauso wie ein Netz mit Bustopologie; der Charakter des gemeinsam genutzten Mediums bleibt für die Signalübertragung erhalten. Deshalb kann an jeden Anschluss eines Hubs ein ganzes Teilnetz mit Bustopologie angeschlossen werden.
|
||||
另一种可以解决该问题的拓扑结构是星型拓扑。星型拓扑中使用一个中央集线器（参见图 2.3）代替共享介质。由于集线器会将接收到的信号复制到所有连接的电缆上，因此星型拓扑网络的行为类似于总线拓扑网络；信号传输仍然保持共享介质的特性。因此，可以在集线器的每个端口连接一个具有总线拓扑的子网。
|
||||
|
||||
Der Vorteil des Hubs liegt darin, dass ein defektes Kabel an einem Anschluss nicht automatisch zu einem Zusammenbruch des gesamten Netzes führt. Außerdem kann an zentraler Stelle das fehlerhafte Kabel ermittelt werden. Üblicherweise ist an jeder Leitung eines Hubs ein einzelner Rechner angeschlossen, wodurch die Fehlerlokalisierung weiter vereinfacht wird. Der Defekt eines Kabels trennt so lediglich eine einzige Leitung (bzw. einen einzelnen Rechner) vom LAN, anstatt das gesamte LAN zum Erliegen zu bringen. Fällt der Hub aus, kann dieser leichter ausgetauscht werden, als ein Kabel, das durch mehrere Räume und Stockwerke verlegt wurde. Ersetzt man den Hub durch einen Switch, kann der Datenverkehr mit Bezug auf die Eigenschaften von Rahmen (Header) gesteuert werden. Ein Switch kann durch die Interpretation der eingehenden Informationen entscheiden eingehende Rahmen über wenige bestimmte Leitungen weitergeben, anstatt den Rahmen auf jedem Port zu replizieren.
|
||||
集线器的优点在于，连接处的电缆故障不会导致整个网络崩溃。此外，可以在中心位置轻松找到故障电缆。通常，每条连接集线器的电缆只连接一个计算机，这样可以进一步简化故障定位。电缆的故障只会切断该电缆所连接的单个设备与局域网的连接，而不会影响整个网络。即使集线器出现故障，其更换也比更换穿越多个房间或楼层的电缆更为简单。如果将集线器替换为交换机，交换机可以根据帧的特性（如头信息）来管理数据流。交换机可以通过解析接收到的信息，将数据帧仅发送到特定的端口，而不是向每个端口复制帧。
|
||||
|
||||
## 2.3 Ethernet
|
||||
|
||||
Infolge der wachsenden Bedeutung der lokalen Vernetzung von Arbeitsplatzrechnern wurden zwischen 1972 und 1976 am Xerox Palo Alto Research Centre die technologischen Grundlagen für ein gleichermaßen leistungsfähiges und “idiotensicheres” Local Area Network geschaffen. Dieses neue Local Area Network nannte man Ethernet, in Anspielung auf jenen geheimnisvollen “Lichtwellenaether”, welchen die Physiker des 19. Jahrhunderts so verzweifelt gesucht haben. Heute wird Ethernet formal als IEEE-Standard 802.3, CSMA/CD: Protokoll und physische Übertragungstechniken [IEEE 802.3], verwaltet und weiterentwickelt.
|
||||
由于工作站计算机本地网络的重要性日益增加，在 1972 年至 1976 年间，施乐公司帕洛阿尔托研究中心开发了高效且“防呆”的局域网技术基础。这种新型局域网被称为以太网（Ethernet），以纪念 19 世纪物理学家们苦苦追寻的“光以太”。如今，以太网已正式被定义为 IEEE 标准 802.3，它管理并发展了 CSMA/CD 协议和物理传输技术 [IEEE 802.3]。
|
||||
|
||||
|
||||
|
||||
Ethernet basiert in seiner ursprünglichen Form auf einer Broadcast-Technik, bei der alle Komponenten an das selbe Medium angeschlossen sind, wie in Abbildung 2.4 dargestellt. Sendet eine Komponente Daten, so werden diese von jeder anderen Komponente empfangen. Senden mehrere Komponenten gleichzeitig, entsteht eine Datenkollision, so dass letztendlich keine Daten übertragen werden können. Bei einer Kollision treffen die Signale im Medium aufeinander, wodurch Interferenzen entstehen, so dass die ursprünglichen Signale nicht mehr unterscheidbar sind (siehe Kapitel 2.1). Aus diesem Grund benutzt Ethernet CSMA/CD, ein Verfahren um die Nutzung des gemeinsamen Mediums zu koordinieren. Die meisten heutigen Ethernet-Netze sind Sterntopologien, bei denen jeder Endpunkt (z.B. Rechner) exklusiv mit einem Switch-Port verbunden ist.
|
||||
|
||||
以太网在其最初的形式中基于广播技术，所有组件连接到相同的媒介，如图 2.4 所示。当一个组件发送数据时，其他所有组件都能接收到。如果多个组件同时发送，则会发生数据碰撞，导致数据无法传输。在碰撞中，信号在介质中相互干扰，原始信号无法区分（参见章节 2.1）。因此，以太网使用 CSMA/CD 协议来协调共享介质的使用。大多数现代以太网网络使用星型拓扑结构，每个终端（如计算机）独立连接到一个交换机端口。
|
||||
|
||||
## 2.4 Virtuelle Topologien 虚拟拓扑
|
||||
|
||||
Endeinrichtungen (Rechner) werden in der Praxis bestimmten Aufgaben oder Rollen einer Organisation zugeordnet, statt den Gegebenheiten der Vernetzung: Es ist z.B. wünschenswert, die Rechner nach Abteilungen bzw. Bereichen zu gruppieren. Oft entspricht dabei die physische Topologie, die durch die verlegten Medien (“Kabel”) gegeben ist, nicht den Nutzungsanforderungen eines LANs: z.B. werden Server in gemeinsam genutzten Server-Räumen untergebracht, in denen sich alle Server die selbe Leitung aus dem Raum hinaus teilen. Meist ist es jedoch so, dass sensible Daten nicht in andere LANs als dem abteilungseigenen LAN gelangen dürfen.
|
||||
|
||||
在实践中，终端设备（计算机）通常根据组织的特定任务或角色进行分配，而不是根据网络连接的物理位置。例如，最好按部门或区域对计算机进行分组。通常，物理拓扑（由布设的介质“电缆”决定）并不符合 LAN 的实际使用需求：例如，服务器被安置在共享的服务器房间中，在该房间内所有服务器共用一条对外连接的线路。然而，通常情况下，敏感数据不应流出部门专用的 LAN。
|
||||
|
||||
Hierzu können sogenannte virtuelle LANs (VLAN) benutzt werden, die eine logische LAN-Topologie auf eine physische aufbringen. VLANs können auf mehrere Arten erzeugt werden: durch die Gruppierung von Ports an einem Switch, durch Gruppierung von MAC-Adressen der zu einer Gruppe gehörenden Rechner und durch eine entsprechende Markierungen (engl. tagging) der gesendeten Rahmen. Im Praktikum liegt dabei der Schwerpunkt auf der zuletzt genannten Technik.
|
||||
|
||||
为此，可以使用所谓的虚拟局域网（VLAN），将逻辑局域网拓扑应用于物理局域网。 创建 VLAN 有几种方法：将交换机上的端口分组、将属于一个组的计算机的 MAC 地址分组以及对发送的帧进行标记。 在实践课程中，重点是后一种技术。
|
||||
|
||||
Ein wichtiger Standard in diesem Kontext ist der IEEE-Standard 802.1q [IEEE 802.1q], “Virtual LANs”. Dieser definiert das Anlegen, Betreiben und Verwalten von (mehreren) virtuellen LAN-Topologien innerhalb eines physischen LANs. Dazu wird jeder Rahmen einer virtuellen Infrastruktur mit einer für diese Infrastruktur eindeutigen Nummer (VLAN Identifier, VLAN-ID) in einem Feld (VLAN-Tag) im Ethernet-Header markiert. Netzkomponenten, die auf Schicht 2 operieren, können anhand der VLAN-ID Rahmen virtueller Topologien unterscheiden und unterschiedlich behandeln.
|
||||
|
||||
在此背景下，一个重要的标准是 IEEE 标准 802.1q [IEEE 802.1q]，即“虚拟 LAN”。该标准定义了在一个物理 LAN 内创建、操作和管理（多个）虚拟 LAN 拓扑的方法。为此，每个帧在以太网头部的一个字段中用一个唯一的编号（VLAN 标识符，VLAN-ID）进行标记。工作在第 2 层的网络组件可以根据 VLAN-ID 区分和不同处理虚拟拓扑中的帧。
|
||||
|
||||
### 2.4.1 Monitoring-Port Konzept 监控端口概念
|
||||
|
||||
Administrierbare Switches bieten meist die Funktion eines Monitoring-Ports. Dabei wird ein bestimmter Port des Switches ausgewählt, auf dem der Switch jeden Rahmen repliziert, der auf einem der anderen Switch-Ports empfangen wird. Diese Funktion ermöglicht es, jeden Rahmen, der vom Switch verarbeitet wird, an zentraler Stelle zu sammeln. Da die Übertragungsrate eines Monitoring-Ports meist deutlich kleiner ist als die aller anderen Ports zusammen, kann ein Monitoring-Port ab einer gewissen Auslastung nicht alle Rahmen replizieren. Aus diesem Grund werden Monitoring-Ports häufig nur zur Fehleranalyse eingesetzt. Das Konzept des Monitoring-Ports kann auch virtualisiert umgesetzt werden.
|
||||
可管理的交换机通常提供监控端口的功能。通过该功能，可以选择交换机上的一个特定端口，该端口将会复制交换机在其他端口接收到的每个数据帧。这项功能使得可以在中央位置收集交换机处理的每个数据帧。由于监控端口的传输速率通常明显低于其他所有端口的总和，当负载达到一定程度时，监控端口可能无法复制所有的数据帧。因此，监控端口通常仅用于故障分析。监控端口的概念也可以虚拟化实现。
|
||||
|
||||
|
||||
|
||||
Abbildung 2.5 zeigt ein Beispiel in dem die Rechner rnpserver und rnpclient über (rnpserver-eth1, S01-A-4) und (S01-D-2, rnpclient-eth1) verbunden sind. Außerdem ist der Rechner rnpmgmt mit dem Switch S01 verbunden. Wird der Switch-Port S01-B-4 als Management-Port konfiguriert, so empfängt der Rechner rnpmgmt an seiner Schnittstelle eth1 alle Rahmen, die rnpserver und rnpclient austauschen. Dies ermöglicht es die Interaktion dieser beiden Rechner zu überwachen, ohne direkten Zugang zu haben.
|
||||
|
||||
图 2.5 显示了一个示例，其中计算机 rnpserver 和 rnpclient 分别通过 (rnpserver-eth1, S01-A-4) 和 (S01-D-2, rnpclient-eth1) 连接。此外，计算机 rnpmgmt 连接到交换机 S01。如果将 S01-B-4 端口配置为管理端口，则计算机 rnpmgmt 会在其接口 eth1 上接收到 rnpserver 和 rnpclient 之间交换的所有数据帧。这使得可以在不直接访问的情况下监控这两台计算机的交互。
|
||||
|
||||
Das Einrichten eines Management-Ports ist eine spezielle Funktion, die von der Konfigurationssoftware der Switches bereitgestellt wird.
|
||||
配置管理端口是一项特殊功能，由交换机的配置软件提供。
|
||||
|
||||
## 2.5 TUN/TAP Devices TUN/TAP 设备
|
||||
|
||||
Linux bietet seit Kernel-Version 2.2 die Möglichkeit virtueller Treiber-Schnittstellen an, sogenannte TUN/TAP Devices. TUN/TAP Devices existieren nur im Kernel und haben im Vergleich zu gewöhnlichen Schnittstellen keine physische Komponente. Falls das Betriebssystem Daten an ein TUN/TAP Device sendet, wird die Nachricht nicht an das physische Device, sondern an eine Benutzeranwendung, die über ein File-Descriptor mit dem TUN/TAP Device verbunden ist, weitergegeben. Was dann tatsächlich mit den Daten passiert, bleibt der Anwendung überlassen. Ein typisches Einsatzgebiet ist Tunneling, wie es beispielsweise in Virtual Private Networks (VPNs) der Fall ist. Durch den Einsatz von TUN Devices empfängt die VPN-Anwendung alle IP-Pakete, verschlüsselt deren Payload und umrahmt das ursprüngliche IP-Paket in ein weiteres IP-Paket mit aktualisierten Header-Informationen. Der Unterschied zwischen TUN und TAP Interfaces liegt darin, dass TAP Devices auf Schicht 2 und TUN Devices auf Schicht 3 operieren. Diese Unterscheidung ist wichtig, denn je nach Anwendungsfall ergeben sich entsprechende Anforderungen. Für VPN-Anwendungen bspw. sind TUN Devices auf Schicht 3 ausreichend. Eine ausführliche Dokumentation findet sich in der Linux-Kernel Dokumentation.
|
||||
自 Linux 内核版本 2.2 起，提供了虚拟驱动接口的功能，即所谓的 TUN/TAP 设备。TUN/TAP 设备仅存在于内核中，与普通接口相比没有物理组件。如果操作系统将数据发送到 TUN/TAP 设备，该消息不会被传送到物理设备，而是传递给通过文件描述符与 TUN/TAP 设备连接的用户应用程序。之后数据的实际处理由应用程序决定。TUN/TAP 设备的一个典型应用领域是隧道技术，例如在虚拟专用网络 (VPN) 中。通过使用 TUN 设备，VPN 应用程序可以接收所有的 IP 数据包，加密其有效负载，并将原始 IP 包封装到一个新的 IP 包中，且附上更新的头信息。TUN 和 TAP 接口的区别在于，TAP 设备工作在第 2 层，而 TUN 设备工作在第 3 层。这个区别很重要，因为不同的应用场景有不同的需求。例如，对于 VPN 应用来说，TUN 设备在第 3 层就足够了。详细的文档可以在 Linux 内核文档中找到。
|
||||
|
||||
Im Rahmen dieses Praktikums setzen wir TUN/TAP Devices dazu ein, um unseren eigenen Netzwerk-Stack zu implementieren. Ein einfaches Beispiel findet sich in der beigelegten Mini-Anwendung. Bevor ein TUN/TAP Device genutzt werden kann, erzeugen wir zunächst ein virtuelles Device. Hierzu nutzen wir das allseits bekannte Tool iproute (ip).
|
||||
在本次实习中，我们将使用 TUN/TAP 设备来实现自己的网络栈。一个简单的示例可以在附带的 Mini 应用中找到。在使用 TUN/TAP 设备之前，我们首先创建一个虚拟设备。为此，我们使用常用的 iproute 工具（ip）。
|
||||
|
||||
```bash
|
||||
$ ip tuntap help
|
||||
Usage: ip tuntap { add | del } [ dev PHYS_DEV ]
|
||||
[ mode { tun | tap } ] [ user USER | group GROUP ]
|
||||
[ one_queue ] [ pi ] [ vnet_hdr ]
|
||||
Where: USER := { STRING | NUMBER }
|
||||
GROUP := { STRING | NUMBER }
|
||||
```
|
||||
|
||||
Nachdem ein physisches Device erzeugt wurde, setzen wir das Device zunächst auf den Status up und geben ihm anschließend ein Netz bzw. eine fixe Host-Adresse. Mit der richtigen Konfiguration wird jeglicher Datenverkehr durch das das TUN/TAP Device geleitet.
|
||||
创建物理设备后，我们首先将设备设置为 up 状态，然后为其分配一个网络或固定的主机地址。通过正确的配置，所有的数据流都将通过 TUN/TAP 设备。
|
||||
|
||||
### 2.5.1 Virtuelle Schnittstellen unter Linux
|
||||
|
||||
|
||||
|
||||
Allgemein kann man sagen: Virtualisierung ist die Abstraktion von starren, beschränkenden Randbedingungen eines Systems zu konfigurierbaren Eigenschaften. Im Fall von virtuellen Schnittstellen bedeutet Virtualisierung, dass man die Anzahl der Schnittstellen eines Rechners verändern kann. Freilich lassen sich dadurch nicht mehr Kabel mit einem Rechner verbinden als physische Schnittstellen vorhanden sind. Trotzdem erhöhen sich die Möglichkeiten im Management.
|
||||
一般而言，虚拟化是将系统的固定、受限条件抽象成可配置的特性。在虚拟接口的情况下，虚拟化意味着可以更改计算机的接口数量。尽管如此，通过虚拟化并不能增加与计算机连接的实际电缆数量，只能使用物理接口。然而，这样可以增加管理方面的灵活性。
|
||||
|
||||
Im Rahmen dieses Praktikums bieten virtuelle Schnittstellen den Mehrwert, dass man über eine physische Verbindung mehrere logische Verbindungen betreiben kann (vgl. Abbildung 2.6).
|
||||
在这个实践中，虚拟接口的优势在于可以通过一个物理连接运行多个逻辑连接（参见图2.6）。
|
||||
|
||||
Jeder virtuellen Schnittstelle kann außer eigenen IP-Adressen auch eine eigene VLAN-ID zugewiesen werden. Es ist somit möglich, mit nur einer physischen Verbindung einen Rechner in mehrere virtuelle LANs einzubinden.
|
||||
每个虚拟接口除了可以分配独立的IP地址外，还可以分配独立的VLAN ID。这使得仅通过一个物理连接就可以将计算机连接到多个虚拟局域网（VLAN）。
|
||||
|
||||
Es ist möglich einer einzelnen Schnittstelle mehrere IPs zuzuweisen und so einen Rechner in mehrere Subnets (z.B. 192.168.1/24 und 192.168.2/24) einzubinden. Der wesentliche Unterschied zum Einsatz virtueller Schnittstellen und VLANs liegt darin, dass virtuelle Schnittstellen bereits auf OSI-Schicht 2 implementiert werden, eine Trennung auf IP-Ebene jedoch eine Funktion von OSI-Schicht 3 ist.
|
||||
还可以给一个单独的接口分配多个IP地址，从而将计算机连接到多个子网（例如192.168.1/24和192.168.2/24）。虚拟接口和VLAN的主要区别在于虚拟接口在OSI模型的第2层实现，而IP层的隔离是OSI第3层的功能。
|
||||
|
||||
Anlegen virtueller Schnittstellen mit VLAN-ID:
|
||||
带VLAN ID的虚拟接口创建：
|
||||
|
||||
Das Anlegen von virtuellen Schnittstellen ist ebenfalls eine Funktion, die mit dem Befehl `ip` realisiert werden kann. Die Syntax zum Anlegen einer VLAN-Schnittstelle ist:
|
||||
可以通过`ip`命令创建虚拟接口。创建VLAN接口的命令语法为：
|
||||
|
||||
```
|
||||
# ip link add link <pNIC> name <vNIC> type vlan id <VLAN-ID>
|
||||
```
|
||||
mit
|
||||
其中
|
||||
|
||||
- `pNIC` := Name der physischen Schnittstelle
|
||||
`pNIC`：物理接口的名称
|
||||
- `vNIC` := Name der virtuellen Schnittstelle
|
||||
`vNIC`：虚拟接口的名称
|
||||
|
||||
z.B.:
|
||||
```
|
||||
# ip link add link eth0 name eth0.100 type vlan id 100
|
||||
```
|
||||
|
||||
Zum Entfernen einer virtuellen Schnittstelle benutzen Sie: 删除虚拟接口的命令：
|
||||
```
|
||||
# ip link del dev <vNIC>
|
||||
```
|
||||
z.B.: 例如：
|
||||
```
|
||||
# ip link del dev eth0.100
|
||||
```
|
||||
|
||||
## 2.6 Scapy
|
||||
|
||||
### 原文内容：
|
||||
|
||||
#### 图片 1:
|
||||
|
||||
**2.6 Scapy**
|
||||
|
||||
Scapy ist ein Python Framework zur Inspektion und Manipulation von Paketen. Es erlaubt Ihnen Pakete vieler bereits implementierter Protokolle zu protokollieren, zu dekodieren, aus pcap-Dateien zu lesen, zu erstellen sowie diese zu versenden und vieles mehr. Scapy wurde auch für schnelles Prototyping entwickelt und benutzt Defaultwerte, die funktionieren.
|
||||
Scapy 是一个用于数据包检查和操作的 Python 框架。它允许您记录、解码许多已实现协议的数据包，从 pcap 文件中读取或创建数据包并发送等。Scapy 还适用于快速原型设计，并使用默认值，保证基本功能可用。
|
||||
|
||||
Viele Aufgaben anderer Tools können von Scapy übernommen werden, z.B. Scanning, Traceroutes, Unit-Tests, Netzwerkerkennung und verschiedene Angriffe. Außerdem können Sie auch ungültige Rahmen versenden, eigene 802.11 Rahmen einbauen und verschiedene Techniken kombinieren (VLAN hopping + ARP cache poisoning, VoIP-Dekodierung auf einem WEP-verschlüsselten Kanal, etc.).
|
||||
许多其他工具的任务可以由 Scapy 完成，例如扫描、路由追踪、单元测试、网络检测和多种攻击。此外，您还可以发送无效的帧、创建自定义的 802.11 帧，并组合各种技术（如 VLAN 跳跃 + ARP 缓存中毒、在 WEP 加密的信道上解码 VoIP 数据包等）。
|
||||
|
||||
#### 2.6.1 Installation auf der Infrastruktur
|
||||
|
||||
`// On Debian`
|
||||
`apt-get install python3-scapy`
|
||||
|
||||
`// On OpenWRT`
|
||||
`opkg update; opkg install scapy`
|
||||
|
||||
#### 2.6.2 Usage
|
||||
|
||||
Eine kleine Übersicht:
|
||||
以下是简要概述：
|
||||
|
||||
- Verschiedene Protokolle und Header sind als Klassen implementiert, wie IPv6 oder ICMP.
|
||||
各种协议和头部作为类实现，例如 IPv6 或 ICMP。
|
||||
- Protokolle können ineinander geschachtelt werden mit dem Slash-Operator, z.B.: IPv6()/TCP() erstellt ein TCP-over-IPv6 Paket.
|
||||
可以使用斜杠操作符嵌套协议，例如 `IPv6()/TCP()` 创建一个 TCP-over-IPv6 包。
|
||||
- Pakete können mit den Methoden show und show2 angezeigt werden, für das Senden bzw. Senden und Empfangen siehe send(), sendp(), sr(), sr1() und srp().
|
||||
可以使用 `show` 和 `show2` 方法显示数据包；发送和接收请参考 `send()`、`sendp()`、`sr()`、`sr1()` 和 `srp()`。
|
||||
- Die meisten Headeroptionen können verändert werden. Setzen Sie diese entweder im Konstruktor oder über Membervariablen, z.B.: p = IP(ttl=64)
|
||||
大多数头选项可以更改。可以在构造函数中或通过成员变量设置这些选项，例如：`p = IP(ttl=64)`。
|
||||
- Nicht alle Optionen müssen angegeben werden, Scapy befüllt solche Werte mit Defaults.
|
||||
并非所有选项都必须指定，Scapy 会自动填充默认值。
|
||||
- Eine Liste aller Funktionen bekommen Sie über die Funktion ls().
|
||||
使用 `ls()` 函数可以查看所有功能列表。
|
||||
- Für weitere Informationen und eine Demonstration, siehe https://scapy.net/
|
||||
更多信息和演示，请访问 [https://scapy.net](https://scapy.net/)
|
||||
|
||||
## 2.7 Aufgaben
|
||||
|
||||
**Hinweis**: vergessen Sie nicht Ihre Konfiguration in Netzplänen zu dokumentieren und auch die relevanten Ausgaben der verwendeten Programme zu übernehmen!
|
||||
**提示**: 请不要忘记在网络图中记录您的配置，并包含所用程序的相关输出！
|
||||
|
||||
---
|
||||
|
||||
### A200 Address Resolution and Neighbor Discovery (Theorie)
|
||||
|
||||
Das RFC 826 definiert das Address Resolution Protocol (ARP). In RFC 4861 wird das Neighbor Discovery Protocol (NDP) spezifiziert.
|
||||
RFC 826 定义了地址解析协议（ARP）。RFC 4861 规定了邻居发现协议（NDP）。
|
||||
|
||||
1. **Wozu wird ARP eingesetzt? Was ist der Unterschied zu NDP?**
|
||||
**ARP 的用途是什么？它与 NDP 的区别是什么？**
|
||||
2. **Beschreiben Sie den Aufbau einer ARP-PDU und erläutern Sie die Bedeutung der einzelnen Felder!**
|
||||
**描述 ARP-PDU 的结构并解释各个字段的含义！**
|
||||
3. **Welche unterschiedlichen ARP-PDUs gibt es? Welche NDP-PDUs gibt es?**
|
||||
**有哪些不同的 ARP-PDU？NDP-PDU 又有哪些？**
|
||||
4. **Wie lang (in Bytes) ist eine ARP-PDU in einem Netz in dem IPv4 und Ethernet eingesetzt werden?**
|
||||
**在 IPv4 和以太网网络中，ARP-PDU 的长度是多少字节？**
|
||||
5. **Wie lang (in Bytes) ist eine Neighbor Solicitation Nachricht?**
|
||||
**Neighbor Solicitation 消息的长度是多少字节？**
|
||||
6. **Das RFC 826 spricht von einer Tabelle (table), deren Implementierung meist als ARP-Cache bezeichnet wird. Was soll laut RFC mit einer Ethernet-SDU passieren, wenn kein Eintrag zur Ziel-IP-Adresse in der Tabelle gefunden wird?**
|
||||
7. **RFC 826 提到了一张表（table），其实现通常称为 ARP 缓存。RFC 规定如果表中没有找到目标 IP 地址的条目，对以太网 SDU 应该怎么处理？**
|
||||
|
||||
### A201 VLANs nach IEEE 802.1q
|
||||
|
||||
Virtuelle Infrastrukturen dienen dazu Netze anzulegen und anzupassen zu können, ohne physisch an den Geräten arbeiten zu müssen. Dies ist insbesondere in großen, weniger übersichtlichen Infrastrukturen von Vorteil.
|
||||
虚拟基础设施的目的是在无需直接物理操作设备的情况下创建和调整网络配置。尤其在大型、结构不明确的基础设施中，这种方法具有优势。
|
||||
|
||||
Nachdem Sie in Aufgabe A101 die Topologie der virtuellen Infrastruktur vollständig rekonstruiert haben, ändern Sie diese im Folgenden.在您完成任务**A101**中虚拟基础设施拓扑的重建之后，按照以下步骤进行修改。
|
||||
|
||||
1. **Modifizieren Sie die Topologie Ihrer virtuellen Infrastruktur so, dass die Router 1,2 und 3 ausschließlich Switches (Bridges) sind. Fügen Sie dieser Bridge alle Interfaces bis auf eth0 hinzu. (Hinweis: Benutzen Sie `ip link`, siehe Referenz^3）**
|
||||
修改您的虚拟基础设施拓扑，使路由器 1、2 和 3 仅包含交换机（桥接器）。将所有接口（除了 eth0 以外）加入该桥接器。（提示：使用 `ip link`，参考文献^3）
|
||||
|
||||
Die PCs 1–3 sowie Router 4 sind Hosts, die in einem (Sub-)Netz gemäß der Baum-Topologie in Abbildung 2.7 verbunden sind. Es genügt hierbei, wenn Sie überflüssige Links als `down` markieren.
|
||||
PC1–3 和路由器 4 是主机，根据图 2.7 的树状拓扑结构连接在同一子网中。这里只需要将冗余的链路标记为 `down`。
|
||||
|
||||
|
||||
|
||||
2. **Testen Sie ihre Verbindungen zwischen den PCs 1–3 sowie Router 4 mittels `ping`。Router 1–3 haben per Definition von Bridges keine IP-Adresse. Vergeben Sie IPv4-Adressen aus Ihrem Adressraum。**
|
||||
通过 `ping` 命令测试 PC1–3 和路由器 4 之间的连接。根据桥接器的定义，路由器 1–3 不会有 IP 地址。请为它们分配 IPv4 地址。
|
||||
|
||||
3. **Derzeit befinden sich alle Hosts im selben Netz. In dieser Aufgabe soll das Netz in zwei logisch getrennte VLANs (Schicht 2) aufgeteilt werden. Ziel ist es, dass Router 4 und PC3 in einem VLAN sowie PC2 und PC1 in einem anderen VLAN voneinander isoliert sind。**
|
||||
当前，所有主机都在同一网络中。在本任务中，将网络划分为两个逻辑上独立的 VLAN（第二层）。目标是将路由器 4 和 PC3 放在一个 VLAN 中，将 PC2 和 PC1 放在另一个 VLAN 中，使它们彼此隔离。
|
||||
第三层地址将保持不变。预期的结果是仅在 VLAN 内可以进行通信。例如，路由器 4 只能与 PC3 通信，而无法与 PC1 和 PC2 通信，即便它们在第三层的同一子网中。
|
||||
|
||||
使用 `ping` 测试您的配置，并通过 `tcpdump`（在路由器 1–3 上）验证 ICMP 请求是否基于 VLAN ID 在 VLAN 内部进行通信。
|
||||
|
||||
|
||||
|
||||
### **A202 ARP 和 NDP 分析**
|
||||
|
||||
使用与上一个任务相同的拓扑结构。如果有 VLAN，请将其移除。
|
||||
|
||||
i) 解释 pc1 上的 `ip neigh` 命令输出！
|
||||
|
||||
ii) 清空 pc1 和 pc2 上的 ARP 缓存！（提示：`ip neigh`）
|
||||
|
||||
iii) 确保 PC 的接口拥有 Link-Local IPv6 地址。（提示：`ip link [down/up]`）
|
||||
|
||||
iv) 使用 `ping` 和 `ping6` 在 pc1 和 pc2 之间生成 IP 流量。`ip neigh` 输出有何变化？
|
||||
|
||||
v) 使用 `tcpdump` 观察从 IP 地址到 MAC 地址的解析。请求解析的 MAC 地址分别发送给哪些 MAC 地址？是否是广播？
|
||||
|
||||
vi) 为您的 PC 添加以下网络的 IPv6 地址：`2001:db8:<组号>::/64`
|
||||
|
||||
vii) 使用新添加的全局地址重复 IPv6 测试。解释这些差异！
|
||||
|
||||
viii) 比较 `tcpdump` 和 `scapy` 的输出。使用 `scapy` 显示 ARP/Neighbor Solicitation (NS) 数据包的详细信息。
|
||||
|
||||
ix) 使用 `scapy` 发送 ARP 和 NS 数据包从 pc1 发出。（提示：`Ether` 和 `sendp()`）
|
||||
|
||||
查看 pc2 和 pc3 是否接收到这些数据包？它们如何响应这些请求？检查 pc1 收到的回复！
|
||||
|
||||
x) 使用 `scapy` 发送带有新 MAC 地址的 ARP Reply 和 Neighbor Advertisement (NA) 数据包从 pc1 发给 pc2。查看 pc2 的邻居缓存在接收到数据包后有何反应？
|
||||
|
||||
### A203 在 C 中实现 ARP
|
||||
|
||||
任务是独立实现 ARP 协议 (参见 RFC 826)。目标是基于 TUN/TAP 设备，在网络内拦截数据流，并通过工具 `arping` 对 ARP 请求发送语义和语法正确的 ARP 响应。
|
||||
|
||||
i) 熟悉 TUN/TAP 设备的工作原理，并使用小应用程序 `tuntap.c` 检查您的配置是否正确。
|
||||
|
||||
ii) 为 ARP 请求和响应选择一个合适的接口，并在一个头文件中记录。阅读 RFC 826 以获得相关信息。
|
||||
|
||||
iii) 实现您指定的接口，使其能够正确响应 `arping` 请求。您可以为响应分配任意 IP 地址和 MAC 地址。
|
||||
|
||||
`arping` 请求示例：
|
||||
```bash
|
||||
$ arping -I mytap <ip>
|
||||
```
|
||||
|
||||
## Appendix
|
||||
|
||||
### SDU
|
||||
|
||||
**SDU**（Service Data Unit，服务数据单元）是计算机网络中的一个概念，指的是在网络协议层之间传递的数据单元。在分层网络模型中，SDU 是上一层协议或服务要传递给下一层协议或服务的数据。SDU 的数据内容在传递到下一层时可能会被封装成一个新的数据单元（PDU，Protocol Data Unit，协议数据单元）。
|
||||
|
||||
#### SDU 的作用
|
||||
|
||||
在分层网络模型中，每一层协议对上一层的 SDU 进行处理，将其封装、分片或添加头信息后，传递到下一层。这一过程在数据从高层（如应用层）到低层（如物理层）时会反复发生，直到数据在物理层上被传输出去。SDU 是分层结构中数据传递的基础单位。
|
||||
|
||||
#### SDU 与 PDU 的关系
|
||||
|
||||
- **SDU（Service Data Unit）**：是传递给下一层协议的数据单元，通常包含应用层或上层协议层的数据。
|
||||
- **PDU（Protocol Data Unit）**：是将 SDU 封装后，加入本层协议的控制信息（例如头部和尾部）形成的完整数据包。PDU 是每一层协议的实际传输单元。
|
||||
|
||||
|
||||
在一层协议中，SDU 被处理和封装成 PDU，然后传递给下一层。例如：
|
||||
1. 传输层将应用层的 SDU 封装成传输层 PDU（例如 TCP 段或 UDP 数据报）。
|
||||
2. 网络层将传输层的 PDU 封装成网络层 PDU（如 IP 数据报）。
|
||||
3. 链路层将网络层的 PDU 封装成链路层 PDU（如以太网帧）。
|
||||
|
||||
假设一个应用程序发送一个数据单元到网络中，这个数据单元会经历多个协议层的封装过程：
|
||||
|
||||
1. **应用层**：应用层生成一个 SDU（例如 HTTP 请求），并将其传递给传输层。
|
||||
2. **传输层**：传输层将应用层的 SDU 封装为传输层的 PDU（例如 TCP 段），并将其传递给网络层。
|
||||
3. **网络层**：网络层将传输层的 PDU 作为 SDU，然后封装为网络层的 PDU（例如 IP 数据报），传递给数据链路层。
|
||||
4. **数据链路层**：链路层将网络层的 PDU 作为 SDU，封装为链路层 PDU（例如以太网帧），最后在物理层上传输。
|
||||
|
||||
### TUN and TAP
|
||||
|
||||
**TUN** 和 **TAP** 是 Linux 和其他操作系统中的两种虚拟网络设备，用于处理网络流量。它们分别用于 **三层（网络层）** 和 **二层（数据链路层）** 网络通信。
|
||||
|
||||
#### 1. TUN 接口
|
||||
|
||||
- **TUN** 代表 **"network TUNnel"**。
|
||||
- TUN 是一个虚拟的三层（网络层）设备，模拟的是 IP 层。
|
||||
- 它处理的是 **IP 数据包**（如 IPv4 或 IPv6），可以看作是虚拟的网卡，但只处理三层协议。
|
||||
- 当应用程序通过 TUN 接口发送 IP 数据包时，操作系统会将这些数据包交给一个用户空间程序，该程序可以对数据包进行处理或转发。
|
||||
- 常用于 **VPN**（如 OpenVPN）的三层隧道，实现私有网络之间的安全通信。
|
||||
|
||||
**工作方式**：
|
||||
- TUN 接口会将 IP 数据包从内核空间转发到用户空间的 VPN 程序。
|
||||
- VPN 程序加密或解密数据包后，再通过 TUN 接口发送到网络中，或转发到目标设备。
|
||||
|
||||
**示例**：OpenVPN 的 TUN 模式使用三层隧道，仅处理 IP 数据包，适用于没有广播流量需求的网络（如 Internet 流量）。
|
||||
|
||||
#### 2. TAP 接口
|
||||
|
||||
- **TAP** 代表 **"network TAP"**，意为网络接入点。
|
||||
- TAP 是一个虚拟的二层（数据链路层）设备，模拟的是以太网设备。
|
||||
- 它处理的是 **以太网帧**，包括 IP、ARP 等协议层的封装。
|
||||
- TAP 接口允许虚拟网络设备和物理网络一样传输以太网帧，因此可以处理广播和多播流量。
|
||||
- 常用于虚拟机（如 KVM、VirtualBox）和容器的二层连接，允许虚拟机像在同一个局域网内一样通信。
|
||||
|
||||
**工作方式**：
|
||||
- TAP 接口可以在二层网络中直接传输以太网帧，包含源 MAC 地址、目标 MAC 地址和协议字段。
|
||||
- 它将这些帧转发到用户空间程序进行处理，程序可以将它们转发到其他网络或应用程序。
|
||||
|
||||
**示例**：OpenVPN 的 TAP 模式使用二层隧道，适用于需要广播或多播的场景，如与局域网相连的虚拟网络环境。
|
||||
|
||||
#### 区别总结
|
||||
|
||||
| 特性 | TUN（网络隧道） | TAP（接入点） |
|
||||
| ------------ | ----------------------- | ------------------------------ |
|
||||
| 层次 | 三层（网络层） | 二层（数据链路层） |
|
||||
| 处理数据类型 | IP 数据包（IPv4、IPv6） | 以太网帧（包括 MAC 地址） |
|
||||
| 广播支持 | 不支持 | 支持 |
|
||||
| 应用场景 | 三层 VPN（不需要广播） | 二层 VPN、虚拟机局域网连接 |
|
||||
| 常用协议 | 仅传输 IP 层协议 | 可以传输任意二层协议（如 ARP） |
|
||||
|
||||
#### 何时使用 TUN 和 TAP
|
||||
|
||||
- **使用 TUN**：如果只需要在网络层传输 IP 数据包，且不需要局域网的广播和多播功能，例如 Internet 访问的三层 VPN。
|
||||
- **使用 TAP**：如果需要在二层连接多个设备，支持以太网帧级别的通信（包括广播和多播），如多个虚拟机在同一局域网内通信的二层 VPN。
|
||||
|
||||
#### 工具支持
|
||||
|
||||
- **`ip tuntap`**：可以在 Linux 上创建和管理 TUN 和 TAP 设备。
|
||||
- **OpenVPN**：支持 TUN 和 TAP 两种模式，用户可以根据需求选择相应的接口类型。
|
||||
- **虚拟化平台**（如 KVM、VirtualBox）：通常使用 TAP 接口来实现虚拟机与主机网络的连接。
|
||||
|
||||
## Wireshark
|
||||
|
||||
`ssh pc1 "tcpdump -i eth1 -s 0 -w - 'not port 22'" | sudo wireshark -k -i-`
|
||||
|
||||
|
||||
|
||||
`grep -A awk` 是一种组合使用 `grep` 和 `awk` 命令的方式，用于在文本中搜索特定内容并提取数据。这种组合通常用于更加精细地过滤和处理数据。下面我们来详细解释它们的用法，并通过一些例子展示如何结合 `grep -A` 和 `awk` 来完成任务。
|
||||
|
||||
## `grep` 和 `-A` 选项
|
||||
|
||||
- **`grep`** 是一个搜索命令，用于在文本中查找特定的字符串或正则表达式匹配项。
|
||||
- **`-A` 选项** 表示“after”（之后），用于输出匹配行及其后面的几行内容。
|
||||
|
||||
**语法：**
|
||||
|
||||
```bash
|
||||
grep -A <number> <pattern> <file>
|
||||
```
|
||||
|
||||
- `<number>`：匹配行之后的行数。
|
||||
- `<pattern>`：要搜索的模式或字符串。
|
||||
- `<file>`：要搜索的文件名。
|
||||
|
||||
**示例：**
|
||||
|
||||
假设文件 `sample.txt` 内容如下：
|
||||
|
||||
```plaintext
|
||||
Line 1: Apple
|
||||
Line 2: Orange
|
||||
Line 3: Banana
|
||||
Line 4: Grape
|
||||
Line 5: Mango
|
||||
```
|
||||
|
||||
使用 `grep -A` 查找包含 `Orange` 的行，并显示它之后的 2 行：
|
||||
|
||||
```bash
|
||||
grep -A 2 "Orange" sample.txt
|
||||
```
|
||||
|
||||
**输出：**
|
||||
|
||||
```plaintext
|
||||
Line 2: Orange
|
||||
Line 3: Banana
|
||||
Line 4: Grape
|
||||
```
|
||||
|
||||
在这里，`grep` 输出匹配行 `Line 2: Orange` 以及接下来的 2 行。
|
||||
|
||||
## `awk` 命令
|
||||
|
||||
`awk` 是一个强大的文本处理工具，可以对 `grep` 的输出结果进行进一步的数据提取和处理。
|
||||
|
||||
**基本语法：**
|
||||
|
||||
```bash
|
||||
awk '<pattern> {action}' <file>
|
||||
```
|
||||
|
||||
- `<pattern>`：条件或模式，表示当行内容符合该条件时执行 `{action}`。
|
||||
- `{action}`：对符合条件的行执行的操作。
|
||||
- `<file>`：输入文件，或直接从管道传入数据。
|
||||
|
||||
**示例：**
|
||||
|
||||
假设 `sample.txt` 内容如下：
|
||||
|
||||
```plaintext
|
||||
Line 1: Apple
|
||||
Line 2: Orange
|
||||
Line 3: Banana
|
||||
Line 4: Grape
|
||||
Line 5: Mango
|
||||
```
|
||||
|
||||
如果我们只想提取包含 `Orange` 的行的第二列：
|
||||
|
||||
```bash
|
||||
grep "Orange" sample.txt | awk '{print $2}'
|
||||
```
|
||||
|
||||
**输出：**
|
||||
|
||||
```plaintext
|
||||
Orange
|
||||
```
|
||||
|
||||
### 3. 组合 `grep -A` 和 `awk`
|
||||
|
||||
将 `grep -A` 和 `awk` 组合在一起使用可以实现更加精确的数据提取。例如，我们想要查找包含 `Orange` 的行以及后面 2 行，并且只提取这些行的第二列。
|
||||
|
||||
**示例：**
|
||||
|
||||
```bash
|
||||
grep -A 2 "Orange" sample.txt | awk '{print $2}'
|
||||
```
|
||||
|
||||
**输出：**
|
||||
|
||||
```plaintext
|
||||
Orange
|
||||
Banana
|
||||
Grape
|
||||
```
|
||||
|
||||
### 示例总结
|
||||
|
||||
结合 `grep -A` 和 `awk` 的方法适用于以下场景：
|
||||
|
||||
1. **grep -A** 用于定位特定模式及其后续行。
|
||||
2. **awk** 提取特定列或执行进一步的数据处理。
|
||||
|
||||
通过这种组合方式，你可以有效地过滤并提取文本中的信息。
|
||||
|
||||
## Scapy
|
||||
|
||||
**Scapy** 是一个强大的 Python 库，用于处理网络包。它允许用户创建、发送、接收和分析网络包，广泛用于网络调试、安全测试、包分析等任务。Scapy 支持多种网络协议，如 Ethernet、IP、TCP、UDP、ICMP、ARP 等，因此非常适合网络工程师、渗透测试人员和研究人员。
|
||||
|
||||
### Scapy 的基本功能
|
||||
|
||||
Scapy 的主要功能包括 **构建网络包**、**发送和接收包**、以及 **分析网络流量**。以下是一些常见的 Scapy 用法。
|
||||
|
||||
### 基本用法示例
|
||||
|
||||
#### 1. 构建和发送 ICMP（ping）请求
|
||||
|
||||
使用 Scapy 发送 ICMP 请求（类似于 `ping` 命令），可以通过构建 IP 层和 ICMP 层来完成。
|
||||
|
||||
```python
|
||||
from scapy.all import *
|
||||
|
||||
# 创建一个 ICMP 请求包
|
||||
packet = IP(dst="8.8.8.8") / ICMP()
|
||||
|
||||
# 发送并接收响应
|
||||
response = sr1(packet, timeout=2)
|
||||
|
||||
# 检查是否有响应
|
||||
if response:
|
||||
print("Received response from:", response.src)
|
||||
else:
|
||||
print("No response")
|
||||
```
|
||||
|
||||
- `IP(dst="8.8.8.8")`：构建目标 IP 地址为 8.8.8.8 的 IP 层。
|
||||
- `/ ICMP()`：在 IP 层上附加 ICMP 协议层，形成一个完整的 ping 包。
|
||||
- `sr1()`：发送并接收一个响应包。
|
||||
|
||||
#### 2. 发送 ARP 请求（地址解析协议）
|
||||
|
||||
构建和发送 ARP 请求来获取局域网中目标 IP 地址的 MAC 地址。
|
||||
|
||||
```python
|
||||
from scapy.all import *
|
||||
|
||||
# 创建一个 ARP 请求包，目标 IP 为 192.168.1.1
|
||||
arp_request = ARP(pdst="192.168.1.1")
|
||||
|
||||
# 将 ARP 包广播发送到局域网
|
||||
broadcast = Ether(dst="ff:ff:ff:ff:ff:ff")
|
||||
packet = broadcast / arp_request
|
||||
|
||||
# 发送并接收响应
|
||||
answered, unanswered = srp(packet, timeout=2, iface="eth0")
|
||||
|
||||
# 打印响应结果
|
||||
for send, receive in answered:
|
||||
print("MAC Address:", receive.hwsrc, "IP Address:", receive.psrc)
|
||||
```
|
||||
|
||||
- `ARP(pdst="192.168.1.1")`：创建一个目标 IP 地址为 192.168.1.1 的 ARP 请求。
|
||||
- `Ether(dst="ff:ff:ff:ff:ff:ff")`：构建一个以太网广播包，将 ARP 请求广播出去。
|
||||
- `srp()`：在数据链路层发送并接收响应。
|
||||
|
||||
#### 3. 捕获网络数据包
|
||||
|
||||
可以使用 Scapy 监听并捕获网络上的数据包，例如捕获 TCP 包：
|
||||
|
||||
```python
|
||||
from scapy.all import *
|
||||
|
||||
# 定义一个回调函数，用于处理捕获到的数据包
|
||||
def packet_callback(packet):
|
||||
if packet.haslayer(TCP):
|
||||
print("Captured TCP Packet:", packet.summary())
|
||||
|
||||
# 开始捕获数据包
|
||||
sniff(filter="tcp", prn=packet_callback, count=10)
|
||||
```
|
||||
|
||||
- `sniff()`：用于捕获网络数据包。
|
||||
- `filter="tcp"`：过滤条件，仅捕获 TCP 包。
|
||||
- `prn=packet_callback`：捕获到的数据包会传递到 `packet_callback` 函数。
|
||||
- `count=10`：捕获 10 个数据包后停止。
|
||||
|
||||
#### 4. 构建自定义网络包
|
||||
|
||||
Scapy 允许构建任意协议层的包，你可以通过叠加不同协议层来构建自定义包：
|
||||
|
||||
```python
|
||||
from scapy.all import *
|
||||
|
||||
# 构建一个自定义的 TCP 数据包
|
||||
packet = IP(dst="192.168.1.1") / TCP(dport=80) / "Hello, World!"
|
||||
send(packet)
|
||||
```
|
||||
|
||||
- `IP(dst="192.168.1.1")`：指定目标 IP 地址。
|
||||
- `TCP(dport=80)`：指定目标端口为 80（HTTP）。
|
||||
- `/"Hello, World!"`：在 TCP 层后添加数据负载。
|
||||
|
||||
#### 5. 追踪路由路径（类似于 traceroute）
|
||||
|
||||
Scapy 可以通过逐渐增加 TTL 值来模拟 `traceroute` 的功能：
|
||||
|
||||
```python
|
||||
from scapy.all import *
|
||||
|
||||
# 使用 Scapy 的 traceroute 功能
|
||||
result, unans = traceroute("google.com", maxttl=20)
|
||||
|
||||
# 打印结果
|
||||
result.show()
|
||||
```
|
||||
|
||||
- `traceroute("google.com", maxttl=20)`：设置最大 TTL 为 20，目标为 `google.com`。
|
||||
- `result.show()`：显示路由追踪结果。
|
||||
|
||||
### Scapy 常用函数
|
||||
|
||||
- `send(packet)`：发送数据包，不等待响应。
|
||||
- `sr(packet)`：发送数据包并等待响应（适用于网络层）。
|
||||
- `sr1(packet)`：发送数据包并等待一个响应包。
|
||||
- `srp(packet)`：在链路层发送数据包并等待响应（适用于数据链路层，如 Ethernet）。
|
||||
- `sniff()`：监听捕获数据包。
|
||||
- `traceroute()`：用于追踪网络路径，类似 `traceroute` 工具。
|
||||
|
||||
### 总结
|
||||
|
||||
Scapy 是一个功能强大的网络包处理库，主要功能包括：
|
||||
|
||||
- **构建**：支持从链路层到应用层的网络包构建。
|
||||
- **发送/接收**：可以发送网络包并接收响应，用于网络测试。
|
||||
- **捕获/分析**：支持数据包捕获和实时流量分析。
|
||||
|
||||
### RFC 826
|
||||
|
||||
**Address Resolution module** convert the <protocol type, target protocol address> pair to a 48.bit Ethernet address.
|
||||
|
||||
```
|
||||
However, the 10Mbit Ethernet requires 48.bit addresses on the physical cable, yet most protocol addresses are not 48.bits long, nor do they necessarily have any relationship to the 48.bit Ethernet address of the hardware.
|
||||
```
|
||||
|
||||
```
|
||||
As a packet is sent down through the network layers, routing determines the protocol address of the next hop for the packet and on which piece of hardware it expects to find the station with the immediate target protocol address.
|
||||
|
||||
In the case of the 10Mbit Ethernet, address resolution is needed and some lower layer (probably the hardware driver) must consult the Address Resolution module (perhaps implemented in the Ethernet support module) to convert the <protocol type, target protocol address> pair to a 48.bit Ethernet address.
|
||||
|
||||
The Address Resolution module tries to find this pair in a table. If it finds the pair, it gives the corresponding 48.bit Ethernet address back to the caller (hardware driver) which then transmits the packet.
|
||||
|
||||
If it does not, it probably informs the caller that it is throwing the packet away (on the assumption the packet will be retransmitted by a higher network layer), and generates an Ethernet packet with a type field of ether_type$ADDRESS_RESOLUTION.
|
||||
|
||||
The Address Resolution module then sets the ar$hrd field to ares_hrd$Ethernet, ar$pro to the protocol type that is being resolved, ar$hln to 6 (the number of bytes in a 48.bit Ethernet address), ar$pln to the length of an address in that protocol, ar$op to ares_op$REQUEST, ar$sha with the 48.bit ethernet address of itself, ar$spa with the protocol address of itself, and ar$tpa with the protocol address of the machine that is trying to be accessed.
|
||||
|
||||
It does not set ar$tha to anything in particular, because it is this value that it is trying to determine. It could set ar$tha to the broadcast address for the hardware (all ones in the case of the 10Mbit Ethernet) if that makes it convenient for some aspect of the implementation. It then causes this packet to be broadcast to all stations on the Ethernet cable originally determined by the routing mechanism.
|
||||
```
|
||||
|
||||
|
||||
|
||||
```
|
||||
Packet Reception:
|
||||
-----------------
|
||||
|
||||
When an address resolution packet is received, the receiving Ethernet module gives the packet to the Address Resolution module which goes through an algorithm similar to the following.
|
||||
|
||||
Negative conditionals indicate an end of processing and a discarding of the packet.
|
||||
|
||||
?Do I have the hardware type in ar$hrd?
|
||||
Yes: (almost definitely)
|
||||
[optionally check the hardware length ar$hln]
|
||||
?Do I speak the protocol in ar$pro?
|
||||
Yes:
|
||||
[optionally check the protocol length ar$pln]
|
||||
Merge_flag := false
|
||||
If the pair <protocol type, sender protocol address> is
|
||||
already in my translation table, update the sender
|
||||
hardware address field of the entry with the new
|
||||
information in the packet and set Merge_flag to true.
|
||||
?Am I the target protocol address?
|
||||
Yes:
|
||||
If Merge_flag is false, add the triplet <protocol type,
|
||||
sender protocol address, sender hardware address> to
|
||||
the translation table.
|
||||
?Is the opcode ares_op$REQUEST? (NOW look at the opcode!!)
|
||||
Yes:
|
||||
Swap hardware and protocol fields, putting the local
|
||||
hardware and protocol addresses in the sender fields.
|
||||
Set the ar$op field to ares_op$REPLY
|
||||
Send the packet to the (new) target hardware address on
|
||||
the same hardware on which the request was received.
|
||||
```
|
||||
|
||||
### tuntap
|
||||
|
||||
`ip tuntap` 命令在 Linux 中用于管理 **TUN** 和 **TAP** 设备。TUN（网络层）和 TAP（链路层）设备是虚拟网络设备，可以通过它们创建虚拟网络接口，实现隧道功能。**TUN 设备**用于处理 IP 包，而 **TAP 设备**用于处理以太网帧。
|
||||
|
||||
以下是如何使用 `ip tuntap` 命令来创建和配置 TUN/TAP 设备的指南：
|
||||
|
||||
#### 1. 创建 TUN/TAP 设备
|
||||
|
||||
要使用 `ip tuntap` 创建 TUN 或 TAP 设备，需要使用 `mode` 参数来指定是创建 TUN 设备还是 TAP 设备。
|
||||
|
||||
创建 TUN 设备
|
||||
|
||||
```bash
|
||||
sudo ip tuntap add dev tun0 mode tun
|
||||
```
|
||||
|
||||
创建 TAP 设备
|
||||
|
||||
```bash
|
||||
sudo ip tuntap add dev tap0 mode tap
|
||||
```
|
||||
|
||||
在这里：
|
||||
- `tun0` 和 `tap0` 是设备名称，可以根据需要更改为其他名称。
|
||||
- `mode tun` 表示创建 TUN 设备，而 `mode tap` 表示创建 TAP 设备。
|
||||
|
||||
#### 2. 配置 TUN/TAP 设备的 IP 地址
|
||||
|
||||
创建设备后，可以用 `ip addr` 为 TUN 或 TAP 设备分配 IP 地址。以下是配置示例：
|
||||
|
||||
```bash
|
||||
# 为 TUN 设备分配 IP 地址
|
||||
sudo ip addr add 10.0.0.1/24 dev tun0
|
||||
|
||||
# 为 TAP 设备分配 IP 地址
|
||||
sudo ip addr add 192.168.1.1/24 dev tap0
|
||||
```
|
||||
|
||||
#### 3. 启动 TUN/TAP 设备
|
||||
|
||||
在分配 IP 地址后，需要将设备设置为“UP”状态，以便开始传输数据：
|
||||
|
||||
```bash
|
||||
sudo ip link set dev tun0 up
|
||||
```
|
||||
|
||||
或对于 TAP 设备：
|
||||
```bash
|
||||
sudo ip link set dev tap0 up
|
||||
```
|
||||
|
||||
#### 4. 删除 TUN/TAP 设备
|
||||
|
||||
可以使用以下命令删除已经创建的 TUN 或 TAP 设备：
|
||||
|
||||
```bash
|
||||
sudo ip tuntap del dev tun0 mode tun
|
||||
sudo ip tuntap del dev tap0 mode tap
|
||||
```
|
||||
|
||||
#### 5. 查看 TUN/TAP 设备状态
|
||||
|
||||
创建完成后，可以使用 `ip addr show` 或 `ip link show` 查看设备的状态和配置信息：
|
||||
|
||||
```bash
|
||||
ip addr show tun0
|
||||
ip link show tap0
|
||||
```
|
||||
|
||||
#### 示例：完整配置
|
||||
|
||||
以下是一个完整示例，创建一个 TUN 设备 `tun0`，分配 IP 地址并启动该设备：
|
||||
|
||||
```bash
|
||||
# 创建 TUN 设备
|
||||
sudo ip tuntap add dev tun0 mode tun
|
||||
|
||||
# 分配 IP 地址
|
||||
sudo ip addr add 10.0.0.1/24 dev tun0
|
||||
|
||||
# 启动设备
|
||||
sudo ip link set dev tun0 up
|
||||
```
|
||||
|
||||
对于 TAP 设备，过程类似，但只需将 `tun0` 替换为 `tap0`，并使用适当的 IP 地址。
|
||||
|
||||
#### 应用场景
|
||||
|
||||
- **VPN**：TUN 设备常用于 VPN（虚拟专用网络），因为它可以处理 IP 包。
|
||||
- **虚拟网络**：TAP 设备可以模拟以太网连接，通常用于虚拟机之间的网络连接。
|
||||
- **隧道**：TUN 和 TAP 设备都可以用于创建隧道，将数据通过其他网络协议进行传输。
|
||||
|
||||
#### 总结
|
||||
|
||||
- **TUN 设备**：工作在网络层，处理 IP 包，适合 VPN 和隧道应用。
|
||||
- **TAP 设备**：工作在链路层，处理以太网帧，适合模拟以太网连接。
|
||||
|
||||
通过 `ip tuntap` 命令，你可以轻松创建、配置、启动和删除 TUN/TAP 设备，用于不同的网络虚拟化和隧道需求。
|
||||
411
Blatt02/Notes1.md
Normal file
411
Blatt02/Notes1.md
Normal file
@@ -0,0 +1,411 @@
|
||||
|
||||
|
||||
[toc]
|
||||
|
||||
## 2.1 Bitübertragungsschicht (OSI-Schicht 1) 物理层（OSI模型第1层）
|
||||
|
||||
Bei jeder Interaktion zwischen zwei Rechnern müssen die Daten früher oder später eine physische Distanz überbrücken. Die binären Daten eines Rechners werden für den physischen Transport aufbereitet und anschließend über ein Medium an einen anderen Rechner übertragen. Kann der andere Rechner aus dem Empfangenen die ursprünglichen Daten rekonstruieren, ist es gelungen, binäre Daten von einem Rechner an einen anderen zu übertragen.
|
||||
在两个计算机之间的每次交互中，数据迟早必须跨越物理距离。一个计算机的二进制数据会被处理以便于物理传输，然后通过某种媒介传输到另一台计算机。如果接收方计算机能够从接收到的信号中重构出原始数据，那么数据已成功地从一个计算机传输到另一个计算机。
|
||||
|
||||
Protokolle der Bitübertragungsschicht beschäftigen sich mit genau diesem Problem. Sie legen fest, welches **Medium** benutzt wird und wie binäre Daten (Bits) als Signale auf das physische Medium moduliert werden. Dazu gehören mehrere Aspekted, die sicherstellen, dass alle Endpunkte auf die gleiche Art und Weise Daten übermitteln und interpretieren. Diese Aspekte lassen sich in vier Gruppen unterteilen:
|
||||
物理层协议正是解决这个问题的。它们规定了使用哪种媒介，以及如何将二进制数据（比特）作为信号调制到物理媒介上。这涉及多个方面，以确保所有终端以相同的方式传输和解释数据。这些方面可以分为四组。
|
||||
|
||||
**Physikalische** Aspekte umfassen Eigenschaften des Mediums und der verwendeten Signale.
|
||||
**物理**方面包括媒介的特性和所使用的信号。
|
||||
|
||||
**Mechanische** Eigenschaften spezifizieren u.A. die Bauform der Anschlüsse an das Medium.
|
||||
**机械**方面指定了与媒介连接的接口的结构形式。
|
||||
|
||||
**Funktionale** Spezifikationen definieren die Benutzung des Mediums, z.B. Pin-Belegung und Takt.
|
||||
**功能性**规范定义了媒介的使用方式，例如引脚分配和时钟。
|
||||
|
||||
**Prozedurale** Beschreibungen enthalten Elementarereignisse und deren Bedeutung, z.B. den genauen Ablauf zur Übertragung einer SDU.
|
||||
**过程性**描述包括基本事件及其含义，例如传输一个 [SDU](#SDU) 的确切流程。
|
||||
|
||||
Heute handelt es sich bei dem Medium meist um Kupfer, Lichtwellenleiter oder "Luft". Die Signale werden in der Regel so gewählt, dass sie deutlich voneinander unterscheidbar sind, da Signale durch Störeinflüsse leicht verfälscht werden können. Eine SDU auf Schicht 1 muss nicht genau ein Bit sein. Ein Schicht 1 Protokoll kann auch die parallele Übertragung von mehreren Bits gleichzeitig spezifizieren.
|
||||
如今，媒介通常是铜线、光导纤维或“空气”。信号通常被设计为明显不同，以便于区分，因为信号容易受到干扰的影响而失真。在第 1 层上，一个 SDU 不一定对应于一个比特。第 1 层协议还可以指定多个比特的并行传输。
|
||||
|
||||
Durch äußere Störeinflüsse können Amplitude, Frequenz und Phase eines Signals bei der Übertragung verändert werden. Komponenten der Schicht 1 verarbeiten Signale dahingehend, dass eingehende Signale als Signalzustände entsprechend der Spezifikation aufgefasst werden (Diskretisierung). Die Umwandlung in Bits ist ein weiterer Arbeitsschritt, der in der Regel nur von Komponenten, die auch eine Schicht 2 implementieren, durchgeführt werden muss. Gängige Schicht 1 Komponenten sind Repeater, Multiport-Repeater (Hubs) und Wavelength Division Multiplexer (WDMs).
|
||||
外部干扰可能会改变信号在传输过程中的幅度、频率和相位。第 1 层的组件处理信号的方式是将接收到的信号解释为符合规格的信号状态（离散化）。将信号转换为比特是另一个工作步骤，通常只有那些同时实现第 2 层的组件才需要完成此步骤。常见的第 1 层组件包括中继器、多端口中继器（集线器）和波分复用器（WDMs）。
|
||||
|
||||
|
||||
|
||||
### 2.1.1 Repeater und Hubs 中继器和集线器
|
||||
|
||||
Ein Repeater verfügt über genau zwei Anschlüsse. Ein eingehendes Signal auf einem Anschluss wird verstärkt auf dem anderen Anschluss ausgegeben. Repeater können eingesetzt werden, um das Problem der Dämpfung zu überwinden und Signale über längere Distanzen zu übertragen, als es die Sendeleistung des ursprünglichen Senders erlaubt. Die logische Weiterentwicklung des Repeaters ist der Hub. Dieser verfügt über mehrere Anschlüsse und gibt ein eingehendes Signal an allen anderen Anschlüssen verstärkt wieder aus.
|
||||
中继器（Repeater）通常有两个接口。当一个接口收到信号时，信号会被增强并从另一个接口输出。中继器可以用来解决信号衰减的问题，使信号传输距离超过原始发送器的功率限制。中继器的进一步发展就是集线器（Hub）。集线器具有多个接口，能够将一个接口接收到的信号增强后发送到所有其他接口。
|
||||
|
||||
|
||||
|
||||
### 2.1.2 Wavelength Division Multiplexer 波分复用器
|
||||
|
||||
Implementieren optische Sendestationen das selbe Schicht 1 Protokoll, so verwenden sie meist die selben Wellenlängen zur Signalisierung. Treffen diese Signale in einem gemeinsamen Medium aufeinander, entstehen Überlagerungen (Kollisionen), so dass kein Empfänger die ursprünglichen Daten rekonstruieren kann. Bei einem Aufbau, in dem mehrere Sender Signale auf dem selben Medium versenden, so dass Kollisionen entstehen können, spricht man von einer Kollisionsdomäne.
|
||||
在光学发送站中，若使用相同的第一层协议，通常会使用相同的波长进行信号传输。当这些信号在同一媒介中相遇时，就会产生叠加（碰撞），导致接收端无法还原原始数据。若在同一媒介上多个发送端同时发送信号，造成碰撞的可能性，这种结构被称为碰撞域。
|
||||
|
||||
WDMs bilden mehrere eingehende optische Signale auf unterschiedliche, disjunkte Bereiche des Farbspektrums (Kanäle) einer ausgehenden Leitung ab (Multiplex). Dadurch können alle eingehenden Signale gleichzeitig über eine einzelne ausgehende Leitung übertragen werden, ohne Kollisionen zu erzeugen. Abbildung 2.1 zeigt einen WDM, der drei eingehende Signale A, B und C auf eine ausgehende Leitung moduliert. Diese Technik setzt man häufig ein, wenn der Aufwand zusätzliche Leitungen zu verlegen hoch ist. In Abbildung 2.1 sind A, B und C optische Signale der selben Schicht 1 Implementierung (z.B. 1 Gbps Ethernet, Monomode) und verwenden deshalb die selbe Wellenlänge für die Datenübertragung. Im WDM werden die Wellenlängen der eingehenden Signale modifiziert, so dass keine Überlagerung mehr stattfindet wenn die Signale in der ausgehenden Leitung aufeinander treffen.
|
||||
波分复用器（WDMs）将多个入射光信号映射到不同的、互不重叠的色谱范围（通道）上，通过一条输出线路（复用）。所有传入的信号可以同时通过一条输出线路传输，而不会产生碰撞。图 2.1 显示了一个波分复用器（WDM），它将三个输入信号 A、B 和 C 调制到一条输出线路上。当增加额外线路的成本很高时，通常会使用这种技术。图 2.1 中的 A、B 和 C 是相同的第 1 层实现的光信号（例如 1 Gbps 以太网，单模），因此使用相同的波长进行数据传输。在 WDM 中，输入信号的波长会被调整，以避免当信号进入输出线路时产生重叠。
|
||||
|
||||
Am anderen Ende der Leitung empfängt ein Demultiplexer das zusammengesetzte Signal. Dieser trennt das empfangene Signal auf, moduliert die Teilsignale zurück auf ihre ursprüngliche Form und sendet die Signale auf separaten Leitungen weiter.
|
||||
在线路的另一端，一个解复用器接收组合信号。该设备将接收到的信号分离，将每个子信号调制回其原始形式，并通过独立的线路发送这些信号。
|
||||
|
||||
## 2.2 Sicherungsschicht (OSI-Schicht 2) 数据链路层（OSI模型第 2 层）
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zu den Hauptaufgaben der Sicherungsschicht gehört Rahmenbildung (bzw. Blockbildung). Darunter versteht man die Gruppierung von Bits zu logischen Einheiten, den PDUs der Schicht 2 (Rahmen oder Blöcke, bzw. engl. frames oder blocks). Eine Basiskomponente der Schicht 2 ist die Bridge (bzw. “Brücke”). Eine Bridge ist eine Schicht 2 Komponente, die zwei Teilnetze (mit möglicherweise verschiedenen Übertragungstechniken) miteinander verbindet, also eine Brücke dazwischen bildet. Dazu muss sie eingehende Signale interpretieren und zu Rahmen zusammensetzen. Erst der vollständige Rahmen wird in das andere Teilnetz übertragen. Diese Technik heißt “store and forward”, da die Bridge eingehende Daten (Bits) speichert (store), bis der Rahmen vollständig empfangen wurde und erst im Anschluss daran den Rahmen weiterleitet (forward). Eine Bridge mit mehr als zwei Anschlüssen heißt Switch oder Multiport-Bridge.
|
||||
数据链路层的主要任务之一是帧构建（或称块构建），即将比特分组为逻辑单元，即第 2 层的 PDU（帧或块）。第 2 层的基本组件之一是桥接器（Bridge）。桥接器是第 2 层组件，它连接两个子网（可能使用不同的传输技术），因此在它们之间形成了一个桥。为此，它必须解释接收到的信号并将其组装成帧。只有完整的帧才会被传输到另一个子网。这种技术被称为“存储和转发”（store and forward），因为桥接器会先存储（store）接收到的数据（比特），直到帧完全接收后才转发（forward）该帧。具有两个以上端口的桥接器被称为交换机（Switch）或多端口桥（Multiport-Bridge）。
|
||||
|
||||
### 2.2.1 Vergleich von Komponenten der Schichten 1 und 2 2.2.1 第 1 层和第 2 层组件的比较
|
||||
|
||||
Aufgrund der Hauptaufgaben der Schichten 1 und 2 ergeben sich unterscheidende Merkmale der Komponenten dieser Schichten: Repeater, Hubs, WDM etc. auf der Schicht 1, Bridges und Switches auf der Schicht 2.
|
||||
根据第 1 层和第 2 层的主要任务，这两层的组件特点有所不同：第 1 层包括中继器、集线器、波分复用器（WDM）等，第 2 层则包括桥接器和交换机。
|
||||
|
||||
Im Gegensatz zu einem WDM verarbeitet eine Bridge nicht einzelne eingehende Signale, sondern eingehende Rahmen. Die Bridge muss demnach in der Lage sein aus gespeicherten Informationen Rahmen zu bilden. Der Einsatz von store and forward ermöglicht es der Bridge unterschiedliche Bitübertragungstechniken für die beiden LANs zu verwenden, wogegen die Anschlüsse eines WDM den Festlegungen der physikalischen Signale entsprechen. Der Aufbau in Abbildung 2.2 erlaubt es unterschiedliche Schicht 1 Implementierungen “links” und “rechts” der Bridge zu nutzen.
|
||||
|
||||
与波分复用器（WDM）不同，桥接器不会处理单个输入信号，而是处理输入的帧。因此，桥接器必须能够根据存储的信息构建帧。通过存储和转发（store and forward）技术，桥接器可以为两个局域网使用不同的比特传输技术，而 WDM 的接口则对应物理信号的规定。图 2.2 的结构允许桥接器左右两侧使用不同的第 1 层实现.
|
||||
|
||||
### 2.2.2 Topologien 拓扑结构
|
||||
|
||||
Neben der Rahmenbildung spezifizieren Schicht 2 Protokolle auch die Übertragung von Rahmen. Dazu gehören Vielfachzugriffsverfahren, die den Zugriff auf Schicht 1 bzw. auf gemeinsam genutzte Medien steuern, sowie die Übertragung von Rahmen zu Schicht 2 Endpunkten. Durch die vielfältigen Komponenten und Funktionen der Schichten 1 und 2 ergeben sich verschiedene Möglichkeiten einen physischen Aufbau eines Netzes (LAN) zu realisieren.
|
||||
除了帧构建，第 2 层协议还定义了帧的传输方式。这包括控制对第 1 层或共享媒介的访问的多重访问协议，以及向第 2 层终端传输帧的方式。由于第 1 层和第 2 层组件和功能的多样性，局域网（LAN）的物理构建有多种实现方式。
|
||||
|
||||
Abbildung 2.2 zeigt auf jeder Seite der Bridge ein Netz mit Bustopologie. Dabei sind mehrere Schicht 2 Endpunkte mit einem gemeinsam genutzten Medium verbunden. Ein Problem der Bustopologie ist die aufwändige Wartung. Tritt ein Hardwaredefekt auf, so kommt meistens das gesamte LAN zum Erliegen. Das Aufspüren der defekten Hardware ist schwierig, da jede Komponente für das Problem verantwortlich sein könnte. Das gemeinsam genutzte Kabel erstreckt sich meist über mehrere Räume oder auch Stockwerke und ist sehr aufwändig auszutauschen.
|
||||
图 2.2 显示了桥接器两侧的总线拓扑网络。在这种拓扑结构中，多个第 2 层终端连接到一个共享媒介上。总线拓扑的一个问题是维护难度较大。一旦出现硬件故障，通常会导致整个局域网瘫痪。因为每个组件都可能是问题的根源，所以定位故障硬件相当困难。共享电缆通常跨越多个房间或楼层，更换非常耗时。
|
||||
|
||||
Eine andere Topologie, die bei diesem Problem hilft, ist die Sterntopologie. An die Stelle des gemeinsam genutzten Mediums tritt ein zentraler Hub (vgl. Abbildung 2.3). Da der Hub eingehende Signale auf alle angeschlossene Kabel repliziert, verhält sich ein Netz mit Sterntopologie genauso wie ein Netz mit Bustopologie; der Charakter des gemeinsam genutzten Mediums bleibt für die Signalübertragung erhalten. Deshalb kann an jeden Anschluss eines Hubs ein ganzes Teilnetz mit Bustopologie angeschlossen werden.
|
||||
另一种可以解决该问题的拓扑结构是星型拓扑。星型拓扑中使用一个中央集线器（参见图 2.3）代替共享介质。由于集线器会将接收到的信号复制到所有连接的电缆上，因此星型拓扑网络的行为类似于总线拓扑网络；信号传输仍然保持共享介质的特性。因此，可以在集线器的每个端口连接一个具有总线拓扑的子网。
|
||||
|
||||
Der Vorteil des Hubs liegt darin, dass ein defektes Kabel an einem Anschluss nicht automatisch zu einem Zusammenbruch des gesamten Netzes führt. Außerdem kann an zentraler Stelle das fehlerhafte Kabel ermittelt werden. Üblicherweise ist an jeder Leitung eines Hubs ein einzelner Rechner angeschlossen, wodurch die Fehlerlokalisierung weiter vereinfacht wird. Der Defekt eines Kabels trennt so lediglich eine einzige Leitung (bzw. einen einzelnen Rechner) vom LAN, anstatt das gesamte LAN zum Erliegen zu bringen. Fällt der Hub aus, kann dieser leichter ausgetauscht werden, als ein Kabel, das durch mehrere Räume und Stockwerke verlegt wurde. Ersetzt man den Hub durch einen Switch, kann der Datenverkehr mit Bezug auf die Eigenschaften von Rahmen (Header) gesteuert werden. Ein Switch kann durch die Interpretation der eingehenden Informationen entscheiden eingehende Rahmen über wenige bestimmte Leitungen weitergeben, anstatt den Rahmen auf jedem Port zu replizieren.
|
||||
集线器的优点在于，连接处的电缆故障不会导致整个网络崩溃。此外，可以在中心位置轻松找到故障电缆。通常，每条连接集线器的电缆只连接一个计算机，这样可以进一步简化故障定位。电缆的故障只会切断该电缆所连接的单个设备与局域网的连接，而不会影响整个网络。即使集线器出现故障，其更换也比更换穿越多个房间或楼层的电缆更为简单。如果将集线器替换为交换机，交换机可以根据帧的特性（如头信息）来管理数据流。交换机可以通过解析接收到的信息，将数据帧仅发送到特定的端口，而不是向每个端口复制帧。
|
||||
|
||||
## 2.3 Ethernet
|
||||
|
||||
Infolge der wachsenden Bedeutung der lokalen Vernetzung von Arbeitsplatzrechnern wurden zwischen 1972 und 1976 am Xerox Palo Alto Research Centre die technologischen Grundlagen für ein gleichermaßen leistungsfähiges und “idiotensicheres” Local Area Network geschaffen. Dieses neue Local Area Network nannte man Ethernet, in Anspielung auf jenen geheimnisvollen “Lichtwellenaether”, welchen die Physiker des 19. Jahrhunderts so verzweifelt gesucht haben. Heute wird Ethernet formal als IEEE-Standard 802.3, CSMA/CD: Protokoll und physische Übertragungstechniken [IEEE 802.3], verwaltet und weiterentwickelt.
|
||||
由于工作站计算机本地网络的重要性日益增加，在 1972 年至 1976 年间，施乐公司帕洛阿尔托研究中心开发了高效且“防呆”的局域网技术基础。这种新型局域网被称为以太网（Ethernet），以纪念 19 世纪物理学家们苦苦追寻的“光以太”。如今，以太网已正式被定义为 IEEE 标准 802.3，它管理并发展了 CSMA/CD 协议和物理传输技术 [IEEE 802.3]。
|
||||
|
||||
|
||||
|
||||
Ethernet basiert in seiner ursprünglichen Form auf einer Broadcast-Technik, bei der alle Komponenten an das selbe Medium angeschlossen sind, wie in Abbildung 2.4 dargestellt. Sendet eine Komponente Daten, so werden diese von jeder anderen Komponente empfangen. Senden mehrere Komponenten gleichzeitig, entsteht eine Datenkollision, so dass letztendlich keine Daten übertragen werden können. Bei einer Kollision treffen die Signale im Medium aufeinander, wodurch Interferenzen entstehen, so dass die ursprünglichen Signale nicht mehr unterscheidbar sind (siehe Kapitel 2.1). Aus diesem Grund benutzt Ethernet CSMA/CD, ein Verfahren um die Nutzung des gemeinsamen Mediums zu koordinieren. Die meisten heutigen Ethernet-Netze sind Sterntopologien, bei denen jeder Endpunkt (z.B. Rechner) exklusiv mit einem Switch-Port verbunden ist.
|
||||
|
||||
以太网在其最初的形式中基于广播技术，所有组件连接到相同的媒介，如图 2.4 所示。当一个组件发送数据时，其他所有组件都能接收到。如果多个组件同时发送，则会发生数据碰撞，导致数据无法传输。在碰撞中，信号在介质中相互干扰，原始信号无法区分（参见章节 2.1）。因此，以太网使用 CSMA/CD 协议来协调共享介质的使用。大多数现代以太网网络使用星型拓扑结构，每个终端（如计算机）独立连接到一个交换机端口。
|
||||
|
||||
## 2.4 Virtuelle Topologien 虚拟拓扑
|
||||
|
||||
Endeinrichtungen (Rechner) werden in der Praxis bestimmten Aufgaben oder Rollen einer Organisation zugeordnet, statt den Gegebenheiten der Vernetzung: Es ist z.B. wünschenswert, die Rechner nach Abteilungen bzw. Bereichen zu gruppieren. Oft entspricht dabei die physische Topologie, die durch die verlegten Medien (“Kabel”) gegeben ist, nicht den Nutzungsanforderungen eines LANs: z.B. werden Server in gemeinsam genutzten Server-Räumen untergebracht, in denen sich alle Server die selbe Leitung aus dem Raum hinaus teilen. Meist ist es jedoch so, dass sensible Daten nicht in andere LANs als dem abteilungseigenen LAN gelangen dürfen.
|
||||
|
||||
在实践中，终端设备（计算机）通常根据组织的特定任务或角色进行分配，而不是根据网络连接的物理位置。例如，最好按部门或区域对计算机进行分组。通常，物理拓扑（由布设的介质“电缆”决定）并不符合 LAN 的实际使用需求：例如，服务器被安置在共享的服务器房间中，在该房间内所有服务器共用一条对外连接的线路。然而，通常情况下，敏感数据不应流出部门专用的 LAN。
|
||||
|
||||
Hierzu können sogenannte virtuelle LANs (VLAN) benutzt werden, die eine logische LAN-Topologie auf eine physische aufbringen. VLANs können auf mehrere Arten erzeugt werden: durch die Gruppierung von Ports an einem Switch, durch Gruppierung von MAC-Adressen der zu einer Gruppe gehörenden Rechner und durch eine entsprechende Markierungen (engl. tagging) der gesendeten Rahmen. Im Praktikum liegt dabei der Schwerpunkt auf der zuletzt genannten Technik.
|
||||
|
||||
为此，可以使用所谓的虚拟局域网（VLAN），将逻辑局域网拓扑应用于物理局域网。 创建 VLAN 有几种方法：将交换机上的端口分组、将属于一个组的计算机的 MAC 地址分组以及对发送的帧进行标记。 在实践课程中，重点是后一种技术。
|
||||
|
||||
Ein wichtiger Standard in diesem Kontext ist der IEEE-Standard 802.1q [IEEE 802.1q], “Virtual LANs”. Dieser definiert das Anlegen, Betreiben und Verwalten von (mehreren) virtuellen LAN-Topologien innerhalb eines physischen LANs. Dazu wird jeder Rahmen einer virtuellen Infrastruktur mit einer für diese Infrastruktur eindeutigen Nummer (VLAN Identifier, VLAN-ID) in einem Feld (VLAN-Tag) im Ethernet-Header markiert. Netzkomponenten, die auf Schicht 2 operieren, können anhand der VLAN-ID Rahmen virtueller Topologien unterscheiden und unterschiedlich behandeln.
|
||||
|
||||
在此背景下，一个重要的标准是 IEEE 标准 802.1q [IEEE 802.1q]，即“虚拟 LAN”。该标准定义了在一个物理 LAN 内创建、操作和管理（多个）虚拟 LAN 拓扑的方法。为此，每个帧在以太网头部的一个字段中用一个唯一的编号（VLAN 标识符，VLAN-ID）进行标记。工作在第 2 层的网络组件可以根据 VLAN-ID 区分和不同处理虚拟拓扑中的帧。
|
||||
|
||||
### 2.4.1 Monitoring-Port Konzept 监控端口概念
|
||||
|
||||
Administrierbare Switches bieten meist die Funktion eines Monitoring-Ports. Dabei wird ein bestimmter Port des Switches ausgewählt, auf dem der Switch jeden Rahmen repliziert, der auf einem der anderen Switch-Ports empfangen wird. Diese Funktion ermöglicht es, jeden Rahmen, der vom Switch verarbeitet wird, an zentraler Stelle zu sammeln. Da die Übertragungsrate eines Monitoring-Ports meist deutlich kleiner ist als die aller anderen Ports zusammen, kann ein Monitoring-Port ab einer gewissen Auslastung nicht alle Rahmen replizieren. Aus diesem Grund werden Monitoring-Ports häufig nur zur Fehleranalyse eingesetzt. Das Konzept des Monitoring-Ports kann auch virtualisiert umgesetzt werden.
|
||||
可管理的交换机通常提供监控端口的功能。通过该功能，可以选择交换机上的一个特定端口，该端口将会复制交换机在其他端口接收到的每个数据帧。这项功能使得可以在中央位置收集交换机处理的每个数据帧。由于监控端口的传输速率通常明显低于其他所有端口的总和，当负载达到一定程度时，监控端口可能无法复制所有的数据帧。因此，监控端口通常仅用于故障分析。监控端口的概念也可以虚拟化实现。
|
||||
|
||||
|
||||
|
||||
Abbildung 2.5 zeigt ein Beispiel in dem die Rechner rnpserver und rnpclient über (rnpserver-eth1, S01-A-4) und (S01-D-2, rnpclient-eth1) verbunden sind. Außerdem ist der Rechner rnpmgmt mit dem Switch S01 verbunden. Wird der Switch-Port S01-B-4 als Management-Port konfiguriert, so empfängt der Rechner rnpmgmt an seiner Schnittstelle eth1 alle Rahmen, die rnpserver und rnpclient austauschen. Dies ermöglicht es die Interaktion dieser beiden Rechner zu überwachen, ohne direkten Zugang zu haben.
|
||||
|
||||
图 2.5 显示了一个示例，其中计算机 rnpserver 和 rnpclient 分别通过 (rnpserver-eth1, S01-A-4) 和 (S01-D-2, rnpclient-eth1) 连接。此外，计算机 rnpmgmt 连接到交换机 S01。如果将 S01-B-4 端口配置为管理端口，则计算机 rnpmgmt 会在其接口 eth1 上接收到 rnpserver 和 rnpclient 之间交换的所有数据帧。这使得可以在不直接访问的情况下监控这两台计算机的交互。
|
||||
|
||||
Das Einrichten eines Management-Ports ist eine spezielle Funktion, die von der Konfigurationssoftware der Switches bereitgestellt wird.
|
||||
配置管理端口是一项特殊功能，由交换机的配置软件提供。
|
||||
|
||||
## 2.5 TUN/TAP Devices TUN/TAP 设备
|
||||
|
||||
Linux bietet seit Kernel-Version 2.2 die Möglichkeit virtueller Treiber-Schnittstellen an, sogenannte TUN/TAP Devices. TUN/TAP Devices existieren nur im Kernel und haben im Vergleich zu gewöhnlichen Schnittstellen keine physische Komponente. Falls das Betriebssystem Daten an ein TUN/TAP Device sendet, wird die Nachricht nicht an das physische Device, sondern an eine Benutzeranwendung, die über ein File-Descriptor mit dem TUN/TAP Device verbunden ist, weitergegeben. Was dann tatsächlich mit den Daten passiert, bleibt der Anwendung überlassen. Ein typisches Einsatzgebiet ist Tunneling, wie es beispielsweise in Virtual Private Networks (VPNs) der Fall ist. Durch den Einsatz von TUN Devices empfängt die VPN-Anwendung alle IP-Pakete, verschlüsselt deren Payload und umrahmt das ursprüngliche IP-Paket in ein weiteres IP-Paket mit aktualisierten Header-Informationen. Der Unterschied zwischen TUN und TAP Interfaces liegt darin, dass TAP Devices auf Schicht 2 und TUN Devices auf Schicht 3 operieren. Diese Unterscheidung ist wichtig, denn je nach Anwendungsfall ergeben sich entsprechende Anforderungen. Für VPN-Anwendungen bspw. sind TUN Devices auf Schicht 3 ausreichend. Eine ausführliche Dokumentation findet sich in der Linux-Kernel Dokumentation.
|
||||
自 Linux 内核版本 2.2 起，提供了虚拟驱动接口的功能，即所谓的 TUN/TAP 设备。TUN/TAP 设备仅存在于内核中，与普通接口相比没有物理组件。如果操作系统将数据发送到 TUN/TAP 设备，该消息不会被传送到物理设备，而是传递给通过文件描述符与 TUN/TAP 设备连接的用户应用程序。之后数据的实际处理由应用程序决定。TUN/TAP 设备的一个典型应用领域是隧道技术，例如在虚拟专用网络 (VPN) 中。通过使用 TUN 设备，VPN 应用程序可以接收所有的 IP 数据包，加密其有效负载，并将原始 IP 包封装到一个新的 IP 包中，且附上更新的头信息。TUN 和 TAP 接口的区别在于，TAP 设备工作在第 2 层，而 TUN 设备工作在第 3 层。这个区别很重要，因为不同的应用场景有不同的需求。例如，对于 VPN 应用来说，TUN 设备在第 3 层就足够了。详细的文档可以在 Linux 内核文档中找到。
|
||||
|
||||
Im Rahmen dieses Praktikums setzen wir TUN/TAP Devices dazu ein, um unseren eigenen Netzwerk-Stack zu implementieren. Ein einfaches Beispiel findet sich in der beigelegten Mini-Anwendung. Bevor ein TUN/TAP Device genutzt werden kann, erzeugen wir zunächst ein virtuelles Device. Hierzu nutzen wir das allseits bekannte Tool iproute (ip).
|
||||
在本次实习中，我们将使用 TUN/TAP 设备来实现自己的网络栈。一个简单的示例可以在附带的 Mini 应用中找到。在使用 TUN/TAP 设备之前，我们首先创建一个虚拟设备。为此，我们使用常用的 iproute 工具（ip）。
|
||||
|
||||
```bash
|
||||
$ ip tuntap help
|
||||
Usage: ip tuntap { add | del } [ dev PHYS_DEV ]
|
||||
[ mode { tun | tap } ] [ user USER | group GROUP ]
|
||||
[ one_queue ] [ pi ] [ vnet_hdr ]
|
||||
Where: USER := { STRING | NUMBER }
|
||||
GROUP := { STRING | NUMBER }
|
||||
```
|
||||
|
||||
Nachdem ein physisches Device erzeugt wurde, setzen wir das Device zunächst auf den Status up und geben ihm anschließend ein Netz bzw. eine fixe Host-Adresse. Mit der richtigen Konfiguration wird jeglicher Datenverkehr durch das das TUN/TAP Device geleitet.
|
||||
创建物理设备后，我们首先将设备设置为 up 状态，然后为其分配一个网络或固定的主机地址。通过正确的配置，所有的数据流都将通过 TUN/TAP 设备。
|
||||
|
||||
### 2.5.1 Virtuelle Schnittstellen unter Linux
|
||||
|
||||
|
||||
|
||||
Allgemein kann man sagen: Virtualisierung ist die Abstraktion von starren, beschränkenden Randbedingungen eines Systems zu konfigurierbaren Eigenschaften. Im Fall von virtuellen Schnittstellen bedeutet Virtualisierung, dass man die Anzahl der Schnittstellen eines Rechners verändern kann. Freilich lassen sich dadurch nicht mehr Kabel mit einem Rechner verbinden als physische Schnittstellen vorhanden sind. Trotzdem erhöhen sich die Möglichkeiten im Management.
|
||||
一般而言，虚拟化是将系统的固定、受限条件抽象成可配置的特性。在虚拟接口的情况下，虚拟化意味着可以更改计算机的接口数量。尽管如此，通过虚拟化并不能增加与计算机连接的实际电缆数量，只能使用物理接口。然而，这样可以增加管理方面的灵活性。
|
||||
|
||||
Im Rahmen dieses Praktikums bieten virtuelle Schnittstellen den Mehrwert, dass man über eine physische Verbindung mehrere logische Verbindungen betreiben kann (vgl. Abbildung 2.6).
|
||||
在这个实践中，虚拟接口的优势在于可以通过一个物理连接运行多个逻辑连接（参见图2.6）。
|
||||
|
||||
Jeder virtuellen Schnittstelle kann außer eigenen IP-Adressen auch eine eigene VLAN-ID zugewiesen werden. Es ist somit möglich, mit nur einer physischen Verbindung einen Rechner in mehrere virtuelle LANs einzubinden.
|
||||
每个虚拟接口除了可以分配独立的IP地址外，还可以分配独立的VLAN ID。这使得仅通过一个物理连接就可以将计算机连接到多个虚拟局域网（VLAN）。
|
||||
|
||||
Es ist möglich einer einzelnen Schnittstelle mehrere IPs zuzuweisen und so einen Rechner in mehrere Subnets (z.B. 192.168.1/24 und 192.168.2/24) einzubinden. Der wesentliche Unterschied zum Einsatz virtueller Schnittstellen und VLANs liegt darin, dass virtuelle Schnittstellen bereits auf OSI-Schicht 2 implementiert werden, eine Trennung auf IP-Ebene jedoch eine Funktion von OSI-Schicht 3 ist.
|
||||
还可以给一个单独的接口分配多个IP地址，从而将计算机连接到多个子网（例如192.168.1/24和192.168.2/24）。虚拟接口和VLAN的主要区别在于虚拟接口在OSI模型的第2层实现，而IP层的隔离是OSI第3层的功能。
|
||||
|
||||
Anlegen virtueller Schnittstellen mit VLAN-ID:
|
||||
带VLAN ID的虚拟接口创建：
|
||||
|
||||
Das Anlegen von virtuellen Schnittstellen ist ebenfalls eine Funktion, die mit dem Befehl `ip` realisiert werden kann. Die Syntax zum Anlegen einer VLAN-Schnittstelle ist:
|
||||
可以通过`ip`命令创建虚拟接口。创建VLAN接口的命令语法为：
|
||||
|
||||
```
|
||||
# ip link add link <pNIC> name <vNIC> type vlan id <VLAN-ID>
|
||||
```
|
||||
mit
|
||||
其中
|
||||
|
||||
- `pNIC` := Name der physischen Schnittstelle
|
||||
`pNIC`：物理接口的名称
|
||||
- `vNIC` := Name der virtuellen Schnittstelle
|
||||
`vNIC`：虚拟接口的名称
|
||||
|
||||
z.B.:
|
||||
```
|
||||
# ip link add link eth0 name eth0.100 type vlan id 100
|
||||
```
|
||||
|
||||
Zum Entfernen einer virtuellen Schnittstelle benutzen Sie: 删除虚拟接口的命令：
|
||||
```
|
||||
# ip link del dev <vNIC>
|
||||
```
|
||||
z.B.: 例如：
|
||||
```
|
||||
# ip link del dev eth0.100
|
||||
```
|
||||
|
||||
## 2.6 Scapy
|
||||
|
||||
### 原文内容：
|
||||
|
||||
#### 图片 1:
|
||||
|
||||
**2.6 Scapy**
|
||||
|
||||
Scapy ist ein Python Framework zur Inspektion und Manipulation von Paketen. Es erlaubt Ihnen Pakete vieler bereits implementierter Protokolle zu protokollieren, zu dekodieren, aus pcap-Dateien zu lesen, zu erstellen sowie diese zu versenden und vieles mehr. Scapy wurde auch für schnelles Prototyping entwickelt und benutzt Defaultwerte, die funktionieren.
|
||||
Scapy 是一个用于数据包检查和操作的 Python 框架。它允许您记录、解码许多已实现协议的数据包，从 pcap 文件中读取或创建数据包并发送等。Scapy 还适用于快速原型设计，并使用默认值，保证基本功能可用。
|
||||
|
||||
Viele Aufgaben anderer Tools können von Scapy übernommen werden, z.B. Scanning, Traceroutes, Unit-Tests, Netzwerkerkennung und verschiedene Angriffe. Außerdem können Sie auch ungültige Rahmen versenden, eigene 802.11 Rahmen einbauen und verschiedene Techniken kombinieren (VLAN hopping + ARP cache poisoning, VoIP-Dekodierung auf einem WEP-verschlüsselten Kanal, etc.).
|
||||
许多其他工具的任务可以由 Scapy 完成，例如扫描、路由追踪、单元测试、网络检测和多种攻击。此外，您还可以发送无效的帧、创建自定义的 802.11 帧，并组合各种技术（如 VLAN 跳跃 + ARP 缓存中毒、在 WEP 加密的信道上解码 VoIP 数据包等）。
|
||||
|
||||
#### 2.6.1 Installation auf der Infrastruktur
|
||||
|
||||
`// On Debian`
|
||||
`apt-get install python3-scapy`
|
||||
|
||||
`// On OpenWRT`
|
||||
`opkg update; opkg install scapy`
|
||||
|
||||
#### 2.6.2 Usage
|
||||
|
||||
Eine kleine Übersicht:
|
||||
以下是简要概述：
|
||||
|
||||
- Verschiedene Protokolle und Header sind als Klassen implementiert, wie IPv6 oder ICMP.
|
||||
各种协议和头部作为类实现，例如 IPv6 或 ICMP。
|
||||
- Protokolle können ineinander geschachtelt werden mit dem Slash-Operator, z.B.: IPv6()/TCP() erstellt ein TCP-over-IPv6 Paket.
|
||||
可以使用斜杠操作符嵌套协议，例如 `IPv6()/TCP()` 创建一个 TCP-over-IPv6 包。
|
||||
- Pakete können mit den Methoden show und show2 angezeigt werden, für das Senden bzw. Senden und Empfangen siehe send(), sendp(), sr(), sr1() und srp().
|
||||
可以使用 `show` 和 `show2` 方法显示数据包；发送和接收请参考 `send()`、`sendp()`、`sr()`、`sr1()` 和 `srp()`。
|
||||
- Die meisten Headeroptionen können verändert werden. Setzen Sie diese entweder im Konstruktor oder über Membervariablen, z.B.: p = IP(ttl=64)
|
||||
大多数头选项可以更改。可以在构造函数中或通过成员变量设置这些选项，例如：`p = IP(ttl=64)`。
|
||||
- Nicht alle Optionen müssen angegeben werden, Scapy befüllt solche Werte mit Defaults.
|
||||
并非所有选项都必须指定，Scapy 会自动填充默认值。
|
||||
- Eine Liste aller Funktionen bekommen Sie über die Funktion ls().
|
||||
使用 `ls()` 函数可以查看所有功能列表。
|
||||
- Für weitere Informationen und eine Demonstration, siehe https://scapy.net/
|
||||
更多信息和演示，请访问 [https://scapy.net](https://scapy.net/)
|
||||
|
||||
## 2.7 Aufgaben
|
||||
|
||||
**Hinweis**: vergessen Sie nicht Ihre Konfiguration in Netzplänen zu dokumentieren und auch die relevanten Ausgaben der verwendeten Programme zu übernehmen!
|
||||
**提示**: 请不要忘记在网络图中记录您的配置，并包含所用程序的相关输出！
|
||||
|
||||
---
|
||||
|
||||
### A200 Address Resolution and Neighbor Discovery (Theorie)
|
||||
|
||||
Das RFC 826 definiert das Address Resolution Protocol (ARP). In RFC 4861 wird das Neighbor Discovery Protocol (NDP) spezifiziert.
|
||||
RFC 826 定义了地址解析协议（ARP）。RFC 4861 规定了邻居发现协议（NDP）。
|
||||
|
||||
1. **Wozu wird ARP eingesetzt? Was ist der Unterschied zu NDP?**
|
||||
**ARP 的用途是什么？它与 NDP 的区别是什么？**
|
||||
2. **Beschreiben Sie den Aufbau einer ARP-PDU und erläutern Sie die Bedeutung der einzelnen Felder!**
|
||||
**描述 ARP-PDU 的结构并解释各个字段的含义！**
|
||||
3. **Welche unterschiedlichen ARP-PDUs gibt es? Welche NDP-PDUs gibt es?**
|
||||
**有哪些不同的 ARP-PDU？NDP-PDU 又有哪些？**
|
||||
4. **Wie lang (in Bytes) ist eine ARP-PDU in einem Netz in dem IPv4 und Ethernet eingesetzt werden?**
|
||||
**在 IPv4 和以太网网络中，ARP-PDU 的长度是多少字节？**
|
||||
5. **Wie lang (in Bytes) ist eine Neighbor Solicitation Nachricht?**
|
||||
**Neighbor Solicitation 消息的长度是多少字节？**
|
||||
6. **Das RFC 826 spricht von einer Tabelle (table), deren Implementierung meist als ARP-Cache bezeichnet wird. Was soll laut RFC mit einer Ethernet-SDU passieren, wenn kein Eintrag zur Ziel-IP-Adresse in der Tabelle gefunden wird?**
|
||||
**RFC 826 提到了一张表（table），其实现通常称为 ARP 缓存。RFC 规定如果表中没有找到目标 IP 地址的条目，对以太网 SDU 应该怎么处理？**
|
||||
|
||||
### A201 VLANs nach IEEE 802.1q
|
||||
|
||||
Virtuelle Infrastrukturen dienen dazu Netze anzulegen und anzupassen zu können, ohne physisch an den Geräten arbeiten zu müssen. Dies ist insbesondere in großen, weniger übersichtlichen Infrastrukturen von Vorteil.
|
||||
虚拟基础设施的目的是在无需直接物理操作设备的情况下创建和调整网络配置。尤其在大型、结构不明确的基础设施中，这种方法具有优势。
|
||||
|
||||
Nachdem Sie in Aufgabe A101 die Topologie der virtuellen Infrastruktur vollständig rekonstruiert haben, ändern Sie diese im Folgenden.在您完成任务**A101**中虚拟基础设施拓扑的重建之后，按照以下步骤进行修改。
|
||||
|
||||
1. **Modifizieren Sie die Topologie Ihrer virtuellen Infrastruktur so, dass die Router 1,2 und 3 ausschließlich Switches (Bridges) sind. Fügen Sie dieser Bridge alle Interfaces bis auf eth0 hinzu. (Hinweis: Benutzen Sie `ip link`, siehe Referenz^3）**
|
||||
修改您的虚拟基础设施拓扑，使路由器 1、2 和 3 仅包含交换机（桥接器）。将所有接口（除了 eth0 以外）加入该桥接器。（提示：使用 `ip link`，参考文献^3）
|
||||
|
||||
Die PCs 1–3 sowie Router 4 sind Hosts, die in einem (Sub-)Netz gemäß der Baum-Topologie in Abbildung 2.7 verbunden sind. Es genügt hierbei, wenn Sie überflüssige Links als `down` markieren.
|
||||
PC1–3 和路由器 4 是主机，根据图 2.7 的树状拓扑结构连接在同一子网中。这里只需要将冗余的链路标记为 `down`。
|
||||
|
||||
|
||||
|
||||
2. **Testen Sie ihre Verbindungen zwischen den PCs 1–3 sowie Router 4 mittels `ping`。Router 1–3 haben per Definition von Bridges keine IP-Adresse. Vergeben Sie IPv4-Adressen aus Ihrem Adressraum。**
|
||||
通过 `ping` 命令测试 PC1–3 和路由器 4 之间的连接。根据桥接器的定义，路由器 1–3 不会有 IP 地址。请为它们分配 IPv4 地址。
|
||||
|
||||
3. **Derzeit befinden sich alle Hosts im selben Netz. In dieser Aufgabe soll das Netz in zwei logisch getrennte VLANs (Schicht 2) aufgeteilt werden. Ziel ist es, dass Router 4 und PC3 in einem VLAN sowie PC2 und PC1 in einem anderen VLAN voneinander isoliert sind。**
|
||||
当前，所有主机都在同一网络中。在本任务中，将网络划分为两个逻辑上独立的 VLAN（第二层）。目标是将路由器 4 和 PC3 放在一个 VLAN 中，将 PC2 和 PC1 放在另一个 VLAN 中，使它们彼此隔离。
|
||||
第三层地址将保持不变。预期的结果是仅在 VLAN 内可以进行通信。例如，路由器 4 只能与 PC3 通信，而无法与 PC1 和 PC2 通信，即便它们在第三层的同一子网中。
|
||||
|
||||
使用 `ping` 测试您的配置，并通过 `tcpdump`（在路由器 1–3 上）验证 ICMP 请求是否基于 VLAN ID 在 VLAN 内部进行通信。
|
||||
|
||||
|
||||
|
||||
### **A202 ARP 和 NDP 分析**
|
||||
|
||||
使用与上一个任务相同的拓扑结构。如果有 VLAN，请将其移除。
|
||||
|
||||
i) 解释 pc1 上的 `ip neigh` 命令输出！
|
||||
|
||||
ii) 清空 pc1 和 pc2 上的 ARP 缓存！（提示：`ip neigh`）
|
||||
|
||||
iii) 确保 PC 的接口拥有 Link-Local IPv6 地址。（提示：`ip link [down/up]`）
|
||||
|
||||
iv) 使用 `ping` 和 `ping6` 在 pc1 和 pc2 之间生成 IP 流量。`ip neigh` 输出有何变化？
|
||||
|
||||
v) 使用 `tcpdump` 观察从 IP 地址到 MAC 地址的解析。请求解析的 MAC 地址分别发送给哪些 MAC 地址？是否是广播？
|
||||
|
||||
vi) 为您的 PC 添加以下网络的 IPv6 地址：`2001:db8:<组号>::/64`
|
||||
|
||||
vii) 使用新添加的全局地址重复 IPv6 测试。解释这些差异！
|
||||
|
||||
viii) 比较 `tcpdump` 和 `scapy` 的输出。使用 `scapy` 显示 ARP/Neighbor Solicitation (NS) 数据包的详细信息。
|
||||
|
||||
ix) 使用 `scapy` 发送 ARP 和 NS 数据包从 pc1 发出。（提示：`Ether` 和 `sendp()`）
|
||||
|
||||
查看 pc2 和 pc3 是否接收到这些数据包？它们如何响应这些请求？检查 pc1 收到的回复！
|
||||
|
||||
x) 使用 `scapy` 发送带有新 MAC 地址的 ARP Reply 和 Neighbor Advertisement (NA) 数据包从 pc1 发给 pc2。查看 pc2 的邻居缓存在接收到数据包后有何反应？
|
||||
|
||||
### **A203 在 C 中实现 ARP**
|
||||
|
||||
任务是独立实现 ARP 协议 (参见 RFC 826)。目标是基于 TUN/TAP 设备，在网络内拦截数据流，并通过工具 `arping` 对 ARP 请求发送语义和语法正确的 ARP 响应。
|
||||
|
||||
i) 熟悉 TUN/TAP 设备的工作原理，并使用小应用程序 `tuntap.c` 检查您的配置是否正确。
|
||||
|
||||
ii) 为 ARP 请求和响应选择一个合适的接口，并在一个头文件中记录。阅读 RFC 826 以获得相关信息。
|
||||
|
||||
iii) 实现您指定的接口，使其能够正确响应 `arping` 请求。您可以为响应分配任意 IP 地址和 MAC 地址。
|
||||
|
||||
`arping` 请求示例：
|
||||
```bash
|
||||
$ arping -I mytap <ip>
|
||||
```
|
||||
|
||||
## Appendix
|
||||
|
||||
### SDU
|
||||
|
||||
**SDU**（Service Data Unit，服务数据单元）是计算机网络中的一个概念，指的是在网络协议层之间传递的数据单元。在分层网络模型中，SDU 是上一层协议或服务要传递给下一层协议或服务的数据。SDU 的数据内容在传递到下一层时可能会被封装成一个新的数据单元（PDU，Protocol Data Unit，协议数据单元）。
|
||||
|
||||
#### SDU 的作用
|
||||
|
||||
在分层网络模型中，每一层协议对上一层的 SDU 进行处理，将其封装、分片或添加头信息后，传递到下一层。这一过程在数据从高层（如应用层）到低层（如物理层）时会反复发生，直到数据在物理层上被传输出去。SDU 是分层结构中数据传递的基础单位。
|
||||
|
||||
#### SDU 与 PDU 的关系
|
||||
|
||||
- **SDU（Service Data Unit）**：是传递给下一层协议的数据单元，通常包含应用层或上层协议层的数据。
|
||||
- **PDU（Protocol Data Unit）**：是将 SDU 封装后，加入本层协议的控制信息（例如头部和尾部）形成的完整数据包。PDU 是每一层协议的实际传输单元。
|
||||
|
||||
|
||||
在一层协议中，SDU 被处理和封装成 PDU，然后传递给下一层。例如：
|
||||
1. 传输层将应用层的 SDU 封装成传输层 PDU（例如 TCP 段或 UDP 数据报）。
|
||||
2. 网络层将传输层的 PDU 封装成网络层 PDU（如 IP 数据报）。
|
||||
3. 链路层将网络层的 PDU 封装成链路层 PDU（如以太网帧）。
|
||||
|
||||
假设一个应用程序发送一个数据单元到网络中，这个数据单元会经历多个协议层的封装过程：
|
||||
|
||||
1. **应用层**：应用层生成一个 SDU（例如 HTTP 请求），并将其传递给传输层。
|
||||
2. **传输层**：传输层将应用层的 SDU 封装为传输层的 PDU（例如 TCP 段），并将其传递给网络层。
|
||||
3. **网络层**：网络层将传输层的 PDU 作为 SDU，然后封装为网络层的 PDU（例如 IP 数据报），传递给数据链路层。
|
||||
4. **数据链路层**：链路层将网络层的 PDU 作为 SDU，封装为链路层 PDU（例如以太网帧），最后在物理层上传输。
|
||||
|
||||
### TUN and TAP
|
||||
|
||||
**TUN** 和 **TAP** 是 Linux 和其他操作系统中的两种虚拟网络设备，用于处理网络流量。它们分别用于 **三层（网络层）** 和 **二层（数据链路层）** 网络通信。
|
||||
|
||||
#### 1. TUN 接口
|
||||
|
||||
- **TUN** 代表 **"network TUNnel"**。
|
||||
- TUN 是一个虚拟的三层（网络层）设备，模拟的是 IP 层。
|
||||
- 它处理的是 **IP 数据包**（如 IPv4 或 IPv6），可以看作是虚拟的网卡，但只处理三层协议。
|
||||
- 当应用程序通过 TUN 接口发送 IP 数据包时，操作系统会将这些数据包交给一个用户空间程序，该程序可以对数据包进行处理或转发。
|
||||
- 常用于 **VPN**（如 OpenVPN）的三层隧道，实现私有网络之间的安全通信。
|
||||
|
||||
**工作方式**：
|
||||
- TUN 接口会将 IP 数据包从内核空间转发到用户空间的 VPN 程序。
|
||||
- VPN 程序加密或解密数据包后，再通过 TUN 接口发送到网络中，或转发到目标设备。
|
||||
|
||||
**示例**：OpenVPN 的 TUN 模式使用三层隧道，仅处理 IP 数据包，适用于没有广播流量需求的网络（如 Internet 流量）。
|
||||
|
||||
#### 2. TAP 接口
|
||||
|
||||
- **TAP** 代表 **"network TAP"**，意为网络接入点。
|
||||
- TAP 是一个虚拟的二层（数据链路层）设备，模拟的是以太网设备。
|
||||
- 它处理的是 **以太网帧**，包括 IP、ARP 等协议层的封装。
|
||||
- TAP 接口允许虚拟网络设备和物理网络一样传输以太网帧，因此可以处理广播和多播流量。
|
||||
- 常用于虚拟机（如 KVM、VirtualBox）和容器的二层连接，允许虚拟机像在同一个局域网内一样通信。
|
||||
|
||||
**工作方式**：
|
||||
- TAP 接口可以在二层网络中直接传输以太网帧，包含源 MAC 地址、目标 MAC 地址和协议字段。
|
||||
- 它将这些帧转发到用户空间程序进行处理，程序可以将它们转发到其他网络或应用程序。
|
||||
|
||||
**示例**：OpenVPN 的 TAP 模式使用二层隧道，适用于需要广播或多播的场景，如与局域网相连的虚拟网络环境。
|
||||
|
||||
#### 区别总结
|
||||
|
||||
| 特性 | TUN（网络隧道） | TAP（接入点） |
|
||||
| ------------ | ----------------------- | ------------------------------ |
|
||||
| 层次 | 三层（网络层） | 二层（数据链路层） |
|
||||
| 处理数据类型 | IP 数据包（IPv4、IPv6） | 以太网帧（包括 MAC 地址） |
|
||||
| 广播支持 | 不支持 | 支持 |
|
||||
| 应用场景 | 三层 VPN（不需要广播） | 二层 VPN、虚拟机局域网连接 |
|
||||
| 常用协议 | 仅传输 IP 层协议 | 可以传输任意二层协议（如 ARP） |
|
||||
|
||||
#### 何时使用 TUN 和 TAP
|
||||
|
||||
- **使用 TUN**：如果只需要在网络层传输 IP 数据包，且不需要局域网的广播和多播功能，例如 Internet 访问的三层 VPN。
|
||||
- **使用 TAP**：如果需要在二层连接多个设备，支持以太网帧级别的通信（包括广播和多播），如多个虚拟机在同一局域网内通信的二层 VPN。
|
||||
|
||||
#### 工具支持
|
||||
|
||||
- **`ip tuntap`**：可以在 Linux 上创建和管理 TUN 和 TAP 设备。
|
||||
- **OpenVPN**：支持 TUN 和 TAP 两种模式，用户可以根据需求选择相应的接口类型。
|
||||
- **虚拟化平台**（如 KVM、VirtualBox）：通常使用 TAP 接口来实现虚拟机与主机网络的连接。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
BIN
Blatt02/RNP24-intro-blatt2.pdf
Normal file
BIN
Blatt02/RNP24-intro-blatt2.pdf
Normal file
Binary file not shown.
BIN
Blatt02/assets/image-20241107104045466.png
Normal file
BIN
Blatt02/assets/image-20241107104045466.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 40 KiB |
BIN
Blatt02/assets/image-20241107104458429.png
Normal file
BIN
Blatt02/assets/image-20241107104458429.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 22 KiB |
BIN
Blatt02/assets/image-20241107104505851.png
Normal file
BIN
Blatt02/assets/image-20241107104505851.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
BIN
Blatt02/assets/image-20241107110237030.png
Normal file
BIN
Blatt02/assets/image-20241107110237030.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 16 KiB |
BIN
Blatt02/assets/image-20241107123004937.png
Normal file
BIN
Blatt02/assets/image-20241107123004937.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 42 KiB |
BIN
Blatt02/assets/image-20241107123017893.png
Normal file
BIN
Blatt02/assets/image-20241107123017893.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 29 KiB |
BIN
Blatt02/assets/image-20241107213435124.png
Normal file
BIN
Blatt02/assets/image-20241107213435124.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 64 KiB |
BIN
Blatt02/assets/image-20241110210209022.png
Normal file
BIN
Blatt02/assets/image-20241110210209022.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
BIN
Blatt02/assets/image-20241114215255732.png
Normal file
BIN
Blatt02/assets/image-20241114215255732.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 257 KiB |
BIN
Blatt02/assets/image-20241114221022240.png
Normal file
BIN
Blatt02/assets/image-20241114221022240.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 45 KiB |
BIN
Blatt02/assets/image-20241120144256948.png
Normal file
BIN
Blatt02/assets/image-20241120144256948.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 55 KiB |
BIN
Blatt02/assets/image-20241120184425244.png
Normal file
BIN
Blatt02/assets/image-20241120184425244.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 213 KiB |
BIN
Blatt02/rnp-aufgabenblock2.pdf
Normal file
BIN
Blatt02/rnp-aufgabenblock2.pdf
Normal file
Binary file not shown.
83
Blatt02/scripts/101.sh
Normal file
83
Blatt02/scripts/101.sh
Normal file
@@ -0,0 +1,83 @@
|
||||
#!/bin/bash
|
||||
|
||||
echo "reboot to erase the old configurations;"
|
||||
bash ~/reboot.sh
|
||||
echo "rebooting"
|
||||
countdown=40
|
||||
while [ $countdown -gt 0 ]; do
|
||||
echo -ne "counting down: $countdown s \033[0K\r"
|
||||
sleep 1
|
||||
countdown=$((countdown - 1))
|
||||
done
|
||||
|
||||
assign_ip(){
|
||||
local dev=$1
|
||||
local eth_num=$2
|
||||
local ip=$3
|
||||
ssh $dev "ip link set dev eth$eth_num up"
|
||||
ssh $dev "ip addr add $ip dev eth$eth_num"
|
||||
echo "dev $dev eth$eth_num assign $ip"
|
||||
}
|
||||
|
||||
assign_br(){
|
||||
local dev=$1
|
||||
local ip=$2
|
||||
local ip_nocode=$3
|
||||
ssh $dev "ip link add name br0 type bridge"
|
||||
ssh $dev "ip link set dev br0 up"
|
||||
ssh $dev "ip address add $ip dev br0"
|
||||
ssh $dev "ip route append default via $ip_nocode dev br0"
|
||||
}
|
||||
|
||||
turn_up(){
|
||||
local dev=$1
|
||||
local eth_num1=$2
|
||||
local eth_num2=$3
|
||||
local eth_num3=$4
|
||||
ssh $dev "ip link set eth$eth_num1 up"
|
||||
ssh $dev "ip link set eth$eth_num1 master br0"
|
||||
ssh $dev "ip link set eth$eth_num2 up"
|
||||
ssh $dev "ip link set eth$eth_num2 master br0"
|
||||
ssh $dev "ip link set eth$eth_num3 up"
|
||||
ssh $dev "ip link set eth$eth_num3 master br0"
|
||||
}
|
||||
|
||||
ping_dev(){
|
||||
local dev=$1
|
||||
local ip=$2
|
||||
local eth_n=$3
|
||||
ssh $dev "which ping"
|
||||
local cmd="ping -c 5 -W 2 -I eth$eth_n $ip"
|
||||
echo $cmd
|
||||
ssh "$dev" $cmd
|
||||
}
|
||||
|
||||
assign_ip "pc1" 1 "10.5.1.1/24"
|
||||
|
||||
assign_ip "pc2" 1 "10.5.1.2/24"
|
||||
|
||||
assign_ip "pc3" 1 "10.5.1.3/24"
|
||||
|
||||
|
||||
assign_ip "router4" 1 "10.5.1.4/24"
|
||||
|
||||
|
||||
assign_br "router1" "10.5.1.5/24" "10.5.1.5"
|
||||
turn_up "router1" 1 3 4
|
||||
|
||||
assign_br "router2" "10.5.1.5/24" "10.5.1.5"
|
||||
turn_up "router2" 1 3 4
|
||||
|
||||
assign_br "router3" "10.5.1.6/24" "10.5.1.6"
|
||||
turn_up "router3" 1 2 3
|
||||
|
||||
ping_dev "pc1" "10.5.1.3" "1"
|
||||
ping_dev "router4" "10.5.1.3" "1"
|
||||
ping_dev "router4" "10.5.1.1" "1"
|
||||
ping_dev "router4" "10.5.1.2" "1"
|
||||
ping_dev "pc1" "10.5.1.4" "1"
|
||||
ping_dev "pc2" "10.5.1.4" "1"
|
||||
ping_dev "pc3" "10.5.1.4" "1"
|
||||
|
||||
|
||||
|
||||
73
Blatt02/scripts/103.sh
Normal file
73
Blatt02/scripts/103.sh
Normal file
@@ -0,0 +1,73 @@
|
||||
#!/bin/bash
|
||||
|
||||
bash /home/rnp/2/101.sh
|
||||
|
||||
echo "Now running 103.sh"
|
||||
|
||||
assign_vlan(){
|
||||
local dev=$1
|
||||
local eth=$2
|
||||
local id=$3
|
||||
local ip=$4
|
||||
ssh $dev "ip link add link $eth name $eth.$id type vlan id $id"
|
||||
ssh $dev "ip link set dev $eth.$id up"
|
||||
ssh $dev "ip addr flush dev $eth"
|
||||
ssh $dev "ip addr add $ip dev $eth.$id"
|
||||
}
|
||||
|
||||
assign_vlan "router4" "eth1" "100" "10.5.1.4/24"
|
||||
assign_vlan "pc3" "eth1" "100" "10.5.1.3/24"
|
||||
assign_vlan "pc2" "eth1" "200" "10.5.1.2/24"
|
||||
assign_vlan "pc1" "eth1" "200" "10.5.1.1/24"
|
||||
|
||||
ping_dev(){
|
||||
local dev=$1
|
||||
local ip=$2
|
||||
local eth_n=$3
|
||||
# ssh "$dev" $cmd
|
||||
loss=$(ssh $dev "ping -c 5 -W 2 -I eth$eth_n $ip | awk -F', ' '/packet loss/ {print \$3}' | awk '{print int(\$1)}'")
|
||||
output=$(ssh $dev "ping -c 5 -W 2 -I eth$eth_n $ip")
|
||||
echo $output > 2/output/"${dev}_${ip}_${eth_n}"
|
||||
echo $loss
|
||||
}
|
||||
|
||||
check(){
|
||||
local dev1=$1
|
||||
local dev2=$2
|
||||
local ping_loss=$3
|
||||
local num=$4
|
||||
echo $ping_loss
|
||||
if [ $ping_loss -eq $num ]; then
|
||||
echo -e "from $dev1 to $dev2: \t yes"
|
||||
else
|
||||
echo -e "from $dev1 to $dev2: \t no"
|
||||
fi
|
||||
}
|
||||
|
||||
loss=$(ping_dev "router4" "10.5.1.1" "1.100")
|
||||
check "router4" "pc1" "$loss" 100
|
||||
loss=$(ping_dev "router4" "10.5.1.2" "1.100")
|
||||
check "router4" "pc2" "$loss" 100
|
||||
loss=$(ping_dev "router4" "10.5.1.3" "1.100")
|
||||
check "router4" "pc3" "$loss" 0
|
||||
|
||||
loss=$(ping_dev "pc1" "10.5.1.2" "1.200")
|
||||
check "pc1" "pc2" "$loss" 0
|
||||
loss=$(ping_dev "pc1" "10.5.1.3" "1.200")
|
||||
check "pc1" "pc3" "$loss" 100
|
||||
loss=$(ping_dev "pc1" "10.5.1.4" "1.200")
|
||||
check "pc1" "router4" "$loss" 100
|
||||
|
||||
loss=$(ping_dev "pc2" "10.5.1.1" "1.200")
|
||||
check "pc2" "pc1" "$loss" 0
|
||||
loss=$(ping_dev "pc2" "10.5.1.3" "1.200")
|
||||
check "pc2" "pc3" "$loss" 100
|
||||
loss=$(ping_dev "pc2" "10.5.1.4" "1.200")
|
||||
check "pc2" "router4" "$loss" 100
|
||||
|
||||
loss=$(ping_dev "pc3" "10.5.1.1" "1.100")
|
||||
check "pc3" "pc1" "$loss" 100
|
||||
loss=$(ping_dev "pc3" "10.5.1.2" "1.100")
|
||||
check "pc3" "pc2" "$loss" 100
|
||||
loss=$(ping_dev "pc3" "10.5.1.4" "1.100")
|
||||
check "pc3" "router4" "$loss" 0
|
||||
67
Blatt02/scripts/201.sh
Normal file
67
Blatt02/scripts/201.sh
Normal file
@@ -0,0 +1,67 @@
|
||||
#!/bin/bash
|
||||
|
||||
bash /home/rnp/2/103.sh
|
||||
clear
|
||||
echo "************************************************************"
|
||||
bash /home/rnp/checkip.sh
|
||||
echo "************************************************************"
|
||||
echo "201" > /home/rnp/2/201.txt
|
||||
del_vlan(){
|
||||
local dev=$1
|
||||
local eth_v=$2
|
||||
local eth_p=$3
|
||||
local ip=$4
|
||||
ssh $dev "ip link delete $eth_v"
|
||||
ssh $dev "ip link set dev $eth_p up"
|
||||
ssh $dev "ip addr add $ip dev $eth_p"
|
||||
}
|
||||
|
||||
del_vlan "router4" "eth1.100" "eth1" "10.5.1.4/24"
|
||||
del_vlan "pc1" "eth1.200" "eth1" "10.5.1.1/24"
|
||||
del_vlan "pc2" "eth1.200" "eth1" "10.5.1.2/24"
|
||||
del_vlan "pc3" "eth1.100" "eth1" "10.5.1.3/24"
|
||||
|
||||
|
||||
assign_ip(){
|
||||
local dev=$1
|
||||
local eth=$2
|
||||
local ip=$3
|
||||
ssh $dev "ip addr add $ip dev $eth"
|
||||
}
|
||||
|
||||
echo "============================================================"
|
||||
bash /home/rnp/checkip.sh
|
||||
echo "============================================================"
|
||||
|
||||
|
||||
echo "pc1 neigh"
|
||||
ssh pc1 "ip neigh"
|
||||
echo "pc2 neigh"
|
||||
ssh pc2 "ip neigh"
|
||||
|
||||
echo "pc1 neigh" >> /home/rnp/2/201.txt
|
||||
ssh pc1 "ip neigh" >> /home/rnp/2/201.txt
|
||||
echo "pc2 neigh" >> /home/rnp/2/201.txt
|
||||
ssh pc2 "ip neigh" >> /home/rnp/2/201.txt
|
||||
|
||||
ping_dev(){
|
||||
local dev=$1
|
||||
local ip=$2
|
||||
local eth_n=$3
|
||||
ssh $dev "ping -c 5 -W 2 -I eth$eth_n $ip"
|
||||
}
|
||||
|
||||
ping_dev "pc1" "10.5.1.2" 1
|
||||
ping_dev "pc1" "10.5.1.3" 1
|
||||
ping_dev "pc1" "10.5.1.4" 1
|
||||
|
||||
ping_dev "pc2" "10.5.1.1" 1
|
||||
ping_dev "pc2" "10.5.1.3" 1
|
||||
ping_dev "pc2" "10.5.1.4" 1
|
||||
|
||||
echo "pc1 neigh-2" >> /home/rnp/2/201.txt
|
||||
ssh pc1 "ip neigh" >> /home/rnp/2/201.txt
|
||||
echo "pc2 neigh-2" >> /home/rnp/2/201.txt
|
||||
ssh pc2 "ip neigh" >> /home/rnp/2/201.txt
|
||||
|
||||
|
||||
15
Blatt02/scripts/201.txt
Normal file
15
Blatt02/scripts/201.txt
Normal file
@@ -0,0 +1,15 @@
|
||||
201
|
||||
pc1 neigh
|
||||
192.168.0.254 dev eth0 lladdr fe:ff:ff:ff:ff:ff DELAY
|
||||
pc2 neigh
|
||||
192.168.0.254 dev eth0 lladdr fe:ff:ff:ff:ff:ff DELAY
|
||||
pc1 neigh-2
|
||||
192.168.0.254 dev eth0 lladdr fe:ff:ff:ff:ff:ff REACHABLE
|
||||
10.5.1.2 dev eth1 lladdr 00:16:3e:00:00:04 STALE
|
||||
10.5.1.3 dev eth1 lladdr 00:16:3e:00:00:06 REACHABLE
|
||||
10.5.1.4 dev eth1 lladdr 00:16:3e:00:00:23 REACHABLE
|
||||
pc2 neigh-2
|
||||
10.5.1.3 dev eth1 lladdr 00:16:3e:00:00:06 REACHABLE
|
||||
192.168.0.254 dev eth0 lladdr fe:ff:ff:ff:ff:ff REACHABLE
|
||||
10.5.1.1 dev eth1 lladdr 00:16:3e:00:00:02 STALE
|
||||
10.5.1.4 dev eth1 lladdr 00:16:3e:00:00:23 REACHABLE
|
||||
25
Blatt02/scripts/202.sh
Normal file
25
Blatt02/scripts/202.sh
Normal file
@@ -0,0 +1,25 @@
|
||||
#!/bin/bash
|
||||
|
||||
bash /home/rnp/2/201.sh
|
||||
|
||||
echo "flush pc1 neigh"
|
||||
echo "ip neigh flush all"
|
||||
output=$(ssh pc1 "ip neigh flush all")
|
||||
echo $output > /home/rnp/2/202.txt
|
||||
echo $output
|
||||
output=$(ssh pc1 "ip neigh")
|
||||
echo $output
|
||||
echo $output >> /home/rnp/2/202.txt
|
||||
|
||||
echo "flush pc2 neigh"
|
||||
echo "ip neigh flush all"
|
||||
output=$(ssh pc2 "ip neigh flush all")
|
||||
echo $output
|
||||
echo $output >> /home/rnp/2/202.txt
|
||||
output=$(ssh pc2 "ip neigh")
|
||||
echo $output
|
||||
echo $output >> /home/rnp/2/202.txt
|
||||
|
||||
|
||||
|
||||
|
||||
4
Blatt02/scripts/202.txt
Normal file
4
Blatt02/scripts/202.txt
Normal file
@@ -0,0 +1,4 @@
|
||||
|
||||
192.168.0.254 dev eth0 lladdr fe:ff:ff:ff:ff:ff REACHABLE
|
||||
|
||||
192.168.0.254 dev eth0 lladdr fe:ff:ff:ff:ff:ff REACHABLE
|
||||
16
Blatt02/scripts/203.sh
Normal file
16
Blatt02/scripts/203.sh
Normal file
@@ -0,0 +1,16 @@
|
||||
#!/bin/bash
|
||||
|
||||
bash /home/rnp/2/202.sh
|
||||
|
||||
echo "203" > /home/rnp/203.txt
|
||||
|
||||
for i in {1..3}; do
|
||||
echo "pc$i ipv6"
|
||||
output=$(ssh pc$i "ip -6 addr show")
|
||||
echo "ip -6 addr show" >> /home/rnp/2/203.txt
|
||||
echo "ip -6 addr show"
|
||||
echo "$output" >> /home/rnp/2/203.txt
|
||||
echo "$output"
|
||||
done
|
||||
|
||||
|
||||
168
Blatt02/scripts/203.txt
Normal file
168
Blatt02/scripts/203.txt
Normal file
@@ -0,0 +1,168 @@
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:1/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:3/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:5/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:1/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:3/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:5/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:1/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:3/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:5/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:1/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:3/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:5/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:1/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:3/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:5/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:1/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:3/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:5/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:1/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:3/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:5/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:1/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:3/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
ip -6 addr show
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
|
||||
inet6 fe80::216:3eff:fe00:5/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
75
Blatt02/scripts/204.sh
Normal file
75
Blatt02/scripts/204.sh
Normal file
@@ -0,0 +1,75 @@
|
||||
#!/bin/bash
|
||||
|
||||
bash /home/rnp/2/203.sh
|
||||
|
||||
get_v6(){
|
||||
local output=$1
|
||||
local eth_n=$2
|
||||
echo "$output" | grep -A 1 "^[0-9]: eth$eth_n" | awk '/inet6/ {split($2, parts, "/"); print parts[1]}'
|
||||
}
|
||||
|
||||
pc1_ip6=$(ssh "pc1" "ip -6 addr show")
|
||||
pc1_ip6=$(ssh "pc1" "ip link set dev eth1 down")
|
||||
pc1_ip6=$(ssh "pc1" "ip link set dev eth1 up")
|
||||
pc1_ip6=$(ssh "pc1" "ip -6 addr show")
|
||||
echo $pc1_ip6
|
||||
pc1_6=$(get_v6 "$pc1_ip6" 1)
|
||||
echo $pc1_6
|
||||
|
||||
pc2_ip6=$(ssh "pc2" "ip -6 addr show")
|
||||
pc2_ip6=$(ssh "pc2" "ip link set dev eth1 down")
|
||||
pc2_ip6=$(ssh "pc2" "ip link set dev eth1 up")
|
||||
pc2_ip6=$(ssh "pc2" "ip -6 addr show")
|
||||
echo $pc2_ip6
|
||||
pc2_6=$(get_v6 "$pc2_ip6" 1)
|
||||
echo $pc2_6
|
||||
|
||||
echo "using ping"
|
||||
echo "using ping" > /home/rnp/2/204.txt
|
||||
|
||||
ping_dev(){
|
||||
local dev=$1
|
||||
local ip=$2
|
||||
local eth_n=$3
|
||||
local output=$(ssh $dev "ping -c 5 -W 2 -I eth$eth_n $ip")
|
||||
echo $output
|
||||
}
|
||||
|
||||
ping6_dev(){
|
||||
local dev=$1
|
||||
local ip=$2
|
||||
local eth_n=$3
|
||||
local output=$(ssh $dev "ping6 -c 5 -W 2 -I eth$eth_n $ip")
|
||||
echo $output
|
||||
}
|
||||
output=$(ping_dev "pc1" "10.5.1.2" 1)
|
||||
echo "pc1 ping pc2"
|
||||
echo "pc1 ping pc2">> /home/rnp/2/204.txt
|
||||
echo "ping -c 5 -W 2 -I eth1 10.5.1.2"
|
||||
echo "ping -c 5 -W 2 -I eth1 10.5.1.2">> /home/rnp/2/204.txt
|
||||
echo "$output"
|
||||
echo "$output" >> /home/rnp/2/204.txt
|
||||
|
||||
output=$(ping_dev "pc2" "10.5.1.1" 1)
|
||||
echo "pc2 ping pc1"
|
||||
echo "pc2 ping pc1">> /home/rnp/2/204.txt
|
||||
echo "ping -c 5 -W 2 -I eth1 10.5.1.1"
|
||||
echo "ping -c 5 -W 2 -I eth1 10.5.1.1">> /home/rnp/2/204.txt
|
||||
echo "$output"
|
||||
echo "$output" >> /home/rnp/2/204.txt
|
||||
|
||||
output=$(ping6_dev "pc1" "$pc2_6" 1)
|
||||
echo "pc1 ping6 pc2"
|
||||
echo "pc1 ping6 pc2">> /home/rnp/2/204.txt
|
||||
echo "ping6 -c 5 -W 2 -I eth1 $pc2_6"
|
||||
echo "ping6 -c 5 -W 2 -I eth1 $pc2_6">> /home/rnp/2/204.txt
|
||||
echo "$output"
|
||||
echo "$output" >> /home/rnp/2/204.txt
|
||||
|
||||
output=$(ping6_dev "pc2" "$pc1_6" 1)
|
||||
echo "pc2 ping6 pc1"
|
||||
echo "pc2 ping6 pc1">> /home/rnp/2/204.txt
|
||||
echo "ping6 -c 5 -W 2 -I eth1 $pc1_6"
|
||||
echo "ping6 -c 5 -W 2 -I eth1 $pc1_6">> /home/rnp/2/204.txt
|
||||
echo "$output"
|
||||
echo "$output" >> /home/rnp/2/204.txt
|
||||
13
Blatt02/scripts/204.txt
Normal file
13
Blatt02/scripts/204.txt
Normal file
@@ -0,0 +1,13 @@
|
||||
using ping
|
||||
pc1 ping pc2
|
||||
ping -c 5 -W 2 -I eth1 10.5.1.2
|
||||
PING 10.5.1.2 (10.5.1.2) from 10.5.1.1 eth1: 56(84) bytes of data. 64 bytes from 10.5.1.2: icmp_seq=1 ttl=64 time=1.87 ms 64 bytes from 10.5.1.2: icmp_seq=2 ttl=64 time=0.707 ms 64 bytes from 10.5.1.2: icmp_seq=3 ttl=64 time=0.664 ms 64 bytes from 10.5.1.2: icmp_seq=4 ttl=64 time=0.689 ms 64 bytes from 10.5.1.2: icmp_seq=5 ttl=64 time=1.02 ms --- 10.5.1.2 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4068ms rtt min/avg/max/mdev = 0.664/0.991/1.874/0.460 ms
|
||||
pc2 ping pc1
|
||||
ping -c 5 -W 2 -I eth1 10.5.1.1
|
||||
PING 10.5.1.1 (10.5.1.1) from 10.5.1.2 eth1: 56(84) bytes of data. 64 bytes from 10.5.1.1: icmp_seq=1 ttl=64 time=0.714 ms 64 bytes from 10.5.1.1: icmp_seq=2 ttl=64 time=0.749 ms 64 bytes from 10.5.1.1: icmp_seq=3 ttl=64 time=1.90 ms 64 bytes from 10.5.1.1: icmp_seq=4 ttl=64 time=0.824 ms 64 bytes from 10.5.1.1: icmp_seq=5 ttl=64 time=0.845 ms --- 10.5.1.1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4049ms rtt min/avg/max/mdev = 0.714/1.005/1.896/0.447 ms
|
||||
pc1 ping6 pc2
|
||||
ping6 -c 5 -W 2 -I eth1 fe80::216:3eff:fe00:4/64
|
||||
|
||||
pc2 ping6 pc1
|
||||
ping6 -c 5 -W 2 -I eth1 fe80::216:3eff:fe00:2/64
|
||||
|
||||
68
Blatt02/scripts/205.sh
Normal file
68
Blatt02/scripts/205.sh
Normal file
@@ -0,0 +1,68 @@
|
||||
#!/bin/bash
|
||||
|
||||
run204=$1
|
||||
ping_type=$2
|
||||
if [ "$run204" = "y" ]; then
|
||||
bash /home/rnp/2/204.sh
|
||||
fi
|
||||
echo "205" > /home/rnp/2/205.txt
|
||||
|
||||
get_v6(){
|
||||
local output=$1
|
||||
local eth_n=$2
|
||||
echo "$output" | grep -A 1 "^[0-9]: eth$eth_n" | awk '/inet6/ {split($2, parts, "/"); print parts[1]}'
|
||||
}
|
||||
|
||||
pc1_ip6=$(ssh "pc1" "ip -6 addr show")
|
||||
pc1_6=$(get_v6 "$pc1_ip6" 1)
|
||||
echo $pc1_6
|
||||
echo -e $pc1_ip6 >> /home/rnp/2/205.txt
|
||||
|
||||
pc2_ip6=$(ssh "pc2" "ip -6 addr show")
|
||||
pc2_6=$(get_v6 "$pc2_ip6" 1)
|
||||
echo -e $pc2_6 >> /home/rnp/2/205.txt
|
||||
|
||||
ping6_dev(){
|
||||
local dev=$1
|
||||
local ip=$2
|
||||
local eth_n=$3
|
||||
local output=$(ssh $dev "ping6 -c 5 -W 2 -I eth$eth_n $ip")
|
||||
echo -e $output
|
||||
}
|
||||
|
||||
ping_dev(){
|
||||
local dev=$1
|
||||
local ip=$2
|
||||
local eth_n=$3
|
||||
# ssh "$dev" $cmd
|
||||
loss=$(ssh $dev "ping -c 5 -W 2 -I eth$eth_n $ip | awk -F', ' '/packet loss/ {print \$3}' | awk '{print int(\$1)}'")
|
||||
output=$(ssh $dev "ping -c 5 -W 2 -I eth$eth_n $ip")
|
||||
echo -e $output > 2/output/"${dev}_${ip}_${eth_n}"
|
||||
echo $loss
|
||||
}
|
||||
|
||||
echo "using ping"
|
||||
echo "using ping" >> /home/rnp/2/205.txt
|
||||
|
||||
|
||||
if [ $ping_type -eq 4 ]; then
|
||||
output=$(ping_dev "pc1" "10.5.1.2" 1)
|
||||
echo $output
|
||||
echo $output >> /home/rnp/2/205.txt
|
||||
|
||||
output=$(ping_dev "pc2" "10.5.1.1" 1)
|
||||
echo $output
|
||||
echo $output >> /home/rnp/2/205.txt
|
||||
elif [ $ping_type -eq 6 ]; then
|
||||
echo "$pc2_6"
|
||||
output=$(ping6_dev "pc1" "$pc2_6" 1)
|
||||
echo -e $output
|
||||
echo -e $output >> /home/rnp/2/205.txt
|
||||
|
||||
output=$(ping6_dev "pc2" "$pc1_6" 1)
|
||||
echo "$pc1_6"
|
||||
echo -e $output
|
||||
echo -e $output >> /home/rnp/2/205.txt
|
||||
fi
|
||||
|
||||
|
||||
6
Blatt02/scripts/205.txt
Normal file
6
Blatt02/scripts/205.txt
Normal file
@@ -0,0 +1,6 @@
|
||||
205
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000 inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 fe80::216:3eff:fe00:1/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 fe80::216:3eff:fe00:2/64 scope link valid_lft forever preferred_lft forever
|
||||
fe80::216:3eff:fe00:4
|
||||
using ping
|
||||
PING fe80::216:3eff:fe00:4(fe80::216:3eff:fe00:4) from :: eth1: 56 data bytes 64 bytes from fe80::216:3eff:fe00:4%eth1: icmp_seq=1 ttl=64 time=2.03 ms 64 bytes from fe80::216:3eff:fe00:4%eth1: icmp_seq=2 ttl=64 time=0.807 ms 64 bytes from fe80::216:3eff:fe00:4%eth1: icmp_seq=3 ttl=64 time=0.942 ms 64 bytes from fe80::216:3eff:fe00:4%eth1: icmp_seq=4 ttl=64 time=0.893 ms 64 bytes from fe80::216:3eff:fe00:4%eth1: icmp_seq=5 ttl=64 time=0.771 ms --- fe80::216:3eff:fe00:4 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 0.771/1.089/2.033/0.475 ms
|
||||
PING fe80::216:3eff:fe00:2(fe80::216:3eff:fe00:2) from :: eth1: 56 data bytes 64 bytes from fe80::216:3eff:fe00:2%eth1: icmp_seq=1 ttl=64 time=0.944 ms 64 bytes from fe80::216:3eff:fe00:2%eth1: icmp_seq=2 ttl=64 time=0.823 ms 64 bytes from fe80::216:3eff:fe00:2%eth1: icmp_seq=3 ttl=64 time=0.778 ms 64 bytes from fe80::216:3eff:fe00:2%eth1: icmp_seq=4 ttl=64 time=0.823 ms 64 bytes from fe80::216:3eff:fe00:2%eth1: icmp_seq=5 ttl=64 time=0.769 ms --- fe80::216:3eff:fe00:2 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 0.769/0.827/0.944/0.062 ms
|
||||
60
Blatt02/scripts/206.sh
Normal file
60
Blatt02/scripts/206.sh
Normal file
@@ -0,0 +1,60 @@
|
||||
#!/bin/bash
|
||||
|
||||
run205=$1
|
||||
if [ "$run205" = "y" ]; then
|
||||
bash /home/rnp/2/205.sh y 4
|
||||
fi
|
||||
echo "206" > /home/rnp/2/206.txt
|
||||
|
||||
assign_ip(){
|
||||
local dev=$1
|
||||
local eth_num=$2
|
||||
local ip=$3
|
||||
ssh $dev "ip link set dev eth$eth_num up"
|
||||
ssh $dev "ip addr add $ip dev eth$eth_num"
|
||||
echo "dev $dev eth$eth_num assign $ip"
|
||||
}
|
||||
|
||||
assign_ip "pc1" 1 "2001:db8:5::1/64"
|
||||
assign_ip "pc2" 1 "2001:db8:5::2/64"
|
||||
|
||||
get_v6(){
|
||||
local output=$1
|
||||
local eth_n=$2
|
||||
echo "$output" | grep -A 1 "^[0-9]: eth$eth_n" | awk '/inet6/ && /global/ {split($2, a, "/"); print a[1]}'
|
||||
}
|
||||
|
||||
ping6_dev(){
|
||||
local dev=$1
|
||||
local ip=$2
|
||||
local eth_n=$3
|
||||
local output=$(ssh $dev "ping6 -c 5 -W 2 -I eth$eth_n $ip")
|
||||
echo $output
|
||||
}
|
||||
|
||||
pc1_ip6=$(ssh "pc1" "ip -6 addr show")
|
||||
echo $pc1_ip6
|
||||
pc1_6=$(get_v6 "$pc1_ip6" 1)
|
||||
echo $pc1_6
|
||||
|
||||
pc2_ip6=$(ssh "pc2" "ip -6 addr show")
|
||||
echo $pc2_ip6
|
||||
pc2_6=$(get_v6 "$pc2_ip6" 1)
|
||||
echo $pc2_6
|
||||
|
||||
output=$(ping6_dev "pc1" "$pc2_6" 1)
|
||||
echo "pc1 ping6 pc2"
|
||||
echo "pc1 ping6 pc2">> /home/rnp/2/206.txt
|
||||
echo "ping6 -c 5 -W 2 -I eth1 $pc2_6"
|
||||
echo "ping6 -c 5 -W 2 -I eth1 $pc2_6">> /home/rnp/2/206.txt
|
||||
echo "$output"
|
||||
echo "$output" >> /home/rnp/2/206.txt
|
||||
|
||||
output=$(ping6_dev "pc2" "$pc1_6" 1)
|
||||
echo "pc2 ping6 pc1"
|
||||
echo "pc2 ping6 pc1">> /home/rnp/2/206.txt
|
||||
echo "ping6 -c 5 -W 2 -I eth1 $pc1_6"
|
||||
echo "ping6 -c 5 -W 2 -I eth1 $pc1_6">> /home/rnp/2/206.txt
|
||||
echo "$output"
|
||||
echo "$output" >> /home/rnp/2/206.txt
|
||||
|
||||
7
Blatt02/scripts/206.txt
Normal file
7
Blatt02/scripts/206.txt
Normal file
@@ -0,0 +1,7 @@
|
||||
206
|
||||
pc1 ping6 pc2
|
||||
ping6 -c 5 -W 2 -I eth1 2001:db8:5::2
|
||||
PING 2001:db8:5::2(2001:db8:5::2) from 2001:db8:5::1 eth1: 56 data bytes 64 bytes from 2001:db8:5::2: icmp_seq=1 ttl=64 time=0.811 ms 64 bytes from 2001:db8:5::2: icmp_seq=2 ttl=64 time=1.26 ms 64 bytes from 2001:db8:5::2: icmp_seq=3 ttl=64 time=1.75 ms 64 bytes from 2001:db8:5::2: icmp_seq=4 ttl=64 time=1.35 ms 64 bytes from 2001:db8:5::2: icmp_seq=5 ttl=64 time=1.41 ms --- 2001:db8:5::2 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 0.811/1.313/1.748/0.301 ms
|
||||
pc2 ping6 pc1
|
||||
ping6 -c 5 -W 2 -I eth1 2001:db8:5::1
|
||||
PING 2001:db8:5::1(2001:db8:5::1) from 2001:db8:5::2 eth1: 56 data bytes 64 bytes from 2001:db8:5::1: icmp_seq=1 ttl=64 time=1.63 ms 64 bytes from 2001:db8:5::1: icmp_seq=2 ttl=64 time=1.58 ms 64 bytes from 2001:db8:5::1: icmp_seq=3 ttl=64 time=1.48 ms 64 bytes from 2001:db8:5::1: icmp_seq=4 ttl=64 time=1.60 ms 64 bytes from 2001:db8:5::1: icmp_seq=5 ttl=64 time=1.63 ms --- 2001:db8:5::1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4008ms rtt min/avg/max/mdev = 1.477/1.582/1.630/0.056 ms
|
||||
60
Blatt02/scripts/207.sh
Normal file
60
Blatt02/scripts/207.sh
Normal file
@@ -0,0 +1,60 @@
|
||||
#!/bin/bash
|
||||
|
||||
run205=$1
|
||||
if [ "$run205" = "y" ]; then
|
||||
bash /home/rnp/2/205.sh y 4
|
||||
fi
|
||||
echo "206" > /home/rnp/2/206.txt
|
||||
|
||||
assign_ip(){
|
||||
local dev=$1
|
||||
local eth_num=$2
|
||||
local ip=$3
|
||||
ssh $dev "ip link set dev eth$eth_num up"
|
||||
ssh $dev "ip addr add $ip dev eth$eth_num"
|
||||
echo "dev $dev eth$eth_num assign $ip"
|
||||
}
|
||||
|
||||
assign_ip "pc1" 1 "2001:db8:5::1/64"
|
||||
assign_ip "pc2" 1 "2001:db8:5::2/64"
|
||||
|
||||
get_v6(){
|
||||
local output=$1
|
||||
local eth_n=$2
|
||||
echo "$output" | grep -A 1 "^[0-9]: eth$eth_n" | awk '/inet6/ && /global/ {split($2, a, "/"); print a[1]}'
|
||||
}
|
||||
|
||||
ping6_dev(){
|
||||
local dev=$1
|
||||
local ip=$2
|
||||
local eth_n=$3
|
||||
local output=$(ssh $dev "ping6 -c 5 -W 2 -I eth$eth_n $ip")
|
||||
echo $output
|
||||
}
|
||||
|
||||
pc1_ip6=$(ssh "pc1" "ip -6 addr show")
|
||||
echo $pc1_ip6
|
||||
pc1_6=$(get_v6 "$pc1_ip6" 1)
|
||||
echo $pc1_6
|
||||
|
||||
pc2_ip6=$(ssh "pc2" "ip -6 addr show")
|
||||
echo $pc2_ip6
|
||||
pc2_6=$(get_v6 "$pc2_ip6" 1)
|
||||
echo $pc2_6
|
||||
|
||||
output=$(ping6_dev "pc1" "$pc2_6" 1)
|
||||
echo "pc1 ping6 pc2"
|
||||
echo "pc1 ping6 pc2">> /home/rnp/2/206.txt
|
||||
echo "ping6 -c 5 -W 2 -I eth1 $pc2_6"
|
||||
echo "ping6 -c 5 -W 2 -I eth1 $pc2_6">> /home/rnp/2/206.txt
|
||||
echo "$output"
|
||||
echo "$output" >> /home/rnp/2/206.txt
|
||||
|
||||
output=$(ping6_dev "pc2" "$pc1_6" 1)
|
||||
echo "pc2 ping6 pc1"
|
||||
echo "pc2 ping6 pc1">> /home/rnp/2/206.txt
|
||||
echo "ping6 -c 5 -W 2 -I eth1 $pc1_6"
|
||||
echo "ping6 -c 5 -W 2 -I eth1 $pc1_6">> /home/rnp/2/206.txt
|
||||
echo "$output"
|
||||
echo "$output" >> /home/rnp/2/206.txt
|
||||
|
||||
6
Blatt02/scripts/208.py
Normal file
6
Blatt02/scripts/208.py
Normal file
@@ -0,0 +1,6 @@
|
||||
from scapy.all import *
|
||||
|
||||
def packet_callback(packet):
|
||||
print(packet.summary())
|
||||
|
||||
sniff(iface="eth1", prn=packet_callback, count=10)
|
||||
12
Blatt02/scripts/209.py
Normal file
12
Blatt02/scripts/209.py
Normal file
@@ -0,0 +1,12 @@
|
||||
from scapy.all import *
|
||||
|
||||
def display_arp(packet):
|
||||
if packet.haslayer(ICMPv6ND_NS):
|
||||
print("NS Packet:")
|
||||
print("Source MAC", packet[Ether].hwsrc)
|
||||
print("Source IP", packet[IPv6].psrc)
|
||||
print("Target IP", packet[ICMPv6ND_NS].tgt)
|
||||
print("="*30)
|
||||
|
||||
sniff(iface="eth1", prn=display_arp, store=0)
|
||||
|
||||
62
Blatt02/scripts/make_topo.sh
Normal file
62
Blatt02/scripts/make_topo.sh
Normal file
@@ -0,0 +1,62 @@
|
||||
#!/bin/bash
|
||||
|
||||
echo "reboot to erase the old configurations;"
|
||||
bash ~/reboot.sh
|
||||
echo "rebooting"
|
||||
countdown=40
|
||||
while [ $countdown -gt 0 ]; do
|
||||
echo -ne "counting down: $countdown s \033[0K\r"
|
||||
sleep 1
|
||||
countdown=$((countdown - 1))
|
||||
done
|
||||
|
||||
assign_ip(){
|
||||
local dev=$1
|
||||
local eth_num=$2
|
||||
local ip=$3
|
||||
ssh $dev "ip link set dev eth$eth_num up"
|
||||
ssh $dev "ip addr add $ip dev eth$eth_num"
|
||||
}
|
||||
|
||||
echo "assigning IP on router1"
|
||||
|
||||
assign_ip "router1" 1 "10.5.1.2/24"
|
||||
assign_ip "router1" 2 "10.5.3.3/24"
|
||||
assign_ip "router1" 3 "10.5.4.2/24"
|
||||
assign_ip "router1" 4 "10.5.2.3/24"
|
||||
|
||||
|
||||
echo "assigning IP on router2"
|
||||
|
||||
assign_ip "router2" 1 "10.5.2.2/24"
|
||||
assign_ip "router2" 2 "10.5.3.4/24"
|
||||
assign_ip "router2" 3 "10.5.6.1/24"
|
||||
assign_ip "router2" 4 "10.5.5.5/24"
|
||||
|
||||
|
||||
echo "assigning IP on router3"
|
||||
|
||||
assign_ip "router3" 1 "10.5.3.2/24"
|
||||
assign_ip "router3" 2 "10.5.4.3/24"
|
||||
assign_ip "router3" 3 "10.5.6.2/24"
|
||||
assign_ip "router3" 4 "10.5.7.1/24"
|
||||
|
||||
echo "assigning IP on router4"
|
||||
|
||||
assign_ip "router4" 1 "10.5.2.4/24"
|
||||
assign_ip "router4" 2 "10.5.5.4/24"
|
||||
assign_ip "router4" 3 "10.5.7.2/24"
|
||||
|
||||
echo "assigning IP on pc1"
|
||||
|
||||
assign_ip "pc1" 1 "10.5.1.1/24"
|
||||
|
||||
|
||||
echo "assigning IP on pc2"
|
||||
|
||||
assign_ip "pc2" 1 "10.5.2.1/24"
|
||||
|
||||
echo "assigning IP on pc3"
|
||||
|
||||
assign_ip "pc3" 1 "10.5.3.1/24"
|
||||
bash ~/checkip.sh
|
||||
1
Blatt02/scripts/output/pc1_10.5.1.2_1
Normal file
1
Blatt02/scripts/output/pc1_10.5.1.2_1
Normal file
@@ -0,0 +1 @@
|
||||
PING 10.5.1.2 (10.5.1.2) from 10.5.1.1 eth1: 56(84) bytes of data. 64 bytes from 10.5.1.2: icmp_seq=1 ttl=64 time=1.46 ms 64 bytes from 10.5.1.2: icmp_seq=2 ttl=64 time=0.903 ms 64 bytes from 10.5.1.2: icmp_seq=3 ttl=64 time=0.818 ms 64 bytes from 10.5.1.2: icmp_seq=4 ttl=64 time=0.681 ms 64 bytes from 10.5.1.2: icmp_seq=5 ttl=64 time=0.699 ms --- 10.5.1.2 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4012ms rtt min/avg/max/mdev = 0.681/0.911/1.458/0.284 ms
|
||||
1
Blatt02/scripts/output/pc1_10.5.1.2_1.200
Normal file
1
Blatt02/scripts/output/pc1_10.5.1.2_1.200
Normal file
@@ -0,0 +1 @@
|
||||
PING 10.5.1.2 (10.5.1.2) from 10.5.1.1 eth1.200: 56(84) bytes of data. 64 bytes from 10.5.1.2: icmp_seq=1 ttl=64 time=0.690 ms 64 bytes from 10.5.1.2: icmp_seq=2 ttl=64 time=0.762 ms 64 bytes from 10.5.1.2: icmp_seq=3 ttl=64 time=0.782 ms 64 bytes from 10.5.1.2: icmp_seq=4 ttl=64 time=0.785 ms 64 bytes from 10.5.1.2: icmp_seq=5 ttl=64 time=0.776 ms --- 10.5.1.2 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4007ms rtt min/avg/max/mdev = 0.690/0.759/0.785/0.035 ms
|
||||
1
Blatt02/scripts/output/pc1_10.5.1.3_1.200
Normal file
1
Blatt02/scripts/output/pc1_10.5.1.3_1.200
Normal file
@@ -0,0 +1 @@
|
||||
PING 10.5.1.3 (10.5.1.3) from 10.5.1.1 eth1.200: 56(84) bytes of data. --- 10.5.1.3 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4091ms pipe 3
|
||||
1
Blatt02/scripts/output/pc1_10.5.1.4_1.200
Normal file
1
Blatt02/scripts/output/pc1_10.5.1.4_1.200
Normal file
@@ -0,0 +1 @@
|
||||
PING 10.5.1.4 (10.5.1.4) from 10.5.1.1 eth1.200: 56(84) bytes of data. --- 10.5.1.4 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4092ms pipe 3
|
||||
1
Blatt02/scripts/output/pc2_10.5.1.1_1
Normal file
1
Blatt02/scripts/output/pc2_10.5.1.1_1
Normal file
@@ -0,0 +1 @@
|
||||
PING 10.5.1.1 (10.5.1.1) from 10.5.1.2 eth1: 56(84) bytes of data. 64 bytes from 10.5.1.1: icmp_seq=1 ttl=64 time=0.749 ms 64 bytes from 10.5.1.1: icmp_seq=2 ttl=64 time=0.649 ms 64 bytes from 10.5.1.1: icmp_seq=3 ttl=64 time=0.705 ms 64 bytes from 10.5.1.1: icmp_seq=4 ttl=64 time=0.739 ms 64 bytes from 10.5.1.1: icmp_seq=5 ttl=64 time=0.693 ms --- 10.5.1.1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4101ms rtt min/avg/max/mdev = 0.649/0.707/0.749/0.035 ms
|
||||
1
Blatt02/scripts/output/pc2_10.5.1.1_1.200
Normal file
1
Blatt02/scripts/output/pc2_10.5.1.1_1.200
Normal file
@@ -0,0 +1 @@
|
||||
PING 10.5.1.1 (10.5.1.1) from 10.5.1.2 eth1.200: 56(84) bytes of data. 64 bytes from 10.5.1.1: icmp_seq=1 ttl=64 time=0.704 ms 64 bytes from 10.5.1.1: icmp_seq=2 ttl=64 time=0.709 ms 64 bytes from 10.5.1.1: icmp_seq=3 ttl=64 time=0.741 ms 64 bytes from 10.5.1.1: icmp_seq=4 ttl=64 time=0.775 ms 64 bytes from 10.5.1.1: icmp_seq=5 ttl=64 time=0.878 ms --- 10.5.1.1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4065ms rtt min/avg/max/mdev = 0.704/0.761/0.878/0.063 ms
|
||||
1
Blatt02/scripts/output/pc2_10.5.1.3_1.200
Normal file
1
Blatt02/scripts/output/pc2_10.5.1.3_1.200
Normal file
@@ -0,0 +1 @@
|
||||
PING 10.5.1.3 (10.5.1.3) from 10.5.1.2 eth1.200: 56(84) bytes of data. --- 10.5.1.3 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4084ms pipe 3
|
||||
1
Blatt02/scripts/output/pc2_10.5.1.4_1.200
Normal file
1
Blatt02/scripts/output/pc2_10.5.1.4_1.200
Normal file
@@ -0,0 +1 @@
|
||||
PING 10.5.1.4 (10.5.1.4) from 10.5.1.2 eth1.200: 56(84) bytes of data. --- 10.5.1.4 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4078ms pipe 3
|
||||
1
Blatt02/scripts/output/pc3_10.5.1.1_1.100
Normal file
1
Blatt02/scripts/output/pc3_10.5.1.1_1.100
Normal file
@@ -0,0 +1 @@
|
||||
PING 10.5.1.1 (10.5.1.1) from 10.5.1.3 eth1.100: 56(84) bytes of data. --- 10.5.1.1 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4083ms pipe 3
|
||||
1
Blatt02/scripts/output/pc3_10.5.1.2_1.100
Normal file
1
Blatt02/scripts/output/pc3_10.5.1.2_1.100
Normal file
@@ -0,0 +1 @@
|
||||
PING 10.5.1.2 (10.5.1.2) from 10.5.1.3 eth1.100: 56(84) bytes of data. --- 10.5.1.2 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4087ms pipe 3
|
||||
1
Blatt02/scripts/output/pc3_10.5.1.4_1.100
Normal file
1
Blatt02/scripts/output/pc3_10.5.1.4_1.100
Normal file
@@ -0,0 +1 @@
|
||||
PING 10.5.1.4 (10.5.1.4) from 10.5.1.3 eth1.100: 56(84) bytes of data. 64 bytes from 10.5.1.4: icmp_seq=1 ttl=64 time=0.810 ms 64 bytes from 10.5.1.4: icmp_seq=2 ttl=64 time=0.608 ms 64 bytes from 10.5.1.4: icmp_seq=3 ttl=64 time=0.950 ms 64 bytes from 10.5.1.4: icmp_seq=4 ttl=64 time=0.863 ms 64 bytes from 10.5.1.4: icmp_seq=5 ttl=64 time=0.823 ms --- 10.5.1.4 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4036ms rtt min/avg/max/mdev = 0.608/0.810/0.950/0.112 ms
|
||||
1
Blatt02/scripts/output/router4_10.5.1.1_1.100
Normal file
1
Blatt02/scripts/output/router4_10.5.1.1_1.100
Normal file
@@ -0,0 +1 @@
|
||||
PING 10.5.1.1 (10.5.1.1) from 10.5.1.4 eth1.100: 56(84) bytes of data. --- 10.5.1.1 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4083ms pipe 3
|
||||
1
Blatt02/scripts/output/router4_10.5.1.2_1.100
Normal file
1
Blatt02/scripts/output/router4_10.5.1.2_1.100
Normal file
@@ -0,0 +1 @@
|
||||
PING 10.5.1.2 (10.5.1.2) from 10.5.1.4 eth1.100: 56(84) bytes of data. --- 10.5.1.2 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4087ms pipe 3
|
||||
1
Blatt02/scripts/output/router4_10.5.1.3_1.100
Normal file
1
Blatt02/scripts/output/router4_10.5.1.3_1.100
Normal file
@@ -0,0 +1 @@
|
||||
PING 10.5.1.3 (10.5.1.3) from 10.5.1.4 eth1.100: 56(84) bytes of data. 64 bytes from 10.5.1.3: icmp_seq=1 ttl=64 time=0.632 ms 64 bytes from 10.5.1.3: icmp_seq=2 ttl=64 time=0.561 ms 64 bytes from 10.5.1.3: icmp_seq=3 ttl=64 time=0.538 ms 64 bytes from 10.5.1.3: icmp_seq=4 ttl=64 time=0.564 ms 64 bytes from 10.5.1.3: icmp_seq=5 ttl=64 time=0.565 ms --- 10.5.1.3 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4097ms rtt min/avg/max/mdev = 0.538/0.572/0.632/0.031 ms
|
||||
48
Blatt02/scripts/test_ping.sh
Normal file
48
Blatt02/scripts/test_ping.sh
Normal file
@@ -0,0 +1,48 @@
|
||||
#!/bin/bash
|
||||
|
||||
test_ping(){
|
||||
local sender_dev=$1
|
||||
local sender_eth=$2
|
||||
local receiver_dev=$3
|
||||
local receiver_eth=$4
|
||||
local receiver_ip=$5
|
||||
|
||||
loss=$(ssh $sender_dev "ping -c 5 -W 2 -I eth$sender_eth $receiver_ip | awk -F', ' '/packet loss/ {print \$3}' | awk '{print int(\$1)}'")
|
||||
echo $loss
|
||||
}
|
||||
|
||||
loss_count=0
|
||||
|
||||
localloss=$(test_ping "router1" 1 "pc1" 1 "10.5.1.1")
|
||||
loss_count=$(($loss_count+$localloss))
|
||||
echo $loss_count
|
||||
localloss=$(test_ping "router1" 2 "router2" 2 "10.5.3.4")
|
||||
loss_count=$(($loss_count+$localloss))
|
||||
echo $loss_count
|
||||
localloss=$(test_ping "router1" 3 "router3" 2 "10.5.4.3")
|
||||
loss_count=$(($loss_count+$localloss))
|
||||
echo $loss_count
|
||||
localloss=$(test_ping "router1" 4 "router4" 1 "10.5.2.4")
|
||||
loss_count=$(($loss_count+$localloss))
|
||||
echo $loss_count
|
||||
|
||||
localloss=$(test_ping "router2" 1 "pc2" 1 "10.5.2.1")
|
||||
loss_count=$(($loss_count+$localloss))
|
||||
echo $loss_count
|
||||
localloss=$(test_ping "router2" 3 "router3" 3 "10.5.6.2")
|
||||
loss_count=$(($loss_count+$localloss))
|
||||
echo $loss_count
|
||||
localloss=$(test_ping "router2" 4 "router4" 2 "10.5.5.4")
|
||||
loss_count=$(($loss_count+$localloss))
|
||||
echo $loss_count
|
||||
|
||||
localloss=$(test_ping "router3" 1 "pc3" 1 "10.5.3.1")
|
||||
loss_count=$(($loss_count+$localloss))
|
||||
echo $loss_count
|
||||
localloss=$(test_ping "router3" 4 "router4" 3 "10.5.7.2")
|
||||
loss_count=$(($loss_count+$localloss))
|
||||
echo $loss_count
|
||||
|
||||
echo $loss_count
|
||||
|
||||
|
||||
87
Blatt02/tuntap.c
Normal file
87
Blatt02/tuntap.c
Normal file
@@ -0,0 +1,87 @@
|
||||
#include <assert.h>
|
||||
#include <sys/ioctl.h>
|
||||
#include <net/if.h>
|
||||
#include <linux/if_tun.h>
|
||||
#include <sys/types.h>
|
||||
#include <sys/stat.h>
|
||||
#include <fcntl.h>
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
#include <string.h>
|
||||
#include <unistd.h>
|
||||
#include <stdint.h>
|
||||
|
||||
#define CLEAR(x) memset(&(x), 0x00, sizeof(x))
|
||||
|
||||
#define IFNAME "tap0"
|
||||
|
||||
#define BUFLEN 1600
|
||||
|
||||
static int tun_alloc(char *dev)
|
||||
{
|
||||
struct ifreq ifr;
|
||||
int fd, err;
|
||||
|
||||
if( (fd = open("/dev/net/tun", O_RDWR)) < 0 ) {
|
||||
perror("Cannot open TUN/TAP dev\n"
|
||||
"Make sure one exists with "
|
||||
"'$ mknod /dev/net/tun c 10 200'");
|
||||
exit(1);
|
||||
}
|
||||
|
||||
CLEAR(ifr);
|
||||
|
||||
/* Flags: IFF_TUN - TUN device (no Ethernet headers)
|
||||
* IFF_TAP - TAP device
|
||||
*
|
||||
* IFF_NO_PI - Do not provide packet information
|
||||
*/
|
||||
ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
|
||||
if( *dev ) {
|
||||
strncpy(ifr.ifr_name, dev, IFNAMSIZ);
|
||||
}
|
||||
|
||||
if( (err = ioctl(fd, TUNSETIFF, (void *) &ifr)) < 0 ){
|
||||
perror("ERR: Could not ioctl tun");
|
||||
close(fd);
|
||||
return err;
|
||||
}
|
||||
|
||||
strcpy(dev, ifr.ifr_name);
|
||||
return fd;
|
||||
}
|
||||
|
||||
int main(int argc, char** argv) {
|
||||
|
||||
char dev[IFNAMSIZ];
|
||||
int tun_fd;
|
||||
|
||||
if (argc > 1) {
|
||||
assert(strlen(argv[1]) < IFNAMSIZ);
|
||||
strcpy(dev, argv[1]);
|
||||
} else {
|
||||
strcpy(dev, IFNAME);
|
||||
}
|
||||
|
||||
printf("device name: %s\n", dev);
|
||||
|
||||
tun_fd = tun_alloc(dev);
|
||||
|
||||
int running = 1;
|
||||
|
||||
uint8_t buf[BUFLEN];
|
||||
while (running) {
|
||||
int nread;
|
||||
|
||||
if ((nread = read(tun_fd, buf, BUFLEN)) < 0) {
|
||||
perror("ERR: Read from tun_fd");
|
||||
break;
|
||||
}
|
||||
|
||||
printf("Read %d bytes from device %s\n", nread, dev);
|
||||
}
|
||||
|
||||
close(tun_fd);
|
||||
|
||||
return EXIT_SUCCESS;
|
||||
}
|
||||
BIN
Blatt03/A300 (1).pdf
Normal file
BIN
Blatt03/A300 (1).pdf
Normal file
Binary file not shown.
3
Blatt03/Blatt03.md
Normal file
3
Blatt03/Blatt03.md
Normal file
@@ -0,0 +1,3 @@
|
||||
|
||||
|
||||
|
||||
1115
Blatt03/Notes03.md
Normal file
1115
Blatt03/Notes03.md
Normal file
File diff suppressed because it is too large
Load Diff
BIN
Blatt03/RNP24-intro-blatt3.pdf
Normal file
BIN
Blatt03/RNP24-intro-blatt3.pdf
Normal file
Binary file not shown.
BIN
Blatt03/assets/image-20241126212614458.png
Normal file
BIN
Blatt03/assets/image-20241126212614458.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 146 KiB |
BIN
Blatt03/assets/image-20241126220515506.png
Normal file
BIN
Blatt03/assets/image-20241126220515506.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 89 KiB |
BIN
Blatt03/assets/image-20241126220522718.png
Normal file
BIN
Blatt03/assets/image-20241126220522718.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
BIN
Blatt03/assets/image-20241126224848633.png
Normal file
BIN
Blatt03/assets/image-20241126224848633.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 77 KiB |
BIN
Blatt03/assets/image-20241127175414690.png
Normal file
BIN
Blatt03/assets/image-20241127175414690.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 67 KiB |
BIN
Blatt03/assets/image-20241127180327569.png
Normal file
BIN
Blatt03/assets/image-20241127180327569.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 73 KiB |
BIN
Blatt03/assets/image-20241127182325976.png
Normal file
BIN
Blatt03/assets/image-20241127182325976.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 38 KiB |
BIN
Blatt03/rnp-aufgabenblock3.pdf
Normal file
BIN
Blatt03/rnp-aufgabenblock3.pdf
Normal file
Binary file not shown.
858
Blatt04/Notes04.md
Normal file
858
Blatt04/Notes04.md
Normal file
@@ -0,0 +1,858 @@
|
||||
# 4 Software Defined Networks
|
||||
|
||||
This chapter introduces Software-defined Networks (SDN) as a new networking approach in contrast to traditional networks. In order to understand the principles of SDN, the layer views of network functionality in traditional networks and in SDN are juxtaposed, the SDN architecture is then presented. The concepts of flow commonly used in the SDN literature is analysed in this text. A deployment example with P4-based SDN is followed. The exercise illustrates how to employ SDN to “program” a network, revealing a new way of performing network control and management.
|
||||
本章介绍了软件定义网络（SDN）作为一种与传统网络形成对比的新型网络方法。
|
||||
为了理解SDN的原理，本文将传统网络和SDN的网络功能分层视图进行对比，并随后介绍了SDN的架构。
|
||||
本文还分析了SDN文献中常用的流的概念，并提供了一个基于P4的SDN部署示例。
|
||||
该练习展示了如何利用SDN来“编程”网络，揭示了一种新的网络控制和管理方式。
|
||||
|
||||
## 4.1 Introduction
|
||||
|
||||
|
||||
|
||||
There are different ways to layer networked systems. Two well-known ones are the ISO OSI (Open Systems Interconnection) and the TCP/IP reference models. Figure 4.1 shows an example of a switch and a router through the OSI view. The switch spans two OSI layers, namely Physical and Data Link whereas the router implements an additional Network layer. A network device is classified into its highest layer, which means that the switch belongs to the Data Link layer and the router to the Network layer. The OSI layering mechanism provides a common basis for the coordination of networking standards’ development as well as facilitates the understanding of these standards and the interaction of networked systems.
|
||||
网络系统的分层方式有多种。两个众所周知的模型是ISO OSI（开放系统互连）模型和TCP/IP参考模型。图4.1展示了通过OSI视图观察交换机和路由器的示例。交换机跨越了OSI的两层，即物理层和数据链路层，而路由器实现了额外的网络层。网络设备按照其最高层进行分类，这意味着交换机属于数据链路层，而路由器属于网络层。OSI分层机制为协调网络标准的开发提供了一个共同的基础，同时也促进了对这些标准的理解以及网络系统的交互。
|
||||
|
||||
|
||||
|
||||
In another view, a traditional network device can be seen as being composed of the three planes (or layers) depicted in Figure 4.2: management plane, control plane, and data plane.
|
||||
从另一种视角来看，传统网络设备可以看作由图4.2所示的三个平面（或层）组成：管理平面、控制平面和数据平面。
|
||||
|
||||
- The data plane consists of various ports for receiving and transmitting packets based on its forwarding table, and switching fabrics for transferring packets from an input buffer to an output buffer.
|
||||
数据平面包括用于接收和发送数据包的各种端口（基于其转发表）以及用于将数据包从输入缓冲区传输到输出缓冲区的交换结构。
|
||||
- The control plane represents protocols used for populating forwarding tables in the data plane, e.g., the routing protocols like RIP, OSPF, BGP in a router.
|
||||
控制平面表示用于填充数据平面中转发表的协议，例如路由协议，如RIP、OSPF、BGP。
|
||||
- The management plane includes software services used by a network administrator (manager) to monitor and configure the control functionalities.
|
||||
管理平面包括网络管理员（管理者）用于监控和配置控制功能的软件服务。
|
||||
|
||||
Figure 4.3 describes the roles of these planes and their interactions.
|
||||
图4.3描述了这些平面的角色及其交互关系。
|
||||
|
||||
|
||||
|
||||
Although traditional IP networks have widespread adoption, they are complex and hard to manage. To make any change to a network, operators need to configure each individual network device separately using low-level and vendor-specific commands. The vertical integration of the control and data plane in each network device reduces the flexibility and hinders the innovation and evolution of networking infrastructure. These limitations pose a question of new networking paradigms, leading to the introduction of Software-Defined Networking (SDN).
|
||||
|
||||
尽管传统的IP网络被广泛采用，但它们复杂且难以管理。要对网络进行任何更改，操作员需要使用底层且特定于供应商的命令单独配置每个网络设备。控制平面和数据平面在每个网络设备中的垂直集成降低了灵活性，并阻碍了网络基础设施的创新和发展。这些限制提出了关于新网络范式的问题，从而引入了软件定义网络（SDN）。
|
||||
|
||||
Some key ideas of SDN are the introduction of dynamic programmability in forwarding devices, the decoupling of the control and data planes, and the global view of the network by logical centralization of the “network brain” [KRV+ 15] in a single place, namely the controller.
|
||||
|
||||
SDN的一些关键理念包括在转发设备中引入动态可编程性、解耦控制平面和数据平面，以及通过逻辑集中化将“网络大脑”集中在单一位置（即控制器）以实现网络的全局视图 [KRV+ 15]。
|
||||
|
||||
## 4.2 Architecture
|
||||
|
||||
Having explained the three-plane view of traditional networks, we will now go deeper into the SDN architecture.
|
||||
|
||||
在解释了传统网络的三平面视图之后，我们现在将深入探讨SDN架构。
|
||||
|
||||
SDN is a network architecture where network control is decoupled from forwarding and is directly programmable [Foun 12].
|
||||
|
||||
SDN是一种网络架构，其网络控制与转发解耦并直接可编程 [Foun 12]。
|
||||
|
||||
A comparison of a traditional network and an SDN in the three-plane view is illustrated in Figure 4.4. In the traditional network, the routing table at the data plane of a router is populated by its control plane residing in the same device, such as the OSPF routing protocol running on the router’s operating system in this example. In SDN, the controller acts as a "network operating system," and the OSPF routing protocol runs atop the controller, which instructs the controller to populate flow tables in the SDN devices via the southbound API. The mapping of the management plane’s services in these two networks is not relevant in terms of network control and is not portrayed in this example to avoid unnecessary confusion.
|
||||
|
||||
图4.4展示了传统网络和SDN在三平面视图中的对比。在传统网络中，路由器的数据平面的路由表由其控制平面填充，控制平面位于同一设备中，例如运行在路由器操作系统上的OSPF路由协议。而在SDN中，控制器扮演“网络操作系统”的角色，OSPF路由协议运行在控制器之上，并通过南向API指示控制器填充SDN设备中的流表。在这一示例中，管理平面服务的映射与网络控制无关，因此未呈现，以避免不必要的混淆。
|
||||
|
||||
|
||||
|
||||
The general SDN architecture is illustrated in Figure 4.5.
|
||||
|
||||
图4.5展示了通用的SDN架构。
|
||||
|
||||
|
||||
|
||||
Kreutz et al. [KRV+ 15] define SDN as a network architecture with four pillars:Kreutz等人 [KRV+ 15] 将SDN定义为一种具有以下四个支柱的网络架构：
|
||||
|
||||
1. The control and data planes are decoupled. Control functionality is removed from network devices that will become simple (packet) forwarding elements.
|
||||
控制平面和数据平面解耦。控制功能从网络设备中移除，使这些设备变成简单的（数据包）转发元素。
|
||||
2. Forwarding decisions are flow-based, instead of destination-based (refer to Section 4.3 for the explanation of the flow concept).
|
||||
转发决策基于流而不是基于目的地（详见第4.3节对流的概念的解释）。
|
||||
3. Control logic is moved to an external entity, the so-called SDN controller.
|
||||
控制逻辑迁移到一个外部实体，即所谓的SDN控制器。
|
||||
4. The network is programmable through software applications running on top of the controller that interacts with underlying data plane devices.
|
||||
通过运行在控制器之上的软件应用程序对网络进行编程，这些应用程序与底层数据平面设备交互。
|
||||
|
||||
Another important characteristic of SDN mentioned in [RFC 7426] is the standardization of the interfaces between the control and data planes.
|
||||
[RFC 7426] 中提到的SDN的另一个重要特性是控制平面和数据平面之间接口的标准化。
|
||||
|
||||
### 4.2.1 Components
|
||||
|
||||
The main components of a SDN include devices in the data plane and one or more controllers.
|
||||
SDN的主要组件包括数据平面的设备和一个或多个控制器。
|
||||
|
||||
#### SDN-devices
|
||||
|
||||
SDN devices, also commonly referred to as SDN switches, are simple forwarding elements without embedded control or software to take autonomous decisions like routing protocols or default/fixed forwarding behavior. The network intelligence is removed from them to a logically centralized controller. Packets are handled in these switches based on their flow tables, whose entries contain control information of different layers (e.g., layer 2 - 4). Standardized interfaces are introduced between the controller and the switches, which provide a means for the controller to install flow tables in these switches.
|
||||
|
||||
SDN设备，也常被称为SDN交换机，是简单的转发元素，没有嵌入的控制功能或用于做出自主决策的软件，如路由协议或默认/固定的转发行为。网络智能从这些设备中被移到逻辑集中化的控制器中。这些交换机根据其流表处理数据包，流表中的条目包含不同层（如第2层至第4层）的控制信息。在控制器和交换机之间引入了标准化接口，控制器可以通过这些接口向交换机安装流表。
|
||||
|
||||
#### Controller
|
||||
|
||||
The controller is a software stack that controls SDN devices. One important function of the controller is the provision of topology service, which maintains a consistent overview of the network. Any change in the network, such as new devices being added or some devices being removed, or some links being down, should be reflected immediately in the network overview at the controller. The controller changes the configuration of network devices based on applications’ requests.
|
||||
|
||||
控制器是一个控制SDN设备的软件栈。控制器的一个重要功能是提供拓扑服务，它维护网络的一致概览。网络中的任何变化，例如新设备的添加、某些设备的移除或某些链路的中断，都应立即反映在控制器的网络概览中。控制器根据应用程序的请求更改网络设备的配置。
|
||||
|
||||
According to Goransson et al. [GoBl 14], four fundamental functions of an SDN controller are:
|
||||
根据Goransson等人 [GoBl 14] 的说法，SDN控制器的四个基本功能是：
|
||||
|
||||
- **End-user device discovery**,
|
||||
**终端用户设备发现**，
|
||||
- **Network device discovery**,
|
||||
**网络设备发现**，
|
||||
- **Network device topology management**, which maintains information about the interconnection details of the network devices to each other and to the end-user devices to which they are directly attached,
|
||||
**网络设备拓扑管理**，维护网络设备彼此之间以及与直接连接的终端用户设备之间的互联细节信息，
|
||||
- **Flow management**, which maintains a database of the flows being managed by the controller and performs all necessary coordination with the devices to ensure synchronization of the device flow entries with that database.
|
||||
**流管理**，维护由控制器管理的流的数据库，并与设备进行所有必要的协调，以确保设备的流表条目与该数据库同步.
|
||||
|
||||
Further functions of the network are realized by SDN applications (see Section 4.2.3).
|
||||
网络的进一步功能由SDN应用程序实现（见第4.2.3节）。
|
||||
|
||||
### 4.2.2 Interfaces
|
||||
|
||||
The SDN architecture introduces two interfaces: the northbound APIs lying between the applications and the controller, and the southbound APIs between the controller and the SDN devices. While OpenFlow [MAB+ 08] and P4Runtime [P4RTSpec] appear to be the most dominant southbound APIs, there are no such counterparts for northbound APIs so far. Each controller has its own northbound APIs.
|
||||
|
||||
SDN架构引入了两种接口：位于应用程序与控制器之间的北向API，以及控制器与SDN设备之间的南向API。尽管OpenFlow [MAB+ 08] 和P4Runtime [P4RTSpec] 是最为主流的南向API，但目前北向API尚无类似的标准化对等接口。每个控制器都有其独特的北向API。
|
||||
|
||||
### 4.2.3 SDN Applications
|
||||
|
||||
|
||||
|
||||
The control functions of the network (e.g., MAC learning of switches, routing, enforcement of QoS, security...) are programmed in applications, which logically reside above the controller. Applications can change the configuration of switches via the controller’s northbound API.
|
||||
|
||||
网络的控制功能（例如交换机的MAC学习、路由、QoS实施、安全性等）由应用程序编程实现，这些应用程序逻辑上位于控制器之上。应用程序可以通过控制器的北向API更改交换机的配置。
|
||||
|
||||
Taking a simple routing application as an example [KRV+ 15]: the logic of this application is to define the path through which packets flow from a point A to a point B. To achieve this goal, the routing application must, based on the topology input, decide on the path to use and instruct the controller to install the respective forwarding rules in all devices on the chosen path from A to B.
|
||||
|
||||
以一个简单的路由应用为例 [KRV+ 15]：该应用程序的逻辑是定义从A点到B点的数据包流经的路径。为了实现这一目标，路由应用程序需要根据拓扑输入确定要使用的路径，并指示控制器在所选路径上的所有设备中安装相应的转发规则，从A到B。
|
||||
|
||||
Once the controller has finished initializing devices and reported the network topology to the application, the application spends most of its processing time responding to events. Application behavior is driven by events from the controller as well as external inputs. The application affects the network by responding to the events as modeled in Figure 4.6.
|
||||
|
||||
一旦控制器完成设备初始化并将网络拓扑报告给应用程序，应用程序的大部分处理时间将用于响应事件。应用程序的行为由来自控制器的事件以及外部输入驱动。通过响应事件，应用程序影响网络的行为，这在图4.6中有所建模。
|
||||
|
||||
The SDN application registers as a listener for certain events, and the controller invokes the application’s callback method whenever such an event occurs. Some examples of events handled by an SDN application are:
|
||||
SDN应用程序注册为某些事件的侦听器，控制器在这些事件发生时会调用应用程序的回调方法。SDN应用程序处理的事件包括：
|
||||
|
||||
- End-user device discovery,
|
||||
- Network device discovery,
|
||||
- Incoming packets.
|
||||
|
||||
In the first two cases, events are sent to the SDN application when a new end-user device (e.g., a MAC address) or a new network device (e.g., a switch, router, or wireless access point) is discovered. Incoming packet events are sent to the SDN application when a packet is received from an SDN device either due to a flow entry instructing the device to forward the packet to the controller or because no matching flow entry exists in the SDN device.
|
||||
|
||||
在前两种情况下，当发现新的终端用户设备（例如MAC地址）或新的网络设备（例如交换机、路由器或无线接入点）时，事件会发送到SDN应用程序。当从SDN设备接收到数据包时，也会发送数据包事件到SDN应用程序，这可能是由于流表条目指示SDN设备将数据包转发到控制器，或者因为SDN设备中没有匹配的流表条目。
|
||||
|
||||
When there is no matching flow entry, the default action is usually to forward the packet to the controller. However, depending on the nature of the application, the packet may instead be dropped [GoBl 14].
|
||||
|
||||
当没有匹配的流表条目时，默认操作通常是将数据包转发到控制器。然而，根据应用程序的性质，也可能选择丢弃数据包 [GoBl 14]。
|
||||
|
||||
## 4.3 Flows
|
||||
|
||||
In SDN, forwarding decisions are flow-based, instead of destination-based as in traditional networks. There is often confusion between the two concepts of path and flow, which need to be clearly distinguished and used correctly.
|
||||
|
||||
在SDN中，转发决策是基于流而非传统网络中的基于目的地。路径和流这两个概念经常被混淆，需要明确区分并正确使用。
|
||||
|
||||
A **path** is the sequence of communication links and devices connecting two endpoints. It is also known as a route and is the foundation of IP routing. The concept of path is topology-oriented, meaning it focuses only on the way through the network, without considering the type of traffic or its content (payload).
|
||||
|
||||
**路径** 是连接两个端点的通信链路和设备的序列。它也被称为路由，是IP路由的基础。路径的概念是拓扑导向的，这意味着它只关注通过网络的路径，而不关注流量的类型和内容（有效负载）。
|
||||
|
||||
A **flow**, or data stream, is a sequence of packets that share the same attributes. These attributes include fields in the protocol header, such as IP address, MAC address, status bit, etc.; they can also include the ingress port of a packet arriving at a network device. Thus, the concept of flow encompasses traffic types and possibly traffic content (payload). Flows are unidirectional and are determined by:
|
||||
**流** 或数据流，是一系列共享相同属性的数据包。这些属性包括协议头中的字段，例如IP地址、MAC地址、状态位等；也可以包括到达网络设备的数据包的入口端口。因此，流的概念包含流量类型，甚至可能包括流量内容（有效负载）。流是单向的，由以下三个方面决定：
|
||||
|
||||
- The path(路径),
|
||||
- The concerned attributes(相关属性),
|
||||
- The direction (which can be considered a special case of the attributes, like address)方向（可视为属性的特殊情况，例如地址）.
|
||||
|
||||
**Example:** Traffic between two endpoints A and B exchanging audio streams and HTTP traffic can be seen as four different flows:
|
||||
|
||||
1. A flow for audio traffic along the path from A to B,
|
||||
2. A flow for audio traffic along the path from B to A,
|
||||
3. A flow for HTTP traffic along the path from A to B,
|
||||
4. A flow for HTTP traffic along the path from B to A.
|
||||
|
||||
**示例：** 在两个端点A和B之间交换音频流和HTTP流量时，可以看作四个不同的流：
|
||||
|
||||
1. 从A到B的音频流量流，
|
||||
2. 从B到A的音频流量流，
|
||||
3. 从A到B的HTTP流量流，
|
||||
4. 从B到A的HTTP流量流。
|
||||
|
||||
**Figure 4.7** [Danc 15] illustrates how four data streams are routed in a traditional network (left picture) and in an SDN (right picture).
|
||||
|
||||
**图4.7** [Danc 15] 说明了四个数据流如何在传统网络（左图）和SDN（右图）中路由。
|
||||
|
||||
- In a traditional network, data streams destined for the same destination are typically routed along the same path because the routing mechanism is destination-based.
|
||||
在传统网络中，发送到同一目的地的数据流通常沿同一路径路由，因为路由机制是基于目的地的。
|
||||
- In SDN, these data streams are routed based on their flows’ attributes, which means they may traverse different paths from the source to the destination.
|
||||
在SDN中，这些数据流是根据其流的属性路由的，因此它们可能沿不同路径从源到达目的地。
|
||||
|
||||
|
||||
|
||||
It is important to note that a flow can be reflected differently in each device along the path. For instance, one network device might handle the flow based on the first attribute (e.g., destination IP address), while another might base its handling on the second attribute (e.g., destination TCP port number).
|
||||
|
||||
需要注意的是，一个流在路径上的每个设备中可能有不同的表现。例如，一个网络设备可能基于流的第一个属性（例如目的地IP地址）处理流，而另一个设备可能基于第二个属性（例如目的地TCP端口号）处理流。
|
||||
|
||||
**Specification of Flow ** **流的规范**
|
||||
An SDN device stores information about flows in tables, referred to as flow tables or rule tables. Each table entry contains:
|
||||
SDN设备将流的信息存储在表中，称为流表或规则表。每个表条目包含：
|
||||
|
||||
- **Match fields**, which define the flow based on protocol fields (e.g., IP, MAC, port, VLAN, etc.). **匹配字段**，基于协议字段（例如IP、MAC、端口、VLAN等）定义流。
|
||||
- **Actions**, which are executed when the match fields are satisfied. **操作**，当匹配字段满足时执行相应的操作。
|
||||
|
||||
A match field can be wildcarded to match any value, thereby reducing the number of table entries.
|
||||
匹配字段可以使用通配符匹配任意值，从而减少表条目的数量。
|
||||
|
||||
The actions applied to a matched flow can include:
|
||||
匹配流所应用的操作可能包括：
|
||||
|
||||
- Sending the packets of that flow to a specific port (interface of the SDN device). 将该流的数据包发送到指定端口（SDN设备的接口）。
|
||||
- Dropping the packets. 丢弃数据包。
|
||||
- Forwarding the packets to the controller. 将数据包转发到控制器。
|
||||
- Sending packets to some or all ports (flooding, broadcast, multicast). 将数据包发送到部分或所有端口（泛洪、广播、多播）。
|
||||
- Modifying the packets. 修改数据包。
|
||||
- A combination of the above actions. 以上操作的某种组合。
|
||||
|
||||
**Priority** 优先级
|
||||
Table entries are organized in rows, each with a specified priority. More specific entries should have higher priority than general ones (which have more masked fields).
|
||||
表条目按行组织，每行具有指定的优先级。更具体的条目应比更一般的条目（即具有更多掩码字段的条目）具有更高的优先级。
|
||||
|
||||
## 4.4 SDN Deployment Example with P4 and P4Runtime
|
||||
|
||||
The most common implementations of SDN include those based on OpenFlow [MAB+ 08] and P4 [BDG+ 14].
|
||||
SDN最常见的实现包括基于OpenFlow [MAB+ 08] 和P4 [BDG+ 14] 的实现。
|
||||
|
||||
OpenFlow assumes that SDN devices have fixed behavior. It supports populating the rule tables in these devices but is constrained by their fixed capabilities. OpenFlow cannot be used to deploy a rule that influences a new packet header not yet available in these fixed-function devices.
|
||||
OpenFlow假设SDN设备具有固定的行为。它支持在这些设备中填充规则表，但受其固定功能的限制。无法使用OpenFlow部署影响固定功能设备中尚未支持的新数据包头的规则。
|
||||
|
||||
P4 was introduced to address this limitation by providing a mechanism to program devices' behavior. P4Runtime enables communication between SDN controllers and P4 devices.P4的引入旨在解决这一问题，它提供了一种编程设备行为的机制。P4Runtime实现了SDN控制器与P4设备之间的通信。
|
||||
|
||||
### 4.4.1 P4
|
||||
|
||||
P4 is a language for programming the data plane of network devices. The name P4 comes from the original paper that introduced the language: *“Programming Protocol-independent Packet Processors”* [BDG+ 14]. The version of P4 introduced in 2014 is named P414, and the language was revised in 2016 to P416, which is used in this assignment.
|
||||
P4是一种用于编程网络设备数据平面的语言。P4的名称来源于该语言的原创论文：*“Programming Protocol-independent Packet Processors”* [BDG+ 14]。2014年发布的P4版本被称为P414，该语言在2016年进行了修订，被称为P416，本次作业中使用的就是P416版本。
|
||||
|
||||
In a traditional switch, the manufacturer defines the data-plane functionality. The control plane manages the data plane by:
|
||||
在传统交换机中，数据平面的功能由制造商定义。控制平面通过以下方式管理数据平面：
|
||||
|
||||
- Managing entries in their rule tables (e.g., routing tables), 管理规则表（例如路由表）中的条目，
|
||||
- Configuring specialized objects (e.g., meters), 配置专用对象（例如计量器），
|
||||
- Processing control packets (e.g., routing protocol packets), 处理控制数据包（例如路由协议数据包），
|
||||
- Handling asynchronous events (e.g., link state changes or learning notifications). 处理异步事件（例如链路状态变化或学习通知）。
|
||||
|
||||
A P4-programmable switch differs from a traditional switch in two essential ways:
|
||||
P4可编程交换机与传统交换机有两个主要区别：
|
||||
|
||||
1. **Data plane functionality is not predefined**: The functionality is defined by a P4 program. The data plane is configured at initialization to implement the behavior described by the P4 program and has no built-in knowledge of existing network protocols.
|
||||
**数据平面的功能不是预先定义的**：其功能由P4程序定义。数据平面在初始化时配置，以实现P4程序描述的行为，并且对现有网络协议没有内置知识。
|
||||
2. **Dynamic communication with the control plane**: The control plane communicates with the data plane using the same channels as in fixed-function devices, but the tables and objects in the data plane are not fixed. Instead, they are defined by a P4 program. The P4 compiler generates the API used by the control plane to interact with the data plane.
|
||||
**与控制平面的动态通信**：控制平面通过与固定功能设备相同的通道与数据平面通信，但数据平面中的表和对象不再固定，而是由P4程序定义的。P4编译器生成控制平面与数据平面交互所使用的API。
|
||||
|
||||
|
||||
|
||||
**Figure 4.8** shows a typical tool workflow for programming a target using P4. A *target* is defined as a packet-processing system capable of executing a P4 program. The term *target* is used interchangeably with *device* in most P4 specifications and in this manuscript.
|
||||
**图4.8** 展示了使用P4编程目标设备的典型工具工作流程。*目标设备* 被定义为能够执行P4程序的数据包处理系统。在大多数P4规范以及本手稿中，*目标设备* 与*设备*的术语可以互换使用。
|
||||
|
||||
Target manufacturers provide the hardware or software implementation framework, an architecture definition, and a P4 compiler for the target. P4 programmers write programs specific to a target architecture, which defines a set of P4-programmable components and their external data plane interfaces.
|
||||
目标设备的制造商提供硬件或软件实现框架、架构定义和针对目标设备的P4编译器。P4程序员为特定的架构编写程序，该架构定义了目标设备上可用的一组P4可编程组件及其外部数据平面接口。
|
||||
|
||||
Compiling a set of P4 programs produces two artifacts:
|
||||
编译一组P4程序会生成两个成果：
|
||||
|
||||
1. A **data plane configuration** implementing the forwarding logic described in the program.
|
||||
**数据平面配置**，用于实现输入程序中描述的转发逻辑。
|
||||
2. An **API** for managing the state of the data plane objects from the control plane.
|
||||
**API**，用于从控制平面管理数据平面对象的状态。
|
||||
|
||||
#### Architecture Model
|
||||
|
||||
The P4 architecture identifies the P4-programmable blocks (e.g., parser, ingress control flow, egress control flow, deparser, etc.) and their data plane interfaces.
|
||||
|
||||
P4架构定义了P4可编程模块（例如解析器、入口控制流、出口控制流、反解析器等）及其数据平面接口。
|
||||
|
||||
The P4 architecture can be thought of as a contract between the program and the target. Each manufacturer must provide both a P4 compiler and an accompanying architecture definition for their target.
|
||||
|
||||
P4架构可以被视为程序与目标设备之间的契约。因此，每个制造商必须为其目标设备提供P4编译器及其配套的架构定义。
|
||||
|
||||
|
||||
|
||||
**Figure 4.9** illustrates the data plane interfaces between P4-programmable blocks. It depicts a target with two programmable blocks (#1 and #2), each of which is programmed through a separate fragment of P4 code. The target interfaces with the P4 program via a set of control registers or signals:
|
||||
**图4.9** 展示了P4可编程模块之间的数据平面接口。图中显示了一个包含两个可编程模块（#1和#2）的目标设备，每个模块通过一个独立的P4代码片段进行编程。目标设备通过一组控制寄存器或信号与P4程序交互：
|
||||
|
||||
- **Input controls** provide information to P4 programs (e.g., the input port a packet was received from). **输入控制** 为P4程序提供信息（例如，接收到数据包的输入端口）。
|
||||
- **Output controls** can be written to by P4 programs to influence the target’s behavior (e.g., the output port where a packet should be directed). **输出控制** 可由P4程序写入以影响目标设备的行为（例如，数据包应被引导到的输出端口）。
|
||||
|
||||
Control registers/signals are represented in P4 as **intrinsic metadata**, while P4 programs can also define and manipulate **user-defined metadata** to store data related to each packet.
|
||||
|
||||
控制寄存器/信号在P4中表示为**内在元数据**，而P4程序还可以定义并操作**用户定义元数据**以存储与每个数据包相关的数据。
|
||||
|
||||
There are various architectures, such as **V1Model**, **SimpleSumeSwitch**, and the **Portable Switch Architecture (PSA)** [PSADraft]. In this assignment, we use the **V1Model** on the BMv2 (Behavioral Model version 2) Simple Switch target because of its ease of deployment as a software switch.
|
||||
|
||||
存在多种架构，例如 [**V1Model**](https://github.com/p4lang/p4c/blob/main/p4include/v1model.p4)、[**SimpleSumeSwitch**](https://github.com/NetFPGA/P4-NetFPGA-public/wiki) 和 **可移植交换架构 (PSA)** [PSADraft]。在本次作业中，由于易于作为软件交换机部署，我们使用了 **BMv2（行为模型第2版）[Simple Switch](https://github.com/p4lang/behavioral-model/blob/main/docs/simple_switch.md)目标** 上的 **V1Model**。
|
||||
|
||||
#### V1Model
|
||||
|
||||
|
||||
|
||||
**Figure 4.10** illustrates the programmable blocks of the V1Model architecture. The **standard metadata** in V1Model includes:
|
||||
|
||||
```c++
|
||||
struct standard_metadata_t {
|
||||
bit<9> ingress_port;
|
||||
bit<9> egress_spec;
|
||||
bit<9> egress_port;
|
||||
bit<32> clone_spec;
|
||||
bit<32> instance_type;
|
||||
bit<1> drop;
|
||||
bit<16> recirculate_port;
|
||||
bit<32> packet_length;
|
||||
bit<32> enq_timestamp;
|
||||
bit<19> enq_qdepth;
|
||||
bit<32> deq_timedelta;
|
||||
bit<19> deq_qdepth;
|
||||
bit<48> ingress_global_timestamp;
|
||||
bit<32> lf_field_list;
|
||||
bit<16> mcast_grp;
|
||||
bit<1> resubmit_flag;
|
||||
bit<16> egress_rid;
|
||||
bit<1> checksum_error;
|
||||
bit<3> priority;
|
||||
}
|
||||
```
|
||||
|
||||
The **ingress_port** is the port on which a packet arrived. The **egress_spec** specifies the port to which the packet should be sent. The **egress_port** denotes the port from which the packet is departing and is read-only in the egress pipeline.
|
||||
**ingress_port** 是数据包到达的端口。**egress_spec** 指定数据包应被发送到的端口。**egress_port** 表示数据包离开的端口，在出口管道中是只读的。
|
||||
|
||||
The file `v1model.p4` is extensively commented, providing details on these and other fields of the standard metadata.
|
||||
|
||||
文件 `v1model.p4` 中有详细的注释，提供了关于这些字段及其他标准元数据字段的详细信息。
|
||||
|
||||
The **P416 program template** for the V1Model architecture includes:
|
||||
**P416程序模板** 适用于V1Model架构，包含以下部分：
|
||||
|
||||
- **头部规范 (HEADER specification)**
|
||||
- **解析器 (PARSER)**
|
||||
- **校验和验证 (CHECKSUM VERIFICATION)**
|
||||
- **入口处理 (INGRESS PROCESSING)**
|
||||
- **出口处理 (EGRESS PROCESSING)**
|
||||
- **校验和更新 (CHECKSUM UPDATE)**
|
||||
- **反解析器块 (DEPARSER blocks)**
|
||||
- **V1Switch包**
|
||||
|
||||
```c++
|
||||
#include <core.p4>
|
||||
#include <v1model.p4>
|
||||
|
||||
/* 头部定义 */
|
||||
struct metadata { ... }
|
||||
struct headers {
|
||||
ethernet_t ethernet;
|
||||
ipv4_t ipv4;
|
||||
}
|
||||
|
||||
/* 解析器 */
|
||||
parser MyParser(packet_in packet,
|
||||
out headers hdr,
|
||||
inout metadata meta,
|
||||
inout standard_metadata_t smeta) {
|
||||
...
|
||||
}
|
||||
|
||||
/* 校验和验证 */
|
||||
control MyVerifyChecksum(in headers hdr,
|
||||
inout metadata meta) {
|
||||
...
|
||||
}
|
||||
|
||||
/* 入口处理 */
|
||||
control MyIngress(inout headers hdr,
|
||||
inout metadata meta,
|
||||
inout standard_metadata_t std_meta) {
|
||||
...
|
||||
}
|
||||
|
||||
/* 出口处理 */
|
||||
control MyEgress(inout headers hdr,
|
||||
inout metadata meta,
|
||||
inout standard_metadata_t std_meta) {
|
||||
...
|
||||
}
|
||||
|
||||
/* 反解析器 */
|
||||
control MyDeparser(packet_out packet,
|
||||
in headers hdr) {
|
||||
...
|
||||
}
|
||||
control MyEgress(inout headers hdr,
|
||||
inout metadata meta,
|
||||
inout standard_metadata_t std_meta) {
|
||||
...
|
||||
}
|
||||
|
||||
/* CHECKSUM UPDATE */
|
||||
control MyComputeChecksum(inout headers hdr,
|
||||
inout metadata meta) {
|
||||
...
|
||||
}
|
||||
|
||||
/* DEPARSER */
|
||||
control MyDeparser(inout headers hdr,
|
||||
inout metadata meta) {
|
||||
...
|
||||
}
|
||||
|
||||
/* SWITCH */
|
||||
V1Switch(
|
||||
MyParser(),
|
||||
MyVerifyChecksum(),
|
||||
MyIngress(),
|
||||
MyEgress(),
|
||||
MyComputeChecksum(),
|
||||
MyDeparser()
|
||||
) main;
|
||||
|
||||
```
|
||||
|
||||
P4_{16} defines various data types, such as `bit`, `bool`, `int`, `string`, `struct`, `enum`, and `header_union`. These data types are described in its specification [P4Spec] (see Section 7 of the specification).
|
||||
|
||||
P416定义了多种数据类型，例如 `bit`、`bool`、`int`、`string`、`struct`、`enum` 和 `header_union`。这些数据类型在其规范 [P4Spec]（参见规范第7节）中有详细说明。
|
||||
|
||||
Another useful reference is the [**P4 Language Cheat Sheet**](https://github.com/p4lang/tutorials/blob/master/p4-cheat-sheet.pdf), which outlines the basic building blocks of P4.
|
||||
|
||||
另一个有用的参考资料是 **[P4语言速查表](https://github.com/p4lang/tutorials/blob/master/p4-cheat-sheet.pdf) (P4 Language Cheat Sheet)**，其中概述了P4的基本构建模块。
|
||||
|
||||
An example of compiling a P4 source file into a **P4 Device Config** file, which can be executed in BMv2 switches, is provided in a later section.
|
||||
|
||||
有关将P4源文件编译为**P4设备配置 (P4 Device Config)** 文件，并在BMv2交换机中执行的示例，将在后续章节中提供。
|
||||
|
||||
### 4.4.2 P4Runtime
|
||||
|
||||
The **P4Runtime API** [P4RTSpec] is a control plane specification for managing the data plane elements of a device defined or described by a P4 program.
|
||||
|
||||
**P4Runtime API** [P4RTSpec] 是一种控制平面规范，用于管理由P4程序定义或描述的设备数据平面元素。
|
||||
|
||||
|
||||
|
||||
**Figure 4.11** illustrates the P4Runtime reference architecture. The device or target to be controlled is at the bottom, while one or more controllers are shown at the top. P4Runtime grants **write access** to only a single **primary controller** for each read/write entity.
|
||||
|
||||
**图4.11** 展示了P4Runtime参考架构。需要控制的设备或目标位于底部，而一个或多个控制器位于顶部。对于每个读/写实体，P4Runtime仅授予一个**主控制器**的**写访问权限**。
|
||||
|
||||
The P4Runtime API defines the messages and semantics of the interface between the client(s) and the server. The API is specified in the `p4runtime.proto` [Protobuf file](https://github.com/p4lang/p4runtime).
|
||||
|
||||
P4Runtime API 定义了客户端和服务器之间接口的消息和语义。该API在 `p4runtime.proto` Protobuf文件中进行了规范化。
|
||||
|
||||
The controller can access P4 entities that are declared in the **P4Info metadata**.
|
||||
|
||||
控制器可以访问在 **P4Info元数据** 中声明的P4实体。
|
||||
|
||||
The **P4Info structure** is defined in the `p4info.proto` file, another Protobuf file included as part of the P4Runtime standard.
|
||||
|
||||
**P4Info结构** 定义在 `p4info.proto` 文件中，这是P4Runtime标准的一部分。
|
||||
|
||||
The controller can set the **ForwardingPipelineConfig**, which involves:
|
||||
|
||||
控制器可以设置 **ForwardingPipelineConfig**，包括以下内容：
|
||||
|
||||
- Installing and running the compiled P4 program output included in the `p4_device_config` field of the Protobuf message.
|
||||
安装并运行包含在 Protobuf 消息 p4_device_config 字段中的已编译P4程序输出。
|
||||
- Installing the associated **P4Info metadata**.
|
||||
安装相关的 **P4Info元数据**。
|
||||
|
||||
The controller can also query the target for the **ForwardingPipelineConfig** to retrieve the device configuration and the P4Info.
|
||||
|
||||
控制器还可以查询目标设备的 **ForwardingPipelineConfig** 以获取设备配置和P4Info。
|
||||
|
||||
The **P4Runtime API** is implemented by a program running a gRPC server that binds to an auto-generated P4Runtime Service interface. This program is called the **P4Runtime server**. By default, the server must listen on **TCP port 9559**, allocated by IANA for the P4Runtime service. However, servers should allow users to override the default port using a configuration file or a startup flag.
|
||||
|
||||
**P4Runtime API** 通过运行一个绑定自动生成的 P4Runtime 服务接口的 gRPC 服务器实现。这个程序被称为 **P4Runtime服务器**。默认情况下，服务器必须监听 **TCP端口9559**，这是IANA为P4Runtime服务分配的端口。不过，服务器应允许用户通过配置文件或启动标志覆盖默认端口。
|
||||
|
||||
In this assignment, we follow the **“idealized workflow”** described in the P4Runtime specification [P4RTSpec] (Section 3.2). This workflow includes:在本次作业中，我们遵循P4Runtime规范 [P4RTSpec] 中描述的 **“理想化工作流程”**（参见规范第3.2节）。该工作流程包括：
|
||||
|
||||
1. Compiling a P4 source program to produce: 将P4源程序编译为：
|
||||
- A **P4 device config**. **P4设备配置**。
|
||||
- **P4Info metadata**. **P4Info元数据**。
|
||||
These together comprise the **ForwardingPipelineConfig** message.
|
||||
这些共同组成 **ForwardingPipelineConfig** 消息。
|
||||
2. The P4Runtime controller selects an appropriate configuration for a particular target and installs it via the **SetForwardingPipelineConfig RPC**.
|
||||
P4Runtime控制器选择适合特定目标设备的配置，并通过 **SetForwardingPipelineConfig RPC** 安装它。
|
||||
|
||||
The **P4Info metadata** describes: **P4Info元数据** 描述了：
|
||||
|
||||
- The overall program itself (**PkgInfo**). 整个程序本身（**PkgInfo**）。
|
||||
- All entity instances derived from the P4 program, such as **tables** and **extern instances**. 所有从P4程序派生的实体实例，例如 **表** 和 **外部实例**。
|
||||
|
||||
Each entity instance is assigned a numeric ID by the P4 compiler, which serves as a concise "handle" for use in API calls.
|
||||
每个实体实例由P4编译器分配一个数字ID，用作API调用中使用的简洁“句柄”。
|
||||
|
||||
In this workflow, **P4 compiler backends** are developed for each unique type of target and generate two outputs:
|
||||
在此工作流程中，为每种独特类型的目标设备开发了 **P4编译器后端**，并生成两个输出：
|
||||
|
||||
- **P4Info**: A schema that is target- and architecture-independent, although its specific contents are likely to be architecture-dependent.
|
||||
**P4Info**：一个目标和架构无关的模式，但其具体内容可能与架构相关。
|
||||
- A **target-specific device config**.
|
||||
**特定目标设备的配置**。
|
||||
|
||||
The compiler ensures that the P4 program is compatible with the specific target and rejects incompatible code.
|
||||
编译器确保P4程序与特定目标兼容，并拒绝不兼容的代码。
|
||||
|
||||
|
||||
|
||||
**P4Runtime** supports the use of multiple controllers. A controller can either be embedded in a P4 target or operate separately. For P4-based SDN, the preferred approach is to deploy controllers separately from the targets, as shown in **Figure 4.12**.
|
||||
**P4Runtime** 支持多个控制器的使用。控制器可以嵌入在P4目标设备中，也可以独立运行。对于基于P4的SDN，我们选择将控制器与目标设备分离部署，如 **图4.12** 所示。
|
||||
|
||||
A single **logically centralized controller** can control multiple targets simultaneously.
|
||||
一个 **逻辑集中式控制器** 可以同时控制多个目标设备。
|
||||
|
||||
### 4.4.3 Test-bed
|
||||
|
||||
The provided infrastructure for this assignment includes an **“outer” virtual machine** (`gruppeX.rnp.lab.nm.ifi.lmu.de`), which hosts seven **“inner” virtual machines**. These inner machines include:
|
||||
该作业提供的基础设施包括一个 **“外部”虚拟机** (`gruppeX.rnp.lab.nm.ifi.lmu.de`)，其中创建了七个 **“内部”虚拟机**，包括：
|
||||
|
||||
- Hosts: `pc1`, `pc2`, `pc3`.
|
||||
- Switches: `S1`, `S2`, `S3`.
|
||||
- A controller deployed at `router4`.
|
||||
|
||||
|
||||
|
||||
The connections between these machines are illustrated in **Figure 4.13**: 这些机器之间的连接如 **图4.13** 所示：
|
||||
|
||||
- **Dashed lines**: Represent the management network, used for accessing and configuring the inner machines. **虚线**：表示管理网络，用于访问和配置内部机器。
|
||||
- **Solid lines**: Represent the data network, used for communication between the inner machines.
|
||||
All `eth0` interfaces of the inner machines are connected to the same switch in the management network. **实线**：表示数据网络，用于内部机器之间的通信。所有内部机器的 `eth0` 接口都连接到管理网络的同一交换机。
|
||||
|
||||
The infrastructure is pre-configured with all the software necessary for this assignment. The **P4 compiler** is installed only on the controller (`router4`). As a result, P4 source files must be compiled on the controller to generate: 基础设施已预装完成该作业所需的所有软件。**P4编译器**仅安装在控制器（`router4`）上。因此，P4源文件必须在控制器上编译，以生成：
|
||||
|
||||
- **P4 Device Config**: Consumed by P4 switches. **P4设备配置文件**：供P4交换机使用。
|
||||
- **P4Info files**: Consumed by controllers. **P4Info文件**：供控制器使用。
|
||||
|
||||
Instructions for installing P4-related software are provided in the **[P4 language tutorials](https://github.com/p4lang/tutorials)**, which include a sample deployment on [**Ubuntu 20.04**](https://github.com/p4lang/tutorials/blob/master/vm-ubuntu-20.04/root-release-bootstrap.sh). Additionally, the development team has facilitated P4 installation via the [**p4lang repository**](http://download.opensuse.org/repositories/home:/p4lang/) for package managers on **Debian 11** and **Ubuntu 22.04**. Installation can also be performed directly from the **[source code](https://github.com/p4lang/tutorials/blob/master/vm-ubuntu-20.04/user-dev-bootstrap.sh)**.
|
||||
|
||||
有关安装P4相关软件的说明，可以参考 **P4语言教程**，其中包括 **Ubuntu 20.04** 上的示例部署。此外，开发团队还通过 **p4lang 仓库** 提供了适用于 **Debian 11** 和 **Ubuntu 22.04** 的包管理器安装方式。也可以直接从 **源代码** 安装。
|
||||
|
||||
### 4.4.4 Example: deploying a simple repeater
|
||||
|
||||
We demonstrate how to execute P4 switches and have them controlled by a controller using a simple **repeater application**. This example reuses material provided by the **[ETH Networked Systems Group](https://github.com/nsg-ethz/p4-learning/tree/master/exercises/02-Repeater/p4runtime)**.
|
||||
|
||||
我们通过一个简单的 **中继器应用 (repeater application)** 演示如何运行P4交换机，并由控制器进行控制。本示例复用了 **ETH网络系统组 (ETH Networked Systems Group)** 提供的材料。
|
||||
|
||||
|
||||
|
||||
**Figure 4.14** illustrates the network topology used in this example, which includes:
|
||||
|
||||
- Two switches: **S1** and **S2**.
|
||||
- Two endpoints: **PC1** and **PC2**.
|
||||
- A **controller**.
|
||||
|
||||
The **P4 source files** and the **controller applications** are stored on the controller (`router4`) in the directories `p4` and `app`, respectively.
|
||||
|
||||
**P4源文件** 和 **控制器应用程序** 分别存储在控制器 (`router4`) 的 `p4` 和 `app` 目录中。
|
||||
|
||||
#### Compiling repeater.p4
|
||||
|
||||
As mentioned earlier, the P4 compiler is installed on the controller (`router4` in this case). To compile `repeater.p4` and generate the **P4 Device config** and **P4Info files**, execute the following commands:
|
||||
|
||||
如前所述，P4编译器安装在控制器上（在本例中为 `router4`）。要编译 `repeater.p4` 并生成 **P4设备配置文件** 和 **P4Info文件**，请执行以下命令：
|
||||
|
||||
```bash
|
||||
ssh root@router4
|
||||
cd p4
|
||||
p4c-bm2-ss --p4v 16 --p4runtime-files build/repeater.p4info.txt \
|
||||
-o build/repeater.json repeater.p4
|
||||
```
|
||||
|
||||
This produces two files:
|
||||
|
||||
- **`repeater.json`**: The P4 Device config file for the P4 switches.
|
||||
- **`repeater.p4info.txt`**: The P4Info file for the controller application `repeater_controller.py`.
|
||||
|
||||
生成的两个文件分别是：
|
||||
|
||||
- **`repeater.json`**：用于P4交换机的P4设备配置文件。
|
||||
- **`repeater.p4info.txt`**：控制器应用程序 `repeater_controller.py` 使用的P4Info文件。
|
||||
|
||||
#### Distributing the P4 Device Config File
|
||||
|
||||
The **`repeater.json`** file needs to be copied to the switches `S1` and `S2`. This can be done from the outer machine using the following commands:
|
||||
|
||||
需要将 **`repeater.json`** 文件复制到交换机 `S1` 和 `S2`。可以通过外部机器执行以下命令：
|
||||
|
||||
```bash
|
||||
scp -3 root@router4:p4/build/repeater.json root@s1:
|
||||
scp -3 root@router4:p4/build/repeater.json root@s2:
|
||||
```
|
||||
|
||||
#### Creating P4 Switches
|
||||
|
||||
At Switch S1
|
||||
|
||||
Use the following commands to create a P4 switch on `S1`:
|
||||
|
||||
使用以下命令在 `S1` 上创建一个 P4 交换机：
|
||||
|
||||
```bash
|
||||
ssh root@s1
|
||||
ip link set eth1 up
|
||||
ip link set eth2 up
|
||||
simple_switch_grpc -i 1@eth1 -i 2@eth2 --pcap pcaps \
|
||||
--nanolog ipc:///log.ipc --device-id 1 repeater.json \
|
||||
--log-console --thrift-port 9090 \
|
||||
-- --grpc-server-addr 0.0.0.0:50051 --cpu-port 255
|
||||
```
|
||||
|
||||
The `simple_switch_grpc` command creates a [**SimpleSwitchGrpc target**,](https://github.com/p4lang/behavioral-model/blob/main/targets/simple_switch_grpc/README.md) which is a version of **SimpleSwitch** with P4Runtime support.
|
||||
|
||||
`simple_switch_grpc` 命令创建了一个 **[SimpleSwitchGrpc 目标](https://github.com/p4lang/behavioral-model/blob/main/targets/simple_switch_grpc/README.md)**，这是支持 **P4Runtime** 的 **SimpleSwitch** 版本。
|
||||
|
||||
Explanation of parameters:
|
||||
|
||||
- `-i 1@eth1 -i 2@eth2`: Binds the switch ports to the "physical" interfaces of the virtual machine. `-i 1@eth1 -i 2@eth2`: 将交换机端口绑定到虚拟机的“物理”接口。
|
||||
- `--pcap pcaps`: Generates PCAP files for interfaces. `--pcap pcaps`: 为接口生成 PCAP 文件。
|
||||
- `--nanolog ipc:///log.ipc`: Specifies the IPC socket for nanomsg pub/sub logs. `--nanolog ipc:///log.ipc`: 指定 nanomsg 发布/订阅日志的 IPC 套接字。
|
||||
- `--device-id 1`: Sets the device ID for identifying the device in IPC messages. `--device-id 1`: 设置设备 ID，用于在 IPC 消息中标识设备。
|
||||
- `--log-console`: Enables logging to stdout. `--log-console`: 启用标准输出的日志记录。
|
||||
- `--thrift-port 9090`: Sets the TCP port for the Thrift runtime server. `--thrift-port 9090`: 设置 Thrift 运行时服务器的 TCP 端口。
|
||||
- `--grpc-server-addr 0.0.0.0:50051`: Binds the gRPC server to the specified address. `--grpc-server-addr 0.0.0.0:50051`: 将 gRPC 服务器绑定到指定地址。
|
||||
- `--cpu-port 255`: Specifies the logical port where a switch can communicate with a controller (packet-in/out). `--cpu-port 255`: 指定逻辑端口，交换机和控制器可以通过该端口通信（数据包输入/输出）。
|
||||
|
||||
For additional information, use the command: 如需更多信息，请使用命令：
|
||||
|
||||
```bash
|
||||
simple_switch_grpc --help
|
||||
```
|
||||
|
||||
At Switch S2
|
||||
|
||||
To create a P4 switch on `S2`, use similar commands: 在 `S2` 上创建 P4 交换机的命令类似：
|
||||
|
||||
```bash
|
||||
ssh root@s2
|
||||
ip link set eth1 up
|
||||
ip link set eth2 up
|
||||
simple_switch_grpc -i 1@eth1 -i 2@eth2 --pcap pcaps \
|
||||
--nanolog ipc:///log.ipc --device-id 2 repeater.json \
|
||||
--log-console --thrift-port 9090 \
|
||||
-- --grpc-server-addr 0.0.0.0:50051 --cpu-port 255
|
||||
```
|
||||
|
||||
#### Executing the Control Application
|
||||
|
||||
To execute the control application: 运行控制应用程序：
|
||||
|
||||
```bash
|
||||
ssh root@router4
|
||||
cd app
|
||||
python3 repeater_controller.py
|
||||
```
|
||||
|
||||
The **[p4-utils library](https://github.com/p4lang/behavioral-model/blob/main/targets/simple_switch_grpc/README.md)** is used (with some modifications for packet-in, packet-out, and idle timeout support) to implement control applications. It acts as a wrapper for **[p4runtime-shell](https://github.com/p4lang/p4runtime-shell)**, simplifying controller plane development.
|
||||
|
||||
**[p4-utils库](https://github.com/p4lang/behavioral-model/blob/main/targets/simple_switch_grpc/README.md)**（经过一些修改以支持 packet-in、packet-out 和 idle timeout）用于实现控制应用程序。它作为 **[p4runtime-shell](https://github.com/p4lang/p4runtime-shell)** 的封装器，简化了控制平面的开发。
|
||||
|
||||
Useful API information (e.g., `table_add`, `table_delete_match`) is available on the linked [GitHub repository](https://nsg-ethz.github.io/p4-utils/p4utils.utils.sswitch_p4runtime_API.html).
|
||||
|
||||
有关 API（如 `table_add`、`table_delete_match`）的详细信息，可以在 [GitHub 仓库](https://nsg-ethz.github.io/p4-utils/p4utils.utils.sswitch_p4runtime_API.html) 中找到。
|
||||
|
||||
The **repeater application** uses the network topology information encoded in `topo_repeater.json`. For other control applications, you need to provide the relevant topology information in a similar file.
|
||||
|
||||
**repeater 应用程序** 使用编码在 `topo_repeater.json` 中的网络拓扑信息。对于其他控制应用程序，需要在类似文件中提供相关的网络拓扑信息。
|
||||
|
||||
#### Generating Traffic Between End-Points
|
||||
|
||||
After deploying the repeater application, you can test its functionality by generating traffic between `PC1` and `PC2`. 部署 repeater 应用程序后，可以通过在 `PC1` 和 `PC2` 之间生成流量来测试其功能。
|
||||
|
||||
1. Configure the `eth1` interface on **PC1**:
|
||||
|
||||
```bash
|
||||
ssh root@pc1
|
||||
ip addr add 192.168.1.1/24 broadcast 192.168.1.255 dev eth1
|
||||
ip link set eth1 up
|
||||
```
|
||||
|
||||
2. Configure the `eth1` interface on **PC2** and generate traffic using the `ping` command:
|
||||
|
||||
```bash
|
||||
ssh root@pc2
|
||||
ip addr add 192.168.1.2/24 broadcast 192.168.1.255 dev eth1
|
||||
ip link set eth1 up
|
||||
ping 192.168.1.1
|
||||
```
|
||||
|
||||
If the PCs successfully communicate via `ping`, the deployment of the repeater application is confirmed.
|
||||
|
||||
如果 `PC1` 和 `PC2` 能够通过 `ping` 互相通信，则说明 repeater 应用程序部署成功。
|
||||
|
||||
#### Debugging the Data Plane Using `simple_switch_CLI`
|
||||
|
||||
The `simple_switch_CLI` command is useful for debugging the data plane. For example, while `S1` is running, open another terminal to observe or manipulate its rule tables: `simple_switch_CLI` 命令可用于调试数据平面。例如，当 `S1` 正在运行时，可以打开另一个终端窗口观察或操作其规则表：
|
||||
|
||||
1. Access **switch S1**:
|
||||
|
||||
```bash
|
||||
ssh root@s1
|
||||
simple_switch_CLI
|
||||
```
|
||||
|
||||
2. Use commands to debug:
|
||||
|
||||
- Show existing tables:
|
||||
|
||||
```bash
|
||||
show_tables
|
||||
```
|
||||
|
||||
- Show contents of a specific rule table (e.g., `repeater` ):
|
||||
|
||||
```bash
|
||||
table_dump repeater
|
||||
```
|
||||
|
||||
- Add a rule to the `repeater` table:
|
||||
|
||||
```bash
|
||||
table_add repeater forward 1 => 2
|
||||
```
|
||||
|
||||
This adds a rule with `match key = 1` , `action = forward`, and `action parameter = 2 `.
|
||||
|
||||
More commands and details can be found in the [P4 language GitHub repository](https://github.com/p4lang/behavioral-model/blob/main/docs/runtime_CLI.md).
|
||||
|
||||
更多命令和详细信息可在 [P4 language GitHub 仓库](https://github.com/p4lang/behavioral-model/blob/main/docs/runtime_CLI.md) 中找到。
|
||||
|
||||
**English:**
|
||||
|
||||
### 4.4.5 Other P4 Sources and Control Applications for Reference
|
||||
|
||||
An advanced control application, **`arpcache.py`**, is provided on `router4` alongside the earlier example. Its corresponding P4 source file is **`packetinout.p4`**.
|
||||
|
||||
一个高级控制应用程序 **`arpcache.py`** 与前面的示例一起提供在 `router4` 上。其对应的 P4 源文件为 **`packetinout.p4`**。
|
||||
|
||||
Additional useful examples are available in the **MNM-GitHub repository** [MNM-GitHub](https://github.com/mnm-team/p4-sdn.git). These examples should be practiced in the order specified on the repository’s main page (`README.md`) for a better understanding and smooth progression. Start with the **simple_demo application**, then proceed to **simple_switch**, and so on.
|
||||
|
||||
更多有用的示例可以在 **MNM-GitHub 仓库** [MNM-GitHub](https://github.com/mnm-team/p4-sdn.git) 中找到。这些示例应按照仓库主页面 (`README.md`) 中指定的顺序进行练习，以便更好地理解和顺利过渡。从 **simple_demo 应用程序** 开始，然后依次进行 **simple_switch** 等其他示例。
|
||||
|
||||
Other P4 sources and control applications can also be found in:
|
||||
|
||||
其他 P4 源文件和控制应用程序也可以在以下链接找到：
|
||||
|
||||
- The **P4 language tutorials** [P4 Tutorials](https://github.com/p4lang/tutorials/tree/master/exercises).
|
||||
- The **p4-learning** repository [P4 Learning](https://github.com/nsg-ethz/p4-learning/tree/master/exercises).
|
||||
|
||||
### 4.5 Assignment
|
||||
|
||||
Students will "program" the provided infrastructure using P4-based SDN to meet specific requirements based on a practical scenario.
|
||||
|
||||
学生将使用基于 P4 的 SDN 对提供的基础设施进行编程，以满足基于实际场景的特定需求。
|
||||
|
||||
#### 4.5.1 Scenario
|
||||
|
||||
The Academic Affairs Office (AAO) of University A has:
|
||||
|
||||
1. A **web server** hosting the AAO-Website, publishing important student information.
|
||||
2. An **E-learning Server** providing experimental e-learning services, such as lectures, exercises, and evaluations.
|
||||
|
||||
大学 A 的教务办公室 (AAO) 拥有以下资源：
|
||||
|
||||
1. 一个 **Web 服务器**，托管 AAO 网站，用于发布重要的学生信息。
|
||||
2. 一个 **E-learning 服务器**，提供实验性的在线学习服务，如讲座、练习和评估。
|
||||
|
||||
|
||||
|
||||
The network containing these servers is shown in **Figure 4.15**.
|
||||
|
||||
- The **E-learning Server** is underutilized since the service is in the testing phase.
|
||||
- The **web server** experiences high loads, especially during university entrance exam result publications.
|
||||
|
||||
包含这些服务器的网络如 **图 4.15** 所示：
|
||||
|
||||
- 由于服务仍处于测试阶段，**E-learning 服务器** 的资源大部分时间处于空闲状态。
|
||||
- 在大学发布入学考试结果时，**Web 服务器** 的负载意外地增加。
|
||||
|
||||
**Temporary solution:**
|
||||
|
||||
1. Deploy an additional instance of the AAO-Website on the **E-learning Server**.
|
||||
2. Perform **load balancing** at the gateway to distribute traffic flows alternately between the two servers.
|
||||
3. If the traffic volume reaches **80% of the link bandwidth**, drop the highest-load traffic flow.
|
||||
|
||||
The internal network of University A is **SDN-based**. Students, acting as network administrators, will program the network to achieve these requirements.
|
||||
|
||||
**临时解决方案：**
|
||||
|
||||
1. 在 **E-learning 服务器** 上部署 AAO 网站的额外实例。
|
||||
2. 在网关执行 **负载均衡**，将流量交替转发到两个服务器。
|
||||
3. 如果流量达到 **链路带宽的 80%**，丢弃负载最高的流量。
|
||||
|
||||
大学 A 的内部网络基于 **SDN**。学生将作为网络管理员，编程网络以实现这些需求。
|
||||
|
||||
#### 4.5.2 Demo
|
||||
|
||||
For demonstration purposes, the scenario is simplified, as shown in **Figure 4.16**:
|
||||
|
||||
- **PC1** represents the external party.
|
||||
- **Switch S1** acts as the gateway.
|
||||
- **Switches S2, S3** and **PC2, PC3** form the internal network.
|
||||
|
||||
为了演示目的，将场景简化为 **图 4.16**：
|
||||
|
||||
- **PC1** 代表外部实体。
|
||||
- **交换机 S1** 作为网关。
|
||||
- **交换机 S2, S3** 和 **PC2, PC3** 构成内部网络。
|
||||
|
||||
|
||||
|
||||
**Requirements:**
|
||||
|
||||
1. If the traffic volume from **PC1 to PC2** is ≥ **512 Kbps**:
|
||||
- Perform **load balancing** at the gateway. Traffic flows will alternately be delivered to **PC3** and **PC2**, as PC3 also provides the same service as PC2.
|
||||
- The response traffic from **PC3 to PC1** must be modified at the gateway, changing its **source IP address** and **source MAC address** to those of **PC2**.
|
||||
2. **Optional**: If the traffic volume from **PC1** to either **PC2** or **PC3** is ≥ **768 Kbps**, drop the traffic flow causing the highest load.
|
||||
|
||||
**需求：**
|
||||
|
||||
1. 如果从 **PC1 到 PC2** 的流量达到或超过 **512 Kbps**：
|
||||
- 在网关执行 **负载均衡**，流量交替转发到 **PC3** 和 **PC2**，因为 PC3 也提供与 PC2 相同的服务。
|
||||
- 从 **PC3 到 PC1** 的响应流量必须在网关处修改，将其 **源 IP 地址** 和 **源 MAC 地址** 更改为 **PC2** 的地址。
|
||||
2. **可选**：如果从 **PC1 到 PC2** 或 **PC3** 的流量达到或超过 **768 Kbps**，丢弃负载最高的流量。
|
||||
|
||||
**Note:** The traffic mentioned refers only to the direction from **PC1 to PC2**. Traffic in the reverse direction (**PC2 to PC1**) or other directions can be ignored.
|
||||
|
||||
**注意：** 以上提到的流量仅指从 **PC1 到 PC2** 的方向。来自 **PC2 到 PC1** 的流量以及其他流量可以忽略。
|
||||
|
||||
####
|
||||
|
||||
#### Implementation
|
||||
|
||||
Student groups will:
|
||||
|
||||
- Develop appropriate SDN applications and P4 programs.
|
||||
- Deploy these on the provided infrastructure to meet the above requirements.
|
||||
|
||||
学生小组需要：
|
||||
|
||||
- 开发适当的 SDN 应用程序和 P4 程序。
|
||||
- 将其部署到提供的基础设施中，以满足上述需求。
|
||||
|
||||
### 4.5.3 Submission
|
||||
|
||||
- Submit the source code and a manual detailing how to deploy and run the applications. 提交源代码以及详细说明如何部署和运行应用程序的手册。
|
||||
- The submission should be compressed into a **zip file**. 提交内容需压缩为 **zip 文件**。
|
||||
|
||||
### 4.5.4 Assessment
|
||||
|
||||
The assignment will be assessed based on: 作业的评估基于以下两点：
|
||||
|
||||
1. The **final demo** presented in class (at the "Baracke"). 在课堂上进行的 **最终演示**（地点："Baracke"）。
|
||||
2. The **manual** submitted with the source code. 提交的 **手册**。
|
||||
|
||||
### 4.5.5 Important Dates
|
||||
|
||||
- **14.01.2025 23:59**:
|
||||
Submission of the source code that measures the traffic volume from **PC1 to PC2**.
|
||||
|
||||
- Refer to the example on Counters available at https://github.com/mnmteam/p4-sdn/tree/main/counters.
|
||||
|
||||
提交用于测量从 **PC1 到 PC2** 流量的源代码。
|
||||
|
||||
- 参考 https://github.com/mnmteam/p4-sdn/tree/main/counters 中关于计数器的示例。
|
||||
|
||||
- **21.01.2025 13:59**:
|
||||
Submission of the **final source code** and the **manual**.
|
||||
提交 **最终源代码** 和 **手册**。
|
||||
|
||||
- **21.01.2025 14:00**:
|
||||
**Demo** presentation
|
||||
BIN
Blatt04/Notes04.pdf
Normal file
BIN
Blatt04/Notes04.pdf
Normal file
Binary file not shown.
831
OralNotes.md
Normal file
831
OralNotes.md
Normal file
@@ -0,0 +1,831 @@
|
||||
还差什么？
|
||||
|
||||
1-3 Theoretical Problems
|
||||
|
||||
4 ask yourself questions
|
||||
|
||||
3 RIP OSPF BGP?
|
||||
|
||||
3 讲述一下RA RS NA NS的过程
|
||||
|
||||
[toc]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 什么是一个自治系统？(Autonome Systeme)
|
||||
|
||||
自治系统（Autonomous System，AS）指的是在互联网中由单一管理实体（如网络运营商、企业、大学等）控制的一组IP网络和路由器集合。每个自治系统都有一个唯一的自治系统号码（ASN），用于在边界网关协议（BGP）中标识和交换路由信息。自治系统内部使用统一的路由策略管理数据流，而各AS之间则通过BGP互联，从而构成全球互联网的基础架构。
|
||||
|
||||
## 自治系统语境下的对等关系和传输关系各是什么意思？
|
||||
|
||||
**Peering relationship（对等互联关系）：**
|
||||
在这种关系中，两家或多家网络通常规模相近且流量互补，它们直接互联并交换彼此的流量，而不收取费用或仅象征性收取费用。这种方式旨在优化数据传输路径和提高网络效率，同时降低运营成本。
|
||||
|
||||
**Transit relationship（传递关系）：**
|
||||
这种关系通常涉及付费，指的是一个网络（客户网络）向一个规模更大、覆盖范围更广的网络（提供商网络）支付费用，以获得对整个互联网或更大部分网络的连接。通过 Transit 关系，客户网络可以访问那些没有与之直接对等互联的其他网络。
|
||||
|
||||
## 网络层和数据链路层的作用各是什么？
|
||||
|
||||
- **网络层（Network Layer）：**
|
||||
- **主要作用：** 负责在不同网络之间传输数据包，确定数据从源到目的地的最佳路径。
|
||||
- 关键功能：
|
||||
- **逻辑寻址：** 使用IP地址标识各个网络设备。
|
||||
- **路由选择：** 通过路由协议（如OSPF、BGP等）决定数据包的转发路径。
|
||||
- **数据包转发：** 在各个网络间将数据包从一跳转发到下一跳。
|
||||
- **分片与重组：** 当数据包在传输中需要跨越不同MTU的网络时进行分片，并在目的地重组数据包。
|
||||
- **数据链路层（Data Link Layer）：**
|
||||
- **主要作用：** 负责在相邻网络节点之间进行可靠的数据传输，确保物理传输过程中数据的完整性。
|
||||
- 关键功能：
|
||||
- **帧封装：** 将网络层传来的数据封装成帧，并在接收端进行解封装。
|
||||
- **物理地址：** 使用MAC地址来唯一标识局域网中的设备。
|
||||
- **错误检测与纠正：** 通过校验和等机制检测传输错误，并在必要时进行纠正。
|
||||
- **流量控制：** 管理数据传输速率，避免网络拥塞。
|
||||
|
||||
## 不同子网的不同的第二层实现指的是什么？
|
||||
|
||||
以太网，WiFi
|
||||
|
||||
## CIDR出现前是怎么划分子网的？
|
||||
|
||||
IPv4 地址被划分为五类，每类的网络部分和主机部分的长度不同：
|
||||
|
||||
| **类别** | **地址范围** | **网络部分长度** | **主机部分长度** | **用途** |
|
||||
| :------- | :-------------------------- | :--------------- | :--------------- | :------------------- |
|
||||
| A | 0.0.0.0 - 127.255.255.255 | 8 位 | 24 位 | 大型网络 |
|
||||
| B | 128.0.0.0 - 191.255.255.255 | 16 位 | 16 位 | 中型网络 |
|
||||
| C | 192.0.0.0 - 223.255.255.255 | 24 位 | 8 位 | 小型网络 |
|
||||
| D | 224.0.0.0 - 239.255.255.255 | N/A | N/A | 多播地址 |
|
||||
| E | 240.0.0.0 - 255.255.255.255 | N/A | N/A | 保留地址（实验用途） |
|
||||
|
||||
RFC 1918 定义了以下私有地址范围，这些地址用于本地网络（如企业内部网络），不会在公共互联网上路由：
|
||||
|
||||
| **类别** | **私有地址范围** | **默认子网掩码** |
|
||||
| :------- | :---------------------------- | :---------------- |
|
||||
| A | 10.0.0.0 - 10.255.255.255 | 255.0.0.0 (/8) |
|
||||
| B | 172.16.0.0 - 172.31.255.255 | 255.240.0.0 (/12) |
|
||||
| C | 192.168.0.0 - 192.168.255.255 | 255.255.0.0 (/16) |
|
||||
|
||||
6. IPv6协议有多长？
|
||||
128位
|
||||
| **字段** | **长度（比特）** | **描述** |
|
||||
| :-------------------------------- | :--------------- | :--------------------------------------------------------- |
|
||||
| **FP（Format Prefix）** | 3 | 格式前缀，用于标识地址类型（如全局单播地址、本地地址等）。 |
|
||||
| **TLA（Top-Level Aggregation）** | 13 | 顶级聚合标识符，用于标识顶级 ISP 或大型组织。 |
|
||||
| **RES（Reserved）** | 8 | 保留字段，用于未来扩展。 |
|
||||
| **NLA（Next-Level Aggregation）** | 24 | 下一级聚合标识符，用于标识下级 ISP 或组织。 |
|
||||
| **SLA（Site-Level Aggregation）** | 16 | 站点级聚合标识符，用于标识组织内部的子网。 |
|
||||
| **Interface ID** | 64 | 接口标识符，用于标识网络接口。 |
|
||||
|
||||
## IPv6地址的构成？（子网和主机ID各有多少位？）
|
||||
|
||||
各64位
|
||||
|
||||
## IPv6的头部是固定的还是变长的？如果是固定的，如何添加额外的信息？
|
||||
|
||||
固定的，存在header-extension
|
||||
IPv6 头部固定为 **40 字节**，包含以下字段：
|
||||
|
||||
| **字段** | **长度（比特）** | **描述** |
|
||||
| :---------------------- | :--------------- | :----------------------------------------------------------- |
|
||||
| **Version** | 4 | 版本号，IPv6 的值为 `6`。 |
|
||||
| **Traffic Class** | 8 | 流量类别，用于区分不同类型的流量（类似于 IPv4 的 TOS 字段）。 |
|
||||
| **Flow Label** | 20 | 流标签，用于标识属于同一流的数据包（用于 QoS 和实时应用）。 |
|
||||
| **Payload Length** | 16 | 有效载荷长度，表示 IPv6 头部之后的数据长度（不包括头部本身）。 |
|
||||
| **Next Header** | 8 | 下一个头部类型，标识紧接在 IPv6 头部之后的扩展头部或上层协议（如 TCP/UDP）。 |
|
||||
| **Hop Limit** | 8 | 跳数限制，类似于 IPv4 的 TTL，每经过一个路由器减 1，减到 0 时丢弃数据包。 |
|
||||
| **Source Address** | 128 | 源 IPv6 地址。 |
|
||||
| **Destination Address** | 128 | 目的 IPv6 地址。 |
|
||||
|
||||
在next header处添加扩展信息
|
||||
|
||||
每个扩展头部都包含以下两个关键字段：
|
||||
|
||||
1. **Next Header**（8 位）：指示下一个扩展头部或上层协议的类型。
|
||||
|
||||
2. **Header Extension Length**（8 位）：指示当前扩展头部的长度（以 8 字节为单位，不包括前 8 字节）。
|
||||
|
||||
## 什么是IPsec?
|
||||
|
||||
**IPsec（Internet Protocol Security）** 是一种用于保护 IP 通信的安全协议套件。它通过在 IP 层提供加密、认证和完整性保护，确保数据在传输过程中的机密性、完整性和真实性。IPsec 广泛应用于虚拟专用网络（VPN）、远程访问、站点到站点连接等场景。
|
||||
|
||||
传输模式（Transport Mode）
|
||||
|
||||
- 仅保护 IP 数据包的有效载荷（Payload），不修改原始 IP 头部。
|
||||
- 适用于端到端通信（如主机到主机）。
|
||||
- 示例：
|
||||
- 原始数据包：`[IP Header][TCP/UDP Header][Data]`
|
||||
- IPsec 保护后：`[IP Header][AH/ESP Header][TCP/UDP Header][Data][ESP Trailer][ICV]`
|
||||
|
||||
**隧道模式（Tunnel Mode）**
|
||||
|
||||
- 保护整个 IP 数据包（包括 IP 头部和有效载荷），并封装在新的 IP 数据包中。
|
||||
- 适用于站点到站点 VPN 或远程访问 VPN。
|
||||
- 示例：
|
||||
- 原始数据包：`[IP Header][TCP/UDP Header][Data]`
|
||||
- IPsec 保护后：`[New IP Header][AH/ESP Header][Original IP Header][TCP/UDP Header][Data][ESP Trailer][ICV]`
|
||||
|
||||
## IPv6是怎么区分本地和全局地址的？
|
||||
|
||||
1. script里主要写分为两类：**全局地址**和**链路本地地址**
|
||||
2. 需要注意的是**链路本地地址不能跨路由器**
|
||||
3. IPv6 地址主要分为以下几类：
|
||||
1. **全局单播地址（Global Unicast Address）**：
|
||||
1. 用于公共互联网，全球唯一。
|
||||
2. 前缀通常为 `2000::/3`（即 `2000::` 到 `3FFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF`）。
|
||||
2. **唯一本地地址（Unique Local Address, ULA）**：
|
||||
1. 用于本地网络，类似于 IPv4 的私有地址。
|
||||
2. 前缀为 `FC00::/7`（即 `FC00::` 到 `FDFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF`）。
|
||||
3. **链路本地地址（Link-Local Address）**：
|
||||
1. 用于同一链路上的设备通信，不能跨路由器。
|
||||
2. 前缀为 `FE80::/10`（即 `FE80::` 到 `FEBF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF`）。
|
||||
4. **多播地址（Multicast Address）**：
|
||||
1. 用于一对多通信。
|
||||
2. 前缀为 `FF00::/8`（即 `FF00::` 到 `FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF`）。
|
||||
5. **回环地址（Loopback Address）**：
|
||||
1. 用于本地回环测试。
|
||||
2. 地址为 `::1`。
|
||||
6. **未指定地址（Unspecified Address）**：
|
||||
1. 用于表示地址未指定。
|
||||
2. 地址为 `::`。
|
||||
|
||||
## 实现IPv4和IPv6两个协议版本共存的方法：
|
||||
|
||||
1. 双栈
|
||||
2. 隧道技术
|
||||
|
||||
## 讲一讲ICMPv6
|
||||
|
||||
ICMPv6 的主要功能包括：
|
||||
|
||||
1. **错误报告**：
|
||||
|
||||
- 当数据包传输过程中发生错误时，ICMPv6 会生成错误消息并发送给源节点。
|
||||
- 例如，目标不可达、数据包过大、超时等。
|
||||
|
||||
2. **诊断功能**：
|
||||
|
||||
- 提供网络诊断工具，如 **Ping** 和 **Traceroute**。
|
||||
- 用于测试网络连通性和路径。
|
||||
|
||||
3. **邻居发现协议（NDP）**：
|
||||
|
||||
- 用于 IPv6 中的地址解析、邻居状态跟踪和路由器发现。
|
||||
- 替代了 IPv4 中的 **ARP（Address Resolution Protocol）**。
|
||||
|
||||
4. **多播监听发现协议（MLD）**：
|
||||
|
||||
- 用于管理多播组成员关系。
|
||||
- 替代了 IPv4 中的 **IGMP（Internet Group Management Protocol）**。
|
||||
|
||||
|
||||
**2. ICMPv6 的消息类型**
|
||||
|
||||
ICMPv6 消息分为两大类：**错误消息** 和 **信息消息**。每种消息类型由一个唯一的类型值标识。
|
||||
|
||||
**2.1 错误消息**
|
||||
|
||||
错误消息用于报告数据包传输过程中的问题。常见的错误消息类型包括：
|
||||
|
||||
| **类型值** | **消息类型** | **描述** |
|
||||
| :--------- | :------------------------------------ | :------------------------------------------- |
|
||||
| 1 | 目标不可达（Destination Unreachable） | 数据包无法到达目标节点。 |
|
||||
| 2 | 数据包过大（Packet Too Big） | 数据包超过链路的 MTU，无法传输。 |
|
||||
| 3 | 超时（Time Exceeded） | 数据包的 TTL（跳数限制）减到 0，或重组超时。 |
|
||||
| 4 | 参数问题（Parameter Problem） | 数据包头部字段有错误。 |
|
||||
|
||||
**2.2 信息消息**
|
||||
|
||||
信息消息用于网络诊断和管理。常见的信息消息类型包括：
|
||||
|
||||
| **类型值** | **消息类型** | **描述** |
|
||||
| :--------- | :---------------------------------------- | :--------------------------------------- |
|
||||
| 128 | 回显请求（Echo Request） | 用于 Ping 测试，请求目标节点回复。 |
|
||||
| 129 | 回显应答（Echo Reply） | 目标节点对回显请求的响应。 |
|
||||
| 133 | 路由器请求（Router Solicitation） | 主机请求路由器发送路由器通告。 |
|
||||
| 134 | 路由器通告（Router Advertisement） | 路由器发送的通告消息，包含网络配置信息。 |
|
||||
| 135 | 邻居请求（Neighbor Solicitation） | 用于地址解析和邻居状态跟踪。 |
|
||||
| 136 | 邻居通告（Neighbor Advertisement） | 对邻居请求的响应，包含链路层地址。 |
|
||||
| 130 | 多播监听查询（Multicast Listener Query） | 用于查询多播组成员。 |
|
||||
| 131 | 多播监听报告（Multicast Listener Report） | 主机报告其多播组成员关系。 |
|
||||
| 132 | 多播监听完成（Multicast Listener Done） | 主机离开多播组时发送的消息。 |
|
||||
|
||||
------
|
||||
|
||||
**3. ICMPv6 的消息格式**
|
||||
|
||||
ICMPv6 消息的通用格式如下：
|
||||
|
||||
| **字段** | **长度（字节）** | **描述** |
|
||||
| :------------------------- | :--------------- | :-------------------------------------------------- |
|
||||
| **类型（Type）** | 1 | 消息类型（如 1 表示目标不可达，128 表示回显请求）。 |
|
||||
| **代码（Code）** | 1 | 消息子类型，提供更详细的错误分类。 |
|
||||
| **校验和（Checksum）** | 2 | 用于检测消息在传输过程中是否损坏。 |
|
||||
| **消息体（Message Body）** | 可变 | 包含具体的消息数据，如错误信息、诊断数据等。 |
|
||||
|
||||
------
|
||||
|
||||
**4. ICMPv6 的关键功能**
|
||||
|
||||
**4.1 邻居发现协议（NDP）**
|
||||
|
||||
NDP 是 ICMPv6 的核心功能之一，用于替代 IPv4 中的 ARP。它通过以下消息实现：
|
||||
|
||||
- **路由器请求（Router Solicitation, RS）**：
|
||||
- 主机发送 RS 消息，请求路由器发送路由器通告。
|
||||
- **路由器通告（Router Advertisement, RA）**：
|
||||
- 路由器发送 RA 消息，包含网络配置信息（如前缀、MTU 等）。
|
||||
- **邻居请求（Neighbor Solicitation, NS）**：
|
||||
- 用于地址解析（将 IPv6 地址解析为链路层地址）。
|
||||
- **邻居通告（Neighbor Advertisement, NA）**：
|
||||
- 对 NS 消息的响应，包含链路层地址。
|
||||
|
||||
**4.2 多播监听发现协议（MLD）**
|
||||
|
||||
MLD 用于管理多播组成员关系，替代了 IPv4 中的 IGMP。它通过以下消息实现：
|
||||
|
||||
- **多播监听查询（Multicast Listener Query）**：
|
||||
- 路由器发送查询消息，询问哪些主机加入了多播组。
|
||||
- **多播监听报告（Multicast Listener Report）**：
|
||||
- 主机发送报告消息，声明其加入的多播组。
|
||||
- **多播监听完成（Multicast Listener Done）**：
|
||||
- 主机发送完成消息，声明其离开多播组。
|
||||
|
||||
## 描述一下NDP的过程？
|
||||
|
||||
**NDP（Neighbor Discovery Protocol，邻居发现协议）** 是 IPv6 中的一个关键协议，用于替代 IPv4 中的 **ARP（Address Resolution Protocol）**。NDP 不仅支持地址解析，还提供了路由器发现、邻居状态跟踪、重复地址检测等功能。以下是 NDP 的工作过程及其主要功能的详细说明：
|
||||
|
||||
**2. NDP 的工作过程**
|
||||
|
||||
**2.1 路由器发现（Router Discovery）**
|
||||
|
||||
当主机加入网络时，它需要发现本地网络中的路由器并获取网络配置信息（如前缀、MTU 等）。这个过程通过 **RS** 和 **RA** 消息实现。
|
||||
|
||||
1. **主机发送 RS 消息**：
|
||||
- 主机发送 **Router Solicitation（RS）** 消息，请求路由器发送路由器通告。
|
||||
- RS 消息的目标地址为 **所有路由器多播地址（FF02::2）**。
|
||||
|
||||
2. **路由器发送 RA 消息**：
|
||||
- 路由器收到 RS 消息后，发送 **Router Advertisement（RA）** 消息。
|
||||
- RA 消息包含以下信息：
|
||||
- 网络前缀（用于地址自动配置）。
|
||||
- 默认路由器的链路层地址。
|
||||
- MTU（最大传输单元）。
|
||||
- RA 消息可以定期发送，也可以响应 RS 消息发送。
|
||||
|
||||
---
|
||||
|
||||
**2.2 地址解析（Address Resolution）**
|
||||
|
||||
当主机需要将 IPv6 地址解析为链路层地址时，使用 **NS** 和 **NA** 消息。
|
||||
|
||||
1. **主机发送 NS 消息**：
|
||||
- 主机发送 **Neighbor Solicitation（NS）** 消息，请求目标 IPv6 地址对应的链路层地址。
|
||||
- NS 消息的目标地址为 **请求节点多播地址（Solicited-Node Multicast Address）**，格式为 `FF02::1:FFXX:XXXX`，其中 `XX:XXXX` 是目标 IPv6 地址的最后 24 位。
|
||||
|
||||
2. **目标主机发送 NA 消息**：
|
||||
- 目标主机收到 NS 消息后，发送 **Neighbor Advertisement（NA）** 消息，包含其链路层地址。
|
||||
- NA 消息的目标地址为请求主机的单播地址。
|
||||
|
||||
---
|
||||
|
||||
**2.3 邻居状态跟踪（Neighbor State Tracking）**
|
||||
|
||||
NDP 维护一个 **邻居缓存表（Neighbor Cache）**，用于跟踪邻居的状态。邻居状态包括：
|
||||
- **INCOMPLETE**：正在解析地址。
|
||||
- **REACHABLE**：邻居可达。
|
||||
- **STALE**：邻居状态未知，需要验证。
|
||||
- **DELAY**：延迟验证。
|
||||
- **PROBE**：正在验证邻居的可达性。
|
||||
|
||||
---
|
||||
|
||||
**2.4 重复地址检测（Duplicate Address Detection, DAD）**
|
||||
|
||||
在主机配置 IPv6 地址之前，需要确保该地址在本地链路上是唯一的。这个过程通过 **NS** 和 **NA** 消息实现。
|
||||
|
||||
1. **主机发送 NS 消息**：
|
||||
- 主机发送 **Neighbor Solicitation（NS）** 消息，目标地址为待检测的 IPv6 地址。
|
||||
- 如果收到 **Neighbor Advertisement（NA）** 消息，说明地址已被占用。
|
||||
|
||||
2. **地址可用**：
|
||||
- 如果没有收到 NA 消息，主机可以安全地使用该地址。
|
||||
|
||||
---
|
||||
|
||||
**2.5 重定向（Redirect）**
|
||||
|
||||
当路由器发现主机选择的下一跳不是最优路径时，会发送 **Redirect** 消息，通知主机有更好的下一跳地址。
|
||||
|
||||
1. **路由器发送 Redirect 消息**：
|
||||
- 路由器发送 **Redirect** 消息，包含更好的下一跳地址。
|
||||
- 主机更新其路由表，使用新的下一跳地址。
|
||||
|
||||
|
||||
|
||||
## 路由协议的主要功能是什么？最优路径用在哪里？
|
||||
|
||||
路由协议的主要功能是让每个路由器将其已知的子网信息传递给其他路由器。
|
||||
最优路径用在计算两个设备之间的最优距离
|
||||
|
||||
## 如何计算最优路径？
|
||||
|
||||
1. 网络可以看成是在生成的加权边图上(generated weighted graph)，规划算法为路由器寻找一条最优路径(plan algorithm finds an optimal path for the router.)
|
||||
2. 一般存在一个成本函数，成本函数会计算包离开网络的代价。离开网络既可以指送到指定设备，也可以是送到对应的运营商（自治系统 ）
|
||||
|
||||
## 自适应路由方法的分类？
|
||||
|
||||
1. 集中式
|
||||
2. 分布式
|
||||
|
||||
## 路由协议一般使用哪两种方法
|
||||
|
||||
1. 自适应距离向量方法
|
||||
1. **距离向量（Distance Vector）**：每个路由器维护一个路由表，表中包含到每个目标网络的距离（通常以跳数或成本度量）和下一跳路由器。
|
||||
2. **自适应（Adaptive）**：路由器根据网络拓扑的变化动态更新路由表。
|
||||
2. 自适应链路状态方法
|
||||
1. **链路状态（Link State）**：每个路由器维护整个网络的拓扑图，包含所有路由器和链路的状态。
|
||||
2. **自适应（Adaptive）**：路由器根据网络拓扑的变化动态更新链路状态数据库。
|
||||
|
||||
## 讲一下RIP？
|
||||
|
||||
## 什么是OSPF？
|
||||
|
||||
## 什么是BGP？
|
||||
|
||||
**OSPF**、**RIP** 和 **BGP** 是三种常见的路由协议，分别适用于不同的网络环境和需求。以下是它们的详细说明：
|
||||
|
||||
---
|
||||
|
||||
## **1. OSPF（Open Shortest Path First）**
|
||||
|
||||
### **1.1 概述**
|
||||
- **类型**：链路状态路由协议（Link-State Routing Protocol）。
|
||||
- **适用范围**：中大型企业网络、ISP 网络。
|
||||
- **标准**：RFC 2328。
|
||||
|
||||
### **1.2 工作原理**
|
||||
1. **链路状态信息收集**：
|
||||
- 每个路由器通过 **Hello 协议** 发现邻居路由器，并收集链路状态信息（如链路成本、带宽等）。
|
||||
|
||||
2. **链路状态广播**：
|
||||
- 每个路由器将收集到的链路状态信息封装成 **链路状态通告（LSA, Link State Advertisement）**，并广播给整个网络。
|
||||
- 使用 **泛洪（Flooding）** 机制确保所有路由器收到 LSA。
|
||||
|
||||
3. **链路状态数据库同步**：
|
||||
- 每个路由器维护一个 **链路状态数据库（LSDB, Link State Database）**，存储整个网络的拓扑信息。
|
||||
- 通过交换 LSA，所有路由器的 LSDB 最终同步。
|
||||
|
||||
4. **最短路径计算**：
|
||||
- 每个路由器使用 **Dijkstra 算法** 计算到所有目标网络的最短路径。
|
||||
- 根据计算结果更新路由表。
|
||||
|
||||
5. **区域划分**：
|
||||
- OSPF 支持将网络划分为多个 **区域（Area）**，以减少路由信息的传播范围。
|
||||
- **Area 0** 是骨干区域，其他区域必须与 Area 0 直接或间接连接。
|
||||
|
||||
### **1.3 特点**
|
||||
- **快速收敛**：在网络拓扑变化时，路由信息传播较快，收敛速度快。
|
||||
- **支持分层设计**：通过区域划分减少路由信息的传播范围。
|
||||
- **计算复杂度高**：需要更多的计算资源和存储空间。
|
||||
|
||||
### **1.4 适用场景**
|
||||
- 中大型企业网络。
|
||||
- ISP 网络。
|
||||
|
||||
---
|
||||
|
||||
## **2. RIP（Routing Information Protocol）**
|
||||
|
||||
### **2.1 概述**
|
||||
- **类型**：距离向量路由协议（Distance-Vector Routing Protocol）。
|
||||
- **适用范围**：小型网络。
|
||||
- **版本**：RIP v1（RFC 1058）、RIP v2（RFC 2453）。
|
||||
|
||||
### **2.2 工作原理**
|
||||
1. **路由表初始化**：
|
||||
- 每个路由器初始化自己的路由表，记录到直连网络的距离（通常为 0）和下一跳路由器。
|
||||
|
||||
2. **定期广播路由信息**：
|
||||
- 每个路由器定期（默认 30 秒）向邻居路由器广播自己的路由表。
|
||||
- 广播的内容包括目标网络和到该网络的距离（跳数）。
|
||||
|
||||
3. **更新路由表**：
|
||||
- 路由器收到邻居的路由表后，根据以下规则更新自己的路由表：
|
||||
- 如果通过邻居到达目标网络的距离更短，则更新路由表。
|
||||
- 如果邻居的路由表中包含新的目标网络，则添加到自己的路由表中。
|
||||
|
||||
4. **路由收敛**：
|
||||
- 通过多次广播和更新，路由表最终收敛到稳定的状态。
|
||||
|
||||
### **2.3 特点**
|
||||
- **简单易实现**：算法简单，适合小型网络。
|
||||
- **慢收敛问题**：在网络拓扑变化时，路由信息传播较慢，可能导致路由环路。
|
||||
- **最大跳数限制**：RIP 的最大跳数为 15，超过 15 跳的网络被视为不可达。
|
||||
|
||||
### **2.4 适用场景**
|
||||
- 小型网络。
|
||||
- 对路由计算复杂度要求较低的场景。
|
||||
|
||||
---
|
||||
|
||||
## **3. BGP（Border Gateway Protocol）**
|
||||
|
||||
### **3.1 概述**
|
||||
- **类型**：路径向量路由协议（Path-Vector Routing Protocol）。
|
||||
- **适用范围**：互联网骨干网、ISP 之间的路由。
|
||||
- **版本**：BGP-4（RFC 4271）。
|
||||
|
||||
### **3.2 工作原理**
|
||||
1. **建立邻居关系**：
|
||||
- BGP 路由器通过 **TCP 连接（端口 179）** 建立邻居关系（Peer）。
|
||||
- 邻居关系可以是 **内部 BGP（iBGP）** 或 **外部 BGP（eBGP）**。
|
||||
|
||||
2. **交换路由信息**：
|
||||
- 邻居之间交换 **BGP 更新消息（Update Message）**，包含目标网络和路径属性（如 AS 路径、下一跳等）。
|
||||
|
||||
3. **路径选择**：
|
||||
- 每个 BGP 路由器根据路径属性（如 AS 路径长度、本地优先级等）选择最佳路径。
|
||||
- 最佳路径被添加到路由表中，并广播给其他邻居。
|
||||
|
||||
4. **路由策略**：
|
||||
- BGP 支持灵活的路由策略配置，如路由过滤、路径偏好设置等。
|
||||
|
||||
### **3.3 特点**
|
||||
- **支持大规模网络**：BGP 是互联网的核心路由协议，支持大规模路由表。
|
||||
- **路径向量协议**：通过 AS 路径属性避免路由环路。
|
||||
- **路由策略灵活**：支持复杂的路由策略配置。
|
||||
|
||||
### **3.4 适用场景**
|
||||
- 互联网骨干网。
|
||||
- ISP 之间的路由。
|
||||
- 大型企业网络的多宿主连接。
|
||||
|
||||
---
|
||||
|
||||
## **4. 三种协议的对比**
|
||||
|
||||
| **特性** | **OSPF** | **RIP** | **BGP** |
|
||||
| -------------- | ------------------------ | ---------- | ---------------------------- |
|
||||
| **类型** | 链路状态 | 距离向量 | 路径向量 |
|
||||
| **适用范围** | 中大型企业网络、ISP 网络 | 小型网络 | 互联网骨干网、ISP 之间的路由 |
|
||||
| **收敛速度** | 快 | 慢 | 中等 |
|
||||
| **计算复杂度** | 高 | 低 | 高 |
|
||||
| **路由策略** | 有限 | 无 | 灵活 |
|
||||
| **典型应用** | 企业内网、ISP 网络 | 小型局域网 | 互联网骨干网 |
|
||||
|
||||
---
|
||||
|
||||
## **5. 总结**
|
||||
- **OSPF**：适用于中大型网络，支持分层设计和快速收敛，计算复杂度较高。
|
||||
- **RIP**：适用于小型网络，简单易实现，但存在慢收敛问题。
|
||||
- **BGP**：适用于互联网骨干网和 ISP 之间的路由，支持复杂的路由策略，但配置和管理较为复杂。
|
||||
|
||||
根据网络规模和需求，可以选择合适的路由协议。
|
||||
|
||||
## A200 Address Resolution and Neighbor Discovery (Theorie)
|
||||
|
||||
Das RFC 826 definiert das Address Resolution Protocol (ARP). In RFC 4861 wird das Neighbor Discovery Protocol (NDP) spezifiziert. RFC 826 定义了地址解析协议（ARP）。RFC 4861 规定了邻居发现协议（NDP）。
|
||||
|
||||
1. **Wozu wird ARP eingesetzt? Was ist der Unterschied zu NDP?** **ARP 的用途是什么？它与 NDP 的区别是什么？**
|
||||
My answer: ARP is used to convert the IPv4 Address to Hardware address, i.e. MAC address.
|
||||
NDP is used in IPv6 protocol
|
||||
While ARP works by broadcasting requests, NDP uses ICMPv6 messages and **multicast** addresses to achieve more efficient neighbor discovery.
|
||||
|
||||
2. **Beschreiben Sie den Aufbau einer ARP-PDU und erläutern Sie die Bedeutung der einzelnen Felder!** **描述 ARP-PDU 的结构并解释各个字段的含义！**
|
||||
Hardware type 2
|
||||
protocol type 2
|
||||
hardware size 1
|
||||
protocol size 1
|
||||
|
||||
op code 2
|
||||
src_ip: 4
|
||||
src_hw: 6
|
||||
dst_ip: 4
|
||||
dst_hw: 6(ff)
|
||||
|
||||
3. **Welche unterschiedlichen ARP-PDUs gibt es? Welche NDP-PDUs gibt es?** **有哪些不同的 ARP-PDU？NDP-PDU 又有哪些？**
|
||||
reply and request
|
||||
NA NS RS rA
|
||||
|
||||
|
||||
|
||||
4. **Wie lang (in Bytes) ist eine ARP-PDU in einem Netz in dem IPv4 und Ethernet eingesetzt werden?** **在 IPv4 和以太网网络中，ARP-PDU 的长度是多少字节？** 28
|
||||
|
||||
5. **Wie lang (in Bytes) ist eine Neighbor Solicitation Nachricht?** **Neighbor Solicitation 消息的长度是多少字节？**
|
||||
|
||||
|
||||
6. **Das RFC 826 spricht von einer Tabelle (table), deren Implementierung meist als ARP-Cache bezeichnet wird. Was soll laut RFC mit einer Ethernet-SDU passieren, wenn kein Eintrag zur Ziel-IP-Adresse in der Tabelle gefunden wird?** **RFC 826 提到了一张表（table），其实现通常称为 ARP 缓存。RFC 规定如果表中没有找到目标 IP 地址的条目，对以太网 SDU 应该怎么处理？**
|
||||
First, the host broadcast the ARP request packet to every neighbor in the network.
|
||||
If the host receives the ARP reply packet, add the entry to both sides.
|
||||
else drop the packet.
|
||||
|
||||
### A300 Fragmentierung und IP-Tunneling (Theorie)
|
||||
|
||||
i) In wie viele Fragmente wird ein IP-Paket mit Größe 9000 Byte zerlegt, um über ein Ethernet mit MTU = 1500 Byte übertragen zu werden? Geben Sie eine vollständige Rechnung an! 一个大小为 9000 字节的 IP 包在 Ethernet 的 MTU 为 1500 字节的情况下会被分成多少个片段？请提供完整的计算过程！
|
||||
|
||||
ii) Nennen Sie drei Gründe dafür, dass Netzbetreiber IP-Fragmentierung in ihren Netzen verbieten. Erläutern Sie diese Gründe! 请列举网络运营商在其网络中禁止 IP 分片的三个原因，并对这些原因进行解释！**Three Reasons Why Network Operators Prohibit IP Fragmentation and Their Explanations**
|
||||
|
||||
IP fragmentation occurs when a packet exceeds the Maximum Transmission Unit (MTU) of a network link and must be broken into smaller fragments. Many **network operators prohibit IP fragmentation** due to the following reasons:
|
||||
|
||||
**1. Performance Degradation & Increased Overhead**
|
||||
|
||||
- Fragmentation increases the number of packets that must be processed, leading to **higher CPU and memory usage** in routers and firewalls.
|
||||
- Each fragment requires additional headers, increasing **network overhead** and reducing effective data transmission efficiency.
|
||||
- Reassembly at the destination requires buffer space, which can cause delays and resource exhaustion in high-throughput environments.
|
||||
|
||||
**2. Security Risks & Susceptibility to Attacks**
|
||||
|
||||
- Fragmentation makes networks vulnerable to **fragmentation-based attacks**, such as **overlapping fragments (Teardrop attack)** and **tiny fragment attacks** used to evade security filters.
|
||||
- Intrusion Detection Systems (IDS) and firewalls may struggle to inspect fragmented packets, allowing attackers to **bypass security policies** and smuggle malicious payloads.
|
||||
- Attackers can send fragmented packets with missing fragments, causing **DoS (Denial of Service)** by exhausting resources on the target system waiting for reassembly.
|
||||
|
||||
**3. Complications in Path MTU Discovery (PMTUD) & Packet Loss Issues**
|
||||
|
||||
- Many modern networks use **Path MTU Discovery (PMTUD)** to dynamically determine the optimal packet size. If fragmentation is allowed, incorrect PMTUD settings can result in persistent retransmissions.
|
||||
- If a single fragment of a fragmented packet is lost, the entire packet must be retransmitted, leading to **higher packet loss rates** and inefficiencies.
|
||||
- Some middleboxes (e.g., NAT devices, firewalls) drop fragmented packets, causing unpredictable failures in communication.
|
||||
|
||||
### **Conclusion:**
|
||||
|
||||
Because of these issues, **network operators often prohibit IP fragmentation and instead rely on techniques like MSS (Maximum Segment Size) adjustment and PMTUD** to ensure efficient packet transmission without fragmentation.
|
||||
|
||||
------
|
||||
|
||||
**网络运营商在其网络中禁止 IP 分片的三个原因及其解释**
|
||||
|
||||
IP 分片（IP Fragmentation）发生在数据包超过网络链路的 **最大传输单元（MTU）** 时，需要拆分成多个小片进行传输。许多**网络运营商禁止 IP 分片**的原因如下：
|
||||
|
||||
**1. 性能下降 & 额外开销增加**
|
||||
|
||||
- 分片会导致 **路由器和防火墙的 CPU 及内存负载增加**，因为它们需要处理更多的小数据包。
|
||||
- 每个分片都需要附加额外的头部信息，增加了**协议开销**，降低了有效数据传输效率。
|
||||
- 目标端的 **数据重组** 需要缓冲区（buffer），在高吞吐量环境下容易造成**延迟**或**资源耗尽**。
|
||||
|
||||
**2. 安全风险增加 & 易受攻击**
|
||||
|
||||
- 分片容易受到 **基于分片的攻击**，例如**重叠分片攻击（Teardrop attack）\**和\**微小分片攻击（Tiny Fragment Attack）**，这些攻击可用于绕过安全检查。
|
||||
- **入侵检测系统（IDS）和防火墙** 可能无法正确分析分片数据包，导致攻击者可以绕过安全策略，传输恶意负载。
|
||||
- 攻击者可以发送 **丢失部分片段的数据包**，导致目标设备的**资源耗尽（DoS 攻击）**，因为系统需要长时间等待完整数据包。
|
||||
|
||||
**3. PMTUD（路径 MTU 发现）问题 & 数据丢失风险**
|
||||
|
||||
- 现代网络通常使用 **路径 MTU 发现（PMTUD）** 机制来动态确定最佳数据包大小，如果允许分片，错误的 PMTUD 配置可能导致**持续的重传**问题。
|
||||
- 如果 **一个分片丢失**，整个数据包必须重新传输，导致**更高的数据丢失率**和**不必要的网络流量**。
|
||||
- 一些中间设备（如 **NAT 设备、防火墙**）可能会**直接丢弃**分片数据包，导致通信失败。
|
||||
|
||||
iii) Wie wird in modernen TCP/IP-Implementierungen dafür gesorgt, dass Fragmentierung in der Regel nicht erforderlich ist? 在现代的 TCP/IP 实现中，是如何确保通常情况下不需要分片的？
|
||||
|
||||
### **How Do Modern TCP/IP Implementations Avoid the Need for Fragmentation?**
|
||||
|
||||
Modern TCP/IP implementations use several techniques to **minimize or eliminate IP fragmentation**, ensuring efficient packet transmission. The key mechanisms include:
|
||||
|
||||
#### **1. Path MTU Discovery (PMTUD)**
|
||||
|
||||
- **PMTUD dynamically determines the maximum packet size** that can be transmitted without fragmentation.
|
||||
- It works by sending packets with the **Don't Fragment (DF) flag** set. If a router cannot forward the packet due to MTU limitations, it drops the packet and sends an **ICMP "Fragmentation Needed" message** back to the sender.
|
||||
- The sender then **reduces the packet size** accordingly until it finds a suitable MTU.
|
||||
- **Drawback:** Some networks block ICMP messages, causing PMTUD to fail.
|
||||
|
||||
#### **2. TCP Maximum Segment Size (MSS) Adjustment**
|
||||
|
||||
- During the **TCP handshake**, both communicating hosts negotiate the **Maximum Segment Size (MSS)**, which defines the largest payload a TCP segment can carry.
|
||||
- The MSS is set to ensure that the TCP segment, when combined with headers, does not exceed the MTU.
|
||||
- This prevents the need for IP fragmentation at the transport layer.
|
||||
|
||||
#### **3. IPv6 Enforces No Fragmentation by Routers**
|
||||
|
||||
- Unlike IPv4, **IPv6 does not allow routers to fragment packets**. Instead, **only the sender can fragment** based on the discovered MTU.
|
||||
- IPv6 requires **end-to-end PMTUD**, ensuring that packets fit within the smallest MTU along the path.
|
||||
- This shifts the responsibility of fragmentation from routers to the sender, improving network efficiency.
|
||||
|
||||
#### **4. Datagram Packetization Layer Path MTU Discovery (DPLPMTUD)**
|
||||
|
||||
- To address ICMP blocking issues in traditional PMTUD, **DPLPMTUD** uses **probe packets** of increasing sizes to discover the optimal MTU.
|
||||
- This method is more reliable since it does not rely on ICMP messages.
|
||||
- Supported in protocols like **QUIC and modern TCP implementations**.
|
||||
|
||||
### **Conclusion:**
|
||||
|
||||
Modern TCP/IP implementations avoid fragmentation by:
|
||||
|
||||
1. **Using PMTUD** to dynamically adjust packet sizes.
|
||||
2. **Negotiating MSS** in TCP to prevent oversized packets.
|
||||
3. **Relying on IPv6's no-fragmentation rule** and sender-side control.
|
||||
4. **Using DPLPMTUD** as an advanced method for MTU discovery.
|
||||
|
||||
------
|
||||
|
||||
### **在现代的 TCP/IP 实现中，是如何确保通常情况下不需要分片的？**
|
||||
|
||||
现代 TCP/IP 实现采用多个技术来**减少或避免 IP 分片**，从而提高数据传输效率。主要方法包括：
|
||||
|
||||
#### **1. 路径 MTU 发现（PMTUD）**
|
||||
|
||||
- **PMTUD 负责动态确定数据包的最大可传输大小**，以避免分片。
|
||||
- 它通过发送 **“不分片（DF）”标志** 的数据包来测试路径 MTU。
|
||||
- 如果路由器无法转发该数据包（因为 MTU 限制），它会丢弃数据包并返回 **ICMP “需要分片”** 消息。
|
||||
- 发送方根据反馈**调整数据包大小**，直到找到合适的 MTU。
|
||||
- **缺点：**某些网络会屏蔽 ICMP 消息，导致 PMTUD 失败。
|
||||
|
||||
#### **2. TCP 最大段大小（MSS）调整**
|
||||
|
||||
- 在 **TCP 握手** 过程中，双方会协商 **最大段大小（MSS）**，决定 TCP 段的最大有效负载。
|
||||
- MSS 设定时会确保 TCP 段加上 **IP 和 TCP 头部** 不会超过 MTU。
|
||||
- 这样可以在 **传输层避免 IP 分片**，确保数据包大小适应网络环境。
|
||||
|
||||
#### **3. IPv6 取消路由器分片**
|
||||
|
||||
- IPv6 **不允许路由器对数据包进行分片**，只有**发送端**可以执行分片。
|
||||
- IPv6 依赖 **端到端的 PMTUD**，确保数据包适应最小 MTU。
|
||||
- 这使得分片的控制权交给发送方，**提升了网络效率**。
|
||||
|
||||
#### **4. 数据报分组层路径 MTU 发现（DPLPMTUD）**
|
||||
|
||||
- 传统 PMTUD 依赖 ICMP 消息，但某些网络会**屏蔽 ICMP**，导致失败。
|
||||
- **DPLPMTUD** 通过发送不同大小的**探测数据包**来测试路径 MTU，而不依赖 ICMP。
|
||||
- 这种方法更可靠，并已在 **QUIC 和现代 TCP 实现** 中得到支持。
|
||||
|
||||
### **总结：**
|
||||
|
||||
现代 TCP/IP 通过以下方式避免分片：
|
||||
|
||||
1. **使用 PMTUD** 动态调整数据包大小。
|
||||
2. **TCP 通过 MSS 协商**，确保 TCP 段不会超出 MTU 限制。
|
||||
3. **IPv6 取消路由器分片**，让发送方控制数据包大小。
|
||||
4. **DPLPMTUD 提供更先进的 MTU 发现机制**，解决 ICMP 屏蔽问题。
|
||||
|
||||
### A301 IPv6 (Theorie)
|
||||
|
||||
i) Erklären Sie anhand eines Beispiels auf einer Ihrer VMs wie link-local Adressen aus der MAC-Adresse abgeleitet werden! 请结合您虚拟机中的一个示例，解释链路本地地址是如何从 MAC 地址派生的！
|
||||
|
||||
1. Split the MAC address into two halves:
|
||||
|
||||
- `08:00:27:53:8a:e0` → `08:00:27` and `53:8a:e0`
|
||||
|
||||
2. Insert `FF:FE` in the middle:
|
||||
|
||||
- `08:00:27:FF:FE:53:8a:e0`
|
||||
|
||||
3. Invert the 7th bit (Universal/Local bit) of the first byte (08):
|
||||
|
||||
- Convert `08` to binary: `00001000`
|
||||
- Flip the **7th bit**: `00001010` (which is `0A` in hex)
|
||||
- New identifier: **0A:00:27:FF:FE:53:8A:E0**
|
||||
|
||||
4.
|
||||
|
||||
5. ```
|
||||
FE80::0A00:27FF:FE53:8AE0
|
||||
```
|
||||
|
||||
ii) Wie implementiert IPv6 „Broadcasts”? IPv6 是如何实现“广播”的？
|
||||
|
||||
iii) Welches sind die privaten Adressbereiche in IPv6, analog zu 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16 in IPv4? IPv6 中的私有地址范围与 IPv4 中的 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16 对应的是什么？**What Are the Private Address Ranges in IPv6, Equivalent to IPv4's 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16?**
|
||||
|
||||
In **IPv6**, the equivalent of IPv4’s private address ranges includes **Unique Local Addresses (ULA)** and **Link-Local Addresses**.
|
||||
|
||||
#### **1. Unique Local Addresses (ULA) – Equivalent to IPv4 Private Addresses**
|
||||
|
||||
- **Address Range:** `FC00::/7` (commonly used as `FD00::/8`)
|
||||
|
||||
- **Similar to:** IPv4 **10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16**
|
||||
|
||||
- **Purpose:** Used for private networks **without global Internet access**.
|
||||
|
||||
- Structure:
|
||||
|
||||
```
|
||||
FC00::/7
|
||||
```
|
||||
|
||||
is divided as:
|
||||
|
||||
- `FC00::/8` (reserved, not widely used)
|
||||
- `FD00::/8` (widely used for private networks)
|
||||
- The next **40 bits** are a randomly generated "Global ID" to ensure uniqueness.
|
||||
- The remaining **16 bits** are for subnetting.
|
||||
|
||||
Example ULA address:
|
||||
|
||||
```
|
||||
FD12:3456:789A::/48
|
||||
```
|
||||
|
||||
- These addresses are **not routable on the global Internet** but can be used across a large organization.
|
||||
|
||||
------
|
||||
|
||||
#### **2. Link-Local Addresses – Equivalent to IPv4 APIPA (169.254.0.0/16)**
|
||||
|
||||
- **Address Range:** `FE80::/10`
|
||||
- **Similar to:** IPv4 **169.254.0.0/16** (Automatic Private IP Addressing, APIPA)
|
||||
- **Purpose:** Used for communication **within the same link (network segment)**.
|
||||
- **Mandatory:** Every IPv6-enabled device **must** have a link-local address.
|
||||
- **Not Routable:** Cannot be forwarded beyond the local network interface.
|
||||
- **Automatically Assigned:** The address is generated based on the interface MAC address (Modified EUI-64) or a random value.
|
||||
|
||||
Example link-local address:
|
||||
|
||||
```
|
||||
FE80::1a2b:3c4d:5e6f:7g8h/64
|
||||
```
|
||||
|
||||
- Always used in local communication, like **Neighbor Discovery Protocol (NDP) and Router Advertisements (RA)**.
|
||||
|
||||
------
|
||||
|
||||
### **Comparison: IPv4 Private vs. IPv6 Private**
|
||||
|
||||
| **IPv4 Private Address** | **Equivalent IPv6 Address** | **Usage** |
|
||||
| ------------------------ | --------------------------- | -------------------------------------------- |
|
||||
| 10.0.0.0/8 | FD00::/8 (ULA) | Private networks |
|
||||
| 172.16.0.0/12 | FD00::/8 (ULA) | Private networks |
|
||||
| 192.168.0.0/16 | FD00::/8 (ULA) | Private home/enterprise networks |
|
||||
| 169.254.0.0/16 (APIPA) | FE80::/10 (Link-Local) | Automatic addressing within the same network |
|
||||
|
||||
### **Conclusion**
|
||||
|
||||
- **`FD00::/8` (ULA) replaces IPv4 private addresses** (10.x.x.x, 172.16.x.x, 192.168.x.x).
|
||||
- **`FE80::/10` (Link-Local) replaces IPv4 APIPA** (169.254.x.x) and is used for local communication.
|
||||
|
||||
Thus, **IPv6 provides private networking similar to IPv4 but with better uniqueness and flexibility**.
|
||||
|
||||
------
|
||||
|
||||
### **IPv6 中的私有地址范围，与 IPv4 中的 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16 对应的是什么？**
|
||||
|
||||
在 **IPv6** 中，与 **IPv4 私有地址** 对应的主要是 **唯一本地地址（ULA）** 和 **链路本地地址（Link-Local Address）**。
|
||||
|
||||
------
|
||||
|
||||
#### **1. 唯一本地地址（ULA）—— 对应 IPv4 私有地址**
|
||||
|
||||
- **地址范围：** `FC00::/7`（通常使用 `FD00::/8`）
|
||||
|
||||
- **类似于：** IPv4 **10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16**
|
||||
|
||||
- **用途：** 供**私有网络使用，不能访问互联网**。
|
||||
|
||||
- 结构：
|
||||
|
||||
```
|
||||
FC00::/7
|
||||
```
|
||||
|
||||
进一步划分为：
|
||||
|
||||
- `FC00::/8`（保留地址，通常不使用）。
|
||||
- `FD00::/8`（广泛用于私有网络）。
|
||||
- 接下来的 **40 位** 是随机生成的 “Global ID”，以确保不同网络中的 ULA 地址唯一。
|
||||
- 其余 **16 位** 用于子网划分。
|
||||
|
||||
示例 ULA 地址：
|
||||
|
||||
```
|
||||
FD12:3456:789A::/48
|
||||
```
|
||||
|
||||
- **不会在全球互联网路由**，但可以用于大规模企业网络或 VPN 连接。
|
||||
|
||||
------
|
||||
|
||||
#### **2. 链路本地地址（Link-Local Address）—— 对应 IPv4 APIPA (169.254.0.0/16)**
|
||||
|
||||
- **地址范围：** `FE80::/10`
|
||||
- **类似于：** IPv4 **169.254.0.0/16**（自动私有 IP 地址，APIPA）
|
||||
- **用途：** 仅用于**同一链路（网络段）内的通信**。
|
||||
- **强制要求：** 每个 IPv6 设备都**必须**拥有一个链路本地地址。
|
||||
- **不可路由：** 不能跨网络转发，仅用于本地通信。
|
||||
- **自动分配：** 设备启动时，会根据**接口 MAC 地址（EUI-64）或随机数**自动生成地址。
|
||||
|
||||
示例链路本地地址：
|
||||
|
||||
```
|
||||
FE80::1a2b:3c4d:5e6f:7g8h/64
|
||||
```
|
||||
|
||||
- 常用于**本地通信**，如 **邻居发现协议（NDP）和路由器通告（RA）**。
|
||||
|
||||
------
|
||||
|
||||
### **IPv4 私有地址 vs. IPv6 私有地址**
|
||||
|
||||
| **IPv4 私有地址** | **对应 IPv6 地址** | **用途** |
|
||||
| ---------------------- | -------------------- | ------------------ |
|
||||
| 10.0.0.0/8 | FD00::/8 (ULA) | 私有网络 |
|
||||
| 172.16.0.0/12 | FD00::/8 (ULA) | 私有网络 |
|
||||
| 192.168.0.0/16 | FD00::/8 (ULA) | 私有家庭或企业网络 |
|
||||
| 169.254.0.0/16 (APIPA) | FE80::/10 (链路本地) | 同一局域网自动通信 |
|
||||
|
||||
------
|
||||
|
||||
### **总结**
|
||||
|
||||
- **`FD00::/8`（ULA）取代 IPv4 私有地址**（10.x.x.x, 172.16.x.x, 192.168.x.x）。
|
||||
- **`FE80::/10`（链路本地地址）取代 IPv4 APIPA 地址**（169.254.x.x），用于本地通信。
|
||||
|
||||
IPv6 提供了与 IPv4 类似的私有网络方案，但**解决了 IPv4 私有地址冲突的问题，提供更好的唯一性和灵活性**。
|
||||
|
||||
iv) Für besondere Zwecke, außer für den privaten Gebrauch, sind noch weitere Bereiche reserviert. Wie teilt sich der IPv6 Addressraum auf? Hinweis: IANA, ignorieren Sie die vom IETF reservierten Bereiche 除了私人用途外，还有其他特殊用途的地址范围被保留。IPv6 地址空间如何划分？提示：请参考 IANA，并忽略由 IETF 保留的范围。
|
||||
290
RESTful-APIs.md
Normal file
290
RESTful-APIs.md
Normal file
@@ -0,0 +1,290 @@
|
||||
# RESTful APIs Documentation
|
||||
|
||||
These APIs are designed to control **TCP** traffic.
|
||||
|
||||
---
|
||||
|
||||
## Policy Endpoints
|
||||
|
||||
Policy rules determine whether to **allow** or **deny** connections between two IP addresses and a specific destination port.
|
||||
|
||||
---
|
||||
|
||||
### **1. Add a Policy Rule**
|
||||
Add a new policy rule to allow or deny traffic.
|
||||
|
||||
- **HTTP Method**: `POST`
|
||||
- **URL Path**: `/policies`
|
||||
- **Request Body**:
|
||||
- `src_ip` (string): Source IP address.
|
||||
- `dst_ip` (string): Destination IP address.
|
||||
- `dst_port` (string): Destination port.
|
||||
- `action` (string): Must be either `allow` or `deny`.
|
||||
|
||||
#### **Example**
|
||||
- **Request**:
|
||||
```bash
|
||||
curl -X POST -H "Content-Type: application/json" -d '{"src_ip": "172.16.1.1", "dst_ip": "172.16.1.2", "dst_port": "5201", "action": "allow"}' http://localhost:8080/policies
|
||||
```
|
||||
|
||||
- **Response**:
|
||||
```json
|
||||
{
|
||||
"action": "allow",
|
||||
"dst_ip": "172.16.1.2",
|
||||
"dst_port": "5201",
|
||||
"id": 0,
|
||||
"src_ip": "172.16.1.1"
|
||||
}
|
||||
```
|
||||
|
||||
- **Status Codes**:
|
||||
- `201 Created`: Policy rule added successfully.
|
||||
- `400 Bad Request`: Invalid input data.
|
||||
- `409 Conflict`: Rule already exists.
|
||||
|
||||
---
|
||||
|
||||
### **2. Retrieve Policy Rules**
|
||||
Fetch all existing policy rules.
|
||||
|
||||
- **HTTP Method**: `GET`
|
||||
- **URL Path**: `/policies`
|
||||
|
||||
#### **Example**
|
||||
- **Request**:
|
||||
```bash
|
||||
curl -X GET http://localhost:8080/policies
|
||||
```
|
||||
|
||||
- **Response**:
|
||||
```json
|
||||
[
|
||||
{
|
||||
"action": "allow",
|
||||
"dst_ip": "172.16.1.2",
|
||||
"dst_port": "5201",
|
||||
"id": 0,
|
||||
"src_ip": "172.16.1.1"
|
||||
},
|
||||
{
|
||||
"action": "allow",
|
||||
"dst_ip": "172.16.1.2",
|
||||
"dst_port": "5202",
|
||||
"id": 1,
|
||||
"src_ip": "172.16.1.1"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
- **Status Codes**:
|
||||
- `200 OK`: Returns the list of policy rules.
|
||||
|
||||
---
|
||||
|
||||
### **3. Update a Policy Rule**
|
||||
Modify an existing policy rule.
|
||||
|
||||
- **HTTP Method**: `PUT`
|
||||
- **URL Path**: `/policies`
|
||||
- **Request Body**:
|
||||
- `src_ip` (string): Source IP address.
|
||||
- `dst_ip` (string): Destination IP address.
|
||||
- `dst_port` (string): Destination port.
|
||||
- `action` (string): Must be either `allow` or `deny`.
|
||||
|
||||
#### **Example**
|
||||
- **Request**:
|
||||
```bash
|
||||
curl -X PUT -H "Content-Type: application/json" -d '{"src_ip": "172.16.1.1", "dst_ip": "172.16.1.2", "dst_port": "5201", "action": "allow"}' http://localhost:8080/policies
|
||||
```
|
||||
|
||||
- **Response**:
|
||||
```json
|
||||
{
|
||||
"action": "allow",
|
||||
"dst_ip": "172.16.1.2",
|
||||
"dst_port": "5201",
|
||||
"id": 0,
|
||||
"src_ip": "172.16.1.1"
|
||||
}
|
||||
```
|
||||
|
||||
- **Status Codes**:
|
||||
- `201 Updated`: Policy rule updated successfully.
|
||||
- `400 Bad Request`: Invalid input data.
|
||||
|
||||
---
|
||||
|
||||
### **4. Delete a Policy Rule**
|
||||
Remove a policy rule by its ID.
|
||||
|
||||
- **HTTP Method**: `DELETE`
|
||||
- **URL Path**: `/policies/{id}`
|
||||
|
||||
#### **Example**
|
||||
- **Request**:
|
||||
```bash
|
||||
curl -X DELETE http://localhost:8080/policies/1
|
||||
```
|
||||
|
||||
- **Response**:
|
||||
```json
|
||||
{
|
||||
"message": "Policy deleted"
|
||||
}
|
||||
```
|
||||
|
||||
- **Status Codes**:
|
||||
- `201 Deleted`: Policy rule deleted successfully.
|
||||
- `404 Not Found`: Rule does not exist.
|
||||
|
||||
---
|
||||
|
||||
## Bandwidth Control Endpoints
|
||||
|
||||
These endpoints manage bandwidth control rules using **P4 meter**. They regulate traffic bandwidth between two IP addresses and a specific destination port.
|
||||
|
||||
Bandwidth is controlled using four parameters:
|
||||
- **CIR (Committed Information Rate)**: Guaranteed minimum bandwidth.
|
||||
- **Cburst (Committed Burst Size)**: Maximum allowed burst above CIR.
|
||||
- **PIR (Peak Information Rate)**: Maximum allowed bandwidth.
|
||||
- **Pburst (Peak Burst Size)**: Maximum allowed burst above PIR.
|
||||
|
||||
**Note**: During testing with `iperf3`, the actual bandwidth was observed to be approximately half of the configured value.
|
||||
|
||||
---
|
||||
|
||||
### **1. Add a Bandwidth Control Rule**
|
||||
Add a new bandwidth control rule.
|
||||
|
||||
- **HTTP Method**: `POST`
|
||||
- **URL Path**: `/bandwidth`
|
||||
- **Request Body**:
|
||||
- `src_ip` (string): Source IP address.
|
||||
- `dst_ip` (string): Destination IP address.
|
||||
- `rates` (list): A list containing two lists:
|
||||
- `[[CIR (bytes), Cburst (bytes)], [PIR (bytes), Pburst (bytes)]]`
|
||||
- `dst_port` (string): Destination port.
|
||||
|
||||
#### **Example**
|
||||
- **Request**:
|
||||
```bash
|
||||
curl -X POST -H "Content-Type: application/json" -d '{"src_ip": "172.16.1.1", "dst_ip": "172.16.1.2", "rates": [[100000, 10000], [100000, 10000]], "dst_port": "5201"}' http://localhost:8080/bandwidth
|
||||
```
|
||||
|
||||
- **Response**:
|
||||
```json
|
||||
{
|
||||
"dst_ip": "172.16.1.2",
|
||||
"dst_port": "5201",
|
||||
"path": ["s1", "s2"],
|
||||
"rates": [[100000, 10000], [100000, 10000]],
|
||||
"src_ip": "172.16.1.1"
|
||||
}
|
||||
```
|
||||
|
||||
- **Status Codes**:
|
||||
- `201 Created`: Bandwidth control rule added successfully.
|
||||
- `400 Bad Request`: Invalid input data.
|
||||
- `409 Conflict`: Rule already exists.
|
||||
|
||||
---
|
||||
|
||||
### **2. Retrieve Bandwidth Control Rules**
|
||||
Fetch all existing bandwidth control rules.
|
||||
|
||||
- **HTTP Method**: `GET`
|
||||
- **URL Path**: `/bandwidth`
|
||||
|
||||
#### **Example**
|
||||
- **Request**:
|
||||
```bash
|
||||
curl -X GET http://localhost:8080/bandwidth
|
||||
```
|
||||
|
||||
- **Response**:
|
||||
```json
|
||||
[
|
||||
{
|
||||
"dst_ip": "172.16.1.2",
|
||||
"dst_port": "5201",
|
||||
"id": 0,
|
||||
"path": ["s1", "s2"],
|
||||
"rates": [[100000, 10000], [100000, 10000]],
|
||||
"src_ip": "172.16.1.1"
|
||||
},
|
||||
{
|
||||
"dst_ip": "172.16.1.2",
|
||||
"dst_port": "5202",
|
||||
"id": 1,
|
||||
"path": ["s1", "s2"],
|
||||
"rates": [[100000, 10000], [100000, 10000]],
|
||||
"src_ip": "172.16.1.1"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
- **Status Codes**:
|
||||
- `200 OK`: Returns the list of bandwidth control rules.
|
||||
|
||||
---
|
||||
|
||||
### **3. Update a Bandwidth Control Rule**
|
||||
Modify an existing bandwidth control rule. If the rule does not exist, it will be created.
|
||||
|
||||
- **HTTP Method**: `PUT`
|
||||
- **URL Path**: `/bandwidth`
|
||||
- **Request Body**:
|
||||
- `src_ip` (string): Source IP address.
|
||||
- `dst_ip` (string): Destination IP address.
|
||||
- `rates` (list): A list containing two lists:
|
||||
- `[[CIR (bytes), Cburst (bytes)], [PIR (bytes), Pburst (bytes)]]`
|
||||
- `dst_port` (string): Destination port.
|
||||
|
||||
#### **Example**
|
||||
- **Request**:
|
||||
```bash
|
||||
curl -X PUT -H "Content-Type: application/json" -d '{"src_ip": "172.16.1.1", "dst_ip": "172.16.1.2", "rates": [[150000, 10000], [150000, 10000]], "dst_port": "5201"}' http://localhost:8080/bandwidth
|
||||
```
|
||||
|
||||
- **Response**:
|
||||
```json
|
||||
{
|
||||
"dst_ip": "172.16.1.2",
|
||||
"dst_port": "5201",
|
||||
"path": ["s1", "s2"],
|
||||
"rates": [[150000, 10000], [150000, 10000]],
|
||||
"src_ip": "172.16.1.1"
|
||||
}
|
||||
```
|
||||
|
||||
- **Status Codes**:
|
||||
- `201 Updated`: Bandwidth control rule updated successfully.
|
||||
- `400 Bad Request`: Invalid input data.
|
||||
|
||||
---
|
||||
|
||||
### **4. Delete a Bandwidth Control Rule**
|
||||
Remove a bandwidth control rule by its ID.
|
||||
|
||||
- **HTTP Method**: `DELETE`
|
||||
- **URL Path**: `/bandwidth/{id}`
|
||||
|
||||
#### **Example**
|
||||
- **Request**:
|
||||
```bash
|
||||
curl -X DELETE http://localhost:8080/bandwidth/1
|
||||
```
|
||||
|
||||
- **Response**:
|
||||
```json
|
||||
{
|
||||
"message": "Bandwidth rule deleted"
|
||||
}
|
||||
```
|
||||
|
||||
- **Status Codes**:
|
||||
- `201 Deleted`: Bandwidth control rule deleted successfully.
|
||||
- `404 Not Found`: Rule does not exist.
|
||||
|
||||
BIN
assets/automaton.drawio.png
Normal file
BIN
assets/automaton.drawio.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 62 KiB |
Reference in New Issue
Block a user