How I Started Hating Automatic Context Switching in Cisco IOS
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).
We migrated our blog a few days ago, and the commenting functionality is not there yet. In the meantime enjoy the older comments, or find our content on LinkedIn and comment there.
I refuse to operate on an OS that does not provide something similar to "commit check" and "show | compare"
if you are still thinking about box level commit check, it is time to change :) it doesn't matter if network OS is still cmd by cmd, what you need is a network wide "show|compare" and "commit|check", it doesn't mater if underneath is IOS or Cumulus or JUNos, EOS ....
Hi Eric! I totally understand you love what your company is doing, but in essence it's just replacing the point of lock-in. See also http://blog.ipspace.net/2015/01/lock-in-is-inevitable-get-used-to-it.html
thanks Ivan for your understanding, I like your "margin shift story" more :)
happy new year!
Yeah they made a bunch of legacy support decisions with XR when they should have just thrown it all out. Automatic context switching, ambiguous "no" statements to delete config. Not being able to define empty prefix-lists is another peeve of mine.
Speaking about "automatic context switching", did it ever happen to you to try to apply a route-policy to a peer, but forget to mention in or out ? If so, have you realised what happened before or after "commit" ? :) IOS-XR case....