By Lou Nardo, Director of Product Marketing at Infoblox
Making a change to a router, switch, or firewall can impact the network function or downstream devices. Before moving forward with a change, you need to know what is connected, and dependent, upon the device or interface. In addition, “how” the device is connected can often have significant implications, as network devices don’t act in isolation. You can assemble a collection of routers and switches in infinite combinations of topologies to create different networks for different purposes. That’s why it’s called a network. The topology gives the network function and purpose.
So doesn’t it follow that a network control system should understand and act in the context of topology? Well most don’t, which severely limits your ability to truly control your network with any efficiency.
I can clearly remember the first customer to ask for help with this challenge. After a fair amount of effort, investment, and iteration with customers, Infoblox is now the only vendor on the market who can perform network analysis and change automation in the context of topology information.
When you consider defining a network construct, interdependence among multiple devices needs to be top of mind. It’s inevitable network engineers will often open sessions with multiple devices simultaneously, before and during changes to trunks or other key network fabric configurations. Since committing a change might accidentally isolate part of the network if handled incorrectly, it’s critical to ensure both ends of a trunk are behaving as expected prior to any changes.
If you do that as a person, shouldn’t a network control system do the same? Our customers insisted on it.
Here are some examples we’ve heard from customers…
- Dynamically maintain Interface description fields. Simply run a recurring job in NetMRI which processes interface by interface in your managed network infrastructure. The job will look up the interface neighbor via NetMRI’s Topology Model API, then audit or write the interface description field based on the discovered topology and your specific syntax, to make sure interface description fields are kept up to date and accurate… automatically. Perhaps run daily or weekly.
- Automatically audit trunk port settings (example should be posted to community site downloads shortly) – script can review neighbor device type and confirm trunks are set where needed and expected.
- Audit MTU settings (example should be posted to community site downloads shortly) – script can look up and instantiate SSH sessions to both ends of a neighbor link and confirm MTU values are set correctly on both sides of the trunk.
Infoblox is in the best position to help our customers truly control the complexities of a network. Network automation is different than server automation. It requires network-specific capabilities. We are committed to making network control a reality and continue to value your experiences and insight into how we can help. Please post ideas and challenges to our site for discussion!