Hello Daniel, When I tried to configure vxlan routes I had mentioned I was seeing errors, when I checked log files under /var/log/openvswitch there is no information...
-rw-r----- 1 root adm 0 Oct 17 06:25 ovs-vswitchd.log -rw-r----- 1 root adm 536 Oct 17 12:32 ovsdb-server.log cat ovsdb-server.log 2018-10-17T12:26:46.865Z|00001|vlog|INFO|opened log file /var/log/openvswitch/ovsdb-server.log 2018-10-17T12:26:47.185Z|00002|ovsdb_server|INFO|ovsdb-server (Open vSwitch) 2.10.0 2018-10-17T12:26:47.334Z|00003|fatal_signal|WARN|terminating with signal 15 (Terminated) 2018-10-17T12:32:25.971Z|00001|vlog|INFO|opened log file /var/log/openvswitch/ovsdb-server.log 2018-10-17T12:32:26.663Z|00002|ovsdb_server|INFO|ovsdb-server (Open vSwitch) 2.10.0 2018-10-17T12:32:26.783Z|00003|fatal_signal|WARN|terminating with signal 15 (Terminated) ~ Link http://docs.openvswitch.org/en/latest/howto/userspace-tunneling/ doesn't mention which version of OVS was tested, looks like it is part of 2.10.90? Should I download latest code for this? Thanks On Sun, Oct 14, 2018 at 7:51 AM Ravi Kerur <[email protected]> wrote: > Hello Daniel, > > Thank you for your quick response and explanation on br-phy to br-int. I > will gather debug logs and update. > > Thanks. > Ravi > > On Sun, Oct 14, 2018 at 6:19 AM benli ye <[email protected]> wrote: > >> Hi Ravi, >> >> Let me try to answer your question. >> (1) For the first one: I believe NORMAL action can lead the packet to >> tunnel port. >> (2) For how packets flow from br-phy to br-int, You can search code >> “terminate_native_tunnel()” in ofproto-dpif-xlate.c. >> When it generates datapath flow for an incoming tunnel packet, a >> OVS_ACTION_ATTR_TUNNEL_POP is inserted in the actions. >> When the encapsulated packet hit OVS_ACTION_ATTR_TUNNEL_POP action, >> it will be handled to tunnel port on br-int as a re-injected packet. >> Then tunnel headers can be split and delivered to corresponding >> interface in br-int. When packet sent out from br-int to br-phy, it will >> hit the tnl_push action which >> is added when computing output action (see native_tunnel_output()), >> then it will use the route you added to send the encapsulated packet from >> br-phy interface. >> (3) That’s a historic issue as it copied from an original guide. I >> believe your assumption is right. >> (4) I don’t try this command, I think more log information in >> /var/log/openvswitch may be helpful. Hope someone have this answer. >> >> Thanks, >> Daniel Benli Ye >> >> > On Oct 14, 2018, at 8:55 PM, Ravi Kerur <[email protected]> wrote: >> > >> > Hi, >> > >> > I am going through following link and setting up the testbed >> > >> > http://docs.openvswitch.org/en/latest/howto/userspace-tunneling/ >> > >> > and it is very confusing to me at least. Can someone please clarify >> > following questions? >> > >> > (1) I believe flows needs to be programmed on br-int bridge with >> > in_port=vm_port0, out_port=vxlan0, vice-versa. When bridge is created it >> > has a default flow with NORMAL action, i don't think this suffices? >> > >> > (2) How do packets flow from br-int to br-phy and br-phy to br-int? >> > >> > (3) Link says add following route >> > >> > "ovs-appctl ovs/route/add 172.168.1.1/24 br-eth1" >> > >> > What is br-eth1? I don't see anything about it in the link? >> > >> > (4) Assuming br-eth1 is br-phy, I tried to add route on the testbed I >> > am configuring I get >> > >> > ovs-appctl ovs/route/add 11.11.11.4/32 br1-phy >> > Error while inserting route. >> > ovs-appctl: ovs-vswitchd: server returned an error >> > >> > Thanks. >> > _______________________________________________ >> > dev mailing list >> > [email protected] >> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev >> >> _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
