Twin-Stack Frequent-Providers VRF Confuses Aruba CX « ipSpace.internet weblog

As I used to be working the netlab pre-release integration assessments, I seen that ArubaCX failed the IPv6 Frequent Providers check (it labored earlier than). Right here’s the gist of what that check does:

• It creates three VRFs (pink, blue, and widespread)
• It imports routes from pink and blue VRF into the widespread VRF and routes from the widespread VRF into the pink and blue VRF (the schoolbook instance of widespread companies VRF)
• Simply to be on the protected aspect, it imports pink routes into the pink VRF and so forth.

Right here’s the related a part of the netlab lab topology:

vrfs:
  pink:
    import: [ red, common ]
    hyperlinks: [ dut-h1 ]
  blue:
    import: [ blue, common ]
    hyperlinks: [ dut-h2 ]
  widespread:
    import: [ red, blue, common ]
    hyperlinks: [ dut-srv ]

That 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 that is what you’ll discover within the gadget 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 notice the distinction? Trace: the IPv6 export route goal is lacking. No surprise nothing works.

OK, let’s attempt to add the route goal manually. That is what occurs:

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 similar VRF

WTA*? It’s OK to enter the identical import route goal for IPv4 and IPv6, however not the identical export route goal? Don’t these guys ever check their software program?

Anyway, one would hope that the error message would set off an error within the aoscx_config Ansible module, proper? Properly, it doesn’t. The issue was reported half a yr in the past, and nothing occurred (one has to like open-source points 😎). Configuration errors are clearly not vital.

Again to the inter-VRF route leaking on ArubaCX. It really works for an IPv4-only VRF and for an IPv6-only VRF, however fails miserably while you attempt to leak routes between dual-stack VRFs.

Now for a number of enjoyable info:

• Is that this a current bug? No, I reproduced it with ArubaCX launch 10.13, which is over a yr outdated.
• Why do most VRF assessments work? VRF route targets are related solely while you’re doing inter-VRF route leaking, or while you’re working MPLS/VPN^{. They don’t matter in easy single-device situations (and it seems like the MPLS knowledge aircraft doesn’t work in ArubaCX VM anyway)}
• Why did ArubaCX go the identical check prior to now? As a result of we checked single-protocol VRFs. Lately, we found that our configuration template for one more gadget failed when confronted with dual-stack VRFs, so we modified a number of VRF assessments to be dual-stacked.
• Would this work with EVPN? I don’t know, and I don’t work for the HPE QA division, so don’t count on me to run these assessments^{. You would possibly wish to ask your SE a number of pointed questions, although.}