服务器发回了不可路由的地址。使用服务器地址代替_值得收藏!!!思科静态路由故障诊断手册...

点击蓝字

36830a569cd32f935a42a4667c03d6a6.gif

关注我们

静态路由故障诊断

也许你听过这样的问题,“他知道什么?他什么时候知道的?”这些问题对于网络调查员也同样适用。当排除路由故障时,首要的一步就是检查路由表。路由器知道什么?这些信息在路由表中存在多久了?路由器知道怎样如何到达讨论中的目标网络?路由表中的信息准确吗?为了顺利地排除网络的故障,了解如何跟踪路由是十分必要的。

案例研究: 追踪故障路由

图3-9所示的网络在前面已经作过相应的配置,其中包括每台路由器相应的静态路由。

现在发现一个问题,在连接到Pooh 以太网接口的子网192.168.1.0/27 上,设备与子网10.1.0.0/16.上的设备可以正常地通信。然而,当从Pooh向子网10.1.0.0/16 发送ping时,结果出现ping失败(参见示例3-36)。这看上去很奇怪。如果Pooh可以成功地路由数据包到达日标网络,那么为什么从Pooh发的数据包却传送失败呢?

为了解决这个问题,需要跟踪ping所经过的路径。首先,检查Pooh的路由表(参见示例3-37)。(根据路由表)目标地址10.1.5.1 可以匹配到路由表项10.0.0.0/8,该子网经下一跳地址是192.68.1.34, 192.168.1.34 是Eeyore的一个接口。

38703012d78c786cb77a2bc0638d1ed5.png 6fb7cb14c5bd79baf8823c634e7e2567.png

然后,需要检查Eeyore的路由表(参见示例3-38)。目标地址10.1.5.1 可以匹配到路由表项10.1.0.0/16,该表项的下一跳地址为10.4.6.1,它是Tgger的一个接口地址。

4814b6be7eb28d977fb883f670c5b906.png

Piglet的路由表(参见示例3-40)显示出目标网络10.1.0.0是一个直连网络。换言之,数据包已经到达目的地了,因为目标地址10.1.5.1就是Piglet自己的接口地址。因为去往目标地址的路径经过验证是正确的,所以我们可以认为来自Pooh的ICMP回应数据包可以到达目标网络。

下一步是跟踪ICMP回应应答数据包所经过的路径。为了跟踪这一路径,读者需要知道回应数据包的源地址一这个地址将是回应应答数据包的目标地址。从路由器发出数据包的源地址就是发送数据包的接口地址。在本例中,最初由Pooh向192.168.1.34 转发回应数据包。在图3-9中,显示出数据包的源地址为192.168.1.33.所以Piglet将要发送的回应应答数据包的目标地址就是192.168.1.33.

参考示例3-34 中Piglet 的路由表,可以发现192.168.1.33 将会匹配到路由表项192.168.1.024并被转发到192.168.1.193,它是Tigger的另一个接口。重新检查示例3-39中Tigger的路由表,首先使我们想起还有一条关于192.168.1.0 的路由。可是,如果根据这些信息准确地解释那里发生的实际情况,那么需要十分小心。

除非用扩展 ping I具将源地址设置为其他地址。

015c8e9d452bd9ec64d99340cd1b9926.png

比较一下Tgger路由表中有关10.0.0.0子网和192.168.1.0子网的路由表项。10.0.0.0 的标题表明其子网大小各不相同:换句话说,指向子网10.4.7.0Tigger 的静态路由使用了24位掩码,指向子网10.1.0.0的静态路由使用了16 位掩码。该路由表为每个子网记录了正确的

掩码。

192.168.1.0的标题则不同,它表明Tigger 知道192.168.1.0 有3个子网,且掩码都为255.255.255.224.用这个掩码可以确定目标地址192.168.1.33 所属的目标网络为192. 168.1 32/27.但是路由表中只有关于192.168.1.64/27. 192.168.1.0/27 和192.168.1.192/27

的路由表项,而没有关于192.168.1.32/27 的路由表项,因此路由器不知道该如何到达这个子网。

这样问题就很清楚了, ICMP的回应应答数据包是在Tgger处被丢弃的。一种解决办法是,另外创建一条指向网络192.168.1.32的静态路由,掩码为5.2.525.224指向下一跳的地址为192.168.1.65 或10.4.6.2.还有一种解决办法是,将关于192. 168.1.0的路由表项的掩码由5525.5255.2244改为255255.255.0.

此案例的精髓就是当你跟踪路由时,你必须考虑完整的通信过程。

注意:不仅要验证去往目标网络的路由是正确的,还要验证返回的路径也是正确的。

案例研究: 协议冲突

如图3-10所示,两台路由器被两个以太网连接起来,其中一个以太网包括一个简 单的网桥。该网桥同时还负责处理其他几条没有画出的链路的流量,所以有时网桥会变得十分拥挤。主机Milne是一台承担重要任务的服务器,网络管理员担心网桥会延误Milne的流量,所以在Roo上添加了-条指向Milne的主机路由,该路由指引数据包使用图上方的以太网以避开该网桥。

这种解决方案看上去是合理的,但是实际并非如此。在添加上面那条静态路由后,数据包经Roo不但不能被路由到服务器,而且经Kanga路由的数据包也不能到达服务器,尽管没有对Kanga作过改动。

第一步首先检查路由表。Roo 的路由表(参见示例3-41)指明目标地址为172.16.20.75的数据包实际。上被转发到Kanga的接口EI上,这正是我们所期望的。由于目标网络直接连接到Kanga上,所以不再需要进一步的路由。经过快速检查确定在Kanga和MiIne上的两个以太网接口都工作正常。

3a631d9692d0c9edca5f9f8f1f34ee9d.png 51b170d820ff7deddd899d131685a566.png

在示例3-42中,从Roo向Milne执行跟踪命令,发现以下症状。Kanga 应该发向MiIne的数据包被发向Roo的接口E0. Roo 又将数据包发给Kanga接口EI,接着Kanga再次将数据包发回给Roo.这看上去像是发生了路由选择环路,但是为什么呢?

此故障的可疑之处在于Kanga不应该对数据包进行路由选择,但事实恰恰相反。

Kanga应该能够识别出数据包的目标地址属于它的直连网络172.16.20.0, 然后使用数据链路向主机传送数据包。因此疑点发生在数据链路上。路由器是否具有经过某条逻辑路径到达目标网络的正确信息,这一点我们可以通过查看路由表来获知。同样的,我们应该检查ARP高速缓冲区,来确定路由器是否具有经过某条物理路径到达某台主机的正确信息。

7a2bebea84c71e6d9bd07b671ee083a8.png

示例3-43给出了Kanga的ARP高速缓冲。在Kanga的高速缓冲中,Mine 的IP地址与MAC标识符00e0. le58.dc39相对应。但是当检查Milne的接口时,发现Milne的MAC标识符为0002.6779.0f4c,因此断定Kanga一定获取了不正确的信息。

10d455bcb02e87e471672c04c20cf12e.png

再次查看Kanga的ARP高速缓冲,令人感到疑感的是与Milne相对应的MAC标识符类似于Kanga自己Cisco接口的MAC标识符(路由器接口的MAC地址没有相应的存活时间)。因为Milne不是Cisco产品,所以MAC标识符的前3个字节应该与Kanga接口的MAC标识符不同。网络上其他的Cisco产品惟有Roo, 因此应该检查一下Roo的ARP高速缓冲(参见示例3-44)。经查Roo接口E0的MAC标识符即为00e0.le58.dc39.

da3933561baaeb38a38836b9c44a53f5.png

所以Kanga错误地认为Roo的接口EO就是Milne的接口。Kanga 使用00e0.le58.dc39作为发向Mine数据帧的目标标识符,Roo 接收到该帧,在读取封装数据包的目标地址之后,又将数据包路由回Kanga。

但Kanga是如何得到这个错误信息的呢?答案是代理ARP。当Kanga首次收到发往Milne的数据包时,它将发送ARP请求,该请求将询问Milne的数据链路标识符。Milne 发回了响应,但是Roo也在接口EO收到了此ARP请求。由于在Roo上也有一条通向Mine的路由,这条路由所在的网络不是Roo收到ARP请求的网络,所以Roo发送了一个代理ARP应答。Kanga收到MiIne的ARP应答后将相关信息输入到ARP高速缓冲内。由于网桥的时延造成了来自Roo代理ARP的应答随后到达Kanga,这时Kanga用新信息覆盖了ARP缓冲内的原始信息。

解决该问题的办法有两种。一种是使用以下命令关闭Roo E0接口上的代理ARP功能:

b818dfbce63dfa109c8197c72e15c9cb.png

第二种办法是在Kanga上为MiIne配置静态ARP表项: 

11c1b967376e1959fda6e9da3f79eec6.png

该表项不会被任何ARP应答所覆盖。示例3-45显示出iE:在输入静态ARP表项以及Kanga上ARP高速缓冲的相应结果。

0ba2c7e3334f1998f061fc41ee753414.png

两种方法哪一种最好取决于网络环境。使用静态ARP表项意味着如果Mine的网络接口被更换,那么需要修改相应的ARP表项来反应新的MAC标识符。另一方面,如果没有主机使用代理ARP功能,关闭此功能也是一种很好的办法。

案例研究: 被取代的路由器

图3-11中有两台路由器Honeypot 和Honeybee通过帧中继链路相连,路由器被配置为IPv4和IPv6,并且使用静态路由建立了静态路由表。

95c37416ffc524bdcfabc9d6f94ba3da.png

示例3-46和示例3-47分别给出了Honeypot和Honeybee的路由配置。

ee58eca151e2ffb4f4b2f94d1e86ca4f.png

如示例3-48所示,在两台路由器之间进行ping和trace测试,结果显示网络工作正常。而且两个站点之间的流量也正常。

33e65086718fd67b5ce0ccd257c45e4c.png

Honeypot可以从自己的以太网地址到达Honeybee的以太网地址,IPv4 和IPv6都可以。

Honeypot还可以通过Honeybee 到达FEC0:0:0:A:1.

可是Honeybee被-台新的路由器替换了,当把Honeybee的配置导入新路由器时,所有的接口都工作正常。两站点之间的测试结果显示IPv4工作正常,但是IPv6发生故障(参见示例3-49)。

f665e9115f6a4cd579309ed6cf8ae771.png 0fe1d3de5d468a71b9058080adf9358d.png

向Honeybee以太网的IPv6地址FEC:8:204:clFF:FES0:F1C0 ping和trace都告失败,但是向FEC:A:0:0:0:ltrace仍然是成功的。

让我们看一下示例3-50中Honeypot的路由表。IPv6 的路由表中有一条路由通过下一跳地址FEC0::3:204:C1FF:FES0:F IC0指向FEC0::/62.

2392d59118c98466d479610e5df23378.png

从示例3-50可以知道,通过FEC:3:204:CIFF:FE50:FIC0可以到达FEC:0:0:/62,并且FEC:0:0::/64被连接到接口Serial0/0.2上;去往FEC:0:8:/64和FEC0:0:A:/64的流量都会从该接口转发给Honeybee。

替代操作前后的路由是完全一样的。那么问题出在哪里呢?或许Honeybee 的以太网接口没有正常工作,这可以查看一下示例3-51中Honeybee的以太网接口状态。

e71cd285679cc1001040eaca4a0f7b7a.png

从示例3-51中可以看到接口状态正常并且配置了IPv6.根据网络的文档和图表,该接口在替换前可以被ping通,但是替换后就不行了。

如果我们仔细查看以太网接口的输出信息,可以发现全球单播地址的后64位发生了变化。现在地址变为FEC::8:2B0:64FF:FE30:IDE0.因为IPv6地址是EU1-64格式,所以后64位由接口的MAC地址确定。当路由器被替换后, MAC地址也随之改变。路由器上不再有FEC0::8:204:CIFF:FE50:FICO存在。这就是ping不通的原因。

但是根据路由表(参见示例3-50),对于目标网络FEC0:0:0:8:/62, Honeypot 的静态路由仍然指向FEC::3:204:CIFF:FE50:F1C0.如果MAC地址发生了变化,那么这个地址就不是同步接口的地址了。示例3-52给出了Honeybee同步接口的新地址。

b3bc0afb73154b1189ff0c8bc6f5c79e.png

如果目标地址在FEC0:0:0:/62的范围内,Honeypot 的IPv6静态路由将把相关流量指向下一跳地址FECO::3:204:CIFF:FE50:F1C0.虽然下一跳地址是原来路由器的MAC地址,然而使用该路由的流量仍然可以被成功路由。

这里虽然指定的下一跳地址不再是合法的,但是它和新的合法地址在相同的子网中(EC0:0:0:-/64),正像我们在Honeypot的路由表中看到的那样,这个子网被连接到Honeypot的接口Serial0/0.2.上。通过对转发表的递归查询,虽然指定的下一跳地址不存在,但是去往FEC0:0:A:I的流量依然从Seria10/0.2送出。

每当路由器或接口卡被替换时,一定要记得修改参考旧路由器EUI-64 格式IPv6地址的路由表项。

案例研究:追踪IPv6故障路由

在图3-3中,在Honeypot和Honeytree之间添加了一条链路,当主链路万一发生中断时,它可以作为备份链路。改动后的新网络如图3-12 所示。由于使用该网络的IPv6应用对时延不敏感,但是对带宽却要求很高,所以网络管理员决定使用新添加的链路作负载均衡,因此在每台路由器上添加静态路由。

152d189b879872de8643210798378d47.png

如示例3-53 所示,对应于Honeypot每个已存在的路由,示例中又添加了第二条路由。

示例3-54和示例3-55也分别对Honeytree和Honeybee进行了类似的操作。

b8815ba8bbe31c0f4691afb63c0f9ef5.png

现在, IPv6的路由选择间歇性的出现故障,有时工作,有时不工作。可以看出路由表中的静态路由与设计的完全相同。从Honeypot向Honeybee 的以太网接口进行ping测试,有时成功,有时出现主机不可达(参见示例3-56)。

5fa669b49e44a2219b5a8ef92cf3c6f4.png 2def5c980b81547ee1608952328bc513.png

在Honeypot.上调试IPv6的ICMP数据包,你可以发现能成功地收到-些响应数据包(参见示例3-57),但是还会收到一些来自Honeytree的目标不可达的ICMP消息。

示例3-57在 Honeypot上的调试结果显示:有时成功,有时失败

5d68603381d7828bf53624e007d33c1b.png

在Honeytree上调试ICMPv6的结果(参见示例3-58)显示,IPv6 的数据包正在从S0/0.3和S0/0.2到达。

2d30993ea500d96c45a8c189bfd75632.png

源地址为fe.:2:230:949:24:2780的数据包从接口S0/0.3 到达Honeytree (来自Honeypot的数据包经过Honeypot至Honeytree的链路到达)。对于目标网络fc.:824:4:fe5/:f12/0来说,出站接口是S0/0.2或S003.这是因为Honeytree执行基于数据包的负载均衡,在S00.2和S0/0.3之间交替转发数据包。当数据包从S00.2出站并且从S00.3入站时,数据包将会被转发。但是如果从S0/0.3出站,而又从S00.3入站,则路由器会产生ICMP错误信息,表明ping失败。

如果数据包从同步接口出站后又从相同的接口入站,那么就表明存在路由环路。由于路由器正在处理交换和基于数据包的负载均衡,每台路由器都会轮流使用两条路由,所以一些数据包会从出站的接口又入站。

36830a569cd32f935a42a4667c03d6a6.gif

10c07d958072abd81c5470efef372983.gif

点击

即可免费获得3天实战课程名额

带你从0到1设计、搭建企业网络

还不赶快动动你的小指头

↓↓↓

4add241883655de117f1841bfebefb94.png

点击  即可免费获得实战课程

