P局点反馈，核心网升级后，UE启动下行业务，S1频繁闪断重建，SCTP也在频繁闪断。UE随即释放。
【关键字】S1链路，闪断，下行业务
【版本信息】非代码缺陷，与版本无关。
【定位思路分析】单独针对S1链路的异常，常见的原因有如下几点：
1. eNodeB ID 配置和其它eNodeB 冲突导致S1闪断。
2. 当前站点无任何小区配置，S1不触发建立。
3. PLMN配置和核心网不一致，导致S1出现闪断。
4. 传输链路异常，比如拥塞、带宽不足，未配置优先级，导致心跳包丢包，使得S1出现闪断。
如果前方反馈问题的信息无误，1、2、3导致的原因可以排除，因为前方只有做下行流量业务时才会出现，且SCTP也在闪断。
【定位信息】SCTP ,S1 跟踪
【定位过程】从前方反馈的问题现象：不做业务时S1没有闪断现象，只在做业务时会出现。基本可以锁定时传输链路的相关问题。从S1闪断的触发因素开始排查：
[attach]4087[/attach]从SCTP信令着手分析，主要原因是由于核心网下发了SCTP_ABORT。核心网反馈发送SCTP_ABORT的原因是，没有收到HERTBERT，超时发送ABORT。但从eNodeB跟踪分析上看，大部分时间eNB是发出去了HEARTBEAT，却没有收到核心网的ACK。那么原因可能有2.
1. 核心网升级后出现什么问题导致核心网不回复ACK。
2. 中间传输链路将信令报文丢弃。
由于问题反馈时强调是核心网升级导致，初期怀疑是由于1导致，期望能够证明是核心网问题。但是eNB的跟踪不足以说明是没有收到核心网的ACK这一结论。究竟是哪一测的问题，有个非常直接的方法，即在中间传输网络抓包分析，看HARTBEAT报文的传输情况，是eNB没发还是没有收到回复？但前方反馈传输链路抓包存在一定的难度。于是暂时跳过原因1的问题的求证，暂时不认为是核心网导致的不回复，直接进行问题2的排查。
请前方做如下测试，20M小区满流量做业务时出现闪断，逐渐减小灌包吞吐量，观察断链现象。前方反馈一个重要信息，流量减小到60M时，S1闪断现象明显减少，几乎不闪断。闪断现象和业务流量强相关，可以基本锁定为传输链路和传输配置的问题。
请前方核查整个传输链路是否存在100M配置且没有配置优先级，这肯定会导致反馈的如下结果。前方反馈当前传输使用千兆传输。
那么使用在基站上的配置出现了百兆配置，请前方执行DSP ETHPORT。果然发现配置的是100M、全双工。
如下是前方的错误配置：
SET ETHPORT: CN=0, SRN=0, SN=7, PN=0, PA=COPPER, MTU=1500, SPEED=100M, DUPLEX=FULL, ARPPROXY=DISABLE, FC=OPEN, FERAT=10, FERDT=8;
修改为千兆全双工后，问题消失。
前方立刻产生两个疑问：
1. 为什么100M场景即使丢包也应该先丢数据包，后丢信令包，为什么会存在问题？
2. 为什么这样的丢包场景没有触发任何告警？
经过对基站日志的排查，在基站测发现了很多CRC错的包。也就是包的异常发生在基站侧。打印对端交换机的协商结果。发现交换机协商成了半双工。
Port hardware type is 1000_BASE_T
100Mbps-speed mode, half-duplex mode
Link speed type is autonegotiation, link duplex type is autonegotiation
Flow-control is not enabled
协商成半双工是因为当前基站设置全双工而交换机设置为1000M自协商。出于兼容性考虑，会协商成半双工，这是数通产品的共性。当链路上出现全双工和半双工对接的情况，流量大时出现包冲突，产生错包被丢弃，影响业务，目前HERT平台的单板几乎不支持半双工模式，所以不能这样配置。
这样如上两个疑问可以解释了：
1. 是由于半双工模式导致的错包，这个和流控或优先级无关，会随机错包。
2. 虽然发生了错包，但量还没有达到触发告警的门限，所以没有告警。只是因为信令包错了，才导致表象很严重。
如下为配置成不同模式的协商结果表，需要高度关注，端口1和端口2是指数通设备的一端，如基站主控和交换机之间，可以互换。
表1 ：电口不同设置协商结果
测试条件 | 协商结果 | ||
端口1 | 端口2 | 端口1 | 端口2 |
自协商 | 自协商 | UP/1000M/FULL | UP/1000M/FULL |
自协商 | 100M全双工 | UP/100M/HALF | UP/100M/FULL |
自协商 | 10M全双工 | UP/10M/HALF | UP/10M/FULL |
100M全双工 | 100M全双工 | UP/100M/FULL | UP/100M/FULL |
100M全双工 | 10M全双工 | down | UP/10M/FULL |
10M全双工 | 10M全双工 | UP/10M/FULL | UP/10M/FULL |
表2 ：光口不同设置的协商结果
测试条件 | 协商结果 | ||
端口1 | 端口2 | 端口1 | 端口2 |
100M FULL | 100M FULL | UP | UP |
100M FULL | 1000M FULL | UP | DOWN |
100M FULL | 1000M AUTO | DOWN | DOWN |
1000M FULL | 100M FULL | DOWN | UP |
1000M FULL | 1000M FULL | UP | UP |
1000M FULL | 1000M AUTO | UP | DOWN |
1000M AUTO | 100M FULL | DOWN | DOWN |
1000M AUTO | 1000M FULL | DOWN | UP |
1000M AUTO | 1000M AUTO | UP | UP |
请注意：一线使用的是电口，一线的场景是如上底纹为黄色的列表，协商成了半双工。
【问题根因】前方误将ETHPORT配置成了100M，全双工。导致同对端1000M自协商交换设备协商成半双工。
【建议与总结】外场组网时配置传输链路设置要充分考虑一致性。
所谓一致的意思是：
1. 若链路一端配置为自协商模式，另一端也需要配置为自协商模式。
2. 若链路一端配置为非自协商固定速率模式，另一端也需要配置为非自协商且速率一致的固定模式，
批注：这个案例强调写了核心网升级，是因为在定位过程中一直关注于一线反馈的核心网升级后出现问题这个信息，走了一些弯路。实际上一线的站点也是刚配置起来。建议反馈问题时尽可能准确也尽量帮忙总部摸清规律，定位问题时也尽量跳出固定模式。
| 欢迎光临 51学通信技术论坛 (http://51xuetongxin.com/bbs/) | Powered by Discuz! X2 |