Connecting devices in SPB networks

Let’s begin by pointing out that every device equipped with an Ethernet interface can be connected to an SPB network. However, there are a couple of different ways to connect traffic that enters our SPB network to a specific virtual network, either L2VSN (Layer 2 Virtual Service Network) or L3VSN (Layer 3 Virtual Service Network). In both cases, the device in question can be connected either directly to a BEB node, or indirectly via some other device – an ordinary Ethernet switch (or multiple hops or switches), a router etc.

Connecting to a virtual layer 3 network is very straightforward and fundamentally there is one way – it’s like connecting to a (sub)net on a router, as shown in the figure 1 below.

Connecting to a virtual layer 2 network gives you some more flexibility. In fact, there are four options:

This may sound a bit obscure, but in reality it’s quite simple. First, remember that a port that faces the world outside of the SPB domain is called User Network Interface (UNI). The four options listed above relate to the services and attributes provided at the UNI port. Secondly, remember that ‘VLAN’ in this context is a VLAN that is facing the world outside of the SPB domain (or in order words: a VLAN that is connected to one or more UNI ports).

Now, let’s see how these four options work, specifically.

This may probably be the most widely used method of attaching a device to a service in an SPB network, and it should look familiar since we’ve already presented in the previous parts of our guide. At the BEB node, you simply define (configure) a VLAN to I-SID binding. For example, the following command will bind (or map) VLAN number 7 to a virtual layer 2 network number 200.

So, for example, let’s assume we have connected an ordinary Ethernet switch to our BEB node (as shown on the left side of the diagram), using a tagged link, and we want to attach VLAN 7 to virtual network 200. The effect of the command (vlan i-sid 7 200) is depicted in the two following figures.

The switched UNI method adds a second attribute to the binding: the physical port. It means that the binding is based on a physical port plus VLAN ID. For example: VLAN 7 on physical port 4 could be mapped to I-SID 200 and VLAN 7 on port 15 could be mapped to I-SID 300. VLAN 10 on physical port 4 could also be mapped to I-SID 300.

The commands to create a switched UNI are quite simple and look like this:

i-sid 200 elan 
(this creates the virutal layer 2 network)

c-vid 7 port 4 
(this associates/maps VLAN 7 on port 4 to this I-SID)

The effect of these commands is depicted in the two following figures.

This is probably the simplest way to map traffic to a virtual layer 2 network – a physical port (UNI) is mapped to a virtual layer 2 network (an I-SID). Everything that is received on this port (tagged or untagged, Spanning Tree BPDUs, LACP, LLDP, etc.) is forwarded into this specific virtual network (with the only exception being the Ethernet Flow Control Pause frames).

This could be very useful if you are serving different customers/departments and you do not want to get involved in their VLAN configuration, e.g. having customer A on port 1, customer B on port 2 and so on. Whatever traffic is delivered on port 1, it is forwarded to the virtual network serving customer A.

Let’s assume a different scenario: you need to create a network that connects some devices (potentially spread across your infrastructure) with some odd requirements, e.g. they must be directly wired to each other. Now this is obviously hard to achieve when you have to pull cables all over the place, you may also run into some distance constraints. However, using a transparent UNI to interconnect those devices will make them look like they were directly wired to each other – that’s because we have created virtual cables between them.

In the figure below we have created two transparent UNI (networks). Everything that is received on port 8 belongs to virtual network 200. Everything that is received on port 12 belongs to virtual network 300.

The commands to achieve this are simply:

Transparent UNI is similar to E-Line services in the MPLS world, and you can extend a transparent UNI network to any location in your network.

An E-tree NI is slightly more complex but very similar to the private VLAN concept. You can think of it as a tree structure, with a root and some leaves (or hub and spokes). Traffic can flow from the root to the leaves, and from the leaves to the root. However, traffic can never flow from one leaf to another leaf (for this to happen, traffic will first have to be sent to some central device – like a firewall – via the root).

Let’s consider a following example: you want to provide internet services to four different customers or departments via one central firewall. However, there must be no direct connectivity between them all. The configuration is slightly more complex, so we’ll leave if for the product user guide to show this. Just consider the following figure.

Let’s remind ourselves that we can stretch a virtual layer 2 network to any ‘corner’ of your physical infrastructure. So in some extreme cases, every edge port in the network can be part of the same virtual layer 2 network (though there are some scaling limitations, depending on the switches used).

It is possible to assign VLAN UNIs and Switched UNIs to the same I-SID, meaning that the VLAN which constitutes the VLAN UNI will be joined (bridged) together with the VLANs that are mapped to the Switched UNIs. This is also possible on the same local BEB! On the other hand, Transparent UNIs cannot be mapped to the same I-SID as a VLAN UNI or a Switched UNI. Also, let’s remember that various virtual networks can be interconnected as/if needed.

All good things must come to an end and so has too our journey across the Shortest Path Bridging networks. What doesn’t end, however, is the popularity of Extreme Fabric Connect, the market-leading, SPB-based fabric network solution from Extreme, which is constantly evolving with new capabilities and features introduced on a regular basis.

We hope that this guide has given you an insight into the fundamentals of Shortest Path Bridging, as well as the Extreme Fabric Connect solution and its capabilities, allowing you to create any type of service you need to support your users and application with – easily and with great flexibility.