internet protocol suite on central processor

Ericsson Internal USER GUIDE 1 (38)

Prepared (also subject responsible if other) No.

EDD/XDT Jörg Bruss 44/1553-AXE 106 30/6 Uen Approved Checked Date Rev Reference

EDD/XMS Hendrik Esser PC-MSC 9/2/2008 B

Internet Protocol Suite on Central Processor

Abstract

This document provides guidelines for configuring the Internet Protocol stack for the VoIP application on the MSC server node.

Copyright

© Copyright Ericsson AB 2008. All rights reserved.

Disclaimer

The contents of this document are subject to revision without notice due to continued progress in methodology, design, and manufacturing.

Ericsson shall have no liability for any errors or damages of any kind resulting from the use of this document.





Contents 1 Introduction ............................................................................................4

1.1 Revision History .........................................................................4 1.2 Purpose......................................................................................6 1.3 Prerequisites ..............................................................................6

2 General Information...............................................................................7 2.1 Overview ....................................................................................7 2.2 Scope .........................................................................................7 2.3 Introduction ................................................................................7 2.3.1 Protocol Suite.............................................................................7 2.3.2 The Node Internal Ethernet Switching Planes ...........................8 2.3.2.1 APZ 212 40 ................................................................................9 2.3.2.2 APZ 212 50 ................................................................................9 2.3.3 Fault Resilience........................................................................10 2.3.3.1 Local Fault Resilience ..............................................................10 2.3.3.2 Hardware Fault Resilience .......................................................11 2.3.3.3 Fault Resilient LAN Configuration ............................................11 2.3.3.4 Router Supervision...................................................................12 2.3.3.5 IP Address Migration................................................................12 2.3.3.6 DNS Fault Resilience ...............................................................13

3 How to Use............................................................................................15 3.1 Preparation of the Site LAN Switches ......................................16 3.1.1 Requirements on the Site LAN Switches .................................16 3.1.2 Configuration of Site LAN Switch .............................................16 3.1.2.1 VLAN Separation .....................................................................16 3.1.2.2 Port Speed and Duplex Mode ..................................................17 3.1.2.3 Packet Filtering ........................................................................17 3.2 Configuring the Ethernet Switching Planes..............................18 3.2.1 Bringing the ESSB into Managed Mode...................................18 3.2.2 Defining the Signaling VLAN on the Switching Planes ............18 3.2.2.1 Defining the Internal Communication VLAN.............................19 3.2.2.2 Using Untagged Frames on the External ESSB Port (Port

Based Tagging)........................................................................20 3.2.2.3 Using Tagged Frames on the External ESSB Port ..................21 3.2.3 Ethernet Link Speed Configuration ..........................................21 3.3 Ethernet Interface Configuration ..............................................22 3.3.1 The Purpose of Virtual Ethernet Interfaces ..............................22 3.3.2 Virtual Interface Definition ........................................................22 3.4 IP Layer Configuration .............................................................23 3.4.1 Adding an IP Address to a Virtual Interface .............................23 3.4.2 Changing an IP Address ..........................................................23 3.5 Fault Resilient Configuration ....................................................25 3.6 IP Route Configuration.............................................................26 3.6.1 Route Types.............................................................................26 3.6.1.1 Default Routes .........................................................................26 3.6.1.2 IP Routes with Interface Property ............................................27 3.6.1.3 IP Routes with Source Address Property.................................27 3.6.2 General Recommendations .....................................................27 3.6.3 Recommendations for Specific DNS Routes ...........................28





3.7 Example Configuration.............................................................29 3.7.1 Preparation of the Site LAN Switches ......................................29 3.7.2 Internal Switch Plane Configuration .........................................30 3.7.3 Virtual Interface Definition ........................................................30 3.7.4 Add IP Address to Virtual Interface ..........................................30 3.7.5 Enabling Router Supervision and Address Migration...............31 3.7.6 Route Configuration .................................................................31 3.7.6.1 Default Route Configuration.....................................................31 3.7.6.2 Adding DNS Specific Routes ...................................................32

4 Glossary................................................................................................33 4.1 Concepts ..................................................................................33 4.2 Abbreviations ...........................................................................34

5 References............................................................................................36 5.1 User Guides .............................................................................36 5.2 Command Descriptions............................................................36 5.3 Printout Descriptions ................................................................37 5.4 Operational Instructions ...........................................................38 5.5 Other Documents .....................................................................38





1 Introduction

1.1 Revision History

Table 1. Revision History

Rev Date Prepared Description

PA1 2007-11-05 EDDJBR First Draft, based on the revision PA6 of the corresponding APZ UG on the subject.

PA2 2008-03-05 EDDJBR Complete modification on the document based on 1/3rd review.

All functional specifications are removed from the section �Introduction�.

All OPI like descriptions formerly included in the section �How to Use� are removed.

VoIP use case taken as an example.

PA3 2008-03-11 EDDJBR Editorial clean up.

PA4 2008-03-14 EDDJBR Updates after internal review.

Source IP routes are now subject to router supervision.

Recommendation on route priorities clarified.

Editorial updates.

Section on DNS Redundancy modified such that the 2nd example only applies to remote name servers.

Requirements on site switches extended.

Title modified slightly.






2008-04-15 EEDJBR ESSB configuration updated to new commands valid for ESSB.

2008-05-14 EEDJBR Use case for changing an IP address added.

Some editorial updates

PA5 2008-05-15 EDDJBR Recommendations on the usage of the port speed configuration of ESSB ports included.

Chu�s Comments included.

PA6 2008-06-26 EDDJBR DNS redundancy solution removed as it does not work. Instead, a model introducing two paths for DNS queries is described.

Correction in section 3.6.5.1:

Configuration line IHRHC:ADD, VIF=ETHA-201, DEFGW=10.0.1.2, PREF=63;

changed to IHRHC:ADD, VIF=ETHB-201, DEFGW=10.0.1.2, PREF=63;

PA7 2008-08-08 EDDJBR Update after PC-MSC review.

