Many Puppet features originate from community contributions. One of the most versatile and long-standing contributors is definitively Brice Figureau. When there still wasn't anything around on the topic, he proposed an approach to the network device management, which has been the foundation for the approach based on the proxy mode we mentioned earlier.

In his blog post at http://puppetlabs.com/blog/puppet-network-device-management, he introduced the puppet device application in Puppet 2.7 to manage external devices where Puppet cannot run natively.

This command uses /etc/puppetlabs/puppet/device.conf, by default, as the configuration file. Here, the hostnames of the equipment to manage, their type, and the method to connect to them can be placed. A sample entry may look like the following code:

[switch01.example42.lan]
  type cisco
  url ssh://puppet:[email protected]/

[router01.example42.lan]
  type cisco
  url telnet://puppet:[email protected]/?enable=enablepassword

With such a file in place, we can use the puppet device command on the host we want to act as proxy for the configuration of remote devices.

The first time this command is executed, it creates certificates for all the devices we have defined in device.conf. These certificates have to be signed by the Puppet Master as normal node's certificates.

The implementation provides two core native types: interface and vlan, with a provider to manage Cisco IOS-based devices. We can execute puppet describe interface / vlan for details on their attributes.

To manage switch interfaces (speed and duplex, VLAN, port mode (access/trunk), description, and so on) we can write resources like this:

interface { 'FastEthernet 0/1':
  description => "Server ${server_name}",
  mode        => access,
  native_vlan => 1000,
  duplex      => auto,
  speed       => auto,
}

To manage router interfaces, we can use the following code:

 interface { 'Vlan12':
   ipaddress => [ "192.168.14.14/24", "2001:2674:8C23::1/64" ]
 }

To manage VLANs (their ID is the same title) is enough a resource as follows:

vlan { '105':
  description => 'DMZ',
}

These resources can be declared in nodes definitions that match the device names specified in device.conf. When puppet device is executed, it behaves like puppet apply: it retrieves facts from the network device, then retrieves a catalog from the Puppet Master for the locally configured devices and runs it providing a normal transaction report, with the notable difference compared to a normal Puppet run, that the providers that implement the preceding types perform configurations on remote network devices.

On Puppet's core source, there is currently just the provider for Cisco devices and supported transport methods are just telnet and ssh, but we can find modules that use the same approach and implement it on different devices.

For example, Puppet Labs' F5 module https://forge.puppetlabs.com/puppetlabs/f5 (Puppet Enterprise is required for installation), introduces several F5 specific resource types, but is based on the network device application and has similar usage patterns. A sample entry in device.conf might look like the following code:

[f5.example42.lan]
  type f5
  url https://username:[email protected]/

Note that, in this case, the network device type is f5 and the access is done via https.

A further demonstration of Puppet expandability is a module available at https://github.com/uniak/puppet-networkdevice written by two community members, Markus Burger and David Schmitt, which provides wider support for Cisco devices and implements, over the Puppet device application, a new device type (cisco_ios). A sample entry in device.conf looks like the following:

[switch01.example42.lan]
  type cisco_ios
  url sshios://user:[email protected]:22/?$flags

The module features a more complete set of resource types to manage different elements of a Cisco IOS configuration (access lists, SNMP configuration, interfaces, VLANs, users, and so on)

Something to consider is that the Puppet agent that normally runs as a service on a node does not implement any device activity. To manage the configured devices on a regular basis we need to place, on the proxy host, a cron job that executes puppet device.

A proxy-based approach, based on puppet device, has the benefit of letting us manage virtually any device that in some way allows programmatic remote configuration but has some cons, related to scale, authentication management, and the facts that it behaves differently to any other Puppet command.

You can go a step further when Puppet runs natively on the device to be managed and can apply configurations directly. This is an emerging field where we are already seeing some implementations and which will probably grow with the same concept of the software-defined data center.

node 'switch01.example42.lan' {
  # Definition of the Device, needed for each device
  cisco_device { 'switch01.example42.lan':
    ensure => present,
  }

  # Configuration of a VLAN on an access interface 
  cisco_interface { 'Ethernet1/5':
    switchport  => access,
    access_vlan => 1000,
  }

  # Configuration of a VLAN
  cisco_vlan { '1000':
    ensure    => present,
    vlan_name => 'DMZ',
    state     => active,
  }
}

node 'switch02.example42.lan' {

  # A single netdev_device resource must be present
  netdev_device { $hostname: }

  # Sample configuration of an interface
  netdev_interface { 'ge-0/0/0':
    admin => down,
    mtu   => 2000,
  }

  # Sample configuration of a VLAN
  netdev_vlan { 'vlan102':
    vlan_id     => '102',
    description => 'Public network',
  }

  # Configuration of an access port without VLAN tag
  netdev_l2_interface { 'ge-0/0/0':
     untagged_vlan => Red
  }

  # Configuration of a trunk port with multiple VLAN tags
  # And untagged packets go to 'native VLAN'
  netdev_l2_interface { 'xe-0/0/2':
     tagged_vlans  => [ Red, Green, Blue ],
     untagged_vlan => Yellow
  }

  # Configuration of Link Aggregation ports (bonding) 
  netdev_lag { 'ae0':
     links => [ 'ge-0/0/0', 'ge-1/0/0', 'ge-0/0/2', 'ge-1/0/2' ],
     lacp  => active,
     minimum_links => 2
  }
}