100-490 RSTECH: Legacy CCT Routing and Switching Exam

100-490 RSTECH was the Cisco Certified Technician Routing and Switching exam for technicians who performed on-site support and maintenance of Cisco routers, switches and operating environments. Cisco retired the exam on February 9, 2025. It is no longer available for certification or recertification.

The current replacement is 800-150 FLDTEC, which combines routing, switching, data center, UCS and collaboration field-support skills into one CCT Field Technician path. The historical RSTECH page remains useful for understanding what the routing-and-switching specialization tested and how those skills fit the current Cisco certification structure.

The retirement creates the same distinction seen with the other former CCT tracks: an old exam page can remain technically valuable without representing a bookable exam. Employers may still have runbooks, inventory labels or training records that refer to RSTECH. New candidates should preserve the technical context while anchoring certification decisions on FLDTEC.

RSTECH focused on keeping network hardware serviceable in the field

The exam was not a design credential and did not require the breadth of CCNA. Its purpose was to validate the technician who could identify hardware, connect to the device, preserve or restore configuration, replace components and verify that a router or switch returned to service. That work sits close to the physical and operational layers of networking.

Understanding this role prevents candidates from misreading the old blueprint. Routing protocols mattered mainly as background to device function; the technician's primary task was to maintain equipment safely and gather evidence for escalation. Product identification, cabling, console access and basic IOS operation therefore carried more weight than advanced network architecture.

A field visit usually began before the console cable was connected. The technician needed the correct device, replacement part, maintenance authorization and remote contact. In racks with multiple similar switches or routers, serial-number and slot verification protected against servicing the wrong system. That preparation is part of technical quality because physical errors can create outages no command can fix.

Networking fundamentals supported every service task

RSTECH covered the OSI and TCP/IP models, IPv4 and IPv6 addressing, common network devices, Ethernet media and basic services such as ping, FTP, TFTP, Telnet and SSH. These topics gave technicians enough context to distinguish a local hardware problem from an addressing or reachability problem.

A field technician needed to know whether a link should be copper or optical, whether the laptop and device were in compatible subnets, and whether remote management could work over the available path. The approved IPv4 subnetting material remains useful background because incorrect local addressing can make a healthy replacement device appear unreachable.

Addressing knowledge also supported temporary service connections. A laptop used for local management might need a compatible address and mask before it could reach the device. The technician had to understand the difference between configuring the service laptop and altering the production device. Keeping those actions separate reduces the risk of introducing an unintended network change.

Product and component identification was a core competency

The old blueprint expected recognition of Cisco router and switch families, transceivers, modules, memory, interfaces and cabling. A technician working under remote guidance must be able to locate the correct chassis, slot and serial number without ambiguity. Misidentification can waste a maintenance window or lead to replacement of the wrong component.

Tools and loopback plugs also appeared because physical diagnostics matter in field work. Candidates were expected to understand what a component does and how to verify it, not merely recognize a photograph. The best preparation linked each hardware item to a support scenario such as replacing a power supply, validating an interface or isolating a cabling fault.

Transceiver troubleshooting deserves special attention because link failures can come from mismatched optics, unsupported modules, dirty connectors or the wrong fiber type. A technician should compare the expected interface with the installed component and inspect both ends of the path. Replacing a switch port will not fix a problem caused by an incompatible optic.

Cisco IOS and related operating systems provided the service interface

RSTECH included IOS, IOS XE, IOS XR and NX-OS awareness, command modes, configuration files and basic CLI operations. The exam did not expect the candidate to design a complex configuration, but a technician needed enough command-line skill to inspect status, save or restore configuration and follow a support procedure without damaging the running system.

Knowing which mode you are in is a safety skill. Commands that are harmless in one context may change configuration in another. Technicians should be able to verify before and after a change, capture outputs for escalation and understand where the running and saved configurations reside.

Show commands were evidence-gathering tools. Interface status, version information, inventory data and configuration output helped remote engineers decide what to do next. Candidates should learn to capture relevant output without flooding the incident record with unrelated data. The best evidence is specific to the symptom and easy for another engineer to interpret.

