On 2/26/25 9:06 PM, Ilya Maximets wrote:
> On 2/26/25 17:28, Felix Huettner wrote:
>> 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.
>
> In the spirit of the spine-leaf topology, what if we advertise FDB entries
> learned on the LS0 ? This would even work for the interconnect, since we
> learn from remote ports on transit switches now.
>
> Is that a reasonable thing to do?
>
We don't advertise FDB entries (yet). But when we add support for that
(for EVPN for example) that might be a good thing to do.
> What about FDB entries learned from localnet or other ports with 'unknown'
> addresses?
>
Same here.
Regards,
Dumitru
> Best regards, Ilya Maximets.
>
>>
>> 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
