logical interface as next hop for routes on cluster members that DO NOT use VIPs in different subnet

[Vladimir]

I see the mention of the logical interfaces being used when VIPs belong to a different subnet and we have to use scopelocal to enable routing through the cluster members.

I am looking at one of my client's configs and am seeing default routes as well as internal static route configured with next hop logical interfaces.

According to our documentation this option should be "Use this option only if the next hop gateway has an unnumbered interface."

What does constitute an unnumbered interface from the cluster's perspective? I am pretty sure that there is an L3 switch downstream or a VLAN interface with IP.

Cluster does not complain about this setup, but I wander if it is an acceptable configuration.

Please share the wisdom.

Thank you,

Vladimir

[PhoneBoy]

Technically it's valid.
However, when I set my default route as an interface route (instead of a next hop IP) hooked up to my cable modem, my arp cache filled up pretty quick.
So it might create a problem for the default route.

[Vladimir]

That's what I was thinking may happen. I'll take a look at their arp cache tomorrow to see how it looks.

[PhoneBoy]

If the arp cache starts filling up, the Internet will appear to "not work." Ask me how I know 😬

[Jerry]

unless your interface-based route has a trunk on another end with relevant vlans towards the default next-hop 🙂 then it should be all good. all depends on the design really Vlad.

[Timothy_Hall]

Exactly! I have seen this situation too Dameon, enough that it got mentioned in my book:

Spoiler

Another problematic situation that can exhaust the available ARP cache space on the firewall no matter how high you crank it is the following: adding the firewall’s default route with a local network interface defined as the next hop, instead of using an actual gateway IP address as a next hop. Most of the time trying to do this will not work at all, but if proxy ARP is enabled on your upstream Internet router, it will cheerfully answer ARP requests for every single IP address on the Internet and reply with its own MAC address. Internet connectivity will be fine until the firewall’s ARP cache is exhausted at which point the “rolling outage” behavior will begin and performance will be absolutely terrible. To check for this condition on your firewall run netstat -rn | grep ^0.0.0.0 . If the gateway address (second column) is listed as 0.0.0.0 , you will most definitely need to fix that during a maintenance window. Remove the network interface next hop and add the correct next hop gateway IP address corresponding to your upstream Internet router.

[Vladimir]

I had a limited time to figure out what was going on on that cluster, but arp overflow did not appear to be the issue.

Running #arp -a | wc -l returned 711 on active cluster member and something like 19 on the standby.

This cluster was slated for the memory upgrade and redux in newly created R80.20 environment. I did change the next hop for the default route to the IP address.