Stateful Packet Inspection – Signalling Survivability is not working
Evermore tickets are being received reporting that Signalling Survivability (Sig. Surv.) is not working.
Almost all cases are then proved to be cause by the customer network, so we wanted to mention that
here to avoid such unnecessary escalations. The condition will be noticed either at time of installation,
after the customer hardens their network infrastructure due to a security assessment, or after upgrade
of network infrastructure components and it will simply be reported that Sig. Surv. is not working.
IPDA works through receiving signalling packets on port 4000 from the Active CC. When Sig. Surv. is
configured, a further Keep Alive mechanism works by polling the IPDA shelf via Port 4001. Should this
keep alive mechanism fail, a PPP connection is set up via WAML (or external router) and all the packets for port 4000 are then routed via that connection using the same TCP stream. The communication for
Port 4000 uses by default TCP and each packet has a TCP Sequence Number (effectively a counter), for
the IPDA to successfully take over the connection via PPP, it is imperative there is no loss in Sequence
Number i.e. without using this counter, the IPDA could not know at what stage the Signalling Messages
were at e.g. if a user dials 1,2,3,4 and the LAN connection breaks down between 2 & 3 – how can the
NCUI know without such a counter exactly where to continue the connection from. For this reason
there has always been the mandatory requirement that Port 4000 is transparent through the customer
network (as documented under IP Solutions in E-Doku):
IMPORTANT: The TCP stream (tcp.port=4000) has to be routed fully transparently through the customer's IP
network (i.e. no manipulation of the Sequence Number etc.), otherwise the "Signaling Survivability" will not work.
Furthermore, any available firewalls have to be configured accordingly so that no Sequence No and SYN check takes
place for the tcp.port=4000.
To prove such an error, usually a wireshark trace is needed on both HSR (Host System) and NCUI sides
where the tcp sequence number can be compared on both sides of the connection. The following NCUI
event log can also be signalled under this circumstance to provide a hint to the error cause.
Event Log Entry from IPSTACK (tNetTask "10/27/2012 22:08:46.171481"
\cm_common_lib\ip_stack\init\ip_cfg_init.cpp 292):
EventType: Major
EventCode: TCP_IP_INVALID_SEQ_NO
EventText: Invalid SEQ number: expected 0xe81b8a90, recv 0xb0e3816,
The condition is not so easy to identify in a Softgate as no explicit error message can be signalled,
however you will see repeated retransmissions in the soco.log before the HSR connection is ended after
the PPP connection has been established (seen in /var/log/messages:
/var/log/messages
Dec 6 11:32:44 softgate ip-up: INFO Remote Survivability: packets to
HHS are routed via PPP
/var/opt/soco.log
2011-12-06 11:32:43,116 INFO [com.sen.esy.lcd.softap.ncui.MmxTime] getTime
retransmission 1 performed
2011-12-06 11:32:53,118 INFO [com.sen.esy.lcd.softap.ncui.MmxTime] getTime
retransmission 2 performed
…
2011-12-06 11:32:53,120 INFO [com.sen.esy.lcd.softap.ncui.MmxTime] getTime
retransmission 5 performed
Solution: The customer must make TCP Port 4000 transparent OR from HiPath 4000 V6 R2, the new
feature HSR over UDP can be activated (AMO UCSU -> AP -> SIGMODE=HSRUDP – HSR over UDP) -
CHANGE-UCSU:UNIT=AP,LTU=<AP>,SIGMODE=HSRUDP;
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.