Interface Description Standard Checker

During an outage or change window, a port name identifies a connector on one device. It does not say where the cable leads, which service uses it, or who can confirm that the connection is still needed. That missing context is why interface descriptions become operational evidence rather than decoration.

A useful description should let someone act without guessing. An uplink normally identifies a remote device or port, a carrier handoff needs a circuit or service identifier, and an access port benefits from a jack, room, owner, or device purpose. Text such as uplink, user, or TBD may be readable but still fails to distinguish one connection from another.

• Peer links: name the remote endpoint and, when useful, its port or link purpose.
• Carrier handoffs: retain a provider, circuit, order, or service identifier that can be matched to an external record.
• Access ports: identify the room, jack, user, device role, or other location evidence needed at the patch panel.

Consistency matters as much as presence. Reusing the same description on many ports can hide an inventory mistake, while mixed capitalization can defeat a token policy that expects formal identifiers. Administratively disabled ports also need an explicit policy: audit them normally, place them in a review queue, or exclude them only when a separate lifecycle owns their records.

Length rules are local policy, not proof of quality. A minimum can catch terse labels, and an upper limit can prevent platform truncation, but a long description can still be vague. Cisco documents a 240-character limit for the cited platform family; other devices or inventory systems may impose different limits.

A text check cannot confirm the physical cable, live neighbor, circuit order, or current owner. It narrows the work to descriptions whose wording is blank, generic, incomplete, repeated, or outside the chosen policy so those facts can be verified against the network and its records.

How to Use This Tool:

Review one bounded device export or inventory slice so the resulting queue has a clear owner and verification source.

1. Paste configuration blocks, CSV, show interfaces description output, or plain interface-and-description rows into Interface source. Pin Source format only when automatic detection chooses the wrong shape.
2. Choose the Standards profile that matches the ports, then adjust Required terms and the minimum and maximum lengths to match the written local standard.
3. Set the duplicate and shutdown policies. Use case-sensitive terms only when tokens such as circuit prefixes are formally case-dependent.
4. Read the summary and row evidence. A parse error means the source shape must be corrected before any description verdict is meaningful.
5. Work through the Remediation queue, then verify changed descriptions against peer devices, tickets, circuit records, or inventory before applying configuration.

Interpreting Results:

Fail means at least one blocking text rule was triggered. Review means no blocking rule failed, but duplicate wording or shutdown handling still needs judgment. Ignored applies only to shutdown interfaces excluded by policy.

A clear gate proves that every audited row satisfied the selected text rules. It does not prove that the described endpoint or service is real. Confirm consequential links with an independent record or live network check.

Technical Details:

Each parsed interface is evaluated independently, while duplicate detection compares normalized descriptions across the whole input. Automatic format selection recognizes configuration blocks first, then CSV, recognizable show output, and finally plain rows. A pinned format bypasses that detection order.

Rule Core

The verdict follows blocking rules before review-only rules. Ignored shutdown rows leave the audited denominator entirely.

Any fail finding makes the row fail. With no fail findings, one or more review findings make it a review row; otherwise it passes. The overall gate clears only when both fail and review counts are zero.

Formula Core

The passing percentage uses audited rows only, so ignored shutdown interfaces cannot inflate or reduce the rate.

The input is limited to 1 MiB and 500 parsed interfaces. Minimum length accepts whole values from 0 through 240 characters; maximum length accepts 1 through 1024 and cannot be lower than the minimum.

Privacy Notes:

Pasted or locally selected text is reviewed in the current browser and no network request is made for the audit. Configuration exports can still contain device names, circuit identifiers, locations, and owner details, so remove unrelated rows before sharing any copied report.

Worked Examples:

References:

• RFC 2863, The Interfaces Group MIB, RFC Editor, June 2000.
• Configuring Interface Characteristics, Cisco.