Category: LAN
Understanding MSTP
Ten steps of small LAN design
Every so often someone tries to apply the “let all be friends and love each other” mentality to LAN networks and designs a pure layer-2 switched LAN (because it’s simpler). Jay contributed a ten-step “what happens next” description in his comment to my “Lies, damned lies and product marketing” post. The steps are so hilarious I simply had to repost them:
- Build everything at layer 2 because "it's simpler".
- Scale a little.
- Things start breaking mysteriously. Run around in circles. Learn about packet sniffers and STP.
- Learn about layer 3 features in switches you already own. Start routing.
- Scale more.
- Things start breaking mysteriously. Learn about TCAMs. Start wishing for NetFlow.
- Redesign. Buy stuff.
- Scale more.
- VMWare jockeys start asking about bridging across the WAN.
- Enroll in hair loss program.
Lies, damned lies and product marketing
Greg Ferro’s “Layer-3 routing” post successfully kicked my huge sore spot: the numerous ways technical terminology is abused by product marketing gurus.
Twenty years ago, before networking became a multi-billion dollar industry, things were clear, simple and consistent: layer-2 (data-link layer) frame forwarding was bridging and layer-3 (network layer) packet forwarding was routing. Everything was crystal clear until some overly smart people tried to turn bridges into something they were not: WAN extension devices. A few large WAN networks were built with bridges … and failed spectacularly. Router vendors quickly used the opportunity to push the “routing is good, bridging is bad” mantra.
Carrier Ethernet service from customer’s perspective
As the Carrier Ethernet services are becoming more popular, people are starting to wonder how to use it in a router-based network. I’ve got the following question from one of my readers:
I was wondering if it was possible to design a redundant network where the core uses L2 MPLS, the provider edge uses L2 for access but the customer edge equipment uses L3 Routers. We don't want to customer to see any STP at their routers.
Of course you can do that. There are two scenarios to consider:
(A) The Service Provider is offering point-to-point Ethernet service (pseudowire). In this case, two of the customer routers would be connected with what looks like a point-to-point Ethernet link. Usually the remote site would have just one "outside" Ethernet connection while the hub site would have numerous links bundled in a trunked (VLAN) link.
(B) The SP is offering VPLS service. In this case, all customer routers appear as being connected to the same Ethernet segment.
In both cases, the customer edge (CE) routers should treat the SP Ethernet link as a simple LAN segment, in case (A) connecting two routers, in case (B) connecting many routers.
Turn a switch into a hub … the Microsoft way
If you’ve ever tried to get advanced Cisco certifications, you’ve probably encountered questions dealing with the mismatch between the end device ARP timeouts and the L2 switch CAM (MAC address cache) timeouts. If you’re still wondering what the underlying problem is (it took me a while to figure it out), read the Unicast Flooding in Switched Campus Networks document from Cisco.
In all scenarios, traffic sent to unknown unicast MAC address causes layer-2 flooding, which can significantly reduce switch performance. Microsoft took this problem to a completely new level with its Network Load Balancing implementation: Windows servers send ARP replies containing MAC address X from MAC address Y, causing all the traffic toward the servers to be flooded – effectively turning an Ethernet switch into a hub.
Followup: VLAN interface status
Thanks to my readers, I often learn something completely new about the intricacies of Cisco IOS. The “VLAN Interface Status” post resulted in a comment about the SVI autostate concept, which is (not surprisingly) a somewhat muddy topic:
- In most cases, the SVI interface tracks the state of access and trunk ports using the VLAN. The details are well explained in the Understanding SVI Autostate section of the Cisco IOS documentation.
The important part of the SVI autostate calculation is the “port is in STP forwarding state for the VLAN” requirement. If a VLAN is not carried in a trunk port (for example, due to switchport trunk allowed configuration command), the trunk port’s status does not influence the autostate.
- In some IOS releases, you can exclude the individual physical ports from the autostate calculation with the switchport autostate exclude interface configuration command. Most commonly you’d want to exclude uplink ports on access switches.
- In some unspecified IOS releases (including 12.4T), you can use the (currently undocumented according to Command Lookup Tool) no autostate VLAN interface configuration command, which disables the autostate algorithm and makes the SVI interface permanently active.
Quick tip: VLAN interface status
Vijay sent me this question a while ago:
I have configured a L3 VLAN interface on a Cisco 3750 switch and assigned an IP address to it. I haven't assigned any ports to this VLAN. Why am I not able to ping the IP address of the VLAN interface from the switch itself?
The VLAN interface (like any other interface) has layer-1 and layer-2 state.
The layer-1 state is displayed in the Status column of the show ip interface brief command, the layer-2 state in the Protocol column.
A VLAN interface is always up, but its line protocol state tracks the state of attached ports: if at least one port is operational, the line protocol of the VLAN interface is up, otherwise it’s down. With no ports assigned to a VLAN, the line protocol of the VLAN interface is down, its IP address is not in the IP routing table and thus you cannot ping it.
This article is part of You've asked for it series.
… updated on Saturday, December 26, 2020 14:04 UTC
Multihomed IP Hosts
IP host (workstations, servers or communication equipment) is multihomed if it has more than one IP address. An IP host can be multihomed in numerous ways, using one or more layer-3 interfaces for network connectivity. Some multihoming scenarios are well understood and commonly used, while others (multiple physical layer-3 interfaces in the same IP subnet) could be hard to implement on common operating systems.
Blurt from the past: ATM LANE module for Catalyst 3000
I've found the following "gem" in the Catalyst 3000 LANE module data sheet:
The module "provides legacy LANs with access to ATM-based services in an ATM campus backbone".
The legacy LAN was switched Ethernet (which is still around after 15 years) and ATM campus backbones have joined the dinosaurs.
In case you've never seen a Catalyst 3000: it was a switch that Cisco got through one of its first acquisitions and although it was a good Ethernet switch, it was a nightmare to configure and the later additions (for example, the LANE module) were a disaster. Luckily, it was allowed to die a quiet death a few years later.
VPLS Is Not Aspirin
If you’re old enough to remember the days when switches were still called bridges and were used to connect multiple sites over WAN links, you’ve probably experienced interesting network meltdowns caused by a single malfunctioning network interface card. Some of you might have had the “privilege” of encountering another somewhat failed attempt at WAN bridging: ATM LAN Emulation (LANE) service (not to mention the “famous” Catalyst 3000 switches with LANE uplink).
It looks like some people decided not to learn from others’ mistakes: years later the bridging-over-WAN idea has resurfaced in the VPLS clothes. While there are legitimate reasons why you’d want to have a bridged connection across the Service Provider network, VPLS should not be used to connect regular remote sites to a central site without on-site routers, as I explained in the VPLS: A secure LAN cloud solution for some, not all article I wrote in 2009 (republished below).
Carrier Ethernet: the big picture
My regular readers are probably not surprised to learn that I dislike buzzwords and marketectures. I’ve heard so much about Carrier Ethernet in the last few years (not including confusing definitions of what it’s supposed to be) that I decided to write an article about it. It was recently published by SearchTelecom as “Carrier Ethernet: Big picture issues for carrier deployment”.
Generating layer-2 broadcast from a regular IP packet
The Wake-on-LAN discussion we had a while ago brought us nowhere; there's simply no way to generate UDP packets on the router. I thought I could use Application Performance Monitor's Tcl scripts to generate the packet, but it looks like APM has been removed from recent IOS releases (and it's not clear whether you can use APM without a peer router).
The discussion nonetheless had an interesting side effect. Robert Turnšek sent me an interesting trick: with static ARP you can generate layer-2 broadcasts with a layer-3 unicast packet.
Blocking rogue DHCP servers
The reader who was concerned about making a loop while connecting a switch to itself was also facing “customer-installed” DHCP servers in his LAN. He wrote:
Some users have installed their own Linksys routers and plug our cable in router's LAN ports, so there is DHCP servers fight in our LAN. How can I sort this out (I cannot physically find the location of the Linsys routers)?
The ideal solution is DHCP snooping (assuming your switch supports it), well documented on www.cisco.com. The basic configuration takes only a few minutes:
Connecting a switch to itself: does it hurt?
I’ve got an unusual question a few days ago:
Does a loop (cable returning back to same switch) in one switch affect other switches? How can I detect that there is such a problem in a particular switch?
The correct answer to the first question is obviously it depends. To start with, it depends on whether the two ports will be able to communicate. With a crossover (switch-to-switch) cable (and assuming there are no negotiation issues), the physical layer will work correctly. If you’re using a standard RJ-45 patch cable, you’re “out of luck” unless the switch is too smart and has auto-MDI sensing (like the Linksys switches, now well hidden under obscure part numbers like Cisco SRW248G4). In this case, the two ports will become active even connected with a patch cable.
Should VTP be disabled by default?
One of my readers sent me a question that triggered one of my old grudges:
In my experience, when you first add a new switch (having a NULL domain) on an existing VTP Domain, it inherits the domain name, regardless of it being a VTP Server. I was wondering if this is a feature (i.e. has proved to be a solution in most cases) or a bug (i.e. has proved to cause problems in most cases). I know it's proved to be the latter for us!
In my personal opinion Cisco at one point in time wanted too much plug-and-play and someone had a great idea that you can just plug another switch into your network and it would autoconfigure itself. We've been suffering because of that "insight" ever since (and the CCIE written test has material for a few more interesting questions :).
I strongly believe that VTP should be turned off by default and should generate a warning before being enabled, but it will probably not happen. What do you think?
Disclaimer: I am not a switching person and have no idea about anything below or above layer 3.