|
Introduction to … Using a Sarian with Wireless WAN (WWAN) |
|
2.9 Private and Public IP addresses
3.8 Dynamic Routes by Authentication
9.1 Event log and logcodes.txt
9.2 Events & reasons in logcodes.txt
9.3 Configuring the Event Handler
9.5 Excluding events from the Event Log
9.6 Freezing the Analyser Trace
9.7 Using automatic emails to diagnose
OLA faults.
11.2 PVC from SYNC port 0 to a Cisco over
XOT
12.0 UDP Echo Server and Statistics
bins
12.1 Configuring the UDP Echo client
12.2 Configuring the UDP Echo Server
13.0 Making and Receiving CSD Calls
13.1 Ensure your SIM is data enabled.
13.3 Making outgoing calls from the Sarian
13.4 Accepting incoming calls on the
Sarian
13.5 Configuring a PC & Sarian to make
PPP calls over ISDN
13.7 CSD Troubleshooting Questions
MR2110
2 Serial ports (one RS232 external + 1 TTL
internal for GSM module)
1 Software UART (fixed at 4800bps for 1-wire
and GPS only)
1 Ethernet port
1 PSU port 12v – 24v DC
2 SIM slots (cannot be used at the same
time)
3 Jumpers to switch between sync and async
operation (see Synchronous Note.pdf)
ER2110
3 Serial ports (one RS232 external + 2 TTL
internal for GSM module)
1 Software UART (fixed at 4800bps for 1-wire
and GPS only)
1 Ethernet port
1 PSU port 12v – 24v DC
2 SIM slots (cannot be used at the same
time)
3 Jumpers to switch between sync and async
operation (see Synchronous Note.pdf)
When power is first turned on the CPU loads
the boot-loader software from the FLASH and flashes the DAT LED. If the DAT LED
flashes and there is no hardware fault then the software on the unit can always
be fixed. The FlashWriter program can be used for this. The use of FlashWriter will be covered later
in the training course if time allows. If the DAT LED does NOT flash when first
powered up, and provided the LED itself is not faulty the unit will have to be
returned to Sarian for repair. With future products this will not be necessary.
Next the DAT LED will continue to flash but
the SIM LED will also FLASH more rapidly then the DAT. During this period the
main software application is being read from FLASH, decompressed and also
decrypted.
If the unit boots up successfully then the
SIM and DAT LEDs should slop flashing and the Ethernet will blink briefly as
the port is re-initialised assuming it is connected to a switch. If all the
LEDs flash and then the process repeats the unit rebooted for some reason i.e.
there is a problem. Note that normally the DAT LED will start to flash again a
few seconds after a successful boot when the GPRS connection is initialised, do
not confuse this with a reboot.
Whenever the Sarian does something
significant, a software event will occur. These events are stored in the
Sarian’s event log. The event log is stored in NVRAM (None Volatile Random
Access Memory – in this case RAM backed up by battery). This means that the
event log is retained even if the Sarian is powered off. The events can be used
to trigger automatic emails, SMS messages or SNMP traps.
All Sarian products also feature a very
powerful analyser trace. This trace shows at packet or frame level every single
packet or frame that the Sarian receives or sends. The analyser trace
understands all the protocols that the Sarian supports (e.g. IP/ TCP/ X.25 /
PPP) and is therefore able to provide detailed decoding of the raw packet so
that they can be easily understood. The analyser trace is not currently stored
in NVRAM so it is lost when the unit is rebooted.
All Sarians can be configured to send an
email when a certain event occurs. The event log and analyser trace can be
attached to the email thus providing a snapshot of everything that was
occurring at the time the email was sent. This is extremely useful for fault
finding.
From RFC 1661:
“The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP is comprised of three main components: 1. A method for encapsulating multi-protocol datagrams. 2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. 3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.”
IP is a point to
multi-point protocol. This is evident when you consider that you can connect to
many different hosts via their IP addresses. A serial link (e.g. GPRS link,
ISDN line, analogue modem) is a point-to-point link. Sarian routers use the PPP
protocol to tunnel IP data over many different types of point-to-point links.
In Sarian routers
and terminal adaptors, PPP is used in two main modes:
“ASYNC to SYNC
mode” and “Full PPP mode”
ASYNC to SYNC mode
would typically be used to connect a PC to the Internet via an ISDN line. The
PC would do most of the PPP “work”. The Sarian would simply serve to convert
the asynchronous PPP data received through the serial port into synchronous PPP
data to be sent over the ISDN line. In this scenario it is really the PC not
the Sarian that is doing the PPP. The PC would be assigned the IP address from
the Internet Service Provider not the Sarian. The PPP entity parameters have no
effect on the operation of ASYNC to SYNC PPP. All that is required is that PPP
is bound to the ASY port used for the connection.
Full PPP mode is
much more common. In “Full PPP mode” the Sarian is doing the PPP. For example
when the Sarian connects to the GPRS network it performs the PPP and the Sarian
is assigned the IP address. The PPP parameters are extremely important in “Full
PPP mode”.
The PPP entity has
many parameters which can be found on the Standard, Advanced, PPP/IP Over X25
and QoS web pages. Usually the only parameters of interest will be on the
Standard and Advanced pages.
Sarian PPP
instances have different default values for their many parameters.
PPP 0 by default is
appropriate for answering incoming connections. (e.g. from the serial port,
ISDN, or a CSD GSM call.) PPP 0 will assign an IP address to the remote peer
and require that the remote peer authenticates with the Sarian.
PPP 1 by default is
appropriate for making outgoing calls. It will request an IP address from the
remote, it will attempt to authenticate with the remote using the username and
password entered on the standard page.
On the MR2110 and
ER2110 PPP 1 is specially pre-configured to work with GPRS.
Note that other PPP
instances can quickly be configured to “answering” or “dialling” defaults by
clicking the appropriate “Load answering defaults” or “Load dialling defaults”
button on the standard or advanced web pages.
It is important to
realise that on a GPRS unit if you click “Load dialling defaults” it will BREAK
your configuration and GPRS will not work. This is because PPP 1 has been
specially pre-configured to work with the GSM/GPRS module. The default settings
are not GPRS defaults but PPP defaults.
As far as the
Sarian is concerned, the GSM/GPRS module is a special type of external modem.
This is why at the CLI the module is controlled by an entity named “modemcc”
Here are the
factory default settings for the modemcc entity on an MR2110:
modemcc 0 ?
signal: -51 dBm on 28 May 2005 11:24:16
Parameters are..
asy_add: mux1
info_asy_add: mux2
init_str: +CGQREQ=1,0,0,0,0,0
init_str1: +CGQMIN=1,0,0,0,0,0
init_str2:
net_str:
gprs: ON
rx_gsm: OFF
gsm_only: OFF
hang_str:
posthang_str:
intercall_idle: 0
apn: yourAPN.goesHere
buapn:
usebuapn: OFF
retry_apntim: 0
pin:
epin:
link_retries: 10
stat_retries: 30
sms_interval: 0
sms_callerid:
sca:
sms_cmd_sep:
sms_replies: ON
sms_concat: 1
init_str_2: +CGQREQ=1,0,0,0,0,0
init_str1_2: +CGQMIN=1,0,0,0,0,0
init_str2_2:
hang_str_2:
posthang_str_2:
intercall_idle_2: 0
apn_2: yourAPN.goesHere
buapn_2:
usebuapn_2: OFF
retry_apntim_2: 0
pin_2:
epin_2:
link_retries_2: 10
stat_retries_2: 30
sms_interval_2: 0
sms_callerid_2:
sca_2:
sms_cmd_sep_2:
sms_replies_2: ON
sms_concat_2: 1
OK
The information is
much more digestible on the web page:

On Sarians with the
MC45 module (e.g. the MR2110) there is one physical async port linking the
module to the Sarian. The Sarian runs a multiplexing protocol across this link
to provide 3 virtual async ports. In the example above the modemcc entity is
configured to use the virtual ports mux1 for GPRS and mux2 for other data such
as reading signal strength and sms messages.
Four instances of
the LAPB entity are used to control the 3 multiplexed channels. The following
is an example only as these settings vary between products depending upon the
number of physical serial port the particular product has:
lapb 3 dtemode 0
lapb 3 asyport 1
lapb 3 mux_0710 ON
lapb 4 dtemode 0
lapb 4 dlc 1
lapb 4 asyport 1
lapb 4 virt_async "mux0"
lapb 4 mux_0710 ON
lapb 5 dtemode 0
lapb 5 dlc 2
lapb 5 asyport 1
lapb 5 virt_async "mux1"
lapb 5 mux_0710 ON
lapb 6 dtemode 0
lapb 6 dlc 3
lapb 6 asyport 1
lapb 6 virt_async "mux2"
lapb 6 mux_0710 ON
These lapb
instances can be configured automatically with the configuration macros:
muxon
muxoff
Also available via
the Disable Mux and Enable Mux buttons on the GPRS module web page.
When the Sarian
boots up or power cycles the GSM module the LAPB initialisation can be seen in
the event log:
12:01:22, 28 May 2005,LAPB 6 up
12:01:22, 28 May 2005,LAPB 5 up
12:01:22, 28 May 2005,LAPB 4 up
12:01:22, 28 May 2005,LAPB 3 up
In order for PPP to use the GPRS connection the “Use GPRS/external modem”
standard parameter is normally needs to be set to “Any GPRS Channel”.
For the Nokia N12i
(in the ER2110) mux is NOT used. Instead the Sarian receives the signal
strength etc via an additional physical serial port on the module. Other
important non-PPP default parameter settings are:
Dial-out number: *98*1# (for the Siemens MC45)
Dial-out number: *99# (for Motorola g18)
Dial-out number: *99***1# (for the Nokia N12i Edge, MC45 or
g18)
Local IP address = 0.0.0.0
Remote CHAP authentication = “No” (Except for the g18)
Inactivity Timeout (s) = 0
Always on mode = Yes
The various PPP options are negotiated via LCP.
Once authentication has occurred IP address assignment will normally take place via the NCP protocol IPCP.
The MC45 is capable
of reporting additional GSM related information for example the current cell ID
and the signal strength and cell IDs of the neighbouring cells. This feature
requires the use of the third mux channel between the MC45 and the Sarian. To
enable this feature ensure that the mc45mon entity asy_add parameter is set to
mux0 and the mon_int parameter is set to say 10 seconds.
The APN or Access
Point Name effectively determines which server the module negotiates PPP with.
Usually there are two choices, an Internet APN and a private APN.
An Internet APN
will give you access to the Internet either by assigning you a public Internet
address or more often by assigning you a private (sometime known as a NAT’ed)
IP address which can route to the Internet via a NAT router at the mobile
operator’s network edge.
A private APN requires
that a link is established between the mobile operator and your premises.
Usually this is a leased line but it could also be an IPSEC connection for
example. A Sarian connecting to a private APN will be assigned a private IP
address that is routed directly to your private network.
When connecting to
the Internet via GPRS usually the Sarian will be assigned a private IP address
that can route to the Internet via a mobile operator’s NAT router. One reason
for this is the fact that on GPRS networks there is usually a charge for data.
If you were to be assigned a public IP address then other Internet uses could
increment your data charges without your knowledge or consent.
In the
The usual technique
used to overcome this issue is the creation of a VPN tunnel using IPSEC. NAT-T
or other keep alive packets can used to keep an NAT router’s tables up to date
and to prevent any firewall from timing out. This solution comes at a cost i.e.
data charges for the keep-alive packets. But it does allow remote access to the
Sarian and full un-restricted IP routing to remote networks connected to the
Sarian’s LAN via private IP addresses.
*EDGE is a method
to increase the data rates on the radio link for GSM. Basically, EDGE only
introduces a new modulation technique and new channel coding that can be used
to transmit both packet-switched and circuit-switched voice and data services.
EDGE is therefore an add-on to GPRS and cannot work alone.
*http://www.ericsson.com/products/white_papers_pdf/edge_wp_technical.pdf
The data rate
actually achieved by Edge or GPRS is determined by the coding scheme supported
by the network and module as well as the number of time slots supported by the
module and allowed by the network.
|
Channel Coding Scheme |
CS-1 |
CS-2 |
CS-3 |
CS-4 |
|
Data rate kbit/s |
9.05 |
13.4 |
15.6 |
21.4 |
|
Maximum data peed with 8
time-slots |
72.4
kb/s |
107.2
kb/s |
124.8
kb/s |
171.2
kb/s |
There are 9 Edge
coding schemes altogether. Here is a summary of the data rates for 4 of them.
|
*Channel Coding Scheme |
MCS1 |
MCS4 |
MCS5 |
MCS9 |
|
Data
rate kbit/s |
8.8 |
17.6 |
22.4 |
59.2 |
|
Maximum
data speed with 8 time-slots |
70.4
kb/s |
140.8
kb/s |
179.2
kb/s |
473.6
kb/s |
* Table from
http://www.evaluationengineering.com/archive/articles/0202wireless.htm
|
Class |
Download |
Upload |
Max slots |
|
1 |
1 |
1 |
2 |
|
2 |
2 |
1 |
3 |
|
3 |
2 |
2 |
3 |
|
4 |
3 |
1 |
4 |
|
5 |
2 |
2 |
4 |
|
6 |
3 |
2 |
4 |
|
7 |
3 |
3 |
5 |
|
8 |
4 |
1 |
5 |
|
9 |
3 |
2 |
5 |
|
10 |
4 |
2 |
5 |
|
11 |
4 |
3 |
5 |
|
12 |
4 |
4 |
5 |
|
13 |
3 |
3 |
unlimited |
|
14 |
4 |
4 |
unlimited |
|
15 |
5 |
5 |
unlimited |
|
16 |
6 |
6 |
unlimited |
|
17 |
7 |
7 |
unlimited |
|
18 |
8 |
8 |
unlimited |
|
19 |
6 |
2 |
unlimited |
|
20 |
6 |
3 |
unlimited |
|
21 |
6 |
4 |
unlimited |
|
22 |
6 |
4 |
unlimited |
|
23 |
6 |
6 |
unlimited |
|
24 |
8 |
2 |
unlimited |
|
25 |
8 |
3 |
unlimited |
|
26 |
8 |
4 |
unlimited |
|
27 |
8 |
4 |
unlimited |
|
28 |
8 |
6 |
unlimited |
|
29 |
8 |
8 |
unlimited |
The MC45 is a Class
10 device which support all 4 coding schemes. This means it can use 2 time
slots to upload and 4 time slots to download.
As only 5 slots can be used at once, if 2 slots are being used for
upload then only 3 can be used for download.
This means in
theory it can support a download rate of 85.6 kb/s and an upload rate of 42.8
kb/s.
The Nokia 12i
module is a class 6 edge device. This means 3 time slots down and one up or 2
down slots and 2 up. It is also a class 10 GPRS device (same as the MC45)
In theory it can
support a download data rate of 177 kb/s and an upload rate of 118 kb/s
“Real life
experience” has shown that data rates of 10-20kb/s down and 30–40kb/s up are
more realistic in the
Some customers in
There is no way to
tell what coding scheme is in use or what time slots have been allocated other
than measuring the data throughput. The coding scheme used is determined by the
maximum coding scheme supported on the network and the quality of the signal.
The number of time slots used is determined by the number of slots the network
will allow you to use and the rate at which you are attempting to transfer
data.
There is no easy
way to tell whether the Nokia module is using Edge or GPRS. It automatically
falls back from Edge to GPRS when Edge is not available. The only way to tell
is by measuring the data throughput.
The Ethernet
Interface can be configured by the command line or the web server.
The number of
Ethernet “instances” available depends upon the model and the firmware loaded.
Sometimes multiple Ethernet interface represent physical Ethernet ports on the
Sarian and sometimes logical Ethernet interfaces. Logical Ethernet interfaces
allow one physical Ethernet interface to be configured with more than one set
of values (e.g. more than one IP address.)
Via the web
Ethernet instance 0 can be configured by navigating to: Configureà Ethernet à Eth 0
Via the command
line the same parameters can be read by the command “eth 0 ?”.
There are currently
more than 30 Ethernet parameters but it is usually only necessary to configure
2 or 3 for basic operation.
It is only
necessary to set the gateway if the Sarian needs to access or route traffic to
other networks (not on our subnet) via an Ethernet gateway.
The Ethernet
Interface can be configured to obtain its IP address, mask, gateway and DNS
server from a DHCP server.
To enable this
feature there are two steps.
1) Ensure that the
all the parameters you wish to obtain their values from the DHCP server are
configured blank.
2) Set the “DHCP
client” parameter to “Enabled”.|
To check that the
Sarian has received the correct values navigate to Status à Ethernet à Eth 0.
The DHCP server can
be configure via the command line or the web server. The number of Ethernet interfaces available
depends upon the Sarian model. Most units will have a single DHCP server but
models incorporating multiple Ethernet ports with V-LAN capability will have
one server instance per port.
As with all routers
and network devices the Sarian contains an internal routing table. The routing
table is used to determine which Interface and/or gateway to send an IP packet
to. The interface and/or gateway to route an IP packet through is normally
determined by the destination IP address. However the Sarian can take into
account the source IP address as well.
The routing table
can be viewed on any of the route configuration pages or via the CLI command
“route print”.
Al's DSL>route print
------------------------------------------------------------
Interface Addresses:
--------------------
PPP 1: 82.68.226.30
ETH 0: 82.68.226.30
ETH 1: 10.1.1.254
ETH 2: 192.168.50.254
Routes:
-------
IP Address Mask Metric Interface Gateway
Dynamic Routes:
62.3.83.5 255.255.255.255 1 PPP 1
82.68.226.30 255.255.255.248 1 ETH 0
10.1.1.254 255.255.255.0 1 ETH 1
192.168.50.254 255.255.255.0 1 ETH 2
Static Routes:
10.9.107.45 255.255.255.255 1 PPP 2
1.2.3.4 255.255.255.255 1 PPP 2
195.92.193.198 255.255.255.255 1 PPP 3
192.168.1.0 255.255.255.0 1 PPP 4
10.128.4.38 255.255.255.0 1 PPP 8
10.105.1.174 255.255.255.255 1 PPP 5
10.105.1.215 255.255.255.255 1 PPP 6
10.105.1.50 255.255.255.255 1 PPP 7
10.105.0.0 255.255.0.0 1 ETH 2 192.168.50.44
Default Routes:
0.0.0.0 0.0.0.0 1 PPP 1
------------------------------------------------------------
OK
Al's DSL>
As can be seen in
the output above, there are three different types of routes found in the
Sarian’s routing table.
Dynamic routes are
created automatically whenever an Interface has an IP address and mask
configured.
Static routes are
configured by the user and allow destination networks or subnets to be routed
via a certain interface or gateway.
If configured, all
IP traffic that does not match a dynamic or static route will be transmitted
through the Interface or gateway specified by the default route with the best
metric (lowest metric number).
When the Sarian has
a packet to route it always checks the routing table in the following order;
Dynamic Routes then Static Routes and then Default Routes.
Metrics are used to
determine the route that is used in the event that the destination IP address
of the packet to route matches more than one entry in the routing table.
Every routing table
entry also has a metric value. Metric values range from 1 to 16. A Metric of 1
indicates that the route has the highest possibly priority. A metric of 16
means the route is out of service and will not be used.
It is possible to
configure 2 default metric values for any route. One value to be used when an
Interface is up (the “Connected Metric”) and one for when the Interface is down
(the “Disconnected Metric”). This provides extra flexibility in determining which
interface to use. For example if the “Disconnected Metric” of a PPP interface
is set to 16 and the “Connected Metric” is set to 1, the interface will only
ever be used if it is manually raised or a remote router connects to it. When
the remote router is connected this interface could then be used in preference
to other interfaces which might normally be used to route this traffic
Routes can go out
of service automatically if an interface fails to activate provided that the
“IP route out of service time (s):” parameter on the Configure à General web page is set to a none-zero
value. The routes will stay out of service for the length of time configured in
this parameter.
This is not a
common configuration. A more commonly used method of putting a route out of
service would be to use a firewall rule. This will be covered later in the
course.
If a PPP interface
is configured as an always on route, the routing rules work differently. If an
always on interface is down then the metric for routes pointing at this
interface will automatically be 16. If the PPP interface is up then the metric
for routes pointing at this interface will automatically be set to its
configured “Connected Metric” value.
The Sarian allows
Network Address Translation to be enabled on all of its Interfaces. NAT is
usually used to share one public IP address between several devices with
private IP address. As a general rule NAT should only be turned on for the WAN
interface. (WAN = Wide Area Network. This is usually the same Interface
configured as the default route.)
Dynamic routes can
also be created when remote user authenticates with the Sarian via a PPP
interface. To enable a dynamic route to be created in this manner use the “IP
Address” and “IP Mask” parameters in the user table.
IP tracing can be
enabled on the Configure à Analyser web page and also on each Interface configuration page. The
Configure à Analyser
web page check boxes actually change the interface configuration values.
E-route (Encrypted
Routes) are used by the Sarian to mange VPN routing. Currently E-routes can be
used for IPSEC and GRE.
When configuring
routes and VPNs it can be helpful to understand the order in which packets are
processed. The following is a simplified description of this but is usually
sufficient enough.
-
Firstly
the packet will be sent to the routing stack.
-
The
routing stack will determine which interface the packet should be routed
through.
-
The selected
interface will then be checked to see if IPSEC or GRE is enabled. If not the packet will be routed through the
Interface.
-
If
IPSEC or GRE is enabled then the Sarian will look for an Eroute that matches
the source and destination IP addresses.
-
If not
by default the packet will be routed through the interface un-encrypted
although the Sarian can be configured to drop the packet.
-
If such
an Eroute is found and is correctly configured it will be used.
















