Posted on August 25, 2021 1:13 pm
 |  Asked by Chris Zhang
 |  89 views
RESOLVED
0
0
Print Friendly, PDF & Email

Hi, I am running a VM as a lightweight server in an Arista 7060CX-32S (4.25.1F). I can ping the VM when VLANs are not forwarding to VRF. VM config:

virtual-machine router01
disk-image drive:/kvm/opnsense.img
memory-size 2047
virtual-nic 1 Management1 52:54:00:2f:f3:2f
virtual-nic 2 Vlan11 52:54:00:cb:b4:3a
virtual-nic 3 Vlan10 52:54:00:61:13:aa
virtual-nic 4 Vlan12 52:54:00:9d:5b:3d
enable
!

So in above configuration, clients in Vlan 10/11/12 can access the VM successfully. However, if I configure VRF for VLANs, the VM IP (say 10.10.10.254 on Vlan11) will become inaccessible, but I can still access the IP address on the VLAN interface, e.g.

interface Vlan11
no autostate
vrf CHANNEL1
ip address 10.10.10.1/24
!

I can ping “10.10.10.1” from the client, but “10.10.10.254” (VM) has become inaccessible.

Is there a solution for this? Did I miss something, or VMs simply can’t use VRF in this case??

Thanks!

Chris

0
Posted by Wei
Answered on August 25, 2021 2:20 pm

Hi Chris,

That's expected,

Caveat: Kernel ‘hair-pinning’ is currently not enabled so you can not communicate directly with the local switch, all traffic must have a destination on another networked device (router, switch, server, etc…)

https://eos.arista.com/virtual-machines-in-eos/

0
Posted by Chris Zhang
Answered on August 25, 2021 9:51 pm

Thanks for the answer. I understand that the VM cannot communicate with the switch itself due to hair-pinning is not enabled. But I think it should still be able to communicate with external devices, say, my laptop. However, once VRF has been set for those VLANs that the VM is in, I can no longer ping the VM from my laptop. And if I disable VRF for those VLANs, I can then ping the VM successfully. Is this still due to "hair-pinning" (I am not sure about the internal implementation of VRF though)?

Thanks.

Chris

0
Posted by Wei
Answered on August 26, 2021 2:42 pm

Hi Chris,

I am afraid we don't support this scenario with macvtap under netns.

0
Posted by Chris Zhang
Answered on August 26, 2021 10:13 pm

Thanks, I think for now a workaround is to leave those VLANs in default VRF, and use a secondary switch to bounce back the traffic.

Post your Answer

You must be logged in to post an answer.