The way Cisco switches will handle it is by cutting off the offending loop ports. Most switches can identify a loop long before any frames get caught up. Because Ethernet doesn’t have a time to live like TCP/IP does (at least, as far as I know, it doesn’t), this process will repeat infinitely. So, the frame will go back to ports 19 and 20 on switch 1, where it will repeat the process. When it comes out on port 20, it will try to deliver it to ports 1-6 and port 19. When it comes out on port 19, it will try to deliver it to ports 1-6 and 20. Ports 19 and 20 will carry the packet over to switch 2. So, it will go to ports 2-6 and, because they are trunk ports with a native VLAN of 10, it will also deliver it to 19 and 20. Switch 1 will know that it needs to deliver that frame to every port that’s a member of VLAN 10. Then, switch port 1 on switch 1 sends out a broadcast frame. Imagine that we have configured ports 19 and 20 on each switch identically and wired them together. That’s because we’ll have created a loop.
In fact, either of these approaches will fail with fairly catastrophic effects. Even if we configure ports 19 just like we have ports 20 configured, it still won’t work. But, we can’t just go blindly plugging in a wire between them, either. Port 19 is empty on each of these switches. To save you from needing to click back to part 2, here is the visualization again: Part 6 – Ports, Sockets, and Applications.
#Hyperswitch mac alternative windows#
Windows Server introduced the ability to team adapters natively starting with the 2012 version. I mentioned then that I would likely use link aggregation to connect those switches in a production environment. In part 3, I showed you a diagram of a couple of switches that were connected together using a single port.
0 kommentar(er)
