除了熟练使用sniffer类工具外,对路由和交换等设备的调试也要熟悉.这样分析问题才胸有成竹.
分割线
--------------------------------------------------------------------------------------------------------------------
【条目标题】华为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地址冲突。可以换用此类型设备满足该组网需求。
--------------------------------------------------------------------------------------------------------------------
【条目标题】两端设备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值恢复为默认值后问题解决
--------------------------------------------------------------------------------------------------------------------
【条目标题】工程师反映删除S3026的flash中的文件后，flash的剩余空间还是没有变大。
【现象描述】工程师反映删除S3026的flash中的文件后，flash的剩余空间还是没有变大。
【告警信息】无
【原因分析】delete命令用来删除以太网交换机的存储设备中的指定文件。该命令支持“*”通配符。被删除的文件存放在回收站目录中，使用dir /all命令显示所有文件目录信息时，发现被删除的文件仍然在flash里面。
【处理过程】没有完全删除文件，用delete/unreserved：彻底删除该文件。再用dir /all 查看，没有被删除
文件。flash的剩余空间正常。
【条目标题】由于禁止了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
--------------------------------------------------------------------------------------------------------------------
【条目标题】交换机端口聚合汇总
【分析】端口汇聚是将多个端口聚合在一起形成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个千兆端口。组内的端口号必须连续，但对起始端口无特殊要求.
--------------------------------------------------------------------------------------------------------------------
【条目标题】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端口执行该命令，既不会因为有环路导致无法上网，也不会因为环路存在而不知晓.
--------------------------------------------------------------------------------------------------------------------
【条目标题】路由器接口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报文不分片.
--------------------------------------------------------------------------------------------------------------------
【条目标题】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小的路由.
--------------------------------------------------------------------------------------------------------------------
【条目标题】采用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报文由于是以组播形式发送，没有受到影响
--------------------------------------------------------------------------------------------------------------------
【条目标题】S6506的ospf邻居down
【现象描述】PC---S6506----S8016----
|
5200(BAS)
用户发现ospf邻居断了两次。
218.76.67.182 s6506 s6506xxdx
【告警信息】无
【原因分析】telnet上用户设备，发现端口有大量的pause流控帧，导致端口处理溢出，ospf的hello报文传不出去。导致ospf邻居断掉。
【处理过程】将8016与65之间互连的端口配置的流控去掉，解决问题.
--------------------------------------------------------------------------------------------------------------------
【条目标题】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必须在一个连续的区域.
--------------------------------------------------------------------------------------------------------------------
【条目标题】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隧道就能建立成功了.
--------------------------------------------------------------------------------------------------------------------
【条目标题】FAQ-FTP的两种工作模式是什么，其工作原理如何？
【现象描述】Q：FTP的两种工作模式是什么，其工作原理如何？
【告警信息】无
【原因分析】无
【处理过程】A：FTP有两种工作模式，一种是port（主动）模式，另一种是passive（被动）模式。
1、port（主动）模式
客户端向服务器的FTP端口（默认是21）发送连接请求，服务器接受连接，建立一条控制连接。当需要传送数据时，客户端在控制连接上用向服务器发送PORT命令告诉服务器自己打开了XXXX端口。于是服务器从20端口向客户端的XXXX端口发送连接请求，建立一条数据链路来传送数据。
2、passive（被动）
PASV（被动）方式的连接过程是：客户端向服务器的FTP端口（默认是21）发送连接请求，服务器接受连接，建立一条控制连接。当需要传送数据时，服务器在控制连接上用PASV命令告诉客户端自己打开了XXXX端口。于是客户端向服务器的XXXX端口发送连接请求，建立一条数据链路来传送数据.
--------------------------------------------------------------------------------------------------------------------
【条目标题】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路由器将该用户的路由回指删除，业务立即恢复正常.
--------------------------------------------------------------------------------------------------------------------
【条目标题】用户反映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网关了.
--------------------------------------------------------------------------------------------------------------------
【条目标题】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中，属于正常现象.
--------------------------------------------------------------------------------------------------------------------
交换机二三层转发流程
二三层转发流程
二层转发：
假设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通了。
--------------------------------------------------------------------------------------------------------------------
【条目标题】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
--------------------------------------------------------------------------------------------------------------------
【条目标题】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端口执行该命令，既不会因为有环路导致无法上网，也不会因为环路存在而不知晓；
方便维护；
--------------------------------------------------------------------------------------------------------------------
【条目标题】因设备地线带电导致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，也不再出现端口误码，用户上网正常。
设备不进行接地或接地出现问题（接地电阻过大或出现地线带电）都可能会对设备运行造成预料不到的影响，对外表现又往往显示为如上所示的接口错包等等，特别是对中低端路由器、交换机设备。
--------------------------------------------------------------------------------------------------------------------
【条目标题】S3526 和s3026 组网导致环路的原因分析
【现象描述】组网:3526=======3026:
1)3526 和3026 E0/1 和E0/1接口对接,都做trunk透传vlan,3526 透传了vlan 15和其他业务vlan,3026没有透传vlan 15,只透传其他业务vlan.并且两端的E0/1的pvid都是1.
2)同时3526 vlan 7的一个access E0/7 连接接到3026的vlan 15的access E0/7,3026上没有配置vlan 7.
3)S3026 VLAN 15 包括 E0/7 和 E0/20 端口,pc挂接在E0/20 端口下.
4)导致目前3026下挂vlan 15用户不能正常使用
【告警信息】3026下挂vlan 15用户不能正常使用
【原因分析】对于SVL方式而言----交换机先根据目的MAC地址查MAC地址表，找到端口之后，然后判断这个端口所属的VLAN是否和报文携带的VLAN信息对应的VLAN相等，如果相等就转发，否则就丢弃。如果根据目的MAC没有找到对应的端口，则在报文所属的VLAN内进行广播。
而对于IVL而言----交换机根据MAC地址和VLAN信息一起查MAC地址表，如果找到对应的端口则转发，否则在报文所属的VLAN内进行广播。
因为3526是IVL转发方式 ,S3026 是SVL 方式.
环路造成的问题原因是:
1)3026 vlan 15的数据从上行的E0/7口出去,到3526端打上了vlan 7的vlan标识.然后3526通过E0/1口透传到3026.
2)3026收到该vlan 7数据报文后,不管3026上是否有该vlan 7的数据,3026都会从数据中学习到源mac,并且更新mac表项,发现数据包内没有匹配的vlan 则丢弃.
3)因为3026 是SVL 方式转发,那么同一个mac只能对应一个端口,所以原先该数据报文mac表项从下挂pc所在的端口 E0/20,现在更新到 E0/1,从而导致3026下挂pc数据不通.[
--------------------------------------------------------------------------------------------------------------------
【条目标题】因HGMP打开导致s2403h配置vlan 2047提示创建失败
【现象描述】两台新s2403h在配置vlan 2047提示创建失败，交换机上没有做任何的操作，创建其他的vlan则没有任何问题，如创建vlan 2048。
【告警信息】Creating VLAN fail!
【原因分析】因为HGMP V1是通过vlan 2047来传播报文的，所以肯定是HGMP占用了vlan 2047从而造成了无法创建。
【处理过程】重起交换机，按ctrl+b进入boot menu菜单，选择将hgmp关闭，再重起，问题解决。
--------------------------------------------------------------------------------------------------------------------
【条目标题】NE05聚合的BGP路由邻居学不到
现象描述】组网：
NE05－－CISCO12000
NE05在BGP相关配置中聚合两条路由：
aggregate 221.7.44.0 255.255.255.0 detail-suppressed
aggregate 221.7.45.0 255.255.255.0 detail-suppressed
结果BGP邻居只能学到221.7.44.0/24；学不到221.7.45.0/24
【告警信息】无
【原因分析】为什么同样是聚合，只有一条聚合成功呢？
BGP的路由聚合包括“手工聚合”和“自动聚合”，无论哪种聚合都要求在BGP路由表中至少存在一条“聚合”的“明细路由”，只有这样聚合才能生效。
检查发现：在BGP配置中，引入了direct路由，对于221.7.44.0，存在一条直联路由221.7.44.0/30，该路由被引入到BGP路由表中，因此可以聚合成功；而221.7.45.0，存在一条静态路由221.7.45.0/26，但是BGP没有引入静态路由，因此该路由无法被引入到BGP路由中，无法聚合。
【处理过程】1、检查配置
<NE05>disp ip rout 221.7.44.0
Destination/Mask Protocol Pre Cost Nexthop Interface
221.7.44.0/30 DIRECT 0 0 221.7.44.2 Virtual-Template0
221.7.44.0/24 AGGRE 130 0 127.0.0.1 InLoopBack0
221.7.32.0/20 BGP 170 2640 221.7.44.65 Pos4/1/0
221.7.32.0/19 BGP 170 2000 221.7.44.65 Pos4/1/0
0.0.0.0/0 BGP 170 0 221.7.44.65 Pos4/1/0
<NE05>disp ip rout 221.7.45.0
Destination/Mask Protocol Pre Cost Nexthop Interface
221.7.45.0/26 STATIC 60 0 221.7.44.10 Ethernet4/0/0
221.7.32.0/20 BGP 170 2640 221.7.44.65 Pos4/1/0
221.7.32.0/19 BGP 170 2000 221.7.44.65 Pos4/1/0
0.0.0.0/0 BGP 170 0 221.7.44.65 Pos4/1/0
<NE05>disp bgp rout 221.7.44.0
BGP route 221.7.44.0
From : local
State : valid, sourced, best,
Nexthop : 127.0.0.1
Origin : INC
As-path : (null)
Local aggregated
<NE05>disp bgp rout 221.7.45.0
BGP route 221.7.32.0/20
From : 221.7.44.65(219.158.2.96)
State : valid, external, best,
Nexthop : 221.7.44.65
Origin : IGP
As-path : 4837
Med : 2640
说明221.7.45.0/24没有聚合成功
3、因为BGP聚合成功要求BGP路由表中至少存在一条“聚合”的“明细路由”，因此配置221.7.45.0/24的黑洞路由，以network方式引入BGP，问题解决.
--------------------------------------------------------------------------------------------------------------------
【条目标题】局域网计算机找不到邻居问题
【现象描述】用户反映他们的局域网计算机经过8016交换机后找不到远端网络的网上邻居
【告警信息】无
【原因分析】Windows系统的网络邻居是利用NETBIOS服务的UDP 137端口和TCP 139端口来实现的，查看8016交换机的配置，在以太网端口上应用了过滤病毒的访问控制列表，该列表中过滤了UDP的137端口和TCP的139端口的报文，造成网络邻居关系无法发现和建立。
【处理过程】在访问控制列表中去掉UDP137和TCP139端口的过滤规则后问题解决。
--------------------------------------------------------------------------------------------------------------------
【条目标题】NE40 BGP中network引入了两个网段，却没有发布出去。
【现象描述】组网：NE40－－NE80
NE40和NE80之间启用BGP协议来学习路由，并且在同一个AS内。
NE40下接的设备使用192.168.100.0/24和192.168.101.0/24两个网段，现在业务还没有使用，想先将这两个网段发布出去，于是在NE40的BGP中配置了如下两条命令：
network 192.168.100.0 0.0.0.255
network 192.168.101.0 0.0.0.255
配置完成之后，发现在NE80上学不到这两个网段的路由。
【告警信息】【原因分析】BGP中network命令的含义是将所配置网段的路由引入BGP。前提条件是这条路由必须在路由器的路由表中存在。
如果路由表中没有，而又需要发布出去，则可以在路由器上配置需要发布网段的黑洞路由来欺骗BGP。
在BGP中做路由聚合时也可以采取这样的方式，配置一条大网段的黑洞路由，仅将这条路由引入BGP，而不引入明细网段的路由。
【处理过程】1、查看路由，因为在用户的网络中这两个网段尚未启用，所以路由表中没有这两个网段的路由；
2、配置黑洞路由，欺骗BGP。
ip route 192.168.100.0 255.255.255.0 null0
ip route 192.168.101.0 255.255.255.0 null0
3、配置完成后，telnet NE80查看，NE80上学到了这两个网段的路由.
--------------------------------------------------------------------------------------------------------------------
【条目标题】NE40做过滤路由导致NAT转换失败
【现象描述】5801-->3552-->MA5200-->NE40-->Cisco 12000-->公网
5801下的用户获得私网地址后，在NE40上做NAT到公网，做强制WEB认证。
NE40与C12000起OSPF协议。
用户反映不能上网，在现场实测，发现可以在5200上获得私网地址，也能ping通网关，但无法访问Portal服务器作认证。
【告警信息】NE40下5200的WEB认证用户可以获得地址，但无法到达认证页面进行认证上网。
【原因分析】1、检查MA5200的数据配置，无异常情况，且下接用户可以获得正确的私网地址，打开任一网页时，因此时只能PING通网关，PING不通DNS和Portal服务器，但5200上却是将这几个地址加入了未认证通过用户的可访问列表中。
2、检查NE40上相关的NAT配置，并无异常配置，dis nat session能找到转换记录。说明NE40上NAT转换成功。但私网用户最远只可以ping到NE40上行对端设备的接口地址，
3、检查NE40上有配置用于NAT转换的地址指向NULL的黑洞路由。
4、询问局方，上行的C12000故障前没有作过任何操作。
5、在NE40上找到一个空闲的三层以太口，配置上NAT转换使用的其中一个地址，指定源地址ping公网，发现PING不通。在公网上tracert这个IP时，发现最后一跳到了一台C6509上，C6509挂在C12000的另一个端口上。
此时，可以明确是这段地址在NE40的上行设备上没有做回程路由。
【处理过程】1、联系局方，在C12000上配置一条回程路由后，故障消失，5200下用户可以正常上网。
2、但局方表示，C12000上从未配置过回程路由，故障前都是可以正常NAT的，这样看来，故障原因并非如此简单。
3、继续检查NE40上的配置，检查日志，发现NE40上有做过配置改动。仔细检查配置，发现这些配置是在NE40上建了一个策略路由，用于在NE40上滤掉私网路由。
相关配置如下：
route-policy deny_private deny node 10
if-match acl 113
route-policy deny_private permit node 20
ospf
import-route direct route-policy deny_private
import-route static route-policy deny_private
但NE40上却没有ACL 113。NE40在应用这个路由策略时就做成了过滤掉所有的直联路由和静态路由。
做此配置之前能成功NAT的原因是因为做NAT必须配置的黑洞路由能成功地发布到对端的C12000上，解决了这个网段没有回程路由的问题。做了这个错误的路由策略导致上行的C12000学不到这个网段的路由，NAT出去之后找不到回程路由，用户上网失败。
至此，故障源找到，正确配置NE40，故障消除.
--------------------------------------------------------------------------------------------------------------------
【条目标题】S6503是基于流的路由负载分担
【现象描述】1、S6503上配置了两条不同下一跳、同样优先级的默认路由，但出去的报文并未逐包负载分担到两条默认路由上。
2、操作见Solution中：操作实例1。
【告警信息】无
【原因分析】1、S6503是基于流的分担负载，6503只根据报文的目的IP地址最后三位奇偶的不同会选用不同的下一跳进行数据转发。
2、操作见Solution中：操作实例2。
【处理过程】1、操作实例1
Destination/Mask Protocol Pre Cost Nexthop Interface
0.0.0.0/0 STATIC 60 0 10.*.*.17 Vlan-interface10
10.*.*.33 Vlan-interface12
10.254.*.65/32 DIRECT 0 0 127.0.0.1 InLoopBack0
10.254.*.17/32 DIRECT 0 0 127.0.0.1 InLoopBack0
<S6503>tracert -a 10.254.*.65 1.1.1.1
traceroute to 1.1.1.1(1.1.1.1) 30 hops max,40 bytes packet
1 10.*.*.33 14 ms 9 ms 9 ms
2、操作实例2
<S6503>tracert -a 10.254.*.65 1.1.1.1
traceroute to 1.1.1.1(1.1.1.1) 30 hops max,40 bytes packet
1 10.*.*.33 14 ms 9 ms 9 ms
2 10.254.*.5 9 ms 9 ms 9 ms
3 202.103.*.145 10 ms 8 ms 9 ms
<S6503>tracert -a 10.254.*.65 1.1.1.2
traceroute to 1.1.1.2(1.1.1.2) 30 hops max,40 bytes packet
1 10.*.*.17 14 ms 8 ms 9 ms
2 10.254.*.1 10 ms 9 ms 10 ms
3 202.103.*.145 9 ms 10 ms 9 ms
<S6503>tracert -a 10.254.*.65 1.1.1.3
traceroute to 1.1.1.3(1.1.1.3) 30 hops max,40 bytes packet
1 10.*.*.33 14 ms 8 ms 9 ms
2 10.254.*.5 10 ms 8 ms 9 ms
3 202.103.*.145 10 ms 8 ms 12 ms
<S6503>tracert -a 10.254.*.17 1.1.1.4
traceroute to 1.1.1.4(1.1.1.4) 30 hops max,40 bytes packet
1 10.*.*.17 14 ms 9 ms 9 ms
2 10.254.34.1 10 ms 8 ms 9 ms
--------------------------------------------------------------------------------------------------------------------
【条目标题】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 enab
现象描述：
AR28做NAT转换后，私网PC用BIT下载特别慢只有十几Kbye/s，同一个PC用公网IP地址上网，采用BIT下载速度可以达到一两百Kbye/s。
告警信息：
无
原因分析：
1、BIT的下载原则是，连接数越多下载速度就越快。在下载的同时也上传文件。BIT的连接的建立分为两种情况，一种是PC主动发起的连接，另外一种其他下载者主动和PC发起的连接。BIT通过侦听端口来提供其他下载者的连接端口。
2、公网PC不仅可以通过种子来主动和其他BIT下载者建立连接来下载和上传文件，其他BIT下载者可以通过公网PC的BIT侦听端口来建立连接来下载和上传文件。而私网PC的BIT侦听端口在公网上是看不到的，所以只能通过种子来和其他BIT下载者建立连接，来下载和上传文件。所以私网PC的BIT连接数要少于公网的BIT连接数，这样导致私网PC的BIT下载速度要比公网PC的BIT下载速度慢了很多。
处理过程：
在路由器的公网接口上做nat server，为私网PC的BIT侦听端口做一个静态TCP端口的映射，把BIT的侦听端口号映射到公网IP地址上：
nat server protocol tcp global X.X.X.X(公网地址)15338 inside Y.Y.Y.Y(私网地址）15338（侦听端口）
这样私网内的PC用BIT下载文件，不仅可以主动通过种子建立BIT连接，而且其他BIT下载者可以通过映射的侦听端口号和私网内的PC建立BIT连接，所以BIT的连接数增加很多，下载速度就便快了很多。
--------------------------------------------------------------------------------------------------------------------
某网吧用户做NAT访问外网时,一段时间出现业务中断，同时路由器有告警信息，然后业务又自动恢复。
组网：
网吧----------------（私网ETH1）R2621（ETH0公网）-----------------------Cisco2950
路由器告警:
%2005/09/30 13:52:37-NAT-6:
NAT: Fail to trans nat frag, src 61.147.119.135, dst 61.153.252.250, id 61513,
pro 17
%2005/09/30 13:52:37-ETHERNET-6:
Ethernet1: Received a unknown frame.
%2005/09/30 13:52:38-STANDBY-6:
ARP Add or update arp cache, IP:192.168.0.54,Ethernet:00-11-09-d8-62-c2
%2005/09/30 13:52:38-NAT-6:
NAT: Fail to trans nat frag, src 61.147.119.135, dst 61.153.252.250, id 63438,
pro 17
%2005/09/30 13:52:38-NAT-6:
NAT: Fail to trans nat frag, src 61.147.119.135, dst 61.153.252.250, id 64919,
pro 17
%2005/09/30 13:52:38-NAT-6:
NAT: Fail to trans nat frag, src 61.147.119.135, dst 61.153.252.250, id 65182,
pro 17
%2005/09/30 13:52:40-STANDBY-6:
ARP Add or update arp cache, IP:192.168.0.54,Ethernet:00-11-09-d8-62-c2
%2005/09/30 13:52:40-ETHERNET-6:
这种告警是从外网发往内网的分片报文乱序造成的（后续分片先于首片到达路由器）。
由于只有首片包含TCP/UDP的端口号，必须先根据首片确定NAT转换使用的Session表项，并记录在nat_frag表中，后续分片到达时根据nat_frag表中的记录，替换目的地址。
如果后续分片先到，在nat_frag表中查不到记录，就不作NAT转换，并打出这种调试信息。
配置nat fragbuffer enable使能乱序分片缓存功能（路由器缓存先到的后续分片，等首片到达后再发送），配置nat fragbuffer length指定分片缓存队列长度。
由于缓存队列长度有限，如果短时间收到大量乱序分片，队列填满之后再收到的分片也将不作NAT转换。
VRP1.74版本可以配置nat fragbuffer enable，配置nat fragbuffer length指定分片缓存队列长度。防止突发峰值流量时分片报文乱序造成业务中断.
[ 本帖最后由 ktjxtty 于 2006-12-31 10:30 编辑 ] |
发表于 2006-12-31 10:00:13
发表于 2006-12-31 14:07:16