Configuring Cisco SLT

Configuring a MTP2 backhaul with Cisco SLT requires configuring both ends, applying configuration and checking the state of the links.

IMPORTANT: Cisco gateways support a maximum of 4 SS7 links. This is enough for small configurations but insufficient to correctly connect to multiple providers. Therefore for flexibility it is desirable to have several smaller gateways rather than a big one.

On this page:

Cisco configuration
Yate configuration
Status on Cisco
Status on Yate
Other configuration steps
Other documentation

Cisco configuration

Here is a fragment of the Cisco configuration for an AS5350 or AS5400XM fitted with a card with 4 or more E1 ports:

 
!
controller E1 1/0
 channel-group 0 timeslots 1
 ds0-group 1 timeslots 2-31 type none service mgcp
!
controller E1 1/1
 channel-group 0 timeslots 1
 ds0-group 1 timeslots 2-31 type none service mgcp
!
controller E1 1/2
 ds0-group 1 timeslots 1-31 type none service mgcp
!
controller E1 1/3
 ds0-group 1 timeslots 1-31 type none service mgcp
!
interface Serial1/0:0
 no ip address
 encapsulation ss7
 channel-id 0
!
interface Serial1/1:0
 no ip address
 encapsulation ss7
 channel-id 1
!
ss7 session 0 address a.b.c.d 4001 w.x.y.z 4000 session-set 0

In the example above two E1 trunks are configured for SS7 signaling (on timeslot 1) and MGCP controlled voice on the remaining timeslots 2 to 31. The third and fourth E1s are used only for voice.

For a T1 controller the timeslots of each port are in range 1 to 24 but otherwise the configuration is similar.

The name of each controller depends on the board and port location. 1/2 means port number two (that is, third as they start counting with zero) of board in slot number one.

Replace a.b.c.d 4001 with the IP and port of the Yate end of the RUDP connection. Instead of w.x.y.z 4000 set the IP and port of the Cisco side of RUDP.

IMPORTANT: The number of the signaling channel-group must be the timeslot number minus one. If you had signaling on timeslots 16 then you would need channel-group 15

Yate configuration

The matching ciscosm.conf on the Yate side would look like this:

 
[sample_session]
local_host=a.b.c.d
local_port=4001
remote_host=w.x.y.z
remote_port=4000

[link1]
session=sample_session
channel=0

[link2]
session=sample_session
channel=1

The Session Manager sample_session defines the RUDP connection to Cisco. Normally you should have only one session between one Yate and one Cisco. You can have separate connections to more gateways and also each gateway may talk to different controllers, each in a separate section.

Each SS7 MTP2 link has a reference to the connection and an unique channel number - you should assign these channel numbers sequentially starting with zero. The names of these link sections are arbitrary, they will be referenced from ysigchan.conf in sections type ss7-mtp3.

Status on Cisco

There are several specific IOS commands to show the state of links and session in Cisco:

 
show ss7 mtp1 links
show ss7 mtp1 channel-id
show ss7 mtp2 state
show ss7 mtp2 stats
show ss7 mtp2 ccb
show ss7 mtp2 timers
show ss7 mtp2 variant
show ss7 sm session
show ss7 sm set
show ss7 sm stats

First check the state of the E1 controllers, check if they are up or down or experience errors:

 
show controller E1 1/0

Then verify the virtual serial interfaces have started:

 
Router#show ss7 mtp1 links
 SS7 MTP1 Links [num = 2, platform max = 4]:

                                       session session
   interface   type   SCC     state    channel   set
   --------- -------- --- ------------ ------- -------
      1/0:0  digital  3/3      STARTED     0       0
      1/0:1  digital  3/2      STARTED     1       0

IMPORTANT: There are some buggy versions of firmware where the serials will show STOPPED after a reload even if the configuration was saved to flash. These versions are unusable for normal operation but just for tests you can issue a "no shutdown" command on each such serial interface.

You should then check the MTP2 Channel allocation to interfaces and timeslots:

 
Router#show ss7 mtp1 channel-id
 SS7 MTP1 Session-channel [all]:
      channel  assigned interface
      -------  ------------------
          0      1/0:0  (digital)
          1      1/1:0  (digital)

