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.

1.3 Logging and Tracing.

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.

2.0 PPP and GPRS

2.1 Introduction to PPP

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.

2.2 PPP Operating Modes

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”.

2.3 PPP Parameters

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.

2.4 GSM / GPRS Module.

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

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

2.5 Essential PPP parameters

Local IP address
Remote IP address pool minimum
Nat Mode
Request IPCP local address option
Request local PAP authentication
Request local CHAP authentication
Request IPCP remote address option
Request remote PAP authentication
Request remote CHAP authentication

2.6 Tracing a PPP negotiation

The various PPP options are negotiated via LCP.

Once authentication has occurred IP address assignment will normally take place via the NCP protocol IPCP.

2.7 The MC45 monitor

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.

2.8 Internet and private APNs

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.

2.9 Private and Public IP addresses

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 UK it is possible to use special APNs with some mobile operators in order to receive a public Internet IP address. However in these cases there is usually a strict firewall in place that prevents “any old packet” with the Sarian’s IP address from being routed to the Sarian. Only if the Sarian initiates the connection are packets allowed to return. This means that it is not possible to connect to the Sarian’s web or telnet interface from Internet or even send packets to devices connected to the Sarian’s LAN.

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.

2.10 GPRS and Edge

*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.

GPRS Coding Schemes

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

Edge Coding Schemes

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

Multi-slot Classes

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

GPRS experience

“Real life experience” has shown that data rates of 10-20kb/s down and 30–40kb/s up are more realistic in the UK.

Edge experience

Some customers in Holland have achieved 170kb/s downloading on a test cell. We’ve seen 130 – 160 on real networks.

Determining the coding scheme and time slots in use

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.

3.0 Routing

3.1 Ethernet Interface

Static Configuration

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.

IP Address
Mask
Gateway

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.

Ethernet as a DHCP client.

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.

3.2 DHCP Server

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.

3.3 Routes

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

------------------------------------------------------------

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

Dynamic routes are created automatically whenever an Interface has an IP address and mask configured.

Static Routes

Static routes are configured by the user and allow destination networks or subnets to be routed via a certain interface or gateway.

Default Routes

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.

3.4 Metrics

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

3.5 Out of service timer

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.

3.6 Always on Interface

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.

3.7 NAT

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.)

3.8 Dynamic Routes by Authentication

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.

3.9 Tracing IP traffic

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.

3.10 E-Routes

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.

4.0 Firewall

Remember to read the “Firewall Scripts” section in the manual.

Also see the TN_SRI_Recovery_draft_1.0.doc document provided.

5.0 Automatic GPRS Recovery

5.1 Problem detection

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.)

5.2 GPRS Module Power Cycle

In order to recover from:

A GSM module problem,
A problem with the GSM network that requires the module to de-register and re-register

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.

5.3 Statefule Rule Inspection

Three examples of SRI firewall rules follow:

TCP

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.

UDP

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.

ICMP PING

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).

5.4 Automatic PPP PING

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 PING over the GPRS network.

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.

5.5 Sarian Unit Reboot

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)

5.6 Thinish Image

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.

5.7 Reboot by SMS

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

6.0 VRRP

6.1 What is VRRP ?

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.

6.2 What is VRRP+ ?

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.

6.3 VRRP Definitions

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.

6.4 VRRP Operation

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.

6.5 VRRP Interoperability

The Sarian VRRP implementation is fully RFC complaint and will work with other vendors VRRP implementations providing they are also RFC compliant.

6.6 VRRP Implementation

You can implement VRRP on the Sarian units in a number of different ways depending on requirements.

Single VRRP IP Address

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.

Dedicated VRRP IP Address

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.

Model Considerations

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.

6.7 VRRP+ Implementation

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.

7.0 Configuration Essentials

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.

7.1 Configuration Files

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.

config.da0

“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.

fw.txt

The fw.txt file contains the saved version of the firewall script.

sregs.dat

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.

x3prof

The X3prof file contains the X.25 profile settings required by PAD.

logcodes.txt

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.

7.2 General Page

Many important settings can be found on the Configure à General web page. The command line equivalent of viewing this page is:

cmd 0 ?

7.3 Users Page

The Configure à Users web page is used to store username and password combinations and control access.

8.0 Remote Management

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.

8.1 Filenames

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

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

sbios

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.

image

The image is the main firmware file. The image file includes the operating system and the application.

Other firmware files:

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.

8.2 Uploading and Downloading

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.

8.3 Reviewing Statistics

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

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.

9.0 Event Handler

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

9.1 Event log and logcodes.txt

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.

9.2 Events & reasons in logcodes.txt

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,,Normal clearing

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.

Changing

01,,Unallocated

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.

Changing the trigger priority based upon the entity instance.

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,Default Route 0 Out Of Service,Activation

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

9.3 Configuring the Event Handler

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).

Emails

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.

SNMP Traps

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.

SMS Messages

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 UK set this field to

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)

9.4 Email Attachments

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.

9.5 Excluding events from the Event Log

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

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.

9.6 Freezing the Analyser Trace

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.

To do this insert an “f” character after the “a” (not the 'e' - we do not ever freeze the event log).

For example change:

36,6ae,%e %a ISDN Call Cleared

36,6afe,%e %a ISDN Call Cleared

9.7 Using automatic emails to diagnose OLA faults.

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

68,6afe,%e %a X25 Call gone

69,6afe,%e %a X25 Deactivated

10.0 IPSEC

11.0 PVCs

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.

11.1 PVC with PAD

11.2 PVC from SYNC port 0 to a Cisco over XOT

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

12.0 UDP Echo Server and Statistics bins

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 SLA (Service Level Agreement).

12.1 Configuring the UDP Echo client

On Configure à UDP Echo Client/Server à UDP Echo 0

Set the following parameters:

Destination IP address

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.

Destination port

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.

Echo request interval (s)

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.

12.2 Configuring the UDP Echo Server

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 “Local Port” to be the port number you choose as “Destination Port” in the remote Sarian.

12.3 Configuring the Firewall

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.

12.4 Statistic Bins

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.

13.0 Making and Receiving CSD Calls

13.1 Ensure your SIM is data enabled.

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.

13.2 Technical Summary

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

13.3 Making outgoing calls from the Sarian

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.

GSM to GSM

Should be supported by default when Data Services are enabled.

GSM Dial Out to ISDN & POTS

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

13.4 Accepting incoming calls on the Sarian

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.

Table of Contents

GPRS Coding Schemes

Edge Coding Schemes

Multi-slot Classes

GPRS experience

Edge experience

Determining the coding scheme and time slots in use

Static Configuration

Ethernet as a DHCP client.

Dynamic Routes

Static Routes

Default Routes

Remember to read the “Firewall Scripts” section in the manual.

Also see the TN_SRI_Recovery_draft_1.0.doc document provided.

TCP

UDP

ICMP PING

5.4 Automatic PPP PING

Dedicated VRRP IP Address

config.da0

fw.txt

sregs.dat

x3prof

logcodes.txt

sbios

image

Other firmware files:

Changing the trigger priority based upon the entity instance.

Emails

SNMP Traps

SMS Messages

Destination IP address

Destination port

Echo request interval (s)

GSM to GSM

GSM Dial Out to ISDN & POTS