CentOS 6环境下Oracle RAC 端口配置及防火墙规则

以下是针对 Oracle RAC（Linux/CentOS 6） 的端口配置、端口查看、防火墙规则配置的完整解决方案，按需求分模块说明： 一、Oracle RAC 必须开放的端口（核心） Oracle RAC 依赖多个端口实现节点间通信、数据库服务、集群管理等，需开放以下端口（所有节点均需配置）： 端口范围 / 号 用途说明 协议 备注 1521 Oracle 数据库监听端口（默认） TCP 客户端连接数据库的核心端口 1522 数据库 SCAN 监听备用端口（可选，建议开放） TCP 高可用场景备用 4899 Oracle Cluster Synchronization Service (CSS) TCP/UDP 集群同步服务（关键，节点间通信） 5000-5019 Oracle RAC  interconnect 端口（私网） TCP/UDP 节点间缓存融合、数据同步（私网必开） 6200-6203 Oracle Cluster Ready Services (CRS) TCP/UDP 集群就绪服务（集群管理核心） 2483-2484 Oracle Net Listener 备用端口 TCP 监听备用（可选，建议开放） 1158 Enterprise Manager (EM) 端口 TCP 网格控制（若使用 EM 需开放） 5520-5539 Oracle ASM 实例端口 TCP/UDP 自动存储管理（ASM 环境必开） 3938 Oracle Notification Service (ONS) TCP/UDP 服务通知（RAC 高可用依赖） 22 SSH 端口 TCP 节点间免密登录、集群部署 / 维护必开 注意： 私网端口（如 5000-5019）仅需在 RAC 私有网络开放，公网可屏蔽； 若修改过默认端口（如监听端口改为 1523），需同步开放修改后的端口； 所有端口需在 防火墙（iptables）中开放，且确保 SELinux 未拦截（建议临时关闭 SELinux 测试）。 二、Linux 查看当前使用的端口及对应程序 CentOS 6 需通过 netstat 或 lsof 工具查看（默认已安装），以下是常用命令： 1. 查看所有监听端口及对应程序（推荐） # 查看 TCP 端口（-t）、监听状态（-l）、程序名（-p）、数字端口（-n） netstat -t……

锐捷RSR20-14E路由器MAC绑定冲突问题

一、故障现象描述 我司RSR20-14E路由器作为网点接入路由器，客户使用mac绑定进行哑终端放通，在配置过程中出现了mac绑定冲突的情况。如下图所示： 二、故障排查分析 从log看是因为mac的hash冲突导致，有两种情形：一是地址表满，二是地址表未满，但发生hash冲突。 通过show某个网点的地址表，环境中总共有130个mac地址，而整个mac表容量是8192，说明是属于上述情形2的hash冲突情况。了解到最近在两个站点出现过两次此情况，并且均已通过修改终端的mac地址解决。 不同的交换芯片具有不同的MAC地址容量，即所谓的MAC地址表大小。对于我们RSR20-14F使用的是xxx交换芯片，它的MAC容量是8K，即8192个。 我们使用的就是缺省的MAC+VID的hash算法，要修改，也只能在初始化时修改，在使用过程中不可能去修改该配置。故客户现场MAC Hash冲突的问题无法通过此方法解决。 三、故障根因说明 由于MAC地址表发生hash冲突导致 四、故障解决方案 修改终端的MAC地址，或者调整端口划分的VLAN来规避解决。

锐捷RSR50-X 设备重启后CPOS接口协议全down

一、故障现象描述 RSR50-X 设备重启后CPOS接口协议全down 场景拓扑 二、故障排查分析 通过show interface serial xx查看接口5分钟input数据为0，input errors和CRC再持续增长 查看对应接口配置的是CRC 32，而且和重启前的配置一致 通过在接口下依次执行crc 16、crc 32恢复 三、故障根因说明 经过代码走查及现场提供的log信息分析，定位原因为CPOS配置了E1F（CE1）并配置校验为crc 32后，如果设备重启或CPOS子卡重启将会导致crc 32无法正常下发配置，Serial通道配置会恢复成默认配置crc 16。该场景下两端crc校验配置长度配置不一致导致校验不过产生协议down问题。 四、故障解决方案 临时恢复方案：可通过依次执行crc 16、crc 32恢复 或 使用默认配置crc 16 解决方案：升级设备软件版本到RSR50-X_RGOS 10.4(3b137)p9 Release(238074)及以上版本解决

锐捷RSR7708 MP口直连不通问题

一、故障现象描述 RSR7708路由器和下联单位对接MP接口直连不通 二、故障排查分析 1.现场的故障情况为核心和分支直连的multilink 26号接口直连不通，查看线卡流表显示收发正常，收集了以下信息： 通过上面的log发现总部发出的icmp echo报文能在分支端的主控到CPOS卡并且建立数据流，说明数据流已经到了快转框架层面，但是快转统计并没有统计到丢包的情况，是由于分支端CPOS线卡EFB数量异常导致。如下图所示： 可以看到线卡上EFB数量较少，由于没有业务运行，判断是EFB被异常占有了，触发条件是异常报文改写内存导致快转TX接口不匹配，从而EFB减少，且报文不能正常转发出去。最终现场执行了如下两个动作： 1.重新配置multilink 26接口，业务没有恢复 2.重置CPOS线卡，直连能够互通，业务恢复。 从现场两个动作看，现场分支端CPOS线卡处于异常状态，并且收到大量异常报文导致的，如下图所示： 三、故障根因说明 现场1/2线卡EFB内存出现泄露，导致无法及时处理加密机发送报文，导致大量报文被识别为错误帧导致直连ping不通的情况。 四、故障解决方案 由于本次故障原因主要是由于CPOS线卡收到大量的异常报文，导致线卡状态出现异常，报文无法正常地从接口发出导致,因此现场可以通过升级3b95版本来解决CPOS线卡异常问题。

锐捷RSR20-14F HSIC-2E1/CE1 线卡对接华三路由器，对端接口每4小时down一次

一、故障现象描述 RSR20-14F使用HSIC-2E1/CE1与华三设备对接，每隔4小时华三接口会down一次，需要重启华三设备才能恢复。 场景拓扑 RSR20-14F——E1线路——华三路由器 二、故障排查分析 步骤一：华三工程师对接口down时的PPP协商进行抓包和DEBUG，答复华三设备最大只能接收length=259字节的协商报文，由于收到了我司超度超259字节的报文，导致板卡处理异常，需要重启板卡才能恢复。 步骤二：分析华三侧抓包结果，报文code值为Protocol-Reject(协议拒绝)，该报文一定是我司设备接收到了某些承载在PPP之上的协议报文，但我司不支持，所以发送的Protocol-Reject消息，Protocol-Reject消息里携带了所有不支持的报文内容。 步骤三：协调本端开启DEBUG调试。 end terminal no monitor con logging file flash:log 6000000 7 no log con end debug ppp authentication debug ppp compression debug ppp error debug ppp event debug ppp negotiation debug ppp packet debug ppp ref 等待故障出现后 undeb all show log more log*.txt //log文件可以dir看到 分析debug日志发现：我司设备接连收到了华三侧发送的三个Type=0x31，Length=255字节的协商报文，本端不支持type=0x31标识的上层协议，所以回复了Protocol-Reject，其中包含了整个报文信息，所以长度超过了259字节。 步骤四：核实后，发现华三E1接口默认开启了LLDP协议，但我司设备不支持E1接口配置LLDP，所以回复了Protocol-Reject通知对端停止发送该类型的协商报文，由于对端软件问题，无法处理超259字节的协商包，所以导致对端板卡异常，接口down。 三、故障根因说明 根因定位为由于友商问题。 四、故障解决方案 非我司问题，友商优化版本或者升级版本解决。

锐捷RSR10-X HSIC-2E1/CE1接口协议不UP，CRC计数增加

