-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"interface not ready" on XFRM network interface (Linux, IPsec) #176
Comments
For the sake of verifying the issue, such an interface can easily be instantiated with iproute2: e.g. |
I'm not sure if you're seeing the same result that I am. Can you please try to capture the debug output of the latest master, running As to what FRR is doing differently: I did manage to make radvd trivially send RAs on the interface, despite the The trick for me: The RA protocol fundamentally has to know where to send the announcements: either a multicast address, or specific recipients (solicited or unsolicited). without multicast:
Key line:
If I do enable multicast on the interface:
|
@cluck ping? |
There is a relatively new type of Linux network interface named "XFRM", that helps with directing network traffic to specific IPsec policies via routing, by "hiding" the policies behind such interfaces. This greatly simplifies VPN server configurations.
Unfortunately, radvd refuses to operate on such interfaces because it is fooled about the operational state of such an interface, because Linux reports it to be in an "unknown" state.
I'm not entirely sure what to propose for fixing the problem. Iproure2 effectively reports "state UNKNOWN", but then also UP,LOWER_UP, and no NO-CARRIER for the interface. And I have FRR happily proceeding with sending router-advertisements on the same interface, so that I think radvd might need some improvement in the
ensure_iface_setup
function in radvd/send.c.The text was updated successfully, but these errors were encountered: