How to operate, administrate and manage an SPB network?

What we, system engineers, understand under operations, administration, and management (OA&M) are the processes, activities, tools, and standards involved with operating, administering, managing and maintaining networks. From the perspective of SPB networks, I should say there are three fundamental parts to this:

For some time, the networking industry has been working hard to automate tasks and processes. And this is indeed one area where complexity versus simplicity really comes into play. I would say that in most cases, vendors have delivered automation by implementing advanced and complex orchestration systems. However, and as emphasized in the previous post: one of the beauties of Shortest Path Bridging and by extension, the Extreme Fabric Connect solution, is simplicity! This simplicity also makes SPB and Fabric Connect so well suited for automation. And not only that!

This simplicity has allowed Extreme Networks to integrate automation into the operating system software of the switches themselves. It means there’s no need for an external orchestration tool! I cannot stress this enough: this capability, named Zero Touch Fabric, means that the switches themselves have the capability to understand that they are connected to other SPB fabric nodes, will learn key parameters from their peers and automatically join the fabric network. Power up a switch, connect it to the network, and voila, the switch is a fully functional member of your network. If it is the first switch of your new fabric network you would have to type in a few key parameters. You can learn more about the Zero Touch Fabric functionality in this article.

However, if you are the kind of person who likes to do it the ‘old fashioned’, manual way, and in particular if your network will only be a handful of switches, then configuring and deploying the switches using CLI commands is a piece of cake, too. In fact, with Extreme Fabric Connect you can configure a node with slightly more than twenty commands (a few more, if you want to do it really nice).

Again, you may probably think it would be more convenient to do things like creating L2VSNs, L3VSNs, and multicast services, using a visual management tool, and indeed, ExtremeCloud IQ – Site Engine is a network management application that supports this very well. But as we have seen in one of the previous chapters, creating a layer 2 service with Extreme Fabric Connect in place requires just a single CLI command (e.g. VLAN I-SID 20 10020), or three CLI commands if the VLAN does not already exist on the edge (BEB) switch. Creating a layer 3 service requires seven CLI commands if the VRF already exists, and thirteen if you also have to create the VRF that maps to this service.

Of course, there are other methods for creating and managing new services, including APIs. The SPB capable switches from Extreme Networks now offer RESTCONF APIs, meaning that client applications can access and manipulate configuration data using common HTTP operations such as GET, POST, PATCH and DELETE. So in fact, you can use a host of application or tool to create and manage the services you want your network to deliver.

In one of the first chapters I mentioned that you can build an SPB network without a single IP address. Indeed, you can still do all the management tasks discussed above without assigning IP addresses to the switches – for example by connecting your PC to the console port of the switch you need to configure, or where you need to add a service.

However, this would become very cumbersome, especially in a network with more than a handful of switches. So, in most (or should I say all) cases you would like to assign an IP address to each switch. Here, we have three options:

(or a combination of the above choices).

I have borrowed a diagram created by my colleague, Ludovico Stevens, that illustrates this nicely:

One easy and simple way to create ´global´ management network is simply to create a L2VSN that is used specifically for management and extend this virtual network to all the SPB switches. On each switch we need to configure a management VLAN, assign an IP address to this VLAN and map it to the virtual layer 2 network. These are the simple commands you type on every switch (assuming you use VLAN 10 and I-SID 100010 for management):

vlan create 10 name management type port-mstprstp 0
vlan i-sid 10 100010
mgmt vlan 10
ip address 10.255.255.2/24 (of course, every switch will receive a unique address)
enable
(and if you want to enable access from an external net, add a static route):
ip route <net>/<mask> next-hop <nhop> [weight <val>]

(and do not get hung up on the ‘type port-mstprstp 0’ part of the first command)

Probably on a couple of switches you also assign a physical port to VLAN 10 so you can attach a PC of some kind, so you can do your management tasks. Assuming you want to reserve port 1 on a couple of switches, the command for this would be:

Management via L2VSN is illustrated below. For the sake of simplicity, the figure shows how the management network is extended only to some of the switches. It also exemplifies how you can allow access from an external net.

Alternatively, we can configure a CLIP address on a VRF for the purpose of management. The VRF could be the global routing table (= VRF 0), or any other VRF. The general advice here is to reserve VRF 0 for management and not use it for any client traffic. And of course, the IP routing will be handled by IS-IS, so there’s no need for OSPF or any other routing protocol.

On all of the switches we need to configure a circuit-less (loopback) interface on VRF 0 and give it an IP address with a host (32-bit) mask. You also instruct IS-IS to use this loopback interface as its source address when it communicates with its peer nodes.

Of course, we would also like to connect some management stations to the network so that we may perform our management tasks at hand. However, we don’t want to connect them anywhere. So let’s assume you want to reserve a port on two different switches. Looking at the figure below, where I have summarized the use of VRF 0 for management, I have attached a VLAN to VRF 0 on two switches and assigned a physical port to them.

Sometimes you may want (or need) to combine both management options described above. Anyway, this gives you access to configure services, look at the statistics, make changes to your network etc., either using a graphical management application or simply using SSH (or telnet).

Note: Choosing the right management strategy is important and should be carefully evaluated. The topic is not fully covered in this blog. Also, the management architecture for managing the SPB fabric network from Extreme Networks has been modified since a couple of years. I therefore advice you to consult the latest user guides from Extreme Networks for a detailed description of the management infrastructure and how to utilize it.

The third major OA&M task that I mentioned at the beginning of this chapter include checking connectivity. As always, there are several ways to do this, but one powerful method is to use IEEE 802.1ag Connectivity Fault Management (CFM for short), implemented on Extreme’s SPB-capable switches. CFM is a little bit complex, but the said implementation has greatly simplified the configuration and use.

As you may have already guessed, CFM is a protocol used by the switches that provides some very useful information about the network. This information (and the associated commands) includes:

Note: These commands are proprietary to Extreme Fabric Connect.

Of course, there is also a host of other useful commands built into the operating system software of the switches. These are useful for both monitoring the network as well as help you to troubleshoot the network when something goes wrong. And yes, eventually something will go wrong, even in an SPB/Fabric Connect network. The big difference, however, is how easy it is to troubleshoot compared to a classic network (or a fabric network based on EVPN for that matter). A study performed by Dynamic Markets some time ago found that the Fabric Connect customers reported significant improvements in the time consumed troubleshooting network outages, with – on average – experiencing a massive 6.5x better (or 85% improved). The highest reported improvement was 8.5x (or 92% improved)¹.

I’ve also mentioned ExtremeCloud IQ – Site Engine, a really powerful management application, which now offers the capability to monitor and visualize the fabric, traffic paths, multicast trees and so on. It also offers the capabilities to create workflows that could further automate management and operation tasks. It is, however, beyond the scope of this post to dive into ExtremeCloud IQ – Site Engine. You can learn more about it by checking out this page.

In the next part of the ‘Shortest Path Bridging for Beginners’