链路层down(链路层的数据封装与解封是由( )完成的)

我这是复制的,以前做实验的时候也经常碰到这种情况,一般多重启几次端口就好了,但始终找不到问题的根本所在,希望这篇文章能对你有所帮助. 物理端口UP 协议DOWN 的排错步骤端口的物理层Up，但是协议Down，可能的原因有很多种。一般而言，链路层协议从初始化到Up 起来，都会经过一个协议的“协商”过程。这里所说的协商是广义上的协商，既包括链路层协议本身规定的参数、能力协商，也包括协议所规定的定期性的链路通达性检测（例如HDLC 的Keepalive 报文）。既然称之为“协商”，也就意味着是过程是一对一交互性的，有一个发送出去的报文，也会有一个对方送过来的回应报文。因此，基于这一点，在广域网络调试的时候，如果遇到物理口Up、协议Down 的情况，建议在确认两端路由器的配置没有问题之后，用dis interface 端口号的命令查看一下该端口的收、发报文情况。在Quidway 路由器中，dis interface 命令的显示结果有XXXX packets input 和XXXXpackets output 两项，分别代表该端口上收到和发送的报文数量。正如刚才所阐述的，如果这两个数字相差很大（为了不致让以往累计的历史统计数据对问题的分析、判断造成干扰，建议先在路由器的特权用户模式下使用Clear port 命令将端口的统计信息清空，再用disinterface 命令进行查看），则大致可以说明在协商的过程中出了问题，造成协议不能Up起来。在很多情况下，物理口Up、协议Down，用dis interface 命令查看端口的收发报文情况，发现只有送出去的报文，收到的报文数量为零，而且连续使用dis interface 命令进行查看，进一步发现送出去的报文数量在不断增长，但是收到的报文数量始终为零。这就说明之所以广域网两端路由器之间的链路层协议处于Down 的状态，就是因为要么路由器之间的传输、线缆出了问题，导致本端路由器收不到对端送过来的回应报文；要么是对端路由器本身出了问题，导致无法给本端路由器发送回应报文。除了最常用的收发报文数量比较的方法之外，在dis interface 命令的显示信息中，还有一项很重要的内容，那就是端口所收到的错误报文数量。在Quidway 路由器的disinterface 命令显示结果的倒数第二行，有如下的信息：0 input errors, 0 CRC, 0 frame errors如果由于传输误码、物理线路质量比较差或者是中间的基带Modem 出了问题，则容易导致路由器收到的IP 报文中，很多是错误的报文。特别地，如果通过连续dis interface 发现错误的包在不断增长，则可以判断此时广域网线路质量比较差、传输有误码，或者中间的基带Modem、某段电缆出了问题，导致送给本端路由器的报文绝大部分是错误包，这样链路层协议也肯定是不能Up 起来的。另外，如果通过dis interface 命令发现收、发报文的数量基本相等，而且也没有错误包，但协议还是Down，这个时候可以在路由器上打开该端口的链路层协议Debug 开关，通过Debug 信息完整地分析一下协议的协商过程，看到底问题出在什么地方，出在协商的哪个阶段。不过，这种情况在实际中很少碰到。最后，正如前面提到的，在路由器中，物理口Up、链路协议Down，可能的原因非常多，不同类型的端口、不同的协议，可能的原因都不尽相同。前面所阐述的只是常见的故障情况，具体问题还是需要具体分析。另外很重要的一点是，协议的功能是用于互连、通信，在实际的网络工程和维护中，协议问题的排查同样需要各个相关部门、相关人员的通力配合， 孤立、静止地去分析问题，很难取得比较好的效果
协议DOWN一般有几种情况: 1.IP地址冲突,子网掩码设置错误2.没有设置DCE时钟3.没有设置对FR的,PPP的封装.4.Hello和Dead的更新时钟,两端路由器不同. 5.路由协议设置错误.
经过你的描述，只有下列3个可能：1 IP设置不当，相邻两个端口IP不在同一网段内。 2 如果在帧中继中，端口封装没设置好。 3 模拟器本身的问题。
在确定配置完全正确的情况下,还出现这种问题. 可能是模拟器问题 重新连接或换个模拟器试试看.
R1(config)#interface serial 0/0 R1(config)#clock rate 128000 R1(config)#no shut

1、如果一直是线路问题，端口状态是一直down。2、有active状态也有可能是线路松动。3、出现active再down对于交换机二层设备无法预知，一般有几个检查的地方：全双工，半双工问题，半双工容易出现这个问题。端口安全是不是有安全特殊限制。1、交换机是按照通信两端传输信息的需要，用人工或设备自动完成的方法，把要传输的信息送到符合要求的相应路由上的技术的统称。交换机根据工作位置的不同，可以分为广域网交换机和局域网交换机。2、广域的交换机（switch）就是一种在通信系统中完成信息交换功能的设备，它应用在数据链路层。交换机有多个端口，每个端口都具有桥接功能，可以连接一个局域网或一台高性能服务器或工作站。实际上，交换机有时被称为多端口网桥。

如果一直是线路问题，端口状态是一直down。 有active状态也有可能是线路松动。 出现active再down对于交换机二层设备无法预知，一般有几个检查的地方：1，全双工，半双工问题，半双工容易出现这个问题。 2，端口安全是不是有安全特殊限制，等
如果一直是线路问题，端口状态是一直down。 有active状态也有可能是线路松动。 出现active再down对于交换机二层设备无法预知，一般有几个检查的地方：1，全双工，半双工问题，半双工容易出现这个问题。 2，端口安全是不是有安全特殊限制，等

