Saving configuration and feature module

[henriots]

Hello!

After using Puppet with NX-OS for a week now i've ran into some questions:

• What is the best way to save system configuration after a configuration run has completed? I know that modules don't save it's configuration neither I can find a module that does this. How have you implemented that part?

• Are you planning to add a module for features that checks which features have been enabled on a device? At the moment I'm using "cisco_command_config" module for setting features, which isn't the best way to do it.

• Is it possible to add such options under "cisco_interface" module:

1. setting "ip pim mode" ( for example ip pim sparse mode)
2. "ip ospf network point-to-point" and "ip ospf bfd" commands for L3 interfaces
3. mtu changing (mtu 9192 for example) for L3 interfaces
4. using "ip unnumbered" command for L3 interface address (also needs command medium p2p)
5. command "medium p2p" for L3 interface
6. creating vpc id options under port-channels

• Also if it's possible to update the agent installation guide for oac containers and adding how to run agent as a service every time it boots (it needs that vrf is set). This would be really helpful.

Other than that one bug I stepped onto and got a fast quickfix - all's been working really well, so thank you.

Henri

[mikewiebe]

@henriots I am currently traveling so sorry for the slow response.

• We have not created a module for saving configuration. Currently the only way to do this is using the cisco_command_config provider.

• The providers that require a feature to be enabled will automatically enable them. For example, cisco_bgp will check to see if feature bgp is set and if not, enable it and then configure BGP. Are there other features you are attempting to enable outside of the feature providers?

• We don't currently have the features you listed above for interface on our roadmap but we love contributions if you would like to contribute!

  • Add support for the missing feature(s) and submit a pull request for it to be integrated into the module.
  • https://github.com/cisco/cisco-network-node-utils/blob/develop/CONTRIBUTING.md
  • https://github.com/cisco/cisco-network-puppet-module/blob/master/CONTRIBUTING.md

• In our docs we don't officially claim support for OAC (https://github.com/cisco/cisco-network-puppet-module/blob/develop/docs/README-agent-install.md#service-management). Do you have a sample working startup script for OAC that you can share?

[henriots]

Thanks a lot for the answer!

Wasn't aware that it automatically installed required features, so I used cisco_command_config to activate features first.

I got my hands on two Nexus 5600 series andnow I'm playing around with them. At the moment I'm using Puppet agent in test mode for all the configuration management, so I wondered if someone has ran Puppet as service on OAC. One problem seem to be the need to put in command "chvrf" after reboot, because I only have management interface connected that this time. But I will dig in and will try to contribute.

[mikewiebe]

@henriots I should clarify that we don't officially support OAC persistence after reboot. The startup script could be modified to do something similar to (https://github.com/cisco/cisco-network-puppet-module/blob/develop/docs/README-agent-install.md#service-management-in-guestshell-using-systemd) to run the agent in the management vrf on startup.

[henriots]

@mikewiebe To get Puppet run at boot with N5K, I edited "/etc/init.d/puppet" as explained here (https://github.com/cisco/cisco-network-puppet-module/blob/master/docs/README-agent-install.md#svc-mgmt-bs)

Then also edited /sbin/ip and /usr/local/bin/chvrf , because commands "chvrf" and "vrf2num" are unknown and start-up fails. I bet you can set a PATH variable, which would be better solution.

/sbin/ip line 9 to: exec /usr/local/bin/chvrf "$@"

And then /usr/local/bin/chvrf line 16 vrfid=/usr/local/bin/vrf2num $vrf

And then to autostart Puppet service on boot:

chkconfig --add puppet
chkconfig --level 345 puppet on

I also added to DCOS_CONTEXT=2 to /etc/environment, but this is optional and not needed. You can find out correct number for your vrf using commmand "vrf2num". My case it was "2".

Maybe this is not the best solution, but it works. It might be good idea to delay Puppet autostart a bit, because 40Gb ports will take time to initalize on 5600, so first config run might fail.

[mikewiebe]

@henriots Thanks for sharing!

[henriots]

About the "saving configuration" option: At the moment, if someone is wondering, I've solved it with creating a seperate class (for example save_config) and using "cisco_command_config" functionality. After that I use Puppet stages to make sure the class is ran after stage "main" is completed.

[mikewiebe]

@henriots Thanks for sharing. Would you be willing to share a sample manifest?

[henriots]

Sure.

classes.pp

class save_config {
    cisco_command_config { "SAVE_CONFIG" :
        command => "
          copy running-config startup-config",
    }
}

stages.pp

class site::stages {
  stage { 'last':
    require => Stage['main'],
  }
}

site.pp

node 'n5k1' {
    #INCLUDE STAGES
    include site::stages

    #SAVE CONFIG
    class { 'save_config':  stage   => 'last' }
}