网络设备维护案例(页 1) - 网络 & 安全 - LoveUnix 最强AIX小机技术论坛,UNIX,Linux,存储,数据库,中间件,开发,管理

2004-12-6 14:37 zn8903

每天一例更新,欢迎大家共享自己的经验,今天先多贴几个<img src='style_emoticons/default/laugh.gif' border='0' style='vertical-align:middle' alt='laugh.gif' /> 【转】 【条目标题】华为S3026多个vlan透传到思科3550终结，下挂用户ping 网关时通时断 【产品类别】数据通信 【现象描述】组网：cisco3550-----华为S3026----用户 S3026的多个vlan透传到cisco3550上终结，S3026下挂的用户ping网关时通时断，但同一个VLAN内的用户互ping没问题。 【告警信息】无 【原因分析】1、查看S3026的MAC地址表项，已正常学习到了下挂用户的MAC地址，但只学习到思科设备的一个MAC地址。 2、查看cisco3550的MAC地址表，CISCO3550均学习到了S3026下挂用户的MAC地址。后查看CISCO3550的三层接口时发现多个三层接口均是同一个MAC地址。 3、cisco3550的所有三层接口均是同一个mac地址，那么S3026上学习到cisco3550上的多个三层接口的MAC地址均为同一个MAC，而S3026交换机是SVL的转发方式，所以问题是在S3026上产生地址冲突。导致下挂用户ping网关时通时断。 【处理过程】S3026E是IVL的转发方式，不同vlan有相同的MAC地址不会产生MAC地址冲突。可以换用此类型设备满足该组网需求。

2004-12-6 14:46 zn8903

【条目标题】两端设备MTU值不匹配导致部分网页打不开的问题 【产品类别】数据通信 【条目代码】8007891 【最后修改时间】2004.11.26 【案例标题】两端设备MTU值不匹配导致部分网页打不开的问题 【现象描述】某次工程开局过程中，NE16路由器通过POS口上行，连接至J厂家的设备上。为了提高NE16的转发效率，统一将MTU值改为1500，这样可以避免在NE16上拆分大报文，因此建议局方将J厂家设备的MTU更改为1500，并且从NE16上ping J厂家设备，8100的大包互通也没有问题。但工程完工后，却一直存在NE16下的以太网用户无法访问部分网页的故障，（如sina网）但是同样情况下，有些网页却可以访问（如该省的一个娱乐网站）。并且NE16通过以太网和J厂家设备互连，NE16下的以太网用户就没有不能访问部分网页的故障。而且该问题与用户使用哪一网段的IP地址上网无关。 【告警信息】无 【原因分析】在NE16上打开debugging tcp packet 调试开关，发现从sina网上只能收到少量的小报文，由于使用以太网与J厂家设备互通正常，以太网又便于抓包分析，所以先从以太网抓包入手，对比分析两者报文的差别，经过抓包对比发现能访问的网站返回的都是小报文，无法访问的网站返回的报文多是1500字节或接近1500字节的大报文，并且这些大报文的DF位为1，即不可分片。由于从POS口没有收到这些大报文，那么问题可能出在J厂家设备上，叫局方联系J厂家工程师查看其设备的配置，发现了问题的原因，原来J厂家设备有两个MTU值设置位置，一个是针对链路层的，默认为4474，一个是网络层（IP）的，默认为4470。局方工程师只修改了链路层的MTU值，没有修改网络层的MTU值，导致网络层接近于1500字节的报文在加上链路层报文头后的长度大于1500 而又不允许分片，该报文只好被丢弃。造成了部分网站无法访问。 【处理过程】修改J厂家设备的网络层的MTU值为1500、链路层的MTU值恢复为默认值后问题解决

2004-12-6 16:04 rhinofly

<img src='style_emoticons/default/fire.gif' border='0' style='vertical-align:middle' alt='fire.gif' /> 我只能顶~~

2004-12-7 09:35 zn8903

【条目标题】工程师反映删除S3026的flash中的文件后，flash的剩余空间还是没有变大。 【现象描述】工程师反映删除S3026的flash中的文件后，flash的剩余空间还是没有变大。 【告警信息】无 【原因分析】delete命令用来删除以太网交换机的存储设备中的指定文件。该命令支持“*”通配符。被删除的文件存放在回收站目录中，使用dir /all命令显示所有文件目录信息时，发现被删除的文件仍然在flash里面。 【处理过程】没有完全删除文件，用delete/unreserved：彻底删除该文件。再用dir /all 查看，没有被删除 文件。flash的剩余空间正常。 【建议与总结】【附件名称】

2004-12-7 12:10 阿土

<img src='style_emoticons/default/rose.gif' border='0' style='vertical-align:middle' alt='rose.gif' /> 天天来看。

2004-12-8 12:26 zn8903

------------------------------------------------------------------------------ 【条目标题】由于禁止了netbios协议，导致S3526E同一个VLAN内的PC机无法找到网上邻居 【现象描述】S3526E同一个VLAN内的PC机无法找到网上邻居。 【告警信息】无 【原因分析】网上邻居互相访问，使用了tcp、udp的137、138、139端口。S3526上设置的访问控制列表恰恰禁掉了netbios协议（端口号是tcp、udp的137、138、139），所以网上邻居不能互访。 netbios-ns 137/tcp NETBIOS Name Service netbios-ns 137/udp NETBIOS Name Service netbios-dgm 138/tcp NETBIOS Datagram Service netbios-dgm 138/udp NETBIOS Datagram Service netbios-ssn 139/tcp NETBIOS Session Service netbios-ssn 139/udp NETBIOS Session Service 【处理过程】导致网上邻居无法访问的配置如下： acl number 100 rule 0 deny tcp destination-port eq 135 rule 1 deny udp destination-port eq 135 rule 2 deny tcp destination-port eq 139 rule 3 deny udp destination-port eq netbios-ssn rule 4 deny tcp destination-port eq 445 rule 5 deny udp destination-port eq 445 rule 6 deny tcp destination-port eq 593 rule 7 deny udp destination-port eq 593 rule 8 deny tcp destination-port eq 4444 rule 9 deny udp destination-port eq tftp rule 10 deny udp destination-port eq 1434 rule 11 deny tcp destination-port eq 137 rule 12 deny tcp destination-port eq 138 rule 13 deny udp destination-port eq netbios-ns rule 14 deny udp destination-port eq netbios-dgm rule 15 deny icmp 修改成如下配置后，S3526E同一个VLAN内的PC机就能发现网上邻居了。 acl number 100 rule 0 deny tcp destination-port eq 135 rule 1 deny udp destination-port eq 135 rule 2 deny tcp destination-port eq 445 rule 3 deny udp destination-port eq 445 rule 4 deny tcp destination-port eq 593 rule 5 deny udp destination-port eq 593 rule 6 deny tcp destination-port eq 4444 rule 7 deny udp destination-port eq 1434 rule 8 deny udp destination-port eq tftp rule 9 deny icmp

2004-12-9 09:57 zn8903

【条目标题】交换机端口聚合汇总 【分析】端口汇聚是将多个端口聚合在一起形成1个汇聚组，以实现出/入负荷在各成员端口中的分担，同时也提供了更高的连接可靠性。 在一个端口汇聚组中，端口号最小的作为主端口，其他的作为成员端口。同一个汇聚组中成员端口的链路类型与主端口的链路类型保持一致，即如果主端口为Trunk端口，则成员端口也为Trunk端口；如主端口的链路类型改为Access端口，则成员端口的链路类型也变为Access端口。 【】一台S3026以太网交换机只能有1个汇聚组，1个汇聚组最多可以有4个端口。另外，两个扩展模块可以汇聚成1个汇聚组。组内的端口号必须连续，但对起始端口无特殊要求。 一台S3026E/S3050C-48以太网交换机最多可以有6个汇聚组，1个汇聚组最多可以有8个端口。另外，两个扩展模块可以汇聚成1个汇聚组。组内的端口号必须连续，但对起始端口无特殊要求。 一台S3026 FM/S3026 FS以太网交换机最多可以有4个汇聚组，1个汇聚组最多可以有8个端口。端口起始值只能为Ethernet0/1、Ethernet0/9、Ethernet1/5、Gigabitethernet3/1，如果组内的端口跨越了两个槽，则槽号必须连续。 一台S3026E FM/S3026E FS以太网交换机最多可以有6个汇聚组，1个汇聚组最多可以有8个端口。如果组内的端口跨越了两个槽，则槽号必须连续 一台S3526以太网交换机最多可以有4个汇聚组，1个汇聚组最多可以有8个固定端口或2个扩展模块端口。端口起始值只能为Ethernet0/1、Ethernet0/9、Ethernet0/17、Gigabitethernet1/1，且组内的端口号必须连续。 一台S3526E/S3526C以太网交换机最多可以有6个汇聚组，1个汇聚组最多可以有8个固定端口或2个扩展模块端口。组内的端口号必须连续，但对起始端口无特殊要求。 一台S3526 FM/S3526 FS以太网交换机最多可以有4个汇聚组，1个汇聚组最多可以有8个端口。端口起始值只能为Ethernet0/1、Ethernet0/9、Ethernet1/5、Gigabitethernet3/1，如果组内的端口是同一槽内的端口，则端口号必须连续；如果组内的端口跨越了两个槽，则同一槽内的端口号必须连续，槽号必须连续，且只能从第二个槽第1个端口开始加入汇聚组。 一台S3526E FM/S3526E FS以太网交换机最多可以有6个汇聚组，1个汇聚组最多可以有8个端口。如果组内的端口是同一槽内的端口，则端口号必须连续；如果组内的端口跨越了两个槽，则同一槽内的端口号必须连续，槽号必须连续，且只能从第二个槽第1个端口开始加入汇聚组。 一台S3552G/S3552P/S3528G/S3528P/S3552F-SI以太网交换机最多可以有6个百兆端口汇聚组及1个千兆端口汇聚组，1个汇聚组最多可以有8个百兆端口或4个千兆端口。组内的端口号必须连续，但对起始端口无特殊要求。

2004-12-10 09:28 zn8903

【条目标题】3026ef trunk端口环回受控功能未关闭影响所有用户上网问题 【现象描述】组网为S8016+++(trunk)+++3026EF+++2016 用户反馈S8016 1/0/0端口下带所有业务出现过中断； 【告警信息】%Jun 20 06:53:52 2004 s3026f DRV_NI/5/LOOP BACK: Loopback does exist on port 10 vlan 100, please check it %Jun 20 06:54:22 2004 s3026f DRV_NI/5/LOOP BACK: Loopback does exist on port 10 vlan 100, please check it 【原因分析】登录3026EF，可以查看到有上述告警提示； 3026EF有环回检测功能，定时发送检测数据包，如果收到自己发送过来的数据包，则认为存在环路，同时删除对应端口的MAC地址并关闭MAC地址学习功能； 如果是ACCESS端口，这种处理方式可以方便查到对应哪个端口形成环路； 如果是TRUNK 端口，因为透传的VLAN 比较多，任意一个VLAN内形成环路，均会导致将TRUNK端口 锁定；从告警上看VLAN 100存在环路，而上行TRUNK端口透传该VLAN，因此导致端口锁定，导致所有用户无法上网； 【处理过程】对于3026EF，上行口如果是TRUNK端口，可以采用下面的命令关闭控制功能； undo loopback-detection control enable 执行该命令后，如果对应VLAN内有环路存在，会有告警提示，但不会将端口关闭； 如果仅仅执行undo loopback-detection enable会将端口检测功能关闭，无法提示告警； 对TRUNK端口执行该命令，既不会因为有环路导致无法上网，也不会因为环路存在而不知晓；

2004-12-11 09:31 zn8903

