I85PREP
⌘ K
A10 ACOS study materials
A10 ACOS study resources

Commissioning a New ACOS Appliance Through a Single Console Window

A10 ACOS · Put your knowledge to work in context.

All case studies

Commissioning a New ACOS Appliance Through a Single Console Window

You are commissioning a new ACOS appliance that will front three public web services. The out-of-band management network is 10.20.5.0/24 with gateway 10.20.5.1; the appliance shipped with 172.31.31.31/24 on its management interface and factory credentials. Your jump host is 10.99.0.40, reachable only through 10.20.5.1. No data ports are cabled yet, and the remote-hands technician can attach the console cable exactly once, for a 45-minute window. The change ticket requires the final management address to be 10.20.5.60, with SSH and HTTPS enabled and Telnet disabled. Two weeks later a colleague moves a different appliance in the same subnet to 10.20.5.61; afterwards, ping to 10.20.5.61 succeeds from the jump host, but SSH and HTTPS both time out. Nothing else in the network changed.

1. Give the ordered plan for the 45-minute console window, and identify which step is most likely to strand the appliance if skipped.

Read the worked answer

Principle: the console is the only guaranteed path, so every change happens inside it and nothing is released until the new path is proven.

  1. Console in and change the factory admin password first. Factory credentials on a management interface are an incident waiting to happen, and a password change cannot lock you out.
  2. Capture show running-config off-box. That is the rollback artifact.
  3. Configure 10.20.5.60/24 and a default route 0.0.0.0/0 via 10.20.5.1. The jump host sits at 10.99.0.40, which is off-subnet from the new address and reachable only through that gateway. Without the default route the appliance answers nothing off-subnet and looks dead while it is actually running.
  4. Enable SSH and HTTPS, disable Telnet.
  5. Only now remove the 172.31.31.31 address.
  6. From the jump host, verify ICMP, SSH and HTTPS before the console is released; keep the session open until then.

The step that strands the device is the default route in step 3 (or removing the old address before the new path is proven). Link light and a local ping would not have revealed either mistake.

2. A colleague reports: ping to the new management address works, SSH and HTTPS time out. Explain the symptom and list the checks you would run, in order, with what each would show.

Read the worked answer

What the symptom already tells you: ICMP replies mean the address is configured, the interface is up, and the return path from 10.20.5.61 to the jump host works. So routing, addressing and physical layer are largely eliminated. The failure is selective by protocol, which points at policy or service state, not connectivity.

Checks in order of likelihood:

  1. Management access controls (allowed-remote-access / management ACL). A filter pinned to the previous host or address range, or one that was edited, drops TCP/22 and TCP/443 while allowing ICMP. Confirm with counters or by testing from a host inside the permitted range.
  2. Protocol services disabled. SSH and HTTPS are separately enabled; a reload or an unrelated change can leave them off. Verify service state locally on console rather than from the network.
  3. Which interface holds the address. If 10.20.5.61 landed on a data interface rather than the management interface, different access policies and source-NAT behaviour apply, and the symptom matches exactly.
  4. Session/concurrency limits, which present as timeouts once the table is full.
  5. Duplicate address. Less likely because ICMP works consistently, but a second holder of .61 would produce partial, intermittent failures; check ARP on the gateway.

Work top-down and change one thing at a time, because several of these produce an identical external symptom.