Hi Mickey, Thanks for your review.
If we could do some modifications to avoid the north/south problem you mentioned? Like as follow: When packets send to the localnet-port, if the MAC is router-port MAC, we change the router-port MAC to HV physical NIC MAC. And in gateway node, we make the HV physical NIC MAC and router-port MAC all sense. Thanks! Mickey Spiegel <mickeys....@gmail.com> 2017/06/30 12:31 收件人: Han Zhou <zhou...@gmail.com>, 抄送: wang.qia...@zte.com.cn, ovs dev <d...@openvswitch.org>, zhou.huij...@zte.com.cn, xurong00037997 <xu.r...@zte.com.cn> 主题: Re: [ovs-dev] 答复: Re: 答复: [spam可疑邮件]Re: 答复: Re: [PATCH 2/2] ovn-northd: Fix ping failure of vlan networks. On Thu, Jun 29, 2017 at 2:19 PM, Han Zhou <zhou...@gmail.com> wrote: I learned that this use case is kind of Hierarchical scenario: https://specs.openstack.org/openstack/neutron-specs/specs/kilo/ml2-hierarchical-port-binding.html In such scenario, user wants to use OVN to manage vlan networks, and the vlan networks is connected via VTEP overlay, which is not managed by OVN itself. VTEP is needed to connect to BM/SRIOV VMs to the same L2 that OVS VIFs are connected to. User don't want to use OVN to manage VTEPs since there will be flooding to many VTEPs. (Mac-learning is not supported yet) So in this scenario, user want to utilize distributed logical router as a way to optimize the datapath. For VM to VM traffic between different vlans, instead of going to a centralized external L3 router, user wants the traffic to be tagged to the destination vlan directly and go straight from source HV to destination HV through the destination vlan. L2 and L3 have different semantics and different ways of handling packets. There is a big difference between: 1) bridging between different VLANs, going through a VTEP overlay that connects those VLANs, and 2) routing between different VLANs. Trying to blur that boundary will lead to unexpected behavior and various issues. In the vtep scenario, this is a valuable optimization. Even in a normal vlan setup without vtep, this can be an optimization too if src and dst VMs are on the same HV (so that the packet doesn't need to go to physical switch and come back). So, I agree with Qianyu that connecting VLAN networks with logical router is reasonable, which means, the transport of logical router can be not only tunnels, but also physical networks (localnet port). Mixing routers and localnet is dangerous because of interactions with MAC addresses and L2 learning. The reason it is not a good idea to transmit packets from a distributed logical router directly to a physical network through localnet is because the router rewrites the source MAC to the router MAC. The physical network will learn about the router MAC based on the last location from which it saw the router send a packet to the physical network. That may have low correlation with the next packet from the physical network back to the router MAC, so north/south packets may end up with an almost random distribution of chassis on which the distributed logical router resides, independent of where the destination actually resides. You are looking only at east west traffic, counting on the asymmetry using the distributed router instance on the other side so that return traffic never hits the physical network with the router MAC as the destination MAC. However, there will be north/south traffic destined to the router MAC, and this approach will make that bounce all over the place. Perhaps you can make something work if you have per node per router MAC addresses, but it still scares me. To fulfill this requirement, we need to solve some problems in current OVN code: 1) Since the data path is asymmetric, we need to solve the CT problem of the localnet port. I agree with the idea of the patch from Qianyu, which bypasses FW for localnet ports, since localnet port is to connect real endpoints, so maybe there is not much value to add ACL on localnet ports. Not sure if there is use case where ACL is really needed for localnet ports. 2) When there are ARP requests from vlan network (e.g. from a BM) to logical router interface IP, the ARP request will reach every HV through the localnet port and the distributed logical router port will respond from every HV. Shall we disable ARP response from logical router for requests from localnet port? In this scenario, I would expect the BM/SRIOV VMs on the same vlan to use a different GW rather than the logical router. How will north/south traffic work? Distributed gateway ports limit ARP responses so that only one instance of the distributed gateway port on one chassis responds. At the moment distributed gateway ports only allow direct traffic (without going through the central node) for 1:1 NAT with logical_port and external_mac specified. This is because of the implications of upstream L2 learning, and lack of a routing protocol. If there are mechanisms that allow things on the outside to know which chassis to forward traffic to, then this can be relaxed. This is controlled by the gw_redirect table. Mickey 3) We need to add a restriction/validation so that the localnet connection is used only we are sure the 2 logical switches are on the same "physical network", e.g. different vlans under same physical bridge group, or a virtual L2 bridge group formed by vtep overlays. Thanks, Han On Tue, Jun 27, 2017 at 10:00 AM, Han Zhou <zhou...@gmail.com> wrote: > It is not about limit but more about use case. Could you explain your use > case why using localnet ports here while the VMs can be connected through > logical router on overlay? Did my patch work for you? Does it work also > when you remove the localnet ports? > > Mickey mentioned scenarios when a combination of localnet ports and > logical router is valid, which are for gateway use cases, and it seems to > me that is not your case cause you are just try to connect two VMs. > > Han > > > On Tue, Jun 27, 2017 at 2:32 AM, <wang.qia...@zte.com.cn> wrote: > >> Hi Han Zhou, >> >> > If using localnet, it should rely on physical network (L2 and L3) to >> reach the destination, not overlay, so adding the logical router here >> doesn't make sense here >> >> Why ovn have this limit for physical network? Does this mean that vlan >> network can not use the l3 function of ovn? >> >> Thanks >> >> >> >> *Han Zhou <zhou...@gmail.com <zhou...@gmail.com>>* >> >> 2017/06/27 16:24 >> >> 收件人: wang.qia...@zte.com.cn, >> 抄送: Russell Bryant <russ...@ovn.org>, ovs dev < >> d...@openvswitch.org>, zhou.huij...@zte.com.cn, xurong00037997 < >> xu.r...@zte.com.cn> >> 主题: Re: [ovs-dev] 答复: [spam可疑邮件]Re: 答复: Re: [PATCH 2/2] >> ovn-northd: Fix ping failure of vlan networks. >> >> >> >> >> >> On Thu, Jun 15, 2017 at 1:04 AM, <*wang.qia...@zte.com.cn* >> <wang.qia...@zte.com.cn>> wrote: >> > >> > Hi Russell, I am sorry for the late reply. >> > The route not bound to a chassis, and have no redirect-chassis. The >> dumped >> > northbound db is as follow. >> > Ip addresses of 100.0.0.148 and 200.0.0.2 locate on different chassis. >> The >> > ping between them is not success before this patch. >> > >> > >> > [root@tecs159 ~]# >> > [root@tecs159 ~]# ovsdb-client dump >> > unix:/var/run/openvswitch/ovnnb_db.sock >> > ACL table >> > _uuid action direction >> external_ids >> > log match priority >> > ------------------------------------ ------------- ---------- >> > -------------------------------------------------------- ----- >> > ------------------------------------------------------------ >> ------------------------------------------------------------ >> -------------------------- >> > -------- >> > ac2900f9-49fd-430a-b646-88d1f7c54ab8 allow from-lport >> > {"neutron:lport"="1ef52eb4-1f0e-416d-8dc2-e2fc7557979c"} false "inport >> == >> > \"1ef52eb4-1f0e-416d-8dc2-e2fc7557979c\" && ip4 && ip4.dst == >> > {255.255.255.255, *100.0.0.0/24* <http://100.0.0.0/24>} && udp && >> udp.src == 68 && udp.dst == 67" >> > 1002 >> > 784a55c3-05fd-4c4d-a51e-5b9ee5cc1e8e allow from-lport >> > {"neutron:lport"="6c04e45e-ad83-4cf0-ae74-84f7720a5bc4"} false "inport >> == >> > \"6c04e45e-ad83-4cf0-ae74-84f7720a5bc4\" && ip4 && ip4.dst == >> > {255.255.255.255, *100.0.0.0/24* <http://100.0.0.0/24>} && udp && >> udp.src == 68 && udp.dst == 67" >> > 1002 >> > 08be2532-f8ff-493f-83e3-085eede36e08 allow from-lport >> > {"neutron:lport"="c5ff4f7b-bd0d-4757-ac18-636f9d62b94c"} false "inport >> == >> > \"c5ff4f7b-bd0d-4757-ac18-636f9d62b94c\" && ip4 && ip4.dst == >> > {255.255.255.255, *100.0.0.0/24* <http://100.0.0.0/24>} && udp && >> udp.src == 68 && udp.dst == 67" >> > 1002 >> > bb263947-a436-4a0d-9218-5abd89546a69 allow from-lport >> > {"neutron:lport"="f8de0603-f4ec-4546-a8f3-574640f270e8"} false "inport >> == >> > \"f8de0603-f4ec-4546-a8f3-574640f270e8\" && ip4 && ip4.dst == >> > {255.255.255.255, *200.0.0.0/24* <http://200.0.0.0/24>} && udp && >> udp.src == 68 && udp.dst == 67" >> > 1002 >> > 092964cc-2ce5-4a34-b747-558006bb3de1 allow-related from-lport >> > {"neutron:lport"="1ef52eb4-1f0e-416d-8dc2-e2fc7557979c"} false "inport >> == >> > \"1ef52eb4-1f0e-416d-8dc2-e2fc7557979c\" && ip4" 1002 >> > 5f2ebb8e-edbc-40aa-ada6-2fc90fc104af allow-related from-lport >> > {"neutron:lport"="1ef52eb4-1f0e-416d-8dc2-e2fc7557979c"} false "inport >> == >> > \"1ef52eb4-1f0e-416d-8dc2-e2fc7557979c\" && ip6" 1002 >> > 13d32fab-0ed7-4472-97c2-1e3057eaca6e allow-related from-lport >> > {"neutron:lport"="6c04e45e-ad83-4cf0-ae74-84f7720a5bc4"} false "inport >> == >> > \"6c04e45e-ad83-4cf0-ae74-84f7720a5bc4\" && ip4" 1002 >> > 7fa4e0b0-ffce-436f-a20a-07b0584c3285 allow-related from-lport >> > {"neutron:lport"="6c04e45e-ad83-4cf0-ae74-84f7720a5bc4"} false "inport >> == >> > \"6c04e45e-ad83-4cf0-ae74-84f7720a5bc4\" && ip6" 1002 >> > b32cf462-a8e5-4597-9c6e-4dc02ae2e2c4 allow-related from-lport >> > {"neutron:lport"="c5ff4f7b-bd0d-4757-ac18-636f9d62b94c"} false "inport >> == >> > \"c5ff4f7b-bd0d-4757-ac18-636f9d62b94c\" && ip4" 1002 >> > 4d003f24-f546-49fa-a33c-92384e4d3549 allow-related from-lport >> > {"neutron:lport"="c5ff4f7b-bd0d-4757-ac18-636f9d62b94c"} false "inport >> == >> > \"c5ff4f7b-bd0d-4757-ac18-636f9d62b94c\" && ip6" 1002 >> > 7078873a-fa44-4c64-be7f-067d19361fb4 allow-related from-lport >> > {"neutron:lport"="f8de0603-f4ec-4546-a8f3-574640f270e8"} false "inport >> == >> > \"f8de0603-f4ec-4546-a8f3-574640f270e8\" && ip4" 1002 >> > a15bd032-9755-45a5-b7ea-9687b9d14560 allow-related from-lport >> > {"neutron:lport"="f8de0603-f4ec-4546-a8f3-574640f270e8"} false "inport >> == >> > \"f8de0603-f4ec-4546-a8f3-574640f270e8\" && ip6" 1002 >> > 4ace5b98-e6dd-467c-a7cf-af5e76a258f5 allow-related to-lport >> > {"neutron:lport"="1ef52eb4-1f0e-416d-8dc2-e2fc7557979c"} false >> "outport == >> > \"1ef52eb4-1f0e-416d-8dc2-e2fc7557979c\" && ip4 && ip4.src == >> > $as_ip4_539bd583_ca35_4ae7_9774_299fd56765ef" 1002 >> > 6e3453ee-a717-49fe-8160-ab304daa7bd8 allow-related to-lport >> > {"neutron:lport"="1ef52eb4-1f0e-416d-8dc2-e2fc7557979c"} false >> "outport == >> > \"1ef52eb4-1f0e-416d-8dc2-e2fc7557979c\" && ip6 && ip6.src == >> > $as_ip6_539bd583_ca35_4ae7_9774_299fd56765ef" 1002 >> > cc1b88c5-e9d7-42fe-8e17-deb2fbc7c7a2 allow-related to-lport >> > {"neutron:lport"="6c04e45e-ad83-4cf0-ae74-84f7720a5bc4"} false >> "outport == >> > \"6c04e45e-ad83-4cf0-ae74-84f7720a5bc4\" && ip4 && ip4.src == >> > $as_ip4_539bd583_ca35_4ae7_9774_299fd56765ef" 1002 >> > ecb2798f-4a87-4260-b9a8-3cdea1eca638 allow-related to-lport >> > {"neutron:lport"="6c04e45e-ad83-4cf0-ae74-84f7720a5bc4"} false >> "outport == >> > \"6c04e45e-ad83-4cf0-ae74-84f7720a5bc4\" && ip6 && ip6.src == >> > $as_ip6_539bd583_ca35_4ae7_9774_299fd56765ef" 1002 >> > 71c56144-3b95-454a-acb4-67cd924dff08 allow-related to-lport >> > {"neutron:lport"="c5ff4f7b-bd0d-4757-ac18-636f9d62b94c"} false >> "outport == >> > \"c5ff4f7b-bd0d-4757-ac18-636f9d62b94c\" && ip4 && ip4.src == >> > $as_ip4_539bd583_ca35_4ae7_9774_299fd56765ef" 1002 >> > 15766592-aa79-465b-8935-bbc916692b75 allow-related to-lport >> > {"neutron:lport"="c5ff4f7b-bd0d-4757-ac18-636f9d62b94c"} false >> "outport == >> > \"c5ff4f7b-bd0d-4757-ac18-636f9d62b94c\" && ip6 && ip6.src == >> > $as_ip6_539bd583_ca35_4ae7_9774_299fd56765ef" 1002 >> > 5c6a9b01-ade0-4b6c-8a1e-2fe0155bdf7d allow-related to-lport >> > {"neutron:lport"="f8de0603-f4ec-4546-a8f3-574640f270e8"} false >> "outport == >> > \"f8de0603-f4ec-4546-a8f3-574640f270e8\" && ip4 && ip4.src == >> > $as_ip4_539bd583_ca35_4ae7_9774_299fd56765ef" 1002 >> > 4e0d6019-7801-4537-883b-aebeae1ab136 allow-related to-lport >> > {"neutron:lport"="f8de0603-f4ec-4546-a8f3-574640f270e8"} false >> "outport == >> > \"f8de0603-f4ec-4546-a8f3-574640f270e8\" && ip6 && ip6.src == >> > $as_ip6_539bd583_ca35_4ae7_9774_299fd56765ef" 1002 >> > 54c72e2f-26b9-433c-968e-8e9b86379dfb drop from-lport >> > {"neutron:lport"="1ef52eb4-1f0e-416d-8dc2-e2fc7557979c"} false "inport >> == >> > \"1ef52eb4-1f0e-416d-8dc2-e2fc7557979c\" && ip" 1001 >> > 2fc107d5-f809-4719-a84c-078add4844b0 drop from-lport >> > {"neutron:lport"="6c04e45e-ad83-4cf0-ae74-84f7720a5bc4"} false "inport >> == >> > \"6c04e45e-ad83-4cf0-ae74-84f7720a5bc4\" && ip" 1001 >> > 32d170f3-af0e-451a-9557-4ba1ff168fab drop from-lport >> > {"neutron:lport"="c5ff4f7b-bd0d-4757-ac18-636f9d62b94c"} false "inport >> == >> > \"c5ff4f7b-bd0d-4757-ac18-636f9d62b94c\" && ip" 1001 >> > d579d231-06c9-4b14-b744-760937f824a7 drop from-lport >> > {"neutron:lport"="f8de0603-f4ec-4546-a8f3-574640f270e8"} false "inport >> == >> > \"f8de0603-f4ec-4546-a8f3-574640f270e8\" && ip" 1001 >> > f7eca2db-82ca-43bd-b8cb-778ecbc6e75b drop to-lport >> > {"neutron:lport"="1ef52eb4-1f0e-416d-8dc2-e2fc7557979c"} false >> "outport == >> > \"1ef52eb4-1f0e-416d-8dc2-e2fc7557979c\" && ip" 1001 >> > 6bd4c9a2-15a0-498b-aa3d-29ed5c041427 drop to-lport >> > {"neutron:lport"="6c04e45e-ad83-4cf0-ae74-84f7720a5bc4"} false >> "outport == >> > \"6c04e45e-ad83-4cf0-ae74-84f7720a5bc4\" && ip" 1001 >> > 9d7efb59-90f2-469d-9550-1e8a906d59e8 drop to-lport >> > {"neutron:lport"="c5ff4f7b-bd0d-4757-ac18-636f9d62b94c"} false >> "outport == >> > \"c5ff4f7b-bd0d-4757-ac18-636f9d62b94c\" && ip" 1001 >> > 10bbc3ba-a5bb-4441-b789-d95158588d96 drop to-lport >> > {"neutron:lport"="f8de0603-f4ec-4546-a8f3-574640f270e8"} false >> "outport == >> > \"f8de0603-f4ec-4546-a8f3-574640f270e8\" && ip" 1001 >> > >> > Address_Set table >> > _uuid addresses external_ids name >> > ------------------------------------ >> > ---------------------------------------------------------- >> > --------------------------------------- >> > --------------------------------------------- >> > dcea33b7-7313-41bb-813c-06d8b9634a7d [] >> > {"neutron:security_group_name"=default} >> > "as_ip4_1a91f4e0_8a0f_4c18_9122_dae1179297c3" >> > 33f542ff-ec0c-4b79-bd9f-9bf38d3721e3 [] >> > {"neutron:security_group_name"=default} >> > "as_ip6_1a91f4e0_8a0f_4c18_9122_dae1179297c3" >> > 062f417a-84f0-488a-947b-eb20127be8ed [] >> > {"neutron:security_group_name"=default} >> > "as_ip6_539bd583_ca35_4ae7_9774_299fd56765ef" >> > 7f8e253a-a937-4557-b976-a62c7b2c62c5 ["100.0.0.147", "100.0.0.148", >> > "100.0.0.149", "200.0.0.2"] {"neutron:security_group_name"=default} >> > "as_ip4_539bd583_ca35_4ae7_9774_299fd56765ef" >> > >> > Connection table >> > _uuid external_ids inactivity_probe is_connected max_backoff >> other_config >> > status target >> > ----- ------------ ---------------- ------------ ----------- >> ------------ >> > ------ ------ >> > >> > DHCP_Options table >> > _uuid cidr external_ids >> > options >> > ------------------------------------ -------------- >> > -------------------------------------------------- >> > ------------------------------------------------------------ >> ----------------------------------------------- >> > b55e7e0b-b26e-4895-a112-7ba15cfc4ebb "*100.0.0.0/24* >> <http://100.0.0.0/24>" >> > {subnet_id="2b218dec-7f3d-4e8b-8c3e-8761203a989f"} {lease_time="43200", >> > mtu="1500", router="100.0.0.1", server_id="100.0.0.1", >> > server_mac="fa:16:3e:86:32:cd"} >> > 06c44867-2b2f-417d-8232-afab999eed1a "*200.0.0.0/24* >> <http://200.0.0.0/24>" >> > {subnet_id="8a50258b-cbbf-4099-9275-dccebfd23762"} {lease_time="43200", >> > mtu="1500", router="200.0.0.1", server_id="200.0.0.1", >> > server_mac="fa:16:3e:12:25:dc"} >> > >> > Load_Balancer table >> > _uuid external_ids name protocol vips >> > ----- ------------ ---- -------- ---- >> > >> > Logical_Router table >> > _uuid enabled external_ids load_balancer >> > name nat options ports >> > static_routes >> > ------------------------------------ ------- >> > --------------------------------- ------------- >> > ---------------------------------------------- --- ------- >> > ------------------------------------------------------------ >> ---------------- >> > ------------- >> > c96ff734-590b-496c-8955-076c8ec524ab true >> > {"neutron:router_name"="router1"} [] >> > "neutron-5ba0b278-d35b-40d6-85a7-1e527576b085" [] {} >> > [5d9b823f-a9f1-4d85-bf15-da392cecebca, >> > 97c1b867-1f0c-4865-a58b-21b8a84f3758] [] >> > >> > Logical_Router_Port table >> > _uuid enabled external_ids mac name >> > networks options peer >> > ------------------------------------ ------- ------------ >> > ------------------- ------------------------------------------ >> > ---------------- ------- ---- >> > 97c1b867-1f0c-4865-a58b-21b8a84f3758 [] {} "fa:16:3e:79:7b:06" >> > "lrp-a794083d-c374-46ac-b246-23568235fea1" ["*200.0.0.1/24* >> <http://200.0.0.1/24>"] {} [] >> > 5d9b823f-a9f1-4d85-bf15-da392cecebca [] {} "fa:16:3e:d1:71:75" >> > "lrp-88561050-51c2-4585-936a-05eba5dba19a" ["*100.0.0.1/24* >> <http://100.0.0.1/24>"] {} [] >> > >> > Logical_Router_Static_Route table >> > _uuid ip_prefix nexthop output_port policy >> > ----- --------- ------- ----------- ------ >> > >> > Logical_Switch table >> > _uuid acls >> > external_ids >> > load_balancer name >> other_config >> > ports qos_rules >> > ------------------------------------ >> > ------------------------------------------------------------ >> ------------------------------------------------------------ >> ------------------------------------------------------------ >> ------------------------------------------------------------ >> ------------------------------------------------------------ >> ------------------------------------------------------------ >> ------------------------------------------------------------ >> ------------------------------------------------------------ >> ------------------------------------------------------------ >> ------------------------------------------------------------ >> ------------------------------------------------------------ >> ------------------------------------------------------------ >> ------------------------------------------------------------ >> ------------------ >> > ----------------------------------- ------------- >> > ---------------------------------------------- ------------ >> > ------------------------------------------------------------ >> ------------------------------------------------------------ >> ------------------------------------------------------------ >> ------------------------------------------------ >> > --------- >> > 616e6c26-4dda-46de-9ceb-96008db3478a >> > [10bbc3ba-a5bb-4441-b789-d95158588d96, >> > 4e0d6019-7801-4537-883b-aebeae1ab136, >> > 5c6a9b01-ade0-4b6c-8a1e-2fe0155bdf7d, >> > 7078873a-fa44-4c64-be7f-067d19361fb4, >> > a15bd032-9755-45a5-b7ea-9687b9d14560, >> > bb263947-a436-4a0d-9218-5abd89546a69, >> > d579d231-06c9-4b14-b744-760937f824a7] >> > {"neutron:network_name"="vlan-200"} [] >> > "neutron-f0e1df21-1a76-46d6-a92b-1ab17ba3ba68" {} >> > [3a513f49-50fb-44f2-8de1-1ee063f38f52, >> > 7692e68e-7f37-4d25-81aa-14fbd8a6eb3c, >> > c13df760-1a00-4948-848e-00f14c79b3d4] [] >> > 5f7e8ce5-486b-4273-86aa-971b1cbe5e93 >> > [08be2532-f8ff-493f-83e3-085eede36e08, >> > 092964cc-2ce5-4a34-b747-558006bb3de1, >> > 13d32fab-0ed7-4472-97c2-1e3057eaca6e, >> > 15766592-aa79-465b-8935-bbc916692b75, >> > 2fc107d5-f809-4719-a84c-078add4844b0, >> > 32d170f3-af0e-451a-9557-4ba1ff168fab, >> > 4ace5b98-e6dd-467c-a7cf-af5e76a258f5, >> > 4d003f24-f546-49fa-a33c-92384e4d3549, >> > 54c72e2f-26b9-433c-968e-8e9b86379dfb, >> > 5f2ebb8e-edbc-40aa-ada6-2fc90fc104af, >> > 6bd4c9a2-15a0-498b-aa3d-29ed5c041427, >> > 6e3453ee-a717-49fe-8160-ab304daa7bd8, >> > 71c56144-3b95-454a-acb4-67cd924dff08, >> > 784a55c3-05fd-4c4d-a51e-5b9ee5cc1e8e, >> > 7fa4e0b0-ffce-436f-a20a-07b0584c3285, >> > 9d7efb59-90f2-469d-9550-1e8a906d59e8, >> > ac2900f9-49fd-430a-b646-88d1f7c54ab8, >> > b32cf462-a8e5-4597-9c6e-4dc02ae2e2c4, >> > cc1b88c5-e9d7-42fe-8e17-deb2fbc7c7a2, >> > ecb2798f-4a87-4260-b9a8-3cdea1eca638, >> > f7eca2db-82ca-43bd-b8cb-778ecbc6e75b] {"neutron:network_name"="vlan1 >> 00"} >> > [] "neutron-47b88d0c-71e8-4129-b091-faccd9665fd5" {} >> > [1eed33cc-5599-4d11-8f33-04c3302e4719, >> > 34282540-5c2b-4a20-9d29-9180c15e5fc2, >> > 3ef7cbaa-b602-496d-8ecd-d17433b3d73d, >> > 87d8a014-22d7-4992-8446-749f2b3705ef, >> > bd2f11ba-49ef-40f8-b576-87d0b8ec1b87, >> > faf8deeb-8f05-4af1-91de-3316f9467959] [] >> > >> > Logical_Switch_Port table >> > _uuid addresses dhcpv4_options >> > dhcpv6_options dynamic_addresses enabled external_ids name >> > options parent_name >> > port_security tag tag_request type up >> > ------------------------------------ --------------------------------- >> > ------------------------------------ -------------- ----------------- >> > ------- -------------------------------------- >> > ---------------------------------------------- >> > -------------------------------------------------------- ----------- >> > ------------- --- ----------- -------- ----- >> > 3ef7cbaa-b602-496d-8ecd-d17433b3d73d ["fa:16:3e:36:41:6e 100.0.0.148"] >> > b55e7e0b-b26e-4895-a112-7ba15cfc4ebb [] [] >> true >> > {"neutron:port_name"=""} "c5ff4f7b-bd0d-4757-ac18-636f9d62b94c" {} >> > [] [] [] [] "" >> > true >> > 1eed33cc-5599-4d11-8f33-04c3302e4719 ["fa:16:3e:66:98:cd 100.0.0.147"] >> > b55e7e0b-b26e-4895-a112-7ba15cfc4ebb [] [] >> true >> > {"neutron:port_name"="port-pci-100-1"} >> > "6c04e45e-ad83-4cf0-ae74-84f7720a5bc4" {} [] [] >> [] >> > [] "" false >> > 87d8a014-22d7-4992-8446-749f2b3705ef ["fa:16:3e:73:c8:95 100.0.0.146"] >> [] >> > [] [] true >> > {"neutron:port_name"=""} "ed3a389a-af88-4234-a30f-749c45d8805d" >> {} >> > [] [] [] >> > [] "" false >> > 7692e68e-7f37-4d25-81aa-14fbd8a6eb3c ["fa:16:3e:e7:1d:3c 200.0.0.2"] >> > 06c44867-2b2f-417d-8232-afab999eed1a [] [] >> true >> > {"neutron:port_name"=""} "f8de0603-f4ec-4546-a8f3-574640f270e8" {} >> > [] [] [] [] "" >> > true >> > bd2f11ba-49ef-40f8-b576-87d0b8ec1b87 ["fa:16:3e:fc:de:db 100.0.0.149"] >> > b55e7e0b-b26e-4895-a112-7ba15cfc4ebb [] [] >> true >> > {"neutron:port_name"=""} "1ef52eb4-1f0e-416d-8dc2-e2fc7557979c" {} >> > [] [] [] [] "" >> > true >> > faf8deeb-8f05-4af1-91de-3316f9467959 [router] >> [] >> > [] [] true >> > {"neutron:port_name"=""} "88561050-51c2-4585-936a-05eba5dba19a" >> > {router-port="lrp-88561050-51c2-4585-936a-05eba5dba19a"} [] [] >> > [] [] router false >> > 3a513f49-50fb-44f2-8de1-1ee063f38f52 [router] >> [] >> > [] [] true >> > {"neutron:port_name"=""} "a794083d-c374-46ac-b246-23568235fea1" >> > {router-port="lrp-a794083d-c374-46ac-b246-23568235fea1"} [] [] >> > [] [] router false >> > 34282540-5c2b-4a20-9d29-9180c15e5fc2 [unknown] >> [] >> > [] [] [] {} >> > "provnet-47b88d0c-71e8-4129-b091-faccd9665fd5" >> > {network_name="physnet1"} [] [] >> > 100 [] localnet false >> > c13df760-1a00-4948-848e-00f14c79b3d4 [unknown] >> [] >> > [] [] [] {} >> > "provnet-f0e1df21-1a76-46d6-a92b-1ab17ba3ba68" >> > {network_name="physnet1"} [] [] >> > 200 [] localnet false >> > >> > NAT table >> > _uuid external_ip external_mac logical_ip logical_port type >> > ----- ----------- ------------ ---------- ------------ ---- >> > >> > NB_Global table >> > _uuid connections external_ids hv_cfg >> > nb_cfg sb_cfg ssl >> > ------------------------------------ ----------- ------------ ------ >> > ------ ------ --- >> > fcf4effb-eff7-4401-8727-03864c363477 [] {} 0 0 >> 0 >> > [] >> > >> > QoS table >> > _uuid action direction external_ids match priority >> > ----- ------ --------- ------------ ----- -------- >> > >> > SSL table >> > _uuid bootstrap_ca_cert ca_cert certificate external_ids private_key >> > ----- ----------------- ------- ----------- ------------ ----------- >> > [root@tecs159 ~]# >> > >> > >> > >> Here you have both logical router and localnet ports, which doesn't seems >> to make sense. The 2 VMs are on different vlan, which are not supposed to >> be able to communicate with localnet port. However, it reveals a bug >> introduced by recursive local-datapath filling, which is fixed in [1]. >> Because of this bug, VM1 is talking to VM2 directly using net2's localnet >> port which tags VLAN2 directly. It is also the reason why CT didn't work. >> Please try the patch [1] to see if it fixes the problem (it will not use >> localnet port but overlay tunnel to reach the destination). >> >> Regarding your configuration itself, localnet is for physical/provider >> network. If using localnet, it should rely on physical network (L2 and L3) >> to reach the destination, not overlay, so adding the logical router here >> doesn't make sense here. Since these 2 VMs are on different VLANs, the >> expected way for them to communicate is through external routers that >> connects these 2 VLANs. >> >> Alternatively, if these 2 HVs are L3 connected, you can use overlay >> logical router to connect the 2 logical switches, and then the localnet >> ports should not be created. >> >> [1] >> *https://mail.openvswitch.org/pipermail/ovs-dev/2017-June/334633.html* >> <https://mail.openvswitch.org/pipermail/ovs-dev/2017-June/334633.html> >> >> Thanks, >> Han >> >> > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev