计算机三级网络真题：一张被低估的技术能力诊断图谱

简介本资源是面向计算机等级考试备考者特别是冲刺三级网络技术科目的考生提供的历年真题专项训练资料。文件为单个PDF文档304KB完整收录2002年9月全国计算机等级考试三级网络技术真题及标准答案覆盖选择题60道内容紧扣考试大纲系统考查网络设备辨识、服务器架构、主板类型、网卡功能层级、视频压缩标准JPEG/MPEG等、国产办公软件识别、操作系统四大管理功能进程/存储/文件/设备、中断分类、地址映射机制、文件物理结构顺序/链接/索引、路由算法、网络资源共享范畴等核心知识点。题目设计典型解析明确便于考生自测查漏、强化概念辨析与应试技巧。目前已有800人下载学习适合作为考前模拟、考点复盘与知识体系梳理的权威真题依据。1. 这不是“刷题PDF”而是一份被低估的网络技术能力校准器它能帮你揪出知识断层、暴露概念混淆、验证实操直觉你手头这份《计算机三级网络技术真题.pdf》远不止是“考前抱佛脚”的模拟卷。它本质是一套经过20年全国统一命题锤炼的网络技术能力诊断图谱——从2002年ATX主板与奔腾处理器的硬件认知到2003年EPIC架构与VLAN跨网段通信的协议理解每一道题都在精准刺探你对“网络技术”这个复合概念的掌握深度。它不考死记硬背而是用60道选择题20道填空题构成一张细密的知识探针网第4题问网卡功能逼你厘清OSI七层中物理层与数据链路层的边界第27题问主干网优选技术实则在检验你对千兆以太网与ATM在成本、兼容性、运维复杂度上的工程权衡能力第58题ATM信元长度53字节表面是数字记忆背后是信元头开销5字节与净荷效率48字节的底层设计哲学。它适合三类人刚学完《计算机网络》教材但总感觉“懂了又像没懂”的学生需要把抽象协议映射到真实设备行为正在备考三级却反复错在“看似简单”的操作系统中断机制或地址映射题的考生急需定位知识盲区还有那些在企业做弱电集成、网络巡检或初级运维发现书本理论和现场设备日志对不上号的一线工程师——这份真题就是你的“协议黑匣子解码器”。它不提供答案速查但每道题都像一面镜子照出你对“技术”二字的理解究竟停留在术语复述还是已内化为可推演、可验证、可排错的肌肉记忆。1.1 真题不是历史文物而是技术演进的刻度尺从ATX主板到VLAN它标记了什么这份真题的时间跨度2002–2003常被误读为“过时”。恰恰相反它是一把精准的刻度尺标记着网络技术从硬件依赖走向协议抽象的关键拐点。2002年题干中反复出现的“ATX主板”“奔腾处理器”“SCSI主板”并非单纯考硬件型号而是在测试你是否理解物理层实现如何约束上层协议设计——例如当题目问“主机板按规格分类”第3题正确答案是AT/Baby-AT/ATX这背后是电源管理、扩展槽布局、I/O地址映射等物理规范对网络驱动加载和中断响应时间的直接影响。到了2003年题目重心明显上移第25题考CSMA/CD在“何种负荷下表现更好”第35题问VLAN间能否直接通信第52题考证书发放单位。这些题目不再纠缠于某块网卡芯片型号而是要求你建立协议栈各层间的因果链物理层的冲突域划分CSMA/CD→ 数据链路层的MAC地址学习交换机→ 网络层的IP子网隔离VLAN→ 应用层的安全信任锚点CA认证。这种从“拧螺丝”到“画拓扑”的思维跃迁正是真题筛选能力的核心逻辑。它不考你能否配置一台Cisco路由器但考你能否预判当把一个VLAN的端口从交换机A移到交换机B时哪些协议会自动重收敛哪些服务会因ARP表失效而短暂中断这才是“技术”在真实场景中的重量。1.2 为什么90%的人刷题无效因为把“选择题”当“知识点清单”却忽略了它的诊断价值多数人拿到真题第一反应是打开答案页逐题核对“ABCD”。这本质上是把诊断工具当成了答案手册。真正的价值藏在错误选项的设计逻辑里。以2002年第2题为例“服务器只能用装配有奔腾、安腾处理器的计算机构成”是正确选项D而错误选项A“只能用大型主机、小型机”、C“不能用个人计算机”恰恰是2000年代初常见的认知误区。当你选错A暴露的不是“不知道奔腾能做服务器”而是对服务器定义的僵化理解——你可能仍认为服务器专用机柜UNIX系统而忽略了Windows NT Server在PC硬件上运行的普遍实践。再看2003年第37题“IP提供可靠的数据投递服务”是错误说法但如果你只记住“IP不可靠”就错过了关键细节IP的“不可靠”特指无连接、不保证送达、不保证顺序、不保证不重复但它绝非“随意丢弃报文”选项D的陷阱。这种对“不可靠”边界的精确把握正是区分“背题者”与“解题者”的分水岭。真题的每一个错误选项都是命题组埋下的认知地雷踩中一次就暴露出你知识体系中一条未加固的裂缝。刷题的正确姿势是把每道错题当作一次微型根因分析我为什么觉得A合理这个想法源于哪本教材的哪句话现实中的H3C交换机日志是否支持这个结论——唯有如此真题才从“考试工具”升维为“能力手术刀”。1.3 它解决的不是“会不会考”而是“能不能用”一份让理论落地的实操校验单最常被忽视的价值是真题对技术决策真实性的校验。比如2002年第27题“多个Ethernet工作组网络通过主干网互连主干网优选技术”选项有帧中继、ATM、FDDI、千兆以太网。标准答案是D千兆以太网。但若你仅止步于记住答案就浪费了命题组设置此题的深意。它其实在逼你进行一场微型技术选型沙盘推演帧中继是广域网技术用于跨地域连接不适合局域主干ATM虽有QoS保障但设备昂贵、配置复杂2003年时在中小企业已显鸡肋FDDI带宽100Mbps但采用双环拓扑单点故障切换耗时且与以太网帧格式不兼容需额外转换设备。而千兆以太网继承了原有以太网的CSMA/CD后演进为全双工、相同帧结构、成熟驱动仅需升级网卡和交换机运维零学习成本。这道题的本质是训练你用成本、兼容性、可维护性、性能冗余度四个维度评估技术方案——这正是你在公司写《核心交换机采购建议书》时必须交出的答卷。真题里所有关于“优选”“最适合”“主要原因”的设问都不是考记忆而是考你能否把教科书里的协议特性如TCP的拥塞控制算法翻译成采购清单上的参数如“要求支持RFC 5681标准的CUBIC算法”、故障排查时的日志关键词如“TCP retransmission timeout”、甚至向非技术人员解释的类比“就像快递员发现道路拥堵主动降低发货频率”。它解决的终极问题从来不是“三级考试会不会过”而是“当客户指着防火墙日志问‘为什么HTTPS打不开’时你脑子里闪过的第一个排查路径是否经得起真题逻辑的拷问”。2. 真题解析不是对答案而是重建知识坐标系从OSI七层到设备选型的全栈映射拿到真题第一步不是翻答案而是用它反向测绘自己的知识地图。每一道题都是一个坐标点横轴是OSI七层模型纵轴是技术应用场景硬件部署、协议配置、故障排查、安全审计。当你把2002年和2003年的60道选择题逐一标注在这张图上会惊觉高频考点并非均匀分布而是密集扎堆在几个关键断层带——这正是你知识体系最脆弱的区域。本章将带你完成一次系统性“坐标重建”不求覆盖全部题目但确保每个解析都指向一个可迁移的技术判断力。2.1 从网卡功能题2002年第4题切入撕开OSI七层的“黑匣子”看清物理层与数据链路层的生死边界题目回溯2002年第4题——“网卡实现的主要功能是A) 物理层与网络层 B) 网络层与应用层 C) 物理层与数据链路层 D) 网络层与表示层”这道题看似简单却是检验你是否真正理解“分层”意义的试金石。正确答案C物理层与数据链路层绝非教科书抄录而是由网卡的硬件行为决定的。我们拆解其物理实现# 在Linux系统中执行以下命令观察网卡驱动加载过程 $ dmesg | grep -i eth0\|e1000 [ 2.123456] e1000 0000:00:19.0: Intel(R) PRO/1000 Network Connection [ 2.123789] e1000 0000:00:19.0: eth0: (PCIe:2.5GT/s:Width x1) 00:1b:21:xx:xx:xx [ 2.124012] e1000 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection这段dmesg日志揭示了网卡工作的两个层面物理层Physical LayerPCIe:2.5GT/s:Width x1表示网卡通过PCIe总线以2.5Gbps速率与CPU通信这是纯粹的电信号传输涉及电压、时钟同步、编码方式如8b/10b。网卡的PHY芯片如Intel I210负责将数字信号转换为RJ-45接口上的模拟波形100BASE-TX的MLT-3编码。数据链路层Data Link Layereth0设备名及MAC地址00:1b:21:xx:xx:xx是关键。网卡固件firmware内置了MAC子层逻辑接收时它过滤掉目的MAC不匹配的帧硬件级过滤不交给CPU发送时它自动生成FCS帧校验序列并处理CSMA/CD冲突检测在半双工模式下。这些操作完全在网卡硬件/FPGA中完成无需CPU干预。参数说明与逻辑延伸PCIe Width x1物理层带宽瓶颈决定了网卡与内存间DMA传输的最大吞吐。若你配置了10G网卡却插在x1插槽实际带宽被锁死在2.5Gbps这就是物理层约束对上层性能的硬性限制。MAC地址过滤数据链路层的“智能”体现。当交换机泛洪ARP请求时只有目标MAC匹配的网卡才会触发中断通知CPU否则该帧被网卡硬件静默丢弃。这解释了为何tcpdump -i eth0 arp能看到所有ARP包而tcpdump -i eth0 host 192.168.1.100却只捕获目标IP的包——前者绕过MAC过滤混杂模式后者依赖网卡硬件过滤。致命误区警示很多人认为“网卡驱动属于网络层”这是典型混淆。驱动如e1000.ko本质是CPU与网卡硬件的翻译官它把内核的sk_buff网络层数据包封装成网卡能识别的DMA描述符并触发硬件发送。驱动本身不实现任何OSI层功能它只是桥梁。2.2 从VLAN通信题2003年第35题破局穿透“虚拟局域网”幻象直击三层交换的本质题目回溯2003年第35题——“在由多个VLAN组成的局域网中以下哪种说法不正确A) 站点转移VLAN无需物理连接 B) VLAN中站点可与另一VLAN站点直接通信 C) VLAN内广播其他VLAN收不到 D) VLAN可通过MAC地址、端口、IP定义”正确答案BVLAN间可直接通信是错误说法但它的“错误”恰恰是理解三层交换的钥匙。所谓“直接通信”必须明确通信主体是同一台交换机上的两个VLAN端口还是不同交换机上的VLAN成员真题默认语境是单台设备此时B选项的“直接”意味着不经过路由器或三层交换机的路由引擎。这引出了核心矛盾二层交换机如Cisco Catalyst 2960的ASIC芯片只识别MAC地址而不同VLAN的IP地址必然属于不同子网其ARP请求发出后由于VLAN隔离目标主机根本收不到自然无法回复MAC地址——没有MAC地址交换机ASIC连“发给谁”都不知道何谈“直接通信”我们用真实交换机命令验证这一逻辑# 在一台支持三层的交换机如Cisco 3560上配置两个VLAN Switch(config)# vlan 10 Switch(config-vlan)# name SALES Switch(config)# vlan 20 Switch(config-vlan)# name ENGINEERING Switch(config)# interface fa0/1 Switch(config-if)# switchport mode access Switch(config-if)# switchport access vlan 10 Switch(config)# interface fa0/2 Switch(config-if)# switchport mode access Switch(config-if)# switchport access vlan 20 # 关键步骤关闭SVISwitch Virtual Interface的三层路由功能 Switch(config)# interface vlan 10 Switch(config-if)# no ip address # 注释禁用VLAN10的IP地址 Switch(config)# interface vlan 20 Switch(config-if)# no ip address # 注释禁用VLAN20的IP地址 # 此时即使两台PC分别接fa0/1和fa0/2执行ping结果必为超时 # 因为1) ARP请求被VLAN隔离无法跨VLAN广播2) 无SVI IP交换机不参与路由参数说明与逻辑延伸switchport mode access将端口绑定到单一VLAN这是二层隔离的基础。若改为trunk模式则端口可承载多VLAN流量但需配合802.1Q标签此时“直接通信”依然不成立因为标签帧需由三层设备解封装。no ip addresson SVI这是实验的关键。SVI是交换机上为VLAN创建的虚拟三层接口其IP地址是该VLAN的网关地址。禁用它等于拔掉了VLAN间通信的“路由器”。此时交换机退化为纯二层设备其转发行为严格遵循MAC地址表而MAC表中绝不会出现跨VLAN的条目因为ARP无法完成。工程启示在数据中心网络中常听到“VLAN间路由走核心交换机”或“走防火墙”。选择依据正是此处逻辑——若核心交换机SVI配置了IP并启用ip routing它就承担了三层网关角色若策略要求所有跨VLAN流量经防火墙审计则需将SVI IP设为防火墙的下一跳此时“直接通信”被防火墙策略显式控制而非网络设备自动放行。2.3 从IP数据报传输题2003年第37、38题深挖解构“源/目的IP不变”的神话定位NAT与隧道的真实战场题目回溯2003年第37题——“IP数据报传输中报头中源地址和目的地址是否变化”第38题——“源主机和中途路由器是否知道完整路径”这两题共同指向IP协议最易被误解的核心端到端透明性。标准答案是源/目的IP在传输中“不会变化”第37题A且“源主机和路由器都不知道完整路径”第38题D。但这“不变”是有前提的——它仅在无中间网络地址转换NAT和无隧道封装的纯IP网络中成立。真题的精妙在于它用理想模型划定了技术边界的起点而你的实战能力正体现在能否识别何时这个模型被打破。我们用Wireshark抓包对比两种场景# 场景1纯内网通信符合真题模型 # PC1(192.168.1.10) - PC2(192.168.1.20)同网段 # 抓包显示IP Header中 Source: 192.168.1.10, Destination: 192.168.1.20 —— 全程不变 # 场景2NAT环境模型被打破 # PC1(192.168.1.10) - 外网服务器(203.208.60.1)经家用路由器 # 在PC1侧抓包Source: 192.168.1.10, Destination: 203.208.60.1 # 在路由器WAN口抓包Source: 112.65.34.12 (公网IP), Destination: 203.208.60.1 # —— 源IP已被NAT修改参数说明与逻辑延伸NAT Overload (PAT)家用路由器使用的端口地址转换。它不仅修改源IP还修改源端口如将192.168.1.10:50000映射为112.65.34.12:62000并维护一张NAT转换表。这解释了为何第37题强调“一般情况”——NAT是互联网规模扩张的必要妥协但它确实破坏了IP的端到端透明性。Tunneling (如GRE/IPsec)当数据包进入隧道原始IP报头被封装在新IP报头内。此时外层IP的源/目的地址是隧道端点如总部与分支的公网IP内层IP才是原始通信双方地址。这再次证明真题的“不变”指的是用户可见的业务IP而非网络设备处理的每一层报头。排错黄金法则当遇到“内网能通访问外网超时”时第一反应不应是“DNS坏了”而是检查NAT状态。在Linux路由器上执行$ iptables -t nat -L -n -v # 查看NAT规则计数器若packets为0说明NAT未触发 $ cat /proc/sys/net/ipv4/ip_forward # 值为1才开启IP转发NAT的前提这比盲目重启服务高效十倍。3. 避坑指南那些让老手也栽跟头的“常识性错误”真题早已埋好伏笔刷题最痛的体验不是不会做而是“明明记得知识点却选错了”。这些错误往往源于对概念边界的模糊、对技术演进的脱节、或对工程现实的误判。真题的命题组深谙此道他们在选项中精心设置了大量“高仿真相”专等你用未经验证的“常识”去踩。本章不讲正确答案只聚焦5个血泪教训——它们不是来自我的经验而是从2002–2003年真题的错误选项中逆向工程出的行业集体认知陷阱。3.1 现象坚信“服务器必须用专用硬件”导致在云环境里过度配置资源原因被2002年第2题的错误选项A“服务器只能用大型主机、小型机”长期洗脑未更新对“服务器”定义的认知。2002年Windows 2000 Server在双CPU奔腾III服务器上运行是主流2023年AWS EC2 t3.micro1 vCPU, 1GB RAM可稳定运行NginxPHP-FPMMySQL小站。真题中“服务器可用奔腾、安腾构成”的正确表述本意是打破硬件迷信却被误读为“低端CPU也能当服务器”忽略了其隐含前提软件栈的轻量化与虚拟化技术的成熟。解决在云环境选型时用“工作负载特征”替代“硬件规格”作为决策依据。例如若应用是I/O密集型如数据库优先选i3系列本地NVMe SSD若是计算密集型如视频转码选c5系列高主频CPU若是内存密集型如Redis缓存选r5系列大内存配比。提示AWS官方文档明确指出“t3实例适用于通用型、突发性工作负载其基准性能由CPU积分CPU Credits保障”。这意味着你不必为峰值负载永远支付高配费用这正是真题所倡导的“务实技术观”的现代演绎。3.2 现象配置VLAN后坚信“同一VLAN内所有设备必然互通”却忽略STP阻塞端口原因2003年第35题正确选项C“VLAN内广播其他VLAN收不到”强化了VLAN的隔离性但未提及同一VLAN内部的连通性保障机制。现实中当交换机间存在冗余链路时生成树协议STP会主动阻塞某些端口以防环路导致同一VLAN的设备因端口被Block而无法通信。这与“VLAN广播域”的教科书定义产生尖锐矛盾。解决在VLAN部署后必须验证STP状态# Cisco交换机命令 Switch# show spanning-tree vlan 10 VLAN0010 Spanning tree enabled protocol ieee # 协议类型 Root ID Priority 24576, Address 001b.0c6a.2a00 # 根桥信息 Bridge ID Priority 32768, Address 001b.0c6a.2a01 # 本机桥ID Interface Role Sts Cost Prio.Nbr Type ---------------- ---- --- --------- -------- -------------------------------- Fa0/1 Desg FWD 19 128.1 P2p # Forwarding正常 Fa0/2 Altn BLK 19 128.2 P2p # Blocking此端口不通若发现关键链路处于BLK状态需调整根桥优先级spanning-tree vlan 10 priority 4096或端口成本spanning-tree cost 10而非盲目增加Trunk链路。3.3 现象看到“千兆以太网”就默认带宽1000Mbps却不知全双工模式下端口带宽是2000Mbps原因2002年第28题直接考查“100Mbps全双工端口端口带宽为”选项B是200Mbps。这道题戳破了“带宽单向速率”的常见误解。真题用具体数字强制你建立“双工模式”的物理直觉全双工Full-Duplex意味着发送TX与接收RX通道独立可同时进行因此总带宽 TX速率 RX速率。解决在规划网络时必须区分“链路速率”Link Speed与“有效吞吐”Throughput。例如一台千兆交换机若所有端口均配置为全双工则背板带宽需 ≥ 端口数 × 2Gbps如24口交换机需 ≥ 48Gbps在Linux服务器上用ethtool eth0查看实际协商模式Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full # 支持千兆全双工 Speed: 1000Mb/s Duplex: Full # 关键确认为Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: d Wake-on: d Current message level: 0x00000007 (7) drv probe link Link detected: yes若Duplex显示Half需检查网线是否为Cat5e以上、两端设备协商能力或强制设置ethtool -s eth0 duplex full speed 1000 autoneg off。3.4 现象调试UDP应用时执着于“抓包看UDP头”却忽略应用层丢包的根本原因原因2003年第39题明确指出“UDP不可靠用户应用程序必须承担可靠性全部工作”。但很多开发者将此理解为“UDP没用”或在UDP丢包时只盯着Wireshark里UDP校验和是否正确却忘了UDP的“不可靠”本质是内核Socket缓冲区溢出。当应用读取速度慢于接收速度内核sk_receive_queue满新到达的UDP包被内核静默丢弃Wireshark在网卡驱动层已抓不到。解决监控UDP丢包需分三层驱动层netstat -s | grep -A 5 Udp:查看packet receive errors驱动丢包内核Socket层netstat -su | grep receive errors或ss -u -i查看rcvbuferrors缓冲区满丢包应用层在代码中检查recvfrom()返回值若为-1且errno ENOBUFS即缓冲区满。提示增大UDP接收缓冲区sysctl -w net.core.rmem_max1677721616MB并在应用中调用setsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, bufsize, sizeof(bufsize))。3.5 现象部署SSL/TLS时迷信“证书有效通信安全”却忽略会话密钥生成环节的漏洞原因2003年第19题提到“SSL协议中最终会话密钥由谁产生”答案是客户端Client Key Exchange。但真题未展开的是若客户端使用弱随机数生成器如嵌入式设备的/dev/urandom熵池不足生成的预主密钥Pre-Master Secret可被预测整个SSL握手即被攻破。这解释了为何2014年Heartbleed漏洞爆发时大量持有合法证书的网站仍被窃取私钥——证书只验证身份不保障密钥生成安全。解决在服务器端强制使用强密钥交换# Nginx配置禁用不安全的密钥交换算法 ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305; ssl_prefer_server_ciphers off; # 关键启用TLS 1.2禁用SSLv3/TLS1.0 ssl_protocols TLSv1.2 TLSv1.3;同时在客户端如IoT设备启动时用haveged或rng-tools补充熵池apt-get install haveged systemctl enable haveged。4. 从真题到生产环境用“三层验证法”把选择题答案变成可落地的运维SOP真题的价值绝不仅止于考场上的60分钟。它最大的红利在于为你提供了一套可迁移的验证方法论——当你把一道选择题的正确逻辑拆解为“理论推导→实验室复现→生产环境观测”三层验证你就完成了从应试者到工程师的质变。本章以2002年第22题城域网三层结构和2003年第16题城域网建设描述为锚点演示如何将纸面知识转化为每日巡检的SOP标准作业程序。这不是炫技而是把真题里“核心交换层、业务汇聚层、接入层”的抽象概念钉死在你每天登录的交换机CLI里。4.1 第一层验证理论推导——为什么是“三层”而不是“两层”或“四层”2002年第22题明确指出“城域网建设采用三层模式核心交换层、业务汇聚层与接入层”。这并非拍脑袋决定而是由网络流量模型和故障域隔离原则共同推导出的最优解。我们用数学建模简析假设一个中型城域网覆盖100个接入点如学校、社区每点平均200用户总用户数20,000。流量特征80%流量为用户访问互联网南北向20%为用户间互访东西向。若采用两层架构核心接入所有接入交换机直连核心核心交换机需处理20,000×200 4M条MAC地址表项理论值远超主流核心交换机如华为CE12800的2M表项上限单点接入交换机故障影响200用户但故障域直接冲击核心层风险集中。三层架构的收益接入层仅需学习本区域200用户的MAC地址表项1K汇聚层聚合10个接入点学习2,000条MAC同时执行QoS策略如限速、VLAN终结核心层只学习汇聚层设备的IP路由100条专注高速转发故障域被严格限制在汇聚层之下。参数说明华为S5735-L系列接入交换机MAC地址表容量为16KS6730-H系列汇聚交换机为64KCE12800核心交换机为2M。三层架构使各层设备表项占用率均低于50%为未来扩容留出余量。这印证了真题中“三层模式”的工程必然性——它不是教条而是对硬件资源约束的诚实回应。4.2 第二层验证实验室复现——用GNS3/EVE-NG搭建三层拓扑亲手观测流量路径理论推导需实验佐证。我们用开源网络仿真平台GNS3或商业版EVE-NG构建最小可行三层拓扑[PC1] --(192.168.10.0/24)-- [Access-SW: Cisco 2960] | | Trunk (802.1Q) v [Aggregation-SW: Cisco 3560] --(10.1.0.0/16)-- [Core-SW: Cisco 6500] | v [PC2] --(192.168.20.0/24)-- [Access-SW2]关键配置与观测点在汇聚交换机3560上启用VLAN间路由interface Vlan10 ip address 192.168.10.1 255.255.255.0 interface Vlan20 ip address 192.168.20.1 255.255.255.0 ip routing # 启用三层路由在核心交换机6500上配置OSPF宣告汇聚层网段router ospf 1 network 10.1.0.0 0.0.255.255 area 0 # 汇聚层上联网段验证路径从PC1192.168.10.10ping PC2192.168.20.10在3560上抓包# 在3560的Vlan10接口抓包应看到PC1的ARP请求目的MAC:ff:ff:ff:ff:ff:ff # 在3560的Vlan20接口抓包应看到3560作为网关发出的ARP请求目的MAC:ff:ff:ff:ff:ff:ff # 在3560的上联接口连核心抓包应看到OSPF Hello包和ICMP转发包此时你亲眼看到PC1的流量先抵达汇聚层3560完成VLAN间路由再由3560通过OSPF学习到的路由转发至核心层65本文还有配套的精品资源点击获取