Expert Reference Series of White Papers. Routing at Layer 2: FabricPath

Transcription

1 Expert Reference Series of White Papers Routing at Layer 2: FabricPath COURSES

2 Routing at Layer 2: FabricPath Alex Marcotte, CCIE 16673, Cisco Certified Instructor, Cisco WAN Specialist First, Some Background When networks were in their infancy and before the OSI model was even a concept, people wanted to connect devices together to avoid the inconvenience of the sneakernet, which consisted in placing data onto a ribbon device or one of those new magnetic floppies and walking it over to the other computer your company had (Figure 1). Figure 1 Once we figured out that we could connect computers on a point-to-point connection with a serial cable and get information exchanged without the sneaker part, we discovered that we had greater productivity than before. After this monumental achievement, companies then decided to splurge on buying a third computer (Figure 2). And that s when things got complicated, and networks really began to take off. Figure 2 Copyright 2011 Global Knowledge Training LLC. All rights reserved. 2

3 I am going to spare you the early debates among engineers, but eventually someone was tasked with writing a layer 2 protocol that would provide a connectivity solution. That would eventually become a standard known as Ethernet. Ethernet was a game changer. End Nodes were now required to have a Media Access Control (MAC) address composed of 48 bits worth of hexadecimal characters to uniquely identify each node. Ethernet frames would then carry data with headers in front of them that identified the source MAC and the destination MAC of each frame. Effectively, when node A wanted to send data to node B, it sent a frame with the destination MAC address of the NIC it was trying to reach. If node A then wanted to send data to node C, node A would just change the destination MAC address of the frame and off it would go, allowing us to use a shared media. Switches eventually entered the fray to try to accommodate as many devices on the network as possible, without over-burdening the network with traffic, by filtering the traffic sent from node to node by only using the ports necessary to transmit such data after learning dynamically where the MAC addresses were connected, and sometimes flooding the network with unknown unicast or broadcast traffic. At the time, networks were only built as layer 2 because connecting one network to another was considered absurd. To quote Radia Pearlman from her recent techtorial, when she raised the issue of scalability to her boss and the fact that networks would eventually be interconnected, her boss replied Why would anyone want to do that? One of the issues raised at the time was that layer 2 frames lacked certain intelligence and, for example, did not have a Time to Live (TTL) field, unlike layer 3 networks. If someone were to interconnect two switches together with multiple L1 links and send an unknown unicast on the network, the two switches would continue to send the traffic to one another, and the frame would never be discarded. This would create a broadcast storm and bring the network down (the switches would be too busy to forward legitimate traffic). To remediate this issue, a protocol called Spanning-Tree was developed to ensure that no loops would be created on a Layer 2 network by disabling redundant links to switches and marking them as alternate links. In the early networks, spanning-tree worked like a champ, providing an insurance policy to network admins that there would be no loops and eliminating the possibility of broadcast storms that would bring down the network. Figure 3 Copyright 2011 Global Knowledge Training LLC. All rights reserved. 3

4 When looked at from a simple connectivity point of view, the problem was solved, and everyone lived on the Layer 2 network happily from then on. Today s Situation A problem has surfaced in recent years when bandwidth needed to be shifted from WAN to LAN and data centers wanted to switch frames as quickly as possible. Network administrators were faced with two options: Either leave the network running Spanning-Tree with one out of two uplinks working or use Portchannels between switches to augment the bandwidth by getting spanning-tree to treat those links as one logical link. When redundancy designers looked at it, they realized that while PortChannels are great, they are typically bound to another single switch, and an alternate path to the destination would be blocked following the spanning-tree rules. So Virtual Port Channel (VPC) came along to alleviate those challenges. Figure 4 From a bigger picture point of view, time finally came to give intelligence to those L2 frames. What about routing frames like a Layer 3 protocol would do? Some simplistic engineers would say: Just make your network a Layer 3 network then! and problem solved. However, technologies such as VMware s Vmotion want you to move hosts from one side of the network to another, making your network LFNs (long fat networks). Copyright 2011 Global Knowledge Training LLC. All rights reserved. 4

