Category: configuration

This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.

Imagine a small bank deciding in their infinite wisdom (in reality: because their CIO attended a conference organized by a database vendor) to implement their banking software by teaching bank tellers how to type SQL transactions by hand.

For example, to transfer money from one account to another account, a bank teller could simply type:

My first Cisco router was a blade for a Cabletron modular hub (anyone remembers what hubs were or a company named Cabletron?). We plugged it in, I read the documentation, figured out I had to type conf t and was faced with a blinking cursor staring back at me from an empty line.

A few years later I was invited to beta test Cisco software release 9.21 (it wasn’t called IOS yet). The best feature it had was the awesome configuration CLI with context-sensitive prompts and on-demand help.

This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.

One of my readers sent me this question:

Would you write about methods for reverting from expected new state to old state in the case automation went wrong due to (un)predictable events that left a node or network in a limbo state betwixt and between.

Like always, there’s the easy and the really hard part.

Here’s a trick question:

• Imagine you have a network running IPv4 and VPNv4 services;
• You want to use neighbor next-hop-self on IPv4 sessions, but not on VPNv4 sessions;

To implement this request you use the following configuration commands (plenty of other commands removed because they don’t impact the results):

router bgp 64500
 address-family ipv4
  maximum-paths ibgp 32
  maximum-paths 32
  neighbor 192.168.0.4 next-hop-self
  neighbor 192.168.0.1 next-hop-self
 address-family vpnv4
  maximum-paths ibgp 32
  maximum-paths 32
  no neighbor 192.168.0.4 next-hop-self
  no neighbor 192.168.0.1 next-hop-self

Try to figure out what the end-result will be without connecting to a router or reading the rest of this blog post.

Ok, here’s what totally threw me off (and wasted an hour of my life): next-hop-self is removed from neighbors in the IPv4 address family. Here’s why:

• There is no maximum-paths ibgp command in VPNv4 address family;
• The moment you enter maximum-paths ibgp command the configuration parser exits the address-family vpnv4 context and enters router bgp context;
• Because the ipv4 address family is the default context within router bgp (for legacy reasons) all the subsequent commands are executed within the address-family ipv4 context removing next-hop self from neighbors in IPv4 address family.

No wonder David Barroso named his library NAPALM (you’ll find the full story in this or this podcast).

Henk left a wonderful comment on my SDN will not solve real-life enterprise problems blog post. He started with a bit of sarcasm:

SDN will give more control and flexibility over the network to the customer/user/network-admin. They will be able to program their equipment themselves, they will be able to tweak routing algorithms in the central controller. They get APIs to hook into the heart of the intelligence. They get more config-knobs. It's gonna be awesome.

However, he thinks (and I agree) that this vision doesn’t make sense:

A recent well-publicized network outage prompted someone to start collecting fat-finger horror stories, and dozens of networking engineers were quick to chime in. Enjoy!

In June 2013 I wrote a rant that got stuck in my Evernote Blog Posts notebook for almost two years. Sadly, not much has changed since I wrote it, so I decided to publish it as-is.

In the meantime, the only vendor that’s working on making generic network deployments simpler seems to be Cumulus Networks (most other vendors went down the path of building proprietary fabrics, be it ACI, DFA, IRF, QFabric, Virtual Chassis or proprietary OpenFlow extensions).

Arista used to be in the same camp (I loved all the nifty little features they were rolling out to make ops simpler), but it seems they lost their mojo after the IPO.

Like every recently designed fabric configuration/management platform, NEC ProgrammableFlow controller supports numerous configuration interfaces, including CLI, GUI, web-based configuration, REST API and OpenStack plugin. For more details, watch this part of the ProgrammableFlow Technical Deep Dive webinar.

Daniel left a very relevant comment to my convoluted BGP session shutdown solution:

What I am currently doing is using EEM to watch my tracked objects and then issuing a neighbor shutdown command. Is there a functional reason I would not want to do it that way, and use the method you prescribe?

As always, the answer is “it depends.” In this case, the question to ask yourself is: “do I track configuration changes and react to them?”

read more see 7 comments

read more see 3 comments

If you have to troubleshoot routers with long configurations, you're probably as fed up with the slow response of the show running-config command as I am. Unfortunately, there's not much you can do; the running configuration is reverse-engineered from various memory variables every time you ask for it and that process simply takes time if you've configured many parameters.

IOS release 12.2(33)SRB has introduced a fantastic feature: router configuration partitioning. The early seeds of this idea are already present in mainstream IOS releases. For example, you can display the configuration of a single interface, all class-maps or all policy-maps. The configuration partitioning gives you the ability to display access-lists, route-maps, static routes, router configurations ...

Numerous comments to the "terminal exec prompt" post told me that it might be good to review the line/terminal configuration rules:

• If you want to configure a permanent line characteristic (for example, international), you should do so in the VTY configuration (see also how the VTY configurations are merged);
• If you want a temporary change in the characteristic of your current line (VTY or console), use terminal characteristic to enable it or terminal no characteristic to disable it.

Marcus Jensen asked me a very interesting question:

I want to send 3 lines of configuration to a remote router, but I know the first line will kill my connection. Can I save these 3 lines of code to a text file, and then issue a Tcl command to add those to the running config?

The solution is much simpler and does not have to involve Tcl at all. The copy something system:running-config command merges the configuration commands in the source file with the current running configuration.

You can store the configuration commands you want to execute in a local file (even in NVRAM) or you could execute them directly off a file server (using HTTP, FTP, TFTP or SCP protocol).

This article is part of You've asked for it series.