link tutorial
Getting Started
- connect it to an OpenFlow controller or use ovs-ofctl to examine and modify it and its OpenFlow flow table.
- On the other hand, the bridge is not visible to the operating system’s network stack, so ip cannot see it or affect it, which means that utilities like ping and tcpdump will not work either. (That has its good side, too: you can’t screw up your computer’s network stack by manipulating a sandboxed OVS.)
Using GDB
Motivation
using an OpenFlow controller to implement MAC learning
- has a significant cost in terms of network bandwidth and latency.
- makes the controller more difficult to scale to large numbers of switches, which is especially important in environments with thousands of hypervisors (each of which contains a virtual OpenFlow switch).
- behaves poorly if the OpenFlow controller fails, slows down, or becomes unavailable due to network problems.
Scenario
A trunk port is a port that is assigned to carry traffic for all the VLANs that are accessible by a specific switch, a process known as trunking. Trunk ports mark frames with unique identifying tags – either 802.1Q tags or Inter-Switch Link (ISL) tags – as they move between switches.
Setup
for i in 1 2 3 4;do ovs-vsctl set Interface p$i type=internal;done
Implementing Table 0: Admission control
Table 0 is where packets enter the switch. We use this stage to discard packets that for one reason or another are invalid. For example, packets with a multicast source address are not valid, so we can add a flow to drop them at ingress to the switch with:
ovs-ofctl add-flow br0 \
"table=0, dl_src=01:00:00:00:00:00/01:00:00:00:00:00, actions=drop"
A switch should also not forward IEEE 802.1D Spanning Tree Protocol (STP) packets, so we can also add a flow to drop those and other packets with reserved multicast protocols:
ovs-ofctl add-flow br0 \
"table=0, dl_dst=01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0, actions=drop"
We need one more flow, with a priority lower than the default, so that flows that don’t match either of the “drop” flows we added above go on to pipeline stage 1 in OpenFlow table 1:
ovs-ofctl add-flow br0 "table=0, priority=0, actions=resubmit(,1)"
The “resubmit” action is an Open vSwitch extension to OpenFlow.
Testing Table 0
network testing tools : ping tcpdump Scapy(more specialized )
That’s difficult with our simulated switch, since it’s not visible to the operating system.
(according to the youtube vedio can ifconfig br0 up）
But our simulated switch has a few specialized testing tools. The most powerful of these tools is ofproto/trace. Given a switch and the specification of a flow, ofproto/trace shows, step-by-step, how such a flow would be treated as it goes through the switch.
ovs-vsctl list interface
Why doesn’t it work?
Example 1
what’s on hell the dl_dst is?
ovs-appctl ofproto/trace br0 in_port=1,dl_dst=01:80:c2:00:00:05
注意重启了flow table就会清空！怪不得下面的结果那么奇怪
ovs-ofctl dump-flows br0
ovs-appctl ofproto/trace br0 in_port=1,dl_dst=01:80:c2:00:00:05
Implementing Table 1: VLAN Input Processing
Table 1的目的就在於過濾已包含 VLAN header 的封包，及幫未包含 VLAN header 的封包標註上我們將要賦予它的 VLAN number，並往下一個階段轉送。
因為要將port p1當作 VLAN 的主幹，所以不管流入的封包是否有 VLAN hander 或者他是屬於那個 VLAN ，都會將收到的封包往下一階段轉送。因此，我們加入規則：
sudo ovs-ofctl add-flow br0 \
"table=1, priority=99, in_port=1, actions=resubmit(,2)"
其他的 port 我們則是希望將沒有標明 VLAN header 的封包，進行標注 VLAN number，再讓此封包往下一階段轉送:
sudo ovs-ofctl add-flows br0 - << 'EOF'
table=1, priority=99, in_port=2, vlan_tci=0, actions=mod_vlan_vid:20, resubmit(,2)
table=1, priority=99, in_port=3, vlan_tci=0, actions=mod_vlan_vid:30, resubmit(,2)
table=1, priority=99, in_port=4, vlan_tci=0, actions=mod_vlan_vid:30, resubmit(,2)
EOF
在這個階段我們並未寫任何關於 match 802.1Q （VLAN）的對應規則，所以只要在這個階段收到含有 VLAN header 資訊的封包，我們則會進行drop（除了port 1）。
Implementing Table 2: MAC+VLAN Learning for Ingress Port
Implementing Table 3: Look Up Destination Port
Implementing Table 4: Output Processing
结果没有匹配上
不知道哪里错了，从这开始的所有的table 4 都匹配不上