See Inspection Record EED/D 1776-2897 Uen for details. Additional editorial changes were made. DNS redundancy solution corrected in sections 3.5.3 and 3.6.5.2.

A 2008-08-15 EDDJBR Approved Revision.






PB1 2008-08-22 EDDJBR Corrections in section 3.1.1 such that it becomes clear that the site switch supports autonegotiation and is capable of supporting 10Mbps FD and 100Mbps FD.

Section 3.1.2.2 has been modified such that is clear that autonegotiation has to be enable on the site switch ports that connect to ESSB.

B 2008-09-02 EDDJBR Agreed with TeCo Peter Kemp to issue a revision B.

1.2 Purpose

This document provides guidelines for configuring the Internet Protocol stack on the MSC server node. It gives recommendations on certain aspects and gives an example configuration when using the SIP and SIP-I protocols of the INET stack aspects for a particular site configuration.

1.3 Prerequisites

• The user should have the common knowledge in TCP/IP networking.

• The user should understand the purpose of dividing an Ethernet LAN into VLANs.

• The user should be familiar with the Ericsson�s basic site configuration for IP-based node.





2 General Information

2.1 Overview

The MSC node supports various types of INET stack implementations for different purposes. There are INET stacks on the Central Processor for system internal communication to the IO system, on the IO system for communicating to the OSS, and INET stacks on the Regional Processors used for SS7oIP signaling.

In addition, there is an INET stack on the Central Processor for transporting SIP and SIP-I signaling and the associated DNS traffic. This stack is discussed in this document.

2.2 Scope

The aim of this document is to serve as a guideline on how to configure the INET stack on Central Processor used by SIP and SIP-I applications for MSC server nodes. Only selected topics are covered in the User Guide.

Examples are given for how to configure this INET stack with the signaling stack for SIP and SIP-I in mind. For details on the SIP and SIP-I applications, please refer to [2] on how to deploy SIP and SIP-I signaling on top of the INET stack on CP.

The DNS resolver function is needed for SIP calls. Please refer to [4] for how to configure the DNS resolver.

2.3 Introduction

2.3.1 Protocol Suite

An MSC node can be configured to support signaling transport over IP networks.

For an IP networking the MSC node uses Ethernet at Layer 21 (Data Link Layer). IPv4 is supported at Layer 3 (Internet Layer). At Layer 4 (Transport Layer), protocols UDP and TCP are supported.

Figure 1 gives an overview over the protocol stack and the application layer protocols using this stack. The figure does not show to which layers the different protocols belong to.

1 The TCP/IP model contains 5 layers: 1) Physical Layer; 2) Data Link Layer; 3) Network Layer; 4) Transport Layer; 5) Application Layer.





DNS SIP / SIP-I

UDP TCP

IP

Ethernet

ARP

ICMP

Figure 1 IP on CP Protocol Stack Overview

2.3.2 The Node Internal Ethernet Switching Planes

This section gives an overview of the node internal Ethernet connectivity as far as it is needed for understanding the Ethernet connectivity for the INET stack. All figures shown in the following on this issue are only example configurations for illustration purposes. Real configurations may differ in certain aspects and certainly include more components than the ones shown (for example Regional Processors are omitted in the figures).

The MSC node utilizes two Ethernet switching planes. These two switching planes are separated and have no connectivity among each other. The purpose of the switching planes is to provide a redundant communication between the node internal components such as the Central Processor, the IO system, and the Regional Processors.

A further purpose of the switching planes is to transport IP based signaling traffic between the node�s connection points to the external site Ethernet LAN and the Ethernet interfaces of the Central Processor.

The Ethernet interfaces of the CP are not directly accessible for connecting to the site LAN. Instead, these interfaces are connected via a node internal Ethernet switching infrastructure that eventually will provide dedicated switch ports on the ESSB for connecting to the site LAN. This is shown in the following subsections for the two APZ versions that support SIP and SIP applications.





2.3.2.1 APZ 212 40

Figure 2 is an example of a simplified hardware configuration for an MSC node using an APZ 212 40 Central Processor.

The Central Processor shown in the figure is hosting the INET stack. The IPNX functions act as the first level switch that connects the CP to the other system components.

Two ESSBs are placed in the magazine. The ESSBs are connected to IPNX. One interface on each of these two ESSB is used for connecting the node to the site Ethernet configuration. These interfaces act as the ports for IP application signaling like SIP, SIP-I and DNS in our case.

IP Signaling traffic from/to the CP Ethernet interfaces will traverse the IPNX and the ESSB for both switching planes.

ESSB

IPNX

ESSB

Central Processor

Front-endEthernet cables

Figure 2 External Ethernet Interfaces, APZ 212 40

2.3.2.2 APZ 212 50

Figure 3 is an example of a simplified hardware configuration for an MSC node using an APZ 212 50 Central Processor.

Two switches (GESB-I and ESSB) are connected together to provide a sufficient number of ports. GESB-I is used as the first level switch.

IP-based application signaling traffic traverses the GESB-I and ESSB.





ESSB ESSB

Central Processor

Front-end Ethernet cables

GESB-I GESB-I

Figure 3 External Ethernet Interfaces, APZ 212 50

2.3.3 Fault Resilience

This section describes the fault resilience measures that are recommended. It describes the preferred site LAN configuration and the mechanisms of the INET stack that complement this LAN configuration.

2.3.3.1 Local Fault Resilience

The INET stack on CP implementation encompasses a local fault resilience solution. Local fault resilience concerns the connectivity of an IP host to the connected network (LAN). This includes the complete set of facilities that minimize the loss of connectivity because of equipment failure within the scope of the LAN.

All nodes in an IP network are attached via interfaces to a LAN. All nodes attached to the same LAN will communicate directly to each other via the LAN infrastructure. The IP routers attached to the LAN will facilitate the communication to nodes belonging to other LANs.

The local fault resilience utilizes two physical interfaces, of which one is used under normal conditions, whereas the other one is used when connectivity for this primarily used interface is considered faulty.





2.3.3.2 Hardware Fault Resilience

The INET stack on CP provides HW fault resilience by providing duplicated hardware components, such as Ethernet interfaces on the CP, internal switch boards and external Ethernet ports.