【条目标题】路由器接口MTU、TCP MSS设置引起某些应用异常 【现象描述】组网： PC－AR2831－AR2880－CISCO设备组成的核心网－SERVER 网络运行MPLS VPN;AR2880为PE;AR2831为CE，PE、CE间运行OSPF,多CE配置；路由器各接口MTU、TCP MSS值采用默认设置 AR2880：Version 3.30, Release 0008 AR2831：Version 3.30, Release 0008 现象1： AR2880路由器的以太口MTU使用缺省设置时,使用的OA系统(BS架构)部分流程无法运行,上网发邮件时附件无法粘贴；但是在cisco设备上，同样的组网没有发现问题； 现象2： 将AR2880路由器的以太口MTU改为512测试,邮件附件可以粘贴,但OA主页打开后无内容,刷新不了；将AR2880路由器的以太口MTU改为1200测试,邮件附件可以粘贴,OA主页可以正常显示,但是点击OA系统的"起草公文"无页面弹出,正常状况下应弹出新建公文页面； 【告警信息】无 【原因分析】原因分析： 可能是应用软件问题；可能是MTU 、TCP MSS值协商配置问题； 具体分析： 1、接口MTU、TCP MSS采用缺省值1500时，无法贴附件； 这是因为应用了三层MPLS VPN技术，增加了8bit的标签，MTU值协商出现问题。 AR28XX路由器默认在接口上自动分片，所以在普通的应用中采用默认值不会影响业务。但路由器接口上收到一个报文长度大于本接口MTU值的报文，如果该报文被强制打上不分片的标记，将丢弃报文，并返回一个ICMP差错报文（type 3,code 4），通知报文发起者丢弃原因。报文发起者将发送比较小的报文。通过多次上述报文协商，将得到对于某一个固定路径上的最小Mtu值，这个过程叫做Mtu Discovery ，通过MTU Discovery来确定报文路径上最小可通过的MTU；如果两个设备相连，没有MTU Discovery功能并且MTU值不一致，将可能导致丢弃报文。只有把双方设备的Mtu为对端设备MRU的最小值，才能正常通信。由于某些组网考虑到网络安全问题和性能，往往会把ICMP报文过滤掉，引起Mtu Discovery不能正常运行；应用软件由于程序算法问题或根本没有相应协商功能，也会导致了部分应用异常。 2、更改接口MTU值以后，仍然有部分业务不正常； 这是因为TCP MSS值协商的问题。 一般的应用软件，当客户端和服务器端在建立TCP连接的时候需要根据实际传输的报文大小来协商TCP的窗口大小MSS。Tcp连接成功后会进行两次滑动窗口的协商,一次是pc与server，一次是与网关，然后在两次协商里选择一个较小的值作为窗口来发送报文。MSS值的计算方法是：MSS=MTU-IP-TCP（如果有其他pppoe、加密报文头的话也同样减去），也就是说MSS值其实就是TCP所承载的净载荷的长度。由于AR28XX接口缺省的MTU是1500字节，故一般要求加密报文头+链路层开销+IP头（20-60字节）+TCP报文（20字节）小于1500字节，即TCP分片配置1200左右比较适合。缺省情况下，TCP报文不分片。因此TCP MSS不匹配也会引起部分应用异常。 【处理过程】本例中通过修改路由器接口MTU、TCP MSS值，解决问题。 具体报文mtu 、tcp mss大小要根据具体应用，按经验值进行尝试，选择最佳值；其中MTU值的选择可以通过ping命令设置不分片来进行测试；TCP MSS值的选择则可以通过MTU减去相应其它加密、链路层开销、IP头、TCP头等字节计算。 具体过程如下： 1、本例中使用cisco路由器时相关应用正常。初步估计是mtu值问题，但是对普通应用AR28系列路由器会自动分片，不会影响业务。测试发现在client上ping大包的时候，如果不设置不允许分片，业务正常。看来客户应用中做了不允许分片的设置或其它原因mtu协商错误。更改路由器接口mtu为1500-8＝1492以后，业务正常。 2、更改接口mtu以后，其它部分业务还不正常。分析原因是tcp mss值的问题。减小tcp mss值8字节1460-8＝1452，但是还有部分业务不正常。询问软件集成商，得到答复部分软件中使用了加密技术。而且不同的应用加密强度不同。 3、逐步调整路由器接口的tcp mss值，减到到1200以后，所有业务测试通过。 命令说明： 1、mtu命令用来设置以太网接口的MTU（最大传输单元），undo mtu命令用来恢复MTU的缺省值。缺省的MTU为1500。使用mtu命令改变接口最大传输单元MTU后，需要先对接口执行shutdown命令，再执行undo shutdown命令将接口重启，以保证设置的MTU生效。 2、tcp mss命令用来配置TCP报文分片，undo tcp mss命令用来取消TCP报文分片。 由于我们接口缺省的MTU是1500字节，故一般要求加密报文头+链路层开销+IP头+TCP报文小于1500字节，即TCP分片配置1200左右比较适合。缺省情况下，TCP报文不分片。

2004-12-15 09:50 zn8903

【条目标题】OSPF选路原则的一个特点 【现象描述】某运营商客户反映S8016 OSPF协议在选择路由时，路由preference相同的情况下没有选择cost值小的路由，而是选择了cost值大的路由。组网见附件，S8016B OSPF引入一条外部路由（210.192.180.X /24），S8016A通过area 0与area 10学到两条优先级相同的路由，通过area0学到的路由cost值小于area10学到的。 实际情况发现，S8016A关于外部路由（210.192.180.X /24）的业务流量选路area10通过NE16转发至S8016B，而不是用户期望的通过area0两条S8016间的高速带宽链路。 【告警信息】无 【原因分析】对于相同掩码长度的路由，通常OSPF选路遵循以下先后原则： 1、路由优先级高优先 2、area内学习到的优于跨area学到的 3、cost值小优先 对于上面的情况，为什么会选择cost值大的路由呢？ 经查证： 按照RFC2328 Section 16.4.1，对于某一目标网络有经过骨干区域的和经过非骨干区域的区域内路由，OSPF优选非骨干区域的路由，目的在于减轻骨干区域的负载。 【处理过程】说明： 1、对于上述组网，如果要实现流量不从NE16转发，可以在S8016间添加一条OSPF链路，定义为非骨干域即可； 2、华为设备OSPF遵循RFC2328，RFC2328是RFC1583的改进，遵循RFC1583则不存在上述情况，会优选cost小的路由。

2004-12-16 02:03 zn8903

【条目标题】利用黑洞路由解决路由环路导致的NE08 VIU CPU占用率高的问题 【现象描述】组网 用户－－S6506－－NE08－－公网 NE08 6槽位单板cpu占用率很高 <NE08_A>disp sys cpu all CPU Usage in slot 6: 91% in last 5 seconds 87% in last 1 minute 85% in last 5 minutes 【告警信息】无 【原因分析】NE08配置了指向S6506下挂用户网段的静态路由，S6506配置缺省路由指向NE08。当外网访问S6506下挂未上线的用户地址时，会导致报文再S6506与NE08间来回转发，形成路由环路，直至TTL exceeded。 【处理过程】1、检查NE08单板为RTC4VIU，单板流量120M左右，在单板处理能力内； 2、发现NE08接S6506的端口入流量接近70M，但接公网出口仅20M左右； 3、通过查询disp ip statistics sl 6 Received packets: discarded for TTL exceeded: 89575321 增涨非常迅速，怀疑是路由环路； 4、在S6506上添加静态路由： ip route-static 10.80.0.0 255.240.0.0 NULL 0 preference 60 blackhole后，NE08 6槽位CPU占用率明显下降，与S6506互连接口流量明显下降。

2004-12-16 02:10 zn8903

【条目标题】采用OSPF路由协议的路由器配置访问列表过滤掉DD报文引起的故障 【现象描述】NE80路由器与某厂商的交换机通过千兆以太网光纤互连，双方运行OSPF协议。相互之间可以Ping通，但是学不到对方的路由。在NE80这边执行display ospf peer命令，发现OSPF邻居的状态在Exchange和Exchange Start之间振荡。 【告警信息】无 【原因分析】通过OSPF的邻居状态可以看出，问题出在双方之间OSPF的DD报文交换过程上。在NE80这边打开OSPF Packet和OSPF Event调试开关，发现双方之间的HELLO报文交互正常，建立起了Two-Way关系。在随后的DD报文交换中，比较双方的Router ID，NE80认为自己是主路由器，向对方发送了OSPF DD报文，但是对方交换机好象对此“视而不见”，一直往NE80发送初始化的主从协商DD报文。导致NE80这边OSPF的邻居状态在Exchange和Exchange Start之间振荡。 只可能有两种原因： 1、NE80没有真正将DD报文发送出去； 2、NE80将DD报文发送出去了，但是对方的交换机没有正确接收，导致它的OSPF模块认为没有收到。 3、检查NE80的配置及各方面的统计信息，都正常； 4、查看对方交换机的配置，发现在与NE80互连的GE端口上启用了访问列表； 5、分析访问列表的各条规则，发现所配置的访问列表刚好把目的地址为GE接口自身地址的IP报文（但是允许ICMP报文通过）给禁止掉了。导致NE80送过来的DD报文在交换机这边全部被过滤掉，但是OSPF HELLO报文由于是以组播形式发送，没有受到影响

