GB over IP dynamic ip nsvc方式下，由于传输瞬断产生的ns-status问题请教？

hou3331

现网中一个Z SGSN和E BSC对接组网结构介绍:


此拓扑图中，SGSN采用loadsharing，bsc采用active/standby方式对接，中间IP网络使用vrrp协议。

sgsn local endpoint为10.196.52.244+40999，10.196.52.245+40999,
bsc remote endpoint有10个，其中port都为20000.
10.228.179.193
10.228.179.194
10.228.179.195
10.228.179.196
10.228.179.197
10.228.179.198
10.228.179.199
10.228.179.200
10.228.179.201
10.228.179.202  

当bsc发起dynamic ip nsvc协商后，假设10.196.52.245和这10个ip地址建成了共10条ip nsvc。

处理机制描述：
1. 传输网络瞬断导致的vrrp切换过程。
由于承载的传输网络条件非常烂，导致经常传输瞬断。假设现在vrrp都正常工作在交换机1上，当link1传输瞬断，sunmmit交换机将发起vrrp切换，切换到summit-2上。8905-1交换机由于优先级高于8905-2交换机，不发起vrrp切换。
切换过程中，在交换机上互ping vrrp ip，大概需要10s左右可以ping通。
2. bsc和sgsn之间 nsip层本身是运行着很多的ns-alive消息的，其中sgsn侧配置如下：
10 NS-ALIVE-RETRIES  
3  SNS-ADD-RETRIES  
3  SNS-CONFIG-RETRIES  
3  SNS-CHANGEWEIGHTS-RETRIES  
3  SNS-DELETE-RETRIES  
10 Tns-test Unit: second
5  Tsns-prov Unit: second

BSC为Ericsson设备，具体配置未知.
3. 告警及restore机制：
1）bsc侧若收不到ns-alive ack消息，会停止发送ns-alive检测消息，而在各条ip nsvc上发起ns-status，所携带ip为出错的ip nsvc上的ip。
2）sgsn侧若收不到ns-alive ack消息，会在此条ip nsvc上发起ns-status，但继续发送ns-alive消息，若再收到了ns-alive ack消息，表明此ip nsvc已经restore了。

实际问题：
前文已经描述，当传输瞬断时，vrrp发生切换，会有大致10s左右的时延。在这时延中，会有部分ns-alive，ns-alive-ack报文丢失，导致bsc和sgsn都会发起ns-status，通知链路出现故障。



但由于处理机制的不同，导致部分ip nsvc业务报文丢失。
1. 在bsc上会继续发送ns-status，除非所有ip nsvc都中断或者网管手动干预，不然此条被标志为non operational的ip nsvc上是不会再有业务传送了。
2. sgsn侧虽然发送了ns-status，但会继续发送ns-alive检测此链路，当后续可以收到ns-alive ack反馈后，继续往此ip nsvc上发送业务。

由于bsc和sgsn两侧的ip nsvc不一致，用户上网丢包。

想问一下，该问题如何处理才是最好？
1. 由于全国基础设施相当差，要解决传输瞬断不可能，故是否可以改变vrrp对接组网方式，采用什么样的IP网络和协议会比较好？
2. E BSC侧或者3GPP上是否有讲到，当某条IP NSVC出现故障后，可以发起rebuild流程，而不需要等到全部ip nsvc都挂了后再发起？
3. 更改bsc或者sgsn上的ns alive定时器有用吗？

爱卫生

现在很多地方都开了BFD(双向转发检测)了，可以做到链路级的毫秒级检测，VRRP也可以支持毫秒级的检测，本身还是很快的。OSPF路由协议也可以支持毫秒级的检测。
但这个组网里有4个Lab SW，当VRRP主备发生切换后，这个虚拟的MAC地址也需要在这4台LAN SW上做一个切换，肯定会慢的。所以现在很多Site里的组网都是网元直接挂CE上，不用LAN SW了。

hou3331

嗯，是建议到启用BFD检测和OSPF协议的，实际上现网还有种组网模式，就是summit 48-s起二层，BSC上的NWI单板起vrrp。就需要BSC NWI侧增加ospf的license，以及summit 48-s支持BFD报文透传。

samsin

学习，向两位学习