What about software assisted networking?

Freeimages.com/Ines Mad

Freeimages.com/Ines Mad

I don’t want a software defined network, I want a software-assisted network. I want tools that will help prevent common but straightforward mistakes and make it easier to baseline a network.

These tools have to work on real networks. Those messy, brownfield, imperfect networks that everyone maintains, but not everyone admits to owning. I’ve listed five tools below that I wish I had freely available when working on enterprise networks.

 

Right Window

Top of the list is a tool that prevents you from pasting the ‘right’ config into the ‘wrong’ window, and overwriting a live configuration. Sometime this mistake is called the ‘career ender’. It is rarely that bad, but there are only so many times your boss can say to senior management… ‘but they ARE really sharp engineers’.

The Right Window tool would force you to tag each your config text blocks with a target host. This tagged config block would be peer-reviewed and the tool would use expect/P-expect to paste those config lines to the right device.

Wingman

Wingman is an extension of Right Window and would warn me when I’m about to do other stupid or pointless things. Wingman would look at my proposed config block and/or pre-existing configuration and advise:

  • …. you’re creating an ACL and not applying it.. doofus!
  • …. you know you’re overwriting a route-map stanza instead of creating one… and the rollback action of removing it will compound your pain.
  • …. STP root is on one switch, but HSRP root is on another
  • …. watch out!  that rollback command will NOT undo your changes (e.g. no redistribute route-map!!)

Not like the other

The ‘not like the other’ would identify the pairs of network devices, and tell you the difference between them. This tool would compare simple things like:

  • VLAN definitions
  • HSRP Configs
  • Static Routes
  • ACLS applied
  • Single homed services

I like to image that you would run this tool with an argument of –can-I-safely-failover to which the inevitable answer would be …’no’.  There’s a serious point here. A ‘no’ answer is clear proof that crufty config is an operational threat, and thus gives you some leverage to get it cleaned up.

Will-it-flow

The will it flow tool would act as a network-wide version of Cisco’s Packet Tracer on ASA. This tool would take a src/dest L4 flow as an argument, and perform a trace route through the network. It would find ACLs in the path, tell you if those ACLS needed additional entries and provide the delta configuration.

Show-cdp-vlan

This tool will take an ip address or a switch port as an argument, and would:

  • Convert IP Address => ARP => MAC => Port
  • Get VLAN from Port, do ‘sh vlan id x’, glean ports from response
  • For each port list the cdp neighbours and or interface descriptions
  • Present the results in an easy to read table.

Sherpa Summary

Some of these tools may be simple and some may be more challenging, but all would help solve ‘real’ problems in Networking. I know that I’ve just scratched the surface here. Jump to the comments and tell me the tools you would love to have at your fingertips?

(Visited 1 times, 1 visits today)
Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInShare on RedditBuffer this pageShare on StumbleUpon

2 thoughts on “What about software assisted networking?

  1. I love your list – seems like a list of somebodywho is stuck with reality most of the time. People can argue it is short-sigted since “the technology” SHOULD NOT allow you to make my takes like that.also

    I believe Netdisco is a perfect example of show-cdpvlan tool – does everything you want. Even more!

    • Hey Pavel,
      I appreciate the tip about show cdpvlan, I’ll definitely check out NetDisco!

      I get your point about short-sightedness, it would definitely be better to enforce policies like configuration sync from Day-1. That said, almost every network has these issues to varying degrees.

      I’m not sure I agree on using ‘the technology’ to prevent you making configuration mistakes. My concern would be that you lose more than you gain here, in terms of flexibility. To me, the ideal starting point for a new network would be to run your new devices through a policy checker and prevent them going live without passing checks. During service, you could alarm on policy violations and auto-remediate the low-risk violations.

      I’ve seen this working well before, but it takes time to write down polcies and coding skills to enforce them. In the mean time, I’ll check out tools like NetDisco to see if it can help bridge the gap.

      Thanks for continuing the discussion.

      /John H

Leave a Reply

Your email address will not be published. Required fields are marked *