一、故障现象描述 RSR10-X-07使用HSIC-2E1/CE1对接省公司CPOS，E1接口物理UP，协议不UP，且接口下input方向有大量CRC增加。 场景拓扑 二、故障排查分析 先通过故障现象分析：   接口物理状态UP，说明线缆能正常接收到对端电信号；接口协议down，input方向存在大量CRC统计，一般是以下几个原因： E1线缆质量或兼容性问题，导致接收到大量损坏的报文。（我司E1线缆时序与友商不一样，不兼容友商E1线缆） 模块软硬件问题，导致无法正常处理报文。 E1两端协商参数不一致：如帧校验模式、封装时隙、CRC校验、时钟源等。 进行硬件自环，排查是否是模块或线缆问题。   硬件自环之后协议UP，接口收发包一致，判断模块软硬件正常，且E1线缆正常。怀疑双方协商参数不一致。 协商双方的CRC校验方式、时钟源不一致，也会导致接口下CRC增加，所以尝试更改参数测试，但现象依旧。 协调客户获取对端华三设备CPOS接口配置参数。   发现华三设备使用的时隙是1-31，判断客户现网实际对接的是CE1而不是E1，所以在我司设备上将E1通道化成CE1，并封装时隙1-31，操作之后发现接口协议依旧为down。 列出CE1对接需要的参数，一一排除：   封装模式：CE1成帧模式   封装时隙：1-31   帧校验格式：no-crc4   idle code：0x7e   line code：hdb3   时钟源：外部时钟   CRC校验：CRC16   发现华三默认使用no-crc4的帧校验格式。修改我司帧校验格式之后接口协议UP，测试与对端通信正常。 三、故障根因说明 故障的根本原因是现场人员提供的对接模式错误，参数不全。 四、故障解决方案 修改对接参数解决。

锐捷RSR77X HA场景LACP备机无法正常UP

一、故障现象描述 RSR77-X路由器HA方案出口与运营商设备建立动态LACP，完成配置后，发现HA备机所在的链路LACP状态异常。 二、故障排查分析 检查配置，未发现异常，HA两台配置都一致。 检查LACP的收发包统计，发现备机的3/1/1接口rx方向统计为0，说明未收到对方发送过来的报文。 三、故障根因说明   由于运营商中间线路问题，导致无法收到对端发包，导致LACP该接口状态异常。 四、故障解决方案 运营商修复好链路后解决。

锐捷RSR30XA 光口突然起不来

一、故障现象描述 RSR30-XA的T0/5光口突然起不来 场景拓扑 二、故障排查分析 检查光模块识别情况。锐捷XG-LR-SM1310光模块插入T0/5口进行验证，通过show int ten0/5 transceiver命令发现设备可以正常获取到光模块SN序列号等参数，说明设备及光模块的I2C通路正常。 检查收发光。通过show int ten0/5 transceiver diag命令发现光模块电气参数中，光模块温度、电压均正常，RX方向的功率正常，说明光模块以及设备收光功能正常，可以排除环境问题。但可以看到TX方向的Bias电流以及发光功率已经很小，出现了告警，说明光模块或设备的发光功能出现了问题。 此时尚无法判断是设备故障还是光模块故障，故再次将相同光模块切换到0/8口进行测试，发现8口的Bias电流和发光都正常，且接口可以如图正常up，故排除光模块问题，定位是设备的T0/5接口出现异常。 三、故障根因说明 设备的T0/5接口出现硬件故障，导致TX方向的Bias电流以及发光功率出现异常。 四、故障解决方案 返修设备。

锐捷RSR10X 光口无法UP

一、故障现象描述 RSR10-X光口起不来 场景拓扑 二、故障排查分析 检查光衰。发现如下图所示收发光均正常，运营商检查运营商对端的收光也正常。 替换设备是否运营商问题。将同一个模块和同一对光纤插入另一个同型号同版本的RSR10-X路由器，可以正常起来。故排除运营商问题。 检查路由器本身设备有问题。通过一根光纤自环连接光模块的两个口，接口可以正常up。 检查接口配置是否有误。RSR10-X的光口属于固化光口，不需要配置光电切换命令。通过show run int gi0/2检查配置发现路由器强制了速率和双工，强制速率为千兆。而另一台可以起来的RSR10-X-07配置了强制速率为百兆。通过show int gi0/2 transceiver发现，光模块本身就是千兆光模块。怀疑速率有误，故尝试强制速率为100Mbps，接口恢复正常。 三、故障根因说明 由于强制速率为百兆后恢复正常，判断运营商侧的光口为百兆，接口两端速率不一致会导致接口down。 四、故障解决方案 配置接口速率为百兆 conf int Gi0/2 speed 100 end wr

锐捷设备电口不UP问题处理流程图