2004-12-17 17:43 zn8903

【条目标题】S6506的ospf邻居down 【现象描述】PC---S6506----S8016---- | 5200(BAS) 用户发现ospf邻居断了两次。 218.76.67.182 s6506 s6506xxdx 【告警信息】无 【原因分析】telnet上用户设备，发现端口有大量的pause流控帧，导致端口处理溢出，ospf的hello报文传不出去。导致ospf邻居断掉。 【处理过程】将8016与65之间互连的端口配置的流控去掉，解决问题。

2004-12-21 09:36 zn8903

【条目标题】2403H-EI配置VLAN 512时提示“VLAN ID out of range ” 【现象描述】S2403H-EI VRP3.10 0001，Bootrom 105 2403H-EI配置VLAN 512时提示VLAN ID out of range 【告警信息】VLAN ID out of range //VLAN ID超出范围 【原因分析】2403H-EI目前的VRP版本所支持的512个VLAN必须在一个连续的区域 【处理过程】1、2403H-EI 的默认VLAN RANG是1-511 2、可以通过命令：vlan rang 改变默认值 [2403]vlan rang ? 1-511 use range 1-511 512-1023 use range 512-1023 1024-1535 use range 1024-1535 1536-2047 use range 1536-2047 2048-2559 use range 2048-2559 2560-3071 use range 2560-3071 3072-3583 use range 3072-3583 3584-4094 use range 3584-4094 3、2403H-EI的支持的512个VLAN必须在一个连续的区域

2004-12-21 09:43 zn8903

【条目标题】AR4640路由器做GRE时隧道建立不成功 【现象描述】AR4640路由器做GRE时tunnel接口配置IP地址，对端E公司设备在tunnel接口不配置地址，导致两端tunnel建立不起来。 【告警信息】无 【原因分析】AR46路由器做GRE时tunnel接口必须配置IP地址，该地址是生成隧道路由用的。有些设备不配置地址，是因为这些设备直接用默认的地址或借用别的地址封装GRE。 以下是GRE封装的过程： 连接内部网络的接口收到IP数据报后首先交由IP协议作路由处理，IP协议检查IP报头中的目的地址域来确定如何路由此报文。若报文的目的地址被发现要从路由器的隧道端口Tunnel X路由出去时，则启用GRE封装，根据端口Tunnel X定义的源目的地址，将这个原始的数据报文进行封装，完成GRE封装后的IP数据报文（协议类型为47）的目的地址是Tunnel X所定义的目的地址（通常是远端路由器的某个端口地址），源地址是Tunnel X所定义的源地址（通常是本地路由器上的某个端口地址），封装后的IP数据报文再交给IP模块处理，根据相应的目的地址及路由表项决定从哪一个端口发送出去，交给相应的网络接口处理。 下面是通过GREtunnel隧道传递的一个ping包收发流程。第一步就是用tunnel接口建立路由。tunnel接口没有IP地址，是不会建立三层路由的，因为路由的下一跳必须是有三层IP地址的。如果配置静态路由，tunnel接口的地址两端可以不在一个网段；但是运行RIP/OSPF等动态路由协议，tunnel接口的地址两端必须在一个网段。 00:07:31: IP: s=192.168.2.1 (local), d=192.168.1.1 (Tunnel0), len 100, sending 00:07:31: ICMP type=8, code=0 00:07:31: IP: s=1.1.1.2 (local), d=1.1.1.1 (Ethernet0/0), len 128, sending, prot o=47 00:07:31: IP: s=1.1.1.1 (Ethernet0/0), d=1.1.1.2 (Ethernet0/0), len 128, rcvd 3, proto=47 00:07:31: IP: s=192.168.1.1 (Tunnel0), d=192.168.2.1, len 100, rcvd 4 00:07:31: ICMP type=0, code=0 【处理过程】AR46路由器做GRE时tunnel接口必须配置IP地址。将E公司设备更改了一下配置，配置TUNNEL接口IP地址，两端GRE隧道就能建立成功了。

2004-12-23 13:30 zn8903

【条目标题】FAQ-FTP的两种工作模式是什么，其工作原理如何？ 【现象描述】Q：FTP的两种工作模式是什么，其工作原理如何？ 【告警信息】无 【原因分析】无 【处理过程】A：FTP有两种工作模式，一种是port（主动）模式，另一种是passive（被动）模式。 1、port（主动）模式 客户端向服务器的FTP端口（默认是21）发送连接请求，服务器接受连接，建立一条控制连接。当需要传送数据时，客户端在控制连接上用向服务器发送PORT命令告诉服务器自己打开了XXXX端口。于是服务器从20端口向客户端的XXXX端口发送连接请求，建立一条数据链路来传送数据。 2、passive（被动） PASV（被动）方式的连接过程是：客户端向服务器的FTP端口（默认是21）发送连接请求，服务器接受连接，建立一条控制连接。当需要传送数据时，服务器在控制连接上用PASV命令告诉客户端自己打开了XXXX端口。于是客户端向服务器的XXXX端口发送连接请求，建立一条数据链路来传送数据。

2004-12-23 13:32 zn8903

【条目标题】S3528G下挂用户因一个用户受到攻击而上网慢 【现象描述】组网：ISN8850-MA5100-S3528G(END)-S3528G(2)-Router/lanswitch(用户端） 1）3528G下挂用户上网慢，ping包存在丢包现象； 2）查看3528END，发现上行口0/24的下行流量达到25M左右，下行口0/2的下行流量几乎也是25M左右； 3）查看各接入3528-2各端口流量，发现0/10端口（某用户）的下行流量接近25M左右，流量明显异常； 4) 将3528-2的0/10端口shutdown后，业务立即恢复正常； 5）3528-2上针对该用户作流量限速，重新放开该端口，故障没有立即重现； 6）约40分钟后，现象再次重现，shutdown 3528-2的0/10端口后，故障现象依旧，且这次3528END的0/24的下行流量达到36M左右，而5100对该pvc的带宽只有40M，带宽几乎全被占满，这次从8850能telnet 3528END下挂的3528,但无法telnet 3528END； 7）在3528END抓包跟踪0/24的流量，发现大量不同源ip地址不同TCP端口到目的地址211.95.104.35的TCP端口7000，7200的连接，据此判断该用户受到攻击。 【告警信息】无 【原因分析】故障是由于3528END下挂用户受到攻击所致，由于攻击并不是一直持续，导致第一次并未定位； 攻击来自3528END上游设备，在3528-2端口0/10 shutdown后,由于路由依然指向3528END,所以3528END依然受到影响，但接入3528不会受影响； 接入3528的限速能防止针对限速用户或限速用户发起的攻击； 汇聚3528起汇聚功能，不针对用户限速，本次攻击来自外网，3528END依然会受到影响。 【处理过程】在GSR路由器将该用户的路由回指删除，业务立即恢复正常。