路由器端口down的意思是接口关闭。接口的关闭有几种，一种是物理层的DOWN，这是因为线路原因，某些控制信号没有起来造成的，这种情况下如果物理信号是否又恢复了正常，端口会UP，并且，只要物理层有载波，肯定会接收到数据，不过都被认为是错误的； 还有就是协议的状态，通常链路层协议会发送KEEP ALIVE，如果没有收到对方的KEEP ALIVE，就会认为物理层已经不工作了圆侍而shutdown，这种情况下，本来物理层就是UP的，所以链路层马上又会UP起来，在链路层UP起来之前，链路层的协商报文也算数据。 路由器是连接两个或多个网络的硬件设备，在网络间起网关的作用，是读取每一个数据包中的地址然后决定如何传送的专用智能性的网络设备。它能够理解不同的协议，例如某个局域网使用的以太网协议，因特网使用的TCP/IP协议。 这样，路由器可以敬腔耐分析各种不同类型网络传来的数据包的目的地址，把非TCP/IP网络的地址转换成TCP/IP地址 ，或者反之；再亮春根据选定的路由算法把各数据包按最佳路线传送到指定位置。所以路由器可以把非TCP/ IP网络连接到因特网上。

默认情况下CISCO的设备刚启动完时所有接口都是人为关闭的。就是你在show ip int brief 的时候会看到一个administrator showdown这样的一个状态。 当进入接口模式后用命令no shut后，就把这个接口打开了，这个时候路由器做什么步骤呢？首先、这个接口的状态由DOWN转变到UP(administrator down转变到up)这只是一个对设置的通告。然后设备开始检测这个接口的物理层有没有问题。如果没有问题这时候接着检测数据链路层，然后是网络层。物理层是怎么检测，就是检测本接口的物理线路，能不能收到对端接口的电流或时钟频率会不会一样，这个都没问题的时候就匹配第二层的数据链路层，如数据链路层的协议啊什么的。比如两端是不是都是hdlc协议，或者ppp协议。如果一、二层都没问题了那个接口的Line protocol就会UP。最后在匹配第三层网络层的一些协议。当这底下的三层没有问题后也就说明在链路上是通的了。至于为什么会UP或DOWN那是因为前期要进行以上步骤的检测是一步步来的。 所以在接口刚开启的时候会UP后又DOWN了。如果对端没有接设备的话，那这个设备肯定是先检测自己的物理接口有没有问题，没问题的时候先UP一下，然后在检测有没有收到对端设备的电源信号和时钟频率，后来发现没有收到，所以又DOWN了，就是这样。

1 当FEC两端配置不匹配的时候就会出现err-disable。假设Switch A把FEC模式配置为on，这时Switch A是不会发送PAgP包和相连的Switch B去协商FEC的，它假设Switch B已经配置好FEC了。但实事上Swtich B并没有配置FEC，当Switch B的这个状态超过1分钟后，Switch A的STP就认为有环路出现，因此也就出现了err-disable。解决办法就是把FEC的模式配置为channel-group 1 mode desirable non-silent这个意思是只有当双方的FEC协商成功后才建立channel，否则接口还处于正常状态。 2 第二个原因就是双工不匹配。一端配置为half-duplex后，他会检测对端是否在传输数据，只有对端停止传输数据，他才会发送类似于ack的包来让链路up，但对端却配置成了full-duplex，他才不管链路是否是空闲的，他只会不停的发送让链路up的请求，这样下去，链路状态就变成err-disable了。3 第三个原因BPDU，也就是和portfast和BPDU guard有关。如果一个接口配置了portfast，那也就是说这个接口应该和一个pc连接，pc是不会发送spanning-tree的BPDU帧的，因此这个口也接收BPDU来生成spanning-tree，管理员也是出于好心在同一接口上配置了BPDU guard来防止未知的BPDU帧以增强安全性，但他恰恰不小心把一个交换机接到这个同时配置了portfast和BPDU guard接口上，于是这个接口接到了BPDU帧，因为配置了BPDU guard，这个接口自然要进入到err-disable状态。解决办法：no spanning-tree portfast bpduguard default，或者直接把portfast关了。4 第四个原因是UDLD。UDLD是cisco的私有2层协议，用于检测链路的单向问题。有的时候物理层是up的，但链路层就是down，这时候就需要UDLD去检测链路是否是真的up的。当AB两端都配置好UDLD后，A给B发送一个包含自己port id的UDLD帧，B收到后会返回一个UDLD帧，并在其中包含了收到的A的port id，当A接收到这个帧并发现自己的port id也在其中后，认为这链路是好的。反之就变成err-disable状态了。假设A配置了UDLD，而B没有配置UDLD：A给B发送一个包含自己port id的帧，B收到后并不知道这个帧是什么，也就不会返回一个包含A的port id的UDLD帧，那么这时候A就认为这条链路是一个单向链路，自然也就变成err-disable状态了。5 第五个原因就是链路的抖动，当链路在10秒内反复up、down五次，那么就进入err-disable状态。6 第六个原因就是keepalive loopback。在12.1EA之前，默认情况下交换机会在所有接口都发送keepalive信息，由于一些不通交换机协商spanning-tree可能会有问题，一个接口又收到了自己发出的keepalive，那么这个接口就会变成err-disable了。解决办法就是把keepalive关了。或者把ios升到12.2SE 7 最后一个原因，相对简单，就是由于配置了port-security violation shutdown。这个太简单，就不解释啦。
当出现这种情况时，网络管理员需要手工恢复接口。一般的做法是，先将端口利用命令shutdown关闭掉，然后再利用命令no shutdown进行启用。 总之，只要交换机支持，就启用UDLD模式，甚至可以启用积极UDLD模式，就可以有效的避免单向链路的误诊情况。特别是采用积极模式的UDLD，那么路由黑洞这个网络难题也可以迎刃而解。