Serial Console to a Nexus 5010

TODO: pull the Eth1/1 module — it's the one reporting invalid
calibration data below. Cheap enough to not be worth debugging further;
physically swap it out next time someone's at the rack.

The plan for the next phase of the fleet's network involves real managed
switching instead of the single unmanaged box currently sitting on the home
LAN. Step one of that plan arrived as a USB-to-serial adapter and a rollover
cable, reportedly plugged into the primary Proxmox host.

It was not plugged into the primary Proxmox host.

Wrong server first

A quick sweep of the primary host — lsusb, dmesg, journalctl -k since
boot, even a direct read of the built-in DB-9 COM port at 9600 8N1 — turned
up nothing. No serial chipset, no signal, silence. It has exactly one
physical serial port and five USB ports, all confirmed empty.

The adapter was on the fleet's second (currently standalone) hypervisor,
instead. lsusb found it immediately: a Prolific PL2303
USB-to-serial converter, cleanly bound to /dev/ttyUSB0. A raw
stty -F /dev/ttyUSB0 9600 cs8 -parenb -cstopb -echo raw followed by a
carriage return got an instant, live reply — the switch was already mid
first-boot, sitting in its setup dialog asking about password policy.

Lesson, filed under the fleet's running "verify enforcement, not presence"
theme: a report that a cable is plugged into host A is a claim about host A,
not evidence about host A. Two live Proxmox hosts exist; check both before
concluding a physical link isn't there.

What showed up on the other end

The switch identifies itself, once logged in, as:

Cisco Nexus Operating System (NX-OS) Software
Copyright (c) 2002-2010, Cisco Systems, Inc.
kickstart: version 4.2(1)N1(1)
system:    version 4.2(1)N1(1)
compile time: 4/29/2010

A Nexus 5010 — fixed-config, twenty 10-Gigabit SFP+ ports, running a
software image compiled in April 2010. Old enough that a few of its
defaults needed working around, which turned out to be the most useful part
of the exercise.

First boot, deliberately incomplete

The Day-0 dialog on NX-OS asks a long string of yes/no questions before it
ever offers a prompt. Answered narrowly on purpose:

• Secure password standard: yes.
• admin account password: set, not written here — see the fleet's
  usual secrets handling.
• A second login account: no — NX-OS's admin already is the
  superuser-equivalent; nothing else was needed yet.
• SNMP strings, NTP server, Fibre Channel, telnet, HTTP server: all
  declined. No community strings worth setting before there's a monitoring
  target to point them at, and telnet/HTTP are just attack surface with SSH
  already in the plan.
• Out-of-band mgmt0 IP and default gateway: declined, deliberately.
  The addressing plan for the new network segment doesn't exist yet — better
  to leave the switch reachable only by console until it does, than guess an
  IP that conflicts with whatever gets decided next.
• SSH server: enabled, with a freshly generated 2048-bit RSA host key
  (RSA offered over the legacy DSA option).

The switch rebooted, applied the config, and came back with a clean
switch# prompt.

A key type from the future

Adding the operator's SSH public key to the admin account for later
passwordless access seemed like the obvious next step —
username admin sshkey <key> is the NX-OS equivalent of dropping a line into
authorized_keys. It rejected the key outright: invalid SSH key format.

The key in question was Ed25519. Ed25519 support landed in OpenSSH in 2014.
This NX-OS image is from 2010. The command's own inline help (username admin sshkey ?) doesn't enumerate accepted key types — it just says LINE
— so the rejection reads identically whether the problem is a malformed
string or an unsupported algorithm entirely, which cost a few minutes
chasing a suspected serial-line corruption bug (a long pasted line did
appear briefly garbled on the wire, a red herring caused by console
auto-wrap at the default 80-column terminal width — fixed with
terminal width 511, and worth remembering for any future long paste over
this same console) before show version settled it. An RSA key is needed
for this device; ed25519-only keys don't have anywhere to go here yet.

What's actually plugged in

show interface transceiver on a NX-OS box is the equivalent of walking
down the row of ports with a flashlight:

Ethernet1/1
    sfp is present but not supported
   SFP calibration is invalid
Ethernet1/2, 1/3, 1/5
    sfp is present
    type is Fabric Extender Transceiver
    part number is PLRXPL-VC-S43-CG
Ethernet1/4, 1/6-1/20
    sfp is not present

Two findings worth writing down before anyone reaches for these later:

• Three of the four populated ports are FET optics — Cisco's
  Fabric-Extender-Transceiver SFP+, a cut-down 10G optic that only
  establishes a link between a Nexus parent switch and a Nexus 2000-series
  Fabric Extender. They will not link up to a server NIC, another switch, or
  anything that isn't a FEX, no matter how good the fiber run is. If the plan
  for this switch doesn't involve a 2000-series FEX downstream, these three
  are the wrong optic for the job.
• One SFP reports a hard failure: present, but flagged unsupported with
  invalid calibration data — the kind of thing a bad or counterfeit module
  produces, not something a config command fixes. Worth physically swapping
  before assuming any port-level troubleshooting will help.

All twenty fixed ports show down in show interface status, which is
expected — nothing is cabled to a live partner yet.

Next: Ansible, once there's an address to talk to

mgmt0 is physically up (link negotiated at 1000 Mb/s) but carries no IP,
by design — bringing this switch under Ansible management is the next
phase, and it depends on the network addressing plan landing first. The
outline:

1. Add the cisco.nxos Ansible Galaxy collection (and its
   ansible.netcommon dependency) to the control node.
2. A new inventory group in inio-infrastructure for network switches, with
   ansible_connection=ansible.netcommon.network_cli and
   ansible_network_os=cisco.nxos.nxos — this NX-OS image predates NX-API,
   so it's classic CLI-over-SSH, not the REST-style API newer Nexus gear
   offers.
3. Credentials in OpenBao, not the playbook — the password set today is a
   known default and gets rotated once real management begins.
4. A role covering the fleet's standing observability baseline (syslog to
   OpenObserve, NTP) plus VLAN/interface config, none of which can be
   written meaningfully until the addressing plan exists.
5. The Cat6 (copper) SFPs that are still in transit will presumably replace
   or supplement the FET optics currently occupying three of the four
   populated ports, depending on what those links are meant to carry.

For now: password set, SSH enabled, transceivers inventoried, one bad optic
identified, and a decade-old assumption about key algorithms re-learned the
hard way. Console access remains the only way in until the network plan
says otherwise.

HOLD Ordered: Waiting for SFP.: