Like I hinted at in an earlier post, there are a some failure scenarios you need to consider for vPC. The first scenario we can’t really do much with, but I’ll describe it anyway. The topology is the one below:
Cisco vPC in VXLAN/EVPN Network – Part 4 – Fabric Peering
Like I mentioned in a previous post, normally leafs don’t connect to leafs, but for vPC this is required. What if we don’t want to use physical interfaces for this interconnection? This is where fabric peering comes into play. Now,
Cisco vPC in VXLAN/EVPN Network – Part 3 – Verifying Connectivity
The following topology is used: We want to verify connectivity and traffic flow towards: Let’s start with the gateway. The gateway is at 10.0.0.1 and has a MAC address of 0001.0001.0001: This is an anycast gateway MAC. When initiating a
Cisco vPC in VXLAN/EVPN Network – Part 2 – Configuring vPC
When building leaf and spine networks, leafs connect to spines, but leafs don’t connect to leafs, and spines don’t connect to spines. There are exceptions to this and vPC is one of those exceptions. The leafs that are going to
Cisco vPC in VXLAN/EVPN Network – Part 1 – Anycast VTEP
Many vendors offer MLAG features, that is, the ability to form a PortChannel (some vendors call it trunk or bond) towards two separate devices. In this post, I will cover the following: Traditional vPC On Cisco Nexus switches, virtual Port
Troubleshooting vPC in My Virtual Lab
I’m preparing a blog post on setting up vPC in a VXLAN/EVPN environment. While doing so, I ran into some issues. Rather than simply fixing them, I wanted to share the troubleshooting experience as it can be useful to see