Skip to content
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

Issues with service IPs on loopback interfaces #194

Open
BarbarossaTM opened this issue Apr 3, 2020 · 1 comment
Open

Issues with service IPs on loopback interfaces #194

BarbarossaTM opened this issue Apr 3, 2020 · 1 comment

Comments

@BarbarossaTM
Copy link

Hi,

we tried to set up Jitsi on boxes which are connected to an IP Fabric and therefore have their system / service IP configured on the loopback interfaces. It turns out for some reason there are explicit checks in the code to ignore IPs configured on the loopback interfaces so the following configuration does not work:

auto lo
iface lo inet loopback
    address 192.0.2.23/32
    address 2001:db8::2342/128

Digging through the code it seems you are check for the usual loopback interface where 127/8 + ::1/128 lives. So it turns out the following config does work (when announcing the IPs into the fabric as well):

auto lo
iface lo inet loopback

auto yolo
iface yolo
    link-type dummy
    #
    address 192.0.2.23/32
    address 2001:db8::2342/128

Is there any reason to not allow IPs configured on the loopback interface? Why does the library care about the network config on the host?

Best
Max

@bgrozev
Copy link
Member

bgrozev commented Apr 4, 2020

I think the code was meant to avoid needlessly listening on and advertising loopback addresses. We've just never used it in a situation where a loopback interface has useful addresses. A patch to allow use of loopback interfaces would be welcome, just put it behind a property and preserve the current behavior as default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants