login delay [secs]
Configures a delay in seconds before the next login attempt after a failed login, used to slow down brute-force attacks on the console or VTY lines.
Definition: login delay [secs] is a Cisco IOS global config command. Configures a delay in seconds before the next login attempt after a failed login, used to slow down brute-force attacks on the console or VTY lines.
Overview
The `login delay` command in global configuration mode introduces a configurable pause (in seconds) before a user can attempt another login after a failed authentication attempt. This is a critical security feature that mitigates brute-force password guessing attacks on console, auxiliary, and VTY lines. By forcing an attacker to wait between attempts, the time required to guess a password increases dramatically, making automated attacks impractical.
The command operates at the line level but is configured globally, affecting all lines that have `login local` or `login` enabled. It is part of a layered defense strategy that includes strong passwords, SSH, and AAA. Unlike `login block-for` (which triggers after a number of failures), `login delay` applies a constant delay after every failure, providing a steady rate limit.
This command is especially useful in environments where you want to slow down attacks without locking out legitimate users. It does not affect successful logins. The delay is applied after the failed login attempt, meaning the user sees the login prompt again only after the delay expires.
The command is available in IOS 12.3(8)T and later. It is stored in the running configuration and can be verified with `show running-config | include login delay`. There is no impact on performance, and the delay is enforced even if the user disconnects and reconnects.
For VTY lines, the delay applies per session; if the attacker opens multiple sessions, each session has its own delay. The command is a simple but effective tool against password guessing, and it is often combined with `login block-for` for a more comprehensive rate-limiting strategy. Understanding this command is essential for CCNA and CCNP candidates as it appears in security configuration topics and troubleshooting scenarios.
login delay [secs]When to Use This Command
- Prevent rapid brute-force password guessing on the console port of a router in a data center.
- Throttle login attempts on VTY lines for remote SSH access to a branch office router.
- Comply with security policies requiring a delay between failed login attempts on network devices.
- Reduce the risk of dictionary attacks on management interfaces of critical infrastructure.
Parameters
| Parameter | Syntax | Description |
|---|---|---|
| secs | <0-10> | Specifies the delay in seconds between login attempts after a failed login. Valid values are from 0 to 10 seconds. A value of 0 disables the delay. Common mistake: setting too high a value may inconvenience legitimate users who mistype their password; a typical value is 1 or 2 seconds. |
Command Examples
Setting a 5-second login delay globally
Router(config)# login delay 5Router(config)#
No output is displayed upon successful configuration. The command sets a 5-second delay between failed login attempts on all lines that use the global login delay.
Verifying login delay configuration
Router# show running-config | include login delaylogin delay 5
The output shows the configured login delay of 5 seconds. If the command is not present, no delay is configured (default is 0).
Understanding the Output
The 'login delay' command does not produce any output when configured. To verify, use 'show running-config | include login delay' which will display the configured delay in seconds. If no delay is set, the line will not appear.
The delay applies after each failed login attempt on console, aux, and VTY lines when using local authentication. A value of 0 means no delay. Typical production values range from 1 to 10 seconds.
Watch for missing configuration on devices that require brute-force protection.
Configuration Scenarios
Basic login delay on console and VTY lines
A network administrator wants to slow down brute-force attacks on the console and remote access lines without implementing complex AAA. They need a simple global setting that applies to all lines.
Topology
R1 (console, VTY lines)Steps
- 1.Step 1: Enter global configuration mode: R1> enable
- 2.Step 2: Configure login delay: R1(config)# login delay 2
- 3.Step 3: (Optional) Verify configuration: R1(config)# do show running-config | include login delay
! Global configuration R1(config)# login delay 2
Verify: Use 'show running-config | include login delay' to confirm the command is present. Output: 'login delay 2'
Watch out: The delay applies only after a failed login; it does not affect successful logins. Also, the delay is per-line; if you have multiple VTY lines, each line enforces its own delay independently.
Combining login delay with login block-for for enhanced security
An organization wants to both slow down and eventually block repeated failed login attempts from a single source. They use login delay to add a constant wait and login block-for to temporarily block the source after a threshold.
Topology
R1 (VTY lines) --- Internet --- AttackerSteps
- 1.Step 1: Enter global configuration mode: R1> enable
- 2.Step 2: Set login delay: R1(config)# login delay 1
- 3.Step 3: Configure login block-for: R1(config)# login block-for 120 attempts 3 within 60
- 4.Step 4: Verify both commands: R1(config)# do show running-config | include login
! Global configuration R1(config)# login delay 1 R1(config)# login block-for 120 attempts 3 within 60
Verify: Use 'show login' to display login parameters. Expected output includes 'Login delay: 1 seconds' and 'Block for 120 seconds after 3 failures within 60 seconds'.
Watch out: The login delay and login block-for are independent; the delay is applied after each failure, and the block is triggered only when the threshold is reached. Ensure the delay value is not too high to avoid frustrating legitimate users who occasionally mistype.
Troubleshooting with This Command
When troubleshooting login issues, the `login delay` command can be verified using `show running-config | include login delay` to confirm it is configured. If users report excessive wait times after a failed login, check the configured delay value; a value of 2-3 seconds is typical. If the delay seems not to be applied, ensure the command is present in the running config and that the line is using `login` or `login local` authentication.
The command does not appear in `show running-config` if it is set to the default (0 seconds). To see the active delay, use `show login` which displays the current login delay setting. If you need to disable the delay temporarily, set it to 0.
Common symptoms: users complaining of slow login after a typo; this is expected behavior. If the delay is too long, reduce it. If attackers are still guessing passwords quickly, the delay may be too short or they may be using multiple sessions.
The `show login` command also shows the number of failed attempts and whether a block is in effect (if `login block-for` is configured). Correlate with `debug login` to see real-time login events, but use caution in production. For VTY lines, the delay is per-session; an attacker opening multiple simultaneous sessions can bypass the delay.
In such cases, combine with `login block-for` to block the source IP. The command is simple and rarely causes issues, but misconfiguration (e.g., setting delay to 10 seconds) can annoy users. Always test the delay with a failed login attempt to ensure it works as expected.
CCNA Exam Tips
CCNA exam may ask: 'Which command slows down brute-force attacks on the console line?' Answer: 'login delay'.
Remember that 'login delay' is a global command; it applies to all lines unless overridden by line-specific 'login delay'.
The default delay is 0 seconds; you must explicitly configure a delay to enable throttling.
This command works with both console and VTY lines; it is not limited to a specific line type.
Common Mistakes
Mistake: Configuring 'login delay' under line configuration mode instead of global config. Consequence: The command is rejected or has no effect.
Mistake: Setting a very high delay (e.g., 60 seconds) causing user frustration. Consequence: Legitimate users may be locked out for too long after a single mistake.
Mistake: Forgetting to apply 'login delay' globally and only configuring it on one line. Consequence: Other lines remain unprotected.
login delay [secs] vs login block-for [secs] attempts [n] within [secs]
Both login delay and login block-for are global configuration commands that mitigate brute-force login attacks, but they operate differently: login delay introduces a mandatory wait after each failed attempt, slowing down attackers, while login block-for temporarily blocks the source IP address after a threshold of failures within a window. They are often considered together because they complement each other, though they affect different attack vectors.
| Aspect | login delay [secs] | login block-for [secs] attempts [n] within [secs] |
|---|---|---|
| Scope | Affects all login attempts (console, VTY, AUX) | Affects VTY (Telnet/SSH) login attempts only |
| Effect | Adds a fixed delay after each failed login | Blocks the source IP after N failures within M seconds |
| Configuration | Specify delay in seconds (e.g., login delay 5) | Specify block period, attempt count, and window (e.g., login block-for 60 attempts 3 within 30) |
| Persistence | Remains configured until removed; delay applies indefinitely | Block is temporary; IP unblocked after block period or manually cleared |
| Precedence / Interoperability | Can be used in conjunction with login block-for; both apply | Login block-for does not override login delay; both active |
| Typical Use | Console or VTY lines where simple slowdown is sufficient | VTY lines exposed to Internet where per-IP blocking is needed |
Use login delay [secs] when you want a simple, uniform slowdown for all login attempts without tracking per-IP failures.
Use login block-for [secs] attempts [n] within [secs] when you need to block attackers by IP address after repeated failures, especially on remote access lines.
Platform Notes
In IOS-XE, the `login delay` command syntax and behavior are identical to classic IOS. It is available in all IOS-XE versions. In NX-OS, the equivalent command is `login delay` in global configuration mode, but the syntax may differ slightly; for example, NX-OS uses `login delay <seconds>` with a range of 0-10 seconds.
However, NX-OS also supports `login block-for` and `login quiet-mode` for more advanced rate limiting. For ASA, the equivalent is `login delay` in global configuration mode, but the ASA uses a different mechanism: `login delay <seconds>` sets the delay between login prompts after a failed attempt. In ASA, the delay is applied per connection, and the range is 0-10 seconds.
In IOS-XR, the `login delay` command is not supported; instead, use `login block-for` or AAA rate-limiting features. Between IOS versions, the command has remained consistent since its introduction in 12.3(8)T. There are no significant differences in output format across versions.
Always verify with `show login` to see the current delay setting. For CCNA/CCNP, focus on the global configuration syntax and the effect on console and VTY lines.
Related Commands
Practice for the CCNA 200-301
Test your knowledge with practice questions covering all CCNA 200-301 exam domains.
Practice CCNA 200-301 Questions