Author: Valter Popeskic

What is MultiPod?

ACI MultiPod was first designed to enable the spread of ACI Fabric inside a building (into two or more Pods), let’s say in two rooms at different floors, without the need to connect all the Leafs from one room to all the Spines in the other room. It was a way of simplifying the cabling and all that comes with building spread CLOS topology fabric stuff.

MultiPod also saves some Leaf ports giving the fact that Pod to Pod connection through Multicast enabled IPN network connects directly to Spines.

People soon realized that MultiPod will be a great solution for a dual site (or more than dual) Datacenter with the ability to have single management with a single ACI Fabric stretched across two or more locations that are connected with an IP connection not too long so that enables RTT latency of less than 50msec with Multicast support. Not too simple but it seems not too demanding for most cases.

Hello World

This is an overview of what I think Cisco ACI actually is. It uses some examples from the lab environment to show you how the things look like when you start to work with ACI. There are other articles in the works which will be online soon and which will go in details through the real configuration of ACI and best practices while doing it.

What is this Cisco ACI Fabric?

Cisco ACI is a datacenter network Fabric. It actually means that it is a networking system of more networking L3 switches that have a modified, next-generation OS which enables them to be centrally provisioned and configured through APIC controller to work as one device from access port perspective.

Edson Erwin invented this highly scalable and optimized way of connecting network nodes in the 1930s and Charles Clos made the telephone nodes interconnection design using that solution. It was even before we had IP networks. He invented it in order to optimize the architecture of telephony network systems back then.

It was not used in IP based network for last few decades but it experienced a big comeback with new datacenter design in the last few years. It was first invented only for scalability requirements that it solved beautifully. In new datacenter design, CLOS topology of interconnecting network devices scalability is also the first requirement that gets solved, but it also greatly helps with improving resiliency and performance.

In today’s datacenters, CLOS topology is used to create Leaf’n’Spine system of interconnecting Leaf switches (datacenter access switches or ToR switches) together through Spine switches. It is created in a way that each Leaf switch is redundantly connected to all Spine switches directly.

As it is shown in the picture below, in this way, using CLOS topology, we are interconnecting Leaf switches in a way that they always have only two hops between each other and this done redundantly as two hops through each Spine switch. Spines are not directly connected and Leafs are also not directly connected.

Again I made it to the list of Cisco Champions, making this the second year in a row!

I am so glad that my effort to give back to the community and to all my networking fellows out there paid off again in the shape of this recognition from Cisco. This badge is only a small thing, relating to all the community connections and sharing that my involvement with networking community via social media and this blog, made possible. It only pushes me to get even more done in the future.

In 2018 I was involved in a few very challenging new projects, working with Cisco ACI and VMware NSX, and basically studying and researching continuously in order to get to know the products as much as it was possible, it resulted in not being so active on my blog or twitter this year.

If there’s no BFD

If you have two routers directly connected, like here:

In this case, it is normal that one of them will remove the routes learned from the other if the other one goes down completely. It is because the link will go to down state and the routing protocol adjacency will disappear.

If two routers are connected through an L2 device (switch) like down here:

In this case, when one of them goes down, it will not take down the interface of the L3 neighbour (other router) because the switch will still work fine and it will keep the other half of the like up:

If that’s the case, you will depend on routing protocol timers which are the failure detection mechanisms implemented in the routing protocol itself. Routing protocol timers will need to expire in order to bring the router adjacency down and start the convergence to some other path towards the destinations.

Routing protocols timers are not a bad mechanism and they can be tuned so that they detect the failure faster.

EIGRP hello and hold timers can be tuned to get you somewhere around 1 second for failure detection and the start of convergence. With IS-IS and OSPF you can enable fast hello option and this can get also to 1 second for failure detection.

You can probably guess by now that to speed things up the BFD from the title will be the best solution.

Whats is BFD?

To make failure detection fast, like really fast, like sub-second fast you should use BFD. BFD, which is a separate protocol for communication failure detection, uses small overhead probe packets (like smallish hello packets) that are sent many times in a second in order to get you to sub-second detection of communication failure.