[ovs-discuss] 答复: [ovn] Can we use LB for distributed router?
Hi, Thanks. But I am still confused by section Logical_Router TABLE in http://www.openvswitch.org/support/dist-docs/ovn-nb.5.html It tells that load_balancer: set of Load_Balancers Load balance a virtual ip address to a set of logical port ip addresses. Load balancer rules only work on the Gateway routers. On Wed, Oct 28, 2020 at 4:42 PM Guoyong wrote: > > I heard a comment that we cannot use LB for distributed router. Is it true? You can associate a load balancer to a distrubuted logical router. If you want to load balance a floating ip/external ip to OVN internal IPs, then the distributed router should have a gateway router port so that DNAT on the LB VIP is done on the gateway chassis which has claimed the gateway router port. Thanks Numan > > > > https://blog.spinhirne.com/posts/an-introduction-to-ovn/the-ovn-load-b > alancer/ > > > > -- > --- > 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 > 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 > 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 > 邮件！ > This e-mail and its attachments contain confidential information from > New H3C, which is intended only for the person or entity whose address > is listed above. Any use of the information contained herein in any > way (including, but not limited to, total or partial disclosure, > reproduction, or dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in error, > please notify the sender by phone or email immediately and delete it! > ___ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [ovs-dev] [ovn] no tunnel from GW to compute
Thanks Numan for the hint! I thought it's about OF flow and DP flow. Didn't realize the problem could be in upstream. I checked NB DB and found a LRP leftover from previous deletion. Someone was testing a deployment with network and VMs. They destroy and recreate the deployment back-to-back. It's likely some issue in Neutron OVN ML2 driver who is responsible for programming NB DB. Somehow, the driver didn't have a chance to completely finish the deletion while start the new creation. I manually delete that stale LRP, everything starts working fine. Tony > -Original Message- > From: Numan Siddique > Sent: Wednesday, October 28, 2020 1:56 AM > To: Tony Liu > Cc: ovs-discuss ; ovs-dev d...@openvswitch.org> > Subject: Re: [ovs-dev] [ovn] no tunnel from GW to compute > > On Wed, Oct 28, 2020 at 11:29 AM Tony Liu > wrote: > > > > Checked OF flows for working and non-working FIPs, can't find any > > difference. DF flow is installed by vswitchd based on OF flow when > > processing the first packet. I enabled debug logging, no log for > > working FIP, a few logs for non-working FIP. Does that mean something > > wrong about non-working FIP? > > Could you share your OVN NB DB ? or ovn-nbctl commands to create the > resources so that I can try it out locally ? > > Thanks > Numan > > > == > > 2020-10-28T05:15:22.058Z|01203|dpif(handler8)|DBG|system@ovs-system: > miss upcall: > > recirc_id(0),dp_hash(0),skb_priority(0),in_port(4),skb_mark(0),ct_stat > > e(0),ct_zone(0),ct_mark(0),ct_label(0),eth(src=e8:1c:ba:9f:b7:c6,dst=f > > a:16:3e:45:da:61),eth_type(0x0800),ipv4(src=172.16.160.1,dst=10.59.53. > > 8,proto=1,tos=0,ttl=125,frag=no),icmp(type=8,code=0) > > icmp,vlan_tci=0x,dl_src=e8:1c:ba:9f:b7:c6,dl_dst=fa:16:3e:45:da:61 > > ,nw_src=172.16.160.1,nw_dst=10.59.53.8,nw_tos=0,nw_ecn=0,nw_ttl=125,ic > mp_type=8,icmp_code=0 icmp_csum:6013 .. > > 2020-10-28T05:15:22.059Z|00808|vconn|DBG|unix#1: sent (Success): > > NXT_PACKET_IN2 (OF1.3) (xid=0x0): table_id=24 cookie=0x9173f925 > > total_len=74 > > ct_state=new|trk|dnat,ct_zone=507,ct_nw_src=172.16.160.1,ct_nw_dst=10. > > 59.53.8,ct_nw_proto=1,ct_tp_src=8,ct_tp_dst=0,ip,reg0=0xa0a000a,reg1=0 > > xa0a0001,reg9=0x8,reg10=0x1,reg11=0x1fb,reg12=0x1fa,reg14=0x1,reg15=0x > > 7,metadata=0x121,in_port=1 (via action) data_len=74 (unbuffered) > > > > userdata=00.00.00.00.00.00.00.00.00.19.00.10.80.00.06.06.ff.ff.ff.ff.f > > f.ff.00.00.ff.ff.00.18.00.00.23.20.00.06.00.20.00.40.00.00.00.01.de.10 > > .00.00.20.04.ff.ff.00.18.00.00.23.20.00.06.00.20.00.60.00.00.00.01.de. > > 10.00.00.22.04.00.19.00.10.80.00.2a.02.00.01.00.00.00.00.00.00.ff.ff.0 > > 0.10.00.00.23.20.00.0e.ff.f8.20.00.00.00 > > icmp,vlan_tci=0x,dl_src=fa:16:3e:93:f4:1e,dl_dst=00:00:00:00:00:00 > > ,nw_src=172.16.160.1,nw_dst=10.10.0.10,nw_tos=0,nw_ecn=0,nw_ttl=124,ic > > mp_type=8,icmp_code=0 icmp_csum:6013 > > > > .. > > 2020-10-28T05:15:27.060Z|01102|dpif(handler10)|DBG|system@ovs-system: > action upcall: > > recirc_id(0x3ad25),dp_hash(0),skb_priority(0),in_port(4),skb_mark(0),c > > t_state(0xa1),ct_zone(0x1fb),ct_mark(0),ct_label(0),ct_tuple4(src=172. > > 16.160.1,dst=10.59.53.8,proto=1,tp_src=8,tp_dst=0),eth(src=fa:16:3e:93 > > :f4:1e,dst=00:00:00:00:00:00),eth_type(0x0800),ipv4(src=172.16.160.1,d > > st=10.10.0.10,proto=1,tos=0,ttl=124,frag=no),icmp(type=8,code=0) > > icmp,vlan_tci=0x,dl_src=fa:16:3e:93:f4:1e,dl_dst=00:00:00:00:00:00 > > ,nw_src=172.16.160.1,nw_dst=10.10.0.10,nw_tos=0,nw_ecn=0,nw_ttl=124,ic > mp_type=8,icmp_code=0 icmp_csum:6012 .. > > 2020-10-28T05:15:27.061Z|00834|vconn|DBG|unix#1: sent (Success): > > NXT_PACKET_IN2 (OF1.3) (xid=0x0): table_id=24 cookie=0x9173f925 > > total_len=74 > > ct_state=new|trk|dnat,ct_zone=507,ct_nw_src=172.16.160.1,ct_nw_dst=10. > > 59.53.8,ct_nw_proto=1,ct_tp_src=8,ct_tp_dst=0,ip,reg0=0xa0a000a,reg1=0 > > xa0a0001,reg9=0x8,reg10=0x1,reg11=0x1fb,reg12=0x1fa,reg14=0x1,reg15=0x > > 7,metadata=0x121,in_port=1 (via action) data_len=74 (unbuffered) > > > > userdata=00.00.00.00.00.00.00.00.00.19.00.10.80.00.06.06.ff.ff.ff.ff.f > > f.ff.00.00.ff.ff.00.18.00.00.23.20.00.06.00.20.00.40.00.00.00.01.de.10 > > .00.00.20.04.ff.ff.00.18.00.00.23.20.00.06.00.20.00.60.00.00.00.01.de. > > 10.00.00.22.04.00.19.00.10.80.00.2a.02.00.01.00.00.00.00.00.00.ff.ff.0 > > 0.10.00.00.23.20.00.0e.ff.f8.20.00.00.00 > > icmp,vlan_tci=0x,dl_src=fa:16:3e:93:f4:1e,dl_dst=00:00:00:00:00:00 > > ,nw_src=172.16.160.1,nw_dst=10.10.0.10,nw_tos=0,nw_ecn=0,nw_ttl=124,ic > mp_type=8,icmp_code=0 icmp_csum:6012 .. > > 2020-10-28T05:15:32.059Z|01359|dpif(handler8)|DBG|system@ovs-system: > action upcall: > > recirc_id(0x3ad25),dp_hash(0),skb_priority(0),in_port(4),skb_mark(0),c > > t_state(0xa1),ct_zone(0x1fb),ct_mark(0),ct_label(0),ct_tuple4(src=172. > > 16.160.1,dst=10.59.53.8,proto=1,tp_src=8,tp_dst=0),eth(src=fa:16:3e:93 > > :f4:1e,dst=00:00:00:00:00:00),eth_type(0x0800),ipv4(src=172.16.160.1,d > >
Re: [ovs-discuss] [ovn] Can we use LB for distributed router?
On Wed, Oct 28, 2020 at 4:42 PM Guoyong wrote: > > I heard a comment that we cannot use LB for distributed router. Is it true? You can associate a load balancer to a distrubuted logical router. If you want to load balance a floating ip/external ip to OVN internal IPs, then the distributed router should have a gateway router port so that DNAT on the LB VIP is done on the gateway chassis which has claimed the gateway router port. Thanks Numan > > > > https://blog.spinhirne.com/posts/an-introduction-to-ovn/the-ovn-load-balancer/ > > > > - > 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 > 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 > 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 > 邮件！ > This e-mail and its attachments contain confidential information from New > H3C, which is > intended only for the person or entity whose address is listed above. Any use > of the > information contained herein in any way (including, but not limited to, total > or partial > disclosure, reproduction, or dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender > by phone or email immediately and delete it! > ___ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] [ovn] Can we use LB for distributed router?
I heard a comment that we cannot use LB for distributed router. Is it true? https://blog.spinhirne.com/posts/an-introduction-to-ovn/the-ovn-load-balancer/ - ? ??? This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] guide for adding custom openflow actions
So a while back I started a project that required the implementation of new actions in ovs. Since there is no clear guide on how to do this I leave to all future developers a link to the project. There’s a guide and commented code just to serve as a way for new developers to create cool new things with ovs. https://github.com/L-Mancio/ovs Thanks to everyone who helped out with my questions in the last few months! ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [ovs-dev] [ovn] no tunnel from GW to compute
On Wed, Oct 28, 2020 at 11:29 AM Tony Liu wrote: > > Checked OF flows for working and non-working FIPs, can't find > any difference. DF flow is installed by vswitchd based on OF flow > when processing the first packet. I enabled debug logging, no log > for working FIP, a few logs for non-working FIP. Does that mean > something wrong about non-working FIP? Could you share your OVN NB DB ? or ovn-nbctl commands to create the resources so that I can try it out locally ? Thanks Numan > == > 2020-10-28T05:15:22.058Z|01203|dpif(handler8)|DBG|system@ovs-system: miss > upcall: > recirc_id(0),dp_hash(0),skb_priority(0),in_port(4),skb_mark(0),ct_state(0),ct_zone(0),ct_mark(0),ct_label(0),eth(src=e8:1c:ba:9f:b7:c6,dst=fa:16:3e:45:da:61),eth_type(0x0800),ipv4(src=172.16.160.1,dst=10.59.53.8,proto=1,tos=0,ttl=125,frag=no),icmp(type=8,code=0) > icmp,vlan_tci=0x,dl_src=e8:1c:ba:9f:b7:c6,dl_dst=fa:16:3e:45:da:61,nw_src=172.16.160.1,nw_dst=10.59.53.8,nw_tos=0,nw_ecn=0,nw_ttl=125,icmp_type=8,icmp_code=0 > icmp_csum:6013 > .. > 2020-10-28T05:15:22.059Z|00808|vconn|DBG|unix#1: sent (Success): > NXT_PACKET_IN2 (OF1.3) (xid=0x0): table_id=24 cookie=0x9173f925 total_len=74 > ct_state=new|trk|dnat,ct_zone=507,ct_nw_src=172.16.160.1,ct_nw_dst=10.59.53.8,ct_nw_proto=1,ct_tp_src=8,ct_tp_dst=0,ip,reg0=0xa0a000a,reg1=0xa0a0001,reg9=0x8,reg10=0x1,reg11=0x1fb,reg12=0x1fa,reg14=0x1,reg15=0x7,metadata=0x121,in_port=1 > (via action) data_len=74 (unbuffered) > > userdata=00.00.00.00.00.00.00.00.00.19.00.10.80.00.06.06.ff.ff.ff.ff.ff.ff.00.00.ff.ff.00.18.00.00.23.20.00.06.00.20.00.40.00.00.00.01.de.10.00.00.20.04.ff.ff.00.18.00.00.23.20.00.06.00.20.00.60.00.00.00.01.de.10.00.00.22.04.00.19.00.10.80.00.2a.02.00.01.00.00.00.00.00.00.ff.ff.00.10.00.00.23.20.00.0e.ff.f8.20.00.00.00 > icmp,vlan_tci=0x,dl_src=fa:16:3e:93:f4:1e,dl_dst=00:00:00:00:00:00,nw_src=172.16.160.1,nw_dst=10.10.0.10,nw_tos=0,nw_ecn=0,nw_ttl=124,icmp_type=8,icmp_code=0 > icmp_csum:6013 > > .. > 2020-10-28T05:15:27.060Z|01102|dpif(handler10)|DBG|system@ovs-system: action > upcall: > recirc_id(0x3ad25),dp_hash(0),skb_priority(0),in_port(4),skb_mark(0),ct_state(0xa1),ct_zone(0x1fb),ct_mark(0),ct_label(0),ct_tuple4(src=172.16.160.1,dst=10.59.53.8,proto=1,tp_src=8,tp_dst=0),eth(src=fa:16:3e:93:f4:1e,dst=00:00:00:00:00:00),eth_type(0x0800),ipv4(src=172.16.160.1,dst=10.10.0.10,proto=1,tos=0,ttl=124,frag=no),icmp(type=8,code=0) > icmp,vlan_tci=0x,dl_src=fa:16:3e:93:f4:1e,dl_dst=00:00:00:00:00:00,nw_src=172.16.160.1,nw_dst=10.10.0.10,nw_tos=0,nw_ecn=0,nw_ttl=124,icmp_type=8,icmp_code=0 > icmp_csum:6012 > .. > 2020-10-28T05:15:27.061Z|00834|vconn|DBG|unix#1: sent (Success): > NXT_PACKET_IN2 (OF1.3) (xid=0x0): table_id=24 cookie=0x9173f925 total_len=74 > ct_state=new|trk|dnat,ct_zone=507,ct_nw_src=172.16.160.1,ct_nw_dst=10.59.53.8,ct_nw_proto=1,ct_tp_src=8,ct_tp_dst=0,ip,reg0=0xa0a000a,reg1=0xa0a0001,reg9=0x8,reg10=0x1,reg11=0x1fb,reg12=0x1fa,reg14=0x1,reg15=0x7,metadata=0x121,in_port=1 > (via action) data_len=74 (unbuffered) > > userdata=00.00.00.00.00.00.00.00.00.19.00.10.80.00.06.06.ff.ff.ff.ff.ff.ff.00.00.ff.ff.00.18.00.00.23.20.00.06.00.20.00.40.00.00.00.01.de.10.00.00.20.04.ff.ff.00.18.00.00.23.20.00.06.00.20.00.60.00.00.00.01.de.10.00.00.22.04.00.19.00.10.80.00.2a.02.00.01.00.00.00.00.00.00.ff.ff.00.10.00.00.23.20.00.0e.ff.f8.20.00.00.00 > icmp,vlan_tci=0x,dl_src=fa:16:3e:93:f4:1e,dl_dst=00:00:00:00:00:00,nw_src=172.16.160.1,nw_dst=10.10.0.10,nw_tos=0,nw_ecn=0,nw_ttl=124,icmp_type=8,icmp_code=0 > icmp_csum:6012 > .. > 2020-10-28T05:15:32.059Z|01359|dpif(handler8)|DBG|system@ovs-system: action > upcall: > recirc_id(0x3ad25),dp_hash(0),skb_priority(0),in_port(4),skb_mark(0),ct_state(0xa1),ct_zone(0x1fb),ct_mark(0),ct_label(0),ct_tuple4(src=172.16.160.1,dst=10.59.53.8,proto=1,tp_src=8,tp_dst=0),eth(src=fa:16:3e:93:f4:1e,dst=00:00:00:00:00:00),eth_type(0x0800),ipv4(src=172.16.160.1,dst=10.10.0.10,proto=1,tos=0,ttl=124,frag=no),icmp(type=8,code=0) > icmp,vlan_tci=0x,dl_src=fa:16:3e:93:f4:1e,dl_dst=00:00:00:00:00:00,nw_src=172.16.160.1,nw_dst=10.10.0.10,nw_tos=0,nw_ecn=0,nw_ttl=124,icmp_type=8,icmp_code=0 > icmp_csum:6011 > .. > 2020-10-28T05:15:32.060Z|00856|vconn|DBG|unix#1: sent (Success): > NXT_PACKET_IN2 (OF1.3) (xid=0x0): table_id=24 cookie=0x9173f925 total_len=74 > ct_state=new|trk|dnat,ct_zone=507,ct_nw_src=172.16.160.1,ct_nw_dst=10.59.53.8,ct_nw_proto=1,ct_tp_src=8,ct_tp_dst=0,ip,reg0=0xa0a000a,reg1=0xa0a0001,reg9=0x8,reg10=0x1,reg11=0x1fb,reg12=0x1fa,reg14=0x1,reg15=0x7,metadata=0x121,in_port=1 > (via action) data_len=74 (unbuffered) > > userdata=00.00.00.00.00.00.00.00.00.19.00.10.80.00.06.06.ff.ff.ff.ff.ff.ff.00.00.ff.ff.00.18.00.00.23.20.00.06.00.20.00.40.00.00.00.01.de.10.00.00.20.04.ff.ff.00.18.00.00.23.20.00.06.00.20.00.60.00.00.00.01.de.10.00.00.22.04.00.19.00.10.80.00.2a.02.00.01.00.00.00.00.00.00.ff.ff.00.10.00.00.23.20.00.0e.ff.f8.20.00.00.00 >
