Category: LAN
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.
Internet Access Russian Dolls
When the local Telco installed my blindingly fast 20 Mbps Internet-over-fiber-cable service, I was expecting to use DHCP on the router’s outside interface to connect to the Internet. After all, they’re running switched Ethernet VLANs over the fiber cable, and using DHCP seemed a logical choice. Imagine my surprise when I had to configure PPP-over-Ethernet (PPPoE) – it was as if I would be using a DSL connection, not a fiber-optic cable.
Are VLANs safe in DMZ environment?
Measure the cable lengths on a Catalyst switch
At one point someone posted an article about a command you could run on the Catalyst switch that would give you back the distance of the cable between the switch and end device, but now I can't find it.I remembered reading the same article and after I've figured out the underlying technology is called TDR (Time Domain Reflectometer), uncle Google immediately provided a reader tip from Csaba Farkas.
CEF and MLS
Harold Arley Morales has asked an interesting question:
What's the difference between Cisco Express Forwarding and Cisco MLS? Is Cisco's implementation of MLS standardized?
CEF is a routing table lookup mechanism. Instead of doing a lookup in the main IP routing table (displayed with the show ip route), the router does a lookup in a fully computed non-recursive version of the IP routing table (Forwarding Information Base - FIB) with layer-2 next-hop information attached to it (adjacency table).
MLS is a caching mechanism (similar to Netflow) that offloads layer-3 processing from the routing component into layer-2 ASICs that cannot perform full-blown layer-3 switching. When the layer-2 engine detects a single IP packet traversing multiple VLANs, the MLS populates the cache with the flow details and the subsequent packets belonging to the same flow (same source/destination IP addresses and port numbers ...) are switched without going through all the layer-3 mechanisms (for example, access lists). The Multilayer Switching Overview document gives you additional details.
The MLS uses a proprietary protocol (MLSP) through which the layer-2 switches identify routers.
This article is part of You've asked for it series.
Update 2008-12-08: Ofer Granit sent me the following information: according to Troubleshooting IP Multilayer Switching document, Supervisor Engine 2 and Supervisor Engine 720 no longer use MLS but rely exclusively on CEF to perform layer-3 forwarding.
MAC addresses on VLAN interfaces
Unconditional trunking port on a Catalyst 3560
Rob van Ooijen has sent me a really interesting question:
I've configured a switch port to be unconditionally a trunk with the switchport mode trunk configuration command. However, when the interface was enabled, I've got a dynamic trap indicating the trunking was still dynamic (and the show commands also showed negotiation of trunking is enabled).
In fact, adjacent layer-2 devices can negotiate a number of things these days, among them:
- Speed and duplex settings (we'll leave this can of worms safely closed);
- Trunking (a port can be access or trunk port);
- Trunk encapsulation (ISL or 802.1q);
With the switchport mode trunk command you just disable the trunking negotiation (the port will never become an access port), but the switch still runs Dynamic Trunking Protocol (DTP) on it, unless you disable DTP with switchport nonegotiate, which (in combination with all the other configuration commands) makes the port configuration totally static. More configuration can be found in Cisco's documentation and in the Basics of DTP document.
This article is part of You've asked for it series.
Interesting QoS problem on Catalyst 3750
Mohammad Faraz Rehan has encountered an interesting problem when using IP access-list based class/policy maps on Catalyst 3750:
When I try to apply the same service-policy to more than 15 interfaces, the configuration command fails and the switch generates the following syslog message:
%QOSMGR-4-POLICER_PLATFORM_NOT_SUPPORTED: Policer configuration has exceeded hardware limitation for policymap …
I've tried to help him with various TCAM-related information and in the end he found an interesting solution to the problem:
It looks like there is a limit related to using the same access-list/class-map/policy-map on multiple interfaces.
The first time I was applying the same policy-map (19 classes/19 ACLs/46 ACL lines) on all interfaces, but the switch would not accept it on more than 15 interfaces. Another test scenario had 18 classes/18 ACLs/52 ACL entries and the same policy-map would only work on 13 interfaces.
Now we implemented 24 different policy-maps, class-maps and ACLs remained the same, and the switch is happy.
TCAM on Catalyst switches
Catalyst switches have an interesting internal architecture that uses a Ternary Content Addressable Memory (TCAM) to perform a variety of lookups. For example:
- If a CAM entry matches on destination MAC address, it performs L2 switching (aka bridging)
- If it matches on destination IP address, it performs L3 switching (aka routing)
- If it matches on a combination of source/destination IP addresses and ports, it can be used to implement access lists, QoS mechanisms or policy routing
To make things even more interesting, multiple TCAM entries use the same mask (don't care bits) as explained in the Understanding ACL on Catalyst 6500 Series Switches white paper. Most of that information also applies to the Catalyst 3750 platform, more details are available in the Understanding and Configuring Switching Database Manager on Catalyst 3750 Series Switches document (here is the corresponding document for Catalyst 3550). As the TCAM size on Catalyst 3750 might not be large enough, you can split it in various ways with the SDM templates.
Making the case for Layer 2 and Layer 3 VPNs
Occasionally someone would try to persuade me that the layer-2 VPN services are like aspirin (you know, totally harmless plus it could get rid of all your headaches). OK, that might be true if you take the layer-2 VPN offering as a pure transport solution and plug in an extra router (sometimes also called a layer-3 switch by marketing people) between the Service Provider’s Ethernet (or whatever they give you) and your LAN. But there are people who don’t know the details and plug the SP Ethernet straight into their L2 switch … and things might even work for a while … until the whole network collapses.
In my opinion, we need both L2 and L3 VPN services, but it’s important that they are positioned and deployed correctly. You can read more about my views on this topic in the SearchTelecom article Making the case for Layer 2 and Layer 3 VPNs.
Static routing with Catalyst 3750: and the winner is …
The Static routing with Catalyst 3750 post has generated a lot of good, creative ideas. Some of the proposed solutions were better than the others and some were simply not implementable (but nonetheless, had great creative potential :). Here is my list of the favorites:
A routing protocol: as a few of you have rightly pointed out, this is the best choice.
Aggressive Unidirectional Link Detection (UDLD): this is my second favorite, as it's a reliable link-level mechanism that will detect a break in the fiber cable … exactly the right tool for the job.
Don't miss the obvious
After replacing the software (didn't help) and tweaking DHCP timers (no change), it finally dawned on me: the ethernet ports are switched, so the spanning tree was playing tricks with me. Disabling spanning tree with the spanning-tree portfast interface configuration command solved the problem.