| Message ID | 20230121164609.3625347-1-odivlad@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [ovs-dev,v2,1/2] northd: make traffic routed to vtep lport distributed | expand |
| Context | Check | Description |
|---|---|---|
| ovsrobot/apply-robot | success | apply and check: success |
| ovsrobot/github-robot-_Build_and_Test | success | github build: passed |
| ovsrobot/github-robot-_ovn-kubernetes | fail | github build: failed |
On Sat, Jan 21, 2023 at 07:46:07PM +0300, Vladislav Odintsov wrote: > There were two issues prior to this patch: > 1. It was unable to have connectivity to networks over a router in > physical network connected through VTEP (ramp) gateway. > Consider next topology: > > ovn-nbctl lr-add lr1 > ovn-nbctl lrp-add lr1 lrp1 00:00:00:00:00:01 10.0.0.1/24 > ovn-nbctl ls-add ls1 > ovn-nbctl lrp-add ls1 lsp1 -- \ > lsp-set-addresses lsp1 router -- \ > lsp-set-type lsp1 router -- \ > lsp-set-options lsp1 router-port=lrp1 > ovn-nbctl lsp-add ls1 lsp-vtep -- \ > lsp-set-type lsp-vtep vtep -- \ > lsp-set-addresses lsp-vtep unknown -- \ > lsp-set-options lsp-vtep vtep-physical-switch=<..> vtep-logical-switch=<..> > ovn-nbctl lr-route-add lr1 192.168.0.0/24 10.0.0.100 > > If one issues ping from lsp1 to some address from 192.168.0.0/24 (via > vtep lsp), to enable routing support with vtep it is required to set > redirect chassis or ha chassis group on lrp1. This topology didn't > provide connectivity. Now such traffic flow will work properly. > > 2. Traffic from lport in one subnet to vtep lport in another subnet of > same LR previously traversed via l3gw chassis, now in 'to vtep lport' > direction goes directly from hypervisor handling lport to VTEP (RAMP) > switch. In the opposite direction traffic still goes from VTEP (RAMP) > switch through l3gw chassis and then to hypervisor. > > The described functionality changes achieved by skipping to add > gateway redirect logical flow for l3dgw ports which peers have datapath > with logical switch ports of 'vtep' type. > In this case traffic from hypervisor to VTEP (ramp) switch should go in > distributed manner. Only returning routed traffic must go through > centralized gateway or ha-chassis-group. > > This patch also updates relevant testcases to check the changed flows > generation and port_binding:options:always-redirect logic. > > Signed-off-by: Vladislav Odintsov <odivlad@gmail.com> Thanks for the updates since v1, they look good to me. FWIIW, Reviewed-by: Simon Horman <simon.horman@corigine.com>
On 1/23/23 10:15, Simon Horman wrote: > On Sat, Jan 21, 2023 at 07:46:07PM +0300, Vladislav Odintsov wrote: >> There were two issues prior to this patch: >> 1. It was unable to have connectivity to networks over a router in >> physical network connected through VTEP (ramp) gateway. >> Consider next topology: >> >> ovn-nbctl lr-add lr1 >> ovn-nbctl lrp-add lr1 lrp1 00:00:00:00:00:01 10.0.0.1/24 >> ovn-nbctl ls-add ls1 >> ovn-nbctl lrp-add ls1 lsp1 -- \ >> lsp-set-addresses lsp1 router -- \ >> lsp-set-type lsp1 router -- \ >> lsp-set-options lsp1 router-port=lrp1 >> ovn-nbctl lsp-add ls1 lsp-vtep -- \ >> lsp-set-type lsp-vtep vtep -- \ >> lsp-set-addresses lsp-vtep unknown -- \ >> lsp-set-options lsp-vtep vtep-physical-switch=<..> vtep-logical-switch=<..> >> ovn-nbctl lr-route-add lr1 192.168.0.0/24 10.0.0.100 >> >> If one issues ping from lsp1 to some address from 192.168.0.0/24 (via >> vtep lsp), to enable routing support with vtep it is required to set >> redirect chassis or ha chassis group on lrp1. This topology didn't >> provide connectivity. Now such traffic flow will work properly. >> >> 2. Traffic from lport in one subnet to vtep lport in another subnet of >> same LR previously traversed via l3gw chassis, now in 'to vtep lport' >> direction goes directly from hypervisor handling lport to VTEP (RAMP) >> switch. In the opposite direction traffic still goes from VTEP (RAMP) >> switch through l3gw chassis and then to hypervisor. >> >> The described functionality changes achieved by skipping to add >> gateway redirect logical flow for l3dgw ports which peers have datapath >> with logical switch ports of 'vtep' type. >> In this case traffic from hypervisor to VTEP (ramp) switch should go in >> distributed manner. Only returning routed traffic must go through >> centralized gateway or ha-chassis-group. >> >> This patch also updates relevant testcases to check the changed flows >> generation and port_binding:options:always-redirect logic. >> >> Signed-off-by: Vladislav Odintsov <odivlad@gmail.com> > > Thanks for the updates since v1, they look good to me. > > FWIIW, > > Reviewed-by: Simon Horman <simon.horman@corigine.com> > _______________________________________________ Thanks, Vladislav and Simon! I applied these two patches to the main branch. Regards, Dumitru
Thanks Dumitru! Regards, Vladislav Odintsov > On 23 Jan 2023, at 17:58, Dumitru Ceara <dceara@redhat.com> wrote: > > On 1/23/23 10:15, Simon Horman wrote: >> On Sat, Jan 21, 2023 at 07:46:07PM +0300, Vladislav Odintsov wrote: >>> There were two issues prior to this patch: >>> 1. It was unable to have connectivity to networks over a router in >>> physical network connected through VTEP (ramp) gateway. >>> Consider next topology: >>> >>> ovn-nbctl lr-add lr1 >>> ovn-nbctl lrp-add lr1 lrp1 00:00:00:00:00:01 10.0.0.1/24 >>> ovn-nbctl ls-add ls1 >>> ovn-nbctl lrp-add ls1 lsp1 -- \ >>> lsp-set-addresses lsp1 router -- \ >>> lsp-set-type lsp1 router -- \ >>> lsp-set-options lsp1 router-port=lrp1 >>> ovn-nbctl lsp-add ls1 lsp-vtep -- \ >>> lsp-set-type lsp-vtep vtep -- \ >>> lsp-set-addresses lsp-vtep unknown -- \ >>> lsp-set-options lsp-vtep vtep-physical-switch=<..> vtep-logical-switch=<..> >>> ovn-nbctl lr-route-add lr1 192.168.0.0/24 10.0.0.100 >>> >>> If one issues ping from lsp1 to some address from 192.168.0.0/24 (via >>> vtep lsp), to enable routing support with vtep it is required to set >>> redirect chassis or ha chassis group on lrp1. This topology didn't >>> provide connectivity. Now such traffic flow will work properly. >>> >>> 2. Traffic from lport in one subnet to vtep lport in another subnet of >>> same LR previously traversed via l3gw chassis, now in 'to vtep lport' >>> direction goes directly from hypervisor handling lport to VTEP (RAMP) >>> switch. In the opposite direction traffic still goes from VTEP (RAMP) >>> switch through l3gw chassis and then to hypervisor. >>> >>> The described functionality changes achieved by skipping to add >>> gateway redirect logical flow for l3dgw ports which peers have datapath >>> with logical switch ports of 'vtep' type. >>> In this case traffic from hypervisor to VTEP (ramp) switch should go in >>> distributed manner. Only returning routed traffic must go through >>> centralized gateway or ha-chassis-group. >>> >>> This patch also updates relevant testcases to check the changed flows >>> generation and port_binding:options:always-redirect logic. >>> >>> Signed-off-by: Vladislav Odintsov <odivlad@gmail.com> >> >> Thanks for the updates since v1, they look good to me. >> >> FWIIW, >> >> Reviewed-by: Simon Horman <simon.horman@corigine.com> >> _______________________________________________ > > Thanks, Vladislav and Simon! I applied these two patches to the main > branch. > > Regards, > Dumitru >
diff --git a/northd/northd.c b/northd/northd.c index 40a302579..46ed39850 100644 --- a/northd/northd.c +++ b/northd/northd.c @@ -3302,6 +3302,14 @@ sbrec_port_binding_update_mirror_rules(struct northd_input *input_data, check_and_do_sb_mirror_addition(input_data, op); } +/* Return true if given ovn_port has peer and this peer's ovn_datapath + * has_vtep_lports set to true. False otherwise. */ +static bool +l3dgw_port_has_associated_vtep_lports(const struct ovn_port *op) +{ + return op->peer && op->peer->od->has_vtep_lports; +} + static void ovn_port_update_sbrec(struct northd_input *input_data, struct ovsdb_idl_txn *ovnsb_txn, @@ -3371,7 +3379,10 @@ ovn_port_update_sbrec(struct northd_input *input_data, } smap_add(&new, "distributed-port", op->nbrp->name); - bool always_redirect = !op->od->has_distributed_nat; + bool always_redirect = + !op->od->has_distributed_nat && + !l3dgw_port_has_associated_vtep_lports(op->l3dgw_port); + if (redirect_type) { smap_add(&new, "redirect-type", redirect_type); /* XXX Why can't we enable always-redirect when redirect-type @@ -11627,7 +11638,7 @@ build_gateway_mtu_flow(struct hmap *lflows, struct ovn_port *op, static bool consider_l3dwg_port_is_centralized(struct ovn_port *op) { - if (op->peer && op->peer->od->has_vtep_lports) { + if (l3dgw_port_has_associated_vtep_lports(op)) { return false; } @@ -12833,6 +12844,17 @@ build_gateway_redirect_flows_for_lrouter( return; } for (size_t i = 0; i < od->n_l3dgw_ports; i++) { + if (l3dgw_port_has_associated_vtep_lports(od->l3dgw_ports[i])) { + /* Skip adding redirect lflow for vtep-enabled l3dgw ports. + * Traffic from hypervisor to VTEP (ramp) switch should go in + * distributed manner. Only returning routed traffic must go + * through centralized gateway (or ha-chassis-group). + * This assumes that attached logical switch with vtep lport(s) has + * no localnet port(s) for NAT. Otherwise centralized NAT will not + * work. */ + continue; + } + const struct ovsdb_idl_row *stage_hint = NULL; bool add_def_flow = true; diff --git a/tests/ovn-northd.at b/tests/ovn-northd.at index 35f186ad6..941460d5b 100644 --- a/tests/ovn-northd.at +++ b/tests/ovn-northd.at @@ -6075,7 +6075,7 @@ AT_CLEANUP ]) OVN_FOR_EACH_NORTHD_NO_HV([ -AT_SETUP([ovn-northd -- lr admission with vtep lports]) +AT_SETUP([ovn-northd -- lrp with chassis-redirect and ls with vtep lport]) AT_KEYWORDS([multiple-l3dgw-ports]) ovn_start NORTHD_TYPE check ovn-sbctl chassis-add ch1 geneve 127.0.0.2 @@ -6099,6 +6099,11 @@ AT_CHECK([grep lr_in_admission lrflows | grep lrp1 | sed 's/table=../table=??/' table=??(lr_in_admission ), priority=50 , match=(eth.mcast && inport == "lrp1"), action=(xreg0[[0..47]] = 00:00:00:00:00:01; next;) ]) +# Check the flows in lr_in_gw_redirect stage +AT_CHECK([grep lr_in_gw_redirect lrflows | grep lrp1 | sed 's/table=../table=??/' | sort], [0], []) + +wait_row_count Port_Binding 0 logical_port=cr-lrp1 options:always-redirect="true" + # make lrp a cr-port and check its flows check ovn-nbctl lrp-set-gateway-chassis lrp1 ch1 @@ -6112,6 +6117,13 @@ AT_CHECK([grep lr_in_admission lrflows | grep lrp1 | sed 's/table=../table=??/' table=??(lr_in_admission ), priority=50 , match=(eth.mcast && inport == "lrp1"), action=(xreg0[[0..47]] = 00:00:00:00:00:01; next;) ]) +# Check the flows in lr_in_gw_redirect stage +AT_CHECK([grep lr_in_gw_redirect lrflows | grep lrp1 | sed 's/table=../table=??/' | sort], [0], [dnl + table=??(lr_in_gw_redirect ), priority=50 , match=(outport == "lrp1"), action=(outport = "cr-lrp1"; next;) +]) + +wait_row_count Port_Binding 1 logical_port=cr-lrp1 options:always-redirect="true" + # attach vtep logical port to logical switch and check flows. # there should not be is_chassis_resident part. check ovn-nbctl lsp-add ls1 lsp-vtep -- lsp-set-type lsp-vtep vtep @@ -6126,6 +6138,11 @@ AT_CHECK([grep lr_in_admission lrflows | grep lrp1 | sed 's/table=../table=??/' table=??(lr_in_admission ), priority=50 , match=(eth.mcast && inport == "lrp1"), action=(xreg0[[0..47]] = 00:00:00:00:00:01; next;) ]) +# Check the flows in lr_in_gw_redirect stage +AT_CHECK([grep lr_in_gw_redirect lrflows | grep lrp1 | sed 's/table=../table=??/' | sort], [0], []) + +wait_row_count Port_Binding 0 logical_port=cr-lrp1 options:always-redirect="true" + # delete vtep lport and check lrp has is_chassis_resident match part again. check ovn-nbctl lsp-del lsp-vtep @@ -6139,6 +6156,13 @@ AT_CHECK([grep lr_in_admission lrflows | grep lrp1 | sed 's/table=../table=??/' table=??(lr_in_admission ), priority=50 , match=(eth.mcast && inport == "lrp1"), action=(xreg0[[0..47]] = 00:00:00:00:00:01; next;) ]) +# Check the flows in lr_in_gw_redirect stage +AT_CHECK([grep lr_in_gw_redirect lrflows | grep lrp1 | sed 's/table=../table=??/' | sort], [0], [dnl + table=??(lr_in_gw_redirect ), priority=50 , match=(outport == "lrp1"), action=(outport = "cr-lrp1"; next;) +]) + +wait_row_count Port_Binding 1 logical_port=cr-lrp1 options:always-redirect="true" + AT_CLEANUP ])
There were two issues prior to this patch: 1. It was unable to have connectivity to networks over a router in physical network connected through VTEP (ramp) gateway. Consider next topology: ovn-nbctl lr-add lr1 ovn-nbctl lrp-add lr1 lrp1 00:00:00:00:00:01 10.0.0.1/24 ovn-nbctl ls-add ls1 ovn-nbctl lrp-add ls1 lsp1 -- \ lsp-set-addresses lsp1 router -- \ lsp-set-type lsp1 router -- \ lsp-set-options lsp1 router-port=lrp1 ovn-nbctl lsp-add ls1 lsp-vtep -- \ lsp-set-type lsp-vtep vtep -- \ lsp-set-addresses lsp-vtep unknown -- \ lsp-set-options lsp-vtep vtep-physical-switch=<..> vtep-logical-switch=<..> ovn-nbctl lr-route-add lr1 192.168.0.0/24 10.0.0.100 If one issues ping from lsp1 to some address from 192.168.0.0/24 (via vtep lsp), to enable routing support with vtep it is required to set redirect chassis or ha chassis group on lrp1. This topology didn't provide connectivity. Now such traffic flow will work properly. 2. Traffic from lport in one subnet to vtep lport in another subnet of same LR previously traversed via l3gw chassis, now in 'to vtep lport' direction goes directly from hypervisor handling lport to VTEP (RAMP) switch. In the opposite direction traffic still goes from VTEP (RAMP) switch through l3gw chassis and then to hypervisor. The described functionality changes achieved by skipping to add gateway redirect logical flow for l3dgw ports which peers have datapath with logical switch ports of 'vtep' type. In this case traffic from hypervisor to VTEP (ramp) switch should go in distributed manner. Only returning routed traffic must go through centralized gateway or ha-chassis-group. This patch also updates relevant testcases to check the changed flows generation and port_binding:options:always-redirect logic. Signed-off-by: Vladislav Odintsov <odivlad@gmail.com> --- northd/northd.c | 26 ++++++++++++++++++++++++-- tests/ovn-northd.at | 26 +++++++++++++++++++++++++- 2 files changed, 49 insertions(+), 3 deletions(-)