back to overview
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).
Related posts by categories
Please read our Blog Commenting Policy before writing a comment.
6 comments:
I refuse to operate on an OS that does not provide something similar to "commit check" and "show | compare"
ReplyDeleteif 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 ....
DeleteHi 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
Deletethanks Ivan for your understanding, I like your "margin shift story" more :)
Deletehappy 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.
ReplyDeleteSpeaking 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....
ReplyDelete