how-to block ads
30.3 Switching Technology
Let's assume that all hosts within the LAN uses IP version 4 as Layer-3 protocol. When IP version 4 is used, there is a protocol called Address Resolution Protocol (ARP) that maps specific IP address with specific MAC address.
During a host configuration, a NIC used to connect to the LAN is picked. Within the NIC itself, there is a unique MAC address. When the host is configured with specific IP address, the IP address is then mapped with the NIC's MAC address. This mapping of IP address and MAC address is stored within the host's ARP table.
Further, the host creates routing table which stores the NIC's assigned IP address, subnet mask, and default gateway to reach hosts outside broadcast domain.
Communication Within A Bridge
Let's say there are two hosts (Host A and Host B) within a bridge need to talk to each other. Here is the process.
* Host A initializes the communication to Host B using IP addresses
* Host A checks its routing table to see if Host B's IP address is within the same broadcast domain or not
* By comparing IP addresses and subnet masks of Host A and Host B, Host A is able to tell that Host B is within the same broadcast domain as Host A
* After Host A confirms that Host B is within the same broadcast domain, Host A checks its ARP table to find out if Host B's IP address and MAC address is listed
* If Host B's IP address and MAC address is listed in Host A's ARP table, then Host A sends frames to Host B and begins communication
Similarly, here is what happen on Host B's side
* Host B receives frames sent by Host A
* Host B tries to response to the frame by sending response frame to Host A
* Host B checks its routing table to see if Host A's IP address is within the same broadcast domain or not
* By comparing IP addresses and subnet masks of Host A and Host B, Host B is able to tell that Host A is within the same broadcast domain as Host B
* After Host B confirms that Host A is within the same broadcast domain, Host B checks its ARP table to find out if Host A's IP address and MAC address is listed
* If Host A's IP address and MAC address is listed in Host B's ARP table, then Host B sends the response frames to Host A and begins two-way communication
Once these actions take place, Hosts A and B send frames to each other and two-way communication between the two hosts are established.
How Bridge Connects Hosts To Form Communication
When Hosts A and B communicate with each other, note that neither Host A or Host B has the info of how each host connects to the LAN. It is the bridge's responsibility to provide the info in order to connect Host A and Host B.
Once a host powers up or connects to a bridge, here is what happen
* The host announce its NIC's MAC address
* As soon as the bridge sees the NIC's MAC address, the bridge records the MAC address in its MAC address table along with which bridge port the NIC connects to
* If there are multiple hosts connect to the bridge, more MAC addresses stored in the bridge MAC address table along with bridge port the hosts' NIC connect to, hence creating longer list of bridge's MAC address table
When Host A sends frames to Host B, here is what happen
* Host A sends the frame through the cable that the NIC uses to connect to the bridge
* Bridge receives the frame
* Bridge checks if Host B's MAC address is listed in the bridge's MAC address table
* When Host B's MAC address is listed in the bridge's MAC address table, the bridge forwards the frame to the bridge port where the Host B connects to
Similar events take place when Host B sends a response frame to Host A
* Host B sends the frame through the cable that the NIC uses to connect to the bridge
* Bridge receives the frame
* Bridge checks if Host A's MAC address is listed in the bridge's MAC address table
* When Host A's MAC address is listed in the bridge's MAC address table, the bridge forwards the frame to the bridge port where the Host A connects to
Bridge's MAC address Table Issue
Let's revisit the event when Host A sends frames to Host B to initiate communication. Now what happen when MAC address Host B is not listed in the bridge's MAC address table? Obviously the bridge does not know how to forward frames that Host A sends. The frames then will be dropped.
Once a host sends frame to another host, the sender host expects certain time limit to receive response frame from the other host. When the response frame is not received after time limit is passed, then the sender host retries to sends the same frame to the other host.
If the sender host still does not receive response frame after time limit is passed, then the sender host sends ARP broadcast to the entire broadcast domain to see if any hosts within the broadcast domain has the info of MAC address that is associated to the other host's IP address.
When the response frame is received after the ARP broadcast, then communication between hosts are established. If the response frame is still not received after the ARP broadcast, then the sender host assumes the other host is either down or not connected to the network. Should this event take place, then the sender host informs the operating system the host runs that the other host is unreachable. The operating system then sends error message to the host's user that communication with other host cannot be establised due to network error.
ARP Table Issue
When Host A tries to communicate with Host B, what happen when Host B's IP address and MAC address is not listed in Host A's ARP table? If Host B's IP address and MAC address is not listed in Host A's ARP table, then Host A sends ARP broadcast to the entire broadcast domain to find out if any host recognizes Host B's intended IP address.
Once the bridge the Host A connects to receive this ARP broadcast from Host A, the bridge checks its MAC address table to see if Host B's MAC address is listed. If the Host B's MAC address is listed in the bridge's MAC address table, the bridge immediately forwards the ARP broadcast to the bridge port the Host B connects to. When Host B receives the ARP broadcast, Host B sends response in a form of ARP reply with Host B's IP address and associated MAC address through the same bridge port.
The bridge then receives the ARP reply from Host B and checks to see if Host A's MAC address is listed in the bridge's MAC address table. When Host A's MAC address is listed in the bridge's MAC address table, the bridge forwards the ARP reply to the bridge port the Host A connects to.
Host A then receives the ARP reply and stores Host B's MAC address in its ARP table. Host A keeps Host B's MAC address in its ARP table until Host A no longer wishes to communicate with Host B or until Host B's MAC address ARP table store time limit is passed.
Both Bridge's MAC address Table Issue and ARP Table Issue Occur
Let's revisit the event when Host A sends ARP broadcast to try to get info of Host B's MAC address. Now what happen when the bridge the Host A connects to does not have Host B's MAC address listed in its MAC address table? The bridge then forwards the ARP broadcast to all ports the bridge has, hoping that any network device connect to the bridge has info of the Host B's MAC address.
When a network device connected to the bridge has such info, the network device forwards the ARP broadcast to the intended Host B. The network device also sends info to the bridge that Host B connects to the network device. Once the bridge receives this info, the bridge stores such info of the Host B's MAC address and the bridge port the network device connects to in the bridge's MAC address table. In other words, the bridge says that Host B is reachable indirectly through this network device.
From the bridge's perspective, this network device is consider as another bridge within the same broadcast domain connected to the network where Host A connects directly and Host B connects indirectly through another bridge.
Note that the bridge where Host A directly connects to does not need to know exactly how Host B connects to the other bridge. All communication frames between Host A and Host B have to go through the bridge port the two bridges interconnect. Therefore the bridge where Host A directly connects to only needs to know that Host B is reachable indirectly through the bridge port the two bridges interconnect.
When Hosts A and B Are Indirectly Connected
When Host A connects to one bridge, Host B connects to another bridge, and the two bridges are interconnected; then there has to be some kind of MAC address table update happening on both bridges saying that either Host A or Host B is indirectly connected through another bridge.
Let's revisit the event when the bridge Host B connects to receives ARP broadcast from Host A. As mentioned earlier, the bridge Host B connects to forward this ARP broadcast to the bridge port the Host B connects to. Once Host B receives the ARP broadcast, Host B sends response in a form of ARP reply with Host B's IP address and associated MAC address.
The bridge Host B connects to receives the ARP reply and then forward the ARP reply to the other bridge that Host A connects to through the bridge port the two bridges interconnect. The bridge Host A connects to receives this ARP reply and forward the ARP reply to the bridge port the Host A connects to. Similar process then takes place as if both hosts connect to the same bridge, as mentioned earlier.
»[HELP] Cisco switches and mac addresses
When Two Bridges In The Same Broadcast Domain Interconnect via Multiple Paths
Earlier it was mentioned that there could be more than one bridge within a broadcast domain. When some hosts connect to one bridge and some other hosts connect to the other bridge, each bridge will forward MAC address of intended host to the other bridge.
Let's review what happen when a host just powers up or connects to a bridge within a LAN consists of two bridges interconnected via multiple cables. These multiple cables that interconnect the two bridges are seen as multiple path between two bridges.
When the host just powers up or connects to one bridge, the bridge forwards the host MAC address to the other bridge in order to keep the other bridge's MAC address table updated as this one bridge. Since there are multiple path to reach the other bridge, this one bridge could choose one of the path. Once one path is selected, the one bridge forwards the host MAC address to the other bridge.
Similarly, the other bridge has to forward the host MAC address to the rest of LAN in order to keep the same updated MAC address table over the entire LAN. Since the host's MAC address is received via one path, the other bridge assumes a bridge that connects via the other path has no knowledge of this host's MAC address. Therefore the other bridge forwards the host's MAC address via the other path to a bridge.
Unfortunately the bridge connects via the other path is the same bridge that forwards the MAC address in the first place. So now the same bridge stores the very same MAC address in its MAC address table, consuming more memory of the bridge that it should.
Note that when a host just powers up or connects to a bridge, the host's ARP table is empty since the host has no knowledge yet of other hosts' MAC addresses within the same broadcast domain. In order to communicate with other hosts, the just-connected host send ARP broadcast to the entire broadcast domain in hoping to get the MAC address of its partner's host.
With scenario of multiple path between two bridges as described earlier, the host's MAC address is kept forwarded over all available paths due to the nature of ARP broadcast that are forwarded to the entire broadcast domain.
To continue what happen when the same bridge stores the very same MAC address in its MAC address table, the MAC address is then forwarded again over the first chosen path to the other bridge as part of ARP broadcast mechanism. Since all bridges keep storing the very same MAC address over and over in their MAC address table, the bridges' memory is filled up and typically is filled up fast. When the memory is filled up, the bridge can no longer forward MAC address between bridge ports as it is supposed to, hence creating a halt in the bridge working process. This halt is seen as down network since the bridge network can no longer work as expected.
You may notice that the very same ARP broadcast is kept forwarded between two switches, creating a loop. This loop as mentioned brings down network, which must be avoided at all times especially during production time. To avoid such loop to take place, there must be some way to block one path to reach other bridge from one bridge. A Spanning Tree Protocol is developed to create such way.
Let's revisit the same scenario where there are multiple paths between two bridges, and this time Spanning Tree Protocol is implemented on both bridges. When other bridge receives the host's MAC address, this other bridge does not forward the MAC address to the originating bridge since there is only one active path at a time and one active path is only used once to forward one MAC address, hence loop is avoided.
Spanning Tree Protocol: An Introduction
»Cisco Forum FAQ »Spanning Tree Protocols: An Overview
»[HELP] Cisco switches and mac addresses
Lesson 20 - Spanning-Tree Protocol Operation
Spanning Tree Protocol: Part 1 of 2
Spanning Tree Protocol: Part 2 of 2
10 Words or Less - Spanning Tree
Spanning Tree Protocol: Overview
Spanning Tree Protocol Timers
Understanding and Configuring Spanning Tree Protocol (STP) on Catalyst Switches
Understanding Spanning-Tree Protocol Topology Changes
Spanning Tree Protocol Problems and Related Design Considerations
»2950 autonegotiation taking a long time
»[Config] newbie spanning-tree question
»Root Bridge Question
»Confused - BPDUGUARD, BPDUFILTER, LOOPGUARD, ROOTGUARD
»[HELP] 2924xl switch interface boot initialize slow
»[OT] network troubleshooting "tunnel vision"
Today's Layer-2 Technology to Minimize or even Eliminate Spanning Tree Usage
Using 10 Gbps Ethernet links and faster, in addition to some proprietary link technology; switch vendors like Cisco and Juniper could offer sophisticated approach to overhaul Spanning Tree reconversion delay, creating multiple switches into single logical switch. Here are some of those technology.
VPC still require properly configured STP. VPC operates at layer 2.5 (my own numbering) as it allows the downstream switch to have the outgoing or forwarding interface to be the upstream facing port-channel rather than having STP computations over two interfaces. Peer-switch approach further 'kuldge' up the matter with both VPC peers sending the same downstream BPDU information to remove the STP reconvergence entirely during a link failure. In analyzing the port-channel frame activities, you'd see unique BPDU's from each of the Cisco Nexus 7000 links, unless peer-switch is enabled.
Different technology like VSS (c6k, c4k) and even stacking (c3k) remove STP due to the unification of the control-plane between chassis. This unification and creation of a single control-plane creates the logical appearance of a single switch.
The new Catalyst 6800 brings campus-fex to the reality, which is really just like a big Juniper VC (if you were to run an EX8208 pair at the core with EX3200 at the edges for example).
Each Cisco's VPC and VSS behave differently especially as it pertains to routing. There are additional hacks to VPC which break the VPC 'drop conditions' for running of things like routing protocols. It is recommended to run VPC as intended by the way.
Fabricpath does remove STP from the network by configuring STP in certain way for fabricpath to even function, that the fabricpath cloud has to be the root of Spanning-Tree network. Without such setup, data plane will not pass traffic even when the fabricpath control plane will not indicate a problem. This data-plane issue can be shed by Spanning Tree related show' commands.
In short, try as you might to remove stp from the network that it will either (a) hack its way out of the network or (b) have strict configuration rules in order to remove it out of the network.
In general, there are two port settings of connecting switches to some network device. The switch port settings can be either access or trunk port. When switch port is set as access port, then the switch considers the connected network device as non-switch, or to be specific is unable to understand BPDU (Bridge Protocol Data Unit). When switch port is set as trunk port, then the switch considers the connected network device as switch/bridge, or to be specific is able to speak and read BPDU.
BPDU was originally developed at times of LAN bridge introduction into networking. Back then, there was no concept of (switch) trunk port capable of carrying multiple VLAN information. The LAN bridge was developed to only deal with single broadcast domain (read: one VLAN), carried only Bridge ID and MAC addresses to determine Spanning Tree network setup.
At a time when switch trunk technology was introduced, a switch had to have certain mechanism to ensure the other end of connectivity had to have ability to acknowledge the multiple VLAN information passed through trunk port. BPDU was then used to also incorporate multiple VLAN information. In Cisco PVST for instance, switches that produce BPDU carrying multiple VLAN info could setup different Spanning Tree network design for each VLAN. Further info on this can be found in following links.
Inter-Switch Link and IEEE 802.1Q Frame Format
STP and MST
How BPDU is transmitted with Native VLAN for PVST and MSTP
As rough understanding, BPDU is now also what bridges (switches) use to pass VLAN information. In switch access port setting, the switch assumes no BPDU communication between the switch and the connected network device. In other words, the switch considers the connected network device as dumb device or regular host that need switch intelligence to determine VLAN information. By nature, the switch intelligence decides to set connected network device within the same VLAN. This nature behavior sets such access switch port to act as "old-school" bridge that carries just one VLAN.
In switch trunk setting, the switch assumes there is BPDU communication between the switch and the connected network device. This BPDU communication includes of pass multiple VLAN information. Through this trunk port, multiple VLAN can pass through simultaneously. This behavior sets such trunk port to act as multiple "old-school" bridge (or "modern" switch) that carries multiple VLAN.
In load balance or active-standby scenario, there is a need to connect a switch with some network device using multiple switch port. In a case of one connection breaks or non-function, there are still other connections to pass through traffic.
When the connected network device is non-BPDU speaking, such setup is generally set as active-standby scenario. As an illustration, a server with dual NIC without ability to understand BPDU may connect one NIC to one switch port and connect another NIC to another switch port. Server sets one NIC as active and another NIC as standby.
You may notice that such multiple connection in Layer-2 network potentially creates a loop (Spanning Tree loop) when the connected network device is BPDU speaking. To avoid the loop, those multiple connections are bundled into one virtual connection. In Cisco implementation, such virtual connection is called Port Channel.
Keep in mind that Port Channel can bundle either multiple access or multiple trunk ports. When multiple access ports are bundled into one Port Channel, this Port Channel pass through just one VLAN in active-standby or load-balance scenario. When multiple trunk ports are bundled into one Port Channel, this Port Channel has ability to pass through multiple VLAN in active-standby or load-balance scenario.
When the connected network device is BPDU-speaking, the setup of multiple connection might be set as load-balance scenario. As illustration, a server with dual NIC that understand BPDU connect both NIC into the same switch. Note that the NIC setting could be in access or trunk mode. Whichever the mode is set on the NIC, make sure that the switch ports are set the same.
More on Switching
Virtual LANs and VLAN Trunking
VLANs - Tagging ALL Traffic Implies ISL
ISL = No Native VLAN
»Cisco Forum FAQ »Switch and VLAN Management Best Practice
»[Config] Port Channels with different distance links
»Take 4 vlans in a port and pass each vlan to its own port
»Configuring Trunking Between ESXi 5 server and CISCO Switch
»VLANs from a Vswitch config Teamed Port
»2950 channel-protocol lacp pagp
»Ether Channel Help
jumbo frames and cisco gear
»[Other] Jumbo frame question (plus an observation)
vPC Best Practices Checklist
[HELP] Switch Buffers - Quick Questoin