Posted on June 8, 2020 5:25 pm
 |  Asked by shuja naqvi
 |  180 views
RESOLVED
0
0
Print Friendly, PDF & Email

interface Vlan141
description t141 hyper_v_access blue
load-interval 30
mtu 9214
vrf forwarding t141
ip address virtual 10.78.141.1/24

When a host tries to ping this or any one else from the remote leaf under the same vrf, they cannot ping it, however they can ping host-to-host. Need to know why this is not possible.

0
Posted by John Hust
Answered on June 8, 2020 5:38 pm
Is the intent to implement VARP on the switch?  Typically IP address virtual is used to configure the same IP address on all switches in the VXLAN network.
Varp Example
switch-A(config)#ip virtual-router mac-address 001c.7300.0999
switch-A(config)#interface vlan 141
switch-A(config-if-vl141)#ip address 10.78.141.2/24
switch-A(config-if-vl141)#ip virtual-router address 10.78.141.1
switch-B(config)#ip virtual-router mac-address 001c.7300.0999
switch-B(config)#interface vlan 141
switch-B(config-if-vl141)#ip address 10.78.141.3/24
switch-B(config-if-vl141)#ip virtual-router address 10.78.141.1
0
Answered on June 8, 2020 5:51 pm

IP address virtual uses a source NAT IP when sourcing ICMP packets. With all VTEPs potentially having the same IP address, this is how the Leaf creates a unique IP address.

Please search for the section "Source IP NAT feature while using “ip address virtual” in this link for an explanation.

https://eos.arista.com/virtual-ips-in-vxlan-and-need-for-vvtep/

From that link:

What is the purpose of Source IP NAT ?

Often when we ping a remote host from a VTEP where “ip address virtual” is configured, we see the ping fails. This is because the source IP (virtual IP of SVI) gets NAT’ed to the highest loopback IP in that VRF and the end host might not have route to reach the NAT’ed IP. If there is no loopback, simply the highest IP in the vrf is used.

The reason why this happens is because, since SVI is configured with a virtual IP, the ICMP reply from remote host may reach to some other routing vteps (due to ECMP routes of VVTEP on spine) as the same SVI ip address is configured in all routing vteps.

To ensure ICMP reply from host reaches the original vtep (which initiated the ICMP echo requests) the source-IP of icmp request  is changed to highest loopback IP. The NAT’ed IP will be unique IP and hence ICMP reply will not go to any other VTEP.

Typically, the NAT’ed IP would be the IP on the Loopback interface that is associated with the VXLAN interface (though it could really be any other non-virtual IP on the switch). However, in case of MLAG-VTEP’s, users need to configure an additional loopback in default VRF, since Vxlan loopback interface will have the same IP among MLAG-VTEPs, for Source NAT.

Note that ip address virtual is only intended for VXLAN implementation. If you have a single set of nodes performing first hop routing "ip virtual-router address" can be used.

I have read through the document. Source NAT makes sense but I have another question related to vVTEP? RULE-1 : If ethernet source MAC of original/naked frame is “PHYSICAL” then after encapsulation, outer Source IP will also be Primary IP of vxlan loopback interface. If ethernet source MAC of original/naked frame is “VIRTUAL”, then after encapsulation outer Source IP will be VVTEP IP (secondary loopback IP). Does that mean if we get an ethernet mac from a virtual machine (vmware or linux vm) on the edge port, the post-encapsulation IP will be the vVTEP ? What if I do no want to assign a secondary loopback ? It should still use the physical VTEP post encapsulation or else we've got a broken network ? Correct me if I am wrong
(shuja naqvi at June 13, 2020 7:55 pm)
0
Posted by Aniket Bhowmick
Answered on June 14, 2020 9:43 am

Hi Shuja,

> Does that mean if we get an ethernet mac from a virtual machine (vmware or linux vm) on the edge port, the post-encapsulation IP will be the vVTEP ? What if I do no want to assign a secondary loopback ? It should still use the physical VTEP post encapsulation or else we've got a broken network ?

>> If the VTEP receives an ethernet frame from a VM on the edge port, then the source mac is of the VM mac. From the perspective of Vxlan configuration, this mac is not the virtual mac but just some host mac. Virtual MAC in VxLan is what you have configured on the the VTEP using the "ip virtual-router mac-address <>" . And we don't expect VMs to source packet with the VMAC that is configured on the switches/VTEPs.

Purpose of VMAC in VxLan:

  • To provide a functionality of Anycast Gateway (Multiple VTEPs acting as GW) for servers/hosts behind a Bridging VTEP (no SVI). If host behind Bridging VTEP sends traffic to GW, it can go to any of the routing VTEP (as all routing VTEP shares the same VMAC). This in turn provides redundancy and load-sharing. To achieve this, VVTEP is also required because if there is no VVTEP, packets send by hosts behind Bridging VTEP will ALWAYS reach a particular VTEP (primary loopback IP of some VTEP) rather than being distributed among multiple routing VTEPs. This is because all VTEP will have unique primary Loopback IP. So a VVTEP (secondary IP in Loopback) is must to achieve Anycast Gateway functionality.
  • Hosts connected behind a Routing VTEP (which SVI configured with Virtual IP and VMAC) can do vMotion (moving the VM to another site) and there is no need to update ARP-cache on those VMs or change default GW IP as all routing VTEPs will have the same Virtual MAC and Virtual IP which will act as Gateway.

Let us know if there is any further query.

Regards,

Aniket

Post your Answer

You must be logged in to post an answer.