2004-12-24 10:03 zn8903

【条目标题】用户反映S2403H下的用户上不了网。 【现象描述】用户反映S2403H下的用户上ping不通自己的网关。 组网图：PC---S2403H（E0/25)-----(E0/1)S3528----S8016（用户网关） 【告警信息】无 【原因分析】S2403H的业务vlan206通S3528做二层透传到S8016，业务vlan206的网关在S8016上。PC机ping不通自己的网关，主要有以下几个原因： 1、链路故障，即从S2403H到S3528,和S3528到S8016。 2、配置问题，S2403H没有把业务VLAN透传到S3528,或者是S3528没有把业务VLAN透传到S8016。 【处理过程】针对上述分析，在进行如下排错之前已经确认PC机和网线没有问题: 1、从S2403H上pingS3528的管理VLAN接口地址是可以ping通，从S3528上pingS8016的管理VLAN 接口地址也是可以ping的。这说明链路是没有问题的。 2、查看S2403H的配置，发现S2403的E0/25端口工作在hybirid模式，业务vlan206全是untaged方式上去的， S3528的E0/1端口是trunk模式，但是PVID是1。这样的话，从E0/1端口进来的untaged 报文全部被打上vlan 1的标记。造成业务vlan的tag标记改变，无法和S8016的业务vlan通信。 所以，PC机ping不网关。把S3528的E0/1的PVID该为206后，用户PC机可以ping网关了。

2004-12-31 11:41 zn8903

【条目标题】3552 MAC地址学习案例分析 【现象描述】1、组网描述：3552P下挂多台2403H，2403H将Vlan Trunk到S3552P，再由3552P将所有Vlan Trunk到上行S8016上，3552P与其下挂的2403H都用Vlan1000做为管理Vlan； 2、3552P学习到了其下挂2403H的MAC地址，但其中有一台2403H（192.168.0.15）的MAC地址表项被学习到了3552P 的多个VLAN中，而这多个VLAN又是从此2403H（192.168.0.15）Trunk上来的； 3、其它的2403H，如2403H（192.168.0.40）与2403H（192.168.0.15）的配置一样，而此台2403H的MAC地址表在3552P只对应了一条MAC地址表； 4、下挂的所有2403H业务转发均正常； 【告警信息】1、在3552上查看ip地址为192.168.0.15的2403H的mac表项时，发现学习在了多个vlan中，信息如下： <XHNL_3552_192.168.0.51>dis mac 00e0-fc21-b154 MAC ADDR VLAN ID STATE PORT INDEX AGING TIME 00e0-fc21-b154 1 Learned Ethernet0/2 AGING 00e0-fc21-b154 31 Learned Ethernet0/2 AGING ...... 2、而在3552上查看ip地址为192.168.0.40的2403H的mac表项时，发现只学习在了1个vlan中。 无其他告警信息。 【原因分析】具体原因如下： 1、2403H（192.168.0.15）打开了环回检测功能，它会在和3552所接的端口的所有vlan中发送环回检测报文，该报文的源mac地址为2403H的桥mac地址，从而导致这个mac地址学习到了所有的3552的各个vlan中。 <XHNL-2403.15>dis loopback-detection Loopback-detection is running Detection interval time is 30 seconds There is no port existing loopback link 2、而2403H（192.168.0.40）的环回检测是关闭的，所以3552的mac地址仅仅学习到和2403H虚接口所在的vlan中。如果在这台2403H上也打开环回检测，也会出现一样的情况。 <XHNL-2403.40>dis loopback-detection Loopback-detection is not running 【处理过程】两台交换机上有一台打开了loopback功能导致mac学习在多vlan中，属于正常现象。

2004-12-31 11:45 zn8903

