We're running a set of 5010 switches and in preparation for some soak testing embarked on setting up our usual snmp based monitoring. After letting the graphs settle we started to see wild results in terms of the amount of traffic claiming to traverse all of the interfaces. A 10G switch it may be but with not much running behind it graphs claiming up to 15G were a little strange to say the least!
Anyways digging further and trawling for similar issues we came across an issue with versions < 4.1(3)N(2a) not supporting 64 bit counters for physical interfaces - these threads alluded that this version fixes the problem and we are infact currently running 4.1(3)N(1)
However we've seen a slight difference in this behaviour whereby both the 32 bit and 64 bit counters exist but claim to be reporting the same value - which is incorrect.
There are no references to any physical interfaces in the ifHCInOctet tree yet a value is still returned; and furthermore we see huge disparities in the value returned; peaks suggesting a huge spike in traffic, which as the number is no longer accumulative is playing havoc with our monitoring system's calculations
Topology & Design:
Two ACI fabrics
Stretching VLANs using OTV
Both fabrics are advertising BD subnets into same routing domain
Some BDs(or say VLANs) are stretched, but some are not.
Endpoints can move betwee...
VMware Trunk Port Group is supported from ACI version 2.1
VMM integration must be configured properly
ASA device package must be uploaded to APIC
ASAv version must be compatible with ACI and device package version
Topology &Design:Traffic flow within same fabric:Endpoint moves to Fabric-2Bounce Entry Times OutTraffic Black-holedSummarySolutionAppendix:
In the Previous articles of ACI Automation, we are using Postman/Newman a...