|
|
1、关于解决MT9660/MT9650黑屏问题的公告
MT9660/MT9650摄像头分为两种型号，华为自产的C200和SONY产的D100。使用了C200摄像头的终端在实际使用过程中，连接了显示设备后，有可能会出现黑屏或者只有黑白两色的情况，但是按遥控器MENU键，可以弹出控制菜单（若设备上原来配置的显示设备类型跟所使用的一致，如配置了TV使用的也是TV，则按一下MENU键就可以显示菜单；但若不一致，如使用了VGA显示器，则需要按住MENU键10秒钟才可以显示出菜单）。这个问题是C200摄像头设计缺陷引起的，原因是C200摄像头和终端主PCB板的数据线插座设计不合理，导致连接两个部件的数据线无法跟两个部件紧密接触。一般情况下设备经过长途运输的颠簸后出现这种情况普遍现象。SONY产品出现此问题概率较小。
解决办法：将设备外壳开启（下面共9个螺丝，7大2小），取下摄像头和PCB板之间的数据线，重新拔插数次，使得连接两个部件的数据线能够跟两个部件紧密接触。
2、关于AR系列路由器VRP3.4版本AUX口拨号问题公告
AR系列路由器运行VRP3.4 Release0006（包含VRP3.4 Release 0006）之前版本时，存在通过AUX口不能拨号问题。AR系列路由器在拨号过程中会输出如下调试信息：
AHHS6201 DCC/8/debug:DCC: try to find routing to '110.95.244.253' on
interface Dialer0
AHHS6201 DCC/8/debug:DCC: the packet is interesting.
AHHS6201 DCC/8/debug:DCC: Vlink index is 0
AHHS6201 DCC/8/debug:DCC: the NextHop of the packet is not Broadcast
AHHS6201 DCC/8/debug:DCC: Found a dialer number
AHHS6201 DCC/8/debug:DCC: Try to find a free channel to dial '0251073
9' on the interface Dialer0
AHHS6201 DCC/8/debug:DCC: Dialing 02510739 on interface Async1/15 of
interface Dialer0
AHHS6201 DCC/8/debug:DCC: not set the queue! discard this packet
AHHS6201 DCC/8/debug:DCC: Receive MDM_DISC_IND
AHHS6201 DCC/8/debug:DCC: shutdown link, start enable timer
以后版本均已解决该问题。
3、MA5800/MA5801设备配置前运行config_ip.sh 安装的必要性
问题描述：在MA5800/MA5801的安装过程中，发现有些工程师没有按照手册资料的要求安装运行初始化配置文件config_ip.sh,导致一些无法预料的后果。
采取措施：在安装MA5800/5801时，配置系统前，请首先运行config_ip.sh,无论你采用带内网管还是带外网管。
4、中低端路由器VRP3.3版本在FR链路上跑MPLS L3VPN时出现业务不通的问题
问题描述： 中低端路由器所有VRP3.3版本在FR链路上跑MPLS L3VPN时业务可能出现业务不通。
采取措施：
(1)在FR链路上关闭快转规避此问题。
(2)升级到VRP3.4版本可以根本解决该问题。
5、中低端路由器在以太网口下配置Sub IP导致原有接口下的静态ARP配置丢失的问题
问题描述：中低端路由器VRP1.74-0110及以前版本，在以太网口所在网段下添加静态ARP表项，然后再在该以太网口下配置Sub IP，配置完Sub IP后发现原来配置在该以太网口同一网段下的静态ARP配置丢失。
采取措施：
(1)在配置时请先配置Sub IP，再配置静态ARP。
(2)升级到VRP1/74-0111及以后版本可以根本解决该问题。
二、学习案例
1、DHCP-Snooping特性使用不当造成PC机无法获取IP地址
DHCP(Dynamic Host Configuration Protocol)即动态主机配置协议，该协议采用Client-Server模型，是基于UDP层的协议，兼容并扩充了BOOTP(BOOTstrap Protocol)协议。DHCP Client采用知名端口号68，DHCP Server采用知名端口号67。当网络中有DHCP Relay设备时，DHCP的主要过程如下：
DHCP协议使用在PC机与DHCP Relay设备之间，当Client收到Relay设备转发的DHCP Ack报文后，对报文中提供的配置参数进行检查，同时进行配置，完成DHCP过程；如果Client收到Nak报文，则重新开始整个过程。
需要注意的是DHCP Relay设备回给Client的报文有可能是单播，也有可能是广播，这完全取决于Client是否将发出的 Discover报文里面的 Bootp flags 字段进行置位。如果该字段数值为1，则DHCP Relay将 Offer或者Ack/Nak报文广播给Client；反之，如果该字段数值为0，则DHCP Relay将 Offer或者Ack/Nak报文单播给Client。
以上，只是简单介绍客户端通过DHCP动态获取地址的过程，主要为了给DHCP-Snoooping这个交换机新增的特性做铺垫。从字面上看，DHCP-Snooping和IGMP-Snooping完成的功能类似，都是对特定报文进行侦听。
当交换机开启了DHCP-Snooping后，会对DHCP报文进行侦听，并可以从接收到的DHCP Request或DHCP Ack报文中提取并记录IP地址和MAC地址信息。另外，DHCP-Snooping允许将某个物理端口设置为信任端口或不信任端口。信任端口可以正常接收并转发DHCP Offer报文，而不信任端口会将接收到的DHCP Offer报文丢弃。这样，可以完成交换机对假冒DHCP Server的屏蔽作用，确保客户端从合法的DHCP Server获取IP地址。
下面通过一个故障实例，来介绍该功能的配置以及注意事项。
【故障现象及问题定位】
使用S3026G作为接入设备，接入设备汇聚到S3528P上，S3528P作为网络中的DHCP Relay设备，而DHCP Server接在S3026G下面。要求各个VLAN的PC机可以自动获取IP地址，同时希望能够屏蔽网络中的假冒DHCP Server。
组网图： 
首先，保证各个VLAN的PC机可以通过这台DHCP Server获取IP地址。然后，开启交换机的DHCP-Snooping功能，发现所有PC机均无法获取IP地址，说明DHCP-Snooping功能正常。为了让S3026G可以正常收发DHCP Offer报文，则在连接DHCP Server的端口0/23上配置dhcp-snooping trust，将该端口设置为信任端口，发现PC机还是无法获取IP地址。将PC机换至其它VLAN，仍然无法获取IP地址。而关闭S3026G的DHCP-Snooping功能后，故障消失。可以肯定是DHCP-Snooping的配置导致该故障。
虽然PC机和DHCP Server连接在同一台S3026G上，但是在整个DHCP过程中，作为DHCP Relay设备的S3528P对所有的DHCP报文都要进行一次转发。因此，采用分别对S3026G的上行端口的出、入方向进行镜像，并抓包分析原因。
通过抓包我们发现，S3026G的上行端口可以将DHCP Server发出的Offer报文透传给S3528P，也能收到S3528P所转发的Offer报文。但是，在0/1端口下的PC机上进行抓包时，却发现该PC机无法收到Offer报文，又由于Offer报文携带着Server分配的地址信息，因此造成PC机无法获取IP地址。
【解决方法】
将S3026G连接DHCP Relay的上行端口0/24也配置为信任端口，则S3026G可以正常收发从DS3528P转发来的DHCP Offer报文，保证客户端可以正常获取IP地址。
当与CAMS配合使用dot1x，并需要上传客户端动态获取的IP地址的时候，开启dot1x的交换机必须支持DHCP-Snooping特性。
2、VPN技术中的MTU问题
【问题简述】
在VPN技术中经常遇到隧道已经建立但是某些应用程序无法正常通讯的问题，一般所来是由于路径MTU不匹配的缘故，下面就其中的数据传输流程做一些分析，以说明遇到出现此类问题该如何解决。
【问题分析】
先从一个实验说起， 实验拓扑如下：
PC1-------VPN网关1―――――VPN网关2--------PC2
在上述组网中，VPN网关1和2之间建立了一条GRE隧道，PC1与PC2通过该GRE隧道互访。
这时，我们会发现，PC1在ping 1448的报文时，在PC2上抓包发现没有被分片，而ping 1449时，PC2上会发现PC1过来的报文已经被分片了。为什么呢？
PC1出来的IP报文长度为1448＋8（ICMP报头长）＋20（IP报头长），到达VPN网关1，VPN网关1发到GRE隧道口，封装GRE头（4字节），再加上外层IP头，到达VPN网关外层以太口，这时IP报文的长度已经变为：1448＋8＋20＋4＋20＝1500字节，刚好等于以太口的MTU，于是被顺利传送。而ping 1449时，到达外层以太口为1501字节，超出了1500的MTU，又因为报文DF位未置1，即可以分片，VPN网关于是将该报文分片发送出去。这就是我们所看到的现象。
在上述实验中，由于应用程序是ping，所以报文可以被分片，因此互通没有问题。但是如果是WEB访问等应用，则有些报文是不允许分片的，这样在外层以太口就会将超过1500的报文丢掉，导致无法通讯。
从上述实验可以看到，由于VPN会额外加入一些报文头，如果通讯双方的MTU不能随之改变的话，就容易产生不通的问题。
下面以HTTP为例，说明为何产生此问题并如何解决。
先看看HTTP为何无法像ICMP那样自动分片通讯。
假设PC1/2建立了HTTP连接后，PC2希望从PC1下载一个大的网页。PC2开始发送，其IP的DF位置1，不允许分片，IP报文长度为1500字节。到达VPN网关1的外网口后，VPN网关1发现其长度超过了1500个字节，于是将其丢弃，并给PC1发回一个目的地址不可达的ICMP信息，出错代码为”Fragmentation needed”，表示需要分片，但不允许分片，同时给出”MTU of next hop: 1500”。PC1接收到该消息后，又按照1500字节对外发送，又被丢弃，于是就形成了循环，无法通讯。
根据上述的分析，很容易得到如下解决方式，在VPN网关1的出接口设置MTU为1500－4－20＝1476，这样VPN网关1返回ICMP不可达消息时将给出”MTU of next hop: 1476”。PC2将以1476作为自己的最大MTU对外发送，到达VPN网关1，封装GRE和外层IP头后就不会超过1500而顺利发到对端。
这时仅解决了下载的问题，如果PC2需要将大文件上传到PC1，同样需要设置VPN网关2的出接口MTU值小于1476。
当然，还可以更改VPN网关1的出接口的TCP MSS数值，将其更改为1500-4-20-20（TCP头）=1456字节，也可保证HTTP等TCP应用顺利通过。但该情况仅适用于TCP应用。
上述解决方式同样适用于其他隧道技术，在L2TP、IPSEC等应用时可以相应的根据其包头数值设置MTU或MSS。
添加到百度搜藏
