On Wed, Feb 26, 2025 at 05:07:38PM +0100, Ilya Maximets wrote:
> On 2/26/25 16:50, Dumitru Ceara wrote:
> > On 2/26/25 4:47 PM, martin.kal...@canonical.com wrote:
> >> On Wed, 2025-02-26 at 15:44 +0100, Ilya Maximets wrote:
> >>> A peer of a switch can be another switch, so the port type has to be
> >>> checked. The missing check doesn't seem to lead to crashes, but it
> >>> leads to addresses of switch-switch ports not being advertised.
> >>
> >> Oh, interesting. Is the switch-switch connection introduced as part of
> >> your spine-leaf topology Ilya?
>
> Yep.
>
> >>
> >> I wonder if this affects also `build_{lb,nat}_connected_parsed_routes`
> >> [0][1]. We employ similar logic in these functions, but instead of
> >>
> >> HMAP_FOR_EACH (port, dp_node, &peer_od->ports)
> >>
> >> we iterate only router ports in peer_od
> >>
> >> for (size_t i = 0; i < peer_od->n_router_ports; i++)
> >>
> >> Do you think we need to update our logic in there too? E.g
> >>
> >> LR0 --- LS0 --- LS1 --- LR1
> >>
> >> If we redistribute NAT/LB on LR0, do we need to traverse all the way to
> >> the LS1 and search for connected routers in there too, to find LR1?
> >>
> >
> > On a similar note, I was wondering initially if we should do a full
> > traversal and advertise everything that's indirectly connected but I was
> > never convinced about it.
> >
> > However, for switch-switch connections that might be good to do
> > automatically indeed.
> >
>
> I'm not 100% sure about this. We do not leak a lot of information
> between directly connected switches sort of on purpose, to let them
> learn what they need to learn on their own via standard networking.
Hi everyone,
i just wanted to share my opinion on this.
I think we could define this easily as a limitation. Something like:
"Logical Routers can only redistribute routes from directly connected
Logical Routers or Logical Switches."
So a valid setup that combines both approaches would be:
LR0 <-> LS0 <-> LR1
^
/ \
v v
LS1 LS2
In that case you could still redistribute routes between LR0 and LR1.
Also LSPs of LS0 can be announced. LSPs of LS1 and LS2 would not be
individually announceable.
However the whole point of the spine-leaf setup seems to be to trade accuracy
for computational effort on the control plane then this would fit quite
well.
The above setup would still allow you to announce the routes of the LRPs
between LS0 and LR0/LR1. You can not use host routes for the individual
LSPs as that would violate the tradeoff you did with this topology in
the first place.
Thanks a lot,
Felix
>
> Is that necessary to redistribute those NAT/LB rules? i.e. does
> it affect correctness of the network if we do not? (I'm not familiar
> with that part of the code well enough)
>
> Also, such a logic will need to be implemented for ovn-ic daemon
> as well. Right? It does some route synchronization today for the
> routers directly connected to a transit switch, IIRC.
>
> >> [0]
> >> https://github.com/ovn-org/ovn/blob/dde3bdca2ddd82d0aaab6fad8638b4b321e82a43/northd/northd.c#L11478
> >> [1]
> >> https://github.com/ovn-org/ovn/blob/dde3bdca2ddd82d0aaab6fad8638b4b321e82a43/northd/northd.c#L11384
> >>
> >>
> >> Thanks,
> >> Martin.
> >>
> >
> > Regards,
> > Dumitru
>
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