2.3.3.3 Fault Resilient LAN Configuration

For the sake of fault resilience, it is advisable that the node utilizes two physical interfaces.

Both interfaces should be attached to the same physical LAN. This ensures that an interface can directly communicate with any other interface via the LAN infrastructure. The LAN infrastructure should as well consist of duplicated devices for the sake of redundancy.

The configuration depicted in the following figure caters most effectively for the fault resilience in line with the recommendations given above.

L2 switch 1

MSC-S MSC-SMSC-S

L2 switch 2

IP router 1 IP router 2

Figure 4 Fault Resilient LAN Configuration

The figure shows some MSC server nodes, each node acting as one IP host2.

2 The single IP host shown is only for the sake of simplification. Typically the MSC server node may use a number of INET stack instances like the ones implemented on GARPs for SS7oIP. These INET stack instances will appear as separate IP hosts.





Each MSC server owns two GE interfaces, but only one GE interface has an assigned IP address used for signaling traffic. Each GE interface is connected to a dedicated Ethernet switch that provides LAN connectivity to the other hosts and the routers on the network.

The L2 switches are duplicated for the sake of fault resilience. The links between the L2 switches are crucial as it connects the two halves of the network topology. The link ensures that all interfaces are connected via LAN devices. Two links should be deployed between the switches to cater for link failure.

The IP routers are redundant as well. Each router is connected to one of the L2 switches. Furthermore, the link between the routers allows forwarding traffic via the other IP router when for instance the link to the IP backbone or to the L2 fails.

2.3.3.4 Router Supervision

The INET stack supports monitoring the connectivity status of site routers by periodically sending ICMP Echo requests to the site router interfaces. The supervision can be done for routers in a subnet. When a connection status is changed to �unavailable� then the IP stack changes route status to �inactive� for all routes that belong to the affected host interface in the VLAN. Routes with status �inactive� are ignored in route selection procedure.

For details on this functionality see [60].

2.3.3.5 IP Address Migration

The function �IP Address Migration� improves the node availability. IP address migration function can be activated for the two Ethernet interfaces of the CP acting as a pair for a particular VLAN. As a prerequisite router supervision has to be enabled. The functionality uses the supervision of routers via ICMP echo requests for determining the connectivity of the local virtual interfaces.

If all connections between one virtual interface and all supervised routers become unavailable then the IP addresses belonging to this virtual interface are migrated to the other virtual interface belonging to that interface pair.

The addresses are moved back to the original virtual interface after the router supervision deems the virtual interface to be working again.

Please note that the monitoring IP addresses used for router supervision are not subject to IP address migration.

For details on this functionality see [60].





2.3.3.6 DNS Fault Resilience

For how to configure the DNS resolver using redundant DNS name servers please refer to [4].

For details on the DNS resolver functionality see [61].

Connectivity to the DNS name servers is supervised by the MSC when the DNS queries are routed via the side edge routers. Therefore the following solutions for a fault resilient DNS configuration are recommended.

The INET stack may attempt to send DNS queries to a local name server on an interface that has no connectivity to the local name servers. Loss of connectivity may be caused by the interface failing itself, or some of the LAN equipment like cables or switches that connect this interface to the local DNS name servers. This can result in the situation, that all locally attached DNS name servers are not reachable anymore.

The following proposals aim at taking advantage of distinct communication paths to the name servers. One physical Ethernet interface is used when sending queries to the primary DNS name server whereas a second physical Ethernet interface is used when sending queries to the secondary DNS name server. In addition a dedicated route is configured for each communication path that utilizes a different router. The proposals only serve as examples.

2.3.3.6.1 Name Servers in Different Subnet

In this approach all local name servers are attached to a separate subnet than the subnet that the interfaces of the MSC are belonging to. The name servers are nevertheless connected to the same LAN as the MSC. The effect of this is that the name servers, although locally attached to the LAN Ethernet switches, can only be reached via the site routers.

The figure below shows that the name servers are placed in a different subnet than the MSC node. DNS queries and results will therefore traverse the site edge routers.





L2 switch 1

DNS Name Server 1

MSC-SDNS Name Server 2

L2 switch 2

IP router 1 IP router 2

DNS subnet signaling subnet

Figure 5 DNS Fault Resilience by Placing Name Servers in Different Subnets

2.3.3.6.2 Using Remote Name Servers

In this approach the DNS name servers are remotely deployed so that queries to the name servers will have to pass through the site routers for the same reason as in the previous solution.

The remotely deployed DNS name servers are configured to be alternative servers belonging to the same name server group.





3 How to Use

This section explains particular subject of the configuration gives advice on notable subjects and aims at illustrating these by an example that is based on the use case of transporting SIP, SIP-I and DNS over IP. The assumption for all example configurations is the preferred LAN configuration as described in the previous section.

The description explains particular ways of applying certain features and functionalities. The examples provided for illustration purposes.

The description does not give a detailed instruction of the sequence of commands to be executed. For this information please refer to the relevant Operation Instructions.

However, the following steps have to be taken in sequence for a proper configuration of the INET stack on the MSC node:

• Preparation of the site LAN switches Prepare the LAN switches that the MSC node is to be connected to for ensuring the MSC system integrity.

• Configuring the Ethernet Switching Planes The MSC internal switching planes are configured such that the application signaling traffic can properly be traversed through the system.

• Ethernet Interface Configuration The Ethernet interfaces of the MSC to be used for the IP signaling application are configured.

• Route Configuration IP routes are configured such that the MSC node can properly utilize the fault resilient LAN configuration.

The following sections will address these configuration steps.





3.1 Preparation of the Site LAN Switches

The following preparation steps are necessary for the sake of system integrity. They have to be performed before the MSC is physically connected to the site LAN.

As described in the previous section, the MSC node uses an internal Ethernet switching configuration for the purpose of communication between internal components. This switching configuration is used for transporting the application signaling traffic to/from the Central Processor by directly attaching the internal LAN to the site LAN. This exposes the system internal LAN to the site LAN unless proper measures are taken. The following configuration steps are to be taken in order to ensure that the internal communication is not jeopardized by effect caused by packets entering the system from the site LAN.

