Page MenuHomeFreeBSD

Fix for IPoIB over lagg
ClosedPublic

Authored by hselasky on Dec 17 2020, 5:59 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 23 2024, 11:57 PM
Unknown Object (File)
Feb 23 2024, 11:57 PM
Unknown Object (File)
Feb 23 2024, 11:45 PM
Unknown Object (File)
Feb 23 2024, 11:45 PM
Unknown Object (File)
Feb 23 2024, 8:50 PM
Unknown Object (File)
Feb 15 2024, 1:55 AM
Unknown Object (File)
Dec 14 2023, 8:23 PM
Unknown Object (File)
Dec 13 2023, 10:57 PM
Subscribers

Details

Summary

Need to update both link layer address and broadcast address when active link changes for IP over infiniband.
This is because the broadcast address contains the so-called P-key, which is interface dependent.

MFC after: 1 week
Sponsored by: Mellanox Technologies // NVIDIA Networking

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 35485

Event Timeline

hselasky edited the summary of this revision. (Show Details)

I suspect this is not how LL addresses are supposed to work, or rather, it breaks typical use scenario involving LL. For instance, hosts use router LL address for forwarding packets. If this address changes, you get connectivity issues on SLAAC-configured hosts until 1. router rtadvd notices link-level configuration change 2. rtadvd sens new RA packet. And I am not sure that typical implementations of rtadvd even monitor such changes, quick look at the FreeBSD implementation suggests that it does not.

I believe that the solution there is for LAGG to generate some own LL address and consistently use it regardless of which interface is active.

I believe that the solution there is for LAGG to generate some own LL address and consistently use it regardless of which interface is active.

That's why we only support failover. The LL addresses are "hardcoded" to each ib<N> interface. IPoIB does not work like ethernet unfortunately.

ok, assuming LL means link-level and not link-local.

This revision is now accepted and ready to land.Dec 29 2020, 1:29 PM
This revision was automatically updated to reflect the committed changes.