Ethernet Flow Point for Catalyst 8000v on ESXi

[bcerny]

My starting point:

Virtual Router: Catalyst 8000v [ license boot level network-essentials addon dna-essentials ]
Hypervisor:  VMWare ESXi Version 7.0.x
vNIC: VMXNET3 

I would like to use Ethernet flow point (EFB) style configuration on a Cat 8000v virtual router to support my legacy Vlan routing and to add support for L2VPN services. But I've hit a snag.

Using the vSphere client, I associate one of the Cat 8K network adapters to an ESXi trunk port. I would like to move the Vlan 3920 gateway (39.20.0.1) from an old school sub-interface to an EFP:

interface GigabitEthernet3
 description --> trunk
 no ip address
 no shutdown
 !
 service instance 1 ethernet
  description --> Vlan 3920
  encapsulation dot1q 3920
  rewrite ingress tag pop 1 symmetric
  bridge-domain 1
!
interface BDI1
 description --> Vlan 3920 Gateway
 ip address 39.20.0.1 255.255.255.0
 no shutdown

But with this configuration, I cannot reach any hosts on Vlan 3920 (39.20.0.xxx), nor can any hosts ping the router (39.20.0.1).  So I reverted to the original old-school configuration:

interface GigabitEthernet3
 description --> trunk
 no ip address
 no shutdown
!
interface GigabitEthernet3.3920
 description --> Vlan 3920 Gateway
 encapsulation dot1q 3920
 ip address 39.20.0.1 255.255.255.0
 no shutdown

This classic sub-interface configuration works well, and the router is reachable from all Vlan 3920 hosts.

Q1. Have you, kind reader, had success configuring EFPs on virtual routers that use VMXNET3 network adapters? (please share an example configuration)

Q2. Is the Ethernet flow point (EFB) style configuration in the first example above not supported using my combination of ESXi version 7.x and network adapter VMXNET3?

Q3. Is there an alternate approach available to use one virtual router interface to support a combination of multiple Vlan routing and L2VPN services?

[Ramblin Tech]

I just did a quick PoC of your configs with back-to-back Cat8Kv (17.9.1a) on CML (bare metal, no hypervisor, vmxnet3 driver), changing the subintf address to 39.20.0.2. No problems pinging.

As a sanity check:

• Can the EFP vrouter ping its own address (39.20.0.1)? 
• Is bridge-domain 1 "up" (not the BDI, but the bridge-domain)?
• Is it showing 2 ports attached to bridge-domain 1: g3 and bdi1?
• Is it showing BDI1's MAC address in bridge-domain 1?
• Is it showing any other L2 neighbor's MAC address in bridge-domain 1?

Since your very simple config works on bare-metal CML, I suspect you are on the right track with examining ESXi.

[bcerny]

Yo Rambler, here is bridge domain operating state: (BDI1 MAC addr = 001e.f604.6ebf)

Router#show bridge-domain 
Bridge-domain 1 (2 ports in all)
State: UP Mac learning: Enabled
Aging-Timer: 300 second(s)
Unknown Unicast Flooding Suppression: Disabled
Maximum address limit: 65536
BDI1 (up)
GigabitEthernet3 service instance 1
AED MAC address Policy Tag Age Pseudoport
- 001E.F604.6EBF to_bdi static 0 BDI1

And the router can ping its own BDI1 IP address:

Router#ping 39.20.0.1
Sending 5, 100-byte ICMP Echos to 39.20.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

I have also labbed this up with a couple of virtual routers in GNS3 and I do not have the EFP trouble that I'm having with ESXi (our production environment) 

[Ramblin Tech · Accepted solution]

Certainly smells like a disconnect between the bridge-domain and ESXi vlan. I took a quick look at the Cat8Kv Config Guides, but did not see a section for EFPs (unlike the CSR1Kv Config Guides, which do list Carrier Ethernet).

You might reach out to your Cisco account team or TAC to confirm that EFPs are actually officially supported on Cat8Kv (Cisco CLI parsers quite frequently accept commands that are not actually supported by that platform). Commands

not supported

when accepted by the parser often comes down to there never having been a devtest program funded and scheduled to see if the feature actually works as designed. Sometimes such unsupported features work, sometimes they don't.