For the sake of system integrity it is recommended that the site switch configuration is done prior to connecting the node to the site LAN.

3.1.1 Requirements on the Site LAN Switches

The site switches should support VLAN for providing the necessary protection of the MSC.

The site switches shall support autonegotiation. They shall support the modes 10Mbps FD (for connecting to a APZ 21240 machine) and 100Mbps FD (for connecting to a APZ 21250 machine).

The switches shall as well only perform flooding (when the destination MAC is unknown to the switch) within the VLAN indicated in the frame to be flooded. All other VLANs must not be flooded.

Packet filtering may be utilized by the switches as a further means for mitigating the effects of unwanted traffic.

3.1.2 Configuration of Site LAN Switch

The following configurations shall be made for the LAN switch ports that connect to the ESSB ports:

3.1.2.1 VLAN Separation

The port of the LAN switch connected to the ESSB should only belong to the VLANs that will be defined for the signaling traffic.





3.1.2.2 Port Speed and Duplex Mode

The port speed and duplex mode has to be determined by autonegotiation in order that the site switch and the ESSB can conclude on the proper result.

The LAN shall apply autonegotiation on the ports connected to the ESSB.

3.1.2.3 Packet Filtering

As an option, the following configurations can be applied on the site switches:

The LAN switch may apply packet filters on the port connected to the ESSB to limit the traffic destined to the INET stack on the CP. This may include filtering on particular source IP addresses or source IP address ranges, port numbers etc.

Examples for packet filters could be:

Filter on destination IP addresses: Drop all packets not destined to the IP addresses configured on the CP.

Filter on source IP addresses: Drop all packets that are not originating from trusted sources.





3.2 Configuring the Ethernet Switching Planes

Before the node interfaces belonging to the INET stack on the CP are connected to the site LAN, the node internal switching planes should be configured such that ingress packets cannot harm the system.

For the sake of system integrity it is recommended that the switch plane configuration is done prior to connecting the node to the site LAN.

The following command sequences have to be issued for the two ESSB switches located in the subrack containing the CP hardware.

One switching plane configuration shall be finalized before configuring the other plane in order to minimize disturbance.

Configuration is done via the CLI on the particular ESSB. Please consult the User Guide [3] for further details on how to access it.

3.2.1 Bringing the ESSB into Managed Mode

The ESSB switches have to be put into the managed mode to handle VLANs properly. This is done by the following command:

OSmon> essb vlan on

The ESSB runs now in managed mode, which means it obeys the VLAN definitions and the VLAN tags in received frames for its switching task.

The command sets the port based VLAN table (called PTABLE) of the ESSB such that all switch ports belong to the VLAN 1. VLAN 1 corresponds to untagged traffic as used for communication between node internal components.

The 802.1Q or tag based VLAN table (called QTABLE) is not altered by this command. In our example the 802.1Q VLAN table remains empty as there is currently no definition of tag-based VLANs.

As a consequence of this setting all internal components connected to the ESSB can communicate with each other via untagged Ethernet frames.

3.2.2 Defining the Signaling VLAN on the Switching Planes

The next step is to enable communication from the Central Processor Ethernet interfaces via the internal switching planes to the external port of the ESSB via dedicated signaling VLANs.

Note that the VLAN configuration must be consistent with the VLAN setting for the CP interfaces, as well as the site routers leading to external network.





One of the ports of both ESSB boards will be connected to the site LAN switches. At least one VLAN has to be defined for the sake of separating the signaling traffic from the communication of node internal components.

There are two options for the using a signaling VLAN on the link between site switch and ESSB:

• Port based VLAN

• Tag based VLAN

Please note that the port based VLAN associates untagged frames with a particular VLAN for a specific port. Consequently, only a single port based VLAN can be used. All further VLANs have to utilize tagged frames that explicitly indicate the VLAN. It is therefore deemed preferable to use tagged VLANs consistently. Nevertheless, both ways of configuring the VLANs are shown.

The following placeholders are used in the command lines given in the following subsections:

• The ESSB port connecting further to the CP interface is called port int (int to be replaced by an appropriate number for a real configuration). For illustration purposes the port 7 is used as the internal port in command line examples.

• The ESSB port connecting further to the site LAN switch interface is called port ext (ext to be replaced by an appropriate number for a real configuration). For illustration purposes the port 2 is used as the external port in command line examples.

• The VLAN used internally for the particular signaling traffic is called VLAN n (n to be replaced by an appropriate number). For illustration purposes the VLAN 201 is used as the signaling VLAN in command line examples.

3.2.2.1 Defining the Internal Communication VLAN

This step will interconnect the internal components via a dedicated VLAN. The VLAN will utilize untagged frames only, hence port based VLANs definitions have to be given for each ESSB port belonging to the internal VLAN.

This step is necessary for two reasons:

• Remove the port ext from the internal VLAN as it only meant to belong to the VLAN carrying signaling traffic.

• Prevent all ports belonging to the internal VLAN to be able to send to the external site equipment. For example, broadcasts meant for internal components are prevented from leaving the system.





The default configuration of the ESSB when entering the managed mode does not comply with these aspects and hence the following configurations have to be performed:

For each port except the port ext define a port based VLAN that includes all other ports except port ext as the members of that VLAN and all those ports to send out the frames untagged.

These following example command lines illustrate this step with port 7 being port int, port 2 being port ext.

OSmon> essb pvlan –p 0 –m 0,1,3,4,5,6,7 –u 0,1,3,4,5,6,7







3.2.2.2 Using Untagged Frames on the External ESSB Port (Port Based Tagging)

The internal ESSB port uses tagged fames for the signaling traffic.

Note that the port based tagging configuration can only be applied for a single VLAN. If more than a single VLAN is used for signaling application, then on a single external ESSB port all VLANs except one will be tagged. If all VLANs are to use untagged frames, than as many external ESSB port as VLANs have to be utilized to connect to the site LAN switch. This is certainly limited by the amount of free external ESSB port.

