Redistribute Neighbor - Silent hosts?


I was looking at some different options for getting rid of the current layer 2 extension that exists today in a network, and two options I've been mulling over are redistribute neighbor and RoH. RoH is going to be a little challenging for us, since it's still a heavy Windows environment and Windows isn't supporting unnumbered presently (I think.)

The second option I was looking at was redistribute neighbor. This appeared to be a slightly more attractive environment with potentially more flexibility for the current situation of Windows hosts, but I had some specific questions around the implementation of it:

The discovery mechanism in LISP ESM is pretty close to redistribute neighbor. In my experience, ESM has typically struggled with discovery of things like load balancer VIPs, SQL cluster IPs, secondary IPs on servers that may not speak unless spoken to. Is there a way to work around this with the current iteration of redistribute neighbor? If not, any plans to do something like offer the ability to tether the address/MAC to a particular leaf and propagate that throughout the fabric? Just a spitball there, but I'm trying to get to the bottom of potential issues with discovery since I'm seriously considering the solution.

5 replies

Userlevel 4
Ryan, I saw your Reddit post on this topic and I had been meaning to comment there but time is never on my side 🙂
The idea of a silent host is certainly a concern; to combat that, we recommend the configuration of an arp configuration of some kind on the host to send gratuitous arps to the gateway in a link-up event (you could even add them in a cronjob for additional assurance). We show the configuration in our "Configuring a Dual-Connected Host" scenario in the documentation --> https://docs.cumulusnetworks.com/disp...
I'll reproduce that host config here:
'''
# /etc/network/interfaces on an Ubuntu Host
# The loopback network interface
auto lo
iface lo inet loopback
auto lo:1
iface lo:1
address 10.1.0.101/32
auto eth1
iface eth1
address 10.1.0.101/32
post-up for i in {1..3}; do arping -q -c 1 -w 0 -i eth1 10.0.0.11; sleep 1; done
post-up ip route add 0.0.0.0/0 nexthop via 10.0.0.11 dev eth1 onlink nexthop via 10.0.0.12 dev eth2 onlink || true
auto eth2
iface eth2
address 10.1.0.101/32
post-up for i in {1..3}; do arping -q -c 1 -w 0 -i eth2 10.0.0.12; sleep 1; done
post-up ip route add 0.0.0.0/0 nexthop via 10.0.0.11 dev eth1 onlink nexthop via 10.0.0.12 dev eth2 onlink || true
'''
These arping statements can be modified to work for your environment.
Here is an additional slide that I built as part of a Redistribute Neighbor module for one of our upcoming Bootcamp Education classes. This slide helps to compare the ROH approach with Redistribute Neighbor... I'd like to see it added to our Docs eventually as well but haven't had a moment to submit it.
Hope this helps!

Thanks Eric, that's good info. I will definitely need to take that into consideration. Because Windows doesn't support unnumbered, RoH gets a little prohibitive it seems (unless I want to start renumbering) when I've got a long line of servers contiguously numbered into a class C - kind of destroys the /31 boundary. Maybe we should start demanding it as a feature enhancement. 😉
Userlevel 4
Ryan wrote:

Thanks Eric, that's good info. I will definitely need to take that into consideration. Because Wi...

I wouldn't think that would be a stopping point, these IP addresses could just as easily be part of a /24 (class C) on the server. The upstream leaf would see the ARP from the server and announce a /32 which would be a bit more specific for other nodes to reach the host more directly throughout the datacenter 🙂
Ryan wrote:

Thanks Eric, that's good info. I will definitely need to take that into consideration. Because Wi...

Hmm. I'm intrigued. Trying to wrap my mind around that. Let's say I use 10.1.1.2/31... .2 is assigned to my server, and .3 is assigned to the leaf. What happens in a scenario where I've also got 10.1.1.3 on a server that may be connected to that same leaf? Is the leaf going to see the ARP from the .3 server, honor it as a more specific route than the "connected" /31, and forward traffic appropriately? Any adverse impact there to the .2 server? I could probably lab that up. Interesting thought. I guess the more specific route should win if it's calling the ARP a /32. I'm just curious what happens when it tries to forward to .3 (which it believes to be itself.)
Userlevel 4
Ryan wrote:

Thanks Eric, that's good info. I will definitely need to take that into consideration. Because Wi...

I would do a /24 on the host. The host will then know how to access everyone via the default route. In either case the leaf always advertises a /32 due to RDNBRd daemon which listens for ARPs received from the host. auto lo iface lo auto eth0 iface eth0 address 192.168.1.1/24 post-up ip route add default via 192.168.1.254 post-up for i in {1..3}; do arping -q -c 1 -w 0 -i eth0 192.168.1.254; sleep 1; done post-down ip route del default via 192.168.1.254

Reply