Then check the session's RUDP configuration:

 
Router#show ss7 sm session
Session[0]: Remote Host a.b.c.d:4001, Local Host w.x.y.z:4000
      retrans_t = 600 milliseconds
      cumack_t  = 300 milliseconds
      kp_t      = 2000 milliseconds
      m_retrans = 2
      m_cumack  = 3
      m_outseq  = 3
      m_rcvnum  = 32

Operational state of the session and the links controlled by it:

 
Router#show ss7 sm set 0

Session-set: 0
  State           = ACTIVE
  Failover-timer  = 5 secs.
  State-debugging = OFF
  Timer-debugging = OFF

  1 Sessions:
    session 0   session-state ACTIVE   remote-host a.b.c.d:4001

  2 SS7 Links:
       1/0:0 (dig.)  chan-id 0  variant ITU-White  link-state INSERVICE
       1/1:0 (dig.)  chan-id 1  variant ITU-White  link-state INSERVICE

If instead of ACTIVE you see OPENING the RUDP parameters (addresses, ports) are incorrect or a firewall may block UDP packets.

On a typical Linux system a firewall can be temporarily disabled by issuing the command:

 
/etc/init.d/iptables stop

You would need to permanently disable the firewall, for example by stopping the iptables service from starting at startup:

 
chkconfig iptables off

The commands for controlling the firewall may differ depending on the Linux distribution.
Note that an external firewall, ACL settings on Cisco or SELinux may be other reasons for lack of UDP connectivity.

Finally, check the detailed state of the SS7 MTP2 links:

 
Router#show ss7 mtp2 state
SS7 MTP2 states for channel 0
Protocol version for channel 0 is ITU-T Q.703 (1996) (White Book)
  MTP2LSC_INSERVICE       MTP2IAC_IDLE
  MTP2TXC_INSERVICE       MTP2RC_INSERVICE
  MTP2SUERM_MONITORING    MTP2AERM_IDLE
  MTP2CONGESTION_IDLE
    Congestion Backhaul  = Abate
Remote Processor Outage  = FALSE

SS7 MTP2 states for channel 1
Protocol version for channel 1 is ITU-T Q.703 (1996) (White Book)
  MTP2LSC_OOS             MTP2IAC_IDLE
  MTP2TXC_INSERVICE       MTP2RC_IDLE
  MTP2SUERM_IDLE          MTP2AERM_IDLE
  MTP2CONGESTION_IDLE
    Congestion Backhaul  = Abate
Remote Processor Outage  = FALSE

In the above example channel 0 is aligned (MTP2LSC_INSERVICE) while channel 1 is paused (MTP2LSC_OOS) from the Yate side. Resuming link2 without an active MTP2 at the other end results in:

 
Router#show ss7 mtp2 state 1
SS7 MTP2 states for channel 1
Protocol version for channel 1 is ITU-T Q.703 (1996) (White Book)
  MTP2LSC_INITIAL_ALIGNM  MTP2IAC_NOT_ALIGNED
  MTP2TXC_INSERVICE       MTP2RC_INSERVICE
  MTP2SUERM_IDLE          MTP2AERM_IDLE
  MTP2CONGESTION_IDLE
    Congestion Backhaul  = Abate
Remote Processor Outage  = FALSE

In this case the link tries to align but didn't succeed yet (MTP2IAC_NOT_ALIGNED).

Status on Yate

The state of Cisco SLT links is displayed in rmanager just like any type of link:

 
status sig links

%%+status:sig links
module=sig,format=Type|Status;count=2;link1=cisco-slt|Normal Alignment,link2=cisco-slt|Out Of Alignment
%%-status

You can also use the Wireshark (former Ethereal) network protocol analyzer to check the communication at IP level. You will need to manually select one of the UDP packets and "Decode As..." RUDP from the Right Click menu.

If a graphical environment is not installed you can use the tshark text mode component of Wireshark to get a rough overview of the signaling:

 
tshark -n -d udp.port==4000,rudp

You can add on the command line above to filter output:

-R sm (Display only RUDP containing SM)
-R sm.len!=0 (Display only SM containing commands or MTP2)

Configuring Cisco SLT

Cisco configuration

Yate configuration

Status on Cisco

Status on Yate

Other configuration steps

Other documentation