Re: [ovs-dev] [PATCH v2] ovn-controller: Fix match crieria for dynamic mac binding flows
Chandra Sekhar Vejendla/San Jose/IBM@IBMUS wrote on 09/08/2016 11:31:54 PM:
> From: Chandra Sekhar Vejendla/San Jose/IBM@IBMUS
> To: dev@openvswitch.org
> Cc: Chandra Sekhar Vejendla/San Jose/IBM@IBMUS, Ryan
Moats/Omaha/IBM@IBMUS
> Date: 09/08/2016 11:32 PM
> Subject: [PATCH v2] ovn-controller: Fix match crieria for dynamic
> mac binding flows
>
> match struct is not initialized before adding flows for each entry in
> mac_bindings table. This results in incorrect match criteria.
>
> Signed-off-by: Chandra Sekhar Vejendla <csvej...@us.ibm.com>
> Signed-off-by: Ryan Moats <rmo...@us.ibm.com>
> Co-authored-by: Ryan Moats <rmo...@us.ibm.com>
> ---
> ovn/controller/lflow.c | 31 ++-
> 1 file changed, 14 insertions(+), 17 deletions(-)
>
> diff --git a/ovn/controller/lflow.c b/ovn/controller/lflow.c
> index efac5b3..3ea7fc7 100644
> --- a/ovn/controller/lflow.c
> +++ b/ovn/controller/lflow.c
> @@ -343,10 +343,13 @@ put_load(const uint8_t *data, size_t len,
> static void
> consider_neighbor_flow(const struct lport_index *lports,
> const struct sbrec_mac_binding *b,
> - struct ofpbuf *ofpacts_p,
> - struct match *match_p,
> struct hmap *flow_table)
> {
> +struct ofpbuf ofpacts;
> +struct match match;
> +match_init_catchall();
> +ofpbuf_init(, 0);
> +
> const struct sbrec_port_binding *pb
> = lport_lookup_by_name(lports, b->logical_port);
> if (!pb) {
> @@ -368,7 +371,7 @@ consider_neighbor_flow(const struct lport_index
*lports,
> VLOG_WARN_RL(, "bad 'ip' %s", b->ip);
> return;
> }
> -match_set_reg(match_p, 0, ntohl(ip));
> +match_set_reg(, 0, ntohl(ip));
> } else {
> struct in6_addr ip6;
> if (!ipv6_parse(b->ip, )) {
> @@ -378,16 +381,17 @@ consider_neighbor_flow(const struct lport_index
*lports,
> }
> ovs_be128 value;
> memcpy(, , sizeof(value));
> -match_set_xxreg(match_p, 0, ntoh128(value));
> +match_set_xxreg(, 0, ntoh128(value));
> }
>
> -match_set_metadata(match_p, htonll(pb->datapath->tunnel_key));
> -match_set_reg(match_p, MFF_LOG_OUTPORT - MFF_REG0, pb->tunnel_key);
> +match_set_metadata(, htonll(pb->datapath->tunnel_key));
> +match_set_reg(, MFF_LOG_OUTPORT - MFF_REG0, pb->tunnel_key);
>
> -ofpbuf_clear(ofpacts_p);
> -put_load(mac.ea, sizeof mac.ea, MFF_ETH_DST, 0, 48, ofpacts_p);
> +ofpbuf_clear();
> +put_load(mac.ea, sizeof mac.ea, MFF_ETH_DST, 0, 48, );
>
> -ofctrl_add_flow(flow_table, OFTABLE_MAC_BINDING, 100, match_p,
> ofpacts_p);
> +ofctrl_add_flow(flow_table, OFTABLE_MAC_BINDING, 100, ,
);
> +ofpbuf_uninit();
> }
>
> /* Adds an OpenFlow flow to flow tables for each MAC binding in the OVN
> @@ -398,17 +402,10 @@ add_neighbor_flows(struct controller_ctx *ctx,
> const struct lport_index *lports,
> struct hmap *flow_table)
> {
> -struct ofpbuf ofpacts;
> -struct match match;
> -match_init_catchall();
> -ofpbuf_init(, 0);
> -
> const struct sbrec_mac_binding *b;
> SBREC_MAC_BINDING_FOR_EACH (b, ctx->ovnsb_idl) {
> -consider_neighbor_flow(lports, b, , , flow_table);
> +consider_neighbor_flow(lports, b, flow_table);
> }
> -
> -ofpbuf_uninit();
> }
>
> /* Translates logical flows in the Logical_Flow table in the OVN_SB
database
> --
> 1.9.1
>
I haven't been able to come up with a valid test case that would fail
without
this patch. For the unit test, I tried to add multiple mac_bindings with
ovn-sbctl command and then verify that the flows generated should have only
reg0 and reg15 in the match criteria. When i tested this in a real setup,
without the patch, reg1, reg2 and reg3 will sometimes show up in the match
criteria along with reg0 and reg15. This is not 100% reproducible, though.
Thanks,
Chandra
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v3] OVN: Fix ARP request flow in router ingresstable
Ryan Moats/Omaha/IBM wrote on 07/18/2016 07:50:50 AM: > From: Ryan Moats/Omaha/IBM > To: Chandra Sekhar Vejendla/San Jose/IBM@IBMUS > Cc: dev@openvswitch.org > Date: 07/18/2016 07:50 AM > Subject: Re: [ovs-dev] [PATCH v3] OVN: Fix ARP request flow in > router ingress table > > "dev" <dev-boun...@openvswitch.org> wrote on 07/07/2016 05:12:48 PM: > > > From: Chandra Sekhar Vejendla/San Jose/IBM@IBMUS > > To: dev@openvswitch.org > > Date: 07/07/2016 05:13 PM > > Subject: [ovs-dev] [PATCH v3] OVN: Fix ARP request flow in router > > ingress table > > Sent by: "dev" <dev-boun...@openvswitch.org> > > > > TPA in arp requests generated for unknown MAC-to-IP bindings is > currently set > > to DST_IP of the original packet. These arps will not be resolved when the > > DST_IP is rechable via the default gateway. This patch fixes the issue by > > setting the TPA to reg0. In routing stage reg0 is set to IP of the default > > gateway when the packet has to go through the default gateway, > otherwise reg0 > > is set to the DST_IP of the original packet. > > > > Signed-off-by: Chandra Sekhar Vejendla <csvej...@us.ibm.com> > > --- > Given that we don't yet have e2e test coverage for this case, I'm not > personally comfortable putting an ack on it without it including said > test coverage. > > Chandra, can you please add some e2e test code that works with this > patch, but fails when that patch isn't in place? > > Thanks, > Ryan Ack, will send out patch v2 with test code. Thanks, Chandra ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH, v2] ovn: Allow SNAT traffic destined to router ip
Ryan Moats/Omaha/IBM wrote on 07/18/2016 10:03:35 AM: > From: Ryan Moats/Omaha/IBM > To: Chandra Sekhar Vejendla/San Jose/IBM@IBMUS > Cc: Guru Shetty <g...@ovn.org>, ovs dev <dev@openvswitch.org> > Date: 07/18/2016 10:03 AM > Subject: Re: [ovs-dev] [PATCH, v2] ovn: Allow SNAT traffic destined > to router ip > > "dev" <dev-boun...@openvswitch.org> wrote on 07/18/2016 11:20:59 AM: > > > From: Chandra Sekhar Vejendla/San Jose/IBM@IBMUS > > To: Guru Shetty <g...@ovn.org> > > Cc: ovs dev <dev@openvswitch.org> > > Date: 07/18/2016 11:21 AM > > Subject: Re: [ovs-dev] [PATCH, v2] ovn: Allow SNAT traffic destined > > to router ip > > Sent by: "dev" <dev-boun...@openvswitch.org> > > > > Guru Shetty <g...@ovn.org> wrote on 07/18/2016 08:03:52 AM: > > > > > From: Guru Shetty <g...@ovn.org> > > > To: Chandra Sekhar Vejendla/San Jose/IBM@IBMUS > > > Cc: ovs dev <dev@openvswitch.org> > > > Date: 07/18/2016 08:04 AM > > > Subject: Re: [ovs-dev] [PATCH, v2] ovn: Allow SNAT traffic destined > > > to router ip > > > > > > On 18 July 2016 at 05:22, Chandra S Vejendla <csvej...@us.ibm.com> wrote: > > > When router ip is used as SNAT IP, traffic destined to router > > > ip should not be dropped > > > > > > Thank you for the fix. You will need to add your Signed-off-by. Can > > > you also add a "Fixes:" tag in commit message. Since this is a > > > regression, I wonder whether we should add a simple unit test that > > > looks at the generated logical flows to make sure that there is no > > > "drop" for the SNAT IP address. > > > > > > > I'll send out patch v3 with 'Signed-off-by' & 'Fixes' tag. > > Yes, i agree that we should have a unit test for this. If its fine with you > > I would like to cover the unit test case in a different patch. > > I'm sorry, but *I* want to see the test in the same patch. We've > already had cases where regressions were created because of > lacking tests, and I'd like to avoid it, especially in cases like this > where we are fixing a regression that could happen again. > > Ryan Fair enough. I'll send out patch v4 with the test ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH, v2] ovn: Allow SNAT traffic destined to router ip
Guru Shetty <g...@ovn.org> wrote on 07/18/2016 08:03:52 AM:
> From: Guru Shetty <g...@ovn.org>
> To: Chandra Sekhar Vejendla/San Jose/IBM@IBMUS
> Cc: ovs dev <dev@openvswitch.org>
> Date: 07/18/2016 08:04 AM
> Subject: Re: [ovs-dev] [PATCH, v2] ovn: Allow SNAT traffic destined
> to router ip
>
> On 18 July 2016 at 05:22, Chandra S Vejendla <csvej...@us.ibm.com> wrote:
> When router ip is used as SNAT IP, traffic destined to router
> ip should not be dropped
>
> Thank you for the fix. You will need to add your Signed-off-by. Can
> you also add a "Fixes:" tag in commit message. Since this is a
> regression, I wonder whether we should add a simple unit test that
> looks at the generated logical flows to make sure that there is no
> "drop" for the SNAT IP address.
>
I'll send out patch v3 with 'Signed-off-by' & 'Fixes' tag.
Yes, i agree that we should have a unit test for this. If its fine with you
I would like to cover the unit test case in a different patch.
> I also wonder, whether we should disable ICMP response to these SNAT
> IP addresses from the router? Don't you see issues with that? I
> presume you will have a situation where the ICMP response flow added
> by the router will override the SNAT flow and the router will
> respond to ICMP instead of the logical port.
Yes, i agree. ICMP responses should be disabled.
>
>
> ---
> ovn/northd/ovn-northd.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index 7ce509d..78c3a7d 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -2399,11 +2399,16 @@ build_lrouter_flows(struct hmap *datapaths,
> struct hmap *ports,
> ds_put_cstr(, "ip4.dst == {");
> bool has_drop_ips = false;
> for (int i = 0; i < op->lrp_networks.n_ipv4_addrs; i++) {
> + bool nat_ip_is_router_ip = false;
> for (int j = 0; j < n_nat_ips; j++) {
> if (op->lrp_networks.ipv4_addrs[i].addr == nat_ips[j]) {
> - continue;
> + nat_ip_is_router_ip = true;
> + break;
> }
> }
> + if (nat_ip_is_router_ip) {
> + continue;
> + }
> ds_put_format(, "%s, ",
> op->lrp_networks.ipv4_addrs[i].addr_s);
> has_drop_ips = true;
> --
> 2.6.1
>
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovn: Allow IP packets destined to router ip for SNAT
Hi Guru,
I am fine with the changes. You can go ahead and apply them.
Thanks,
Chandra
Guru Shetty <g...@ovn.org> wrote on 06/22/2016 09:39:17 AM:
> From: Guru Shetty <g...@ovn.org>
> To: Chandra Sekhar Vejendla/San Jose/IBM@IBMUS
> Cc: ovs dev <dev@openvswitch.org>
> Date: 06/22/2016 09:39 AM
> Subject: Re: [ovs-dev] [PATCH] ovn: Allow IP packets destined to
> router ip for SNAT
>
> On 21 June 2016 at 18:36, Chandra S Vejendla <csvej...@us.ibm.com> wrote:
> By default all the ip traffic destined to router ip is dropped in
> lr_in_ip_input stage. When the router ip is used as snat ip, allow
> reverse snat traffic destined to the router ip.
>
> Signed-off-by: Chandra Sekhar Vejendla <csvej...@us.ibm.com>
>
> Thank you for the fix! This needs an update to ovn-northd.8.xml. If
> you are happy with the following incremental which does that (and
> also adds your name to AUTHORS and makes a couple of stylistic
> changes), I will apply it.
>
> diff --git a/AUTHORS b/AUTHORS
> index e2ac267..c39fdd3 100644
> --- a/AUTHORS
> +++ b/AUTHORS
> @@ -39,6 +39,7 @@ Bruce Davie b...@nicira.com
> Bryan Phillippe b...@toroki.com
> Carlo Andreotti c.andreo...@m3s.it
> Casey Barker crbar...@google.com
> +Chandra Sekhar Vejendla csvej...@us.ibm.com
> Christoph Jaeger c...@linux.com
> Chris Wright chr...@sous-sol.org
> Chuck Short zul...@ubuntu.com
> diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
> index 22edba9..6d52f7e 100644
> --- a/ovn/northd/ovn-northd.8.xml
> +++ b/ovn/northd/ovn-northd.8.xml
> @@ -631,7 +631,10 @@ output;
> handled by one of the flows above, which amounts to ICMP (other
than
> echo requests) and fragments with nonzero offsets. For
> each IP address
> A owned by the router, a priority-60 flow matches
> - ip4.dst == A and drops the traffic.
> + ip4.dst == A and drops the traffic. An
> + exception is made and the above flow is not added if the router
> + port's own IP address is used to SNAT packets passing through
that
> + router.
>
>
>
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index 6ff303e..1599e18 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -2047,9 +2047,9 @@ build_lrouter_flows(struct hmap *datapaths,
> struct hmap *ports,
> }
>
> /* Drop IP traffic to this router, unless the router ip is used
as
> - * snat ip. */
> + * SNAT ip. */
> bool snat_ip_is_router_ip = false;
> - for (int i = 0; i < op->od->nbr->n_nat && !
> snat_ip_is_router_ip; i++) {
> + for (int i = 0; i < op->od->nbr->n_nat; i++) {
> const struct nbrec_nat *nat;
> ovs_be32 ip;
>
> @@ -2057,14 +2057,17 @@ build_lrouter_flows(struct hmap *datapaths,
> struct hmap *ports,
> if (strcmp(nat->type, "snat")) {
> continue;
> }
> +
> if (!ip_parse(nat->external_ip, ) || !ip) {
> static struct vlog_rate_limit rl =
> VLOG_RATE_LIMIT_INIT(5, 1);
> VLOG_WARN_RL(, "bad ip address %s in snat
configuration "
> "for router %s", nat->external_ip, op->key);
> continue;
> }
> +
> if (ip == op->ip) {
> snat_ip_is_router_ip = true;
> + break;
> }
> }
>
>
> ---
> ovn/northd/ovn-northd.c | 33 -
> 1 file changed, 28 insertions(+), 5 deletions(-)
>
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index 17713ec..6ff303e 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -2046,11 +2046,34 @@ build_lrouter_flows(struct hmap *datapaths,
> struct hmap *ports,
> free(actions);
> }
>
> - /* Drop IP traffic to this router. */
> - match = xasprintf("ip4.dst == "IP_FMT, IP_ARGS(op->ip));
> - ovn_lflow_add(lflows, op->od, S_ROUTER_IN_IP_INPUT, 60,
> - match, "drop;");
> - free(match);
> + /* Drop IP traffic to this router, unless the router ip is used
as
> + * snat ip. */
> + bool snat_ip_is_router_ip = false;
> + for (int i = 0; i < op->od->nbr->n_nat && !
> snat_ip_is_router_ip; i++) {
> + const struct nbrec_nat *nat;
> + ovs_be32 ip;
> +
> +
Re: [ovs-dev] [PATCH RFC] OVN: Openstack floating ip support
Ryan, I'll send out a V2 patch with the documentation changes you have suggested. In the IP_DNAT stage inport is reset to address cases which involve east-west communication via a floating ip where both the source and the destination VM's are in the same logical switch. This would require that the router send out the packet on the same interface it came in after applying the NAT rules. Thanks, Chandra Ryan Moats/Omaha/IBM wrote on 03/25/2016 10:15:22 AM: > From: Ryan Moats/Omaha/IBM > To: Chandra Sekhar Vejendla/San Jose/IBM@IBMUS > Cc: dev@openvswitch.org > Date: 03/25/2016 10:15 AM > Subject: Re: [ovs-dev] [PATCH RFC] OVN: Openstack floating ip support > > "dev" <dev-boun...@openvswitch.org> wrote on 03/22/2016 04:19:07 PM: > > > From: Chandra Sekhar Vejendla/San Jose/IBM@IBMUS > > To: dev@openvswitch.org > > Date: 03/22/2016 04:19 PM > > Subject: [ovs-dev] [PATCH RFC] OVN: Openstack floating ip support > > Sent by: "dev" <dev-boun...@openvswitch.org> > > > > This patch adds distributed floating ip support for ovn. The assumption made > > here is that the external network is a single L2 broadcast domain > and all the > > chassis have connectivity to the external network. > > > > 2 new tables are added in the LROUTER pipeline IN_IP_DNAT & IP_IN_SNAT. > > IN_IP_DNAT will modify the dst ip of the packet from floating ip to vm ip. > > IN_IP_SNAT will modify the src ip of the packet from vm ip to floating ip. > > > > Rules in IN_IP_DNAT: > > - Priority 100 rule to set the reg2 to 0x1 if dst & src networks are > > connectected via a router and both the networks are private. > > - Priority 90 rule to modify the dst ip from floating ip to vm ip. > > - Priority 0 rule to go to next table. > > > > Rules in IN_IP_SNAT: > > - Priority 100 rule to skip modifying the src ip when reg2 is set to 0x1 > > - Priority 90 rule to modify the src ip from vm ip to floating ip > and dst mac > > to floating ip port mac if the packet is egressing via the gateway port > > - Priority 50 rule to modify the src ip from vm ip to floating ip > > - Priority 0 rule to go to next table. > > > > Priority 100 rules in IN_IP_DNAT and IN_IP_SNAT serves 2 purposes. > > - Avoid NAT when vms in different LSWITCHES connected via a LROUTER talk to > > each other using private ips. > > - When 2 VMs connected to the same LSWITCH or different LSWITCHES connected > > via a router try to talk to each other, the dst ip of the packet should > > first be DNATed and then the src ip should be SNATed. > > > > The initial design was to stage DNAT in the ingress pipeline and the SNAT in > > the egress pipeline, but now both the stages are in the ingress > pipeline. This > > was done to solve the cases highlighted above [Priority 100 > rules]. There is a > > need to use information from DNAT stage when SNAT is being processed. This > > would require an explicit register to be burnt to store the information. > > > > Flows modified in the LSWITCH pipeline > > > > Rules in IN_PORT_SEC: > > - Priority 50 rule to allow packets ingressing the LSWITCH router port > > with a src mac of floating ip port > > > > Rules in ARP_RSP: > > - Priority 150 rule to respond to arp request for floating ip. To > prevent arp > > responses for floating ip's from all the chassis, "lport" optionis set in > > the external_id's column of the lflow table. lport will point to > > the vif-id of > > the vm that is associated with the floating ip. When ovn-controller is > > processing the flows, if it sees an lport option set in the external_ids > > column, it will install this lflow only if the lport is a local > port on the > > chassis. > > > > Rules in L2_LKUP: > > - Priority 50 rule to set the outport to the lrouter port when the dst mac > > matches the floating ip mac > > > > Rules in OUT_PORT_SEC: > > - Priority 50 rule to allow packet egressing the lrouter port witha mac of a > > floating ip port. > > > > Had to increase MAX_RESUBMIT_RECURSION from 64 to 96. When 2 VMs connected > > via vm1->LS->LR->LS->LR->LS->vm2 are trying to talk to each other, the > > resubmits are exceeding the existing 64 limit. > > > > When a floating ip is associated with a VM ip, NB will set the > options of the > > floating ip lport to "fixed-ip-port=, router- > port= > logical router port". > > > > If you want to try out this patch with openstack, add the > following patch [1] > > to networking-ovn. > > > > [1] https://review.openstack.org/#/c/295547/ > I know this is an RFC patch, but I'd really like to see two improvements > w.r.t the documentation: > > 1. include the needed changes to ovn-northd.8.xml. > 2. It looks like the DNAT code is also clearing the inport value and I > didn't find the reason why anywhere - I'm pretty sure I know why, but > confirmation would be good. > > Ryan Moats (regXboi) ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH RFC] OVN: Openstack floating ip support
10.1.2.5 responds to VM 10.1.1.3 [IN PVM3]: m_vm3, 10.1.2.5 -> m_net2, 10.1.1.3 The return path from 10.1.2.5 --> 10.1.1.3 will follow the exact same path as outlined in steps 1-8 above. The packet is not altered in the IP_DNAT and the IP_SNAT stages. [OUT PVM1]: m_net1, 10.1.2.5 -> m_vm1, 10.1.1.3 ___ Scenario 4: East <--> West via FIP, both endpoints on the same logical switch. (VM1 <--> FIP2 (VM2)) ___ [IN PVM1]: m_vm1, 10.1.1.3 -> m_net1, 198.44.1.4 1. Packet ingresses the Net1 logical switch on port PVM1 and will egress out of port P1 since the DMAC matches the router port's mac address. [OUT P1]: m_vm1, 10.1.1.3 -> m_net1, 198.44.1.4 [IN RP1]: m_vm1, 10.1.1.3 -> m_net1, 198.44.1.4 2. Packet ingresses the logical router on port RP1 and passes through the ingress security rules. 3. Packet gets processed in IP_DNAT stage where the priority 90 rule will be hit, since the DIP of the packet matches the FIP3 IP. The DIP of the packet will be changed from 198.44.1.4(FIP3 IP) to 10.1.1.4 (VM3 IP). The rule will also reset the inport, since this packet should egress out on the same interface it ingresses in. m_vm1, 10.1.1.3 -> m_net1, 10.1.1.4 (inport = " ") 4. Packet gets processed in the ROUTING stage and the SMAC is changed to m_net1 and the outport is set to RP1. m_net1, 10.1.1.3 -> m_net1, 10.1.1.4 (inport = " ") 5. Packet enters IP_SNAT stage where the priority 50 rule will be hit and the SIP is changed from 10.1.1.3(VM1 IP) to 198.44.1.3(FIP1 IP). Priority 90 rules do not match here, since the outport is not RP3. m_net1, 198.44.1.3 -> m_net1, 10.1.1.4 6. Packet gets processed in ARP_RESOLVE stage where the priority 100 rule will be hit and the DMAC of the packet is changed to VM2 mac (m_vm2) m_net1, 198.44.1.3 -> m_vm2, 10.1.1.4 7. Packet egresses out of the logical router via port RP1. The egress rules drops packets which match inport == outport, but in this case the inport was reset in IP_DNAT stage, so the packet egresses out. [OUT RP1]: m_net1, 198.44.1.3 -> m_vm2, 10.1.1.4 [IN P1 ]: m_net1, 198.44.1.3 -> m_vm2, 10.1.1.4 8. The packet ingresses Net1 logical switch on port P1 and after further processing, the packet will be sent out of port PVM2 to VM2. [OUT PVM2]: m_net1, 198.44.1.3 -> m_vm2, 10.1.1.4 VM 10.1.1.4 responds to 198.44.1.3 [IN PVM2]: m_vm2, 10.1.1.4 -> m_net1, 198.44.1.3 The return path from 10.1.1.4 --> 198.44.1.3 will follow the exact same path as outlined in steps 1-8 above. The DIP gets modified in IP_DNAT stage to 198.44.1.4 and the inport is reset. In the IP_SNAT stage the SIP gets modified to 10.1.1.3. [OUT PVM1]: m_net1, 198.44.1.4 -> m_vm1, 10.1.1.3 Guru Shetty <g...@ovn.org> wrote on 03/25/2016 10:56:20 AM: > From: Guru Shetty <g...@ovn.org> > To: Chandra Sekhar Vejendla/San Jose/IBM@IBMUS > Cc: ovs dev <dev@openvswitch.org> > Date: 03/25/2016 10:56 AM > Subject: Re: [ovs-dev] [PATCH RFC] OVN: Openstack floating ip support > > It would really help if you give packet walkthrough when following 2 > simultaneous connections happen at the same time. > 1. east-west without NAT between the private IP addresses > 2 east-west with floating IP. > > You also mentioned in the meeting (if I remember correctly) on how > you have to keep a particular interface pinned to a hypervisor. A > little description on that would help. > > Also, does this work with overlay networking? > > On 22 March 2016 at 14:19, Chandra S Vejendla <csvej...@us.ibm.com> wrote: > This patch adds distributed floating ip support for ovn. The assumption made > here is that the external network is a single L2 broadcast domain and all the > chassis have connectivity to the external network. > > 2 new tables are added in the LROUTER pipeline IN_IP_DNAT & IP_IN_SNAT. > IN_IP_DNAT will modify the dst ip of the packet from floating ip to vm ip. > IN_IP_SNAT will modify the src ip of the packet from vm ip to floating ip. > > Rules in IN_IP_DNAT: > - Priority 100 rule to set the reg2 to 0x1 if dst & src networks are > connectected via a router and both the networks are private. > - Priority 90 rule to modify the dst ip from floating ip to vm ip. > - Priority 0 rule to go to next table. > > Rules in IN_IP_SNAT: > - Priority 100 rule to skip modifying the src ip when reg2 is set to 0x1 > - Priority 90 rule to modify the src ip from vm ip to floating ip and dst mac > to floating ip port mac if the packet is egressing via the gateway port > - Priority 50 rule to modify the src ip from vm ip to floating ip > - Priority 0 rule to go to next table. > > Priority 100 rules in IN_IP_DNAT and IN_IP_SNAT serves 2 purposes. >