The following command defines that port int and port ext shall belong to the VLAN with tag n, and that the egress traffic on port ext should be untagged:

OSmon> essb qvlan –t 201 –m 2,7 –u 2

The next command defines that untagged ingress traffic on port ext shall belong to the VLAN with tag n:

OSmon> essb pvlan –p 2 –t 201 –m 7





3.2.2.3 Using Tagged Frames on the External ESSB Port

Both ports int and ext accept only tagged traffic.

The following command has to be issued to define the tag based VLAN. In the example command lines listed below the follow data is entered.

OSmon> essb qvlan –t 201 –m 2,7

The list of ports for untagged traffic is omitted in this command, in contrast to the previous case.

3.2.3 Ethernet Link Speed Configuration

For 212 40 machines 10 Mbps Full Duplex is recommended. This is done by the following command:

OSmon> essb pset 7 mode 10F PC

For 212 50 machines 100 Mbps Full Duplex is recommended. This is done by the following command:

OSmon> essb pset 7 mode 100F PC

Please note that the parameter PC activates the sending of pause frames and may be replaced by NPC if Pause frames are unwanted.

Note that although the port speed and the duplex mode is set by command, the ESSB will still perform autonegotiation. Consequently, forcing the external ESSB port to a particular port speed requires autonegotiation on the Ethernet equipment to which the ESSB connects (this is typically a port on a site switch) in order to ensure that the link is run in the proper mode.

It is not recommended to change the Ethernet link speed of any other ESSB port than the external ESSB port. Changes to the default configuration of the other ports may have negative side effects on the internal communication of system components attached to the ESSB.





3.3 Ethernet Interface Configuration

There are two physical interfaces on CP. The interfaces are referred to as ETHA and ETHB.

The operator can define multiple virtual interface pairs on top of the physical interface pair. Each virtual interface pair has its own VLAN tag and represents a VLAN.

3.3.1 The Purpose of Virtual Ethernet Interfaces

Virtual Ethernet interfaces are a means for defining VLANs to be used for signaling traffic. When a VLAN is to be defined, it is done by creating virtual interfaces on both physical interfaces. The virtual interfaces are referred to as ETHA-n and ETHB-n, where the number n corresponds to the VLAN identifier to be used on the VLAN.

Please note that all signaling traffic has to use a VLAN. It is not possible to omit the VLAN usage on the host interfaces. The purpose is for the sake of separating external signaling traffic from the node internal communication. These VLAN tags can be stripped off by a proper ESSB configuration, if tagged frames shall not be used in the site LAN.

3.3.2 Virtual Interface Definition

Command IHIFI is used to define and create a virtual interface (VIF) configuration on ETHA or ETHB.

The VLAN ID as specified for a virtual interface must not use the values 1, and 4095 as these VLAN IDs are either used for node internal purposes or are reserved values.

Note that the VLAN configuration must be consistent with the VLAN setting on ESSB, as well as the site switches and site routers leading to external network.

It is recommended to define virtual interfaces in pairs (that means defining them on ETHA as well as on ETHB). This is the precondition for using the fault resilience provided by Router Supervision with IP Address Migration can be used.





3.4 IP Layer Configuration

This section describes the basic configuration for the IP layer, in particular all issue around address definitions on the Ethernet interfaces.

3.4.1 Adding an IP Address to a Virtual Interface

IP addresses have to be configured on a virtual Ethernet interfaces in order for the applications to be able to participate in the IP network.

The command IHIFC enables to add host IP addresses to a virtual interface. The subnet and usage of ARP protocol for each defined IP address can be decided. Only the IPv4 address format is supported3.

Command IHIFC defines host IP addresses that are used for signaling traffic only. Supervision IP addresses as defined for the Router Supervision function are not defined by IHIFC (refer to section 2.3.3.4) as this type of IP addresses are defined by command IHRSI.

It is recommended to enable the ARP protocol for IP addresses, unless these IP addresses shall be deliberately excluded from the address learning via ARP.

The command IHIFC allows for defining the applicable MTU for a particular virtual interface.

Tunneling should be taken into account when setting the MTU as it can happen externally in a particular node such as security gateway (for example IPSec tunnel). This would effectively reduce the available MTU if IP layer fragmentation is to be avoided.

It is recommended that the MTU for virtual interfaces on the physical interfaces ETHA and ETHB are set to the same size so that IP address migration caused by router supervision does not impose an MTU with different restrictions.

Modification of the MTU size for an interface can only be performed if the interface is blocked.

3.4.2 Changing an IP Address

For changing an IP address it is recommended to perform a certain number of steps in order to minimize the traffic disturbances caused by this change. For that reason it is not recommended to simply remove the existing IP address. The signaling application may object to removing this address as it is being used, or traffic disturbance may happen when the address is forcedly removed. The steps to take are basically:

3 This applies to all cases when IP addresses are mentioned in this document.





• Prepare the new address before it is used by the signaling application

• Instruct the signaling application to use the new IP address for traffic

• Check and eventually remove IP routes with source address property for which the source address is the one to be removed (see section 3.6.1.3 for details about this route type and section 3.5 for IP route configuration in general)

• Remove the now superfluous address

The second step is out of scope of this document as the details of this configuration step are application specific.

For the first step one would need to execute the command IHIFC with the ADD parameter and the new address information (same procedure as described in section 3.4.1).

IHIFC:VIF=vif, ADD, IP=ip;

The next action is to instruct the application for using this new address.

Check whether any IP routes exist with source address property for the IP address to be removed by applying command IHRHP for the IP address.

IHRHP:IP=ip;

If there are any such routes, remove those routes from the routing table by command IHRHC and parameter DEL, specifying the source IP address and the gateway as further parameters.

IHRHC:DEL, SOURCE=source, GW=gw;

For the last step one needs to remove the IP address with the command IHIFC with the DEL parameter and the address information.

IHIFC:VIF=vif, DEL, IP=ip;





3.5 Fault Resilient Configuration

In order to archive fault resilience, it is recommended to enable router supervision for all routers used in the used VLANs and enable IP address migration for each VLAN

