设备运行概览设备状态中CPU、内存、并发连接数喝新建连接数规律性到0,业务没有影响 1、查看图形是30分钟间隔掉0，设备是集群模式部署，其中一台设备显示有问题 2、检查设备有配置NTP时间同步，间隔是30分钟同步自动同步，沟通关闭NTP同步功能后，故障消失 3、可以判断是NTP之间同步或者设备之间同步有问题，检查集群配置，当前有问题的设备集群角色是被控，应用组生效 在当前设备上，而集群主控设备是没有业务地址下发（网口没有配置静态IP地址，只有浮动IP），去NTP服务器因此没法走 业务口出去，导致主控NTP同步不了时间，也没法向被控设备同步准确的时间 设备之间时间同步问题、导致图形数据计算出问题 方案1（一旦切换还有问题）：切换集群主备控角色（不影响业务），让主控角色是跟应用组生效设备在同一台，确保与NTP能交互 方案2（需要改动接口配置新增地址，不推荐）：配置静态IP地址，这样两台设备都可以通过业务口去与NTP服务器通信 方案3（推荐方案，改动最小）：配置32位明细路由，去NTP服务器地址下一跳走管理口网关，两台设备也能与NTP通信，目前使用此方案解决了问题 方案4（根据需求）：关闭NTP功能 与用户沟通即可，方案1、3/4不影响业务 否    

SJJ国密设备重启后，提示加密错误，产生随机数错误。   1、确认设备型号，如果是SJJ国密设备，重启后，密钥检测页面会提示算法异常，需要重新登录加密卡后才能使用随机数功能，影响业务。 2、确保加密卡插在设备上，然后在如图登录页面登录即可。密码默认是123456或12345678。如果客户改过密码则是修改之后的密码。   需要重新登录加密卡          

         双机主备或者集群状态下，两种故障现象，一个是提交配置的时候页面报错设备与主控通讯连接超时。另外一种是客户反馈双机状态异常，一台上看着状态正常，另外一台上看两台都是黄色未知的状态。 现象一   现象二      目前遇到过的相关问题大概可以分为两个场景，下面分别进行说明，具体解决方案，在解决方案里面根据场景情况对号入座。   场景一           44325端口有一台或者两台都没有监听的情况   情况1：           打过老的护网补丁包，导致设备后台没有监听44325端口，查看/etc/sinfor/ad/httpd.conf代码里面44325相关的代码被注释掉了，导致端口无法监听。     情况2:         /etc/sinfor/ad/httpd.conf配置文件里面44325相关的代码没有被注释，但是同样44325端口没有被监听。这种一般重启web服务可以恢复正常，对外的答复是设备会自动校验设备证书，小概率在校验的时候出现异常导致端口没有监听。   场景二         44325端口两台都是监听的状态，但是报错与主控通讯超时     情况1：         界面提交配置的时候，报错与主控通讯超时，但是44325端口是监听的，这种情况查看cluster2进程一直在重启     情况2：         界面提交配置的时候，报错与主控通讯超时，但是44325端口是监听的，cluster2进程也没有不停的重启，但是提交配置的时候只有在主机上提交的时候会报错，在备机上提交就不报错       AD双机环境，存在主控和备控的概念，这两个角色在组建双机的时候就已经决定，没有出现重组或者设备故障等情况一般不会变，和界面的主机备机角色不一样。在提交配置的时候配置都需要先下发到主控设备上，先在主控设备生效，然后同步到被控设备。44325是apache2的监听端口，配置下发和控制台状态获取都和这个相关，当这个端口没有监听或者通讯出现异常的时候，双机会获取对端的状态异常，或者配置下发同步异常。所以会报错提示设备与主控通讯超时和双机状态显示黄色的未知。 场景一，情况1的解决方案： 方案1：后台使用命令回滚掉老的护网补丁，然后重新打上最新的护网补丁包。（补丁回滚命令找专家获取） 方案2：后台手动修改配置文件，把被注释掉的44325相关的代码，去掉注释。然后重启web服务恢复正常 注意：去掉注释的时候，首先代码里面，四行带44325的前面去掉前面的#好，变成下图的样子。   另外还有两段virtualhost开头的，带44325的代码，两个virtualhost之间所有的#好都要去掉。   修改后重启web_service服务 /etc/init.d/web_service restart 注意：       双机场景下，两台设备都检查下httpd.conf和httpd.conf.tpl文件都要修改，tpl是模板，模板如果注释掉没有修改，则容易覆盖掉，另外修改文件之前记得备份文件   场景一，情况2的解决方案：       方案一：临时解决方案，重启控制台服务就可以恢复，/etc/init.d/web_service restart，但是这个只是临时解决方案       方案二：永久解决方案，推荐升级到7.0.26r2版本，然后打上SP_AD_UPDATE_03_7026R2_746R2，升级版本需要重启设备影响业务，打包会重启核心进程，也会影响业务   场景二，情况1的解决方案：       后台cat /etc/sinfor/ad/cluster/cluster_manage.conf分别查看两台设备心跳口的配置，发现有一台设备上，备份心跳口的配置上没有ip地址     检查备机的配置确实没有备份心跳口的ip地址配置，但是当前界面因为双机服务异常无法手动配置，界面报错。    后台手动修改配置文件后恢复正常（主机和备机修改为一样的，备机上修改需要添加filesum -m）   ps:后台手动修改配置文件，修改之前找专家或者研发评估，修改之前记得备份文件   场景二，情况2的解决方案       方案1：临时方案，到备机上修改提交配置       方案2：临时方案，在备机后台执行cluster_oam_tool CLUSTER_CONFIG_M OAM_MSG_RORCE_FAILOVER_DEV "" 这条命令会让备机主控变成备机被控，主机上可以正常操作下发配置。（不推荐）       方案3：最终解决方案，升级到7.0.26r2版本（推荐）        1、涉及到升级和打补丁的都影响业务，注意沟通好        2、需要后台操作修改文件的都记得要先备份好文件        3、重启控制台服务的不影响业务   双机常见端口和作用  3128                 //代理通信端口22345                  //ssh端口，通过心跳口登陆备机sshd7710                 //心跳单播端口7711              //心跳组播端口42655            //配置同步端口42530             //控制连接端口3879            //集群组建单播端口7967            //脑裂检测组播端口11223         //双机组建组播端口44325                //adapi监听端口，apache监听为44325443          //web控制台https默认端口8719           //会话同步服务端端口      

客户反馈AD上只配置了cname，windows电脑使用nslookup解析不出来。     1、原因是windows nslookup的逻辑问题，需要对应的cname域名有A记录解析的时候，才会都显示出来。 2、linux 的终端 dig测试，可以直接显示cname，或者可以抓包确认AD是否有返回cname。          

AD集群部署，节点AD打开集群界面提示设备与主控通讯连接超时报错   1、集群和主备都会使用到44325端口通讯 2、进入主备设备检测44325端口是否有监听 3、如果没有监听可以手动重启web_service服务，重启后再检查44325端口是否有监听 4、确认端口监听正常后再确认是否还有报错 AD每一个月会检测控制台证书是否过期，会影响到44325端口。 检测证书是否过期导致44325端口没有拉起来时会出现上述报错 临时解决方案手动重启web_service服务彻底解决方案需要给设备打SP_AD_UPDATE_03_7026R2_746R2补丁包 打补丁包会影响业务5分钟 否      

AD设备配置的虚拟服务，启用优化策略插入了X-Forwarded-For传递客户端IP到节点服务器，但发现服务器收到的X-Forwarded-For内容跟对应的客户端IP不相符。   1、查看HTTP虚拟服务，关联的优化策略配置如下图。   2、检查虚拟服务没有启用SNAT配置，抓取VS后端数据包分析，发现前端客户端IP是175.152.xx，但是插入的XFF值却是125.70.x.x 两者理论上应该是一样的，但这里不相符。   3、经过深入分析前后端数据发现匹配到后端的同一条TCP流，检查配置发现VS关联的TCP策略开启了连接池功能。 连接池功能原理: 配置启用或禁用连接复用功能，启用后将AD与后端节点的TCP空闲连接保存在池中，当有请求来时，直接复用池中的TCP连接访问节点，节省创建和销毁连接的过程，进而提升性能。 该种场景下，需要重新新建个TCP策略，禁用TCP连接池功能，再关联到虚拟服务里面即可。          

AD设备6.4版本七层虚拟服务发布了网站业务，智能机器人聊天时候，提出问题给机器人，回答显示出现异常，内容是一段一段文字显示效果；正常情况下直接访问服务器是逐字逐行回显效果   1、七层虚拟服务改为四层TCP类型虚拟服务，通过负载访问正常，负载到服务器中间没有安全设备 2、分析客户端与AD、AD与服务器交互数据包，发现服务器应答的多个小包内容被AD合并为大包发给客户端，问题得到定位 6.x老版本架构七层HTTP/HTTPS类型虚拟服务为应用层代理模式，设备默认对服务器返回的多个小包数据会进行合并为大包后返回客户端，较少客户端与AD数据包数量，增加优化传输效率，目前软件版本无法调整；对于当前场景下，最终导致业务客户端聊天窗口返回内容显示不是逐字打印效果，而是一段内容一次回显。 当前6.4版本无法支持参数调整，需要AD使用7.x架构软件版本，默认不会将多个小包进行合并转发客户端，可以实现逐包转发，实现动态效果显示。 无 否 备注：若AD设备使用7.x版本还有此类现象问题，需要注意AD与服务器之间是否有安全设备 目前有遇到还有安全设备合并数据包场景，例如waf或者ips会有内容识别功能，也会将服务器小包内容合并为大包功能，导致同样的问题。  

调整设备时区操作方式       1、zdump /usr/share/zoneinfo/Asia/Shanghai校验客户需要修改之后的时区文件是否正常（如果发现当前版本没有对应的时区，可以从7028版本上面拷贝一份过来、路径要一致/usr/share/zoneinfo/目录下） 2、删除旧的软连接rm /etc/sinfor/ad/localtime（7028是/etc/localtime） 3、修改时区软链接ln -s /usr/share/zoneinfo/Asia/Shanghai /etc/sinfor/ad/localtime（7028是/etc/localtime） ls -lht /etc/sinfor/ad/localtime（7028是/etc/localtime）检查软链接是否正常 4、编辑/etc/timezone文件，修改时区成需要的时区 5、使用date命令检查软件时间是否正常 6、如果操作完毕之后前台时间看还是不对，则需要重启adapi进程（操作不影响业务） /etc/init.d/adapi restart   设备升级之后修改的文件会被覆盖，需要重新操作      

打补丁包报错网络错误，页面卡住，刷新页面之后重新上传补丁包报错API文件缓存-无法删除正在被使用的文件资源 API文件缓存-无法删除正在被使用的文件资源     重启web_service服务之后重新打包 /etc/init.d/web_service restart ps:重启控制台服务不影响业务          

1、aclog分区满 2、配置文件太大   1、反馈设备控制台页面异常，后台查看df -h 发现aclog分区满了。 2、使用du -sh /aclog/* |sort -hr 发现主要是黑匣子占用。 3、查看黑匣子里面文件，主要是配置文件过大。 4、这种几百M的配置文件，是因为里面包含了补丁包导致，可以调整配置去掉包含补丁包。 在/etc/sinfor/backup_exclude.ad 里面加一行sinfor/service_pack ，排除这个目录。 5、删除几个最早的黑匣子里的配置文件，释放空间。         在/etc/sinfor/backup_exclude.ad 里面加一行sinfor/service_pack ，排除这个目录          

客户通过虚拟服务发布内网业务，往业务主机上传大文件时会异常   1、测试内网上传大文件正常 2、虚拟服务是http服务，改成tcp服务后正常，初步判断和AD有关 3、测试http服务时，上传小文件正常，上传大文件时大概在120s左右就开始异常了 4、排查是启用了http防护策略中，配置了请求超时时间120s；也就是上传这个请求只能在120s内交互完，超时后ad会拦截断开 防护策略配置了请求超时时间120s，导致文件上传的时间限制在120s内 去掉http防护策略或者增大防护策略的超时时间 无 否      

AD关闭了全局负载的dns服务器后，wan口的53端口仍然开放，并且配置在wan口的IP可以做dns解析 无 1、检查全局负载开启了dns服务器，关闭之后再次检查，wan口的53端口仍然开放，并且可以直接做dns解析；2、检查dns代理开启了全部dns请求，开起了所有网段代理，使用实验环境测试将所有网段改为部分网段，配置内网的网段后，wan口的53端口便会关闭且不会进行dns代理； 选择所有网段： 只选择内网网段： dns代理了全部网段的dns请求 解决办法：方法一：AD上写acl，拒绝wan口进来的udp 53；方法二（推荐）：当前dns代理目标范围为全部dns请求时候，AD的dns代理网段所有网段改为内网用户网段即可； dns代理 否 dns代理配置时建议代理网段选择部分网段，填写内网网段，不要选择代理全部网段      

两台以上AD设备组集群的环境下，手动切换主控角色时，发现主控只会在其中两台设备上生效，另外灵台不会出现，并且禁用的成员设备也能变为主控角色 无 主控切换只在两台设备上切换属于正常现象，默认情况下创建集群的设备会被选举成主控，第一个加入集群的设备会被选举成备控， 切换会在创建集群的设备和第一个加入集群的设备上进行切换，且切换只根据健康状态作为标准，即使将设备禁用但还是可以变为主控角色，但应用组不会生效在禁用的设备上。 非设备问题   否 集群模式中主控角色业务承载没有关联性，主控角色只是做配置集中下发功能。 关于禁用的设备还能成为主控角色（7.0.28及以前），后续版本已考虑改进    

配置了根据域名选路的智能路由策略，把这条根据域名选路禁用之后就匹配不上路由    1、通过进行路由测试查看，在禁用了这条根据域名选路的智能路由策略之后，路由测试无法匹配上路由，，提示路由测试失败，没有与测试条件匹配的规则 2、通过检查智能路由的配置，发现禁止了default的默认选路策略，default前面其他路由策略中有配置流量传输标识TOS功能，导致路由策略无法匹配上 由于配置了流量传输标识，且关闭了默认的路由选路策略，导致数据没有路由可以匹配得上 通过开启默认的路由选路策略或者调整中间所有ip所有协议的智能路由策略的流量传输标识为默认值0即可 编辑智能路由会导致智能路由会话保持清除，已有链接会话不影响，重要业务建议窗口期间操作 否 流量传输标识默认情况下是不会改动，此功能使用的场景需要结合下联其他设备给流量打上TOS标识后，AD根据这个TOS标识识别选路。      

现象1：用户控制台打包提示系统升级失败[执行脚本 do_update.sh失败。升级失败     现象2：纪元平台巡检工具打包提示   后台执行 sfcli list sys maintenance-mode提示密码未及时更新 由于admin账号长时间没有更新，密码过期了，需要web界面重置admin密码 修改admin账号密码后正常 备注：如果7.0.21及以上版本，通过巡检工具打包，则ssh密码也要设置为admin账号的密码一致 无 否        

       1、配置了全局负载域名无法解析         1、检查域名解析配置没有问题       2、dns指像设备监听地址也无法解析，虚拟ip池状态正常       3、抓包查看设备收到了包，没有应答       4、检查本地服务器发现有个服务启用和禁用，客户配置选择的禁用，改成启用就可以了       7028版本在本地服务器里面新增了一个服务的启用和禁用，如果是禁用的状态，整个本地全局负载模块不提供服务            本地服务器里面勾选启用就行了       不影响业务        

双向地址转换不生效   1、用户双向地址配置正常，源目地址转的匹配次数也有、 2、ad本身可以telnet通，但是ad的lan口抓不到访问服务器的数据包 3、后面抓包发现是ad的wan口区访问服务器，设备静态路由配置正常，路由追踪也是显示lan口     ad路由优先级，用户勾选了智能路由优先级高于主路由表 取消勾选智能路由优先级高于主路由表 AD路由优先级配置默认是没有勾选【优先级高于主路由表】选项，效果是 静态路由优先于智能路由，注意沟通实际业务场景，如果要静态路由优先，则这里无需勾选 否        

在AD上生成证书请求，在CFCA申请证书和私钥后，导入私钥提示不支持的证书格式 不支持的证书格式 用notepad打开私钥，发现私钥只有一行 私钥是base64编码所以要每64位字符换一行 私钥每64个字符换一行，然后保存私钥文件再导入 无 无 无      

XXX银行人行征信业务国密改造，要求对业务做基于URI不同调度到不同节点池的前置调度策略，虚拟服务配置加密策略+客户端认证，业务前置机对AD的虚拟服务发起业务访问，前置机到AD的虚拟服务建立一个TCP会话，发起3次不同URI的请求，根据URI的前置调度策略访问到后端的两个节点池，在此场景下业务访问出现超时，导致访问失败，具体拓扑如下图： 1、客户业务检测系统报告存在访问超时 APM指标名称： 接口平均响应时间 所属应用： credit-core  告警时间： 2024-07-19 20:54  告警内容：XXXXXX系统在最近5分钟内有1分钟 接口平均响应时间 大于等于 3000 毫秒 详情数据：  16165毫秒 | 2次 | 202407192053  可疑点 : 2024-07-19 20:53:14时刻, credit-core调用XXXXXXuri 耗时 31545毫秒 请求路径 :xxxx   2、抓包显示业务请求超时31s   1、抓取前端业务访问包发现整体业务访问过程一个TCP会话发起了三次不同的URI请求。 2、抓取后端调度业务流量发现后端请求每次不同的URI请求发起不同节点池的请求 3、抓包发现每次前置机发起的URI请求，切换不同节点池时设备都会发起一次rst，告知服务端进行重置会话，发现在第三次重复对第一个节点请求时会出现会话超时的问题 老版本M746之前AD前端一个会话进行多次post请求时，后端调度到不同节点，会将上一个链接正常发送fin断开，但是只要是服务器端在我们发送fin之后在回应数据，AD会直接发送rst的数据包，释放端口，M7.4.6版本针对此问题进行了解决，AD在发送fin之后无论服务器回复什么都不会直接rst，而是会等待超时时间，正常等待time_wait. 1、临时解决方案（1）TCP七层开启连接池，超时时间填写120s（根据抓包看60s无返回人行服务器会直接断开连接，具体根据业务评估），开启此功能可以保证因为uri更换节点池之后不会将原来的会话断开，进行端口释放，这样在进行新的post请求时会重新启用端口注意：此功能开启之后需要根据业务量评估时间，如果客户业务量过大，可能会导致端口未来的及释放，从而导致端口被消耗完. 2、永久解决方案升级到M746版本，启用TCP策略配置关闭连接之后超时时间为120s（根据业务量评估） 临时解决方案需要注意评估客户业务量防止出现业务端口冲突问题 永久解决方案升级版本会重启设备影响业务          

打完SP_AD_PORT_SHRINK 补丁包后，WEB控制台的WAN口远程维护不能选择永久生效，如下图，导致旁路部署的设备就无法从WAN口来管理设备。   该补丁包SP_AD_PORT_SHRINK 就是为了提升安全性加固，故意将永久生效的功能禁用了。 1、 回滚该补丁包，命令是path_rollback.sh   缺点：AD回滚补丁包每次只能回滚最近的补丁包，所以如果这个补丁包在中间的话，就需要回滚很多次比较麻烦。   2、通过命令行去关闭，参考如下。   PS：命令行编辑完成后， 记得不要去web控制台再去编辑，否则会覆盖。 无