已标记关键词 清除标记
表情包
插入表情
评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符
相关推荐
目 录 译者序 前言 第1章 Cisco故障诊断与排除结构化方法 1.1 简介 1.2 故障诊断与排除策略 1.2.1 网络互连的复杂性 1.2.2 问题解决模型 1.2.3 信息和文档列表 1.3 Cisco故障诊断与排除资源 1.3.1 Cisco Connection Online 1.3.2 技术支持中心 1.3.3 其他Cisco资源 第2章 网络测试、管理与分析 2.1 简介 2.2 物理层测试设备 2.3 数字接口测试 2.4 网络管理及其作用 2.4.1 SNTP概览 2.4.2 Cisco路由器和交换机上的SNMP 2.5 网络监视 2.6 网络分析 2.6.1 协议分析 2.6.2 报文分析与Sniffer 2.7 网络管理软件包和平台 2.7.1 CiscoWorks网络管理软件 2.7.2 CiscoWorks for Switched Internetworks复习思考题 第3章 CISCO诊断工具 3.1 简介 3.2 路由器的功能特性和体系结构 3.2.1 路由功能 3.2.2 交换功能 3.2.3 Cisco 7000系列路由器体系结构 3.2.4 Cisco 7500系列路由器体系结构 3.2.5 Cisco 4000/2500系列路由器 体系结构 3.3 Cisco 7000系列路由器交换过程 的报文流 3.4 快速交换与缓存技术 3.4.1 快速交换 3.4.2 自治交换 3.4.3 硅交换 3.4.4 先进的交换技术 3.5 路由处理器的特殊功能 3.6 Cisco 7000系列路由器的队列和缓冲区 3.6.1 缓冲区参数 3.6.2 接口缓存队列 3.6.3 接口缓冲区 3.6.4 show buffers命令 3.7 Cisco 4000/2500系列路由器的 队列与缓存 3.8 故障诊断与排除命令 3.8.1 show命令 3.8.2 debug命令 3.8.3 ping命令 3.8.4 trace命令 3.9 理解Cisco错误消息 3.9.1 错误消息格式 3.9.2 Traceback Report 3.10 错误消息和事件信息的日志 3.11. 核心转储(CORE DUMP) 3.12. 小结 复习思考题 第4章 WAN介质(I)串行线路和X.25 故障诊断与排除 4.1 简介 4.2 HDLC串行链路故障诊断与排除 4.2.1 show interface命令 4.2.2 CSU/DSU返回测试(Loopback test) 4.2.3 show controllers命令 4.2.4 show buffers命令 4.2.5 debug serial interface命令 4.3 调制解调器的连通性 4.4 X.25连通性故障诊断与排除 4.4.1 show命令 4.4.2 debug x25 events命令 4.5 .X.25 动态路由故障的诊断与排除 复习思考题 第5章 WAN介质(II)帧中继故障诊断与 排除 5.1 简介 5.2 基础知识 5.2.1 封装类型 5.2.2 LMI类型 5.2.3 DLCI映射 5.3 帧中继子接口 5.4 点到点与点到多点 5.5 基于帧中继的路由 5.5.1 水平分割 5.5.2 非广播介质引发的问题 5.6 帧中继SHOW命令 5.6.1 show interface命令 5.6.2 show frame-relay命令 5.6.3 show frame-relay命令 5.6.4 show frame-relay map命令 5.7 帧中继调试命令 5.7.1 debug frame-relay lmi命令 5.7.2 debug frame-relay events命令 5.7.3 debug frame-relay packet命令 5.8 拥塞控制和流量整形 5.8.1 允许丢弃列表 5.8.2 广播队列 5.8.3 DLCI优先 5.9 帧中继故障诊断与排除示例 5.9.1 示例1:参数不匹配 5.9.2 示例2:多点与逆向ARP 5.9.3 示例3:基于帧中继的路由 复习思考题 第6章 ISDN连接的故障诊断与排除 6.1 简介 6.2 ISDN配置问题 6.2.1 ISDN交换类型 6.2.2 服务轮廓标识 6.2.3 拨号映射配置语句 6.2.4 拨号列表 6.2.5 PPP与多链路PPP 6.2.6 使用ISDN备份 6.2.7 与ISDN相关的路由问题 6.2.8 ISDN配置实例 6.3 ISDN SHOW命令 6.3.1 Show Interface--D信道 6.3.2 Show Interface--B信道 6.3.3 Show ISDN status命令 6.3.4 Show dialer命令 6.3.5 Show isdn memory命令 6.4 ISDN Debug命令 6.4.1 debug isdn q921命令 6.4.2 debug isdn q931命令 6.4.3 debug isdn events命令 6.4.4 debug dialer命令 6.4.5 debug ppp authentication 命令 6.4.6 debug ppp negotiation命令 6.5 ISDN 故障诊断与排除小结 复习思考题 第7章 IP(Ⅰ):静态路由RIP、IGRP、 EIGRP 7.1 简介 7.2 TCP/IP诊断命令 7.2.1 Ping和Trace命令 7.2.2 Ping命令 7.2.3 Trace命令 7.2.4 Show 命令 7.2.5 Debug命令 7.3 TCP/IP故障解决方案 7.4 局域网连通性问题 7.4.1 设置IP地址 7.4.2 ARP 7.4.3 IP名字解析 7.5 广域网连通性问题 7.5.1 缺省网关 7.5.2 静态和动态路由选择 7.5.3 代理ARP 7.6 IP访问列表 7.6.1 标准访问列表 7.6.2 扩展访问列表 7.7 Internet控制消息协议 7.8 RIP故障诊断与排除 7.8.1 老版本的RIP和新版本的RIP 7.8.2 Show命令 7.8.3 Debug命令 7.8.4 RIP故障诊断与排除示例— 第一部分 7.8.5 RIP故障诊断与排除示例— 第二部分 7.9 IGRP故障诊断与排除 7.9.1 Show命令 7.9.2 Debug命令 7.9.3 IGRP故障诊断与排除示例 7.10 IP EIGRP故障诊断与排除 7.10.1 EIGRP特性 7.10.2 IP EIGRP Show命令 7.10.3 IP EIGRP的调试 7.10.4 EIGRP故障诊断与排除示例 复习思考题 第8章 IP(II):OSPF和BGP故障 诊断与排除 8.1 简介 8.2 OSPF故障诊断与排除 8.2.1 OSPF的特征 8.2.2 OSPF show命令 8.2.3 调试OSPF 8.2.4 OSPF故障诊断与排除示例 8.3 BGP故障诊断与排除 8.3.1 BGP的特性 8.3.2 BGP Show命令 8.3.3 BGP的调试 8.3.4 BGP故障诊断与排除示例 8.4 重新分发 8.4.1 修改路由距离 8.4.2 应用分发列表 8.4.3 路由映射语句的功能 第7、8章 复习思考题 第9章 Novell连通性故障诊断与排除 9.1 简介 9.2 Novell客户-服务器的连接序列 9.3 Novell路由器诊断工具 9.3.1 Ping 9.3.2 Show命令 9.3.3 Debug命令 9.4 IPX封装不匹配 9.5 SAP、路由和访问过滤 9.5.1 SAP过滤 9.5.2 控制GNS响应 9.5.3 路由过滤器 9.5.4 IPX访问过滤器 9.6 客户-服务器远程连接故障诊断 9.7 SAP带宽消耗 9.8 IPX EIGRP 9.8.1 IPX EIGRP诊断工具 9.8.2 EIGRP分发列表 9.9 基于IPX的NetBIOS 9.10 广域网环境中的IPX 9.10.1 基于帧中继IPX 9.10.2 基于ISDN的IPX 9.11 IPX故障诊断与排除示例 复习思考题 第10章 APPLETALK连通性故障 诊断与排除 10.1 简介 10.2 AappleTalk客户-服务器的连接序列 10.3 AappleTalk路由器诊断工具 10.3.1 ping命令 10.3.2 NBP测试命令 10.3.3 show命令 10.3.4 debug命令 10.4 局域网中的AappleTalk故障 诊断与排除 10.4.1 AppleTalk 阶段I和阶段II 10.4.2 AppleTalk过滤和访问控制 10.5 广域网中的AappleTalk故障 诊断与排除 10.5.1 基于帧中继的AppleTalk 10.5.2 基于ISDN的AppleTalk 10.5.3 AppleTalk EIGRP 10.5.4 IP隧道 10.6 AappleTalk故障诊断与排除 示例 复习思考题 第11章 IBM网络互连故障诊断与排除 11.1 简介 11.2 远程信源路由桥接(RSRB) 11.2.1 RSRB的流量控制 11.2.2 RSRB故障诊断与排除工具 11.2.2 LNM命令 11.2.4 SRB调试 11.3 SRB环境中的N 11.4 SRB故障诊断与排除示例 11.5 数据链路交换 11.5.1 关于RIF终止 11.5.2 基于帧中继的DLSW 11.5.3 DLSW和以太网 11.5.4 搜索和流量过滤 11.5.5 DLSW的先进特性 11.5.6 DLSW中的Cisco诊断工具 11.6 DLSW 故障诊断与排除示例 复习思考题 第12章 交换式以太网故障诊断与排除 12.1 简介 12.2 Catalyst 5000/5500交换机上的故障 诊断与排除工具 12.2.1 ping命令 12.2.2 Cisco发现协议 12.2.3 show和clear命令 12.2.4 日志记录 12.2.5 SPAN分析仪端口 12.2.6 Catalyst 5000上的SNMP 12.3 VLAN故障 12.3.1 缺省VLAN 12.3.2 隧道 12.3.3 Inter-VLAN通信 12.4 解决与IP相关的问题 12.4.1 IP交换机的配置 12.4.2 路由和RSM模块 12.5 生成树协议(SPANNING-TREE PROTOCOL)及其相关问题 12.5.1 配置生成树参数 12.5.2 Portfast属性 12.6 高带宽特性 12.6.1 全双工传输 12.6.2 快速以太网信道和G比特 以太网信道 12.7 交换机安全 12.7.1 端口安全性 12.7.2 telnet限制 12.8 以太网故障诊断与排除示例 复习思考题 第13章 实验室练习 1 3.1 简介 13.2 练习1:路由器崩溃后的恢复 13.3 练习2:IGRP/EIGRP路由故障示例 13.4 练习3:RIP/OSPF路由问题 13.5 练习4:BGP路由故障示例 13.6 练习5:DLSW+故障示例 13.7 练习6:IPX RIP/EIGRP故障示例 附录 复习思考题答案
©️2020 CSDN 皮肤主题: 1024 设计师:白松林 返回首页