On 2/26/25 5:08 PM, Felix Huettner wrote: > 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. >
+1 I wasn't suggesting doing anything right now, especially not for 25.03. Regards, Dumitru > Thanks a lot, > Felix > >> >>> Best regards, Ilya Maximets. >>> >> >> Thanks, >> Dumitru >> > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
