| Message ID | f5ca6d096989ba78798a8435c1984ddf87f25fa5.1730713432.git.felix.huettner@stackit.cloud |
|---|---|
| State | Superseded |
| Headers | show |
| Series | OVN Fabric integration | expand |
| Context | Check | Description |
|---|---|---|
| ovsrobot/apply-robot | success | apply and check: success |
Hello, Felix, On Mon, Nov 4, 2024 at 12:04 PM Felix Huettner via dev <ovs-dev@openvswitch.org> wrote: > > previously we prevented using the routing-protocol-redirect option on > chassis-redirect ports. However the option works fine there, therefor we > remove the limitation. I would be interested in your thoughts around the implications of allowing this. Let's say you have a system where 5 chassis participate in a HA Chassis Group for a LRP. Now let's say you set up a routing protocol daemon on these 5 chassis, all of which will expect to speak with one or more fabric switches, which may or may not have a shared L2 between them, using the IP address of the LRP, which is the same for all 5 chassis. How would the fabric react to this, and how easy would it be for its operator to understand such a configuration? -- Frode Nordahl > Signed-off-by: Felix Huettner <felix.huettner@stackit.cloud> > --- > northd/northd.c | 8 -------- > 1 file changed, 8 deletions(-) > > diff --git a/northd/northd.c b/northd/northd.c > index 7a8148b13..c25c501d9 100644 > --- a/northd/northd.c > +++ b/northd/northd.c > @@ -14196,14 +14196,6 @@ build_lrouter_routing_protocol_redirect( > return; > } > > - if (op->cr_port) { > - static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5); > - VLOG_WARN_RL(&rl, "Option 'routing-protocol-redirect' is not " > - "supported on Distributed Gateway Port '%s'", > - op->key); > - return; > - } > - > /* Ensure that LSP, to which the routing protocol traffic is redirected, > * exists. */ > struct ovn_port *lsp_in_peer = ovn_port_find(ls_ports, > -- > 2.47.0 > > > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
On Mon, Nov 18, 2024 at 01:03:39PM +0100, Frode Nordahl wrote: > Hello, Felix, > > On Mon, Nov 4, 2024 at 12:04 PM Felix Huettner via dev > <ovs-dev@openvswitch.org> wrote: > > > > previously we prevented using the routing-protocol-redirect option on > > chassis-redirect ports. However the option works fine there, therefor we > > remove the limitation. Hi Frode, thanks for the comment. > > I would be interested in your thoughts around the implications of allowing this. > > Let's say you have a system where 5 chassis participate in a HA > Chassis Group for a LRP. Now let's say you set up a routing protocol > daemon on these 5 chassis, all of which will expect to speak with one > or more fabric switches, which may or may not have a shared L2 between > them, using the IP address of the LRP, which is the same for all 5 > chassis. > > How would the fabric react to this, and how easy would it be for its > operator to understand such a configuration? To my understanding of the routing-protocol-redirect logic we always redirect traffic to a single LSP. That means that in your mentioned case this LSP is generally only bound on one location. Most probably it would need to move in this case between chassis as the LRP changes (which would currently be the users responsibility). In this case only one chassis would use the MAC at a time. As an alternative maybe the user would create a localport as the routing-protocol-redirect target. In this case i guess you could get to the situation where separate chassis speak to the same switch with the same MAC. However this would then already be the case for any kind of localport connected to a LSP with a localnet. So maybe it is just something you should not do. Thanks a lot Felix > > -- > Frode Nordahl > > > Signed-off-by: Felix Huettner <felix.huettner@stackit.cloud> > > --- > > northd/northd.c | 8 -------- > > 1 file changed, 8 deletions(-) > > > > diff --git a/northd/northd.c b/northd/northd.c > > index 7a8148b13..c25c501d9 100644 > > --- a/northd/northd.c > > +++ b/northd/northd.c > > @@ -14196,14 +14196,6 @@ build_lrouter_routing_protocol_redirect( > > return; > > } > > > > - if (op->cr_port) { > > - static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5); > > - VLOG_WARN_RL(&rl, "Option 'routing-protocol-redirect' is not " > > - "supported on Distributed Gateway Port '%s'", > > - op->key); > > - return; > > - } > > - > > /* Ensure that LSP, to which the routing protocol traffic is redirected, > > * exists. */ > > struct ovn_port *lsp_in_peer = ovn_port_find(ls_ports, > > -- > > 2.47.0 > > > > > > _______________________________________________ > > dev mailing list > > dev@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
diff --git a/northd/northd.c b/northd/northd.c index 7a8148b13..c25c501d9 100644 --- a/northd/northd.c +++ b/northd/northd.c @@ -14196,14 +14196,6 @@ build_lrouter_routing_protocol_redirect( return; } - if (op->cr_port) { - static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5); - VLOG_WARN_RL(&rl, "Option 'routing-protocol-redirect' is not " - "supported on Distributed Gateway Port '%s'", - op->key); - return; - } - /* Ensure that LSP, to which the routing protocol traffic is redirected, * exists. */ struct ovn_port *lsp_in_peer = ovn_port_find(ls_ports,
previously we prevented using the routing-protocol-redirect option on chassis-redirect ports. However the option works fine there, therefor we remove the limitation. Signed-off-by: Felix Huettner <felix.huettner@stackit.cloud> --- northd/northd.c | 8 -------- 1 file changed, 8 deletions(-)