Imagine you want to deploy a BGP route reflector for MPLS 6PE or L3VPN service. Both services run over MPLS LSPs, use IPv4 BGP sessions, and use IPv4 next hops for BGP routes. There’s absolutely no reason to need IPv6 routing on a node that handles solely the control-plane activity (it never appears as a BGP next hop anywhere), right? Cisco IOS disagrees, as I discovered when running route reflector integration tests for netlab 6PE and (MPLS) L3VPN functionality.

Most platforms failed those tests because we forgot to configure route-reflector-clients in labeled IPv6 and VPNv4/VPNv6 address families¹. That was easy to fix, but the IOS-based devices were still failing the tests, with nothing in the toolchain ever complaining about configuration problems.

Looking more closely at what was going on, I discovered something weird: BGP ipv6 labeled-unicast and vpnv6 address families appeared to be configured without a hitch with Ansible’s ios_config module, but they did not subsequently appear in the BGP configuration.

Logging into the route reflector and copy-pasting the commands quickly identified the culprit:

dut(config)#router bgp 65001
dut(config-router)#address-family ipv6
% IPv6 routing not enabled
dut(config-router)#address-family vpnv6 unicast
% IPv6 routing not enabled

Adding ipv6 unicast-routing to a BGP route reflector that did not have a single IPv6 address configured or IPv6 enabled on a single interface fixed the problem.

After adding that command, the integration tests were passing without a hitch, but I was still wondering why Ansible reported no configuration errors. Fortunately, Ansible collections are available on GitHub, and I’ve been down this road before, so it wasn’t hard to find what the Ansible ios_config module considers to be a configuration error. Instead of “every response to a configuration command that starts with a percent sign is an error”, they have a nice collection of whatever error messages they’ve seen in the past. Any error message they haven’t seen before is quietly ignored².

And that’s why it would be much better to use a configuration mechanism like NETCONF or REST API that consistently reports the completion status, rather than the CLI to configure network devices. If only they would be as easy to use as the CLI 🤷‍♂️.