Router supervision is defined on a per VLAN basis.

Command IHRSI can be used initiate router supervision and IP address migration on a pair of virtual interfaces. The command assigns an IP address as a monitoring IP address for router supervision to each virtual interface. The monitoring IP addresses inherit the netmask of host IP addresses in the same VLAN.

If the envisaged configuration does not assign an application IP address to one of the interface (i.e. one of the interfaces has no application IP address assigned), then command IHRSI has to be initiated before defining routes for the interface without a traffic IP address. The definition of routes for this interface without a traffic IP address becomes necessary for ensuring that the proper routes are present when the IP address migration function will move the IP address to that interface.

The reason is that IP routes (see section 3.6) can only be assigned to interfaces with assigned IP addresses. Activating router supervision will assign the monitoring IP addresses to both interfaces of a virtual interface pair. Therefore this action will enable the definition of routes on the interfaces without traffic IP addresses assigned.





3.6 IP Route Configuration

IP routes are used to define the first hop for packets not destined to the local IP subnet.

Please note that any route definition as given by command IHRHC can be verified in two ways:

The printout command IHRHP displays the route definitions as given by the definition commands.

The command IHNSP with option route returns the routes as used by the INET stack itself. The latter provides of information for verifying the actual routes as used by the IP layer.

There are a number of different routes with different properties that can be defined. There are some definition properties in common to all these routes. One is the definition of the first hop that the packet will take, that means the router to be used. In addition there is the preference that allows prioritization of routes with otherwise same match in the route selection process.

3.6.1 Route Types

The following sub-sections explain the different supported route types and when to apply them for the most benefit.

3.6.1.1 Default Routes

Default routes are routes that are least specific concerning anything that the packets concerns. Default routes are selected when no better match is found in the route selection process.

The destination of a default route is unspecified, which means that any destination may apply.

There is a configuration object that is called default gateway. This is actually an alternative way for defining a default route by omitting the destination and subnet properties in the route definition.

Default routes are subject to router supervision if that feature is enabled for the particular virtual interface that the default route is attached to.

It is recommended to define default routes from each interface. For the preferred site LAN configuration, each interface should have a default route to each of the two routers on the LAN. The priorities for the two routes from one interface should differ. As well the priorities for the routes from the different interfaces to the same router should differ. This ensures that a clear distinction in the route selection can be made based on the given priorities.





3.6.1.2 IP Routes with Interface Property

Interface routes are defined for a particular virtual interface. They are more specific than default routes as they define a particular destination in the form IP address and netmask. Packet matching this destination will use the first hop given in the route definition unless a better match is found in the route selection process.

Interface routes are bound to the virtual interface and will never be removed from that interface by the system.

Interface routes are subject to router supervision if that feature is enabled for the particular virtual interface.

It is recommended that interface routes are applied when the traffic to particular destinations has to be treated differently for each interface in terms of first hop selection.

3.6.1.3 IP Routes with Source Address Property

Source address routes further detail the matching condition for the route selection. This is achieved by additionally defining the source IP address of the packet that should take the route.

If the router supervision is enabled with IP address migration, then the source address routes are removed from the original interface and recreated on the alternative interface as soon as IP address migration happens. In other words, the source address routes will perform the migration along with the source address that it is bound to.

It is recommended to use source IP routes when particular traffic from applications are bound to a specific source address and when this traffic shall always take a particular first hop even when IP address migration is happening.

3.6.2 General Recommendations

Definition of routes can only be given for interfaces that have an IP address assigned. It is therefore recommended to assign the application IP addresses prior to the route definitions.

It is recommended to assign different preference levels to routes. This rule should be applied especially to routes from the same interface and routes that specify the same first hop and same destination (netmask and address) if the routes are specified for different interfaces or for source addresses. The reason is to avoid that for a particular packet these presumably different routes actually turn out to be equivalent in the route selection process and the actual selection is arbitrarily done.





In order to achieve fault resilience as described in Chapter 1.4.3, the following configuration is recommended:

In a VLAN, at least two default gateways should be configured. Each default gateway should be reachable from any central processor interface.

The preferences for the gateways have to be different such that from a particular interface one gateway is clearly preferred over the other.

If the preferred default gateway should remain after IP address migration in a fault situation, the preference for this gateway should be high on both interfaces, but should be higher on the main interface than on the fall back interface. In the same way, the preference for the fallback gateways should be configured.

For example, the preferences for default gateways in declining preference order, with ETHA-n being the interface used under normal condition and ETHB-n being the interface used when ETHA-n fails, should be:

• Gateway A on interface ETHA-n

• Gateway A on interface ETHB-n

• Gateway B on interface ETHA-n

• Gateway B on interface ETHB-n

3.6.3 Recommendations for Specific DNS Routes

Specific DNS routes refer to routes defined to specifically point to the DNS name server used for the queries. The purpose of the routes is to force a particular IP address to be selected as a source for DNS queries and enforce redundancy by applying two distinct paths for DNS queries. The definition of DNS name server in the DNS resolver configuration has to be accordingly such that a at least two DNS names servers known, the primary and secondary DNS name servers.

It is recommended to define two DNS specific routes. One route is to define the primary communication path to the DNS primary name server. This route is defined for the first interface (primary interface), specifying the one of the two routers (primary router) as the first hop and the primary DNS name server as the destination address in the route definition. A second route is to be defined for the second interface (secondary interface), specifying the other of the two routers (secondary router) as the first hop and the secondary DNS name server as the destination address in the route definition.





3.7 Example Configuration

This configuration example assumes that the protocols SIP, SIP-I and DNS will utilize the stack.

The configuration assumes the preferred LAN configuration as shown in the introduction section.

This example configures the site LAN switch for SIP under the following assumptions:

• The VLAN used for SIP is the VLAN 201.

• The IP address used for SIP is 10.0.1.101/24

Please note that SIP binds itself to a specific source address, whereas DNS does not. This means:

• SIP traffic will always originate and terminate on that particular IP address, irrespective of on what physical interface that address resides (for example IP address migration might move the address to another physical interface as described in section IP Address Migration 2.3.3.5).

