This is TikiWiki 1.9.7 -Sirius- © 2002–2006 by the Tiki community Thu 20 of Dec, 2007 [16:13 UTC]

History: SS7 Link Status

Source of version: 2 (current)

The status of an SS7 link can change in fraction of a second, so as soon as you determine if the link is up or down, the information rapidly becomes obsolete. To answer the question about an SS7 link state, you should watch it for a few seconds to see if the state remains the same. ss7box periodically sends indications about links being up or down to /var/log/messages in the form of warnings and link status reports. With a new link, you will have to watch the link closely for a while to see if it stays up. Usually, a link that stays up for 5 minutes will stay up for weeks or months without a problem. With a link that has been in service for a while, you can watch the link status reports once or twice and get a sense of current link status.

When links are in service, you will find a message in /var/log/messages for each configured link:~pp~
Sep 6 16:29:49 GTC_Ast1 ss7boxd_i_0.3.55[3897]:
W:mtp3_slm.c:mtp3_lsac_ars:Link In Service:LS/LINK id follow::0:0~/pp~
Look for a link utilization report that has non-zero "msu oc", or MSU octet counts to indicate that the link is up. In the following report the total number of octets received is 80000 and out of that total, 20 octets were MSU. MSU are only transmitted on a SS7 link that is aligned and in service. If a link is aligned and in service and both sides are idle and do not send periodic test messages, then it is difficult to tell from these link status messages if the link is up because the MSU octet count could be 0 for quite a while. In this case you stimulate the system to create SS7 traffic and then see the msu oc become non-zero.:~pp~Sep 3 04:52:39 GTC_Ast1 ss7boxd_i_0.3.55[13930]:
R:link util:ls 0:link 0:msu oc 20:tot oc 80000:util 0
~/pp~
If you see a rapidly rising MSU octet count and there is nothing to account for this rise, then most likely there is a loopback in the circuit. You can use this effect when you are installing the link and purposefully using a loopback to verify the correct operation of the loopback.~pp~
Sep 6 16:29:57 GTC_Ast1 ss7boxd_i_0.3.55[3897]:
R:link util:ls 0:link 0:msu oc 20:tot oc 79680:util 0
Sep 6 16:30:07 GTC_Ast1 ss7boxd_i_0.3.55[3897]:
R:link util:ls 0:link 0:msu oc 6660:tot oc 80000:util 0
Sep 6 16:30:17 GTC_Ast1 ss7boxd_i_0.3.55[3897]:
R:link util:ls 0:link 0:msu oc 13320:tot oc 80000:util 0
Sep 6 16:30:27 GTC_Ast1 ss7boxd_i_0.3.55[3897]:
R:link util:ls 0:link 0:msu oc 20000:tot oc 80000:util 0~/pp~
If the link is not coming up:
#Verify the E1 is connected. You should see this message in /var/log/messages:~pp~Sep 6 16:14:23 GTC_Ast1 kernel: wanpipe3: E1 connected!~/pp~(Your wanpipe number depends on your particular configuration.)
#Verify that the PSTN side of the link has the link operational and allowed. This can be a tricky thing to determine. We have expert level tools to examine the incoming content to see if SS7 link alignment is occuring.
#Examine the possibilty of the "we can see them, but they can't see us" syndrome. This is a wiring defect. It is fairly common. Both sides claim to the other side is to blame. The only way to work this problem out is to cooperate and methodically move a loopback device through the various connection points in the transmission path. The technique should be applied on both sides so that both the ss7box and PSTN side are debugged.
#If the link comes up and goes down a few seconds later, it is likely that the point codes are improperly administered.
Most of the time spent of bringing up an SS7 link is on the troubleshooting steps listed above.

In the next example, we see a periodic link report for a link that is trying to connect but is being refused by the remote end:

~pp~Sep 11 22:46:04 ss7box ss7boxd_i_isb_0.3.55[4412]:
R:link util:ls 0:link 0:msu oc 0:tot oc 240000:util 0~/pp~

In the next example, we see a periodic link report for a link that is not connected at the E1 level:

~pp~Sep 11 22:46:04 ss7box ss7boxd_i_isb_0.3.55[4412]:
R:link util:ls 1:link 0:msu oc 0:tot oc 0:util -1~/pp~

Issuing the "wanrouter status" command we find information that supports this analysis. In the examples above, ls 0 link 0 is on wanpipe1, and ls 1 link 0 is on wanpipe4:

~pp~Devices currently active:
wanpipe1 wanpipe4

Wanpipe Config:

Device name | Protocol Map | Adapter | IRQ | Slot/IO | If's | CLK | Baud rate |
wanpipe1 | N/A | A104/4D/8| 27 | 2 | 2 | EXT | 0 |
wanpipe4 | N/A | A104/4D/8| 27 | 2 | 1 | EXT | 0 |
Wanrouter Status:

Device name | Protocol | Station | Status |
wanpipe1 | AFT HDLC | N/A | Connected |
wanpipe4 | AFT HDLC | N/A | Connecting |~/pp~


Menu [hide]
Toggle  Wiki
Powered by TikiWiki Powered by PHP Powered by Smarty Powered by ADOdb Made with CSS Powered by RDF
RSS Wiki
[ Execution time: 0.90 secs ]   [ Memory usage: Unknown ]   [ 16 database queries used ]   [ GZIP Disabled ]   [ Server load: 7.80 ]