Forum Discussion

rafaelbn_176840's avatar
rafaelbn_176840
Icon for Altocumulus rankAltocumulus
Sep 06, 2018

BIG-IP with /31 self-ips

Hello devs! How's everybody doing?

New client, new design! This time an ISP wants to connect a BIG-IP just like a router, with only point-to-point addresses, BUT he wants to use /31 prefixes since this is their default for the entire DC.

The topology would be something like this:

I managed to create both selfs with the /31 but when I go to tmsh and try to ping both routers, the CLI complains that to ping .1 and .7 I have to append a "-b" since it's a broadcast.

If I append it, I can successfully ping the routers.

root@(bigip1)(cfg-sync Standalone)(Active)(/Common)(tmos) ping 192.168.0.7
Do you want to ping broadcast? Then -b
root@(bigip1)(cfg-sync Standalone)(Active)(/Common)(tmos) ping -b 192.168.0.7
WARNING: pinging broadcast address
PING 192.168.0.7 (192.168.0.7) 56(84) bytes of data.
64 bytes from 192.168.0.7: icmp_seq=1 ttl=255 time=3.22 ms
64 bytes from 192.168.0.7: icmp_seq=2 ttl=255 time=1.22 ms
^C
--- 192.168.0.7 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1714ms
rtt min/avg/max/mdev = 1.223/2.223/3.223/1.000 ms

Is this the normal behavior? It seems to me that either TMOS or the linux Kernel is not getting the /31 right.

Has anyone tryed this kind of design?

Thanks! Rafael

application delivery
BIG-IP
TMOS

4 Replies

Sort By
  • Lee_Sutcliffe's avatar
    Lee_Sutcliffe
    Icon for Nacreous rankNacreous
    Sep 06, 2018

    /31 addresses are typically used for point-to-point links on non-broadcast networks. They only have two possible addresses so a broadcast would be pointless.

     

    From RFC 3021: https://tools.ietf.org/html/rfc3021

     

    In current practice, numbered Internet subnets do not use longer than a 30-bit subnet mask (in most cases), which requires four addresses per link - two host addresses, one all-zeros network, and one all-ones broadcast. This is unfortunate for point-to-point links, since they can only possibly have two identifying endpoints and don't support the notion of broadcast - any packet which is transmitted by one end of a link is always received by the other.

     

    Can you confirm the subnet mask you have configured on your interface as you shouldn't have a broadcast address with a /31 mask. Sounds like you may have configured a mask of 255.255.255.252 and not 255.255.255.254

     

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Sep 06, 2018

    Bonus if it works, but it probably isn't the most technically correct design. If you switch to a /30 you'd have 2 usable addresses per subnet.

     

  • rafaelbn's avatar
    rafaelbn
    Icon for Cirrostratus rankCirrostratus
    Sep 06, 2018

    Here are my findings so far:

    1- You cannot create a route pointing to the other end when using /31. I don't know why. The error messages that big-ip spits is related to a configuration error:

    root@(bigip1)(cfg-sync Standalone)(Active)(/Common)(tmos) create net route DEFAULT network 0.0.0.0/0 gw 192.168.0.1
01070712:3: Cannot create static route: 0.0.0.0/0 gw 192.168.0.1 on interface  in rd0 - netlink error: 22 (Invalid argument)

    From the log messages list, this message is related to a configuration exception.

    01070712 : "Caught configuration exception (%d), %s."
Location:
/var/log/ltm

Conditions:
MCPD logs this error in response various configuration issues that might arise while attempting to process a transaction. The nature of the issue could be caused by any number of runtime scenarios, for example, "can't get class information from schema repository", "invalid MAC address", "Can't get class definition while retrieving sub classes", etc.

Impact:
MCPD will stop processing the current transaction and roll back to the last valid state.

Recommended Action:
Depending on the message being logged, modify the configuration that caused the error, and then attempt to submit the transaction again.

    I was able to circumvent this error by:

    A- Creating a pool with the default gateway inside and point the default route to the pool. The only thing is that monitoring at the node and pool level was not working. I think it's connected with the same error while trying to ping (you have to use the -b option).

    B- Creating a default route pointing to the VLAN. Which could potentially be very bad, because the BIG-IP send ARP requests for every remote IP and it's ARP table could become huge! Another thing is that the remote L3 device have to have proxy-arp enabled, otherwise it won't solve and the traffic will not be routed properly. Below is the capture to illustrate this behavior:

    root@(bigip1)(cfg-sync Standalone)(Active)(/Common)(tmos) tcpdump -nni 0.0 host 192.168.0.0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 0.0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:24:13.704958 ARP, Request who-has 172.16.99.1 tell 192.168.0.0, length 35 out slot1/tmm0 lis=
11:24:14.704389 ARP, Request who-has 172.16.99.1 tell 192.168.0.0, length 35 out slot1/tmm0 lis=
11:24:15.704240 ARP, Request who-has 172.16.99.1 tell 192.168.0.0, length 35 out slot1/tmm0 lis=
11:24:16.704544 ARP, Request who-has 172.16.99.1 tell 192.168.0.0, length 35 out slot1/tmm0 lis=
11:24:17.704437 ARP, Request who-has 172.16.99.1 tell 192.168.0.0, length 35 out slot1/tmm0 lis=

    Soo... To sum it up, I think (at least for now), it's safe to assume that using /31s for self-ips is not a good ideia since you can corner yourself on some really odd caveats.

    If anybody have any documentation about this type of design I would love to see it.

    Feel free to comment guys.

    Thanks! Rafael