Posted on October 2, 2014 10:19 am
 |  Asked by Victor
Print Friendly, PDF & Email

I am trying to setup VARP in a test LAB and I am getting some weird results when I initiate a ping.  Currently I have MLAG configured between switches Spine-1 and Spine-2. Both interfaces on Switch1 are part of the MLAG on Spine-1 and Spine-2. On Spine-1 and Spine-2 I have SVI Vlan100 configured with VARP. The issue is when send a ping from Switch1 towards the virtual-router address which is I get a replies back but with duplicate packets. I understand that from VARP perspective both switches reply but how can I stop the duplicate packets? Below is a link to the diagram. Also put some of the configs below.

Diagram Link:

Spine1#sh mlag
MLAG Configuration:
 domain-id : MLAG_DOMAIN1
 local-interface : Vlan4094
 peer-address :
 peer-link : Port-Channel100
 MLAG Status:
 state : Active
 negotiation status : Connected
 peer-link status : Up
 local-int status : Up
 system-id : 02:0c:29:94:fa:06
 MLAG Ports:
 Disabled : 0
 Configured : 0
 Inactive : 0
 Active-partial : 0
 Active-full : 1
Spine1#sh mlag inter
 mlag desc state local remote status
 ---------- ---------- ----------------- ------------ ------------ ------------
 1111 active-full Po1111 Po1111 up/up
Spine1#sh run int vlan 100
 interface Vlan100
 ip address
 ip virtual-router address
Spine1#sh run | inc mac
 ip virtual-router mac-address 00:1c:73:00:00:99

Switch1 ping test:

 PING ( 72(100) bytes of data.
 80 bytes from icmp_req=1 ttl=64 time=22.4 ms
 80 bytes from icmp_req=1 ttl=64 time=30.1 ms (DUP!)
 80 bytes from icmp_req=2 ttl=64 time=56.6 ms
 80 bytes from icmp_req=2 ttl=64 time=64.9 ms (DUP!)
 80 bytes from icmp_req=3 ttl=64 time=48.1 ms
 80 bytes from icmp_req=3 ttl=64 time=63.5 ms (DUP!)
 80 bytes from icmp_req=4 ttl=64 time=55.2 ms
 80 bytes from icmp_req=4 ttl=64 time=64.8 ms (DUP!)
 80 bytes from icmp_req=5 ttl=64 time=46.6 ms
Posted by Mark Berly
Answered on October 6, 2014 12:10 pm

Victor – vARP, or Virtual ARP, is just that a virtualization of the ARP process in which the gateway routers respond to ARP requests for the gateway. Since it is ’protocoless’ all configured gateways respond to these requests, as well as gratuitous ARPs being periodically sent, and there is no practical way to prevent this from happening. These duplicate responses are not an issue from a host perspective as they will just use the most recent response. The benefit of this design are:

- no protocol to break
- converge during a failure is immediate (all the gateways are already forwarding)
- no scale limits on a design (with vARP you can have as many gateways as you like)
In deployments of this technology we have had no issues around the issue you bring up. If you have further questions please let us know….

Posted by Victor
Answered on October 6, 2014 10:00 pm


I found the issue. The issue was I forgot to confirm the virtual-router mac-address on the second L3 switch(Spine2). I am no longer getting duplicate packets. Thank you


Post your Answer

You must be logged in to post an answer.