02-03-2020 12:14 AM - edited 02-03-2020 12:21 AM
I have ip flapping issue in cisco ACI environment
as the topology:
I found that when icmp reply from 168.1.37.129 to 168.1.37.45,these icmp reply packets will be sent to SW13 and SW14 at the same time,the icmp reply packets which sent to SW13 with S-IP:168.1.37.129 and S-MAC:d9bc,other icmp reply packets which sent to SW14 with S-IP:168.1.37.129 and S-MAC:66ec,in other words,this is “ip flapping" issue.
problem:
in this case,when 168.1.37.45 ping 168.1.37.129 without interruption,i found 168.1.37.45 can receive icmp reply packets from 168.1.37.129 without interruption,but more than 10 minutes later it can not receive icmp reply packets suddenly,show endpoints command list 168.1.37.129 associate mac is d9bc;after a few minutes 168.1.37.45 can receive icmp reply packets again and show endpoints command list 168.1.37.129 associate mac is 66ec.
Solution:
enable arp flooding
i think this feature can resolve this problem,but it is not root cause for this probelm.
questions:
1.I want to know the root cause for 168.1.37.45 can not receive icmp reply packet suddenly.
2.this is NIC Teaming active/active without vPC config at server side,so it can cause ip flapping.Does this phenomenon have anything to do with "endpoint loop protection or rogue endpoint control"?
3.if there have others method to resolve this problem without enable arp flooding?
02-05-2020 02:55 PM
I'm not certain this is the exact situation, but it sounds oddly familiar to me.
We had a similar issue and Disabling IP Data-Plane Learning at the VRF level fixed it.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide