[JunOS]

[EOS]

记录：主机名、平台、软件版本、管理 IP 和邻居数量。邻居数量为步骤 2 设定预期。将此设备作为第一条记录添加到发现跟踪器中，状态为"已发现"。注意：CDP 是 Cisco 专有协议，仅在 Cisco 和 EOS 设备上可用。JunOS 仅支持 LLDP。在多厂商环境中将 LLDP 作为主要协议使用。
步骤 2：L2 邻居发现
从当前设备收集所有 CDP 和 LLDP 邻居。这将揭示直接连接的交换机、路由器、电话和接入点。
[Cisco]

[JunOS]

[EOS]

对于每个发现的邻居，记录：远程主机名、远程平台/型号、远程管理 IP、本地接口、远程接口和通告的能力（Router、Switch、Phone、AP）。能力字段可识别设备角色而无需登录。将每个邻居与发现跟踪器进行交叉引用。新条目的状态为"待处理"——它们成为下一次迭代扩展的种子。已发现的设备将被跳过。
步骤 3：MAC 地址表分析
收集 MAC 地址表以识别所有连接的端点，并区分干道端口（多个 MAC）和接入端口（少数 MAC）。
[Cisco]

[JunOS]

[EOS]

分析端口到 MAC 的映射：
干道端口——学习到多个 MAC，通常连接到其他交换机。这些应该已经作为 CDP/LLDP 邻居出现。
接入端口——学习到一个或少数几个 MAC，通常是终端主机。
没有 MAC 的端口——要么未使用，要么连接到尚未发送流量的设备。检查接口管理/运行状态。
MAC 过多的端口（接入端口上 >100）——可能是集线器、非托管交换机或错误配置的干道。标记任何在意外端口上的 MAC 地址——这有助于识别未文档化的设备或布线错误。
步骤 4：ARP 表关联
收集 ARP 表以将 IP 地址映射到 MAC 地址，建立 L2 发现主机的 L3 身份。
[Cisco]

[JunOS]

[EOS]

对于每个 ARP 条目，记录：IP 地址、MAC 地址、接口、VLAN 和条目年龄。将步骤 3 中的 MAC 进行交叉引用，为先前发现的 L2 端点分配 IP 地址。未解析的 MAC——MAC 表中有但没有对应 ARP 条目的条目——表示仅 L2 设备（该 VLAN 上没有管理 IP 的交换机）或通过干道可到达的不同子网上的设备。未解析的 ARP——MAC 不完整的 ARP 条目——表示可达性问题（设备离线或 ARP 超时）。
步骤 5：路由表分析
收集路由表条目以发现 L3 下一跳、远程子网和路由域边界。
[Cisco]

[JunOS]

[EOS]

识别：
直连子网——直接附加的网络；这些定义了此设备的 L3 边界。
下一跳路由器——相邻 L3 设备的 IP 地址。与 ARP/MAC 数据交叉引用以识别每个下一跳的物理接口和 MAC。
路由协议邻居——OSPF/BGP/EIGRP 邻居即使在 CDP/LLDP 禁用时也能揭示 L3 邻接关系。
默认路由——指向上游网关；跟随它以发现下一层。
VRF 路由——单独的路由表表示 VRF 边界。每个 VRF 重复发现以映射隔离的路由域。
任何没有对应 ARP 条目的下一跳 IP 表示不活动或不可达的 peer——标记以供调查。
步骤 6：拓扑整合
将 L2 和 L3 发现数据合并到统一的拓扑模型中。对于每条发现的链路，在可能的情况下从两端确认。从设备 A 到设备 B 报告的链路也应该出现在设备 B 的邻居表中指向设备 A。不对称条目（仅从一端可见的链路）表示：一端禁用 CDP/LLDP、单向链路或陈旧的邻居条目。
构建邻接模型：
去重链路——同一物理连接出现在两个邻居的表中。使用本地端口/远程端口对进行匹配。
解析 L2/L3 重叠——在 CDP/LLDP 中可见且承载多个 ARP 子网的干道链路表示一条物理链路，具有多条 L3 路径。
分类设备——使用 CDP/LLDP 的能力和路由协议参与情况为每个设备打标签：核心路由器、汇聚交换机、接入交换机、防火墙、无线控制器、端点。
识别边界——发现范围边缘的设备（没有进一步邻居，或邻居在目标域之外）定义拓扑周边。
标记异常——未文档化的设备、不对称链路、意外的路由 peer 和错误 VLAN 上的 MAC 地址。
阈值表
发现完整性和数据新鲜度指标。与健康检查阈值不同，这些指标衡量拓扑数据的完整性和当前程度。
发现完整性：
指标
完整
部分
不完整
CDP/LLDP 邻居与预期相比
100%
80–99%
<80%
有 ARP 解析的 MAC
>90%
70–90%
<70%
有 ARP 条目的下一跳
100%
80–99%
<80%
从两端确认的链路
>95%
80–95%
<80%
收集到路由表的设备
100%
>80%
<80%
数据新鲜度：
数据源
新鲜
老化
陈旧
CDP 剩余保持时间
>120s
60–120s
<60s
LLDP 剩余 TTL
>90s
30–90s
<30s
ARP 条目年龄
<300s (5分钟)
300–1200s
>1200s (20分钟)
MAC 条目年龄
最近活动
>300s 未见
>900s
路由表年龄
已收敛
重新收敛中
不完整
报告模板

Iterative discovery skill that builds a network topology map layer by layer. Unlike threshold-based health checks, this procedure works outward from a seed device — discovering neighbors, correlating MAC and ARP tables, analyzing routing boundaries, and consolidating a complete adjacency model across L2 and L3.

Commands are labeled [Cisco], [JunOS], or [EOS] where syntax diverges. Unlabeled statements apply to all three vendors. Detailed command syntax is in references/cli-reference.md; the full discovery methodology and data model are in references/discovery-workflow.md.

When to Use

• Building or validating a network diagram for an unfamiliar environment
• Post-acquisition network inventory where documentation is missing or stale
• Pre-change impact analysis — mapping blast radius before maintenance
• Incident response — determining the L2/L3 path between two endpoints
• Auditing discovered topology against intended design documents
• Identifying rogue or undocumented devices on the network
• Capacity planning — mapping link utilization paths between sites
• Migration planning — inventorying devices and links in a domain

Prerequisites

• SSH or console access to the seed device (read-only privilege sufficient)
• Credentials that work across devices in the discovery scope — if different

devices use different credentials, identify credential sets in advance

• CDP and/or LLDP enabled on the network (at least one protocol required)
• Knowledge of the intended discovery scope: site boundary, VRF, management

subnet, or administrative domain to avoid unbounded expansion

• A device inventory tracker (spreadsheet, CMDB, or text file) to record

discovered devices and avoid revisiting them

Procedure

Follow this procedure iteratively. Each step builds on prior data. The process expands outward from a seed device, discovering neighbors layer by layer and correlating L2 with L3 information to produce a consolidated topology.

Step 1: Seed Device Identification

Select a starting device and verify connectivity. The seed is typically a core switch, distribution switch, or router with the broadest neighbor visibility.

Confirm access and collect the device identity:

[Cisco]

show version | include hostname|uptime|Software
show cdp neighbors | count
show lldp neighbors | count

[JunOS]

show version | match "Hostname|Model|Junos"
show lldp neighbors | count

[EOS]

show version | include hostname|uptime|model
show lldp neighbors | count

Record: hostname, platform, software version, management IP, and neighbor count. The neighbor count sets expectations for Step 2. Add this device as the first entry in the discovery tracker with status "discovered."

Note: CDP is Cisco-proprietary and available only on Cisco and EOS devices. JunOS supports LLDP only. Use LLDP as the primary protocol for multi-vendor environments.

Step 2: L2 Neighbor Discovery

Collect all CDP and LLDP neighbors from the current device. This reveals directly connected switches, routers, phones, and access points.

[Cisco]

show cdp neighbors detail
show lldp neighbors detail

[JunOS]

show lldp neighbors detail

[EOS]

show lldp neighbors detail
show lldp neighbors | include System

For each discovered neighbor, record: remote hostname, remote platform/model, remote management IP, local interface, remote interface, and advertised capabilities (Router, Switch, Phone, AP). The capabilities field identifies device role without logging in.

Cross-reference each neighbor against the discovery tracker. New entries get status "pending" — they become the next seeds for iterative expansion. Already discovered devices are skipped.

Step 3: MAC Address Table Analysis

Collect the MAC address table to identify all connected endpoints and to distinguish trunk ports (many MACs) from access ports (few MACs).

[Cisco]

show mac address-table
show mac address-table count

[JunOS]

show ethernet-switching table
show ethernet-switching table summary

[EOS]

show mac address-table
show mac address-table count

Analyze port-to-MAC mappings:

• Trunk ports — multiple MACs learned, typically connecting to other

switches. These should already appear as CDP/LLDP neighbors.

• Access ports — one or a few MACs learned, typically end hosts.
• Ports with no MACs — either unused or connected to a device that has

not sent traffic. Check interface admin/oper state.

• Ports with excessive MACs (>100 on access port) — possible hub,

unmanaged switch, or misconfigured trunk.

Flag any MAC addresses on unexpected ports — this helps identify undocumented devices or cabling errors.

Step 4: ARP Table Correlation

