Once up a time there were other LAN protocols and Ethernet was but one of many LAN network protocols. Fiber Distributed Data Interface (FDDI) and Token Ring were also common and had many superior capabilities but because Ethernet was easy and cheap (both for network equipment and cabling) it was the most common way to connect desktops to a network. Token Ring was popular for desktops but was also much more expensive.
Therefore it was a common requirement to connect FDDI or Token Ring LANs to Ethernet LANs using bridging.
The Catalyst OS of the day reserved the Ethernet VLAN ID 1002-1005 in the software so that there would be default VLANs for the FDDI and Token Ring interfaces to belong to and then be bridged into the appropriate Ethernet VLANs (because routing was too expensive and very slow to be used).
|VLAN 1002||Default FDDI VLAN|
|VLAN 1004||Default FDDI NET VLAN|
|VLAN 1005 (trbrf-default) with bridge number 0F||Default Token Ring TrBRF VLAN|
|VLAN 1003 (trcrf-default)||Default Token Ring TrCRF VLAN|
Later, the code that managed this process was still left in the IOS SX software because it was tightly bound to other VLAN code it couldn’t be removed. Today, I think these VLANs are still reserved because the legacy code is still in place, and because it might cause software defects if it was removed – it’s not causing a problem so why change anything 1
In the latest Cisco Nexus switches, the new software platform does not contain any of the legacy code ( or any need to work with FDDI or Token Ring) and so does not have this restriction.
Cisco’s reluctance to move their code base forward is annoying and reassuring at the same time. On one hand, they should be able to refactor their code easily and progressively without causing problems. On the other hand, I don’t want to see the code unstable and unreliable. This whole issue highlights Cisco’s IOS SX software development and architecture as reasonably poor. ↩