Hi @dnoc43 ,
OK. So go to the EPG, then to [Operational] > [Configured Access Policies] or, if you have the Policy Viewer plugin installed, that may be a better option. [Edit: 2023.04.08 - updated diagram so both diagrams match]
From one of these two views, you should be able to see the problem. I hope!
Very odd! When I attach the phy dom to the EPG it shows every IPG I have created even though no static ports are assigned. Is that normal behavior?
I've collaped the phy domain AAEP to show full policy
Hi @dnoc43 ,
OK. I've had a bit more of a look - tried to lab it but I can't hook up an ESXi in a VPC ATM, so just added VMs to the design I had before. BUT...
Very odd! When I attach the phy dom to the EPG it shows every IPG I have created even though no static ports are assigned. Is that normal behavior?
YES - this is normal behaviour IF you have mapped the AMDC-AAEP up to the TEST2_EPG for a particular VLAN (this effectively assigns EVERY IPG linked to the AAEP to the EPG)
On the other hand, linking two AAEPs to the same Phys Dom is NOT normal behaviour - at least NOT best practice, although it is technically possible to do so.
I reckon that if you can collapse your two AAEPs to a single AAEP, or if that's not possible, create a new PhysDom (with the same VLAN pool if necessary) and add that PhysDom association to the TEST2_EPG and then make sure there is one PhysDom per AAEP, then your conundrum from above may fix itself.
Let me know how it goes.
If I do a endpoint lookup on a known mac address of VM on VMM this is what I see. It's still being learned from 162/172?? Since this is a test environment my next step was to disable the vmotion/storage/mgmt VPC ports on 162/172. Then did the endpoint search again. It's still there??
Hi @dnoc43 ,
I'm beginning to wonder if the problem MAY be with the bits of the diagram that you didn't include. Based on your naming, I'm assuming your physical setup looks more like this in reality (no wonder you didn't put all the detail in!)
The thing is that your VPCs are NOT connected to ESXi hosts, but to FIs
Now, within the ESXi hosts, the VMM vSwitches will send traffic either to FI-A or FI-B (based on source virtual port which means the same MAC always goes to the same FI)
And UNLESS YOU ARE USING DISJOINT VLANS on the FIs, the FIs will load balance on all uplink ports, which in your case is the two VPCs! And that would explain perfectly why you are seeing traffic from a non-expected VLAN on one or both of the VPCs
So I think your next troubleshooting step would be to look at UCS Manager, and check to see how your uplinks are configured
In UCS Manager, thats Equipment > Fabric Interconnects > Fabric Interconnect A (or B) then click the LAN Uplinks Manager from the General tab.
Yes, sorry you're 100% correct. That's exactly how it's wired up. Only difference is we have pinning setup in UCS to pin specific VLANs to port-channels. My concern is why is the APIC still pointing to a VPC IPG that's shut down.
If I look at LEAF162 I see only a remote EP pointing to a tunnel interface destined for LEAF173
Chris thanks so much for the video. It did help with the learning source. Which brings me to today's question.
I've noticed as soon as I attach a vm to the dvs I see this in the Client Endpoint in EPG. Notice the 2 vmm incorrect paths and the correct learned path once it sees a packet. The two incorrect paths are port-channels connected to the same FI. I guess ACI is assuming these are also valid paths to the vmware hosts? Is there a way to prevent this learning? The two incorrect paths don't go into "learning" because it never receives a packet on those interfaces.
Below is the layout for one of the two FIs. Both LEAF1s should not be there.
