dumbnetworkautomation

A lot of people outside of the network space are quite surprised to find out that network devices don't always support LDAP. There are convenient reasons for this. Doing Authentication Most devices will support RADIUS with varied levels of "support". For others, they will support TACACS+ as well as RADIUS. Finally, a subset of devices will support LDAP. RADIUS You have to map in the dictionary for the appropriate attributes. Example, Juniper, Cisco, etc have their own special attributes. FreeRadius keeps a good list, but it may require occasional additions for other vendors TACACS+ Is a pile of shit, but a convenient pile of shit for cisco environments. Most people use shrubbery.net's tac_plus or Cisco ACS. ACS is well known for being horrible at the worst times. Also, building your own TACACS+ box means it will last until the apocalypse unlike ACS. Why not just LDAP everywhere? Three easy reasons:  LDAP is usually maintained by someone els...

So, you wanna begin in automation? Begin with your changes and how you develop and test. The biggest mistake network admins regularly make is to merely "think" about problems and then develop solutions by "thinking" and committee. The figuring is, it will all work if we just think enough about it. This is nonsense. You will make mistakes relying on eyes and perfection. Let machines do their thing. Change analysis I have a need to sling some routes to another part of the network. Will it break stuff? By some work in determining the scope of the proposed changes, one can note the assumptions that take place in the change. Example, I will be doing redistribution from BGP into OSPF and I assume that all prefixes from BGP from BGP today originate on two routers. How can I verify? Another (crappy) example, I believe RIP route distribution contains no filtering anywhere. How can this be checked? Decomposing the change and verifying state Consider a situa...

I had a request sent to me the other day to make a script push some config with the hostname of the node included. Pretty basic thing to do. I was further constrained to use the FortiManager script runner to make this work. As usual, CLI-like scripting sucks and the magic behind the scenes made things more difficult. FortiManager's Role Big HA pile of shit to sync configs with templates. Also has a script runner (used by the config pushes). The scripts are handled through a component called "deployment manager". Relevant debugs: diagnose debug application depmanager -1 -> Not so useful for TCL, good under-the-hood look diagnose debug dpm conf-trace enable -> Will show you SSH connection stuff. More useful IMO. FortiManager holds SSH credentials for the device. It isn't like, even though FortiManager is trusted to play with config, FortiManager can magically login via SSH. This seems like quite a stupid design, but that is the situation we'...

Proprietary CLIs are often considered the "normal" way of interacting with IP network devices. These CLIs allow for bad design with respect to automation. CLI transport methods and notes Vendors regularly shit the bed with their CLI behaviors. Some of the components worth looking at are transport, authentication, the TTY, and error handling. Transport Some things only do telnet? In 2017?! Meh, yes, some. Console You need a commserver. Better to write everything against this than trying to mess with shell scripts. Problem is: you have to adjust settings carefully for the serial link to work well. Console is the most manual idiotic shit to write for. It should be treated as such, used for basic provisioning tasks only. SSH This is usually what we want. Two basic modes of operation: pty allocation or an "exec" type. In PTY, shitty expect-like garbage will be necessary. In exec, you have the POSSIBILITY that return codes actually come back and d...