VXLAN Puppet Module

If you’ve done any work with OpenStack or VMware NSX, you’ve likely come across VXLAN. It’s an encapsulation protocol that allows you to wrap layer 2 traffic in unicast UDP packets for traversal over a router network. The distribution of MAC addresses is done via. multicast. IPv4 or IPv6 can be used out of the box.
It’s a neat alternative to GRE tunnels in that it acts more like an MPLS/VPLS metro ethernet solution. What’s more, it’s been built into the Linux kernel for a while now. It’s just a shame that the only hardware VTEP (VXLAN Tunnel EndPoint) we have on campus is a Brocade VDX cluster we only use as L2 switches.
Anyhow, VXLAN seemed an appropriate solution to building a semi-isolated network for connecting Elasticsearch cluster nodes without exposing the service to the local layer 2 network. If I only relied on that, it would be security by obscurity but I do also have appropriate firewall and multicast controls in place as well.
As we’re in the modern world, I don’t like doing anything more than once. That’s where Puppet comes in, helping me build these Elastic Stack nodes for a syslog analysis experiment. Turns out there isn’t a VXLAN Puppet module.
Well, there is now. You can find it here and I’ll get it on Puppet forge in good time. It’s not my finest code (there’s not really enough sanity checking in there) but it’ll help you create multiple VXLAN interfaces in an automated fashion.
To make use of it, you configure a set of interfaces as follows:

class { 'vxlan'
    interfaces => {
        'tun0' => {
            'name' => 'tun0'
            'id' => 10,
            'group' => '239.0.0.1'
            'ttl' => 255
            'physical' => 'ens192'
            'address' => '10.10.10.10/24'
        }
        'tun1' => {
            'name' => 'tun1'
            'id' => 11,
            'group' => '239.0.0.1'
            'ttl' => 255
            'physical' => 'ens192'
            'address' => '10.11.11.11/24'
        }
    }
}

This creates two VXLAN interfaces – tun0 and tun1. We’ll take a closer look at tun0. tun0 is the interface name that’ll be used by your applications. It could be something like vxlan10 instead needs to be a single alphanumeric “word”.
The ID could almost be thought of as the VLAN number equivalent for VXLAN. There’s 2 to the power of 24 IDs to choose from. You shouldn’t run into collisions anywhere in a sensibly designed network using VXLAN.
The group is the multicast address used to pass addressing information between nodes. In this case, we’re using IPv4 backhaul. The TTL ties into this by determining how many routed hops the packets can travel across.
The physical field indicated the physical interface the VXLAN interface will use. This can be a bridge or aggregate interface if needs be.
The final field, address, defines the subnet and mask for the virtual interface. This is the IP address your applications will use for talking in the VXLAN network.
And that’s it. Run the ip a command to confirm the configuration of the interface once Puppet creates it.