As I was running the netlab pre-release integration tests, I noticed that ArubaCX failed the IPv6 Common Services test (it worked before). Here’s the gist of what that test does:

• It creates three VRFs (red, blue, and common)
• It imports routes from red and blue VRF into the common VRF and routes from the common VRF into the red and blue VRF (the schoolbook example of common services VRF)
• Just to be on the safe side, it imports red routes into the red VRF and so on.

Here’s the relevant part of the netlab lab topology:

vrfs:
  red:
    import: [ red, common ]
    links: [ dut-h1 ]
  blue:
    import: [ blue, common ]
    links: [ dut-h2 ]
  common:
    import: [ red, blue, common ]
    links: [ dut-srv ]

This is the netlab-generated ArubaCX config for the blue VRF:

vrf blue
    rd 65000:2
    address-family ipv4 unicast
        route-target import 65000:2
        route-target import 65000:3
        route-target export 65000:2
    exit-address-family
    address-family ipv6 unicast
        route-target import 65000:2
        route-target import 65000:3
        route-target export 65000:2
    exit-address-family

And this is what you’ll find in the device configuration after the configuration playbook completes:

vrf blue
    rd 65000:2
    address-family ipv4 unicast
        route-target export 65000:2
        route-target import 65000:2
        route-target import 65000:3
    exit-address-family
    address-family ipv6 unicast
        route-target import 65000:2
        route-target import 65000:3
    exit-address-family

Can you spot the difference? Hint: the IPv6 export route target is missing. No wonder nothing works.

OK, let’s try to add the route target manually. This is what happens:

dut# conf t
dut(config)# vrf blue
dut(config-vrf)# address-family ipv6 unicast
dut(config-vrf-ipv6-uc)# route-target export 65000:2
Export route-target 65000:2 exists in same VRF

WTA*? It’s OK to enter the same import route target for IPv4 and IPv6, but not the same export route target? Don’t these guys ever test their software?

Anyway, one would hope the error message would trigger an error in the aoscx_config Ansible module, right? Well, it doesn’t. The problem was reported half a year ago, and nothing happened (one has to love open-source issues 😎). Configuration errors are obviously not significant.

Back to the inter-VRF route leaking on ArubaCX. It works for an IPv4-only VRF and an IPv6-only VRF, but fails miserably when you try to leak routes between dual-stack VRFs.

Now for a few fun facts:

• Is this a recent bug? No, I reproduced it with ArubaCX release 10.13, which is over a year old.
• Why do most VRF tests work? VRF route targets are relevant only when you’re doing inter-VRF route leaking or running MPLS/VPN¹. They don’t matter in simple single-device scenarios (and it looks like the MPLS data plane doesn’t work in ArubaCX VM anyway)
• Why did ArubaCX pass the same test in the past? Because we checked single-protocol VRFs. Recently, we discovered that our configuration template for another device failed when faced with dual-stack VRFs, so we changed several VRF tests to be dual-stacked.
• Does this happen only in ArubaCX VM? Sadly, David Williams confirmed that the physical boxes experience the same behavior.
• Would this work with EVPN? I have no idea, and I don’t work for the HPE QA department, so don’t expect me to run those tests². You might want to ask your SE a few pointed questions, though.
• Is there a workaround? Sort of. You could use different route targets for IPv4 and IPv6 address families. That would most probably work™ (see also the previous bullet) for inter-VRF route leaking inside a single box, but you’ll run into interesting interoperability challenges when trying to use the same trick in multi-vendor MPLS/VPN networks (the route targets were traditionally assigned to VRFs, not to address families).

Revision History

2025-07-14

• The physical boxes experience the same problem
• Added the description of a potential workaround