Collect the ARP table to map IP addresses to MAC addresses, establishing the L3 identity of L2-discovered hosts.

[Cisco]

show ip arp
show ip arp vrf [name]

[JunOS]

show arp no-resolve
show arp interface [intf]

[EOS]

show ip arp
show ip arp vrf [name]

For each ARP entry, record: IP address, MAC address, interface, VLAN, and entry age. Cross-reference MACs from Step 3 to assign IP addresses to previously discovered L2 endpoints.

Unresolved MACs — entries in the MAC table with no corresponding ARP entry — indicate L2-only devices (switches without management IPs on that VLAN) or devices on a different subnet reachable via a trunk. Unresolved ARPs — ARP entries with incomplete MAC — indicate reachability issues (device offline or ARP timeout).

Step 5: Routing Table Analysis

Collect routing table entries to discover L3 next-hops, remote subnets, and routing domain boundaries.

[Cisco]

show ip route summary
show ip route
show ip route vrf [name]

[JunOS]

show route summary
show route protocol [ospf|bgp|static]
show route table [routing-instance].inet.0

[EOS]

show ip route summary
show ip route
show ip route vrf [name]

Identify:

• Connected subnets — directly attached networks; these define the L3

boundaries of this device.

• Next-hop routers — IP addresses of adjacent L3 devices. Cross-reference

with ARP/MAC data to identify the physical interface and MAC of each next-hop.

• Routing protocol neighbors — OSPF/BGP/EIGRP peers reveal L3 adjacency

even when CDP/LLDP is disabled.

• Default route — points to the upstream gateway; follow it to discover

the next layer.

• VRF routes — separate routing tables indicate VRF boundaries. Repeat

discovery per VRF to map isolated routing domains.

Any next-hop IP without a corresponding ARP entry suggests an inactive or unreachable peer — flag for investigation.

Step 6: Topology Consolidation

Merge L2 and L3 discovery data into a unified topology model.

For each discovered link, confirm it from both ends where possible. A link reported by device A to device B should also appear in device B's neighbor table pointing to device A. Asymmetric entries (link visible from one end only) indicate: CDP/LLDP disabled on one end, unidirectional link, or stale neighbor entry.

Build the adjacency model:

• Deduplicate links — the same physical connection appears in both

neighbors' tables. Use the local-port/remote-port pair to match.

• Resolve L2/L3 overlap — a trunk link visible in CDP/LLDP and also

carrying multiple ARP subnets represents one physical link with multiple L3 paths.

• Classify devices — use capabilities from CDP/LLDP and routing protocol

participation to tag each device: core router, distribution switch, access switch, firewall, wireless controller, endpoint.

• Identify boundaries — devices at the edge of discovery scope (no

further neighbors, or neighbors outside the target domain) define the topology perimeter.

• Flag anomalies — undocumented devices, asymmetric links, unexpected

routing peers, and MAC addresses on wrong VLANs.

Threshold Tables

Discovery completeness and data freshness metrics. Unlike health-check thresholds, these measure how complete and current the topology data is.

Discovery Completeness:

Metric	Complete	Partial	Incomplete
CDP/LLDP neighbors vs expected	100%	80–99%	<80%
MACs with ARP resolution	>90%	70–90%	<70%
Next-hops with ARP entries	100%	80–99%	<80%
Links confirmed from both ends	>95%	80–95%	<80%
Devices with routing table collected	100%	>80%	<80%

Data Freshness:

Data Source	Fresh	Aging	Stale
CDP holdtime remaining	>120s	60–120s	<60s
LLDP TTL remaining	>90s	30–90s	<30s
ARP entry age	<300s (5min)	300–1200s	>1200s (20min)
MAC entry age	Recent activity	>300s since last seen	>900s
Routing table age	Converged	Reconverging	Incomplete

Decision Trees

Missing Expected Neighbor

Expected neighbor not in CDP/LLDP table
├── Is the interface admin up and oper up?
│   ├── No → Fix interface state first
│   └── Yes → Continue
├── Is CDP/LLDP enabled on local interface?
│   ├── [Cisco] show cdp interface [intf]
│   ├── [JunOS] show lldp detail | match [intf]
│   ├── [EOS] show lldp local-info interface [intf]
│   ├── Disabled → Enable CDP/LLDP on the interface
│   └── Enabled → Continue
├── Is CDP/LLDP enabled on remote device?
│   ├── Cannot verify without access → Attempt SSH to remote
│   └── Disabled on remote → Enable or use MAC/ARP as fallback
├── VLAN mismatch?
│   ├── Access port VLAN differs between ends → Fix VLAN assignment
│   └── Trunk allowed VLANs pruned → Add VLAN to trunk
└── Physical layer issue?
    ├── Check interface errors → See interface-health skill
    └── Unidirectional link → Check fiber Tx/Rx, SFP seating

