ClusterXL VTI with interface bond and VLAN

[Duane_Toler]

All physical interfaces are configured to be part of various bonding groups (I have three of these: bond0, bond1, and bond2; each has 2 physical interfaces).

Two of these are configured with VLANs (bond0.10, bond0.20, bond1.30, bond1.40).

I try to add an unnumbered VTI, it fails:

gw1> add vpn tunnel 4 type unnumbered peer FOO-GW dev bond0.10
VpntErr0001  There is no interface bond0.10

R80.40 HFA 139, also tested on HFA 158

Does this seem more like a feature-limitation than a bug?  I'm guessing it's a TAC call either way...?

[Duane_Toler]

Okie dokie.. so I used a loopback instead:

gw1:

add interface lo loopback 169.254.1.1/32 

add vpn tunnel 1 type unnumbered peer FOO-gw dev loop00

set static-route 192.168.100.0/24 nexthop gateway logical vpnt1 on

gw2:

add interface lo loopback 169.254.1.2/32 

add vpn tunnel 1 type unnumbered peer FOO-gw dev loop00

set static-route 192.168.100.0/24 nexthop gateway logical vpnt1 on

In SmartConsole:

Edit cluster object - Network Management - Get Interfaces -> "Get Interfaces WITHOUT topology" (my emphasis)

The physical IP of vpnt1 on each cluster member was the Gaia config (as expected).  I configured the VIP of "vpnt1" to be the same IP as the same IP of the physical egress interface (eth0, in this case; for my customer this was a bond0.X VLAN).

This actually works...  wow.  I'm a bit surprised. 🙂  I ran a VPN debug to see what was going on, and ... nothing much, actually.  It looked just about the same as any typical IKEv2 VPN would.  The traffic selectors did their thing as you'd expect.  VPN came up, and I tested clusterXL_admin down/up on each of the cluster members while passing traffic.  Nothing unusual.

R80.40 HFA 139 for my customer, but HFA 158 for my lab VMs.

[Chris_Atkinson]

I'm fairly certain in the Web UI we label the parameter as "Physical Device" and limit the drop down accordingly but also allow Loopbacks as you've discovered. Glad its working for you now.

[Duane_Toler]

Yep, that's exactly what happened, both in WebUI and CLISH.  Is there a particular reason why the virtual layer 3 interfaces (either straight portchannel or VLAN interfaces) are unusable for unnumbered VTI?  There's no clear documentation on the options or explanations, so it is somewhat jarring when starting the configuration.

Admittedly, when I did the first PoC lab, my test gateway was using direct ethernet interfaces with no VLAN configuration.  I didn't expect the functionality or configuration to be very different when repeating the configuration on the production gateway.  I know, this wasn't a "like-kind exchange" between PoC and production, and indeed my fault, so this is an additional #LessonLearned. 🙂

Thanks!