5 Enter FabricPath. Cisco developed FabricPath and implemented it ahead of schedule on select hardware such as Nexus 7000 F modules and soon to be on Nexus We mentioned Dr. Radia Perlman earlier, who is also working on TRILL, which is going to be an open-vendor protocol aimed at resolving the same challenges. According to Cisco, FabricPath is more feature-rich than TRILL, and all the Cisco devices that support FabricPath will be able to support TRILL. But, TRILL is not out yet so it is difficult to really see what happens when the rubber meets the road there. FabricPath is already out and working, and the configuration is quite simple (Figure 5). Figure 5 What both protocols aim to do is to give a switch the ability to see what the destination MAC address of your frame is going to be, then route it (note that I said route) via the optimal path to its destination. In regular switching networks, the switches usually learn each other s MAC address table during regular transmissions and build their tables accordingly. For example, switch A would learn that a host connected to switch C needs to talk to switch B, almost as a hop-to-hop basis, which is what TRILL is based on, according to what I have seen. FabricPath is different in the way this works: switch A would learn that switch C has the destination MAC address via a discovery or via conversational process. The switches would exchange this information on an IS-IS backbone that is established between them. The IS-IS process (hidden from the network admin) would be in charge of determining which path is the optimal path to switch C using the IS-IS algorithms, regardless of the topology changes on the network, effectively getting rid of spanning-tree recalculations on the network. Copyright 2011 Global Knowledge Training LLC. All rights reserved. 5

6 Figure 6 Overall, FabricPath gives you a full Layer 2 vision of the network without having to rely on what your immediate peer says. Switches are informed of MAC addresses on a need to know basis so there are no full exchanges of routing tables as in Layer 3 networks. In theory, you could move a host from one end of the network to another, and the switches would adapt on how to reach that MAC and what the best path would be from each switch s point of view. In other words: no more roots. Every switch on the network has fair access to the FabricPath topology and gets to forward frames on the topology without having to fear any loops. I will not get into the FabricPath topologies here in too much detail, but they should be considered as areas like OSPF areas. The mechanics work like this: switch A receives an ingress frame meant for a MAC address that is currently unknown to this switch. The switch will hold the frame and send a L2 discovery, like ARP. Switch C realizes that the MAC belongs to it and sends over its switch ID number. What switch A has to solve now is: what is the best path between my switch ID and the switch ID of C? This kind of information is learned from the IS-IS part of FabricPath. Once the path is learned, it will be stored in the local L2 routing table, and the frame will be modified. The original frame will now be inserted with the local port ID, the local switch ID, and the remote switch ID. (Note: the remote port ID is completely irrelevant to the originating switch.) Copyright 2011 Global Knowledge Training LLC. All rights reserved. 6

7 Figure 7 Once this frame is on the forwarding table, the switch will determine the best path and send the frame over. The receiving switch will forward it to its appropriate port, and every switch in between just needs to know that the remote switch ID is; no need to worry about the MAC at this time. Of course, the switches need to participate in the FabricPath topology in order for this to work. Switches can bond together by simply making the switch ports FabricPath ports and enabling the feature on your hardware. Summary FabricPath can give network admins the possibility of connecting any switch to any switch without rhyme or reason. No need for port channels here. Need more bandwidth? Just connect more ports from one switch to another and consider your problem solved. Overhead? Hardly any, given that only select hardware are supporting this at this time. Reconvergence? Forget it. This acts as a layer 3 protocol. Learn More Learn more about how you can improve productivity, enhance efficiency, and sharpen your competitive edge through training. Check out these courses: DCNX7 - Data Center Networking with the Cisco Nexus 7000 DCNX5+7 - Data Center Networking with the Cisco Nexus 5000 & 7000 Copyright 2011 Global Knowledge Training LLC. All rights reserved. 7

8 Visit or call COURSES ( ) to speak with a Global Knowledge training advisor. About the Author Alex Marcotte is a CCIE in security #16673, Cisco Certified Instructor (CCSI) and a Cisco WAN Specialist with 14 years of experience in the field. He manages a data center in Houston, Texas (Evertech, LLC) which hosts several business applications such as remote backups, and virtual servers. Copyright 2011 Global Knowledge Training LLC. All rights reserved. 8