On Wed, Feb 26, 2025 at 04:48:05PM +0100, Dumitru Ceara wrote: > On 2/26/25 4:45 PM, Ilya Maximets wrote: > > On 2/26/25 16:30, Felix Huettner wrote: > >> On Wed, Feb 26, 2025 at 03:44:52PM +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. > >>> > >>> Fix that by checking the port type instead of assuming. > >>> > >>> The issue is a result of two features being developed at the same time > >>> and the code not being re-checked before merging the routing patches. > >> > >> Thanks a lot, thats a nice one. > >> > >> Acked-by: Felix Huettner <felix.huettner@stackit.cloud> > > > > BTW, this code also advertises addresses of remote ports in case of > > interconnect, IIUC. Is that supposed to be happening? Or should > > we not advertise them, as they are not local to the AZ? > > > > In my opinion that's fine. They are reachable and therefore routes for > them can be advertised. We could maybe extend the 'tracked_port' > support to transit switch ports so that we advertise the routes for > these IPs with higher preference on the chassis/AZ where they reside. > > What do you think Felix?
I would agree that we should announce them. On the route preference side i am unsure how this should work. But probably that is just something for the future. Currently we differenciate between two cases for the route preference. We just check if a given port is lokal to the current chassis and then give it a better preference than otherwise. In the IC case i think we would be generally worse from a preference perspective. So traffic that should go to a given IP should rather go to the OVN cluster that actually hosts that IP than needing to traverse an IC link. However even if we need to traverse an IC link (because the IP is otherwise not reachable) there might be different chassis that are more or less appropriate. A chassis that has ovn-is-interconn=true is probably better than one that does not have that set. But i don't think we should touch this right now. I would rather wait until someone actually has a usecase for this to try to figure out how this needs to work. People can do a lot of things e.g. on the FRR config side, so maybe just leaving it to there is the more generic way. Thanks a lot, Felix > > > Best regards, Ilya Maximets. > > > > Thanks, > Dumitru > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