交换机二三层转发流程 二三层转发流程 二层转发： 假设Pc1，和Pc2发ping包，pc1的IP地址是1.1.1.3，网关掩码是255.255.0.0， pc2的IP地址是1.1.1.5，网关掩码是255.255.0.0， Pc1 发ping包时，先比较pc1的IP和pc1网关相与是否等于pc2的IP和pc1网关相与的值，若相等，则认为是二层转发。 若认为是二层转发则查本机的ARP表，看表中是否有这一项。 若有： 则可由pc2的IP得到pc2的mac，然后发ICMP requst报文给L3，L3收到后，先查pct(端口配置表)表，比较目的mac是否与L3的MAC相等，若相等，则认为是三层，在此情况下是不相等，则接着查vlan表，得到vlanid，然后以vlanid和目的mac为索引，查单播mac表， 若查得到，则可得到出端口号，然后，帧走到下行，在下行入队列之后，学习添加pc1的mac表项。 若在单播MAC表中查不到，则根据原来vlan表中查到的mid，查Mid up表，然后由此表可知有那些lpu 板上配有此vlan，（因为是广播，所以就不查单播mac表了），然后再上网板前，把此ICMP报文复制给每个lpu板一份，然后下网板的时候，查mid down表，得到本板上哪些端口是属于这个vlan的，对属于本vlan的各个端口（pc1所在的端口除外）都复制一份ICMP报文下发下去，当进行到本板的最后一个端口时，添加有关pc1的单播mac表项。 各端口的pc收到此ICMP报文后，比较目的mac是否与本机相同，若不同则丢弃，若相同，则接收，并回ICMP reply报文。此处，也就是pc2回ICMP reply报文。L3收到后，在下行的时候学习到pc2的mac表项。 若没有： 则发ARP广播，请求目的IP为pc2的MAC,此时目的MAC填的是全f，当L3收到这个ARP报文后，先查PCT表，比较报文中的目的MAC是否与L3的MAC相等，此处为不等，认为是二层转发，先查vlan表，得到vlanid，然后用vlanid查Mid up表，然后由此表可知有那些lpu 板上配有此vlan，（因为是广播，所以就不查单播mac表了），然后再上网板前，把此ARP报文复制给每个lpu板一份，然后下网板的时候，先抄送一份给CP，此时cp可以由此ARP 报文学习ARP表项和FIB表项。查mid down表，得到本板上那些端口是属于这个vlan的，对属于本vlan的各个端口（pc1所在的端口除外）都复制一份ARP报文下发下去，当进行到本板的最后一个端口时，添加有关pc1的单播mac表项。 这时，pc2将会收到此ARP报文，pc2收到后，发送ARP应答给L3，然后因为L3中已经有了pc1的mac表项，直接可以发到pc1所在的端口，此时学习pc2的mac信息。这样 当此ARP reply报文回到pc1后，pc1就可以直接发ICMP报文了。 三层转发： 假设Pc1 ，和Pc2 发ping包，pc1的IP地址是2.2.2.2，网关掩码是255.255.0.0， pc2的IP地址是3.3.3.3，网关掩码是255.255.0.0，网关是3.3.3.1。 pc1发ping包时，先比较pc1的IP和网关相与是否等于pc2的IP和网关相与的值，不相等，认为是三层转发，然后查本机的fib表，查对应下一跳IP的Mac。 若查到了，则可直接发ICMP报文了。转 * 处继续处理。 若查不到， 则发ARP 报文请求下一跳IP 的mac（本例中也就是L3的mac），即目的mac为L3的mac，目的ip为L3的ip。 此ARP报文到了L3后，会在pc1所属的vlan内广播一下，同时给cp送一份，此时cp回一个ARP reply应答，同时学习pc1的fib和arp表项，下行的时候学习pc1的mac。 * pc1收到此ARP reply后，开始发ICMP报文，目的ip为pc2的ip，目的mac为L3的mac。 此ARP reply报文到了L3后，L3先查PCT表比较目的mac是否等于L3的mac，此处相等，则认为是三层转发。 再查fib表，得到下一跳的IP和目标板号，目标端口号，在查fib表的过程中： 若一项都不能匹配，则丢弃； 若能匹配，则匹配有两种情况： 1、能匹配到主机路由，则在下行的时候查ARP表项，从相应端口发出去； 2、只能匹配到网段路由，则产生fib miss消息，并把此ICMP报文上送cp，当cp收到此ICMP报文后，则发一个ARP广播报文在pc2所属的vlan内进行广播,（此处是采用D201封装的，解封装后相当于二层报文），此报文进入下行，并通过wrap端口环回到上行，在上行的时候再查pct表，vlan表，和mid up表，给每个在pc2的vlan的各板复制一份，上网板，下网板，（此时因为判断原mac是L3的mac，所以就不上送给cp了），再查mid down表，给每个板上各所在pc2的vlan的各端口复制一份。 当pc2收到此ARP报文后，则回一个Arp reply给L3 ，然后L3就可以学到pc2的fib和arp表项，下行的时候学习到pc2的mac表项。 这样，pc1和pc2就可以ping通了。 [楼顶] lifengJS 回复于2004-11-29 21:00:09 二三层转发流程中的重要微码表 二层转发 首先报文从PC机发出时查找本机ARP表（arp －a），若存在相应的表项，就直接发出，报文下一跳MAC地址为目的MAC地址，IP地址为目的IP地址。若不存在相应表项则发出ARP请求报文，走ARP请求流程。等报文来到交换设备S，S首先查找自己的PCT表，比较报文的目的MAC地址和自己的MAC地址是否相同，若相同则为三层转发，二层转发则不相同。下面查找S设备的VLAN表（disp efu l3vlan）通过报文帧中所带的vlan id检查此报文做了哪些配置，不同配置要走不同的流程。此外我们还可以得到mid表项。然后通过vlan id查找单播MAC表（disp mac dy slotnum）从相应的出接口发出报文，在下行学习源MAC表项，最后到达目的地。如果这里查找单播MAC表失败的话，就根据刚才的mid值在上行查找mid_up_tbl，看哪些单板上有这个vlan，在每个含有此vlan的单板都复制一份广播报文，在下行查找mid down表得知在单板上此vlan包含哪些端口，最后就复制报文在这些端口进行广播。目的PC收到此报文后进行回应。S收到回应报文在下行学习该MAC地址。 PC S S S S ARP--------->PCT--------->VLAN--------->MAC---------->Mid_Up-------- S -->Mid_Down pct表 [121-diag] PCT: 00 E0 FC 0F AB 57 EB 07 ***这就是设备的mac地址。报文中的mac地址与之。 00 00 6E 10 00 40 00 00 ***比较判断二三层转发 Detail: MAC address: 00.E0.FC.0F.AB.57. arp is enabled ip multicast is enabled broadcast is enabled mpls multicast is disabled ip is enabled mpls unicast is disabled clns is enabled support_8021p is disabled reserved ipmc is disabled qinq enable is disabled qinq internet access enable is disabled Port is not isolated vswtich is disabled vswtich is inclusive l2 bridge is enabled port aggregation is disabled STP Op is disabled Blocking is disabled Listening is disabled Learning is disabled Forwarding is enabled Ingress filtering Op is enabled Admit all frames is enabled default priority is 0 default vlanid is 110 l4_skip is disabled ba_flag is disabled sa lookup is disabled eth port type is ethernet_l2 ingress_context(hex) is 000 ac field is absent physical port is ethernet entry address is 0000 complete unit generate label is disabled hard classifier is disabled start pos of QW 0 prefetched QWs is 4 reserved ip mc address 00-15: [0x0]-[0x0]-[0x0]-[0x555555] reserved ip mc address 16-31: [0x5502823c]-[0x90000000]-[0x0]-[0x0] Done. [121-diag] Vlan表 [121-diag]disp efu l3vlan 3 110 Start query l3vlan of board 03... completionCode = 0 vlan_id = 110 MID = 110 learningDisabled is enable NotuseMid is disable VlanDisable is disable vpls is disable multicast is disable vrrp = 0 supervlanid = 0 MC reserved Flag = 0x0 vpnid = 1 counterindex =0x1130a3 mc_ttl =0 l3_enable =1 qos_behavior =3 trust 802.1p =0 igmp =0 memberSet = 0x0 0x8 0x0 0x0 0x0 0x0 untaggedSet = 0x0 0x8 0x0 0x0 0x0 0x0 groupFilter = 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x100 0x111ca7 [121-diag] mac表 [121]display mac-address dy 3 MAC Address VLAN ID Port/Lsp Type ---------------------------------------------------------------- 0005-5d0a-1b2d 110 gigabitethernet3/0/0 dynamic 00e0-fc11-2233 110 gigabitethernet3/0/0 dynamic mid up表 [121-diag]disp efu mid_up_tbl 3 110 Start query mid_up_tbl of board 03... Slot member of mid 110 = [3] 三层转发 首先PC机根据目的IP地址先查找自己的路由表（route print），查对应下一跳的IP地址，在根据此IP 地址查找ARP表对应下一跳的MAC地址（若查不到则发ARP请求，走ARP流程）。报文到达接入设备后，设备还是查找PCT表，判断二三层转发。然后查找FIB表，得到下一跳IP地址和目标板号和端口号（tb & tp），没有匹配的表项就丢弃报文。这里如果只能找到网段路由，则发fib_miss到主控板CP，CP走ARP流程进行学习。若存在主机表项，则从相应端口出。 fib表 [121-diag]disp efu fib 3 192.168.120.3 24 vrf1 Start display lpu fib on board 03... Message sending success. [121-diag] IP address = 192.168.120.0 IP prefixLength = 24 VRF index = 1 Signature = 0 ecmpThr1 = 100 ecmpThr2 = 0 nextHop[0] lsptoken = 44 inner label = 1040 egressContext = 0 tb = 5 tp = 0x3 subIndex = 0 nextHop[0] is MPLS nextHop[0] is WITH_BGP_LABEL arp表 [121-diag]disp efu arp 3 0 0 192.168.110.3 110 Start display lpu arp on board 03... Message sending success. [121-diag] IP address = 192.168.110.3 nextHopMac = 0.5.5d.a.1b.2d vlanid = 110 encapsulation type is DIX slot=3, card=0, port=0 需要注意的几个常用表项 1．查报文的丢弃计数 [121-diag]disp efu counter 3 discard Start show lpu efu ims information of board 03... show lpu efu ims information message is sent successfully. [121-diag] Discard[ 47]= 27, reason:FIB lookup failed //说明有报文因为fib表查找失败而丢失。 2．查报文的转发计数 [121-diag]disp efu counter 3 internal Start show lpu efu ims information of board 03... show lpu efu ims information message is sent successfully. [121-diag] Internal[ 4]= 3, reason:enqi unicast frame to LPU 15 Internal[ 16]= 564, reason:D201 frame //下送接口板的组播报文 Internal[ 18]= 7, reason:D205 frame //下送接口板的单播报文 Internal[ 20]= 21, reason:D204 frame //上送主控板的单播报文 Internal[ 22]= 3, reason:Wrap Copy frame Internal[ 28]= 2390947859, reason:frame entering L3 //进入的3层报文 Internal[ 32]= 3, reason:RESERVED Internal[ 46]= 2390945735, reason:L3 into L4 //上送主控板处理的上层协议报文（3层到4层） Internal[ 48]= 2239430201, reason:SMT leaf hitted Internal[ 55]= 5462, reason:frame entering L2 //进入的2层报文 Internal[ 64]= 6026, reason:L2 sent M1 frame Internal[ 74]= 2390947820, reason:RESERVED [121-diag] 3．查nps接收和发送的控制报文，数据报文计数 [121-diag]disp msgcnt 3 ? cmo To display CMO message counter information //cmo计数 control To display control message counter information //普通消息计数 egress To display egress data message counter information //NP上送协议报文计数 ingress To display ingress data message counter information //上层下发给NP的协议报文计数 [121-diag]disp msgcnt 3 con [121-diag]disp msgcnt 3 control ? INTEGER<0-8> Please seletct number 0:All; 1:Ip; 2:Mac; 3:Vlan; 4:Mpls; 5:Qos; 6:Nat; 7:webswitch; 8:Reset [121-diag]disp msgcnt 3 control 4 Start display message conuter on board 03... OutSegment Add: RPS->NPS = 232, NPS->NP = 232 OutSegment Update: RPS->NPS = 0, NPS->NP = 0 OutSegment Delete: RPS->NPS = 27, NPS->NP = 27 InSegment Add: RPS->NPS = 325, NPS->NP = 325 InSegment Update: RPS->NPS = 0, NPS->NP = 0 InSegment Delete: RPS->NPS = 33, NPS->NP = 33 E2D Add: RPS->NPS = 0, NPS->NP = 0 E2D Update: RPS->NPS = 0, NPS->NP = 0 E2D Delete: RPS->NPS = 0, NPS->NP = 0 D2E Add: RPS->NPS = 0, NPS->NP = 0 D2E Update: RPS->NPS = 0, NPS->NP = 0 D2E Delete: RPS->NPS = 0, NPS->NP = 0 FACS Add: RPS->NPS = 0, NPS->NP = 0 FACS Update: RPS->NPS = 0, NPS->NP = 0 FACS Delete: RPS->NPS = 0, NPS->NP = 0 VPN Add: RPS->NPS = 0, NPS->NP = 0 VPN Update: RPS->NPS = 0, NPS->NP = 0 VPN Delete: RPS->NPS = 0, NPS->NP = 0 [121-diag]disp msgcnt 3 eng [121-diag]disp msgcnt 3 eg [121-diag]disp msgcnt 3 egress ? INTEGER<0-1> Is reset? 1:yes; 0:no; default=0 <cr> [121-diag]disp msgcnt 3 egress Start display message conuter on board 03... Egress Data Message Statistic: ARP_Request: XXX->NPS = 6349, NPS->NP = 6349 ARP_ACK: XXX->NPS = 718, NPS->NP = 718 L3_NEED_FIB: XXX->NPS = 0, NPS->NP = 0 DHCP_RSTP: XXX->NPS = 0, NPS->NP = 0 HGMP_GVRP: XXX->NPS = 0, NPS->NP = 0 L3_NO_FIB_Other: XXX->NPS = 3860, NPS->NP = 3860 ICMP_L2VPN: XXX->NPS = 0, NPS->NP = 0 RIP_Broatcast: XXX->NPS = 0, NPS->NP = 0 L2_Other: XXX->NPS = 0, NPS->NP = 0 ETH_VRRP: XXX->NPS = 8218, NPS->NP = 8218 L2_ISIS: XXX->NPS = 0, NPS->NP = 0 [121-diag]disp msgcnt 3 ing [121-diag]disp msgcnt 3 ingress ^ % Incomplete command found at '^' position. [121-diag]disp msgcnt 3 ingress ? INTEGER<0-21> Please select number 0:All; 1-20:Component Number; 21:Reset [121-diag]disp msgcnt 3 ingress 0 Start display message conuter on board 03... Ingress Data Message Statistic: Component- 1 Reason_code- 1: NP->NPS = 0, NPS->XXX = 0 Component- 1 Reason_code- 2: NP->NPS = 0, NPS->XXX = 0 Component- 1 Reason_code- 3: NP->NPS = 0, NPS->XXX = 0 Component- 2 Reason_code- 1: NP->NPS = 0, NPS->XXX = 0 Component- 2 Reason_code- 4: NP->NPS = 0, NPS->XXX = 0 Component- 3 Reason_code- 0: NP->NPS = 293, NPS->XXX = 293 Component- 3 Reason_code- 1: NP->NPS = 0, NPS->XXX = 0 Component- 3 Reason_code- 2: NP->NPS = 40643, NPS->XXX = 40643 Component- 3 Reason_code- 3: NP->NPS = 0, NPS->XXX = 0 Component- 3 Reason_code- 4: NP->NPS = 0, NPS->XXX = 0 Component- 3 Reason_code- 6: NP->NPS = 0, NPS->XXX = 0 [121-diag] [121-diag]disp msgcnt 3 cmo [121-diag]disp msgcnt 3 cmo ? INTEGER<0-6> Please select number 0:All; 1:Port; 2:Protocol; 3:Qos; 4:L2if; 5:Pm; 6:Reset [121-diag]disp msgcnt 3 cmo 0 Start display message conuter on board 03... CMO Message Statistic: CMO_PORT_Valid: RPS->NPS = 0, NPS->NP = 0 CMO_PORT_Status: RPS->NPS = 0, NPS->NP = 0 CMO_NI_Status: RPS->NPS = 0, NPS->NP = 0 CMO_NI_ShutDown: RPS->NPS = 12, NPS->NP = 0 4．查Qos规则命中计数 [121-diag]efu qos hit-count eacl e111 Query EACL hit count from NPS: e111 r192: GigabitEthernet3/0/0 VLAN 65535 //不同的规则命中计数 The number of EACL hits: 3427293 e111 r193: GigabitEthernet3/0/0 VLAN 65535 The number of EACL hits: 8443947 e111 r111: GigabitEthernet3/0/0 VLAN 65535 The number of EACL hits: 121987474 e111 r110: GigabitEthernet3/0/0 VLAN 65535 The number of EACL hits: 1121935812 5．查7号表 [121-diag]disp table 3 7 //7号表也是路由表和fib表性质差不多，只是它包含了一些特殊信息。比如板号，端口号等等。 IP=255.255.255.255, prefix=32, Th0=100, Th1=0 Color=0x1 [0] ip=127.0.0.1, hop_action=0x60, tb=0x0, tp=0x0, subindex=0 ,eContext=0 [1] ip=0.0.0.0, hop_action=0x0, tb=0x0, tp=0x0, subindex=0 ,eContext=0 [2] ip=0.0.0.0, hop_action=0x0, tb=0x0, tp=0x0, subindex=0 ,eContext=0 IP=50.1.1.1, prefix=32, Th0=100, Th1=0 Color=0x0 [0] ip=127.0.0.1, hop_action=0x20, tb=0x0, tp=0x0, subindex=0 ,eContext=0 [1] ip=0.0.0.0, hop_action=0x0, tb=0x0, tp=0x0, subindex=0 ,eContext=0 [2] ip=0.0.0.0, hop_action=0x0, tb=0x0, tp=0x0, subindex=0 ,eContext=0 IP=1.1.1.1, prefix=32, Th0=100, Th1=0 Color=0x0 [0] ip=127.0.0.1, hop_action=0x20, tb=0x0, tp=0x0, subindex=0 ,eContext=0 [1] ip=0.0.0.0, hop_action=0x0, tb=0x0, tp=0x0, subindex=0 ,eContext=0 [2] ip=0.0.0.0, hop_action=0x0, tb=0x0, tp=0x0, subindex=0 ,eContext=0 IP=10.164.19.121, prefix=32, Th0=100, Th1=0 Color=0x0 [0] ip=127.0.0.1, hop_action=0x20, tb=0x0, tp=0x0, subindex=0 ,eContext=0 [1] ip=0.0.0.0, hop_action=0x0, tb=0x0, tp=0x0, subindex=0 ,eContext=0 [2] ip=0.0.0.0, hop_action=0x0, tb=0x0, tp=0x0, subindex=0 ,eContext=0

