Reading Your Network — @-Mentions and Bash Execution

@-mentions: loading files into context

The @ symbol pulls files from disk into Claude's context window. Claude reads the entire file, understands its structure, and answers questions about it.

Single file analysis

You: @configs/core-nyc-01.cfg Does this router have OSPF
     authentication enabled on all area 0 interfaces?

Claude: [Reads the file]
        OSPF authentication is configured at the area level:

          router ospf 1
            area 0 authentication message-digest

        But interface-level keys are only present on 3 of 5
        area 0 interfaces:

        ✓ GigabitEthernet0/0/0 — key 1, md5
        ✓ GigabitEthernet0/0/1 — key 1, md5
        ✓ Loopback0 — (loopback, auth not needed)
        ✗ GigabitEthernet0/0/2 — NO key configured
        ✗ GigabitEthernet0/0/3 — NO key configured

        Gi0/0/2 and Gi0/0/3 will fail to form adjacencies with
        any neighbor that enforces authentication. If they're
        currently up, the remote side also lacks auth — both
        ends need fixing.

Claude didn't grep for a keyword. It understood the OSPF authentication model — area-level enables enforcement, interface-level provides the actual keys. It identified the functional gap: interfaces without keys in an authenticated area.

Directory sweep

You: @configs/ Which of these configs have SNMP community
     strings set to "public" or "private"?

Claude reads every file in the directory, checks each one, and returns a list with device names and the specific offending lines. For 200 configs, this takes 30-40 seconds. The equivalent grep pipeline would need multi-line context awareness to distinguish snmp-server community public RO from a comment containing the word "public."

URL reference

You: @https://raw.githubusercontent.com/our-org/templates/main/acl-mgmt.cfg
     Compare this ACL template against @configs/fw-lax-01.cfg
     — what's missing from the firewall?

Config drift detection in a single prompt. Claude reads both files, understands the semantic structure of access-lists, and reports what's functionally different — not just line-by-line text diffs, but missing permit/deny entries, reordered rules, and entries present in the running config that aren't in the template.

Bash execution: running network commands

Claude Code can execute any bash command on your local machine. Every command requires your approval by default.

You: Ping 10.0.1.1 from my machine — 5 packets,
     report the loss and latency.

Claude: I'll run this command. May I execute it?

        ping -c 5 10.0.1.1

        [You press Enter to approve]

        Results:
        5 packets transmitted, 5 received, 0% loss
        RTT min/avg/max/stddev = 1.2/1.4/1.8/0.2 ms

        Latency is healthy. Sub-2ms suggests this host
        is on the local LAN segment or within the same
        data center fabric.

Claude interpreted the output — it didn't just echo it back. It drew a conclusion about network topology from the RTL values. That interpretation layer is where the compound value appears.

Chaining commands across devices

You: Interface Gi0/0/1 on core-rtr01 is showing input errors.
     SSH into core-rtr01, check the interface counters and
     transceiver levels. Then SSH into the remote end —
     access-sw15 port Gi1/0/49 — and check output errors there.

Claude: I'll need to run SSH commands. Let me start with core-rtr01.

        [Asks permission: ssh core-rtr01 "show interface Gi0/0/1"]
        [Asks permission: ssh core-rtr01 "show interfaces Gi0/0/1 transceiver detail"]
        [Asks permission: ssh access-sw15 "show interface Gi1/0/49 counters errors"]

        Cross-referenced findings:

        core-rtr01 Gi0/0/1:
        - 14,283 CRC errors since last clear
        - Rx power: -18.2 dBm (threshold: -14 dBm — 4 dB over budget)

        access-sw15 Gi1/0/49:
        - 0 output errors
        - Tx power: -2.1 dBm (nominal)

        Diagnosis: Receive-side optics issue on core-rtr01. The remote
        end is transmitting fine — no output errors, healthy Tx power.
        The Rx power on core-rtr01 is below receiver sensitivity. The
        SFP or fiber on the core-rtr01 end is degraded.

        Action: Replace the SFP in core-rtr01 Gi0/0/1. If errors
        persist after swap, test the fiber with an OTDR.

Three SSH sessions, four commands, cross-device correlation, a root cause, and a remediation plan. The engineer's role shifted from "type commands and read output" to "describe the symptom and validate the conclusion."