What's changed: Initial version
4.4QoS, SSH, and file transfer
Covers the per-hop behavior of QoS (classification, marking (DSCP), queuing, congestion management, policing that drops excess, and shaping that buffers to smooth), the setup prerequisites of SSH (RSA key, domain name) for encrypted remote management versus Telnet, and choosing among TFTP, FTP, and SCP for transferring IOS images/configs—as practical judgment.
Because bandwidth is finite, treating delay-sensitive traffic like voice/video at the same priority as backup traffic that tolerates delay causes calls to break up. So we prioritize important traffic with QoS. Also, if the path for remote device management is plaintext, credentials can be stolen, so we encrypt it with SSH and choose a transfer protocol suited to the task for moving IOS and config files. This section treats these as practical judgment: which to choose for a requirement, and how to configure it.
4.4.1The per-hop behavior of QoS
- QoS controls how each hop (device) treats a packet (per-hop behavior). First, classification identifies traffic by type (via ACL, NBAR, etc.), and marking stamps a priority onto the packet. At L3 this uses the IP header's DSCP (6 bits; voice is typically EF = DSCP 46), and at L2 the 802.1Q CoS; downstream devices trust this mark and prioritize accordingly.
- Congestion handling includes queuing (controlling send order, e.g., putting voice in the low-latency priority queue LLQ) and congestion avoidance (e.g., WRED, dropping some packets early before the queue fills). Rate enforcement of excess traffic comes in two forms: policing drops (or re-marks) excess and does not buffer—so it adds no delay but causes drops, while shaping buffers excess and sends it later—smoothing traffic but adding delay (latency).
4.4.2Configuring remote management via SSH
- SSH encrypts the remote-management session (TCP 22). Plaintext Telnet (TCP 23) exposes both credentials and actions to eavesdropping, so in practice you allow only SSH. Enabling SSH has prerequisites: (1) set a hostname (other than the default Router); (2) set a domain name with
ip domain-name <name>; (3) generate an RSA key pair withcrypto key generate rsa(1024 bits or more recommended); (4) a local user (username X secret Y) pluslogin localonline vty; and (5)transport input ssh. - In particular, generating the RSA key pair requires a hostname and domain name; without them,
crypto key generate rsacannot run, so SSH never becomes active. It is preferable to pin the more secure SSHv2 withip ssh version 2. Verify withshow ip sshorshow ssh.
4.4.3File transfer (TFTP / FTP / SCP)
- Choose by task for moving IOS images and config files: TFTP (UDP 69) is lightweight and simple with no authentication or encryption, handy for quick config backups and IOS distribution (
copy running-config tftp, etc.). FTP (TCP 20/21) has username/password authentication and is robust for larger files but is plaintext. SCP is encrypted, secure transfer running over SSH; choose SCP when confidentiality is required. - Selection cue: for "just a quick config backup on a closed management LAN," TFTP suffices; for "want authentication / larger files," FTP; for "prevent eavesdropping in transit," SCP. Choose by requirement (need for authentication, confidentiality, simplicity).
Most-tested: policing = drops excess and adds no delay / shaping = buffers to smooth and adds delay; marking uses DSCP (L3) / CoS (L2), trusted downstream; SSH requires a hostname and domain name to generate the RSA key; Telnet is plaintext while SSH is encrypted; and TFTP = simple no-auth / FTP = authenticated plaintext / SCP = encrypted over SSH. Be able to answer questions that pick a method from the requirement (delay tolerance, confidentiality, authentication).
Suppose you are designing QoS for a site whose WAN link is congested. IP-phone voice (extremely sensitive to delay and jitter) and a large nightly backup (which tolerates some delay) share the same link, and call quality was degrading. First, classify the voice traffic (e.g., identify it by voice VLAN or port), apply marking to stamp DSCP EF (46), and unify the per-hop behavior so each downstream hop trusts this mark and places it in the low-latency priority queue (LLQ). Next, you must keep the WAN egress within the contracted rate, and here the crux is choosing between policing and shaping. Policing drops excess immediately, so it adds no buffer delay, but packets fall during bursts, which is ill-suited to voice—which is delay-sensitive but also loss-intolerant (and dropped-then-retransmitted traffic tends to worsen congestion). Shaping, by contrast, buffers and smooths excess, staying within the contracted rate while avoiding drops, so shaping is generally appropriate on the sending side at a WAN egress to shape your own output so it does not trip the ISP's policer (the trade-off being added delay). Choosing the method from this trade-off—can you tolerate drops, or can you tolerate delay—is the heart of QoS design. Then, when migrating this site router's remote management from Telnet to SSH, set hostname and ip domain-name first, generate the RSA key with crypto key generate rsa (note that key generation fails without a hostname/domain name), and set transport input ssh and login local on line vty. Finally, for backing up the migrated config, judge by requirement: quick TFTP if the management LAN is closed, or SCP if you need to prevent eavesdropping.
| Item | Behavior / trait | Effect on delay / confidentiality | Selection cue |
|---|---|---|---|
| Policing | Drops/re-marks excess (no buffering) | No added delay, but drops occur | Ingress rate-limit; where drops are acceptable |
| Shaping | Buffers excess to smooth | Avoids drops but adds delay | WAN egress smoothing; where drops must be avoided |
| Telnet | Plaintext remote management (TCP 23) | Weak to eavesdropping | Discouraged in practice (replace with SSH) |
| SSH | Encrypted remote management (TCP 22, needs RSA key) | High confidentiality | Standard for remote mgmt; key needs hostname/domain |
Trap: "Shaping drops excess traffic, so it adds no delay" is wrong—policing drops, while shaping buffers excess and sends it later, adding delay (latency) in exchange for avoiding drops. Do not swap these two roles. Also wrong: "SSH works immediately once you write transport input ssh"—SSH is not enabled unless you set a hostname and domain name and generate the RSA key (crypto key generate rsa). And wrong: "TFTP is authenticated and secure"—TFTP is a simple transfer with no authentication or encryption; when encryption is needed, use SCP (over SSH).
4.4.4Section summary
- The per-hop behavior of QoS is classify -> mark (DSCP/CoS) -> queue. For excess rate: policing = drop (no added delay) / shaping = buffer to smooth (adds delay)
- SSH (TCP 22, encrypted) replaces plaintext Telnet (TCP 23). A hostname + domain name + RSA key generation are prerequisites for enabling it
- File transfer: TFTP = simple, no auth / FTP = authenticated, plaintext / SCP = encrypted over SSH. Choose by requirement (authentication, confidentiality, simplicity)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. At a WAN egress you want to keep your site's outbound traffic within the contracted rate. Delay-sensitive voice also flows, and you want to avoid packet drops as much as possible. Which should you choose, policing or shaping, and why?
Q2. On a new router you try to enable SSH remote management, configuring `transport input ssh` and `login local` under `line vty 0 4`, but SSH connections fail. Attempting `crypto key generate rsa` also fails to generate a key. What is the most likely cause?
Q3. You want to quickly back up a running router's config file to a server on a closed management LAN. There is no particular requirement for authentication or encryption. Which transfer method is the simplest and most appropriate?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.