2005-1-7 14:39 zn8903

【条目标题】6506开启端口802.1X认证功能后，HGMP无法管理到此端口下挂的交换机 【现象描述】6506开启端口802.1X认证功能后，HGMP无法管理到此端口下挂的交换机 【告警信息】无 【原因分析】1、802.1x会对启动了802.1x的端口进行授权认证，只允许经过授权的端口转发报文。此时如果连接交换机的端口没有进行802.1x的授权和认证，HGMP报文将会被802.1x特性过滤，使管理设备无法获取下挂的交换机的MAC地址，从而管理设备无法对下挂的交换机进行管理。6506交换机上开启802.1X协议后，下挂的交换机的MAC地址对于开启802.1X协议的端口来说，也是非授权端口，所以关键问题就是让这个MAC地址合法化。 【处理过程】1、通过配置静态MAC地址来实现，在HGMP server上配置下挂交换机的MAC地址。 配置命令 系统视图： mac-address { static | dynamic } hw-addr interface { interface-name | interface-type interface-num } vlan vlan-id 2、交换机上启动HABP特性，HABP报文将会忽略端口上的802.1x认证，在交换机之间进行通信，从而使管理设备可以获取下挂交换机的MAC地址，对下挂的交换机进行管理。HABP包括HABP Server和HABP Client。一般情况下，Server会定期向Client发送HABP请求报文，收集下挂交换机的MAC地址。而Client会对请求报文进行应答，同时向下层交换机转发HABP请求报文。HABP Server一般应该在管理设备上启动，HABP client应该在下挂的交换机上启动。 配置命令 Server端配置 使能HABP特性： habp enable 配置当前交换机为HABP Server： habp server vlan vlan-id Client端配置 使能HABP特性： habp enable