Configuration transfer and software recovery were part of real field work

The blueprint included TFTP, FTP, USB storage and other methods used to move images or configuration data. It also covered software upgrade and downgrade procedures and password recovery. These tasks matter because replacement hardware may not arrive with the correct software or configuration state.

A disciplined workflow begins with the approved image and configuration, verifies checksums or version information where the procedure requires it, protects the existing state and performs the change in the documented order. Afterward, the technician confirms that the device boots correctly and that interfaces and services return as expected.

Software recovery also depended on boot behavior and storage state. A failed upgrade could leave the device at a boot loader or with an image mismatch. The technician needed to follow a controlled recovery procedure and know when to stop rather than improvising. Historical RSTECH study is useful here because it emphasizes operational discipline around IOS image handling.

Layer 1 and Layer 2 troubleshooting was deliberately practical

Common faults included incorrect speed or duplex, bad cabling, failed interfaces and WAN loopback conditions. These problems can produce symptoms that look like routing issues even though the cause is physical or data-link related. RSTECH therefore rewarded technicians who checked the simple evidence first.

Look at link state, interface counters, error conditions and the physical path. Compare both ends of the connection. Confirm the correct media and transceiver. Only after the lower layers are healthy should a technician escalate toward more complex logical causes. That sequence remains valuable in the current FLDTEC role.

Duplex and speed problems show why symptoms can mislead. A link may remain up while users experience poor performance and interface errors. Comparing negotiation state and counters on both ends can reveal the real issue. This is a good study pattern: learn not just what a fault is called, but which observable evidence distinguishes it from other causes.

Service documentation and remote collaboration mattered as much as commands

Field technicians often work with a central operations team or Cisco support engineer. Accurate notes, serial numbers, timestamps, command output and change details let remote staff make better decisions. A technician who silently replaces hardware but cannot describe the before-and-after state creates uncertainty even when the immediate symptom disappears.

Communication should be precise: identify what was observed, what procedure was followed, what changed and what verification passed or failed. This is especially important when multiple devices are involved or when a maintenance window is short. Good documentation turns field work into a repeatable support process.

Remote collaboration works best when the technician narrates state changes precisely. “Port is bad” is less useful than reporting link state, error counters, cable test results and what changed after moving or replacing a component. The technician does not need to own the entire diagnosis, but must produce trustworthy observations for the engineer who does.

RSTECH was retired as Cisco consolidated technician certifications

Cisco retired RSTECH together with 010-151 DCTECH and 100-890 CLTECH. The three specializations were merged into the current FLDTEC path so one technician credential now covers common hardware and service tasks across multiple Cisco technology families.

The consolidation means historical RSTECH expertise is still useful, but it represents only one part of the current scope. Candidates moving to 800-150 must add data-center and collaboration hardware awareness, while retaining the networking foundations, Cisco software handling and disciplined service procedures that RSTECH emphasized.

In the consolidated FLDTEC role, the same support method applies to more platforms. Identify the device, preserve state, replace or restore according to procedure, verify the intended service and document the result. The products differ, but the technician workflow is intentionally transferable. That is the continuity between RSTECH and the current certification.

Another durable lesson is rollback planning. Before a software change or configuration restoration, technicians should know what state they are trying to reach and how to recover if the procedure fails. A maintenance task is safer when the previous image, configuration and physical path are understood. That discipline remains relevant whether the device is a legacy ISR, a Catalyst platform or a system covered by the newer field-technician exam.

Use the legacy blueprint for context, not for a current exam plan

Archived RSTECH objectives remain a good checklist for technicians supporting older routing and switching estates. They can expose weak areas in cabling, hardware recognition, console access, image handling and basic troubleshooting. They should not be treated as the current Cisco exam specification.

For certification preparation, start with the 800-150 FLDTEC blueprint and use RSTECH only as supplemental depth. Map each old topic to the new domains, identify what the new exam adds, and practice cross-platform service scenarios. That approach respects the historical value of 100-490 while keeping the study plan aligned with Cisco's current technician credential.