We use ipfire to run a /24 network on green and want to connect to a router of the network department of the University on red via a 192.168.0.24/31 transfer net, so red is assigned to 192.168.0.24, connecting to the other routers IP 192.168.0.25, with no other IPs within this transfer net. Our network department initially assigned us the /31 transfer net, saying that they are using this all over the place without any problem. It’s possible to configure 31-bit masks on ipfire, it just doesn’t work. According to https://tools.ietf.org/html/rfc3021 using a /31 transfer net should be possible, but ipfire seems to work with a minimum of /30 transfer net, suggesting that two addresses (network and broadcast) are always reserved, even though that is unnecessary in a network with only two hosts that only talk to each other. This is in contrast to saving IP addresses according to rfc3021. discussion under: https://community.ipfire.org/t/31-transfer-net/3197
(In reply to Klaus Huebler from comment #0) > It’s possible to configure 31-bit masks on ipfire, it just doesn’t work. Do you have any more details about this? I am not aware that we are generally blocking this. However, the RFC is a draft, and I would not recommend to do it this way.
I don't know whole the network code of IPFire. But I couldn't find a location in setup and the network start scripts, that reject to assign the "network address" to the red interface. The "broadcast address" would fit to the P2P network described. Thus it should work without modifications. As Michael wrote RFC3021 is a draft, written by Cisco and possibly implemented in their routers. If it is possible to communicate with these routers, we should leave it as is.
(In reply to Michael Tremer from comment #1) > > It’s possible to configure 31-bit masks on ipfire, it just doesn’t work. > > Do you have any more details about this? > I asked our isp, the network department of the University, to set up another /31 transfer net for testing with another ipfire installation. Result is that both IPs in this very limited network cannot ping each other. We double checked that all IPs, net masks (255.255.255.254), gateway an routing are setup correctly but the hosts cannot see each other. I am well aware that rfc3021 is only a request, a proposal, but a 20 year old proposal that does make perfectly sense to me in terms of saving IP addresses. This is what our isp keeps on telling us, combined with the hint that we are now unnessecarily granted a /30 transfer net - temporarily! So at the moment, ipfire works perfectly fine for us, but would it be wrong to work even better in terms of saving precous ip addresses? If any more information or testing is needed, I am happy to support and try to convince our network department to join in.
Thank you for our response. (In reply to Klaus Huebler from comment #3) > (In reply to Michael Tremer from comment #1) > > > It’s possible to configure 31-bit masks on ipfire, it just doesn’t work. > > > > Do you have any more details about this? > > > I asked our isp, the network department of the University, to set up another > /31 transfer net for testing with another ipfire installation. Result is > that both IPs in this very limited network cannot ping each other. We double > checked that all IPs, net masks (255.255.255.254), gateway an routing are > setup correctly but the hosts cannot see each other. Could you please send the output of "ip addr" with the /31 configuration? > I am well aware that rfc3021 is only a request, a proposal, but a 20 year > old proposal that does make perfectly sense to me in terms of saving IP > addresses. Not really. There are other protocols for point-to-point connections. Ethernet is designed differently. > If any more information or testing is needed, I am happy to support and try > to convince our network department to join in. Please, you can simply CC people to this ticket after they have registered for an account on https://people.ipfire.org.
Created attachment 779 [details] ip addr please find enclosed the output of ip addr
Hey Klaus, could you please try the following for me? In /etc/init.d/networking/red there is a line that has the word "broadcast" in it and a variable. Could you simply remove both and reboot the system? https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/initscripts/networking/red;hb=d328c232d7df7bf3f8582388f428c47a92fab0c1#l76 We seem to explicitly set the broadcast address, which makes sense in all other networks, but for /31 there obviously isn't a broadcast address. I think this could be causing the problem.
Hi Michael, line 76 of your example config looks just like mine which is: args="${args} ${ADDRESS}/${PREFIX} broadcast ${BROADCAST}" Do you want me to delete 'broadcast ${BROADCAST}' only, or the entire line?
(In reply to Klaus Huebler from comment #7) > Hi Michael, > > line 76 of your example config looks just like mine which is: > > args="${args} ${ADDRESS}/${PREFIX} broadcast ${BROADCAST}" > > Do you want me to delete 'broadcast ${BROADCAST}' only, or the entire line? Sorry if I wasn't clear. Just the 'broadcast ${BROADCAST}' part, please.
To make it more exactly, we could change args="${args} ${ADDRESS}/${PREFIX} broadcast ${BROADCAST}" to args="${args} ${ADDRESS}/${PREFIX}" if [ "${PREFIX}" != "31" ]; then args="${args} broadcast ${BROADCAST}" fi This leaves untouched the command for all other networks.
I do not think that the broadcast parameter is required at all any more. The kernel should be able to figure that out.
Hi again, I changed /etc/init.d/networking/red according to what Michael proposed in Comment 8 and tested it together with our network department this morning. Everything works fine. Everyone happy that it does? The question now is, if this will be implemented in one of the next updates or will /etc/init.d/networking/red be reset with every new version of ipfire?
Thank you for testing this. I can put a patch together and submit it to the development branch. This is currently preparing for Core Update 152, but 150 and 151 should not overwrite the script.
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=b67f02d512335f235710934bafe15db87067316d Please consider supporting my work with your donation at https://www.ipfire.org/donate.
This has been fixed in Core Update 152. https://blog.ipfire.org/post/ipfire-2-25-core-update-152-released