Cisco ITP Exercise and Answer v00.02
Cisco ITP Exercise and Answer v00.02
Cisco ITP Exercise and Answer v00.02
Version 00.02
Cisco ITP exercises
Purpose
This document contains Cisco ITP exercises.
Scope
The scope of this document includes all eSG provided solution components with ITP.
Audience
This guide is primarily written for EWS.
Prerequisites
An understanding of SS7 over IP concepts, IN architectures is assumed as a prerequisite.
Related Documents
See relevant sections at the end of this document.
Document Information
Document: Cisco ITP exercises
Document ID: training
Version: 00.02
Date Issued: 13/08/2008
Project: ESW
Solution: Cisco ITP
Client: EWS
Country: Belgium
Approved By
Name
Function
Approval Date
Signature
Version control
Contents
2 Getting started 7
2.1 Login credentials 7
2.2 Show configuration file 7
2.3 DNS lookup 7
2.4 System clock configuration 8
2.5 Configure general SS7 network settings 8
SS7core simulator
E1 SS7 E1 SS7
ITP1 ITP2
Instance 0 an 1 Instance 0 and 1
IP
UAS1 UAS2
ASP1, ASP2 ASP1, ASP2
2 Getting started
Each course group will configure one ITP from scratch, subsequently varying the routing options.
The goal is to get 2 ITPs fully functional thus to be able to transport messages between UAS and
a (virtual) mobile, passing the SS7 simulator and SS7 network formed by 2 ITPs as shown in
figure 1.
- ITP(config)#no ip domain-lookup
- Configure a daylight saving time starting in the night on the last Sunday of March,
moving time 1 hour forward from 2 to 3 o’clock, and ending on the last Sunday of
October, moving time 1 backwards from 3 to 2 o’clock at night.
ITP(config)# clock summer-time MET recurring last Sunday march 02:00
last Sunday October 03:00 60
Configure your ITP point code, set it to x000, where x is your ITP/course group. E.g.
ITP3’s point code, as configured by group3, is 3000. For group1 is would become:
- ITP(config)#cs7 point-code instance 0 1000
Set the (cumulative) accounting intervals for link and GTT parameters to 1 minute
- ITP(config)# cs7 accounting checkpoint-interval 1
- ITP(config)# cs7 accounting gtt-checkpoint-interval 1
- ITP(config)#interface FastEthernet0/0
- ITP(config-if)#ip address 192.168.001.1x 255.255.255.192
- ITP(config-if)#full-duplex
- ITP(config-if)#speed 100
- ITP(config-if)#exit
- ITP(config)#interface FastEthernet0/1
- ITP(config-if)#ip address 192.168.001.10x 255.255.255.192
- ITP(config-if)#full-duplex
- ITP(config-if)#speed 100
- ITP(config)#ip subnet-zero
- ITP(config)#ip route 0.0.0.0 0.0.0.0 192.168.001.1
- ITP(config)#card type e1 1
- ITP(config)#controller E1 0/0
- ITP(config-controller)#framing no-crc4
Configure the link synchronizing clock source. Configure ITP1, 2 with clock source internal
(alternatively clock source line if there is an SS7 link between ITP1 and 2).
Note here that ITP1 and 2 may interconnected with SS7 links; one of the end-points should
provide the clock source, the other not.ITP1 and ITP2 generate the clock signals for their links
with the SS7 simulator.
- ITP(config-controller)#channel-group 0 timeslots 1
- ITP(config-controller)#channel-group 1 timeslots 2
- ITP(config-controller)#exit
In the linkset configuration statement enter the point code of the node where you are
connecting to, NOT the point code of your own ITP node! Note that:
ITP1 has point code 1000, ITP2 has point code 2000 and the SS7 simulator has point code
900.
Name the linksets and assign the available links, namely Serial 0/0:0 and Serial 0/0:1 for
controller E1 0/0 and Serial 0/1:0 and Serial 0/1:1 for controller E1 0/1, according to the
following table:
Assign the links to these linksets and also enter accounting and gtt-accounting statements
to be later able to collect statistical information with the ‘ITP#show cs7 accounting’
command.
- Associate to each linkset on each ITP for controller E1 0/0:
link 0 to Serial1/0:0 and link 1 to Serial1/0:0.
- Here solution is given for ITP1, only the first line is different for other ITPs:
- ITP1(config)#cs7 instance 0 linkset ITP1-TO-SIM1 3000 ! Note here 3000 is PC of
SS7 SIM
- ITP1(config-cs7-ls)#link 0 Serial 1/0:0
- ITP1(config-cs7-ls)#link 1 Serial 1/0:1
- ITP1(config-cs7-ls)#accounting
- ITP1(config-cs7-ls)#gtt-accounting
- ITP1(config-cs7-ls)#exit
If ITP 1 and 2 are interconnect via SS7, configure linksets on both ITPs
Note here that ITP1 and 2 are interconnected with SS7 links, so one of the end-points
should provide the clock source, the other not.
Configure a SCTP fail-over linkset, using SCTP peer port 6000, named on
ITP1: FO-itp1-to-itp2
ITP2: FO-itp2-to-ipt1
Note that the fail-over linkset is used to re-route traffic in case the TDM linksets are
unavailable on your local ITP.
- Here solution is given for ITP1, only the first line is different for other ITPs
- ITP1(config)#cs7 instance 0 linkset FO-itp1-to-itp2 2000 !Note 2000 is PC of
ITP2
- ITP1(config-cs7-ls)#link 0 sctp 192.168.25.130 6000 6000
- ITP1(config-cs7-ls)#accounting
- ITP1(config-cs7-ls)#gtt-accounting
- ITP1(config-cs7-ls)#exit
- Here solution is given for ITP1, the first line is different for other sua’s/ITPs
- ITP1(config)#cs7 sua 14001 !or 14002 (for UAS2) on ITP1
- ITP1(config-cs7-sua)#local-ip 192.168.001.11
- ITP1(config-cs7-sua)#local-ip 192.168.001.101
- ITP1(config-cs7-sua)#cumulative-sack 500
- ITP1(config-cs7-sua)#tx-queue-depth 10000
- ITP1(config-cs7-sua)#exit
- Here solution is given for ITP1, the asp name and SUA port number differs for the
other ITPs:
- ITP1(config)#cs7 asp ASP-UAS11 14001 14001
- ITP1(config-cs7-asp)#remote-ip 192.168.001.13
- ITP1(config-cs7-asp)#remote-ip 192.168.001.103
- ITP1(config-cs7-asp)#exit
- ITP1(config)#cs7 asp ASP-UAS12 14001 14001
- ITP1(config-cs7-asp)#remote-ip 192.168.001.14
- ITP1(config-cs7-asp)#remote-ip 192.168.001.104
- ITP1(config-cs7-asp)#exit
- ITP1(config)#cs7 asp ASP-UAS21 14002 14002
- ITP1(config-cs7-asp)#remote-ip 192.168.001.13
- ITP1(config-cs7-asp)#remote-ip 192.168.001.103
- ITP1(config-cs7-asp)#exit
- ITP1(config)#cs7 asp ASP-UAS22 14002 14002
- ITP1(config-cs7-asp)#remote-ip 192.168.001.14
- ITP1(config-cs7-asp)#remote-ip 192.168.001.104
- ITP1(config-cs7-asp)#exit
Configure per UAS an AS using SUA and assign the corresponding ASP processes. Name
this AS (for instance 0):
on ITP1 AS1-UAS1-0 ASP-UAS11, ASP-UAS12
AS2-UAS2-0 ASP-UAS21, ASP-UAS22
on ITP2 AS1-UAS1-0 ASP-UAS11, ASP-UAS12
AS2-UAS2-0 ASP-UAS21, ASP-UAS22
- Define a routing-key per AS that matches all traffic routed to a particular UAS
point code and ssn. The SSN=8 for all UASs. The UAS point code is 100 for UAS1,
200 for UAS2.
- Configure the AS traffic-mode as loadshare bindings. Thus loadsharing over
available SCTP associations to available ASPs.
-
- ITP1(config)# cs7 instance 0 as AS2-UAS2-0 sua
- ITP1(config-cs7-as)#routing-key 2000 200 si sccp ssn 8
- ITP1(config-cs7-as)#asp ASP-UAS21
- ITP1(config-cs7-as)#asp ASP-UAS22
- ITP1(config-cs7-as)#traffic-mode loadshare bindings
- ITP1(config-cs7-as)#exit
6.1 Add the following PC routes to your local ITP system route table
Add routes to point codes that are not adjacent PCs or serviced by an Application Server
(AS) on your local ITP. You need to define routes depending on which ITP you are
configuring.
For instance 0, configure on each ITP a route to the following PC destinations:
(NOTE that a route is a linkset to one of the adjacents, multiple routes can be configured for the
same destination, loadsharing takes places when routes to the same destination share equal
priority.)
LINKSET = 'ITP1-TO-SIM1'
DPC OPC SI In Pkts In Bytes Out Pkts Out Bytes
------ ------ -- ---------- ---------- ---------- ----------
100 900 3 44 2699 0 0
900 200 3 48 3112 0 0
900 300 3 3 173 0 0
1000 3000 0 47 367 0 0
1000 3000 1 56076 504684 0 0
3000 1000 0 0 0 18731 149840
3000 1000 1 0 0 56076 504684
- The Accounting figures demonstrate load distribution over the available resources.
For tuning of the network, these are best suited.
- The congestion counters show the level of buffered traffic and indicate any
congestion:
CongestionRxInd = Abate
CongestionTxInd = Abate (Level0)
Layer3 congestion state shows the current state, this should indicate Abate. Whenever it
shows ‘Onset’ this means that the interface queue is overloaded. The fields
“CongestionRxInd” and “CongestionTxInd” indicate current congestion levels. The field
“XmitQ depth (max-used)” indicates the maximum number of packets waiting in the queue
ever and thus tells how congested the router might have been.
Check the counters of sigtran on the UAS. Study them and consider which ones could be
useful for your daily job.
The link shown is “In service”, the link can be used to send traffic over. Other statuses
you might encounter are:
Out of Service: The E1 controller on the ITP is probably in shutdown state, or other
parameters (like crc4, or clock source) do not match with that what is defined on the
adjacent.
- On the ITP:
ITP1#sho cs7 as
Routing
AS Name State Context
------------ ------ ----------
ASALL active 8
- The command used is ping cs7 [–sls <sls>] [–duration <duration>] <pointcode>,
where the SLS and duration are optional parameters and the pointcode for
instance the PC of one of the other ITPs in the training network. (ie 1000 – 6000)
Trace the SISGTRAN entity on the UAS; try to find an appropriate trace level to see all
error information.
In what way would you proceed if a message did not arrive, when sending from one
mobile to another? Please describe the steps and perform them.
- Under ‘normal circumstances’ (SS7 network => ITP => UAS) you should first
check the message path. In the training environment (and maybe even in your
own network), the switch is not within your scope of management. The lowest
level where a message enters is on the E1 interfaces of the ITP
(the training environment uses an IP connection between mobile and switch). On
the incoming side start checking whether or not all SS7 links are available (use
SHOW CS7 LINKSET for example). If one of the links is not active, you could check
the E1 controllers for configuration problems. With SHOW RUNNING, see if the
controllers are shutdown or lack specific settings. Do the same for the serial
interfaces / timeslots.
- Next check the GTT selector, with SHOW CS7 GTT CONFIG, and see if the message
will be routed to the proper AS. Then find the AS in the SHOW RUNNING-CONFIG
and see if the right UASs (ASPs) are attached to this AS. Lookup for the ASP’s as
part of the AS, to which IP addresses the message can go to.
- With this information, check SHOW CS7 AS and see if they are active (in other
words if the SCTP/IP Association is active). If one of the associations is not up,
then do a SHOW RUNNING to check whether the Ethernet interfaces are
‘shutdown’, or other parameters (duplex, or speed) do not match with the UAS
side. When an association is not up and the Ethernets are available, it becomes
time to switch your troubleshooting activities to check the UAS.
- The final step is to reverse the above procedure for the MT part.
(Most things have already been checked in the MO part, so you only need to
ensure routing is properly executed).