BIG-IP with /31 self-ips

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