When an always on
interface is down routes are automatically put out of service. In the case of
GPRS and Edge automatic recover procedures include power cycling the Internal
GSM module will take place automatically if the PPP Interface is down.
However with any
WAN interface (Ethernet, ADSL, GPRS or Edge) it is more often the case that
that the Interface will stay up but some problem “deeper” in the network
prevents end to end routing from working.
There are a number
of features built into the Sarian that are designed to recover - without user
intervention - from any GSM module or network problems that may occur.
Some of these
options are passive
· They work simply by monitoring traffic on the GPRS network and spotting problems. For example SRI.
Some of them are active
· They work by actually generating traffic on the GPRS network.
The active options have the advantage
of working even when the hosts on the Sarian’s Ethernet network are not sending
packets to the network. The disadvantage is that data charges will be incurred
if your GPRS / Edge network provider charges you for data.
NB If a speedy recovery from the problem is not required then the amount of traffic generated for the active options can be set so low as to be of negligible cost. (e.g. as low as one or two small packets per day.)
In order to recover
from:
The Sarian will need
to power cycle the GPRS module.
The Configure à GPRS Module à SIM 1 parameter “Link retries” will cause
the GSM module to be power cycled after the specified number of PPP activation
failures.
The Configure à GPRS Module à SIM 1 parameter “Status retries” will cause
the GSM module to be power cycled after the specified number of status request
failures. A status request is when the
Sarian reads some information from the GPRS module such as the signal strength.
These status requests occur automatically on a regular basis, so if the module
stops responding for any reason the Sarian will detect this and power cycle it.
The key to
recovering from most problems is that the PPP interface is deactivated. Firstly
re-negotiating a PPP session may fix the problem. If the Sarian is unable to
re-connect with PPP then the module will be power cycled.
Three examples of
SRI firewall rules follow:
Line 1: pass out break end on ppp 1 proto tcp from any to 192.168.20.1 flags S!A inspect-state oos 1 t=5 c=5 d=5
Line 2: pass
The above firewall will cause PPP 1 (the GPRS PPP interface) to be deactivated
if several TCP connection attempts to the IP address 192.168.20.1 fail.
Line 1: pass out break end on ppp 1 proto udp from any to 192.168.0.0/16 port=1001 inspect-state oos ppp 1 1 t=10 c=5 d=5
Line 2: pass
The above firewall will cause PPP 1 (the GPRS PPP interface) to be deactivated
if five (c = 5 & d = 5) UDP packets are sent to IP subnet 192.168.0.0/16 on
port number 1001 and no UDP packet is received back from the 192.168.0.0/16
subnet. NB It can be completely OK for some protocols that use UDP not to
receive a reply, this rule should only be used for UDP based protocols that
expect a reply.
Line 1: pass out break end on ppp 1 proto icmp from any to 192.168.99.99 icmp-type echo inspect-state oos 1 t=10 c = 2 d = 2
Line 2: pass
The above example will cause PPP 1 (the GPRS interface) to be deactivated if
two (c = 2 & d = 2) ICMP PING (echo request) packets are sent to the
192.168.99.99 IP address and no ICMP PING (echo response) is received back
within 20 seconds (d=2 x t=10 = 20 seconds).
On the Sarian’s web
server navigate to the Configure à PPP Instance 1 à Advanced web page.
Set the “PING IP
address:” parameter to an address that the Sarian should be able to
Enter the interval
in seconds at which the Sarian is to send a ping into the “PING request
interval (s)” parameter (e.g. 60 seconds).
Now enter the time
in seconds that the Sarian will wait for a reply to one of the pings into the
“No PING response reset delay (s):” parameter. (e.g. 65 seconds which means
wait 60 seconds after sending the first ping and an extra 5 seconds in case we
receive a reply to the second ping within five seconds.) With this
configuration, if the Sarian does not receive a reply to 2 pings in row then
the PPP 1 link will be deactivated.
Although it should
never be necessary to reboot a Sarian to recover from a problem, some customers
like to configure the Sarian to reboot itself if PPP fails to activate a number
of times.
This can be
achieved by setting “Reboot after this many consecutive failed connections:” to
a value other than 0. If you choose to use this facility please ensure the
value is significantly higher than the Configure à GPRS module àSIM 1 “Link Retires” parameter. (i.e. at
least double)
Another useful
feature which can be employed to improve the robustness of a GPRS\Edge solution
is the “Thinish Image”. Should for any reason the Sarian's flash become
corrupted (very rare) the Sarian has the capability of booting to a
"thinish" image. A "thinish" or small backup image is a
software build and configuration that is stored contiguously in the Sarian’s
flash. As it is contiguous it can be found by the boot loader even in the event
that the main flash directory is completely corrupted.
This "thinish
image" should have a configuration "compiled" into it so that
should the unit's flash become corrupted (this could happen if the power were
turned off during a firmware upgrade for example) you would still be able to
connect to your Sarian and fix it remotely.
Such a
configuration should contain only the bare essentials for connecting to the
GPRS network and allowing you to access the unit remotely. One such
configuration would be to enable the UDP heartbeat functionality. (This is a
PPP 1 advanced parameter.) The Sarian can be configured to send a UDP heart
beat containing its current IP address and serial number to a fixed IP address
thus allowing it to be contacted remotely and fixed.
Such a “thinish”
image should probably only be considered for use in a large project with many
remote Sarian devices. Please contact Sarian support to obtain a “thinish”
image for your configuration.
More details on all
the above can be found on the Sarian web site in application note 7.
To enable the Saran
to respond to SMS messages configure the following parameters:
Configure à GPRS Module à SIM 1
Set the “SMS
polling interval” to 1.
Set the "SMS
concatenation limit” to 0.
Set the “SMS
command caller ID” parameter to * or match the “trailing digits” of your mobile
phone number,
The Sarian will
respond to any CLI command, but the following commands will be especially
useful:
gstatus
modemcc 0 ?
reboot
VRRP is an internet
standard defined by RFC2338 (http://www.faqs.org/rfcs/rfc2338.html)
and to quote the RFC:
“VRRP specifies an election protocol that dynamically assigns
responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP
address(es) associated with a virtual router is called the Master, and forwards
packets sent to these IP addresses. The
election process provides dynamic fail over in the forwarding responsibility
should the Master become unavailable.
This allows any of the virtual router IP addresses on the LAN to be used
as the default first hop router by end-hosts.
The advantage gained from using VRRP is a higher availability default
path without requiring configuration of dynamic routing or router discovery
protocols on every end-host.”
To paraphrase, VRRP
works by setting up a Virtual Router - a 'floating' IP Address that clients can
use as their default gateway/next hop which transparently swaps between devices
in case of failure.
In this case,
‘failure’ refers to the loss of the complete unit i.e. physical redundancy; it
does not take into account the status of the connections behind the router.
VRRP+ is an
extension to VRRP developed by Sarian Systems, it allows other devices to be
monitored and alter the priorities of the VRRP routers. For example, if a host becomes unreachable on
the far end of a network link then the default router can be changed by
adjusting the VRRP priority of the router connected to that failing link.
In this case we are
able to achieve logical redundancy in addition to the physical redundancy
provided by basic VRRP and fail over based on the status of connections behind
the router.
As defined in
RFC2338.
|
VRRP Router |
A router running the
Virtual Router Redundancy Protocol. It may participate in one or more virtual
routers. |
|
Virtual Router |
An abstract object
managed by VRRP that acts as a default router for hosts on a shared LAN. It
consists of a Virtual Router Identifier and a set of associated IP
address(es) across a common LAN. A VRRP Router may backup one or more virtual
routers. |
|
IP Address Owner |
The VRRP router that has
the virtual router's IP address(es) as real interface address(es).This is the
router that, when up, will respond to packets addressed to one of these IP addresses
for ICMP pings, TCP connections, etc. |
|
Primary IP Address |
An IP address selected
from the set of real interface addresses. One possible selection algorithm is
to always select the first address. VRRP advertisements are always sent using
the primary IP address as the source of the IP packet. |
|
Virtual Router Master |
The VRRP router that is
assuming the responsibility of forwarding packets sent to the IP address(es)
associated with the virtual router, and answering ARP requests for these IP
addresses. Note that if the IP address owner is available, then it will
always become the Master. |
|
Virtual Router Backup |
The set of VRRP routers
available to assume forwarding responsibility for a virtual router should the
current Master fail. |
VRRP routers are
organised into groups which are identified with a Group ID, all VRRP routers
within the group should be able to provide the same routing and hence act as
fallbacks to each other.
In VRRP routers do
not communicate with each other – they only need to be aware of failures in the
virtual master router. To achieve this,
the virtual master router sends out multicast 'I am alive' announcements which
are listened to by the virtual router backup devices in the same VRRP group.
If an announcement
is not received by the virtual router backup within an allotted time (usually 1
second) then it will assume control and start announcing itself as the virtual
master router. If there are multiple
virtual router backups then the one with the highest priority will take over.
VRRP routers have a
priority of which the highest number will become the virtual master
router. This ranges from 1 to 255 and
usual settings are to use 255 for the highest priority and 100 for the backup
priority.
If the current
virtual master router receives an announcement from a group member with a
higher priority then it will pre-empt that device and become the virtual master
router.
The Sarian VRRP
implementation is fully RFC complaint and will work with other vendors VRRP
implementations providing they are also RFC compliant.
You can implement
VRRP on the Sarian units in a number of different ways depending on
requirements.
This uses a single
Virtual IP address shared between two units.

This will mean that
the IP Address 10.1.4.254 is not assigned to any one unit but floats between
them depending on which is the VRRP master router. If both ETH0 interfaces are connected to
hub/switch along with a client then the client will be able to always see a
router at the 10.1.4.254 address.
Unit_1 has a
priority of 110 so should become the VRRP master router over Unit_2 which has a
lower priority of 100.
This is the simplest configuration but it is not generally
adopted as it means that you can only attach to the unit that is the VRRP
master at any one time which is no good for administration and monitoring of
both the units.
A more common
solution would be to have an IP address for each unit and then a third address
for VRRP e.g.

So as before the
10.1.4.254 VRRP address floats between the two routers on ETH1 and can be used
by the clients as a default gateway, but the routers can also be reached on
their own IP addresses on ETH0.
See the next
section for restrictions on this configuration.
Depending on the
Sarian model you have means you can implement VRRP in different ways, if you
have a unit with a single LAN port (e.g. IR2140) then you can use ETH0 and ETH1
in the configuration above, if you have a unit with multiple ports (e.g.
IR2420) in ‘Hub Mode’ then the same applies.
If you are using a
multi port unit in ‘VLAN Mode’ then you will need to provide a second uplink
for the VRRP-addressed port:

NOTE: Do not try this configuration in ‘Hub Mode’
otherwise a network loop will form with undesirable consequences.
This may not be
practical so a better solution would be to keep the unit in Hub Mode and use
the Group feature to make each port a member of a different hub group but have
the ETH0 and ETH1 ports in the same group for VRRP.
VRRP+ is an
innovation of Sarian Systems and allows VRRP to be extended to provide
intelligent fail over scenarios.
For example, if you
have two routers that connect to the internet, a DSL router and an ISDN router
that you want to use as backup.

In addition to the
ISDN router taking over if the DSL router fails completely it is also desirably
to swap over if the DSL line fails or the DSL ISP has some kind of fault to
prevent access to the Web Site Host.
To achieve this the
DSL router is set to use VRRP+ probing to send ICMP (ping) packets to the web
site host on 192.32.42.133.
In the event of a
failure of a ping, the VRRP Priority on the DSL Router will be decremented by
20, giving it a VRRP priority of 90.
This makes it lower than the priority of the ISDN router (100) will
cause the ISDN router to become the VRRP Master Router and take all the traffic
bound for the internet.
In addition to this
the DSL router (which is now a VRRP Backup Router) will attempt to periodically
contact the Web Site Host via ICMP and upon restoring the connection the VRRP
Priority will be restored to 110 and the DSL router will once again become the
VRRP Master Router.
It is possible that
the Web Site Host is behind a firewall and configured not to respond to ICMP
(ping) requests, this can be overcome by setting the router to probe port 80
(HTTP/Web) on the Web Site Host instead.
Configuration can
be achieved by the command line interface (CLI) or the web server.
The CLI can be
accessed locally through the serial port or remotely over telnet, v120 and
X.25.
The main configuration files are:
·
config.da0
·
fw.txt
·
sregs.dat
·
x3prof
·
logcodes.txt
Configuration files
can be loaded via FTP whenever an IP connection is available or by Xmodem
whenever a CLI session is available.
“All Entity à Entity Instance à Parameter Name à Parameter Value” style configurations are
stored in the config.da0 file. All the commands in this file are automatically
programmed into the Sarian when it boots up. The config.da0 file stores all the
changes to parameters from the Sarian’s “software defaults”. (NB The software
defaults are not the same as the factory defaults which can be found in the
config.fac read only file.)
The “config c show”
command shows the current running configuration. The “config 0 show” or the
“type config.da0” commands show the current saved configuration.
Configuration
changes to the configs.da0 file can be saved from the command line with the
“configs 0 save” command or from the web server by clicking on the “Save
current config to config 0” OK button.
The fw.txt file
contains the saved version of the firewall script.
The sregs.dat file
contains the ASY port s-register settings. Saving this file from the command
line and the web was demonstrating in the practical session.
The X3prof file
contains the X.25 profile settings required by PAD.
Logcodes.txt is
considered partly a configuration file and partly firmware file. For this
reason it must be updated whenever the firmware is upgraded.
This is known as
the event logger definitions file. The file is used to convert events to a
“human readable” form when the event log is viewed. By changing values in here
the user can give different priorities to all the events that can occur. One
reason this is needed is to control the triggering of automatic emails, SMS
messages or SNMP traps.
As a test rename
eventlog.txt to eventlog.old and then try to view the Sarian’s event log.
Many important
settings can be found on the Configure à General web page. The command line
equivalent of viewing this page is:
cmd 0 ?
The Configure à Users web page is used to store username
and password combinations and control access.
Remote management
of all Sarian products is easy whether the unit is located locally or remotely.
A combination of the telnet server, ftp server and web server are normally used
to manage a Sarian remotely.
The following
output of the dir is an example of a set of files you might find on an MR2110:
ss23532>dir
direct 15360 ro 17:17:03, 25 Apr 2005 CRC 131a
sbios 131072 ro 01:57:40, 09 May 2005 CRC f782
mirror 15360 ro 17:17:05, 25 Apr 2005 CRC 0000
image4.c2 118824 rw 17:21:58, 25 Apr 2005 CRC 8ed4
image 1145211 rw 17:19:30, 25 Apr 2005 CRC f8c4
sregs.dat 1680 rw 02:18:19, 09 May 2005 CRC 35d7
x3prof 1680 rw 17:19:57, 25 Apr 2005 CRC d99e
LOGCODES.TXT 12903 rw 17:22:02, 25 Apr 2005 CRC b8b4
N4763wDS.web 549317 rw 17:22:18, 25 Apr 2005 CRC 4e79
config.da0 1856 rw 10:01:27, 29 May 2005 CRC 4658
config.fac 1806 ro 17:22:25, 25 Apr 2005 CRC 339f
fwstat.txt 200 ro 12:24:32, 29 May 2005
fwstat.htm 2500 ro 12:24:32, 29 May 2005
fwlog.txt 100 ro 12:24:32, 29 May 2005
eventlog.txt 50601 ro 12:24:32, 29 May 2005
statbin.enc 60000 ro 12:24:32, 29 May 2005
ana.txt 1000000 ro 12:24:32, 29 May 2005
Flash Used: 1995069 Bytes, Flash Free: 2166784 Bytes
OK
Every file with a CRC entry is stored on the Sarian’s flash. Any files without
a CRC are stored in memory not flash. These are known as pseudo files. As the
content of these files is dynamic the size reported by the dir command is an
approximation only and may not reflect the size of the file if you try to download
it.
The “direct” and
“mirror” files are not actually files but a representation of the Sarian’s file
allocation tables. “direct” is the main file allocation table and “mirror” is a
backup. If the main table is corrupted it will be replaced automatically by the
mirror.
The filenames for
various firmware items can vary by version number. The main two firmware files
always have the same name though:
sbios
image
The sbios file is
the boot loader. This is the first code executed by the processor when the unit
is powered up or rebooted. During boot up it is the boot loader that causes the
DAT or B2 LED to flash.
The image is the
main firmware file. The image file includes the operating system and the
application.
image4.c2
N4763wDS.web
logcodes.txt
image4.c2 is a backup application. This application is stored in the Sarian’s
flash contiguously. This application will be run in the event of total flash
corruption or corruption of the main image. The “4” in the file name can change.
This refers to the image number. You can
tell the Sarian which image number to run with the “inum <n>” command and
then rebooting. (Where n is the image number.) If the Sarian is running any
image other than “0” (i.e. image) it will reboot every few minutes to try and
run image number 0. The “c” in the filename instructs the Sarian to store the
file contiguously in the flash. The “2” means that exactly 2 contiguous sectors
are to be reserved for this file.
N4763wDS.web contains all the files required by the web
server. This can be any file with the
.web extension. In the file name above the meaning of the other letters and
numbers is as follows:
N = This web file
is for the MR2110
4763 = This web
file is for firmware version 4.763
w = This web file is for the “wireless switch” version of firmware
DS = This web file
is for the MR2110 with two SIM slots. (DS = Duel SIM)
NB The rules for
naming the .web file can vary between products and firmware versions.
logcodes.txt is the event logger definitions files. It
contains the definition of all events that can appear in the Sarian’s event
log. Although this is a firmware file it can be edited by the user to change
the priorities of events.
Copying firmware
and configuration files from one Sarian to another can be achieved via the FTP
and telnet servers.
Full instructions
for downloading firmware and upgrading a Sarian via FTP can be found on the
following web page: http://www.sarian.co.uk/support/ftp.html
During the training
as an exercise or demonstration a full set of firmware and configuration files
will be downloaded from one Sarian and uploaded to another.
Statistics can be
viewed from the command line and the web server. Currently most of the
statistics can only be reset by clicking the appropriate button on the
Statistics à web pages.
To view stats from
the command line use the “at\mibs=” command. For example to read the PPP 1
statistics:
ss23532>at\mibs=ppp.1.stats
stats.rxbytes = 232106
stats.rx_lcp = 1703
stats.rx_pap = 332
stats.rx_ipcp = 56
stats.rx_unknown = 0
stats.rx_crcerr = 0
stats.rx_frame_err = 1
stats.rx_error = 0
stats.txbytes = 128893
stats.tx_lcp = 1663
stats.tx_pap = 332
stats.tx_ipcp = 429
stats.tx_error = 0
stats.rx_bacp = 0
stats.rx_bap = 0
stats.tx_bacp = 0
stats.tx_bap = 0
OK
In large projects Remote Manager can be configured to collect statistics from
the remote Sarians and produce reports. This will be demonstrated later in the
course.
All Sarian models contain a powerful event handler. The event handler enables the Sarian to automatically send Emails, SMS messages or SNMP traps when certain events are logged in the event log.
A snapshot of the current analyser trace and event log can be attached to emails, this is an invaluable mechanism for fault finding.
The event handler will trigger an email, SMS message or SNMP trap if an event occurs with a trigger priority equal to or higher than the trigger level specified in Configure à Event Handler
The Sarian’s event log is not stored in the NVRAM in a “human readable” format. Instead it is dynamically expanded to a “human readable” format when it is read. The logcodes.txt file is used to provide most of the English (or other language) text when the event log is accessed.
As an experiment to help understand the way this works, try renaming the logcodes.txt file to another name and then try reading the event log.
The logcodes.txt file is known as the “event logger definitions file”. It contains a list of all the events and reasons that can be logged in the event log.
As an example consider event number 36, ISDN Call Cleared.
[EVENTS]
36,0,%e %a ISDN Call Cleared
[REASONS]
01,,Unallocated
03,,No route to dest
16,,
17,,User busy
18,,No user
19,,No answer
21,,Call rejected
34,,No cct
38,,Net oor
44,,Req cct not av
50,,Fac not sup
57,,Bearer not auth
58,,Bearer not avail
63,,Service not avail
88,,Incomp dest
90,,Dest incomplete
There are 16 different reasons listed for this event in logcodes.txt.
In the eventlog, the reason appears after the event like so:
15:10:01, 14 Jul 2005,PPP 7 ISDN Call Cleared,Unallocated


The first digit in a logcodes entry is always the event number. The second digit is the event trigger priority. In the above example the trigger priority for the event is 0. Changing:
36,0,%e %a ISDN Call Cleared
36,6,%e %a ISDN Call Cleared
Will change the trigger priority for this event from 0 to 6.
01,,Unallocated
to
01,6,Unallocated
will change the trigger priority from this event from 0 to 6 but only if the
reason the event was triggered is “Unallocated”.
The trigger priority you set for
the reason always overrides the global trigger priority set for the event.
It is also possible to change the
trigger priority based upon which instance of an entity created the event.
It is also possible to change the
trigger priority of an event based upon the entity and the entity instance.
Consider as an example the event
05,0,%e %a down
The above “down” events occurs when many different things happen. E.g. PPP 1
down or LAPB 0 down etc.
In most situations you would only
want to know if specific instances of say PPP went down. (e.g. PPP 1)
In order to give PPP 1 a higher
trigger priority (say 6) you would add another line to logcodes as follows:
05,6[a=1 e=ppp],%e %a down
Where “a=” specifies the instance (i.e. 1) and “e=” specifies the entity name
(i.e. PPP).
So the event log would contain two
entries for this event as follows:
05,0,%e %a down
05,6[a=1 e=ppp],%e %a down
When PPP 1 goes down it triggers
an email:
12:12:33, 18 Jul 2005,SMTP success
12:12:33, 18 Jul 2005,SMTP req by CMD email event.eml
12:12:33, 18 Jul 2005,
12:12:33, 18 Jul 2005,PPP 1 Out Of Service,Activation
12:12:33, 18 Jul 2005,PPP 1 down
When PPP 0 goes down it does not trigger an email:
12:12:30, 18 Jul 2005,IKE Request Received From Eroute 0
12:12:21, 18 Jul 2005,DTR Down ASY 0
12:12:21, 18 Jul 2005,DTR Up ASY 0
12:12:20, 18 Jul 2005,PPP 0 down,LL disconnect
The event handler configuration
web page (Configure à
Event Handler) consist of three sections.
The first controls the sending of emails, the second SNMP traps and the third
SMS messages. The third section is only present if you are using a Sarian with
a GSM module (e.g. capable of GPRS or Edge).
To configure the Sarian to send an
automatic email set:
“Max emails/day” to the maximum
number of emails you want the Sarian to send in any 24 hour period.
“Email template” to “event.eml”. “event.eml” is an email template built in to the Sarian. (It is actually stored in the .web file and can be viewed in Status à Web Directory.) You can create your own .eml template and upload it to the Sarians normal flash directory via FTP. If you do so you should specify the name of this file in the “Email Template” field. For more details on this see the reference manual.
“Email trigger priority” to the event trigger priority for which you want the Sarian to send emails. For example, if you set this value to 6, every event with trigger priority 6 and higher will trigger an email.
“Email To” enter the email address of the recipient.
“Email From” enter the name of the unit sending the email e.g. “Sarian1”
“Email Subject” enter the text to be used in the subject field of the email.
It is also necessary to configure the SMTP server under Configure à SMTP
Configure the “Mail from address:” to an email address from which the mail server you are connecting to will allow you to send email. (Usually this can be any email address you like i.e. it does not usually have to be real)
Configure the “Retry delay” to a value in seconds e.g. 30, if you wish the Sarian to try sending the email once, should a problem occur.
Configure the “Server address” to
the IP address or host.domain name of the SMTP server.
Finally either set “Use routing
code to determine interface” to “Yes”, or explicitly configure an interface to
use to send the email using the “Interface” and “Interface #” parameters.
To configure the Sarian to send an
SNMP trap when an event with suitable trigger priority occurs, under Configure
à Event Handler,
configure:
“Max SNMP traps/day” to the
maximum number of SNMP traps you want the Sarian to send in any 24 hour period.
“SNMP trap trigger priority” to the event trigger priority for which you want the Sarian to send an SNMP trap. For example, if you set this value to 6, every event with trigger priority 6 and higher will trigger an SNMP trap.
It is also necessary to configure the “SNMP trap destination address” on the Configure à General web page to the IP address of the SNMP server.
To configure the Sarian to send SMS messages, on the Configure àEvent Handler page set the:
“Max SMS/day” to the maximum
number of SMS message you want the Sarian to send in any 24 hour period.
“SMS trigger priority” to the event trigger priority for which you want the Sarian to send an SMS message. For example, if you set this value to 6, every event with trigger priority 6 and higher will trigger an SMS message.
“SMS template” to “event.sms”. “event.sms” is an sms template built in to the Sarian. (It is actually stored in the .web file and can be viewed in Status à Web Directory.) You can create your own .sms template and upload it to the Sarians normal flash directory via FTP. If you do so you should specify the name of this file in the “SMS Template” field. For more details on this see the reference manual.
“SMS destination” to the mobile number you want the sms messages to be sent to. Numbers must start with the country code and have the leading zero from the area code deleted.
e.g. to send a message to the number 07974 234567 in the
447974234567
If you wish the Sarian to be able to receive SMS messages then it is also
necessary to configure two parameters on the Configure à
GPRS Module page, set:
“SMS polling interval (mins)” to “0”
“SMS command caller ID” to “*” to accept messages from all numbers, or to the mobile phone number you wish to only accept messages from. (In the same international format as above)
In the case of sending automatic
emails, an additional two letters can be added immediately after the trigger
priority and before the comma in logcodes.txt. This determines the email
attachments, “e” means attach an event log, and “a” means attach an analyser
trace.
For example:
36,6ae,%e %a ISDN Call Cleared
The above entry will cause an analyser trace and event log to be attached to
the automatic email.
If you find that a large number of “un-interesting” events fill up your event log, the Sarian can be configured to exclude these events from the log.
To do this enter an “L<level>” tag into the priority field of an event or reason in logcodes.txt
For example to exclude the event “GP socket connected”
Change the line in logcodes.txt from:
181,0,GP socket connected: %c
to
181,0L9,GP socket connected: %c
Next set the Configure à
Event Handler parameter “Maximum event priority to log” to the value 8.
Thus this event with log priority of 9 will no longer be logged in the event
log.
It is sometimes necessary to “freeze” the analyser trace whilst an automatic email is sent. (In order to prevent the trace from being filled up with the traffic generated by the Sarian actually sending the email.
For example change:
36,6ae,%e %a ISDN Call Cleared
to
36,6afe,%e %a ISDN Call Cleared
In order to help diagnose a TPAD OLA fault, two events are included which should occur whenever anything goes wrong with an OLA. To use these events to trigger an email, configure the Event Handler and SMTP client as necessary (i.e. to send an email for event with trigger priority 6 and higher) and then change the following two lines in logcodes.txt:
68,0,%e %a X25 Call gone
69,0,%e %a X25 Deactivated
to
68,6afe,%e %a X25 Call gone
69,6afe,%e %a X25 Deactivated











An X.25 PVC or Permanent Virtual Circuit is the X.25 equivalent of a leased line. It allows data to be sent at any time without the need for a layer 3 X.25 call to be made. You can just start sending and receiving data on the specified LCN.
Any of the X.25 applications in the Sarian (TPAD, PAD and X.25 Switch) are able to terminate an X.25 PVC.
The Sarian firmware currently supports the use of up to 4 PVC sessions simultaneously.
Typical configuration parameters to achieve this are listed below for discussion during training:
LAPB 0 configures port 0 for syncronous operation:
lapb 0 dtemode 0
lapb 0 ans OFF
lapb 0 l1iface "Port"
PVC 0 is the PVC used over the serial link:
pvc 0 lcn 200
pvc 0 l2iface "LAPB"
pvc 0 uliface "XSW"
pvc 0 psize 7
pvc 0 window 2
PVC 1 is the PVC used over the xot link:
pvc 1 lcn 100
pvc 1 l2iface "TCP"
pvc 1 IPaddr "10.0.0.2"
pvc 1 iniiface "Serial1/2"
pvc 1 respiface "Serial1/2"
pvc 1 psize 7
pvc 1 window 2
The X.25 Switch must switch the LAPB 0 PVC to the XOT PVC
x25sw 0 swfrlapb0pvc 8
The X.25 Switch must switch from the XOT PVC to the LAPB PVC
x25sw 0 swfrxotpvc 6
x25sw 0 lapb0wpar 2
x25sw 0 lapb0ppar 7
x25sw 0 lapb1wpar 2
x25sw 0 lapb1ppar 7
The firewall “stat”
keyword can be used to collect various transaction style statistics on TCP and
UDP traffic that the Sarian routes. When used in conjunction with the UDP echo
server and Remote Manager this is especially useful on GPRS or Edge networks as
it allows the performance of the network to be monitored and automated reports
to be generated every day. This feature can be used to police an
On Configure à UDP Echo Client/Server à UDP Echo 0
Set the following
parameters:
The address to send
the UDP packets to. Normally this would be a Sarian running the Echo server. It
could be any PC at the head-end. If an IPSEC tunnel is in use it is advisable
to set the destination address to an address that will cause the UDP packets to
go through the tunnel. The Configureà General
“GP sockets use IP from interface” and “GP sockets use IP from interface
#” parameters can be used to set the source IP address of the UDP packets to an
Ethernet interface to ensure that they go through the tunnel.
This can be any
valid unused port number if the destination IP address is another Sarian. If
the destination is a PC then the echo port number should be used which is 7.
Configure this to a
suitable interval. A popular value would be between 30 and 80 seconds but any
value is acceptable.
Use
routing code to determine echo interface:
Set to yes.
If you are using a
Sarian as the echo server at the head end, then navigate to Configure à UDP Echo Client/Server à UDP Echo 0 and configure the parameter “
On the echo client
remote Sarian ensure that the firewall is turned on for the appropriate WAN
interface. Enter a firewall rule similar to the following:
pass out break end
on ppp 1 proto udp from any to <Echo server IP address> port = 7
inspect-state oos 1 t=60 c=5 d=5 stat
And a second rule
to allow other traffic to route:
pass
The firewall rule
will cause the Sarian to collect the following statistics based upon the
performance of the UDP stat bins.
|
Successful Transaction Count |
0 |
|
Dropped Transaction Count |
0 |
|
Route OOS Count |
0 |
|
Minimum Transaction Time (ms) |
0 |
|
Maximum Transaction Time (ms) |
0 |
|
Average Transaction Time (ms) |
0 |
These stats can be
seen on the Statistics à PPP à PPP 1 web page.
In addition to the
stats visible on the web page, the Sarian will automatically store these same
statistics in statistic bins.
A single statistic
bin contains one hours worth of data. Every hour on the hour a new bin is
created. This allows the Sarian to keep a historical record of the performance
of the network hour by hour. Remote Manager can be used to collect the data in
the stat bins and draw graphs and reports.
Statistic bins are
encrypted but can be accessed via the “statbin.enc” file.
In order for the Sarian to make GSM CSD calls to ISDN/POTS your SIM must be enabled for data services by your network operator.
In order for the Sarian to receive GSM CSD calls from ISDN/POTS your SIM must also be enabled to accept incoming data services on a data number by your network operator.
Most normal GSM SIM’s are not enabled for any data services by default. Please check with your network operator before attempting to configure devices.
CSD data calls differ significantly from normal point-to-point ISDN or POTS calls as they rely on using equipment at the network operator to provide access to the services.
For example, when a GSM data call is going out to a POTS/ISDN device the GSM device does not actually dial this number, this is done by the modem interworking function at the Mobile Switching Centre (MSC) of the network operator and the data is then relayed over the GSM network back to the device.
These connections are called non-transparent i.e. the link is not a dedicated tunnel and utilises a special GSM error correction/flow control facility called Radio Link Protocol (RLP).
RLP does add an amount of overhead but it ensures successful data delivery over the GSM parts of the link.
For example, the order of the call from a GSM device to a POTS would be something like:
|
GSM Device |
Network Operator |
POTS device |
|
Dial Number è |
Makes Call è |
è Number rings |
|
|
|
ç Answers |
|
|
Modem Speed Negotiation è |
ç Modem Speed Negotiation |
|
|
Connect Indicationç |
ç Connect Indication |
|
Connect RLP ç |
ç Connect Indication |
|
|
|
|
|
|
Data è |
Data converted and relayed è |
è Data |
|
Data ç |
ç Data converted and relayed |
ç Data |
As can be seen there are actually two sets of connections – the GSM to the Network Operator and the Network Operator to the POTS device with the data being relayed between the GSM RLP link and the normal POTS analogue link.
Note that the speed at which the Network Operator connects to the POTS device will normally be at whatever is set from the GSM device data bearer i.e. 9600/14400bps, however the Network Operator is able to convert between speeds if the POTS device runs at a higher data rate than the GSM device can support.
Also if the POTS device cannot answer then a BUSY/NO CARRIER indication will be relayed back to the GSM device and the call terminated.
For a GSM device to an ISDN device would be similar but with the benefit of faster call setup from ISDN.
|
GSM Device |
Network Operator |
ISDN device |
|
Call Setup è |
Call Setup è |
è Call Indication |
|
|
Connect Indicationç |
ç Connect Indication |
|
Connect RLP ç |
ç Connect Indication |
|
|
|
|
|
|
Data è |
Data converted and relayed è |
è Data |
|
Data ç |
ç Data converted and relayed |
ç Data |
A Sarian can make calls to GSM, POTS and ISDN using V.110 rate adaptation or PPP over V.110, PPP is most common and is discussed here.
Should be supported by default when Data Services are enabled.
With Data Services enabled you will be able to call ISDN and POTS numbers but your network operator may require you to set the ‘Bearer Service’ on the Sarian to use.
Add the following into the Modem Init String 1 in Configure à PPP à External Modems à External Modem 0
+CBST=71,0,1 For 9600bps ISDN services.
+CBST=75,0,1 For 14400bps ISDN services.
+CBST=7,0,1 For 9600bps Analogue Services
+CBST=14,0,1 For 14400bps Analogue Services

A Sarian will accept calls from POTS or ISDN with V.110 rate adaptation or PPP over V.110, PPP is most common and is discussed here.
The factory configuration of the Sarian will allow incoming PPP calls but PPP 0 (the accepting PPP interface) must be configured to accept calls from the GSM module.