2005-1-11 15:28 zn8903

2005-1-13 14:43 zn8903

【条目标题】因设备地线带电导致R2631E上行口ping包丢包 【现象描述】版本信息：1.74 组网概述：地市中心NE08－－传输－－县局R2631E－－L2－－PC，NE08通过两个2M连接一个县局的R2631。 故障现象：R2631E下用户无法上网，直接从2631E上行口ping对端NE08 2M接口丢包率高达30％。脱开L2，现象如故。从NE08侧disp int ser，可以看到连接26的两个2M口都有input、output error，清除端口统计值再查看端口状态可以看到端口crc错误在增长。 【告警信息】设备无异常告警 【原因分析】原因分析：从现象看比较简单，最大的可能是传输问题，或者设备2M接口问题（NE08以前出过）。因为同时坏两个2M口的可能性较小，应该以检查传输线路问题为主。 【处理过程】首先检查传输，做环。传输对两端DDF架打环，两条2M都没有问题，排除线路原因；从NE08向县局DDF打环，也没有问题，排除NE08侧问题；从县局26向地市中心DDF架打环，2M口都有误码；26向县局DDF架打环，仍然有误码，说明问题出在26侧，很可能是2M接口故障。 更换26的4E1模块，对DDF架打环，仍然有误码。更换26整机，打环，误码消失，解环，ping NE08不丢包。至此以为问题解决，新26上机架，接好地线，用户上网又不行了，检查2M口又出现误码，脱开地线，用万用表一打电压有60多V。重新接地，使用原26，也不再出现端口误码，用户上网正常。 设备不进行接地或接地出现问题（接地电阻过大或出现地线带电）都可能会对设备运行造成预料不到的影响，对外表现又往往显示为如上所示的接口错包等等，特别是对中低端路由器、交换机设备。

2005-1-13 15:21 老老鼠

我这里有个AVAYA的奇怪问题，还没解决呢，把案例放来，大家看看： AVAYA 882或者580，下连334T交换机甚至HUB，隔几天334t就连不上来，看882（580）日志，端口有DOWN掉记录，但是目前正常，可是网络就是不通，或者第一包能PING通，之后就丢掉几十个包，再通一个包。要882重启才能解决。 另外的FOUNDRY 15000上有过一点小问题，哪天整理了放上来。还有CISCO的6509的案例比较多，但是都没记录 <img src='style_emoticons/default/blush.gif' border='0' style='vertical-align:middle' alt='blush.gif' />

页: [1] 2 3