Unresolved MAC Address

MAC in table but no ARP entry
├── Is MAC on a trunk port?
│   ├── Yes → MAC is behind a downstream switch, not local
│   │   └── Discover downstream switch to find the endpoint
│   └── No → MAC is on an access port
├── Is the MAC's VLAN routed on this device?
│   ├── No → ARP is on a different L3 gateway for that VLAN
│   │   └── Check the SVI/IRB owner for ARP entry
│   └── Yes → Continue
├── Check spanning-tree state on the port
│   ├── Blocking/Discarding → Port is STP-blocked; MAC learned before
│   └── Forwarding → Continue
└── Device may not have an IP configured
    └── L2-only device (unmanaged switch, printer in DHCP timeout)

Asymmetric Routing View

Route visible from device A but not device B (or different next-hop)
├── Are both devices in the same VRF?
│   ├── No → Separate routing domains; route leaking required
│   └── Yes → Continue
├── Check routing protocol adjacency between A and B
│   ├── No adjacency → Protocol not configured or filtered
│   └── Adjacency up → Continue
├── Check route filters / distribute-lists
│   ├── [Cisco] show ip protocols | section Routing
│   ├── [JunOS] show policy [name]
│   ├── [EOS] show ip protocols | section Routing
│   └── Filter blocking the prefix → Adjust policy
├── Route redistribution boundary?
│   └── Prefix from one protocol not redistributed into another
└── Summarization hiding the specific route?
    └── Check for area summarization or aggregate routes

Report Template

NETWORK TOPOLOGY DISCOVERY REPORT
===================================
Seed Device: [hostname]
Discovery Scope: [site / VRF / subnet range / domain]
Discovery Time: [start] to [end]
Performed By: [operator/agent]
DISCOVERY SUMMARY:
Total devices discovered: [n]
Routers: [n] | Switches: [n] | Firewalls: [n] | Other: [n]
Total links mapped: [n] (confirmed bilateral: [n], unilateral: [n])
Subnets identified: [n]
VRFs encountered: [list]
DEVICE INVENTORY:
Hostname
Platform
Mgmt IP
Role
Discovery Method
[name]
[model]
[ip]
[role]
[CDP/LLDP/ARP/routing]
LINK MAP:
Device A
Port A
Device B
Port B
Type
Speed
[name]
[intf]
[name]
[intf]
[trunk/access/routed]
[1G/10G/...]
ANOMALIES:
[Severity] [Category] — [Description]
   
Observed: [what was found]
   Expected: [what design documents show]
   Impact: [topology accuracy / security / operational]
   Action: [recommended investigation or remediation]
COMPLETENESS ASSESSMENT:
CDP/LLDP coverage: [%] of expected neighbors
ARP resolution: [%] of MAC entries resolved
Bilateral link confirmation: [%]
RECOMMENDATIONS:
[Prioritized action list]
NEXT DISCOVERY: [Recommended refresh interval based on network change rate]

Troubleshooting

CDP Neighbors Missing on JunOS Devices

CDP is Cisco-proprietary and not supported on JunOS. LLDP must be used for Juniper neighbor discovery. Ensure LLDP is enabled globally and on relevant interfaces: set protocols lldp interface all. On the Cisco/EOS side, enable LLDP alongside CDP so both protocols can exchange neighbor data with JunOS devices.

LLDP Showing Stale Neighbors

LLDP entries persist for the TTL duration (default 120s) after a neighbor disappears. If stale entries appear, check: remote device was recently powered off or rebooted, cable was disconnected, or LLDP was disabled on the remote interface. Wait for TTL expiry or clear LLDP table manually to refresh.

MAC Table Showing Thousands of Entries on Access Port

An access port learning hundreds of MACs suggests: a hub or unmanaged switch behind the port, a virtualization host with many VMs bridged to one interface, or a misconfigured trunk. Check port configuration — if it should be an access port, investigate what is connected. Consider enabling port security to limit MAC learning.

ARP Entries with Incomplete MAC

show ip arp showing "Incomplete" for a MAC address means the device sent an ARP request but received no reply. The target IP is configured on the local subnet but the host is not responding. Causes: host is offline, host firewall is blocking ARP, duplicate IP address conflict, or host is on the wrong VLAN. Verify the host is powered on and connected to the correct VLAN.

Routing Table Shows Unexpected Default Route

A default route pointing to an unknown next-hop may indicate: a rogue DHCP server providing gateway addresses, an unplanned static route, or route redistribution pulling in a default from another domain. Trace the route source — check show ip route 0.0.0.0 for the protocol and source. If OSPF or BGP, identify which peer is advertising the default.