DNS is not bound to a particular IP address or interface. Consequently, the INET stack will select a proper interface and an IP address defined on that interface. This selection is performed by two steps. The first step is the route selection process for the name server address given in the destination address of the IP packet. The second step is the following source address selection process for the interface determined by the route selection. This will result in source addresses and interfaces being selected spontaneously for a DNS query. This may result even in an address originally intended for router supervision being used.

Bearing this in mind, a configuration is shown that copes with the different application behavior such that fault resilience is ensured.

It is assumed that the IP address configuration is done as given in the example section on that subject above. Furthermore, it is assumed that router supervision is enabled and the corresponding supervision addresses are defined.

3.7.1 Preparation of the Site LAN Switches

The preparation steps as outlined in section 3.1 have to be performed. In particular the rate limiting has to be configured on the corresponding site switch port for VLAN 201.





3.7.2 Internal Switch Plane Configuration

In this example it is assumed that VLAN 201 is to be used for the SIP traffic. The internal port of the ESSB connecting further to the Ethernet interfaces of the Central Processor is port 2. The external port connecting to the site LAN switch is port 7. It is further assumed that all SIP traffic will use tagged frames.

Log on to the ESSB belonging to switching plane A and execute the following commands:

OSmon> essb vlan on


Log on to the ESSB belonging to switching plane B and execute the following commands:

OSmon> essb vlan on


3.7.3 Virtual Interface Definition

The VLAN to be used for SIP is to be created on both CP Ethernet interfaces. The VLAN has to be configured on both interfaces because the IP address migration feature shall be enabled.

The following commands have to be entered:

IHIFI:VIF=ETHA-201;

IHIFI:VIF=ETHB-201;

3.7.4 Add IP Address to Virtual Interface

Now the IP address to be used for SIP has to be configured. The preferred interface for SIP is ETHA, with ETHB acting as a fallback interface in failure configurations. For this reason it is not needed to configure an address on ETHB, but only on ETHA.

IHIFC:VIF=ETHA-201, ADD, IP=10.0.1.101, NETMASK=255.255.255.0;

In addition the two IP addresses assigned for DNS traffic have to be defined (see section 2.3.3.6 for further information).

IHIFC:VIF=ETHA-201, ADD, IP=10.0.1.103, NETMASK=255.255.255.0;

IHIFC:VIF=ETHB-201, ADD, IP=10.0.1.102, NETMASK=255.255.255.0;





3.7.5 Enabling Router Supervision and Address Migration

The following configuration steps ensure that the configured default gateways are supervised and address migration happens for the used IP address when the interface ETHA is deemed failing and interface ETHB is used instead for this IP address. For the gateway supervision there are two IP addresses (PINGA and PINGB) defined.

IHRSI:VIFP=ETH-201, GW=10.0.1.1&10.0.1.2, PINGA=10.0.1.3, PINGB=10.0.1.4, IPMIGR=YES;

3.7.6 Route Configuration

3.7.6.1 Default Route Configuration

Default gateways have to be defined for enabling routes for packets not destined to the LAN.

The objectives are:

• One gateway (assumed gateway address is 10.0.1.1) is the preferred gateway irrespective of whether the SIP communicates from ETHA or ETHB.

• An alternative gateway (assumed gateway address is 10.0.1.2) exists that is only used when the preferred gateways is deemed to be faulty.

The following configuration provides this:

Define the preferred gateway on ETHA by giving the highest preference;

IHRHC:ADD, VIF=ETHA-201, DEFGW=10.0.1.1, PREF=255;

Define the alternative gateway on ETHA (in case gateway 10.0.0.1 is deemed faulty) by giving lower preference;

IHRHC:ADD, VIF=ETHA-201, DEFGW=10.0.1.2, PREF=127;

Define the preferred gateway on ETHB by giving a preference that is lower than for the route to the same gateway from ETHA, but higher than the router to the alternative gateway from ETHA.

IHRHC:ADD, VIF=ETHB-201, DEFGW=10.0.1.1, PREF=191;

Define the alternative gateway on ETHB (in case gateway 10.0.0.1 is deemed faulty) giving the lowest preference of all these routes

IHRHC:ADD, VIF=ETHB-201, DEFGW=10.0.1.2, PREF=63;





3.7.6.2 Adding DNS Specific Routes

DNS specific routes have to be added for enforcing particular paths to be used towards a specific DNS name server. In this example the two addresses (10.0.1.103 & 10.0.1.102) are assigned for DNS traffic.

The assumed addresses of the two DNS name servers are 10.0.2.253 and 10.0.2.254.

The following configuration gives the wanted result:

As recommended, two specific routes pointing to the DNS name servers are defined, one for the first interface, the other from the second interface. Each of the two routes should utilize a different gateway.

IHRHC:ADD, VIF=ETHA-201, DEST=10.0.2.253, NETMASK=255.255.255.0, GW=10.0.1.1, PREF=255;

IHRHC:ADD, VIF=ETHB-201, DEST=10.0.2.254, NETMASK=255.255.255.0, GW=10.0.1.2, PREF=255;

In the configuration above, the DNS name server with address 10.0.2.253 is preferably reached via gateway 10.0.1.1 from interface ETHA-201 with address 10.0.1.103, whereas the DNS name server with address 10.0.2.254 is reached via gateway 10.0.1.2 from interface ETHB-201 with address 10.0.1.102. This caters for additional fault resilience.





4 Glossary

4.1 Concepts

Default Gateway

A default gateway is similar to a default IP route, which is a router defined with destination and netmask 0.0.0.0 (any destination). A default gateway is treated different from a default IP route from a command syntax viewpoint such that a default gateway/router is added by MML command IHRHI with DEFGW option. The actual IP routing does not distinguish between default gateways/routers and default IP routes because the corresponding entries in the IP routing table are the same.

ESSB

The ESSB is a node internal switching boards that support VLAN tagged traffic.

Gateway

The term �gateway� is a synonym for a router. Please refer to the explanation given for the router.

LAN

