diff options
Diffstat (limited to 'tutorial/OVN-Tutorial.md')
| -rw-r--r-- | tutorial/OVN-Tutorial.md | 356 |
1 files changed, 205 insertions, 151 deletions
diff --git a/tutorial/OVN-Tutorial.md b/tutorial/OVN-Tutorial.md index 3d0f538d7..a1fff0bba 100644 --- a/tutorial/OVN-Tutorial.md +++ b/tutorial/OVN-Tutorial.md @@ -503,66 +503,78 @@ connectivity to that network. We call these “bridge mappings”. For our example, the following script creates a bridge called `br-eth1` and then configures `ovn-controller` with a bridge mapping from `physnet1` to `br-eth1`. -[View ovn/env4/setup1.sh][env4setup1]. +We want to create a fake second chassis and then create the topology that tells +OVN we want both ports on both hypervisors connected to `physnet1`. The way this +is modeled in OVN is by creating a logical switch for each port. The logical +switch has the regular VIF port and a `localnet` port. - $ ovn/env4/setup1.sh +[View ovn/env4/setup.sh][env4setup]. + + $ ovn/env4/setup.sh At this point we should be able to see that `ovn-controller` has automatically created patch ports between `br-int` and `br-eth1`. $ ovs-vsctl show - aea39214-ebec-4210-aa34-1ae7d6921720 + c0a06d85-d70a-4e11-9518-76a92588b34e + Bridge "br-eth1" + Port "patch-provnet1-1-physnet1-to-br-int" + Interface "patch-provnet1-1-physnet1-to-br-int" + type: patch + options: {peer="patch-br-int-to-provnet1-1-physnet1"} + Port "br-eth1" + Interface "br-eth1" + type: internal + Port "patch-provnet1-2-physnet1-to-br-int" + Interface "patch-provnet1-2-physnet1-to-br-int" + type: patch + options: {peer="patch-br-int-to-provnet1-2-physnet1"} Bridge br-int fail_mode: secure - Port “patch-br-int-to-br-eth1” - Interface “patch-br-int-to-br-eth1” + Port "ovn-fakech-0" + Interface "ovn-fakech-0" + type: geneve + options: {key=flow, remote_ip="127.0.0.1"} + Port "patch-br-int-to-provnet1-2-physnet1" + Interface "patch-br-int-to-provnet1-2-physnet1" type: patch - options: {peer=”patch-br-eth1-to-br-int”} + options: {peer="patch-provnet1-2-physnet1-to-br-int"} Port br-int Interface br-int type: internal - Bridge “br-eth1” - Port “br-eth1” - Interface “br-eth1” - type: internal - Port “patch-br-eth1-to-br-int” - Interface “patch-br-eth1-to-br-int” + Port "patch-br-int-to-provnet1-1-physnet1" + Interface "patch-br-int-to-provnet1-1-physnet1" type: patch - options: {peer=”patch-br-int-to-br-eth1”} - -Now we can move on to the next setup phase for this example. We want to create -a fake second chassis and then create the topology that tells OVN we want both -ports on both hypervisors connected to `physnet1`. The way this is modeled in -OVN is by creating a logical switch for each port. The logical switch has the -regular VIF port and a `localnet` port. - -[View ovn/env4/setup2.sh][env4setup2]. + options: {peer="patch-provnet1-1-physnet1-to-br-int"} + Port "lport2" + Interface "lport2" + Port "lport1" + Interface "lport1 - $ ovn/env4/setup2.sh The logical topology from `ovn-nbctl` should look like this. $ ovn-nbctl show - switch 5a652488-cfba-4f3e-929d-00010cdfde40 (provnet1-2) - port provnet1-2-physnet1 - addresses: unknown - port provnet1-2-port1 - addresses: 00:00:00:00:00:02 - switch 5829b60a-eda8-4d78-94f6-7017ff9efcf0 (provnet1-4) - port provnet1-4-port1 - addresses: 00:00:00:00:00:04 - port provnet1-4-physnet1 - addresses: unknown - switch 06cbbcb6-38e3-418d-a81e-634ec9b54ad6 (provnet1-1) - port provnet1-1-port1 - addresses: 00:00:00:00:00:01 - port provnet1-1-physnet1 - addresses: unknown - switch 9cba3b3b-59ae-4175-95f5-b6f1cd9c2afb (provnet1-3) - port provnet1-3-physnet1 - addresses: unknown - port provnet1-3-port1 - addresses: 00:00:00:00:00:03 + switch 9db81140-5504-4f60-be3d-2bee45b57e27 (provnet1-2) + port provnet1-2-port1 + addresses: ["00:00:00:00:00:02"] + port provnet1-2-physnet1 + addresses: ["unknown"] + switch cf175cb9-35c5-41cf-8bc7-2d322cdbead0 (provnet1-3) + port provnet1-3-physnet1 + addresses: ["unknown"] + port provnet1-3-port1 + addresses: ["00:00:00:00:00:03"] + switch b85f7af6-8055-4db2-ba93-efc7887cf38f (provnet1-1) + port provnet1-1-port1 + addresses: ["00:00:00:00:00:01"] + port provnet1-1-physnet1 + addresses: ["unknown"] + switch 63a5e276-8807-417d-bbec-a7e907e106b1 (provnet1-4) + port provnet1-4-port1 + addresses: ["00:00:00:00:00:04"] + port provnet1-4-physnet1 + addresses: ["unknown"] `port1` on each logical switch represents a regular logical port for a VIF on a hypervisor. `physnet1` on each logical switch is the special `localnet` port. @@ -578,16 +590,17 @@ The physical topology should reflect that there are two regular ports on each chassis. $ ovn-sbctl show - Chassis fakechassis + Chassis "56b18105-5706-46ef-80c4-ff20979ab068" + hostname: sandbox Encap geneve - ip: “127.0.0.1” - Port_Binding “provnet1-3-port1” - Port_Binding “provnet1-4-port1” - Chassis “56b18105-5706-46ef-80c4-ff20979ab068” + ip: "127.0.0.1" + Port_Binding "provnet1-1-port1" + Port_Binding "provnet1-2-port1" + Chassis fakechassis Encap geneve - ip: “127.0.0.1” - Port_Binding “provnet1-2-port1” - Port_Binding “provnet1-1-port1” + ip: "127.0.0.1" + Port_Binding "provnet1-3-port1" + Port_Binding "provnet1-4-port1" All four of our ports should be able to communicate with each other, but they do so through `physnet1`. A packet from any of these ports to any destination @@ -596,85 +609,87 @@ to `br-eth1`. This example assumes following OpenFlow port number mappings: -* 1 = patch port to `br-eth1` -* 2 = tunnel to the fake second chassis -* 3 = lport1, which is the logical port named `provnet1-1-port1` -* 4 = lport2, which is the logical port named `provnet1-2-port1` +* 1 = tunnel to the fake second chassis +* 2 = `lport1`, which is the logical port named `provnet1-1-port1` +* 3 = `patch-br-int-to-provnet1-1-physnet1`, patch port to `br-eth1` +* 4 = `lport2`, which is the logical port named `provnet1-2-port1` +* 5 = `patch-br-int-to-provnet1-2-physnet1`, patch port to `br-eth1` We get those port numbers using `ovs-ofctl`: $ ovs-ofctl show br-int - OFPT_FEATURES_REPLY (xid=0x2): dpid:0000765054700040 + OFPT_FEATURES_REPLY (xid=0x2): dpid:00002a84824b0d40 n_tables:254, n_buffers:256 capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP - actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src - mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst - 1(patch-br-int-to): addr:de:29:14:95:8a:b8 - config: 0 - state: 0 - speed: 0 Mbps now, 0 Mbps max - 2(ovn-fakech-0): addr:aa:55:aa:55:00:08 + actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst + 1(ovn-fakech-0): addr:aa:55:aa:55:00:0e config: PORT_DOWN state: LINK_DOWN speed: 0 Mbps now, 0 Mbps max - 3(lport1): addr:aa:55:aa:55:00:09 + 2(lport1): addr:aa:55:aa:55:00:0f config: PORT_DOWN state: LINK_DOWN speed: 0 Mbps now, 0 Mbps max - 4(lport2): addr:aa:55:aa:55:00:0a + 3(patch-br-int-to): addr:7a:6f:8a:d5:69:2a + config: 0 + state: 0 + speed: 0 Mbps now, 0 Mbps max + 4(lport2): addr:aa:55:aa:55:00:10 config: PORT_DOWN state: LINK_DOWN speed: 0 Mbps now, 0 Mbps max - LOCAL(br-int): addr:76:50:54:70:00:40 + 5(patch-br-int-to): addr:4a:fd:c1:11:fc:a5 + config: 0 + state: 0 + speed: 0 Mbps now, 0 Mbps max + LOCAL(br-int): addr:2a:84:82:4b:0d:40 config: PORT_DOWN state: LINK_DOWN speed: 0 Mbps now, 0 Mbps max OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0 This first trace shows a packet from `provnet1-1-port1` with a destination MAC -address of `provnet1-2-port1`. Despite both of these ports being on the same -local switch (`lport1` and `lport2`), we expect all packets to be sent out to -`br-eth1` (OpenFlow port 1). We then expect the network to handle getting the -packet to its destination. In practice, this will be optimized at `br-eth1` and -the packet won’t actually go out and back on the network. +address of `provnet1-2-port1`. We expect the packets from `lport1`(OpenFlow port 2) +to be sent out to `lport2`(OpenFlow port 4). For example, the following topology +illustrates how the packets travel from `lport1` to `lport2`. + + `lport1` --> `patch-br-int-to-provnet1-1-physnet1`(OpenFlow port 3) + --> `br-eth1` --> `patch-br-int-to-provnet1-2-physnet1` --> `lport2`(OpenFlow port 4) + +Similarly, We expect the packets from `provnet1-2-port1` to be sent out to +`provnet1-1-port1`. We then expect the network to handle getting the packet to its +destination. In practice, this will be optimized at `br-eth1` and the packet won’t +actually go out and back on the network. [View ovn/env4/packet1.sh][env4packet1]. $ ovn/env4/packet1.sh -This next trace is a continuation of the previous one. This shows the packet -coming back into `br-int` from `br-eth1`. We now expect the packet to be output -to `provnet1-2-port1`, which is OpenFlow port 4. +This next trace shows an example of a packet being sent to a destination on another +hypervisor. The source is `provnet1-1-port1`, but the destination is `provnet1-3-port1`, +which is on the other fake chassis. As usual, we expect the output to be to `br-eth1` +(`patch-br-int-to-provnet1-1-physnet1`, OpenFlow port 3). [View ovn/env4/packet2.sh][env4packet2]. $ ovn/env4/packet2.sh -This next trace shows an example of a packet being sent to a destination on -another hypervisor. The source is `provnet1-2-port1`, but the destination is -`provnet1-3-port1`, which is on the other fake chassis. As usual, we expect the -output to be to OpenFlow port 1, the patch port to `br-et1`. - -[View ovn/env4/packet3.sh][env4packet3]. - - $ ovn/env4/packet3.sh - This next test shows a broadcast packet. The destination should still only be -OpenFlow port 1. +OpenFlow port 3 and 4. -[View ovn/env4/packet4.sh][env4packet4] +[View ovn/env4/packet3.sh][env4packet3] - $ ovn/env4/packet4.sh + $ ovn/env4/packet3.sh Finally, this last trace shows what happens when a broadcast packet arrives from the network. In this case, it simulates a broadcast that originated from a port on the remote fake chassis and arrived at the local chassis via `br-eth1`. We should see it output to both local ports that are attached to this network -(OpenFlow ports 3 and 4). +(OpenFlow ports 2 and 4). -[View ovn/env4/packet5.sh][env4packet5] +[View ovn/env4/packet4.sh][env4packet4] - $ ovn/env4/packet5.sh + $ ovn/env4/packet4.sh 5) Locally attached networks with VLANs --------------------------------------- @@ -696,83 +711,89 @@ ports representing connectivity to VLAN 101 of `physnet1` have the `tag` field set to `101`. $ ovn-nbctl show - switch 12ea93d0-694b-48e9-adef-d0ddd3ec4ac9 (provnet1-7-101) - port provnet1-7-physnet1-101 - parent: , tag:101 - addresses: unknown - port provnet1-7-101-port1 - addresses: 00:00:00:00:00:07 - switch c9a5ce3a-15ec-48ea-a898-416013463589 (provnet1-4) - port provnet1-4-port1 - addresses: 00:00:00:00:00:04 - port provnet1-4-physnet1 - addresses: unknown - switch e07d4f7a-2085-4fbb-9937-d6192b79a397 (provnet1-1) - port provnet1-1-physnet1 - addresses: unknown - port provnet1-1-port1 - addresses: 00:00:00:00:00:01 - switch 6c098474-0509-4219-bc9b-eb4e28dd1aeb (provnet1-2) - port provnet1-2-physnet1 - addresses: unknown - port provnet1-2-port1 - addresses: 00:00:00:00:00:02 - switch 723c4684-5d58-4202-b8e3-4ba99ad5ed9e (provnet1-8-101) - port provnet1-8-101-port1 - addresses: 00:00:00:00:00:08 - port provnet1-8-physnet1-101 - parent: , tag:101 - addresses: unknown - switch 8444e925-ceb2-4b02-ac20-eb2e4cfb954d (provnet1-6-101) - port provnet1-6-physnet1-101 - parent: , tag:101 - addresses: unknown - port provnet1-6-101-port1 - addresses: 00:00:00:00:00:06 - switch e11e5605-7c46-4395-b28d-cff57451fc7e (provnet1-3) - port provnet1-3-port1 - addresses: 00:00:00:00:00:03 - port provnet1-3-physnet1 - addresses: unknown - switch 0706b697-6c92-4d54-bc0a-db5bababb74a (provnet1-5-101) - port provnet1-5-101-port1 - addresses: 00:00:00:00:00:05 - port provnet1-5-physnet1-101 - parent: , tag:101 - addresses: unknown + switch 3e60b940-00bf-44c6-9db6-04abf28d7e5f (provnet1-1) + port provnet1-1-physnet1 + addresses: ["unknown"] + port provnet1-1-port1 + addresses: ["00:00:00:00:00:01"] + switch 87f6bea0-f74d-4f39-aa65-ca1f94670429 (provnet1-2) + port provnet1-2-port1 + addresses: ["00:00:00:00:00:02"] + port provnet1-2-physnet1 + addresses: ["unknown"] + switch e6c9cb69-a056-428d-aa40-e903ce416dcd (provnet1-6-101) + port provnet1-6-101-port1 + addresses: ["00:00:00:00:00:06"] + port provnet1-6-physnet1-101 + parent: + tag: 101 + addresses: ["unknown"] + switch 5f8f72ca-6030-4f66-baea-fe6174eb54df (provnet1-4) + port provnet1-4-port1 + addresses: ["00:00:00:00:00:04"] + port provnet1-4-physnet1 + addresses: ["unknown"] + switch 15d585eb-d2c1-45ea-a946-b08de0eb2f55 (provnet1-7-101) + port provnet1-7-physnet1-101 + parent: + tag: 101 + addresses: ["unknown"] + port provnet1-7-101-port1 + addresses: ["00:00:00:00:00:07"] + switch 7be4aabe-1bb0-4e16-a755-a1f6d81c1c2f (provnet1-5-101) + port provnet1-5-101-port1 + addresses: ["00:00:00:00:00:05"] + port provnet1-5-physnet1-101 + parent: + tag: 101 + addresses: ["unknown"] + switch 9bbdbf0e-50f3-4286-ba5a-29bf347531bb (provnet1-8-101) + port provnet1-8-101-port1 + addresses: ["00:00:00:00:00:08"] + port provnet1-8-physnet1-101 + parent: + tag: 101 + addresses: ["unknown"] + switch 70d053f7-2bca-4dff-96ae-bd728d3ba1d2 (provnet1-3) + port provnet1-3-physnet1 + addresses: ["unknown"] + port provnet1-3-port1 + addresses: ["00:00:00:00:00:03"] The physical topology shows that we have 4 regular VIF ports on each simulated hypervisor. $ ovn-sbctl show - Chassis “56b18105-5706-46ef-80c4-ff20979ab068” - Encap geneve - ip: “127.0.0.1” - Port_Binding “provnet1-6-101-port1” - Port_Binding “provnet1-1-port1” - Port_Binding “provnet1-2-port1” - Port_Binding “provnet1-5-101-port1” Chassis fakechassis Encap geneve - ip: “127.0.0.1” - Port_Binding “provnet1-4-port1” - Port_Binding “provnet1-3-port1” - Port_Binding “provnet1-8-101-port1” - Port_Binding “provnet1-7-101-port1” + ip: "127.0.0.1" + Port_Binding "provnet1-3-port1" + Port_Binding "provnet1-8-101-port1" + Port_Binding "provnet1-7-101-port1" + Port_Binding "provnet1-4-port1" + Chassis "56b18105-5706-46ef-80c4-ff20979ab068" + hostname: sandbox + Encap geneve + ip: "127.0.0.1" + Port_Binding "provnet1-2-port1" + Port_Binding "provnet1-5-101-port1" + Port_Binding "provnet1-1-port1" + Port_Binding "provnet1-6-101-port1" All of the traces from the previous example, `env4`, should work in this environment and provide the same result. Now we can show what happens for the ports connected to VLAN 101. This first example shows a packet originating from -`provnet1-5-101-port1`, which is OpenFlow port 5. We should see VLAN tag 101 -pushed on the packet and then output to OpenFlow port 1, the patch port to -`br-eth1` (the bridge providing connectivity to `physnet1`). +`provnet1-5-101-port1`, which is OpenFlow port 6. We should see VLAN tag 101 +pushed on the packet and then output to OpenFlow port 7, the patch port to +`br-eth1` (the bridge providing connectivity to `physnet1`), and finally arrives +on OpenFlow port 8. [View ovn/env5/packet1.sh][env5packet1]. $ ovn/env5/packet1.sh If we look at a broadcast packet arriving on VLAN 101 of `physnet1`, we should -see it output to OpenFlow ports 5 and 6 only. +see it output to OpenFlow ports 6 and 8 only. [View ovn/env5/packet2.sh][env5packet2]. @@ -932,6 +953,38 @@ The second trace shows a packet from 'csw0-port2' to 'csw0-port1'. You can extend this setup by adding additional container ports with two hypervisors. Please see the tutorial 3 above. +8) L2Gateway Ports +------------------ + +L2Gateway provides a way to connect logical switch ports of type `l2gateway` to +a physical network. The difference between `l2gateway` ports and `localnet` ports +is that an `l2gateway` port is bound to a specific chassis. A single chassis +serves as the L2 gateway to the physical network and all traffic between +chassis continues to go over geneve tunnels. + +Start with a simple logical switch with 3 logical ports. + +[View ovn/env8/setup.sh][env8setup]. + + $ ovn/env8/setup.sh + +This first example shows a packet originating from `lport1`, which is OpenFlow port 1. +We expect all packets from `lport1` to be sent out to br-eth1 (`patch-br-int-to-sw0-port3`, +OpenFlow port 3). The patch port to br-eth1 provides connectivity to the physical network. + +[View ovn/env8/packet1.sh][env8packet1]. + + $ ovn/env8/packet1.sh + +The last trace shows what happens when a broadcast packet arrives from the network. +In this case, it simulates a broadcast that originated from a port on the physical network +and arrived at the local chassis via br-eth1. We should see it output to the local port `lport1` +and `lport2`. + +[View ovn/env8/packet2.sh][env8packet2]. + + $ ovn/env8/packet2.sh + [ovn-architecture(7)]:http://openvswitch.org/support/dist-docs/ovn-architecture.7.html [Tutorial.md]:https://github.com/openvswitch/ovs/blob/master/tutorial/Tutorial.md [ovn-nb(5)]:http://openvswitch.org/support/dist-docs/ovn-nb.5.html @@ -957,13 +1010,11 @@ hypervisors. Please see the tutorial 3 above. [env3setup]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env3/setup.sh [env3packet1]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env3/packet1.sh [env3packet2]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env3/packet2.sh -[env4setup1]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env4/setup1.sh -[env4setup2]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env4/setup2.sh +[env4setup]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env4/setup.sh [env4packet1]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env4/packet1.sh [env4packet2]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env4/packet2.sh [env4packet3]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env4/packet3.sh [env4packet4]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env4/packet4.sh -[env4packet5]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env4/packet5.sh [env5setup]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env5/setup.sh [env5packet1]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env5/packet1.sh [env5packet2]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env5/packet2.sh @@ -973,5 +1024,8 @@ hypervisors. Please see the tutorial 3 above. [env7contports]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env7/add-container-ports.sh [env7packet1]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env7/packet1.sh [env7packet2]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env7/packet2.sh +[env8setup]:https://github.com/nickcooper-zhangtonghao/ovs/blob/master/tutorial/ovn/env8/setup.sh +[env8packet1]:https://github.com/nickcooper-zhangtonghao/ovs/blob/master/tutorial/ovn/env8/packet1.sh +[env8packet2]:https://github.com/nickcooper-zhangtonghao/ovs/blob/master/tutorial/ovn/env8/packet2.sh [openstack-ovn-acl-blog]:http://blog.russellbryant.net/2015/10/22/openstack-security-groups-using-ovn-acls/ [openvswitch-docker]:http://openvswitch.org/support/dist-docs/INSTALL.Docker.md.txt |