Hello,
I have a strange issue that I can't quite understand. I have 2 ISR 4451s connected to an ACI fabric that function as network appliances (nodes 2, 4 in attached). I have 2 netscalers with mgmt connected to the same ACI epg/bridge-domain that function as hosts for the purposes of this post (nodes 1, 3 in attached). The BD is configured to flood BUM traffic (no HW proxy) and is required for other undepicted hosts. It is configured as an L3 BD.
Periodically, I lose traffic in this EPG. Troubleshooting efforts eventually led me to this output by pinging from one host to another in the EPG (ping source is 1 and ping dest is 3 in attached diag):
bash-3.2# ping 172.17.26.77
PING 172.17.26.77 (172.17.26.77): 56 data bytes
64 bytes from 172.17.26.77: icmp_seq=0 ttl=64 time=3.183 ms
64 bytes from 172.17.26.77: icmp_seq=0 ttl=63 time=3.186 ms (DUP!)
64 bytes from 172.17.26.77: icmp_seq=0 ttl=63 time=3.188 ms (DUP!)
64 bytes from 172.17.26.77: icmp_seq=0 ttl=62 time=3.189 ms (DUP!)
64 bytes from 172.17.26.77: icmp_seq=0 ttl=62 time=3.445 ms (DUP!)
64 bytes from 172.17.26.77: icmp_seq=0 ttl=61 time=3.447 ms (DUP!)
64 bytes from 172.17.26.77: icmp_seq=0 ttl=61 time=3.449 ms (DUP!)
64 bytes from 172.17.26.77: icmp_seq=0 ttl=60 time=3.451 ms (DUP!)
64 bytes from 172.17.26.77: icmp_seq=0 ttl=60 time=3.898 ms (DUP!)
64 bytes from 172.17.26.77: icmp_seq=0 ttl=59 time=3.901 ms (DUP!)
64 bytes from 172.17.26.77: icmp_seq=0 ttl=59 time=3.902 ms (DUP!)
64 bytes from 172.17.26.77: icmp_seq=0 ttl=58 time=3.904 ms (DUP!)
64 bytes from 172.17.26.77: icmp_seq=0 ttl=58 time=4.361 ms (DUP!)
[[cut - pattern repeats ]]
64 bytes from 172.17.26.77: icmp_seq=0 ttl=5 time=16.326 ms (DUP!)
64 bytes from 172.17.26.77: icmp_seq=0 ttl=5 time=16.328 ms (DUP!)
64 bytes from 172.17.26.77: icmp_seq=0 ttl=4 time=16.329 ms (DUP!)
64 bytes from 172.17.26.77: icmp_seq=0 ttl=4 time=16.786 ms (DUP!)
64 bytes from 172.17.26.77: icmp_seq=0 ttl=3 time=16.788 ms (DUP!)
64 bytes from 172.17.26.77: icmp_seq=0 ttl=3 time=16.789 ms (DUP!)
64 bytes from 172.17.26.77: icmp_seq=0 ttl=2 time=16.791 ms (DUP!)
64 bytes from 172.17.26.77: icmp_seq=0 ttl=2 time=17.241 ms (DUP!)
64 bytes from 172.17.26.77: icmp_seq=0 ttl=1 time=17.243 ms (DUP!)
64 bytes from 172.17.26.77: icmp_seq=0 ttl=1 time=17.244 ms (DUP!)
64 bytes from 172.17.26.77: icmp_seq=1 ttl=64 time=1.420 ms
64 bytes from 172.17.26.77: icmp_seq=2 ttl=64 time=1.201 ms
64 bytes from 172.17.26.77: icmp_seq=3 ttl=64 time=1.601 ms
c64 bytes from 172.17.26.77: icmp_seq=4 ttl=64 time=1.163 ms
64 bytes from 172.17.26.77: icmp_seq=5 ttl=64 time=1.481 ms
64 bytes from 172.17.26.77: icmp_seq=6 ttl=64 time=1.557 ms
64 bytes from 172.17.26.77: icmp_seq=7 ttl=64 time=1.442 ms
^C
--- 172.17.26.77 ping statistics ---
8 packets transmitted, 8 packets received, +126 duplicates, 0.0% packet loss
round-trip min/avg/max/stddev = 1.163/9.624/17.244/4.529 ms
bash-3.2#
Clearly, there is a L3 loop going on here. I did some packet captures (attach pcap not allowed
In this wireshark snip, you can view the source MAC for the first 2 ping packets are what would be expected. Then come the duplicates from ttl=63 through ttl=1. The source MACs of these are the interface MAC addresses of the 2 ISRs in the topology. To me, this is nearly irrefutable evidence that the ISRs received and forwarded the ping replies (they are routers, after all).
My question is what function would cause the ISRs to process those frames? The dst MAC is clearly NOT owned by either ISR. Why would they not simply drop the frames?
Thoughts?
As an aside, I resolved this issue by putting an ACL on the ISRs interfaces since the only traffic that they should process is traffic that is destined for the interface IP. So, a simple permit ip any host 172.17.26.103 and deny all other traffic fixed my issues. I'm still just very confused why the ISRs were processing frames for a MACs destined for another host.
