Blog Posts in December 2016

How I Started Hating Automatic Context Switching in Cisco IOS

Here’s a trick question:

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).

see 6 comments

Push Configuration Snippet to a Bunch of Cisco IOS Devices

As I was trying to automate configuration deployment in a multi-router Cisco IOS lab, I got to a point where the only way of figuring out what was going on was to log commands on Cisco IOS devices. Not a big deal, but I hate logging into a dozen boxes and configuring the same few lines on all of them (or removing them afterwards).

Time for another playbook: this one can push one of many (configurable) configuration snippets to a group of Cisco IOS devices defined in an Ansible inventory file.

Interesting? Want to do something more complex? Join the Network Automation online course.

add comment

Generating OSPF, BGP and MPLS/VPN Configurations from Network Data Model

Over a month ago I decided to create a lab network to figure out how to solve an interesting Inter-AS MPLS/VPN routing challenge. Instead of configuring half a dozen routers I decided to develop a fully-automated deployment because it will make my life easier.

I finally got to a point where OSPF, LDP, BGP (IPv4 and VPNv4) and MPLS/VPN configurations are created, deployed and verified automatically.

read more see 6 comments

Worth Reading: Load Balancing at Fastly

High-speed scale-out load balancing is a Mission Impossible. You can get the correct abstraction at the wrong cost or another layer of indirection (to paraphrase the authors of Fastly load balancing solution).

However, once every third blue moon you might get a team of smart engineers focused on optimal solutions to real-life problems. The result: a layer of misdirection, a combination of hardware ECMP and server-level traffic redirection. Enjoy!

add comment

Network Automation Tools: Featured Webinar in December 2016

The featured webinar in December 2016 is the Network Automation Tools webinar, and in the featured videos you'll find in-depth description of automation frameworks (focusing on Ansible) and open-source IPAM tools (including NSoT recently released by Dropbox).

To view the videos, log into my.ipspace.net, select the webinar from the first page, and watch the videos marked with star.

read more add comment

Q&A: Building a Layer-2 Data Center Fabric in 2016

One of my readers designing a new data center fabric that has to provide L2 transport across the data center sent me this observation:

While we don’t have plans to seek an open solution in our DC we are considering ACI or VXLAN with EVPN. Our systems integrator partner expressed a view that VXLAN is still very new. Would you share that view?

Assuming he wants to stay with Cisco, what are the other options?

read more see 18 comments

Response: On the Death of OpenFlow

On November 7th SDx Central published an article saying “OpenFlow is virtually dead.” There’s a first time for everything, and it’s a real fun reading a marketing blurb on a site sponsored by SDN vendors claiming the shiny SDN parade unicorn is dead.

On a more serious note, Tom Hollingsworth wrote a blog post in which he effectively said “OpenFlow is just a tool. Can we please find the right problem for it?

read more see 6 comments
Sidebar