A local area network (LAN) is a computer network covering a small geographic area. In the context of this document, this small geographic area encompasses the equipment belonging to a site of network nodes interconnected via the LAN technology. The LAN technology used in the context of this document is Ethernet.

Supervision IP Address

IP address tied to a virtual interface to monitor connectivity between the virtual interface and routers. A supervision IP address is dedicated to router supervision. Supervision IP addresses are bound to a virtual interface, that means they are never subject to IP address migration.

Router

A node that interconnects several IP networks and forwards data packets according to their destinations and adopted policies.

Virtual Interface





A virtual interface is a logical interface built on top of the physical Ethernet interface on CP. Each virtual interface (pair) will be assigned its own unique VLAN tag.

Virtual Interface Pair

A pair of virtual interfaces defined on the two physical Ethernet interfaces of a CP. Both virtual interfaces belong to the same VLAN tag.

VLAN

Virtual LAN, commonly known as a VLAN, is a method of creating independent logical networks within a physical local area network. Several VLANs can co-exist within such a local area network. This helps in reducing the broadcast domain and aids in network administration by separating logical segments of a LAN that should not exchange data using a LAN.

4.2 Abbreviations

ARP Address Resolution Protocol

CP Central Processor

DNS Domain Name System

ESSB Ethernet Switch and Security Board

ETH Ethernet Interface

GE Gigabit Ethernet

GESB Gigabit Ethernet Switching Board

ICMP Internet Control Message Protocol

INET Internet

ICMP Internet Control Message Protocol

IO Input Output

IP Internet Protocol

IPN Inter-Platform Network

IPNX Inter-Platform Network Switch

L2 Layer 2





LAN Local Area Network

Mbps Megabit per second

MSC Mobile Services Switching Centre

MTU Maximum Transfer Unit

OSS Operation & Maintenance Subsystem

SIP Session Initiation Protocol

SIP-I SIP with encapsulated ISUP

SS7 Signaling System Number 7

SS7oIP Signaling System Number 7 over IP

TCP Transmission Control Protocol

UDP User Datagram Protocol

VIF Virtual Interface

VLAN Virtual LAN





5 References

5.1 User Guides

[1] Signaling System No.7 Transport over IP

[2] SIP and SIP with Encapsulated ISUP Signaling, MSC Server

[3] User Guide for ESS

[4] DNS Resolver Configuration

5.2 Command Descriptions

[5] IHIFI, IP Transport, Virtual Ethernet Interface, Initiate

[6] IHIFC, IP Transport, Virtual Ethernet Interface, Change

[7] IHIFE, IP Transport, Virtual Ethernet Interface, End

[8] IHIFP, IP Transport, Virtual Ethernet Interface, Print

[9] IHRHC, IP Transport, Route Handling, Change

[10] IHRHP, IP Transport, Route Handling, Print

[11] IHRSI, IP Transport, Router Supervision, Initiate

[12] IHRSC, IP Transport, Router Supervision, Change

[13] IHRSE, IP Transport, Router Supervision, End

[14] IHRSP, IP Transport, Router Supervision, Print

[15] IHRGI, IP Transport, Resolver Name Server Group, Initiate

[16] IHRGC, IP Transport, Resolver Name Server Group, Change

[17] IHRGE, IP Transport, Resolver Name Server Group, End

[18] IHRGP, IP Transport, Resolver Name Server Group, Print

[19] IHRPC, IP Transport, Resolver Parameter, Change

[20] IHRPP, IP Transport, Resolver Parameter, Print

[21] IHRCC, IP Transport, Resolver Cache Configuration, Change

[22] IHRCP, IP Transport, Resolver Cache Configuration, Print





[23] IHRLI, IP Transport, Resolver Local Table Look Up, Initiate

[24] IHRLE, IP Transport, Resolver Local Table Look Up, End

[25] IHRLP, IP Transport, Resolver Local Table Look Up, Print

[26] IHRTI, IP Transport, Resolver Local Table IDENTITY, Initiate

[27] IHRTE, IP Transport, Resolver Local Table IDENTITY, End

[28] IHRTP, IP Transport, Resolver Local Table IDENTITY, Print

[29] IHRUI, IP Transport, Resolver Search Suffix, Initate

[30] IHRUE, IP Transport, Resolver Search Suffix, End

[31] IHRUP, IP Transport, Resolver Search Suffix, Print

[32] IHRCI, IP Transport, Resolver Cache, Initiate

[33] IHRCE, IP Transport, Resolver Cache, End

[34] IHNSP, IP Transport, Network Statistics, Print

[35] IHNPI, IP Transport, Network Ping, Initiate

[36] IHNPE, IP Transport, Network Ping, End

5.3 Printout Descriptions

[37] Virtual Ethernet Interface Data

[38] Route Handling

[39] Router Supervision Data

[40] Gateway Supervision Fault

[41] DNS Resolver Name Server Identiy

[42] DNS Resolver Name Server Group Data

[43] DNS Resolver Name Server Parameter Data

[44] DNS Resolver Cache Configuration Data

[45] DNS Resolver Local Table Configuration Data

[46] DNS Resolver Local Table Identity

[47] DNS Resolver Local Table Data





[48] DNS Resolver Search Suffix Data

[49] Network Information and Statistics

[50] PING Data

5.4 Operational Instructions

[51] IP Transport, Maintenance and Operation

[52] Gateway Supervision Fault Indication

[53] IP Transport, Resolver Group Configuration, Set

[54] IP Transport, Resolver Search Suffix Configuration, Set

[55] IP Transport, Resolver Cache Configuration, Set

[56] IP Transport, Local Table Configuration, Set

[57] Ethernet Switch and Shielding Functionality, Define

[58] Ethernet Switch and Shielding Functionality, Delete

[59] Configure ESSB in the DHCP Table

5.5 Other Documents

[60] IP Based Functions on CP Function Specification

[61] DNS Resolver on CP Function Specification

internet protocol suite on central processor

Documents

local fault resilience

hardware fault resilience

dns fault resilience

site lan switches

ericsson internal user

b internet protocol

b contents

internet protocol stack