Moving around SPB – how does traffic get from A to B?

In the previous article in our series we have established that an SPB network is basically built on two types of switches: Backbone Edge Bridges (BEBs) and Backbone Core Bridges (BCBs). Apart from participating in building network topology, the four most fundamental tasks a BEB node has to take care of are following:

Before we leave the BEB node and move on to the next topic, of course it would be prudent to explain how does it even know where the destination is connected. Well, our little BEB node learns about all the end-nodes connected to itself locally (even the ones that may be connected to an ordinary Ethernet switch that in turn connects to the BEB node). What’s more, it also learns about remote end-devices from other BEB that is a member of the same virtual layer 2 network.

Let’s take a look at the figure below:

Since the nodes BEB1, BEB2, BEB3, and BEB4 are all part of the green virtual network, they also learn about the green end-stations that are attached to this virtual network. For example, BEB1 learns that the PC11 and PC12 stations are directly connected to it. In addition, it also learns from BEB2 that PC21 and PC22 are connected to BEB2, from BEB3 he learns that PC31, PC32, and PC33 are connected to BEB3. And finally, it learns from BEB4 that the S1 server is connected to BEB4. So if BEB1 receives traffic from PC11 with server S1 as the destination, then BEB1 will automatically know that it has to send it to BEB4.

I know what you might be thinking: a BCB node has quite an easy life! It switches traffic from the in-port where it receives a frame to the out-port which is on the shortest path to the destination. This is exactly how Ethernet switches operate; the only difference is that an SPB does not do ‘flooding and learning’, as any ordinary Ethernet switch would do (and by the way, no broadcast either). And that’s about it!

However, there’s one tiny thing that still needs to be taken care of: to ensure that no traffic is looping in case something goes wrong!

When a BCB node receives a frame on one of its NNI ports, it checks if the frame is received on the port that is on the shortest path back to the sender. If that’s the case, then everything is fine and the frame is forwarded to its destination normally. If not – well – then something has gone wrong and the frame is dropped to avoid the traffic loop. So, as you can see, traffic will never loop in an SPB network, and there’s no need for some ‘time-to-live’ mechanism that kicks in, in case traffic loops for a certain amount of time.

Now you may think, “if there is no flooding and learning in the SPB Ethernet, how do the SPB nodes learn about other SPB nodes in the network?” or “how do they learn about hosts and devices that are connected to the network?” The simple answer is that it is the task of IS-IS to distribute this information. Of course, all SPB nodes need an address (an Ethernet address, to be precise), and there are – guess what – two options:

Let’s take a look at our previous network scheme again and assume that PC11 wants to communicate with server S1.

PC11 will send an IP packet to S1. If this is the first communication (and assuming PC11 already knows the IP address of S1), PC11 will send and ARP request to learn the MAC address of S1. This ARP request is multicasted by BEB1 to all the BEB nodes that are members of the green virtual network (meaning that BEB2, BEB3 and BEB4 will be the ones to receive it). BEB2, BEB3 and BEB4 will then broadcast it to all green stations. S1 will send an ARP reply which BEB4 will receive. Knowing that the ARP request came via BEB1, BEB4 will forward this ARP reply to BEB1, which in turn (after having the outer Ethernet frame stripped off) will forward it to PC11. PC11 can now encapsulate the IP packet in an Ethernet frame that has the MAC address of S1 as the destination address (and his own MAC address as the source address). PC11 sends this Ethernet frame to BEB1. As we’ve already seen, BEB1 will encapsulate this frame in a new Ethernet frame and – having learned that S1 is connected to BEB4 – it will use the MAC address of BEB4 as the destination address and send it out on the interface that is on the shortest path to BEB4. All nodes in between BEB1 and BEB4 will just look at the destination MAC address (which is the MAC address of BEB4) and forward it on the out interface that is on the shortest path to BEB4. Upon receiving this frame, BEB4 will strip the outer Ethernet frame off and forward the original Ethernet frame to S1.

Seems complicated? It is anything but, however to better understand this, here’s a little graph:

From the graph above you will also notice that we are using the term B-DA and B-SA in the Ethernet addressing fields. These are MAC addresses as we have known since the day of Ethernet; we just use the notation B-DA and B-SA to indicate that this is the destination and source MAC address of the backbone (meaning the SPB network).

One last thing to mention: the outer Ethernet header has a field that is not in a ‘normal’ Ethernet frame: the I-SID field.

The I-SID field is a service identifier, or virtual network identifier, and is crucial to the properties of the SPB technology. In our example above, it identifies the green network. The I-SID file is 24-bits wide which allows us to define 16777215 virtual networks. Some are reserved, so for good measure we say 16 million (which should be sufficient for most deployments). As you probably have understood by now: an I-SIDs is globally unique. And for layer 2 virtual networks, as we have seen at the edge of the SPB network, I-SIDs are attached/mapped to VLANs.

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