Telindus 1424

1424 SHDSL Router
User and reference manual

Version: 1.3 - 550104
26 January 2009
ii 1424 SHDSL Router Copyright, safety and statements
Document properties
Subject 1424 SHDSL Router
Manual type User and reference manual
Version 1.3
Code 550104
Modification date 26 January 2009 ©OneAccess
Copyright notice
The information and descriptions contained in this publication are the property of OneAccess. Such infor-
mation and descriptions must not be copied or reproduced by any means, or disseminated or distributed
without the express prior written permission of OneAccess.
This publication could include technical inaccuracies or typographical errors, for which OneAccess never
can or shall be held liable. Changes are made periodically to the information herein; these changes will
be incorporated in new editions of this publication. OneAccess may make improvements and/or changes
in the product(s) described in this publication at any time, without prior notice.
Safety requirements
Carefully read the safety instructions, installation precautions and connection precautions as stated in
chapter 2 - Installing and connecting the 1424 SHDSL Router on page 11.
1424 SHDSL Router Copyright, safety and statements iii
Statements
www.oneaccess-net.com → Products → Choose a product → Downloads → Certificates
Hereby, OneAccess declares that this 1424 SHDSL Router complies with the essential requirements
and other relevant provisions of Directive 1999/5/EC.
Hierbij verklaart OneAccess dat deze 1424 SHDSL Router overeenstemt met de essentiële vereisten en
andere relevante bepalingen van Richtlijn 1999/5/EC.
Par la présente, OneAccess déclare que ce 1424 SHDSL Router est en conformité avec les exigences
essentielles et autres articles applicables de la Directive 1999/5/EC.
Hiermit, OneAccess erklärt daß dieser 1424 SHDSL Router in Fügsamkeit ist mit den wesentlichen
Anforderungen und anderen relevanten Bereitstellungen von Direktive 1999/5/EC.
Mediante la presente, OneAccess declara que el 1424 SHDSL Router cumple con los requisitos esen-
ciales y las demás prescripciones relevantes de la Directiva 1999/5/CE.
A OneAccess declara que o 1424 SHDSL Router cumpre os principais requisitos e outras disposições
da Directiva 1999/5/EC.
Col presente, OneAccess dichiara che questo 1424 SHDSL Router è in acquiescenza coi requisiti
essenziali e stipulazioni attinenti ed altre di Direttivo 1999/5/EC.
Με το παρόν η OneAccess δηλώνει ότι το 1424 SHDSL Router είναι συµµορφούµενο µε τις βασικές
απαιτήσεις και µε τις υπόλοιπες σχετικές διατάξες της οδηγίας 1999/5/EC.
iv 1424 SHDSL Router Copyright, safety and statements
Environmental information
The crossed-out wheeled bin means that within the European Union the product must be taken to separate
collection at the product end-of-life. This applies to the device but also to any accessories marked with this symbol.
Do not dispose of these products as unsorted municipal waste.
If you need more information on the collection points where you can present your end-of-life equipment for
recycling, please contact your local importer.
For Belgium, you can contact rma@oneaccess-net.com.
De doorstreepte container wil zeggen dat binnen de Europese gemeenschap het product voor gescheiden afvalverzameling moet
worden aangeboden aan het einde van de levensduur van het product. Dit geldt voor het toestel, maar ook voor alle toebehoren
die van dit symbool voorzien zijn. Bied deze producten niet aan bij het gewone huisvuil.
Indien u meer informatie wenst over het inzamelpunt waar u afgedankte apparatuur kan aanbieden voor recyclage, gelieve dan
uw lokale importateur te contacteren.
Voor Belgie kan u contact opnemen met rma@oneaccess-net.com.
Le symbole de la poubelle sur roues barrée d'une croix signifie que ce produit doit faire l'objet d'une collecte sélective en fin de vie
au sein de l'Union Européenne. Cette mesure s'applique non seulement à vorte appareil mais également à tout autre accessoire
marqué de ce symbole. Ne jetez pas ces produits dans les ordures ménagères non sujettes au tri sélectif.
Si vous souhaitez plus d'information concernant le point de collecte où vous pouvez présenter vos appareils fin-de-vie afin qu'ils
soient recycles, veuillez contacter votre importateur locale.
Pour la Belgique, vous pouvez prendre contact avec rma@oneaccess-net.com.
Das Symbol der durchgestrichenen Abfalltonne auf Rädern bedeutet dass das Produkt in der Europäischen Union einer
getrennten Mülsammlung zugeführt werden muss. Dies gilt sowohl für das Produkt selbst, als auch für alle mit diesem Symbol
gekennzeichneten Zubehörteile. Diese Produkte dürfen nicht über den unsortierten Hausmüll entsorgt werden.
Falls Sie weitere Auskünfte brauchen im Betracht der Sammelplätze für ausrangierte Apparate, wenden Sie sich bitte an Ihren
örtlichen Importeur.
Für Belgien, bitte kontaktieren sie rma@oneaccess-net.com.
1424 SHDSL Router Preface v
Documentation set
For all devices, the documentation set currently consists of the following:
Document Description
1424 SHDSL Router manual This is the manual you are reading now.
(this manual) It shows you how to install and connect the 1424 SHDSL Router and
gives you a basic configuration. It also contains a complete descrip-
tion of all the configuration, status, performance and alarm parame-
ters for look-up purposes.
The proxy management (also called Orchid function) parameters are
described in the Orchid function manual.
maintenance and manage- The 1424 SHDSL Router can be maintained and managed by a vari-
ment application manuals ety of maintenance and management tools. Refer to 1.4 - Mainte-
nance and management tools on page 8 for an introduction on these
tools and for a reference to the manual of these tools.
cable documents A wide variety of cables exist to connect the 1424 SHDSL Router.
The Data cables document (PDF) and the Management cables doc-
ument (PDF) describe these cables.
Orchid function manual (PDF/ This manual explains what proxy management is (also called Orchid
CHM) function). It describes how to connect the 1424 SHDSL Router to
other OneAccess devices to be able to manage them. It also gives a
thorough explanation of the proxy management parameters.
All these documents, together with the free maintenance tool TMA and the firmware of the OneAccess
devices, can be found on the OneAccess Access Products distribution CD that is delivered with all
OneAccess products.
Organisation of this manual
This manual contains the following main parts:
Part This part …
User manual shows you how to install and connect the 1424 SHDSL Router. It also gives a
basic configuration of the 1424 SHDSL Router.
Reference manual gives more detailed information on the 1424 SHDSL Router, such as software
download procedures, technical specifications, etc. It also contains a complete
description of all the configuration, status, performance and alarm parameters
for look-up purposes.
Annex gives additional information, such as product sales codes.
Refer to the Table of contents on page x for a detailed overview of this manual.
vi 1424 SHDSL Router Preface
Typographical conventions
The following typographical conventions are used in this manual:
The format … indicates …
Normal normal text.
Italic • new or emphasised words

• application windows, buttons and fields. E.g. In the Filename field enter …
Computer text you have to enter at the DOS or CLI prompt, computer output and code
examples.
E.g. NOK,1,1,Invalid command.
Computer Bold text you have to enter at the DOS or CLI prompt when it is part of a mix of com-
puter input and output.
E.g.
/o1003:"Edit Configuration"
>get sysName
sysName = "Orchid 1003 LAN"
/o1003:"Edit Configuration"
>
Narrow containment tree objects and attributes of a device when they are mentioned in
the normal text. I.e. when they are not a part of computer input or output.
E.g. Use the sysName attribute in order to …
<Narrow> containment tree objects or attributes or part of them that are variable. I.e.
depending on the product version, used interface, etc. the names of these
objects or attributes are slightly different.
E.g. topObject/<modularIf>/someAttribute means that the name of the object
<modularIf> depends on which modular interface you use. For example, v35 in
case of a V.35 interface, g703 in case of a G.703 interface, etc.
Blue references to other parts in the manual.

E.g. “Refer to xx - Title for more information”.
Blue underline • a hyperlink to a web site. E.g. www.oneaccess-net.com

• a reference to another manual. E.g. “Refer to the TMA manual (PDF) for
more information”. The abbreviation between brackets is an indication of the
file format (PDF = Portable Document Format / CHM = Compiled HTML
Help).
1424 SHDSL Router Preface vii
Graphical conventions
The following icons are used in this manual:
Icon Name This icon indicates …
Remark remarks or useful tips.
Caution text to be read carefully in order to avoid damage to the device.
Warning text to be read carefully in order to avoid injury.
DIP switch a DIP switch or strap table.
Basic attribute a basic attribute in the containment tree of the 1424 SHDSL Router.
Advanced attribute an advanced attribute in the containment tree of the 1424 SHDSL
Router.
Structured attribute a structured attribute within another attribute in the containment tree
of the 1424 SHDSL Router.
Action an action in the containment tree of the 1424 SHDSL Router.

viii 1424 SHDSL Router Preface
Reading a DIP switch table
At several places in this manual DIP switch tables are shown. To enable you to read such a table in a
correct manner it is explained below.
A DIP switch table has the following layout:
The following table explains the DIP switch configuration table layout:
Number This position displays …
1 the DIP switch icon.
2 the DIP switch name.
3 the DIP switch position on the DIP switch bank.

The abbreviations mean the following:
DS1 no. 1: DIP switch bank number 1, switch position number 1
4 the possible settings of the DIP switch: on and off. The default setting is printed in bold.
5 the function associated with the corresponding DIP switch setting.
Reading an attribute string
At several places in this manual attribute strings are shown. To enable you to read such a string in a
correct manner it is explained below.
An attribute string has the following layout:
The following table explains the attribute string layout:
Number This position displays …
1 the attribute icon. It indicates that the string which follows is an attribute string. Refer to
Graphical conventions on page vii for more information.
2 the attribute name and its position in the containment tree.
3 the default value of a configuration attribute.

1424 SHDSL Router Preface ix
TDRE version
The Total Dynamic Routing Engine (TDRE) is a feature-rich operating system that guarantees a com-
mon feature set across the different OneAccess product lines and a uniform support by maintenance
and management tools.
This manual describes the features, containment tree and attributes of the TDRE version 12.2.
Audience
This manual is intended for computer-literate people, who have a working knowledge of computing and
networking principles.
Your feedback
Your satisfaction about this purchase is an extremely important priority to all of us at OneAccess. Accord-
ingly, all electronic, functional and cosmetic aspects of this new unit have been carefully and thoroughly
tested and inspected. If any fault is found with this unit or should you have any other quality-related com-
ment concerning this delivery, please submit the Quality Comment Form on our web page at
www.oneaccess-net.com → Contact → Send a quality comment form.
x 1424 SHDSL Router Table of contents
Table of contents
User manual............................................................................................ 1
1 Introducing the 1424 SHDSL Router ..................................................................3
1.1 General description .................................................................................................... 4
1.2 1424 SHDSL Router family overview ......................................................................... 6
1.3 Overview of features .................................................................................................. 7
1.4 Maintenance and management tools ......................................................................... 8
1.5 Maintenance and management tools connection possibilities ................................. 10
2 Installing and connecting the 1424 SHDSL Router ........................................11

2.1 Safety instructions .................................................................................................... 12
2.2 Unpacking ................................................................................................................ 13
2.3 Selecting a site ......................................................................................................... 14
2.4 Mounting the 1424 SHDSL Router on a wall............................................................ 15
2.5 Connection precautions............................................................................................ 17
2.6 Connecting the 1424 SHDSL Router ....................................................................... 18
2.7 The front panel LED indicators................................................................................. 22
2.8 Powering up the 1424 SHDSL Router...................................................................... 25
3 DIP switches of the 1424 SHDSL Router .........................................................27

3.1 The 1424 SHDSL Router motherboard .................................................................... 28
3.2 Opening and closing the housing ............................................................................. 29
4 Maintaining the 1424 SHDSL Router................................................................31

4.1 Maintaining the 1424 SHDSL Router with TMA ....................................................... 32
4.2 Introducing the management terminology ................................................................ 38
4.3 The objects in the 1424 SHDSL Router containment tree ....................................... 42
4.4 Adding an object to the containment tree................................................................. 45
4.5 1424 SHDSL Router attribute overview ................................................................... 50
5 Basic configuration ...........................................................................................51

5.1 What is an interface?................................................................................................ 52
5.2 Configuring IP addresses ......................................................................................... 53
5.3 Managing devices using SNMP ............................................................................... 65
5.4 Configuring the SHDSL line ..................................................................................... 75
5.5 Enabling EOC message exchange .......................................................................... 79
5.6 Configuring passwords............................................................................................. 87
5.7 Executing configuration actions................................................................................ 89
5.8 Troubleshooting the 1424 SHDSL Router................................................................ 93
1424 SHDSL Router Table of contents xi
6 Configuring the WAN encapsulation protocols ..............................................95

6.1 Selecting an encapsulation protocol......................................................................... 96
6.2 Configuring ATM encapsulation ............................................................................... 97
6.3 Configuring OAM on ATM interfaces...................................................................... 125
6.4 Configuring ATM IMA ............................................................................................. 138
6.5 Configuring EFM encapsulation ............................................................................. 141
6.6 Configuring Frame Relay encapsulation ................................................................ 145
6.7 Configuring PPP encapsulation.............................................................................. 160
7 Configuring routing .........................................................................................185

7.1 Introducing routing.................................................................................................. 186
7.2 Enabling routing on an interface............................................................................. 187
7.3 Configuring static routes......................................................................................... 188
7.4 Configuring policy based routing ............................................................................ 197
7.5 Configuring RIP ...................................................................................................... 204
7.6 Configuring OSPF .................................................................................................. 212
7.7 Configuring BGP .................................................................................................... 221
7.8 Configuring address translation.............................................................................. 225
7.9 Configuring VRRP .................................................................................................. 247
7.10 Configuring Virtual Routing and Forwarding or VRF .............................................. 254
7.11 Applying QoS on routed traffic ............................................................................... 259
8 Configuring bridging and VLANs ...................................................................297

8.1 Introducing bridging................................................................................................ 298
8.2 Configuring bridging ............................................................................................... 311
8.3 Configuring VLANs................................................................................................. 325
8.4 Configuring VLANs on the 4 port Ethernet switch .................................................. 336
8.5 Bridge traffic classification by filtering .................................................................... 344
8.6 Bridge traffic classification by applying QoS on bridged traffic............................... 352
8.7 Example: combining bridging and routing in a network.......................................... 360
9 Configuring the additional features ...............................................................363

9.1 Configuring DHCP.................................................................................................. 364
9.2 Configuring the access restrictions ........................................................................ 370
9.3 Tuning the bandwidth on the LAN interface ........................................................... 376
9.4 Configuring L2TP tunnels....................................................................................... 379
9.5 Configuring GRE tunnels........................................................................................ 389
9.6 Configuring IP security ........................................................................................... 407
9.7 Configuring RADIUS .............................................................................................. 440
9.8 Configuring the stateful inspection firewall ............................................................. 450
9.9 IP SLA or traffic quality monitoring ......................................................................... 474
9.10 Logging of performance statistics........................................................................... 479
10 Configuration examples ..................................................................................485

10.1 LAN extension over a PDH/SDH network .............................................................. 486
xii 1424 SHDSL Router Table of contents
Reference manual .............................................................................. 489

11 Configuration attributes ..................................................................................491
11.1 Configuration attribute overview............................................................................. 492
11.2 General configuration attributes ............................................................................. 503
11.3 LAN interface configuration attributes .................................................................... 509
11.4 WAN interface configuration attributes................................................................... 530
11.5 Encapsulation configuration attributes ................................................................... 532
11.6 SHDSL line configuration attributes ....................................................................... 578
11.7 Profiles configuration attributes .............................................................................. 591
11.8 Bundle configuration attributes............................................................................... 610
11.9 Router configuration attributes ............................................................................... 616
11.10Bridge configuration attributes................................................................................ 771
11.11SNMP configuration attributes................................................................................ 796
11.12Management configuration attributes ..................................................................... 799
12 Status attributes ..............................................................................................817

12.1 Status attribute overview ........................................................................................ 818
12.2 General status attributes ........................................................................................ 827
12.3 LAN interface status attributes ............................................................................... 831
12.4 WAN interface status attributes.............................................................................. 843
12.5 Encapsulation status attributes .............................................................................. 846
12.6 SHDSL line status attributes .................................................................................. 887
12.7 End and repeater status attributes ......................................................................... 896
12.8 Bundle status attributes.......................................................................................... 900
12.9 Router status attributes .......................................................................................... 911
12.10Bridge status attributes........................................................................................... 976
12.11SNMP status attributes........................................................................................... 991
12.12Management status attributes ................................................................................ 993
12.13File system status attributes................................................................................. 1000
12.14Operating system status attributes....................................................................... 1011
13 Performance attributes .................................................................................1013

13.1 Performance attributes overview.......................................................................... 1014
13.2 General performance attributes............................................................................ 1022
13.3 LAN interface performance attributes................................................................... 1024
13.4 WAN interface performance attributes ................................................................. 1032
13.5 Encapsulation performance attributes.................................................................. 1033
13.6 SHDSL line performance attributes...................................................................... 1046
13.7 End and repeater performance attributes............................................................. 1050
13.8 Bundle performance attributes ............................................................................. 1051
13.9 Router performance attributes.............................................................................. 1054
13.10IP traffic policy performance attributes ................................................................. 1097
13.11Bridge performance attributes .............................................................................. 1099
13.12SNMP performance attributes .............................................................................. 1109
13.13Management performance attributes ................................................................... 1112
13.14Operating system performance attributes ............................................................ 1115
1424 SHDSL Router Table of contents xiii
14 Alarm attributes .............................................................................................1119

14.1 Alarm attributes overview ..................................................................................... 1120
14.2 Introducing the alarm attributes............................................................................ 1123
14.3 General alarms..................................................................................................... 1126
14.4 LAN interface alarms............................................................................................ 1128
14.5 WAN interface alarms .......................................................................................... 1129
14.6 EFM alarms .......................................................................................................... 1131
14.7 SHDSL line alarms ............................................................................................... 1132
14.8 SHDSL line pair alarms ........................................................................................ 1133
14.9 End and repeater alarms...................................................................................... 1135
14.10Bundle alarms ...................................................................................................... 1139
14.11Router and vrfRouter[ ] alarms ............................................................................. 1140
14.12Bridge group alarms ............................................................................................. 1141
14.13BGP ePeer and iPeer alarms .................................................................................. 1142
15 TMA sub-system picture ...............................................................................1143
16 Auto installing the 1424 SHDSL Router.......................................................1147

16.1 Introducing the auto-install protocols.................................................................... 1148
16.2 Auto-install on the LAN interface.......................................................................... 1150
16.3 Auto-install on the WAN interface ........................................................................ 1155
16.4 Creating a configuration file.................................................................................. 1162
16.5 Restoring a configuration file................................................................................ 1169
17 Downloading software ..................................................................................1173

17.1 What is boot and application software?................................................................ 1174
17.2 Downloading application software using TMA...................................................... 1175
17.3 Downloading application software using TFTP .................................................... 1176
17.4 Downloading application software using TML ...................................................... 1177
17.5 Downloading application software using FTP ...................................................... 1178
17.6 Downloading files to the file system ..................................................................... 1179
xiv 1424 SHDSL Router Table of contents
18 Technical specifications ...............................................................................1181

18.1 SHDSL line specifications .................................................................................... 1182
18.2 LAN interface specifications ................................................................................. 1183
18.3 4 port Ethernet switch specifications .................................................................... 1184
18.4 Console port specifications .................................................................................. 1185
18.5 IP address assignment and auto-provisioning ..................................................... 1186
18.6 ATM encapsulation specifications ........................................................................ 1187
18.7 Frame Relay encapsulation specifications ........................................................... 1188
18.8 PPP encapsulation specifications ........................................................................ 1189
18.9 EFM encapsulation specifications ........................................................................ 1190
18.10IP routing specifications ....................................................................................... 1191
18.11Bridging specifications.......................................................................................... 1193
18.12Network address translation specifications .......................................................... 1194
18.13Tunnelling and VPN specifications....................................................................... 1195
18.14Priority and traffic policy specifications................................................................. 1196
18.15Firewall specifications .......................................................................................... 1199
18.16Access security specifications.............................................................................. 1200
18.17Maintenance and management specifications ..................................................... 1200
18.18Memory specifications.......................................................................................... 1201
18.19Power requirements ............................................................................................. 1202
18.20Dimensions........................................................................................................... 1203
18.21Safety compliance ................................................................................................ 1204
18.22Over-voltage and over-current protection compliance ......................................... 1204
18.23EMC compliance .................................................................................................. 1204
18.24Environmental compliance ................................................................................... 1204
Annex ................................................................................................ 1205

Annex A:common TCP and UDP numbers ........................................................1207
Annex B:product information .............................................................................1209
Annex C:Console cable .......................................................................................1211
Index .................................................................................................. 1213

1424 SHDSL Router 1
User manual
User manual
2 1424 SHDSL Router
User manual
1424 SHDSL Router Chapter 1 3
User manual Introducing the 1424 SHDSL Router
1 Introducing the 1424 SHDSL Router

This chapter gives an introduction to the OneAccess TDRE devices. The following gives an overview of
this chapter:
• 1.1 - General description on page 4
• 1.2 - 1424 SHDSL Router family overview on page 6
• 1.3 - Overview of features on page 7
• 1.4 - Maintenance and management tools on page 8
• 1.5 - Maintenance and management tools connection possibilities on page 10
4 1424 SHDSL Router Chapter 1
1.1 General description
A general description of the OneAccess TDRE devices is given in following sections:

• 1.1.1 - 1424 SHDSL Router on page 5
As of TDRE 12.0:
• the operating system has been adapted with an improved buffer management. It makes more effi-
cient use of Mbuf ‘s: there are 2000 normal Mbuf ‘s available, each with a size of 1500 bytes. Short
Mbuf ‘s exist as well, they are 64 bytes each, and are used in cell related switching.
Before TDRE 12.0, the size of the Mbuf ‘s was 220 bytes, with about 14000 Mbuf ‘s in total available.
This has an impact on the overall performance and in particular with some software modules like the
firewall.
In other words, it results in a more efficient use of the Mbuf ‘s, which means the performance is
increased. It must be taken into account however that the total number of available Mbuf ‘s is less
than before.
• a common packet driver is used for HDLC, ATM and ethernet. This results in an increased perform-
ance: per second, more packets can be treated by the 1424 SHDSL Router.
1.1.1 1424 SHDSL Router
The 1424 SHDSL Router is a secure SHDSL router for high bandwidth applications. The SHDSL multi-
pair interface offers a bandwidth up to 22Mbps over up to 4 copper pairs.
High speed DSL access
The 1424 SHDSL Router includes a high speed symmetrical bandwidth in various DSL networks and at
various local loop distances. It includes a SHDSL.bis interface with up to 4 copper pairs. This provides
line rates up to 22Mbps on short distances and up to 10Mbps on operator standard loop lengths. The
various pair bonding techniques make it suitable for any type of DSL infrastructure. The 1424 SHDSL
Router supports both ATM and EFM modes in single and multipair topologies.
High network availability
A dedicated Ethernet interface is available as a backup when the DSL network is not available. Traffic
is automatically routed to the available network. Alternatively this interface can be used for a DMZ zone
(De-Militarised Zone).
Ethernet services
The 1424 SHDSL Router relies on the robust TDRE software, the OneAccess Bridging and Routing
Engine offering advanced layer 2 and layer 3 functions. Ethernet functionalities include Spanning Tree
Protocol, multiple bridge groups and VLAN features such as tagging, switching, QinQ, COS/TOS and
TOS/COS mapping and Ethernet QoS. VLANs and ATM PVCs have the status and statistics character-
istics of a physical interface.
Full service router
On IP level, the equipment implements different routing protocols such as RIP, OSPF and BGP-4 and
Policy based routing. The 1424 SHDSL Router provides secured Internet access through a stateful
inspection firewall. The business applications can be used based on central databases through IP VPNs.
For this purpose, advanced VPN functions such as L2TP, GRE and IPSec with encryption are standard
included. It provides best-in-class IP Quality of Service features including real-time processing of high
priority, delay sensitive applications and guaranteed bandwidth for selected flows.
Accelerated deployment and service provisioning
As all TDRE routers, the 1424 SHDSL Router is manageable through a variety of maintenance and man-
agement tools. These include:
• A free graphical user interface for local or remote maintenance.
• A customisable Web-configuration utility.
• A CLI to facilitate scripting.
• Easy integration into Network element management platforms such as TMA or HP OpenView.
Technicians or the customer install the units with a standard configuration. Once connected to the net-
work the 1424 SHDSL Router automatically retrieves all customer specific information from the service
provider’s databases and thus becomes ready for the service.
1.2 1424 SHDSL Router family overview
The following gives an overview of the 1424 SHDSL Router versions:
SHDSL line pairs
Ethernet ports
Standard
version
Flash
RAM
1424 SHDSLBIS 1P 1 1+4 64MB 32MB

1.3 Overview of features
The following tables give an overview of which features are present on the OneAccess devices.
WAN encapsulations
Products 1424
Interface type DSL

PPP
Multilink PPP
Multi-class PPP
Frame Relay
Multilink Frame Relay
HDLC
Error Test
ATM X
ATM IMA X
EFM X
Other features
Feature 1424
Hardware accelerator (HWA) X
DES encryption X
3DES encryption X
ATM CBR service category X
ATM VBR-rt &VBR-nrt service X
ATM OAM Performance Management (PM) X
Statefull inspection firewall & application layer gateway X
ISAKMP, IKE & IPSEC certificates X
BGP4, GRE, native IPSEC X
PPPoE client on the LAN X
Ready for IPv6 X
SSH & HTTPS server X
Customisable JAVA web interface X
Reset button
1.4 Maintenance and management tools
The 1424 SHDSL Router is manageable in many different ways. This section gives a quick overview of
the various maintenance and management tools.
Maintenance or Description and reference

management
tool
TMA TMA (Total Maintenance/Management Application) is a free Windows software

package with a comprehensive graphical user interface that enables you to control
the OneAccess products completely. I.e. to access their configuration attributes
and look at status, performance and alarm information.
Refer to 4 - Maintaining the 1424 SHDSL Router on page 31 and the TMA manual
(PDF) for more information.
TMA Element TMA Element Management is a management application designed to monitor

Management large numbers of OneAccess devices. It combines the easy to use graphical inter-
face of the stand-alone version of TMA with an event-logging application called the
Element Viewer.
Refer to the TMA Element Management manual (PDF/CHM) for more information.
TMA for HP TMA for HP OpenView is the management application that runs on the widely
OpenView spread network management platform HP OpenView. It combines the easy to use
graphical interface of the stand-alone version of TMA with the advantages and fea-
tures of HP OpenView.
Refer to the TMA for HP OpenView manual (PDF) for more information.
TMA CLI TMA CLI (TMA Command Line Interface) enables you to use its commands in
scripts in order to automate management actions. This is particularly useful in
large networks. TMA CLI is a complementary product to TMA, TMA Element Man-
agement and TMA for HP OpenView.
Refer to the TMA CLI manual (PDF) for more information.
ATWIN ATWIN is a menu-driven user interface. You can read and change all attributes as
with TMA, but in a more basic, textual representation using a VT100 terminal.
Refer to the Maintenance tools manual (PDF) for more information.
CLI CLI is also a Command Line Interface, although not so extensive as TMA CLI.
Experienced users who are familiar with the syntax can access the OneAccess
devices more quickly than with TMA or ATWIN.
Web Interface The Web Interface is an ATWIN alike menu-driven user interface. You can read
and change all attributes as with TMA, but in a more basic representation using a
web browser.
Note that the HTTP interfaces are not only available on port 80, but also on
port 8080. This allows connecting to the HTTP interfaces in case a NAT
service is defined on port 80.
Maintenance or Description and reference

management
tool
SNMP You can manage the 1424 SHDSL Router through SNMP using any SNMP
browser. The 1424 SHDSL Router supports MIB2 and a private MIB, including
traps.
The private MIB files come with your copy of TMA. After installation of the TMA
data files, the private MIB files are available in directory C:\Program
Files\TMA\snmp1.
The “old” MIB files, from before the SNMPv2 era, can be recognised by the follow-
ing format: <filename>.mib2.
The “new” MIB files can be recognised by the following format:
<filename>_smiv2.mib
Refer to 5.3 - Managing devices using SNMP on page 65 for more information on
MIB ‘s and SNMP. Also refer to 11.11 - SNMP configuration attributes on page 796
and the documentation of your SNMP browser for more information.
Easy Configura- The Easy Configurator allows you to add HTML pages on top of the standard Web
tor Interface by adding a set of specific files on the file system of the 1424 SHDSL
Router. These files can be made either by OneAccess or by the customer itself.
The goal is to offer a simple, custom made web interface which allows only to
change or show those parameters that are relevant for a certain application or cus-
tomer.
Note that the HTTP interfaces are not only available on port 80, but also on
port 8080. This allows connecting to the HTTP interfaces in case a NAT
service is defined on port 80.
1. The first part of the directory path may be different if you did not choose the default path during
the installation of the TMA data files.
2. The filename is product dependent. To determine which MIB file corresponds with which prod-
uct, refer to the models.nms file (located in C:\Program Files\TMA\model1).
1.5 Maintenance and management tools connection possibilities
The following table gives an overview of all the maintenance and management tools and how you can
connect them with the 1424 SHDSL Router:
Maintenance or manage- Tool - 1424 SHDSL Router con- Tool - management concentra-
ment tool nection tor connection1, 2
Serial3 IP4 Serial3 IP4
CLI X5 X6 X5 X6
ATWIN X5 X6 X5 X6
TMA X X X X
TMA CLI X X X X
TMA Element Management X X
TMA for HP OpenView X X
SNMP7 X X
Web Interface8 X X
1. Examples of management concentrators are the Orchid 1003 LAN, the 1030 Router series, the
2300 SHDSL series, the 1040 Router series, etc. Refer to their corresponding manuals for
more information on how to set up these devices as management proxy.
2. Not applicable to 1431 and 1432 SHDSL CPE.
3. A serial connection is a connection between the COM port of your PC and the control connec-
tor of the OneAccess device using a male-female DB9 cable.
4. An IP connection is a connection between your PC and the 1424 SHDSL Router over an IP
network.
5. Using a VT100 terminal (emulation program).
6. Using Telnet.
7. Using an SNMP browser
8. Using a web browser
User manual Installing and connecting the 1424 SHDSL Router
2 Installing and connecting the 1424 SHDSL Router

First this chapter gives some important safety instructions. Then it explains how to install and connect
the 1424 SHDSL Router.
You are advised to read this chapter from the beginning to the end, without skipping any part. By doing
so, your 1424 SHDSL Router will be completely installed and ready for configuration when you reach the
end of this chapter.
The following gives an overview of this chapter:

• 2.1 - Safety instructions on page 12
• 2.2 - Unpacking on page 13
• 2.3 - Selecting a site on page 14
• 2.4 - Mounting the 1424 SHDSL Router on a wall on page 15
• 2.5 - Connection precautions on page 17
• 2.6 - Connecting the 1424 SHDSL Router on page 18
• 2.7 - The front panel LED indicators on page 22
• 2.8 - Powering up the 1424 SHDSL Router on page 25
2.1 Safety instructions
IMPORTANT SAFETY INSTRUCTIONS
• Disconnect the power supply before installing, adjusting or servicing the unit. Always disconnect the
AC input first.
• The external power supply is connected on the rear panel of the device, and may be delivered
together with the 1424 SHDSL Router.
• To connect the power supply, proceed as follows:
- Connect the DC input jack from the power supply to the DC 12V power input on the rear panel of
the device.
- Secure the power supply connection by installing the DC power supply cord into the foreseen clip.
- Connect the power supply to an AC electrical outlet (100-240 VAC). Plugging in the power supply
turns the router on.
• Do not use another type of power supply then the one prescribed by OneAccess.
• Over current Protection: This device requires that the building’s electrical installation is designed for
protection against short-circuit (over-current) protection. A fuse or circuit breaker no larger than 240
VAC, 10A must be used on the phase conductors.
SAFETY WARNING
• To avoid damage to the unit, please observe all procedures described in this chapter.
• It is essential that the earth stud on the back panel is effectively connected to earth. Otherwise, in
case of electrical problems, other devices connected to the 1424 SHDSL Router could be damaged.
Also refer to 2.6.2 - Back panel earth connection on page 21.
Ensure that the unit and its connected equipment all use the same power and ground, to reduce noise
interference and possible safety hazards caused by differences in ground or earth potentials.
2.2 Unpacking
Checking the shipping carton
Rough handling during shipping causes most early failures. Before installation, check the shipping car-
ton for signs of damage:
• If the shipping carton is damaged, please place a claim with the carrier company immediately.
• If the shipping carton is undamaged, do not dispose of it in case you need to store the unit or ship it
in the future.
2.3 Selecting a site
WARNING
Always place the unit in such a way that the air vents are not blocked.
Install the unit in an area free of extreme temperatures, humidity, shock and vibration. Position it so that
you can easily see and access the front panel and its control indicators. Leave enough clearance at the
back for cables and wires. Position the unit within the correct distances for the different accesses and
within 2m of a power outlet.
2.4 Mounting the 1424 SHDSL Router on a wall
Procedure
The backpanel of the 1424 SHDSL Router has 2 notches in order to enable wall mounting. Refer to the
figure below, for the position of these notches. By installing two screws at the required distance, the
router can be hung on any vertical surface.
In order to do so, proceed as follows:
Step Action
1 Drill two holes in the wall, according to the following specifications:

• hole diameter: 6 mm
• distance between the holes: 160 mm
• hole depth: at least 50 mm
2 Insert two standard wall plugs in the holes. The plugs should have the following dimen-
sions:
• diameter: 6 mm
• length: < 50 mm
3 Screw in two standard screws in the plugs. Leave a distance of 5 mm between the wall
and the head of the screw. The screws should have the following dimensions:
• diameter: 4 mm
• length: 40 mm
• The head of the screws may have a diameter of maximum 8 mm.
4 Slide the 1424 SHDSL Router over the screws until it touches the wall, and gently push
it down. If necessary, adjust the screws in the notches of the router.
Bottom plate of the 1424 SHDSL Router

2.5 Connection precautions
ESD WARNING
The circuit boards are sensitive to electrostatic discharges (ESD) and should be handled with care. It is
advisable to ensure an optimal electrical contact between yourself, the working area and a safety ground
before touching any circuit board. Take special care not to touch any component or connector on the
circuit board.
NOTE
This unit may be powered by an IT power system.

For the definition of an IT power system, refer to Annex V - AC power distribution systems of EN60950-1.
The connectors of the 1424 SHDSL Router should only be connected to the following circuit types:
Connector Connector label Connector type Circuit type
SHDSL SHDSL RJ45 TNV-1
LAN interface1 ETHERNET/SWITCH RJ45 SELV
RS232 Interface2 Console RJ45 SELV
Earth stud Clinching stud Earth
1. 10/100 Mbps interface

2. V.24
• SELV (Safety Extra Low Voltage): local connection (e.g. PC to 1424 SHDSL Router) or leased line
inside the building.
• TNV-1 (Telecom Network Voltage): leased line outside the building.
• TNV-2: PSTN from PABX inside the building.
• TNV-3: PSTN from operator PABX outside the building.
2.6 Connecting the 1424 SHDSL Router
This section describes the 1424 SHDSL Router rear panel, so that the user can identify the interface
type and port numbering.
The following gives an overview of this section:
• 2.6.1 - Rear view of the 1424 SHDSL Router on page 19
• 2.6.2 - Back panel earth connection on page 21
2.6.1 Rear view of the 1424 SHDSL Router
The following figure shows the back panel of the 1424 SHDSL Router:
Following connectors are present:
Connector(s) Label Type Function
Line LINE RJ45 SHDSL line connector
Console CONSOLE RJ45 V.24 DTE interface
Ethernet LAN2 RJ45 Ethernet LAN connector
4 port Ethernet LAN1 RJ45 Ethernet LAN connectors

switch
Power 12V-1A DC input Power input

jack
The following table gives an overview of the possible connectors located at the back of the 1424 SHDSL
Router and explains their function:
Label Function
CONSOLE This RJ45 connector is a V.24 DTE interface. This enables you to manage the
1424 SHDSL Router locally. For more information, refer to 18.4 - Console port
specifications on page 1185.
This is the earth stud. Connect the earth wire to this stud. Refer to 2.6.2 - Back
panel earth connection on page 21 for more information.
Contact the appropriate electrical inspection authority or an electrician if you are
uncertain that suitable grounding is available.
LINE This RJ45 connector is the SHDSL line connector.

Connect one side of an SHDSL line cable (not included) to the LINE connector of
the 1424 SHDSL Router and the other side to an SHDSL outlet.
For optimum performance, the used line pairs have to be properly twisted.
Refer to 18.1 - SHDSL line specifications on page 1182 for the pin lay-out of this
connector.
LAN1 These RJ45 connectors are the Ethernet LAN connectors. There are 4+1 Ethernet
LAN2 LAN connectors on the 1424 SHDSL Router.
The separate Ethernet interface can be used as main WAN link or as a back-up
WAN link interface. The Ethernet switch is VLAN manageable.
Connect one side of an Ethernet LAN cable (not included) to the LAN connector of
the 1424 SHDSL Router and the other side to an Ethernet network outlet. Each
LAN interface supports 10/100 Mbps auto-sense and auto cross-over.
Refer to 18.2 - LAN interface specifications on page 1183 for the pin lay-out of this
connector.
12VDC-1A This is the power input. Insert the plug of the external power supply in this socket.
Secure the power supply connection by installing the DC power supply cord into
the plastic ring provided on the back panel.
Refer to 18.19 - Power requirements on page 1202 for the power specifications of
• Note that an earth stud is also present on the back panel.

• The back panel may be slightly different on specific versions of the 1424 SHDSL Router.
2.6.2 Back panel earth connection
Safety
It is essential that the earth stud on the back panel is effectively connected to earth. Otherwise, in case
of electrical problems, other devices connected to the 1424 SHDSL Router could be damaged.
Earth Connection
To connect an earth wire to the clinching stud on the back panel, use:
• 2 round M3 washers; these are delivered with the 1424 SHDSL Router.
• 1 M3 nut; this is also delivered with the 1424 SHDSL Router.
• 1 M3 ring tongue; this is not delivered with the 1424 SHDSL Router.
Proceed as follows:
Step Action
1 Slide one of the round M3 washers over the clinching stud.
2 If not already done so, the earth cable that will be connected to the clinching stud, must
be equipped with an M3 ring tongue.
3 Slide the M3 ring tongue of the earth cable over the clinching stud.
4 Slide the second M3 round washer over the clinching stud.
5 Use the M3 nut to fix everything; make sure it is firmly fixed.

2.7 The front panel LED indicators
This section gives an overview of the front panel LEDs and what they indicate. The following gives an
overview of this section:
• 2.7.1 - Introducing the front panel LEDs on page 23
• 2.7.2 - LED states on page 24
2.7.1 Introducing the front panel LEDs
When all the connections are made and the 1424 SHDSL Router is powered, the LEDs on the front panel
reflect the actual status of the device.
The following figure shows the front panel LED indicators of the 1424 SHDSL Router:
The front panel may be slightly different on specific versions of the 1424 SHDSL Router.
LED states
One front panel LED can reflect different status modes by the way it lights up. The front panel LEDs can
light up as follows:
LED state LED duty cycle Description
OFF 0% The LED never lights up.
ON 100 % The LED lights up continuously.
blinking 50 % The LED is alternating 0,5 seconds ON, and 0,5 seconds OFF.
2.7.2 LED states
The state of the LEDs indicates the following:
LED name Colour Description
PWR Bicolour • OFF: no input power

• ON - Green: switched on and operational
• ON - Red: switched on and not operational
• Blinking green : (Re)boot in progress
LINK Bicolour • OFF: The SHDSL interface is not configured.

• ON - Green: The SHDSL uplink is synchronised.
• ON - Red: The SHDSL interface is not synchronised (although it
is configured).
• Blinking green: The SHDSL synchronisation is in progress.
IP Bicolour • OFF: No IP routing has been configured.

• ON - Green: All IP interfaces on the SHDSL link are up.
• ON - Red: All IP interfaces on the SHDSL link are down.
• Blinking green: At least one IP interface is up and at least one is
not up on the SHDSL link.
LAN1 Green • OFF: None of the ports on the Ethernet switch is active.
• ON - Green: At least one of the ports on the Ethernet switch is
active.
• Blinking green: Traffic in progress on at least one of the ports on
the Ethernet switch.
LAN2 Green • OFF: The second Ethernet port is inactive.

• ON - Green: The second Ethernet port is active.
• Blinking green: Traffic in progress on the second Ethernet port.
2.8 Powering up the 1424 SHDSL Router
To power up the 1424 SHDSL Router, always follow these steps:

• Connect the DC power input jack from the power supply to the DC power input of the rear panel of
the router.
• Connect the power supply to the AC mains (100-240 V AC).
Self test
A few seconds after the power is switched on, the 1424 SHDSL Router performs a series of self-tests
and loads the software into memory (RAM), during which the PWR LED on the front panel blinks.
At the end of the software loading, after about 30 seconds, if:
• the PWR LED remains green continuously, it means that the software initialization was successful.
• the PWR LED blinks, it means that:
- the software was absent,
or,
- there was an error during the software loading process.
User manual DIP switches of the 1424 SHDSL Router
3 DIP switches of the 1424 SHDSL Router

This chapter locates the DIP switches on the 1424 SHDSL Router motherboard. It gives an overview of
their function and it explains how to change their settings.
This chapter informs about the 1424 SHDSL Router motherboard, and shows how to open the housing.
• 3.1 - The 1424 SHDSL Router motherboard on page 28
• 3.2 - Opening and closing the housing on page 29
Default settings are printed in bold.

3.1 The 1424 SHDSL Router motherboard
The 1424 SHDSL Router motherboard is equipped with the following interfaces:
• SHDSL line connector
• Console port
• Managed switch with 4 ports
• Additional Ethernet port
For more information, refer to 2.6.1 - Rear view of the 1424 SHDSL Router on page 19.
3.2 Opening and closing the housing
When you want to change the DIP switch settings, you have to open and close the housing. This section
explains how to do so.
Opening the housing
To open the housing of the 1424 SHDSL Router, proceed as follows:
Step Action
1 Disconnect the external power supply; always disconnect the AC input first, then discon-
nect the DC input jack on the device itself.
2 Unscrew both screws at the bottom of the unit and remove them.
3 Slide the cover backwards and remove it, but always keep the following in mind:
Slide the cover backwards by pressing underneath the wall mounting holes, as shown in
the picture below.
Closing the housing
To close the housing of the 1424 SHDSL Router, proceed as follows:
Step Action
1 Slide the cover back over the device.
Do not close the housing while holding it upside-down.
2 Fasten both bottom screws .
3 Reconnect the external power supply; first, connect the DC input jack on the device itself,
then connect the power supply to the AC mains.
User manual Maintaining the 1424 SHDSL Router
4 Maintaining the 1424 SHDSL Router

Once you installed the 1424 SHDSL Router, you can proceed with the configuration of the 1424 SHDSL
Router. You can do this using any of the maintenance or management tools introduced in 1.4 - Mainte-
nance and management tools on page 8.
This chapter briefly highlights one of those tools: the Total Maintenance Application (TMA). It introduces
TMA and describes how to start a session on the 1424 SHDSL Router. It also introduces the terminology
concerning the management of a OneAccess device. Furthermore, it explains why and how to add an
object to the containment tree.
• 4.1 - Maintaining the 1424 SHDSL Router with TMA on page 32
• 4.2 - Introducing the management terminology on page 38
• 4.3 - The objects in the 1424 SHDSL Router containment tree on page 42
• 4.4 - Adding an object to the containment tree on page 45
• 4.5 - 1424 SHDSL Router attribute overview on page 50
4.1 Maintaining the 1424 SHDSL Router with TMA
First, this section introduces TMA. Then it describes how to start a session on the 1424 SHDSL Router.
• 4.1.1 - What is TMA? on page 33
• 4.1.2 - How to connect TMA? on page 33
• 4.1.3 - Connecting with TMA through the control connector on page 34
• 4.1.4 - Connecting with TMA over an IP network on page 36
4.1.1 What is TMA?
TMA is the acronym for Total Maintenance Application. TMA is a free Windows software package that
enables you to maintain the 1424 SHDSL Router, i.e. to access its configuration attributes and look at
status, performance and alarm information using a user friendly graphical user interface.
TMA is an excellent tool for complete control of the OneAccess access devices. When using TMA in
combination with a network management system such as HP OpenView, complete networks can be
managed from one central site.
Consult the TMA manual (PDF) to find out how to install TMA and to get acquainted with the user inter-
face.
You will need a new version of the model file distribution if changes have been made to the attributes of
the 1424 SHDSL Router. The most recent model files and TMA engine can always be downloaded from
the OneAccess web site at http://www.oneaccess-net.com → Download Center.
4.1.2 How to connect TMA?
There are two ways to establish a connection between the computer running TMA and the 1424 SHDSL
Router:
• through a serial connection, i.e. through the control connector of the device. Refer to 4.1.3 - Connect-
ing with TMA through the control connector on page 34.
• through an IP connection, i.e. through the LAN connector of the 1424 SHDSL Router. Refer to 4.1.4
- Connecting with TMA over an IP network on page 36.
4.1.3 Connecting with TMA through the control connector
To established a connection between TMA and the 1424 SHDSL Router through the control connector,
proceed as follows:
Step Action
1 Connect a serial port of your com-

puter (e.g. COM1) through a
straight DB9 male - female cable
or straight DB9 - RJ45 cable with
the control connector of the device.
2 Start TMA.
3 In the TMA window, either …

• select from the menu bar: Connect →
Device…
• or press the short-cut key: Ctrl+N
• or click on the Connect to device button:
The Connect… (to a device) window is displayed

as in the following figure:
4 In the Connect… (to a device) window, specify the following:

• Select the option Serial and specify the COM port of your computer to which the
device is connected.
• If previously a password has been configured in the device then also fill in the pass-
word field.
5 Click on the Next > button.

⇒The second Connect… window is displayed.
Step Action
6 In the Connect… (select a device) window, pro-

ceed as follows to connect to the …
• local 1424 SHDSL Router: select On device.
• remote 1424 SHDSL Router:
- Select After device.
- Enter 1 in the NMS address field.
- Select Relative.
- If previously a password has been config-
ured in the remote 1424 SHDSL Router
then also fill in the password field.
You can only connect to a remote 1424

SHDSL Router if the data link is up.
7 Click on the Finish button.
8 After a couple of seconds, the attributes of the 1424 SHDSL Router appear in the TMA
window.
4.1.4 Connecting with TMA over an IP network
To established a connection between TMA and the 1424 SHDSL Router over an IP network, proceed as
follows:
Step Action
1 Connect the IP network

to …
• the network port of
your PC,
• the LAN connector of
the 1424 SHDSL
Router.
2 Start TMA.
3 In the TMA window, either …

• select from the menu bar: Connect →
Device…
• or press the short-cut key: Ctrl+N
• or press on the Connect to device button:
The Connect… (to a device) window is being dis-

played as in the following figure:
4 In the Connect… (to a device) window, specify the following:

• Select the option IP address and enter the IP address of the 1424 SHDSL Router.
• If a password has previously been configured in the 1424 SHDSL Router then also fill
in the password field.
Before you are able to establish a connection over an IP network, you have to con-
figure an IP address and a default gateway in the 1424 SHDSL Router.
You can do this by first connecting TMA to the 1424 SHDSL Router through the control
connector, and then configuring an IP address and a default gateway. Refer to the 5.2 -
Configuring IP addresses on page 53.
5 Click on the Next > button.

⇒The second Connect… window is displayed.
Step Action
6 In the Connect… (select a device) window, pro-

ceed as follows to connect to the …
• local 1424 SHDSL Router: select On device.
• remote 1424 SHDSL Router:
- Select After device.
- Enter 1 in the NMS address field.
- Select Relative.
- If previously a password has been config-
ured in the remote 1424 SHDSL Router
then also fill in the password field.
You can only connect to a remote 1424

SHDSL Router if the data link is up.
7 Click on the Finish button.
8 After a couple of seconds, the attributes of the 1424 SHDSL Router appear in the TMA
window.
4.2 Introducing the management terminology
This section briefly introduces the terminology concerning the management of a OneAccess device. It
explains terms such as containment tree, group, object, attribute, value and action.
• 4.2.1 - Graphical representation of the containment tree on page 39
• 4.2.2 - Containment tree terminology on page 40
4.2.1 Graphical representation of the containment tree
The most comprehensible graphical representation of the containment tree is given in TMA. The follow-
ing figure depicts the TMA window displaying a containment tree:
Refer to 4.2.2 - Containment tree terminology on page 40 for an explanation of the terms associated with
the containment tree.
4.2.2 Containment tree terminology
Refer to 4.2.1 - Graphical representation of the containment tree on page 39 for a figure of a containment
tree.
The following table explains the terminology associated with the containment tree:
Term Description
containment tree The containment tree represents the hierarchical structure of the 1424 SHDSL
Router. It is composed of a number of objects that are ordered in a tree. This tree
resembles a Windows directory structure:
• it is also a levelled structure, with nodes which can be expanded or reduced.
• the containment tree objects can be compared with file folders.
• the objects contain attributes like file folders contain files.
object An object represents a physical interface, an application or a combination of both.

Each object has its own set of attributes.
parent and child Some objects are not present in the containment tree by default. If you want to use
object the features associated with such an object, then you have to add the object first.
You always add an object under another object. The object you add is called the
child object. The object under which you add this child object is called the parent
object.
Objects which you can add are also often referred to as user-instantiatable objects.
index name Of some objects more than one object is present in the containment tree. The dif-
ferent objects are distinguished from one another by adding an index. E.g. linePair[1]
and linePair[2], where 1 and 2 are the indexes. Also child objects are given an index
(by the user when adding the object).
An index name is also often referred to as index, instance value or instance name.
attribute An attribute is a parameter related to a certain object. It has a certain value.
value An attribute has a certain value which is …

• changeable in case of a configuration attribute (provided you have write
access).
• read only in case of a status, performance and alarm attribute.
structured value Some attribute values contain underlying values: a structured value. These values
are displayed in the structured value window. If an attribute contains structured val-
ues, then a bit string, <Table> or <Struct> is displayed after the attribute:
• a bit string is a series of bits. The value of each of these bits can be 0 or 1, on
or off, enabled or disabled.
• a table contains columns and rows. Each column contains an attribute (which,
on its turn, can have a structured value). Each row is an entry in the table.
• a structure contains columns but only one row. A structure could be compared
to an attribute which contains several “sub-attributes”.
A structured value is also often referred to as bit string, table, structure or complex
value.
Term Description
element An element is an attribute within a structured value. In other words, they could be
considered as “sub-attributes”.
group Groups assemble a set of attributes related by functionality. There are four groups
in TMA, which correspond with the four tabs in the attribute window:
• configuration,
• status,
• performance,
• alarms.
action A group in combination with an object may have actions assigned to them. These
actions are displayed in the action window.
4.3 The objects in the 1424 SHDSL Router containment tree
The following table lists the different objects of the 1424 SHDSL Router containment tree. It also speci-
fies whether the objects are present by default, whether you have to add them yourself or whether they
are added automatically.
> router1424
>> lanInterface1
>> lanInterface2
>> dslInterface
>>> channel[ ]
>>>> atm
>>>>> ima
>>>> efm
>>> line
>>>> linePair[ ]1
>>> repeater[ ]
>>> end2
>> profiles
>>> policy
>>>> traffic
>>>>> ipTrafficPolicy[ ]3
>>>>> bridgingTrafficPolicy[ ]3
>>>> priority
1. In case of a 1424 SHDSL Router 2 pair version, two linePair[ ] objects are present; In case of a
1424 SHDSL Router 4 pair version, four linePair[ ] objects are present.
2. Not present by default. Only appears when setting the eocHandling attribute. Refer to 5.5.3 -
Controlling the standard EOC message exchange on page 81.
3. Not present by default, has to be added. The index name is user defined. Refer to 4.4 - Adding
an object to the containment tree on page 45
>>>>> priorityPolicy[ ]3
>> bundle
>>> pppBundle[ ]3
>> ip
>>> router
>>>> tunnels
>>>> defaultNat
>>>> nat[ ]3
>>>> manualSA[ ]3
>>>> ikeSA[ ]3
>>>> routingFilter[ ]3
>>>> ospf
>>>>> area
>>>> bgp
>>>>> ePeer[ ]3
>>>>> iPeer[ ]3
>>>>> routeFilter[ ]3
>>>>> routeMap[ ]3
>>>> firewall
>>>> vrrp[ ]3
>>> vrfRouter[ ]3
>> bridge
>>> bridgeGroup
>>> vpnBridgeGroup[ ]3
>>> accessList[ ]3
>> snmp
>> management
>>> loopBack
>>> usrLoopback[ ]3
4.4 Adding an object to the containment tree
This section explains why and how you can add an object to the containment tree. It then explains why
and how to refer to this object.
• 4.4.1 - Why add an object to the containment tree? on page 46
• 4.4.2 - How to add an object to the containment tree? on page 47
• 4.4.3 - Referring to an added object on page 49
4.4.1 Why add an object to the containment tree?
Why can you add an object to the containment tree?
Some objects are not present in the containment tree by default but you can add them yourself because
…
• in this way the containment tree remains clear and surveyable,
• you possibly do not need the functions associated with such an object,
• you possibly need several of these objects so you can add as many objects as you like.
When do you have to add an object to the containment tree?
If you want to use the features associated with such an object, then you have to add the object first.
Which objects can be added to the containment tree?
Section 4.3 - The objects in the 1424 SHDSL Router containment tree on page 42 gives you an overview
of all the objects in the containment tree. It also tells you which objects have to be added before you can
use them.
4.4.2 How to add an object to the containment tree?
The section shows you, for each maintenance tool, how to add an object to the containment tree. The
following section, 4.4.3 - Referring to an added object on page 49, shows you how you can “refer” to this
added object somewhere else in the containment tree.
Adding an object in TMA
Step Action
1 Right click on the parent object (e.g. router).

⇒A pop-up menu appears.
2 In the pop-up menu, select Add Child… and select the child object you want to add (e.g.
routingFilter).
⇒A pop-up window appears.
3 In the pop-up window, type the index name (i.e. the instance value) for the child object
(e.g. my_filter) and click on OK.
⇒The new child object is created (e.g. routingFilter[my_filter]).
Adding an object in (TMA) CLI
Step Action
1 Enter the parent object (e.g. select router).
2 Type the following command: set {select childObjectName[instanceValue]{}}

where instanceValue is a string of your choice.
(e.g. set {select routingFilter[my_filter]{}})
⇒The new child object is created.
Adding an object in ATWIN
Step Action
1 Enter the parent object (e.g. go to the router object and press the enter key).
⇒The ATWIN window shows the sub-objects and attributes of the parent object.
2 Go to the line displaying the string <CREATE INSTANCE> and the name of the object you
want to add (e.g. routingFilter <CREATE INSTANCE>) and press the enter key.
⇒A new window appears, displaying the string Give the instanceValue.
3 Press the enter key and type the index name (i.e. the instance value) for the child object
(e.g. my_filter) and press the enter key again.
⇒The new child object is created (e.g. >.routingFilter [name:my_filter]).
Adding an object in the Web Interface
Step Action
1 Enter the parent object (e.g. select the router object and double-click it or click on Open).
⇒The Web Interface window shows the sub-objects and attributes of the parent
object.
2 Select the line displaying the string <CREATE INSTANCE> and the name of the object you
want to add (e.g. routingFilter <CREATE INSTANCE>) and double-click it or click on
Open.
⇒A new window appears, displaying the string Give the instanceValue.
3 Type the index name (i.e. the instance value) for the child object (e.g. my_filter) and click
on exit.
⇒The new child object is created (e.g. >.routingFilter [name:my_filter]).
4.4.3 Referring to an added object
What is referring to an added object?
If at a certain place in the containment tree you want to apply the function associated with an object you
added, then you have to refer to this object.
How to refer to an added object?
Some attributes allow you to enter the index name (i.e. the instance value you assigned to the object) of
an added object. By doing so, the function associated with this object is applied there.
Example
Suppose you create a routingFilter object with the index name my_filter. The containment tree then looks as
follows:
Now, you want to use this filter on the LAN interface. In that case, in the ip/rip structure in the lanInterface
object, enter the index name of the routingFilter object under the element “filter”. This looks as follows:
4.5 1424 SHDSL Router attribute overview
The reference part of this manual explains all the attributes of the 1424 SHDSL Router. One chapter
describes one group of attributes:
• chapter 11 - Configuration attributes on page 491,
• chapter 12 - Status attributes on page 817,
• chapter 13 - Performance attributes on page 1013,
• chapte r14 - Alarm attributes on page 1119.
User manual Basic configuration
5 Basic configuration
This chapter shows you how to configure the very basics of the 1424 SHDSL Router. This will allow you
to access the 1424 SHDSL Router over an IP connection with, for example, TMA. It also explains how
to configure passwords on the 1424 SHDSL Router. Furthermore, there is a section on configuration
actions, i.e. how to activate a configuration, how to load the default configuration, etc. Another section
redirects you to the explanation of the major features of the 1424 SHDSL Router. The last section briefly
explains what to check should you experience trouble when installing, configuring or operating the 1424
SHDSL Router.
• 5.1 - What is an interface? on page 52
• 5.2 - Configuring IP addresses on page 53
• 5.3 - Managing devices using SNMP on page 65
• 5.4 - Configuring the SHDSL line on page 75
• 5.5 - Enabling EOC message exchange on page 79
• 5.6 - Configuring passwords on page 87
• 5.7 - Executing configuration actions on page 89
• 5.8 - Troubleshooting the 1424 SHDSL Router on page 93
Refer to the Reference manual on page 489 for a complete overview of all the attributes of the 1424
SHDSL Router.
5.1 What is an interface?
The term interface, as it is used in this manual, can be divided into two groups:
Interface type Description
physical A physical interface is an interface to which you can physically connect a cable. So
a physical interface has a physical connector. It also has some configuration
attributes that control the behaviour of the interface.
For example:
• The control interface (CTRL). It has a female 9-pins subD connector to which
you can connect a male 9-pins subD connector for maintenance purposes. It
has configuration attributes such as ctrlPortProtocol, cms2Address, etc.
• The LAN interface (LAN). It has a female RJ45 connector to which you can con-
nect a male RJ45 connector to connect to an Ethernet network. It has configu-
ration attributes such as ip, vlan, etc.
Other examples are the station clock interface, the alarm interfaces, the xDSL line
interfaces, etc.
logical A logical interface is an interface to which you can not physically connect a cable.
So a logical interface has no physical connector. However, it is part of the physical
interface, but on a higher level. One physical interface can “contain” several logical
interfaces. A logical interface also has some configuration attributes that control
the behaviour of the interface.
For example:
• An ATM PVC on an xDSL line. The xDSL line is the physical interface (it has a
physical connector) whereas the ATM PVC is the logical interface (it is located
on a higher level, i.e. layer 2 protocol level). You can have several ATM PVCs
on one xDSL line.
• a VLAN on the LAN interface. The LAN interface is the physical interface and
the VLAN is the logical interface.
Other examples are L2TP tunnels, links in a multi-link bundle, bridge groups, etc.
5.2 Configuring IP addresses
The first thing you have to configure are the IP addresses of the 1424 SHDSL Router. First this section
lists which mechanisms there are to obtain an IP address automatically. Then it shows you, for each
interface, where you can find the IP related parameters. Finally this section explains these IP related
parameters.
• 5.2.1 - Automatically obtaining an IP address on page 54
• 5.2.2 - Where to find the IP parameters? on page 55
• 5.2.3 - Explaining the ip structure on page 56
• 5.2.4 - Configuring an IP address on the LAN interface on page 63
5.2.1 Automatically obtaining an IP address
Obtaining an IP address on the LAN interface
The 1424 SHDSL Router supports several protocols to automatically obtain an IP address on its LAN
interface. Refer to 16 - Auto installing the 1424 SHDSL Router on page 1147 for more information on
auto-install.
An IP address that is obtained using a dynamic procedure is not displayed in the configuration window,
but can be found in the status window.
Obtaining an IP address on the WAN interface
In case of …
• ATM, refer to …
- 6.2.3 - Automatically obtaining IP addresses in ATM on page 112.
- 16.3.2 - Auto-install in case of ATM on page 1157.
• Frame Relay, refer to …
- 6.6.3 - Automatically obtaining IP addresses in Frame Relay on page 152.
• PPP(oA), refer to 6.7.2 - Automatically obtaining IP addresses in PPP on page 165.
An IP address that is obtained using a dynamic procedure is not displayed in the configuration window,
but can be found in the status window.
5.2.2 Where to find the IP parameters?
The following table shows where you can find the IP parameters of the different IP interfaces:
Interface Location of the IP parameters
LAN interface • In the ip structure of the lanInterface object: ip.
Important remark
If you set the configuration attribute mode to bridging, then the settings of the
configuration attribute ip are ignored. As a result, if you want to manage the 1424
SHDSL Router via IP, you have to configure an IP address in the bridgeGroup object
instead: ip.
• In the ip structure in the pppoEClient table of the lanInterface object:: pppoEClient.
VLAN on the In the ip structure of the vlan table which is located in the lanInterface object: vlan/ip.
LAN interface
ATM PVC In the ip structure of the pvcTable which is located in the atm object: pvcTable/ip.
EFM link In the ip structure of the of the efm object
pppBundle[ ] In the ip structure of the pppBundle[ ]object
L2TP tunnel In the ip structure of the l2tpTunnels table which is located in the tunnels object:
l2tpTunnels/ip.
IPSEC L2TP In the ip structure of the ipsecL2tpTunnels table which is located in the tunnels object:
tunnel ipsecL2tpTunnels/ip.
IPSEC tunnel In the ip structure of the ipsecTunnels table which is located in the tunnels object: ipsec-
Tunnels on page 674
GRE tunnel In the ip structure of the greTunnels table which is located in the tunnels object: greTun-
nels on page 684.
IPSEC GRE tun- In the ip structure of the greTunnels table which is located in the tunnels object: ipsec-
nel GreTunnels on page 687.
bridge group In the ip structure of the bridgeGroup object: ip.
management In the ipAddress attribute of the loopback object: ipAddress.

loopback
Refer to 5.2.3 - Explaining the ip structure on page 56 for a detailed description of the ip structure.
5.2.3 Explaining the ip structure
Because the ip structure occurs in several objects, it is described here once and referenced where nec-
essary. Refer to 5.2.2 - Where to find the IP parameters? on page 55 for the location of the ip structure.
This section lists all the elements that can be present in the ip structure. However, depending on the inter-
face, it is possible that not all of these elements are present.
The ip structure contains the following elements:
Element Description
vrfRouter Use this element to assign the interface to a virtual Default:<empty>

router (VRF Router). Range: 0 … 24 characters
Do this by entering the index name of the VRF Router you want to assign the inter-
face to. To create a VRF Router, a vrfRouter[ ] object must be added and configured;
refer to:
• 7.10 - Configuring Virtual Routing and Forwarding or VRF on page 254
• 11.9.13 - Virtual Routing and Forwarding (VRF) configuration attirbutes on
page 769
address Use this element to assign an IP address to the inter- Default:0.0.0.0

face. The address should belong to the subnet the Range: up to 255.255.255.255
interface is connected to.
If you do not explicitly configure a local IP address using the address element,
then it can be learned. Refer to 5.2.1 - Automatically obtaining an IP address
on page 54.
An IP address that is obtained using a dynamic procedure is not displayed in the
configuration window, but can be found in the status window.
netMask Use this element to assign an IP subnet mask to the Default:255.255.255.0

interface. The subnet mask defines the number of IP Range: up to 255.255.255.255
devices that may be present on the corresponding IP
segment.
Element Description
sNet Use this element to add the interface to a secure net- Default:<opt>
work (SNet) so that it can be controlled by a (virtual) Range: choice, see below
firewall.
The sNet element is a choice element. The first part of the sNet element has the fol-
lowing values:
• name. Select this value if you want to add the interface to
one of the standard secure networks. In the second part
of the sNet element, use the drop-down box to select one
of the standard SNets: corp, dmz or internet.
Note that if you select the value <opt> (default), then the
interface is not added to a secure network.
• custom. Currently, you can only select standard secure net-

works. In future releases of the TDRE, it will be possible to
select custom created SNets.
dhcpClient Use this element to enable or disable the sending of Default:enabled

DHCP client requests on the interface. Range: enabled / disabled
secondaryIp Use this element to create additional virtual networks Default:<empty>

on the same Ethernet interface. Range: table, see below
The secondaryIp table contains the elements address and netMask. See above for an
explanation of these elements.
remote Use this element to assign an IP address to the Default:0.0.0.0

remote end of a connection (e.g. the remote end of an Range: up to 255.255.255.255
L2TP tunnel, a PPP link, etc.).
If you do not explicitly configure a remote IP address using the remote ele-
ment, then it can be learned. Refer to 5.2.1 - Automatically obtaining an IP
address on page 54.
An IP address that is obtained using a dynamic procedure is not displayed in the
configuration window, but can be found in the status window.
Element Description
acceptLocAddr In case of a PPP link, it is possible to learn the local IP Default:enabled

address from the remote side. Use the acceptLocAddr Range: enabled / disabled
element to determine whether to accept or reject the
learned IP address.
The acceptLocAddr element has the following values:
• enabled. If the remote side is able to give an IP address, then the local IP
address is learned from the remote side. Even if you explicitly configure a local
IP address (e.g. using the address element). In other words, if the acceptLocAddr
element is set to enabled, then the local IP address that has been configured is
overruled by the one that has been learned.
• disabled. The local IP address can not be learned from the remote side.
Also see 6.7.2 - Automatically obtaining IP addresses in PPP on page 165.
An IP address that is obtained using a dynamic procedure is not displayed

in the configuration window, but can be found in the status window.
acceptRemAddr In case of a PPP link, it is possible to learn the remote Default:enabled

IP address from the remote side. Use the acceptRem- Range: enabled / disabled
Addr element to determine whether to accept or reject
the learned IP address.
The acceptRemAddr element has the following values:
• enabled. If the remote side is able to give an IP address, then the remote IP
address is learned from the remote side. Even if you explicitly configure a
remote IP address (e.g. using the remote element). In other words, if the accep-
tRemAddr element is set to enabled, then the remote IP address that has been
configured is overruled by the one that has been learned.
• disabled. The remote IP address can not be learned from the remote side.
Also see 6.7.2 - Automatically obtaining IP addresses in PPP on page 165.
An IP address that is obtained using a dynamic procedure is not displayed

in the configuration window, but can be found in the status window.
unnumbered In case you do not explicitly configure a local IP Default:<empty>

address for a PPP(oA) link using the address element, Range: 0 … 24 characters
then you can use the unnumbered element to "borrow"
the IP address of another interface for which an IP address is already configured,
thereby conserving network and address space.
Do this by entering the interface name as unnumbered element
value.
Element Description
gatewayPreference In case you do not explicitly configure a local or Default:80

remote IP address for a PPP(oA) link using the address Range: 0 … 90
and remote element, then these addresses can be
learned from the remote side. What is more, this route is automatically installed as
default route to the remote. In that case you can use the gatewayPreference element
to set the preference of this default route. Refer to the element preference on page 620
for more information.
Note that if you set the gatewayPreference element to 0, then the route is not installed.
mtu Use this element to set the Maximum Transmission Default:1500

Unit of the interface. Range: 500 … 1650
What is MTU?
The Maximum Transmission Unit (MTU) is the largest size packet or frame, spec-
ified in octets (eight-bit bytes), that can be sent in a packet- or frame-based net-
work (e.g. the Internet). The Ethernet standard MTU is 1500.
An MTU that is too large may result in retransmissions if the packet encounters a
router that cannot handle that large a packet. An MTU that is too small results in
relatively more header overhead and more acknowledgements that have to be
sent and handled.
The Internet de facto standard MTU is 576, but ISPs often suggest using 1500. For
protocols other than TCP, different MTU sizes may apply.
IP packets with a size larger than the MTU and with the DF (Don’t Fragment)
bit set are dropped and an ICMP destination unreachable (type 3, code 4)
message is sent.
rip Use this element to configure the RIP related param- Default:-
eters of the interface. Range: structure, see below
Refer to 7.5.3 - Explaining the rip structure on page 208 for a detailed description
of the rip structure.
Element Description
trafficPolicy Use this element to apply a traffic policy on the routed Default:<empty>
data on the interface. Range: 0 … 24 characters
Do this by entering the index name of the traffic policy you want to use. You can
create the traffic policy itself by adding a trafficPolicy object and by configuring the
attributes in this object.
Example
If you created a trafficPolicy object with index name my_traffic_policy

(i.e. trafficPolicy[my_traffic_policy]) and you want to apply this traffic
policy here, then enter the index name as value for the trafficPol-
icy element.
Refer to …
• 7.11 - Applying QoS on routed traffic on page 259 for more information on pol-
icies.
• 9.2 - Configuring the access restrictions on page 370 for more information on
outbound access lists.
accessPolicy Use this element to apply an access policy on the Default:<empty>

routed data on the interface. Range: 0 … 24 characters
Whereas by using the trafficPolicy element you can apply an outbound access list on
the interface, you can apply an inbound access list on the interface by using the
accessPolicy element.
Do this by entering the index name of the traffic policy you want to use. You can
create the traffic policy itself by adding a trafficPolicy object and by configuring the
Example
If you created a trafficPolicy object with index name my_traffic_policy

(i.e. trafficPolicy[my_traffic_policy]) and you want to apply this traffic
policy here, then enter the index name as value for the trafficPol-
icy element.
Refer to 9.2 - Configuring the access restrictions on page 370 for more information
on inbound access lists.
mgmtAccess Use this element to enable or disable management Default:enabled

access through this interface. Range: enabled / disabled
If you set the mgmtAccess attribute to disabled, then you can not access the protocol
stack through this interface.
Element Description
directedBroadcasts Use this element to enable (forward) or disable (dis- Default:enabled

card) directed broadcasts. Range: enabled / disabled
What is a directed broadcast?
A directed broadcast is an IP packet destined for a complete (sub-)network. For

example, a packet destined for all devices on subnetwork 192.168.48.0 with sub-
net mask 255.255.255.0 has destination address 192.168.48.255. I.e. all ones in
the subnet area of the IP address.
icmpRedirects Use this element to enable or disable the transmission Default:enabled

of ICMP messages. Range: enabled / disabled
What is an ICMP redirect?
If icmpRedirects is enabled and if the 1424 SHDSL Router receives an IP packet on

the interface for which …
• the next hop gateway is on the same interface,
• the next hop address is in the same subnet as the source,
… then it sends an ICMP message to the originator of the packet to inform him that
a better (shorter) route exists.
igmp Use this element to configure the multicasting IGMP Default:disabled

protocol. Range: enumerated, see below
The igmp element has the following values:
• disabled. IGMP is disabled on this interface.
• proxy.
- IGMP join and leave messages are transmitted on this interface according
to the multicast member list.
- Multicast frames are always forwarded on this interface.
• router.
- IGMP join and leave messages are interpreted on this interface and the mul-
ticast member list is adapted accordingly.
- Multicast frames are forwarded on this interface if they are present in the
multicast member list.
Refer to What is IGMP? and IGMP topology on page 916 for more information on
IGMP.
Element Description
helpers Use this element to enable broadcast forwarding. Default:<empty>

Limited IP broadcasts (address 255.255.255.255) Range: table, see below
and (sub-)network broadcasts for a directly connected network are normally not
forwarded by the 1424 SHDSL Router. However, client / server applications often
use these broadcasts during start-up to discover the server on the network. If the
server is on a remote LAN, then the detection may fail.
Therefore, if you configure a helper IP address, the received broadcasts address
is replaced by this helper IP address and the packets are re-routed using the des-
tination address. Multiple helper IP addresses can be configured.
The 1424 SHDSL Router only substitutes addresses for the protocols which
are selected in the helperProtocols attribute. Refer to helperProtocols on page 626.
nat Use this element to enable Network Address Transla- Default:<empty>

tion on the interface. Range: 0 … 24 characters
Do this by entering the name of the NAT object you want to apply:
• If you want to apply the NAT settings as defined in the router/defaultNat
object, then enter the string “default“ as value for the nat element.
• If you want to apply the NAT settings as defined in a NAT object you
added yourself (e.g. router/nat[myNat]), then enter the index name of the
NAT object (in this case “myNat”) as value for the nat element.
Refer to …
• 7.8 - Configuring address translation on page 225 for more information on NAT.
• 11.9.2 - NAT configuration attributes on page 652 for a detailed description of
the NAT configuration attributes.
Important remark
If you want to enable NAT on an interface but you also want that the inter-
face is inspected by the firewall, then enable NAT in the policies of the firewall and
not in the ip structure of the interface.
vrrp Use this element to enable or disable VRRP. Refer to Default:enabled

7.9 - Configuring VRRP on page 247 for more infor- Range: enabled / disabled
mation.
5.2.4 Configuring an IP address on the LAN interface
When configuring an IP address on the LAN interface, there are two different scenarios:
• The LAN interface mode is bridging (the configuration attribute mode is set to bridging). This is the
default setting.
• The LAN interface mode is routing (the configuration attribute mode is set to routing).
LAN interface mode = bridging
In this case the settings of the configuration attribute ip are ignored. If you want to manage the 1424
SHDSL Router via IP, then you have to configure an IP address in the bridgeGroup object instead: ip.
Suppose you want to assign IP address 10.0.8.210 with subnet mask 255.255.252.0 to the LAN inter-
face, then configure the appropriate attributes as follows:
LAN interface mode = routing
In this case the settings of the configuration attribute ip are used.

Suppose you want to assign IP address 10.0.8.210 with subnet mask 255.255.252.0 to the LAN inter-
face, then configure the appropriate attributes as follows:
5.3 Managing devices using SNMP
This section defines SNMP, and gives an overview of the different versions.
• 5.3.1 - Introducting SNMP on page 66
• 5.3.2 - What are the SNMP Basic Components? on page 67
• 5.3.3 - SNMP versions on page 68
• 5.3.4 - SNMP entity on page 70
• 5.3.5 - Introducing MIB ‘s on page 73
• 5.3.6 - Explaining the SNMP message format on page 74
• 5.3.7 - Introducing attributes snmpIndex and snmpIndexOffset on page 74
5.3.1 Introducting SNMP
SNMP stands for Simple Network Management Protocol.

It is the protocol developed to manage and monitor network-attached devices (servers, workstations,
routers, switches and hubs etc.) on an IP network. It enables network administrators to manage the per-
formance of their network, find and solve network problems and so on.
It is the protocol that allows an SNMP manager to control an SNMP agent by exchanging SNMP mes-
sages. An SNMP message is a packet sent over UDP/IP to port 161.
The main purpose of SNMP is to control (set) or monitor (get) parameters on an SNMP agent.
A few features of SNMP are:
• Network devices send out traps or change notices to inform network management systems about any
problems.
• Network management systems learn of problems by receiving traps or change notices from network
devices.
• SNMP uses management information bases (MIBs), which specify the management data of a device.
• SNMP uses ASN.1 or Abstract Syntax Notation One to define the data types used to build an SNMP
message:
- All data types are encoded in the same way by following the Basic Encoding Rules or BER.
- Data types fall into two categories: primitive and complex. ASN.1 allows primitive data types to be
grouped together into complex data types.
- Several complex data types exist. One complex data type is the Sequence. This is a list of several
data fields joined together.
- ASN.1 also defines the SNMP PDU (Protocol Data Unit) data types. These are complex data
types specific to SNMP. The PDU field contains the actual body of an SNMP message.
• Currently, there are three versions of SNMP defined: SNMP v1 , SNMP v2 and SNMPv3.
Also refer to RFC 1155, RFC 1213, RFC 3411, RFC 3412 for more information on SNMP and MIB ‘s.
5.3.2 What are the SNMP Basic Components?
An SNMP-managed network consists of three key components:

• Managed devices. A managed device is a network node that contains an SNMP agent and that
resides on a managed network. Managed devices collect and store management information and
make this information available to NMSs using SNMP. Managed devices or network elements can be
routers and access servers, switches and bridges, hubs, computer hosts...
• Agents. An agent is a network-management software module that resides in a managed device. An
agent has local knowledge of management information and translates that information into a form
compatible with SNMP.
• Network-management systems (NMSs). An NMS executes applications that monitor and control
managed devices. NMSs provide the bulk of the processing and memory resources required for net-
work management. One or more NMSs must exist on any managed network.
5.3.3 SNMP versions
Currently, three versions of SNMP have been defined: SNMP v1, SNMP v2 and SNMP v3. SNMP v2
makes certain additions and enhancements to the first verion, SNMP v1. SNMP v3 adds security and
remote configuration capabilities.
In practice, SNMP implementations often support multiple versions: typically SNMPv1, SNMPv2c, and
SNMPv3. Refer to RFC 3584 Coexistence between Version 1, Version 2, and Version 3 of the Internet-
standard Network Management Framework.
SNMP v1
• SNMP v1 defines highly structured tables that are used to group the instances of a tabular object (this
is an object that contains multiple variables). The tables are composed of zero or more rows, which
are indexed in a way that allows SNMP to retrieve or alter an entire row with a single Get, GetNext,
or Set command.
• SNMPv1 is the initial implementation of the SNMP protocol. It operates over protocols such as User
Datagram Protocol (UDP), Internet Protocol (IP), OSI Connectionless Network Service (CLNS).
SNMPv1 is widely used and is the de facto network-management protocol in the Internet community.
• Version 1 has been criticized for its poor security. Authentication of clients is performed only by a
community string, in effect a type of password, which is transmitted in cleartext.
SNMP v2
• SNMP v2 makes certain additions and enhancements to SNMPv1, such as including bit strings, net-
work addresses, and counters. Bit strings are defined only in SNMPv2 and comprise zero or more
named bits that specify a value. Network addresses represent an address from a particular protocol
family. SNMPv1 supports only 32-bit IP addresses, but SNMPv2 can support other types of
addresses as well. Counters are non-negative integers that increase until they reach a maximum
value and then return to zero. In SNMPv1, a 32-bit counter size is specified. In SNMPv2, 32-bit and
64-bit counters are defined.
• Evolutions within SNMP v2 are:
- Simple Network Management Protocol version 2 (RFC 1441–RFC 1452), also known as SNMP
v2 or SNMP v2p, revises version 1 and includes improvements in the areas of performance, secu-
rity, confidentiality, and manager-to-manager communications. It introduced GETBULK, an alter-
native to iterative GETNEXTs for retrieving large amounts of management data in a single
request. However, the new party-based security system in SNMP v2 was not widely accepted.
- Community-Based Simple Network Management Protocol version 2, or SNMP v2c, is defined in
RFC 1901–RFC 1908. In its initial stages, this was also informally known as SNMP v1.5. SNMP
v2c comprises SNMP v2 without the controversial new SNMP v2 security model, using instead
the simple community-based security scheme of SNMP v1. While officially only a Draft Standard,
this is widely considered as the de facto SNMP v2 standard.
- User-Based Simple Network Management Protocol version 2, or SNMP v2u, is defined in RFC
1909–RFC 1910. This is a compromise that attempts to offer greater security than SNMP v1, but
without the high complexity of SNMP v2. A variant of this was commercialized as SNMP v2*, and
the mechanism was eventually adopted as one of two security frameworks in SNMP v3.
SNMP v3
• SNMP v3 is an advanced version of SNMP v2 that provides additional administrative structure,

authentication, privacy and access control, and makes use of authentication, encryption and user
authentication.
• SNMPv3 provides a secured environment during data transmission in the network. There can be pos-
sibilities where SNMP messages are easily intercepted and decoded by unauthorized personnel. To
avoid this, SNMPv3 provides secured communication of data in the network.
5.3.4 SNMP entity
Each SNMP entity, or SNMP device, consists of an SNMP engine and one or more associated applica-
tions. The following figure shows the components of an SNMP entity.
SNMP engine
An SNMP engine provides services for sending and receiving messages, authenticating and encrypting
messages, and controlling access to managed objects. There is a one-to-one association between an
SNMP engine and the SNMP entity which contains it.
The engine contains:
• a Dispatcher
• a Message Processing Subsystem
• a Security Subsystem
• an Access Control Subsystem
snmpEngineId
Within an administrative domain, an snmpEngineId is the unique and unambiguous identifier of an

SNMP engine (i.e. a device like the 1424 SHDSL Router). Since there is a one-to- one association
between SNMP engines and SNMP entities, it also uniquely and unambiguously identifies the SNMP
entity within that administrative domain.
Note that it is possible for SNMP entities in different administrative domains to have the same value for
snmpEngineId.
Dispatcher
There is only one dispatcher in an SNMP engine. It allows for concurrent support of multiple versions of
SNMP messages in the SNMP engine. It does so by:
• sending and receiving SNMP messages to and from the network.
• determining the version of an SNMP message and interacting with the corresponding Message
Processing Model.
• providing an abstract interface to SNMP applications for delivery of a PDU to an application.
• providing an abstract interface for SNMP applications that allows them to send a PDU to a remote
SNMP entity.
Message Processing Subsystem
The Message Processing Subsystem is responsible for preparing messages for sending, and extracting
data from received messages. It might contain multiple Message Processing Models.
Each Message Processing Model defines the format of a particular version of an SNMP message and
coordinates the preparation and extraction of each such version-specific message format.
Security Subsystem
The Security Subsystem provides security services such as the authentication and privacy of messages
and potentially contains multiple Security Models. It might contain multiple Security Models.
A Security Model specifies the threats against which it protects, the goals of its services, and the security
protocols used to provide security services such as authentication and privacy.
A Security Protocol specifies the mechanisms, procedures, and MIB objects used to provide a security
service such as authentication or privacy.
Access Control Subsystem
The Access Control Subsystem provides authorization services by means of one or more Access Control
Models.
An Access Control Model defines a particular access decision function in order to support decisions
regarding access rights.
Applications
There are several types of applications:

• command generators, which monitor and manipulate management data,
• command responders, which provide access to management data,
• notification originators, which initiate asynchronous messages,
• notification receivers, which process asynchronous messages,
• proxy forwarders, which forward messages between entities.
These applications make use of the services provided by the SNMP engine.
5.3.5 Introducing MIB ‘s
Every SNMP agent has an address book of all its objects, called the MIB or Management Information
Base. A MIB is a collection of information that is organized hierarchically. MIBs are comprised of man-
aged objects, and are identified by object identifiers:
• A managed object (sometimes called a MIB object, an object, or a MIB) is one of any number of spe-
cific characteristics of a managed device.
• An object identifier (or object ID or OID) uniquely identifies a managed object in the MIB hierarchy.
In an SNMP agent, parameters are arranged in a tree. SNMP uses OID ‘s to specify the exact param-
eter to set or get in the tree.
The MIB provides the name, OID, data type, read/write permissions, and a brief description for each
object in an SNMP agent.
• The release of SNMPv2 involves SNMP private MIB files that are different from the ones before
TDRE 12.0. Both versions however may co-exist in a network.
• The private MIB files come with your copy of TMA. After installation of the TMA data files, the private
MIB files are available in directory C:\Program Files\TMA\snmp1.
The “old” MIB files, from before the SNMPv2 era, can be recognised by the following format:
<filename>.mib.
The “new” MIB files can be recognised by the following format: <filename>_smiv2.mib
1. The first part of the directory path may be different if you did not choose the default path during
the installation of the TMA data files.
5.3.6 Explaining the SNMP message format
The SNMP message format specifies which fields are included in the message and in which order. The
entire SNMP message is a Sequence of three smaller fields:
• the SNMP version. This field indicates the version of the SNMP message.
• the SNMP community string. This is used as a password in the SNMP communication.
• the SNMP PDU. The PDU is a complex data type made up of several smaller fields and contains the
actual body of an SNMP message.
5.3.7 Introducing attributes snmpIndex and snmpIndexOffset
With regards to SNMPv2 and SNMPv3, there are 2 new attributes in TMA that need explaining here:
snmpIndex and snmpIndexOffset:
• snmpIndex. This is a unique number, assigned to each individual object in the containment tree.
• snmpIndexOffset. With this attribute, the snmpIndex can be corrected in order to let it keep the same value
as before, after a manually added object has been removed from the containment tree. Refer to the
following example:
Within the router subtree, when Filter2 is removed, Filter3 would normally get snmpIndex 1062.
With snmpIndexOffset set to 1 for Filter3 however, the snmpIndex of Filter3 remains 1063.
5.4 Configuring the SHDSL line
When you want to establish a line connection successfully, you have to configure some line attributes.
This section shows you which line attributes are essential. It also gives more information on how to select
a line speed (range). Then it explains the concept power back-off. Finally it explains how to configure the
Embedded Operations Channel (EOC) handling.
• 5.4.1 - Essential SHDSL line configuration attributes on page 76
• 5.4.2 - Selecting an SHDSL line speed (range) on page 77
• 5.4.3 - Power back-off on page 78
• 5.4.4 - Compatibility with other SHDSL devices on page 78
Important remarks
The following must be taken into account when configuring the SHDSL line:
• When using ATM as encapsulation on the SHDSL line, the following line pair speeds are supported:
- Single pair: all speeds are supported.
- Dual pair: all speeds are supported.
- Three pair: up to 5312Mbits/s per line pair is supported.
- Four pair: up to 3840Mbits/s per line pair supported.
This basically means that, in all cases, a maximum total line speed of up to 16 Mbit/s is supported
when using ATM.
Refer to 6.2 - Configuring ATM encapsulation on page 97 for more information about ATM.
• When using EFM as encapsulation on the SHDSL line, linePair1 must be configured on the central
device. As long as this is not the case, the EFM datapath can never be up.
Refer to 6.5 - Configuring EFM encapsulation on page 141 for more information about EFM.
5.4.1 Essential SHDSL line configuration attributes
To establish a line connection successfully, it is essential to set the following configuration attributes cor-
rect:
Attribute Purpose of the attribute
channel on page 580 For synchronisation purposes, one unit has to be

defined as central and its remote counterpart as
remote.
region on page 581 For correct operation, select the correct SHDSL
standard. Normally, the auto setting should suffice.
minLinePairSpeed Use this attribute to set the lowest linepair speed

the 1424 SHDSL Router may select.
maxLinePairSpeed Use this attribute to set the highest line speed the
1424 SHDSL Router may select.
modulation Use this attribute to set the modulation that will be

used on the line.
Refer to 11.6 - SHDSL line configuration attributes on page 578 for a complete overview of the line con-
figuration attributes.
5.4.2 Selecting an SHDSL line speed (range)
Selecting a speed range
The 1424 SHDSL Router features auto speed negotiation according to ITU-T G.994.1. During this nego-
tiation the 1424 SHDSL Router selects a speed within the range from the minimum speed up to the max-
imum speed as set with the minLinePairSpeed and maxLinePairSpeed attributes.
Important remark
In case of a 1424 SHDSL Router 2 or 4 pair version, define a speed range either on the central or on the
remote 1424 SHDSL Router, but not on both. Else the line pairs could train at a different speed which is
not allowed.
Selecting a fixed speed
If you set the minLinePairSpeed and maxLinePairSpeed attribute to the same value, then the 1424 SHDSL
Router operates at a fixed speed.
Fall-back speed
When you define a speed range, the 1424 SHDSL Router will always try to operate at the maximum
speed. If the remote does not allow that speed or the signal quality deteriorates, then the 1424 SHDSL
Router tries to select the second speed down the range. If also this speed fails, the 1424 SHDSL Router
again lowers its speed. It does this until it reaches the minimum speed.
Modulation
The selected modulation has an influence on the available speed range:

• When using tc-pam16, the line rate is limited from 192kbps to 3840kbps. Use this when the remote
device is a G.SHDSL device.
• When using tc-pam32, the line rate is limited from 768kbps to 5696kbps. Use this when the remote
device is a G.SHDSL.bis device.
5.4.3 Power back-off
The 1424 SHDSL Router features power back-off. Power back-off is a part of the ITU-T G.991.2 SHDSL
recommendation. It reduces the maximum transmit power level if the line conditions are sufficiently good
to operate at a lower transmit level.
Power back-off is performed by default (no configuration attribute). During the ITU-T G.994.1 hand-
shake, the two sides of the line mutually agree on the transmit level. The transmit level is lowered
between 0 and 6 dB in steps of 1dB.
5.4.4 Compatibility with other SHDSL devices
The 1424 SHDSL Router can be used in combination with other (OneAccess) SHDSL devices. The doc-
ument “Interoperability for OneAccess SHDSL products” (PDF) gives an overview of the interoperability.
5.5 Enabling EOC message exchange
This section introduces EOC message exchange and shows you how to enable this feature.
• 5.5.1 - Standard versus proprietary EOC message exchange on page 80
• 5.5.2 - Controlling the proprietary EOC message exchange on page 80
• 5.5.3 - Controlling the standard EOC message exchange on page 81
• 5.5.4 - Which standard EOC information is retrieved? on page 83
5.5.1 Standard versus proprietary EOC message exchange
On the OneAccess SHDSL devices you can distinguish two types of EOC message exchange:
• standard EOC message exchange. These are the messages as defined in the SHDSL standard
G.991.2. They are sent through the Embedded Operations Channel (EOC).
• proprietary EOC message exchange. This is the proprietary O10 management protocol. This is also
sent through the Embedded Operations Channel (EOC).
5.5.2 Controlling the proprietary EOC message exchange
The proprietary EOC message exchange can be controlled by the configuration attribute management on
page 589. The management attribute has the following values:
Value Description
transparent No management data is forwarded over the SHDSL line. The data is passed trans-
parently over the line.
o10Management This forwards the proprietary OneAccess O10 protocol over the SHDSL line. This
allows you to manage the remote SHDSL device (and possibly other OneAccess
devices connected to the SHDSL device).
pathManagement This forwards path management information over the SHDSL line. This allows you
to manage complete paths instead of managing individual devices (i.e. elements).
For more information on path management, refer to the TMA Path Management
manual (PDF).
o10-PathManage- This forwards both the proprietary OneAccess O10 protocol as the path manage-
ment ment information over the SHDSL line.
5.5.3 Controlling the standard EOC message exchange
The standard EOC message exchange can be controlled by the configuration attribute eocHandling on
page 589. The eocHandling attribute has the following values:
Value Description
passive The 1424 SHDSL Router does not send any standard EOC messages. However,
the 1424 SHDSL Router does respond on standard EOC messages it receives.
Also, after getting into data state, no proprietary EOC messages will be sent for the
first 2 minutes, unless the 1424 SHDSL Router received a OneAccess specific
frame from the other side (e.g. O10 data, or a test or configuration frame).
This is the preferred value when connecting the 1424 SHDSL Router to the
2300 Series.
none Except for discovery probes, the 1424 SHDSL Router does not send standard
EOC messages. However, the 1424 SHDSL Router does respond on standard
EOC messages it receives.
discovery The 1424 SHDSL Router “scans” the SHDSL line. For every device it discovers, it
adds an object to the containment tree. Refer to Discovering devices on the
inventory
SHDSL line.
info
Then the 1424 SHDSL Router retrieves information from these devices and dis-
plays it in the corresponding objects. Exactly which information is retrieved
depends on the setting of the eocHandling attribute. Refer to 5.5.4 - Which standard
EOC information is retrieved? on page 83.
alarmConfiguration Also in this case the 1424 SHDSL Router “scans” the SHDSL line, adds the objects
to the containment tree and retrieves information from the devices. Refer to Dis-
covering devices on the SHDSL line and 5.5.4 - Which standard EOC information
is retrieved? on page 83.
Additionally, the central1 SHDSL device forces the remote2 SHDSL device to use
the link alarm thresholds lineAttenuationOn and signalNoiseOn as configured on the
central device. In other words, the settings of the lineAttenuationOn and signalNoiseOn
on the central device overrule those of the remote device.
1. The central device is the device on which the channel attribute is set to central.
2. The remote device is the device on which the channel attribute is set to remote.
Discovering devices on the SHDSL line
When you change the eocHandling attribute from none or passive to any other value, the 1424 SHDSL
Router starts “scanning” the SHDSL line in order to determine which devices are present between itself
and its remote counterpart.
So in this case, when the scan is finished, an end object is added to the containment
tree1 on the same level as the line object. This end object represents the remote
counterpart.
1. It can take up to 5 minutes before the new objects appear in the containment tree.
5.5.4 Which standard EOC information is retrieved?
As said in 5.5.3 - Controlling the standard EOC message exchange on page 81, exactly which standard
EOC information is retrieved from the remote SHDSL device(s) depends on the setting of the eocHandling
attribute.
This section gives an overview in which case which information is retrieved:
• Standard EOC status information on page 84
• Standard EOC performance information on page 85
• Standard EOC alarm information on page 86
Standard EOC status information Does the attribute or element display relevant information in case eocHandling is set to … ?
Object Attribute none discovery inventory info alarmConfiguration

router1424/… (Element)
User manual
line eocAlarmThresholds No. The value is • On the central1: yes. The values are those as set in the linkA- Yes. The values are
(lineAttenuation, signal- always 0.0. larmThresholds attribute. those as set in the linkA-
84 1424 SHDSL Router
Noise) • On the remote2: no. The value is always 0.0. larmThresholds attribute
on the central device.3
numDiscoveredRepeaters Yes.
repeater[ ] vendorId No repeater[ ] or Yes.

or (countryCode, provider- end object is cre-
Code, vendorSpecific) ated.
end
vendorModel No. Yes.
vendorSerial No. Yes.
vendorSoftVersion No. Yes.
eocSoftVersion Yes.
shdslVersion Yes.
eocState Yes.
eocAlarmThresholds No. The value is always 0.0. Yes. The values are Yes. The values are
(lineAttenuation, signal- those as set in the linkA- those as set in the linkA-
Noise) larmThresholds attribute larmThresholds attribute
on the remote device. on the central device.
repeater[ ]/linePair[ ] lineAttenuation No repeater[ ] or No. The value is always 0.0. Yes. The values are the actual line attenuation
or end object is cre- and signal noise as measured on the remote
signalNoise
ated. device.
end/linePair[ ]
Basic configuration
Chapter 5
3. Refer to 5.5.3 - Controlling the standard EOC message exchange on page 81 for more information on the alarmConfiguration value.
Standard EOC performance information Does the attribute or element display relevant information in case eocHandling is set to … ?

router1424/…
User manual
repeater[ ]/linePair[ ] lineParameters No repeater[ ] or No. The value is always 0.0. Yes. The values are the same as those on the
or end object is cre- remote device.
performance
1424 SHDSL Router
ated. Note that in this case the sysUpTime is not the

end/linePair[ ] h2LineParameters
elapsed time since the last cold boot, but the
h2Performance elapsed time since the creation of the repeater[ ] or
h24LineParameters end object.
h24Performance
d7LineParameters
d7Performance
Basic configuration
Chapter 5 85
Standard EOC alarm information Does the attribute or element display relevant information in case eocHandling is set to … ?

router1424/…
User manual
line/linePair[ ] lineAttenuation The thresholds as configured in the linkAlarmThresholds attribute on the local device The thresholds as con-
are used to generate the alarms. figured in the linkAlarm-
signalNoise
Thresholds attribute on
the central1 device are
used to generate the
alarms2.
repeater[ ]/linePair[ ] lineAttenuation No repeater[ ] or No alarms are generated. The thresholds as con- The thresholds as con-
or end object is cre- figured in the linkAlarm- figured in the linkAlarm-
signalNoise
ated. Thresholds attribute on Thresholds attribute on
end/linePair[ ]
the local device are the central device are
used to generate the used to generate the
alarms. alarms.
errSecRatioExceeded The thresholds as con-

figured in the linkAlarm-
sevErrSecRatioExceeded
Thresholds attribute on
the local device are
used to generate the
alarms.
2. Refer to 5.5.3 - Controlling the standard EOC message exchange on page 81 for more information on the alarmConfiguration value.
Basic configuration
Chapter 5
5.6 Configuring passwords
This section shows you how to create a (list of) password(s) with associated access level in the security
table. It also explains how to correct the security table in case of error or in case you forgot your pass-
word. Furthermore, this section shows you how to enter the passwords in the different maintenance
tools.
• 5.6.1 - Creating passwords in the security table on page 88
• 5.6.2 - Entering passwords in the different management tools on page 88
5.6.1 Creating passwords in the security table
In order to avoid unauthorised access to the 1424 SHDSL Router and the network you can create a list
of passwords with associated access levels in the security table. Do this using the security attribute. Refer
to security on page 505.
5.6.2 Entering passwords in the different management tools
Now that you created a (list of) password(s) in the 1424 SHDSL Router, you have to enter these pass-
words every time you want to access the 1424 SHDSL Router with one of the maintenance or manage-
ment tools.
The following table explains how to enter passwords in the different maintenance or management tools:
Maintenance or man- How to enter the password?

agement tool
TMA Enter the password in the Connect… window.
TMA CLI, TMA for HP Use the application TmaUserConf.exe to create a TMA user and assign a
OpenView and TMA password to this user. The password should correspond with a password
Element Management configured in the device.
Refer to the manual of TMA CLI manual (PDF), TMA for HP OpenView man-
ual (PDF) or TMA Element Management manual (PDF/CHM) for more infor-
mation.
CLI You are prompted to enter the password when the session starts.
ATWIN You are prompted to enter the password when the CLI session starts. Then
you can start an ATWIN session.
Web Interface You are prompted to enter the password when the session starts.
SNMP Define the password as community string. If no passwords are defined, then
you can use any string as community string.
TML Enter the password after the destination filename. Separate password and
filename by a ‘?’.
Example: tml –fsourcefile@destinationfile?pwd
(T)FTP Enter the password after the destination filename. Separate password and
filename by a ‘?’.
Example: put sourcefile destinationfile?pwd
5.7 Executing configuration actions
This section shows you how to execute actions on the configuration. The following gives an overview of
this section:
• 5.7.1 - What are the different configuration types? on page 90
• 5.7.2 - Activating the configuration on page 91
• 5.7.3 - Loading the default configuration on page 91
• 5.7.4 - Loading the preconfiguration on page 92
5.7.1 What are the different configuration types?
This section explains the different configuration types that are present in the 1424 SHDSL Router.
Which are the configuration types?
Three types of configuration are present in the 1424 SHDSL Router:

• the non-active configuration
• the active configuration
• the default configuration.
• the preconfiguration.
Explaining the configuration types
When you configure the 1424 SHDSL Router, the following happens:
Phase Action Result
1 Connect the computer running the mainte- The non-active configuration is displayed
nance tool to the 1424 SHDSL Router. on the screen.
2 Modify the non-active configuration. The modifications have no immediate influ-

ence on the active configuration currently
used by the 1424 SHDSL Router.
3 Complete the modifications on the non- The non-active configuration has to be acti-
active configuration. vated.
4 In case of … The non-active configuration becomes the

active configuration.
• TMA, click on the TMA button Send all
attributes to device: .
• any other maintenance tool than the

graphical user interface based TMA
(e.g. ATWIN, CLI, Web Interface, Easy-
Connect terminal, TMA CLI), then exe-
cute the Activate Configuration action.
Which are the configuration actions?
You can execute the following actions on the configuration:

• Activate Configuration on page 507
• Load Default Configuration on page 507
• Load Preconfiguration on page 507
• Load Saved Configuration on page 508
5.7.2 Activating the configuration
As explained in section 5.7.1 - What are the different configuration types? on page 90, when you finished
configuring the 1424 SHDSL Router you have to activate the configuration changes you made.
In case of …
• TMA, click on the TMA button Send all attributes to device: .
• any other maintenance tool than the graphical user interface based TMA (e.g. ATWIN, CLI, Web
Interface, EasyConnect terminal, TMA CLI), then execute the Activate Configuration action.
5.7.3 Loading the default configuration
If you install the 1424 SHDSL Router for the first time, all configuration attributes have their default val-
ues (except if a preconfiguration is present, refer to 5.7.4 - Loading the preconfiguration on page 92). If
the 1424 SHDSL Router has already been configured but you want to start from scratch, then you can
revert to the default configuration.
You can load the default configuration using the Load Default Configuration …
• action. Refer to Load Default Configuration on page 507.
5.7.4 Loading the preconfiguration
In some cases, the 1424 SHDSL Router is preconfigured when it leaves the factory. In that case a file
named “precfg.cms” is present on the file system1. This means that not all attributes have their default
values, but some will have a preconfigured value. Now, if the 1424 SHDSL Router has already been con-
figured a couple of times, then you have the possibility to revert to the preconfiguration.
You can load the preconfiguration using the Load Preconfiguration action. Refer to Load Preconfiguration on
page 507.
Note that if no preconfiguration is present (i.e. the precfg.cms file is not present on the file system), then
this action does nothing.
1. If this file is not present, then no preconfiguration is present. If you want, you could create your
own preconfiguration by placing a custom made “precfg.cms” configuration file on the file sys-
tem.
5.8 Troubleshooting the 1424 SHDSL Router
If you experience trouble when installing, configuring or operating the 1424 SHDSL Router, then check
the following:
Check Description
power Is the 1424 SHDSL Router powered properly?
connections Are all the necessary cables connected to the 1424 SHDSL Router? Are they con-
nected to the correct connectors of the 1424 SHDSL Router? Are they connected
properly? Did you use the correct cables (straight, crossed, …)?
Refer to 2.6 - Connecting the 1424 SHDSL Router on page 18.
other devices Are the devices that are connected to the 1424 SHDSL Router working properly
(are they powered, are they operational, …)?
LEDs What indicate the LEDs of the 1424 SHDSL Router? Do they indicate a fault con-
dition?
Refer to 2.7 - The front panel LED indicators on page 22.
messages What messages are displayed in the messages table? This table displays informa-
tive and error messages.
Refer to router1424/messages on page 829.
status What indicate the status attributes of the 1424 SHDSL Router? What is the status
of the different interfaces (up, down, testing, …)?
Refer to 12 - Status attributes on page 817.
performance What indicate the performance attributes of the 1424 SHDSL Router? What is the
performance of the different interfaces (does the data pass the interface, is the
interface up or down, when did it go up or down, …)?
Refer to 13 - Performance attributes on page 1013.
alarms What indicate the alarm attributes of the 1424 SHDSL Router? What is the alarm
status of the different interfaces (link down, errors, …)?
Refer to 14 - Alarm attributes on page 1119.
User manual Configuring the WAN encapsulation protocols
6 Configuring the WAN encapsulation protocols

This chapter introduces the encapsulation protocols that can be used on the 1424 SHDSL Router and
lists the attributes you can use to configure the encapsulation protocols.
Depending on the device, some protocols may or may not be present. Refer to the detailed features
overview.

• 6.1 - Selecting an encapsulation protocol on page 96
• 6.2 - Configuring ATM encapsulation on page 97
• 6.3 - Configuring OAM on ATM interfaces on page 125
• 6.4 - Configuring ATM IMA on page 138
• 6.5 - Configuring EFM encapsulation on page 141
• 6.6 - Configuring Frame Relay encapsulation on page 145
• 6.7 - Configuring PPP encapsulation on page 160
Refer to the Reference manual on page 489 for a complete overview of the attributes of the 1424 SHDSL
Router.
6.1 Selecting an encapsulation protocol
Selecting an encapsulation protocol on the SHDSL line
On the SHDSL line, you can choose between several encapsulation protocols. So first select the encap-
sulation protocol you want to use. Do this using the encapsulation attribute. Refer to encapsulation on page 531.
Once you selected an encapsulation protocol you can configure it as described in this chapter.
6.2 Configuring ATM encapsulation
This section introduces the ATM encapsulation protocol and gives a short description of the attributes
you can use to configure this encapsulation protocol.
• 6.2.1 - Introducing ATM on page 98
• 6.2.2 - Configuring ATM PVCs on page 110
• 6.2.3 - Automatically obtaining IP addresses in ATM on page 112
• 6.2.4 - Configuring IP addresses in ATM on page 113
• 6.2.5 - Configuring the VPI and VCI on page 114
• 6.2.6 - Configuring UBR on page 115
• 6.2.7 - Configuring VBR-nrt on page 116
• 6.2.8 - Configuring VBR-rt on page 117
• 6.2.9 - Configuring CBR on page 118
• 6.2.10 - ATM PVC bandwidth assignment on page 119
• 6.2.11 - Configuring bridged/routed Ethernet/IP over ATM (RFC 2684) on page 121
• 6.2.12 - Configuring Classical IP (IPoA) on page 122
• 6.2.13 - Configuring PPP over ATM (PPPoA) on page 123
• 6.2.14 - Configuring PPP over Ethernet (PPPoE) on page 124
6.2.1 Introducing ATM
What is ATM?
ATM is a cell-switching and multiplexing technology that combines the benefits of circuit switching (guar-
anteed capacity and constant transmission delay) with those of packet switching (flexibility and efficiency
for intermittent traffic). It provides scalable bandwidth. Because of its asynchronous nature, ATM is more
efficient than synchronous technologies, such as time-division multiplexing (TDM).
With TDM, each user is assigned a time slot, and no other station can send in that time slot. If a station
has much data to send, it can send only when its time slot comes up, even if all other time slots are
empty. However, if a station has nothing to transmit when its time slot comes up, the time slot is sent
empty and is wasted. Because ATM is asynchronous, time slots are available on demand with informa-
tion identifying the source of the transmission contained in the header of each ATM cell.
ATM makes use of 53 byte cells; each cells contains:
• a 5 byte header.
• 48 bytes of payload.
What is VPI and VCI?
ATM networks are fundamentally connection-oriented, which means that a virtual channel must be set
up across the ATM network prior to any data transfer. (A virtual channel is roughly equivalent to a Per-
manent Virtual Circuit or PVC.)
Two types of ATM connections exist:
• virtual paths, which are identified by Virtual Path Identifiers (VPIs).
• virtual channels, which are identified by the combination of a VPI and a Virtual Channel Identifier
(VCI).
A virtual path is a bundle of virtual channels, all of which are switched transparently across the ATM net-
work based on the common VPI. All VPIs and VCIs, however, have only local significance across a par-
ticular link and are remapped, as appropriate, at each switch.
A transmission path is the physical media that transports virtual channels and virtual paths. The following
figure illustrates how VCs concatenate to create VPs, which, in turn, traverse the media or transmission
path.
What are the ATM layers?
The ATM reference model is composed of the following ATM layers:
Layer Description
physical layer Analogous to the physical layer of the OSI reference model, the ATM physical
layer manages the medium-dependent transmission.
ATM layer Combined with the ATM adaptation layer, the ATM layer is roughly analogous to
the data link layer of the OSI reference model. The ATM layer is responsible for
the simultaneous sharing of virtual circuits over a physical link (cell multiplexing)
and passing cells through the ATM network (cell relay). To do this, it uses the VPI
and VCI information in the header of each ATM cell.
ATM Adaptation Combined with the ATM layer, the AAL is roughly analogous to the data link layer
Layer (AAL) of the OSI model. The AAL is responsible for isolating higher-layer protocols from
the details of the ATM processes. The adaptation layer prepares user data for con-
version into cells and segments the data into 48-byte cell payloads.
At present, the four types of AAL recommended by the ITU-T are AAL1, AAL2,
AAL3/4, and AAL5:
• AAL1 is used for connection-oriented, delay-sensitive services requiring con-
stant bit rates, such as uncompressed video and other isochronous traffic.
• AAL2 is used for connection-oriented services that support a variable bit rate,
such as some isochronous video and voice traffic.
• AAL3/4 (merged from two initially distinct adaptation layers) supports both con-
nectionless and connection-oriented links but is used primarily for the transmis-
sion of SMDS packets over ATM networks.
• AAL5 supports connection-oriented VBR services and is used predominantly
for the transfer of classical IP over ATM and LANE traffic. AAL5 uses SEAL and
is the least complex of the current AAL recommendations. It offers low band-
width overhead and simpler processing requirements in exchange for reduced
bandwidth capacity and error-recovery capability.
higher layers Finally, the higher layers residing above the AAL accept user data, arrange it into
packets, and hand it to the AAL.
What are ATM service categories?
The Traffic Management Specification Version 4.0 defines five ATM service categories that describe the
traffic transmitted by users onto a network and the Quality of Service (QoS) that a network needs to pro-
vide for that traffic. The five service categories are:
• Constant Bit Rate (CBR)
• Variable Bit Rate real-time (VBR-rt)
• Variable Bit Rate non-real-time (VBR-nrt)
• Available Bit Rate (ABR)
• Unspecified Bit Rate (UBR)
The 1424 SHDSL Router supports CBR, VBR-rt, VBR-nrt and UBR.
Which are the ATM service category traffic parameters?
The traffic parameters with which you can configure the ATM service categories are:
Traffic parame- Description

ter
PCR The Peak Cell Rate (PCR) is the maximum rate at which you expect to transmit
data. Obviously, the maximum possible PCR is the physical speed of the cus-
tomer's access circuit into the ATM service provider.
Also refer to the peakCellRate element in the pvcTable; refer to the ATM configuration
attributes.
SCR The Sustainable Cell Rate (SCR) is the sustained rate at which you expect to
transmit data. Consider the SCR to be the true bandwidth of a PVC and not the
long-term average traffic rate.
Also refer to the sustCellRate element in the pvcTable; refer to the ATM configuration
attributes.
MBS The Maximum Burst Size (MBS) is the maximum number of cells that are allowed
to be sent above the SCR, with an upper limit which is PCR.
This is furhter explained in the next paragraph; also refer to the maxBurstSize ele-
ment in the pvcTable; refer to the ATM configuration attributes.
Maximum Burst Size
• Definition
The Maximum Burst Size (MBS) is the maximum number of cells that are allowed to be sent above the
SCR, with an upper limit to the load of those cells, which is PCR.
In other words: MBS sets the limit for the number of cells that are allowed to be sent above the SCR;
PCR puts a maximum on the load of those cells.
The following figure illustrates the relation between MBS, SCR and PCR:
MBS will accommodate temporary bursts or short spikes in the traffic pattern. For example, an MBS of
100 cells allows a burst of three MTU-size Ethernet frames.
• Cell times
MBS is a number of cells, and is expressed in cell times.
Since each ATM cell has a certain length of time, this number of cells corresponds to a number of cell
time slots.
So, cell times is a unit expressed as a number of cells, which represent the amount of time that it takes
the ATM cells to pass an interface.
It can be converted into seconds using the following formula:
With:
- MBS: Maximum Burst Size; this is the total number of cells with a load higher than SCR.
- (424 bits per cell): ATM uses cells of 53 bytes, so that results in 424 bits per cell.
- PCR: Peak Cell Rate; this is the maximum data rate.
- SCR: Sustainable Cell Rate; this is the sustained data rate.
What is UBR?
The Unspecified Bit Rate (UBR) service category is a "best effort" service intended for non-critical appli-
cations, which do not require tightly constrained delay and delay variation, nor a specified quality of serv-
ice. UBR sources are expected to transmit non-continuous bursts of cells. UBR service supports a high
degree of statistical multiplexing among sources.
UBR service does not specify traffic related service guarantees. Specifically, UBR does not include the
notion of a per-connection negotiated bandwidth. There may not be any numerical commitments made
as to the cell loss ratio experienced by a UBR connection, or as to the cell transfer delay experienced by
cells on the connection: available bandwidth depends on other traffic on the connection.
The only traffic parameter you have to configure in case of UBR is the PCR. The PCR only provides an
indication of a physical bandwidth limitation within a PVC.
Examples of applications which can be seen as appropriate targets for the UBR service category are:
data transfer, messaging, etc.
The following figure shows the PCR, SCR and MBS relationship:
What is VBR-nrt?
The non-real time VBR service category is intended for applications which have bursty traffic character-
istics and do not have tight constraints as to delay and delay variation. For those cells which are trans-
ferred within the traffic contract, the application expects a low Cell Loss Ratio (CLR). For all cells, it
expects a bound on the Cell Transfer Delay (CTD). Non-real time VBR service may support statistical
multiplexing of connections.
The traffic parameters you have to configure in case of VBR-nrt are:
• the Sustainable Cell Rate (SCR)
• the Peak Cell Rate (PCR)
• the Maximum Burst Size (MBS)
Examples of applications which can be seen as appropriate targets for the VBR-nrt service category are:
response-time critical transaction processing applications (e.g. airline reservations, banking transac-
tions, process monitoring), etc.
What is VBR-rt?
The real-time VBR service category is intended for time-sensitive applications, (i.e., those requiring
tightly constrained delay and delay variation), as would be appropriate for voice and video applications.
Sources are expected to transmit at a rate which varies with time. Equivalently, the source can be
described as "bursty".
Cells which are delayed beyond the value specified by CTD are assumed to be of significantly less value
to the application. Real-time VBR service may support statistical multiplexing of real-time sources.
The traffic parameters you have to configure in case of VBR-rt are:
• the Sustainable Cell Rate (SCR)
• the Peak Cell Rate (PCR)
• the Maximum Burst Size (MBS)
Examples of applications which can be seen as appropriate targets for the VBR-rt service category are:
some classes of multimedia communications (e.g. compressed audio, interactive multimedia), etc.
What is CBR?
The CBR service category is used by connections that request a fixed (static) amount of bandwidth,
characterized by a Peak Cell Rate (PCR) value that is continuously available during the connection life-
time, independent from other traffic on the network. The source may emit cells at or below the PCR at
any time, and for any duration (or may be silent).
This category is intended for real-time applications, i.e., those requiring tightly constrained Cell Transfer
Delay (CTD) and Cell Delay Variation (CDV), but is not restricted to these applications. It would be
appropriate for voice and video applications, as well as for Circuit Emulation Services (CES).
The basic commitment made by the network is that once the connection is established, the negotiated
QoS is assured to all cells conforming to the relevant conformance tests. It is assumed that cells which
are delayed beyond the value specified by Cell Transfer Delay (CTD) may be of significantly less value
to the application.
The only traffic parameter you have to configure in case of CBR is the PCR.
Examples of applications which can be seen as appropriate targets for the CBR service category are:
video conferencing, interactive audio (e.g., telephony), audio/video distribution (e.g. television, distance
learning), audio/video retrieval (e.g. video-on-demand, audio library)
What is multi-protocol over ATM (MPoA)?
As its name implies, multi-protocol encapsulation over ATM provides mechanisms for carrying traffic
other than just IP. Several different protocols can be used on top of ATM:
• Bridged/routed Ethernet/IP over ATM (formerly RFC 1483, now RFC 2684). This protocol makes the
router appear as a LAN device to the operating system.
• IP over ATM (IPoA, RFC 1577, similar to RFC 2684). Also in this case the protocol makes the router
appear as a LAN device to the operating system.
• Point to Point Protocol Over ATM ( PPPoA, RFC 2364). PPP provides session setup, user authenti-
cation (login), and encapsulation for upper layer protocols such as IP. The use of PPP makes the
router appear as a dial device to the operating system.
• Point to Point Protocol Over Ethernet (PPPoE, RFC 2516). This protocol makes the router appear as
a LAN device to the operating system. It allows multiple devices on an Ethernet to share a common
connection to the remote network (e.g. the Internet).
Which are the multi-protocol over ATM encapsulation mechanisms?
As said before, you can encapsulate several protocols in ATM. The mechanisms to do this are:
MPoA encapsulation Description

mechanism
Logical Link Control In this method, multiple protocol types can be carried across a single con-
(LLC) encapsulation nection with the type of encapsulated packet identified by a standard LLC/
SNAP header.
Virtual Connection Mul- In this method, only a single protocol is carried across an ATM connection,
tiplexing with the type of protocol implicitly identified at connection setup.
LLC encapsulation is provided to support routed and bridged protocols. In this encapsulation format,
PDUs from multiple protocols can be carried over the same virtual connection. The type of protocol is
indicated in the packet's SNAP header. By contrast, the virtual connection multiplexing method allows
for transport of just one protocol per virtual connection.
The following table gives an overview of which multi-protocol mechanism can be used for which higher
layer protocol encapsulation.
higherLayerProtocol multiProtocolMech
rfc2684 llcEncapsulation +
vcMultiplexing
ppp llcEncapsulation +
vcMultiplexing
pppOverEthernet llcEncapsulation
What is PPPoA (RFC 2364)?
PPP over ATM adaptation layer 5 (AAL5) uses AAL5 as the framed protocol. It relies on RFC 2684, oper-
ating in either Logical Link Control Encapsulation or Virtual Connection Multiplexing mode. A Customer
Premises Equipment (CPE) device encapsulates the PPP session based on this RFC for transport
across the xDSL loop and the Digital Subscriber Line Access Multiplexer (DSLAM).
What is over ATM (RFC 2516)?
PPP over Ethernet (PPPoE) over ATM actually combines three protocols: Ethernet, PPP and ATM. The
Ethernet is encapsulated in PPP which, on its turn, is encapsulated in ATM:
• The Ethernet protocol provides the ability to connect a network of hosts over a simple bridging access
device to a remote access concentrator.
• The PPP protocol provides the ability that each host utilises its own PPP stack and that the user is
presented with a familiar user interface. Access control, billing and type of service can be done on a
per-user basis, rather than on a per-site basis.
• The ATM protocol provides service-provider digital subscriber line (DSL) support.
What is PPPoE (RFC 2516)?
PPP over Ethernet (PPPoE) provides the ability to connect a network of hosts over a simple bridging
access device to a remote access concentrator. With this model, each host utilises its own PPP stack
and the user is presented with a familiar user interface. Access control, billing and type of service can
be done on a per-user basis, rather than on a per-site basis.
PPPoE has two distinct stages:
• a discovery stage.
• a PPP session stage.
When a host wants to initiate a PPPoE session, it must first perform discovery to identify the Ethernet
MAC address of the peer and establish a PPPoE session ID. While PPP defines a peer-to-peer relation-
ship, discovery is inherently a client-server relationship. In the discovery process, a host (the client) dis-
covers an access concentrator (the server). Based on the network topology, there may be more than
one access concentrator that the host can communicate with. The discovery stage allows the host to
discover all access concentrators and then select one. When discovery completes successfully, both the
host and the selected access concentrator have the information they will use to build their point-to-point
connection over Ethernet.
The discovery stage remains stateless until a PPP session is established. Once a PPP session is estab-
lished, both the host and the access concentrator must allocate the resources for a PPP virtual interface.
What is CLP?
The Cell Loss Priority (CLP) indicates whether the cell should be discarded if it encounters extreme con-
gestion as it moves through the network. If the CLP bit equals 1, the cell should be discarded in prefer-
ence to cells with the CLP bit equal to 0.
What is EFCI?
The Explicit Forward Congestion Indication (EFCI) indicates whether a cell containing user data experi-
enced congestion as it moved through the network.
6.2.2 Configuring ATM PVCs
Refer to 6.2.1 - Introducing ATM on page 98 for an introduction.

In an ATM network you can set-up PVCs. A PVC allows direct connectivity between sites. In this way, a
PVC is similar to a leased line. A PVC guarantees availability of a connection and does not require call
setup procedures between the ATM switches.
To configure an ATM PVC, proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to the atm object, select the pvcTable
attribute and add one or more entries to this table.
Use this attribute to set up ATM PVCs. Add a row to the pvcTable for each ATM PVC you
want to create.
2 Configure the elements of the ATM PVC you just created. These elements are:
• name. Use this element to assign an administrative name to the ATM PVC.
• adminStatus. Use this element to activate (up) or deactivate (down) the ATM PVC.
• mode. Use this element to determine whether, for the corresponding ATM PVC, the
packets are treated by the routing process, the bridging process or both.
• priorityPolicy. Use this element to apply a priority policy on the ATM PVC. Refer to
7.11.15 - Applying a priority policy on an interface on page 293 for more information.
• ip. Use this element to configure the IP related parameters of the ATM PVC. Refer to
5.2.3 - Explaining the ip structure on page 56 for more information.
• bridging. Use this element to configure the bridging related parameters of the ATM PVC
in case the PVC is in bridging mode (i.e. in case the mode element is set to bridging).
Refer to 8.2.6 - Explaining the bridging structure on page 318 for more information.
• atm. Use this element to configure the ATM specific parameters of the ATM PVC.
Refer to pvcTable/atm on page 536 for more information.
• ppp. Use this element to configure the PPP related parameters of the ATM PVC in
case you want to run PPP over ATM. Refer to 11.5.4 - PPP configuration attributes on
page 566 for a detailed description of the elements in the ppp structure.
Refer to pvcTable on page 534 for a detailed description of the pvcTable.

Example - configuring ATM PVCs
The following figure gives an example of a local Ethernet segment connected to three different networks
through three different PVCs:
The following screenshot shows (part of) the pvcTable of the set-up depicted in the figure above:
6.2.3 Automatically obtaining IP addresses in ATM
Obtaining a local IP address
In case of ATM, the 1424 SHDSL Router can perform an auto-install (refer to 16 - Auto installing the
1424 SHDSL Router on page 1147). This includes obtaining a local IP address of the ATM PVC. How-
ever, even if no auto-install is performed the 1424 SHDSL Router runs the following sequence to obtain
a local IP address of the ATM PVC:
Obtaining a remote IP address
If the ATM network supports the InARP (Inverse Address Resolution Protocol) protocol, then the 1424
SHDSL Router can learn the remote IP address of an ATM PVC.
6.2.4 Configuring IP addresses in ATM
To configure IP addresses on an ATM PVC, proceed as follows:
Step Action
1 In the pvcTable, select the ip structure.
2 In the ip structure, configure the following elements:

• address. Use this element to assign an IP address to the local end of the ATM PVC.
• netMask. Use this element to assign an IP subnet mask to the local end of the ATM
PVC.
• remote. Use this element to assign an IP address to the remote end of the ATM PVC.
• unnumbered. In case you do not explicitly configure a local IP address for an ATM PVC,
then you can use this element to "borrow" the IP address of another interface for
which an IP address is already configured.
Refer to …
• 5.2.3 - Explaining the ip structure on page 56 for a complete description of the ip structure.
• Example - configuring ATM PVCs on page 111 for an example.
6.2.5 Configuring the VPI and VCI
Refer to 6.2.1 - Introducing ATM on page 98 for an introduction on VPI and VCI.
To configure the VPI and VCI of an ATM PVC, proceed as follows:
Step Action
1 In the pvcTable, select the atm structure.
2 In the atm structure, configure the following elements:

• vpi. Use this element to set the Virtual Path Identifier (VPI) of the
ATM PVC.
• vci. Use this element to set the Virtual Channel Identifier (VCI) of
the ATM PVC.
Refer to …
• pvcTable/atm on page 536 for a complete description of the atm structure.
• Example - configuring ATM PVCs on page 111 for an example.
6.2.6 Configuring UBR
Refer to 6.2.1 - Introducing ATM on page 98 for an introduction on UBR and related traffic parameters.
To configure UBR on an ATM PVC, proceed as follows:
Step Action
2 In the atm structure, set the serviceCategory element to ubr.
3 In the atm structure, configure the UBR related traffic parameters.

The only parameter you have to configure in case of UBR is the
Peak Cell Rate (PCR). The PCR only provides an indication of a
physical bandwidth limitation within a PVC.
Refer to pvcTable/atm on page 536 for a complete description of the atm structure.
6.2.7 Configuring VBR-nrt
Refer to 6.2.1 - Introducing ATM on page 98 for an introduction on VBR-nrt and related traffic parame-
ters.
To configure VBR-nrt on an ATM PVC, proceed as follows:
Step Action
2 In the atm structure, set the serviceCategory element to vbt-nrt.
3 In the atm structure, configure the VBR-nrt related traffic parameters:

• the Peak Cell Rate (PCR).
• the Sustainable Cell Rate (SCR).
• the Maximum Burst Size (MBS).
The PCR and MBS must be understood only as mechanisms to reduce latency and not
as a way to increase bandwidth. Thus, the PCR and MBS allow you to accommodate
short duration bursts of traffic without packet drops taking place. If long duration bursts
exist often in your specific traffic pattern, they should be taken under account when
choosing the value for SCR.
Calculating the burst size
From the MBS it is possible to figure out how many time, in seconds, the 1424 SHDSL Router will be
able to transmit at PCR, by means of the following equation:
T = (MBS x 424 bits per cell) / (PCR - SCR)
So suppose the SCR and PCR are known to be 64 kbps and 256 kbps and suppose you set the MBS to
…
• 45 cells, then T = 100 ms which means you can have bursts up to approximately 3 kbytes.
6.2.8 Configuring VBR-rt
Refer to 6.2.1 - Introducing ATM on page 98 for an introduction on VBR-rt and related traffic parameters.
To configure VBR-rt on an ATM PVC, proceed as follows:
Step Action
2 In the atm structure, set the serviceCategory element to vbt-rt.
3 In the atm structure, configure the VBR-rt related traffic parameters:

• the Peak Cell Rate (PCR).
• the Sustainable Cell Rate (SCR).
• the Maximum Burst Size (MBS).
The PCR and MBS must be understood only as mechanisms to reduce latency and not
as a way to increase bandwidth. Thus, the PCR and MBS allow you to accommodate
short duration bursts of traffic without packet drops taking place. If long duration bursts
exist often in your specific traffic pattern, they should be taken under account when
choosing the value for SCR.
Calculating the burst size
From the MBS it is possible to figure out how many time, in seconds, the 1424 SHDSL Router will be
able to transmit at PCR, by means of the following equation:
T = (MBS x 424 bits per cell) / (PCR - SCR)
So suppose the SCR and PCR are known to be 64 kbps and 256 kbps and suppose you set the MBS to
…
6.2.9 Configuring CBR
Refer to 6.2.1 - Introducing ATM on page 98 for an introduction on CBR and related traffic parameters.
To configure CBR on an ATM PVC, proceed as follows:
Step Action
2 In the atm structure, set the serviceCategory element to cbr.
3 In the atm structure, configure the CBR related traffic parameters.

The only parameter you have to configure in case of CBR is the
Peak Cell Rate (PCR).
6.2.10 ATM PVC bandwidth assignment
Bridging and routing
When selecting a certain service category for an ATM PVC, the 1424 SHDSL Router assigns a certain
amount of bandwidth to this ATM PVC. The amount of bandwidth that is assigned by the 1424 SHDSL
Router does not necessarily correspond with the amount of bandwidth that you configured.
The way the 1424 SHDSL Router assigns bandwidth depends on factors such as available memory, the
service category, the minimum bandwidth, etc. The most important factors are:
Factor Description
service category The higher the importance of the requested service category, the closer the
importance assigned bandwidth comes to the requested bandwidth. The importance of the
service categories in descending order is as follows:
1. CBR (high)
2. VBR-rt
3. VBR-nrt
4. UBR (low)
Examples:
• Suppose you select the service category UBR and you set the PCR to 8 kbps.
In that case, it is possible that instead of 8 kbps, 16 kbps is assigned to the ATM
PVC.
• Suppose you select the service category CBR and you set the PCR to 8 kbps.
PVC.
minimum The higher the requested bandwidth, the closer the assigned bandwidth comes to
requested band- the requested bandwidth.
width
Examples:
• Suppose you select the service category UBR and you set the PCR to 8 kbps.
PVC. This is a deviation of 50%.
• Suppose you select the service category UBR and you set the PCR to 1024
kbps. In that case, it is possible that instead of 1024 kbps, 1032 kbps is
assigned to the ATM PVC. This is a deviation of only +- 0.8%.
The amount of bandwidth that is assigned can be checked in the ATM status attributes.
Switching
In case of switched ATM PVCs, there is no QoS translation between source and destination. This would
imply that when a switched ATM PVC comes through, it would get as much bandwidth as necessary to
serve the incoming data stream. This would mean that if the switched ATM PVC carries a high bandwidth
data stream, that the existing bridged or routed ATM PVCs (on the same physical interface) may suffer
from this, even if their service category is CBR.
To avoid this, the priority configuration element has been added to the ATM switching table. Using this
element, you can define in which “service category” the switched ATM PVC falls.
Switched ATM PVC priority Corresponding “service category”
high CBR
medium VBR-rt
low VBR-nrt
You can define a different priority for each switched ATM PVC. However, all switched ATM PVCs that
have the same priority are treated equally.
Examples:
• Setting the priority of a switched ATM PVC to high, makes it of equal priority as a bridged or routed
ATM PVC with service category CBR. So both ATM PVCs will be treated equally as it comes to band-
width assignment.
• Setting the priority of a switched ATM PVC to high, makes it of higher priority as a bridged or routed
ATM PVC with service category VBR. So when the switched ATM PVC comes through, it will be given
priority over the bridged or routed ATM PVC.
6.2.11 Configuring bridged/routed Ethernet/IP over ATM (RFC 2684)
Refer to 6.2.1 - Introducing ATM on page 98 for an introduction on bridged/routed Ethernet/IP over ATM.
To configure bridged/routed Ethernet/IP (multi-protocol) over ATM on an ATM PVC, proceed as follows:
Step Action
2 In the atm structure, set the higherLayerProtocol element to rfc2684.

By selecting this value you indicate that different types of protocol
data units (PDUs) may be present in the traffic on this interface.
3 Also in the atm structure, set the multiProtocolMech element to the

desired encapsulation mechanism.
By selecting one of these two values you indicate how the different
types of protocol data units (PDUs) have to be encapsulated in
ATM AAL type 5.
In case of …
• llcEncapuslation, all the different PDU types are carried over a single PVC. In this case,
the different PDU types can be distinguished from one another by the information in
the Logical Link Control (LLC) header.
• vcMultiplexing, each PDU type is carried over a separate PVC. So in this case, you have
to set up as many PVCs as there are PDU types in your traffic. What is more, the
remote application has to know which PVC carries which PDU type.
6.2.12 Configuring Classical IP (IPoA)
Refer to 6.2.1 - Introducing ATM on page 98 for an introduction on IP over ATM.

Classical IP (RFC 1577) is one of the first commonly used encapsulations of IP over ATM. The encap-
sulation method is the same as described in RFC 2684 (formerly RFC 1483). The IP traffic is encapsu-
lated without Ethernet header. Inverse ARP is in use for the resolution of IP addresses to PVC channels.
To configure Classical IP on an ATM PVC, proceed as follows:
Step Action
1 In the pvcTable, set the mode element to routing.
3 In the atm structure, set the higherLayerProtocol element to rfc2684.

desired encapsulation mechanism: llcEncapuslation or vcMultiplexing.
Note that Inverse ARP is always in use. Therefore there is no dedicated attribute to enable or disable
InARP.
6.2.13 Configuring PPP over ATM (PPPoA)
Refer to 6.2.1 - Introducing ATM on page 98 for an introduction on PPP over ATM.
To configure PPP over ATM on an ATM PVC, proceed as follows:
Step Action
2 In the atm structure, set the higherLayerProtocol element to ppp.

desired encapsulation mechanism: llcEncapuslation or vcMultiplexing.
4 In the pvcTable, select the ppp structure.
5 In the ppp structure, configure the PPP elements (link monitoring, authentication, etc.).
Refer to …
• 6.7 - Configuring PPP encapsulation on page 160 for more information on configuring
PPP.
• 11.5.4 - PPP configuration attributes on page 566 for a detailed description of the ele-
ments in the ppp structure.
6.2.14 Configuring PPP over Ethernet (PPPoE)
Refer to 6.2.1 - Introducing ATM on page 98 for an introduction on PPP over Ethernet.
To configure PPP over Ethernet on an ATM PVC, proceed as follows:
Step Action
2 In the atm structure, set the higherLayerProtocol element to pppOver-

Ethernet.
3 Also in the atm structure, set the multiProtocolMech element to llcEnca-

puslation.
4 In the pvcTable, select the ppp structure.
5 In the ppp structure, configure the PPP elements (link monitoring, authentication, etc.).
Refer to …
• 6.7 - Configuring PPP encapsulation on page 160 for more information on configuring
PPP.
• 11.5.4 - PPP configuration attributes on page 566 for a detailed description of the ele-
ments in the ppp structure.
6.3 Configuring OAM on ATM interfaces
This section introduces OAM on ATM interfaces, and gives a short description of the attributes you can
use to configure OAM.
• 6.3.1 - What is OAM? on page 126
• 6.3.2 - OAM functional overview on page 128
• 6.3.3 - OAM concepts on page 129
• 6.3.4 - OAM Fault and performance management on page 131
• 6.3.5 - OAM Loopback (LB) on page 133
• 6.3.6 - OAM Continuity Check (CC) on page 134
• 6.3.7 - OAM Performance Monitoring (PM) on page 136
• 6.3.8 - Activation/deactivation mechanism on page 137
6.3.1 What is OAM?
• OAM (Operation, Administration and Maintenance) defines the ability to monitor the functionality of
VC's and VP's in the ATM network, detect failures, propagate these failures to ATM end nodes, and
monitor the performance of VC and VP links.
• OAM is basically a 'layer 1' feature of the VC's and VP's, i.e. OAM determines if the VC or VP is oper-
ational, and as such triggers higher layer functionality.
For example: OAM will bring the status of the pvc down if a defect has been detected between its
endpoints and subsequently will bring down the higher layer application (e.g. bridging and routing).
• Detecting the operational status of the VC/VP is done by two mechanisms:
- OAM Loopback: an endpoint sends out a loopback message at regular intervals which should be
replied by the remote endpoint. OAM Loopback must be activated manually.
Subsequent failures in receiving loopback replies results in an operational down of the VC/VP.
- OAM CC: an endpoint sends a CC message at regular intervals, which is interpreted by the
remote endpoint as a kind of 'keepalive' message. If the remote endpoint fails to receive CC mes-
sages, the VC/VP is considered operationally down, which is reported to the other endpoint by
sending AIS messages. OAM CC can either be activated manually, or automatically.
• Besides determining the operational status of a VC/VP, OAM also provides for performance monitor-
ing of VC's/VP's. This is accomplished with the help of the processor, which, if activated, determines
when a PM cell needs to be sent to the remote endpoint, and is able to independently interpret such
messages for statistics purposes. OAM PM can either be activated manually, or automatically.
• OAM is used to maintain ATM VP’s and VC’s by sending a certain type of cells, OAM F4 and OAM
F5 cells:
- OAM on Virtual Path level is referred to as OAM F4.
- OAM on Virtual Channel level is referred to as OAM F5.
OAM F4 is functionally equal to OAM F5.
• The following principles have been considered in specifying the OAM functions:
- Performance monitoring (PM)
PM is a function which processes user information to produce maintenance information specific to
the user information. This maintenance information is added to the user information at the source of
a connection/link, and extracted at the sink of a connection/link. Analysis of the maintenance event
information at the sink of the connection allows estimation of the transport integrity.
- Defect and failure detection
Defects or failures affecting the transport of user information are detected by continuous or periodic
checking. As a result, maintenance event information or various alarms will be produced.
- System protection
The effect of a defect on the transport of user information is minimized by blocking or changeover to
other entities. As a result the failed entity is excluded from operation.
- Defect information
Defect information is given to other management entities. As a result, alarm indications are given to
other management planes. Response to a status report request will also be given.
- Fault localization
Internal or external test systems can determine a failed entity, if defect information is insufficient.
6.3.2 OAM functional overview
There are two basic functions:

• ‘layer 1’ maintenance: monitoring of the operational status of a virtual path (VP) or virtual channel
(VC).
• Performance monitoring: monitoring of the ‘quality level’ of a VP / VC
OAM allows network operators to:
• have a view on the operational status of their network.
• Pro-actively manage and adapt the network infrastructure.
• guarantee the SLA’s they have agreed with their customers.
OAM allows users of an ATM network to:
• verify the QoS aspects of the ATM network they are dependent of.
• check the SLA agreement with their network operator.
• receive notifications of VP/VC failures for e.g. backup reasons.
6.3.3 OAM concepts
• The ATM network is divided into:

- End-to-end connections (on VP and VC level).
- Segments within these end-to-end connections (on VP and VC level).
• OAM flows are generated and terminated within a segment. The following figure illustrates the con-
cept of segments:
• Each ATM interface is characterized as an endpoint or an intermediate point:

- a connection endpoint is the end of a VP/VC.
- a segment endpoint is the end of a segment within the ATM network.
- an intermediate point is the intermediate interface which is not end of a segment or a connection.
- An endpoint generates and receives OAM messages.
- An intermediate point only switches OAM messages.
- The following figure illustrates the concept of endpoints and intermediate points:
• This concept holds for OAM F4 and OAM F5.

6.3.4 OAM Fault and performance management
OAM LoopBack (LB)
The ATM protocol features OAM LoopBack (LB) cells. These are used to verify whether a Virtual Chan-
nel/Path is truly up or down. This can be done on two levels:
• on Virtual Path (VP) level by using OAM F4 LB cells. The relevant configuration attributes can be
found in the vp table: refer to vp on page 549.
• on Virtual Channel (VC) level by using OAM F5 LB cells. The relevant configuration attributes can be
found in the pvcTable: refer to pvcTable on page 534.
The 1424 SHDSL Router always responds to OAM LB cells received from the peer ATM device (both
segment and end-to-end cells). However, when OAM LB is activated, the 1424 SHDSL Router only
sends end-to-end OAM LB request cells.
OAM Continuity Check (CC)
The ATM protocol features OAM Continuity Check (CC) cells. These are used to continuously monitor
the continuity of a Virtual Channel/Path. This can be done on two levels:
• on Virtual Path (VP) level by using OAM F4 CC cells. The relevant configuration attributes can be
found in the vp table: refer to vp on page 549.
• on Virtual Channel (VC) level by using OAM F5 CC cells. The relevant configuration attributes can
be found in the pvcTable: refer to pvcTable on page 534.
In case of a failure of the VP or VC:

• an alarm is sent in the forward direction, which is also referred to as AIS : Alarm Indication Signal.
• an alarm is sent in the backward direction, which is also referred to as RDI : Remote Defect Indication.
The CC mechanism can be activated/deactivated …
• manually.
• by using activator/deactivator cells.
OAM Performance Management
OAM performance Management gathers and analyzes statistical data to detect error conditions in the
flow of ATM data.
Performance Management works in both directions:
• FPM or forward performance monitoring: estimates performance over a specific connection.
• BR or backward reporting: reports gathered data to the backward direction.
Refer to 11.5.1 - ATM configuration attributes on page 533, 12.5.1 - ATM status attributes on page 847
and 13.5.1 - ATM performance attributes on page 1034 for more information about the respective con-
figuration, status and performance attributes of OAM.
6.3.5 OAM Loopback (LB)
• OAM LB can be seen as an ATM ping.

• OAM LB must be activated manually.
• An endpoint sends out a LB cell at regular intervals, which should be replied by the remote endpoint.
If no replies are received for x intervals, the VP/VC is considered down.
• There are two types of loopback:
- End-to-end loopback: this is a loopback between connection endpoints.
- Segment loopback: this is a loopback between segment endpoints.
• The main applications of LB are:
- On-demand connectivity monitoring.
- Fault localization.
- Pre-service connectivity verification.
6.3.6 OAM Continuity Check (CC)
What is oAM CC?
• OAM CC is a keep-alive mechanism on ATM level.

• OAM CC is a mechanism for continuously monitoring operational continuity.
• OAM CC can either be activated manually, or automatically.
• A source endpoint sends CC cells at regular intervals.
• The sink endpoint expects CC cells at regular intervals.
• If the sink endpoint does not receive CC cells for x intervals, the VP/VC on the defined segment is
considered down.
In this case:
- The endpoint enters AIS state.
- The endpoint sends AIS messages in the forward direction during AIS state.
- The remote endpoint receiving AIS messages returns RDI messages in the backward direction.
Forward/backward direction
• The Forward direction is the direction of the considered ATM cell flow.
E.g.: failure is detected at an interface at the rx side
- AIS cells are sent in the direction of the ATM cell rx flow, this means downstream.
- AIS cells are sent on the switched interface.
• The Backward direction is the reverse direction of the considered ATM cell flow.
E.g: failure is detected at an interface at the rx side
- RDI cells are sent in the backward direction of the ATM cell rx flow, this means upstream.
- RDI cells are sent on the interface which detected the fault
OAM AIS
• Indicates a failure of the VP/VC in the forward direction.

• Is generated by an endpoint or by an intermediate point.
• Is only interpreted by an endpoint.
• A failure is:
- Continuity Check Failure
- Link failure (Loss of Framing – Loss of Signal)
OAM RDI
• Indicates a failure of the VP / VC in the backward direction.

• Is only generated by an endpoint
• Is only interpreted by an endpoint
• OAM RDI is sent when the endpoint is in AIS-state.
• The endpoint is in AIS state upon:
- Reception of AIS messages
- Loss Of Continuity (LOC)
- Link failure (Loss of Framing – Loss of Signal)
OAM AIS/RDI generation
• A failure at an intermediate connection point generates:

- Segment AIS in forward direction.
- End-to-end AIS in forward direction.
• A failure at a segment endpoint generates:
- End-to-end AIS in forward direction.
- Segment RDI in backward direction.
• A failure at a connection endpoint generates:
- End-to-end RDI in backward direction.
• A failure on VP level affects all VC’s that are part of that VP, i.e. a VP level failure causes a VC failure
for all the VC’s belonging to that VP.
OAM AIS/RDI example
The following example illustrates OAM AIS/RDI generation:

6.3.7 OAM Performance Monitoring (PM)
Purpose
• PM gathers and analyzes statistical data to detect error conditions in the flow of ATM data.
• OAM PM can either be activated manually, or automatically.
• PM monitors the QoS of a network connection and detects potential problems (i.e. due to malfunc-
tioning or failing ATM devices, overload in the network, ...). Some of the things that are monitored are:
- Cell Block Error ratio
- Cell Loss Ratio
- Misinserted cells
Refer to 13.5.1 - ATM performance attributes on page 1034 for more information on the OAM per-
formance attributes.
Forward Performance Management (FPM)
• FPM collects statistics of the forward (i.e. tx direction) ATM cell flow and sends this information to the
remote endpoint at regular times.
• FPM data is generated at the source endpoint.
• FPM data is interpreted at the sink endpoint: information contained in the FPM cells are compared
with the really received ATM cell flow. This allows for detection of lost, mis-inserted, … cells.
• FPM allows the sink to obtain statistics about its rx side (i.e. estimates performance about the forward
direction at the sink).
Backward Reporting (BR)
• BR reports statistics in the backward (i.e. rx direction) ATM cell flow.

• A BR cell is a ‘looped back’ FPM cell (sent back to the source) containing additional statistics about
the really received ATM cell flow.
• BR data is generated at the sink endpoint, and interpreted at the source endpoint.
• BR allows the source to obtain statistics about its tx side (i.e. estimates performance about the for-
ward direction at the source).
Mechanism
• The tx ATM cell flow is divided into blocks of cells of configurable size.
• Statistics are gathered per block.
• An FPM cell is inserted into the cell flow at the end of each block containing the gathered statistics.
• Statistics about the received cell flow are gathered per block.
• Blocks are bound by the received FPM cells.
• Each FPM cell is returned with additionally gathered statistics.
6.3.8 Activation/deactivation mechanism
• The activation/deactivation mechanism is a negotiation between endpoints to agree if and what OAM
functionality needs to be activated at both endpoints.
• It is used with CC and FPM.
• Necessary if on-demand activation of OAM CC or PM is needed, as both source and sink need to
agree on the activation (this in contrast with LB, AIS and RDI).
• The different activation/deactivation modes are:
- Deactivated: this mode will not start CC or PM in any case.
- Activated: CC/PM is started, no negotiation is done with the remote endpoint.
- Passive: the 1424 SHDSL Router is willing to accept activation/deactivation messages and
responds to it.
- InitActivation: this mode initiates the activation of the CC/PM process by sending activation mes-
sages.
6.4 Configuring ATM IMA
This section introduces Inverse Multiplexing over ATM (ATM IMA) and gives a short description of how
to configure it.
• 6.4.1 - Introducing ATM IMA on page 139
• 6.4.2 - Configuring ATM IMA on page 140
6.4.1 Introducing ATM IMA
Combining DSL links
IMA is a technique enabling to split and reassemble an ATM cell stream over multiple physical links. It
was defined by the ATM Forum recommendation AF-PHY-0086.0001.
This technique is highly efficient to increase the capacity of transmission links: up to 4 DSL links can be
combined.
An IMA interface forms an IMA group. An IMA group is actually made up of several physical links. The
role of IMA is to split the incoming cell traffic over the different physical interfaces. The IMA group must
respectively reassemble the cell stream at the remote end. The IMA algorithm ensures the cell stream
is reassembled in the proper order and compensates for possible inter-link delays.
This is illustrated in the following figure:
Data cells
The data transiting over the DSL links are made up of:
• ATM cells. Tthe cells are sent over each link on a cell-by-cell basis.
• ICP (IMA Control Protocol) cells. These cells provide the definition of an IMA frame. The transmitter
must align the transmission of IMA frames on all links. This allows the receiver to adjust for differential
link delays among the physical links. The receiver can detect the differential delays by measuring the
arrival times of the IMA frames on each link.
• Filler cells (when no ATM cells have to be sent). At the transmitting end, the cells are transmitted con-
tinuously. If there are no ATM layer cells to be sent between ICP cells within an IMA frame, then the
IMA transmitter sends filler cells to maintain a continuous stream of cells at the physical layer. The
filler cells are discarded by the IMA receiver.
6.4.2 Configuring ATM IMA
To configure ATM IMA, proceed as follows:
Step Action
1 First of all, the encapsulation of the DSL interface must be set to atm, using the encapsula-
tion attribute:
2 The ATM encapsulation protocol itself must then be configured, and ima must be enabled
on the WAN intefrace:
3 Then, the ima attributes must be configured as needed:

6.5 Configuring EFM encapsulation
This section introduces the EFM encapsulation protocol and gives a short description of the features.
• 6.5.1 - Introducing EFM on page 142
• 6.5.2 - OAM or Operation, Administration and Maintenance on page 143
6.5.1 Introducing EFM
What is EFM?
Ethernet in the First Mile or EFM, also known as IEEE 802.3ah, is a collection of protocols which define
Ethernet in access networks, or First or Last Mile. It allows much bigger speeds in the customer access
networks.
The Last Mile is the name traditionally given to the part of a public communication network that links the
last provider-owned node (the central office or CO, the street cabinet or pole) with the customer premises
equipment (CPE). The First Mile means the same, but viewed from the customer's perspective.
The Last Mile can be seen as a bottle neck in the communication network.
EFM does not improve or replace the existing Ethernet standard, it is an extension of Ethernet technol-
ogy.
It is a new standard, allowing users to run the Ethernet protocol over previously unsupported media, such
as single pairs of telephone wiring. This makes EFM suitable for use in subscriber access networks, i.e.
the networks that connect subscribers to their service provider.
Ethernet
Ethernet began as a broadcast local area network technology as a best effort delivery protocol. Occa-
sional frame disruptions due to collisions or signal noise were expected and tolerated.
These days, Ethernet is omnipresent. It is easy to configure, cost-effective, highly scalable and supports
a wide range of services such as data, voice and video. This makes it well suited to the demands of the
First Mile, bridging the gap between the provider network and the subscriber network, making use of
cable or Digital Subscriber Line (DSL).
However, quality demands in First Mile connection networks using EFM, are much higher compared to
LAN networks. High availability and sophisticated tools to manage and troubleshoot the EFM networks
are a must for providing the high level of service customers require. Performance must be monitored,
and any errors in the network must be detected and isolated very quickly.
Therefore, issues required for mass deployment of Ethernet services, such as OAM (Operation, Admin-
istration and Maintenance) and compatibility with existing technologies, have all been dealt with in the
EFM standard.
More simple architecture
The use of EFM in subscriber access applications eliminates unnecessary network layers. The elimina-
tion of network layers reduces the number of network elements in a network, and that reduces equipment
costs, operational costs, and complexity.
6.5.2 OAM or Operation, Administration and Maintenance
EFM OAM is a mechanism that provides DTE information, event notification, variable retrieval, and loop-
back controls.
The actual use of the OAM functionality is optional. A device is able to determine whether or not a remote
device has the OAM functionality enabled. The OAM Discovery mechanism ascertains the configured
parameters, such as maximum allowable OAMPDU size, and supported functions such as OAM remote
loopback, on a given link.
For more detailed information about the OAM mechanism, refer to section 5 of IEEE Std. 802.3-2005,
more specifically section 57. Operations, Administration, and Maintenance (OAM).
Refer to 11.5.5 - EFM configuration attributes on page 571 for a detailed explanation of the EFM and
OAM configuration attributes.
Purpose of OAM
• OAM is a mechanism to:

- monitor the functionality, link operation and health of the EFM network.
- detect failures and improve fault isolation.
- propagate these failures to end nodes.
- monitor the performance of the EFM network.
• The OAM mode can be set to active, passive, auto, or can be disabled. The OAM mode is further dis-
cussed below.
OAMPDUs or protocol data units
OAM information is conveyed in protocol frames called OAM Protocol Data Units or OAMPDUs, that are
sent between two ends of a single link. OAMPDUs contain the appropriate control and status information
used to monitor, test and troubleshoot OAM-enabled links.
OAM discovery
• OAM discovery allows a local DTE to detect OAM on a remote DTE.

• Once OAM support is detected, both ends of the link exchange configuration and status information
e.g. mode, PDU size, loopback support.
• If both DTEs are satisfied with the settings, OAM is enabled on the link.
• Loss of link and non-reception of PDUs for 5 seconds will cause the discovery process to restart.
OAM remote loopback
• OAM remote loopback can be used for fault localization and link performance testing. Statistics from
both the local and remote DTE can be queried and compared at any time while the remote DTE is in
OAM remote loopback mode.
• OAM loopback is a process that is used to verify whether a link is truly up or down. This is done by
sending (and receiving) OAM LoopBack PDUs between both ends of the link.
• OAM loopback can be started or stopped on the device. Refer to the action oamRemoteLoopback in
12.5.5 - EFM status attributes on page 877.
• The Local DTE sends loopback control PDUs, the remote DTE acknowledges by sending information
PDUs with updated state information.
OAM Active Mode
A device configured in active mode initiates the exchange of Information OAMPDUs. Once the Discovery
process completes, active devices are permitted to send any OAMPDU while connected to a remote
OAM device in active mode. Active devices operate in a limited respect if the remote OAM device is oper-
ating in passive mode. Active devices do not respond to OAM remote loopback commands and variable
requests from a passive device.
The 1424 SHDSL Router can be set to active mode using the oam attribute; also refer to 11.5.5 - EFM
configuration attributes on page 571.
The 1424 SHDSL Router in active mode:
• initiates the OAM Discovery process.
• sends Information PDUs.
• may send Event Notification PDUs.
• may send Variable Request/Response PDUs.
• may send Loopback Control PDUs.
The 1424 SHDSL Router in active mode does not:
• respond to Variable Request PDUs from other DTEs in Passive mode.
• react to Loopback Control PDUs from other DTEs in Passive mode.
6.6 Configuring Frame Relay encapsulation
This section introduces the Frame Relay encapsulation protocol and gives a short description of the
attributes you can use to configure this encapsulation protocol.
• 6.6.1 - Introducing Frame Relay on page 146
• 6.6.2 - Configuring Frame Relay DLCIs on page 150
• 6.6.3 - Automatically obtaining IP addresses in Frame Relay on page 152
• 6.6.4 - Configuring IP addresses in Frame Relay on page 153
• 6.6.5 - Configuring LMI on page 156
• 6.6.6 - Configuring CIR and EIR on page 157
• 6.6.7 - Enabling Frame Relay fragmentation on page 159
6.6.1 Introducing Frame Relay
What is Frame Relay?
Frame Relay is a networking protocol that works at the bottom two levels of the OSI reference model:
the physical and data link layers. It is an example of packet-switching technology, which enables end
stations to dynamically share network resources.
Frame Relay devices fall into the following two general categories:
• Data Terminal Equipment (DTEs), which include terminals, personal computers, routers, and
bridges.
• Data Circuit Equipment (DCEs), which transmit the data through the network and are often carrier-
owned devices.
What is a DLCI?
Frame Relay networks transfer data using one of the following connection types:
• Switched Virtual Circuits (SVCs), which are temporary connections that are created for each data
transfer and then are terminated when the data transfer is complete (not a widely used connection).
• Permanent Virtual Circuits (PVCs), which are permanent connections.
The 1424 SHDSL Router makes use of Permanent Virtual Circuits. The Data Link Connection Identifier
(DLCI) is a value assigned to each virtual circuit and DTE device connection point in the Frame Relay
WAN. Two different connections can be assigned the same value within the same Frame Relay WAN,
one on each side of the virtual connection.
What is LMI?
A set of Frame Relay enhancements exists, called the Local Management Interface (LMI). The LMI
enhancements offer a number of features (referred to as extensions) for managing complex networks,
including:
• global addressing,
• virtual circuit status messages,
• multicasting.
LMI provides a status mechanism which gives an on-going status report on the DLCIs. These status
reports are exchanged between the Frame Relay access device (or Frame Relay DTE or user) and
Frame Relay node (or Frame Relay DCE or network).
At regular intervals (typically every 1 minute), the Frame Relay user (e.g. a router) sends Full Status
Enquiry messages to the Frame Relay network (e.g. a Frame Relay switch). On its turn, the Frame Relay
network sends a Full Status Response to the Frame Relay user. In this response the Frame Relay net-
work reports which DLCIs are configured at its side and which of these DLCIs are up or down. Until the
first Full Status Enquiry exchange has occurred, the Frame Relay user does not know which DLCIs are
active and so no data transfer can take place.
At smaller intervals (typically every 10 seconds), the Frame Relay user sends Status Enquiry messages
to the Frame Relay network. On its turn, the Frame Relay network sends a Status Response to the
Frame Relay user. In this response the Frame Relay network only reports which DLCIs are up or down.
There are various LMI versions: LMI rev.1, ANSI T1.617 Annex D, Q.933 Annex A, etc. To ensure inter-
operability when your network consists of equipment from different vendors, the same version of LMI
protocol must be at each end of the Frame Relay link.
What is CIR and BC?
• CIR = BC / TC
• The Committed Information Rate (CIR) is the specified amount of guaranteed bandwidth (measured
in bits per second) on a Frame Relay service. Typically, when purchasing a Frame Relay service the
customer can specify the CIR level he wishes. The Frame Relay network provider guarantees that
traffic not exceeding this level will be delivered.
• The Committed Burst (BC) is the maximum amount of data (in bits) that the network agrees to trans-
fer, under normal conditions, during a time interval TC.
What is EIR and BE?
• EIR = BE / TC
• The Excess Information Rate (EIR) is the specified amount of unguaranteed bandwidth (measured
in bits per second) on a Frame Relay service. It is the traffic in excess of the CIR. This traffic may also
be delivered, but this is not guaranteed.
• The Excess Burst (BE) is the maximum amount of uncommitted data (in bits) in excess of BC that a
Frame Relay network can attempt to deliver during a time interval TC. Generally, BE data is delivered
with a lower probability than BC, and the network treats it as discard eligible.
What is TC?
The measurement interval (TC) is the time over which rates and burst sizes are measured. In general,
the duration of TC is proportional to the burstiness of traffic.
The following figure shows the relationship between BC, BE and TC:
What is DE?
When the CIR is exceeded, all subsequent frames get marked Discard Eligible by setting the Discard
Eligible (DE) bit in the Frame Relay header. This is performed at the local Frame Relay switch. If con-
gestion occurs at a node in the Frame Relay network, packets marked DE are the first to be dropped.
Upon detecting congestion, a Frame Relay switch will send a Backward Explicit Congestion Notifier
(BECN) message back to the source. If the source (e.g. the router) has sufficient intelligence to process
this message, it may throttle back to the CIR.
What is BECN?
Backward Explicit Congestion Notification (BECN) is a bit set by a Frame Relay network in frames trav-
elling in the opposite direction of frames encountering a congested path. DTEs receiving frames with the
BECN bit set can request that higher-level protocols take flow control action as appropriate.
What is FECN?
Forward Explicit Congestion Notification (FECN) is a bit set by a Frame Relay network to inform DTEs
receiving the frame that congestion was experienced in the path from source to destination. DTEs receiv-
ing frames with the FECN bit set can request that higher-level protocols take flow-control action as
appropriate.
What is interface Frame Relay fragmentation?
Interface fragmentation is used in order to allow real-time and data frames to share the same (physical)
interface. The fragmentation is strictly local to the interface and provides the proper delay and delay var-
iation based upon the logical speed of the interface (the logical speed of an interface may be slower than
the physical clocking rate if a channelised physical interface is used). Since fragmentation is local to the
interface, the network can take advantage of the higher internal trunk speeds by transporting the com-
plete frames, which is more efficient than transporting a larger number of smaller fragments.
Interface fragmentation is also useful when there is a speed mismatch between the two DTEs at the ends
of a VC. It also allows the network to proxy for a DTE that does not implement end-to-end fragmentation.
Refer to What is end-to-end Frame Relay fragmentation? on page 149.
Interface fragmentation is not transparent to the Frame Relay network. I.e. the Frame Relay switches in
the network have to “understand” Frame Relay fragmentation.
Interface fragmentation is provisioned on an interface-by-interface basis. When Interface fragmentation

is used on an interface, then all frames on all DLCIs (including DLCI 0) are preceded by the fragmenta-
tion header.
Refer to FRF.12 for more information on Frame Relay fragmentation.

What is end-to-end Frame Relay fragmentation?
End-to-end Frame Relay fragmentation is used on DLCIs only. It is most useful when peer Frame Relay
DTEs wish to exchange both real-time and non-real-time traffic using slower interface(s), but either one
or both (physical) interfaces does not support interface Frame Relay fragmentation. Refer to What is
interface Frame Relay fragmentation? on page 148.
End-to-end Frame Relay fragmentation is transparent to the Frame Relay network. I.e. the Frame Relay
switches in the network do not have to “know” about the fragmentation.
Because DLCI 0 is never carried end-to-end, it is never fragmented using end-to-end Frame Relay frag-
mentation.
Refer to FRF.12 for more information on Frame Relay fragmentation.
What is MLFR?
Multilink Frame Relay (MLFR) provides physical interface emulation for Frame Relay devices. The emu-
lated physical interface consists of one or more physical links, called "bundle links", aggregated together
into a single "bundle" of bandwidth. This service provides a frame-based inverse multiplexing function,
sometimes referred to as an "IMUX".
The bundle provides the same order-preserving service as a physical layer for frames sent on a data link
connection. In addition, the bundle provides support for all Frame Relay services based on UNI and NNI
standards.
Refer to FRF.16 for more information on multilink Frame Relay.
What is LIP?
The Link Integrity Protocol (LIP) features a set of control messages to insure the integrity of a Frame
Relay bundle. These messages are:
LIP message Description
Add Link The Add Link message notifies the peer endpoint that the local endpoint supports
frame processing. The message includes information required to verify bundle
membership and detect loopbacks. Both ends of a bundle link generate this mes-
sage when a bundle link endpoint is ready to become operational.
Add Link The Add Link Acknowledge message notifies the peer endpoint that the local end-
Acknowledge point has received a valid Add Link message.
Add Link Reject The Add Link Reject message notifies the peer endpoint that the local endpoint
has received an invalid Add Link message.
Hello The Hello message notifies the peer endpoint that the local endpoint remains in
the state up. Both ends of a bundle link generate this message on a periodic basis.
Hello Acknowl- The Hello Acknowledge message notifies the peer that the local endpoint has
edge received a valid Hello message.
Remove Link The Remove Link message notifies the peer that the local end layer management
function is removing the bundle link from bundle operation.
Remove Link The Remove Link Acknowledge message notifies the peer that the local end has
Acknowledge received a Remove Link message.
6.6.2 Configuring Frame Relay DLCIs
Refer to 6.6.1 - Introducing Frame Relay on page 146 for an introduction.

If the Frame Relay network supports LMI, then the 1424 SHDSL Router can learn its active and inactive
DLCIs. If the Frame Relay network also supports the InARP (Inverse Address Resolution Protocol) pro-
tocol, the 1424 SHDSL Router can learn the IP address of the corresponding router for each DLCI.
If neither LMI nor InARP is supported by the Frame Relay network you can configure the DLCIs yourself
using the dlciTable.
To configure a Frame Relay DLCI, proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to the frameRelay object, select the dlciT-
able attribute and add one or more entries to this table.
Use this attribute to set up Frame Relay DLCIs. Add a row to the dlciTable for each Frame
Relay DLCI you want to create.
2 Configure the elements of the Frame Relay DLCI you just created. These elements are:
• name. Use this element to assign an administrative name to the Frame Relay DLCI.
• adminStatus. Use this element to activate (up) or deactivate (down) the Frame Relay
DLCI.
• mode. Use this element to determine whether, for the corresponding Frame Relay
DLCI, the packets are treated by the routing process, the bridging process or both.
• priorityPolicy. Use this element to apply a priority policy on the Frame Relay DLCI. Refer
to 7.11.15 - Applying a priority policy on an interface on page 293 for more informa-
tion.
• ip. Use this element to configure the IP related parameters of the Frame Relay DLCI.
Refer to 5.2.3 - Explaining the ip structure on page 56 for more information.
• bridging. Use this element to configure the bridging related parameters of the Frame
Relay DLCI in case the DLCI is in bridging mode (i.e. in case the mode element is set
to bridging). Refer to 8.2.6 - Explaining the bridging structure on page 318 for more infor-
mation.
• frameRelay. Use this element to configure the Frame Relay specific parameters of the
Frame Relay DLCI. Refer to frameRelay on page 557 for more information.
Refer to dlciTable on page 556 for a detailed description of the dlciTable.

Example - configuring Frame Relay DLCIs
The following figure gives an example of a local Ethernet segment connected to three different networks
through three different DLCIs:
The following screenshot shows (part of) the dlciTable of the set-up depicted in the figure above:
6.6.3 Automatically obtaining IP addresses in Frame Relay
In case of Frame Relay, the 1424 SHDSL Router can perform an auto-install (refer to 16.3.3 - Auto-install
in case of Frame-Relay on page 1158). This includes obtaining a local IP address of the Frame Relay
DLCI. However, even if no auto-install is performed the 1424 SHDSL Router runs the following sequence
to obtain a local IP address of the Frame Relay DLCI:
If the Frame Relay network supports the InARP (Inverse Address Resolution Protocol) protocol, then the
1424 SHDSL Router can learn the remote IP address of an Frame Relay DLCI.
6.6.4 Configuring IP addresses in Frame Relay
When you use Frame Relay encapsulation on the WAN interface, you can configure the IP related
parameters on two levels:
Using the ip structure in the … Use this structure to configure the IP related parameters of …
frameRelay object. all the DLCIs for which …

• in the dlciTable no IP address is defined for that specific DLCI,
• and the mode element is set to routing or routingAndBridgning.
In other words, use this attribute to globally configure the IP param-

eters of the DLCIs. Refer to Example - DLCI global IP.
dlciTable attribute. one specific DLCI. Refer to Example - DLCI specific IP.
Refer to 5.2.3 - Explaining the ip structure on page 56 for a detailed description of the ip structure.
Example - DLCI global IP
Suppose you have the following set-up:
If you consider Router A, then for this router …

• two DLCIs are configured in the frameRelay/dlciT-
able, being DLCI 16 and DLCI 17,
• no IP addresses are specifically configured for
these DLCIs,
• in the frameRelay/ip attribute a global IP address
is configured for the DLCIs, being 10.0.0.3.
The characteristics of a set-up with a global IP address for the DLCIs are:
• Broadcasts are copied and sent over all DLCIs (that use the global IP address). E.g. pinging
10.0.0.255 results in a reply from 10.0.0.1, 10.0.0.2 and 10.0.0.3.
• Pinging 10.0.0.3 results in a reply when LMI is up.
• Routes learned over one DLCI are not passed to other DLCIs. E.g. a route learned over DLCI 16 is
not passed to DLCI 17. This means that split horizon is applicable.
• RIP only functions if the network is fully meshed. I.e. if every router is directly connected to its neigh-
bour with a DLCI (as in the example above).
Example - DLCI specific IP
Suppose you have the following set-up:
If you consider Router A, then for this router …

• two DLCIs are configured in the frameRelay/dlciTable, being DLCI 16 and DLCI 17,
• an IP address is specifically configured per DLCI in the frameRelay/dlciTable/ip attribute,
• no global IP address is configured for the DLCIs.
The characteristics of a set-up with a specific IP address for each DLCI are:
• Each DLCI is an IP interface.
• Pinging 10.1.0.1 results in a reply when the DLCI is up.
• Routes learned over one DLCI are passed to other DLCIs. E.g. a route learned over DLCI 16 is
passed to DLCI 17. This means that split horizon is not applicable.
6.6.5 Configuring LMI
Refer to 6.6.1 - Introducing Frame Relay on page 146 for an introduction on LMI.
To configure LMI, proceed as follows:
Step Action
1 In the frameRelay object, select the lmi

structure.
2 The most important elements in the lmi structure are:

• mode. Use this element to set the Frame Relay mode (user, network, auto or nni).
• type. Use this element to set the LMI variant. There are several standards for the LMI
protocol with small variations between them. Therefore you should configure the 1424
SHDSL Router according to the standard that is used by your service provider.
Refer to lmi on page 561 for a complete description of the lmi structure.
6.6.6 Configuring CIR and EIR
Refer to 6.6.1 - Introducing Frame Relay on page 146 for an introduction on CIR and EIR.
As said before, CIR is the data rate which the user expects to pass into the Frame Relay network with
few problems. Note that the CIR is unrelated to the actual bit rate of the physical connection. A user could
have a physical connection operating at 2 Mbps, but a CIR across this physical connection of only 64
kbps. This would mean that the user’s average data rate would be 64 kbps, but data bursts up to 2 Mbps
would be possible (EIR).
To configure the CIR and EIR of a Frame Relay DLCI, proceed as follows:
Step Action
1 In the dlciTable, select the frameRelay

structure.
2 In the frameRelay structure, configure the following ele-

ments:
• cir. Use this element to set the Committed Informa-
tion Rate for the DLCI.
The cir is expressed in bps. Enter a multiple of 64000
bps as cir value (e.g. 2048000). The maximum value is the physical connection towards
the Frame Relay network. If the cir value is set to 0 (default), it means the complete
bandwidth may be used (no flow control).
• eir. Use this element to set the Excess Information Rate for the DLCI.
The eir is expressed in bps. Enter a multiple of 64000 bps as eir value (e.g. 2048000).
The maximum value is the physical connection towards the Frame Relay network. If
the eir value is set to 0 (default), it means no excess burst is allowed.
The bursts of data that are allowed are the CIR value + EIR value. I.e. If you want a
CIR of 1 Mbps and you want to allow bursts up to 1.5 Mbps, then set the CIR to
1024000 bps and the EIR to 512000 bps.
Important remarks
• Be careful not to over-dimension the CIR. I.e. do not let the sum of the CIRs of the DLCIs exceed the
bandwidth of the physical connection.
• When you do exceed the total bandwidth of the physical connection, then the 1424 SHDSL Router
first buffers the data. However, when the buffers of the 1424 SHDSL Router are completely filled up,
it has to discard the “excess” data.
• To obtain an optimal QoS for links that contain both voice and data DLCIs, it is advisable to use CIR
for the voice DLCIs and EIR for the data DLCIs. This decreases the amount of data packets that are
queued in a single burst, thereby reducing the transmission delay for voice packets.
Examples
Suppose you have a 2

Mbps physical connection
towards the Frame Relay
service provider and you
define 2 DLCIs:
• Suppose you assign to both DLCIs a CIR of 1 Mbps and an EIR of 0.
⇒In that case you have per DLCI a guaranteed bandwidth of 1 Mbps and no bursts are allowed.
• Suppose you assign to both DLCIs a CIR of 512 kbps and an EIR of 512 kbps.
⇒In that case you have per DLCI a guaranteed bandwidth of 512 kbps and you allow bursts up to 1
Mbps. This means that if on both DLCIs a burst up to 1 Mbps occurs at the same time, the speed
of the physical connection (2 Mbps) is still not exceeded (so no data is discarded). If however
somewhere else on the network a congestion occurs, it is possible that some of the “excess” data
is discarded (refer to What is DE? on page 148).
• Suppose you assign to both DLCIs a CIR of 1 Mbps and an EIR of 1 Mbps.
⇒In that case you have per DLCI a guaranteed bandwidth of 1 Mbps and you allow bursts up to 2
Mbps. Obviously, this means that if on both DLCIs a burst up to 2 Mbps occurs at the same time,
the speed of the physical connection (2 Mbps) is exceeded and some data is discarded. In that
case the principle of first come, first served is applied. I.e. the DLCI on which the burst occurred
first its data is passed on to the Frame Relay network. If however somewhere else on the network
a congestion occurs, it is still possible that some of the “excess” data is discarded.
• Suppose you assign to both DLCIs a CIR of 2 Mbps and an EIR of 0.
⇒In that case you over-dimensioned your CIR. You can not guarantee 2 Mbps of bandwidth for both
DLCIs, due to the bandwidth limit of 2 Mbps on the physical connection. Also in this case the prin-
ciple of first come, first served is applied. I.e. the DLCI which sends data first gets its data onto the
Frame Relay network.
6.6.7 Enabling Frame Relay fragmentation
Refer to 6.6.1 - Introducing Frame Relay on page 146 for an introduction on Frame Relay fragmentation.
There are different cases of fragmentation. How to enable fragmentation in each of these cases is shown
in the following table:
Case How to enable fragmentation?
1 Interface fragmentation on one interface
To enable Frame Relay fragmen-

tation on interface level and this
for one particular interface, pro-
ceed as follows:
1. Select the frameRelay object.
2. Select the fragmentation struc-
ture.
3. Set the interfaceFormat element to enabled.
2 End-to-end fragmentation on one interface
To enable Frame Relay frag-

mentation on end-to-end level
and this for one particular DLCI
on one particular interface, pro-
ceed as follows:
1. Select the frameRelay object.
2. Select the dlciTable.
3. Select the frameRelay struc-
ture.
4. Select the fragmentation struc-
ture.
5. Set the endToEndFormat element to enabled.
6.7 Configuring PPP encapsulation
This section introduces the PPP encapsulation protocol and gives a short description of the attributes
you can use to configure this encapsulation protocol.
• 6.7.1 - Introducing PPP on page 161
• 6.7.2 - Automatically obtaining IP addresses in PPP on page 165
• 6.7.3 - Configuring IP addresses in PPP on page 167
• 6.7.4 - Imposing IP addresses on the remote in PPP on page 168
• 6.7.5 - Configuring link monitoring on page 169
• 6.7.6 - Configuring PAP on page 170
• 6.7.7 - How does PAP work? on page 171
• 6.7.8 - Configuring CHAP on page 173
• 6.7.9 - How does CHAP work? on page 174
• 6.7.10 - Use which name and secret attributes for PPP authentication? on page 176
• 6.7.11 - Setting up multilink PPP on page 177
• 6.7.12 - Enabling PPP fragmentation on page 182
• 6.7.13 - Setting up multiclass PPP on page 183
6.7.1 Introducing PPP
What is PPP?
The Point-to-Point Protocol (PPP) originally emerged as an encapsulation protocol for transporting IP
traffic over point-to-point links. PPP also established a standard for assigning and managing IP
addresses, asynchronous and bit-oriented synchronous encapsulation, network protocol multiplexing,
link configuration, link quality testing, error detection, and option negotiation for added networking capa-
bilities.
Also refer to What is PPPoA (RFC 2364)? on page 108.
What is LCP, IPCP, BCP and CCP?
PPP provides a method for transmitting datagrams over serial point-to-point links, which include the fol-
lowing components:
• A method for encapsulating datagrams over serial links.
• An extensible Link Control Protocol (LCP) which provides a method of establishing, configuring,
maintaining, and terminating the point-to-point connection.
• A family of Network Control Protocols (NCPs) for establishing and configuring different network layer
protocols such as the IP Control Protocol (IPCP) and the Bridge Control Protocol (BCP).
• A Compression Control Protocol (CCP) for configuring, enabling and disabling data compression
algorithms on both ends of the point-to-point link.
The PPP handshake
PPP makes a handshake in two phases:
Phase Description
1 The Link Control Protocol (LCP) builds the link layer.
2 The Network Control Protocol (NCP, i.e. IPCP or BCP) builds the network layer.
What is PPP link monitoring?
PPP features link monitoring in order to check whether the PPP link is truly up or down. If link monitoring
is enabled, then echo request packets are sent over the link at regular intervals. If on consecutive
requests no reply is given, then the PPP link is declared down. Data traffic is stopped until the PPP hand-
shake succeeds again.
What is PAP?
The Password Authentication Protocol (PAP) is the most basic form of authentication (complies with RF
1334). It basically works the same way as a normal login procedure. The peer (the authenticating sys-
tem) authenticates itself by sending a username and password to the authenticator. The authenticator
compares this username and password to its secrets database. If the password matches, the peer is
authenticated and the session can be set up. PAP authentication can be performed in one direction or
in both directions.
The disadvantage of PAP is that it is vulnerable to eavesdroppers who may try to obtain the password
by listening in on the serial line, and to repeated trial and error attacks.
What is CHAP?
The Challenge Handshake Authentication Protocol (CHAP) is more secure than PAP.
With CHAP, the server (the authenticator) sends a randomly generated “challenge” string to the client
(the authenticating system). The client hashes the challenge string, its username and password using
the MD5 algorithm. This result is returned to the server. The server now performs the same computation
and compares this username and password to its secrets database. If the passwords match, the client
is authenticated and the session can be set up. CHAP authentication can be performed in one direction
or in both directions.
Another feature of CHAP is that it does not only requires the client to authenticate itself at start-up time,
but to do so at regular intervals. This to make sure the client has not been replaced by an intruder (for
instance by just switching lines).
What is MS-CHAP?
The Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) is the Microsoft version of
CHAP and is an extension to RFC 1994. Like the standard version of CHAP, MS-CHAP is used for PPP
authentication. In this case, authentication occurs between a PC using Microsoft Windows and a router
or access server acting as a network access server (NAS).
The differences between the standard CHAP and MS-CHAP are:
• MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP option 3, Authentication Protocol.
• The MS-CHAP Response packet is in a format designed to be compatible with Microsoft Windows.
This format does not require the authenticator to store a clear or reversibly encrypted password.
• MS-CHAP provides an authenticator-controlled authentication retry mechanism.
• MS-CHAP provides an authenticator-controlled change password mechanism.
• MS-CHAP defines a set a "reason for failure" codes returned in the Failure packet message field.
What is MS-CHAP v2?
MS-CHAP version 2 provides stronger security for remote access connections and also solves some
issues of MS-CHAP version 1:
MS-CHAP version 1 issue MS-CHAP version 2 solution
LAN Manager encoding of the response used for MS-CHAP v2 no longer allows LAN Manager
backward compatibility with older Microsoft encoded responses.
remote access clients is cryptographically weak.
LAN Manager encoding of password changes is MS-CHAP v2 no longer allows LAN Manager
cryptographically weak. encoded password changes.
Only one-way authentication is possible. The MS-CHAP v2 provides two-way authentication,

remote access client cannot verify that it is dialling also known as mutual authentication. The remote
in to its organisation's remote access server or a access client receives verification that the remote
masquerading remote access server. access server that it is dialling in to has access to
the user's password.
With 40-bit encryption, the cryptographic key is With MS-CHAP v2, the cryptographic key is
based on the user's password. Each time the user always based on the user's password and an arbi-
connects with the same password, the same cryp- trary challenge string. Each time the user con-
tographic key is generated. nects with the same password, a different
cryptographic key is used.
A single cryptographic key is used for data sent in With MS-CHAP v2, separate cryptographic keys
both directions on the connection. are generated for transmitted and received data.
What is MLPPP?
Multilink PPP (MLPPP) is a method of splitting, recombining, and sequencing datagrams across multiple
logical data links.
For all its strengths, PPP has one inherent limitation when it comes to network deployment: it is designed
to handle only one physical link at a time. MLPPP does away with this restriction. MLPPP is a higher-
level data link protocol that sits between PPP and the network protocol layer. It accommodates one or
more PPP links, with each PPP link representing either a separate physical WAN connection or a chan-
nel in a multi-channel switched service. MLPPP its ability to combine multiple lower-speed links into a
single, higher-speed data path is often referred to as WAN-independent or packet-based inverse multi-
plexing.
MLPPP negotiates configuration options the same way as conventional PPP. However, during the nego-
tiation process, one router or access device indicates to the other communicating device that it is willing
to combine multiple connections and treat them as a single physical pipe. It does this by sending along
a multilink option message as part of its initial LCP option negotiation.
Once a multilink session is successfully opened, MLPPP at the sending side receives network protocol
data units (PDUs) from higher-layer protocols or applications. It then fragments those PDUs into smaller
packets, adds an MLPPP header to each fragment and sends them over the available PPP links. On the
receiving end, the MLPPP software takes the fragmented packets from the different links, puts them in
their correct order based on their MLPPP headers and reconverts them to their original network-layer
PDUs.
What is PPP fragmentation?
In case of MLPPP you can enable packet fragmentation. When packet fragmentation is not enabled,
packets are sent whole across the channels. When packet fragmentation is enabled, larger packets are
divided into smaller fragments and distributed over all the channels in use. Sending the packets in this
way reduces transit times. The receiver collects the fragments, reassembles them, and delivers them in
the original intended order.
What is multiclass PPP?
Multiclass PPP recovers some unused bits in the PPP multilink header to allow separate streams within
a single PPP session. This allows for Frame Relay like features within this PPP session. It also facilitates
QoS over a single PPP link. However, the number of sessions possible is small compared to Frame
Relay.
What is BAP?
The Bandwidth Allocation Protocol (BAP) can be used to manage the number of links in a multi-link bun-
dle. BAP defines datagrams to coordinate adding and removing individual links in a multi-link bundle, as
well as specifying which peer is responsible for various decisions regarding managing bandwidth during
a multi-link connection. The Bandwidth Allocation Control Protocol (BACP) is the associated control pro-
tocol for BAP. BACP defines control parameters for the BAP protocol to use.
6.7.2 Automatically obtaining IP addresses in PPP
In case of PPP, the 1424 SHDSL Router can learn the local IP address of a PPP link.
In case of PPP, the 1424 SHDSL Router can learn the remote IP address of a PPP link.
6.7.3 Configuring IP addresses in PPP
To configure IP addresses on a PPP(oA) link, proceed as follows:
Step Action
1 In case you set up a …

• PPPoA link on the WAN interface, then you actually configure the IP addresses on
ATM PVC level. So in that case, you have to configure the IP related parameters the
ip structure of the pvcTable.
PPPoA link on WAN
In the atm object, select the pvcTable and then select

the ip structure.
PPP link on a LAN interface
In the lanInterface/pppoEClient object, select

the ip structure.
2 In the ip structure, configure the following elements:

• address. Use this element to assign an IP address to the local end of the PPP(oA) link.
• netMask. Use this element to assign an IP subnet mask to the local end of the PPP(oA)
link.
• remote. Use this element to assign an IP address to the remote end of the PPP(oA)
link.
• unnumbered. In case you do not explicitly configure a local IP address for an PPP(oA)
link, then you can use this element to "borrow" the IP address of another interface for
which an IP address is already configured.
• acceptLocAddr. Use this element to determine whether to accept or reject the local IP
address being imposed by the remote side.
• acceptRemAddr. Use this element to determine whether to accept or reject the remote
IP address being imposed by the remote side.
Refer to 5.2.3 - Explaining the ip structure on page 56 for a complete description of the ip
structure.
6.7.4 Imposing IP addresses on the remote in PPP
As can be seen in 6.7.2 - Automatically obtaining IP addresses in PPP on page 165, in case of PPP the
1424 SHDSL Router can learn IP addresses from the remote side. What is more, in case of PPP the
1424 SHDSL Router itself can impose IP addresses on the remote.
To impose IP addresses on the remote, proceed as follows:
Step Action
1 On the 1424 SHDSL Router, configure a local and remote IP address on the PPP link.
Refer to 6.7.3 - Configuring IP addresses in PPP on page 167.
2 On the remote device (e.g. a 1031 Router), configure nor a local nor a remote address
on the PPP link.
⇒Once the PPP handshake reaches the IPCP stage, the 1031 Router will declare to
the 1424 SHDSL Router that it has no IP addresses on its PPP link. The 1424
SHDSL Router on its turn will impose the local and remote IP address of the PPP
link on the 1031 Router.
⇒What is more, the 1031 Router adds a route towards the 1424 SHDSL Router. Also
see the explanation of the element gatewayPreference on page 59.
Note that the IP configuration attributes acceptLocAddr and acceptRemAddr on the

1031 Router have to be set to enabled. Else the 1031 Router will not accept the IP
addresses imposed by the 1424 SHDSL Router.
Example - imposing IP addresses on the remote in PPP

6.7.5 Configuring link monitoring
Refer to 6.7.1 - Introducing PPP on page 161 for an introduction on link monitoring.
To configure link monitoring on a PPP(oA) link, proceed as follows:
Step Action
1 PPPoA link on WAN
In the atm object, select the pvcTable and then

select the linkMonitoring structure.
PPP link on a LAN interface
In the lanInterface/pppoEClient object,

select the linkMonitoring structure.
2 The linkMonitoring structure contains the following elements:

• operation. Use this element to enable or disable link monitoring.
• interval. Use this element to set the time interval between two consecutive echo
requests.
• replyTimeOut. Use this element to set the time the 1424 SHDSL Router waits for a reply
on the echo request.
• failsPermitted. Use this element to set the number of echo requests that may fail before
the 1424 SHDSL Router declares the PPP link down.
Refer to linkMonitoring on page 568 for a complete description of the linkMonitoring structure.
6.7.6 Configuring PAP
Refer to 6.7.1 - Introducing PPP on page 161 for an introduction on PAP.

To configure PAP on a PPP(oA) link, proceed as follows:
Step Action
1 On the authenticating router, configure the PPP attributes authentication and authenPeriod.
• authentication. Use this attribute to set the PPP authentication to PAP.
• authenPeriod. Use this attribute to determine the interval at which the PPP link is
authenticated once it has been set up.
Refer to 11.5.4 - PPP configuration attributes on page 566 for a detailed description of
the ppp attributes.
2 On the peer router, configure the following attributes:

• sysName. Use this attribute to set the name of the peer. This is used in the authentica-
tion process. Alternatively, you can use the sessionName attribute. Refer to 6.7.10 - Use
which name and secret attributes for PPP authentication? on page 176 for more infor-
mation on what to use.
• sysSecret. Use this attribute to set the secret of the peer. This is used in the authenti-
cation process. Alternatively, you can use the sessionSecret attribute. Refer to 6.7.10 -
Use which name and secret attributes for PPP authentication? on page 176 for more
information on what to use.
3 Again on the authenticating router, go to the router object and configure the pppSecretTable.
In this table, enter the name and secret you configured on the peer in step 2. These are
used in the authentication process.
How exactly all these configuration attributes are used in the authentication process is explained in the
6.7.7 - How does PAP work? on page 171.
6.7.7 How does PAP work?
Refer to 6.7.1 - Introducing PPP on page 161 for an introduction on PAP.
PAP authentication in one direction
The router authenticates after building its LCP layer and prior to building the IPCP layer. If the authenti-
cation succeeds, then the PPP link is built further until data can be sent. Else PPP starts its handshake
again.
Consider the following example: router A (the 1424 SHDSL Router) is the authenticator and router B is
the peer. Router A is configured for PAP authentication and router B is not. The authentication process
goes as follows:
Phase Description
1 Router B wants to establish a PPP link with router A (the 1424 SHDSL Router).
2 Router A asks router B to authenticate himself.
3 Router B sends its name1 and its secret2 to router A.
4 Router A looks up the name of router B in its pppSecretTable to find a corresponding secret.
If the secret found in the pppSecretTable matches the secret received from router B, then
the authentication succeeded and a PPP link is established. Else the authentication failed
and no PPP link is established.
1. Depending on how router B is configured, this can be its sysName or sessionName.

2. Depending on how router B is configured, this can be its sysSecret or sessionSecret.
The following figure shows the PAP authentication process:

PAP authentication in both directions
If PAP authentication is enabled on both routers, then they both request and respond to the authentica-
tion. If the remote router is a router from another vendor, then read the documentation in order to find
out how to configure the PAP name and secret values.
6.7.8 Configuring CHAP
Refer to 6.7.1 - Introducing PPP on page 161 for an introduction on CHAP.

To configure CHAP on a PPP(oA) link, proceed as follows:
Step Action
1 On the authenticating router, configure the PPP attributes authentication and authenPeriod.
• authentication. Use this element to set the PPP authentication to CHAP (or MS-CHAP
or MS-CHAP v2).
• authenPeriod. Use this attribute to determine the interval at which the PPP link is
authenticated once it has been set up.
Refer to 11.5.4 - PPP configuration attributes on page 566 for a detailed description of
the ppp attributes.
2 On the peer router, configure the following attributes:

• sysName. Use this attribute to set the name of the peer. This is used in the authentica-
tion process. Alternatively, you can use the sessionName attribute. Refer to 6.7.10 - Use
which name and secret attributes for PPP authentication? on page 176 for more infor-
mation on what to use.
• sysSecret. Use this attribute to set the secret of the peer. This is used in the authenti-
cation process. Alternatively, you can use the sessionSecret attribute. Refer to 6.7.10 -
Use which name and secret attributes for PPP authentication? on page 176 for more
information on what to use.
3 Again on the authenticating router, go to the router object and configure the pppSecretTable.
In this table, enter the name and secret you configured on the peer in step 2. These are
used in the authentication process.
How exactly all these configuration attributes are used in the authentication process is explained in the
6.7.9 - How does CHAP work? on page 174.
6.7.9 How does CHAP work?
Refer to 6.7.1 - Introducing PPP on page 161 for an introduction on CHAP.
CHAP authentication in one direction
The router authenticates after building its LCP layer and prior to building the IPCP layer. If the authenti-
cation succeeds, then the PPP link is built further until data can be sent. Else PPP starts its handshake
again.
Consider the following example: router A (the 1424 SHDSL Router) is the authenticator and router B is
the peer. Router A is configured for CHAP authentication and router B is not. The authentication process
goes as follows:
Phase Description
1 Router B wants to establish a PPP link with router A (the 1424 SHDSL Router).
2 Router A asks router B to authenticate himself. So router A sends a challenge packet

containing a random value to router B.
The challenge packet also contains the sysName of router A. If the peer (router B)
is also a OneAccess Router, then it does nothing with it. Other vendors, however,
may use this sysName to determine which secret to use in the authentication proc-
ess. Check the vendor’s documentation.
3 Router B feeds the random value and its secret1 into the MD5 hash generator, resulting
in a hash value.
4 Router B sends a response packet containing the hash value and its name2.
5 Router A looks up the name of router B in its pppSecretTable to find a corresponding secret.
This secret found in the pppSecretTable and the random value router A sent in step 2 is fed
into the MD5 hash generator, resulting in a hash value. If this hash value equals the hash
value received from router B, then the authentication succeeded and a PPP link is estab-
lished. Else the authentication failed and no PPP link is established.
1. Depending on how router B is configured, this can be its sysSecret or sessionSecret.

2. Depending on how router B is configured, this can be its sysName or sessionName.
The following figure shows the authentication process:
CHAP authentication in both directions
If CHAP authentication is enabled on both routers, then they both request and respond to the authenti-
cation. If the remote router is a router from another vendor, then read the documentation in order to find
out how to configure the CHAP name and secret values.
6.7.10 Use which name and secret attributes for PPP authentication?
Older firmware versions only used the sysName and the router/sysSecret attributes in their PPP authentica-
tion process. Newer firmware versions, however, have two new attributes for PPP authentication pur-
poses being: ppp/sessionName and ppp/sessionSecret. This enhancement allows you to define different
names and secrets for each PPP link (whereas before all PPP links used the same sysName and sysSecret
attribute).
So suppose you have several ATM PVCs on which you all run PPPoA, you can use a different name
and secret for each PPPoA link by configuring per PVC the sessionName and sessionSecret in the ppp struc-
ture of the atm/pvcTable attribute.
Refer to …
• sysName on page 504
• sysSecret on page 625
• sessionName on page 570
• sessionSecret on page 570
• pppoEClient on page 525
Important remarks
• If on a PPP link authentication is enabled and the sessionName/sessionSecret attributes are not filled in,
then the sysName/sysSecret attributes are used in the PPP authentication process for that link.
• If on a PPP link authentication is enabled and the sessionName/sessionSecret attributes are filled in, then
the sysName/sysSecret attributes are ignored and are not used in the PPP authentication process for
that link.
• If you have several PPP links and you use a different name and secret for each link (using the ses-
sionName/sessionSecret attributes), then do not forget to add all these names and secrets in the
pppSecretTable of the authenticator.
• The sysName/sysSecret attributes do not serve as “back-up” for the sessionName/sessionSecret attributes.
This means that if for some reason authentication using the sessionName/sessionSecret attributes fails
(e.g. because the secrets do not match), then the authenticator does not restart the authentication
process using the sysName/sysSecret attributes instead.
• If you have several PPP links, it is allowed to use a specific name and secret on some of them (using
the sessionName/sessionSecret attributes) and use a general name and secret for the rest (using the
sysName/sysSecret attributes). In that case, make sure that for the latter the sessionName/sessionSecret
attributes are not configured (i.e. their value fields are empty).
6.7.11 Setting up multilink PPP
MLPPP means running a PPP bundle over several physical interfaces. In case you only have one phys-
ical interface towards the WAN, setting up MLPPP seems a bit awkward. However, if you want to enable
PPP fragmentation or set up multiclass PPP links, then you have to set up a PPP bundle even if it means
setting up a bundle on just one physical interface. This because PPP fragmentation and multiclass PPP
are part of the MLPPP feature set.
Note that you can also set up MLPPP for a PPPoA link.
Setting up MLPPP on the SHDSL line
To set up MLPPP on a PPP link, proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to the

wanInterface object and set the encapsulation attribute to ppp.
2 In the 1424 SHDSL Router containment tree, go

to the wanInterface/ppp object and set …
• the mode attribute to multiLink.
• the operation element in the linkMonitoring struc-
ture to enabled. This allows that when a mem-
ber (i.e. a PPP link) of the PPP bundle goes
down, the PPP bundle falls back to a lower
speed and vice versa.
3 Create a PPP bundle.

In the 1424 SHDSL Router containment tree, go to the
bundle object and add a pppBundle[ ] object underneath (refer to 4.4 - Adding an object to
the containment tree on page 45).
E.g. pppBundle[myPppBundle]
4 Configure the attributes of the pppBundle[ ] object you just added. The most important
attributes are:
• members. Use this attribute to make the WAN interface a member of
the PPP bundle. Do this by adding one entry to the members table
and by typing “wan” as value of the interface element.
• ip. Use this attribute to configure the IP related parameters of the
PPP bundle.
• mode. Use this attribute to determine whether the packets are treated by the routing
process, the bridging process or both.
Refer to 11.8.1 - PPP bundle configuration attributes on page 611 for more information
on the configuration attributes of the PPP bundle.
Setting up MLPPP on a PPPoA link
To set up MLPPP on a PPPoA link, proceed as follows:
Step Action
1 Set up a PPPoA link. Refer to 6.2.13 - Configuring PPP over ATM (PPPoA) on page 123.
Note that it is important to set the operation element in the linkMonitoring structure to
enabled. This allows that when a member (i.e. a PPP link) of the PPP bundle goes
down, the PPP bundle falls back to a lower speed and vice versa.

attributes are:
• members. Use this attribute to make an ATM PVC (running PPPoA)
a member of the PPP bundle. Do this by adding an entry to the mem-
bers table and by typing the name of the ATM PVC as value of the
interface element.
• ip. Use this attribute to configure the IP related parameters of the PPP bundle.
Setting up MLPPP on an E1 interface
To set up MLPPP on an E1 interface, proceed as follows:
Step Action
1 For each E1 channel (g703[x]/

channel[x]) that has to be a part
of the MLPPP bundle, config-
ure the following attributes:
• encapsulation. To be able to
run MLPPP, the encapsula-
tion attribute has to be set
to ppp.
• timeSlots. Use this attribute to enable (on) or disable (off) the individual 64 kbps time
slots in the framed data stream.
2 In the ppp object of each E1 channel

(g703[x]/channel[x]/ppp) that has to be a part
of the MLPPP bundle, configure the fol-
lowing attributes:
• mode. To be able to run MLPPP, the
mode attribute has to be set to multiLink.
• linkMonitoring. To allow that when a
member (i.e. a PPP link) of the PPP
bundle goes down, the PPP bundle falls back to a lower speed and vice versa, set the
operation element in the linkMonitoring structure to enabled.

bundle object and add an pppBundle[ ] object underneath (refer to 4.4 - Adding an object to
attributes are:
• members. Use this attribute to determine which E1 interfaces (more
particularly, which E1 channels) are member of the PPP bundle. So
you have to add an entry to the members table for every E1 channel
that you want to include in the PPP bundle. Then type the index
name of the E1 channel as value of the interface element.
• ip. Use this attribute to configure the IP related parameters of the
PPP bundle.
Setting up MLPPP on an RS530 interface
To set up MLPPP on an RS530 interface, proceed as follows:
Step Action

rs530 object and configure the following attributes:
• encapsulation. To be able to run MLPPP, the encapsulation
attribute has to be set to ppp.
• timeSlots. Use this attribute to enable (on) or disable (off)
the individual 64 kbps time slots in the framed data
stream.

to the rs530/ppp object and configure the following
attributes
• mode. To be able to run MLPPP, the mode
attribute has to be set to multiLink.
• linkMonitoring. To allow that when a member
(i.e. a PPP link) of the PPP bundle goes
speed and vice versa, set the operation ele-
ment in the linkMonitoring structure to enabled.

bundle object and add an pppBundle[ ] object underneath (refer to 4.4 - Adding an object to
attributes are:
• members. Use this attribute to make the RS530 interface a member
of the PPP bundle. Do this by adding one entry to the members table
and by typing the name of the RS530 interface as value of the inter-
face element. By default, the name is “wan”.
Setting up MLPPP on a BRI interface in leased line mode
To set up MLPPP on a BRI interface in leased line mode, proceed as follows:
Step Action
1 Configure the ISDN interface in leased line mode. Refer to .
2 In the 1424 SHDSL Router containment tree, go to the leasedLine[ ] object and set the
encapsulation attribute to ppp.

to the leasedLine[ ]/ppp object and set …
• the mode attribute to multiLink.
• the operation element in the linkMonitoring struc-
ture to enabled. This allows that when a mem-
ber (i.e. a PPP link) of the PPP bundle goes
speed and vice versa.

attributes are:
• members. Use this attribute to make the BRI interface in leased line
mode a part of the PPP bundle. Do this by adding one or more
entries to the members table and by typing the index name of the
leasedLine[ ] object as value of the interface element.
6.7.12 Enabling PPP fragmentation
Setting up multilink PPP (MLPPP) allows you to enable PPP fragmentation. Refer to 6.7.1 - Introducing
PPP on page 161 for an introduction on PPP fragmentation.
Important remark
Note that PPP fragmentation is actually a part of the MLPPP feature set. So in case you want to enable
PPP fragmentation, you actually have to set up a PPP bundle. Even if you want to enable PPP fragmen-
tation on just one interface!
To enable PPP fragmentation, proceed as follows:
Step Action
1 Set up MLPPP as described in 6.7.11 - Setting up multilink PPP on page 177.

Note that if you want to enable PPP fragmentation on just one interface, you have to cre-
ate a PPP bundle with just one member.
2 In the pppBundle[ ] object you created in step 1, set the fragmentation attribute to enabled.
6.7.13 Setting up multiclass PPP
Setting up multilink PPP (MLPPP) allows you to set up multiclass PPP. Refer to 6.7.1 - Introducing PPP
on page 161 for an introduction on multiclass PPP.
Important remark
Note that multiclass PPP is actually a part of the MLPPP feature set. So in case you want to set up mul-
ticlass PPP, you actually have to set up a PPP bundle. Even if you want to enable multiclass PPP on
just one interface!
To set up multiclass PPP, proceed as follows:
Step Action
1 Set up MLPPP as described in 6.7.11 - Setting up multilink PPP on page 177.

Note that if you want to set up multiclass PPP on just one interface, you have to create a
PPP bundle with just one member.
2 In the pppBundle[ ] object you created in step 1, select the multiclassInterfaces attribute and
add one or more entries to this table.
Use this attribute to set up multiclass PPP links. Add a row to the multiclassInterfaces table
for each multiclass PPP link you want to create.
Step Action
3 Configure the elements of the multiclass PPP link you just created. These elements are:
• name. Use this element to assign an administrative name to the multiclass PPP link.
• adminStatus. Use this element to activate (up) or deactivate (down) the multiclass PPP
link.
• mode. Use this element to determine whether, for the corresponding multiclass PPP
link, the packets are treated by the routing process, the bridging process or the switch-
ing process.
• ip. Use this element to configure the IP related parameters of the multiclass PPP link.
Refer to 5.2.3 - Explaining the ip structure on page 56 for more information.
• bridging. Use this element to configure the bridging related parameters of the multiclass
PPP link in case the link is in bridging mode (i.e. in case the mode element is set to
bridging). Refer to 8.2.6 - Explaining the bridging structure on page 318 for more infor-
mation.
• multiclass. Use this element to configure the multiclass specific parameters of the mul-
ticlass PPP link. The multiclass element contains the following sub-elements:
- multiclass. Use this element to set a multiclass identifier for the multiclass PPP link.
- defaultQueue. Use this element to select a default queue. This allows you to easily
set up a traffic policy without having to create and apply traffic policy profiles. How-
ever, you still have to create and apply a priority policy profile to empty the queues.
Refer to 7.11.11 - The default queue attribute versus a traffic policy profile on
page 286 for more information.
Refer to multiclassInterfaces on page 613 for a detailed description of the multiclassInterfaces

table.
User manual Configuring routing
7 Configuring routing
Depending on the device, some features may or may not be present. Refer to the detailed features over-
view.
This chapter introduces routing on the 1424 SHDSL Router and lists the attributes you can use to con-
figure routing. It also introduces the most important features of the router besides routing and lists the
attributes you can use to configure these features.
• 7.1 - Introducing routing on page 186
• 7.2 - Enabling routing on an interface on page 187
• 7.3 - Configuring static routes on page 188
• 7.4 - Configuring policy based routing on page 197
• 7.5 - Configuring RIP on page 204
• 7.6 - Configuring OSPF on page 212
• 7.7 - Configuring BGP on page 221
• 7.8 - Configuring address translation on page 225
• 7.9 - Configuring VRRP on page 247
• 7.11 - Applying QoS on routed traffic on page 259
Router.
7.1 Introducing routing
What is routing?
Routing is the act of moving information across an internetwork from a source to a destination.
Routing versus bridging
Routing is often contrasted with bridging. At first sight, bridging might seem to do the same as routing.
The primary difference between the two is that bridging occurs at layer 2 (the link layer) of the OSI ref-
erence model, whereas routing occurs at Layer 3 (the network layer). In other words, bridging occurs at
a lower level and is therefore more of a hardware function whereas routing occurs at a higher level where
the software component is more important. And because routing occurs at a higher level, it can perform
more complex analysis to determine the optimal path for the packet.
Basic routing activities
Routing involves two basic activities:

• determining optimal routing paths,
• transporting information groups (typically called packets).
Determining the optimal routing path
In order to determine a routing path, routers initialise and maintain routing tables. These routing tables
contain a variety of information. For example:
• Destination/next hop associations tell a router that a particular destination can be reached optimally
by sending the packet to a particular router representing the "next hop" on the way to the final desti-
nation. When a router receives an incoming packet, it checks the destination address and attempts
to associate this address with a next hop.
• Desirability of a path. Routers use metrics to evaluate what path will be the best for a packet to travel.
Routers communicate with one another and maintain their routing tables through the transmission of a
variety of messages. The routing update message is one such message that generally consists of all or
a portion of a routing table. By analysing routing updates from all other routers, a router can build a
detailed picture of network topology.
Transporting packets
In most cases, a host determines that it must send a packet to another host. Having acquired a router's
address by some means, the source host sends a packet addressed specifically to a router's physical
(i.e. Media Access Control or MAC) address, this time with the protocol (i.e. network) address of the des-
tination host.
As it examines the packet's destination protocol address, the router determines that it either knows or
does not know how to forward the packet to the next hop. If the router does not know how to forward the
packet, it typically drops the packet. If the router knows how to forward the packet, however, it changes
the destination physical address to that of the next hop and transmits the packet.
The next hop may be the ultimate destination host. If not, the next hop is usually another router, which
executes the same switching decision process. As the packet moves through the internetwork, its phys-
ical address changes, but its protocol address remains constant.
7.2 Enabling routing on an interface
Refer to 7.1 - Introducing routing on page 186 for an introduction.

Per IP interface you can determine whether you perform routing, bridging or both. The following table
shows, for each IP interface, how to enable routing on this interface:
Interface How to enable routing?
LAN interface Set the mode attribute to routing or routingAndBridging. The mode attribute can be found
in the lanInterface object: mode.
Important remark
• If you set the configuration attribute mode to bridging, then the settings of the con-
figuration attribute ip are ignored. As a result, if you want to manage the 1424
SHDSL Router via IP, you have to configure an IP address in the bridgeGroup
object instead: ip.
VLAN on the Set the mode element to routing or routingAndBridging. The mode element can be found
LAN interface in the vlan table which is located in the lanInterface object: vlan/mode.
ATM PVC Set the mode element to routing or routingAndBridging. The mode element can be found
in the pvcTable table which is located in the atm object: pvcTable/mode.
PPP link Set the mode element to routing or routingAndBridging. Refer to the PPP configuration
attributes.
Frame Relay Set the mode element to routing or routingAndBridging. The mode element can be found
PVC in the dlciTable table which is located in the frameRelay object: dlciTable/mode.
EFM Set the mode attribute to routing or routingAndBridging. Refer to the EFM configuration
attributes.
L2TP tunnel Set the mode element to routing or routingAndBridging. The mode element can be found
in the l2tpTunnels table which is located in the tunnels object: l2tpTunnels/mode.
IPSEC L2TP Set the mode element to routing or routingAndBridging. The mode element can be found
tunnel in the ipsecL2tpTunnels table which is located in the tunnels object: ipsecL2tpTunnels/
mode.
7.3 Configuring static routes
This section introduces static routing and gives a short description of the attributes you can use to con-
figure static routing.
• 7.3.1 - Introducing static routing on page 189
• 7.3.2 - Configuring a default route on page 190
• 7.3.3 - Configuring the routing table on page 191
• 7.3.4 - Configuring the routing table - rules of thumb on page 194
• 7.3.5 - The rerouting principle on page 196
7.3.1 Introducing static routing
Static versus dynamic routing
The following table states the differences between static and dynamic routing:
Routing algo- Description

rithm
static Static routing algorithms are hardly algorithms at all, but are table mappings estab-
lished by the network administrator before the beginning of routing. These map-
pings do not change unless the network administrator alters them. Static routing
algorithms work well in environments where network traffic is relatively predictable
and where network design is relatively simple.
dynamic Because static routing systems cannot react to network changes, they generally
are considered unsuitable for today's large, constantly changing networks. Most of
the dominant routing algorithms today are dynamic routing algorithms, which
adjust to changing network circumstances by analysing incoming routing update
messages. If the message indicates that a network change has occurred, the rout-
ing software recalculates routes and sends out new routing update messages.
These messages permeate the network, stimulating routers to rerun their algo-
rithms and change their routing tables accordingly.
Also refer to …
• 7.5.1 - Introducing RIP on page 205.
• 7.6.1 - Introducing OSPF on page 213.
static and Dynamic routing algorithms can be supplemented with static routes where appro-
dynamic priate. A router of last resort (a router to which all unroutable packets are sent), for
example, can be designated to act as a repository for all unroutable packets,
ensuring that all messages are at least handled in some way.
What is a default route?
A default route is a route (also called gateway) that is used to direct packets addressed to networks not
explicitly listed in the routing table. A default route is also typically used when only one specific remote
network has to be reached.
What is a routing table?
The routing table is composed of a set of routes that are known to the router. It includes a list of known
addresses, as well as information to get a packet one router closer to its final destination. Routing tables
can be static (with routes manually entered by the network administrator) or dynamic (where routers
communicate to exchange connection and route information using e.g. RIP).
7.3.2 Configuring a default route
Refer to 7.3.1 - Introducing static routing on page 189 for an introduction on the default route.
To configure a default route, proceed as follows:
Step Action
1 In the 1424 SHDSL Router contain-

ment tree, go to the router object and
select the defaultRoute attribute.
2 Configure the elements in the defaultRoute structure. The most important elements are:
• gateway. Use this element to specify the IP address of the next router that will route all
packets for which no specific (static or dynamic) route exists in the routing table.
• interface. Use this element to specify the interface through which the gateway can be
reached. Do this by typing the name of the interface as you assigned it using the con-
figuration attribute name (e.g. name). Note that this interface can also be a DLCI, PVC,
tunnel, etc.
Refer to defaultRoute on page 618 for more information on.
Example - configuring a default route
Suppose network 1 is connected over a network of an operator to network 2. Network 1 only needs to
reach network 2. So for the router in network 1 it suffices to configure a default route towards network 2.
Configure the defaultRoute attribute of Router A as follows:

7.3.3 Configuring the routing table
Refer to 7.3.1 - Introducing static routing on page 189 for an introduction on the routing table.
To configure the routing table, proceed as follows:
Step Action
1 In the 1424 SHDSL Router contain-

ment tree, go to the router object and
select the routingTable attribute.
2 Configure the elements in the routingTable:

• network. Use this element to specify the IP address of the destination network.
• mask. Use this element to specify the network mask of the destination network.
• gateway. Use this element to specify the IP address of the next router on the path to
the destination network.
• interface. Use this element to specify the interface through which the destination net-
work can be reached. Do this by typing the name of the interface as you assigned it
using the configuration attribute name (e.g. name). Note that the “interface” can also be
a DLCI, PVC, tunnel, etc.
• preference. Use this element to set the level of importance of the route.
• metric. Use this element to set with how much the metric parameter of a route has to
be incremented.
Refer to routingTable on page 620 for more information.

Example - configuring a static route (WAN IP address is present)
Suppose network 1 is connected over a network of an operator to network 2. The two routers have an
IP address on their WAN interface.
To make network 192.168.48.0 reachable from network 192.168.47.0 and vice versa, you have to define
one static route in Router A and one static route in Router B. So configure the routingTable attribute of
Router A and B as follows:
Example - configuring a static route (WAN IP address is not present)
Suppose network 1 is connected over a network of an operator to network 2. The two routers do not have
an IP address on their WAN interface, only on their LAN interface.
To make network 192.168.48.0 reachable from network 192.168.47.0 and vice versa, you have to define
one static route in Router A and one static route in Router B. So configure the routingTable attribute of
Router A and B as follows:
7.3.4 Configuring the routing table - rules of thumb
Some rules
The following table lists some rules when configuring the routingTable:
Rule Description
1 As a rule of thumb, one can say that the interface name has priority over the gateway.
2 In case you enter a correct (i.e. existing) interface name and in case it refers to a …
• point-to-point (PTP) interface, the route is always added to the routing table, no matter
which gateway (GW) is specified.
• multi-point (MP) interface, then …
- the route is only added to the routing table when a local gateway is specified.
- the route is not added to the routing table when no gateway is specified.
- a reroute occurs when no local gateway is specified.
3 In case you enter an incorrect interface name, the route is not added to the routing table.
4 In case you enter no interface name then …

• the route is added to the routing table when a local gateway is specified.
• the route is not added to the routing table when no gateway is specified.
• the route is not added to the routing table when the gateway lies within the configured
network route. For example: network = 10.0.0.0; mask = 255.255.255.0; gateway =
10.0.0.1.
• a reroute occurs when no local gateway is specified.
The following table summarises the above:
Interface name Gateway Result
correct none (0.0.0.0) • PTP: route added

• MP: route not added
correct local route added (always)
correct not local • PTP: route added1

• MP: rerouted
incorrect - route not added
no name local for an interface routed added
no name not local for an interface rerouted to gateway

Exception:
• GW = none (0.0.0.0) • route not added
• GW lies in configured net- • route not added
work route
1. In the routingTable status, the configured gateway will appear but for the routing itself the gate-
way is ignored.
Gateway Field
It is important to note that, as of TDRE12, static routes that use an Ethernet-like interface (broadcast
interface) no longer require filling in the gateway field.
When such a route is used, an ARP look-up for the destination address of the packet is performed before
transmitting the packet, instead of a look-up for the gateway address.
Refer to the following example:
• Situation: the server with IP address 192.168.1.200, which was on Lan2 needs to be physically
placed in Lan1, but its IP address may not be changed.
• Solution: This can be solved by adding a static host route to that server on the router between the 2
networks. If proxy ARP is enabled on that router, both the hosts on Lan2 and the server will be able
to continue working without any modification to their network configuration.
7.3.5 The rerouting principle
What is the rerouting principle?
If the gateway of a route does not belong to the subnet of an interface, then the 1424 SHDSL Router
adds a special route. Then a second route look-up occurs, this time using the gateway field of the route.
This can be used as a back-up functionality as shown below.
Example
Suppose you have

the following set-up:
In the routing table,

the following routes
are defined:
• network
172.31.75.0 is
reachable via
172.31.77.10
• 172.31.77.10 is
reachable via
PVC A
(172.31.77.2)
• 172.31.77.10 is
also reachable
via PVC B
(172.31.77.6)
Now in order to reach network 172.31.75.0, PVC A is used. However, when PVC A goes down, the 1424
SHDSL Router automatically uses PVC B in order to reach network 172.31.75.0. I.e. it automatically
“reroutes” and this without the need of a routing protocol.
Important remarks
• This only works for the entries of the routing table, not for the default gateway.
• This type of route is always up.
• In the status information, the interface element of such a route displays internal.
7.4 Configuring policy based routing
This section introduces the policy based routing and gives a short description of the attributes you can
use to configure policy based routing.
• 7.4.1 - Introducing policy based routing on page 198
• 7.4.2 - Setting up policy based routing on page 199
• 7.4.3 - Applying policy based routing on page 202
7.4.1 Introducing policy based routing
What is policy based routing?
Normal routing is based on the destination IP address. Policy based routing offers the possibility to
define different routing entries based on additional information. Traffic is routed to a certain interface or
gateway based on e.g. the source IP address, the IP protocol, etc.
7.4.2 Setting up policy based routing
Refer to 7.4.1 - Introducing policy based routing on page 198 for an introduction.
To configure policy based routing, proceed as follows:
Step Action

profiles/policy/traffic object and add an ipTrafficPolicy[ ]
object underneath (refer to 4.4 - Adding an object to
2 Select a traffic policy method. Do this using the

method attribute in the traffic policy object you added
in step 1.
In case of policy based routing, you can only use
trafficShaping or tosMapped, not tosDiffServ.
3 Configure the policy criteria for the traffic policy method you selected in step 2.
If you choose then use the following attribute in the traffic policy object to
the method … configure the policy criteria:
trafficShaping, trafficShaping.
So using the elements in this table you can route traffic based on
IP source and destination address, TOS values, IP protocol, etc.
tosMapped, tos2QueueMapping.
So using the elements in this table you can route traffic based on
TOS values.
For more information on these attributes, refer to …

• trafficShaping on page 595.
• tos2QueueMapping on page 600.
4 Now you have to determine to which interface and gateway the traffic is routed. Do this
using the interface and gateway elements that you find in the traffic policy tables you config-
ured in step 3.
Example - configuring policy based routing
Suppose you have two networks which are interconnected over an ATM network. Network 1 carries a
mix of data and voice traffic. The traffic on this network is differentiated by setting the Type Of Service
(TOS) values in the IP packet headers (data = 0, voice = 10). When the traffic is routed from network 1
to network 2 you want that the data traffic and the voice traffic each go over a separate PVC.
Sketched in broad outlines, this is how you configure the above:
Step Action
1 Set up two ATM PVCs.

For example:
• Configure one ATM PVC that will carry the data traffic, e.g. pvcTable/name = dataPvc.
• Configure another ATM PVC that will carry the voice traffic, e.g. pvcTable/name =
voicePvc.
Since this is not the main subject of this example, refer for more information on creating
ATM PVCs to 6.2.2 - Configuring ATM PVCs on page 110.
2 Create and configure an IP traffic policy for policy based routing purposes.
For example:
• Create a trafficPolicy[myIpPol] object.
• Set the method attribute to tosMapped.
• In the tos2QueueMapping table, create two entries and define the startTos, endTos, interface
and gateway elements of each entry in such a way that the data traffic and the voice
traffic each go over a separate PVC.
The following figure shows how to configure policy based routing:

7.4.3 Applying policy based routing
There are 2 ways to apply policy based routing:

• The first way is to add a route that uses the trafficPolicy as interface: type in the name of the trafficPolicy
in the interface element. Refer to the example below.
When a packet arrives, it will be routed and then the trafficPolicy will be applied.
• The second way is to use an accessPolicy.
To apply an access policy for the routed data on a certain interface, enter the index name of the ear-
lier created traffic policy object as value of the accessPolicy element.
An access policy is actually a trafficPolicy that is being applied before the actual routing takes place, so
it can be seen an inbound access list:
- When in an entry that matches, the interface element is filled in, the packet is sent directly to this
interface without the routing process being applied.
- However, when the interface element is blank, the accessPolicy acts as an actual inbound access list:
› If there is a match, the packet is let through.
› If there is no match, the packet is dropped.
- When discard has been entered in the interface field, the packets will be denied.
It is important to note that, when the data does not match with any line, the data will be discarded.
Example - applying PBR
• This example continues from the example above, where the traffic policy myIpPol has been configured.
The following figure shows a default route that uses the traffic policy myIpPol as interface:
• The figure below shows how an accessPolicy is applied on the LAN interface:
The IP address of the LAN interface must also be set in the traffic policy myIpPol2:
7.5 Configuring RIP
This section introduces the Routing Information Protocol (RIP) and gives a short description of the
attributes you can use to configure RIP.
• 7.5.1 - Introducing RIP on page 205
• 7.5.2 - Enabling RIP on an interface on page 206
• 7.5.3 - Explaining the rip structure on page 208
• 7.5.4 - Enabling RIP authentication on an interface on page 211
7.5.1 Introducing RIP
What is RIP?
The Routing Information Protocol (RIP) is a protocol that routers use to exchange dynamic routing infor-
mation. RIP can be enabled or disabled per interface.
There are two main RIP modes:
RIP mode Description
passive Received RIP updates are parsed, but no RIP updates are transmitted.
active RIP updates are transmitted and received.
How does RIP work?
When RIP is enabled, the 1424 SHDSL Router advertises every 30 seconds its routing information to
adjacent routers. It also receives the routing information from the adjacent routers. With this information
it adapts its routing table dynamically. If after 180 seconds no information about a certain route has been
received, then this route is declared down. If after an additional 120 seconds (i.e. 300 seconds in total)
still no information about the route has been received, then this route is deleted from the routing table.
RIP support
The 1424 SHDSL Router supports RIP protocol version 1, 1-compatible and 2. RIP version 1 is a very
common routing protocol. Version 2 includes extra features like variable subnet masks and authentica-
tion. Check which RIP version is used by the other routers in the network.
Currently, the RIPv2 routing protocol requires the use of an IP address on the WAN interface.
RIP authentication
For security reasons the RIP updates that are exchanged between routers can be authenticated. RIP
authentication can be enabled or disabled per interface.
7.5.2 Enabling RIP on an interface
Refer to …
• 7.3.1 - Introducing static routing on page 189 for a comparison between static and dynamic (e.g.
using RIP) routing.
• 7.5.1 - Introducing RIP on page 205 for an introduction on RIP.
To enable dynamic routing using RIP on an IP interface, proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to the router object and set the routingPro-
tocol attribute to rip.
This activates the general RIP process on the 1424 SHDSL Router. Now you can activate
or deactivate RIP per IP interface. Note that by default RIP is activated on all IP inter-
faces.
2 Each IP interfaces has an ip structure. Within this ip structure you find a rip structure. Use
the following elements in the rip structure to activate or deactivate RIP per IP interface:
• mode. Use this element to set the transmission and/or reception of RIP updates on the
interface. By default the 1424 SHDSL Router transmits and receives RIP updates on
all interfaces.
• txVersion. Use this element to set the version of the RIP updates that are transmitted
on the interface.
• rxVersion. Use this element to set which version of received RIP updates is accepted
on the interface.
For example, the following shows the location of the rip structure on the LAN interface:
Refer to …
• 5.2.2 - Where to find the IP parameters? on page 55 for the location of the ip structure
on the different IP interfaces. The rip structure is located within the ip structure.
• 7.5.3 - Explaining the rip structure on page 208 for a detailed explanation of the rip
structure.
Example - configuring RIP
Suppose you want to activate RIP on the LAN interface. What is more, you want that the LAN interface
does not transmit RIP updates but only parses received RIP updates (passive RIP). Furthermore, you
only want to accept RIP version 1 updates on the LAN interface.
The following figure shows how to configure this:
Note that since in this example the mode element is set to passive, the txVersion element is ignored.
7.5.3 Explaining the rip structure
Because the rip structure occurs in several objects, it is described here once and referenced where nec-
essary. The rip structure is located within the ip structure. Refer to 5.2.2 - Where to find the IP parame-
ters? on page 55 for the location of the ip structure.
The rip structure contains the following elements:
Element Description
metric Use this element to determine with how much the Default:1
1424 SHDSL Router increments the metric parameter Range: 1 … 15
of a route.
Routing information includes a metric parameter. Every time a router is passed,
this parameter is incremented. Also the 1424 SHDSL Router increments the metric
parameter (default by 1) before it writes the route in the routing table. Hence, the
metric parameter indicates for each route how many routers have to be passed
before reaching the network. When several routes to a single network exist and
they all have the same preference, then the route with the smallest metric param-
eter is chosen.
However, using the metric element, you can increment the metric parameter by
more than 1 (up to a maximum of 15). You could do this, for instance, to indicate
that a certain interface is less desirable to route through. As a result, the 1424
SHDSL Router adds this value to the metric parameter of every route learnt
through that interface.
The metric parameter is also used to represent the directly connected subnets on
the LAN and WAN interfaces.
mode Use this element to set the transmission and/or recep- Default:active
tion of RIP updates on the interface. By default the Range: enumerated, see below
1424 SHDSL Router transmits and receives RIP
updates on all interfaces.
The mode element has the following values:
• active. RIP updates are transmitted and received on this interface.
• passive. RIP updates are not transmitted on this interface, but received updates
are parsed.
• disabled. RIP updates are nor transmitted nor received on this interface.
txVersion Use this element to set the version of the RIP updates Default:rip2
that are transmitted on the interface. Range: enumerated, see below
The txVersion element has the following values:
• rip1. The transmitted RIP updates are RIP version 1 updates.
• rip2. The transmitted RIP updates are RIP version 2 updates.
• rip1-compatible. The contents of the RIP update packet is a RIP version 2 packet,
but it is encapsulated as a RIP version 1 packet. This allows some older imple-
mentations of RIP 1 to be interoperable with RIP 2.
Element Description
rxVersion Use this element to set which version of received RIP Default:rip2only
updates is accepted on the interface. Range: enumerated, see below
The rxVersion element has the following values:
• rip1only. Only RIP version 1 received RIP updates are accepted.
• rip2only. Only RIP version 2 received RIP updates are accepted.
• rip1&2. Both RIP version 1 and 2 received RIP updates are accepted.
If you want to accept RIP1-compatible updates on the interface, then set the
rxVersion attribute to rip1&2.
splitHorizon Use this element to enable or disable split horizon Default:poisonedReverse

operation. Range: enumerated, see below
The splitHorizon element has the following values:
• disabled. Split horizon is disabled.
• enabled. Split horizon is enabled.
Split horizon operation prevents that routing information exits the interface
through which the information was received in the first place. This optimises
communications among multiple routers, particularly when links are broken. It
also prevents routing loops.
• poisonedReverse. Poisoned reverse split horizon is used.
Whereas “simple” split horizon simply omits the routes learned from one neigh-
bour in updates sent to that neighbour, poisoned reverse split horizon includes
such routes in updates but sets their metrics to infinity.
Element Description
authentication Use this element to enable or disable RIP authentica- Default:disabled

tion. Range: enumerated, see below
Refer to 7.5.4 - Enabling RIP authentication on an interface on page 211 for more
information on RIP authentication.
The authentication element has the following values:
• disabled. No authentication is used.
• text. The authentication secret is exchanged in clear text.
• md5. Instead of sending the authentication secret together with the RIP
updates, it is hashed together with the routing information into a unique value.
This authentication is the most secure. This because it provides also protection
against tampering with the contents of a packet: both an incorrect password
and modified routing information result in different hash values.
Remarks
•If authentication is enabled (either text or md5), then only updates using that
authentication are processed. All other updates on that interface are discarded.
• If you use md5 and if for a certain interface multiple secrets are present in the
ripv2SecretTable, then the first entry in the ripv2SecretTable is used to transmit RIP
updates. Authentication of the received RIP updates is done by looking for the
first secret with a matching key.
• If you use text and if for a certain interface multiple secrets are present in the
ripv2SecretTable, then only the first entry in the ripv2SecretTable is used to transmit
and receive RIP updates.
filter Use this element to apply a filter on the RIP updates Default:<empty>
on the interface. Range: 0 … 24 characters
Do this by entering the index name of the filter you want to use. You can create the
filter itself by adding a routingFilter object and by configuring the attributes in this
object.
Example
If you created a routingFilter object with index name my_filter (i.e.

routingFilter[my_filter]) and you want to apply this filter here, then enter the
index name as value for the filter element.
Refer to …
• 11.9.10 - Routing filter configuration attributes on page 736 for more informa-
tion on RIP filtering.
• 4.4 - Adding an object to the containment tree on page 45 for more information
on adding objects.
clearNextHop When this element is enabled, the nextHop parameter Default:disabled

in an advertised RIP route is set to zero. Range: enabled / disabled
7.5.4 Enabling RIP authentication on an interface
Refer to 7.5.1 - Introducing RIP on page 205 for an introduction on RIP authentication.
To enable RIP authentication on a certain interface, proceed as follows:
Step Action
1 In the rip structure, set the authentication element to …

• text. RIP authentication is enabled and the authentication secret is
sent along with the RIP updates in clear text.
• md5. RIP authentication is enabled and the authentication secret is
hashed together with the routing information into a unique value.
Refer to 7.5.3 - Explaining the rip structure on page 208.
2 In the 1424 SHDSL Router containment tree, go to the router object, select the
ripv2SecretTable attribute and add one or more entries to this table.
3 Configure the elements of an entry in the ripv2SecretTable attribute:

• keyId. Use this element to set a unique identifier for each secret.
• secret. Use this element to define the secret. This secret is sent with the RIP updates
on the specified interface. It is also used to authenticate incoming RIP updates.
• interface. Use this element to specify on which interface the secret is used. Do this by
typing the name of the interface as you assigned it using the configuration attribute
name (e.g. name). Note that the “interface” can also be a DLCI, PVC, tunnel, etc. Enter-
ing the string “all” (default) means the secret is used on all the interfaces.
Refer to ripv2SecretTable on page 624 for more information.

7.6 Configuring OSPF
This section introduces the OSPF protocol. The following gives an overview of this section:
• 7.6.1 - Introducing OSPF on page 213
• 7.6.2 - Activating OSPF on page 218
• 7.6.3 - Enabling OSPF authentication on page 219
7.6.1 Introducing OSPF
What is OSPF?
The Open Shortest Path First (OSPF) protocol is an Interior Gateway Protocol used to distribute routing
information within a single Autonomous System.
On the Internet, an autonomous system (AS) is either a single network or a group of networks that is
controlled by a common network administrator (or group of administrators) on behalf of a single admin-
istrative entity (such as a university, a business enterprise, or a business division). An autonomous sys-
tem is also sometimes referred to as a routing domain.
Using OSPF, a host that obtains a change to a routing table or detects a change in the network imme-
diately multicasts the information to all other hosts in the network so that all will have the same routing
table information. Unlike the RIP in which the entire routing table is sent, the host using OSPF sends
only the part that has changed. With RIP, the routing table is sent to a neighbour host every 30 seconds.
OSPF multicasts the updated information only when a change has taken place.
What are the OSPF link states?
Rather than simply counting the number of hops, OSPF bases its path descriptions on "link states" that
take into account additional network information. That is why OSPF is called a link-state protocol. A link
can be seen as an interface on the router. The state of the link is a description of that interface and of its
relationship to its neighbouring routers. A description of the interface would include, for example, the IP
address of the interface, the mask, the type of network it is connected to, the routers connected to that
network and so on.
Each router in the Autonomous System originates one or more link state advertisements (LSAs). The
collection of LSAs forms the link-state database. Each separate type of LSA has a separate function.
There 4 distinct types of LSAs:
Link State Packets Description
Router-LSAs • Describes the state and cost of the router ‘s links (interfaces) to the area,
i.e. intra-area.
• Each router will generate a Router-LSA for all of its interfaces.
Network-LSAs Network-LSAs are generated by a Designated Router (DR) on a segment.

This information is an indication of all routers connected to a particular multi-
access segment such as Ethernet, Token Ring and FDDI (DRs will be dis-
cussed further down).
Summary-LSAs • Summary-LSA ‘s provide a way of condensing an area's routing informa-

tion.
• Summary-LSA ‘s describe networks in the Autonomous System, but out-
side of an area, i.e. inter-area. Summary links are generated by an Area
Border Router (ABR, ABRs will be discussed further down).
• By generating summary links, the network reachability information is
shared between areas. Normally, all information is injected into the back-
bone (area 0) and in turn the backbone will pass it on to other areas.
ABRs also have the task of propagating the reachability of the ASBR.
This is how routers know how to get to external routes in other Autono-
mous Systems.
Link State Packets Description
AS-external-LSAs • AS-external-LSAs provide a way of transparently advertising externally-

derived routing information throughout the Autonomous System
• AS-external-LSAs are an indication of networks outside of the AS. These
networks are injected into OSPF via redistribution. External links are
generated by an ASBR (ASBRs will be discussed further down). The
ASBR has the task of injecting these routes into an autonomous system.
What is the backbone area or area 0?
OSPF has special restrictions when multiple areas are involved. If more than one area is configured, one
of these areas has be to be area 0. This is called the backbone. When designing networks it is good
practice to start with area 0 and then expand into other areas later on.
The backbone has to be at the centre of all other areas, i.e. all areas have to be physically connected to
the backbone. The reasoning behind this is that OSPF expects all areas to inject routing information into
the backbone and in turn the backbone will disseminate that information into other areas.
What are areas and border routers?
OSPF uses flooding to exchange link-state updates between routers. Any change in routing information
is flooded to all routers in the network. Areas are introduced to put a boundary on the explosion of link-
state updates. All routers within an area have the exact link-state database.
A router that has all of its interfaces within the same area is called an internal router (IR).
Routers that belong to multiple areas, and connect these areas to the backbone area are called area
border routers (ABR). ABRs must therefore maintain information describing the backbone areas and
other attached areas.
Routers that act as gateways (redistribution) between OSPF and other routing protocols (e.g. RIP) are
called autonomous system boundary routers (ASBR).
In order to minimize the amount of information exchange on a particular segment, OSPF elects one
router to be a designated router (DR), and one router to be a backup designated router (BDR), on each
multi-access segment. The BDR is elected as a backup mechanism in case the DR goes down (the DR
and BDR are elected based upon their OSPF priority). The idea behind this is that routers have a central
point of contact for information exchange. Instead of each router exchanging updates with every other
router on the segment, every router exchanges information with the DR and BDR. The DR and BDR
relay the information to everybody else.
What are stub areas?
OSPF allows certain areas to be configured as stub areas. External networks, such as those redistrib-
uted from other protocols into OSPF, are not allowed to be flooded into a stub area. Routing from these
areas to the outside world is based on a default route. Configuring a stub area reduces the topological
database size inside an area and reduces the memory requirements of routers inside that area.
An area can be called a stub when there is a single exit point from that area or if routing to outside of the
area does not go via an optimal path. The latter description is just an indication that a stub area that has
multiple exit points, will have one or more area border routers injecting a default into that area.
All OSPF routers inside a stub area have to be configured as stub routers. This is because whenever an
area is configured as stub, all interfaces that belong to that area will start exchanging Hello packets with
a flag that indicates that the interface is stub. All routers that have a common segment have to agree on
that flag. If they don't, then they will not become neighbours and routing will not take effect.
What are NSSAs?
Not-so-stubby areas are a type of stub area in which external routes can be flooded.
OSPF areas flood all external routes across area borders. In the presence of large number of external
routes, this may be a problem, as external routes cannot be summarized at the ABRs. Stub areas are
designed to alleviate the problem by preventing external routes from being injected into the stub area,
and instead a default route is injected. Stub areas are incapable of carrying external routes (Type 5
LSAs), and hence are incapable of supporting ASBRs.
NSSAs allow for supporting ASBRs within the NSSA, while maintaining the same behaviour as stub
areas of not injecting external (Type 5) routes coming from the backbone. Thus NSSA routers benefit
from the significant reduction of external routes coming from the backbone, while having the capability
to carry a limited number of externals that originate in the NSSA.
To provide the ability of carrying external routes originated in the NSSA, a new LSA type was defined,
Type 7 LSA. It has the structure and semantics of a Type 5 (External) LSA, with a two differences:
• Type 7 LSAs can be originated and propagated within the NSSA, they do not cross area borders like
Type 5 LSAs do.
• Type 5 LSAs are not supported in NSSA; they can be neither originated nor propagated in NSSA.
In order to allow limited exchange of external information across an NSSA border, NSSA border routers
will translate selected Type-7 LSAs received from the NSSA into Type-5 LSAs. These Type-5 LSAs will
be flooded to all Type-5 capable areas. NSSA border routers may be configured with address ranges so
that multiple Type-7 LSAs may be aggregated into a single Type-5 LSA. The NSSA border routers that
perform translation are configurable. In the absence of a configured translator one is elected.
What are neighbours and adjacency?
Routers that share a common segment become neighbours on that segment. Neighbours are discov-
ered via the Hello protocol. Hello packets are sent periodically out of each interface using IP multicast.
Routers become neighbours as soon as they see themselves listed in the neighbour’s Hello packet. This
way, a two way communication is guaranteed.
Adjacency is the next step after the neighbouring process. Adjacent routers are routers that go beyond
the simple Hello exchange and proceed into the database exchange process. In order to minimize the
amount of information exchange on a particular segment, OSPF elects one router to be a designated
router (DR), and one router to be a backup designated router (BDR), on each multi-access segment
(refer to What are areas and border routers? on page 214).
What is OSPF cost?
The cost of an interface in OSPF is an indication of the overhead required to send packets across a cer-
tain interface. The cost of an interface is inversely proportional to the bandwidth of that interface. A
higher bandwidth indicates a lower cost. There is more overhead (higher cost) and time delays involved
in crossing a 56k serial line than crossing a 10M ethernet line.
The cost of an interface can either be calculated automatically, or the user can overrule the calculated
cost by using his own configuration so that some paths are given preference.
The formula used to calculate the cost is:
cost = reference bandwidth (in bps) / interface bandwidth (in bps)
The reference bandwidth can be set by the user.
Virtual links
Virtual links are used for two purposes:

• Linking an area that does not have a physical connection to the backbone.
• Patching the backbone in case discontinuity of area 0 occurs.
As mentioned earlier, area 0 has to be at the centre of all other areas. In some rare case where it is
impossible to have an area physically connected to the backbone, a virtual link is used. The virtual link
will provide the disconnected area a logical path to the backbone. The virtual link has to be established
between two ABRs that have a common area, with one ABR connected to the backbone.
OSPF authentication
It is possible to authenticate the OSPF packets so that routers can participate in routing domains based
on predefined passwords. By default, a router uses a Null authentication which means that routing
exchanges over a network are not authenticated. Two other authentication methods exist: Simple Pass-
word authentication and Message Digest authentication (MD-5):
Authentication Description
Null authentication No authentication is used.
Simple Password This allows a password (key) to be configured per interface. Interfaces of dif-
authentication ferent routers that want to exchange OSPF information will have to be con-
figured with the same key.
Message Digest This is a cryptographic authentication. A key (password) and key-id are con-
authentication (MD-5) figured on each router. The router uses an algorithm based on the OSPF
packet, the key, and the key-id to generate a "message digest" that gets
appended to the packet. Unlike the simple authentication, the key is not
exchanged over the wire.
OSPF authentication can be enabled or disabled per interface.

7.6.2 Activating OSPF
Refer to 7.6.1 - Introducing OSPF on page 213 for an introduction on OSPF.

OSPF does not need to be activated as such. By modifying the configuration attributes under the router/
ospf and router/ospf/Area[ ] objects, OSPF can be applied within an autonomous system. Refer to 11.9.8 -
OSPF configuration attributes on page 704.
The router/ospf/Area[ ] object is not present in the containment tree by default. If you want to use the feature
associated with this object, then add the object first. Refer to 4.4 - Adding an object to the containment
tree on page 45.
7.6.3 Enabling OSPF authentication
Refer to 7.6.1 - Introducing OSPF on page 213 for an introduction on OSPF authentication.
There are two authentication methods:
• simple password authentication. Refer to Enabling simple password authentication on page 219.
• MD-5 authentication. Refer to Enabling MD-5 authentication on page 220.
Enabling simple password authentication
To enable simple password authentication, proceed as follows:
Step Action
1 In the containment tree, go to the router/ospf/Area[ ] object, and select the networks configu-
ration attribute. In the authentication structure, set the authentication type element to text.
2 In the authentication text element, type the password.

Enabling MD-5 authentication
To enable MD-5 authentication, proceed as follows:
Step Action
1 In the containment tree, go to the router/ospf object and select the keyChains configuration
attribute. In the keyChains table, add a new chain.
2 In the chain table, set the elements correctly. Refer to router1424/ip/router/ospf/keyChains/chain

on page 707.
3 In the containment tree, go to the router/ospf/Area[ ] object, and select the networks configu-
ration attribute. In the authentication structure, set the authentication type element to md5.
4 In the authentication keyChain element, type the name of the key chain that will be used.
In the screenshots above, the authentication structure is explained as being part of the networks table. Note
that the authentication structure is also present in the virtualLinks table.
7.7 Configuring BGP
Introduction
The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. An autonomous
system (AS) is a network or group of networks under a common administration and with common routing
policies.
BGP is used to exchange routing information for the internet and is the protocol used between Internet
service providers (ISPs). Customer networks, such as universities and corporations, usually employ an
Interior Gateway Protocol (IGP) such as RIP or OSPF for the exchange of routing information within their
networks. Customers connect to ISPs, and ISPs use BGP to exchange customer and ISP routes.
When BGP is used between autonomous systems, the protocol is referred to as External BGP (EBGP).
If a service provider is using BGP to exchange routes within an AS, then the protocol is referred to as
Interior BGP (IBGP). Every service provider is identified by its AS number (ASN).
BGP came into being, because:
• Service providers must tell each other which addresses they manage.
• There was a need to manage lots of address ranges (prefixes): 150.000 to 250.000.
• Because of peering agreements best route is no longer a simple concept.
• There was a need for a routing protocol that can express not only reachability information but also
policy information
BGP transport protocol
BGP uses TCP as transport protocol:

• Port 179 is used.
• Only unicasts are used.
• Neighbours are not automatically discovered.
• BGP must be configured on both sides of the connection.
• The source address of an incoming connection can be verified.
BGP key attributes
Routes learned via BGP have associated properties that are used to determine the best route to a des-
tination, when multiple paths exist to one specific destination.
Understanding how these BGP attributes influence route selection is required for the design of reliable
networks. The key attributes that BGP uses in the route selection process are:
• Weight: the weight attribute is local to a router. The weight attribute is not advertised to neighbouring
routers. If the router learns about more than one route to the same destination, the route with the high-
est weight will be preferred.
• Local preference: the localPreference attribute is used to prefer an exit point from the local autonomous
system (AS). Unlike the weight attribute, the localPreference attribute is propagated throughout the local
AS. If there are multiple exit points from the AS, the localPreference attribute is used to select the exit
point for a specific route.
• Multi-exit discriminator, or MED: the med or metric attribute is used as a suggestion to an external AS
regarding the preferred route into the AS that is advertising the metric. MEDs are advertised through-
out the local AS.
• Origin: the origin attribute indicates how BGP learned about a particular route.
• AS path: when a route advertisement passes through an AS, the AS number is added to an ordered
list of AS numbers that the route advertisement has passed.
Refer to BGP route selection process on page 223 for a description of how BGP selects a path for a des-
tination.
Refer to 11.9.9 - BGP configuration attributes on page 718 for more information about all BGP configu-
ration attributes.
BGP route selection process
BGP can possibly receive multiple advertisements for the same route from multiple sources. Only one
path is selected as the best path.
When the path is selected, BGP puts the selected path in the IP routing table and propagates the path
to its neighbours.
BGP uses the following criteria, in consecutive order as stated here, to select a path for a destination:
Step Action
1 The path with the largest weight is always preferred (local to the router).
2 If the weights are the same, the path with the highest local preference (global in the AS)
is preferred.
3 If the local preferences are the same, the path that was originated by BGP running on
this router is preferred.
4 If no route was originated, the route that has the shortest AS path is preferred.
5 If all paths have the same AS path length, the path with the lowest origin type is preferred
(where IGP is lower than EGP, and EGP is lower than incomplete).
6 If the origin codes are the same, the path with the lowest med value is preferred.
7 If the paths have the same med, external paths (EBGP) are preferred over internal paths
(IBGP).
8 • In case of IBGP, if the paths are still the same, the path through the closest IGP neigh-
bour is preferred.
• In case of EBGP, the oldest, most stable path is preferred.
9 The path from the router with the lowest BGP router ID is preferred.
BGP routeFilter
On each peer incoming and outgoing filters can be applied, simply allowing or denying certain routes to
be accepted or advertised through a peer.
If no entry is added in the inboundFilters or outboundFilters attributes on the peer, no filtering will be applied,
allowing all routes.
When entries are added referring to the routeFilter objects, the routeFilter objects are searched one by one
in the order of entry for a match in the filters table. As soon as a match is found, the filtering mode is
applied, be it allow or deny.
If after searching all routeFilter objects no match is found, the route is denied. The behaviour is as if all
filter tables were appended in one big filter table. By default the table is empty which means everything
will be denied: anything which is not explicitly allowed will be denied.
However, adding a new row will allow everything, because network 0.0.0.0/0 is the default value and the
asPath specification is empty.
Examples of the use of route maps could be:
• only accept routes for specific prefixes from the customer.
• only accept the default route from your ISP.
• only accept routes with a given AS path.
BGP routeMap
Even ‘simple’ internet connectivity scenarios require manipulation of route attributes. For this purpose,
route maps are used. Route maps give fine grained control of what is received and transmitted.
Examples of the use of route maps could be:
• modify the AS-Path before sending it to your ISP (consult your ISP before doing this).
• set attributes to enforce your policy.
Each peer has an inboundMaps and an outboundMaps table attribute, where each row refers to a route map
to be applied when accepting or advertising routes through a peer. When entries are added referring to
the routeMap objects, the routeMap objects are searched one by one in the order of entry for a match in the
routeFilter they are referring too. As soon as a match is found, the mode is checked: in mode allow, the
changes to the route are applied; in mode deny the route is passed unchanged.
If after searching all routeFilter objects no match is found, the route is passed unchanged.
If on a routeMap object no filter is defined, all routes will be adapted by this routeMap.
If no entry is added in the inboundMaps or outboundMaps attributes on the peer, no mapping will be applied,
passing all routes unchanged.
No real route filtering is applied by means of a routeMap. The reference to a routeFilter objects is only used
to specify which routes must be adapted and which ones may pass unchanged. Route filtering is only
possible through use of the inboundFilters and outboundFilters attributes on the peers.
7.8 Configuring address translation
This section explains Network Address Translation (NAT) and Port Address Translation (PAT). Firstly, it
gives an introduction. Secondly, a table is presented that will help you to determine which translation
method meets your requirements. Then this section teaches you how to configure NAT and PAT.
• 7.8.1 - Introducing address translation on page 226
• 7.8.2 - When use NAT and/or PAT on page 227
• 7.8.3 - Enabling PAT on an interface on page 228
• 7.8.4 - How does PAT work? on page 230
• 7.8.5 - PAT limitations and work-arounds on page 233
• 7.8.6 - Enabling NAT on an interface on page 234
• 7.8.7 - Adding multiple NAT objects on page 236
• 7.8.8 - How does NAT work? on page 238
• 7.8.9 - Combining PAT and NAT on page 240
• 7.8.10 - Easy NAT on PPP on page 240
• 7.8.11 - Example: connecting a LAN to the Internet using NAT and PAT on page 243
• 7.8.12 - Example: using PAT with a minimum of official IP addresses on page 245
7.8.1 Introducing address translation
What is address translation?
Address translation is used to translate private IP addresses into official IP addresses. This is also known
as IP masquerading.
Why use address translation?
Each device connected to the Internet must have an official (i.e. unique) IP address. The success of the
Internet has caused a lack of these official IP addresses. As a result, your Internet Service Provider (ISP)
may offer you only one or a small number of official IP addresses.
If the number of IP devices on your local network is larger than the number of official IP addresses, you
can assign test or private IP addresses to your local network. In that case, you have to configure your
access router to translate IP addresses using NAT or PAT.
Even when there are sufficient official IP addresses available, you may still choose to use NAT e.g. for
preserving previously assigned test addresses to all the devices on your local network.
What is NAT?
Network Address Translation (NAT) is an Internet standard that enables a local area network (LAN) to
use one set of IP addresses for internal traffic (private IP addresses) and a second set of addresses for
external traffic (official IP addresses). The access router (located where the LAN meets the Internet)
makes all necessary IP address translations. This is a dynamic process.
NAT serves three main purposes:
• Provides a type of firewall by hiding internal IP addresses.
• Enables a company to use more internal IP addresses. Since these are used internally only, there is
no possibility of conflict with IP addresses used by other companies and organizations.
• Allows a company to combine multiple ISDN connections into a single Internet connection.
The number of simultaneous users with Internet access is limited to the number of official IP addresses.
What is PAT?
Port Address Translation (PAT) is a type of Network Address Translation. During PAT, each computer
on LAN is translated to the same IP address, but with a different port number assignment.
Only outgoing TCP sessions are supported.
Private IP address range
The international authority IANA assigns the official (also called global) IP addresses. It has also defined
3 ranges of IP addresses for private use. This means that you can use these addresses without regis-
tration on your internal network, as long as you are not connected to the Internet.
Private IP address range Remarks
10.0.0.0 - 10.255.255.255 1 class A network
172.16.0.0 - 172.31.255.255 16 class B networks
192.168.0.0 - 192.168.255.255 256 class C networks
You can define (sub-)networks in these ranges for your private IP addresses.
7.8.2 When use NAT and/or PAT
Refer to 7.8.1 - Introducing address translation on page 226 for an introduction on NAT and PAT authen-
tication.
Check in the next table whether you need NAT and/or PAT:
No. of official IP No. of devices on local Use NAT of PAT? Refer to …

addresses network
1 more than 1 Use PAT. 7.8.3 - Enabling PAT on

an interface on page 228
k (> 1) more than k Use NAT in combination 7.8.9 - Combining PAT

with PAT. and NAT on page 240
at least k k (≥ 1) 1. No translation 1. Skip this section.

needed. 2. 7.8.6 - Enabling NAT
2. If you want translation, on an interface on
use NAT. page 234
7.8.3 Enabling PAT on an interface
Refer to 7.8.1 - Introducing address translation on page 226 for an introduction on PAT.
To enable PAT on a certain interface, proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to the router/defaultNat object. In this
object, configure the patAddress attribute.
Use this attribute to enter the official IP address that has to be used for the Port Address
Translation. Entering an address different from the default value 0.0.0.0 automatically ena-
bles the general PAT process. Now you can activate or deactivate PAT per IP interface.
Note that by default PAT is deactivated on all IP interfaces.
2 In the router/defaultNat object, configure the gateway attribute.
Use this attribute to define the gateway address of routes on which PAT should be
applied. If you do not configure the gateway attribute, then PAT is applied on all routes
through this interface.
3 Each IP interfaces has an ip structure. Use the following element in the ip structure to acti-
vate or deactivate PAT per IP interface:
• nat. Use this element to enable address translation on the interface with the official IP
addresses. Do this by entering the string “default“ as nat element value. By doing so,
the settings are applied as defined in the router/defaultNat object.
For example, the following shows the location of the ip structure on the LAN interface:
Refer to 5.2.2 - Where to find the IP parameters? on page 55 for the location of the ip
structure on the different IP interfaces.
Example - configuring PAT
Suppose your network is connected over a network of an operator to an Internet Service Provider (ISP).
You received only one single official IP address from you ISP, being 195.7.12.22.
The following shows how to enable PAT:

• In the router/defaultNat object, set the patAddress attribute to 195.7.12.22. In that case, the PAT address
is the same as the IP address that is used on the WAN interface.
• In the router/defaultNat object, set the gateway attribute to 195.7.12.254. If, however, you already defined
the router/defaultRoute attribute to be 195.7.12.254, then you can leave the gateway attribute empty. This
because if the gateway attribute is empty, then the defaultRoute attribute is taken as only gateway
addresses.
• In the ip structure of the WAN interface, type the string “default” as value of the nat element.
7.8.4 How does PAT work?
Again consider the network topology as depicted in 7.8.3 - Enabling PAT on an interface on page 228.
The following two paragraphs explain how the 1424 SHDSL Router treats the outgoing and incoming
traffic when PAT is applied:
• Outgoing traffic (to the Internet) on page 230.
• Incoming traffic (from the Internet) on page 232.
Outgoing traffic (to the Internet)
The 1424 SHDSL Router replaces the source address by its PAT address in all the traffic coming from
the local network and destined for the Internet. Depending on the IP transport protocol and the number
of simultaneous users accessing the Internet, the 1424 SHDSL Router takes different actions:
Protocol
TCP Description This is a connection-oriented protocol: two devices communicating with the
TCP protocol build a session before exchanging user data. When they have
finished exchanging user data, the session is closed.
Examples of such applications are Telnet, HTTP and FTP. The TCP header
contains a port field indicating the higher-layer protocol.
Action When a session is started, a specific port number is assigned to this ses-
sion. All traffic from this session is assigned this specific port number.
The specific port number is freed within 5 minutes after the TCP session is
closed (i.e. after TCP Reset or TCP Finish is seen). If the session has not
been properly closed, the port number is freed 24 hours after the last ses-
sion traffic. This time is configurable (refer to tcpSocketTimeOut on page 655).
UDP Description This is a connection-less protocol: user data can be sent without first build-
ing a session.
Examples of such applications are SNMP and TFTP. Although TFTP is ses-
sion-oriented, it builds the session at a higher level and uses UDP for its
simplicity as transport protocol. The UDP header contains a port field indi-
cating the higher-layer protocol.
Action The source port number is replaced by a specific port number. All traffic
from this source IP address / port number pair is assigned this specific port
number.
If there is no traffic for 5 to 10 minutes, the specific port number is freed. If
the session has not been properly closed, the port number is freed 3 min-
utes after the last session traffic. This time is configurable (refer to udpSock-
etTimeOut on page 656).
Protocol
ICMP Description This is a connection-less protocol: user data can be sent without first build-
ing a session.
An example of such an application is ping. These protocols do not have port
numbers.
Action Each ICMP packet is forwarded towards the Internet. Each ICMP packet is
considered as a new session.
If there is no traffic for 5 to 10 minutes, the session is closed.
The fact that it is possible to open a total of 2048 simultaneous sessions
and that each ICMP packet is considered as a new session, implies that for
instance a continuous series of ping requests at a rate of one per second
will allocate between 300 and 600 sessions.
Incoming traffic (from the Internet)
Suppose the WAN IP network depicted in 7.8.3 - Enabling PAT on an interface on page 228 works in
numbered mode1. The incoming traffic from the Internet may be destined either for the local network, or
for the router itself. The router treats incoming traffic on the PAT address as follows:
Note that the 1424 SHDSL Router only answers to ICMP requests on the public address of its WAN inter-
face if the LAN interface is up. I.e. when the TCP/UDP sessions can really “cross” the 1424 SHDSL
Router.
1. Numbered mode means that each WAN interface has an IP address. In that case, you need
the single official IP address for your WAN interface.
7.8.5 PAT limitations and work-arounds
PAT limitations
Port Address Translation has some limitations:

• Some TCP or UDP applications do not support port translation.
• Only outgoing sessions are supported. This implies that you can not access servers on your local net-
work over the Internet.
• Limited ICMP support.
PAT limitations work-arounds
Use the following attributes to partly overcome the PAT limitations:
Attribute Description
portTranslations You can find this attribute in the router/defaultNat object. Use this attribute to define
specific port number ranges that should not be translated when using PAT.
Refer to portTranslations on page 653.
Example - configuring the portTranslations table
TMA is an example of an
application that does not
support port translation. If
you want to make TMA con-
nections from your local net-
work to the outside world, you have to list TMA port number 1728 in this table.
However, keep in mind that even then it is still not possible to have two simultane-
ous TMA sessions to the same outside world address.
If you do not want that UDP packets with port numbers in the range 2000 up to
3000 are sent to the outside world, then you also have to include those in the table.
servicesAvailable You can find this attribute in the router/defaultNat object. Use this attribute to define
specific port number ranges for incoming Internet traffic that should not be trans-
lated when using PAT. Instead it is sent to the corresponding private IP address.
Refer to servicesAvailable on page 654.
Example - configuring the servicesAvailable table
In this example, a web

server with address
192.168.47.250 on the
local network is accessi-
ble from the Internet
although it has no official IP address.
7.8.6 Enabling NAT on an interface
Refer to 7.8.1 - Introducing address translation on page 226 for an introduction on NAT.
Despite the work-arounds offered by the previous two PAT configuration attributes to overcome the lim-
itations of PAT (refer to 7.8.5 - PAT limitations and work-arounds on page 233), there are situations
where PAT is inadequate. For example, it is not possible to have several web servers on your local net-
work. It is also impossible to run an application with fixed source port numbers on several local devices
that are connected simultaneously to a single Internet device. This can only be solved by using several
official IP addresses: Network Address Translation.
To enable NAT on a certain interface, proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to the router/defaultNat object or add your
own NAT object under the router object, e.g. router/nat[myNat] (refer to 4.4 - Adding an object
to the containment tree on page 45).
2 In the NAT object (default or user instantiated), select the addresses attribute and add one
or more entries to this table.
Use this attribute to enter all the official IP addresses that have to be used for Network
Address Translation. Entering an address in the addresses table automatically enables the
general NAT process. Now you can activate or deactivate NAT per IP interface. Note that
by default NAT is deactivated on all IP interfaces.
3 Configure the elements of the addresses table:

• officialAddress. Use this element to set the official IP address. These addresses are
used in the reverse order as they appear in the list.
• privateAddress. Use this element to set the private IP address, i.e. to permanently assign
an official IP address to a private address.
If you do not specify a private IP address, then NAT is applied dynamically. I.e. the
official IP address is used for any private source IP address.
4 In the NAT object (default or user instantiated), configure the gateway attribute.
Use this attribute to define the gateway address of routes on which NAT should be
applied. If you do not configure the gateway attribute, then NAT is applied on all routes
through this interface.
Step Action
5 Each IP interfaces has an ip structure. Use the following element in the ip structure to acti-
vate or deactivate NAT per IP interface:
• nat. Use this element to enable address translation on the interface with the official IP
addresses. Do this by entering the name of the NAT object you want to apply:
- If you want to apply the NAT settings as defined in the router/defaultNat
object, then enter the string “default“ as value for the nat element.
- If you want to apply the NAT settings as defined in a NAT object you
added yourself (e.g. router/nat[myNat]), then enter the index name of the
NAT object (in this case “myNat”) as value for the nat element.
For example, the following shows the location of the ip structure on the LAN interface:
Important remark - using NAT on the LAN interface
Consider the following configuration:

• router1424/lanInterface/ip/address = 195.7.12.22
• router1424/router/defaultNat/addresses = { officialAddress = 195.7.12.22; privateAddress = <opt> }
• router1424/wanInterface/ppp/ip/address = 2.2.2.2
The above means that NAT is used on the LAN interface and the router uses the address 195.7.12.22
as official IP address.
The problem that arises here is that the router can no longer be managed via the LAN interface using
the management tool (TMA, Telnet, etc.). This because the NAT route has priority over the LAN route
and, because it is a NAT address, the router does not accept incoming traffic on the address
195.7.12.22.
The solution is to add the WAN IP address to the addresses table as private address:
router1424/router/addresses = { officialAddress = 195.7.12.22; privateAddress = 2.2.2.2 }. In that case, the manage-
ment tool “service” runs on the WAN IP address. This means however, that the WAN has to be up.
7.8.7 Adding multiple NAT objects
It is possible to add multiple NAT objects (up to 5). This means that up to 5 interfaces can make use of
a dedicated NAT object.
Two or more interfaces pointing to one and the same NAT object is an invalid configuration of which the
result is unpredictable.
Example
Suppose on a 1421 SHDSL Router you …

• want to have 2 NAT objects: the default NAT object (router/defaultNat) and a user instantiated NAT
object (e.g. router/nat[myNat]).
• want to apply the default NAT object on the LAN interface and the user instantiated NAT object on
the WAN interface (and the WAN interface uses, for example, PPP).
Proceed as follows:
Step Action
1 In the 1421 SHDSL Router containment tree, go to the router/default-

Nat object and configure the attributes in this object to your needs.
Refer to 11.9.2 - NAT configuration attributes on page 652.
2 In the 1421 SHDSL Router containment tree, go to the router object

an add a nat object underneath. E.g. router/nat[myNat].
Refer to 4.4 - Adding an object to the containment tree on page 45.
3 Configure the attributes in the router/nat[myNat] object to your needs.

Refer to 11.9.2 - NAT configuration attributes on page 652.
4 In the 1421 SHDSL Router containment tree, go to the lanInterface object and select the ip
structure. In the nat element of the ip structure enter the string “default”.
⇒The NAT settings as defined in the router/defaultNat object are applied on the LAN
interface.
Step Action
5 In the 1421 SHDSL Router containment tree, go to the wanInterface/ppp object and select
the ip structure. In the nat element of the ip structure enter the string “myNat”.
⇒The NAT settings as defined in the router/nat[myNat] object are applied on the WAN
interface.
7.8.8 How does NAT work?
Dynamically assigning official IP address
If a local station sends data to the Internet for the first time, NAT looks for an unused official IP address.
It assigns this official IP address to the local station. The amount of local stations that can have simulta-
neous Internet access equals the amount of NAT addresses you defined. If all sessions between a local
station and the Internet have been closed by the application (in case of TCP) or because of time-outs,
then the previously assigned official IP address is freed for another local station.
Statically assigning official IP address
Optionally, the NAT address entry may contain a corresponding private IP address. This allows to per-
manently assign an official IP address to a local station. This is useful for stations or servers that should
have Internet access at all times. Another example of permanently assigned official IP addresses is a
network where only a limited number of users has Internet access.
Incoming traffic on an official IP address
NAT only converts IP addresses and thus allows traffic in both directions. However, incoming traffic on
one of the official IP addresses can only be forwarded to the local network if a corresponding private IP
address has been configured.
Example - configuring NAT
Suppose your network is connected over a network of an operator to an Internet Service Provider (ISP).
You received 4 official IP address from you ISP, being 195.7.12.21 up to 195.7.12.24. You want to assign
one of these official addresses permanently to a web server which has private address 192.168.47.250.
All other official addresses have to be assigned dynamically.
The following shows how to enable NAT:

• In the router/defaultNat object, configure the addresses attribute as follows:
• In the router/defaultNat object, set the gateway attribute to 195.7.12.254. If, however, you already defined
the router/defaultRoute attribute to be 195.7.12.254, then you can leave the gateway attribute empty. This
because if the gateway attribute is empty, then the defaultRoute attribute is taken as only gateway
addresses.
• In the ip structure of the WAN interface, type the string “default” as value of the nat element.
7.8.9 Combining PAT and NAT
It is possible to use a combination of PAT and NAT. In that case the router first assigns NAT addresses
until they are all used. Then it uses PAT addresses for further translations.
Make sure the PAT address does not appear in the NAT address table.
7.8.10 Easy NAT on PPP
What is easy NAT on PPP?
Easy NAT on PPP means that in a typical client / ISP setup NAT will automatically be enabled without
the need to specifically configure NAT.
A typical client / ISP setup would be, for example, a 1421 SHDSL Router on the client side and a 2400
on the ISP side connected over an SHDSL line.
What are the conditions for easy NAT on PPP?
The conditions for easy NAT on PPP are:

• A PPP (or PPPoA) connection between ISP and client.
• PPP interface on ISP router:
- The mode is routing.
- A local IP address may be configured, or it may be coming from the LAN (unnumbered).
- A remote IP address is imposed on the client router.
- NAT is disabled.
• PPP interface on client router:
- The mode is routing.
- No local nor remote IP address is configured.
- NAT is enabled (a reference is made to the defaultNat object).
• The defaultNat object on the client router:
- No PAT address is configured.
- No NAT address(es) is (are) configured.
What does easy NAT on PPP?
Once the conditions as stated above are met, the following happens:
• The client router learns the local and remote IP address of the PPP link from the ISP router.
• The client router adds a route towards the ISP router.
• The client router enables NAT on the PPP interface.
Example - easy NAT
Suppose you have the following setup:
Once the PPP link is up and running, you will see that …
• the client router learns the local and remote IP address of the PPP link from the ISP router. You can
check this by looking at the IP status of the PPP link:
• The client router adds a route towards the ISP router. You can check this by looking at the routing
table status:
• The client router enables NAT on the PPP interface. You can check this by looking at the NAT per-
formance. When a connection to the ISP is active, you will see that socketsFree attribute decreases
while the used sockets (xxxSocketsUsed) and allocation (xxxAllocs) attributes increase.
7.8.11 Example: connecting a LAN to the Internet using NAT and PAT
This is an example of a local network that only uses private addresses.

Your site is connected to an Internet Service Provider. At your site a 1424 SHDSL Router is installed.
You only received 2 official IP addresses from the ISP, one for all outgoing traffic using PAT
(195.7.12.22) and one for accessing the local web server using NAT (195.7.12.21) with a dedicated pri-
vate address.
The configuration of the 1424 SHDSL Router in CLI format is as follows:

action "Load Default Configuration"
SET
{
SELECT lanInterface
{
LIST
{
ip =
{
address = 192.168.47.254
}
mode = routing
}
}
SELECT wanInterface
{
SELECT atm
{
LIST
{
pvcTable =
{
[a] =
{
ip =
{
address = 195.7.12.22
nat = default
}
mode = routing
}
}
}
}
}
SELECT router
{
LIST
{
defaultRoute =
{
gateway = 195.7.12.254
}
}
SELECT defaultNat
{
LIST
{
patAddress = 195.7.12.22
addresses =
{
[a] =
{
officialAddress = 195.7.12.21
privateAddress = 192.168.47.250
}
}
}
}
}
}
action "Activate Configuration"
7.8.12 Example: using PAT with a minimum of official IP addresses
This is another example of a local network that only uses private addresses.
Your site is connected to an Internet Service Provider. At your site a 1424 SHDSL Router is installed.
You only received 1 official IP address from the ISP. To reduce the number of official IP addresses, the
ISP also uses private IP addresses on the link. The central router its routing table has a host route to its
PAT address per customer.

SET
{
SELECT lanInterface
{
LIST
{
ip =
{
address = 192.168.47.254
}
mode = routing
}
}
SELECT wanInterface
{
LIST
{
encapsulation = ppp
}
SELECT ppp
{
LIST
{
ip =
{
address = 192.168.100.1
nat = default
}
mode = routing
}
}
}
SELECT router
{
LIST
{
defaultRoute =
{
gateway = 192.168.100.254
}
}
SELECT defaultNat
{
LIST
{
patAddress = 195.7.12.22
servicesAvailable =
{
[a] =
{
protocol = tcp
startPort = 80
serverAddress = 192.168.47.250
}
}
}
}
}
}
7.9 Configuring VRRP
This section introduces the Virtual Router Redundancy Protocol (VRRP) and gives a short description
of the attributes you can use to configure VRRP.
• 7.9.1 - Introducing VRRP on page 248
• 7.9.2 - Setting up VRRP on page 250
7.9.1 Introducing VRRP
What is VRRP?
VRRP is designed to eliminate the single point of failure inherent in the static default routed environment.
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 pro-
vides dynamic fail-over in the forwarding responsibility should the Master become unavailable. Any of
the virtual router's IP addresses on a LAN can then 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 configura-
tion of dynamic routing or router discovery protocols on every end-host.
What is a VRRP router?
A router running VRRP. It may participate in one or more virtual routers.
What is a 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.
What is a master virtual router?
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.
What is a backup virtual router?
The set of VRRP routers available to assume forwarding responsibility for a virtual router should the cur-
rent master fail.
What is a VRRP 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.
What is a VRRP 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.
How is a master virtual router elected?
In a VRRP set-up as shown below, there is one master virtual router and one (or more) backup virtual
router.
The following shows how the master is elected:

7.9.2 Setting up VRRP
Refer to 7.9.1 - Introducing VRRP on page 248 for an introduction on VRRP.

To set up VRRP, proceed as follows:
Step Action
1 Enable VRRP on the interface(s) of your choice. Do this by setting the vrrp element in the
ip structure of the interface to enabled.
For example, if you want to enable VRRP on the LAN interface, then proceed as follows:
1. In the containment tree of the 1424 SHDSL Router, select the configuration structure
ip.
2. In the ip structure, set the element vrrp to enabled.
2 In the containment tree of the 1424 SHDSL Router, go to the router

object an add a vrrp object underneath. E.g. router/vrrp[myVrrp].
Refer to 4.4 - Adding an object to the containment tree on page 45.
3 Configure the virtual router. Do this by configuring the attributes of the vrrp object. The
most important attributes are:
• vrId. Use this attribute to set the identification of the virtual router. Specify a number
between 1 and 255. The VRID has to be set the same on all participating routers.
• ipAddresses. Use this attribute to configure one or more IP addresses on the virtual
router.
• interfaces. Use this attribute to add (IP) interfaces to the virtual router and assign a pri-
ority to them. This priority is used in the master virtual router election process.
• criticals. Use this attribute to specify which interfaces must be up before a router may
be elected as master virtual router.
Refer to 11.9.11 - VRRP configuration attributes on page 738 for more information.
Example: VRRP master/backup with owner
Suppose you have two routers configured for VRRP:
Configure this setup as follows:
In the setup above, once Router A is configured for VRRP, it looks at the IP address of the virtual router
and compares it with the IP addresses of its own interface that is configured for VRRP on that VRID.
Since Router A owns the virtual router’s IP address, it declares itself the master and sends out an adver-
tisement to all of the other VRRP routers. The IP address owner is always the master as long as it is
available.
The host shown in the setup above is configured with the virtual router's IP address as its default gate-
way. The master forwards packets destined to remote subnets and responds to ARP requests. Since in
this example, the master is also the owner of the virtual router’s IP address, it also responds to ICMP
ping requests and IP datagrams destined for the virtual router’s IP address. The backup does not forward
any traffic on behalf of the virtual router, nor does it respond to ARP requests.
If the master (in this case also the IP address owner) is not available, then the backup becomes the mas-
ter and takes over responsibility for packet forwarding and responding to ARP requests. However, since
this new master is not the IP address owner, it does not respond to ICMP ping requests and IP data-
grams destined to that address.
Each VRRP Router that is an IP address renter is configured with a priority between 1 and 254. Accord-
ing to the VRRP standard, an owner has a priority of 255.
It is not necessary for the virtual router IP address to be owned by one of the VRRP routers. In that case,
however, the election process to determine the master is different. The process involves comparing two
criteria:
• First, the VRRP router with the highest priority becomes the master.
• Second, if the priorities are the same, then the higher IP address wins and becomes the master.
Example: VRRP master/backup without owner
Suppose you have two routers configured for VRRP:
Configure this setup as follows:
In this case the VRRP configuration is identical, except for the priority. Router A has its priority set to
200, which when compared to Router B’s priority of 100, will ensure that Router A is the master. There
is no virtual router IP address owner in this configuration, since neither VRRP router has the virtual router
IP address configured on a real interface address. So, both VRRP routers are considered renters.
7.10 Configuring Virtual Routing and Forwarding or VRF
This section introduces Virtual Routing and Forwarding (VRF) and gives an overview of the attributes
you can use to configure VRF.
• 7.10.1 - Introducing VRF on page 255
• 7.10.2 - Setting up VRF on page 256
• 7.10.3 - Principle on page 257
7.10.1 Introducing VRF
Virtual routing and forwarding or VRF allows a single router to use multiple routing tables. The main ben-
efit is enhanced VPN support. Multiple customers can now be connected to a single device without
address collisions, as they each have a seperate routing table assigned to them.
This increases functionality by allowing network paths to be segmented without using multiple devices.
Traffic is automatically segregated, i.e. prevented from being forwarded outside a specific VRF path, and
traffic that should remain outside the VRF path is also kept out. Hence, VRF increases network security
and can eliminate the need for encryption and authentication.
Internet service providers often use VRF to create separate virtual private networks (VPNs) for custom-
ers; therefore, the technology is also referred to as VPN routing and forwarding.
VRF acts like a logical router, but while a logical router may include many routing tables, a VRF instance
uses only a single routing table.
The following features are available on each virtual router:
• static routing
• OSPF
• RIP
• DHCP server
• Basic NAT
Furthermore BGP will know the concept of IP VPNs, so BGP can pass information of virtual routers. This
feature is only available on the default router however.
Tunneling, firewall and IPSEC is also limited to the default router, but is possible to pass data from a
VRF router over a tunnel.
7.10.2 Setting up VRF
First of all, a vrfRouter[ ] object must be created and configured. An interface can then be assigned to the
VRF router, in order to become part of the VRF network.
The maximum allowed number of vrfRouter[ ] objects depends on the memory of the device.
vrfRouter[ ] object
To configure a VRF router, a vrfRouter[ ] object must be added to the containment tree first , since the
vrfRouter[ ] object is not present in the containment tree by default. For more information on how to add
the object, refer to 4.4 - Adding an object to the containment tree on page 45.
Following objects appear in the containment tree after adding the vrfRouter[ ] object:
• router1424/ip/vrfRouter[ ]. Use this to configure the general VRF router attributes; refer to 11.9.13 - Virtual
Routing and Forwarding (VRF) configuration attirbutes on page 769.
• router1424/ip/vrfRouter[ ]/ospf. Use this to configure the OSPF network the VRF router is part of; refer to
11.9.8 - OSPF configuration attributes on page 704.
Under the vrfRouter[ ] object, a routingFilter[ ] object can be manually added as well:
• router1424/ip/vrfRouter[ ]/routingFilter[ ]. Use this to set up a routing update filter; refer to 11.9.10 - Routing
filter configuration attributes on page 736.
This is illustrated in the following figure, where 2 vrfRouter[ ] objects have been created:
Other occurrences
There are other objects in the containment tree where a vrfRouter element is present:
• router1424/profiles/policy/traffic/ipTrafficPolicy[ ]. Use this to assign a traffic policy to a VRF router; refer to
11.7.1 - IP traffic policy configuration attributes on page 592.
• router1424/management/loopback and router1424/management/usrLoopback[ ]. Use these to add the loopback
interface to a VRF router; refer to 11.12 - Management configuration attributes on page 799.
• The ip structure, which occurs in several objects. The ip structure contains a vrfRouter element with
which you can assign an interface to a VRF Router. Refer to 5.2.2 - Where to find the IP parameters?
on page 55 and 5.2.3 - Explaining the ip structure on page 56.
7.10.3 Principle
Situation
Imagine following situation:
Network A and network B connect to the internet via the OneAccess device. Both routers use OSPF to
exchange routing information with the OneAccess device.
VRF
The information of router A and B can be kept apart using VRF:

In such a set up:

• the OneAccess router has two VRF router objects, vrfrouter[A] and vrfRouter[B], each with their own rout-
ing table.
• there are 2 different interfaces on the OneAccess device communicating with both OSPF networks.
This allows to keep traffic from routers A and B completely separated from one another; it is just as if the
OneAccess device has been split up in two separate devices.
7.11 Applying QoS on routed traffic
First, this section introduces QoS or Quality Of Service; it also introduces traffic policy on routed data,
and priority policy both on routed and on bridged data, since this is the same in both cases. Refer to the
following sections:
• 7.11.1 - Introducing QoS on page 260
• 7.11.2 - Introducing traffic and priority policy on page 262
• 7.11.3 - Traffic policy on routed and on bridged data on page 266
• 7.11.4 - Introducing priority policy for traffic shaping and policing on page 267
• 7.11.5 - Introducing priority policy for priority scheduling on page 268
This section also describes how to configure a traffic policy on routed data; refer to the following sections:
• 7.11.6 - IP traffic classification: 4 variants of IP traffic policy on page 269
• 7.11.7 - Configuring a traffic policy on routed data on page 273
• 7.11.8 - Creating a traffic policy on the router on page 274
• 7.11.9 - Applying a traffic policy on an IP interface of the router on page 276
• 7.11.10 - Applying a traffic policy as an extended access list on an IP interface on page 278
• 7.11.11 - The default queue attribute versus a traffic policy profile on page 286
Subsequently, it describes the configuration of priority policy on routed and bridged data; refer to the fol-
lowing sections:
• 7.11.12 - Priority policy on routed and on bridged data on page 289
• 7.11.13 - Configuring a priority policy on the router on page 290
• 7.11.14 - Creating a priority policy on page 291
• 7.11.15 - Applying a priority policy on an interface on page 293
Finally, all this is illustrated with an example:

• 7.11.16 - Configuring a traffic and priority policy on the router - an example on page 294
7.11.1 Introducing QoS
What is QoS?
Quality of Service (QoS) is the capability of a network to provide better service to certain network traffic
over various technologies (e.g.Frame Relay, ATM, Ethernet and IP networks that use any or all of these
underlying technologies). The primary goal of QoS is to provide priority including dedicated bandwidth,
controlled jitter and latency, and improved loss characteristics. Also important is making sure that pro-
viding priority for one or more flows does not make other flows fail.
QoS is not one attribute that you can set to “low”, “medium” or “high” quality. QoS is a collection of con-
figuration attributes located on different levels (e.g. queueing, PPP fragmentation, bandwidth control,
etc.).
The following table gives an overview of the features that can be used for QoS:
Protocol Feature
All 7 queues: 5 user configurable queues, a low delay queue and a system queue.
All Priority policies: FIFO, round robin, absolute priority, WFQ, low delay WFQ.
All Bandwidth control per queue with CIR / EIR values.
IP IP traffic classification based on access lists: trafficShaping, tosDiffServ &

tosMapped, queueMapped.
VLAN VLAN traffic classification based on 802.1P bits.
PPP PPP fragmentation.
PPP PPP multi-class.
PPP Improved load balancing for MLPPP.
Frame Relay Frame Relay fragmentation.
Frame Relay CIR / EIR on outgoing traffic.
Frame Relay CIR / EIR on incoming traffic.
ATM ATM traffic classes (UBR, VBR-rt, VBR-nrt, CBR).

Traffic classes
The Quality of Service mechanism is based on a total of 7 forwarding queues per interface, both physical
and logical. Queues are numbered 1 to 7 with 1 being the lowest priority and 7 the highest. Six of them
are for user data, while the last one is a system queue:
Queue Queue type Description
1-5 user configurable queue The user can decide which data goes into which queue.
6 low delay queue The user can decide which data goes into this queue. This
queue usually is addressed more often then the user con-
figurable queues.
7 system queue This queue is filled with mission critical data (e.g.link moni-
toring messages etc.) and has priority over all other queues.
7.11.2 Introducing traffic and priority policy
What is traffic and priority policy?
Because of the bursty nature of voice / video / data traffic, sometimes the amount of traffic exceeds the
speed of a link. At this point, the 1424 SHDSL Router has to decide what to do with this “excess” of traffic:
• Buffer the traffic in a single queue and let the first packet in be the first packet out?
• Or put packets into different queues and service certain queues more often (also known as priority
queuing)?
These questions are dealt with by the traffic and priority policy mechanisms:
• The traffic policy determines, on traffic overload conditions, how and which queues are filled with the
“excess” data. The traffic policy is not the same for routed data as the one for bridged data.
• The priority policy determines how and which queues are emptied. The priority policy is the same for
routed data as the one for bridged data. This is further dealt with in 7.11.4 - Introducing priority policy
for traffic shaping and policing on page 267, 7.11.5 - Introducing priority policy for priority scheduling
on page 268 and the following sections.
In other words, the mechanism to fill the queues is different for routed data and bridged data, but the
mechanism to empty the queues is the same for both routed and bridged data.
What is a priority queuing?
Using the traffic and priority policy features you can perform priority queuing. This allows you to define
how traffic is prioritised in the network. E.g. to ensure that voice, video or other streaming media is serv-
iced before (or after) other traffic types, to ensure that web response traffic is routed before normal web
browsing traffic, etc.
Per interface (both physical and logical), there are 7 queues:
Queue Queue type Description
1-5 user configurable queue The user can decide which data goes into which queue.
6 low delay queue The user can decide which data goes into this queue. This
queue usually is addressed more often then the user con-
figurable queues.
7 system queue This queue is filled with mission critical data (e.g.link moni-
toring messages etc.) and has priority over all other queues.
What is DiffServ?
Differentiated Services (DiffServ) differentiates between multiple traffic flows. So, packets are marked,
and routers and switches can then make decisions based on those markings (e.g., dropping or forward-
ing decisions). You can mark packets either with IP Precedence or Differentiated Service Code Point
(DSCP) markings.
What is the TOS byte?
The Type Of Service (TOS) byte is an eight bit field inside an IPv4 header. Using these bits you can mark
packets either with IP Precedence or Differentiated Service Code Point (DSCP) markings. The TOS byte
is structured as follows:
0 1 2 3 4 5 6 7
precedence field TOS field unused
DSCP field unused
What is IP Precedence?
IP Precedence uses the precedence bits (3 leftmost bits) of the TOS byte (see RFC 791). So IP Prece-
dence markings can range from 0 to 7. However, values 6 and 7 should not be used since they are
reserved for network use. IP precedence is being phased out in favour of DSCP, but is supported by
many applications and routers.
What is the TOS field?
The TOS field is a four bit field in the TOS byte (see RFC 1349). The TOS field lets values from 0 to 15
be assigned to request special handling of traffic (for example, minimize delay, maximize throughput).
The TOS field is being phased out in favour of DSCP.
What is DSCP?
A next step in the definition and application of the TOS byte is DSCP. Differentiated Services Code Point
(DSCP) uses the DSCP bits (6 leftmost bits) of the TOS byte (see RFC 2474). This offers a bigger gran-
ularity over IP Precedence, since 6 bits yield 64 possible values (0 to 63)1. The problem with so many
values is that the value you choose to represent a certain level of priority can be treated differently by a
router under someone else’s administration.
To maintain relative levels of priority among devices, the Internet Engineering Task Force (IETF)
selected a subset of those 64 values for use. These values are called per-hop behaviours (PHBs),
because they indicate how packets should be treated by each router hop along the path from the source
to the destination.
The four categories of PHBs are:
• Best Effort (BE)
• Expedited Forwarding (EF)
• Assured Forwarding (AF)
• Class Selector (CS)
1. This also means that DSCP is not compatible with IP Precedence.

What is BE PHB?
Best Effort Per-Hop Behaviour (BE PHB) means that all DSCP bits are 0 (i.e. a DSCP value of 0).
Best Effort does not truly provide QoS, because there is no reordering of packets. Best Effort uses the
first-in first-out (FIFO) queuing strategy, where packets are emptied from a queue in the same order in
which they entered it.
What is EF PHB?
Expedited Forwarding Per-Hop Behaviour (EF PHB, see RFC 3246) has a DSCP value of 46. Latency-
sensitive traffic, such as voice, typically has an EF PHB.
What is AF PHB?
Assured Forwarding Per-Hop Behaviour (AF PHB, see RFC 2597) is the broadest category of PHBs.
These are shown in the following table:
AF PHB Low drop preference Medium drop preference High drop preference
class 1 AF11 (10) AF12 (12) AF13 (14)

001010 001100 001110
class 2 AF21 (18) AF22 (20) AF23 (22)

010010 010100 010110
class 3 AF31 (26) AF32 (28) AF33 (30)

011010 011100 011110
class 4 AF41 (34) AF42 (36) AF43 (38)

100010 100100 100110
Note that the AF PHBs are grouped into four classes. Within each AF PHB class there are three distinct
values which indicate a packet’s drop preference. Higher values in an AF PHB class are more likely to
be discarded during periods of congestion. For example, an AF13 packet is more likely to be discarded
than an AF11 packet.
Note that since IP Precedence only examines the 3 leftmost bits, all AF PHB class 1 values would be
interpreted by an IP Precedence aware router as an IP Precedence value of 1, AF PHB class 2 values
as an IP Precedence value of 2, etc.
What is CS PHB?
Class Selector Per-Hop Behaviour (CS PHB, see RFC 2474) is used for backward compatibility with IP
Precedence. This because, just like IP Precedence, CS PHB only examines the 3 leftmost bits of the
TOS byte.
What is IEEE 802.1P or COS?
The IEEE 802.1P signalling technique (also often referred to as Class Of Service, COS) is an IEEE
endorsed specification for prioritising network traffic at the datalink/MAC sub-layer (layer 2).
802.1P is a spin-off of the 802.1Q (VLAN tagging) standard and they work in tandem. The 802.1Q stand-
ard specifies a tag that appends to a MAC frame. The VLAN tag carries VLAN information. The VLAN
tag has two parts: The VLAN ID (12-bit) and prioritisation (3-bit). The prioritisation field was never defined
in the VLAN standard. The 802.1P implementation defines this prioritisation field.
7.11.3 Traffic policy on routed and on bridged data
Refer to 7.11.2 - Introducing traffic and priority policy on page 262 for an introduction.
The traffic policy, i.e. the policy to fill the queues, is not the same for routed data as the one for bridged
data:
Traffic policy on routed data
In case … is enabled, then …
only routing the routed data is queued using the traffic

policy settings as configured in the ipTraf-
ficPolicy[ ] object under the profiles/policy/traf-
fic object.
Refer to 7.11.8 - Creating a traffic policy on the router on page 274.
Although a bridging traffic policy can still be configured, the preferred way to manipulate bridged traffic,
is to make use of access lists. These allow for extra configuration possiblities compared to bridge traffic
policies.
Refer to 8.5 - Bridge traffic classification by filtering on page 344 and 11.10.2 - Bridge access list config-
uration attributes on page 786 for more information.
Traffic policy on bridged data
only bridging the bridged data is queued using

the traffic policy settings as con-
figured in the bridgingTrafficPolicy[ ]
object under the profiles/policy/traf-
fic object.
Refer to 11.7.2 - Bridging traffic policy configuration attributes on page 603.
Traffic policy on routed and on bridged data
routing and bridging • the routed data is queued

using the traffic policy set-
tings as configured in the
ipTrafficPolicy[ ] object under
the profiles/policy/traffic object.
• the bridged data is queued using the traffic policy settings as configured
in the bridgingTrafficPolicy[ ] object under the profiles/policy/traffic object.
7.11.4 Introducing priority policy for traffic shaping and policing
• Whereas configuring a traffic policy for routed data is different than for bridged data, configuring a
priority policy is the same for both.
• The following figure shows the configuration attributes that have to be set for traffic shaping:
• On the Ethernet interfaces, a maximum outbound bandwidth can be configured. This allows limiting
the traffic sent out on the Ethernet interface below the physical bandwidth. Also refer to 9.3 - Tuning
the bandwidth on the LAN interface on page 376 for more information.
• Per queue, a committed information rate (CIR) and excess information rate (EIR) are configurable,
by setting the bandwidth attribute. Per queue the bandwidth is measured over a period of time. Traffic
above the CIR value is accepted up to a maximum rate CIR + EIR if there is sufficient bandwidth avail-
able, e.g. because there is currently no higher priority traffic on this outbound interface. If the maxi-
mum queue length is meanwhile reached, additional packets are dropped.
• The CIR and EIR traffic shaping parameters can be configured as absolute values or as relative val-
ues to the physical interface bandwidth, by setting the countingPolicy attribute.
• The CIR and EIR traffic shaping parameters have a configurable time interval. This can be set via the
tc attribute.
• The traffic shaping is applicable on inbound and outbound traffic.
• CIR and EIR statistics are available. The statistics include the number of packets that could be
directly transmitted, the number of packets that were first queued before they were sent, the number
of packets dropped, the total number of packets sent conform the CIR value and the total number of
packets sent conform the EIR value. The same statistics are also available expressed in bytes.
Refer to the ifOutPriorityQueues performance attribute for more information.
• Refer to 7.11.12 - Priority policy on routed and on bridged data on page 289 and the following sec-
tions for a detailed description of the configuration process of priority policies.
• Refer to 11.7.3 - Priority policy configuration attributes on page 605 for a detailed description of the
configuration attributes of priority policies.
7.11.5 Introducing priority policy for priority scheduling
• Whereas configuring a traffic policy for routed data is different than for bridged data, configuring a
priority policy is the same for both.
• The following figure shows the configuration attributes that have to be set for traffic shaping:
• The way that the configurable queues are transmitting data can be selected according to different
algorithms; this is also called Priority Queuing (PQ). It can be set using the queueConfigurations attribute.
Each queue has a quotum and a weight parameter:
- The quotum defines how much data is taken from the queue each time and is expressed in bytes
or packets, which can be set using the countingPolicy attribute.
- The weight parameter defines the relative number of times this queue is emptied.
• The algorithms that have been implemented, which can be selected via the algorithm attribute, are the
following:
- FIFO (first in first out): no separate priority queues are in use.
- Round Robin: the configurable queues all have equal weight.
- Absolute Priority: the queues have no weight nor quotum. A lower priority queue is emptied only
if all higher priority queues are empty.
- Weighted Fair Queuing: weights are configurable per configurable queue .
If the traffic classification is based on DSCP (tosDiffServ) bits, this is commonly called WFQ.
If the traffic classification is using traffic shaping, this is commonly called Class Based Weighted
Fair Queuing (CBWFQ).
- Low delay Weighted Fair Queuing: weights are configurable per configurable queue. Data in the
low delay queue is always emptied prior to any data in the user configurable queues. This is com-
monly called Low Latency Queuing (LLC).
• The number of bytes or packets that is dequeued from the low delay queue when the queue is
addressed, can be set via the lowDelayQuotum attribute. Again, whether it is expressed in bytes or pack-
ets, can be set via the countingPolicy attribute.
• Refer to 7.11.12 - Priority policy on routed and on bridged data on page 289 and the following sec-
tions for a detailed description of the configuration process of priority policies.
• Refer to 11.7.3 - Priority policy configuration attributes on page 605for a detailed description of the
7.11.6 IP traffic classification: 4 variants of IP traffic policy
The classification of the traffic between the different queues occurs through an IP traffic policy. There
are 4 variants of IP traffic policy, which can be selected via the method attribute; these variants are:
• Customised policy.
• TosDiffserv.
• TosMapped.
• QueueMapped.
These are further explained below:
Customised policy
• Based on a variety of TCP/IP protocol parameters, a complete customised policy may be set. The
elements that define how the traffic is forwarded to a certain priority queue are the following:
- Source and destination IP address range
- Type Of Service (TOS) value range (8 bits in the IP header, also called DSCP bits)
- IP protocol (examples are any (0), ICMP (1), IGMP (2), TCP (6), UDP (17))
- Source and destination port range for UDP / TCP packets
- Existing priority colour (suitable for outbound traffic policies)
• Traffic that meets an entry in the traffic policy can be remarked with a different TOS/DSCP value, or
the priority can be coloured for further processing (independent of the TOS/DSCP setting). The max-
imum queue length in packets (before packets are dropped) is configurable via the dropLevels attribute.
• To configure traffic shaping, proceed as follows:
- Add an ipTrafficPolicy[ ] object.
- Set the method attribute to trafficShaping.
- Configure the trafficShaping tabel; refer to 11.7.1 - IP traffic policy configuration attributes on
page 592.
- Configure the maximum queue length using the dropLevels attribute.
These attributes are shown in the following figure:
• Refer to 7.11.7 - Configuring a traffic policy on routed data on page 273 for a detailed description of
the configuration process of IP traffic policies.
• Refer to 11.7.1 - IP traffic policy configuration attributes on page 592 for a detailed description of the
configuration attributes of IP traffic policies.
• Performance information is available on classified traffic: discarded packets and usage of each line
in the traffic-shaping table; refer to 13.10 - IP traffic policy performance attributes on page 1097.
TosDiffServ
• The data is redirected to the queues based on DiffServ (RFCs 2474, 2475) regarding class and drop
precedence. This means that, depending on their Type Of Service (TOS) field, some packets are
moved to other queues and/or dropped sooner than other packets in case the queue is full.
• The highest 3 bits of the TOS/DSCP field are mapped as follows:
Bit values correspond with
000 up to 100 queues 1 up to 5, respectively
101 and higher the low delay queue
• The next 2 bits of the TOS/DSCP field define the drop levels:
Bit values packets are dropped if
00 and 01 the queue length exceeds a configurable maximum length, which can be set with
dropLevel1 element of the dropLevels attribute.
10 the queue length exceeds a configurable maximum length, which can be set with
11 the queue length exceeds a configurable maximum length, which can be set with
• To configure a DiffServ IP traffic policy, proceed as follows:

- Set the method attribute to tosDiffServ.
TosMapped
• This simple and flexible policy allows classifying the traffic based on a user-defined range of the TOS
field into one of the queues The maximum queue length in packets (before packets are dropped) is
configurable via the dropLevels attribute.
• Which traffic is forwarded to which specific priority queue is set in the tos2QueueMapping tabel. If an
overload condition occurs, then a packet is redirected to the specified queue when the criteria as
specified in the tos2QueueMapping table are met.
• To configure a tosMapped IP traffic policy, proceed as follows:
- Set the method attribute to tosMapped.
- Configure the tos2QueueMapping tabel; refer to 11.7.1 - IP traffic policy configuration attributes on
page 592.
QueueMapped
• This outbound policy maps previously coloured packets (packets that already have a certain priority,
e.g. by passing an inbound traffic policy) to a priority queue. This allows grouping differently coloured
packets to a single priority queue. The maximum queue length in packets (before packets are
dropped) is configurable via the dropLevels attribute.
• Which traffic is forwarded to which specific priority queue is set in the queue2QueueMapping tabel. If an
overload condition occurs, then a packet is redirected to the specified queue when the criteria as
specified in the queue2QueueMapping table are met.
• To configure a queueMapped IP traffic policy, proceed as follows:
- Set the method attribute to queueMapped.
- Configure the queue2QueueMapping tabel; refer to 11.7.1 - IP traffic policy configuration attributes on
page 592.
7.11.7 Configuring a traffic policy on routed data
To configure a traffic and priority policy for the routed data on a certain interface, proceed as follows:
Step Action
1 Create and configure a routing traffic policy.

Refer to 7.11.8 - Creating a traffic policy on the router on page 274.
2 Apply the routing traffic policy on the desired interface.

Refer to 7.11.9 - Applying a traffic policy on an IP interface of the router on page 276.
7.11.8 Creating a traffic policy on the router
To create and configure a traffic policy for the routed data on a certain interface, proceed as follows:
Step Action

profiles/policy/traffic object and add an ipTrafficPolicy[ ]
object underneath (refer to 4.4 - Adding an object to
2 In the traffic policy object you just added, go to the

method attribute. Use this attribute to choose a traffic
policy method. This traffic policy is then used to
determine, on traffic overload conditions, how and
which queues are filled with the “excess” data.
Refer to method on page 593 for more information.
3 Now, depending on which traffic policy method you selected, you have to configure the
actual policy criteria:
If you choose the then use the following attribute to configure the policy
method … criteria:
trafficShaping, • trafficShaping.
• dropLevels (only the dropLevel1 element).
tosDiffServ, dropLevels.
tosMapped, • tos2QueueMapping.
queueMapped • queue2QueueMapping.
For more information, refer to …

• trafficShaping on page 595.
• dropLevels on page 598.
• tos2QueueMapping on page 600.
Example - creating a traffic policy on the router
Suppose you create a traffic policy which uses the traffic shaping method to fill the queues, on traffic
overload conditions, with the “excess” data. Suppose you want to do this for the UDP protocol only.
7.11.9 Applying a traffic policy on an IP interface of the router
Refer to 7.11.7 - Configuring a traffic policy on routed data on page 273 for an overview on how to con-
figure a traffic policy.
Traffic policy on outbound traffic
To apply a traffic policy for the routed data on a certain interface, enter the index name of the earlier
created traffic policy object as value of the trafficPolicy element:
1. Add and configure a profiles/policy/traffic/ipTrafficPolicy[ ] object. E.g. ipTrafficPolicy[myOutList].
2. Apply the traffic policy by typing the index name of the ipTrafficPolicy[ ] object as value of the trafficPolicy
element in the ip structure (e.g. “myOutList”). The trafficPolicy element can be found in the ip structure of
the IP interface. Refer to 5.2.2 - Where to find the IP parameters? on page 55 for the location of the
ip structure on the different IP interfaces.
Traffic policy on inbound traffic: access policy
A traffic policy can also be applied as an access policy. This is actually a trafficPolicy that is being applied
before the actual routing takes place, so it can be seen an inbound access list. To apply an access policy
for the routed data on a certain interface, proceed as follows:
1. Add and configure a profiles/policy/traffic/ipTrafficPolicy[ ] object. E.g. ipTrafficPolicy[myInList].
2. Apply the traffic policy by typing the index name of the ipTrafficPolicy[ ] object as value of the accessPolicy
element in the ip structure (e.g. “myInList”).
The following figure illustrates the terms access policy and traffic policy:
Example - applying a traffic policy on an interface of the router
Suppose you created and configured a traffic policy object with index name myTrafPol (i.e. trafficPol-
icy[myTrafPol]), and you want to apply this traffic policy on an L2TP tunnel you created earlier.
7.11.10 Applying a traffic policy as an extended access list on an IP interface
What is an extended access list?
Access lists control the access to or from an interface for a number of specified services or IP addresses.
The access list describes the condition to forward (permit) packets to an interface or to drop (deny) them.
When access lists are combined with NAT/PAT translation, then first the conditions of the access list are
applied before the NAT/PAT translation is done.
On the 1424 SHDSL Router, the extended access lists are implemented using the traffic policy function
and by defining traffic shaping rules.
Setting up an extended access list on an IP interface
In order to set up an extended access list, proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to

the profiles/policy/traffic object and add an ipTrafficPolicy[
] object underneath
2 In the traffic policy object you just created, make sure that the configuration attribute
method is set to trafficShaping (this is the default value):
3 Configure the configuration attribute trafficShaping to match you filter criteria; refer to 11.7.1
- IP traffic policy configuration attributes on page 592.
4 Apply the traffic policy on the desired interface. See below.
Setting up an inbound extended access list on an IP interface
1. Go to the ip attribute of the interface on which you want to apply your extended access
list.
For example, suppose you want to apply an extended access list on the LAN inter-
face, then go to lanInterface object and then go to the ip attribute.
2. In the ip attribute, enter the index name of the traffic policy object you created in step
1 as value of the accessPolicy element.
In this example, enter the string myTrafPol as value of the accessPolicy element.
Step Action
5 Setting up an outbound extended access list on an IP interface
1. Go to the ip attribute of the interface on which you want to apply your extended access
list.
For example, suppose you want to apply an extended access list on the LAN inter-
face, then go to lanInterface object and then go to the ip attribute.
2. In the ip attribute, enter the index name of the traffic policy object you created in step
1 as value of the trafficPolicy element.
In this example, enter the string myTrafPol as value of the trafficPolicy element.
Tuning an extended access list on an IP interface
Above, it is explained how to set up an extended access list, this section shows you how to tune the
access list. I.e. how to define the filter criteria.
You have to define your filter criteria in the trafficShaping attribute. This is a table, which is empty by default,
but to which you can add several lines (entries).
The following figure shows a screenshot of the trafficShaping table containing one line:
As it shows from the elements in the trafficShaping table, you can filter on several criteria:
Filter criterion Description
IP addresses • 1 IP address: enter an IP address in the element sourceIpStartAddress and/or

destinationIpStartAddress.
• IP address range: enter an IP address range using the elements …
- sourceIpStartAddress and sourceIpEndAddress and/or
- destinationIpStartAddress and destinationIpEndAddress
So if you define 1 or more IP addresses in the trafficShaping table, then traffic from
(source) or to (destination) these IP addresses is allowed. All other traffic is dis-
carded.
IP protocol Specify an IP protocol using the ipProtocol element. Either select one of the common
IP protocols from the ipProtocol element its drop-down box, or directly type a specific
protocol number in the ipProtocol element field.
So if you define an IP protocol in the trafficShaping table, then traffic carrying this IP
protocol is allowed. All other traffic is discarded.
Filter criterion Description
port number • 1 port number: enter a port number in the element sourcePortStart and/or
destinationPortStart.
• port number range: enter a port number range using the elements …
- sourcePortStart and sourcePortEnd
- and/or
- destinationPortStart and destinationPortEnd
So if you define 1 or more port numbers in the trafficShaping table, then traffic carry-
ing these port numbers is allowed. All other traffic is discarded.
You can not filter on port numbers only. What is more, you can only filter on
port numbers when the IP protocol is set to TCP or UDP. So in other words,
if the IP protocol element is set to a value different from TCP or UDP, then
all the port elements are ignored.
Type Of Service • 1 TOS value: enter a TOS value in the element tosStartValue.
(TOS) value • TOS value range: enter a TOS value range using the elements tosStartValue and
tosEndValue.
So if you define 1 or more TOS values in the trafficShaping table, then traffic carrying
these TOS values is allowed. All other traffic is discarded.
Remarks on extended access lists on an IP interface
• By default, the entries in the trafficShaping table are “allow” rules. I.e. only the traffic defined in the table
is permitted, all other traffic is discarded (independent whether the traffic shaping table is used as an
access list, for priority policing or policy based routing). However, you can inverse an entry making it
a “deny” rule by entering “discard” as value of the interface element.
• If more than one entry applies to the same packet, then the entry which has the narrowest filter range
(when looking at the filter criteria from left to right) is chosen. For example: two rows in the trafficShaping
table apply to the same packet, but row 1 wants to forward packets to queue 3 and row 2 wants to
forward packets to the low delay queue. In that case, first the IP source address is considered. The
row with the smallest range wins. If the ranges are exactly the same, then the IP destination address
is considered. And so on. Should the two rows be completely identical except for the queue, then one
of the rows is chosen at random.
• You do not necessarily have to fill in IP addresses in the trafficShaping table. It is perfectly valid to filter
on IP protocol, IP protocol/port combination or TOS values only. However, you can not filter on port
numbers only. What is more, you can only filter on port numbers when the IP protocol is set to TCP
or UDP. So in other words, if the IP protocol element is set to a value different from TCP or UDP, then
all the port elements are ignored.
Example - configuring an extended access list
This is an example of a network connected to the Internet and for which the following conditions are
required:
• only 5 stations may have access to the Internet.
• only the HTTP-port for web browsing is open for incoming packets from the Internet.
The following figure shows how to configure the extended access lists:
7.11.11 The default queue attribute versus a traffic policy profile
In case of a Frame Relay DLCIs and multiclass PPP links, it is possible to assign a default queue to the
link. This allows you to easily set up a traffic policy without having to create and apply a traffic policy
profile. As most setups that require QoS only split voice and data streams (often based on IP addresses
only), configuring such a setup becomes more straightforward.
To configure a default queue, proceed as follows:
Step Action
1 Create a …
• Frame Relay DLCI. Refer to 6.6.2 - Configuring Frame Relay DLCIs on page 150.
or
• multiclass PPP link. Refer to 6.7.13 - Setting up multiclass PPP on page 183.
2 In the dlciTable (Frame Relay) or the multiclassInterfaces table (PPP), set the defaultQueue ele-
ment to the desired queue (e.g. queue3).
⇒In case of an overload condition, this queue will be filled with the excess data.
3 Now you still have to create and apply a priority policy to empty the queue. Do this as
described in 7.11.14 - Creating a priority policy on page 291 and 7.11.15 - Applying a pri-
ority policy on an interface on page 293.
The following figure shows where the defaultQueue attribute is located:

Example - configuring a default queue
Suppose you have a network connected to two other networks over a Frame Relay backbone. Network
1 carries a mix of data and voice traffic. You want that the data traffic is routed from network 1 to network
2 and that the voice traffic is routed from network 1 to network 3. If congestion should occur you want
that the data is queued in queue 1 and that the voice is queued in the low delay queue. The algorithm
that you want to use to empty the queues is the low delay weighted fair queueing mechanism.
Step Action
1 Set up two Frame Relay DLCIs.

For example:
• Configure one Frame Relay DLCI that carries the data traffic, e.g. dlciTable/name = dat-
aDlci.
• Configure another Frame Relay DLCI that carries the voice traffic, e.g. dlciTable/name =
voiceDlci.
Since this is not the main subject of this example, refer for more information on creating
Frame Relay DLCIs to 6.6.2 - Configuring Frame Relay DLCIs on page 150.
2 Set the correct default queue for the DLCIs you just created. I.e. queue 1 for the data
DLCI and queue 6 (i.e. low delay queue) for the voice DLCI.
3 Create and apply a priority policy. The priority policy uses the low delay weighted fair
queueing mechanism to empty the queues.
4 Create routes to the other networks.

The following figure shows how to configure the traffic and priority policy you want to set up:
7.11.12 Priority policy on routed and on bridged data
• A priority policy determines how and which queues are emptied.

• The priority policy is the same for routed and bridged data.
• The queues are emptied using the priority policy settings as con-
figured in the priorityPolicy[ ] object under the profiles/policy/priority
object.
• Refer to 7.11.13 - Configuring a priority policy on the router on
page 290 for a detailed description of the configuration process of
priority policies.
• Refer to 11.7.3 - Priority policy configuration attributes on page 605 for a detailed description of the
7.11.13 Configuring a priority policy on the router
To configure a traffic and priority policy for the routed data on a certain interface, proceed as follows:
Step Action
1 Create and configure a priority policy.

Refer to 7.11.14 - Creating a priority policy on page 291.
2 Apply the priority policy on the desired interface.

Refer to 7.11.15 - Applying a priority policy on an interface on page 293
7.11.14 Creating a priority policy
Whenever a priority policy is applied on an interface, a delay optimisation mechanism is activated auto-
matically in order to guarantee a minimum delay for high priority packets.
This applies to all types of priority policies, except fifo.
To create and configure a priority policy for a certain interface, proceed as follows:
Step Action

profiles/policy/priority object and add a priorityPolicy[ ] object
underneath (refer to 4.4 - Adding an object to the con-
tainment tree on page 45).
2 In the priority policy object you just

added, go to the algorithm attribute.
Use this attribute to determine how
and which queues are emptied.
Refer to algorithm on page 606 for more
information.
3 Configure the other attributes in the priority policy object. The most important are:
• queueConfigurations. Use this attribute to …
- set the number of bytes/packets that is dequeued from the user configurable
queue when the queue is addressed.
- set the relative importance of the user configurable queues.
Refer to queueConfigurations on page 608 for more information.
• lowDelayQuotum. Use this attribute to set the number of bytes/packets that is dequeued
from the low delay queue when the queue is addressed.
Refer to lowdelayQuotum on page 608 for more information.
• bandwidth. Use this attribute to set the Committed Information Rate (CIR) per queue.
Refer to bandwidth on page 609 for more information.
• tc. Use this attribute to set the time interval with which the CIR/EIR quota on the
queues is updated. The default value is 50 ms; the user can change this interval to
any multiple of 50 ms ranging from 50 ms up to 1 sec.
• countingPolicy. Use this attribute to define whether the quotum of the queues is
expressed in bytes or packets.
Example - creating a traffic policy on the router
Suppose you create a priority policy which uses the round-robin algorithm to empty the queues.
7.11.15 Applying a priority policy on an interface
To apply a priority policy on a certain interface, enter the index name of the earlier created priorityPolicy[ ]
object as value of the priorityPolicy attribute. The priorityPolicy attribute can be specified for …
• the LAN interface;
• the EFM interface;
• each PPP bundle;
• each ATM PVC;
• L2TP tunnels;
• IPsec L2TP tunnels;
• GRE tunnels;
• IPsec GRE tunnels;
Refer to the configuration attributes of these items for more detailed information.
Example - applying a priority policy on an interface
Suppose you created and configured a priority policy object with index name myPrioPol (i.e. priorityPol-
icy[myPrioPol]), and you want to apply this priority policy on an ATM PVC profile you created earlier.
7.11.16 Configuring a traffic and priority policy on the router - an example
Suppose you have two networks which are interconnected over an ATM network. Network 1 carries a
mix of data and voice traffic. The traffic on this network is differentiated by setting the Type Of Service
(TOS) values in the IP packet headers (data = 0, voice = 10). If congestion occurs when routing the traffic
from network 1 to network 2, then you want that the voice traffic is queued in the low delay queue and
that the data traffic is queued in queue 1. The algorithm that you want to use to empty the queues is the
low delay weighted fair queueing mechanism.
Step Action
1 Create and configure an IP traffic policy and a priority policy.

For example:
• Create a trafficPolicy[myIpPol] object.
• Set the method attribute to tosMapped.
• In the tos2QueueMapping structure, create two entries and define the startTos, endTos and
interface elements of each entry. Also set the targetQueue for both types of traffic:
- the low delay queue for the voice.
- queue 1 for the data.
• Create a priorityPolicy[myPrioPol] object and set the algorithm attribute to lowDelayWeighted-
FairQueueing.
2 Set up the ATM PVC.

Since this is not the main subject of this example, refer for more information on setting
up an ATM PVC to 6.2.2 - Configuring ATM PVCs on page 110.
3 Create a route that “points” to the traffic policy you created earlier.
For example:
Create an entry in the routingTable attribute in which you specify that traffic destined for net-
work 192.168.48.0 has to be sent to the IP traffic policy you created earlier.
Depending on the location of the priorityPolicy[ ] and trafficPolicy[ ] objects in the tree, refer to the following
figures:
User manual Configuring bridging and VLANs
8 Configuring bridging and VLANs
view.
This chapter introduces bridging on the 1424 SHDSL Router and lists the attributes you can use to con-
figure bridging.
• 8.1 - Introducing bridging on page 298
• 8.2 - Configuring bridging on page 311
• 8.3 - Configuring VLANs on page 325
• 8.4 - Configuring VLANs on the 4 port Ethernet switch on page 336
• 8.5 - Bridge traffic classification by filtering on page 344
• 8.6 - Bridge traffic classification by applying QoS on bridged traffic on page 352
• 8.7 - Example: combining bridging and routing in a network on page 360
Router.
8.1 Introducing bridging
This section introduces the bridging concept. The following gives an overview of this section:
• 8.1.1 - What is bridging? on page 299
• 8.1.2 - The self-learning and Transparent Spanning Tree bridge on page 300
• 8.1.3 - The Rapid Spanning Tree and Multiple Spanning Tree Protocol on page 301
• 8.1.4 - The Spanning Tree root bridge on page 303
• 8.1.5 - The Spanning Tree topology on page 304
• 8.1.6 - The Spanning Tree bridge port states on page 306
• 8.1.7 - The Spanning Tree Bridge Protocol Data Unit on page 307
• 8.1.8 - The Spanning Tree behaviour on page 308
• 8.1.9 - The Spanning Tree priority and cost on page 309
8.1.1 What is bridging?
The 1424 SHDSL Router can be configured to act as a bridge. This enables you to split up your LAN
network into smaller parts or segments. This decreases the amount of data traffic on the separated LAN
segments and, consequently, increases the amount of available bandwidth.
Example
The following figure shows an example of bridging:
Data coming from network 1, will only be let through by the bridge if this data has a destination outside
network 1 or if it has a broadcast or multicast address. This means the bridge filters the data and
decreases the amount of data traffic on the separated LAN segments.
8.1.2 The self-learning and Transparent Spanning Tree bridge
The 1424 SHDSL Router features two bridging mechanisms:

• self-learning bridging,
• self-learning bridging in conjunction with the Spanning Tree Protocol (STP).
Bridging principle Description
self-learning The bridge learns which data it has to forward to the other LAN segment and
which data it has to block. I.e. it builds its own bridging table.
In other words, you do not have to configure a bridging table with MAC
addresses of stations that are located on the separated LAN segments but that
have to be able to communicate with each other.
self-learning + STP This is based on the self-learning principle, but a protocol is used to implement
the STP algorithm.
Bridging loops
The primary goal of this algorithm is to avoid that bridging loops arise. A bridg-
ing loop occurs when two self-learning bridges are placed in parallel. This
results in data that keeps circling around as each bridge forwards the same
data.
The STP algorithm
Using the STP algorithm, bridges know of each others existence. By communi-
cating with each other, they establish one single path for reaching any particu-
lar network segment. If necessary, they may decide to disable some bridges in
the network in order to establish this single path.
This is a continuous process. So if a bridge fails, the remaining bridges will
reconfigure their bridging tables keeping each LAN segment reachable.
8.1.3 The Rapid Spanning Tree and Multiple Spanning Tree Protocol
Rapid Spanning Tree Protocol or RSTP
• RSTP supersedes the Spanning Tree Algorithm and Protocol (STP - IEEE 802.1D) that was already
implemented. RSTP interoperates with STP to facilitate migration. Bridges conforming to either spec-
ification can be used in the same network without configuration restrictions beyond those previously
imposed by STP.
• If it is absolutely necessary that the old STP protocol is used, it must be configured as such. Under
normal circomstances, the Rapid Spanning Tree Protocol is always applied.
• The Rapid Spanning Tree Protocol (RSTP) configures the port state of each bridge port. RSTP
ensures ...
- stable connectivity within the bridging network.
- that temporary loops in the active topology do not occur if the network has to reconfigure in
response to the failure, removal, or addition of a network component, and that erroneous station
location information is removed from the filtering database after reconfiguration.
Also refer to 11.10.1 - Bridge group configuration attributes on page 772 for more information.
Multiple Spanning Tree Protocol or MSTP
• The design of the Multiple Spanning Tree Protocol (STP - IEEE 802.1Q) is based on that of the Rapid
Spanning Tree Protocol, extended to provide the capability for frames assigned to different VLANs
to be transmitted along different paths within MST Regions. In other words, MSTP allows frames
assigned to different VLANs to follow separate paths through the network.
• For this, VLAN groups must be created. Each VLAN group can have its own path within the spanning
tree domain.
• The path for each VLAN group is determined by the path cost, like RSTP but for each VLAN group
separately.
If, however, the path cost of two paths are identical, the priority of the interface determines the path.
• When VLAN groups are defined in the network, they must be configured consistently and identically
throughout the whole MSTP network. Otherwise, connection problems will arise.
• MSTP is compatible and interoperable with STP and RSTP, without requiring any extra settings or
adjustments.
• Different regions, each uniquely identifiable, can be interconnected into one big MST network.
• The following figure illustrates the principles of MSTP and VLAN groups:
Also refer to ...

• 8.3.5 - Adding a VLAN group on page 335
• 11.10.1 - Bridge group configuration attributes on page 772
• 11.10.3 - VLAN group configuration attributes on page 793
... for more information.
8.1.4 The Spanning Tree root bridge
What is the root bridge?
Spanning Tree defines a tree with a root bridge and a loop-free path from the root to all bridges in the
extended network. The root bridge is the logical centre of the Spanning Tree topology.
Redundant data paths are forced into a stand-by (blocked) state. If a network segment in the spanning
tree fails and a redundant path exists, the spanning-tree algorithm recalculates the spanning-tree topol-
ogy and activates the stand-by path.
How is a root bridge selected?
All bridges in the network participating in Spanning Tree gather information about other bridges in the
network. They do this through an exchange of data messages called Bridge Protocol Data Units
(BPDUs).
This exchange of messages results in the following phases:
Phase Description
1 The selection of a root bridge.

The bridge with the highest bridge priority (i.e. the lowest numerical priority value) is
selected as the root bridge. If all bridges are configured with the default priority (32768),
the bridge with the lowest MAC address becomes the root bridge.
2 The selection of a designated bridge for every bridged LAN segment.
3 The removal of loops in the bridged network by blocking bridge ports connected to redun-
dant links.
8.1.5 The Spanning Tree topology
Port roles
The cost factor is used to calculate the distance from each port of a bridge to the root bridge. On the
basis of this, each port on a bridge is assigned one of the following roles:
Port role Description
root port The port that is closest to the root bridge, i.e. it provides that lowest cost path to
the root bridge. Only one port on each bridge is assigned as the root port.
designated port • Each LAN in the bridged Local Area Network has an associated root path cost.
This is the root path cost of the lowest cost bridge with a bridge port connected
to that LAN. This bridge is selected as the designated bridge for that LAN. If
there are two or more bridges with the same root path cost, then the bridge with
the best priority (least numerical value) is selected as the designated bridge.
• The bridge port on the designated bridge that is connected to the LAN is
assigned the role of designated port for that LAN. If the designated bridge has
two or more ports connected to the LAN, then the bridge port with the best pri-
ority port identifier (least numerical value) is selected as the designated port.
• The root bridge itself only has designated port.
disabled Frames (with the exception of Configuration BPDUs) are not accepted or transmit-
ted by the port when it is in the blocking state. The port can be said to be in stand-
by.
alternate and • Port roles of alternate port and backup port are assigned to bridge ports that
backup can provide connectivity if other network components fail.
• Any operational bridge port that is not a root or designated port is a backup port
if that bridge is the designated bridge for the attached LAN, and an alternate
port otherwise.
• An alternate port offers an alternate path in the direction of the root bridge to
that provided by the bridge’s own root port, whereas a backup port acts as a
backup for the path provided by a designated port in the direction of the leaves
of the spanning tree.
• Backup ports exist only where there are two or more connections from a given
bridge to a given LAN; hence, they (and the designated ports that they back up)
can only exist where two ports are connected together in loopback by a point-
to-point link, or where the bridge has two or more connections to a shared
media LAN.
master The role of master port has been introduced for the Multiple Spanning Tree Proto-
col.
A port which is a root port, and that receives spanning tree information from
another MST region, is assigned the role of master.
Connectivity
• In a Bridged Local Area Network whose physical topology is stable, i.e RSTP has communicated con-
sistent information throughout the network, every LAN has one and only one designated port, and
every bridge with the exception of the root bridge has a single root port connected to a LAN.
Since each bridge provides connectivity between its root port and its designated ports, the resulting
active topology connects all LANs and will be loop free.
• Each port ’s role can change if a bridge, bridge port, or LAN fails, is added to, or removed from the
network.
Port state transitions to learning and forwarding are delayed, and ports can temporarily transition to
the discarding state to ensure that misordering and duplication rates remain negligible.
Example
An elementary example of a Spanning Tree topology is given in the figure below:
8.1.6 The Spanning Tree bridge port states
Bridge port states
There are four possible states a bridge port can be in:
State A port in this state …
discarding • does no frame forwarding.

• does not incorporate station location into its address database (there is no
learning on a blocking port, so there is no MAC address database update).
• receives and processes BPDUs, but does not propagate them.
learning • does no frame forwarding.

• incorporates station location into its MAC address database.
• receives, processes and propagates BPDUs.
forwarding • forwards frames.

• incorporates station location into its MAC address database.
• receives, processes and propagates BPDUs.
Bridge port state transition diagram
The following figure shows how a bridge port moves through the differ-
ent states when the bridge is powered:
When you enable Spanning Tree, every bridge in the network goes
through the transitory states of discarding and learning at power up. If
properly configured, each port stabilises to the forwarding or discarding
state.
When the spanning-tree algorithm places a port in the forwarding state,
the following process occurs:
1. The port is put into the discarding state while it waits for protocol
information that suggests it should go to the learning state.
2. The port waits for the expiration of the forward delay timer, moves
the port to the learning state, and resets the forward delay timer.
3. In the learning state, the port continues to block frame forwarding as
it learns station location information for the forwarding database.
4. The port waits for the expiration of the forward delay timer and then moves the port to the forwarding
state, where both learning and forwarding are enabled.
8.1.7 The Spanning Tree Bridge Protocol Data Unit
What is a BPDU?
To establish a stable path, each bridge sends Configuration Bridge Protocol Data Units (BPDUs) to its
neighbouring bridges. These Configuration BPDU messages contain information about the spanning
tree topology. The contents of these frames only changes when the bridged network topology changes
or has not been established.
Each Configuration BPDU contains the following minimal information:
• The unique bridge identifier of the bridge that the transmitting bridge believes to be the root bridge.
• The cost of the path to the root from the transmitting port.
• The unique port identifier of the transmitting port.
When a bridge transmits a BPDU frame, all bridges connected to the LAN on which the frame is trans-
mitted receive the BPDU. When a bridge receives a BPDU, it does not forward the frame. Instead, it uses
the information in the frame to:
• calculate a BPDU,
• initiate a BPDU transmission if the topology changes.
The propagation of Configuration BDPUs
When a bridged network is in a stable condition, switches continue to send Configuration BPDUs to its
neighbouring bridges at regular intervals. Configuration BPDUs are transmitted down the spanning tree
from designated ports to root ports. If a Configuration BPDU is not received by the root port of a bridge
within a predefined time interval (for example, because a bridge along the path has dropped out), the
port enters the listening state to re-determine a stable path.
Message age
To ensure that old information does not endlessly circulate through redundant paths in the network and
prevent propagation of new information, each configuration message includes a message age and a
maximum age. The message age is incremented on receipt, and the information discarded if it exceeds
the maximum. Thus the number of bridges the information can traverse is limited.
8.1.8 The Spanning Tree behaviour
The following are some examples of how Spanning Tree behaves when certain events occur in your net-
work.
Bridging loops
Bridges connected in a LAN must

detect potential bridge loops. They
must then remove these loops by
blocking the appropriate ports to
other bridges.
This is illustrated in the following fig-
ure:
An alternate path has been estab-
lished by connecting Bridge B in par-
allel with Bridges A and C. This also
creates a potential bridge loop. How-
ever, by using the Spanning Tree
Algorithm, Bridge B breaks the loop and blocks its path to segment 3.
Bridge failure

also detect bridge failure. They must
then establish an alternative path.
Should the root bridge fail, also a
new root bridge must be selected.
A bridge failure is illustrated in the
following figure:
If Bridge A fails, the Spanning Tree
Algorithm must be capable of acti-
vating an alternative path, such as
Bridge B.
Network extension

also detect topology changes. They
must adapt to these changes.
A topology change is illustrated in
the following figure:
If the network is extended by adding
Bridge D, the Spanning Tree Algo-
rithm must be capable of adapting
automatically to the new topology.
This means that Bridge B stops loop-
ing by blocking the path to segment
3.
8.1.9 The Spanning Tree priority and cost
Consider the following Spanning Tree Topology:
What is bridge priority?
In the example above, Bridge A is selected as the root bridge. This because the bridge priority of all the
bridges is set to the default value (32768) and Bridge A has the lowest MAC address. However, due to
traffic patterns or link types, Bridge A might not be the ideal root bridge.
By increasing the bridge priority (lowering the numerical priority value) of the ideal bridge so that it
becomes the root bridge, you force a Spanning Tree recalculation to form a new spanning-tree topology
with the ideal bridge as the root.
What is port priority and path cost?
When the spanning-tree topology is calculated based on default parameters, the path between source
and destination stations in a bridged network might not be ideal. The goal is to make the fastest link the
root port.
For example, assume on Bridge B that …
• port 1, currently the root port, is an unshielded twisted-pair link,
• port 2 is a fibre-optic link.
Network traffic might be more efficient over the high-speed fibre-optic link. By changing the spanning-
tree port priority or path cost for port 2 to a higher priority (lower numerical value) than port 1, port 2
becomes the root port.
Note that path cost is linked to a port of the bridge, not to the bridge itself.
Example
By changing the priority and/or the pathCost, you can create a "preferred" path:
By setting the path costs of the entry ports of Bridge B and C to a lower value than the path cost of the
entry port of Bridge Z, you can create a preferred path through Bridge B and C.
To get from bridge A to bridge D, the path cost via bridge B and C is 20; via bridge Z, it is 100. The path
through Bridge Z becomes the back-up path.
8.2 Configuring bridging
This section lists the attributes you can use to configure bridging. The following gives an overview of this
section:
• 8.2.1 - Introducing the bridging attributes on page 312
• 8.2.2 - Configuring the bridge group on page 313
• 8.2.3 - Adding a bridge group on page 314
• 8.2.4 - Enabling bridging on an interface on page 316
• 8.2.5 - Configuring bridging on an interface on page 317
• 8.2.6 - Explaining the bridging structure on page 318
8.2.1 Introducing the bridging attributes
What is a bridge group?
A bridge group comprises the main bridging process. So in the containment tree, the bridgeGroup object
contains the general bridging attributes.
What are multiple bridge groups?
The 1424 SHDSL Router offers the possibility to create multiple bridge groups. This means you can
group some interfaces in one bridge group while you group several other interfaces in another bridge
group. By doing so, it is as if you created several “simple” bridge devices within one device.
Bridging on the different interfaces
In addition to configuring the general bridging process using the configuration attributes of the bridge
group, you also have to configure bridging on each interface on which you want to use bridging.
8.2.2 Configuring the bridge group
Refer to …
• 8.1 - Introducing bridging on page 298 for an introduction on bridging.
• 8.2.1 - Introducing the bridging attributes on page 312 for an introduction on the bridging attributes.
This section lists the most important configuration attributes of the bridge group.
Configuring an IP address on the bridge group
As on other interfaces (LAN, PVCs, etc.), you can

configure an IP address on the bridge group. Do
this using the configuration attribute ip on page 774.
What is more, if you enable bridging on the LAN interface (mode = bridging), then the settings of the con-
figuration attribute ip are ignored. So in this case, if you want to manage the 1424 SHDSL Router via IP,
then you have to configure an IP address in the bridgeGroup object instead.
Selecting the bridging protocol
Refer to 8.1.2 - The self-learning and Transparent Spanning Tree bridge on page 300 for an introduction.
Use the protocol element in the spanningTree structure to select the bridging protocol. Refer to spanningTree
on page 777.
Setting the bridge priority
Refer to 8.1.9 - The Spanning Tree priority and cost on page 309 for more information on bridge priority.
Use the bridgePriority element in the spanningTree structure to set the bridge priority. Refer to spanningTree on
page 777.
8.2.3 Adding a bridge group
As said in 8.2.1 - Introducing the bridging attributes on page 312, you can add several bridge groups.
In order to add a bridge group, proceed as follows:
Step Action

bridge object and add a vpnBridgeGroup[ ] object underneath
(refer to 4.4 - Adding an object to the containment tree on
page 45).
E.g. vpnBridgeGroup[my_bg]
2 In the vpnBridgeGroup[ ] object you just added, configure the attributes to your needs.
Example:
Suppose you configure an IP address on the bridge group, activate the spanning tree
protocol and set a bridge priority.
3 Now you can add interfaces to the bridge group you just created. Do this by entering the
name of the bridge group in the bridging/bridgeGroup element of the interfaces you want to
add.
Refer to 8.2.6 - Explaining the bridging structure on page 318 (more specifically to the
bridgeGroup element) for more information.
Example:
Suppose you want to add the LAN interface to the vpnBridgeGroup[my_bg] object you previ-
ously added, then type the string “my_bg” in the bridgeGroup element of the bridging structure
of the lanInterface object.
Example - multiple bridge groups
Suppose …
• you have 2 VLANs (VLAN 1 and VLAN 2).
• you have 5 PVCs (PVC 1 up to PVC 5).
• you want to assign VLAN 1 and PVC 1 and 2 to
the default bridge group.
• you want to assign VLAN 2 and PVC 3, 4 and 5
to a bridge group you added yourself.
So first, add a bridge group to the containment tree (e.g. vpnBridgeGroup[my_bg]. Then assign the different
interfaces to the different bridge groups by specifying bridge group names in the bridging/bridgeGroup ele-
ments of the different interfaces. Also set the different interfaces in bridging mode.
The configuration looks as follows:
8.2.4 Enabling bridging on an interface
Refer to …
Per IP interface you can determine whether you perform routing, bridging or both. The following table
shows, for each IP interface, how to enable bridging on this interface:
Interface How to enable bridging?
LAN interface Set the mode attribute to bridging or routingAndBridging. The mode attribute can be found
in the lanInterface object: mode.
Important remark
instead: ip.
VLAN on the Set the mode element to bridging or routingAndBridging. The mode element can be found
LAN interface in the vlan table which is located in the lanInterface object: vlan/mode.
L2TP tunnel Set the mode element to bridging or routingAndBridging. The mode element can be found
in the l2tpTunnels table which is located in the tunnels object: l2tpTunnels/mode.
IPSEC L2TP Set the mode element to bridging or routingAndBridging. The mode element can be found
tunnel in the ipsecL2tpTunnels table which is located in the tunnels object: ipsecL2tpTunnels/
mode.
8.2.5 Configuring bridging on an interface
Refer to …
Once the bridging process is enabled on the interface (refer to 8.2.4 - Enabling bridging on an interface
on page 316) you can configure the bridging parameters of this interface. Use the elements in the bridging
structure for this purpose. The following table shows you the location of the bridging structure for each
interface:
Interface Location of the bridging parameters
LAN interface In the bridging structure of the lanInterface object: bridging.
Important remark
instead: ip.
VLAN on the In the bridging structure of the vlan table which is located in the lanInterface object: vlan/
LAN interface bridging.
L2TP tunnel In the bridging structure of the l2tpTunnels table which is located in the tunnels object:
l2tpTunnels/bridging.
IPSEC L2TP In the bridging structure of the ipsecL2tpTunnels table which is located in the tunnels
tunnel object: ipsecL2tpTunnels/bridging.
Refer to 8.2.6 - Explaining the bridging structure on page 318 for a detailed explanation of the bridging
structure.
8.2.6 Explaining the bridging structure
Because the bridging structure occurs in several objects, it is described here once and referenced where
necessary. Refer to 8.2.5 - Configuring bridging on an interface on page 317 for the location of the bridging
structure.
This section lists all the elements that can be present in the bridging structure. However, depending on
the interface, it is possible that not all of these elements are present.
The bridging structure contains the following elements:
Element Description
accessList Use this element set up an outbound access list on Default:<empty>

the interface. Range: 0 … 24 characters
Do this by entering the index name of the access list you want to use. You can cre-
ate the access list itself by adding an accessList object under the bridge object and
by configuring the attributes in this object.
Example
If you created a accessList object with index name my_access_list

(i.e. accessList[my_access_list]) and you want to apply this access list
here, then enter the index name as value for the accessList ele-
ment.
Refer to …
• 8.5 - Bridge traffic classification by filtering on page 344 for an introduction on
access lists.
• 11.10.2 - Bridge access list configuration attributes on page 786 for more infor-
mation on bridge access lists.
inAccessList Use this element set up an inbound access list on the Default:<empty>
interface. Range: 0 … 24 characters
To do so, proceed in exectly the same way as described above, for the accessList
element.
Element Description
trafficPolicy Use this element to apply a bridging traffic policy on Default:<empty>

the bridged data on the interface. Range: 0 … 24 characters
Do this by entering the index name of the bridging traffic policy you want to use.
You can create the bridging traffic policy itself by adding a bridgingTrafficPolicy object
under the profiles object and by configuring the attributes in this object.
Note that an IP traffic policy cannot be applied here.
Example
If you created a bridgingTrafficPolicy object with index name

my_traffic_policy (i.e. bridgingTrafficPolicy[my_traffic_policy]) and you
want to apply this traffic policy here, then enter the index name
as value for the trafficPolicy element.
Although a bridging traffic policy can still be configured, the preferred way to
manipulate bridged traffic, is to make use of access lists. These allow for
extra configuration possiblities compared to bridge traffic policies.
Refer to ...
• 8.5 - Bridge traffic classification by filtering on page 344,
• 8.6 - Bridge traffic classification by applying QoS on bridged traffic on page 352
and
• 11.10.2 - Bridge access list configuration attributes on page 786
Element Description
bridgeGroup Use this element to determine to which bridge group Default:bridge

the interface belongs. Range: 1 … 24 characters
You have the possibility to create multiple bridge groups (refer to 8.2.3 - Adding a
bridge group on page 314). Then, you can assign some interfaces to one bridge
group while you assign several other interfaces to another bridge group.
By default, the interface is assigned to the default bridge group (provided the con-
figuration attribute name of the default bridge group still has its default value
“bridge”). You can assign the interface to another bridge group than the default
bridge group by specifying the index name of the bridge group in the bridgeGroup
element.
Examples
• By default, both the bridgeGroup element and the configuration attribute name of
the default bridge group are set to “bridge”. This means that by default the inter-
face is assigned to the default bridge group.
• Suppose you change the name of the default bridge group (by changing the
value of the configuration attribute name). If you still want to assign the interface
to the default bridge group, then you have to enter the new name of the default
bridge group in the bridgeGroup element of the interface.
• Suppose you add a bridge group with index name my_bg and you want to assign
the interface to this bridge group, then enter the index name as value for the
bridgeGroup element.
Element Description
limitBroadcasts Use this element to limit broadcasts between inter- Default:disabled

faces for which the limitBroadcasts element is set to ena- Range: enabled / disabled
bled.
Example
Suppose you have the follow-

ing set-up:
• Four links towards four dif-
ferent users (clients).
• One uplink towards the
backbone.
• All links are configured for
bridging.
In this case you probably want
that broadcasts coming from
the uplink are distributed to the user links and that broadcasts coming from the
user links are forwarded to the uplink. However, you most likely do not want that
broadcasts coming from one user link are distributed over all the other user links.
Therefore, set the limitBroadcasts element to enabled on all interfaces that may not for-
ward each other’s broadcasts.
learning Use this element to enable or disable the learning of Default:disabled

MAC addresses on this interface. Range: enabled / disabled
When disabled, the bridge cache will not be filled up with newly learned MAC
addresses from this interface.
maxCacheSize Use this element to set the maximum allowed number Default:0, unlimited
of dynamically learned MAC addresses in the bridge Range: 0 ... 10000
cache, via the interface. If set to 0, this means this
number is unlimited.
If a packet with an unknown MAC address is received, and the address will
not be entered in the bridge cache because either learning is set to disabled or
the maxCacheSize for this interface has been exceeded, the packet will be
dropped.
Element Description
relearn Use this element to resolve inconsistency issues in Default:-

the bridge group. Range: structure, see below
When MAC addresses are relearned within a bridge group on different interfaces,
it indicates that some inconsistency is present in the network, which can lead to
circles and traffic bursts.
The relearn structure contains the following elements:
• dropOnRelearn. When this element is set to enabled, Default:disabled
relearned packets on the interface are dropped. Range: enabled / disabled
• shutdownThreshold. Use this element to set the Default:0

number of relearns that are allowed on the inter- Range: 0 ... 2147483647
face. When this threshold is exceeded, the inter-
face is shut down during the shutdownTime, which is described below.
• shutdownTime. This is the time during which the Default:00000d 00h 00m 00s
interface is shut down. The interface can then Range: 00000d 00h 00m 05s -
automatically be restarted after this time, or a user 00000d 18h 12m 15s
action can be required. As long as the interface is
in shutDown state, an alarm is raised on the bridge group.
vlanMembership Use this element to set to which VLAN ‘s a bridging Default:all

interface belongs to. Possible values are: Range: enumerated, see below
• all. The bridging interface belongs to all VLAN ‘s.
• none. The bridging interface does not belong to any VLAN.
• grouped. The membership is based on the defined VLAN groups. Refer to
11.10.3 - VLAN group configuration attributes on page 793 for more information
about VLAN groups.
If an interface is not a member of a certain VLAN, it will discard incoming packets
with that VLAN tag.
Refer to 8.3 - Configuring VLANs on page 325 for more information about VLAN ‘s.
priority Use this element to set the port priority of the inter- Default:128
face. Range: 0 ... 255
Each port of a bridge has a unique port identifier. The priority element is a part of
this port identifier and allows you to change the priority of the port. It is taken as
the more significant part in priority comparisons.
The other part of the unique port identifier has a fixed relationship to the physical
or logical port. This assures the uniqueness of the unique port identifier among the
ports of a single bridge.
Refer to 8.1.9 - The Spanning Tree priority and cost on page 309 for more infor-
mation on port priority.
Element Description
pathCost Use this element to set the path cost of the interface. Default:100
The path cost is the value that is added to the total Range: 1 … 65535
cost of the path to the root bridge, provided that this particular port is a root port.
I.e. that the path to the root goes through this port.
This value is used in RSTP, and in MSTP in the global common spanning tree.
The total cost of the path to the root bridge should not exceed 65500.
Refer to 8.1.9 - The Spanning Tree priority and cost on page 309 for more infor-
mation on port priority.
internalPathCost Use this element to set the path cost of the interface Default:100
for MSTP, i.e. this is the path cost to use internally in Range: 1 … 65535
a VLAN region.
This internal path cost can be overruled by the configuration of a VLAN group:
Bridge ports can be imported in a VLAN group by enabling the importBridgePorts
attribute in the vlanGroup[ ] object.
By setting the ports attribute in the vlanGroup[ ] object, the internalPathCost configured
here in the bridging structure, is overruled by the one set in the VLAN group.
Refer to 11.10.3 - VLAN group configuration attributes on page 793 for more infor-
mation.
topologyChange- Use this element to enable or disable the communica- Default:enabled

Detection tion of Spanning Tree topology changes to other Range: enabled / disabled
ports.
restrictedRole When using the Multiple Spanning Tree Protocol or Default:disabled

MSTP, use this element to restrict the role of a port . Range: enabled / disabled
When enabled:
• the port will not be selected as root port, even it has the best spanning tree pri-
ority.
• the port will be selected as an alternate port after the root port has been
selected.
When enabled, it can cause lack of spanning tree connectivity. It can be set by a
network administrator to prevent bridges external to the core region of the network
influencing the spanning tree active topology, possibly because those bridges are
not under the full control of the administrator.
Refer to 8.1.5 - The Spanning Tree topology on page 304 for more information on
port states.
Element Description
adminEdge When using the Multiple Spanning Tree Protocol or Default:disabled

MSTP, use this element to configure an interface port Range: enabled / disabled
as an edge port.
What is an edge port?
An edge port is located on the boundary of the spanning tree domain; it is con-
nected to a device or network which is not part of the spanning tree domain. This
means that no spanning tree messages are sent out via this port to the outside
world.
8.3 Configuring VLANs
This section introduces VLANs and gives a short description of the attributes you can use to configure
VLANs.
• 8.3.1 - Introducing VLANs on page 326
• 8.3.2 - Setting up a VLAN on a LAN interface on page 329
• 8.3.3 - Setting up a VLAN on the bridge group on page 331
• 8.3.4 - Configuring VLAN switching on page 332
• 8.3.5 - Adding a VLAN group on page 335
8.3.1 Introducing VLANs
What is a VLAN?
A Virtual LAN (VLAN) is a group of devices on one or more LANs that are configured (using management
software) so that they can communicate as if they were attached to the same wire, when in fact they are
located on a number of different LAN segments. Because VLANs are based on logical instead of phys-
ical connections, they are extremely flexible.
What is a VLAN tag?
The VLAN tag header is inserted immediately following the destination MAC address and source MAC
address fields of the frame. The VLAN tag header can be divided into two components:
• TPID (Tag Protocol Identifier). The 802.1Q Ethernet-encoded TPID is defined as two octets or 16 bits,
with the value “8100”.
• TCI (Tag Control Information). The TCI field is also two octets in length and contains:
- PCP (Priority Code Point) or user priority. The 3 user priority bits represent eight priority levels, 0
through 7. IEEE 802.1P defines the operation for these 3 user priority bits. The IEEE 802.1P sig-
nalling technique, also often referred to as Class Of Service or COS, is an IEEE endorsed speci-
fication for prioritising network traffic at the datalink/MAC sub-layer (layer 2).
- CFI (Canonical Format Indicator). The CFI bit indicates that all MAC address information carried
by the frame that may be present in the MAC data is in Canonical format.
- VID (VLAN Identifier). The 12-bit VID field identifies the VLAN to which the frame belongs. Three
VID values are reserved by the 802.1Q standard.
All this is illustrated in the following figure:
Double tagging
The IEEE 802.1Q standard specifies a tag that appends to a MAC frame. In addition to one tag being
added, it is also possible that two tags are added, i.e. double tagging, also referred to as QinQ VLAN
stacking. In addition to the IEEE 802.1Q standard, the IEEE 802.1ad standard is also supported; this is
an amendment to IEEE 802.1Q.
The first VLAN tag header, or inner tag, is inserted immediately following the destination MAC address
and source MAC address fields of the frame. The 16-bit TPID field of the VLAN tag header is 802.1Q
Ethernet-encoded, with the value “8100”.
The second VLAN tag header, or outer tag, is again inserted immediately following the destination MAC
address and source MAC address fields of the frame. The 16-bit TPID field of this VLAN tag header can
have multiple values:
• a value of 0x8100, in order to identify the frame as an IEEE 802.1Q - tagged frame.
• a value of 0x88a8, in order to identify the frame as an IEEE 802.1ad - tagged frame.
These predefined values can be set using the tpid element in the vlan structure of the vlan table on an
Ethernet interface; refer to the vlan attribute in 11.3 - LAN interface configuration attributes on page 509
for more information. In principle, beside these two predefined values, any other value can be filled in by
the user manually.
All this is illustrated in the following figure:

8.3.2 Setting up a VLAN on a LAN interface
Refer to 8.3.1 - Introducing VLANs on page 326 for an introduction.

To set up a VLAN on the LAN interface, proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to the lanInterface object, select the vlan
• Use this attribute to configure the VLANs you want to set up. Add a row to the vlan table
for each VLAN you want to set up.
• As long as no VLANs are created in the vlan table, the LAN interface accepts both
VLAN untagged and VLAN tagged frames.
• The VLAN untagged frames are bridged and/or routed (depending on the setting of
the mode attribute).
• The VLAN tagged frames are bridged (in case the mode attribute is set to bridging or
bridgingAndRouting, else they are discarded).
• As soon as a VLAN is created in the vlan table, the LAN interface still accepts VLAN
untagged frames but only accepts those VLAN tagged frames of which the VLAN ID
corresponds with the VLAN ID that has been configured in the vlan table (see the vid
element below). Other VLAN tagged frames are discarded.
2 Configure the elements of the vlan table:

• name. Use this element to assign an administrative name to the VLAN.
• remark. Use this attribute to write down any text, message, remark, etc. of up to 64
characters.
• adminStatus. Use this element to activate or deactivate the VLAN.
• mode. Use this element to determine whether for the corresponding VLAN, IP packets
are treated by the routing process or the bridging process.
• priorityPolicy. Use this attribute to apply a priority policy on the LAN interface.
• ip. Use this element to configure the IP related parameters of the VLAN. Refer to 5.2.3
- Explaining the ip structure on page 56 for more information.
• bridging. Use this element to configure the bridging related parameters in case the mode
attribute is set to bridging. Refer to 8.2.6 - Explaining the bridging structure on page 318
• vlan. Use this element to configure the specific VLAN related parameters of the VLAN.
See below.
• inboundBandwidth. Use this attribute to configure the inbound bandwidth on the LAN
interface.
1
Refer to vlan on page 515 for more information.

Step Action
3 Configure the vlan structure in the vlan table. The most important elements in this structure
are:
• vid. Use this element to set the VLAN ID.
Important remark
You can also enter VLAN tag 0 as VLAN ID. This is not really a VLAN, but a way
to reverse the filtering:
- all the untagged data is passed, internally, to VLAN 0.
- all the other, tagged, data for which no VLANs are defined, are handled by the
main LAN interface.
This allows a set-up where a number of VLANs are VLAN switched, while other VLANs
and untagged data are bridged. This is particularly interesting for VLAN based networks
with Ethernet switch discovery protocols like Cisco CDP. Until now, this was not possible
since the VLAN switching mode did not allow flooding packets over multiple interfaces
(bridging), nor did it allow terminating management data in the device.
In such set-up, the configuration looks as follows:
- A first bridge group includes all VLANs that need to be switched. This bridge group
is set in VLAN switching mode.
- A second bridge group includes VLAN 0 and possibly also a VLAN for manage-
ment of the device.
- The interface VLAN table(s) include(s) entries for all switched VLANs, VLAN 0 and
possibly a VLAN for management.
• tpid. Use this element to set the Tag Protocol ID of the VLAN header. This is the value
to be used as the first 2 bytes of the VLAN tag when adding a VLAN header. Prede-
fined values are dot1Q and dot1ad.
• tagSignificance. Use this element to determine the significance of the VLAN tag: local, glo-
bal, cVlan or sVlan. Refer to vlan/vlan on page 517 for more detailed information.
8.3.3 Setting up a VLAN on the bridge group
Refer to 8.3.1 - Introducing VLANs on page 326 for an introduction.

Although the 1424 SHDSL Router bridges VLAN tagged frames when connected to a VLAN aware
switch, the 1424 SHDSL Router itself can only be managed via IP if a VLAN is configured on the bridge
group. In other words, if you want that the data carried by a VLAN can be delivered to the 1424 SHDSL
Router itself (e.g. so that it can be delivered to the protocol stack, routed, etc.), then you have to config-
ure a VLAN on the bridge group.
To set up VLANs on the bridge group, proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to the bridgeGroup object, select the vlan
Use this attribute to configure the VLANs you want to set up. Add a row to the vlan table
for each VLAN you want to set up.
2 Configure the elements of the vlan table:

• name. Use this element to assign an administrative name to the VLAN.
• adminStatus. Use this element to activate or deactivate the VLAN.
• ip. Use this element to configure the IP related parameters of the VLAN. Refer to 5.2.3
- Explaining the ip structure on page 56 for more information.
• vlan. Use this element to configure the specific VLAN related parameters of the VLAN.
Refer to the following step.
Refer to the bridgeGroup attribute in 11.10.1 - Bridge group configuration attributes on

3 Configure the vlan structure in the vlan table. The elements in this structure are:
• vid. Use this element to set the VLAN ID.
• txCos. Use this element to set the default user priority (802.1P, also called COS) of the
transmitted VLAN frames.
• changeTos. Use this element to enable or disable the COS to TOS mapping.
If you set the changeTos attribute to disabled, then the element cosTosMap is ignored.
• cosTosMap. Use this element to determine how the VLAN user priority (COS) maps
onto the IP TOS byte value.
• tosCosMap. Use this element to determine how the IP TOS byte value maps onto the
VLAN user priority (COS).
• arp. Use this element to configure the Address Resolution Protocol (ARP) cache.
Refer to the bridgeGroup attribute in 11.10.1 - Bridge group configuration attributes on

8.3.4 Configuring VLAN switching
Refer to 8.3.1 - Introducing VLANs on page 326 for an introduction on VLANs.

To configure VLAN switching, proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to the bridge/bridgeGroup object and set
the bridgeCache attribute to switching.
2 In the 1424 SHDSL Router containment tree, go to the bridge/bridgeGroup object, select the
vlanSwitching attribute and add one or more entries to this table.
Use this attribute to specify which VLANs you want to switch. Add a row to the vlanSwitching
table for each VLAN you want to switch.
Step Action
3 Configure the elements of the vlanSwitching table:

• sourceIntf. Use this element to enter the name of the (physical) source interface which
carries the VLAN that has to be switched.
• sourceVlan. Use this element to enter the VLAN ID of the VLAN that has to be switched.
Entering 0 as VLAN ID strips the VLAN tag of the Ethernet frame.
• sourcePFilter. Use this element to apply a filter on the priority bits of the source VLAN
packets. Selecting value -1 leaves the sourcePFilter element as optional, so no filtering
is done.
• sourcePMap. Use this element to, if desired, remap the VLAN priorities. The priorities
defined in the sourcePMap are applied after the VLAN is switched from sourceVlan to des-
tinationVlan.
• destinationIntf. Use this element to enter the name of the (physical) destination interface
which carries the VLAN when it has been switched. The destination interface can also
be a bridge group, in that case just enter the name of the bridge group.
• destinationVlan. Use this element to enter the VLAN ID of the VLAN when it has been
switched. Entering 0 as VLAN ID strips the VLAN tag of the Ethernet frame.
• destinationPFilter. Use this element to apply a filter on the priority bits of the destination
VLAN packets. Selecting value -1 leaves the destinationPFilter element as optional, so
no filtering is done.
• destinationPMap. Use this element to, if desired, remap the VLAN priorities. The priori-
ties defined in the destinationPMap are applied after the VLAN is switched from destina-
tionVlan to sourceVlan.
• tunnel. Enabling this element inserts an extra VLAN tag, the IEEE 802.1Q-in-Q VLAN
Tag, to the tagged packets; this results in double-tagged frames.
• bidirectional. Use this element to set in which direction the switching will take place, in
both directions, or from source to destination.
Important remarks
•Note that one row in the vlanSwitching table represents a bidirectional connection.
I.e. data is switched from source to destination and vice versa.
• Also note that only point-to-point connections are possible. Point-to-multipoint con-
nections are not possible. In other words, a certain VLAN may only appear once in the
vlanSwitching table.
Refer to vlanSwitching on page 782 for more information on the elements of the vlanSwitching
configuration attribute.
Example - configuring VLAN switching
The following figure shows the LAN interface carrying 3 VLANs that are switched to 3 different ATM
PVCs. One of the VLAN IDs is kept, one is changed and one is stripped.
The following figure shows how to configure the bridge group for VLAN switching.
8.3.5 Adding a VLAN group
VLAN groups must be added when using the Multiple Spanning Tree Protocol or MSTP.
MSTP allows frames assigned to different VLANs to follow separate paths through the network. For this,
VLAN groups must be created. Each VLAN group can have its own path within the spanning tree
domain.
Refer to 8.3.1 - Introducing VLANs on page 326 for an introduction on VLAN ‘s; also refer to 8.1.3 - The
Rapid Spanning Tree and Multiple Spanning Tree Protocol on page 301 for more information about
MSTP.
To set up a VLAN group under the bridge group, proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to the bridge object, select the bridgeGroup
object and add a vlanGroup[ ] object. Refer to 4.4 - Adding an object to the containment
tree on page 45 for an explanation on how to add objects to the containment tree.
Refer to the following figure:
2 Configure the attributes of the vlanGroup[ ] object:
• filteringId. Use this attribute to set a unique identifier for the VLAN group.
• vlanMembers. Use this attribute to add VLAN ‘s to the VLAN group by means of their
VLAN ID. VLAN ‘s can be added individually, or by entering a range.
• importBridgePorts. Use this attribute to automatically import all bridging interfaces, which
are members of this bridge group, into the VLAN group. Do this by setting this attribute
to enabled.
• ports. Use this attribute to manually add ports to the VLAN group, or to overrule the
configuration values of the ports, which have been imported using the importBridgePorts
attribute, for this VLAN group.
• mst. Use this attribute to set priority of the VLAN group for Multiple Spanning Tree or
MST.
Refer to 11.10.3 - VLAN group configuration attributes on page 793 for more detailed
information.
8.4 Configuring VLANs on the 4 port Ethernet switch
This chapter is only relevant in case your 1424 SHDSL Router is equiped with a 4 port Ethernet switch.
You can use the 4 port Ethernet switch as an ordinary Ethernet switch on the one hand, but you can also
use it as a VLAN switch on the other hand. This section explains how you can create VLANs on the 4
port Ethernet switch.
• 8.4.1 - Introducing the 4 port Ethernet switch on page 337
• 8.4.2 - Setting up VLANs on the 4 port Ethernet switch on page 339
8.4.1 Introducing the 4 port Ethernet switch
What is the 4 port Ethernet switch?
The Ethernet switch that is used on the 1424 SHDSL Router is actually a 5 port Ethernet switch, with:
• 4 “external” ports.
• 1 “internal” port.
The 4 port Ethernet switch can be used as an ordinary Ethernet switch or as a VLAN switch.
The vlan attribute versus the ports attribute
In the lanInterface object of the 4 port Ethernet switch there are two attributes directly involved with the
configuration of VLANs:
• The ports attribute. Use this attribute to set up VLANs on the different ports of the 4 port Ethernet
switch. Depending on which type of VLAN tagging you select, VLAN IDs are stripped, added, etc.
• The vlan attribute. Use this attribute if you want that VLAN tagged packets inside the 4 port Ethernet
switch are forwarded to the bridging or routing function of the 1424 SHDSL Router.
VLAN switching restrictions
You can define up to 16 different VLANs in the vlan attribute and the ports attribute together. If you con-
figure more than 16 VLANs in total, then only the first 16 VLANs are activated. For each VLAN that could
not be activated the following warning message is displayed in the messages status attribute: “Ethernet
switch configuration failed: too many different VIDs! VID x is not activated.”.
The order in which the configured VLANs are activated is the following:
1. First the VLANs that are configured in the ports attribute are activated. This is done in numerical port
order, i.e. from port 1 to 4.
2. Then the VLANs that are configured in the vlan attribute are activated.
Examples:
• Suppose you configure port 1 as a trunk port with 16 different VIDs and you configure port 2, 3 and
4 as tagged ports also all with different VIDs. That makes 19 different VIDs! In that case, only the
VIDs of port 1 are activated.
• Suppose you configure port 1, 2 and 3 as tagged ports, all with different VIDs. Suppose you configure
port 4 as a trunk port with another 8 different VIDs. Finally, you create 8 entries in the vlan attribute,
also with VIDs different from the others. That makes 19 different VIDs! In that case, the last 3 entries
of the vlan attribute are not activated.
8.4.2 Setting up VLANs on the 4 port Ethernet switch
Refer to 8.4.1 - Introducing the 4 port Ethernet switch on page 337 for an introduction.
To create VLANs on the 4 port Ethernet switch, proceed as follows:
Step Action
1 If you want to create VLANs that only have a significance on the 4 port Ethernet switch,
in other words they do not have to be known by the protocol stack of the 1424 SHDSL
Router, then it suffices to create VLANs on the ports of the 4 port Ethernet switch. Do this
as follows:
1. In the 1424 SHDSL Router containment tree, go to the lanInterfaceX object and select
the ports attribute.
2. In the ports attribute, you can configure the adapter and crossover element for each port.
3. Set the switchMode attribute to dot1QSwitching to enable VLAN switching on the 4 port
Ethernet switch.
2 Configure the VLANs that the 1424 SHDSL Router needs to bridge or route in the vlan
attribute. If no VLANs are configured in the vlan attribute, then only local VLAN switching
between the Ethernet ports of the 4P switch is done.
Refer to 8.3.2 - Setting up a VLAN on a LAN interface on page 329 for more information
on the vlan attribute.
Important remark
As explained in VLAN switching restrictions on page 338, the sum of the unique VLANs configured in
the ports attribute and those configured in the vlan attribute may not exceed 16. This because the internal
VLAN table of the 4 port Ethernet switch can only handle up to 16 unique VLANs.
Example 1 - creating VLANs on the 4 port Ethernet switch
In this example, all ports are untagged and the VIDs are set to the same value.
Incoming untagged packets and null-VID tagged packets are internally tagged with VID 1 before they
are forwarded (except if they are forwarded to the local port, see below). Incoming packets tagged with
VID 1 are forwarded unaltered. Incoming packets tagged with a different VID are discarded.
Outgoing untagged packets are forwarded unaltered. Outgoing tagged packets their VLAN tag is
removed before they are forwarded.
What makes this case a special case is that since all VIDs on all ports are the same, there is no need
for the 1424 SHDSL Router itself to be able to make a distinction between the different packets coming
from the different ports (it is the same VLAN). So packets that are destined for the 1424 SHDSL Router
itself their VLAN tag is removed before they are forwarded through the local port. In other words, the
central CPU of the 1424 SHDSL Router receives untagged packets from the 4 port Ethernet switch.
In this example, all ports are untagged and the VIDs are set to different values.
Depending on which port they arrive, incoming untagged packets and null-VID tagged packets are inter-
nally tagged with VID 10 or 20 before they are forwarded. Incoming tagged packets are forwarded unal-
tered if the VID corresponds with the one configured on the port. Incoming packets tagged with a
different VID are discarded.
Outgoing untagged packets are forwarded unaltered. Outgoing tagged packets their VLAN tag is
removed before they are forwarded.
As opposed to the previous case (Example 1 - creating VLANs on the 4 port Ethernet switch on
page 340), packets that are forwarded through the local port keep their VLAN tag. So in this case, if you
want that one or both VLANs are processed by the 1424 SHDSL Router itself (e.g. because they have
to be routed or bridged etc.), then add them to the vlan attribute.
So more concrete, if you want that both VLAN 10 and 20 are processed by the 1424 SHDSL Router itself,
then add 2 entries to the vlan attribute, one with VID = 10 and one with VID = 20.
In this example, all ports are tagged and the VIDs are set to different values.
Incoming untagged packets and null-VID tagged packets are discarded. Incoming tagged packets are
forwarded unaltered if the VID corresponds with the one configured on the port. Incoming packets tagged
with a different VID are discarded.
Outgoing tagged packets are forwarded unaltered if the VID corresponds with the one configured on the
port.
If you want that one or both VLANs are processed by the 1424 SHDSL Router itself (e.g. because they
have to be routed or bridged etc.), then add them to the vlan attribute.
In this example, 2 ports are untagged, 2 ports are tagged, but the VIDs are set to the same value.
The untagged and tagged ports behave as explained in the previous examples.
One thing that can be noted here is that although all VIDs are set to the same value, packets forwarded
to the local port keep their VLAN tag. This as opposed to the situation in Example 1 - creating VLANs on
the 4 port Ethernet switch on page 340.
So in this case, if you want that the VLAN is processed by the 1424 SHDSL Router itself (e.g. because
it has to be routed or bridged etc.), then add it to the vlan attribute.
In this example, one port is configured as a trunk port.
The untagged and tagged ports behave as explained in the previous examples.
The trunk port is a special kind of tagged port. It can be seen as a concentrator for packets of all other
ports or as an uplink to a backbone LAN. On a trunk you can configure more than one VID. Note that the
local port is actually a permanent trunk port, i.e. it concentrates all packets destined for the central CPU.
On a trunk port, incoming untagged packets and null-VID tagged packets are discarded. Incoming
tagged packets are forwarded unaltered if the VID corresponds with the one configured on the port.
Incoming packets tagged with a different VID are discarded.
Outgoing tagged packets are forwarded unaltered if the VID corresponds with the one configured on the
port.
In this example, one port is configured as a sniffer port.
If a port is configured as sniffer port, its normal function is suspended and this port starts to transmit all
packets it has to monitor. So on a sniffer port the VLAN filtering and incoming and outgoing tagging rules
are all disabled.
In the example above, all packets (including packets that do not successfully pass the validation proc-
ess) entering or exiting port 2 and that are tagged with VID 101 are copied to port 4 and transmitted unal-
tered there. If you then connect a VLAN-enabled sniffer program running on a PC, you can monitor all
traffic to and from port 2.
8.5 Bridge traffic classification by filtering
This section explains how bridge access lists can be used as a filter, simple or advanced, and if neces-
sary how a certain action can be applied on the filtered packets. It also explains how the access lists can
be applied on an interface.
For filtering purposes, access lists on the bridged interface can be used in three different ways:
• They can be used as a simple filter, based on the source MAC address, via the macAddress attribute.
• They can be used as an advanced filter, via the advancedFilter attribute.
• When using the advanced element of the advancedFilter attribute, even more sophisticated actions can
be applied on the filtered packets.
This section gives an overview of the bridge access list configuration attributes that are relevant for fil-
tering; refer to 11.10.2 - Bridge access list configuration attributes on page 786 for a detailed overview
of all bridge access list configuration attributes.
• 8.5.1 - Using an access list as a simple filter on page 345
• 8.5.2 - Using an access list as an advanced filter on page 346
• 8.5.3 - Using the advanced element of the advancedFilter attribute on page 347
• 8.5.4 - Applying an access list on an interface on page 350
Access lists can be added under the bridge object. By default, no accessList[ ] object is present in the con-
tainment tree. If you want to use this feature, an accesslist[ ] object must be added. Refer to 4.4 - Adding
an object to the containment tree on page 45.
8.5.1 Using an access list as a simple filter
An access list can be used for simple filtering purposes via the macAddress attribute under the accessList[ ]
object. Refer to 11.10.2 - Bridge access list configuration attributes on page 786 and the following figure:
This is an outbound access list: packets coming from MAC addresses that are specified in the access
list are not sent out on the interface on which the access list is applied.
8.5.2 Using an access list as an advanced filter
A more sophisticated way to filter bridged frames is to make us of the advancedFilter attribute under the
accessList[ ] object. This way, bridged frames can be filtered, taking into account:
• source and destination MAC address ranges. These ranges can be set using the sourceMacStart,
sourceMacEnd, destinationMacStart and destinationMacEnd elements.
• the layer 3 protocol field. To select a protocol, use the protocol element.
• VLAN tag and priority bits. To filter out specific VLAN ‘s, use the vlan element; to filter bridged frames
based on the priority bits in the VLAN header, use the priority element.
An action can be set, using the action element, that has to be executed on the filtered frames: deny, permit
or continue. This means:
• deny. Packets matching this line are dropped.
• permit. Packets matching this line are passed to the advanced action (if present) or permitted. For more
information about the advanced action, refer to 8.5.3 - Using the advanced element of the advancedFilter
attribute on page 347.
• continue. Packets matching this line are passed to the advanced action (if present) and processing of
the ACL continues.
Refer to 11.10.2 - Bridge access list configuration attributes on page 786 and the following figure:
• The advancedFilter table can contain many lines, each line with its own filter criteria; i.e. each line is a
separate filter, which can also be given a unique name with the name element.
• This type of classification can be configured per physical and logical interface both in inbound and
outbound directions.
8.5.3 Using the advanced element of the advancedFilter attribute
When using the advanced element of the advancedFilter attribute, even more sophisticated actions can be
applied on the filtered packets:
• Limit the number of TCP SYN packets per minute on page 348
• Jump over or jump to another entry in the access list on page 348
• Apply an IP traffic policy on page 349
Refer to 11.10.2 - Bridge access list configuration attributes on page 786 and the following figure, it
shows the attributes that can be set:
Note that the advancedFilter/advanced/mark element part is of the QoS features of the device, and therefore
has been described in 8.6 - Bridge traffic classification by applying QoS on bridged traffic on page 352.
Limit the number of TCP SYN packets per minute
TCP SYN packets are sent out by a host that wants to establish a TCP connection. The device that
receives the packets, stores these requests in a queue.
When a host sends out these packets with a fake source address, at a high rate, it can block the queue
of the device that receives the packets. And thereby making TCP connections from and to actual users
impossible.
The number of TCP SYN packets that are actually received, can be limited in time, so that a TCP SYN
attack cannot block the device.
This can be done:
• globally, taking into account the total number of received TCP SYN packets, or
• per MAC address.
Jump over or jump to another entry in the access list
This is also refered to as stacked filtering.

The advancedFilter table can contain many lines, each line with its own filter criteria; i.e. each line is a sep-
arate filter, which can also be given a unique name. With the elements jumpOver and jumpTo, it is possible
to jump to another location within the advanced filter itself, so that another filter is activated.
Apply an IP traffic policy
Another way to filter bridged traffic is the use of an IP traffic policy. Refer to 7.11.3 - Traffic policy on
routed and on bridged data on page 266 for more information about IP traffic policies.
8.5.4 Applying an access list on an interface
Access lists can be used as simple filter, or advanced filter:

• Simple filtering can be configured per interface for outbound traffic.
How to configure an access list as simple filter is explained in 8.5.1 - Using an access list as a simple
filter on page 345.
• Advanced filtering can be configured per interface both in inbound and outbound directions. How to
configure an access list as an advanced filter is explained in 8.5.2 - Using an access list as an
advanced filter on page 346 and 8.5.3 - Using the advanced element of the advancedFilter attribute on
page 347.
Access list on outbound traffic

To apply an access list on outbound traffic, proceed as follows:
1. Add a bridge/accessList[ ] object, e.g. bridge/accessList[myList].
2. Configure the bridge/accessList[ ] object, either as a simple filter, or as an advanced filter.
3. Apply the access list on an interface by typing the index name of the accessList[ ] object as value of the
accessList element in the bridging structure. The accessList element can be found in the bridging structure of
the interface. Refer to 8.2.4 - Enabling bridging on an interface on page 316 for the location of the bridging
structure on the different interfaces.
Access list on inbound traffic

To apply an access list on inbound traffic, proceed as follows:
2. Configure the bridge/accessList[ ] object, either as a simple filter, or as an advanced filter.
inAccessList element in the bridging structure. The accessList element can be found in the bridging structure
of the interface. Refer to 8.2.4 - Enabling bridging on an interface on page 316 for the location of the
bridging structure on the different interfaces.
Example - applying an access list on an interface
Suppose you created and configured an access list object with index name myList (i.e. accessList[myList]),
and you want to apply this access list on the EFM link.
The figure shows 2 possibilities:

• in the first possibility, the access list is applied on outbound traffic.
• in the scond possibility, the access list is applied on inbound traffic.
8.6 Bridge traffic classification by applying QoS on bridged traffic
This chapter explains the application of advanced access lists as advanced filter on bridged traffic, as
part of QoS on bridged traffic.
In the first section, 2 important concepts with regard to QoS are explained: TOS and COS. Then, it
explains in detail how to configure advanced filters for QoS and how to apply them on an interface.
This section gives an overview of the bridge access list configuration attributes that are relevant for QoS;
refer to 11.10.2 - Bridge access list configuration attributes on page 786 for a detailed overview of all
bridge access list configuration attributes.
• 8.6.1 - Defining TOS and COS on page 353
• 8.6.2 - Colouring of bridged packets on page 354
• 8.6.3 - Applying colouring on an interface on page 358
• Access lists can be added under the bridge object. By default, no accessList[ ] object is present in the
containment tree. If you want to use this feature, an accesslist[ ] object must be added. Refer to 4.4 -
Adding an object to the containment tree on page 45.
• Another aspect of QoS is the application of priority policies.
This is the same for routed and bridged data, and has therefore already been described in 7.11.12 -
Priority policy on routed and on bridged data on page 289 and the sections beyond; refer to these
sections for more information about priority policies.
8.6.1 Defining TOS and COS
TOS and COS are 2 concepts which determine the prioritisation or classification of data packets. But on
2 different levels:
• COS is part of the data link layer or layer 2 of the OSI model. Also refer to 8.3.1 - Introducing VLANs
on page 326 for more information.
• TOS is part of the network layer or layer 3 of the OSI model. Also refer to 7.11.2 - Introducing traffic
and priority policy on page 262 for more information.
The prioritisation or classification of data packets is also referred to as colouring of the data packets.
Extended access lists can manipulate the priority of data packets: they can be set to a specific desired
value, or TOS can be mapped to an according COS.
The figures below illustrate the COS and TOS presence in the data packets on layer 2 and 3.
Classification and marking at the data link layer or layer 2: COS
Priority at layer 2 is called Class Of Service or COS. 3 bits are used to set the priority, so this leads to 8
different priorities. The following figure shows a tagged ethernet frame with the priority field highlighted:
Classification and marking at the network layer or layer 3: TOS
Priority at layer 3 is done via the TOS byte in an IP packet. In the OneAccess devices, all 8 bits can effec-
tively be used, so this allows for 256 possible priorities that can be set. The following figure shows an IP
packet with the TOS byte highlighted:
8.6.2 Colouring of bridged packets
An important aspect within the accessList[ ]/advancedFilter/advanced element, is the colouring of bridged pack-
ets i.e. making certain changes to the bridged packets. Traffic colouring is a mechanism where data is
marked in order to belong to a specific traffic category.
This can be done by using the mark element in the advanced element of the advancedFilter attribute. Refer
to the following figure:
Either one of the following options can be applied on the filtered packets:
• Setting a destination queue on page 355; the element to be used for this, is marked in the figure
above with 1, and explained further below.
• Setting TOS and COS value on page 356; the element to be used for this, is marked in the figure
above with 2, and explained further below.
• Mapping the IP TOS byte onto the VLAN user priority (COS) on page 357; the element to be used for
this, is marked in the figure above with 3, and explained further below.
Setting a destination queue
Each physical or virtual interface has 6 queues that can be filled: queues 1 to 5, and a low delay queue.
On an interface the access list is applied to:
• the filtered packets can be assigned to one of the queues by setting the queue element.
• the user can set how many packets may be queued before they are dropped, or that no packets may
be dropped at all, by setting the dropLevel element.
Setting TOS and COS value
On an interface the access list is applied to, the TOS byte and VLAN user priority (COS) of the filtered
packets can be set to a specific desired value:
• The TOS byte can be set to any value between 0 and 256, using the tos element. Entering 256 leaves
the TOS byte unchanged.
• The COS value can be set to any value between 0 and 8, using the cos element. Entering 8 leaves the
VLAN user priority unchanged.
In combination with this:
For more information about the TOS byte and COS, refer to 7.11.2 - Introducing traffic and priority policy
on page 262 and 8.6.1 - Defining TOS and COS on page 353.
Mapping the IP TOS byte onto the VLAN user priority (COS)
On an interface the access list is applied to, a TOS byte value range can be mapped onto the VLAN user
priority (COS):
• the TOS byte value range can be set using the startTos and endTos elements. They can be set to any
value between 0 and 256 (256 is for non IP data).
• The COS value can be set to any value between 0 and 8, using the cos element. Entering 8 leaves the
VLAN user priority unchanged.
In combination with this:
8.6.3 Applying colouring on an interface
Applying an access list on an interface for colouring purposes can be done on inbound and outbound
traffic:
Colouring of outbound traffic
To apply an access list on outbound traffic, proceed as follows:
2. Configure the bridge/accessList[ ] object, more specifically the mark element in the advanced element of the
advancedFilter attribute, as explained in 8.6.2 - Colouring of bridged packets on page 354.
accessList element in the bridging structure. The accessList element can be found in the bridging structure of
the interface. Refer to 8.2.4 - Enabling bridging on an interface on page 316 for the location of the bridging
structure on the different interfaces.
Colouring of inbound traffic

To apply an access list on inbound traffic, proceed as follows:
2. Configure the bridge/accessList[ ] object, more specifically the mark element in the advanced element of the
advancedFilter attribute, as explained in 8.6.2 - Colouring of bridged packets on page 354.
inAccessList element in the bridging structure. The accessList element can be found in the bridging structure
of the interface. Refer to 8.2.4 - Enabling bridging on an interface on page 316 for the location of the
bridging structure on the different interfaces.
All this is illustrated in the example below.

Example - applying an access list on an interface
Suppose you created an access list object with index name myList (i.e. accessList[myList]). The access list
will be configured for queueing up to 100 packets in queue 1. If the queue is full, packets will be dropped.
This access list will be applied on an ATM pvc.
8.7 Example: combining bridging and routing in a network
The following example shows a combination of bridging and routing in a network:

User manual Configuring the additional features
9 Configuring the additional features
view.
This chapter introduces the most important additional features of the 1424 SHDSL Router besides rout-
ing, bridging and switching and lists the attributes you can use to configure these features.
• 9.1 - Configuring DHCP on page 364
• 9.2 - Configuring the access restrictions on page 370
• 9.3 - Tuning the bandwidth on the LAN interface on page 376
• 9.4 - Configuring L2TP tunnels on page 379
• 9.5 - Configuring GRE tunnels on page 389
• 9.6 - Configuring IP security on page 407
• 9.7 - Configuring RADIUS on page 440
• 9.8 - Configuring the stateful inspection firewall on page 450
• 9.9 - IP SLA or traffic quality monitoring on page 474
• 9.10 - Logging of performance statistics on page 479
9.1 Configuring DHCP
This section introduces the Dynamic Host Configuration Protocol (DHCP) and gives a short description
of the attributes you can use to configure DHCP.
• 9.1.1 - Introducing DHCP on page 365
• 9.1.2 - Assigning static IP addresses on page 366
• 9.1.3 - Assigning dynamic IP addresses on page 367
• 9.1.4 - Configuring the 1424 SHDSL Router as DHCP relay agent on page 369
9.1.1 Introducing DHCP
What is DHCP?
The DHCP protocol is a protocol for assigning IP addresses to devices on a network. DHCP can assign
dynamic or static IP addresses. With dynamic addressing, a device can have a different IP address every
time it connects to the network. What is more, the IP address can even change while the device is still
connected.
Dynamic addressing simplifies network administration because the software keeps track of IP addresses
rather than requiring an administrator to manage the task. This means that a new computer can be
added to a network without the hassle of manually assigning it a unique IP address.
What is a DHCP relay agent?
Being a broadcast message, a DHCP request can not pass a router by default. To help a DHCP request
pass the router, IP helper addresses have to be configured. This adds additional information to the
request packets allowing servers on distant networks to send back the answer.
Combining static and dynamic DHCP tables
If you combine static and dynamic DHCP server tables, then on an incoming DHCP request first the
static table is scanned for matches and then the dynamic DHCP table is considered.
How does the DHCP server react on a BootP request?
The DHCP server reacts on a BootP request as follows: the source MAC address of the incoming BootP
request packet is compared with the MAC addresses that have been entered in the dhcpStatic table. Then,
there are two possibilities:
• If the source MAC address corresponds with a MAC address in the dhcpStatic table, then the DHCP
server replies with a BootP reply packet. In this reply, the IP address that is linked with the MAC
address in question (as defined in the dhcpStatic table) is returned.
• If the source MAC address does not correspond with a MAC address in the dhcpStatic table, then the
DHCP server returns no response on that frame.
Releasing IP addresses - DHCP versus BootP
On DHCP level, it is regularly checked whether the device that has an IP address in lease is still con-
nected to the network. If it is not, the IP address is returned to the pool of free IP addresses.
On BootP level, however, such a check (or refresh) does not exist. What is more, a statistic IP address
lease is for an infinite time. Consequently, if the device that requested the IP address is no longer con-
nected to the network, this is not detected by the server. In that case, the statistical information will still
indicate that the IP address is leased although it is not.
9.1.2 Assigning static IP addresses
Refer to 9.1.1 - Introducing DHCP on page 365 for an introduction.

To assign static IP addresses to an IP device, proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to the router object, select the dhcpStatic
Use this attribute to assign a fixed IP address to an IP device and this for an infinite time.
Add a row to the dhcpStatic table for each IP address you want to assign.
2 Configure the elements of the dhcpStatic table. The most important are:
• ipAddress. Use this element to assign an IP address to a certain client. This client is
identified with its MAC address.
• mask. Use this element to set the client its subnet mask.
• gateway. Use this element to set the default gateway for the client its subnet. If the inter-
face element is left empty (default), then it is the gateway element that determines on
which interface the 1424 SHDSL Router will act as DHCP server. Namely the inter-
face through which the IP address as entered in the gateway element can be reached.
• interface. Use this element to specify the name of the interface on which you want the
1424 SHDSL Router to act as DHCP server.
• macAddress. Use this element to enter the client its MAC address.
Refer to dhcpStatic on page 629 for more information.
Important remark
If you apply an access list on an interface1 of the 1424 SHDSL Router through which DHCP requests
have to be received, then make sure that this access list explicitly allows the passing of DHCP packets!
This to make sure that the DHCP packets are not dropped should you accidentally misconfigure the
access list.
Also when you activate the firewall, make sure that DHCP requests are allowed access to the protocol
stack of the 1424 SHDSL Router.
1. The term “interface” also implies the 1424 SHDSL Router its own protocol stack. So if an
access list is applied on the protocol stack, then also in this case make sure that the DHCP
packets are allowed to pass.
9.1.3 Assigning dynamic IP addresses

To assign dynamic IP addresses to an IP device, proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to the router object, select the dhcpDynamic
Use this attribute to assign an IP address selected from an IP address range to an IP

device and this for a certain time. Add a row to the dhcpDynamic table for each IP address
range you want to create.
2 Configure the elements of the dhcpDynamic table. The most important are:
• ipStartAddress. Use this element to define the start address of the IP address range. It
is from this range that an IP address will be dynamically assigned to a client.
• ipEndAddress. Use this element to define the end address of the IP address range. It is
from this range that an IP address will be dynamically assigned to a client.
• mask. Use this element to set the client its subnet mask for the specified IP address
range.
• gateway. Use this element to set the default gateway for the client its subnet. If the inter-
face element is left empty (default), then it is the gateway element that determines on
which interface the 1424 SHDSL Router will act as DHCP server. Namely the inter-
face through which the IP address as entered in the gateway element can be reached.
• interface. Use this element to specify the name of the interface on which you want the
1424 SHDSL Router to act as DHCP server.
• leaseTime. Use this element to set the maximum time a client can lease an IP address
from the specified IP address range. If 00000d 00h 00m 00s (default) is specified, then
the lease time is infinite.
Refer to dhcpDynamic on page 631 for more information.

Important remark
If you apply an access list on an interface1 of the 1424 SHDSL Router through which DHCP requests
have to be received, then make sure that this access list explicitly allows the passing of DHCP packets!
This to make sure that the DHCP packets are not dropped should you accidently misconfigure the
access list.
Also when you activate the firewall, make sure that DHCP requests are allowed access to the protocol
stack of the 1424 SHDSL Router.
1. The term “interface” also implies the 1424 SHDSL Router its own protocol stack. So if an
access list is applied on the protocol stack, then also in this case make sure that the DHCP
packets are allowed to pass.
9.1.4 Configuring the 1424 SHDSL Router as DHCP relay agent

To configure the 1424 SHDSL Router as DHCP relay agent, proceed as follows:
Step Action
1 Specify (a) helper IP address(es) using the helpers element in the ip structure. Refer to
5.2.3 - Explaining the ip structure on page 56 for more information.
2 Now specify the helper protocols.

By default, the helperProtocols table is empty. In this case the BootP/DHCP requests
(among others) are forwarded automatically. However, specifying at least one value in
the helperProtocols table clears the default helper list automatically. In that case you explic-
itly have to enter the BootP/DHCP protocol in the helperProtocols table.
Refer to helperProtocols on page 626 for more information.
9.2 Configuring the access restrictions
This section explains how to control the access to the 1424 SHDSL Router for both management data
and user data.
Access can be restricted on three levels:
• On an IP interface.
• On a bridge interface.
• On the protocol stack.
This is further explained below:
Access restrictions on an IP interface
Restricting access on an IP interface involves the use of an IP traffic policy. More specifically, applying
a traffic policy as an extended access list on an IP interface.
Access lists control the access to or from an interface for a number of specified services or IP addresses.
The access list describes the condition to forward (permit) packets to an interface or to drop (deny) them.
This has already been explained in the routing chapter, refer to 7.11.10 - Applying a traffic policy as an
extended access list on an IP interface on page 278 for a detailed explanation.
Access restrictions on a bridge interface
You can apply the following access restrictions on a bridge interface:
Access restrictions on user Quick configuration

data
Outbound simple access list 1. Add and configure a bridge/accessList[ ] object. E.g. accessList[myList].
with “deny” rules. 2. Apply the access list by typing the index name of the bridge/access-
List[ ] object as value of the accessList element in the bridging struc-
ture (e.g. “myList”).
Refer to the macAddress attirbute in 11.10.2 - Bridge access list config-

uration attributes on page 786, and also 8.5 - Bridge traffic classifica-
tion by filtering on page 344 for detailed information.
Advanced filter 1. Add and configure a bridge/accessList[ ] object. E.g. accessList[myList].

2. Apply the access list by typing the index name of the bridge/access-
List[ ] object as value of the accessList element in the bridging struc-
ture (e.g. “myList”).
Use the advanced filter to filter bridged frames, taking into account
source and destination MAC address ranges, the layer 3 protocol
field and VLAN tag and priority bits.
Refer to the advancedFilter attribute in 11.10.2 - Bridge access list con-
figuration attributes on page 786, and also 8.5 - Bridge traffic classi-
fication by filtering on page 344 for detailed information.
The advanced filters always have priority above the filters defined
using the macAddress attribute, i.e. the advanced filters will overrule the
filters defined using the macAddress attribute.
Using the advanced element of This means that access lists are applied as advanced access lists, as
the advancedFilter attribute part of QoS on bridged traffic, by setting the advanced element of the
advancedFilter attribute.
When using this feature, even more sophisticated actions can be
applied on the filtered packets.
Refer to the advanced element of the advancedFilter attribute in 11.10.2 -
Bridge access list configuration attributes on page 786, and also 8.6
- Bridge traffic classification by applying QoS on bridged traffic on
page 352 for detailed information.
Prevent broadcasts and multi- Configure the limitBroadcasts element in the bridging structure, refer to
casts from flooding to all inter- 8.2.6 - Explaining the bridging structure on page 318 for detailed infor-
faces mation.
Access restrictions on the protocol stack
You can apply the following access restrictions on the protocol stack
Access restrictions on Quick configuration

management data
Inbound simple access list Configure the accessList attribute in the management object.
with “allow” and/or “deny” Refer to 11.12 - Management configuration attributes on page 799 for
rules. detailed information.
Inbound extended access list 1. Add and configure a profiles/policy/traffic/ipTrafficPolicy[ ] object. E.g.
with “allow” and/or “deny” ipTrafficPolicy[myMgtList].
rules. 2. Apply the traffic policy by typing the index name of the ipTrafficPolicy[
] object as value of the accessPolicy attribute in the management
object (e.g. “myMgtList”).
Refer to 7.11.10 - Applying a traffic policy as an extended access list

on an IP interface on page 278 for detailed information.
Easy protocol restrictions Configure the telnet, ftp, tftp and snmp attributes in the management
without the need of an access object.
list (Telnet, FTP, TFTP, Refer to 11.12 - Management configuration attributes on page 799 for
SNMP: allow / deny).
detailed information.
Access restrictions per IP Configure the mgmtAccess element in the ip structure.

interface (allow / deny)
Refer to 5.2.3 - Explaining the ip structure on page 56 for detailed
information.
Access restrictions per bridge Configure the localAccess attribute in the bridgeGroup object.
interface (on VLAN level: Refer to 11.10.1 - Bridge group configuration attributes on page 772
allow / deny) for detailed information.
Setting up an inbound extended access list on the protocol stack
This section explains how to set up an extended access list, and how it can be applied on the protocol
stack.
Proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to

the profiles/policy/traffic object and add an ipTrafficPolicy[
] object underneath (refer to 4.4 - Adding an object to
the containment tree on page 45 and 11.7.1 - IP traf-
fic policy configuration attributes on page 592).
2 In the traffic policy object you just created, make sure that the configuration attribute
method is set to trafficShaping (this is the default value).
3 Configure the configuration attribute trafficShaping to match you filter criteria. Also refer to
7.11.10 - Applying a traffic policy as an extended access list on an IP interface on
page 278.
4 Go to the management object and enter the index name of the traffic policy object you cre-
ated in step 1 as value of the accessPolicy attribute.
Important remark
It is possible that the 1424 SHDSL Router has to answer to DHCP requests or ter-
minate L2TP and IPsec tunnels. In that case, if you set up an access list on the protocol
stack, then make sure that these protocols are allowed access to the protocol stack.
9.3 Tuning the bandwidth on the LAN interface
This section explains how to tune the bandwidth on the LAN interface, both in inbound and outbound
direction.
A maximum inbound and outbound bandwidth can be configured. This allows limiting the traffic coming
in or sent out on the Ethernet interface.
This is suitable:
• in inbound direction, when the Ethernet interface is connected to another NTU device with a higher
bandwidth capacity.
• in outbound direction, when using the Ethernet interface as the network interface with another NTU
device with limited WAN bandwidth.
• 9.3.1 - Data rate on the LAN interface on page 377
• 9.3.2 - Calculation of the data size correction on the LAN interface on page 378
9.3.1 Data rate on the LAN interface
Limiting the bandwidth
• Outbound
It is possible to have the outbound bandwidth on the LAN interface tuned in such a way that further up
in the link, the remote device does not drop any data packets.
When the outgoing data rate on the LAN interface is too high, it is possible that the remote device which
has to forward the LAN data, will start dropping data packets because it receives too much data and does
not have the capacity to forward the data at the same rate. Therefore, the outbound bandwidth on the
LAN interface can be limited.
A bandwidth configuration attribute is present on the LAN interfaces, with the possibility to:
- set the Committed Information Rate or CIR.
- set the maximum length (number of packets) of the queues where the incoming data is queued
when the CIR quotum is exceeded.
- fine tune the bandwidth, using bandwidth calculation correction parameters.
• Inbound
It is possible to have the inbound bandwidth on the LAN interface tuned in such a way that the Ethernet
interface does not drop any data packets.
When the incoming data rate on the LAN interface is too high, it is possible that the Ethernet interface
will start dropping data packets because it receives too much data and does not have the capacity to
forward the data at the same rate. Therefore, the inbound bandwidth on the LAN interface can be limited.
An inboundBandwidth configuration attribute is present on the LAN interfaces, with the possibility to:
- set the Committed Information Rate or CIR.
- set the maximum length (number of packets) of the queues where the incoming data is queued
when the CIR quotum is exceeded.
- fine tune the bandwidth, using bandwidth calculation correction parameters.
- apply a priority policy.
Bandwidth correction
If the remote device forwards the data over a WAN link using an encapsulation which requires extra
headers, it is difficult to calculate the overhead which has been added (inbound) or will be added (out-
bound) to the data. The inboundBandwidth/correction and bandwidth/correction attributes help in doing this.
Refer to:
• the inboundBandwidth attribute in 11.3 - LAN interface configuration attributes on page 509 for a detailed
explanation of the inbound bandwidth configuration.
• the bandwidth attribute in 11.3 - LAN interface configuration attributes on page 509 for a detailed expla-
nation of the outbound bandwidth configuration.
• 9.3.2 - Calculation of the data size correction on the LAN interface on page 378 for an example .
9.3.2 Calculation of the data size correction on the LAN interface
The actual calculation in outbound direction is explained here by using an example, refer to the following:
The actual correction of the data size is done according to a specific formula as stated in the previous
figure, with:
• line data = the total amount of data that is sent out on the WAN line.
• LAN data = number of data bytes on the LAN interface.
• Actual data = LAN data - MAC header.
• Overhead = number of overhead bytes added by the WAN line encapsulation to the actual data.
• frameData = the actual amount of data bytes in 1 frame on the line.
• frameHeader = the actual amount of header bytes in 1 frame on the line.
As the bandwidth correction depends on the size of the packets that are sent out on the LAN, this cal-
culation is performed on each packet separately. This allows the actual number of bytes that are needed
on the WAN interface of the remote device to be adjusted for each packet individually.
This mechanism ensures that no data is lost in the remote device.
9.4 Configuring L2TP tunnels
This section introduces the Layer 2 Tunnelling Protocol (L2TP) and gives a short description of the
attributes you can use to configure L2TP.
• 9.4.1 - Introducing L2TP tunnels on page 380
• 9.4.2 - Setting up an L2TP tunnel on page 382
• 9.4.3 - How does an L2TP tunnel work? on page 385
• 9.4.4 - Setting up a main and back-up tunnel on page 386
9.4.1 Introducing L2TP tunnels
What is an L2TP tunnel?
The Layer 2 Tunnelling Protocol (L2TP) is a protocol used for connecting VPNs (Virtual Private Net-
works) over public lines. More specific, it allows you to set up virtual PPP connections. In other words,
an L2TP tunnel simulates an additional PPP interface which directly connects two routers with each
other.
Concrete, using the Layer 2 Tunnelling Protocol you can connect several private and physically dis-
persed local networks with each other over public lines (such as the Internet) in order to create one big
(virtual) local network. This without the need for address translation.
L2TP tunnel terminology
The following table gives some specific L2TP terminology:
Term Description
L2TP Access Con- A node that acts as one side of an L2TP tunnel. It is a peer to the L2TP Network
centrator (LAC) Server (LNS). Packets sent from the LAC to the LNS require tunnelling with the
L2TP protocol.
L2TP Network A node that acts as one side of an L2TP tunnel. It is a peer to the L2TP Access
Server (LNS) Concentrator (LAC). The LNS is the logical termination point of a PPP session
that is being tunnelled from the remote system by the LAC.
Tunnel A tunnel exists between a LAC-LNS pair. The tunnel consists of a Control Con-
nection and zero or more L2TP sessions. The tunnel carries encapsulated PPP
datagrams and Control Messages between the LAC and the LNS.
Control Connection A control connection operates in-band over a tunnel to control the establish-
ment, release, and maintenance of sessions and of the tunnel itself.
Control Messages Control messages are exchanged between LAC and LNS pairs, operating in-
band within the tunnel protocol. Control messages govern aspects of the tunnel
and sessions within the tunnel.
L2TP tunnel encapsulation
The following table shows the L2TP encapsulation on the LAN and WAN interface:
Interface L2TP encapsulation
WAN interface The L2TP encapsulation on the WAN interface is as follows:
LAN interface The L2TP encapsulation on the LAN interface is as follows:

9.4.2 Setting up an L2TP tunnel
Refer to 9.4.1 - Introducing L2TP tunnels on page 380 for an introduction.

To set up an L2TP tunnel, proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to the router/tunnels object, select the
l2tpTunnels attribute and add one or more entries to this table.
Use this attribute to configure the Layer 2 Tunnelling Protocol tunnels you want to set up.
Add a row to the l2tpTunnels table for each L2TP tunnel you want to set up.
2 Configure the elements of the l2tpTunnels table:

• name. Use this element to assign an administrative name to the tunnel.
• remark. Use this element to write down any text, message, remark, etc. of up to 64
characters.
• adminStatus. Use this element to activate or deactivate the tunnel.
• mode. Use this element to determine whether for the corresponding tunnel, IP packets
are treated by the routing process, the bridging process or both.
• priorityPolicy. Use this element to apply a priority policy on the L2TP tunnel.
• ip. Use this element to configure the IP related parameters of the tunnel. Building an
L2TP tunnel is based on logical interfaces. Those logical interfaces have their own IP
address. Refer to 5.2.3 - Explaining the ip structure on page 56 for more information.
• bridging. Use this element to configure the bridging related parameters in case the mode
attribute is set to bridging or routingAndBridging. Refer to 8.2.6 - Explaining the bridging
structure on page 318 for more information.
• l2tp. Use this element to configure the L2TP related parameters of the tunnel. See
below.
• backup. Use this element to configure the back-up related parameters of the tunnel.
• inboundBandwidth. Use this element to configure the inbound bandwidth of the L2TP tun-
nel.
Refer to l2tpTunnels on page 659 for more information.

Step Action
3 Configure the l2tp structure in the l2tpTunnels table. The most important elements in this
structure are:
• localIpAddress. Use this element to set the IP address that serves as start point of the
L2TP tunnel.
• remoteIpAddress. Use this element to set the IP address that serves as end point of the
L2TP tunnel.
• type. Use this element to specify the tunnel type (incoming or outgoing).
• mode. Use this element to set the L2TP mode of the 1424 SHDSL Router (LAC, LNS
or auto). Only use auto in case a OneAccess router is located at both sides of the tun-
nel.
Refer to l2tpTunnels/l2tp on page 661 for more information.
Remarks
• L2TP tunnels can also be set up by an IP host. The 1424 SHDSL Router is transparent for tunnels
set up by a host.
• Multiple L2TP tunnels are possible on a single link. Currently, only one single PPP session is possible
per L2TP tunnel.
Example - configuring an L2TP tunnel
Suppose private network 1 has to be interconnected to private network 2 over the Internet. For this pur-
pose you want to set up an L2TP tunnel between the two access routers of these private networks.
So first create a route between the WAN interfaces of Router A and B. Then set up the tunnel between
the WAN interfaces of Router A and B (i.e. the tunnel start point is IP address 207.46.197.101, the tunnel
end point is IP address 198.182.196.56).
The following figure shows how to set up the L2TP tunnel:
9.4.3 How does an L2TP tunnel work?
Suppose a packet coming from the LAN has a destination address for a network that is accessible
through an L2TP tunnel. The following happens:
Phase Description
1 The packet goes through the routing decision process. If the

result of this decision is a route which uses the tunnel interface,
then the packet is encapsulated in PPP first, then L2TP, UDP
and finally IP.
2 Then the packet goes through the routing decision process again. This time using the
outer IP header.
3 The packet is routed over the Internet using the outer IP header.
4 The packet is received in the tunnel's end point, where it is then routed again using the
original IP header.
9.4.4 Setting up a main and back-up tunnel
Refer to 9.4.1 - Introducing L2TP tunnels on page 380 for an introduction.

This example explains how to set up a main and a back-up tunnel. More specifically how to use the
l2tpTunnels/backup element to do so.
Suppose private network 1 has to be interconnected to private network 2 over the Internet. For this pur-
pose you want to set up an L2TP tunnel between the two access routers of these private networks. What
is more, you want one main tunnel and one back-up tunnel.
Configure this example as follows:
Step Action
1 Add two entries to the l2tpTunnels table: one entry for the main tunnel and one for the back-
up tunnel. Configure these entries as described in 9.4.2 - Setting up an L2TP tunnel on
page 382.
Typically the main tunnel is of the type outgoing leased line, whereas the back-up tunnel
usually is an outgoing dial tunnel.
2 Now, by adding two entries to the routingTable, create two routes to network 2: one main
route (through the main tunnel) and one back-up route (through the back-up tunnel).
Differentiate the main route from the back-up route by giving them a different preference:
the main route is preferred (i.e. it’s preference value is lower) above the back-up route (it’s
preference value is higher).
Step Action
3 Now use the backup element in the l2tpTunnels table to optimise the back-up process. Con-
figuring the backup element allows you to quickly set up a back-up tunnel as soon as the
main tunnel goes down, instead of waiting on several time-outs before the back-up tunnel
is set up.
For the main tunnel, you could configure the backup structure as follows:
The backup structure contains the following elements:

• interface. Use this element to enter the name of the back-up tunnel.
• timeOut. Use this element to set the set-up time-out of the main tunnel in seconds. If
the main tunnel is not set up within the specified time-out, then the back-up tunnel is
set up.
• autoRetry. This element is only relevant in case the type element of the main tunnel is
set to outgoingLeasedLine. Use this element to determine, if a leased line tunnel does not
come up, whether it has to keep trying to come up (yes) or quit after one try (no).
4 Configuring the above results in the following:

• The main route and tunnel are up.
⇒Data destined for network 2 goes over the main route/tunnel to network 2.
• The main tunnel goes down.
⇒The back-up tunnel is set up immediately. Data destined for network 2 now goes
over the back-up route/tunnel to network 2.
• The main route and tunnel come up again.
⇒Data destined for network 2 goes over the main route/tunnel again since this is the
preferred route.
Some remarks
1. The back-up mechanism only works for routing.

2. Typically the main tunnel is a leased line tunnel, whereas the back-up tunnel usually is a dial tunnel.
3. You can create an alternating back-up mechanism by letting the main tunnel refer to the back-up tun-
nel and vice versa. In that case you could set …
- the backup/autoRetry of the main tunnel to no, to avoid that both main and back-up tunnel are up at
the same time.
- the l2tp/noTrafficTimeOut of the back-up tunnel to 0, to “simulate” a leased line tunnel with the advan-
tage that this tunnel does not come up when the 1424 SHDSL Router boots. The back-up tunnel
will only come up (and stay up) at the moment it is triggered.
4. If in the situation as described in remark 3. you set the l2tp/noTrafficTimeOut of the back-up tunnel to
anything else than 0, then it is best to set the backup/autoRetry of the main tunnel to yes. This because
if the back-up tunnel goes down due to the no traffic time-out, then it does not trigger the main tunnel
to come up again. Moreover, due to the main/back-up routes in the routingTable, the only available
route remains the back-up route through the back-up tunnel (since the main tunnel and hence main
route stay down). However, in this case you have to keep in mind that setting up a dial tunnel can
take a long time (especially when using IPSEC with IKE).
9.5 Configuring GRE tunnels
This section introduces GRE tunnels. The following gives an overview of this section:
• 9.5.1 - Introducing GRE tunnels on page 390
• 9.5.2 - Setting up a GRE tunnel on page 391
• 9.5.3 - When does a GRE tunnel come up? on page 393
• 9.5.4 - Combining GRE Tunnels with IPSEC on page 394
• 9.5.5 - Some remarks on GRE tunnels on page 394
• 9.5.6 - Example - configuring GRE tunnels on page 395
9.5.1 Introducing GRE tunnels
GRE tunnels with optional IPSEC have been added to the TDRE for inter vendor compatibility.
GRE stands for: Generic Routing Encapsulation. As the name indicates, a GRE tunnel is a generic tun-
nel that transports packets in IP packets. IP connectivity must be present in order to allow a GRE tunnel
to function.
A wide variety of protocol packet types can be encapsulated in IP tunnels, creating a virtual point-to-point
link at remote points over an IP internetwork.
GRE is capable of handling the transportation of multiprotocol and IP multicast traffic between two sites,
which only have IP unicast connectivity.
9.5.2 Setting up a GRE tunnel
To set up an GRE tunnel, proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to the router/tunnels object, select the gre-
Tunnels attribute and add one or more entries to this table:
Use this attribute to configure the GRE tunnels you want to set up. Add a row to the gre-
Tunnels table for each GRE tunnel you want to set up.
2 Configure the elements of the greTunnels table:

• name. Use this element to assign an administrative name to the tunnel.
• remark. Use this element to write down any text, message, remark, etc. of up to 64
characters.
• adminStatus. Use this element to activate or deactivate the tunnel.
• priorityPolicy. Use this element to apply a priority policy on the GRE tunnel.
• ip. Use this element to configure the IP related parameters of the tunnel. Building an
GRE tunnel is based on logical interfaces. Those logical interfaces have their own IP
address. Refer to 5.2.3 - Explaining the ip structure on page 56 for more information.
• gre. Use the gre structure to configure the GRE related parameters of the tunnel.
• inboundBandwidth. Use this element to configure the inbound bandwidth of the GRE tun-
nel.
Refer to the greTunnels attribute in 11.9.5 - GRE tunnel configuration attributes on

Step Action
3 Configure the gre structure in the greTunnels table. The elements in this structure are:
• localIpAddress. Use this element to set the official IP address that serves as start point
of the GRE tunnel.
• localInterface. Use this element to set the startpoint of the tunnel to the address of the
interface referenced by localInterface.
• remoteIpAddress. Use this element to set the official IP address that serves as end point
of the GRE tunnel.
• remoteRoute. Use this element to allow default route filtering.
• tos. Use this element to copy the TOS byte value from the IP header of the payload,
or to force the TOS byte to a fixed value of 0...255.
• dontfragmentBit. Use this element to copy the dontFragment bit value from the IP header
of the payload to the new GRE IP header.
• ttl. Use this element to copy the ttl byte value from the IP header of the payload, or to
force the ttl byte to a fixed value of 0...255.
• mtu.Use this element to set the Maximum Transmission Unit of the tunnel. This MTU
will override the MTU on the outgoing interface if it is smaller.
Configure the gre structure in the greTunnels table in 11.9.5 - GRE tunnel configuration
attributes on page 683 for more information.
9.5.3 When does a GRE tunnel come up?
GRE tunnels are designed to be completely stateless. This means that each tunnel end-point does not
keep any information about the state or availability of the remote tunnel end-point. A consequence of this
is that the local tunnel end-point router does not have the ability to bring the line protocol of the GRE
tunnel interface down if the remote end of the tunnel is unreachable.
As soon as there is a route to the endpoint, which can be the default route, the tunnel status will be up.
This means the user can see an operational tunnel at both ends, even though it is possible that no traffic
can pass through the tunnel just yet.
The ability to mark an interface as down when the remote end of the link is not available, is used in order
to remove any routes (specifically static routes) in the routing table that use that interface as the out-
bound interface.
Specifically, if the line protocol for an interface is changed to down, then any static routes that point out
that interface are removed from the routing table. This allows for the installation of an alternate (floating)
static route or for Policy Based Routing (PBR) to select an alternate next-hop or interface.
Normally, a GRE Tunnel interface comes up as soon as it is configured and it stays up as long as there
is a valid tunnel source address or interface which is up. The tunnel destination IP address must also be
routable.
This is true even if the other side of the tunnel has not been configured. This means that a static route
or PBR forwarding of packets via the GRE tunnel interface remains in effect even though the GRE tunnel
packets do not reach the other end of the tunnel.
9.5.4 Combining GRE Tunnels with IPSEC
GRE tunnels are sometimes combined with IPSEC.

IPSEC however does not support IP multicast packets. This prevents dynamic routing protocols from
running successfully over an IPSEC VPN network.
Since GRE tunnels do support IP multicast, a dynamic routing protocol can be run over a GRE tunnel.
This way, the GRE IP unicast packets can be encrypted using IPSEC. The IPSEC encryption is per-
formed after the addition of the GRE encapsulation.
9.5.5 Some remarks on GRE tunnels
• Some remarks with regard to OSPF in combination with GRE tunnels:

- The GRE default settings of the ttl attribute is copy, which means inside the tunnel the IP packet
will copy the ttl packet from the original, right before it enters the tunnel. Going from some interface
on the router to the tunnel interface will decrease the ttl with 1.
- OSPF sends packets to its neighbours, which means it will send with a ttl of 1. If the router is con-
figured to use OSPF, it will send out packets to it neighbours. Which means that when the packet
enters the tunnel its ttl will decrease to 0 and the router will not send the packet into the tunnel. For
the user it will seem that OSPF is broken, but it is not. The only way to prevent this, is to set the
ttl parameter of the GRE tunnel to a number high enough so that the packets will cross the tunnel.
• Traceroute suffers from the same problem. The first packet sent out through the tunnel will be dis-
carded. As long as the hops to travel between tunnel endpoints is larger then the TTL, packets will
die inside the tunnel.
• The GRE/IPSEC tunnels can inherit their endpoint addresses from the IKE configuration.
When using IKE, we use IP addresses as local and remote ID's but also hostnames and usernames.
If we don't give the IP addresses to IKE, IKE is capable of learning these through the negotiation proc-
ess. If the GRE/IPSEC tunnel has no local and/or remote address configured, it will inherit the local
and remote IP address from IKE.
• A GRE tunnel is capable of learning its localIpAddress from an interface with a name matching the one
configured in localInterface.
If localIpAddress is also configured, localIpAddress and the address learned from the interface matching
the configuration attribute localInterface, must match to become operational. If not, the tunnel will not
be added.
• GRE and GRE/IPSEC tunnels have been tested up to 32 simultaneous tunnels.
9.5.6 Example - configuring GRE tunnels
The following figure shows a typical GRE tunnel setup:

The configuration in CLI format, for plain GRE, of the different devices is as follows:
T2000
SET
{
LIST
{
sysName = "TTF GRE/Functional test 1 - router 1"
sysContact = "stsy"
sysLocation = "Tecap Test Setup 38"
}
SELECT lanInterface1
{
LIST
{
ip =
{
address = 172.31.96.93
netMask = 255.255.255.192
icmpRedirects = "disabled"
}
mode = "routing"
}
}
{
LIST
{
ip =
{
address = 172.31.124.229
netMask = 255.255.255.252
}
mode = "routing"
}
}
SELECT ip
{
SELECT router
{
LIST
{
defaultRoute =
{
gateway = 172.31.96.125
}
routingTable =
{
[a] =
{
network = 172.31.124.232
mask = 255.255.255.248
gateway = 172.31.124.230
}
[a] =
{
network = 172.31.124.248
mask = 255.255.255.248
interface = "tunnel1"
}
[a] =
{
network = 172.31.124.240
mask = 255.255.255.248
}
}
}
SELECT tunnels
{
LIST
{
greTunnels =
{
[a] =
{
name = "tunnel1"
ip =
{
address = 1.1.1.1
remote = 1.1.1.2
}
gre =
{
localIpAddress = 172.31.124.229
remoteIpAddress = 172.31.124.233
}
}
[a] =
{
name = "tunnel2"
ip =
{
address = 1.1.2.1
remote = 1.1.2.2
}
gre =
{
}
}
}
}
}
}
}
SELECT management
{
LIST
{
cms2Address = 1
ctrlPortProtocol = "management"
}
}
}
T2001
SET
{
LIST
{
sysContact = "stsy"
}
{
LIST
{
ip =
{
address = 172.31.124.235
netMask = 255.255.255.248
}
mode = "routing"
}
}
{
LIST
{
ip =
{
address = 172.31.124.230
netMask = 255.255.255.252
}
mode = "routing"
}
}
SELECT ip
{
SELECT router
{
LIST
{
defaultRoute =
{
gateway = 172.31.124.229
}
}
}
}
SELECT management
{
LIST
{
cms2Address = 2
}
}
}
T2002
SET
{
LIST
{
sysContact = "stsy"
}
{
LIST
{
ip =
{
address = 172.31.124.234
netMask = 255.255.255.248
}
mode = "routing"
}
}
SELECT ip
{
SELECT router
{
LIST
{
routingTable =
{
[a] =
{
mask = 0.0.0.0
}
[a] =
{
mask = 0.0.0.0
gateway = 172.31.124.235
preference = 15
}
[a] =
{
network = 172.31.124.229
mask = 255.255.255.252
gateway = 172.31.124.235
}
}
}
SELECT tunnels
{
LIST
{
greTunnels =
{
[a] =
{
name = "tunnel2"
ip =
{
address = 1.1.2.2
remote = 1.1.2.1
}
gre =
{
}
}
}
}
}
}
}
SELECT management
{
SELECT loopback
{
LIST
{
ipAddress = 172.31.124.241
}
}
}
SELECT management
{
LIST
{
cms2Address = 4
}
}
}
T2004
SET
{
LIST
{
sysContact = "stsy"
}
SELECT lanInterface
{
LIST
{
ip =
{
address = 172.31.124.233
netMask = 255.255.255.248
}
mode = "routing"
}
}
SELECT ip
{
SELECT router
{
LIST
{
routingTable =
{
[a] =
{
mask = 0.0.0.0
}
[a] =
{
mask = 0.0.0.0
gateway = 172.31.124.235
preference = 15
}
[a] =
{
network = 172.31.124.229
mask = 255.255.255.252
gateway = 172.31.124.235
}
}
}
SELECT tunnels
{
LIST
{
greTunnels =
{
[a] =
{
name = "tunnel1"
ip =
{
address = 1.1.1.2
remote = 1.1.1.1
}
gre =
{
}
}
}
}
}
}
}
SELECT management
{
SELECT loopback
{
LIST
{
ipAddress = 172.31.124.249
ipNetMask = 255.255.255.248
}
}
}
SELECT management
{
LIST
{
cms2Address = 3
}
}
}
The configuration in CLI format, for IPSEC GRE, of the different devices is as follows:
T2000
SET
{
LIST
{
sysContact = "stsy"
}
{
LIST
{
ip =
{
address = 172.31.96.93
netMask = 255.255.255.192
icmpRedirects = "disabled"
}
mode = "routing"
}
}
{
LIST
{
ip =
{
address = 172.31.124.229
netMask = 255.255.255.252
}
mode = "routing"
}
}
SELECT ip
{
SELECT router
{
LIST
{
defaultRoute =
{
gateway = 172.31.96.125
}
routingTable =
{
[a] =
{
network = 172.31.124.232
mask = 255.255.255.248
gateway = 172.31.124.230
}
[a] =
{
network = 172.31.124.248
mask = 255.255.255.248
}
[a] =
{
network = 172.31.124.240
mask = 255.255.255.248
}
}
}
SELECT tunnels
{
LIST
{
ipsecGreTunnels =
{
[a] =
{
name = "tunnel1"
ip =
{
address = 1.1.1.1
remote = 1.1.1.2
}
gre =
{
ipsec =
{
ikePresharedSA =
{
ikeSA = "ike"
localId =
{
ipAddress = 172.31.124.229
}
remoteId =
{
ipAddress = 172.31.124.233
}
}
}
}
}
[a] =
{
name = "tunnel2"
ip =
{
address = 1.1.2.1
remote = 1.1.2.2
}
gre =
{
ipsec =
{
ikePresharedSA =
{
ikeSA = "ike"
localId =
{
ipAddress = 172.31.124.229
}
remoteId =
{
ipAddress = 172.31.124.234
}
}
}
}
}
}
}
}
SELECT ikeSA[ike]
{
}
}
}
SELECT management
{
LIST
{
cms2Address = 1
}
}
}
T2001
SET
{
LIST
{
sysContact = "stsy"
}
{
LIST
{
ip =
{
address = 172.31.124.235
netMask = 255.255.255.248
}
mode = "routing"
}
}
{
LIST
{
ip =
{
address = 172.31.124.230
netMask = 255.255.255.252
}
mode = "routing"
}
}
SELECT ip
{
SELECT router
{
LIST
{
defaultRoute =
{
gateway = 172.31.124.229
}
}
}
}
SELECT management
{
LIST
{
cms2Address = 2
}
}
}
T2002
SET
{
LIST
{
sysContact = "stsy"
}
{
LIST
{
ip =
{
address = 172.31.124.234
netMask = 255.255.255.248
}
mode = "routing"
}
}
SELECT ip
{
SELECT router
{
LIST
{
routingTable =
{
[a] =
{
mask = 0.0.0.0
}
[a] =
{
mask = 0.0.0.0
gateway = 172.31.124.235
preference = 15
}
[a] =
{
network = 172.31.124.229
mask = 255.255.255.252
gateway = 172.31.124.235
}
}
}
SELECT tunnels
{
LIST
{
ipsecGreTunnels =
{
[a] =
{
name = "tunnel2"
ip =
{
address = 1.1.2.2
remote = 1.1.2.1
}
gre =
{
ipsec =
{
ikePresharedSA =
{
ikeSA = "ike"
localId =
{
ipAddress = 172.31.124.234
}
remoteId =
{
ipAddress = 172.31.124.229
}
}
}
}
}
}
}
}
SELECT ikeSA[ike]
{
LIST
{
phase1 =
{
type = "server"
}
}
}
}
}
SELECT management
{
LIST
{
cms2Address = 4
}
SELECT loopback
{
LIST
{
ipAddress = 172.31.124.241
}
}
}
}
T2004
SET
{
LIST
{
sysContact = "stsy"
}
SELECT lanInterface
{
LIST
{
ip =
{
address = 172.31.124.233
netMask = 255.255.255.248
}
mode = "routing"
}
}
SELECT wanInterface
{
SELECT line
{
LIST
{
standard = "lite"
}
}
}
SELECT ip
{
SELECT router
{
LIST
{
routingTable =
{
[a] =
{
mask = 0.0.0.0
}
[a] =
{
network = 172.31.124.229
mask = 255.255.255.252
gateway = 172.31.124.235
}
}
}
SELECT tunnels
{
LIST
{
ipsecGreTunnels =
{
[a] =
{
name = "tunnel1"
ip =
{
address = 1.1.1.2
remote = 1.1.1.1
}
gre =
{
ipsec =
{
ikePresharedSA =
{
ikeSA = "ike"
localId =
{
ipAddress = 172.31.124.233
}
remoteId =
{
ipAddress = 172.31.124.229
}
}
}
type = "incoming"
}
}
}
}
}
SELECT ikeSA[ike]
{
LIST
{
phase1 =
{
type = "server"
}
}
}
}
}
SELECT management
{
LIST
{
cms2Address = 3
}
SELECT loopback
{
LIST
{
ipAddress = 172.31.124.249
ipNetMask = 255.255.255.248
}
}
}
}
9.6 Configuring IP security
This section introduces IP security (IPSEC) and gives a short description of the attributes you can use
to configure IPSEC.
• 9.6.1 - Introducing IPSEC on page 408
• 9.6.2 - Introducing IKE on page 411
• 9.6.3 - Introducing native IPSEC tunnels on page 416
• 9.6.4 - Setting up an IPSEC secured tunnel using a manual SA on page 417
• 9.6.5 - Setting up an IPSEC secured tunnel using an IKE preshared SA on page 419
• 9.6.6 - Setting up an IPSEC secured tunnel using an IKE certificate SA on page 420
• 9.6.7 - Setting up an IPSEC secured L2TP tunnel using a manual SA on page 421
• 9.6.8 - Setting up an IPSEC secured L2TP tunnel using an IKE preshared SA on page 423
• 9.6.9 - Setting up an IPSEC secured L2TP tunnel using an IKE certificate SA on page 425
• 9.6.10 - Setting up an IPsec secured GRE tunnel using a manual SA on page 427
• 9.6.11 - Setting up an IPsec secured GRE tunnel using an IKE preshared SA on page 429
• 9.6.12 - Setting up an IPsec secured GRE tunnel using an IKE certificate SA on page 431
• 9.6.13 - Obtaining security certificates manually on page 433
• 9.6.14 - Obtaining security certificates through SCEP on page 437
• 9.6.15 - The hardware accelerator (HWA) chip on page 439
9.6.1 Introducing IPSEC
What is IPSEC?
IPSEC (Internet Protocol Security) is a framework for a set of protocols for security at the network or
packet processing layer of network communication. Earlier security approaches have inserted security
at the application layer of the communications model. IPSEC is deployed widely to implement Virtual Pri-
vate Networks (VPNs). A big advantage of IPSEC is that security arrangements can be handled without
requiring changes to individual user computers.
IPSEC compatibility
IPSEC on the 1424 SHDSL Router is compatible with IPSEC on Cisco devices and on Linux.
The IPSEC modes
IPSEC features two basic modes: transport mode or tunnel mode:

• The 1424 SHDSL Router supports L2TP and GRE tunnels over IPSEC. IPSEC is used in transport
mode. I.e. traffic destined for an L2TP or GRE tunnel is secured with IPSEC (refer to RFC 3193,
Securing L2TP using IPSEC).
• As opposed to using IPSEC in transport mode with L2TP or GRE as transport protocol, IPSEC can
also be used in tunnel mode. This is referred to as native IPSEC tunnels. A performance increase
can be noticed because there is no control protocol: 10% increase with null encryption/null authenti-
cation, up to 70% increase with DES, small packets.
The IPSEC protocols (ESP and AH)
IPSEC provides two choices of security service:

• Authentication Header (AH), essentially allows authentication of the sender of data and parts of the
IP header.
• Encapsulating Security Payload (ESP), allows both authentication of the sender and encryption of
data as well.
The specific information associated with each of these services is inserted into the packet in a header
that follows the IP packet header.
What is AH?
AH is a protocol used for authenticating a data stream. It uses a cryptographic hash function to produce
a MAC from the data in the IP packet. This MAC is then transmitted with the packet, allowing the remote
gateway to verify the integrity of the original IP packet, making sure the data has not been tampered with
on its way through the Internet.
Apart from the IP packet data, AH also authenticates parts of the IP header.
The AH protocol inserts an AH header after the original IP header, and in tunnel mode, the AH header
is inserted after the outer header, but before the original, inner, IP header.
What is ESP?
The ESP protocol is used for both encryption and authentication of the IP packet. It can also be used to
do either encryption only, or authentication only.
The ESP protocol inserts an ESP header after the original IP header, in tunnel mode, the ESP header
is inserted after the outer header, but before the original, inner, IP header.
All data after the ESP header is encrypted and/or authenticated. The difference from AH is that ESP also
provides encryption of the IP packet. The authentication phase also differs in that ESP only authenticates
the data after the ESP header; thus the outer IP header is left unprotected.
What is a security association (SA)?
IPSEC provides different options for performing network encryption and authentication. The two com-
municating nodes must determine exactly which algorithms to use (e.g. DES or 3DES for encryption,
MD5 or SHA for integrity and authentication) and must share session keys. All this information is
described in the Security Association (SA). In other words, the security association is simply a statement
of the negotiated security policy between two devices.
An SA is, by nature, unidirectional. Hence the need for more than one SA per connection. In most cases,
where either ESP or AH is used, two SAs will be created for each connection: one describing the incom-
ing traffic and the other the outgoing. In cases where ESP and AH are used in conjunction, four SAs will
be created.
What is the Security Parameter Index (SPI)?
An SPI is an arbitrary value that uniquely identifies which SA to use at the receiving host. The sending
host uses the SPI to identify and select which SA to use to secure every packet. The receiving host uses
the SPI to identify and select the encryption algorithm and key used to decrypt packets.
What is a manual SA?
There are two types of security associations:

• Manual SA
• Dynamic SA
The 1424 SHDSL Router currently supports Manual SA. This requires no negotiation. All values, includ-
ing the keys, are static and specified in the configuration. As a result, each peer must have the same
configured options for communication to take place.
In principle, security association is unidirectional (half-duplex). I.e. one SA for the inbound traffic and one
SA for the outbound traffic. The 1424 SHDSL Router also supports full-duplex SA (one SA for both
inbound and outbound traffic).
IPSEC encryption
You can encrypt the data using the Data Encryption Standard (DES or 3DES).
DES is a widely-used method of data encryption using a private (secret) key. Like other private key cryp-
tographic methods, both the sender and the receiver must know and use the same private key. DES
applies a 56-bit key to each 64-bit block of data. Triple DES applies three keys in succession.
IPSEC authentication
You can not only encrypt but also authenticate the data using the Keyed-Hashing for Message Authen-
tication (HMAC).
HMAC is a mechanism for message authentication using cryptographic hash functions. HMAC can be
used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret
shared key.
9.6.2 Introducing IKE
What is IKE?
IKE (Internet Key Exchange) is an IPSEC protocol used to ensure security for VPN negotiation and
remote host or network access. IKE defines an automatic means of negotiation and authentication for
IPSEC security associations (SA).
IKE has three main tasks:
• Provide a means for the endpoints to authenticate each other.
• Establish new IPSEC connections (create SA pairs).
• Manage existing connections.
IKE is layered on UDP and uses UDP port 500 to exchange IKE information between the security gate-
ways. Therefore, UDP port 500 packets must be permitted on any IP interface involved in connecting a
security gateway peer.
IKE negotiation
The process of negotiating session parameters consists of a number of phases and modes, which can
be briefly described as follows:
• IKE phase 1: Negotiate how IKE should be protected.
• IKE phase 2:
- Negotiate how IPSEC should be protected.
- Derive some fresh keying material from the key exchange in phase 1, to provide session keys to
be used in the encryption and authentication of the VPN data flow.
Both the IKE and the IPSEC connections have limited lifetimes, described both as time (seconds) and
data (kilobytes). These lifetimes prevent a connection from being used too long, which is desirable from
a cryptanalysis perspective.
The IPSEC lifetime is generally shorter than the IKE lifetime. This allows for the IPSEC connection to be
re-keyed simply by performing another phase 2 negotiation. There is no need to do another phase 1
negotiation until the IKE lifetime has expired.
What is an IKE proposal?
An IKE proposal is a suggestion of how to protect data. The proposals contain all parameters needed,
such as algorithms used to encrypt and authenticate the data etc.
IKE encryption
The IKE encryption specifies the encryption algorithm used in the IKE negotiation, and depending on the
algorithm, the size of the encryption key used. Supported encryption algorithms are:
• Data Encryption Standard (DES).
• Advanced Encryption Standard (AES).
IKE authentication
The IKE authentication specifies the authentication algorithm used in the IKE negotiation. Supported
authentication algorithms are:
• HMAC MD5
• HMAC SHA-1
What is the IKE DH group?
The IKE DH group specifies the Diffie-Hellman group to use when doing key exchanges in IKE. Sup-
ported Diffie-Hellman groups are:
• Diffie-Hellman group 1 (768 bit)
What is PFS?
Without PFS (Perfect Forwarding Secrecy), initial keying material is "created" during the key exchange
in phase 1 of the IKE negotiation. In phase 2 of the IKE negotiation, encryption and authentication ses-
sion keys will be extracted from this initial keying material.
When using PFS, completely new keying material will always be created upon re-key. Should one key
be compromised, no other key can be derived using that information.
What is the IPSEC DH group?
This is a Diffie-Hellman group much like the one for IKE. However, this one is used solely for PFS.
What is IKE preshared key authentication?
With preshared key authentication, you must manually configure the same, shared symmetric key on
both systems. The preshared key is used only for the primary authentication. The two negotiating entities
then generate dynamic shared keys for the IKE SAs.
What is IKE security certificate authentication?
Security certificates are used for public key cryptography, also referred to as asymmetric key cryptogra-
phy. Public key cryptography uses a pair of related, but different keys. One key, the private key, is asso-
ciated with a specific system or entity and is kept secret. The other key is the public key and can be
distributed freely. The public and private keys are mathematically related so that data encrypted with the
public key can only be decrypted with the private key.
Obtaining a security certificate
There are 2 ways to obtain the right certificates in order to negotiate an SA with another device through
IKE:
• Manually: install all certificates yourself. In this case you have to transfer the certificates yourself.
• SCEP: Simple Certificate Enrollment Protocol. In this case the certificate is obtained without an actual
transfer taking place.
The device should obtain 2 certificates:

1. A trusted certificate from the Certificate Authority (CA). This is a certificate that contains the CAs pub-
lic information and is self-signed by the CA. So it is a self-signed certificate to the CA and a CA cer-
tificate to the 1424 SHDSL Router.
2. A self-certificate, containing the device its information, signed by the Certificate Authority (CA). The
device generates a private/public key pair and associates its private key with the CA-signed certifi-
cate.
Security certificate terminology
Summarised, the terminology associated with certificates is:

• Trusted (CA) certificate. This is a certificate containing external information and signed by a CA. A
self-certificate is associated with a certain CA certificate because that CA signed the self-certificate.
• Self-certificate. This is a certificate containing local information and signed by a CA. It will authenti-
cate the device with another device.
• Self-signed certificate. This is a certificate containing local information and signed by yourself. Since
it is self-signed it has no authentication purpose to yourself, but it can be used by other devices in
order to authenticate themselves with yet another device. In that case the local device is a third party
device.
Certificates - some general remarks
• Windows Vista
When using certificates in Windows Vista, the Enhanced Key Usage and Subject Alternative Name fields
are verified by Vista when the Verify Name and Usage attribute is ticked:
• OpenSSL
Certificates can also by created using OpenSSL, refer to http://www.openssl.org.
The self-certificate request must always be created on the 1424 SHDSL Router; the matching private
key must remain on the device.
• The Subject field
The Subject field of a certificate contains some official abbreviations that can be verified by the remote
device. They are the following:
• CN. This is the subject name.
• OU. This is the department name.
• O. This is the name of the organisation or company.
• L. This is the city where you are located.
• S. This is the state or province where you are located.
• C. This is the country where you are located.
This information, or part of it, must be filled in when obtaining a self-certificate. For this, refer to router1424/
fileSystem/generateSelfCertificateRequest on page 1004 and router1424/fileSystem/getSelfCertificateScep on page 1008.
For an example, refer to the figures below:
What is NAT-T?
The problem with IKE and IPSEC protocols is that they were not designed to work through NAT. There-
fore, NAT-T (NAT Traversal) has evolved. NAT traversal (RFC 3947 and 3948) is an add-on to the IKE
and IPsec protocols that makes them work when going through NAT.
NAT-T makes the following changes to the IKE and IPSEC protocols:
• NAT-T support. NAT-T is only used if both ends support it. For this purpose, NAT-T aware VPNs send
out a special "vendor ID", telling the other end that it understand NAT-T and which specific versions
of the draft it supports.
• NAT detection. Both IPSEC peers send hashes of their own IP addresses along with the source UDP
port used in the IKE negotiations. This information is used to see whether the IP address and source
port each peer uses is the same as what the other peer sees. If the source address and port have
not changed, then the traffic has passed NAT along the way and NAT-T is not necessary. If the
source address and/or port has changed, then the traffic has passed NAT and NAT-T is used.
• UDP encapsulation. Once the IPSEC peers have decided that NAT-T is necessary, the IKE negotia-
tion is moved away from UDP port 500 to port 4500. This is necessary since certain NAT devices
treat UDP packet to port 500 differently from other UDP packets in an effort to work around the NAT
problems with IKE. The problem is that this special handling of IKE packets may in fact break the IKE
negotiations, which is why the UDP port used by IKE has changed.
Another problem NAT-T resolves is that the ESP protocol is an IP protocol. There is no port information
like in TCP and UDP, which makes it impossible to have more than one NATed client connected to the
same remote gateway at the same time. Because of this, ESP packets are encapsulated in UDP. The
ESP-UDP traffic is sent on port 4500, the same port as IKE when NAT-T is used. Once the port has been
changed all following IKE communications are done over port 4500. Keep-alive packets are also being
sent periodically to keep the NAT mapping alive.
9.6.3 Introducing native IPSEC tunnels
As opposed to using IPSEC in transport mode with L2TP as transport protocol, IPSEC can also be used
in tunnel mode. This is referred to as native IPSEC tunnels. A performance increase can be noticed
because there is no control protocol: 10% increase with null encryption/null authentication, up to 70%
increase with DES, small packets.
Inter vendor compatibility
Native IPSEC has been added to the TDRE for inter vendor compatibility.
Since the payload of an IPSEC packet in tunnel mode is not defined, the proxyId element has been added
to allow a tunnel to be setup with other vendors. The proxyId field must match with the access list of the
remote tunnel. Only 1 access list is supported per tunnel.
Refer to 11.9.4 - Native ipsec tunnel configuration attributes on page 673 for more information about the
proxyId element.
The proxyId of an IPSEC L2TP tunnel cannot be configured manually. It is always set to:
• UDP
• localIp
• 255.255.255.255
• 1701
• remoteIp
• 255.255.255.255
• 1701
Refer to 9.6 - Configuring IP security on page 407 for more information about IPSEC L2TP tunnels.
Implementation
A big difference with other encapsulations is that IPSEC tunnels are not handled as interfaces: the ip
element is not present in the configuration of the tunnel.
When a tunnel is up, i.e. always with Manual SA or when the IKE SA is up, data is directly routed to the
IPSEC engine. Received encrypted frames are decrypted and passed to the router where they are re-
routed using the destination address of the inner IP header.
The implementation has been done according to RFC 2402, RFC 2406, RFC2401. Ipsec tunnels are
state-less; nevertheless, some states have been introduced to follow up/set up IPSEC tunnels. Refer to
11.9.4 - Native ipsec tunnel configuration attributes on page 673 for the configuration attributes of native
IPSEC tunnels; refer to 12.9.5 - Native IPSEC tunnel status attributes on page 934 for the status
attributes.
9.6.4 Setting up an IPSEC secured tunnel using a manual SA
Refer to 9.6.1 - Introducing IPSEC on page 408 for an introduction.

In order to set up an L2TP tunnel secured with IPSEC using a manual SA, proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to the router

object and add a manualSA[ ] object underneath (refer to 4.4 -
Adding an object to the containment tree on page 45).
E.g. manualSA[mySA]
2 Now configure the attributes of the manualSA[ ] object you added in step 1 to your needs.
These attribute are:
• espEncryptionAlgorithm. Use this attribute to select the algorithm that will be used to
encrypt the data when using IPSEC.
• espEncryptionKey. Use this attribute to define the key that will be used in the encryption
/ decryption process when using IPSEC.
• espAuthenticationAlgorithm. Use this attribute to select the algorithm that will be used to
authenticate the data when using IPSEC.
• espAuthenticationKey. Use this attribute to define the key that will be used in the authen-
tication process when using IPSEC.
• spi. Use this attribute to set the SPI value. Each security association must have a
unique SPI value because this value is used to identify the security association.
Refer to 11.9.6 - Manual SA configuration attributes on page 691 for more information.
3 In the 1424 SHDSL Router containment tree, go to the router/tunnels object, select the ipsec-
Tunnels attribute and add one or more entries to this table.
Use this attribute to configure the IP secured tunnels you want to set up. Add a row to the
ipsecTunnels table for each IPSEC tunnel you want to set up.
Step Action
4 In the ipsecTunnels table, go to the ipsec element.

Choose between full-duplex or half-duplex manual SA, using the elements fdxManualSA or
hdxManualSA respectively (refer to ipsecTunnels/ipsec on page 677 for more information):
• In case of full-duplex manual SA, enter the index name of the manualSA[ ] object you
added in step 1, as value of the fdxManualSA element:
• In case of half-duplex manual SA, the element hdxManualSA must be used, which is a
structure with following elements:
- inbound. To apply a security association on the inbound traffic, type the index name
of the manualSA[ ] object in this field.
- outbound. To apply a security association on the outbound traffic, type the index
name of the manualSA[ ] object in this field.
By doing so, you apply the security association on the IPSEC tunnel.
9.6.5 Setting up an IPSEC secured tunnel using an IKE preshared SA
Refer to 9.6.2 - Introducing IKE on page 411 for an introduction.

In order to set up an L2TP tunnel secured with IPSEC using an IKE preshared SA, proceed as follows:
Step Action

and add an ikeSA[ ] object underneath (refer to 4.4 - Adding an
object to the containment tree on page 45).
E.g. ikeSA[mySA]
2 Now configure the attributes of the ikeSA[ ] object you added in step 1 to your needs.
• phase1. Use this attribute to configure the parameters of phase 1 in the IKE negotiation
process. IKE phase 1 negotiations are used to establish IKE SAs. These SAs protect
the IKE phase 2 negotiations.
process.
Refer to 11.9.7 - IKE SA configuration attributes on page 696 for more information.
Use this attribute to configure the IPSEC tunnels you want to set up. Add a row to the
4 In the ipsecTunnels table, go to the ipsec element:

• Set the first part of this element to ikePresharedSA.
• The second part of this element is a structure which, on its turn, contains the following
elements:
- ikeSA. Use this element to apply a certain IKE preshared key security
association on the IPSEC L2TP tunnel. Do this by typing the ikeSA
object its index name in this field.
- localId. Use this element to set the local identifier for use in IKE phase 1 negotiation.
- remoteId. Use this element to set the remote identifier for use in IKE phase 1 nego-
tiation.
- preSharedKey. Use this element to set the preshared key string. This key string in
combination with the selected IKE DH group is used to calculate the key during the
key exchange in phase 1 of the IKE negotiation.
- proxyId. Use this element to set up a tunnel with other vendors.
Refer to ipsecTunnels/ipsec/ikePresharedSA on page 679 for more information.

9.6.6 Setting up an IPSEC secured tunnel using an IKE certificate SA

In order to set up an L2TP tunnel secured with IPSEC using an IKE certificate SA, proceed as follows:
Step Action
1 Obtain and load the necessary security certificates. You can do this either …
• manually. Refer to 9.6.13 - Obtaining security certificates manually on page 433.
or
• through SCEP. Refer to 9.6.14 - Obtaining security certificates through SCEP on
page 437.

E.g. ikeSA[mySA]
process.
Use this attribute to configure the IPSEC tunnels you want to set up. Add a row to the
5 In the ipsecTunnels table, go to the ipsec element:

• Set the first part of this element to ikeCertificateSA.
elements:
- ikeSA. Use this element to apply a certain IKE certificate security asso-
ciation on the IPSEC L2TP tunnel. Do this by typing the ikeSA object its
index name in this field.
This has to be the same as the IP address / hostname / username in the certificate
of the local device.
tiation. This has to be the same as the IP address / hostname / username in the
certificate of the remote device.
- proxyId. Use this element to set up a tunnel with other vendors.
Refer to ipsecTunnels/ipsec/ikeCertificateSA on page 681 for more information.

9.6.7 Setting up an IPSEC secured L2TP tunnel using a manual SA

In order to set up an L2TP tunnel secured with IPSEC using a manual SA, proceed as follows:
Step Action

E.g. manualSA[mySA]
encrypt the data when using IPSEC.
/ decryption process when using IPSEC.
authenticate the data when using IPSEC.
tication process when using IPSEC.
ipsecL2tpTunnels attribute and add one or more entries to this table.
Use this attribute to configure the IP secured Layer 2 Tunnelling Protocol tunnels you
want to set up. Add a row to the ipsecL2tpTunnels table for each IPSEC L2TP tunnel you
want to set up.
4 Configure the non-IPSEC related parameters in the ipsecL2tpTunnels table as described in

9.4.2 - Setting up an L2TP tunnel on page 382.
The only IPSEC related parameter is the ipsec element in the l2tp structure of the
ipsecL2tpTunnels table.
Step Action
5 In the ipsecL2tpTunnels table, go to the l2tp structure. In this structure, go to the ipsec ele-
ment:
• Set the first part of this element to fdxManualSA or hdxManualSA to choose between full-
duplex or half-duplex manual SA (refer to ipsecL2tpTunnels/l2tp/ipsec on page 667 for more
information).
• In the second part of this element, enter the index name of the manualSA[ ] object you
added in step 1 as value of the ipsec element.
By doing so, you apply the security association on the L2TP tunnel.
E.g. in our example, select fdxManualSA in the
first part of the ipsec element and enter the
string mySA in the second part of the ipsec
element.
9.6.8 Setting up an IPSEC secured L2TP tunnel using an IKE preshared SA

In order to set up an L2TP tunnel secured with IPSEC using an IKE preshared SA, proceed as follows:
Step Action

E.g. ikeSA[mySA]
process.
want to set up.

Step Action
ment:
elements:
association on the IPSEC L2TP tunnel. Do this by typing the ikeSA
tiation.
Refer to ipsecL2tpTunnels/l2tp/ipsec/ikePresharedSA on page 669 for more information.

9.6.9 Setting up an IPSEC secured L2TP tunnel using an IKE certificate SA

In order to set up an L2TP tunnel secured with IPSEC using an IKE certificate SA, proceed as follows:
Step Action
or
page 437.

E.g. ikeSA[mySA]
process.
want to set up.

Step Action
ment:
elements:
ciation on the IPSEC L2TP tunnel. Do this by typing the ikeSA object its
Refer to ipsecL2tpTunnels/l2tp/ipsec/ikeCertificateSA on page 671 for more information.

9.6.10 Setting up an IPsec secured GRE tunnel using a manual SA

In order to set up an GRE tunnel secured with IPsec using a manual SA, proceed as follows:
Step Action

E.g. manualSA[mySA]
encrypt the data when using IPsec.
/ decryption process when using IPsec.
authenticate the data when using IPsec.
tication process when using IPsec.
GreTunnels attribute and add one or more entries to this table:
Use this attribute to configure the IP secured GRE tunnels you want to set up. Add a row
to the ipsecGreTunnels table for each IPsec GRE tunnel you want to set up.
4 Configure the non-IPsec related parameters in the ipsecGreTunnels table as described in

9.5.2 - Setting up a GRE tunnel on page 391.
The only IPsec related parameter is the ipsec element in the gre structure of the ipsecGre-
Tunnels table.
Step Action
5 In the ipsecGreTunnels table, go to the gre structure. In this structure, go to the ipsec element:
• Set the first part of this element to fdxManualSA or hdxManualSA to choose between full-
duplex or half-duplex manual SA (refer to the ipsecGreTunnels/gre element in 11.9.5 -
GRE tunnel configuration attributes on page 683 for more information).
• In the second part of this element, enter the index name of the manualSA[ ] object you
added in step 1 as value of the ipsec element.
By doing so, you apply the security association on the GRE tunnel.
E.g. in our example, select fdxManualSA in the first part of
the ipsec element and enter he string mySA in the second
part of the ipsec element.
9.6.11 Setting up an IPsec secured GRE tunnel using an IKE preshared SA

In order to set up an GRE tunnel secured with IPsec using an IKE preshared SA, proceed as follows:
Step Action

E.g. ikeSA[mySA]
process.
GreTunnels attribute and add one or more entries to this table.
4 Configure the non-IPsec related parameters in the ipsecGreTunnels table as described in

Tunnels table.
Step Action
elements:
association on the IPsec GRE tunnel. Do this by typing the ikeSA object
its index name in this field.
tiation.
- proxyId. Use this element to set up a tunnel with other vendors, and define the type
of payload carried by the ipsec frame. This element must match with the access
list of the remote tunnel.
Refer to the ipsecGreTunnels/gre element in 11.9.5 - GRE tunnel configuration attributes on

9.6.12 Setting up an IPsec secured GRE tunnel using an IKE certificate SA

In order to set up an GRE tunnel secured with IPsec using an IKE certificate SA, proceed as follows:
Step Action
or
page 437.

E.g. ikeSA[mySA]
process.
GreTunnels attribute and add one or more entries to this table.
5 Configure the non-IPsec related parameters in the ipsecGRETunnels table as described in

Tunnels table.
Step Action
elements:
ciation on the IPsec GRE tunnel. Do this by typing the ikeSA object its
- proxyId. Use this element to define the type of payload carried by the ipsec frame.
Refer to the ipsecGreTunnels/gre element in 11.9.5 - GRE tunnel configuration attributes on

9.6.13 Obtaining security certificates manually

In order to set up an L2TP tunnel secured with IPSEC using an IKE certificate SA, you have to obtain
and load the necessary security certificates. This procedure shows how to do this manually.
To obtain security certificates manually, proceed as follows:
Step Action
1 Configure a valid timeserver since all certificates are tested on their validity. Refer to time-
Server on page 803 for more information.
2 Obtaining the trusted certificate
Retrieve a trusted certificate from a CA.

The following gives an example of this procedure with the Microsoft Certificate Services.
Example
1. Download and install SCEP server software (e.g. the Microsoft SCEP Add-on for Cer-
tificate Services).
2. Once installed, surf to the Microsoft Certificate Services server.
3. Select Retrieve the CA certificate or certificate revocation list and click on the Next
button.
4. Select the current CA certificate (Current), the encoding (e.g. DER encoded) and
select Download CA certificate.
5. Save the trusted certificate on your computer. E.g. with filename certnew.cer.
3 Download the trusted certificate to the file system of the 1424 SHDSL Router. Refer to
29.9 - Downloading files to the file system on page 2081.
Step Action
4 Load the trusted certificate into the memory of the 1424 SHDSL Router.
In the containment tree of the 1424 SHDSL Router, select the Status group and go to the
fileSystem object. Then execute the loadTrustedCertificate action with the previously down-
loaded trusted certificate filename as argument value.
⇒The trusted certificate is loaded into the 1424 SHDSL Router its memory. Once you
executed the saveCertificates action (refer to step 10), you may delete the original
trusted certificate file from the file system (in our example the certnew.cer file).
5 Obtaining the self-certificate
Generate a self-certificate request on the 1424 SHDSL Router.

fileSystem object. Then execute the generateSelfCertificateRequest action with at least a
filename (e.g. certreq.txt), a private key name and your IP address or hostname or user-
name as argument values.
⇒The self-certificate request file is written to the file system and the 1424 SHDSL
Router generates a public/private key pair. Note that the longer the key length, the
longer it takes to generate the keys.
Important remarks
• It is important to note that at least one of the three following fields may not be left
empty: ipAddress, hostname and/or username. This information is written in the Subject
Alternative Name field of the certificate itself.
• Remember the private key name. You need it again later on in the procedure in order
to load the associated signed self-certificate into the memory of the 1424 SHDSL
Router.
• Do not reboot the 1424 SHDSL Router from this point onwards until you reach the end
of the procedure. Else the public/private key pair is lost making it impossible to load
the associated signed self-certificate into the memory of the 1424 SHDSL Router.
6 Download the self-certificate request file to your computer (e.g. using FTP or TFTP).
Step Action
7 Let the CA sign the self-certificate request in order to obtain a signed self-certificate.
The following gives an example of this procedure with the Microsoft Certificate Services
(Chicken).
Example
1. Surf to the Microsoft Certificate Services server: http://chicken/certsrv/.

2. Select Request a certificate and click on the Next button.
3. Select Advanced request and click on the Next button.

4. Select Submit a certificate request using a base64 encoded PKCS #10 file or a
renewal request using a base64 encoded PKCS #7 file and select the Next button.
5. Locate the self-certificate request file you created in step 5 and downloaded to your
computer in step 6. Open it in a plain text editor (in our example, open the certreq.txt
file in e.g. NotePad). Select all the text and copy it.
6. Paste the self-certificate request text you just copied in the Saved Request box and
click on the Submit button.
⇒The CA signs the self-certificate request making it a valid signed self-certificate.

7. Select the encoding (e.g. DER encoded) and select Download CA certificate.
8. Save the signed self-certificate on your computer. E.g. with filename selfcert.cer.
8 Download the signed self-certificate to the file system of the 1424 SHDSL Router. Refer
to 29.9 - Downloading files to the file system on page 2081.
Step Action
9 Load the signed self-certificate into the memory of the 1424 SHDSL Router.
fileSystem object. Then execute the loadSelfCertificate action with the previously downloaded
signed self-certificate filename and the private key name you remember in step 5 as
argument values.
⇒The signed self-certificate is loaded into the 1424 SHDSL Router its memory. Once
you executed the saveCertificates action (refer to step 10), you may delete the origi-
nal signed self-certificate file from the file system (in our example the selfcert.cer
file).
10 Permanently store the certificates and generated public/private key pair.

fileSystem object. Then execute the saveCertificates action.
⇒The certificates and the associated public/private key pair are stored on the 1424
SHDSL Router. They are loaded each time the 1424 SHDSL Router starts up.
You may delete the original trusted certificate and signed self-certificate files from
the file system (in our example the certnew.cer and selfcert.cer files).
11 You can check which trusted and signed self-certificates are loaded by looking at the sta-
tus attributes router1424/fileSystem/trustedCertificates on page 1002 and router1424/fileSystem/
selfCertificates on page 1002.
9.6.14 Obtaining security certificates through SCEP

In order to set up an L2TP tunnel secured with IPSEC using an IKE certificate SA, you have to obtain
and load the necessary security certificates. This procedure shows how to do this through SCEP.
To obtain security certificates through SCEP, proceed as follows:
Step Action
1 Configure a valid timeserver since all certificates are tested on their validity. Refer to time-
Server on page 803 for more information.
2 Make sure you have a SCEP server running (e.g. the Microsoft SCEP Add-on for Certif-
icate Services).
3 Load the trusted certificate into the memory of the 1424 SHDSL Router using SCEP.
fileSystem object. Then execute the getTrustedCertificateScep action with at least the SCEP
server IP address and the SCEP URL1 as argument values.
⇒The trusted certificate is loaded into the 1424 SHDSL Router its memory.
Step Action
4 Load the signed self-certificate into the memory of the 1424 SHDSL Router using SCEP.
fileSystem object. Then execute the getSelfCertificateScep action with at least the SCEP
server IP address, the SCEP URL, a private key name and your IP address or hostname
or username as argument values.
It is important to note that at least one of the three following fields may not be left
empty: ipAddress, hostname and/or username. This information is written in the Subject
Alternative Name field of the certificate itself.
⇒The signed self-certificate is loaded into the 1424 SHDSL Router its memory.
5 Permanently store the certificates and generated public/private key pair.
fileSystem object. Then execute the saveCertififcates action.
⇒The certificates and the associated public/private key pair are stored on the 1424
SHDSL Router. They are loaded each time the 1424 SHDSL Router starts up.
6 You can check which trusted and signed self-certificates are loaded by looking at the sta-
tus attributes router1424/fileSystem/trustedCertificates on page 1002 and router1424/fileSystem/
selfCertificates on page 1002.
1. Consult the manual of your SCEP server to find out which URL you have to specify.
9.6.15 The hardware accelerator (HWA) chip
Standard 1424 SHDSL Router versus 1424 SHDSL Router HWA
On the standard 1424 SHDSL Router, encryption in IPSEC is handled by the software. As this is a proc-
essor consuming task, the forwarding performance of the 1424 SHDSL Router decreases. Therefore,
the 1424 SHDSL Router is also available in a version with a HWA chip. This chip takes care of the DES
and 3DES encryption / decryption, unburdening the software of this task. This results in a better forward-
ing performance.
How to identify a 1424 SHDSL Router HWA version?
You can not distinguish a standard version from a HWA version on sight. However, you can distinguish
the two versions by looking at the status attribute router1424/sysDescr. In case you have a HWA version,
the string “HWA” or “3DES” appears in the sysDescr.
Example:
• 1424 SHDSL Router Txxxx/xxxxx 01/01/00 12:00 indicates that you have a standard version.
• 1424 SHDSL Router 3DES Txxxx/xxxxx 01/01/00 12:00 indicates that you have a 3DES version.
The status of the HWA chip
Whenever the 1424 SHDSL Router boots, it checks the presence of the HWA chip and does a diagnostic
test. Should these checks fail (e.g. because the HWA chip is faulty), then the following messages appear
in the status attribute router1424/messages:
• encryption chip init failed
• encryption chip diag failed
In case the HWA chip is faulty, the DES and 3DES encryption is done by the software as on the standard
1424 SHDSL Router.
9.7 Configuring RADIUS
This section introduces Remote Authentication Dial-In User Service (RADIUS) and gives a short descrip-
tion of the attributes you can use to configure RADIUS.
• 9.7.1 - Introducing RADIUS on page 441
• 9.7.2 - Enabling RADIUS for device access authentication on page 443
• 9.7.3 - Enabling RADIUS for network access authentication on page 445
• 9.7.4 - Enabling RADIUS for accounting on page 446
• 9.7.5 - Supported RADIUS attribute types on page 447
• 9.7.6 - Client (calling) IP settings on page 449
• 9.7.7 - NAS (called) IP settings on page 449
9.7.1 Introducing RADIUS
What is RADIUS?
Remote Authentication Dial-In User Service (RADIUS) is a client/server protocol and software that ena-
bles Network Access Servers (NAS) to communicate with a central server to authenticate dial-in users
and authorize their access to the requested system or service. RADIUS allows a company to maintain
user profiles in a central database that all remote servers can share. It provides better security, allowing
a company to set up a policy that can be applied at a single administered network point. Having a central
service also means that it's easier to track usage for billing and for keeping network statistics.
The following figure shows the interaction between a dial-in user, the RADIUS client and the RADIUS
server:
1. The user initiates PPP authentication to the NAS.

2. The NAS asks for a username and a password (if PAP or CHAP is active).
3. The user replies.
4. The RADIUS client sends the username and encrypted password to the RADIUS server.
5. The RADIUS server responds with accept, reject or challenge.
6. The RADIUS client acts upon services and services parameters bundled with accept or reject.
Authentication and authorisation using RADIUS
The RADIUS server can support a variety of methods to authenticate a user. When it is provided with
the username and original password given by the user, it can support PPP, PAP or CHAP and other
authentication mechanisms.
Typically, a user login consists of a query (Access-Request) from the NAS to the RADIUS server and a
corresponding response (Access-Accept or Access-Reject) from the server:
• Access-Request. The Access-Request packet contains the username, encrypted password, NAS IP
address, and port. The format of the request also provides information about the type of session that
the user wants to initiate.
• Access-Reject. When the RADIUS server receives the Access-Request from the NAS, it searches a
database for the username listed. If the username does not exist in the database, an Access-Reject
message is sent.
• Access-Accept. In RADIUS, authentication and authorisation are coupled together. If the username
is found and the password is correct, the RADIUS server returns an Access-Accept response, includ-
ing a list of attribute-value pairs that describe the parameters to be used for this session. Typical
parameters include service type, protocol type, IP address to assign the user (static or dynamic),
access list to apply, or a static route to install in the NAS routing table. The configuration information
in the RADIUS server defines what will be installed on the NAS.
The figure below illustrates the RADIUS authentication and authorization sequence:
Accounting using RADIUS
The accounting features of the RADIUS protocol can be used independently of RADIUS authentication
or authorisation. The RADIUS accounting functions allow data to be sent at the start and end of sessions,
indicating the amount of resources (such as time, packets, bytes, and so on) used during the session.
An Internet service provider (ISP) might use RADIUS access control and accounting software to meet
special security and billing needs.
Transactions between the client and RADIUS server are authenticated through the use of a shared
secret, which is never sent over the network. In addition, user passwords are sent encrypted between
the client and RADIUS server to eliminate the possibility that someone snooping on an insecure network
could determine a user's password.
9.7.2 Enabling RADIUS for device access authentication
Refer to 9.7.1 - Introducing RADIUS on page 441 for an introduction.

To prevent unauthorised access to the OneAccess devices themselves (for management purposes), you
can configure a password in the devices. However, instead of configuring the passwords in the devices
themselves, you can also use a RADIUS server for this purpose.
So in order to enable device access authentication with RADIUS, proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to the router object and select the radius
attribute.
2 Configure the following elements of the radius structure:

• authServers. Use this element to select an authentication server. You can create a list
of several authentication servers. The authServers table contains the following ele-
ments:
- address. Use this element to specify the IP address of the authentication server.
- secret. Use this element to set the shared secret to authenticate the transaction with
the authentication server.
- timeOut. Use this element to specify the authentication time-out.
• retries. Use this element to specify the number of retries before selecting the next
authentication server in the authServers table.
• login. Use this element to set the authentication of access to the 1424 SHDSL Router
using a management application (e.g. Telnet, FTP, TFTP, TMA, etc.). No accounting
data is sent to the server. The login element has the following values:
- disabled. No RADIUS login authentication is done.
- enabled. Login authentication is always done using a RADIUS server. Refer to step
3.
- fallback. Login authentication is done using a RADIUS server. However, if the server
is not available, then authentication is done using the local security table of the
device.
Step Action
3 If in step 2 you set the login element to enabled or fallback, then you have to configure user-
names and associated passwords on the RADIUS server.
The username and password have to be entered as follows: "username:password". If
the ‘:’ is omitted, then the string is considered to be a password.
Multiple passwords can be added using the same username. Access rights are sent
using the RADIUS attribute CLASS (25) encoded as a string carrying a binary value. The
bit definitions are:
• readAccess = 00000001B
• writeAccess = 00000010B
• securityAccess = 00000100B
• countryAccess = 00001000B (only used on aster4/5)
• fileAccess = 00010000B
Caution should be taken since all access to the device has to be authenticated by a
RADIUS server.
Refer to radius on page 634 for a complete explanation of the radius attribute.
9.7.3 Enabling RADIUS for network access authentication

The most typical application of RADIUS is where the RADIUS server authenticates dial-in users and
authorises their access to an ISP its network (in order to access the Internet).
So in order to enable network access authentication with RADIUS, proceed as follows:
Step Action
1 Configure a PPP(oA) link towards the remote network (e.g. the ISP’s network) and ena-
ble PAP or CHAP on this link.
Refer to 6.7 - Configuring PPP encapsulation on page 160 for more information.
attribute.

• authServers. Use this element to select an authentication server. You can create a list
of several authentication servers. The authServers table contains the following ele-
ments:
- address. Use this element to specify the IP address of the authentication server.
the authentication server.
- timeOut. Use this element to specify the authentication time-out.
• retries. Use this element to specify the number of retries before selecting the next
authentication server in the authServers table.
• ppp. Use this element to set the authentication of a PPP connection that uses PAP or
CHAP. The ppp element has the following values:
- disabled. PPP authentication is not done using a RADIUS server. It is done using
the local sysName/sysSecret or sessionName/sessionSecret of the device.
- enabled. PPP authentication is always done using a RADIUS server.
Note that the local configuration of username and password is ignored if a table of RADIUS servers exist.
Furthermore, remote IP address and remote netmask are ignored if a RADIUS server imposes these
attributes.
Refer to radius on page 634 for a complete explanation of the radius attribute.
9.7.4 Enabling RADIUS for accounting

Together with authentication, an Internet service provider (ISP) might use RADIUS for accounting pur-
poses (e.g. for billing or network statistics).
So in order to enable accounting with RADIUS, proceed as follows:
Step Action
attribute.

• acctServers. Use this element to select an accounting server. You can only select one
accounting server. The acctServers structure contains the following elements:
- address. Use this element to specify the IP address of the accounting server.
the accounting server.
- timeOut. Use this element to specify the accounting time-out.
• acctUpdate. Use this element to specify the time at which an update of the accounting
data should be send to the server.
Set this element to 0 (default) if no update is required. Note that this is not always sup-
ported by the accounting server.
9.7.5 Supported RADIUS attribute types
This section shows which RADIUS attribute types are supported by the 1424 SHDSL Router.
RADIUS authentication attribute types
(1) User-Name Is sent.
(2) User-Password Is sent in case of PAP, TELNET, FTP and TMA authentication.
(3) CHAP-Password Is sent in case of CHAP authentication.
(4) NAS-IP-Address Is sent (this is the IP address of the interface that received the incom-
ing call).
(5) NAS-Port-ID Is sent (this is the index of the interface that received the incoming
call).
(7) Framed-Protocol Is sent.
(8) Framed-IP-Address Supported. Local configuration is overruled when received.

• 255.255.255.255: client is allowed to choose an address. It must
be rejected if null.
• 255.255.255.254: remote IP address that is configured on the
NAS is sent to the remote client.
• any valid address: this address is taken as remote IP address.
Also see 9.7.6 - Client (calling) IP settings on page 449 and 9.7.7 -
NAS (called) IP settings on page 449 for NAS and remote client
behaviour when sending/learning IP addresses and masks.
(9) Framed-IP-Netmask Supported.

Also see 9.7.6 - Client (calling) IP settings on page 449 and 9.7.7 -
NAS (called) IP settings on page 449 for NAS and remote client
behaviour when sending/learning IP addresses and masks.
(22) Framed-Route Supported (1 metric).
(25) Class Is used to send the “accessRights” when using TELNET and TMA. Is
sent as a hexadecimal value.
(27) Session-Timeout Supported.
(32) NAS-Identifier Is sent (= sysName).
(33) Proxy-State
(60) CHAP-Challenge Is sent.
(62) Port-Limit Supported in case of multilink.
(80) Message-Authenticator HMAC MD5 authentication of access request. Is not required but is
sent for security reasons.
RADIUS accounting attribute types
(40) Status-Type Supported (values (1) Start, (2) Stop and (3) Update).
(41) Delay-Time Supported.
(42) Input-Octets Supported.
(43) Output-Octets Supported.
(44) Session-ID Supported.
(45) Authentic Supported (always value (1) RADIUS).
(46) Session-Time Supported.
(47) Input-Packets Supported.
(48) Output-Packets Supported.
(49) Terminate-Cause Supported (values (2) Lost Carrier, (5) Session Timeout and (6)
Admin Reset).
(50) Multi-Session-ID Supported in case of multilink.
(51) Link-Count Supported in case of multilink.

9.7.6 Client (calling) IP settings
The following table shows some cases of how and which IP addresses the client can learn on its PPP
link in case of RADIUS:
Case Description
1 IP address and mask are already configured on the client.

⇒Configured IP address and mask are used.
2 No IP address and mask are configured on the client, they are learned from the NAS.
⇒Normal case: add 3 routes (host, network and broadcast). However, if the learned
mask is 255.255.255.252, then no broadcast route is added. If the learned mask
is 255.255.255.255, then only a host route is added.
⇒If the gatewayPreference is not 0, then a default gateway is added via the PPP inter-
face with the configured preference.
⇒If the PPP link goes down, then remove all the routes.
3 No IP address is configured on the client. IP address is learned from the NAS, the mask
not.
⇒Configured IP address is used.
⇒Set mask to 255.255.255.255.
4 The client is configured in unnumbered mode (an IP address and mask are taken from
another interface for which the IP address and mask is configured).
⇒IP address and mask of the referenced interface are used.
9.7.7 NAS (called) IP settings
The following table shows some cases of how and which IP addresses the NAS sets on its PPP link in
case of RADIUS:
Case Description
1 An IP address and mask is configured or unnumbered mode is configured. The remote

client requests an IP address and mask.
⇒If the remote IP address does not fall within the network defined by the own IP
address and mask, then reject the VSO option 0.0.0.0 from the other side. (E.g.
remote IP = 10.0.0.1 and own IP = 192.168.0.1 / 255.255.255.0.)
⇒If (remote IP address and mask) = (local IP address and mask), then a host route
is added for the remote IP address to make sure that the remote can be reached
(via proxy ARP when the NAS is in unnumbered mode).
9.8 Configuring the stateful inspection firewall
The 1424 SHDSL Router features a stateful inspection firewall. This sections introduces the firewall and
explains how to configure it.
• 9.8.1 - Introducing the firewall on page 451
• 9.8.2 - Activating the firewall on page 457
• 9.8.3 - Adding an interface to a secure network (SNet) on page 458
• 9.8.4 - Defining an outbound SNet policy on page 460
• 9.8.5 - Defining an inbound SNet policy on page 462
• 9.8.6 - Defining an outbound self policy on page 464
• 9.8.7 - Defining an inbound self policy on page 466
• 9.8.8 - Configuring the firewall - rules of thumb on page 468
• 9.8.9 - Allowing access to the protocol stack when the firewall is active on page 469
• 9.8.10 - Determining which policies have to be defined on page 472
9.8.1 Introducing the firewall
Firewall types
In general, there are three types of firewall solutions:

• packet filter firewall. A packet filter firewall controls the flow of a datagram based on its source and
destination IP addresses and port numbers. The filtering is based on static permit and deny rules.
Refer to 9.2 - Configuring the access restrictions on page 370 for more information on packet filtering.
• proxy firewall. A proxy firewall acts, for each application, as server and client on the different sides of
the firewall.
• stateful inspection firewall. A stateful inspection firewall is actually a combination of a packet filter fire-
wall and a proxy firewall. Refer to What is stateful inspection? on page 451 for more information. The
firewall that is present on the 1424 SHDSL Router is a stateful inspection firewall.
What is stateful inspection?
Stateful inspection, also referred to as dynamic packet filtering, is a firewall architecture that works at the
network layer. Unlike static packet filtering, which examines a packet based on the information in its
header, stateful inspection tracks each connection traversing all interfaces of the firewall and makes sure
they are valid. An example of a stateful firewall may examine not just the header information but also the
contents of the packet up through the application layer in order to determine more about the packet than
just information about its source and destination. A stateful inspection firewall also monitors the state of
the connection and compiles the information in a state table. Because of this, filtering decisions are
based not only on administrator-defined rules (as in static packet filtering) but also on context that has
been established by prior packets that have passed through the firewall.
As an added security measure against port scanning, stateful inspection firewalls close off ports until
connection to the specific port is requested.
What is a Virtual Firewall System (VFS)?
A Virtual Firewall System (VFS) provides multiple logical firewalls for multiple networks, on one system.
That is, a service provider with numerous subscribers can provide firewalls separating and securing all
the subscribers and yet, is able to manage it from one system. This is accomplished by establishing
"security domains" controlled by Virtual Firewalls, with each firewall having its own defined security pol-
icy. Security domains are exclusive in that they are external to any other security domain in a given sys-
tem.
Virtual Firewalls are functionally similar to a simple firewall, and are configured with their own outbound
and inbound policies, and network objects. However, Virtual Firewalls enable easy management of a col-
lection of firewalls through policies at a defined security domain.
An SNet is a logical name by which we can identify each "security domain" network.
What is a Secure Network (SNet)?
A Secure Network (SNet) is a logical name by which we can identify a "security domain" controlled by
Virtual Firewalls (VF).
There are four “standard1” SNets:
• self (i.e. the 1424 SHDSL Router itself)
• internet (i.e. the internet or any other external network)
• corp (i.e. the corporate network)
• DMZ (i.e. the demilitarised zone)
1. In future releases of the TDRE, it will be possible to create custom SNets.

What are SNet and self in- and outbound policies?
Policy Description
outbound SNet With outbound policies configured for a host in a secure network, it can access var-
ious services on the internet or on other secure networks.
So an outbound SNet policy defines the traffic from an SNet to any SNet but the
self SNet.
inbound SNet With inbound policies configured for a secure network, a remote host can access
various services running on internal machines in this secure network. With
Reverse NAT enabled, you can forward a service request onto the external public
IP address from a remote host (a host in the Internet) to any one of the internal
machines in the secure network with private IP address, which is running that serv-
ice.
So an inbound SNet policy defines the traffic to an SNet from any SNet but the self
SNet.
outbound self With outbound self policies configured for the device itself, the device can access
services running on hosts in various secure networks.
So an outbound self policy defines the traffic from the device itself (self SNet) to
any SNet.
Policy Description
inbound self With inbound self policies configured for the device itself, services running on the
device itself can be accessed from various secure networks. For example, the
response to an ICMP echo request when a host in a secure network does a ping,
can be restricted by an inbound self policy.
So an inbound self policy defines the traffic to the device itself (self SNet) from any
SNet.
Which are the different types of attacks?
A network is vulnerable to attacks. Therefore, it is important to protect your network (e.g. with a firewall,
virus scanners, etc.). In general, there are five types of attacks:
Attack type Description
sniffing and port Sniffing is the term generally used for traffic monitoring within a network, while port
scanning scanning is used to find out information about a remote network. Both sniffing and
port scanning have the same objective: finding system vulnerabilities. However,
they take different approaches. Sniffing is used by an attacker already on the net-
work who wants to gather more information about the network. Port scanning is
used by someone who is interested in finding vulnerabilities on a system that is
unknown.
Denial of Service Denial of Service is a type of attack on a network that is designed to bring the net-
(DoS) work to its knees by flooding it with useless traffic. Many DoS attacks exploit limi-
tations in the TCP/IP protocols.
spoofing An IP spoofing attack is one in which the source IP address of a packet is forged.
There are generally two types of spoofing attacks:
• IP spoofing used in DoS attacks.
• man in the middle attacks.
IP spoofing-based DoS attacks are relatively simple. An attacker sends a packet

to the target host with a forged IP address (SYN). The targeted host sends an
acknowledgement (ACK) and waits for a response. The response never comes,
and these unanswered queries remain in the buffer of the targeted device. If
enough spoofed queries are sent, the buffer will overflow and the network device
will become unstable and crash.
Man in the middle attacks are much more difficult. Here, the attacker intercepts
traffic heading between two devices on the network. The attacker can either mon-
itor information or alter the data as it passes through the network.
exploits An exploit allows an attacker to take advantage of known weaknesses in operating

systems or applications to gain access to a server.
Attack type Description
viruses and The two most common types of network attacks are the virus and the worm. A virus
worms is a program used to infect a computer. It is usually buried inside another program,
known as a Trojan, or distributed as a stand-alone executable. Worms are often
confused with viruses, but they are very different types of code. A worm is self-rep-
licating code that spreads itself from system to system. A traditional virus requires
manual intervention to propagate itself.
Attack protection
A firewall not only controls in- and outbound traffic, it also protects your network against malicious
attacks. The different attacks are listed below:
Attack Description
SYN Flooding What is the SYN Flooding attack?
SYN Flooding is a well-known Denial Of Service (DOS) attack on TCP based serv-
ices. TCP needs a 3-way handshake before the actual communication starts
between two hosts. Whenever a new connection request comes in, the server allo-
cates some resources for serving it. A malicious intruder can forge a huge amount
of service requests over a very short period, and make the server run out of its
resources.
Source Routing What is the Source Routing attack?
With strict and loose source routing, as specified in IP standard RFC 791, one can
make datagrams take a predefined path towards a destination. In this way, an
intruder can gain more information about the corporate network, which he or she
can then misuse.
WinNuke What is the WinNuke attack?
WinNuke is a well-known Denial Of Service attack. This attack sends a string of

OOB (Out Of Band) data to the target computer on TCP port 139 (NetBIOS), caus-
ing it to lock up.
FTP Bounce What is the FTP Bounce attack?
With an FTP Bounce attack, an attacker issues a PORT command with IP address
and port number of some other system so that the server bounces the data to that
system.
IP Unaligned What is the IP Unaligned Timestamp attack?

Timestamp
With an IP Unaligned Timestamp attack, a packet with a timestamp option that is
not aligned on a 32-bit boundary crashes some systems. This is due to an una-
ligned memory access of the option.
MIME What is the MIME attack?
Certain web servers have no limit on the MIME headers that could be included in
a clients HTTP request. The only limits are: 8192 byte for each header, 300 sec-
onds on reading headers. Due to this limitation, by sending a large amount of 8000
byte headers, it is possible to consume a lot of memory (and CPU) and slow down
or even lock the server.
Attack Description
Sequence What is the Sequence Number Prediction attack?

Number Predic-
A TCP Sequence Number Prediction attack is when an attacker sets up a TCP
tion
connection (through the 3-way handshake) using a forged source address, without
seeing the target machine its responses. Predictable sequence numbers allow the
attacker to guess, with a high level of confidence, what the sequence number on
the SYN+ACK response from the target will be. This allows the attacker to com-
plete the handshake blindly by guessing a window of acknowledgement numbers
on the ACK packet. This allows a connection to be established where the source
address is different from that of the attacking machine.
Sequence What is the Sequence Number Out Of Range attack?

Number Out Of
A Sequence Number Out Of Range attack is when packets with out of range
Range
sequence number are received.
ICMP Error Mes- What is the ICMP Error Message attack?

sage
The Internet Control Message Protocol (ICMP) could be used to perform a number
of Denial Of Service attacks against TCP. Successful attacks may cause connec-
tion resets or reduction of throughput in existing connections, depending on the
attack type.
Ping Of Death What is the Ping Of Death attack?
A Ping Of Death attack is a Denial Of Service attack, which exploits the errors in
the oversize datagram handling mechanism of a TCP/IP stack. It is a well-known
problem that certain popular operating systems have difficulty in handling data-
grams more than the maximum datagram size defined by the IP standard. If hosts
running such operating systems come across oversized ping packets, they tend to
hang or crash.
IP Spoofing What is the IP Spoofing attack?
IP Spoofing is a network intrusion where a user pretending to be at a trusted IP

address gains access to a computer. The firewall makes sure that all traffic des-
tined to the corporate network is originated from the authorised sites in the internet.
IP Option What is the IP Option attack?
IP Option attacks are:

• zero length IP options.
• source routing options.
• unaligned timestamp options.
9.8.2 Activating the firewall
Refer to 9.8.1 - Introducing the firewall on page 451 for an introduction.

If you want to use the firewall function of the 1424 SHDSL Router, then you have to activate it first. Do
this as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to the router/firewall

object.
2 In the firewall object, set the inspection attribute to enabled.
3 Once the firewall is enabled, you can proceed with adding interfaces to SNets and defin-
ing policies.
9.8.3 Adding an interface to a secure network (SNet)

Before you can start defining policies for the firewall you have to add the interfaces, of which you want
that they are controlled by a (virtual) firewall, to an SNet.
To add an interface to an SNet, proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to the ip attribute

of the interface that you want to add to the SNet.
2 In the ip attribute structure, go to the sNet element. Use this element to add the interface
to the SNet.
The sNet element is a choice element. The first part of the sNet element has the following
values:
• name. Select this value if you want to add the interface to one of
the standard SNets. In the second part of the sNet element, use
the drop-down box to select one of the standard SNets: corp, dmz
or internet.
Note that if you select the value <opt> (default), then the interface
is not added to a secure network.
• custom. Currently, you can only select standard SNets. In future

releases of the TDRE, it will be possible to select custom created
SNets.
Important remark
Note that if you configure the 1424 SHDSL Router with TMA through the LAN interface (i.e. over an IP
network), then make sure that before you assign the LAN interface to an SNet, that you create an
inbound self policy so that TMA can access the protocol stack of the 1424 SHDSL Router.
• 9.8.7 - Defining an inbound self policy on page 466
• 9.8.9 - Allowing access to the protocol stack when the firewall is active on page 469
If you configure the 1424 SHDSL Router with TMA through the control port (i.e. through a serial connec-
tion), then there is no problem.
Example - adding an interface to an SNet
Suppose you have the following setup:
Now, if you want to add the LAN interface to the SNet “corporate” and the ATM PVC on the WAN inter-
face to the SNet “internet”, then configure this as follows:
9.8.4 Defining an outbound SNet policy

Once the firewall function is activated and the necessary interfaces are added to SNets, you can start to
define policies. As explained in What are SNet and self in- and outbound policies? on page 453, there
are 4 types of policies. This section explains how to define an outbound SNet policy.
To define an outbound SNet policy, proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to the firewall object, select the outbound-
Policies attribute and add one or more entries to this table.
Use this attribute to define outbound SNet policies. Add a row to the outboundPolicies table
for each outbound SNet policy you want to define.
2 Configure the elements of the outbound SNet policy you just created. These elements
are:
• sNet. Use this element to specify the name of the source SNet for which you want to
create an outbound SNet policy. By doing so, you create a policy for the traffic from
the source SNet to any SNet except the self SNet.
• sourceIp. Use this element to specify the source IP address(es) for which you want to
create an outbound SNet policy.
Note that if you leave the sourceIp element at its default value (<opt>), then no source
IP address(es) is/are specified.
• destIp. Use this element to specify the destination IP address(es) for which you want
to create an outbound SNet policy.
Note that if you leave the destIp element at its default value (<opt>), then no source IP
address(es) is/are specified.
• application. Use this element to specify the application for which you want to create an
outbound SNet policy.
Note that if you leave the application element at its default value (<opt>), then no appli-
cation is specified.
• action. Use this element to specify whether packets that fall within the specification of
the policy are passed on (allow) or dropped (deny).
• nat. Use this element to determine whether address translation has to be done for the
outbound SNet policy and, if so, which translation address has to be taken.
Note that if you leave the nat element at its default value (<opt>), then no address trans-
lation is done.
• log. Use this element to determine whether limited (disabled) or extended (enabled) log-
ging is done for this policy.
• name. Use this element to assign a name (description) to the outbound SNet policy.
Example - defining an outbound SNet policy
Reconsider the example shown in Example - adding an interface to an SNet on page 459. Suppose you
want that the computers on the corporate network can surf on the Internet.
In that case you have to define an outbound SNet policy from the corporate network to the Internet allow-
ing HTTP traffic. Configure this as follows:
9.8.5 Defining an inbound SNet policy

are 4 types of policies. This section explains how to define an inbound SNet policy.
To define an inbound SNet policy, proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to the firewall object, select the inbound-
Policies attribute and add one or more entries to this table.
Use this attribute to define inbound SNet policies. Add a row to the inboundPolicies table for
each inbound SNet policy you want to define.
2 Configure the elements of the inbound SNet policy you just created. These elements are:
• sNet. Use this element to specify the name of the destination SNet for which you want
to create an inbound SNet policy. By doing so, you create a policy for the traffic from
any SNet except the self SNet to the destination SNet.
create an inbound SNet policy.
to create an inbound SNet policy.
inbound SNet policy.
• nat. Use this element to determine whether address translation has to be done for the
inbound SNet policy and, if so, which translation address has to be taken.
Note that if you leave the nat element at its default value (<opt>), then no address trans-
lation is done.
• name. Use this element to assign a name (description) to the inbound SNet policy.
Example - defining an inbound SNet policy
have an FTP server in your corporate network and you want that it can be accessed from the Internet.
In that case you have to define an inbound SNet policy from the Internet to the corporate network allow-
ing FTP traffic. Configure this as follows:
9.8.6 Defining an outbound self policy

are 4 types of policies. This section explains how to define an outbound self policy.
To define an outbound self policy, proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to the firewall object, select the outbound-
SelfPolicies attribute and add one or more entries to this table.
Use this attribute to define outbound self policies. Add a row to the outboundSelfPolicies
table for each outbound self policy you want to define.
2 Configure the elements of the outbound self policy you just created. These elements are:
• sNet. Use this element to specify the name of the destination SNet for which you want
to create an outbound self policy. By doing so, you create a policy for the traffic from
the device itself (self SNet) to the destination SNet.
create an outbound self policy.
to create an outbound self policy.
outbound self policy.
• name. Use this element to assign a name (description) to the outbound self policy.
Example - defining an outbound self policy
want that the firewall (i.e. the 1424 SHDSL Router itself) can ping computers on the corporate network.
In that case you have to define an outbound self policy from the device itself to the corporate network
allowing ICMP traffic. Configure this as follows:
9.8.7 Defining an inbound self policy

are 4 types of policies. This section explains how to define an inbound self policy.
To define an inbound self policy, proceed as follows:
Step Action
1 In the 1424 SHDSL Router containment tree, go to the firewall object, select the inbound-
SelfPolicies attribute and add one or more entries to this table.
Use this attribute to define inbound self policies. Add a row to the inboundSelfPolicies table
for each inbound self policy you want to define.
2 Configure the elements of the inbound self policy you just created. These elements are:
• sNet. Use this element to specify the name of the source SNet for which you want to
create an inbound self policy. By doing so, you create a policy for the traffic from the
source SNet to the device itself (self SNet).
create an inbound self policy.
to create an inbound self policy.
inbound self policy.
• name. Use this element to assign a name (description) to the inbound self policy.
Example - defining an inbound self policy
want configured the 1424 SHDSL Router to be a DHCP server for the computers on the corporate net-
work. So it has to be able to accept DHCP requests from these computers on the corporate network.
In that case you have to define an inbound self policy from corporate network to the device itself allowing
DHCP traffic. Configure this as follows:
9.8.8 Configuring the firewall - rules of thumb
The following table lists some rules of thumb when configuring the firewall:
Rule Description
1 Only traffic that is transmitted or received on an interface that is assigned to an SNet is

inspected by the firewall.
2 If interfaces are assigned to SNets and if the firewall is activated but no policies are
defined yet, then all traffic on the SNet interfaces is denied (i.e. dropped), except multi-
casts and broadcasts.
3 When activating the firewall, carefully consider which applications/processes have to be

able to access the protocol stack of the 1424 SHDSL Router, so that you can include
them in the in- and/or outbound self policies. Else they are denied access to the protocol
stack.
For example, …
• suppose you want to access the 1424 SHDSL Router with TMA through the LAN inter-
face, then it has to be able to accept the TMA session. Therefore, you have to create
an inbound self policy that allows this.
• suppose that you configured the 1424 SHDSL Router to be a DHCP server, then it
has to be able to accept DHCP requests from clients. Therefore, you have to create
an inbound self policy that allows this.
• suppose that you configured the 1424 SHDSL Router to be a local DNS server but it
has to forward these DNS requests to an external DNS server, then it has to be able
to accept and receive DNS requests. Therefore, you have to create an inbound self
policy allowing to receive local DNS requests and an outbound self policy allowing to
send DNS requests to an external DNS server.
4 Traffic that is received on an SNet interface, has to be routed to another SNet interface.
Else it is dropped.
5 The most specific policy has to be listed first (i.e. the policy that specifies the narrowest
“range”).
For example, suppose that all computers but one are allowed to surf on the Internet, then
put the deny rule first and the allow rule second:
1. Deny surfing for computer X.
2. Allow surfing for all other computers.
6 You do not have to set up policies to allow the reverse session (i.e. the return path) of a
session that was initiated. These reverse sessions are set up and allowed automatically.
For example, if you define an outbound policy from the corporate network to the Internet
to allow web browsing (HTTP) and if a HTTP session from the corporate network to the
Internet is set up, then a reverse session from the Internet to the corporate network is set
up and allowed automatically. These reverse sessions can be seen in the status attribute
router1424/ip/router/firewall/reverseSessions on page 973.
9.8.9 Allowing access to the protocol stack when the firewall is active
As explained in 9.8.8 - Configuring the firewall - rules of thumb on page 468, when activating the firewall,
carefully consider which applications/processes have to be able to access the protocol stack of the 1424
SHDSL Router, so that you can include them in the in- and/or outbound self policies. Else they are
denied access to the protocol stack.
This section gives a non-exhaustive list of applications/processes that need access to the protocol stack
of the 1424 SHDSL Router to function properly.
Maintenance applications
All the maintenance applications with which you want to manage the 1424 SHDSL Router have to be
able to access the protocol stack:
Application Self policies to be defined
TMA inbound self:

• protocol: UDP
• port: 1728 (OneAccess)
Telnet inbound self:

• protocol: TCP
• port: 23 (telnet)
FTP inbound self:

• protocol: TCP
• port: 21 (ftp)
TFTP inbound self:

• protocol: UDP
• port: 69 (tftp)
Web Interface inbound self:

(web browser) • protocol: TCP
• port: 80 (www-http)
SNMP inbound self:

• protocol: TCP
• port: 161 (snmp)
Ping to device inbound self:

• protocol: ICMP
Ping from device outbound self:

• protocol: ICMP
etc.
L2TP tunnel (IPSEC secured)
Suppose a tunnel has to be set up over the SNet “internet”. The SNet of the tunnel can be “corp” or
“dmz”.
L2TP tunnel type Self policies to be defined for Self policies to be defined for
the outgoing tunnel the incoming tunnel
L2TP without IPSEC • outbound self: • inbound self:

- protocol: UDP - protocol: UDP
- port: 1701 (l2tp) - port: 1701 (l2tp)
- SNet: internet - SNet: internet
L2TP with IPSEC (manual SA • outbound self: • inbound self:

ESP) - protocol: ESP - protocol: ESP
L2TP with IPSEC (IKE SA ESP) • outbound self: • inbound self:

- port: 500 (isakmp) - port: 500 (isakmp)
• outbound self: • inbound self:
- protocol: ESP - protocol: ESP
• inbound self: • outbound self:
- protocol: ESP - protocol: ESP
L2TP with IPSEC (IKE SA NAT) • outbound self: • inbound self:

• outbound self: • inbound self:
- port: 4500 (ipsec-nat-t) - port: 4500 (ipsec-nat-t)
- port: 4500 (ipsec-nat-t) - port: 4500 (ipsec-nat-t)
Miscellaneous protocols
If the 1424 SHDSL Router is configured to be a server and/or client for protocols such as DHCP, DNS,
NTP, etc., then in- and/or outbound self policies have to be defined for these protocols:
Application Self policies to be defined
DHCP server inbound self:

• protocol: UDP
• port: 67 (bootp-dhcp-s)
DHCP client outbound self:

• protocol: UDP
• port: 68 (bootp-dhcp-c)
DNS server inbound self:

• protocol: UDP
• port: 53 (domain)
DNS client outbound self:

• protocol: UDP
• port: 53 (domain)
NTP client outbound self:

• protocol: UDP
• port: 123 (ntp)
etc.
9.8.10 Determining which policies have to be defined
As can be learned from 9.8.8 - Configuring the firewall - rules of thumb on page 468 and 9.8.9 - Allowing
access to the protocol stack when the firewall is active on page 469, determining which policies you need
is not always easy. For some application/processes it may be trivial which in- and/or outbound policies
have to be defined (e.g. web access to the Internet). For others it may be somewhat more complicated
because there are several (hidden) processes that need to access, for instance, the protocol stack of the
1424 SHDSL Router (e.g. setting up an IPSEC secured L2TP tunnel).
The procedure below tries to help you how you can determine for which application/processes you have
to define inbound/outbound SNet/self policies.
Step Action
1 Activate the firewall as described in 9.8.2 - Activating the firewall on page 457.
2 Add the interfaces to SNets as described in 9.8.3 - Adding an interface to a secure net-
work (SNet) on page 458.
3 Now, in the 1424 SHDSL Router containment tree, go to the firewall object, select the log
attribute, go in the …
• general structure and set the unavailablePolicies element to enabled (you can leave the
other elements at their default value).
• thresholds structure and set the general element (temporarily1) to 1 (you can leave the
other elements at their default value).
4 Now, in the 1424 SHDSL Router containment tree, go to the Status group, go to the firewall
object and select the log attribute.
Step Action
5 Carefully observe the logs that appear in this table. If you see entries appear with the
string “access policy not found, dropping packet”, then this means that an application/
process tries to pass the firewall but is not allowed because no matching policy is defined
for it.
Once you figured out which application/process it is (look at the protocol and sourcePort/dest-
Port elements), you can determine whether you want to allow it and define a policy for it.
1. After you’re done inspecting the log table in order to determine which policies you have to
define, it is best to reset the general element in the thresholds structure to its default value (20).
This to keep the log table surveyable.
Example - determining which policies have to be defined
Suppose that after following the procedure as described above, you see the following entries appear in
the log status attribute:
The “access policy not found, dropping packet” entries show you that you tried to access the 1424
SHDSL Router with TMA, but that no inbound self policy was defined for it. So define an inbound self
policy allowing TMA to access the protocol stack of the 1424 SHDSL Router and try again. Refer to Main-
tenance applications on page 469.
9.9 IP SLA or traffic quality monitoring
Introduction
End-to-end roundtrip delay, jitter and loss can be measured to configurable destinations. The measure-
ment is based on ICMP echo packets (ping).
The DSCP bits can be configured in order to obtain results for different quality service classes. Using a
sliding window of up to 2000 packets with a configurable time interval, values are returned for the number
of packets sent and received, the number of lost packets, the minimum, average and maximum delay
and the average, maximum negative and maximum positive jitter.
Alarms are available with configurable thresholds for the average delay, the maximum delay, the differ-
ence between the minimum and the maximum delay, the average jitter, the maximum jitter and percent-
age loss. Jitter is defined as the differential delay between two consecutive packets.
Logging of the quality monitoring results per time interval is also available. For this, refer to 9.10 - Log-
ging of performance statistics on page 479.
The configuration attribute qualityMonitor
This attribute can be used to verify the quality of an entire network link between the 1424 SHDSL Router
and the end device.
Which type of network actually is used between both devices is of no importance to this attribute. It is
sufficient to identify the end device at the other side of the link to start the quality monitoring. The follow-
ing figure shows an example:
The qualityMonitor:
• makes use of pings to measure the quality of the network link. A ping is sent out and received again,
after which data is compared. From this comparison, loss, delay and jitter are derived, which are an
indication of the link quality.
• can be enabled or disabled by the user at any point.
• can be found under the router object, refer to 11.9.1 - General router configuration attributes on
page 617.
• can generate performance statistics about the network link, refer to 13.9.1 - General router perform-
ance attributes on page 1055.
• can generate alarms in case of network problems, refer to 14.11 - Router and vrfRouter[ ] alarms on
page 1140.
Time window
The data that is sent out is continuously monitored by using a sliding window which shifts in time over
the data stream. This time window is the interval between the sent out IP packets, multiplied by a number
of samples. Refer to the following figure:
There actually are 2 separate windows that can be defined:

• one to calculate loss, also refered to as the loss window.
• one to calculate delay and jitter, also refered to as the delay window.
On the basis of these time windows, the following values are calculated:
• loss. This is the number of packets that have been lost in the network link.
• real time delay. This is the roundtrip delay from source to destination and back. The following values
are calculated:
- the minimum delay.
- the average delay.
- the maximum delay.
• jitter. This is the delay variation in the network. The following values are calculated:
- the maximum positive deviation.
- the average jitter.
- the maximum negative deviation.
Next, these last three terms are explained further.
Jitter or delay variation
Packets are sent out with a certain time difference between them. Variations in the network will cause a
certain extra delay before the packets are received again. This variation in delay is called jitter. This is
illustrated in the following figure:
The quality monitor calculates three values: the maximum positive deviation, the average jitter and the
maximum negative deviation. These terms are illustrated in the following figure:
Statistics
The performance attribute qualityMonitor displays the performance statistics of the network links that are
being monitored.
This attribute is actually a table which provides information about loss, delay and jitter of the network link.
It also contains the data that is effectively logged to a file that is saved on the file system of the device,
and gives alarm information, as mentioned next. Refer to 13.9.1 - General router performance attributes
on page 1055 for more detailed information.
Alarms
The quality monitor can generate three different alarms:

• qMonLoss. This alarm is generated when more packets have been lost than allowed in the configura-
tion.
• qMonDelay. This alarm is generated when the delay is bigger than allowed in the configuration.
• qMonJitter. This alarm is generated when the jitter is bigger than allowed in the configuration.
Refer to 14.11 - Router and vrfRouter[ ] alarms on page 1140 for more information about the alarms.
Refer to the qualityMonitor attribute in 11.9.1 - General router configuration attributes on page 617 for more
information about configuring the quality monitor.
In the performance attribute qualityMonitor, in the element alarm, the user can check in more detail what
exactly the cause of the alarm is. Refer to 13.9.1 - General router performance attributes on page 1055
for more detailed information.
9.10 Logging of performance statistics
File Logging
Performance statistics can be logged to a file that can be stored on the file system of the device, so that
they can be retrieved and processed by the user.
These statistics, more specifically h2Performance, h24Performance and d7Performance, are present in many
objects in the containment tree:
• the h2Performance performance attribute displays a 2 hours performance summary of the object where
the attribute is present.
• the h24Performance performance attribute displays a 24 hours performance summary of the object
where the attribute is present.
• the d7Performance performance attribute displays a 7 days performance summary of the object where
the attribute is present.
Refer to 13 - Performance attributes on page 1013 for a detailed explication of these attributes, and an
overview of where they can be found in the containment tree.
Configuration
• The configuration of file logging is done via the logStatsToFile attribute, which can be found under the
management object in the containment tree. Refer to 11.12 - Management configuration attributes on
page 799 for a detailed description.
• It may be desirable to align the logging of the performance information with the real time clock. There-
fore, the alignStatsToRtc configuration attribute has been introduced. Enabling this attribute will make
sure that the 2h statistics are aligned to 15 minutes, the 24h statisitics to 2 hours and the 7 days sta-
tistics to a day. This attribute can also be found under the management object in the containment tree.
• The behind-the-scenes mechanism that actually collects the data is using a CLI command, get -v.
This command gathers the values of a table in rows and columns and separates the data by a value
separator, in this case the <tab>.
For more information about CLI, refer to the TMA CLI manual on the TMA CD or the OneAccess web-
site.
Daily, weekly and monthly statistics
Three different types of files can be logged:

• day files. A day file contains samples of the statistics of one day (starting at 0h and ending at 23.59h).
• week files. A week file contains samples of the data of one week; the week starts on Monday and
ends on Sunday.
• month files. A month file will contain samples of the data of exactly one month.
When a new period is started, the logging starts in a new file as well. For example, in case of a week file:
• As soon as a new week is started, the logging restarts in a new file.
• The logged files are immediately available for the user: even if a file is still being filled up, a copy of
the file can be downloaded by the user at any time.
• If the week is not over yet when the file is downloaded, the file will not be complete. On the device,
the logging just continues in that same file until the week is full, and a new file is started when the
new week begins.
Cleaning of the file system
The system will clean the file system automatically:

• day files will be kept on the system for 15 days.
• week files will be kept on the system for 5 weeks.
• month files will be kept on the system for 2 months.
This mechanism will make sure that the file system of the device can never get full.
Real time clock
It is essential for the logging to be succesful, that a real time clock is available on the device. The real
time clock can be made available on a device in two different ways:
• Manually. Configuring the clock manually must be done via the actions Set Date and Set Time. Refer to
12.2 - General status attributes on page 827 for more information.
Depending on the stuffing of the device, some devices are able to remember the real time clock for
a certain time after the device has been switched off (or restarted). Whether or not a device is able
to remember the real time clock, can be seen in the description of the device in the sysDescr status
attribute.
• Via SNTP (Simple Network Time Protocol). This way, the device receives a real time clock over the
network. Refer to the timeServer configuration attribute in 11.12 - Management configuration attributes
on page 799, and the timeServer status attribute in 12.12 - Management status attributes on page 993
When a real time clock is not available, no logging can be done.
Status
• The statistics files that have been logged on the file system can be found in the logStats status
attribute, refer to 12.12 - Management status attributes on page 993 for a detailed description.
• The statistics files contain data that has been retrieved from the performance data of the device,
together with a time stamp.
• The logged files are text files in which the data is seperated by a <tab>. They can easily be imported
in a spreadsheet program for analyzing the data.
Example of file logging
• Configuration
The following figure shows an example of a logStatsToFile table:
- In this example, each half hour, two samples are taken from the 2 hour performance table of the
WAN interface of the device, and logged as a file that starts with the name WanData. It is a week
file, so after one week, the file is stored away, and a new file is created.
- Each half hour, two samples are taken: this means that the period of 30 minutes is divided in two,
so every 15 minutes, one line is added to the log file.
- The logged data is modified: the logged date and time information is converted into seconds, units
are removed, and decimal points are converted into comma’s, via the conversion element.
• Status
The status attribute logStats shows which files are present on the file system of the device. In this exam-
ple, the following file will be present:
The first part of the filename is set in the logStatsToFile table; the second part of the file, in this case indi-
cating year and week number, are added automatically.
• Content of log file

The following figure shows the content of a logged file, after it has been imported in a spreadsheet pro-
gram:
The following table describes the columns in the logged file:
Columns Description
1 This column indicates the status of the logging event itself.

In case of a problem, the message NOT VALID will be displayed, and the line in the table
will be empty.
2 and 3 This is the date and time when the data in each line of the table was added. For example,
looking at the first line:
• The date is the 9th of July 2008.
• The time is 22 hours, 15 minutes and 11 seconds.
4 This is the total time that has elapsed since the logging was started, expressed in sec-
onds.
The original format of this data is “xxd yyh zzm qqs”, as retrieved by the CLI command.
It has been converted into seconds by setting the conversion element.
5 This is the time period between each logging event, expressed in seconds. In this case,
a period of 15 minutes or 900 seconds has elapsed each time.
This has also been converted into seconds by setting the conversion element.
6 These columns are the performance data, as can be found in the 2 hour performance
table of the WAN interface. Refer to 13.4 - WAN interface performance attributes on
page 1032 for more information; the order of the columns are exactly the same as
described there.
Columns 1, 2 and 3 have been added to the log file by the file logging functionality of the 1424 SHDSL
Router itself. Columns 4, 5 an 6 are the reply of the CLI command that collects the data.
User manual Configuration examples
10 Configuration examples
This chapter shows some basic configuration examples for the 1424 SHDSL Router. This allows you to
get acquainted with the way the 1424 SHDSL Router has to be configured. The first example is a step-
by-step example. For the other examples, the CLI code is given.
• 10.1 - LAN extension over a PDH/SDH network on page 486
10.1 LAN extension over a PDH/SDH network
In this example, a remote office is connected to a central office over a PDH or SDH network.
A modem link connects the remote office to the PDH or SDH network. At the local office a 1424 SHDSL
Router is installed. The central router is a third party router. The WAN encapsulation is PPP with active
link monitoring.

SET
{
SELECT lanInterface
{
LIST
{
ip =
{
address = 192.168.47.254
}
mode = routing
}
}
SELECT wanInterface
{
LIST
{
encapsulation = ppp
}
SELECT ppp
{
LIST
{
ip =
{
address = 192.168.100.1
netMask = 255.255.255.252
}
mode = routing
linkMonitoring =
{
operation = enabled
}
}
}
}
SELECT router
{
LIST
{
routingTable =
{
[a] =
{
network = 192.168.48.0
gateway = 192.168.100.2
}
}
}
}
}
1424 SHDSL Router 489
Reference manual
Reference manual
Reference manual
User manual Configuration attributes
11 Configuration attributes
view: 1.3 - Overview of features on page 7
This chapter discusses the configuration attributes of the 1424 SHDSL Router. The following gives an
overview of this chapter:
• 11.1 - Configuration attribute overview on page 492
• 11.2 - General configuration attributes on page 503
• 11.3 - LAN interface configuration attributes on page 509
• 11.4 - WAN interface configuration attributes on page 530
• 11.5 - Encapsulation configuration attributes on page 532
• 11.6 - SHDSL line configuration attributes on page 578
• 11.7 - Profiles configuration attributes on page 591
• 11.8 - Bundle configuration attributes on page 610
• 11.9 - Router configuration attributes on page 616
• 11.10 - Bridge configuration attributes on page 771
• 11.11 - SNMP configuration attributes on page 796
• 11.12 - Management configuration attributes on page 799
11.1 Configuration attribute overview
Refer to 4.3 - The objects in the 1424 SHDSL Router containment tree on page 42 to find out which
objects are present by default, which ones you can add yourself and which ones are added automati-
cally.
> router1424
sysName
sysContact
sysLocation
bootFromFlash
security
alarmMask
alarmLevel
Action: Activate Configuration
Action: Load Default Configuration
Action: Load Preconfiguration
Action: Load Saved Configuration
Action: Cold Boot
>> lanInterface
name
mode
ip
bridging
priorityPolicy
arp
vlan
adapter1
crossover1
flowControl1
ports2
bcastStormProtection2
switchCacheSize2
staticSwitchCase2
pppoEClient
bandwidth
inboundBandwidth
remark
adminStatus
linkStateTracking
delayOptimisation
oam
switchMode2
portGroups2
nrOfTxBds
alarmMask
alarmLevel
>> dslInterface
name
alarmMask
alarmLevel
>>> channel[ ]
encapsulation
maxFifoQLen
alarmMask
alarmLevel
>>>> atm
pvcTable
vp
ima
1. Only present on the single port LAN interface.

2. Only present on the 4 port LAN interface.
>>>>> ima
imaDifferentialDelay
imaVersion
txClockMode
txFrameLength
minActiveLinks
members
>>>> efm
name
ip
mode
arp
bridging
bandwidth
inboundBandwidth
vlan
priorityPolicy
pppoEClient
minActiveLinks
oam
>>> line
channel
region
retrain
management
endAlarmMask
endAlarmLevel
endLinePairAlarmMask
endLinePairAlarmLevel
repeaterAlarmMask
repeaterAlarmLevel
repeaterLinePairAlarmMask
repeaterLinePairAlarmLevel
name
startupMargin
alarmMask
alarmLevel
linkAlarmThresholds
numExpectedRepeaters
eocHandling
minLinePairSpeed
maxLinePairSpeed
modulation
compatibility
remark
autoConfig
>>>> linePair[ ]
alarmMask
alarmLevel
snmpIndexOffset
>> profiles
>>> policy
>>>> traffic
>>>>> ipTrafficPolicy[ ]
snmpIndexOffset
method
vrfRouter
trafficShaping
tos2QueueMapping
queue2QueueMapping
dropLevels
>>>>> bridgingTrafficPolicy[ ]
vlanPriorityMap
dropLevels
snmpIndexOffset
>>>> priority
>>>>> priorityPolicy[ ]
algorithm
countingPolicy
queueConfigurations
lowdelayQuotum
bandwidth
tc
snmpIndexOffset
>> bundle
>>> pppBundle[ ]
snmpIndexOffset
ip
bridging
mode
members
fragmentation
multiclassInterfaces
endpointDiscrClass
priorityPolicy
maxFifoQlen
defaultQueue
inboundBandwidth
alarmMask
alarmLevel
>> ip
>>> router
defaultRoute
routingTable
routingProtocol
alternativeRoutes
ripUpdateInterval
ripHoldDownTime
ripv2SecretTable
sysSecret
pppSecretTable
helperProtocols
sendTtlExceeded
sendPortUnreachable
sendAdminUnreachable
dhcpStatic
dhcpDynamic
dhcpCheckAddress
radius
dns
addrPools
sendHostUnreachable
dnsUpdateClient
qualityMonitor
alarmMask
alarmLevel
>>>> defaultNat
patAddress
portTranslations
servicesAvailable
addresses
gateway
tcpSocketTimeOut
udpSocketTimeOut
tcpSockets
udpSockets
dmzHost
tcpAdjustMss
>>>> nat[ ]
snmpIndexOffset
<All other objects are the same as the defaultNat object.>
>>>> tunnels
name
l2tpTunnels
ipsecL2tpTunnels
greTunnels
ipsecGreTunnels
ipsecTunnels
>>>> manualSA[ ]
espEncryptionAlgorithm
espEncryptionKey
espAuthenticationAlgorithm
espAuthenticationKey
spi
snmpIndexOffset
>>>> ikeSA[ ]
phase1
phase2
snmpIndexOffset
>>>> routingFilter[ ]
filter
snmpIndexOffset
>>>> ospf
routerId
refBandwidth
keyChains
importDefault
importMetrics
importFilter
>>>>> area
areaId
stub
networks
virtualLinks
ranges
snmpIndexOffset
>>>> vrrp[ ]
snmpIndexOffset
vrId
ipAddresses
interfaces
criticals
advertiseInterval
preemptMode
>>>> firewall
inspection
outboundPolicies
inboundPolicies
outboundSelfPolicies
inboundSelfPolicies
attacks
log
alg
tcpAdjustMss
>>>> bgp
asNr
routerId
localPreference
bestPath
networks
aggregates
importMetrics
importFilter
>>>>> ePeer[ ]
localIp
remoteIp
timers
weight
originateDefault
softReconfig
inbouldFilters
outboundFilters
inboundMaps
outboundMaps
alarmMask
alarmLevel
asTranslation
remoteAs
multiHop
snmpIndexOffset
>>>>> iPeer[ ]
localIp
remoteIp
timers
weight
originateDefault
softReconfig
inbouldFilters
outboundFilters
inboundMaps
outboundMaps
alarmMask
alarmLevel
nextHopSelf
snmpIndexOffset
>>>>> routeFilter[ ]
filters
snmpIndexOffset
>>>>> routeMap[ ]
filter
nextHop
weight
localPreference
prependAsPath
origin
med
snmpIndexOffset
>>> vrfRouter[ ]
snmpIndexOffset
defaultRoute
routingTable
sendTtlExceeded
sendPortUnreachable
sendAdminUnreachable
sendHostUnreachable
alternativeRoutes
routingProtocol
ripUpdateInterval
ripHoldDownTime
ripv2SecretTable
dhcpStatic
dhcpDynamic
dhcpCheckAddress
addrPools
dns
helperProtocols
alarmMask
alarmLevel
snmpIndexOffset
filter
>>>> ospf
routerId
refBandwidth
keyChains
importDefault
importMetrics
importFilter
>> bridge
>>> bridgeGroup
name
ip
arp
bridgeCache
bridgeCacheSize
bridgeTimeOut
spanningTree
localAccess
macAddress
vlan
vlanSwitching
accessControl
staticBridgeCash
forwardMulticast
alarmMask
alarmLevel
>>> vpnBridgeGroup[ ]
ip
arp
bridgeCache
bridgeCacheSize
bridgeTimeOut
spanningTree
localAccess
macAddress
vlan
vlanSwitching
accessControl
staticBridgeCash
forwardMulticast
snmpIndexOffset
>>> accessList[ ]
macAddress
advancedFilter
snmpIndexOffset
>> snmp
trapDestinations
mib2Traps
>> management
cms2Address
accessList
snmp
telnet
tftp
ftp
timedStatsAvailability
alignStatsToRtc
logStatsToFile
userInfo
consoleNoTrafficTimeOut
alarmFilter
atwinGraphics
accessPolicy
maxPingReplies
https
timeServer
timeZone
syslog
accessControl
ctrlPortProtocol
>>> loopback
ipAddress
ipNetMask
sNet
vrfRouter
>>> usrLoopback
snmpIndexOffset
<All other objects are the same as the loopback object.>
11.2 General configuration attributes
This section describes the following configuration attributes:

• sysName on page 504
• sysContact on page 504
• sysLocation on page 504
• bootFromFlash on page 504
• security on page 505
• <alarmConfigurationAttributes> on page 506
This section describes the following actions:
• Activate Configuration on page 507
• Load Default Configuration on page 507
• Load Preconfiguration on page 507
• Load Saved Configuration on page 508
• Cold Boot on page 508
sysName Default:<empty>
Range: 0 … 64 characters
Use this attribute to assign a name to the 1424 SHDSL Router. The sysName
attribute is an SNMP MIB2 parameter.
This attribute is also used in the PPP authentication process. The PPP authenticator uses the sysName
attribute in order to verify the peer its response.
For more information on PPP authentication, refer to …
sysContact Default:<empty>
Use this attribute to add contact information. You could, for instance, enter
the name and telephone number of the person to contact in case problem occur.
The sysContact attribute is an SNMP MIB2 parameter.
sysLocation Default:<empty>
Use this attribute to specify the physical location of the 1424 SHDSL Router.
The sysLocation attribute is an SNMP MIB2 parameter.
bootFromFlash Default:auto
Range: enumerated, see below
Part of the flash memory of the 1424 SHDSL Router is organised as a file
system. In this file system, you can store two complete application software versions. You can use the
bootFromFlash attribute to switch between these softwares.
When you store two application software versions in the file system, they are automatically renamed as
CONTROL1 and CONTROL2, respectively. You can check this with the status attribute router1424/fileSys-
tem/fileList.
The bootFromFlash attribute has the following values:
Value When the 1424 SHDSL Router boots …
flash1 the application software CONTROL1 is active.
flash2 the application software CONTROL2 is active.
auto the 1424 SHDSL Router automatically chooses the most recent application soft-
ware. It does this by comparing the application software version numbers.
security Default:<empty>
Range: table, see below
Use this attribute to create a list of passwords with associated access levels
in order to avoid unauthorised access to the 1424 SHDSL Router and the network.
Also use this attribute to set the protocols and passwords for SNMPv3.
The security table contains the following elements:
Element Description
password Use this element to set the password. You can then Default:<empty>
associate this password with a certain access level. Range: 0 … 20 characters
Also see Important remarks on page 506.
accessRights Use this element to set the access level associated Default:1111
with the password. It is a bit string of which each bit Range: bit string, see below
corresponds to an access level. The different access
levels are listed below.
snmpv3 Use this element to set the protocols and passwords for SNMPv3. The snmpv3
structure contains following elements:
• authProtocol. Use this element to set which authentication protocol is used. Pos-
sible values are:
- none. No authentication protocol is set.
- hmac-md5. MD5 authentication will be used.
• authPassword. Use this element to set the key that will be used in the authentica-
tion protocol.
• privProtocol. Use this element to set the encryption protocol. Possible values are:
- none. No encryption will be used.
- des. DES will be used as encryption protocol.
• privPassword. Use this element to set the encryption key.
The following table shows, for each access level, what you can or can not do:
Access Read Change Read secu- Change Execute Access file

level attributes attributes rity security actions2 system
attributes1 attributes
readAccess yes no no no no no
writeAccess yes yes no no yes no
securityAccess no no yes yes no no
fileSystem- no no no no no yes
Access
testAccess yes3 no no no yes4 no

1. The 1424 SHDSL Router has the following security attributes:

router1424/sysName
router1424/security
router1424/router/sysSecret, pppSecretTable and ripv2SecretTable
router1424/router/priorityPolicy and trafficPolicy
router1424/wanInterface/ppp/authentication and authenPeriod
router1424/management/accessList, snmp, telnet and tftp
2. Actions are e.g. Cold Boot, clearArpCache, clearBridgeCache, etc…
3. It is possible to see status and performance attributes that are applicable to tests like ping,
tracert, dnsUpdate.
4. It is possible to execute actions like ping, tracert, dnsUpdate.
The table above indicates that the security attributes are not visible for users with readAccess. There is
however one exception on the standard properties of the security attributes: the sysName attribute.
This is still visible for users with readAccess.
Important remarks
• If you create no passwords, everybody has complete access.

• If you define at least one password, it is impossible to access the 1424 SHDSL Router with one of
the management systems without entering the correct password.
• If you create a list of passwords, create at least one with write and security access. If not, you will be
unable to make configuration and password changes after activation of the new configuration.
• If you access the 1424 SHDSL Router via RADIUS, then this requires that the password is associated
with a user. So in that case, enter the username and password in the password element as follows:
"username:password".
- Note that if the ‘:’ is omitted, then the string is considered to be a password.
- Note that if you do not access the device via RADIUS, but you access it directly with e.g. TMA,
then you have to enter the complete string, i.e. "username:password". Not just the password part
of the string.
• When using SNMPv3, the password must be associated with a user. So in that case, enter the user-
name and password in the password element as follows:"username:password". The part before the
‘:’ is considered as username, the part after the ‘:’ is considered as the password.
SNMPv1 and SNMPv2 do not make use of usernames.
<alarmConfigurationAttributes>
For more information on …

• the alarm configuration attributes alarmMask and alarmLevel and on the alarms in general, refer to 14.2
- Introducing the alarm attributes on page 1123.
• the alarms of the router1424 object, refer to 14.3 - General alarms on page 1126.
Activate Configuration
If you execute this action, then the editable non-active configuration becomes the active configuration.
Refer to 5.7.1 - What are the different configuration types? on page 90 for more information.
When use this action?
If you configure the 1424 SHDSL Router using …

• any other maintenance tool than the graphical user interface based TMA (e.g. ATWIN, CLI, Web
Interface, EasyConnect terminal, TMA CLI), then execute the Activate Configuration action to activate the
configuration after you finished configuring the 1424 SHDSL Router or after you executed the Load
Saved Configuration or Load Default Configuration action.
• TMA, then do not just execute the Activate Configuration action to activate the configuration after you fin-
ished configuring the 1424 SHDSL Router, but use the TMA button Send all attributes to device
instead. You must, however, execute the Activate Configuration action after you executed the Load Saved
Configuration or Load Default Configuration action. The default or saved configuration will only be activated
by the action Activate Configuration.
Load Default Configuration
If you execute this action, then the non-active configuration is overwritten by the default configuration.
Refer to 5.7.1 - What are the different configuration types? on page 90 for more information.
If you install the 1424 SHDSL Router for the first time, all configuration attributes have their default val-
ues. If the 1424 SHDSL Router has already been configured but you want to start from scratch, then use
this action to revert to the default configuration.
Load Preconfiguration
If you execute this action, then the non-active configuration is overwritten by the preconfiguration (if
present, else this action does nothing). Refer to 5.7.1 - What are the different configuration types? on
If you install the 1424 SHDSL Router for the first time and if a preconfiguration is present (i.e. a
precfg.cms file is present on the file system), then some configuration attributes will be set to a precon-
figured value. The rest of the attributes will be set to their default values. If the 1424 SHDSL Router has
already been configured but you want to revert to the preconfiguration, then use this action.
Load Saved Configuration
If you execute this action, then the non-active configuration is overwritten by the active configuration cur-
rently used by the 1424 SHDSL Router. Refer to 5.7.1 - What are the different configuration types? on
If you are in the progress of modifying the non-active configuration but made some mistakes, then use
this action to revert to the active configuration.
Cold Boot
If you execute this action, then the 1424 SHDSL Router reboots. As a result, the 1424 SHDSL Router …
• performs a self-test.
• checks the software.
• reads the saved configuration and restarts program execution.
Use this action, for instance, to activate new application software.

11.3 LAN interface configuration attributes
This section describes the configuration attributes of the following object:
router1424/lanInterface
This object contains the following attributes:

• name on page 510
• mode on page 510
• ip on page 510
• bridging on page 511
• priorityPolicy on page 511
• arp on page 512
• vlan on page 515
• bandwidth on page 522
• inboundBandwidth on page 525
• remark on page 526
• adminStatus on page 526
• linkStateTracking on page 526
• delayOptimisation on page 526
• oam on page 527
The following elements are only present on the 4 port Ethernet LAN interface:
• switchMode on page 527
• ports on page 528
• bcastStormProtection on page 529
• switchCacheSize on page 529
• staticSwitchCache on page 529
The following attributes are only present on the single port Ethernet LAN interface:
• adapter on page 513
• crossover on page 514
• flowControl on page 514
name Default:lan
Use this attribute to assign an administrative name to the LAN interface.
mode Default:bridging
Use this attribute to determine whether the packets are treated by the rout-
ing process, the bridging process or both.
The mode attribute has the following values:
Value Description
bridging All packets are bridged.
The settings of the IP configuration attributes of the LAN are ignored. If you
want to manage the 1424 SHDSL Router via IP, you have to configure an
IP address in the bridgeGroup object. Refer to ip on page 774.
routing The IP packets are routed. All other protocols are discarded.
routingAndBridging IP packets are routed. Non-IP packets are bridged.
The settings of the IP configuration attributes are taken into account.
ip Default:-
Range: structure, see below
Use this attribute to configure the IP related parameters of the LAN inter-
face.
Refer to …
• 5.2 - Configuring IP addresses on page 53 for general information on configuring IP addresses.
• 5.2.3 - Explaining the ip structure on page 56 for a detailed description of the ip structure.
Important remark
If you set the configuration attribute mode to bridging, then the settings of the configuration attribute ip are
ignored. As a result, if you want to manage the 1424 SHDSL Router via IP, you have to configure an IP
address in the bridgeGroup object instead: ip.
bridging Default:-
Use this attribute to configure the bridging related parameters of the LAN
interface.
Refer to …
• 8 - Configuring bridging and VLANs on page 297 for more information on bridging.
• 8.2.6 - Explaining the bridging structure on page 318 for a detailed description of the bridging structure.
priorityPolicy Default:<empty>
Use this attribute to apply a priority policy on the LAN interface.
Do this by entering the index name of the priority policy you want to use. You can create the priority policy
itself by adding a priorityPolicy object and by configuring the attributes in this object.
Example
If you created a priorityPolicy object with index name my_priority_policy

(i.e. priorityPolicy[my_priority_policy]) and you want to apply this priority
policy here, then enter the index name as value for the priorityPolicy attribute.
Refer to 7.11.14 - Creating a priority policy on page 291 for more information on priority policies.
arp Default:-
Use this attribute to configure the Address Resolution Protocol (ARP)
cache.
The arp structure contains the following elements:
Element Description
timeOut Use this element to set the ageing time of the ARP Default:00000d 02h 00m 00s
cache entries. Refer to The ARP cache time-out. Range: 00000d 00h 00m 00s -
24855d 03h 14m 07s
Although a value of less than 5 minutes can be configured, at least 5 min-

utes are necessary for correct operation of the device.
proxyArp Use this element to enable or disable the proxy ARP Default:enabled
mechanism. Refer to What is proxy ARP?. Range: enabled / disabled
Note that when you want to access a proxied device via its IP address that
is configured in the router1424/proxy/nmsGroup/objectTable, then the proxyArp ele-
ment must be set to enabled.
staticArp Use this element to create a fixed link between a MAC address and an IP address.
When set up here, this IP address will always be linked to this MAC address, and
cannot be linked to another one.
The staticArp table contains following elements:
• macAddress. Use this element to fill in the MAC address.
• ipAddress. Use this element to fill in the IP address.
What is the ARP cache?
The LAN interface has been allocated a fixed Ethernet address, also called MAC (Medium Access Con-
trol) address. This MAC address is not user configurable. The IP address of the LAN interface, on the
other hand, is user configurable. This means that the user associates an IP address with the predefined
MAC address. The MAC address - IP address pairs are kept in a table, called the ARP cache. Refer to
arpCache on page 834 for an example of such a table.
How does the ARP cache work?
Before the 1424 SHDSL Router sends an IP packet on the LAN interface, it has to know the MAC
address of the destination device. If the address is not present in the ARP cache table yet, the 1424
SHDSL Router sends an ARP request on the Ethernet to learn the MAC address and associated IP
address of the destination device. This address pair is then written in the ARP cache. Once the address
pair is present, the 1424 SHDSL Router can reference to this pair if it has to send an IP packet to the
same device later on.
The ARP cache time-out

Summarised, all the MAC address - IP address pairs from ARP requests and replies received on the
LAN interface are kept in the ARP cache. However, if devices on the network are reconfigured then this
MAC address - IP address relation may change. Therefore, the ARP cache entries are automatically
removed from the cache after a fixed time-out. This time-out period can be set with the timeOut element.
What is proxy ARP?
Proxy ARP is the technique in which one host, usually a router, answers ARP requests intended for
another machine. By "faking" its identity, the router accepts responsibility for routing packets to the "real"
destination. Proxy ARP can help machines on a subnet reach remote subnets without configuring routing
or a default gateway.
The advantages and disadvantages of proxy ARP are listed below:
advantages The main advantage of using proxy ARP is that it can be added to a single router
on a network without disturbing the routing tables of the other routers on the net-
work.
Proxy ARP should be used on the network where IP hosts are not configured with
default gateway or does not have any routing intelligence.
disadvantages Hosts have no idea of the physical details of their network and assume it to be a
flat network in which they can reach any destination simply by sending an ARP
request. But using ARP for everything has disadvantages, some of which are listed
below:
• It increases the amount of ARP traffic on your segment.
• Hosts need larger ARP tables to handle IP-to-MAC address mappings.
• Security may be undermined. A machine can claim to be another in order to
intercept packets, an act called "spoofing."
• It does not work for networks that do not use ARP for address resolution.
• It does not generalise to all network topologies (for example, more than one
router connecting two physical networks).
adapter Default:autoDetect
Only present on the single port LAN interface.
Use this attribute to set the Ethernet mode of the LAN interface.
The adapter attribute has the following values: autoDetect, 10Mb/halfDuplex, 10Mb/fullDuplex, 100Mb/halfDuplex,
100Mb/fullDuplex.
crossover Default:auto
Range: mdi/mdix/auto
Use this attribute to adjust the LAN interface, if necessary, to the type of cable that is used (crossed or
straight), and the mode of the LAN connector of the remote device (MDI or MDIX; MDI stands for Medium
Dependant Interface).
By default, the LAN interface adjusts automatically. But, for compatibility reasons, it might be necessary
sometimes to manually adjust the interface.
The crossover structure contains the following element:
Element Description
auto This is the default setting, which means that the LAN interface automatically
adjusts to MDI or MDIX mode, however necessary.
mdi The LAN interface functions as an MDI port. Use this when:
• The remote port is an MDI port, in combination with a crossed cable.
• The remote port is an MDIX port, in combination with a straight cable.
mdix The LAN interface functions as an MDIX port. Use this when:
• The remote port is an MDI port, in combination with a straight cable.
• The remote port is an MDIX port, in combination with a crossed cable.
flowControl

Use this attribute to control the flow of data packets on the LAN interface.
The flowControl structure contains the following element:
Element Description
rx If the 1424 SHDSL Router receives pause frames on the LAN interface from the
remote device, it stops sending out packets.
tx If the receive buffer of the LAN interface fills up, the 1424 SHDSL Router sends
out pause frames to the remote device.
rxAndTx The packet flow is monitored in both receive and transmit direction. The 1424
SHDSL Router reacts as described for the rx and tx element.
disabled The packet flow is not monitored.

vlan Default:<empty>
Use this attribute to create and configure VLANs. Refer to 8.3 - Configuring
VLANs on page 325 for an introduction and a step-by-step procedure.
As long as no VLANs are created in the vlan table, the LAN interface accepts both VLAN untagged and
VLAN tagged frames. The VLAN untagged frames are bridged and/or routed (depending on the setting
of the mode attribute). The VLAN tagged frames are bridged (in case the mode attribute is set to bridging
or bridgingAndRouting, else they are discarded).
As soon as a VLAN is created in the vlan table, the LAN interface still accepts VLAN untagged frames
but only accepts those VLAN tagged frames of which the VLAN ID corresponds with the VLAN ID that
has been configured in the vlan table (refer to the configuration element vid on page 517). Other VLAN
tagged frames are discarded.
Note that in case of the 1424 SHDSL Router 4 port Ethernet switch, the vlan table of the 4 port Ethernet
switch has to be used only if you want that VLAN tagged packets inside the 4 port Ethernet switch are
forwarded to the bridging or routing function of the 1424 SHDSL Router. Refer to for 8.4.2 - Setting up
VLANs on the 4 port Ethernet switch on page 339 more information.
The vlan table contains the following elements:
Element Description
name Use this element to assign an administrative name to Default:<empty>

the VLAN. Range: 0 … 24 characters
remark Use this element to write down any text, message, Default:-
remark, etc. of up to 64 characters. Range: 0 … 64 characters
adminStatus Use this element to activate (up) or deactivate (down) Default:up

the VLAN. Range: up / down
mode Use this element to determine whether, for the corre- Default:bridging
sponding VLAN, the packets are treated by the rout- Range: enumerated, see below
ing process or the bridging process.
• bridging. All packets received on the VLAN are bridged.
• routing. All packets received on the VLAN are routed.
Element Description
priorityPolicy Use this element to apply a priority policy on the LAN Default:<empty>
interface. Range: 0 … 24 characters
Do this by entering the index name of the priority policy you want to use. You can
create the priority policy itself by adding a priorityPolicy object and by configuring the
Example
If you created a priorityPolicy object with index

name my_priority_policy (i.e.
priorityPolicy[my_priority_policy]) and you want to apply this priority policy here, then
enter the index name as value for the priorityPolicy attribute.
Refer to 7.11.14 - Creating a priority policy on page 291 for more information on
priority policies.
ip Use this element to configure the IP related parame- Default:-

ters of the VLAN. Range: structure, see below
Refer to …
• 5.2 - Configuring IP addresses on page 53 for general information on configur-
ing IP addresses.
• 5.2.3 - Explaining the ip structure on page 56 for a detailed description of the ip
structure.
bridging Use this element to configure the bridging related Default:-

parameters of the VLAN. Range: structure, see below
Refer to …
• 8 - Configuring bridging and VLANs on page 297 for more information on bridg-
ing.
• 8.2.6 - Explaining the bridging structure on page 318 for a detailed description of
the bridging structure.
vlan Use this element to configure the specific VLAN Default:-

parameters. Range: structure, see below
Refer to vlan/vlan on page 517 for a detailed description of the vlan structure.
inboundandwidth Use this element to configure the inbound bandwidth on the VLAN.
This element has already been explained in the context of the LAN interface itself,
refer to 11.3 - LAN interface configuration attributes on page 509 for more informa-
tion.
vlan/vlan Default:-
Use the vlan structure in the vlan table to configure the VLAN related param-
eters of the corresponding VLAN.
Refer to 8.3 - Configuring VLANs on page 325 for an introduction on VLANs.
The vlan structure contains the following elements:
Element Description
vid Use this element to set the VLAN ID. Default:1

Range: 0 … 4095
Important remark
You can also enter VLAN tag 0 as VLAN ID. This is not really a VLAN, but
a way to reverse the filtering:
- all the untagged data is passed, internally, to VLAN 0.
- all the other, tagged, data for which no VLANs are defined, are handled by
the main LAN interface.
This allows a set-up where a number of VLANs are VLAN switched, while other
VLANs and untagged data are bridged. This is particularly interesting for VLAN
based networks with Ethernet switch discovery protocols like Cisco CDP. Until
now, this was not possible since the VLAN switching mode did not allow flooding
packets over multiple interfaces (bridging), nor did it allow terminating manage-
ment data in the device.
In such set-up, the configuration looks as follows:
- A first bridge group includes all VLANs that need to be switched. This bridge
group is set in VLAN switching mode.
- A second bridge group includes VLAN 0 and possibly also a VLAN for man-
agement of the device.
- The interface VLAN table(s) include(s) entries for all switched VLANs, VLAN
0 and possibly a VLAN for management.
Element Description
tpid Use this element to set the Tag Protocol ID of the Default:33024
VLAN header. Range: 0 ... 65535
This is the value to be used as the first 2 bytes of the VLAN tag when adding a
VLAN header.
Remarks
• This value must be filled in here as a decimal number, although TPID is nor-
mally expressed as a hexadecimal number. Make sure to convert the desired
hexadecimal value to decimal, before filling it in.
• This element is only relevant when the tagSignificance element, described next,
is set to sVlan or local.
The tpid element has the following predefined values:

• dot1Q or 33024. Chosing this value adds 0x8100 as TPID. This identifies the
frame as an IEEE 802.1Q - tagged frame.
• dot1ad or 34984. Chosing this value adds 0x88a8 as TPID. This identifies the
frame as an IEEE 802.1ad - tagged frame.
Beside these two values, any other decimal value between 0 and 65535 can be
filled in by the user.
Element Description
tagSignificance This element is only relevant when you set the mode Default:global
element to bridging. Range: local / global
The tagSignificance element has the following values:
• local. The VLAN tag only has a local significance, i.e. it is only present on the
LAN interface side. This means that when the data is moved …
- from the LAN interface to the bridge group, the VLAN tag is removed.
- from the bridge group to the LAN interface, the VLAN tag is added.
If a VLAN header is already present in the packet, the P bits will be defined by
the cosCosMap. The cosCosMap is described below.
• global. The VLAN tag has a global significance, i.e. it is both present on the LAN
interface and the bridge group side.
This means that when the data is moved from the LAN interface to the bridge
group or vice versa, the VLAN tag is always preserved.
• cVlan. Upon transmission a VLAN tag is added according to the information in
the tunnel field. The P bits in the outer header are defined by the cosCosMap of
this VLAN.
Upon reception, if a matching sVlan is found for the outer header, the inner cVlan
‘s are checked to find the corresponding bridge group. If no matching cVlan is
found, the sVlan header is stripped, and the packet is parsed according to the
rules defined by the sVlan configuration.
The usage of cVlan is only needed if per-vlan rules need to be defined.
• sVlan. Upon transmission a VLAN tag is added to the packet. Upon reception it
behaves the same as the cVlan option. sVlan ’s can use 802.1ad vlan TPID.
Refer to the figure Local or global VLAN tag significance on page 521.
txCos Use this element to set the default user priority Default:0
(802.1P, also called COS) of the transmitted VLAN Range: 0 … 7
frames.
changeTos Use this element to enable or disable the COS to TOS Default:disabled
mapping. Range: enabled / disabled
Note that the TOS to COS mapping is always enabled, irrespective with the
setting of the changeTos attribute.
Element Description
cosTosMap Use this element to determine how the VLAN user pri- Default:-
ority (COS) maps onto the IP TOS byte value. Range: structure, see below
Note that the COS to TOS mapping only occurs in case …
• the mode element is set to routing and the changeTos element is set to enabled.
or
• the mode element is set to bridging, the changeTos element is set to enabled and
the tagSignificance element is set to local.
The cosTosMap structure contains the following elements:

• p0 … p7. Use these elements to define which VLAN Default:0
user priority (0 up to 7) maps onto which IP TOS Range: 0 … 7
byte value (0 up to 255).
cosCosMap Use this element, in case of a cVlan, upon transmis- Default:0

sion, to define the P bits in the outer header of this Range: 0 … 7
VLAN.
tosCosMap Use this element to determine how the IP TOS byte Default:-
value maps onto the VLAN user priority (COS). Range: table, see below
Note that the COS to TOS mapping only occurs in case …
• the mode element is set to routing.
or
• the mode element is set to bridging and the tagSignificance element is set to local.
The tosCosMap table contains the following elements:

• startTos and endTos. Use these elements to set the Default:0
TOS byte value range that has to be mapped. Range: 0 … 255
• cos. Use this element to set the VLAN user priority Default:0
(COS) value on which the specified TOS byte Range: 0 … 7
value range has to be mapped.
tunnel Use this element, in case of a cVlan, upon transmis- Default:-

sion, to set the VLAN tag that is added. Range: structure, see below
The tunnel structure contains the following elements:
• sVid. This is the VLAN ID of the outer VLAN Default:0
header. Range: 0 … 4095
• sTpid. This is the Tag Protocol ID of the outer VLAN Default:33024

header. Range: 0 ... 65535
Note that the priority bits of the outer VLAN header are defined by the cosCosMap,
described above.
arp Use this attribute to configure the Address Resolution Default:-

Protocol (ARP) cache of the VLAN. Range: structure, see below
For a description of the arp structure, refer to arp on page 512.
Local or global VLAN tag significance
The following figure shows how the tagSignificance element influences the VLAN tagging between the LAN
interface and the bridge group:
bandwidth Default:-
Use this attribute to configure the outbound bandwidth on the LAN interface.
Refer to 9.3 - Tuning the bandwidth on the LAN interface on page 376 for more detailed information.
The bandwidth strucuture contains following elements:
Element Description
cir Use this element to set the Committed Information Default:0

Rate for the LAN interface. Range: 0 ... 2147483647
The cir is expressed in bps. Enter a multiple of 64000 bps as cir value (e.g.
2048000). The maximum value is the physical connection towards the network. If
the cir value is set to 0 (default), it means the complete bandwidth may be used (no
flow control).
correction Use this element to adjust the bandwidth. Default:-

Refer to bandwidth/correction on page 522 for a detailed Range: structure, see below
description of the correction structure.
maxFifoQlen Use this element to set the maximum length (number Default:200
of packets) of the First In First Out queue. Range: 1 ... 4000
Note that this element is only applicable when the interface is running in FIFO
queueing mode, and only applicable to non-colored packets.
Refer to algorithm on page 606 for more information on this queue.
bandwidth/correction Default:-
Use this element to adjust the bandwidth on the LAN interface.
The correction structure contains following elements:
Element Description
type Use this element to choose how, if necessary at all, Default:-

the bandwidth will be tuned: Range: enumerated, see below
The type element has the following values:
• noCorrection. No bandwidth correction will be applied.
• predefined. The bandwidth will be tuned according to predefined settings. Refer
to the predefined element below.
• manual. The user himself has full control over the bandwidth tuning. Refer to the
manual element below.
predefined Use this element to have the bandwidth automatically Default:-

tuned, depending on the encapsulation that is used Range: structure, see below
further up in the link.
Refer to bandwidth/correction/predefined on page 523 for a detailed explanation.
Element Description
manual Use this element to manually adjust the bandwidth. By Default:-

using this method, the user himself has full control Range: structure, see below
over the bandwidth tuning.
Refer to bandwidth/correction/manual on page 524 for a detailed explanation.
bandwidth/correction/predefined
Use this element to have the bandwidth automatically tuned, depending on the encapsulation that is
used further up in the link.
The predefined structure contains the following elements:
Element Description
encapsulation Use this element to set which encapsulation is used further up in the link: frameRe-
lay, ppp, atm, hdlc or efm. Either one of these 5 can selected by clicking the right
mouse button and selecting Set To This Choice Type.
• When chosing atm, the following settings must be refined: higherLayer and multi-
Protocol. Refer to the pvcTable/atm attribute in 11.5.1 - ATM configuration
attributes on page 533 for a detailed explantion of both elements.
• When efm is used further up in the link, the following settings must be refined to
control the bandwidth correction: fragmentSize and idleBytes.
When using EFM, Ethernet packets are broken up into variable length frag-
ments, which are then split up into 64/65 bytes frames (64 bytes of Payload
Data, and 1 SYNC byte).
The following elements must be set:
- The actual length of the fragments can be set with the fragmentsize element.
By default, the fragmentSize is 256 bytes.
- To get a smooth dataflow, a number of idle bytes can be introduced inbe-
tween the different frames; this can be set with the idleBytes element.
By default, the idleBytes is 2.
mode Use this element to set whether the WAN interface Default:routing
further up in the link is set to routing or bridging mode. Range: routing/bridging
bandwidth/correction/manual
Use this element to manually tune the bandwidth.

By using this method, the user himself has full control over the bandwidth tuning, by manually setting
some of the parameters in the data size correction formula himself. This formula is explained in 9.3.2 -
Calculation of the data size correction on the LAN interface on page 378.
The manual structure contains the following elements:
Element Description
overhead This is the number of overhead bytes added by the Default:0

WAN encapsulation further up in the link. Range: 0 ... max
frameData This is the actual amount of data bytes in 1 frame on Default:1

the line. Range: 0 ... max
frameHeader This is the actual amount of header bytes in 1 frame Default:0

on the line. Range: 0 ... max
inboundBandwidth
Use this attribute to configure the inbound bandwidth on the LAN interface.
The inboundBandwidth structure contains the same elements as the bandwidth on page 522 structure described
above, except that inboundBandwidth has one extra element, which is priorityPolicy; this has also already
been described above.
Also refer to 9.3 - Tuning the bandwidth on the LAN interface on page 376 for more detailed information.
pppoEClient Default:-
Use this attribute to establish a PPPoE link over the LAN interface. The
1424 SHDSL Router can only act as a client.
If you use PPPoE on your computer, then the IP MTU size has to be limited to 1492 bytes. This is a gen-
eral rule defined in the PPPoE protocol.
The pppoEClient table contains following elements:
Element Description
name Use this element to set the administrative name of the Default:<empty>
PPPoE link. Range: 0 … 24 characters
adminStatus Use this element to set the administrative state of the Default:up
PPPoE link: up or down. Range: up / down

ters of the PPPoE link. Range: structure, see below
Refer to …
ing IP addresses.
structure.
ppp Use this element to configure the PPP related param- Default:-
eters of the PPPoE link. Range: structure, see below
The ppp element contains the following elements: linkMonitoring, authentication, authen-
Period, sessionName and sessionSecret. Refer to 11.5.4 - PPP configuration attributes
on page 566 for a detailed description of these elements.
remark Default:-
Use this attribute to write down any text, message, remark, etc. of up to 64
characters.
adminStatus Default:up
Range: down/up
Use this attribute to activate (up) or deactivate (down) the LAN interface.
Sometimes, there might be a need to put the LAN interface admininstratively down, for instance when a
network administrator wants to reconfigure a few settings on the 1424 SHDSL Router from a distance.
When set to down, this attribute can bring the LAN interface and its VLAN subinterfaces down, including
shutting of the power on the Ethernet chips, so that connected devices also see this link as down.
linkStateTracking Default:-
Use this attribute to track the link state of the interface.
The linkStatetracking structure contains the following elements:
Element Description
trackedInterface Use this element to fill in the name of an interface of which the link state will be
tracked:
• As long as this interface is up, nothing is done.
• When the tracked interface goes down, the LAN is brought physically down; no
power is put on the output port so that the device which is connected to this LAN
interface does no longer get any power on its own LAN interface.
ports
Note that this element is only present on the 4 port Ethernet LAN interface.
This is a mask which can be configured, to indicate on which of the 4 ports the link-
StateTracking must be applied: port1, port2, port3 and port4 can each be enabled or dis-
abled.
delayOptimisation Default:disabled
Range: enabled/disabled
Use this attribute to minimize delay over the LAN interface when using a pri-
orityPolicy.
Whenever a priority policy is applied on the interface, a delay optimisation mechanism is activated auto-
oam Default:-
Use this attribute to set the LAN interface OAM mode.
Refer to 6.5.2 - OAM or Operation, Administration and Maintenance on page 143 for more information
on OAM; there, OAM has been explained in the context of EFM.
Note that OAM is to be used in point-to-point connections: within the same broadcast domain, only 2
devices may be present with OAM enabled.
The oam structure contains the following element:
Element Description
mode The mode element has the following values:

• disabled: This disables the OAM mechanism in the 1424 SHDSL Router. The
LAN interface will not be monitored.
• active: This activates the OAM Discovery process: the 1424 SHDSL Router
actively monitors the LAN interface.
• passive: This sets the OAM mode to passive, this means that the 1424 SHDSL
Router waits for the remote device to initiate OAM actions.

• the alarms of the lanInterface object, refer to 14.4 - LAN interface alarms on page 1128.
switchMode Default:portSwitching
Only present on the 4 port Ethernet LAN interface.
Use this attribute to select the switching mode of the 4 port Ethernet interface.
The switchMode attribute has the following values:
Value Description
portSwitching The 4 port Ethernet interface behaves as a normal Ethernet switch.
dot1QSwitching The 4 port Ethernet interface behaves as a VLAN switch.
The switchMode attribute is a bootable attribute: it is necessary to reboot the 1424 SHDSL Router or dis-
connect and reconnect the ethernet devices from the 1424 SHDSL Router before the newly selected
option becomes active.
ports Default:-
Use this attribute to set the Ethernet mode for each port of the 4 port Ethernet interface.
The ports table contains 4 entries. Each entry corresponds with a port of the 4 port Ethernet interface. So
you can configure the Ethernet and VLAN tagging mode for each port separately. The ports table contains
the following elements:
Element Description
adapter Use this element to set the Ethernet mode for each Default:autoNegotiate
port of the 4 port Ethernet interface. Range: choice, see below
The first part of the adapter element has the following values:
• autoNegotiate. The port automatically negotiates Default:all enabled
with its link partner which Ethernet mode they are Range: structure, see below
going to use.
Using the second part of the adapter element, you can determine which capabil-
ities the port may advertise in this negotiation process. Do this by setting the
corresponding element in this structure to enabled. The structure contains the
following elements: 10Mb/halfDuplex, 10Mb/fullDuplex, 100Mb/halfDuplex, 100Mb/fullDu-
plex, flowControl. By default, all these elements are set to enabled.
• fixed. The port is set to a fixed Ethernet mode. Default:10Mb/halfDuplex
Using the second part of the adapter element, you Range: enumerated, see below
can select the Ethernet mode. Possible values are:
10Mb/halfDuplex, 10Mb/fullDuplex, 100Mb/halfDuplex, 100Mb/fullDuplex.
crossover Use this element to adjust the LAN port, if necessary, Default:auto
to the type of cable that is used (crossed or straight), Range: enumerated, see below
and the mode of the LAN connector of the remote
device (MDI or MDIX; MDI stands for Medium Dependant Interface).
Refer to crossover on page 514 for more information.
bcastStormProtection Default:-
Use this attribute to protect the 4 port Ethernet interface against broadcast/multicast storms. Note that
this configuration is done for all ports at once (including the local port).
The bcastStormProtection structure contains the following elements:
Element Description
mode Use this element to enable or disable the broadcast/ Default:disabled

multicast storm protection. Range: enumerated, see below
• disabled. The broadcast/multicast storm protection is not active.
• enabled. The broadcast storm protection is active. However, there is no multicast
storm protection!
• inclMulticastStormProt. The broadcast/multicast storm protection is active.
rate Use this element to set the percentage of “64-byte Default:1

blocks” of packet data that is allowed on an input port Range: 1 … 27
during a fixed period. This period is 500 ms for a
speed of 10 Mbps and 50 ms for a speed of 100 Mbps.
For example, in case of the default of 1%:
148800 frames/sec * 50 ms/interval * 1% = 74 frames/interval
switchCacheSize Default:1024
Range: 256/512/1024
Use this attribute to set the size of the MAC address cache: 256, 512 or 1024. This is the maximum number
of entries in the MAC address cache.
staticSwitchCache Default:<empty>
Use this attribute to set the static MAC address cache. This is a fixed mapping between a MAC address
and a port.
The staticSwitchCache table contains the following elements: port and macAddress.
11.4 WAN interface configuration attributes
This section only applies to the following devices:

• 1221 ADSL Router
• 1423 SHDSL Router
• 1431 SHDSL CPE
• 1432 SHDSL CPE
This section describes the configuration attributes of the following objects:
router1424/wanInterface
router1424/wanInterface/channel[ ]
The WAN interface configuration attributes are:

• encapsulation on page 531
• maxFifoQLen on page 531
name Default:wan
Use this attribute to assign an administrative name to the WAN interface.

• the alarms of the wanInterface object, refer to 14.5 - WAN interface alarms on page 1129.
encapsulation Default:atm
Use this attribute to select the encapsulation protocol on the WAN interface.
The encapsulation attribute may have the following values: atm, efm, frameRelay, ppp and/or hdlc.
Note that not all encapsulation protocols are present on all 1424 SHDSL Router versions. Refer to 1 -
Introducing the 1424 SHDSL Router on page 3.
Use this attribute to apply a priority policy on the WAN interface.
Example

maxFifoQLen Default:200
Range: 1 … 4000
Use this attribute to set the maximum length (number of packets) of the First
In First Out queue.
Note that this attribute is only applicable when the interface is running in FIFO queueing mode, and only
applicable to non-colored packets.
11.5 Encapsulation configuration attributes
This section discusses the configuration attributes of the encapsulation protocols that can be used on
• 11.5.1 - ATM configuration attributes on page 533
• 11.5.2 - ATM IMA configuration attributes on page 551
• 11.5.3 - Frame Relay configuration attributes on page 554
• 11.5.4 - PPP configuration attributes on page 566
• 11.5.5 - EFM configuration attributes on page 571
11.5.1 ATM configuration attributes
This section describes the configuration attributes of the following object(s):
router1424/dslInterface/channel[wan_1]/atm
The ATM configuration attributes are:

• pvcTable on page 534
• vp on page 549
• ima on page 550
pvcTable Default:<empty>
Use this attribute to configure the ATM Permanent Virtual Circuits (PVCs) .
Refer to 6.2.2 - Configuring ATM PVCs on page 110 for more information on PVCs.
The pvcTable contains the following elements:
Element Description

the PVC. Range: 0 … 24 characters
remark Use this attribute to write down any text, message, Default:-

the PVC. Range: up / down
mode Use this element to determine whether, for the corre- Default:routing
sponding PVC, the packets are treated by the routing Range: enumerated, see below
• bridging. All packets received on the PVC are bridged.
• routing. All packets received on the PVC are routed.
• routingAndBridging. The SNAP header is checked to determine whether the pack-
ets have to be bridged or routed.
priorityPolicy Use this element to set a priority policy per PVC. Default:<empty>
Do this by entering the index name of the priority pol- Range: 0 … 24 characters
icy you want to use. You can create the priority policy itself by adding a priorityPolicy
object and by configuring the attributes in this object.
Refer to 7.11 - Applying QoS on routed traffic on page 259 for more information on
priority policies.
delayOptimisation Use this attribute to minimize delay over the PVC Default:disabled
when using a priorityPolicy. Range: enabled/disabled
Whenever a priority policy is applied on the PVC, a delay optimisation mechanism
is activated automatically in order to guarantee a minimum delay for high priority
packets.

ters of the PVC. Range: structure, see below
Refer to …
ing IP addresses.
structure.
Element Description

parameters of the PVC. Range: structure, see below
Refer to …
ing.
atm Use this element to configure the specific PVC param- Default:-
eters. Range: structure, see below
Refer to pvcTable/atm on page 536 for a detailed description of the atm structure.
eters of the PVC in case you choose to map PPP onto Range: structure, see below
AAL5 (refer to the elements higherLayerProtocol and mul-
tiProtocolMech on page 536).
Refer to 11.5.4 - PPP configuration attributes on page 566 for a detailed descrip-
tion of the elements in the ppp structure.
frameRelay Use this element to configure the Frame Relay related Default:-
parameters of the PVC. Range: structure, see below
Refer to pvcTable/frameRelay on page 546 for a detailed description of the frameRelay
structure.
inboundBandwidth Use this element to configure the inbound bandwidth Default:-

of the PVC. Range: structure, see below
The inboundBandwidth structure contains the following elements:
• cir.
• correction.
• maxFifoQLen.
• priorityPolicy.
For a detailed description of these elements, refer to inboundBandwidth on page 525;
they have already been explained there in the context of the LAN interface.
pvcTable/atm Default:-
Use the atm structure in the pvcTable to configure the ATM related parame-
ters of the corresponding PVC.
Refer to 6.2.2 - Configuring ATM PVCs on page 110 for more information on PVCs.
The atm structure contains the following elements:
Element Description
vpi Use this element to set the Virtual Path Identifier Default:0
(VPI). Range: 0 … 255
vci Use this element to set the Virtual Channel Identifier Default:32
(VCI). Range: 32 … 65535
You can configure multiple virtual channels per virtual path. Refer to What is VPI
and VCI? on page 98.
higherLayerProtocol Use this attribute to select the protocol you want to run Default:rfc2684
over ATM. Range: enumerated, see below
The higherLayerProtocol element has the following values:
• rfc2684. Select this value in case you want to run bridged/routed Ethernet/IP
over ATM (RFC 2684).
• ppp. Select this value in case you want to run PPP over ATM (PPPoA, RFC
2364).
• pppOverEthernet. Select this value in case you want to run PPP over Ethernet
(PPPoE, RFC 2516).
-In the PPPoE context, the 1424 SHDSL Router can only act as a cli-
ent.
- If you use PPPoE on your computer, then the IP MTU size has to be limited
to 1492 bytes. This is a general rule defined in the PPPoE protocol.
multiProtocolMech Use this element to define how you want to encapsu- Default:llcEncapsulation
late the higher layer protocol data in ATM. Range: enumerated, see below
The multiProtocolMech element has the following values:
• llcEncapsulation. Logical Link Control (LLC) encapsulation multiplexes multiple
protocols over a single virtual connection. The protocol type of each protocol
data unit (PDU) is identified by a prefixed IEEE 802.2 Logical Link Control (LLC)
header.
In general, LLC encapsulation tends to require fewer VCs in a multi-protocol
environment but has more fragmentation overhead.
• vcMultiplexing. Virtual Circuit (VC) multiplexing uses one virtual connection to
carry the PDUs of exactly one protocol type. When multiple protocols need to
be transported, there is a separate VC for each.
VC multiplexing tends to reduce fragmentation overhead (e.g. an IPV4 data-
gram containing a TCP control packet with neither IP nor TCP options exactly
fits into a single cell) but needs more VCs.
Element Description
serviceCategory Use this element to specify the ATM service category. Default:ubr
The serviceCategory element has the following values: Range: enumerated, see below
cbr, vbr-rt, vbr-nrt, ubr.
For more information on ATM service categories, refer to 6.2.1 - Introducing ATM
on page 98.
peakCellRate Use this element to set the Peak Cell Rate (PCR) of Default:auto
the PVC. Range: auto, 64000…
The peakCellRate is expressed in bps. Enter a multiple of 64000 bps as peakCellRate
value (e.g. 2048000). The maximum value is the physical connection towards the
ATM network.
Note that:
• when selecting the PCR form the drop down list, the values are expressed in
kbps, instead of bps.
In auto mode, the PVC will try to get the maximum bandwidth, i.e. the speed of the
physical connection towards the ATM network. This is the line speed on which the
1424 SHDSL Router is trained.
For more information on PCR and how to configure it, refer to …
• 6.2.6 - Configuring UBR on page 115
• 6.2.9 - Configuring CBR on page 118
sustCellRate Use this element to set the Sustainable Cell Rate Default:<opt>
(SCR) of the PVC. Range: 0 …
The sustCellRate is expressed in bps. Enter a multiple of 64000 bps as sustCellRate
value (e.g. 2048000). The maximum value is the physical connection towards the
ATM network.
For more information on SCR and how to configure it, refer to …
Element Description
maxBurstSize Use this element to set the Maximum Burst Size Default:<opt>
(MBS) of the PVC. This is the maximum number of Range: 0 … 2147483647
cells that are allowed to be sent above the SCR, with
an upper limit which is PCR.
The maxBurstSize is expressed as a number of cells (or cell times). Since each ATM
cell has a certain length of time, this number of cells corresponds to a number of
cell time slots.
So, cell times is a unit expressed as a number of cells, which represent the amount
of time that it takes the ATM cells to pass an interface.
For more information on MBS and how to configure it, and a definition of cell times,
refer to …
inArpTimeOut Use this element to set the time between the trans- Default:00000d 00h 00m 30s
mission of two consecutive Inverse ARP frames. Range: 00000d 00h 00m 01s -
00000d 01h 00m 00s
oamF5Loopback Use this element to configure the transmission of Default:-

OAM F5 LoopBack cells. Refer to OAM Fault and per- Range: structure, see below
formance management on page 131.
Refer to pvcTable/atm/oamF5Loopback on page 539 for a detailed description of the
oamF5Loopback structure.
oamF5CC Use this element to configure the transmission of Default:-

OAM F5 Continuity Check cells. Refer to OAM Conti- Range: structure, see below
nuity Check (CC) on page 131.
Refer to pvcTable/atm/oamF5CC on page 540 for a detailed description of the oamF5CC
structure.
oamF5PM Use this element to configure the transmission of Default:-

OAM F5 Performance Monitoring cells. Refer to OAM Range: structure, see below
Performance Management on page 132.
Refer to pvcTable/atm/oamF5PM on page 543for a detailed description of the oamF5PM
structure.
segmentEndpoint Use this element to configure whether the 1424 Default:yes

SHDSL Router is a segment endpoint or not. Range: yes/no
pvcTable/atm/oamF5Loopback Default:-
Use the oamF5Loopback structure to configure the transmission of OAM F5
loopback cells.
The oamF5Loopback structure contains the following elements:
Element Description
operation Use this element to enable or disable loopback oper- Default:disabled

ation. Range: enabled / disabled
The operation element has the following values:
• disabled. Loopback operation is disabled, i.e. the loopback cells are not sent.
This means that the ifOperStatus of the PVC becomes up when the ATM is syn-
chronised globally. However, this does not guarantee that the PVC is config-
ured (correctly) on the remote side.
• enabled. Loopback operation is enabled, i.e. the 1424 SHDSL Router sends
loopback cells at regular intervals. If consecutive cells are not returned by the
remote side, then the ifOperStatus of the PVC becomes down.
The 1424 SHDSL Router always responds to OAM LB cells received from
the peer ATM device (both segment and end-to-end cells). However, when
OAM LB is activated, the 1424 SHDSL Router only sends end-to-end OAM
LB request cells.
interval Use this element to set the time interval between the Default:00000d 00h 00m 10s
sending of two consecutive loopback cells. Range: 00000d 00h 00m 00s -
24855d 03h 14m 07s
failsPermitted Use this element to set the number of non-returned Default:4

loopback cells after which the 1424 SHDSL Router Range: 1 … 30
declares the PVC down.
Example
Suppose failsPermitted is set to 10. If 10 consecutive loopback cells are not returned
by the remote side, then the 1424 SHDSL Router declares the PVC down.
target Use this element to indicate whether the loopback Default:endToEnd

cells are defined for the current segment (segment) or Range: segment / endToEnd
end-to-end (endToEnd).
The segment cells only work for the segment to which the device itself belongs (i.e.
no specific coding is used for location identifiers).
The target elements of both sides have to be configured correspondingly, i.e. both
segment or both endToEnd.
pvcTable/atm/oamF5CC Default:-
Use the oamF5CC structure to configure the transmission of OAM F5 conti-
nuity check cells.
The oamF5CC structure contains the following elements:
Element Description
direction Use this element to indicate whether this side of the Default:sink
PVC is the originator, the receiver or both of the CC Range: enumerated, see below
cells.
The direction element has the following values:
• source. This side of the PVC is the originator of the CC cells.
• sink. This side of the PVC is the receiver of the CC cells.
• both. This side of the PVC is both the originator and the receiver of the CC cells.
The source transmits CC cells as configured in the tx structure. The sink acts as
configured in the rx structure.
The direction elements of both sides have to be configured correspondingly, i.e. sink/
source, source/sink or both/both. Refer to Common activation/deactivation configura-
tions on page 542 for some examples.
target Use this element to indicate whether the CC cells are Default:endToEnd
defined for the current segment (segment) or end-to- Range: enumerated, see below
end (endToEnd), ot for both (both).
The target elements of both sides have to be configured correspondingly, i.e. either
both segment, or both endToEnd, or both both.
tx Use this structure to configure how the source trans- Default:-

mits CC cells. This structure only applies in case you Range: structure, see below
set the direction element to the value source or both.
The tx structure contains the following elements:
• mode. Use this element to set the transmit mode of Default:onIdle
the source. Range: onIdle / interval
- onIdle. CC cells are sent in the forward direction by the source when no user
cells have been sent for a period as configured in the interval element.
- continuously. CC cells are sent repetitively with a periodicity of 1 cell per interval
independent of the user cells flow.
• interval. Use this element to determine the period of Default:00m 01s 000ms
CC cell transmission. Range: 00m 00s 500ms -
10m 00s 000ms
Element Description
rx Use this structure to configure how the sink acts. This Default:-
structure only applies in case you set the direction ele- Range: structure, see below
ment to the value sink or both.
The rx structure contains the following elements:
• timeOut. Use this element to determine the time-out Default:00m 03s 500ms
period after which the sink declares the AIS (Alarm Range: 00m 00s 500ms -
Indication Signal) state. 10m 00s 000ms
If the sink with CC activated does not receive any
user cell or CC cell within a time interval as configured in the timeOut element,
then it declares the AIS state due to a LOC (Loss of Continuity) defect.
actDeact Use this structure to determine how the CC mecha- Default:-

nism is activated or deactivated. Range: structure, see below
The actDeact structure contains the following elements:
• initProcedure. Use this element to determine how the Default:passive
CC mechanism is activated or deactivated. Range: enumerated, see below
The initProcedure element has the following values:
- passive. The CC mechanism is activated/deactivated only when receiving
activator/deactivator cells from the other side. This side will never (de)acti-
vate the CC mechanism if the other side is manually (de)activated.
- activated. The CC mechanism is manually activated. This excludes the use of
(de)activator cells. Also the other side has to be activated manually.
- deactivated. The CC mechanism is manually deactivated.
- initActivation. This side takes the initiative in activating/deactivating the CC
mechanism. This means that this side sends activator/deactivator cells and
starts a state machine to monitor the (de)activation state.
Refer to Common activation/deactivation configurations on page 542 for some
examples.
• retryInterval. Use this element to set the time-out Default:00m 03s 000ms
after which the activator/deactivator cells have to Range: 00m 00s 500ms -
be resent in case no ACK cell is received. 10m 00s 000ms
• retryCount. Use this element to set the number of Default:3
times the activator/deactivator cells have to be Range: 3 … 255
resent in case no ACK cell is received.
Common activation/deactivation configurations
Some common activation/deactivation configurations are:
Local 1424 SHDSL Remote 1424 SHDSL Comments

Router Router
direction / initProcedure direction / initProcedure
source / initActivation sink / passive The local side transmits the CC cells and is the
“master” in the (de)activation of the CC mecha-
nism. The remote side receives the CC cells and
is the “slave” in the (de)activation of the CC mech-
anism.
both / initActivation both / passive Both local and remote side transmit and receive
CC cells. The local side is the “master” in the
(de)activation of the CC mechanism and the
remote the “slave”.
source / activated sink / activated The local side transmits the CC cells and the
remote side receives the CC cells. The CC mech-
anism is activated manually on both sides.
both / activated both / activated Both local and remote side transmit and receive
CC cells. The CC mechanism is activated manu-
ally on both sides.
deactivated deactivated The CC mechanism is deactivated.

pvcTable/atm/oamF5PM Default:-
Use the oamF5PM structure to configure the transmission of OAM F5 Per-
formance Monitoring cells.
The oamF5PM structure contains the following elements:
Element Description
direction Use this element to indicate whether this side of the Default:sink
PVC is the originator, the receiver or both of the PM Range: enumerated, see below
cells.
The direction element has the following values:
• source. This side of the PVC is the originator of the PM cells.
• sink. This side of the PVC is the receiver of the PM cells.
• both. This side of the PVC is both the originator and the receiver of the PM cells.
The direction elements of both sides have to be configured correspondingly, i.e. sink/
source, source/sink or both/both.
target Use this element to indicate whether the PM cells are Default:endToEnd
defined for the current segment (segment) or end-to- Range: segment/endToEnd
end (endToEnd).
The target elements of both sides have to be configured correspondingly, i.e. both
segment or both endToEnd.
type Use this element to set the type of performance mon- Default:fpmWithBr
itoring. Range: fpmWithBr/fpm
• fpmWithBr. Forward performance monitoring (FPM) together with backward
reporting (BR) are applied.
• fpm. Only forward performance monitoring is applied.
Refer to 6.3.7 - OAM Performance Monitoring (PM) on page 136 for more informa-
tion about FPM and BR.
policy Use this element to set how PM cells are switched. Default:inband
The policy element has the following values: Range: inband/outband
• outband: the PM cells will be switched 'out of band', i.e. the switching of regular
pvc ATM cells is not in sync with the switching of PM cells for this pvc.
• inband: the PM cells will be switched in sync with the switching of PM cells.
blockSizeAB Use this element to set the size of the block of cells, Default:128
after which an activation/deactivation cell is inserted Range: enumerated, see below
in the cell flow, in the direction away from the activa-
tor/deactivator.
Possible values are: 128 cells, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768.
Element Description
blockSizeBA Use this element to set the size of the block of cells, Default:128
after which an activation/deactivation cell is inserted Range: enumerated, see below
in the cell flow, in the direction towards the activator/
deactivator.
Possible values are: 128 cells, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768.
actDeact Use this structure to determine how the PM mecha- Default:-

nism is activated or deactivated. Range: structure, see below
The actDeact structure contains the following elements:
• initProcedure. Use this element to determine how the Default:passive
PM mechanism is activated or deactivated. Range: enumerated, see below
The initProcedure element has the following values:
- passive. The PM mechanism is activated/deactivated only when receiving
activator/deactivator cells from the other side. This side will never (de)acti-
vate the PM mechanism if the other side is manually (de)activated.
- activated. The PM mechanism is manually activated. This excludes the use
of (de)activator cells. Also the other side has to be activated manually.
- deactivated. The PM mechanism is manually deactivated.
- initActivation. This side takes the initiative in activating/deactivating the PM
mechanism. This means that this side sends activator/deactivator cells and
starts a state machine to monitor the (de)activation state.
Refer to Common activation/deactivation configurations for some examples.
• retryInterval. Use this element to set the time-out Default:00m 03s 000ms
after which the activator/deactivator cells have to Range: 00m 00s 500ms -
be resent in case no ACK cell is received. 10m 00s 000ms
• retryCount. Use this element to set the number of Default:3
times the activator/deactivator cells have to be Range: 3 … 255
resent in case no ACK cell is received.
Common activation/deactivation configurations
Some common activation/deactivation configurations are:
Local 1424 SHDSL Remote 1424 SHDSL Comments

Router Router
direction / initProcedure direction / initProcedure
source / initActivation sink / passive The local side transmits the PM cells and is the
“master” in the (de)activation of the PM mecha-
nism. The remote side receives the PM cells and
is the “slave” in the (de)activation of the PM mech-
anism.
both / initActivation both / passive Both local and remote side transmit and receive
PM cells. The local side is the “master” in the
(de)activation of the PM mechanism and the
remote the “slave”.
source / activated sink / activated The local side transmits the PM cells and the
remote side receives the PM cells. The PM mech-
anism is activated manually on both sides.
both / activated both / activated Both local and remote side transmit and receive
PM cells. The PM mechanism is activated manu-
ally on both sides.
deactivated deactivated The PM mechanism is deactivated.

pvcTable/frameRelay Default:-
Use the frameRelay structure in the pvcTable to configure the Frame Relay
related parameters of the corresponding PVC.
Refer to 6.2 - Configuring ATM encapsulation on page 97 for more information on PVCs.
The frameRelay structure contains the following elements:
Element Description
common The common structure contains the following elements: Default:-

• lmi: Refer to pvcTable/frameRelay/common/lmi on Default:-
page 547 for a detailed description of the lmi struc- Range: structure, see below
ture.
• fragmentation: Use this attribute to enable or disable Default:-
Frame Relay fragmentation on (physical) interface Range: structure, see below
level. Refer to What is interface Frame Relay frag-
mentation? on page 148.
The fragmentation structure contains the following element:
- interfaceFormat: Use this element to enable or Default:disabled
disable Frame Relay fragmentation on (physi- Range: enabled/disabled
cal) interface level. When interface Frame
Relay fragmentation is enabled, long frames are fragmented into a
sequence of shorter frames. At the remote side they are reassembled into
the original frame.
• modeLearnedDlci: If the Frame Relay network sup- Default:routing
ports LMI, then the 1424 SHDSL Router can learn Range: enumerated, see below
its active and inactive DLCIs. Use this attribute to
determine whether, for learned DLCIs, the packets are treated by the routing
The modeLearnedDlci element has the following values:
- routing: All packets received on the DLCI are routed.
- bridging: All packets received on the DLCI are bridged.
- routingAndBridging: The SNAP header is checked to determine whether the
packets have to be bridged or routed.
dlciTable The dlciTable table contains the following elements: Default:<empty>

name, adminStatus, mode, ip, bridging, frameRelay. For more Range: table, see below
information about these elements, refer to dlciTable on
page 556.
pvcTable/frameRelay/common/lmi Default:-
Use this attribute to select the Local Management Interface (LMI) protocol
and to fine-tune the LMI operation.
Refer to 6.6.5 - Configuring LMI on page 156 for more information on LMI.
The lmi structure contains the following elements:
Element Description
mode Use this element to set the Frame Relay mode. Default:auto
The mode element has the following values: Range: enumerated, see below
• noLmi. No LMI is used.

• user. In the LMI context, the 1424 SHDSL Router is defined as Frame Relay
user. This means it only sends Status Enquiries and receives Status
Responses.
• network. In the LMI context, the 1424 SHDSL Router is defined as Frame Relay
network. This means it only receives Status Enquiries and sends Status
Responses.
• auto. In the LMI context, the 1424 SHDSL Router is both Frame Relay user and
Frame Relay network. This means it can both send and receive Status Enquir-
ies and Status Responses.
At initialisation, the 1424 SHDSL Router sends the first Full Status Enquiry. As
soon as it gets a Full Status Response, it declares that LMI is up.
If you use the 1424 SHDSL Router in combination with equipment from
another vendor and you set the LMI mode to auto, then the LMI mode on the
other equipment may only be set to user or network to insure valid operation.
• nni. In the LMI context, the 1424 SHDSL Router is both Frame Relay user and
In a Network-to-Network Interface (NNI) it is important for the connected Frame
Relay devices that they know which DLCIs are configured on each side. There-
fore, in comparison with the auto setting, one extra step is required before LMI
is declared to be up.
So at initialisation, the 1424 SHDSL Router sends the first Full Status Enquiry
and receives a Full Status Response. Then it waits until it receives a Full Status
Enquiry from the remote before it declares that LMI is up.
Refer to Interaction between the LMI modes on page 563 for an overview of how
the different LMI modes work together.
Element Description
type Use this element to set the LMI variant. There are sev- Default:q933-Annex-A
eral standards for the LMI protocol with small varia- Range: enumerated, see below
tions between them. Therefore you should configure
the 1424 SHDSL Router according to the standard that is used by your service pro-
vider.
• lmiRev1. Set this value only for compatibility with older equipment.
• ansiT1-617-d. Set this value for ANSI LMI compliance.
• q933-Annex-A. Set this value for ITU-T LMI compliance.
• frf1-2. Set this value for FRF.1-2 compliance.
pollingInterval Use this element to set the time between consecutive Default:00000d 00h 00m 10s
Status Enquiry messages. Range: 00000d 00h 00m 05s -
00000d 00h 00m 30s
errorTreshold Use this element to set the maximum number of unan- Default:3
swered Status Enquiry messages that the 1424 Range: 1 … 10
SHDSL Router will accept before declaring the DLCI
down. Also see the monitoredEvents element below.
monitoredEvents Use this element to set the number of status polling Default:3
intervals over which the error threshold is counted. Range: 1 … 10
In other words, if the station receives an errorThreshold number of unanswered Sta-
tus Enquiry messages within a monitoredEvents number of pollingInterval intervals, then
the interface is declared down.
Example
If the station receives 3 unanswered Status Enquiry messages within 4 x 10s =

40s, then the interface is declared down.
expectedPollInterval Use this element to set the maximum time between Default:00000d 00h 00m 15s
two consecutive incoming Status Enquiry messages. Range: 00000d 00h 00m 00s -
Select the value 0 in order to disable verification. 00000d 00h 00m 30s
This element is only relevant when using Frame Relay over a point-to-point link (no
Frame Relay network). In Frame Relay language, a router is normally considered
as a Frame Relay user or DTE. However, if two routers are connected to each
other in Frame Relay but without a real Frame Relay network in between, then the
routers also have to take the role of a Frame Relay network or DCE (refer to the
mode element above). In that case the Status Enquiry messages are sent in both
directions.
fullEnquieryInterval Use this element to set the number of Status Enquiry Default:6
intervals that have to pass before sending a Full Sta- Range: 1 … 255
tus Enquiry message.
vp Default:<empty>
Use this attribute to configure the transmission of OAM F4 loopback cells.
The vp table contains the following elements:
Element Description
vpi Use this element to enter the Virtual Path Identifier Default:0
(VPI) of the Virtual Path for which you want to send Range: 0 … 255
the OAM F4 loopback cells.
oamF4Loopback Use this element to configure the transmission of Default:-

OAM F4 LoopBack cells. Refer to OAM Fault and per- Range: structure, see below
formance management on page 131.
The elements contained in this structure are the same as those in the
oamF5Loopback structure. For a detailed description of these elements refer to pvcTa-
ble/atm/oamF5Loopback on page 539.
oamF4CC Use this element to configure the transmission of Default:-

OAM F4 Continuity Check cells. Refer to OAM Conti- Range: structure, see below
nuity Check (CC) on page 131.
The elements contained in this structure are the same as those in the oamF5CC
structure. For a detailed description of these elements refer to pvcTable/atm/oamF5CC
on page 540.
oamF4PM Use this element to configure the transmission of OAM F4 Performance Monitoring
cells. Refer to OAM Performance Management on page 132.
Refer to pvcTable/atm/oamF5PM on page 543 for a detailed description of the oamF4PM
structure.
segmentEndpoint Use this element to configure whether the 1424 Default:yes

SHDSL Router is a segment endpoint or not. Range: yes/no
All entries in the vp configuration table are considered, even if for a certain VPI number no corresponding
PVC has been configured. In the vp status and performance tables only the information about VPs that
are configured in the vp configuration table is shown. However, the 1424 SHDSL Router does respond
to loopback requests for VPs that are not configured in the vp configuration table but for which a PVC
has been configured.
ima
Use this attribute to enable or disable Inverse Multiplexing over ATM.

Refer to 6.4 - Configuring ATM IMA on page 138 for more information about IMA.
Also refer to 11.5.2 - ATM IMA configuration attributes on page 551 for more information about the con-
figuration attributes.
11.5.2 ATM IMA configuration attributes
router1424/dslInterface/channel[wan_1]/atm/ima

• imaDifferentialDelay on page 552
• imaVersion on page 552
• txClockMode on page 552
• txFrameLength on page 553
• minActiveLinks on page 553
imaDifferentialDelay Default:100ms
Use this attribute to set the maximum amount of delay that is allowed
between the different DSL line pairs of an IMA group (i.e. the link differential delay tolerance).
The imaDifferentialDelay attribute has the following values: 50ms, 75ms, 100ms, 125ms, 150ms.
imaVersion Default:1.0
Range: 1.0/1.1
Use this attribute to select the IMA version.
There are two IMA versions: 1.0 and 1.1. The IMA version 1.1 is a revision of the IMA version 1.0. The
purpose of this revision is to introduce the IMA PICS proforma and a new version of the IMA MIBs as
well as several minor corrections and clarifications to the content of IMA version 1.0. It is recognized that
interoperability problems were generated by different interpretations of some IMA version 1.0 require-
ments.
For this reason, the ATM Forum encourages the migration to IMA version 1.1. The IMA version 1.1 spec-
ification increments the OAM Label value used in the IMA OAM cells in order to differentiate version 1.1
from version 1.0 IMA units.
txClockMode Default:common
Range: common/independent
This attribute displays the transmit clock mode that is currently being used
by the trasmitter. Possible values are:
Value Description
common This is Common Transmit Clock configuration (CTC). This is a configuration where
the transmit clocks of all the physical links within the IMA group are derived from
the same clock source.
independent This is Independent Transmit Clock configuration (ITC). This is a configuration

where there is a transmit clock of at least one link within the IMA group that is not
derived from a clock source different from some of the other transmit links.
txFrameLength Default:128
Use this attribute to set the IMA frame length, in cells, of the transmitter.
The txFrameLength attribute has the following values: 32, 64, 128, 256.
minActiveLinks Default:1
Range: 1 ... 4
Use this attribute to set the minimum amount of DSL line pairs that have to
be up before the IMA group becomes active.
11.5.3 Frame Relay configuration attributes
router1424/dslInterface/channel[wan_1]/frameRelay
The Frame Relay configuration attributes are:

• ip on page 555
• dlciTable on page 556
• frameRelay on page 557
• lmi on page 561
• modeLearnedDlci on page 564
• fragmentation on page 564
• mru on page 565
ip Default:<empty>
Use this attribute to globally configure the IP parameters of the DLCIs. More
specifically, use this attribute to configure the IP related parameters of all the DLCIs for which …
• in the dlciTable no IP address is defined for that specific DLCI,
• and the mode element is set to routing or routingAndBridgning.
If you want to configure the IP related parameters for one specific DLCI, then configure for that DLCI the
ip structure in the dlciTable.
Refer to …
• 6.6.4 - Configuring IP addresses in Frame Relay on page 153 for more specific information on con-
figuring IP addresses in Frame Relay.
dlciTable Default:<empty>
Use this attribute to configure the Frame Relay Data Link Connection Iden-
tifiers (DLCIs).
Refer to 6.6.2 - Configuring Frame Relay DLCIs on page 150 for more information on DLCIs.
The dlciTable contains the following elements:
Element Description

the DLCI. Range: 0 … 24 characters

the DLCI. Range: up / down
sponding DLCI, the packets are treated by the routing Range: enumerated, see below
• bridging. All packets received on the DLCI are bridged.
• routing. All packets received on the DLCI are routed.

ters of the corresponding DLCI. Range: structure, see below
Refer to …
ing IP addresses.
structure.
• 6.6.4 - Configuring IP addresses in Frame Relay on page 153 for more specific
information on configuring IP addresses in Frame Relay.

parameters of the DLCI. Range: structure, see below
Refer to …
ing.
frameRelay Use this element to configure the specific DLCI Default:-

Refer to frameRelay on page 557, for a detailed description of the frameRelay structure.
frameRelay Default:-
Use the frameRelay structure to configure the Frame Relay related parame-
ters of the corresponding DLCI.
Refer to …
• 6.6.2 - Configuring Frame Relay DLCIs on page 150 for more information on DLCIs.
• 6.6.6 - Configuring CIR and EIR on page 157 for more information on CIR and EIR.
Element Description
dlci Use this element to set the Data Link Connection Default:16
Identifier (DLCI). Range: 16 … 1022
The DLCI number may have any value between 16 and 1022. However, if you set
the type element of the lmi structure to q933-Annex-A, you should only use DLCIs up
to 1007.

Rate for the DLCI. Range: 0 …
The cir is expressed in bps. Enter a multiple of 64000 bps as cir value (e.g. 2048000).
The maximum value is the physical connection towards the Frame Relay network.
If the cir value is set to 0 (default), it means the complete bandwidth may be used
(no flow control).
eir Use this element to set the Excess Information Rate Default:0
for the DLCI. Range: 0 …
The eir is expressed in bps. Enter a multiple of 64000 bps as eir value (e.g. 2048000).
The maximum value is the physical connection towards the Frame Relay network.
If the eir value is set to 0 (default), it means no excess burst is allowed.
The bursts of data that are allowed are the CIR value + EIR value. I.e. If you want
a CIR of 1 Mbps and you want to allow bursts up to 1.5 Mbps, then set the CIR to
1024000 bps and the EIR to 512000 bps.
overhead Use this element to set the amount of overhead you Default:0
want to add to the configured CIR value. The overhead Range: 0 … 50
element is expressed in bytes.
Normally when you specify CIR, you have to make sure that the CIR value you
enter includes the user data (i.e. the payload) and the Frame Relay headers (i.e.
the overhead). However, you could choose to only specify the amount of payload
as CIR value. In that case use the overhead element to specify the amount of over-
head.
tc Use this element to set the measurement interval Default:200

(TC). The TC interval is expressed in milliseconds. Range: 50 … 1000
TC is the time over which rates and burst sizes are measured. In general, the dura-
tion of TC is proportional to the burstiness of traffic.
Element Description
slidingWindow Use this element to enable or disable sliding window. Default:disabled

If the slidingWindow element is set to … Range: enabled / disabled
• disabled (default), then TC is a periodic time interval.

• enabled, then TC is a sliding window. This means that data triggers the TC inter-
val which continues until it completes its commuted duration.
deBitSet Use this element to determine, in case the CIR is Default:enabled

exceeded, whether all subsequent frames get marked Range: enabled / disabled
Discard Eligible (deBitSet = enabled) or not (deBitSet = dis-
abled).
If congestion occurs at a node in the Frame Relay network, packets marked DE
are the first to be dropped.
defaultQueue Use this element to select a default queue. Default:queue1

This allows you to easily set up a traffic policy without Range: enumerated, see below
having to create and apply traffic policy profiles. However, you still have to create
and apply a priority policy profile to empty the queues.
Refer to 7.11.11 - The default queue attribute versus a traffic policy profile on
rxCir Use this element to set the receive Committed Infor- Default:0
mation Rate for the DLCI. Range: 0 …
Whereas the cir element is the Committed Information Rate for the outgoing traffic
on a DLCI, the rxCir element is the Committed Information Rate for the incoming
traffic on a DLCI. So using the latter you can also limit the incoming data stream
on a DLCI.
Also see rxCir, rxEir and rxExcess relationship on page 560.
rxEir Use this element to set the receive Excess Informa- Default:0
tion Rate for the DLCI. Range: 0 …
Whereas the eir element is the Excess Information Rate for the outgoing traffic on
a DLCI, the rxEir element is the Excess Information Rate for the incoming traffic on
a DLCI. So using the latter you can also limit the incoming data stream on a DLCI.
Element Description
rxExcess Use this element to determine which action is taken in Default:discard

case the rxCir is exceeded (i.e. what is done with the Range: enumerated, see below
data that exceeds the rxCir rate).
The rxExcess element has the following values:
Value All data above the rxCir rate but below the rxCir+rxEir
rate is …
discard dropped.
setDeBit passed but marked Discard Eligible.
ignore passed.
fragmentation Use this element to enable or disable Frame Relay Default:-

fragmentation on an end-to-end level. Refer to What Range: structure, see below
is end-to-end Frame Relay fragmentation? on
page 149.
The fragmentation structure contains the following elements:
• endToEndFormat. Use this element to enable or dis- Default:disabled
able Frame Relay fragmentation on an end-to-end Range: enabled / disabled
level.
When end-to-end Frame Relay fragmentation is enabled, long frames are frag-
mented into a sequence of shorter frames. At the remote side they are reas-
sembled into the original frame.
rxCir, rxEir and rxExcess relationship
The following table shows the rxCir, rxEir and rxExcess relationship:
rxCir rxEir rxExcess Behaviour
0 any value any value This is the default situation. In this case the
incoming bandwidth is not checked.
different from 0 any value discard All data above the rxCir rate is discarded
(and counted as ifOutDiscards).
different from 0 any value setDeBit All data between the rxCir and rxCir+rxEir rate
is marked Discard Eligible. All data above
the rxCir+rxEir rate is discarded (and
counted as ifOutDiscards).
different from 0 any value ignore All data between the rxCir and rxCir+rxEir rate
is passed. All data above the rxCir+rxEir rate
is discarded (and counted as ifOutDiscards).
lmi Default:-
Use this attribute to select the Local Management Interface (LMI) protocol
and to fine-tune the LMI operation.
Refer to 6.6.5 - Configuring LMI on page 156 for more information on LMI.
Element Description
mode Use this element to set the Frame Relay mode. Default:auto
• noLmi. No LMI is used.

• user. In the LMI context, the 1424 SHDSL Router is defined as Frame Relay
user. This means it only sends Status Enquiries and receives Status
Responses.
• network. In the LMI context, the 1424 SHDSL Router is defined as Frame Relay
network. This means it only receives Status Enquiries and sends Status
Responses.
• auto. In the LMI context, the 1424 SHDSL Router is both Frame Relay user and
At initialisation, the 1424 SHDSL Router sends the first Full Status Enquiry. As
soon as it gets a Full Status Response, it declares that LMI is up.
If you use the 1424 SHDSL Router in combination with equipment from
another vendor and you set the LMI mode to auto, then the LMI mode on the
other equipment may only be set to user or network to insure valid operation.
• nni. In the LMI context, the 1424 SHDSL Router is both Frame Relay user and
In a Network-to-Network Interface (NNI) it is important for the connected Frame
Relay devices that they know which DLCIs are configured on each side. There-
fore, in comparison with the auto setting, one extra step is required before LMI
is declared to be up.
So at initialisation, the 1424 SHDSL Router sends the first Full Status Enquiry
and receives a Full Status Response. Then it waits until it receives a Full Status
Enquiry from the remote before it declares that LMI is up.
Refer to Interaction between the LMI modes on page 563 for an overview of how
the different LMI modes work together.
Element Description
type Use this element to set the LMI variant. There are sev- Default:q933-Annex-A
eral standards for the LMI protocol with small varia- Range: enumerated, see below
tions between them. Therefore you should configure
the 1424 SHDSL Router according to the standard that is used by your service pro-
vider.
• lmiRev1. Set this value only for compatibility with older equipment.
• ansiT1-617-d. Set this value for ANSI LMI compliance.
• q933-Annex-A. Set this value for ITU-T LMI compliance.
• frf1-2. Set this value for FRF.1-2 compliance.
pollingInterval Use this element to set the time between consecutive Default:00000d 00h 00m 10s
Status Enquiry messages. Range: 00000d 00h 00m 05s -
00000d 00h 00m 30s
errorThreshold Use this element to set the maximum number of unan- Default:3
swered Status Enquiry messages that the 1424 Range: 1 … 10
SHDSL Router will accept before declaring the DLCI
down. Also see the monitoredEvents element.
monitoredEvents Use this element to set the number of status polling Default:4
intervals over which the error threshold is counted. Range: 1 … 10
In other words, if the station receives an errorThreshold number of unanswered Sta-
tus Enquiry messages within a monitoredEvents number of pollingInterval intervals, then
the interface is declared down.
Example
If the station receives 3 unanswered Status Enquiry messages within 4 x 10s =

40s, then the interface is declared down.
expectedPollInterval Use this element to set the maximum time between Default:00000d 00h 00m 15s
two consecutive incoming Status Enquiry messages. Range: 00000d 00h 00m 00s -
Select the value 0 in order to disable verification. 00000d 00h 00m 30s
This element is only relevant when using Frame Relay over a point-to-point link (no
Frame Relay network). In Frame Relay language, a router is normally considered
as a Frame Relay user or DTE. However, if two routers are connected to each
other in Frame Relay but without a real Frame Relay network in between, then the
routers also have to take the role of a Frame Relay network or DCE (refer to the
mode element). In that case the Status Enquiry messages are sent in both direc-
tions.
fullEnquiryInterval Use this element to set the number of Status Enquiry Default:6
intervals that have to pass before sending a Full Sta- Range: 1 … 255
tus Enquiry message.
Interaction between the LMI modes
The following table shows how the different LMI modes work together when two routers are connected
to each other over a Frame Relay network:
LMI mode LMI status DLCI status Router learns DLCIs?
Router Router Router Router Router Router Router A Router B

A B A B A B
noLmi noLmi up up up up no no
user up down up down no no
network up down up down no no
nni up down up down no no
auto up down up down no no
user user down down down down no no
network up up up up learns (user) no
nni up down up down learns (user) no
auto up up up up learns (user) no
network network down down down down no no
nni up down up down no learns (nni)
auto up up up up no learns (auto)
nni nni up up up up learns learns
auto up up up up learns learns
auto auto up up up up learns learns

modeLearnedDlci Default:routing
If the Frame Relay network supports LMI, then the 1424 SHDSL Router can
learn its active and inactive DLCIs. Use this attribute to determine whether, for learned DLCIs, the pack-
ets are treated by the routing process, the bridging process or both.
The modeLearnedDlci attribute has the following values:
Value Description
bridging All packets received on the DLCI are bridged.
routing All packets received on the DLCI are routed.
routingAndBridging The SNAP header is checked to determine whether the packets have to be bridged
or routed.
delayOptimisation Default:none
Range: none / lowSpeedLinks
Use this attribute to reduce the delay on low speed links. Especially if these
links have to transport delay sensitive data (e.g. voice over IP).
fragmentation Default:-
Use this attribute to enable or disable Frame Relay fragmentation on (phys-
ical) interface level. Refer to What is interface Frame Relay fragmentation? on page 148.
The fragmentation structure contains the following elements:
Element Description
interfaceFormat Use this element to enable or disable Frame Relay Default:disabled

fragmentation on (physical) interface level. Range: enabled / disabled
When interface Frame Relay fragmentation is enabled, long frames are frag-
mented into a sequence of shorter frames. At the remote side they are reassem-
bled into the original frame.
mru Default:1560
Range: 500 … 1650
Use this attribute to set the Maximum Receive Unit (MRU) of the interface.
What is MRU?
The Maximum Receive Unit (MRU) is the largest size packet or frame, specified in octets (eight-bit
bytes), that can be received in a packet- or frame-based network (e.g. the Internet).
11.5.4 PPP configuration attributes
router1424/dslInterface/channel[wan_1]/atm/pvcTable/ppp
router1424/lanInterface/pppoEClient/ppp
router1424/wanEfm/efm/pppoEClient/ppp
The PPP configuration attributes are:

• compression on page 567
• linkMonitoring on page 568
• authentication on page 569
• authenPeriod on page 569
• sessionName on page 570
• sessionSecret on page 570
compression Default:disabled
Use this attribute to enable or disable the compression of PPP encapsu-
lated packets.
The compression attribute has the following values:
Value Description
disabled No PPP compression is done.
predictor1 PPP compression is done using the Predictor type 1 compression algorithm (RFC
1978). Using compression you can increase the throughput on PPP links.
linkMonitoring Default:-
Use this attribute to enable or disable link monitoring and to fine-tune it.
Refer to 6.7.5 - Configuring link monitoring on page 169 for more information on link monitoring.
The linkMonitoring structure contains the following elements:
Element Description
operation Use this element to enable or disable link monitoring. Default:disabled

Range: enabled / disabled
interval Use this element to set the time interval between two Default:00000d 00h 00m 10s
consecutive echo requests. Range: 00000d 00h 00m 00s -
24855d 03h 14m 07s
replyTimeOut Use this element to set the time the 1424 SHDSL Default:00000d 00h 00m 02s
Router waits for a reply on the echo request. Range: 00000d 00h 00m 00s -
00000d 00h 04m 15s
If no reply has been received within this time-out, then
the 1424 SHDSL Router considers this as a failed echo request.
failsPermitted Use this element to set the number of failed echo Default:4
requests after which the 1424 SHDSL Router Range: 1 … 30
declares the PPP link down.
Example
Suppose failsPermitted is set to 10. If on 10 consecutive echo requests no reply is

given, then the 1424 SHDSL Router declares the PPP link down and the PPP
handshake is started again.
authentication Default:disabled
Use this attribute to enable or disable authentication on the PPP link.
• 6.7.6 - Configuring PAP on page 170.
• 6.7.8 - Configuring CHAP on page 173.
The authentication attribute has the following values:
Value Description
disabled Authentication is disabled. However, the 1424 SHDSL Router will answer to
authentication requests received from the remote side.
pap This side of the link requests a PAP authentication from the remote router.
chap This side of the link requests a CHAP authentication from the remote router.
chapOrPap This side of the link requests a CHAP or PAP authentication from the remote
router.
If the remote router supports …
• only PAP, then PAP is used.
• only CHAP, then CHAP is used.
• both CHAP and PAP, then CHAP is used.
msChap This side of the link requests an MS CHAP version 1 authentication from the
remote router.
msChapV2 This side of the link requests an MS CHAP version 2 authentication from the
remote router.
authenPeriod Default:00000d 00h 10m 00s

Range: 00000d 00h 00m 00s -
Use this attribute to set the PPP authentication interval. 24855d 03h 14m 07s
Normally on an authenticated PPP link, authentication is not only performed
at link set-up but also at regular intervals during the data transfer. You can set this interval using the
authenPeriod attribute. If you set the authenPeriod attribute to 00000d 00h 00m 00s, then authentication is only
performed at link set-up and not during the data transfer.
• 6.7.6 - Configuring PAP on page 170.
• 6.7.8 - Configuring CHAP on page 173.
sessionName Default:<empty>
Use this attribute to set the PPP authentication name of the 1424 SHDSL
Router.
sessionSecret Default:<empty>
Use this element to set the PPP authentication secret of the 1424 SHDSL
Router.
11.5.5 EFM configuration attributes
router1424/wanEfm/efm

• ip on page 572
• arp on page 573
• minActiveLinks on page 576
• oam on page 577
name Default:efm
Range: 1 ... 24 characters
Use this attribute to assign an administrative name to the EFM link.
ip Default:-
Use this attribute to configure the IP related parameters of the EFM link.
Refer to …
Important remark
address using the ip attribute in the bridgeGroup object instead: 11.10.1 - Bridge group configuration
attributes on page 772.
Value Description
bridging All packets are bridged.
The settings of the IP configuration attributes of the EFM interface are

ignored. If you want to manage the 1424 SHDSL Router via IP, you have to
configure an IP address using the ip attribute in the bridgeGroup object
instead: 11.10.1 - Bridge group configuration attributes on page 772.
routing The IP packets are routed. All other protocols are discarded.
routingAndBridging IP packets are routed. Non-IP packets are bridged.
The settings of the IP configuration attributes are taken into account.

arp Default:-
Use this attribute to configure the Address Resolution Protocol (ARP)
cache.
The arp structure contains the following elements:
Element Description
timeOut Use this element to set the ageing time of the ARP Default:00000d 02h 00m 00s
cache entries. Refer to The ARP cache time-out. Range: 00000d 00h 00m 00s -
24855d 03h 14m 07s
Although a value of less than 5 minutes can be configured, at least 5 min-

utes are necessary for correct operation of the device.
proxyArp Use this element to enable or disable the proxy ARP Default:enabled
mechanism. Refer to What is proxy ARP?. Range: enabled / disabled
staticArp Use this element to create a fixed link between a MAC address and an IP address.
When set up here, this IP address will always be linked to this MAC address, and
cannot be linked to another one.
The staticArp table contains following elements:
• macAddress. Use this element to fill in the MAC address.
• ipAddress. Use this element to fill in the IP address.
What is the ARP cache?
The line interface has been allocated a fixed Ethernet address, also called MAC (Medium Access Con-
trol) address. This MAC address is not user configurable. The IP address of the line interface, on the
other hand, is user configurable. This means that the user associates an IP address with the predefined
MAC address. The MAC address - IP address pairs are kept in a table, called the ARP cache. Refer to
the arpCache status attribute in 12.5.5 - EFM status attributes on page 877 for an example of such a table.
How does the ARP cache work?
Before the 1424 SHDSL Router sends an IP packet on the line interface, it has to know the MAC address
of the destination device. If the address is not present in the ARP cache table yet, the 1424 SHDSL
Router sends an ARP request on the line to learn the MAC address and associated IP address of the
destination device. This address pair is then written in the ARP cache. Once the address pair is present,
the 1424 SHDSL Router can reference to this pair if it has to send an IP packet to the same device later
on.
The ARP cache time-out
Summarised, all the MAC address - IP address pairs from ARP requests and replies received on the line
interface are kept in the ARP cache. However, if devices on the network are reconfigured then this MAC
address - IP address relation may change. Therefore, the ARP cache entries are automatically removed
from the cache after a fixed time-out. This time-out period can be set with the timeOut element.
What is proxy ARP?
Proxy ARP is the technique in which one host, usually a router, answers ARP requests intended for
another machine. By "faking" its identity, the router accepts responsibility for routing packets to the "real"
destination. Proxy ARP can help machines on a subnet reach remote subnets without configuring routing
or a default gateway.
The advantages and disadvantages of proxy ARP are listed below:
advantages The main advantage of using proxy ARP is that it can be added to a single router
on a network without disturbing the routing tables of the other routers on the net-
work.
Proxy ARP should be used on the network where IP hosts are not configured with
default gateway or does not have any routing intelligence.
disadvantages Hosts have no idea of the physical details of their network and assume it to be a
flat network in which they can reach any destination simply by sending an ARP
request. But using ARP for everything has disadvantages, some of which are listed
below:
• It increases the amount of ARP traffic on your segment.
• Hosts need larger ARP tables to handle IP-to-MAC address mappings.
• Security may be undermined. A machine can claim to be another in order to
intercept packets, an act called "spoofing."
• It does not work for networks that do not use ARP for address resolution.
• It does not generalise to all network topologies (for example, more than one
router connecting two physical networks).
bridging Default:-
Use this attribute to configure the bridging related parameters of the EFM
link.
Refer to …
bandwidth Default:-
Use this attribute to configure the outbound bandwidth of the EFM link.
This attribute has already been explained in the context of the LAN interface; refer to bandwidth on page 522
for a detailed description.
inboundBandwidth Default:-
Use this attribute to configure the inbound bandwidth of the EFM link.
• cir.
• correction.
• maxFifoQLen.
• priorityPolicy.
For a detailed description of these elements, refer to inboundBandwidth on page 525; they have already been
explained there in the context of the LAN interface.
Use this attribute to create and configure VLANs. Refer to 8.3 - Configuring
VLANs on page 325 for an introduction and a step-by-step procedure.
Refer to the vlan configuration attribute of the LAN interface for a detailed description.
priorityPolicy Default:-
Use this attribute to apply a priority policy on the EFM link.
Refer to 7.11 - Applying QoS on routed traffic on page 259 for more information on priority policies.
Example

pppoEClient Default:<empty>
Use this attribute to establish a PPPoE link over the EFM link. The 1424
SHDSL Router can only act as a client.
If you use PPPoE on your computer, then the IP MTU size has to be limited to 1492 bytes. This is a gen-
eral rule defined in the PPPoE protocol.
The pppoEClient table contains following elements:
Element Description
name Use this element to set the administrative name of the Default:<empty>
PPPoE link. Range: 0 … 24 characters
PPPoE link: up or down. Range: up / down

ters of the PPPoE link. Range: structure, see below
Refer to …5.2 - Configuring IP addresses on page 53
ing IP addresses.
structure.
eters of the PPPoE link. Range: structure, see below
The ppp element contains the following elements: linkMonitoring, authentication, authen-
Period, sessionName and sessionSecret. Refer to 11.5.4 - PPP configuration attributes
on page 566 for a detailed description of these elements.
minActiveLinks Default:1
Range: 1 ... 4
Use this attribute to set the minimum amount of DSL line pairs that have to
be up before the EFM link becomes active.
oam Default:-
Use this attribute to set the EFM OAM mode.
Refer to 6.5.2 - OAM or Operation, Administration and Maintenance on page 143 for more information
on OAM.
The oam structure contains the following element:
Element Description
mode The mode element has the following values:

• disabled: This disables the OAM mechanism in the 1424 SHDSL Router. The
EFM link will not be monitored.
• active: This activates the OAM Discovery process: the 1424 SHDSL Router
actively monitors the EFM link.
• passive: This sets the OAM mode to passive, this means that the 1424 SHDSL
Router waits for the remote device to initiate OAM actions.
Use this attribute to minimize delay over the EFM link when using a priority-
Policy.
Whenever a priority policy is applied on the EFM link, a delay optimisation mechanism is activated auto-
11.6 SHDSL line configuration attributes
router1424/dslInterface/line
router1424/dslInterface/line/linePair[ ]
The SHDSL line configuration attributes are:

• channel on page 580
• region on page 581
• retrain on page 582
• startupMargin on page 584
• minLinePairSpeed on page 585
• maxLinePairSpeed on page 585
• modulation on page 586
• compatibility on page 586
• remark on page 586
• autoConfig on page 587
• linkAlarmThresholds on page 588
• numExpectedRepeaters on page 589
• eocHandling on page 589
• management on page 589
The line/linePair[ ]object contains the following attributes:
• snmpIndexOffset on page 590
Note that the linePair[ ] object is not present in the containment tree by default. It must be added manually;
refer to 4.4 - Adding an object to the containment tree on page 45 , this section explains how to. Up to 4
line pairs (1, 2, 3 and 4) can be added.
Important remarks
• When using ATM as encapsulation on the SHDSL line, the following line pair speeds are supported:
- Single pair: all speeds are supported.
- Dual pair: all speeds are supported.
- Three pair: up to 5312Mbits/s per line pair is supported.
- Four pair: up to 3840Mbits/s per line pair supported.
This basically means that, in all cases, a maximum total line speed of up to 16 Mbit/s is supported
when using ATM.
Refer to 6.2 - Configuring ATM encapsulation on page 97 for more information about ATM.
• When using EFM as encapsulation on the SHDSL line, linePair1 must be configured on the central
device. As long as this is not the case, the EFM datapath can never be up.
Refer to 6.5 - Configuring EFM encapsulation on page 141 for more information about EFM.
channel Default:remote
Range: central / remote
Use this attribute to determine which unit is the central unit and which the
remote unit. I.e. it determines which unit acts as master and which as slave during the synchronisation
procedure. Therefore set one device to central and its remote counterpart to remote.
On the 1424 SHDSL Router, the clocking follows the channel attribute:
If the channel attribute is set to … then the clocking is set to …
central internal.
remote slave-receive.
region Default:auto
Use this attribute to determine which SHDSL standard is used.
The region attribute has the following values:
Value Description
annexA The North-American SHDSL standard is used.
annexB The European SHDSL standard is used.
auto The 1424 SHDSL Router itself determines which standard it has to use.
Note that the central unit should never be set to auto.

retrain Default:-
Use this attribute to determine when the 1424 SHDSL Router should retrain.
The retrain criteria
The following criteria determine when to retrain:
Criterion Description
no SHDSL frame synchro- When the 1424 SHDSL Router cannot synchronise on the SHDSL fram-
nisation ing, it retrains.
SHDSL frame CRC error SHDSL framing sends 166 blocks per second over the line, independ-
threshold exceeded ently of the speed. Each block has a CRC check. When a certain per-
centage of frames has a CRC error, the 1424 SHDSL Router retrains.
signal to noise ratio too low When the signal to noise ratio becomes too low during a certain period
of time, the 1424 SHDSL Router retrains.
layer 2 protocol not yet up When you connect the 1424 SHDSL Router with a remote SHDSL
device, the 1424 SHDSL Router trains and establishes a layer 1 link with
the remote SHDSL device. Then the 1424 SHDSL Router tries to estab-
lish a layer 2 link (e.g. PPP, FR, ATM). If the layer 2 handshake does not
succeed within 1 minute, then the 1424 SHDSL Router retrains and the
whole process restarts. Also the following message is dumped in the
message table: Retrain due to framer-out-of-sync. However, once
the layer 2 handshake succeeds (layer 2 is up), then a drop of the layer
2 link will not cause a retrain.
Configuring the retrain criteria
The retrain structure contains the following elements:
Element Description
enabled Use this attribute to enable (yes) or disable (no) Default:yes

retraining. So when selecting no, the 1424 SHDSL Range: yes / no
Router will never retrain (even not when the line is dis-
connected).
errorPersistence- Use this element to set the period, in seconds, during Default:10
Time which each retrain criterion is measured. If within this Range: 1 … 30
period the predefined criterion value is equalled or
exceeded, the 1424 SHDSL Router retrains.
errorThreshold Use this element to set the amount of CRC errors, in Default:10
promille, at which the 1424 SHDSL Router should Range: 1 … 1000
retrain. If the amount of CRC errors exceeds this
value, then the 1424 SHDSL Router retrains.
The erroneous SHDSL frames can be monitored using the performance

attribute codeViolations.
noiseMarginThresh- Use this element to set the noise margin ratio, in dB, Default:0
old which has to be maintained. If the measured noise Range: -2… 15
margin ratio drops below this value, then the 1424
SHDSL Router retrains. It will retrain at a lower speed (because of the deteriorated
line conditions).
The noiseMarginThreshold can be set between -2 and 15dB. When the noiseMargin-
Threshold is 0, this matches an error ratio of 10-6 for the given speed according to
the SHDSL standard. This means that a positive value gives a lower error ratio,
and a negative value gives a higher error ratio.
stepupMargin In case the 1424 SHDSL Router retrains because the Default:disabled
measured signal to noise ratio drops below the Range: 3 … 15
snrThreshold value, then it will retrain at a lower speed
(because of the deteriorated line conditions).
If after this retrain the measured signal to noise value increases again with a value
as configured in the stepupMargin element, then the 1424 SHDSL Router retrains
again in order to achieve a higher speed.
startupMargin Default:2dB
Use this attribute to set the target margin in function of which a line speed
has to be selected during the ITU-T G.994.1 auto speed negotiation.
The startupMargin attribute is only relevant in case on both the central and remote 1424 SHDSL Router (or
any other compatible SHDSL device) a speed range is selected. In other words, the startupMargin attribute
has no function in case a fixed speed is selected (i.e. minLinePairSpeed = maxLinePairSpeed); in all other
cases, it will be used to decide which line speed to use.
The higher the startupMargin, the lower the selected line speed but the more stable the line will be. The
startupMargin attribute has the following values: disabled, 0dB, 1dB, 2dB, 3dB, 4dB, 5dB, 6dB, 7dB, 8dB, 9dB, 10dB.
When you set the startupMargin to disabled, the target margin is not considered during the ITU-T G.994.1
auto speed negotiation. I.e. all the speeds in the range as set with the attributes minLinePairSpeed and max-
LinePairSpeed are available.
What is the target margin?
The target margin is the amount of received signal power in excess of that required to achieve the DSL
target bit error rate of 10-7.
minLinePairSpeed Default:192kbps
Use this attribute to set the lowest linepair speed the 1424 SHDSL Router
may select. The minLinePairSpeed attribute has the following values: 192kbps up to 5696kbps in steps of
64kbps.
Refer to 5.4.2 - Selecting an SHDSL line speed (range) on page 77 for more information.
maxLinePairSpeed Default:5696kbps
Use this attribute to set the highest linepair speed the 1424 SHDSL Router
may select. The maxLinePairSpeed attribute has the following values: 192kbps up to 5696kbps in steps of
64kbps.
Refer to 5.4.2 - Selecting an SHDSL line speed (range) on page 77 for more information.
name Default:o10-PathManagement
Use this attribute to assign an administrative name to the line.
modulation Default:auto
Use this attribute to set the modulation that will be used on the line.
The modulation attribute has the following values:
Value Description
auto When using this value, the modulation will be determined automatically.
This is the default value, and will suffice in practically all cases.
tc-pam16 When using tc-pam16, the line rate is limited from 192kbps to 3840kbps. Use this
when the remote device is a G.SHDSL device.
tc-pam32 When using tc-pam32, the line rate is limited from 768kbps to 5696kbps. Use this
when the remote device is a G.SHDSL.bis device.
compatibility Default:-
Range: structure
This attribute has been added for inter vendor compatibility.
For detailed information about this structure, contact OneAccess Support.
remark Default:-
Use this attribute to write down any text, message, remark, etc. of up to 64
characters.
autoConfig Default:-
Use this attribute to enable the automatic configuration of the line pairs of
the 1424 SHDSL Router, based on the remote device: the 1424 SHDSL Router detects the DSLAM con-
figuration and then sets the appropriate parameters for the G.SHDSL lines.
This automatic configuration will only occur when the 1424 SHDSL Router is configured as CPE device,
and running in ATM.
The autoconfig structure contains the following elements:
Element Description
operation Use this element to enable or disable the automatic Default:enabled

configuration of the G.SHDSL lines: Range: disabled/enabled
• enabled means the automatic wire pair detection is enabled.
• When set to disabled, the automatic wire pair detection is disabled and the 1424
SHDSL Router is configured based on the number of linePair objects that there
are created (when 1 linePair object is present, the 1424 SHDSL Router works in
singlePair mode, when more than 1 linePair object is present, the 1424 SHDSL
Router works in multiPair mode).
This attribute is only applicable to ATM mode whereby bonding is done on SHDSL
physical layer.
initialWireMode Use this element to set the preferred initial startup Default:multiPair
mode, single pair or multi-pair mode. Range: singlePair/multiPair
When a connection is set up, the handshake can be done using a single line pair,
or multiple line pairs.
The 1424 SHDSL Router retrieves the line parameters from the DSLAM and ini-
tializes the G.SHDSL line according to the retrieved parameters.
Remark:
When the SHDSL parameters have been retrieved from the remote device via the autoConfig functionality,
the configuration remains as it has been set, even when a line pair is disconnected or interrupted.
For example:
• When a 1424 SHDSL Router is connected to a 4 wire DSLAM, the autoConfig mechanism will also con-
figure it for 4 wires.
• If the second line pair is interrupted or breaks down, the SHDSL configuration of the 1424 SHDSL
Router remains for 4 wires; there is no automatic fallback mechanism.
Conclusion: the autoConfig mechanism sets the SHDSL parameters according to the configuration of the
remote device, not according to the actual lines that are connected to the device.
linkAlarmThresholds Default:-
Use this attribute to set the alarm threshold values of the most important line
parameters. If this predefined threshold value is exceeded, then a corresponding alarm is generated.
The linkAlarmThresholds structure contains the following elements:
Element Description
lineAttenuationOn Use this element to set the alarm threshold value of Default:0.0
the line attenuation in dB. If the line attenuation … Range: 0.0 … 63.5
• exceeds this value during at least 10 seconds, then the lineAttenuation alarm is
raised.
• drops below this value during at least 10 seconds, then the lineAttenuation alarm
is cleared.
signalNoiseOn Use this element to set the alarm threshold value of Default:0.0
the signal noise in dB. If the signal noise … Range: 0.0 … 58.4
• drops below this value during at least 10 seconds, then the signalNoise alarm is
raised.
• exceeds this value during at least 10 seconds, then the signalNoise alarm is
cleared.
errSecOn Use this element to set the alarm threshold value of Default:00000d 00h 00m 36s
the erroneous seconds in days, hours, minutes and Range: 00000d 00h 00m 00s -
seconds. If the amount of erroneous seconds … 00000d 18h 12m 15s
• exceeds this value within a 15 minutes period1, then the errSecExceeded alarm is
raised.
• drops below this value within a 15 minutes period, then the errSecExceeded alarm
is cleared.
sevErrSecOn Use this element to set the alarm threshold value of Default:00000d 00h 00m 02s
the severely erroneous seconds in days, hours, min- Range: 00000d 00h 00m 00s -
utes and seconds. If the amount of severely errone- 00000d 18h 12m 15s
ous seconds …
• exceeds this value within a 15 minutes period1, then the sevErrSecExceeded
alarm is raised.
• drops below this value within a 15 minutes period, then the sevErrSecExceeded
alarm is cleared.
1. The 15 minutes periods run synchronous with the 15 minutes periods of the router1424/wanInter-
face/line/h2Line performance attribute.
Because alarms are raised or cleared within 15 minutes periods, there is a delay in the alarm
status. For example, suppose that in the first minute of a 15 minutes period the errSecOn value
is exceeded, then the errSecRatioExceeded alarm is raised. The alarm stays on for the remainder
of the 15 minutes period. The alarm is only cleared if also in the next 15 minutes period the
errSecOn value is not exceeded.
numExpectedRepeaters Default:0
Range: 0 … 8
Use this attribute to set the number of Crocus SHDSL Repeaters that the
1424 SHDSL Router can expect to find on the SHDSL line. If the actual number of repeaters does not
match the number you entered in the numExpectedRepeaters attribute, then the invalidNumRepeaters alarm is
raised.
eocHandling Default:none
SHDSL devices can communicate with each other through the Embedded
Operations Channel (EOC). Use the eocHandling attribute to define the handling of the EOC messages.
Refer to 5.5.3 - Controlling the standard EOC message exchange on page 81 for more information.
management Default:o10-PathManagement
Use this attribute to determine whether and which management data is for-
warded over the SHDSL line.
Refer to 5.5.2 - Controlling the proprietary EOC message exchange on page 80 for more information.
snmpIndexOffset
Use this attribute to correct the snmpIndex, in order to let it keep the same value as before, after a manually
added object has been removed from the containment tree. Refer to 5.3.7 - Introducing attributes snmpIn-
dex and snmpIndexOffset on page 74 for more information.

• the alarms of the line object, refer to 14.7 - SHDSL line alarms on page 1132.
• the alarms of the linePair[ ] object, refer to 14.8 - SHDSL line pair alarms on page 1133.
• the alarms of the repeater[ ] object, refer to 14.9 - End and repeater alarms on page 1135.
• the alarms of the end object, refer to 14.9 - End and repeater alarms on page 1135.
11.7 Profiles configuration attributes
This section lists the configuration attributes that are present in the different profiles.
• 11.7.1 - IP traffic policy configuration attributes on page 592
• 11.7.2 - Bridging traffic policy configuration attributes on page 603
• 11.7.3 - Priority policy configuration attributes on page 605
11.7.1 IP traffic policy configuration attributes
router1424/profiles/policy/traffic/ipTrafficPolicy[ ]

• method on page 593
• trafficShaping on page 595
• dropLevels on page 598
• tos2QueueMapping on page 600
• queue2QueueMapping on page 601
• vrfRouter on page 602
This object is not present in the containment tree by default. If you want to use the feature associated
with this object, then add the object first. Refer to 4.4 - Adding an object to the containment tree on
page 45.
method Default:trafficShaping
Use this attribute to choose an IP traffic policy method. This IP traffic policy
is then used to …
• determine, on traffic overload conditions, how and which queues are filled with the “excess” data.
Refer to 7.11 - Applying QoS on routed traffic on page 259.
• do policy based routing. Refer to 7.4 - Configuring policy based routing on page 197.
• filter data on an interface. Refer to 9.2 - Configuring the access restrictions on page 370.
The method attribute has the following values:
Value Description
trafficShaping The data is …

• redirected to the queues based on the settings of the trafficShaping attribute
(queueing).
• redirected to an interface or a gateway based on the settings of the trafficShaping
attribute (policy based routing).
• filtered based on the settings of the trafficShaping attribute (extended access list).
Refer to trafficShaping on page 595 for more information on traffic shaping.
tosDiffServ The data is redirected to the queues based on DiffServ (refer to RFC 2597) regard-
ing class and drop precedence. Refer to What is AF PHB? on page 264.
This means that, depending on their DSCP field in the TOS byte, some packets
are moved to other queues and/or dropped sooner than other packets in case the
queue is full.
The highest 3 bits of the DSCP field are mapped as follows:
Bit values … are mapped to …
000 up to 100 queues 1 up to 5, respectively.
101 and higher the low delay queue.
The next 2 bits of the DSCP field define the drop levels:
Bit values … correspond with …
00 and 01 dropLevel1
10 dropLevel2
11 dropLevel3
Refer to the attribute dropLevels on page 598 for more information on drop levels.
Value Description
tosMapped The data is redirected to …

• the queues based on the settings of the tos2QueueMapping attribute (queueing).
• an interface or a gateway based on the settings of the tos2QueueMapping attribute
(policy based routing).
Refer to the attribute tos2QueueMapping on page 600 for more information on TOS to
queue mapping.
queueMapped The data is redirected to …

• the queues based on the settings of the queue2QueueMapping attribute (queue-
ing).
• an interface or a gateway based on the settings of the queue2QueueMapping
attribute (policy based routing).
Refer to the attribute queue2QueueMapping on page 601 for more information on queue
to queue mapping.
trafficShaping Default:<empty>
The function of this attribute is threefold:
• Traffic and priority policing
In case you have set the method attribute to trafficShaping, then use the trafficShaping table to specify
which data has to be redirected to which queue. If an overload condition occurs, then a packet is redi-
rected to the specified queue when the criteria as specified in the trafficShaping table are met.
• Policy based routing
which data has to be redirected to which interface or gateway. Packets are redirected to the specified
interface or gateway when the criteria as specified in the trafficShaping table are met.
Refer to 7.4 - Configuring policy based routing on page 197.
• Extended access list
which data is forwarded. Packets are forwarded when the criteria as specified in the trafficShaping table
are met. If more than one entry applies to the same packet, then the entry which has the narrowest
filter range (when looking at the filter criteria from left to right) is chosen.
Refer to 9.2 - Configuring the access restrictions on page 370.
Important remarks
• By default, the entries in the trafficShaping table are “allow” rules. I.e. only the traffic defined in the table
is permitted, all other traffic is discarded (independent whether the traffic shaping table is used as an
access list, for priority policing or policy based routing). However, you can inverse an entry making it
a “deny” rule by entering “discard” as value of the interface element.
• If more than one entry applies to the same packet, then the entry which has the narrowest filter range
(when looking at the filter criteria from left to right) is chosen. For example: two rows in the trafficShaping
table apply to the same packet, but row 1 wants to forward packets to queue 3 and row 2 wants to
forward packets to the low delay queue. In that case, first the IP source address is considered. The
row with the smallest range wins. If the ranges are exactly the same, then the IP destination address
is considered. And so on. Should the two rows be completely identical except for the queue, then one
of the rows is chosen at random.
• You do not necessarily have to fill in IP addresses in the trafficShaping table. It is perfectly valid to filter
on IP protocol, IP protocol/port combination or TOS values only.
• If the IP protocol is set to any, and one of the sourcePortStart, destinationPortStart, sourcePortEnd, or destina-
tionPortEnd parameters is non-default, then this entry is internally split into 2 seperate entries : one with
protocol TCP and one with protocol UDP.
• If the IP protocol is set to a different value than any, UDP or TCP, the sourcePortStart, destinationPortStart,
sourcePortEnd, and destinationPortEnd parameterss are ignored.
The trafficShaping table contains the following elements:
Element Description
name Use this element to assign a useful name for each Default:<empty>
entry in the trafficShaping table, for example allow http. Range: 0 … 24 characters
sourceIpStart- Use these elements to set the IP source address as Default:0.0.0.0

Address specified in the IP header. Range: up to 255.255.255.255
sourceIpEnd- Packets that fall within the specified range are forwarded and queued if applicable.
Address
destinationIpStart- Use these elements to set the IP destination address Default:0.0.0.0

Address as specified in the IP header. Range: up to 255.255.255.255
destinationIpEnd- Packets that fall within the specified range are forwarded and queued if applicable.
Address
tosStartValue Use these elements to set the TOS byte value. Default:any(start)/optional(end)
Packets that fall within the specified range are for- Range: 0 … 256
tosEndValue
warded and queued if applicable.
ipProtocol Use this element to set the protocol field from the IP Default:any
header. Range: 0 … 255
Packets that have the specified protocol field are forwarded and queued if applica-
ble.
You can specify the protocol by typing the protocol number. For ease of use, some
common protocols can be selected from a drop-down box: any (0), ICMP (1), IGMP
(2), IPinIP (4), TCP (6), EGP (8), IGP (9), UDP (17), RSVP (46), IGRP (88), OSPFIGP (89),
TCPestablished (255).
sourcePortStart Use these elements to set the source port as specified Default:any(start)/optional(end)
in the UDP / TCP headers. Range: 0 … 65535
sourcePortEnd
Packets that fall within the specified range are forwarded and queued if applicable.
You can specify the port by typing the protocol number. For ease of use, some
common port numbers can be selected from a drop-down box: any or optional (0),
echo (7), discard (9), ftp-data (20), ftp (21), telnet (23), smtp (25), domain (53), www-http
(80), pop3 (110), nntp (119), snmp (161), snmptrap (162), z39.50 (210), syslog (514),
router (520), socks (1080), I2tp (1701), OneAccess (1728).
Note that the predefined “echo” value is a UDP port. It has nothing to do with
ICMP echo.
destinationPortStart Use these elements to set the destination port as Default:any(start)/optional(end)

specified in the UDP / TCP headers. Range: 0 … 65535
destinationPortEnd
You can specify the port by typing the protocol number. For ease of use, some
common port numbers can be selected from a drop-down box: see above.
Element Description
newTosValue Use this element to set the new TOS byte value. Default:unchanged
When you select a new TOS byte value, then a packet Range: 0 … 256
that matches an entry in the trafficShaping table its TOS byte value is changed.
Selecting unchanged, leaves the TOS byte value as it is.
priority Use this element to set the destination queue for a Default:queue1
packet matching an entry in the trafficShaping table. Range: enumerated, see below
In case an overload condition occurs, then a packet that matches an entry in the
trafficShaping table is sent to the specified queue.
The priority element has the following values: queue1, queue2, queue3, queue4, queue5,
lowDelayQueue.
interface Use this element to set the destination interface for a Default:<empty>
packet matching an entry in the trafficShaping table. Range: 0 … 24 characters
This is policy based routing.
Type the name of the interface in the interface element, e.g. lan.
Note that by default, the entries in the trafficShaping table are “allow” rules. I.e. only
the traffic defined in the table is permitted, all other traffic is discarded (independ-
ent whether the traffic shaping table is used as an access list, for priority policing
or policy based routing). However, you can inverse an entry making it a “deny” rule
by entering “discard” as value of the interface element.
gateway Use this element to set the gateway for a packet Default:<opt>
matching an entry in the trafficShaping table. This is pol- Range: up to 255.255.255.255
icy based routing.
Start and end values
Except for the ipProtocol, newTosValue and priority elements, it is possible to specify ranges using the start
and end values. There are two special cases:
• A start value is entered, but no end value ⇒ an exact match is needed for the start value.
• Neither a start nor an end value is entered ⇒ the field is not checked.
dropLevels Default:-
Use this attribute to define for each user configurable queue, how many
packets may be queued before they are dropped.
The dropLevels table contains the following elements:
Element Description
dropLevel1 Use this element to set the maximum length (drop Default:100
level 1), in packets, of each user configurable queue. Range: 1 … 3000
In case you set the attribute method to …
• trafficShaping or tosMapped, then only this drop level is relevant.
• tosDiffServ, then this drop level corresponds with the drop level bits value 00 and
01.
• trafficShaping or tosMapped, then this drop level is not relevant.
• tosDiffServ, then this drop level corresponds with the drop level bits value 10.
• trafficShaping or tosMapped, then this drop level is not relevant.
• tosDiffServ, then this drop level corresponds with the drop level bits value 11.
Examples
Suppose …
• method is set to trafficShaping or tosMapped.
• for queue 1 you set maxLength1 = 1000, for queue 2 to 500, for queue 3 to 3000, for queue 4 to 1000
and for queue 5 to 200.
In this case, packets are dropped when the amount of packets in the queue exceeds the amount as
specified with the maxLength1 element.
Suppose …
• method is set to tosDiffServ.
• for queue 1 you set maxLength1 = 100, maxLength2 = 200 and maxLength3 = 50.
In this case, the following applies:
Queue 1 contains … data An incoming data packet with … is …

packets.
drop level1 1 drop level 2 drop level 3
less than 50 accepted accepted accepted
more than 50, less than 100 accepted accepted dropped
more than 100, less than 200 dropped accepted dropped
more than 200 dropped dropped dropped
1. As defined in the TOS byte.

tos2QueueMapping Default:<empty>
In case you have set the method attribute to tosMapped, then use the tos2QueueMapping table to specify
which data has to be redirected to which queue. If an overload condition occurs, then a packet is redi-
rected to the specified queue when the criteria as specified in the tos2QueueMapping table are met.
In case you have set the method attribute to tosMapped, then use the tos2QueueMapping table to specify
which data has to be redirected to which interface or gateway. Packets are redirected to the specified
interface or gateway when the criteria as specified in the tos2QueueMapping table are met.
The tos2QueueMapping table contains the following elements:
Element Description
startTos Use these elements to set the TOS byte value. Default:0 (start) / 255 (end)
endTos Packets that have a TOS byte value within the speci- Range: 0 … 255
fied range are redirected to the targetQueue.
targetQueue Use this element to set the destination queue. Default:Queue1

The targetQueue element has the following values: Range: enumerated, see below
Queue1, Queue2, Queue3, Queue4, Queue5, lowDelayQueue.
packet matching an entry in the tos2QueueMapping Range: 0 … 24 characters
table. This is policy based routing.
matching an entry in the tos2QueueMapping table. This Range: up to 255.255.255.255
is policy based routing.
queue2QueueMapping Default:<empty>
In case you have set the method attribute to queueMapped, then use the queue2QueueMapping table to
specify which data has to be redirected to which queue. If an overload condition occurs, then a packet
is redirected to the specified queue when the criteria as specified in the queue2QueueMapping table are
met.
In case you have set the method attribute to queueMapped, then use the queue2QueueMapping table to
specify which data has to be redirected to which interface or gateway. Packets are redirected to the
specified interface or gateway when the criteria as specified in the queue2QueueMapping table are met.
The queue2QueueMapping table contains the following elements:
Element Description
queue Use this element to set the current colouring of the Default:any
packets. Range: enumerated, see below
Packets that have a certain colouring are redirected to the targetQueue.
The queue element has the following values: queue1, queue2, queue3, queue4, queue5,
lowDelayQueue, any.
targetQueue Use this element to set the destination queue. Default:Queue1

The targetQueue element has the following values: Range: enumerated, see below
queue1, queue2, queue3, queue4, queue5, lowDelayQueue.
packet matching an entry in the queue2QueueMapping Range: 0 … 24 characters
table. This is policy based routing.
matching an entry in the queue2QueueMapping table. Range: up to 255.255.255.255
This is policy based routing.
snmpIndexOffset Default:0
Range: 0 ... 65535
Use this attribute to correct the snmpIndex, in order to let it keep the same
value as before, after a manually added object has been removed from the containment tree. Refer to
5.3.7 - Introducing attributes snmpIndex and snmpIndexOffset on page 74 for more information.
vrfRouter Default:<empty>
Use this attribute to apply the traffic policy on a VRF router.
Do this by entering the index name of the VRF Router you want the traffic policy to apply on. To create
a VRF Router, a vrfRouter[ ] object must be added and configured; refer to:
• 4.4 - Adding an object to the containment tree on page 45
• 11.9.13 - Virtual Routing and Forwarding (VRF) configuration attirbutes on page 769
11.7.2 Bridging traffic policy configuration attributes
Although a bridging traffic policy can still be configured, the preferred way to manipulate bridged traffic,
is to make use of access lists. These allow for extra configuration possiblities compared to bridge traffic
policies.
Refer to ...
• 8.5 - Bridge traffic classification by filtering on page 344,
• 8.6 - Bridge traffic classification by applying QoS on bridged traffic on page 352and
router1424/profiles/policy/traffic/bridgingTrafficPolicy[ ]

• vlanPriorityMap on page 604
• dropLevels on page 604
page 45.
vlanPriorityMap Default:-
Use this attribute to impose a bridging traffic policy on the bridged VLAN
frames received by the 1424 SHDSL Router.
Each VLAN frame has a certain priority (this is specified in the 802.1P part of the 802.1Q header of the
VLAN frame). In case a traffic overload condition occurs and in case you imposed this traffic policy on a
certain interface, then the VLAN frames are sent to a queue. Using the vlanPriorityMap attribute, you can
specify which VLAN frame is sent to which queue based on the priority of the VLAN frame.
The vlanPriorityMap structure contains the following elements:
Element Description
priority0 Use these elements to define which priority corresponds with which queue. The
… possible queues are: queue1 up to queue5 and lowDelayQueue. To empty these
queues, specify a priority policy.
priority7
Frames that are not tagged are all considered to have priority 0.
$
Refer to 8 - Configuring bridging and VLANs on page 297 for more information on
traffic policy, priority policy and priority queuing.
dropLevels Default:-
Use this attribute to define for each user configurable queue, how many
packets may be queued before they are dropped.
The dropLevels table contains the following element:
Element Description
dropLevel1 Use this element to set the maximum length, in pack- Default:100
ets, of each user configurable queue. Range: 1 … 3000
Range: 0 ... 65535
11.7.3 Priority policy configuration attributes
router1424/profiles/policy/priority/priorityPolicy[ ]

• algorithm on page 606
• countingPolicy on page 608
• queueConfigurations on page 608
• lowdelayQuotum on page 608
• tc on page 609
page 45.
algorithm Default:fifo
Use this attribute to determine how and which queues are emptied.
Whenever a priority policy is applied on an interface, a delay optimisation mechanism is activated auto-
This applies to all types of priority policies, except fifo.
The algorithm attribute has the following values:
Value Description
fifo This is a First In First Out queue. The data that enters the queue first, also leaves
the queue first. This is the fastest but most superficial queuing mechanism.
You can change the maximum length of the FIFO queue on an interface using the
configuration attribute maxFifoQLen.
roundRobin This is a priority queuing mechanism. In this case, all user configurable queues
containing data have an equal weight. In other words, if all the user configurable
queues contain data, they are addressed in turns. The low delay has a higher pri-
ority, it is addressed between every user configurable queue. The system queue
has absolute priority, it is emptied as soon as it contains data.
• Queues 1 up to 5: user configurable queues. These queues are addressed in
turns.
• Queue 6: low delay queue. This queue is addressed between every user con-
figurable queue.
• Queue 7: system queue. This queue has absolute priority over all other queues.
As soon as it contains data, it is emptied.
absolutePriority This is a priority queuing mechanism. In this case, queues with a high priority have
absolute priority over queues with a low priority. In other words, no lower priority
queue is emptied as long as a higher priority queue contains data.
The priority of the queues runs parallel to the queue number. I.e. the user config-
urable queue number 1 has the lowest priority, whereas the system queue
(number 7) has the highest priority.
• Queues 1 up to 5: user configurable queues. Queue 1 has the lowest priority
whereas queue 5 has the highest priority. A lower priority queue is only emptied
in case no higher priority queue contains data.
• Queue 6: low delay queue. This queue is only emptied in case the system
queue contains no data.
Note that there is a risk of starvation. This means that it is possible that the
lower priority queues are never emptied because a higher priority queue
continuously receives data.
Value Description
weightedFair- This is a priority queuing mechanism. In this case, the user configurable queues
Queueing are addressed based on their weight. The low delay has a higher priority, it is
addressed between every user configurable queue. The system queue has abso-
lute priority, it is emptied as soon as it contains data.
• Queues 1 up to 5: user configurable queues. These queues are addressed
based on their weight. The weight can be configured in the queueConfigurations
attribute.
• Queue 6: low delay queue. This queue is addressed between every user con-
figurable queue.
lowDelayWeighted- This is a priority queuing mechanism. It is a combination of absolute priority and

FairQueueing weighted fair queueing. In this case, the user configurable queues are addressed
based on their weight. The low delay queue has absolute priority over all user con-
figurable queues and the system queue has absolute priority over all queues.
• Queues 1 up to 5: user configurable queues. These queues are addressed
based on their weight. The weight can be configured in the queueConfigurations
attribute.
• Queue 6: low delay queue. This queue has absolute priority over all user con-
figurable queues. If the system queue does not contain data but the low delay
queue and the user configurable queues do, then it is the low delay queue that
is emptied.
In a network that carries both voice and data, the lowDelayWeightedFairQueueing

algorithm is the most suited mechanism to get the voice over the network
with a minimum delay. In this case, the voice has to be queued in the low
delay queue.
countingPolicy Default:bytes
Use this attribute to define whether the quotum of the queues is expressed
in bytes or packets.
queueConfigurations Default:<empty>
Use this attribute to …
• set the number of bytes/packets that is dequeued from the user configurable queue when the queue
is addressed.
• set the relative importance of the user configurable queues.
The queueConfigurations table contains the following elements:
Element Description
quotum Use this element to set the number of bytes/packets Default:1500

that is dequeued from the user configurable queue Range: 1 … 25000
when the queue is addressed.
The unit of the quotum (bytes or packets) can be set with the countingPolicy attribute.
weight Use this element to set the relative importance of the Default:1
user configurable queues. Range: 1 … 10
The weight element is only relevant in case the algorithm attribute is set to weighted-
FairQueueing.
Example
Suppose queue 1 has weight 2, queue 2 has weight 1 and both queues contain
data. In that case the queues are emptied in the following order: queue 1 → queue
1 → queue 2 → queue 1 → queue 1 → queue 2 → etc.
Refer to 7.11.2 - Introducing traffic and priority policy on page 262 for more information on queues.
lowdelayQuotum Default:1500
Range: 1 … 25000
Use this attribute to set the number of bytes/packets that is dequeued from
the low delay queue when the queue is addressed. The unit of the quotum (bytes or packets) can be set
with the countingPolicy attribute.
Refer to 7.11.2 - Introducing traffic and priority policy on page 262 for more information on queues.
bandwidth Default:-
Use this attribute to set the bandwidth per queue.
The bandwidth table contains the following elements:
Element Description

Rate (CIR), in bits per second, of the different queues. Range: 0 … 2147483647
Using entry 1 up to 5 in the bandwidth table you can set the CIR for queues 1 up to
5, respectively. Using entry 6 in the bandwidth table you can set the CIR for the low
delay queue.
If the CIR is exceeded, then the data is first queued. The amount of data that is
queued can be set using the maxFifoQLen attribute. If the queue is completely filled
up, then the data is discarded.
eir Use this element to set the Excess Information Rate Default:0
(EIR), in bits per second, of the different queues. Range: 0 … 2147483647
Traffic above the cir value is accepted up to a maximum rate of cir + eir if there is
sufficient bandwidth available, e.g. because there is currently no higher priority
traffic on the outbound interface.
unit Use this element to set how the cir and eir values are Default:bits/sec
expressed: either in bits/sec or percent. Range: enumerated, see below
tc Default:50
Range: 50 ... 1000
Use this attribute to set the time interval with which the CIR/EIR quota on
the queues is updated.
The default value is 50 ms; the user can change this interval to any multiple of 50 ms ranging from 50
ms up to 1 sec.
Range: 0 ... 65535
11.8 Bundle configuration attributes
This section describes the configuration attributes of the different bundles that you can set up on the
1424 SHDSL Router.
• 11.8.1 - PPP bundle configuration attributes on page 611
11.8.1 PPP bundle configuration attributes
router1424/bundle/pppBundle[ ]

• members on page 612
• ip on page 612
• fragmentation on page 613
• multiclassInterfaces on page 613
• maxFifoQlen on page 614
• defaultQueue on page 615
page 45.
members Default:<empty>
Use this attribute to make the WAN interface a part of the PPP bundle. Do
this by adding one entry to the members table and by typing “wan” as value of the interface element.
Note that in case you run PPP over ATM (PPPoA) you can also create PPP bundles. In that case, just
type the name of the ATM PVC as value of the interface element in the members table.
Refer to 6.7.11 - Setting up multilink PPP on page 177 for more information on how to set up a PPP bun-
dle.
Value Description
bridging All packets received on the PPP bundle are bridged. BCP is set up.
routing All packets received on the PPP bundle are routed. IPCP is set up.
routingAndBridging The SNAP header is checked to determine whether the packets have to be bridged
or routed. IPCP and BCP are set up.
ip Default:<empty>
Use this attribute to configure the IP related parameters of the PPP bundle.
Refer to …
bridging Default:-
Use this attribute to configure the bridging related parameters of the PPP
bundle.
Refer to …
fragmentation Default:enabled
Use this attribute to enable or disable PPP fragmentation. Refer to What is
PPP fragmentation? on page 164.
When PPP fragmentation is enabled, long frames are fragmented into a sequence of shorter frames. At
the remote side they are reassembled into the original frame.
multiclassInterfaces Default:<empty>
Use this attribute to set up multiclass PPP links. So you have to add an entry
to the multiclassInterfaces table for every multiclass PPP link that you want to create.
Refer to 6.7.13 - Setting up multiclass PPP on page 183 for more information.
The multiclassInterfaces table contains the following elements:
Element Description

the multiclass PPP link. Range: 0 … 24 characters

the multiclass PPP link. Range: up / down
sponding multiclass PPP link, the packets are treated Range: enumerated, see below
by the routing process, the bridging process or both.
• bridging. All packets received on the multiclass PPP link are bridged.
• routing. All packets received on the multiclass PPP link are routed.

ters of the multiclass PPP link. Range: structure, see below
Refer to …
ing IP addresses.
structure.

parameters of the multiclass PPP link in case the mul- Range: structure, see below
ticlass PPP link is in bridging mode (i.e. in case the
mode element is set to bridging).
Refer to …
ing.
Element Description
multiclass Use this element to configure the multiclass specific Default:-

parameters of the multiclass PPP link. Range: structure, see below
Refer to multiclassInterfaces/multiclass on page 614 for a detailed description of the multi-
class structure.
multiclassInterfaces/multiclass Default:-
Use this structure to configure the multiclass specific parameters of the mul-
ticlass PPP link.
The multiclass structure contains the following elements:
Element Description
multiclass Use this element to set a multiclass identifier for the Default:1
multiclass PPP link. Range: 1 … 7
defaultQueue Use this element to select a default queue. Default:queue1

This allows you to easily set up a traffic policy without Range: enumerated, see below
having to create and apply traffic policy profiles. However, you still have to create
and apply a priority policy profile to empty the queues.
Range: 0 ... 65535
Use this attribute to apply a priority policy on the bundle.
Example

maxFifoQlen Default:200
Range: 1 ... 4000
Use this attribute to set the maximum length (number of packets) of the First
In First Out queue.
Note that this attribute is only applicable when the interface is running in FIFO queueing mode, and only
applicable to non-colored packets.
defaultQueue Default:queue1
Use this element to select a default queue.
This allows you to easily set up a traffic policy without having to create and apply traffic policy profiles.
However, you still have to create and apply a priority policy profile to empty the queues.
Refer to 7.11.11 - The default queue attribute versus a traffic policy profile on page 286 for more infor-
mation.
Use this attribute to minimize delay over the PPP bundle when using a prior-
ityPolicy.
Whenever a priority policy is applied on the PPP link, a delay optimisation mechanism is activated auto-
inboundBandwidth Default:-
Use this attribute to configure the inbound bandwidth of the PPP bundle.
• cir.
• correction.
• maxFifoQLen.
• priorityPolicy.
For a detailed description of these elements, refer to inboundBandwidth on page 525; they have already been
explained there in the context of the LAN interface.

• the alarm configuration attributes alarmMask, alarmLevel, alarmContactHighMask and alarmContactLowMask
and on the alarms in general, refer to 14.2 - Introducing the alarm attributes on page 1123.
• the alarms of the pppBundle[ ] object, refer to 14.10 - Bundle alarms on page 1139.
11.9 Router configuration attributes
This section discusses the configuration attributes concerned with routing. First it describes the general
routing configuration attributes. Then it explains the configuration attributes of the extra features as there
are NAT, L2TP tunnelling, GRE tunnelling, filtering, traffic and priority policy, etc…
Depending on the device, it is possible that not all of these features are present. Refer to the detailed
features overview.

• 11.9.1 - General router configuration attributes on page 617
• 11.9.2 - NAT configuration attributes on page 652
• 11.9.3 - L2TP tunnel configuration attributes on page 658
• 11.9.4 - Native ipsec tunnel configuration attributes on page 673
• 11.9.5 - GRE tunnel configuration attributes on page 683
• 11.9.6 - Manual SA configuration attributes on page 691
• 11.9.7 - IKE SA configuration attributes on page 696
• 11.9.8 - OSPF configuration attributes on page 704
• 11.9.9 - BGP configuration attributes on page 718
• 11.9.10 - Routing filter configuration attributes on page 736
• 11.9.11 - VRRP configuration attributes on page 738
• 11.9.12 - Firewall configuration attributes on page 744
• 11.9.13 - Virtual Routing and Forwarding (VRF) configuration attirbutes on page 769
11.9.1 General router configuration attributes
router1424/ip/router/
The general router configuration attributes are:

• defaultRoute on page 618
• routingTable on page 620
• routingProtocol on page 622
• alternativeRoutes on page 622
• ripUpdateInterval on page 622
• ripHoldDownTime on page 623
• ripv2SecretTable on page 624
• sysSecret on page 625
• pppSecretTable on page 625
• helperProtocols on page 626
• sendTtlExceeded on page 627
• sendPortUnreachable on page 628
• sendAdminUnreachable on page 628
• dhcpStatic on page 629
• dhcpDynamic on page 631
• dhcpCheckAddress on page 633
• radius on page 634
• dns on page 636
• sendHostUnreachable on page 643
• dnsUpdateClient on page 644
• qualityMonitor on page 647
defaultRoute Default:-
Use this attribute to set the default route, also called gateway address.
Refer to 7.3 - Configuring static routes on page 188 for more information on static routes.
The defaultRoute structure contains the following elements:
Element Description
gateway Use this element to specify the IP address of the next Default:0.0.0.0
router that will route all packets for which no specific Range: up to 255.255.255.255
(static or dynamic) route exists in the routing table.
Whether you can omit the gateway element or not, is linked to the following condi-
tions:
If the interface element then …

specifies …
the LAN interface, you can not omit the gateway element.
the WAN interface, you can omit the gateway element only when using
PPP encapsulation.
a DLCI, PVC or tunnel, you can omit the gateway element.
It is important to note that, as of TDRE12, static routes that use an Ethernet-like

interface (broadcast interface) no longer require filling in the gateway field. Refer
to 7.3.4 - Configuring the routing table - rules of thumb on page 194 for more infor-
mation.
interface Use this element to specify the interface through Default:<empty>

which the gateway can be reached. Range: 0 … 24 characters
Do this by typing the name of the interface as you assigned it using the configura-
tion attribute name (e.g. name). Note that this interface can also be a DLCI, PVC,
tunnel, etc.
If you do not specify a value for the interface element, then it is deduced by checking
all interfaces (including DLCIs, PVCs and tunnels) and finding an interface for
which the gateway lies in the subnet defined by the IP address and net mask of
that interface.
Typing the string “discard”, discards all packets for the corresponding destination.
preference Use this element to set the level of importance of the Default:10
default route with respect to routes learnt via RIP. Range: 1 … 200
RIP routes always have a preference of 60. Routes with a lower preference value
are chosen over routes with higher preference value.
Element Description
metric Use this element to set with how much the metric Default:1
parameter of a route has to be incremented. Range: 1 … 15
If two routes exist with the same preference, then the route with the lowest metric
value is chosen. This element is only important when combining static routes and
RIP routes.
Refer to 7.5.3 - Explaining the rip structure on page 208 for more information on
the metric parameter.
routingTable Default:<empty>
Use this attribute to configure the static IP routes.
Refer to 7.3 - Configuring static routes on page 188 for more information on static routes.
The routingTable table contains the following elements:
Element Description
network Use this element to specify the IP address of the des- Default:0.0.0.0
tination network. Range: up to 255.255.255.255
mask Use this element to specify the network mask of the Default:255.255.255.0
destination network. Range: up to 255.255.255.255
gateway Use this element to specify the IP address of the next Default:0.0.0.0
router on the path to the destination network. Range: up to 255.255.255.255
Whether you can omit the gateway element or not, is linked to the following condi-
tions:
If the interface element then …

specifies …
the LAN interface, you can not omit the gateway element.
the WAN interface, you can omit the gateway element only when using
PPP encapsulation.
a DLCI, PVC or tunnel, you can omit the gateway element.
It is important to note that, as of TDRE12, static routes that use an Ethernet-like

interface (broadcast interface) no longer require filling in the gateway field. Refer
to 7.3.4 - Configuring the routing table - rules of thumb on page 194 for more infor-
mation.
interface Use this element to specify the interface through Default:<empty>

which the destination network can be reached. Range: 0 … 24 characters
Do this by typing the name of the interface as you assigned it using the configura-
tion attribute name (e.g. name on page 510). Note that the “interface” can also be a
DLCI, PVC, tunnel, etc.
If you do not specify a value for the interface element, then it is deduced by checking
all interfaces (including DLCIs, PVCs and tunnels) and finding an interface for
which the gateway lies in the subnet defined by the IP address and net mask of
that interface.
Typing the string “discard”, discards all packets for the corresponding destination.
preference Use this element to set the level of importance of the Default:10
route. Range: 1 … 200
Routes with a lower preference value are chosen over routes with higher prefer-
ence value. Note that routes learned through RIP always have a preference of 60.
Element Description
metric Use this element to set with how much the metric Default:1
parameter of a route has to be incremented. Range: 1 … 15
If two routes exist with the same preference, then the route with the lowest metric
value is chosen. Refer to 7.5.3 - Explaining the rip structure on page 208 for more
information on the metric parameter.
routingProtocol Default:none
Use this attribute to activate or deactivate the Routing Information Protocol
(RIP).
Refer to 7.5 - Configuring RIP on page 204 for more information on RIP.
The routingProtocol attribute has the following values:
Value Description
none No routing protocol is used. Only static routes are used.
rip The RIP routing protocol is active. You can set the RIP version per interface. Refer
to the elements txVersion and rxVersion in the rip structure (refer to 7.5.3 - Explaining
the rip structure on page 208).
alternativeRoutes Default:backup
Use this attribute to determine how the 1424 SHDSL Router deals with iden-
tical routes.
If more than one route to a (sub-)network is defined in the routing table, and these routes have …
• identical destination addresses, masks, preferences and metrics,
• a different gateway,
… then you can use the alternativeRoutes attribute to determine which route the 1424 SHDSL Router uses
to reach the (sub-)network.
The alternativeRoutes attribute has the following values:
Value Description
backup The 1424 SHDSL Router always uses the same route to reach the (sub-)network.
Only when this route goes down, it uses the alternative route.
roundRobin The 1424 SHDSL Router alternately uses the two possible routes to reach the
(sub-)network. However, once a certain route is used to reach a specific address,
this same route is always used to reach this specific address.
ripUpdateInterval Default:00000d 00h 00m 30s

Range: 00000d 00h 00m 05s -
Use this attribute to set the interval the 1424 SHDSL Router transmits RIP 00000d 00h 10m 00s
update messages.
Normally, RIP update messages are transmitted every 30 seconds. It is possible to change this interval.
However, changing this interval will also change the lifetime of routes learnt through RIP. If a RIP route
is received for the last time, it is declared down after 6 times the ripUpdateInterval. After the route is down,
it is deleted after 4 times the ripUpdateInterval.
ripHoldDownTime Default:00000d 00h 03m 00s

Range: 00000d 00h 00m 00s -
Use this attribute to set the time during which routing information regarding 00000d 00h 10m 00s
better paths is suppressed.
It should be at least three times the value of the ripUpdateInterval attribute. A route enters into a hold-down
state when an update packet is received that indicates the route is unreachable. The route is marked
inaccessible and advertised as unreachable. However, the route is still used for forwarding packets.
When hold-down expires, routes advertised by other sources are accepted and the route is no longer
inaccessible.
What is the RIP hold-down time?
Suppose you have a situation as depicted in the figure

alongside.
Now suppose the following happens:
1. Route X goes down.
⇒Router A sends a RIP update message to router B
declaring route X down.
2. Only a few moments later, route X goes up for a while
after which it goes down again. This continues for a certain time. In other words, the route status tog-
gles between up and down.
⇒Every time the status of route X changes, Router A sends a RIP update message to router B. Also
router B propagates these RIP update messages. In other words, the toggling of route X causes
that a lot of RIP update messages are sent.
The ripHoldDownTime attribute tries to avoid situations as described above. Suppose router B has a
ripHoldDownTime attribute. In that case, the situation is as follows:
1. Route X goes down.
⇒Router A sends a RIP update message to router B declaring route X down. Router B starts the RIP
hold-down timer.
2. The status of route X starts toggling between up and down.
⇒Router A sends several RIP update messages concerning route X to router B. Router B holds the
status of route X down, as longs as the RIP hold-down timer has not expired.
When the RIP hold-down timer expires and the route is …

• down, then the route status stays down.
• up, then the route status changes to up.
ripv2SecretTable Default:<empty>
Use this attribute to define the secrets used for the RIP authentication.
Refer to 7.5.4 - Enabling RIP authentication on an interface on page 211 for more information on RIP
authentication.
The ripv2SecretTable table contains the following elements:
Element Description
keyId Use this element to set a unique identifier for each Default:0
secret. Range: 0 … 255
secret Use this element to define the secret. Default:<empty>

This secret is sent with the RIP updates on the speci- Range: 0 … 16 characters
fied interface. It is also used to authenticate incoming RIP updates.
interface Use this element to specify on which interface the Default:all

secret is used. Range: 0 … 24 characters
Entering the string “all” (default) means the secret is used on all the interfaces.
Remarks
• If authentication is enabled (either text or md5), then only updates using that authentication are proc-
essed. All other updates on that interface are discarded.
• If you use md5 and if for a certain interface multiple secrets are present in the ripv2SecretTable, then the
first entry in the ripv2SecretTable is used to transmit RIP updates. Authentication of the received RIP
updates is done by looking for the first secret with a matching key.
• If you use text and if for a certain interface multiple secrets are present in the ripv2SecretTable, then only
the first entry in the ripv2SecretTable is used to transmit and receive RIP updates.
sysSecret Default:<empty>
Use this attribute for the PPP authentication process. The PPP authentica-
tor uses the sysSecret attribute in order to verify the peer its response.
pppSecretTable Default:<empty>
Use this attribute for the PPP authentication process. Enter the authentica-
tion name and secret of the remote router in this table.
The pppSecretTable contains the following elements:
Element Description
name Use this element to set the PPP authentication name Default:<empty>
of the remote router. Range: 0 … 64 characters
If the remote router is a 1424 SHDSL Router, then the name element should corre-
spond with the remote 1424 SHDSL Router its sysName or sessionName attribute.
Refer to 6.7.10 - Use which name and secret attributes for PPP authentication? on
page 176.
secret Use this element to set the PPP authentication secret Default:<empty>
of the remote router. Range: 0 … 64 characters
If the remote router is a 1424 SHDSL Router, then the secret element should cor-
respond with the remote 1424 SHDSL Router its sysSecret or sessionSecret attribute.
Refer to 6.7.10 - Use which name and secret attributes for PPP authentication? on
page 176.
helperProtocols Default:<empty>
Use this attribute to define the TCP and UDP port numbers for which broad-
cast forwarding is required. Use this attribute if you specified helper IP addresses using the helpers ele-
ment in the ip structure of the LAN interface. Refer to 5.2.3 - Explaining the ip structure on page 56.
If the helperProtocols table is empty (default), then address substitution is applied for the following proto-
cols:
Protocol name TCP/UDP port number
Time Server 37
IEN-116 Host Name Server 42
Domain Name Server 53
TACACS database service 65
Boot Protocol (BootP) / DHCP server 68
NetBIOS Name Server 137
NetBIOS Datagram Server 138
Important remark
Specifying at least one value in the helperProtocols table clears the default helper list automatically. In that
case, if you want that for instance NetBios Datagram Server broadcast is forwarded, you have to specify
port number 138 again.
For BootP / DHCP broadcast packets, the 1424 SHDSL Router is also a BootP / DHCP Relay Agent. If
the protocol is selected, then the 1424 SHDSL Router will write the IP address of its Ethernet interface
in the BootP or DHCP gateway field and increment the hops field in addition to the address substitution.
sendTtlExceeded Default:enabled
Use this attribute to enable or disable the sending of ICMP “TTL exceeded“
messages.
The sendTtlExceeded attribute has the following values:
Value Description
enabled The 1424 SHDSL Router sends ICMP “TTL exceeded" messages.
disabled The 1424 SHDSL Router does not send ICMP “TTL exceeded” messages.
This also implies that the router is not recognised by the UNIX or Windows trace-
route feature.
What is Time To Live (TTL)?
Each IP packet has a Time To Live (TTL) value in its header. Each device that sends an IP packet sets
this parameter at some fixed or predefined value. When the packet enters a router, the router decre-
ments the TTL value. If a router finds a value 0 after decrementing the TTL, it discards the packet. This
because a value 0 means the packet has passed too many routers. Probably the packet is looping
between a number of routers. This mechanism avoids that routers with configuration errors bring down
a complete network.
The ICMP message “TTL exceeded”
If a router discards a packet because its TTL is exceeded, it normally sends an ICMP “TTL exceeded“
message to the originator of the packet. With the sendTtlExceeded attribute you can define whether you
want the 1424 SHDSL Router to send such ICMP messages or not.
It has been chosen to allow TTL exceeded messages in case of PPP. However, this has the effect that
TTL exceeded is also transmitted on some Ethernet broadcasts.
sendPortUnreachable Default:enabled
Use this attribute to enable or disable the sending of ICMP “Destination
unreachable: Port unreachable“ messages.
The sendPortUnreachable attribute has the following values:
Value Description
enabled The 1424 SHDSL Router sends ICMP “port unreachable" messages.
disabled The 1424 SHDSL Router does not send ICMP “port unreachable” messages.
This also implies that the router is not recognised by the UNIX or Windows trace-
route feature.
The ICMP message “port unreachable”
The 1424 SHDSL Router supports a number of higher-layer IP protocols (Telnet, SNMP and TMA) for
management purposes. If an IP packet is sent to the 1424 SHDSL Router for a higher-layer protocol that
it does not support, it normally sends an ICMP “Destination unreachable: Port unreachable“ message to
the originator of the packet. With the sendPortUnreachable attribute you can define whether you want the
1424 SHDSL Router to send such an ICMP message or not.
sendAdminUnreachable Default:enabled
Use this attribute to enable or disable the sending of ICMP "Destination
unreachable: Communication with destination is administratively prohibited” messages.
The sendAdminUnreachable attribute has the following values:
Value Description
enabled The 1424 SHDSL Router sends ICMP “communication prohibited“ messages.
disabled The 1424 SHDSL Router does not send ICMP “communication prohibited“ mes-
sages.
The ICMP message “communication prohibited”
If the 1424 SHDSL Router receives an IP packet that is destined for a prohibited destination (because
this destination is defined in an access list), then it sends an ICMP "Destination unreachable: Commu-
nication with destination is administratively prohibited” message to the originator of the packet. With the
sendAdminUnreachable attribute you can define whether you want the 1424 SHDSL Router to send such
an ICMP message or not.
dhcpStatic Default:<empty>
This attribute activates the DHCP server on the 1424 SHDSL Router. Use
this attribute to assign a fixed IP address to a client its MAC address and this for an infinite time.
The dhcpStatic table contains the following elements:
Element Description
ipAddress Use this element to assign an IP address to a certain Default:0.0.0.0

client. This client is identified with its MAC address. Range: up to 255.255.255.255
If no IP address is specified, then there is no connection to the client. In that case,
all other attributes in the table are ignored for this client.
mask Use this element to set the client its subnet mask. Default:255.255.255.0
Range: up to 255.255.255.255
gateway Use this element to set the default gateway for the cli- Default:0.0.0.0
ent its subnet. Range: up to 255.255.255.255
If the interface element is left empty (default), then it is the gateway element that
determines on which interface the 1424 SHDSL Router will act as DHCP server.
Namely the interface through which the IP address as entered in the gateway ele-
ment can be reached.
If no gateway is specified, then the 1424 SHDSL Router gives its own address.
This address lies in the subnet of the interface through which the 1424 SHDSL
Router sends out the DHCP reply.
interface Use this element to specify the name of the interface Default:<empty>
on which you want the 1424 SHDSL Router to act as Range: 0 … 36 characters
DHCP server.
dnsSetting Use this element to determine which DNS servers are Default:learned
used for handling the DNS requests. Range: enumerated, see below
The dnsSetting element has the following values:
• configured. The 1424 SHDSL Router sends all DNS requests to the DNS servers
that have been configured in the attribute dns on page 636.
• learned. If DNS servers have been configured in the attribute dns, then all DNS
requests are sent to these servers. However, if no DNS servers have been con-
figured, then the 1424 SHDSL Router tries to learn the DNS servers from the
network. During the time the 1424 SHDSL Router has not learned the DNS
servers yet, DNS relay is active allowing DNS between the clients that already
have been given an IP address.
• relay. The 1424 SHDSL Router acts as a DNS server for its clients, caching all
DNS requests. It answers to DNS requests if possible. However, if an entry is
not present in its cache, then it relays this request to the DNS servers that have
been configured in the attribute dns.
nameServer Use this element to set the IP address of the name Default:0.0.0.0
server that is available to the client. Range: up to 255.255.255.255
Element Description
nameServer2 Use this element to set the IP address of the second Default:0.0.0.0
name server that is available to the client. Range: up to 255.255.255.255
tftpServer Use this element to set the IP address of the TFTP Default:0.0.0.0
server that is available to the client. It is the next Range: up to 255.255.255.255
server to use in boottrap.
macAddress Use this element to enter the client its MAC address. Default:0.0.0.0.0.0
If no MAC address is specified, then there is no con- Range: up to ff.ff.ff.ff.ff.ff
nection to the client. Therefore, all other attributes in the table are ignored for this
client.
bootFile Use this element to set the location of the boot file. Default:<empty>
hostName Use this element to set the name of the client. Default:<empty>
domainName Use this element to set the name the client should use Default:<empty>
when resolving hostnames via the Domain Name Range: 0 … 20 characters
System (DNS).
netbiosNameServer Use this element to set the IP address of the NetBios Default:0.0.0.0
server. Range: up to 255.255.255.255
netbiosNameServer Use this element to set the IP address of the second Default:0.0.0.0
2 NetBios server. Range: up to 255.255.255.255
netbiosNodeType Use this element to configure the client as described Default:<opt>

in RFC 1001 / RFC 1002. Range: enumerated, see below
The netbiosNodeType element has the following values: no-node, B-node, P-node, M-
node, H-node.
dhcpDynamic Default:<empty>
This attribute activates the DHCP server on the 1424 SHDSL Router. Use
this attribute to specify the IP address range from which an IP address may be dynamically assigned to
a client its MAC address.
The dhcpDynamic table contains the following elements:
Element Description
ipStartAddress Use this element to define the start address of the IP Default:192.168.1.100
address range. It is from this range that an IP address Range: up to 255.255.255.255
will be dynamically assigned to a client.
If no IP start address is specified, all other attributes on the same line in the table
are ignored.
ipEndAddress Use this element to define the end address of the IP Default:192.168.1.254
address range. It is from this range that an IP address Range: up to 255.255.255.255
will be dynamically assigned to a client.
The IP address range will only contain the ipStartAddress in case …
• no ipEndAddress is specified,
• the specified ipEndAddress is the same as the ipStartAddress,
• the specified ipEndAddress is smaller than the ipStartAddress,
• the specified ipEndAddress belongs to another subnet than the ipStartAddress.
Do not include the 1424 SHDSL Router its own IP address in this range!
mask Use this element to set the client its subnet mask for Default:255.255.255.0
the specified IP address range. Range: up to 255.255.255.255
gateway Use this element to set the default gateway for the cli- Default:0.0.0.0
ent its subnet. Range: up to 255.255.255.255
If the interface element is left empty (default), then it is the gateway element that
determines on which interface the 1424 SHDSL Router will act as DHCP server.
Namely the interface through which the IP address as entered in the gateway ele-
ment can be reached.
If no gateway is specified, then the 1424 SHDSL Router gives its own address.
This address lies in the subnet of the interface through which the 1424 SHDSL
Router sends out the DHCP reply.
interface Use this element to specify the name of the interface Default:<empty>
on which you want the 1424 SHDSL Router to act as Range: 0 … 36 characters
DHCP server.
Element Description
dnsSetting Use this element to determine which DNS servers are Default:learned
used for handling the DNS requests. Range: enumerated, see below
The dnsSetting element has the following values:
• configured. The 1424 SHDSL Router sends all DNS requests to the DNS servers
that have been configured in the attribute dns on page 636.
• learned. If DNS servers have been configured in the attribute dns, then all DNS
requests are sent to these servers. However, if no DNS servers have been con-
figured, then the 1424 SHDSL Router tries to learn the DNS servers from the
network. During the time the 1424 SHDSL Router has not learned the DNS
servers yet, DNS relay is active allowing DNS between the clients that already
have been given an IP address.
• relay. The 1424 SHDSL Router acts as a DNS server for its clients, caching all
DNS requests. It answers to DNS requests if possible. However, if an entry is
not present in its cache, then it relays this request to the DNS servers that have
been configured in the attribute dns.
Important remark:
• If the dnsSetting element is set to learned and no DNS server is discovered, the
lease time of an IP address (set with the leaseTime element described below) will
always be 60 seconds. This is done because the DHCP client needs to update
its DNS settings when they become available on the DHCP server. If the lease
time of the IP address would be infinit, the client would never receive the DNS
settings.
• When the DHCP server has a valid DNS server or the dnsSetting element is set
to configured, the actual configured leased time will be used.
nameServer Use this element to set the IP address of the name Default:0.0.0.0
server that is available to the client. Range: up to 255.255.255.255
nameServer2 Use this element to set the IP address of the second Default:0.0.0.0
name server that is available to the client. Range: up to 255.255.255.255
tftpServer Use this element to set the IP address of the TFTP Default:0.0.0.0
server that is available to the client. It is the next Range: up to 255.255.255.255
server to use in boottrap.
leaseTime Use this element to set the maximum time a client can Default:00000d 00h 00m 00s
lease an IP address from the specified IP address Range: 00000d 00h 00m 00s -
range. 24855d 03h 14m 07s
If 00000d 00h 00m 00s (default) is specified, then the lease time is infinite.
holdTime Use this element to set the time between two consec- Default:00000d 00h 00m 00s
utive leases of an IP address. I.e. if a client has just let Range: 00000d 00h 00m 00s -
go of its dynamically assigned IP address, then this 24855d 03h 14m 07s
same IP address can not be reassigned before the
holdTime has elapsed.
Element Description
bootFile Use this element to set the location of the boot file. Default:<empty>
hostName Use this element to set the name of the client. Default:<empty>
Because the DHCP server can not give the same Range: 0 … 20 characters
name to all clients of this IP address range, a number is added to the hostname
from the second IP address onwards. The number goes up to 99.
Example
Suppose the hostname is OneAccess. In that case the name for the start IP address
is OneAccess, for the second IP address OneAccess1, and so on.
domainName Use this element to set the name the client should use Default:<empty>
when resolving hostnames via the Domain Name Range: 0 … 20 characters
System (DNS).
netbiosNameServer Use this element to set the IP address of the NetBios Default:0.0.0.0
server. Range: up to 255.255.255.255
netbiosNameServer Use this element to set the IP address of the second Default:0.0.0.0
2 NetBios server. Range: up to 255.255.255.255
netbiosNodeType Use this element to configure the client as described Default:<opt>

in RFC 1001 / RFC 1002. Range: enumerated, see below
The netbiosNodeType element has the following values: no-node, B-node, P-node, M-
node, H-node.
dhcpCheckAddress Default:disabled
Use this attribute to allow that the IP address assigned by the DHCP server
is probed with an ARP request (Ethernet) or ICMP Echo Request (IP). This checks and prevents the dou-
ble use of IP addresses.
The dhcpCheckAddress attribute has the following values:
Value Description
disabled No probing is done when an IP address is leased by a client.
enabled Probing is done when an IP address is leased by a client. In case of …

• Ethernet, the probing is done with an ARP request.
• IP, the probing is done with an ICMP Echo Request (ping).
If a reply is received, it means the IP address is already in use. Therefore, another
IP address is assigned.
arpOnly Probing is done when an IP address is leased by a client. However, the probing is
only done by means of an ARP request (Ethernet).
radius Default:-
Use this attribute to configure the 1424 SHDSL Router for RADIUS. Also
see 9.7 - Configuring RADIUS on page 440.
To enable the use of RADIUS in PPP, PAP or CHAP should be enabled on the 1424 SHDSL Router.
The local configuration of the username and password is ignored if a table of RADIUS servers exist. Fur-
thermore, remote IP address and remote netmask are ignored if a RADIUS server imposes these
attributes.
The radius structure contains the following elements:
Element Description
authServers Use this element to select an authentication server. Default:<empty>

You can create a list of several authentication servers. Range: table, see below
The authServers table contains the following elements:
• address. Use this element to specify the IP address Default:0.0.0.0
of the authentication server. Range: up to 255.255.255.255
• secret. Use this element to set the shared secret to Default:<empty>
authenticate the transaction with the authentica- Range: 0 … 64 characters
tion server.
• timeOut. Use this element to specify the authentica- Default:00000d 00h 00m 05s
tion time-out. Range: 00000d 00h 00m 01s -
00000d 00h 00m 10s
acctServer Use this element to select an accounting server. You Default:-

can only select one accounting server. Range: structure, see below
The acctServer structure contains the following elements:
• address. Use this element to specify the IP address Default:0.0.0.0
of the accounting server. Range: up to 255.255.255.255
• secret. Use this element to set the shared secret to Default:<empty>
authenticate the transaction with the accounting Range: 0 … 64 characters
server.
• timeOut. Use this element to specify the accounting Default:00000d 00h 00m 05s
time-out. Range: 00000d 00h 00m 01s -
00000d 00h 00m 10s
retries Use this element to specify the number of retries Default:1

before selecting the next authentication server in the Range: 0 … 10
authServers table.
acctUpdate Use this element to specify the time at which an Default:00000d 00h 00m 00s
update of the accounting data should be send to the Range: 00000d 00h 00m 00s -
server. 00000d 00h 01m 00s
Set this element to 0 (default) if no update is required. Note that this is not always
supported by the accounting server.
Element Description
login Use this element to set the authentication of access to Default:disabled

the 1424 SHDSL Router using Telnet, FTP, TFTP or Range: enumerated, see below
TMA. No accounting data is sent to the server.
The login element has the following values:
• disabled. No RADIUS login authentication is done.
• enabled. Login authentication is always done using a RADIUS server.
The username and password have to be entered as follows: "username:pass-
word". If the ‘:’ is omitted, then the string is considered to be a password.
Multiple passwords can be added using the same username. Access rights are
sent using the RADIUS attribute CLASS (25) encoded as a string carrying a
binary value. The bit definitions are:
- readAccess = 00000001B
- writeAccess = 00000010B
- securityAccess = 00000100B
- countryAccess = 00001000B (only used on aster4/5)
- fileAccess = 00010000B
Caution should be taken since all access to the device has to be authenticated
by a RADIUS server.
• fallback. Login authentication is done using a RADIUS server. However, if the
server is not available, then authentication is done using the local security table
of the device.
ppp Use this element to set the authentication of a PPP Default:enabled

connection that uses PAP or CHAP. Range: enumerated, see below
The ppp element has the following values:
• disabled. PPP authentication is done using the local sysName/sysSecret or session-
Name/sessionSecret of the device.
• enabled. PPP authentication is always done using a RADIUS server.
dns Default:-
Use this attribute to enter the DNS server addresses. Also see What is
DNS? on page 1148.
The dns structure contains the following elements:
Element Description
primaryDns Use this element to specify the IP address of the pri- Default:0.0.0.0
mary DNS server. Range: up to 255.255.255.255
secondaryDns Use this element to specify the IP address of the sec- Default:0.0.0.0
ondary DNS server. Range: up to 255.255.255.255
domainName Use this element to enter the domain name to which Default:<empty>
the 1424 SHDSL Router belongs. Range: 0 … 32 characters
What is DNS?
The Domain Name Service (DNS) is an Internet service that translates domain names into IP addresses.
Because domain names are alphabetic, they are easier to remember. The Internet however, is really
based on IP addresses. Therefore, every time you use a domain name, a DNS service must translate
the name into the corresponding IP address. For example, the domain name www.mywebsite.com might
translate to 198.105.232.4.
The DNS system is, in fact, its own network. If one DNS server doesn't know how to translate a particular
domain name, it asks another one, and so on, until the correct IP address is returned.
What is DNS proxy?
The 1424 SHDSL Router is a DNS proxy. This means that if the 1424 SHDSL Router has not received
a DNS address (as DHCP client), then it gives its own address in DHCP requests (as DHCP server). The
1424 SHDSL Router relays DNS requests it receives to configured or learned DNS servers.
addrPools Default:<empty>
Use this attribute to create a list or an interval of IP addresses from which
the 1424 SHDSL Router can pick IP addresses and use them on a PPP link.
The addrPool table contains the following elements:
Element Description
name Use this element to assign a name to the IP pool. Default:<empty>

pool Use this element to select between an IP pool type Default:<empty>

and to add IP addresses to the pool. Range: choice, see below
You can select between the following IP pool types:
• an IP list pool. Refer to addrPools/pool/list on page 638.
• an IP interval pool. Refer to addrPool/pool/interval on page 641.
addrPools/pool/list Default:<empty>
Use this element to create one or more lists of IP addresses from which the
1424 SHDSL Router can pick IP addresses and use them as local and remote IP address for a PPP link.
Use the addrPool element in the ip structure to determine from which IP list pool the 1424 SHDSL Router
has to pick IP addresses. Refer to 5.2.3 - Explaining the ip structure on page 56 for more information.
The list table contains the following elements:
Element Description
name Use this element to assign a name to the IP list pool. Default:<empty>
pool Use this element to create a list of IP addresses from Default:<empty>

which the 1424 SHDSL Router can pick one. Range: table, see below
The pool table contains the following elements:
• local. Use this element to set the local IP address. Default:0.0.0.0
Range: up to 255.255.255.255
• remote. Use this element to set the remote IP Default:0.0.0.0
address. Range: up to 255.255.255.255
• netmask. Use this element to set the subnet mask. Default:0.0.0.0
Range: up to 255.255.255.255
Important remark
Note again that an IP list pool is for both local and remote IP addresses.
Example
Suppose …
• you want to create two IP list pools: myList1 and myList2.
• you want that the 1424 SHDSL Router picks local and remote IP addresses from myList2.
Configure this as follows:
Step Action
1 Create two entries in the router/addrPools table and specify a name for each entry.
2 In the pool element select the value list.
3 Expand the pool element by clicking on the black triangle of the pool element.
4 Double-click on the <Table> string situated in the pool/list column.

Step Action
5 Create entries in the pool/list tables and enter a local IP address, remote IP address and
a netmask for each entry.
6 In the addrPool element of the ip structure, select the value “list” and enter the name of the
IP list pool from which you want to pick IP addresses. In our example, this is myList2.
addrPool/pool/interval Default:<empty>
Use this element to create one or more ranges of IP addresses from which
the 1424 SHDSL Router can pick IP addresses and use them as remote IP address for a PPP link. Use
the addrPool element in the ip structure to determine from which IP interval pool the 1424 SHDSL Router
has to pick IP addresses. Refer to 5.2.3 - Explaining the ip structure on page 56 for more information.
The interval structure contains the following elements:
Element Description
name Use this element to assign a name to the IP interval Default:<empty>

pool. Range: 0 … 24 characters
from Use these elements to create a range of IP addresses Default:0.0.0.0

to from which the 1424 SHDSL Router can pick one. Range: up to 255.255.255.255
Important remark
Note again that an IP interval pool is for remote IP addresses only.

Example
Suppose …
• you want to create two IP interval pools: myInterval1 and myInterval2.
• you want that the 1424 SHDSL Router picks a remote IP addresses from myInterval2.
Configure this as follows:
Step Action
1 Create two entries in the router/addrPools table and specify a name for each entry.
2 In the pool element select the value interval.
3 Expand the pool element by clicking on the black triangle of the pool element.
4 Double-click on the <Struct> string situated in the pool/interval column.

Step Action
5 Configure the pool/interval structures. I.e. create an IP address range using the elements
from and to.
6 In the addrPool element of the ip structure, select the value “interval” and enter the name of
the IP interval pool from which you want to pick IP addresses. In our example, this is
myInterval2.
sendHostUnreachable Default:enabled
Use this attribute to enable or disable the sending of ICMP destination
unreachable messages.
The sendHostUnreachable attribute has the following values:
Value Description
enabled The 1424 SHDSL Router sends ICMP destination unreachable messages.
disabled The 1424 SHDSL Router does not send ICMP destination unreachable messages.
dnsUpdateClient Default:-
Use this attribute to let the 1424 SHDSL Router act as a DNS update client.
When enabled, it automatically updates the hostname, managed on the servers of the DNS provider,
with the new IP address.
This update sequence is triggered by a change of the IP address of the coupled interface in the 1424
SHDSL Router.
The dnsUpdateClient table contains the following elements:
Element Description
name Use this element to assign a name to each entry in the Default:<empty>
table. This name must be filled in as argument value Range: 0 ... 24 characters
in the forceDnsUpdate action, refer to router1424/ip/router/
forceDnsUpdate on page 923 for more information.
dnsProvider Use this element to choose a DNS provider. The Default:dynDns

dnsProvider structure contains the following element: Range: dynDns
• dynDns. Currrently, only dynDns can be selected. In the future, other DNS provid-
ers can be added, each with their own set of configuration parameters. Refer
to dnsUpdateClient/dnsProvider/dynDns on page 645 for a detailed description of the
dnsProvider structure.
dnsUpdateClient/dnsProvider/dynDns
Use the dynDns structure to set the configuration parameters of the dynDns DNS provider.
The dynDns structure contains following elements:
Element Description
mode Use this element to select a working mode. The mode Default:disabled
element has the following values: Range: enumerated, see below
• disabled. This is the default setting when adding a new row to this table. It is rec-
ommended by DynDNS that updates only be done from the moment that all
configuration settings are properly done.
So until that is the case, it is recommended to leave the mode element to this
default setting.
• offline. This sets the hostname to offline mode.
This feature is only available to credited users of DynDNS. The return code
Option only for Credited Users will be returned by the server when the account is not
credited. This feature is only effective when the parameter system, described
below, is set to dynamic or custom.
• online. This sets the hostname to online mode.
The update state-machine will change its state to enabledIdle, and will start to
send updates, when appropriate, i.e. when the IP address of the interface
changes.
system Use this element to select the way the updates are Default:dynamic
done. The system element has the following values: Range: enumerated, see below
• dynamic. Updates will be done in the Dynamic DNS system of DynDNS.
• static. Updates are done in the Static DNS system of DynDNS. The Static DNS
system is meant for users whose IP address will not change over time. Unlike
a Dynamic DNS host, a Static DNS host does not expire after 35 days without
updates, but updates take longer to propagate through the DNS system.
• custom. Custom DNS service provides a full DNS solution, giving complete con-
trol over an entire domain name. This service is not free however.
hostNameFqdn Use this element to set the name that will be used Default:<empty>
when updating with the update servers of DynDNS. Range: 0 … 128 characters
An example is: 1424 SHDSL Router.dyndns.org.
A wildcard * is allowed in front of this parameter, for example: *.myhost . The wild-
card aliases *.myhost.dyndns.org to the same address as myhost.dyndns.org.
Note that wildcard aliasing is only effective when the system element is set to
dynamic or static.
interface Use this element to set the name of the interface to Default:<empty>
which the DynDNS hostname update client is to be Range: 0 … 24 characters
coupled. This can be any interface that is configured
to run in routing mode.
Element Description
userName Use this element to set the username to log in to the Default:<empty>
website of DynDNS; it is the same username as the Range: 0 … 24 characters
one the user utilises to log in into the website of
DynDNS as registered account.
password Use this element to set the password to log in to the Default:<empty>
website of DynDNS; It is the same password as the Range: 0 … 24 characters
one the user utilises to log in into the website of
DynDNS as registered account.
tcpPort Use this element to set the TCP port used to commu- Default:http
nicate with the update server of DynDNS. The tcpPort Range: enumerated, see below
element has the following values:
• http. Port 80 will be used.
• httpProxyBypass. Port 8245 will be used. This allows the update client to bypass
transparent HTTP proxies.
mx Use this element to set up mail exchange service. The Default:<empty>

mx structure contains following elements: Range: structure, see below
• name. This is the name of a mail exchange server, Default:<empty>
in the form of mymailserver.domain.tld . In case the Range: 0 … 128 characters
user has a mail exchange server in the network
behind this router, this parameter must be filled in. This servername specifies
a Mail eXchanger for use with the hostname being modified. The specified MX
must resolve to an IP address, or it will be ignored. Providing no MX setting (or
an MX that doesn't resolve properly to an A record) will cause the hostname's
MX records to be removed.
Refer to the Knowledge Base on www.dyndns.org, for more information on Mail
Exchangers and MX records.
• backup. Setting this element to yes, requests that Default:no
the MX is set up as a backup MX. Range: yes/no
The mx element is only effective when the system element is set to dynamic or static.
qualityMonitor
Use this attribute to verify the quality of an entire network link between this device and the end device.
Refer to 9.9 - IP SLA or traffic quality monitoring on page 474 for more information.
The qualityMonitor structure contains the following elements:
Element Description
monitor Use this element to start or stop the quality monitor by Default:disabled
setting this element to enabled or disabled respectively. Range: enabled/disabled
The quality monitor is disabled by default.
This element makes it possible to enable the qualityMonitor during a certain period
of time, during which quality data is logged. It can be disabled again, while the data
is being kept, so that the user can analyze it at any time at a later stage.
It basically means that the qualityMonitor does not have to run all the time, in order
to be able to analyze quality data.
type Use this element to set the way in which the destinations Default:sequantial
table is executed: each line in the table is an action, Range: concurrent/sequantial
they can be executed one after the other, or all at the
same time, i.e. sequential or concurrent respectively.
destinations Use this element to configure the actual monitoring. Default:<empty>

The destinations element is a table: every line in the Range: table, see below
table is a link that is being monitored.
Refer to qualityMonitor/destinations on page 648 for a detailed description.
qualityMonitor/destinations Default:<empty>
Use this element to configure the actual monitoring. The destinations element
is a table: every line in the table is a link that is being monitored.
The destinations table contains the following elements:
Element Description
ipAddress Use this element to set the IP address of the end Default:0.0.0.0
device of the link. Range: up to 255.255.255.255
Either use this element, or the hostName element, to identify the end device.
hostName Use this element to set the name of the end device of Default:<empty>
the link. Range: 0 … 132 characters
Either use this element, or the ipAddress element, to identify the end device.
source Use this element to set the IP source address from Default:0.0.0.0
which the quality monitoring is initiated. Range: up to 255.255.255.255
This must be one of the 1424 SHDSL Router inter-
faces; if this IP address is not one of the 1424 SHDSL Router interface addresses,
then nothing is sent.
When using the default, 0.0.0.0, this means that the IP address of the exit port is
used.
tos Use this element to set the TOS byte of the IP pack- Default:0
ets that are sent out. Range: 0 ... 255
With this, a certain priority can be given to the pack-
ets, in order to get reliable statistics about the link.
It is important that the quality monitoring packets are treated with the same priority
in the link, as actual data that is being sent over the link. This will give a reliable
image of the quality of the link.
interval Use this element to set the time interval with which IP Default:10
packets are sent out. Range: 1 ... 36000
This element is expressed in multiples of 100 milliseconds (msec).
timeOut Use this element to set the time out value after which Default:10
the sent out packets have to be considered as lost. Range: 1 ... 100
This element is expressed in multiples of 100 milliseconds (msec).
icmpLength Use this element to set the length, in bytes, of the Default:64
ICMP packets that are sent out. Range: 32 ... 1300
Element Description
lossAlarm Use this element to set when a loss alarm is gener- Default:<empty>
ated, and when it is cleared again. Range: structure, see below
The lossAlarm structure contains following elements:
• samples. This is the number of samples that are Default:10
taken to calculate the loss alarm. Range: 1 ... 2000
Together with the interval element, explained
above, these elements define the loss window.
For example, when set to 10, and interval is set to 10, a time window of 10 sec-
onds is monitored.
• alarmOn. This is the threshold that activates the loss Default:1
alarm: when more than this number of packets are Range: 1 ... 256
lost, the lossAlarm is activated.
• alarmOff. This is the threshold that deactivates the Default:0
loss alarm: the lossAlarm remains on until this Range: 0 ... 256
number of packets, or less, are lost.
delayAlarm Use this element to set when a delay alarm is gener- Default:<empty>
ated, and when it is cleared again. Range: structure, see below
Refer to qualityMonitor/destinations/delayAlarm on page 650 for a detailed description.
logging Use this element to enable or disable the logging of Default:disabled

the collected quality data. Range: enumerated, see below
By default, the logging is disabled. To enable logging, set this element to one of the
following values: 3min, 5min, 10min, 15min, 30min, 60min. This is the time interval after
which the logging is updated.
For the logging to work correctly and reliably, the logging interval should be
lower or equal to the duration of the loss and the delay window.
To view the quality data that is being logged by the quality monitor, refer to the log-
ging element in the qualityMonitor performance table: refer to 13.9.1 - General router
performance attributes on page 1055.
qualityMonitor/destinations/delayAlarm Default:-
Use this element to set when a delay alarm is generated, and when it is
cleared again.
2 factors are taken into consideration for generating alarms: roundtrip delay and jitter. For the delay,
three values are calculated: a minimum, a maximum and an average. For jitter, a positive deviation, a
negative deviation and an average value are calculated. Based on these values, alarms are generated.
The delayAlarm structure contains the following elements:
Element Description
samples This is the number of samples that are taken to calcu- Default:10
late the delay alarm. Range: 1 ... 2000
Together with the interval element, explained in previ-
ous table, these elements define the delay window.
For example, when set to 10, and interval is set to 10, a time window of 10 seconds
is monitored.
alarmAvgOn This is the threshold that activates the delay alarm Default:500
when the average delay is bigger than this value. Range: 1 ... 64000
This element is expressed in milliseconds (msec).
alarmAvgOff This is the threshold that deactivates the delay alarm Default:500
when the average delay drops below this value. Range: 1 ... 64000
alarmMaxOn This is the threshold that activates the delay alarm Default:500
when the maximum delay is bigger than this value. Range: 1 ... 64000
alarmMaxOff This is the threshold that deactivates the delay alarm Default:500
when the maximum delay drops below this value. Range: 1 ... 64000
alarmMinMaxOn This is the threshold that activates the delay alarm Default:500
when the difference between the minimum and maxi- Range: 1 ... 64000
mum delay is bigger than this value.
alarmMinMaxOff This is the threshold that deactivates the delay alarm Default:500
when the difference between the minimum and maxi- Range: 1 ... 64000
mum delay drops below this value.
alarmAvgJitterOn This is the threshold that activates the jitter alarm Default:500
when the average jitter is bigger than this value. Range: 1 ... 64000
alarmAvgJitterOff This is the threshold that deactivates the jitter alarm Default:500
when the average jitter drops below this value. Range: 1 ... 64000
Element Description
alarmMaxJitterOn This is the threshold that activates the jitter alarm Default:500
when the maximum jitter is bigger than this value. Range: 1 ... 64000
alarmMaxJitterOff This is the threshold that deactivates the jitter alarm Default:500
when the maximum jitter drops below this value. Range: 1 ... 64000

• the alarms of the router object, refer to 14.11 - Router and vrfRouter[ ] alarms on page 1140.
11.9.2 NAT configuration attributes
router1424/ip/router/defaultNat
router1424/ip/router/nat[ ]
These objects contain the following attributes:

• patAddress on page 653
• portTranslations on page 653
• servicesAvailable on page 654
• addresses on page 655
• gateway on page 655
• tcpSocketTimeOut on page 655
• udpSocketTimeOut on page 656
• tcpSockets on page 656
• udpSockets on page 656
• dmzHost on page 656
• tcpAdjustMss on page 657
The following attribute is only present on the nat[ ] object:

Note that the nat [ ] object is not present in the containment tree by default. It must be added manually;
refer to 4.4 - Adding an object to the containment tree on page 45 , this section explains how to do so.
patAddress Default:0.0.0.0
Range: up to 255.255.255.255
Use this attribute to enter the official IP address that has to be used for the
Port Address Translation. Entering an address different from the default value 0.0.0.0 automatically ena-
bles PAT.
Refer to 7.8 - Configuring address translation on page 225 for more information on PAT.
portTranslations Default:<empty>
Use this attribute to define specific port number ranges that should not be
translated.
Some TCP or UDP applications do not allow port translations: these applications require a dedicated
source port number. In the portTranslations table you can define UDP and TCP port ranges that should not
be translated. If a packet with a source port number in such a range is received, PAT replaces only the
source IP address provided it is the first device using this port number. When other devices using the
same application (hence the same port number) try to send traffic to the same Internet destination
address, PAT discards this traffic.
It is also possible to define port ranges that PAT should always discard. The port translation range PAT
uses goes from 60928 up to 65535.
The portTranslations table contains the following elements:
Element Description
protocol Use this element to select the protocol: tcp or udp. Default:tcp
Range: tcp / udp
startPort Use this element to set the lowest value of the TCP or Default:0
UDP port range. Range: 0 … 65535
endPort Use this element to set the highest value of the TCP Default:<opt>
or UDP port range. Range: 0 … 65535
If no endPort value is defined (<opt>), then the port range is limited to the startPort
value only.
action Use this element to set the action in case a packet is Default:noTranslation
received with a source port number that falls within Range: enumerated, see below
the specified port range.
The action element has the following values:
• noTranslation. The port numbers that fall within the specified port range are not
translated.
• deny. Packets with port numbers that fall within the specified port range are dis-
carded.
servicesAvailable Default:<empty>
Use this attribute to define specific port number ranges for incoming Internet
traffic that should not be translated. Instead it is sent to the corresponding private IP address.
The servicesAvailable table makes it possible to have a server on the local network that can be accessed
from the Internet, although it has no official IP address.
The servicesAvailable table contains the following elements:
Element Description
protocol Use this element to select the protocol: tcp or udp. Default:tcp
Range: tcp / udp
startPort Use this element to set the lowest value of the TCP or Default:0
UDP port range. Range: 0 … 65535
endPort Use this element to set the highest value of the TCP Default:<opt>
or UDP port range. Range: 0 … 65535
If no endPort value is defined (<opt>), then the port range is limited to the startPort
value only.
serverAddress Use this element to set the private server address. Default:0.0.0.0
If a packet is received with a source port number that Range: up to 255.255.255.255
falls within the specified port range, then it is sent to the private server address.
serverPort Use this element to realize port translations for incom- Default:<OPT>
ing connections; refer to the example below. Range: 0 ... 65535
Example:
• protocol=tcp, startport=1024, serverAddress=192.168.1.1, serverport=23 (or telnet), endport will be ignored when
using serverPort:
⇒when starting a telnet session to the PAT address port 1024, you actually start a telnet session to
192.168.1.1
using serverPort:
192.168.1.2
using serverPort:
192.168.1.3
addresses Default:<empty>
Use this attribute to enter all the official IP addresses that have to be used
for Network Address Translation. Entering an address in the addresses table automatically enables the
general NAT process. Now you can activate or deactivate NAT per IP interface. Note that by default NAT
is deactivated on all IP interfaces.
Refer to 7.8 - Configuring address translation on page 225 for more information on NAT.
The addresses table contains the following elements:
Element Description
officialAddress Use this element to set the official IP address. Default:0.0.0.0

These addresses are used in the reverse order as Range: up to 255.255.255.255
they appear in the list.
privateAddress Use this element to set the private IP address, i.e. to Default:<opt>
permanently assign an official IP address to a private Range: up to 255.255.255.255
address.
If you do not specify a private IP address, then NAT is applied dynamically. I.e. the
official IP address is used for any private source IP address.
gateway Default:0.0.0.0
Range: up to 255.255.255.255
Use this attribute to define the gateway addresses of routes on which NAT
or PAT should be applied. If you do not configure the gateway attribute, then NAT or PAT is applied on all
routes through this interface.
tcpSocketTimeOut Default:00001d 00h 00m 00s

Range: 00000d 00h 00m 00s -
Use this attribute to define the time-out for TCP sessions that are not closed 24855d 03h 14m 07s
by the application.
Such sessions, whether PAT or NAT is in use, remain active for one day by default. Only decrease this
attribute if some TCP applications do not close properly, filling up the available translation sessions.
udpSocketTimeOut Default:00000d 00h 03m 00s

Range: 00000d 00h 00m 00s -
Use this attribute to define the time-out for UDP sessions that are not closed 24855d 03h 14m 07s
by the application.
Such sessions, whether PAT or NAT is in use, remain active for 3 minutes by default. Only decrease this
attribute if some UDP applications do not close properly, filling up the available translation sessions.
tcpSockets Default:1024
Range: 500 … 4500
Use this attribute to set the maximum number of TCP sessions that may be
used simultaneously for address translation.
udpSockets Default:1024
Range: 500 … 4500
Use this attribute to set the maximum number of UDP session that may be
used simultaneously for address translation.
Remark
As long as the total sum of configured sockets, using the udpSockets and tcpSockets attributes, is higher
then the actually used sockets, new sockets can be allocated.
Both pools must be added together because not only TCP and UDP are supported, but also ESP and
GRE sockets/sessions are counted (and ICMP, but these used to be allocated from the number of UDP
sockets). Both configuration parameters are still present to remain backwards compatible.
In other words, the total amount of usable sockets is the sum of the values of the udpSockets and tcpSockets
attributes.
dmzHost Default:0.0.0.0
Range: up to 255.255.255.255
Use this attribute to set the address of the DMZ (demilitarised zone) host.
What is a DMZ?
In computer networks, a DMZ (demilitarised zone) is a computer host or small network inserted as a
"neutral zone" between a company's private network and the outside public network. It prevents outside
users from getting direct access to a server that has company data. A DMZ is an optional and more
secure approach to a firewall and effectively acts as a proxy server as well.
In a typical DMZ configuration for a small company, a separate computer receives requests from users
within the private network for access to Web sites or other companies accessible on the public network.
The DMZ host then initiates sessions for these requests on the public network. However, the DMZ host
is not able to initiate a session back into the private network. It can only forward packets that have
already been requested.
Users of the public network outside the company can access only the DMZ host. The DMZ may typically
also have the company's Web pages so these could be served to the outside world. However, the DMZ
provides access to no other company data. In the event that an outside user penetrated the DMZ host's
security, the Web pages might be corrupted but no other company information would be exposed.
tcpAdjustMss Default:0/disabled
Range: 200...2000
Use this attribute to configure the Maximum Segment Size (MSS) for tran-
sient packets that traverse the 1424 SHDSL Router.
When a TCP session is established the MSS value in the setup is adapted to the value configured here,
in order to reduce the maximum size of TCP segments.
What is MSS?
MTU or Maximum Transfer Unit is the maximum number of bytes that one packet can contain. Typical,
for Ethernet, this is 1500 bytes. The maximum amount of actual data that can be transported in such a
data packet is 1460 bytes; this is the Maximum Segment Size or MSS.
Reducing MSS
Reducing the maximum size of TCP segments may prevent the communication from slowing down or
even failing.
For instance, when PPP over Ethernet (PPPoE) is being used in the network, PPPoE truncates the
Ethernet Maximum Transfer Unit (MTU) to 1492 bytes, which could result in loss of communication.
Similarly, when a tunnelling protocol such as GRE, L2TP or IPSEC is being used in the network, frag-
mentation may be required if the MSS is not adjusted, which slows down the communication.
Range: 0 ... 65535
11.9.3 L2TP tunnel configuration attributes
This section describes configuration attributes of the following object:
router1424/ip/router/tunnels/

• l2tpTunnels on page 659
• ipsecL2tpTunnels on page 666
l2tpTunnels Default:<empty>
Use this attribute to configure the Layer 2 Tunnelling Protocol tunnels you
want to set up. Add a row to the l2tpTunnels table for each L2TP tunnel you want to set up.
The l2tpTunnels table contains the following elements:
Element Description

the tunnel. Range: 0 … 24 characters
adminStatus Use this element to activate (up) or deactivate the tun- Default:down
nel (down). Range: up / down
mode Use this element to determine whether for the corre- Default:routing
sponding tunnel, IP packets are treated by the routing Range: enumerated, see below
• bridging. All packets received on the tunnel are bridged.
• routing. All packets received on the tunnel are routed.
priorityPolicy Use this element to apply a priority policy on the L2TP Default:<empty>
tunnel. Range: 0 … 24 characters
Refer to 7.11 - Applying QoS on routed traffic on page 259 for more information
about priority policy.

ters of the tunnel. Range: structure, see below
Refer to …
ing IP addresses.
structure.
Element Description

parameters of the tunnel. Range: structure, see below
When bridging is enabled on a tunnel interface, the tunnel acts exactly as a bridge
port for a physical PPP connection.
Refer to …
ing.
l2tp Use this element to configure the L2TP related Default:-

Refer to l2tpTunnels/l2tp on page 661 for a detailed description of the l2tp structure.
backup Use this element to configure the back-up related Default:-

Refer to l2tpTunnels/backup on page 665 for a detailed description of the backup struc-
ture.
inboundBandwidth Use this element to configure the inbound bandwidth of the L2TP tunnel.
• cir.
• correction.
• maxFifoQLen.
• priorityPolicy.
For a detailed description of these elements, refer to 11.3 - LAN interface configu-
ration attributes on page 509; they have already been explained there in the con-
text of the LAN interface.
l2tpTunnels/l2tp Default:-
Use the l2tp structure in the l2tpTunnels table to configure the L2TP related
parameters of the tunnel.
The l2tp structure contains the following elements:
Element Description
localIpAddress Use this element to set the official IP address that Default:<opt>
serves as start point of the L2TP connection. Range: up to 255.255.255.255
remoteIpAddress Use this element to set the official IP address that Default:<opt>
serves as end point of the L2TP connection. Range: up to 255.255.255.255
Both localIpAddress and remoteIpAddress together with the well-known port number for
L2TP (i.e. 1701), make up the socket used for the L2TP session. At the moment,
only one L2TP session can exist between one localIpAddress and remoteIpAddress
combination.
remoteDnsName Instead of specifying a remoteIpAddress, you can specify Default:<empty>

the DNS name of the end point of the L2TP connec- Range: 0 … 64 characters
tion. In that case, the DNS name will be resolved to an
IP address.
Note that in this case, DNS has to be configured on the 1424 SHDSL Router. Refer
to dns on page 636.
pppAuthentication Use this element to enable or disable authentication Default:disabled

on the PPP link in the tunnel. Range: enumerated, see below
Refer to authentication on page 569 for more information.
pppSesionName Use this element to set the PPP authentication name Default:<empty>
of the PPP link in the tunnel. Range: 0 … 64 characters
pppSesionSecret Use this element to set the PPP authentication secret Default:<empty>
of the PPP link in the tunnel. Range: 0 … 64 characters
linkMonitoring Use this element to enable or disable link monitoring Default:-

on the PPP link in the tunnel and to fine-tune it. Range: structure, see below
Refer to linkMonitoring on page 568 for more information.
Element Description
type Use this element to specify the tunnel type. Default:outgoingDial

The type element has the following values: Range: enumerated, see below
• outgoingDial. The outgoing tunnel is not continuously open. It is opened when-

ever data has to be sent through the tunnel, and closed when no data is
detected for a certain time.
• outgoingLeasedLine. The outgoing tunnel is opened as soon as the 1424 SHDSL
Router is up, and it stays open.
• incoming. The tunnel is an incoming tunnel.
Important remark
Make sure that if the type element is set to outgoingDial or outgoingLeasedLine at

one end of the tunnel, that at the other end of the tunnel the type element is set to
incoming.
dataChannelSe- Use this element to enable (on) or disable (off) Default:off

quenceNumbering sequence numbering on the data messages. These Range: on / off
sequence numbers are used to detect lost packets
and/or restore the original sequence of packets that may have been reordered dur-
ing transport.
On control messages, sequence numbering is always enabled.
It is recommended that for connections where reordering or packet loss may occur,
dataChannelSequenceNumbering is enabled.
keepAliveTimeOut Use this element to set the amount of time (in sec- Default:30
onds) the tunnel waits before it sends a keep alive Range: 1 … 3600
message in case it receives no data.
If the tunnel does not receive incoming data during a certain time, it sends a keep
alive message to the other side and waits for an acknowledgement.
noTrafficTimeOut This element applies on dial tunnels only (i.e. for Default:120
which the type element is set to outgoingDial). Range: 1 … 3600
Use this element to set the amount of time (in seconds) the tunnel waits before it
closes in case it receives no data.
l2tpMode Use this element to set the L2TP function of the 1424 SHDSL Router.
The l2tpMode element has the following values:
• lac. The 1424 SHDSL Router acts as an L2TP Access Concentrator.
• lns. The 1424 SHDSL Router acts as an L2TP Network Server.
• auto. If both local and remote 1424 SHDSL Router are set to auto, they mutually
decide who will be the LAC and who the LNS.
Important remark
Only select auto if you use a OneAccess router at both sides of the tunnel.
In conjunction with routers from other vendors (e.g. Cisco), specifically select an
L2TP mode (lac or lns).
Element Description
tunnelAuthentication Use this element to enable (on) or disable (off) tunnel Default:off
authentication. Range: on / off
L2TP incorporates a simple, optional, CHAP-like tunnel authentication system dur-
ing control connection establishment.
If the LAC or LNS wishes to authenticate the identity of the peer it is contacting or
being contacted by, it sends a challenge packet. If the expected response and
response received from a peer does not match, the tunnel is not opened.
To participate in tunnel authentication, a single shared secret has to exist between
the LAC and LNS.
tunnelSecret Use this element to set the tunnel secret. This secret Default:<empty>
is used in the tunnel authentication in order to verify Range: 0 … 64 characters
the peer its response.
copyTos Use this element to enable (on) or disable (off) the cop- Default:on
ying of the TOS byte value from the payload its IP Range: on / off
header to the L2TP header.
maxNrOfRetrans- Use this element to set the number of times a control Default:4
missions message has to be retransmitted in case no acknowl- Range: 0 … 10
edgement follows, before the tunnel is closed.
transmitWindowSize Use this element to set the window size for transmit- Default:4
ting control messages. Range: 1 … 30
receiveWindowSize Use this element to set the window size for receiving Default:4
control messages. Range: 1 … 30
udpChecksum Use this element to enable (on) or disable (off) the Default:off
UDP checksum. Range: on / off
It is recommended to enable the UDP checksum on lower quality links.
calledNr Use this element to set the called number. This ele- Default:<empty>
ment is present for compatibility with other vendors Range: 0 … 48 characters
that support this feature. If you set up a tunnel
between two OneAccess devices, then you can leave this element empty.
The called number is an indication to the receiver of a call as to what (telephone)
number the caller used to reach it. It encodes the (telephone) number to be called
for an outgoing call request (OCRQ) and the called number for an incoming call
request (ICRQ).
The called number is an ASCII string. Contact between the administrator of the
LAC and the LNS may be necessary to coordinate interpretation of the value
needed in this element.
speed Use this element to make an indication of the Default:64000

expected speed for the tunnel in case of MLPPP. Range: 0 … 2147483647
In case you use MLPPP, the Bandwidth Allocation Protocol adds or deletes PPP
links from the bundle depending on the actual amount of traffic. However, some-
how you have to be able to specify the normally required speed. Do this using the
speed element.
Element Description

Unit of the tunnel. This MTU will override the MTU on Range: 500 … 1500
the outgoing interface if it is smaller.
This feature is handy for instance if the tunnel passes over a PPPoE link which
requires an MTU of 1492 instead of the typical 1500. In such a setup, the other,
non-tunnelled traffic will use the standard MTU on the outgoing interface, while for
the tunnel the MTU can be set to 1492.
What is MTU?
sent and handled.
message is sent.
l2tpTunnels/backup Default:-
Use the backup structure in the l2tpTunnels table to configure the back-up
related parameters of the tunnel.
In a main/back-up tunnel mechanism, configuring the backup element allows you to quickly set up a back-
up tunnel as soon as the main tunnel goes down, instead of waiting on several time-outs before the back-
up tunnel is set up. Refer to 9.4.4 - Setting up a main and back-up tunnel on page 386.
The backup structure contains the following elements:
Element Description
interface Use this element to enter the name of the tunnel that Default:<empty>
will act as back-up in a main/back-up mechanism. Range: 0 … 24 characters
Alternatively, if the string "discard" is entered as a backup interface, then the
backup functionality is executed for the main tunnel even if no backup tunnel is
present. So the main tunnel is reset and the route to the main tunnel is closed (so
the route status goes “down” instead of “spoofing”). In that case, if an alternative
route is present, then this route will be taken.
timeOut Use this element to set the set-up time-out in sec- Default:30
onds. If the tunnel is not set up within the specified Range: 1 … 3600
time-out, then the back-up tunnel is set up.
autoRetry This element is only relevant in case the type element Default:no
of the tunnel is set to outgoingLeasedLine. Range: yes / no
Use this element to determine, if a leased line tunnel does not come up, whether
it has to keep trying to come up (yes) or quit after one try (no).
ipsecL2tpTunnels Default:<empty>
Use this attribute to configure the IP secured Layer 2 Tunnelling Protocol
tunnels you want to set up. Add a row to the IpsecL2tpTunnels table for each IPSEC L2TP tunnel you want
to set up.
The elements of the ipsecL2tpTunnel are basically the same as the elements of the l2tpTunnel (refer to
l2tpTunnels on page 659). The only difference is the presence of the ipsec element within the l2tp structure.
Refer to ipsecL2tpTunnels/l2tp/ipsec on page 667 for more information on the ipsec element.
ipsecL2tpTunnels/l2tp/ipsec Default:-
Range: choice, see below
Use this element to apply a security association on the IPSEC L2TP tunnel.
Do this by typing the index name of the security association you want to use. You can create the security
association itself by adding a manualSA or ikeSA object and by configuring the attributes in this object.
Refer to 9.6 - Configuring IP security on page 407 for more information on IP security.
The ipsec element offers you the following choice:
Choice Description
fdxManualSA Select this value if you want to apply a manual secu- Default:<empty>
rity association on both the inbound and outbound Range: 0 … 24 characters
traffic of the IPSEC L2TP tunnel.
If you select this value, then a field appears behind the value. Type the manualSA
Example
If you created a manualSA object with index name my_SA

(i.e. manualSA[my_SA]) and you want to apply this security
association on an IPSEC L2TP tunnel, then enter the
index name as value of the ipsec element.
hdxManualSA Select this value if you want to apply a manual secu- Default:-
rity association on the inbound traffic and another Range: structure, see below
manual security association on the outbound traffic of
the IPSEC L2TP tunnel.
If you select this value, then a structure appears behind the value. This structure
contains the following elements:
• inbound. To apply a security association on the Default:<empty>
inbound traffic, type the manualSA object its index Range: 0 … 24 characters
name in this field.
• outbound. To apply a security association on the Default:<empty>
outbound traffic, type the manualSA object its index Range: 0 … 24 characters
name in this field.
Example
If you created a manualSA object with index name my_SA_in (i.e. manualSA[my_SA_in])
and one with index name my_SA_out (i.e. manualSA[my_SA_out]) and you want to apply
the first on the inbound and the latter on the outbound traffic, then enter the index
names of the manualSA objects as follows:
Choice Description
ikePresharedSA Select this value if you want to apply an IKE pre- Default:-
shared key security association on both the inbound Range: structure, see below
and outbound traffic of the IPSEC L2TP tunnel.
If you select this value, then a structure appears behind the value. Refer to
ipsecL2tpTunnels/l2tp/ipsec/ikePresharedSA on page 669 for a detailed description of the
ikePresharedSA structure.
ikeCertificateSA Select this value if you want to apply an IKE certificate Default:-
security association on both the inbound and out- Range: structure, see below
bound traffic of the IPSEC L2TP tunnel.
If you select this value, then a structure appears behind the value. Refer to
ipsecL2tpTunnels/l2tp/ipsec/ikeCertificateSA on page 671 for a detailed description of the
ikeCertificateSA structure.
ipsecL2tpTunnels/l2tp/ipsec/ikePresharedSA Default:-
Use the ikePresharedSA structure in the ipsec structure to apply an IKE pre-
shared key security association on both the inbound and outbound traffic of the IPSEC L2TP tunnel.
The ikePresharedSA structure contains the following elements:
Element Description
ikeSA Use this element to apply a certain IKE preshared key Default:<empty>
security association on the IPSEC L2TP tunnel. Range: 0 … 24 characters
Do this by typing the ikeSA object its index name in this field.
Example
If you created an ikeSA object with index name mySA (i.e. ikeSA[mySA])
and you want to apply this security association on an IPSEC L2TP tun-
nel, then enter the index name as value of the ikeSA element.
localId Use this element to set the local identifier for use in Default:<ipAddress> 0.0.0.0
IKE phase 1 negotiation. Range: choice, see below
The localId element has the following values:
• ipAddress. Set the IP address that will be used as local ID. If you leave the ipAd-
dress element at its default value (0.0.0.0), then the local IP address of the L2TP
tunnel is used as local ID.
• hostname. Set the hostname that will be used as local ID. The hostname has to
be of the form “host.domain.com”.
• user. Set the username that will be used as local ID. The username has to be of
the form “my.name@company.com”.
remoteId Use this element to set the remote identifier for use in Default:<ipAddress> 0.0.0.0
The remoteId element has the following values:
• ipAddress. Sets the IP address that will be used as remote ID. If you leave the
ipAddress element at its default value (0.0.0.0), then the remote IP address of the
L2TP tunnel is used as remote ID.
• hostname. Sets the hostname that will be used as remote ID. The hostname has
to be of the form “host.domain.com”.
• user. Sets the username that will be used as remote ID. The username has to
be of the form “my.name@company.com”.
preSharedKey Use this element to set the pre-shared key string. Default:presharedkey
This key string in combination with the selected IKE Range: 12 … 49 characters
DH group is used to calculate the key during the key exchange in phase 1 of the
IKE negotiation. Refer to diffieHelmanGroup on page 699.
Element Description
proxyId Use this element to set up a tunnel with other vendors. Default:-
This element must match with the access list of the Range: structure, see below
remote tunnel. The following values define the type of
payload carried by the IPsec frame:
• ipProtocol: Specify an IP protocol using the ipProtocol element. Select one of the
common IP protocols from the drop-down box.
• localIpAddress: Specify the IP address that serves as start point of the IPsec tun-
nel.
• localIpMask: Specify the subnet mask of the local IP address.
• localIpPort: Specify the local port number.
• remoteIpAddress: Specify the IP address that serves as end point of the IPsec tun-
nel.
• remoteIpMask: Specify the subnet mask of the remote IP address.
• remoteIpPort: Specify the remote port number.
ipsecL2tpTunnels/l2tp/ipsec/ikeCertificateSA Default:-
Use the ikeCertificateSA structure in the ipsec structure to apply an IKE certifi-
cate security association on both the inbound and outbound traffic of the IPSEC L2TP tunnel.
The ikeCertificateSA structure contains the following elements:
Element Description
ikeSA Use this element to apply a certain IKE certificate Default:<empty>

security association on the IPSEC L2TP tunnel. Range: 0 … 24 characters
Example
and you want to apply this security association on an IPSEC L2TP tun-
nel, then enter the index name as value of the ikeSA element.
The ipAddress, hostName, user element has to be the same as the IP address / host-
name / username in the certificate of the local device (at least one of these three
values has to be filled in); refer to router1424/fileSystem/generateSelfCertificateRequest on
page 1004 and router1424/fileSystem/getSelfCertificateScep on page 1008.
Element Description
• hostName. Sets the hostname that will be used as remote ID. The hostname has
• derAsn1Dn. This allows a part of the certificate subject field to be used for remote
identification, for example O=company, L=Heverlee.
Certain elements can be used here to fill in in this field. For more information
on these elements, refer to the subject field in router1424/fileSystem/generateSelfCer-
tificateRequest on page 1004.
Pay attention to the order in which the elements are written. Also, spaces
between the characters are taken into account; the field is also case sensitive.
In other words, the information typed in here must be identical to how it is writ-
ten in the certificate subject field.
The remoteId element has to be the same as the ipAddress / hostName / user / derAsn1Dn
in the certificate of the remote device (the remoteId element is actually the localId ele-
ment of the remote device).
payload carried by the ipsec frame:
• localIpAddress: Specify the IP address that serves as start point of the IPsec tun-
nel.
• remoteIpAddress: Specify the IP address that serves as end point of the IPsec tun-
nel.
11.9.4 Native ipsec tunnel configuration attributes
This section describes a configuration attribute of the following object:
This object contains the following attribute:

• ipsecTunnels on page 674
ipsecTunnels Default:<empty>
Use this attribute to configure the IP secured tunnels you want to set up.
Add a row to the IpsecTunnels table for each IPSEC tunnel you want to set up.
The ipsecTunnels table contains the following elements:
Element Description

the tunnel. Range: 0 … 24 characters
serves as start point of the IPSEC tunnel. Range: up to 255.255.255.255
localInterface Use this element to set the startpoint of the tunnel to Default:<empty>
the address of the interface referenced by localInterface. Range: 0 … 24 characters
Use this element when the start point of the tunnel can
not be determined in advance.
serves as end point of the IPSEC tunnel. Range: up to 255.255.255.255
remoteDnsName Use this element to set the DNS name of the end point Default:<empty>
of the IPSEC connection. In this case, the DNS name Range: 0 … 64 characters
will be resolved to an IP address.
ipsec Use this element to apply a security association on Default:-

the IPSEC tunnel. Range: table, see below
Do this by typing the index name of the security association you want to use. You
can create the security association itself by adding a manualSA or ikeSA object and
by configuring the attributes in this object. Refer to 9.6 - Configuring IP security on
page 407 for more information on IP security.
Refer to ipsecTunnels/ipsec on page 677 for a detailed description of the IPSEC struc-
ture.
type Use this element to specify the tunnel type. Default:outgoingLeasedLine

• incoming: The incoming tunnel does not initiate the tunnel but waits for a request
from the remote party.
• outgoingLeasedLine: An outgoingLeasedLine tunnel is opened as soon as the 1424
SHDSL Router is up, and it stays open. No traffic timeouts are started.
• outgoingDial: The outgoingDial tunnel is not continuously open. It is opened when-
Element Description
noTrafficTimeOut This element only applies to dial tunnels, i.e. for which Default:00000d 00h 02m 00s
the type element is set to outgoingDial. Range: 00000d 00h 00m 30s -
00000d 01h 00m 00s
Use this element to set the amount of time (in sec-
onds) the tunnel waits before it closes in case it receives no data.
noTrafficDirection Use this element to set the direction in which traffic is Default:both
monitored. Range: enumerated, see below
The noTrafficDirection element has the following values:
• both: traffic is monitored in both direction.
• inbound: only incoming traffic is monitored.
• outbound: only outgoing traffic is monitored.
remoteRoute Use this element to allow or forbid the use of the Default:-
default route to reach the tunnel end point. Range: structure, see below
When you select this element, a structure appears behind the element. This struc-
ture contains the following elements:
• useDefaultRoute: This element has the following val- Default:enabled
ues: Range: enumerated, see below
- enabled: It is allowed the reach the tunnel end-
point by using the default route.
- disabled: It is not allowed the reach the tunnel endpoint by using the default
route. The user has to wait for an alternative route to come up.
tos Use this element to copy the TOS byte value from the Default:copy
IP header of the payload, or to force the TOS byte to Range: enumerated, see below
a fixed value of 0...255.
The tos element has the following values:
• copy: the TOS byte value is copied from the IP header of the payload.
• 0...255: the TOS byte value is forced to a value between 0 and 255.
dontFragmentBit Use this element to copy the dontFragment bit value Default:copy
from the IP header of the payload to the new IPSEC Range: enumerated, see below
IP header.
The dontFragmentBit element has the following values:
• copy: copies the dontFragment bit value from the IP header of the payload to the
new IPSEC IP header.
• clear: clears the dontFragment bit in the new IPSEC IP header.
• set: sets the dontFragment bit in the new IPSEC IP header.
Element Description

What is MTU?
sent and handled.
message is sent.
ipsecTunnels/ipsec Default:<empty>
Use this element to apply a security association on the IPSEC tunnel.
Do this by typing the index name of the security association you want to use. You can create the security
association itself by adding a manualSA or ikeSA object and by configuring the attributes in this object.
Refer to 9.6 - Configuring IP security on page 407 for more information on IP security.
The ipsec element offers you the following choice:
Choice Description
fdxManualSA Select this value if you want to apply a manual secu- Default:<empty>
rity association on both the inbound and outbound Range: 0 … 24 characters
traffic of the IPSEC tunnel.
If you select this value, then a field appears behind the value. Type the manualSA
Example
If you created a manualSA object with index name my_SA (i.e. manualSA[my_SA]) and
you want to apply this security association on an IPSEC tunnel, then enter the
index name as value of the fdxManualSA element.
hdxManualSA Select this value if you want to apply a manual secu- Default:-
rity association on the inbound traffic and another Range: structure, see below
manual security association on the outbound traffic of
the IPSEC tunnel.
If you select this value, then a structure appears behind the value. This structure
• inbound. To apply a security association on the Default:<empty>
inbound traffic, type the manualSA object its index Range: 0 … 24 characters
name in this field.
• outbound. To apply a security association on the Default:<empty>
outbound traffic, type the manualSA object its index Range: 0 … 24 characters
name in this field.
Example
If you created a manualSA object with index name my_SA_in (i.e. manualSA[my_SA_in])
and one with index name my_SA_out (i.e. manualSA[my_SA_out]) and you want to apply
the first on the inbound and the latter on the outbound traffic, then enter the index
names of the manualSA objects as follows.
ikePresharedSA Select this value if you want to apply an IKE pre- Default:-
shared key security association on both the inbound Range: structure, see below
and outbound traffic of the IPSEC tunnel.
If you select this value, then a structure appears behind the value. Refer to ipsec-
Tunnels/ipsec/ikePresharedSA on page 679 for a detailed description of the ikePresharedSA
structure.
Choice Description
ikeCertificateSA Select this value if you want to apply an IKE certificate Default:-
security association on both the inbound and out- Range: structure, see below
bound traffic of the IPSEC tunnel.
If you select this value, then a structure appears behind the value. Refer to ipsec-
Tunnels/ipsec/ikeCertificateSA on page 681 for a detailed description of the ikeCertificateSA
structure.
ipsecTunnels/ipsec/ikePresharedSA Default:-
Use the ikePresharedSA structure in the ipsec structure to apply an IKE pre-
shared key security association on both the inbound and outbound traffic of the IPSEC tunnel.
The ikePresharedSA structure contains the following elements:
Element Description
ikeSA Use this element to apply a certain IKE preshared key Default:<empty>
security association on the IPSEC tunnel. Range: 0 … 24 characters
Example
and you want to apply this security association on an IPSEC tunnel,
then enter the index name as value of the ikeSA element.
preSharedKey Use this element to set the pre-shared key string. Default:presharedkey
This key string in combination with the selected IKE Range: 12 … 49 characters
DH group is used to calculate the key during the key exchange in phase 1 of the
IKE negotiation. Refer to diffieHelmanGroup on page 699.
Element Description
payload carried by the ipsec frame:
• localIpAddress: Specify the IP address that serves as start point of the IPSEC tun-
nel.
• remoteIpAddress: Specify the IP address that serves as end point of the IPSEC
tunnel.
ipsecTunnels/ipsec/ikeCertificateSA Default:-
Use the ikeCertificateSA structure in the ipsec structure to apply an IKE certifi-
cate security association on both the inbound and outbound traffic of the IPSEC tunnel.
The ikeCertificateSA structure contains the following elements:
Element Description
ikeSA Use this element to apply a certain IKE certificate Default:<empty>

security association on the IPSEC tunnel. Range: 0 … 24 characters
Example
and you want to apply this security association on an IPSEC tunnel,
then enter the index name as value of the ikeSA element.
The ipAddress, hostName, user element has to be the same as the IP address / host-
name / username in the certificate of the local device (at least one of these three
values has to be filled in); refer to router1424/fileSystem/generateSelfCertificateRequest on
page 1004 and router1424/fileSystem/getSelfCertificateScep on page 1008.
Element Description
• derAsn1Dn. This allows a part of the certificate subject field to be used for remote
identification, for example O=company, L=Heverlee.
Certain elements can be used here to fill in in this field. For more information
on these elements, refer to the subject field in router1424/fileSystem/generateSelfCer-
tificateRequest on page 1004.
Pay attention to the order in which the elements are written. Also, spaces
between the characters are taken into account; the field is also case sensitive.
In other words, the information typed in here must be identical to how it is writ-
ten in the certificate subject field.
The remoteId element has to be the same as the IP address / hostname / username
in the certificate of the remote device (the remoteId element is actually the localId ele-
ment of the remote device).
proxyId The following values define the type of payload car- Default:-
ried by the ipsec frame: Range: structure, see below
• localIpAddress: Specify the IP address that will be used as local ID.
• remoteIpAddress: Specify the IP address that will be used as remote ID.
11.9.5 GRE tunnel configuration attributes

• greTunnels on page 684
• ipsecGreTunnels on page 687
greTunnels Default:<empty>
Use this attribute to configure the GRE tunnels you want to set up. Add a
row to the greTunnels table for each GRE tunnel you want to set up.
The greTunnels table contains the following elements:
Element Description
name Use this element to assign a unique interface name to Default:<empty>

the GRE tunnel. Range: 0 … 24 characters
GRE tunnel: up or down. Range: enumerated, see below
priorityPolicy Use this element to apply a priority policy on the GRE Default:<empty>
tunnel. Range: 0 … 24 characters
Refer to 7.11 - Applying QoS on routed traffic on page 259 for more information
about priority policy.
ip Use the ip structure for IP configuration inside the Default:-

GRE tunnel. Refer to 5.2.3 - Explaining the ip structure Range: structure, see below
on page 56 for a detailed description of the ip struc-
ture.
gre Use the gre structure to configure the GRE related Default:-
parameters of the tunnel. Refer to greTunnels/gre on Range: structure, see below
page 685 for a detailed explanation of the gre structure.
inboundBandwidth Use this element to configure the inbound bandwidth of the GRE tunnel.
• cir.
• correction.
• maxFifoQLen.
• priorityPolicy.
For a detailed description of these elements, refer to the inboundBandwidth attribute
in 11.3 - LAN interface configuration attributes on page 509; they have already
been explained there in the context of the LAN interface.
greTunnels/gre Default:-
Use the gre structure to configure the GRE related parameters of the tunnel.
The gre structure contains the following elements:
Element Description
serves as start point of the GRE tunnel. Range: up to 255.255.255.255
serves as end point of the GRE tunnel. Range: up to 255.255.255.255
remoteRoute Use this element to allow default route filtering. Default:-

The remoteRoute structure contains the following ele- Range: structure, see below
ment:
• useDefaultRoute. Use this element to enable or disa- Default:enabled
ble the use of the default route. Range: enabled/disabled
• copy. The TOS byte value is copied from the IP header of the payload.
• 0...255. The TOS byte value is forced to a value between 0 and 255.
from the IP header of the payload to the new GRE IP Range: enumerated, see below
header.
• copy. Copies the dontFragment bit value from the IP header of the payload to the
new GRE IP header.
• clear. Clears the dontFragment bit in the new GRE IP header.
• set. Sets the dontFragment bit in the new GRE IP header.
ttl Use this element to copy the ttl byte value from the IP Default:copy
header of the payload, or to force the ttl byte to a fixed Range: enumerated, see below
value of 0...255.
The ttl element has the following values:
• copy. The ttl byte value is copied from the IP header of the payload.
• 0...255. The ttl byte value is forced to a value between 0 and 255.
Element Description

What is MTU?
sent and handled.
message is sent.
ipsecGreTunnels Default:<empty>
Use this attribute to configure the IPSEC GRE tunnels you want to set up.
Add a row to the ipsecGreTunnels table for each IPSEC GRE tunnel you want to set up.
The ipsecGreTunnels table contains the following elements:
Element Description
name Use this element to assign a unique interface name for the IPSEC GRE Tunnel.
adminStatus Use this element to set the administrative state of the IPSEC GRE tunnel: up or
down.
priorityPolicy Use this element to apply a priority policy on the IPSEC GRE tunnel. Refer to 7.11
- Applying QoS on routed traffic on page 259 for more information about priority
policy.
ip Use the ip structure for IP configuration inside the IPSEC GRE tunnel. Refer to
5.2.3 - Explaining the ip structure on page 56 for a detailed description of the ip
structure.
gre Use the gre structure to set the specific IPSEC GRE parameters. Refer to ipsecGre-
Tunnels/gre on page 688 for a detailed explanation of the gre structure.
inboundBandwidth Use this element to configure the inbound bandwidth of the IPsec GRE tunnel.
• cir.
• correction.
• maxFifoQLen.
• priorityPolicy.
For a detailed description of these elements, refer to the inboundBandwidth attribute
in 11.3 - LAN interface configuration attributes on page 509; they have already
been explained there in the context of the LAN interface.
ipsecGreTunnels/gre Default:-
Use the gre structure to set the specific IPSEC GRE parameters.The gre
structure contains the following elements:
Element Description
serves as start point of the GRE tunnel. Range: up to 255.255.255.255
serves as end point of the GRE tunnel. Range: up to 255.255.255.255
ipsec Use this element to apply a security association on Default:-

the IPSEC GRE tunnel. Range: table, see below
Do this by typing the index name of the security association you want to use. You
can create the security association itself by adding a manualSA or ikeSA object and
by configuring the attributes in this object. Refer to 9.6 - Configuring IP security on
page 407 for more information on IP security.
The ipsec structure contains following elements:
• fdxManualSA
• hdxManualSA
• ikePresharedSA
• ikeCertificateSA
For a detailed description of these elements, refer to ipsecTunnels/ipsec on page 677.
noTrafficTimeout This element only applies to dial tunnels, i.e. for which Default:00000d 00h 02m 00s
the type element is set to outgoingDial. Range: 00000d 00h 00m 30s -
00000d 01h 00m 00s
Use this element to set the amount of time (in sec-
onds) the tunnel waits before it closes in case it receives no data.
noTrafficDirection Use this element to set the direction in which traffic is Default:both
monitored. Range: enumerated, see below
The noTrafficDirection element has the following values:
• both: traffic is monitored in both direction.
• inbound: only incoming traffic is monitored.
• outbound: only outgoing traffic is monitored.
Element Description
type Use this element to specify the tunnel type. Default:outgoingLeasedLine

• incoming: The incoming tunnel does not initiate the tunnel but waits for a request
from the remote party.
• outgoingLeasedLine: An outgoingLeasedLine tunnel is opened as soon as the 1424
SHDSL Router is up, and it stays open. No traffic timeouts are started.
• outgoingDial: The outgoingDial tunnel is not continuously open. It is opened when-
remoteRoute Use this element to allow default route filtering. Default:-

The remoteRoute structure contains the following ele- Range: structure, see below
ment:
• useDefaultRoute. Use this element to enable or disa- Default:enabled
ble the use of the default route. Range: enabled/disabled
• copy. The TOS byte value is copied from the IP header of the payload.
• 0...255. The TOS byte value is forced to a value between 0 and 255.
from the IP header of the payload to the new GRE IP Range: enumerated, see below
header.
• copy. Copies the dontFragment bit value from the IP header of the payload to the
new GRE IP header.
• clear. Clears the dontFragment bit in the new GRE IP header.
• set. Sets the dontFragment bit in the new GRE IP header.
ttl Use this element to copy the ttl byte value from the IP Default:copy
header of the payload, or to force the ttl byte to a fixed Range: enumerated, see below
value of 0...255.
The ttl element has the following values:
• copy. The ttl byte value is copied from the IP header of the payload.
• 0...255. The ttl byte value is forced to a value between 0 and 255.
Element Description

What is MTU?
sent and handled.
message is sent.
11.9.6 Manual SA configuration attributes

• router1424/ip/router/manualSA[ ]/espEncryptionAlgorithm on page 692
• router1424/ip/router/manualSA[ ]/espEncryptionKey on page 693
• router1424/ip/router/manualSA[ ]/espAuthenticationAlgorithm on page 694
• router1424/ip/router/manualSA[ ]/espAuthenticationKey on page 694
• router1424/ip/router/manualSA[ ]/spi on page 694
• router1424/ip/router/manualSA[ ]/snmpIndexOffset on page 695
page 45.
router1424/ip/router/manualSA[ ]/espEncryptionAlgorithm Default:des

Use this attribute to select the algorithm that will be used to encrypt the data
when using IPSEC.
The espEncryptionAlgorithm attribute has the following values:
Value Description
null No encryption is done.

The null encryption algorithm is simply a convenient way to represent the optional
use of applying encryption within ESP. ESP can then be used to provide authenti-
cation and integrity without confidentiality.
des DES is used to encrypt / decrypt the data. The DES key has to be entered in the
espEncryptionKey attribute.
3des Triple DES is used to encrypt / decrypt the data. The 3DES key has to be entered
in the espEncryptionKey attribute.
Make sure that for the same security association on both the local and remote router the same ESP
encryption algorithm is selected.
router1424/ip/router/manualSA[ ]/espEncryptionKey Default:<empty>

Range: octet string, 0 … 24
Use this attribute to define the key that will be used in the encryption /
decryption process when using IPSEC.
The algorithm can be selected using the espEncryptionAlgorithm attribute.
If you use … then …
null encryption the setting of the espEncryptionKey attribute is irrelevant.
DES encryption only the first 8 octets of the key are used. All other octets are ignored.
11 11 11 11 11 11 11 11 22 22 22 22 22 22 22 22 33 33 33 33 33 33 33 33
not used in the encryption

used in the encryption
/ decryption process
/ decryption process
3DES encryption at the transmitter side, the first set of 8 octets of the key are used to encrypt the
data, the second set of 8 octets to decrypt the data and the third set of 8 octets to
encrypt the data again.
11 11 11 11 11 11 11 11 22 22 22 22 22 22 22 22 33 33 33 33 33 33 33 33
encryption encryption
decryption
At the receiver side, the opposite occurs.
encryption key is used.
router1424/ip/router/manualSA[ ]/espAuthenticationAlgorithm Default:hmac_md5

Use this attribute to select the algorithm that will be used to authenticate the
data when using IPSEC.
The espAuthenticationAlgorithm attribute has the following values:
Value Description
null No authentication is done.
hmac_md5 The MD5 hash function is used to authenticate the data. The MD5 key has to be
entered in the espAuthenticationKey attribute.
hmac_sha-1 The SHA-1 hash function is used to authenticate the data. The SHA-1 key has to
be entered in the espAuthenticationKey attribute.
authentication algorithm is selected.
router1424/ip/router/manualSA[ ]/espAuthenticationKey Default:<empty>

Range: octet string, 0 … 20
Use this attribute to define the key that will be used in the authentication
process when using IPSEC. The algorithm can be selected using the espAuthenticationAlgorithm attribute.
If you use … then …
null authentication the setting of the espAuthenticationKey attribute is irrelevant.
MD5 authentication only the first 16 octets of the key are used. All other octets are ignored.
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20
used in the authentication not used in the

process authentication process
SHA-1 authentication all 20 octets of the key are used.
Make sure that on both the local and remote router the same ESP authentication key is used.
router1424/ip/router/manualSA[ ]/spi Default:256

Range: 256 … 2147483647
Use this attribute to set the SPI value. Each security association must have
a unique SPI value because this value is used to identify the security association.
Make sure that for the same security association on both the local and remote router the same SPI value
is used.
router1424/ip/router/manualSA[ ]/snmpIndexOffset Default:0

Range: 0 ... 65535
11.9.7 IKE SA configuration attributes

• router1424/ip/router/ikeSA[ ]/phase1 on page 697
• router1424/ip/router/ikeSA[ ]/snmpIndexOffset on page 703
page 45.
router1424/ip/router/ikeSA[ ]/phase1 Default:-

Use this attribute to configure the parameters of phase 1 in the IKE negoti-
ation process. IKE phase 1 negotiations are used to establish IKE SAs. These SAs protect the IKE phase
2 negotiations.
The phase1 structure contains the following elements:
Element Description
type Use this element to determine who initiates phase 1 of Default:client

the IKE negotiation. Range: enumerated, see below
• client: This side initiates phase 1.
• server: This side waits until the remote side initiates phase 1.
• peerToPeer: Both sides can initiate phase 1.
mode Use this element to set the IKE mode. The choice Default:aggressive
between these modes is a matter of trade-offs. Range: enumerated, see below
• main: Main mode is selected. Some characteristics of main mode are:
- Protects the identities of the peers during negotiations and is therefore more
secure.
- Allows greater proposal flexibility than aggressive mode.
- Is more time consuming than aggressive mode because more messages
are exchanged between peers. (Six messages are exchanged in main
mode.)
• aggressive: Aggressive mode is selected. Some characteristics of aggressive
mode are:
- Exposes identities of the peers to eavesdropping, making it less secure than
main mode.
- Takes half the number of messages of main mode, has less negotiation
power, and does not provide identity protection.
- Is faster than main mode because fewer messages are exchanged between
peers. (Three messages are exchanged in aggressive mode.)
Element Description
encryptionAlgorithm Use this element to select the IKE encryption algo- Default:des
rithm. Range: enumerated, see below
The encryption key is calculated using the selected diffieHelmanGroup algorithm in
combination with the value of the preSharedKey element.
The encryptionAlgorithm element has the following values:
• des: DES (56 bits) is used to encrypt / decrypt the data.
• 3des: Triple DES (168 bits) is used to encrypt / decrypt the data.
• aes128: AES128 (128 bits) is used to encrypt / decrypt the data.
Make sure that for the same security association on both the local and
remote router the same encryption algorithm is selected.
authenticationAlgo- Use this element to select the IKE authentication algo- Default:hmac_sha-1
rithm rithm. Range: enumerated, see below
The authentication key is calculated using the selected diffieHelmanGroup algorithm
in combination with the value of the preSharedKey element.
The authenticationAlgorithm element has the following values:
• hmac_md5: The MD5 hash function is used to authenticate the data.
• hmac_sha-1: The SHA-1 hash function is used to authenticate the data.
remote router the same authentication algorithm is selected.
Element Description
diffieHelmanGroup Use this element to select the algorithm that will be Default:1_modp768
used to calculate the phase 1 IKE key. This key is Range: enumerated, see below
then used to encrypt and authenticate the data. The
calculation of the IKE key is based on the value of the preSharedKey element (refer
to preSharedKey on page 669).
The diffieHelmanGroup element has the following values:
• 1_modp768: The Diffie-Hellman group 1 (768 bits) is used to calculate the IKE
key.
key.
key.
Important remarks
• Note that the heavier the algorithm, the more processing power is required. E.g.
when selecting the Diffie-Hellman group 5, up to 30 seconds may be needed to
generate a key.
• Make sure that for the same security association on both the local and remote
router the same Diffie-Hellman algorithm is selected.
lifeTime Use this element to set the life time, in seconds, of the Default:28800
IKE SA. Range: 120 … 86400
When the life time expires, it is replaced by a new SA (and SPI) or terminated.
keepAlive Use this element to configure the IKE keep alive mes- Default:-
sages. Keep alive messages are sent to check and Range: structure, see below
maintain, or keep alive, the connection between local
and remote.
Refer to router1424/ip/router/ikeSA[ ]/phase1/keepAlive on page 700 for a detailed descrip-
tion of the keepAlive structure.
router1424/ip/router/ikeSA[ ]/phase1/keepAlive Default:-

Use the keepAlive structure in the phase1 structure to configure the IKE keep
alive messages.
The keepAlive structure contains the following elements:
Element Description
mode Use this element to set the keep alive mode. Default:onDemand
• disabled: Keep alive is disabled, i.e. no keep alive messages are sent.
• onDemand: Keep alive messages are sent on the basis of traffic patterns. For
example, if a router has to send outbound traffic and the liveliness of the peer
is questionable, the router sends a keep alive message to query the status of
the peer. If a router has no traffic to send, it never sends a keep alive message.
• periodic: Keep alive messages are sent at the interval specified by the delay ele-
ment.
delay Use this element to set the interval at which keep alive Default:00000d 00h 00m 30s
messages are sent in case the mode element is set to Range: 00000d 00h 00m 00s -
periodic. 24855d 03h 14m 07s
failsPermitted Use this element to set the number of times a keep Default:3
alive message is resent in case no answer was Range: 0 …
received on the original keep alive message.
interval Use this element to set the delay between the retries. Default:00000d 00h 00m 10s
For example, considering the default values, if no Range: 00000d 00h 00m 00s -
24855d 03h 14m 07s
answer is received on a keep alive message, then the
router retries 3 times to resent the keep alive message with an interval of 10 sec-
onds.
router1424/ip/router/ikeSA[ ]/phase2 Default:-

Use this attribute to configure the parameters of phase 2 in the IKE negoti-
ation process.
The phase2 structure contains the following elements:
Element Description
pfsGroup Use this element to select the Perfect Forward Default:none

Secrecy algorithm. Range: enumerated, see below
The pfsGroup element has the following values:
• none: No Perfect Forward Secrecy is performed. The IKE key is calculated
based on the previous key.
• 1_modp768: A completely new key is calculated using the Diffie-Hellman group
1 (768 bits).
2 (1024 bits).
5 (1536 bits).
Important remarks
• Note that the heavier the algorithm, the more processing power is required. E.g.
when selecting the Diffie-Hellman group 5, up to 30 seconds may be needed to
generate a key.
• Make sure that for the same security association on both the local and remote
router the same PFS algorithm is selected.
natTraversal Use this element to enable or disable NAT traversal. Default:enabled

If natTraversal is enabled, then IPSEC traffic flows Range: enabled / disabled
transparently through a NAT device, thereby allowing one or more remote hosts
located behind the NAT device to use secure L2TP/IPSec tunnel connections to
access the router.
natVendorId Use this element to determine which vendor identifi- Default:rfc3947

cation string is exchanged with the remote in order to Range: rfc3947/draft/draft02
detect NAT support.
proposal Use this element to configure the IKE proposal. A pro- Default:-
posal is a list of IKE attributes to protect the IKE con- Range: structure, see below
nection between the IKE host and its peer.
Refer to router1424/ip/router/ikeSA[ ]/phase2/proposal on page 702 for a detailed description
of the proposal structure.
router1424/ip/router/ikeSA[ ]/phase2/proposal Default:-

Use the proposal structure in the phase2 structure to configure the IKE pro-
posal. A proposal is a list of IKE attributes to protect the IKE connection between the IKE host and its
peer.
The proposal structure contains the following elements:
Element Description
espEncryptionAlgo- Use this element to select the IPSEC encryption algo- Default:des
rithm rithm (in case of ESP). Range: enumerated, see below
The espEncryptionAlgorithm element has the following values:
• null: No encryption is done.
The null encryption algorithm is simply a convenient way to represent the
optional use of applying encryption within ESP. ESP can then be used to pro-
vide authentication and integrity without confidentiality.
• des: DES (56 bits) is used to encrypt / decrypt the data.
• 3des: Triple DES (168 bits) is used to encrypt / decrypt the data.
• disabled: No encryption is done.
remote router the same encryption algorithm is selected.
espAuthentication- Use this element to select the IPSEC authentication Default:hmac_md5

Algorithm algorithm (in case of ESP). Range: enumerated, see below
The epsAuthenticationAlgorithm element has the following values:
• disabled: No authentication is done.
ahAuthenticationAl- Use this element to select the IPSEC authentication Default:disabled

gorithm algorithm (in case of AH). Range: enumerated, see below
The ahAuthenticationAlgorithm element has the following values:
• disabled: No authentication is done.
Element Description
lifeTime Use this element to set the life time of the IPSEC SA. Default:-
When the life time expires, it is replaced by a new SA Range: structure, see below
(and SPI) or terminated.
The lifeTime structure contains the following elements:
• time. Use this element to set the life time, in sec- Default:3600
onds, of the IPSEC SA. Range: 120 … 86400
• kBytes. Use this element to set the life time, in kilo- Default:4250000
bytes, of the IPSEC SA. Range: 2500 … 4250000
As soon as one of the two criteria is exceeded (i.e. either the time or the number
of kilobytes), the IPSEC SA is timed out.
router1424/ip/router/ikeSA[ ]/snmpIndexOffset Default:-

11.9.8 OSPF configuration attributes
This section discusses the configuration attributes concerned with OSPF. First it describes the general
OSPF configuration attributes. Then it explains the OSPF area configuration attributes.
• General OSPF configuration attributes on page 705
• Area configuration attributes on page 710
General OSPF configuration attributes

• router1424/ip/router/ospf/routerId on page 706
• router1424/ip/router/ospf/refBandwidth on page 706
• router1424/ip/router/ospf/keyChains on page 706
• router1424/ip/router/ospf/importMetrics on page 707
• router1424/ip/router/ospf/importFilter on page 708
• router1424/ip/router/ospf/importDefault on page 709
²v
router1424/ip/router/ospf/routerId Default:0.0.0.0
Range: up to 255.255.255.255
Use this attribute to set the unique sequence number for the router in the
OSPF network.
router1424/ip/router/ospf/refBandwidth Default:100000 bps

Range: 0 … 2147483647
Use this attribute to set the reference bandwidth. It is used to calculate the
cost of an interface in OSPF. Refer to 7.6.1 - Introducing OSPF on page 213 for more information about
cost.
router1424/ip/router/ospf/keyChains Default:<empty>
Use this attribute to set the key chains that will be used in the MD-5 authen-
tication process. For more information on authentication, refer to …
• 7.6.3 - Enabling OSPF authentication on page 219
• router1424/ip/router/ospf/area[ ]/networks/authentication on page 714
• router1424/ip/router/ospf/area[ ]/virtualLinks/authentication on page 716
The keyChains table contains the following elements:
Element Description
name Use this element to assign an administrative name to Default:chain

the key chain. Range: 0 … 24 characters
chain Use this element to set the properties of each key Default:<empty>
chain. Range: table, see below
Refer to router1424/ip/router/ospf/keyChains/chain on page 707 for a detailed description of
this element.
router1424/ip/router/ospf/keyChains/chain Default:<empty>
The chain table contains the following elements:
Element Description
keyId Use this element to set a unique identifier for each Default:0
secret. Range: 0 … 255
secret Use this element to define the secret. Default:<empty>

sendDate Use this element to set the start date from which the Default:01/01/01
secret is allowed to be sent. Enter the date as argu- Range: 01/01/01 … 31/12/99
ment value in the format dd/mm/yy (e.g. 01/01/05)
sendTime Use this element to set the time from which the secret Default:00:00:00
is allowed to be sent. Enter the time as argument Range: 00:00:00 … 23:59:59
value in the format hh:mm:ss (e.g. 12:30:45).
sendDuration Use this element to set the period of time during which Default:00000d 00h 00m 00s
the secret is allowed to be sent. Range: 00000d 00h 00m 00s -
24855d 03h 14m 07s
acceptDate Use this element to set the start date from which the Default:01/01/01
secret is allowed to be accepted by the other routers Range: 01/01/01 … 31/12/99
in the OSPF network. Enter the date as argument
value in the format dd/mm/yy (e.g. 01/01/05)
acceptTime Use this element to set the time from which the secret Default:00:00:00
is allowed to be accepted by the other routers in the Range: 00:00:00 … 23:59:59
OSPF network. Enter the time as argument value in
the format hh:mm:ss (e.g. 12:30:45).
acceptDuration Use this element to set the period of time during which Default:00000d 00h 00m 00s
the secret is allowed to be accepted by the other rout- Range: 00000d 00h 00m 00s -
ers in the OSPF network. Enter this value in seconds. 24855d 03h 14m 07s
router1424/ip/router/ospf/importMetrics Default:-
Use this attribute to configure the default cost for importing RIP and static
routes into OSPF.
The importMetrics structure contains following elements:
Element Description
static Use this element to set the default cost of a static Default:20
route which will be imported into OSPF. Range: 0 … 2147483647
rip Use this element to set the default cost of a RIP route Default:20
which will be imported into OSPF. Range: 0 … 2147483647
router1424/ip/router/ospf/importFilter Default:<empty>
Use this attribute to configure the import filter which allows or denies the
import of external routes into OSPF.
The importFilter table contains following elements:
Element Description
type Use this element to select the type of routes which will Default:all
be allowed or denied into OSPF. Range: static / rip / all
Whether a route is allowed into OSPF or denied access to OSPF, is set by the ele-
ment mode which is described further on in this table.
• all. All routes are allowed into OSPF / denied access to OSPF.
• static. Static routes are allowed into OSPF / denied access to OSPF.
• rip. Rip routes are allowed into OSPF / denied access to OSPF.
address Use this element to set the IP address the external Default:0.0.0.0
route has to comply to. Range: up to 255.255.255.255
mask Use this element to set the netmask the external route Default:0.0.0.0
has to comply to. Range: up to 255.255.255.255
Address and mask define the address range the external route has to comply
to.
mode Use this element to allow or deny the import of exter- Default:allow
nal routes into OSPF. Range: deny / allow
costType Use this element to set the type of cost of the external Default:type2
route. Range: type1 / type2
The costType element has the following values:
• type1. The external cost is expressed in the same units as OSPF interface cost
(i.e. in terms of the link state metric).
• type2. The external cost is an order of magnitude larger; any type 2 cost is con-
sidered greater than the cost of any path internal to the OSPF routing domain.
Use of type 2 external cost assumes that routing outside the OSPF domain is
the major cost of routing a packet, and eliminates the need for conversion of
external costs to internal link state costs.
cost Use this element to set the cost of the external route. Default:0
Range: 0 … 65535
tag Each external route can be tagged, enabling the Default:0

passing of additional information between AS bound- Range: 0 … 2147483647
ary routers.
router1424/ip/router/ospf/importDefault Default:disabled
Use this attribute to enable or disable the import of a default route into
OSPF. When OSPF receives an external route from any other protocol (static, bgp, rip, radius), it is
checked whether this is a default route or not. When this attribute is enabled, the route will be imported.
Area configuration attributes

• router1424/ip/router/ospf/area[ ]/areaId on page 711
• router1424/ip/router/ospf/area[ ]/stub on page 711
• router1424/ip/router/ospf/area[ ]/networks on page 712
• router1424/ip/router/ospf/area[ ]/virtualLinks on page 715
• router1424/ip/router/ospf/area[ ]/ranges on page 717
• router1424/ip/router/ospf/area[ ]/snmpIndexOffset on page 717
page 45.
router1424/ip/router/ospf/area[ ]/areaId Default:0.0.0.0

Range: up to 255.255.255.255
Use this attribute to set the unique sequence number for the area. The back
bone area must always be area 0.
router1424/ip/router/ospf/area[ ]/stub Default:-

Use this attribute to define an area as a stub area. Refer to 7.6.1 - Introduc-
ing OSPF on page 213 for the definition of a stub area.
The stub structure contains the following elements:
Element Description
mode Use this element to enable or disable the area as a Default:disabled

stub area. Range: enabled / disabled
defaultCost Use this element to assign a default cost to the area. Default:0
This is the cost of the default route of the area. Range: 0 … 2147483647
importSummaries Use this element to enable or disable the import of Default:enabled

summary links into the stub area. Range: disabled / enabled
When this attribute is disabled, only the default route will be injected into the area
(by the Area Border Router). When it is enabled, also the summary links are
injected into the area.
Refer to 7.6.1 - Introducing OSPF on page 213 for the definition of a summary link.
translatorRole Use this element to specify whether or not the 1424 Default:candidate
SHDSL Router will unconditionally translate Type-7 Range: candidate / always
LSAs into Type-5 LSAs.
The translatorRole element has the following values:
• always. The 1424 SHDSL Router always translates Type-7 LSAs into Type-5
LSAs regardless of the translator state of other NSSA border routers.
• candidate. The 1424 SHDSL Router participates in the translator election proc-
ess. I.e. only one NSSA border router is elected as Type-7 translator among all
the NSSA border routers that were set as candidate.
translatorInterval Use this element to define the length of time the 1424 Default:00000d 00h 00m 40s
SHDSL Router, if it is an elected Type-7 translator, Range: 00000d 00h 00m 00s -
will continue to perform its translator duties once it has 00000d 18h 12m 15s
determined that its translator status has been
deposed by another NSSA border router translator.
If an NSSA border router is elected as Type-7 translator among all the NSSA bor-
der routers that were set as candidate, then it will continue to perform translation
duties until supplanted by a reachable NSSA border router whose Nt bit is set or
whose router ID is greater. Such an event may happen when an NSSA router with
translatorRole set to always regains border router status, or when a partitioned NSSA
becomes whole. If an elected translator determines its services are no longer
required, it continues to perform its translation duties for the additional time interval
defined by the translatorInterval. This minimizes excessive flushing of translated
Type-7 LSAs and provides for a more stable translator transition.
router1424/ip/router/ospf/area[ ]/networks Default:<empty>

Use this attribute to identify the interfaces which are part of the area.
The networks table contains following elements:
Element Description
name Use this element to assign an administrative name to Default:<network>

a network. Range: 0 … 24 characters
address Use this element to specify the IP address of the net- Default:0.0.0.0
work. Range: up to 255.255.255.255
mask Use this element to specify the IP address mask of the Default:255.255.255.0
attached network (Network Mask). Range: up to 255.255.255.255
Address and mask define the network address to select the interfaces that will
be part of the OSPF network (with the OSPF parameters defined in this net-
work).
cost Use this element to specify the cost of the link. When Default:0
the cost is set to 0, the actual cost is calculated auto- Range: 0 … 65535
matically.
Refer to 7.6.1 - Introducing OSPF on page 213 for more information about cost.
priority Use this element to set the priority of the link. On the Default:0
basis of this element, the designated router in the net- Range: 0 … 255
work is elected.
Refer to 7.6.1 - Introducing OSPF on page 213 for more information about desig-
nated routers.
This element is only important for broadcast networks. It must not be set for
P2P links.
helloInterval Use this element to specify the length of time, in sec- Default:00000d 00h 00m 30s
onds, between the hello packets that a router sends Range: 00000d 00h 00m 00s -
on an OSPF interface. 00000d 18h 12m 15s
OSPF requires the hello interval and dead interval to be exactly the same
for all routers attached to a common network.
Element Description
deadInterval Use this element to specify the maximum length of Default:00000d 00h 02m 00s
time, in seconds, before the neighbours declare the Range: 00000d 00h 00m 00s -
OSPF router down when they stop hearing the 24855d 3h 14m 07s
router's Hello Packets.
retransmitInterval Use this element to specify the length of time, in sec- Default:00000d 00h 00m 05s
onds, after which an hello packet is retransmitted. Range: 00000d 00h 00m 00s -
00000d 00h 4m 15s
authentication Use this element to authenticate OSPF packets. Default:-
OSPF packets can be authenticated so that routers Range: structure, see below
can be part of routing domains based on predefined passwords. By default, a
router uses a Null authentication which means that routing exchanges over a net-
work are not authenticated. There are two other authentication methods: Simple
Password authentication and Message Digest authentication (MD-5).
Refer to router1424/ip/router/ospf/area[ ]/networks/authentication on page 714 for a detailed
description of this element.
mode Use this element to activate or disable an interface in Default:active

the OSPF network. Range: active / disabled
When an interface is active it is known in the OSPF network, and will pass OSPF
data through the OSPF network. When it is disabled the interface is known in the
OSPF network, but OSPF data will not be passed through (e.g. if an interface is
connected to the outside world using RIP, the other routers in the area will know
this interface, but there is no OSPF link to the outside world).
router1424/ip/router/ospf/area[ ]/networks/authentication Default:-

The authentication structure contains the following elements:
Element Description
type Use this element to set the type of authentication. Default:disabled

The type element has the following values: Range: disabled / text/ md5
• disabled. No authentication is done.

• test. This allows a password (key) to be configured per interface. Interfaces of
different routers that want to exchange OSPF information will have to be con-
• md5. Message Digest authentication. This is a cryptographic authentication. A
key (password) and key-id are configured on each router. The router uses an
algorithm based on the OSPF packet, the key, and the key-id to generate an
"authentication secret" that gets added to the packet. Unlike the simple authen-
tication, the key is not exchanged over the wire.
text Use this element to set the password when using text Default:-
authentication. Range: 0 … 8 characters
keyChain Use this element to set the key chain which will be Default:chain
used in this network when using md5 authentication. Range: 0 … 24 characters
router1424/ip/router/ospf/area[ ]/virtualLinks Default:<empty>

Use this attribute to set up a virtual link between the current area and a
remote area which is not physically connected to the backbone area.
Refer to 7.6.1 - Introducing OSPF on page 213 for more information on the back bone area.
The virtual links table contains following elements:
Element Description
remoteId Use this element to set the IP address of the remote Default:0.0.0.0
router with which the virtual link is established. Range: up to 255.255.255.255
helloInterval Use this element to specify the length of time, in sec- Default:00000d 00h 00m 30s
onds, between the hello packets that a router sends Range: 00000d 00h 00m 00s -
on an OSPF interface. 00000d 18h 12m 15s
deadInterval Use this element to specify the maximum length of Default:00000d 00h 02m 00s
time, in seconds, between the sent hello packets after Range: 00000d 00h 00m 00s -
which the neighbours declare the virtual link down. 24855d 3h 14m 07s
retransmitInterval Use this element to specify the length of time, in sec- Default:00000d 00h 00m 05s
onds, after which an hello packet is retransmitted. Range: 00000d 00h 00m 00s -
00000d 00h 4m 15s
authentication Use this element to authenticate OSPF packets. Default:-
OSPF packets can be authenticated so that routers Range: structure, see below
can be part of routing domains based on predefined passwords. By default, a
router uses a Null authentication which means that routing exchanges over a net-
work are not authenticated. There are two other authentication methods: Simple
Password authentication and Message Digest authentication (MD-5).
Refer to router1424/ip/router/ospf/area[ ]/virtualLinks/authentication on page 716 for more infor-
mation.
router1424/ip/router/ospf/area[ ]/virtualLinks/authentication Default:-

The authentication structure contains the following elements:
Element Description
type Use this element to set the type of authentication. Default:disabled

The type element has the following values: Range: disabled / text/ md5
• disabled. No authentication is done.

• test. This allows a password (key) to be configured per interface. Interfaces of
different routers that want to exchange OSPF information will have to be con-
• md5. Message Digest authentication. This is a cryptographic authentication. A
key (password) and key-id are configured on each router. The router uses an
algorithm based on the OSPF packet, the key, and the key-id to generate an
"authentication secret" that gets added to the packet. Unlike the simple authen-
tication, the key is not exchanged over the wire.
text Use this element to set the password when using text Default:--
authentication. Range: 0 … 8 characters
keyChain Use this element to set the key chain which will be Default:chain
used in the virtual link when using md5 authentication. Range: 0 … 24 characters
router1424/ip/router/ospf/area[ ]/ranges Default:<empty>

By defining ranges in an area, Summary-LSAs can be condensed before
being injected in an other area (by defining a larger subnet mask).
Refer to 7.6.1 - Introducing OSPF on page 213 for more information about Summary-LSAs.
Each address range is defined as an address-mask pair. Many separate networks may then be con-
tained in a single address range, just as a subnetted network is composed of many separate subnets.
Area border routers then summarize the area contents (for distribution to the backbone) by advertising
a single route for each address range. The cost of the route is the maximum cost to any of the networks
falling in the specified range.
The ranges table contains following elements:
Element Description
type Use this element to set the type of Summary-LSA that Default:all
has to be created. Range: enumerated, see below
• summary. The area's routing information is condensed.
• nssa. In case of an NNSA, multiple Type-7 LSAs are aggregated into a single
Type-5 LSA.
• all. Both tasks are performed.
network Use this element to set the IP address of the network. Default:0.0.0.0
Range: up to 255.255.255.255
mask Use this element to set the subnet mask of the net- Default:255.255.255.0
work. Range: up to 255.255.255.255
advertise Use this element to enable or disable the advertise- Default:enabled

ment of the Summary-LSAs into the other areas. Range: enabled / disabled
When this element is disabled, the Summary-LSAs which are part of this range,
will not be known in the other area’s in the OSPF network. When this element is
enabled, the summaries are injected in the other areas of the OSPF network.
tag This element is only relevant in case of NSSAs. Default:0

Use this element to retag the summary of the external Range: 0 … 2147483647
routes entering the NSSA.
router1424/ip/router/ospf/area[ ]/snmpIndexOffset Default:0

Range: 0 ... 65535
11.9.9 BGP configuration attributes
This section discusses the configuration attributes concerned with BGP. First it describes the general
BGP configuration attributes, followed by the ePeer, iPeer, routeFilter and routeMap configuration attributes.
Refer to 7.7 - Configuring BGP on page 221 for more information about BGP.
• General BGP configuration attributes
• ePeer and iPeer configuration attributes
• routeFilter configuration attributes
• routeMap configuration attributes
General BGP configuration attributes

• router1424/ip/router/bgp/asNr on page 720
• router1424/ip/router/bgp/routerId on page 720
• router1424/ip/router/bgp/localPreference on page 720
• router1424/ip/router/bgp/bestPath on page 720
• router1424/ip/router/bgp/networks on page 721
• router1424/ip/router/bgp/aggregates on page 721
• router1424/ip/router/bgp/importMetrics on page 722
• router1424/ip/router/bgp/importFilter on page 723
router1424/ip/router/bgp/asNr Default:0
Range: 0 ... 65535
Use this attribute to set the number of the Autonomous System (AS) the
1424 SHDSL Router belongs to.
router1424/ip/router/bgp/routerId Default:0.0.0.0
Range: up to 255.255.255.255
Use this attribute to set the router ID which identifies the sender within the
BGP network.
router1424/ip/router/bgp/localPreference Default:100
Range: 0 ... max
Use this attribute to set the advertising speaker's degree of preference for
an advertised route. A BGP speaker uses this atribute to inform its internal peers of this preference.
router1424/ip/router/bgp/bestPath Default:-
Use this attribute to influence the routing decision process. The bestPath
Element Description
ignoreAsPath Use this element to enable or disable the use of the Default:disabled
asPath attribute in the decision process. Range: enabled/disabled
deterministicMed Use this element to change the BGP route selection Default:disabled
procedure to a deterministic but slower one. The 1424 Range: enabled/disabled
SHDSL Router will compare the med values first
before applying other selection criteria.
alwaysCompareMed By default, the med value is only considered during Default:disabled

selection of routes from the same Autonomous Sys- Range: enabled/disabled
tem. With this element enabled, the med value is also
considered for routes coming from a different Autonomous System.
missingMedWorst By default, routes that are missing the med attribute, Default:disabled
will be assigned a value of zero. With this element Range: enabled/disabled
enabled, a value of infinity will be assigned to the
missing med attribute, making routes without a med value the least desirable path.
compareRouterId When identical routes are received from different external Default:disabled
peers, the oldest path is normally selected. Range: enabled/disabled
However, when this element is enabled, the route received from the peer with the lowest
router ID is selected.
router1424/ip/router/bgp/networks Default:<empty>
Use this attribute to assemble a list of networks that will be advertised by the
BGP protocol. The networks table contains following elements:
Element Description
address Use this element to set the IP address of the network Default:0.0.0.0
that BGP will advertise. Range: up to 255.255.255.255
work that BGP will advertise. Range: up to 255.255.255.255
routeMap Use this element to set the name of a BGP routeMap, Default:-
used to change the attribute values of the advertised Range: 0 … 24 characters
network. For more information about the routeMap
attribute, refer to routeMap configuration attributes on page 734.
router1424/ip/router/bgp/aggregates Default:<empty>
Use this attribute to create an aggregate entry in the BGP database if any
more-specific BGP routes are available that fall into the specified range. The aggregates attribute contains
Element Description
address Use this element to set the aggregate IP address of Default:0.0.0.0

the network that BGP will advertise. Range: up to 255.255.255.255
mask Use this element to set the aggregate subnet mask of Default:255.255.255.0
the network that BGP will advertise. Range: up to 255.255.255.255
summaryOnly Use this element to suppress all advertisements of Default:disabled

more-specific routes from the updates. Range: enabled/disabled
When this element is enabled, only the aggregate will
be distributed.
asSet Use this element to distribute the aggregate route with Default:disabled
the atomic aggregate attribute present. Range: enabled/disabled
If this element is enabled, the path advertised for this
route will consist of all elements contained in all paths that are being summarized.
routeMap Use this element to set the name of a BGP routeMap, Default:-
used to change the attribute values of the aggregate. Range: 0 … 24 characters
For more information about the routeMap attribute,
refer to routeMap configuration attributes on page 734.
router1424/ip/router/bgp/importMetrics Default:-
Use this attribute to define the value of the med attribute for routes imported
from the system routing table.
The importMetrics table contains following elements:
Element Description
local Use this element to define the value of routes con- Default:noImport
nected to local interfaces. Range: enumerated, see below
The local element has the following values:
• noImport. The route will not be imported into the BGP domain.
• useIGP. The metric value of the route in the system routing table will be used.
• 0 ... 2147483647. The metric value can be entered manually.
static Use this element to define the value of statically con- Default:noImport
figured routes. Range: enumerated, see below
The static element has the same values as the local element: noImport, useIGP and 0
... 2147483647. For the explanation of these values, refer to the local element above.
rip Use this element to define the value of RIP routes. Default:noImport
The rip element has the same values as the local ele- Range: enumerated, see below
ment: noImport, useIGP and 0 ... 2147483647. For the explanation of these values, refer
to the local element above.
ospf Use this element to define the value of OSPF routes. Default:noImport
The ospf element has the same values as the local ele- Range: enumerated, see below
ment: noImport, useIGP and 0 ... 2147483647. For the explanation of these values, refer
to the local element above.
radius Use this element to define the value of routes con- Default:noImport
nected via RADIUS. Range: enumerated, see below
The radius element has the same values as the local element: noImport, useIGP and 0
... 2147483647. For the explanation of these values, refer to the local element above.
router1424/ip/router/bgp/importFilter Default:<empty>
Use this attribute to allow a finer granularity in filtering the import of routes
from the system routing table after the importMetrics settings are applied. The entries in the table are
searched one-by-one in the order they are configured, until the first match is found and applied.
The importFilter table contains following elements:
Element Description
type Use this element to select which routes will be filtered. Default:all
The type element has the following values: all, local, Range: enumerated, see below
static, rip, ospf, radius.
address Use this element to set the IP address of the network Default:0.0.0.0
that will be filtered. Range: up to 255.255.255.255
work that will be filtered. Range: up to 255.255.255.255
mode Use this element to deny or allow the import of the Default:allow
chosen route. Range: deny/allow
routeMap Use this element to set the name of a BGP routeMap. Default:-
When the route is allowed, using the mode element, Range: 0 … 24 characters
this routeMap is used to change the attribute values of
the imported network.
ePeer and iPeer configuration attributes
This section describes the following common ePeer and iPeer configuration attributes:
• router1424/ip/router/bgp/ePeer[ ]/localIp on page 725
• router1424/ip/router/bgp/ePeer[ ]/remoteIp on page 725
• router1424/ip/router/bgp/ePeer[ ]/timers on page 725
• router1424/ip/router/bgp/ePeer[ ]/weight on page 726
• router1424/ip/router/bgp/ePeer[ ]/originateDefault on page 726
• router1424/ip/router/bgp/ePeer[ ]/softReconfig on page 726
• router1424/ip/router/bgp/ePeer[ ]/inboundFilters on page 727
• router1424/ip/router/bgp/ePeer[ ]/outboundFilters on page 727
• router1424/ip/router/bgp/ePeer[ ]/inboundMaps on page 728
• router1424/ip/router/bgp/ePeer[ ]/outboundMaps on page 728
• router1424/ip/router/bgp/ePeer[ ]/snmpIndexOffset on page 728
• router1424/ip/router/bgp/ePeer[ ]/<alarmConfigurationAttributes> on page 728
This section describes the following ePeer configuration attributes:
• router1424/ip/router/bgp/ePeer[ ]/astranslation on page 729
• router1424/ip/router/bgp/ePeer[ ]/remoteAs on page 729
• router1424/ip/router/bgp/ePeer[ ]/multiHop on page 730
This section describes the following iPeer configuration attributes:
• router1424/ip/router/bgp/iPeer[ ]/nextHopSelf on page 730
The objects ePeer and iPeer are not present in the containment tree by default. If you want to use the fea-
ture associated with this object, then add the objects first. Refer to 4.4 - Adding an object to the contain-
ment tree on page 45.
router1424/ip/router/bgp/ePeer[ ]/localIp Default:<OPT>,0.0.0.0

Range: up to 255.255.255.255
Use this attribute to set the local IP address of the TCP connection. If not
configured, the IP address of the outgoing interface is used.
router1424/ip/router/bgp/ePeer[ ]/remoteIp Default:0.0.0.0

Range: up to 255.255.255.255
Use this attribute to set the remote IP address of the TCP connection.
router1424/ip/router/bgp/ePeer[ ]/timers Default:-

Use this attribute to set the timing parameters of the connection. The timers
Element Description
keepAlive Use this element to set the interval by which keep Default:00000d 00h 00m 30s
alive messages are sent to the peer. Range: 00000d 00h 00m 00s -
00000d 18h 12m 15s
A reasonable maximum value of the keepAlive interval is one third of the
negotiated holdTime interval.
holdTime Use this element to set the period after which the peer Default:00000d 00h 01m 30s
is declared dead, when no keep alive messages are Range: 00000d 00h 00m 00s -
received. 00000d 18h 12m 15s
router1424/ip/router/bgp/ePeer[ ]/weight Default:0

Range: 0 ... 2147483647
Use this attribute to set the local weight of all routes learned from this neigh-
bor.
router1424/ip/router/bgp/ePeer[ ]/originateDefault Default:-

Use this attribute to set whether or not a default route is sent to the neighbor.
The originateDefault structure contains the following elements:
Element Description
mode Use this element to enable or disable the sending of a Default:disabled

default route to the neighbor. Range: enabled/disabled
routeMap Use this element to set the name of a BGP routeMap, Default:<OPT>
used to change the atribute values of the default Range: 0 … 24 characters
route.
router1424/ip/router/bgp/ePeer[ ]/softReconfig Default:disabled

When enabled, incoming updates from the neighbor will be stored unmodi-
fied, so when the inbound route filtering/mapping configuration on the peer changes, an inbound softRe-
set can be executed without having to reset the peer.
router1424/ip/router/bgp/ePeer[ ]/inboundFilters Default:<empty>

Use this attrbibute to set a list of filters to be applied one by one, until the
first match is found, on the incoming updates of this peer. The inboundFilters table contains following ele-
ment:
Element Description
name Use this element to set the name of a BGP routeFilter. Default:-
Refer to routeFilter configuration attributes on Range: 0 … 24 characters
page 731 for more information about the attribute
routeFilter.
router1424/ip/router/bgp/ePeer[ ]/outboundFilters Default:<empty>

Use this attrbibute to set a list of filters to be applied one by one, until the
first match is found, on the outgoing updates of this peer. The outboundFilters table contains following ele-
ment:
Element Description
Refer to routeFilter configuration attributes on Range: 0 … 24 characters
routeFilter.
router1424/ip/router/bgp/ePeer[ ]/inboundMaps Default:<empty>

Use this attrbibute to set a list of routeMaps to be applied one by one, until the
first match is found, on the incoming updates of this peer. The inboundMaps table contains following ele-
ment:
Element Description
name Use this element to set the name of a BGP routeMap. Default:-
Refer to routeMap configuration attributes on Range: 0 … 24 characters
routeMap.
router1424/ip/router/bgp/ePeer[ ]/outboundMaps Default:<empty>

Use this attrbibute to set a list of routeMaps to be applied one by one, until the
first match is found, on the outgoing updates of this peer. The outboundMaps table contains following ele-
ment:
Element Description
Refer to routeMap configuration attributes on Range: 0 … 24 characters
routeMap.
router1424/ip/router/bgp/ePeer[ ]/snmpIndexOffset Default:0

Range: 0 ... 65535
router1424/ip/router/bgp/ePeer[ ]/<alarmConfigurationAttributes> Default:<empty>

• the alarms of the ePeer/iPeer object, refer to 14.13 - BGP ePeer and iPeer alarms on page 1142.
router1424/ip/router/bgp/ePeer[ ]/astranslation Default:-

This attribute is only present in the ePeer object.
Use this attribute to manipulate the AS numbers. The asTranslation structure contains the following ele-
ments:
Element Description
localAsNr Use this element to set the AS number that will be Default:<OPT>, 0
used to set up the connection with the external peer, Range: 0 … 65535
instead of the common AS number of the BGP router
prepend When enabled, the localAsNr will be prepended to any Default:enabled

routes received from the external peer. Range: enabled/disabled
The localAsNr is the localAsNr element described above, here in this table.
router1424/ip/router/bgp/ePeer[ ]/remoteAs Default:<OPT>, 0

Range: 0 ... 65535
When different from zero, the external peer neighbor must announce itself to belong to this Atonomous
System. If not, the connection is refused.
router1424/ip/router/bgp/ePeer[ ]/multiHop Default:-

By default, for external peers, only directly connected neighbors are allowed. This means the number of
hops is 1.
Use this attribute to set the maximum number of hops needed to reach the neighbor of an external peer.
The multiHop structure contains the following elements:
Element Description
nrHops Use this element to set the maximum number of hops Default:1
needed to reach the neighbor of an external peer. Range: 0 … 255
securityCheck Use this element to set a security check on the BGP Default:enabled
packets. The securityCheck element has the following Range: enabled/disabled
values:
• enabled. If securityCheck is enabled, BGP packets are transmitted on this peer with
TTL value 255; on the receiving side, packets are checked to have a minimum
TTL value of (255 - nrHops).
• disabled. When securityCheck is disabled, no check on the minimum TTL value of
an incoming packet is executed, but BGP packets are transmitted with a TTL
value of only nrHops, thus ensuring that the packets will not reach the remote
neighbor if more hops are needed.
router1424/ip/router/bgp/iPeer[ ]/nextHopSelf Default:disabled

This attribute is only present in the iPeer object.
When enabled, the local IP address will be used as the next hop for all updates sent to the BGP neighbor.
routeFilter configuration attributes

• router1424/ip/router/bgp/routeFilter[ ]/snmpIndexOffset on page 732
• router1424/ip/router/bgp/routeFilter[ ]/filters on page 732
page 45.
router1424/ip/router/bgp/routeFilter[ ]/snmpIndexOffset Default:0

Range: 0 ... 65535
router1424/ip/router/bgp/routeFilter[ ]/filters Default:<empty>

Use this attribute to define filters. Each row in the table contains a filter def-
inition. The filters table contains following elements:
Element Description
network Use this element to set the network IP address. After Default:0.0.0.0
applying the prefixLength to both this network configura- Range: up to 255.255.255.255
tion and the prefix to be filtered, a match is successful
if both results are equal.
prefixLength Use this element to set the prefix length. The prefix- Default:-
Length element contains the following values: Range: structure, see below
• mask. Use this value to set the mask length to apply Default:255
to the configured network and the prefix to filter. Range: 0 ... 255
The value 255 actually means any.
• minLength. Use this value to set the minimum net- Default:<OPT>, 0
Mask length required. Range:
• maxLength. Use this value to set the maximum net- Default:0
Mask length allowed. The value 255 actually Range: 0 ... 32|255
means any.
nextHop Use this element to find a match for the nextHop Default:<OPT>,0.0.0.0
attribute value. Range: up to 255.255.255.255
asPath Use this element to filter the AS path. The asPath ele- Default:<OPT>, any
ment contains the following values: Range: choice, see below
• any. No filtering will be done. Default:<empty>
• empty. The asPath attribute must be empty. Default:<empty>

• contains. The asPath attribute must contain the AS Default:0

number configured here. Range: 0 ... 65535
• origin. Route update must be originated in the AS Default:0
configured here. Range: 0 ... 65535
• neighbor. Route update is directly received from the Default:0
AS configured here. Range: 0 ... 65535
origin Use this element to find a match for the origin attribute Default:<OPT>
value. The origin element contains the following val- Range: enumerated, see below
ues: any, igp, egp, incomplete.
Element Description
med Use this element to find a match for the med attribute Default:<OPT>, 0
value. Range: 0 … 24 characters
mode Use this element to set the action to take if all config- Default:allow
ured attribute values match. Range: allow/deny
routeMap configuration attributes

• router1424/ip/router/bgp/routeMap[ ]/snmpIndexOffset on page 735
• router1424/ip/router/bgp/routeMap[ ]/filter on page 735
• router1424/ip/router/bgp/routeMap[ ]/nextHop on page 735
• router1424/ip/router/bgp/routeMap[ ]/weight on page 735
• router1424/ip/router/bgp/routeMap[ ]/localPreference on page 735
• router1424/ip/router/bgp/routeMap[ ]/prependAsPath on page 735
• router1424/ip/router/bgp/routeMap[ ]/origin on page 735
• router1424/ip/router/bgp/routeMap[ ]/med on page 735
page 45.
router1424/ip/router/bgp/routeMap[ ]/snmpIndexOffset Default:<empty>

router1424/ip/router/bgp/routeMap[ ]/filter Default:<empty>

Use this attribute to set the name of the routeFilter to be checked:
• If mode "allow" is returned, the routeMap is applied.
• If mode "deny" is returned, the route is passed unchanged.
• If no filter object is found, all routes are adapted by this routeMap.
router1424/ip/router/bgp/routeMap[ ]/nextHop Default:<OPT>,0.0.0.0

Range: up to 255.255.255.255
Use this attribute to set a new value for the nextHop attribute.
router1424/ip/router/bgp/routeMap[ ]/weight Default:<OPT>,0

Range: 0 ... 2147483647
Use this attribute to set the local weight, for incoming updates, that will be
applied for the route by the BGP route selection process.
router1424/ip/router/bgp/routeMap[ ]/localPreference Default:<OPT>,0

Range: 0 ... 2147483647
Use this attribute to set a new value for the localPreference attribute.
router1424/ip/router/bgp/routeMap[ ]/prependAsPath Default:<OPT>

Range: character string, 0 ...9
Use this attribute to set a string containing a space separated list of AS num-
bers to be prepended to the asPath attribute of the route update.
router1424/ip/router/bgp/routeMap[ ]/origin Default:any

Use this attribute to set a new value for the origin attribute. Possible values
are: any, igp, egp, incomplete.
router1424/ip/router/bgp/routeMap[ ]/med Default:0

Range: 0 ... 2147483647
Use this attribute to set a new value for the med attribute.
11.9.10 Routing filter configuration attributes

• router1424/ip/router/routingFilter[ ]/filter on page 737
• router1424/ip/router/routingFilter[ ]/snmpIndexOffset on page 737
page 45.
router1424/ip/router/routingFilter[ ]/filter Default:<empty>

Use this attribute to set up a routing update filter.
Only the routes to networks that are specified in the filter table are forwarded. All other routes are blocked.
If the filter table is empty, then all routes are forwarded.
The filter table contains the following elements:
Element Description
network This is the IP address of the network. The address Default:0.0.0.0

may be a (sub-)network address. It should match an Range: up to 255.255.255.255
entry in the router1424/ip/router/routingTable status
attribute of the 1424 SHDSL Router.
mask This is the IP subnet mask of the network. By combin- Default:255.255.255.0

ing an IP address with a mask you can uniquely iden- Range: up to 255.255.255.255
tify a range of addresses.
Currently, the 1424 SHDSL Router supports up to 5 routing update filters. Although you can add more
than 5 routingFilter[ ] objects to the containment tree, no more than 5 will be active.
Example
This example shows a filter that only forwards the route to subnet 192.168.48.0.
router1424/ip/router/routingFilter[ ]/snmpIndexOffset Default:0

Range: 0 ... 65535
11.9.11 VRRP configuration attributes
router1424/ip/router/vrrp[ ]/

• vrId on page 739
• ipAddresses on page 739
• interfaces on page 740
• criticals on page 741
• advertiseInterval on page 742
• preemptMode on page 742
• pingReply on page 743
page 45.
vrId Default:0
Range: 0 … 255
Use this attribute to set the identification of the virtual router. Specify a
number between 1 and 255. The VRID has to be set the same on all participating routers.
Setting the vrId to 0 (default) disables this virtual router instance.
ipAddresses Default:<empty>
Use this attribute to configure one or more IP addresses on the virtual
router.
The ipAddresses table contains the following element:
Element Description
address Use this element to configure the IP address of the vir- Default:0.0.0.0
tual router. This address must be the same on all rout- Range: up to 255.255.255.255
ers participating in this virtual router.
By adding several IP addresses, several IP addresses can be configured on a sin-
gle virtual router. This can be used to ensure redundancy while migrating from one
address scheme to another. It cannot be used for load balancing purposes, in this
case multiple virtual routers must be used.
If no IP address is configured, this virtual router instance is not active.
It is important that all VRRP routers have a physical interface configured with an IP address in the same
subnet as the virtual router. The VRRP protocol sends only IP addresses and not subnet information.
Without the corresponding subnet information, the VRRP router will add the virtual router address as a
single IP address with a host (255.255.255.255) netmask. This will prevent routing from working prop-
erly, as the virtual router will not listen to broadcasts from the local network.
interfaces Default:<empty>
Use this attribute to add Ethernet-alike interfaces3 to the virtual router and
assign a priority to them. This priority is used in the master virtual router election process.
The interfaces table contains the following element:
Element Description
name Use this element to specify the name of the interface Default:<empty>
that you want to add to the virtual router. Range: 0 … 36 characters
priority Use this element to specify the priority of the interface. Default:100
Specify a number between 1 and 254. The higher the Range: 1 … 254
number, the higher the priority.
The numbers 0 and 255 are reserved numbers and cannot be set by the user:
• 0 specifies that the master has stopped working and that the backup router
needs to transition to master state.
• 255 specifies that the VRRP router is the IP address owner and therefore is
master, independently from the priority settings.
Refer to 7.9.1 - Introducing VRRP on page 248 for more information on how the
priority plays a role in the election of a master virtual router.
3. Ethernet-alike interfaces are e.g. an Ethernet interface, a VLAN on an Ethernet interface, a

bridge group, a VLAN on a bridge group, etc.
criticals Default:<empty>
Use this attribute to specify which interfaces must be up in order for the
VRRP router to start.
The criticals table contains the following element:
Element Description
name Use this element to specify the name of the interface Default:<empty>
that must be up before the router may be elected as Range: 0 … 36 characters
master.
So as soon as an interface that is defined in the criticals table goes down, the com-
plete router is considered to be down (on VRRP level that is). In that case, a new
master has to be elected. So this adds an extra condition to the election process
as shown in How is a master virtual router elected? on page 249.
penalty Use this element to specify a penalty that can be Default:255

applied on the critical interface. Range: 0 … 255
If a critical interface is down, this penalty will be applied to the priority configured on
a VRRP interface (with the interfaces attribute described above).
When the penalty exceeds the priority, the VRRP interface is inactive; otherwise the
VRRP interface uses the reduced priority.
By default, the penalty for each critical interface is 255 or fullPriority, so that all critical
interfaces must be up in order for the VRRP interfaces to be activated.
advertiseInterval Default:00000d 00h 00m 01s

Range: 00000d 00h 00m 00s -
Use this attribute to set the time between VRRP advertisement transmis- 00000d 18h 12m 15s
sions.
Actually, only the master virtual router sends VRRP advertisements. However, the advertisement inter-
val has to be set the same on all participating routers.
preemptMode Default:enabled
Use this attribute to allow a backup virtual router to take over from the mas-
ter virtual router in case the backup virtual router has a higher priority on the enclosing virtual router.
The preemptMode attribute has the following values:
Value Description
enabled If after a router is elected as master a backup appears which has a higher priority
than the master, then the backup begins to send its own advertisements. The cur-
rent master will see that the backup has higher priority and stop functioning as the
master. The backup will then see that the master has stopped sending advertise-
ments and assume the role of master.
disabled Once a router is elected as master, it stays master until it goes down. So the
appearance of a backup with a higher priority after the master has been elected
does not cause a new election process.
While preemption can ensure that a primary router will return to master status once it returns to service,
preemption also causes a brief outage while the election process takes place. Disabling preemption will
ensure maximum up-time on the network, but will not always result in the primary or highest priority
router acting as master.
Note that, regardless of the setting of the preemptMode attribute, the VRRP IP address owner will always
preempt.
pingReply Default:any
Use this attribute to set how the virtual router responds to ICMP requests.
The pingReply attribute has the following values:
Value Description
ownerOnly This is the default behaviour, and means that the VRRP address will not reply to
ICMP echo packets when the VRRP address is virtual (i.e. not attached to an inter-
face).
master The VRRP will answer to the ICMP requests.
Range: 0 ... 65535
11.9.12 Firewall configuration attributes
router1424/ip/router/firewall

• inspection on page 745
• outboundPolicies on page 745
• inboundPolicies on page 750
• outboundSelfPolicies on page 755
• inboundSelfPolicies on page 759
• attacks on page 763
• log on page 765
• alg on page 767
• tcpAdjustMss on page 768
inspection Default:disabled
Use this attribute to enable or disable the firewall.
outboundPolicies Default:<empty>
Use this attribute to define outbound SNet policies. Refer to 9.8.4 - Defining
an outbound SNet policy on page 460 for more information.
The outboundPolicies table contains the following elements:
Element Description
sNet Use this element to specify the name of the source Default:<name> corp
SNet for which you want to create an outbound SNet Range: choice, see below
policy.
lowing values:
• name. Select this value if the source SNet is one of Default:corp
the standard SNets. In the second part of the sNet Range: corp / dmz
element, use the drop-down box to select one of
the standard SNets:
- corp. The source SNet is “corporate”. If you select this
value, then you create a policy for the traffic from the
corporate SNet to any SNet except the self SNet.
- dmz. The source SNet is “DMZ”. If you select this value,
then you create a policy for the traffic from the DMZ
SNet to any SNet except the self SNet.
• custom. Currently, you can only select standard Default:<empty>

SNets. In future releases of the TDRE, it will be Range: 0 … 16 characters
possible to select custom created SNets.
Note that you only have to set the source SNet. The destination SNet is
always any SNet except the self SNet.
Element Description
sourceIp Use this element to specify the source IP address(es) Default:<opt>

for which you want to create an outbound SNet policy. Range: choice, see below
The sourceIp element is a choice element. The first part of the sourceIp element has
the following values:
• network. Select this value if you want to create a pol-
icy for the traffic coming from a specific network. In
the second part of the sourceIp element, specify the
address of that network.
The network structure contains the following ele-
ments:
- address. Use this element to specify the IP Default:0.0.0.0
address of the network. Range: up to 255.255.255.255
- netmask. Use this element to specify the net- Default:0.0.0.0
mask of the network. Range: up to 255.255.255.255
• custom. Select this value if you want to create a

policy for the traffic coming from a specific
(range of) IP address(es). In the second part of
the sourceIp element, specify the IP address
(range).
The custom structure contains the following ele-
ments:
- startAddress. Use this element to specify the start Default:0.0.0.0
of the source IP address range. Range: up to 255.255.255.255
- endAddress. Use this element to specify the end Default:<opt>
Note that you can specify one single source IP
address by filling in the startAddress element and leaving the endAddress ele-
ment at its default value (<opt>).
Note that if you leave the sourceIp element at its default value (<opt>), then no
source IP address(es) is/are specified.
Element Description
destIp Use this element to specify the destination IP Default:<opt>

address(es) for which you want to create an outbound Range: choice, see below
SNet policy.
The destIp element is a choice element. The first part of the destIp element has the
following values:
icy for the traffic destined for a specific network. In
the second part of the destIp element, specify the
ments:

policy for the traffic destined for a specific
the destIp element, specify the IP address
(range).
ments:
of the destination IP address range. Range: up to 255.255.255.255
Note that you can specify one single destina-
tion IP address by filling in the startAddress element and leaving the endAddress
element at its default value (<opt>).
Note that if you leave the destIp element at its default value (<opt>), then no
destination IP address(es) is/are specified.
Element Description
application Use this element to specify the application for which Default:<opt>
you want to create an outbound SNet policy. Range: choice, see below
The application element is a choice element. Currently, the first part of the application
element is always custom. The custom structure contains the following elements:
• protocol. Use this element to specify the protocol. Default:any
The protocol element has the following values: any, Range: enumerated, see below
icmp, tcp, udp, ah, esp.
Note that if you leave the protocol element at its default value (any), then no pro-
tocol is specified.
• startPort. Use this element to specify the start of the Default:0 (any)
port range. Specify the port by typing the port Range: 0 … 65535
number. For ease of use, some common port num-
bers can be selected from a drop-down box.
Note that if you leave the port element at its default value (any), then no port is
specified.
• endPort. Use this element to specify the end of the Default:<opt>
Note that you can specify one single port by filling in the startPort element and
leaving the endPort element at its default value (<opt>).
Note that if you leave the application element at its default value (<opt>), then
no application is specified.
action Use this element to determine whether the outbound Default:allow

SNet policy allows or denies traffic. Range: allow / deny
• allow. Packets that fall within the specification of the policy are passed on.
• deny. Packets that fall within the specification of the policy are dropped.
Element Description
nat Use this element to determine whether address trans- Default:<opt>

lation has to be done for the outbound SNet policy Range: choice, see below
and, if so, which translation address has to be taken.
The nat element is a choice element. The first part of the nat element has the fol-
lowing values:
• ipAddress. Select this value if you want to specify a Default:0.0.0.0
fixed IP address for the address translation. In the Range: up to 255.255.255.255
second part of the nat element, specify the IP
address.
• interface. Select this value if you want to that the IP Default:<empty>

address that is used for the address translation is Range: 0 … 24 characters
taken from another interface. In the second part of
the nat element, specify the name of the interface.
Note that if you leave the nat element at its default value (<opt>), then no
address translation is done.
Important remark
log Use this element to determine whether limited (disa- Default:disabled

bled) or extended (enabled) logging is done for this pol- Range: enabled / disabled
icy.
name Use this element to assign a name (description) to the Default:<empty>

outbound SNet policy. By doing so, you can easily Range: 0 … 24 characters
identify the policy when it is listed in status and per-
formance tables.
inboundPolicies Default:<empty>
Use this attribute to define inbound SNet policies. Refer to 9.8.5 - Defining
an inbound SNet policy on page 462 for more information.
The inboundPolicies table contains the following elements:
Element Description
sNet Use this element to specify the name of the destina- Default:<name> corp
tion SNet for which you want to create an inbound Range: choice, see below
SNet policy.
lowing values:
• name. Select this value if the destination SNet is Default:corp
one of the standard SNets. In the second part of Range: corp / dmz
the sNet element, use the drop-down box to select
one of the standard SNets:
- corp. The destination SNet is “corporate”. If you select
this value, then you create a policy for the traffic from
any SNet except the self SNet to the corporate SNet.
- dmz. The destination SNet is “DMZ”. If you select this
value, then you create a policy for the traffic from any
SNet except the self SNet to the DMZ SNet.

Note that you only have to set the destination SNet. The source SNet is
always any SNet except the self SNet.
Element Description

for which you want to create an inbound SNet policy. Range: choice, see below
ments:

(range).
ments:
Element Description

address(es) for which you want to create an inbound Range: choice, see below
SNet policy.
following values:
ments:

(range).
ments:
Element Description
you want to create an inbound SNet policy. Range: choice, see below
tocol is specified.
specified.
action Use this element to determine whether the inbound Default:allow

SNet policy allows or denies traffic. Range: allow / deny
Element Description
nat Use this element to determine whether address trans- Default:<opt>

lation has to be done for the inbound SNet policy and, Range: choice, see below
if so, which translation address has to be taken.
The nat element is a choice element. Currently, the first part of the nat element is
always custom. The custom structure contains the following elements:
• ipAddress. Use this element to specify the IP Default:0.0.0.0
address of the server that will handle the applica- Range: up to 255.255.255.255
tion specified in the policy.
• port. Use this element to specify the new port Default:<opt>
number. Range: 0 … 65535
Note that if you leave the port element at its default
value (<opt>), then no port translation is done.
Note that if you leave the nat element at its default value (<opt>), then no
address translation is done.
Important remark

icy.

inbound SNet policy. By doing so, you can easily iden- Range: 0 … 24 characters
tify the policy when it is listed in status and perform-
ance tables.
outboundSelfPolicies Default:<empty>
Use this attribute to define outbound self policies. Refer to 9.8.6 - Defining
an outbound self policy on page 464 for more information.
The outboundSelfPolicies table contains the following elements:
Element Description
sNet Use this element to specify the name of the destina- Default:<name> corp
tion SNet for which you want to create an outbound Range: choice, see below
self policy.
lowing values:
• name. Select this value if the destination SNet is Default:corp
one of the standard SNets. In the second part of Range: corp / dmz
the sNet element, use the drop-down box to select
one of the standard SNets:
- corp. The destination SNet is “corporate”. If you select
this value, then you create a policy for the traffic from
the device itself (self SNet) to the corporate SNet.
- dmz. The destination SNet is “DMZ”. If you select this
device itself (self SNet) to the DMZ SNet.
- internet. The destination SNet is “internet”. If you select this value, then you
create a policy for the traffic from the device itself (self SNet) to the internet
SNet.

Note that you only have to set the destination SNet. The source SNet is
always the self SNet.
Element Description

for which you want to create an outbound self policy. Range: choice, see below
ments:

(range).
ments:
Element Description

address(es) for which you want to create an outbound Range: choice, see below
self policy.
following values:
ments:

(range).
ments:
Element Description
you want to create an outbound self policy. Range: choice, see below
tocol is specified.
specified.
action Use this element to determine whether the outbound Default:allow

self policy allows or denies traffic. Range: allow / deny

icy.

outbound self policy. By doing so, you can easily iden- Range: 0 … 24 characters
ance tables.
inboundSelfPolicies Default:<empty>
Use this attribute to define inbound self policies. Refer to 9.8.4 - Defining an
outbound SNet policy on page 460 for more information.
The inboundSelfPolicies table contains the following elements:
Element Description
sNet Use this element to specify the name of the source Default:<name> corp
SNet for which you want to create an inbound self pol- Range: choice, see below
icy.
lowing values:
• name. Select this value if the source SNet is one of Default:corp
the standard SNets. In the second part of the sNet Range: corp / dmz
element, use the drop-down box to select one of
the standard SNets:
- corp. The source SNet is “corporate”. If you select this
corporate SNet to the device itself (self SNet).
- dmz. The source SNet is “DMZ”. If you select this value,
then you create a policy for the traffic from the DMZ
SNet to the device itself (self SNet).
- internet. The source SNet is “internet”. If you select this value, then you create
a policy for the traffic from the internet SNet to the device itself (self SNet).

Note that you only have to set the source SNet. The destination SNet is
always the self SNet.
Element Description

for which you want to create an inbound self policy. Range: choice, see below
ments:

(range).
ments:
Element Description

address(es) for which you want to create an inbound Range: choice, see below
self policy.
following values:
ments:

(range).
ments:
Element Description
you want to create an inbound self policy. Range: choice, see below
tocol is specified.
specified.
action Use this element to determine whether the inbound Default:allow

self policy allows or denies traffic. Range: allow / deny

icy.

inbound self policy. By doing so, you can easily iden- Range: 0 … 24 characters
ance tables.
attacks Default:-
Use this attribute to determine, per type of attack, whether the firewall has
to check for this type of attack and neutralise it.
The attacks structure contains the following elements:
Element Description
synFlooding Use this element to enable or disable the detection Default:disabled

and neutralisation of the SYN Flooding attack. Refer Range: enabled / disabled
to What is the SYN Flooding attack? on page 455.
If you set the synFlooding element to enabled, then the firewall filters out forged serv-
ice requests while allowing legitimate requests to pass through.
sourceRouting Use this element to enable or disable the detection Default:disabled

and neutralisation of Source Routing attack. Refer to Range: enabled / disabled
What is the Source Routing attack? on page 455.
If you set the sourceRouting element to enabled, then the firewall filters out all data-
grams with strict or loose source routing option enabled.
winNuke Use this element to enable or disable the detection Default:disabled

and neutralisation of the WinNuke attack. Refer to Range: enabled / disabled
What is the WinNuke attack? on page 455.
If you set the winNuke element to enabled, then the firewall filters out this attack.
ftpBounce Use this element to enable or disable the detection Default:disabled

and neutralisation of the FTP Bounce attack. Refer to Range: enabled / disabled
What is the FTP Bounce attack? on page 455.
If you set the ftpBounce element to enabled, then the firewall checks that the data con-
nection is to the same system as that of the control connection.
ipUnalignedTimeS- Use this element to enable or disable the detection Default:disabled

tamp and neutralisation of the IP Unaligned Timestamp Range: enabled / disabled
attack. Refer to What is the IP Unaligned Timestamp
attack? on page 455.
If you set the ipUnalignedTimeStamp element to enabled, then the firewall checks
whether the IP packets received have the timestamp option set. If so, it checks that
it is aligned on a 32-bit boundary and drops the packet if it is not.
Element Description
mime Use this element to enable or disable the detection Default:-

and neutralisation of the MIME attack. Refer to What Range: structure, see below
is the MIME attack? on page 455.
By configuring the mime structure, you can close the connection if the number of
received MIME headers exceeds the number of MIME headers you configured.
The mime structure contains the following elements:
• flood. Use this element to enable or disable the Default:disabled
detection and neutralisation of the MIME attack. Range: enabled / disabled
• maxHeaderLength. Use this element to determine the Default:8192
maximum length of the MIME header that may be Range: 256 … 65535
included in the HTTP request.
• maxHeaders. Use this element to determine the Default:16
maximum number of MIME headers that may be Range: 12 … 65535
included in the HTTP request.
seqNumPrediction Use this element to enable or disable the detection Default:disabled

and neutralisation of the Sequence Number Predic- Range: enabled / disabled
tion attack. Refer to What is the Sequence Number
Prediction attack? on page 456.
If you set the seqNumPrediction element to enabled, then the firewall manipulates the
initial sequence number with a new sequence number generated by the firewall
making it difficult to guess the sequence number for the attacker.
seqNumOutOf- Use this element to enable or disable the detection Default:disabled

Range and neutralisation of the Sequence Number Out Of Range: enabled / disabled
Range attack. Refer to What is the Sequence Number
Out Of Range attack? on page 456.
If you set the seqNumOutOfRange element to enabled, then the firewall drops the pack-
ets with sequence numbers that are out of range.
icmpErrorMessages Use this element to enable or disable the detection Default:disabled

and neutralisation of the ICMP Error Message attack. Range: enabled / disabled
Refer to What is the ICMP Error Message attack? on
page 456.
If you set the icmpErrorMessages element to enabled, then the firewall drops ICMP
error packets with a destination different from the internet SNet.
log Default:-
Use this attribute to enable or disable logging and to determine what is
logged.
The log structure contains the following elements:
Element Description
mode Use this element to enable or disable logging. Default:enabled

The log information can be checked in the log status Range: enabled / disabled
attribute. Refer to router1424/ip/router/firewall/log on page 974.
attacks Use this element to enable or disable, per type of Default:-

attack, whether it is logged or not. Range: structure, see below
The attacks structure contains the following elements:
• synFlooding. Use this element to enable or disable Default:disabled
the logging of a SYN Flooding attack. Refer to Range: enabled / disabled
What is the SYN Flooding attack? on page 455.
• pingOfDeath. Use this element to enable or disable Default:disabled
the logging of a Ping Of Death attack. Refer to Range: enabled / disabled
What is the Ping Of Death attack? on page 456.
• ipSpoofing. Use this element to enable or disable the Default:disabled
logging of an IP Spoofing attack. Refer to What is Range: enabled / disabled
the IP Spoofing attack? on page 456.
• winNuke. Use this element to enable or disable the Default:disabled
logging of a WinNuke attack. Refer to What is the Range: enabled / disabled
WinNuke attack? on page 455.
• ipOptionAttack. Use this element to enable or disable Default:disabled
the logging of an IP Option attack. Refer to What is Range: enabled / disabled
the IP Option attack? on page 456.
All these attacks are logged with the priority “alert”.
Element Description
general Use this element to enable or disable some general Default:-

loggings. Range: structure, see below
The general structure contains the following elements:
• systemErrorMessages. Use this element to enable or Default:enabled
disable the logging of system error messages. E.g. Range: enabled / disabled
memory allocation problems, module initialisation
problems, resource allocation problems. This is logged with the priority “notice”.
• denyPolicies. Use this element to enable or disable Default:enabled
the logging of deny policies. I.e. a policy of which Range: enabled / disabled
the action is set to “deny”. This is logged with the pri-
ority “alert”.
Note that this is only logged if for this policy, the log element is set to enabled.
• allowPolicies. Use this element to enable or disable Default:disabled
the logging of allow policies. I.e. a policy of which Range: enabled / disabled
the action is set to “allow”. This is logged with the pri-
ority “info”.
• dataInspection. Use this element to enable or disable Default:disabled
the logging of data that is not allowed. E.g. due to Range: enabled / disabled
memory allocation problems, buffer limits, invalid
requests. This is logged with the priority “warning”.
• generalAttacks. Use this element to enable or disable Default:enabled
the general logging of attacks. You can then spec- Range: enabled / disabled
ify per attack whether it is logged or not. Refer to
the attacks element. This is logged with the priority “alert”.
• unavailablePolicies. Use this element to enable or dis- Default:disabled
able the logging of unavailable policies. I.e. when Range: enabled / disabled
no matching policy could be found. This is logged
with the priority “warning”.
• accessStatistics. Use this element to enable or disa- Default:disabled
ble the logging of access statistics. E.g. logs about Range: enabled / disabled
connection termination, closing, time-out, trans-
ferred bytes. This is logged with the priority “info”.
• verbose. Use this element to enable or disable the Default:disabled
logging of ICMP messages, DNS requests and Range: enabled / disabled
replies. This is logged with the priority “info”.
Element Description
thresholds Use this element to set the threshold to trigger the log- Default:-
ging. The threshold is set per log entry type, except for Range: structure, see below
denyPolicies and allowPolicies. In that case the threshold
is set per policy.
Logging thresholds are provided so that the logging system does not get flooded
with a huge number of duplicate logs in case the firewall or the corporate network
connected to it is under attack.
The thresholds structure contains the following elements:
• attack. Use this element to determine the number of Default:50
attacks that should occur before they are logged. Range: 1 … 300
• general. Use this element to determine the number Default:20
of general events that should occur before they are Range: 1 … 300
logged.
tableLength Use this element to set the length of the log table. Default:200
Note that changing this value clears the table. Range: 10 … 500
alg Default:-
Use this attribute to enable or disable the ALG, the Application Level Gate-
way.
The alg structure contains following elements:
Element Description
sip If your SIP application is not working as expected, try Default:enabled

disabling the ALG. In this way no modifications are Range: disabled/enabled
done to the SIP internal frame structure, except for
normal NAT/PAT translation.
ike If your IKE negotiation is not working as expected, try Default:enabled

disabling the ALG. In this way no modifications are Range: disabled/enabled
done to the IKE fram, except for normal NAT transla-
tion.
When the ALG is enabled, the source port number of the IKE frame after NAT/PAT
translation remains 500.
When the ALG is disabled, NAT/PAT will handle the IKE frame as any other frame
and replace the source port with a random port number.
tcpAdjustMss Default:0/disabled
Range: 0, 200 ... 2000
Use this attribute to configure the Maximum Segment Size (MSS) for tran-
sient packets that traverse the 1424 SHDSL Router.
When a TCP session is established the MSS value in the setup is adapted to the value configured here,
in order to reduce the maximum size of TCP segments.
What is MSS?
MTU or Maximum Transfer Unit is the maximum number of bytes that one packet can contain. Typical,
for Ethernet, this is 1500 bytes. The maximum amount of actual data that can be transported in such a
data packet is 1460 bytes; this is the Maximum Segment Size or MSS.
Reducing MSS
Reducing the maximum size of TCP segments may prevent the communication from slowing down or
even failing.
For instance, when PPP over Ethernet (PPPoE) is being used in the network, PPPoE truncates the
Ethernet Maximum Transfer Unit (MTU) to 1492 bytes, which could result in loss of communication.
Similarly, when a tunnelling protocol such as GRE, L2TP or IPSEC is being used in the network, frag-
mentation may be required if the MSS is not adjusted, which slows down the communication.
11.9.13 Virtual Routing and Forwarding (VRF) configuration attirbutes
router1424/ip/vrfRouter[ ]

• snmpIndexOffset
• defaultRoute
• routingTable
• sendTtlExceeded
• sendPortUnreachable
• sendAdminUnreachable
• sendHostUnreachable
• alternativeRoutes
• routingProtocol
• ripUpdateInterval
• ripHoldDownTime
• ripv2SecretTable
• dhcpStatic
• dhcpDynamic
• dhcpCheckAddress
• addrPools
• dns
• helperProtocols
• alarmMask
• alarmLevel
• This object is not present in the containment tree by default. If you want to use the feature associated
page 45.
• These attributes have already been described in 11.9.1 - General router configuration attributes on
page 617. Refer to this section for more information.
• For more information on VRF, refer to 7.10 - Configuring Virtual Routing and Forwarding or VRF on
page 254.
This section also describes the configuration attributes of the following object:
router1424/ip/vrfRouter[ ]/ospf

• routerId
• refBandwidth
• keyChains
• importDefault
• importMetrics
• importFilter
These attributes have already been described in 11.9.8 - OSPF configuration attributes on page 704.
Refer to this section for more information.
Finally, this section also describes the configuration attributes of the following object:
router1424/ip/vrfRouter[ ]/routingFilter[ ]

• snmpIndexOffset
• filter
These attributes have already been described in 11.9.10 - Routing filter configuration attributes on
11.10 Bridge configuration attributes
This section discusses the configuration attributes concerned with bridging. First it describes the general
bridging configuration attributes. Then it explains the configuration attributes of the extra features as
there are access listing, user priority mapping, etc…
• 11.10.1 - Bridge group configuration attributes on page 772
• 11.10.3 - VLAN group configuration attributes on page 793
11.10.1 Bridge group configuration attributes
router1424/bridge/bridgeGroup/

• maxCacheSize on page 773
• staticBridgeCache on page 773
• forwardMulticast on page 773
• ip on page 774
• arp on page 774
• bridgeCache on page 775
• bridgeTimeOut on page 776
• spanningTree on page 777
• localAccess on page 779
• macAddress on page 779
• vlanSwitching on page 782
• accessControl on page 784
• vlanLearningMode on page 785
maxCacheSize Default:0, unlimited

Range: 0 ... 10000
Use this attribute to set the maximum allowed number of dynamically
learned MAC addresses in the bridge cache. If set to 0, this means this number is unlimited.
staticBridgeCache Default:<empty>
Use this attribute to set the static bridge cache. This is a fixed mapping
between a MAC address and an interface.
The staticBridgeCache table contains the following elements: interface and macAddress.
If a packet with the same MAC address is received on another interface, that packet will be dropped.
forwardMulticast Default:0
Range: 0, 1, 2
Use this attribute to define the multicast forwarding behavior.
The forwardMulticast attribute has the following values:
Value Description
0 or noSpan- Spanning tree packets (mac address 01:80:c2:00:00:00) are not forwarded, all
ningTree. other multicast addresses are flooded to all other members of the bridgegroup.
1 or all. All multicast packets are forwarded to all other members of the bridgegroup.
2 or noLinkCon- Packets with a destination address in the range 01:80:c2:00:00:00 –

strainedProtos. 01:80:c2:00:ff:ff are not forwarded.
name Default:bridge
Use this attribute to assign an administrative name to the bridge.
This attribute is only present on the default bridge group (bridgeGroup), not on the user instantiatable
bridge groups (vpnBridgeGroup[ ]). The user instantiatable bridge groups their name is the index name that
you have to specify when you add the bridge group object to the containment tree (refer to 8.2.3 - Adding
a bridge group on page 314).
ip Default:<empty>
Use this attribute to configure the IP related parameters of the bridge.
Refer to …
Important remark
address in the bridgeGroup object instead: ip.
arp Default:-
Use this attribute to configure the Address Resolution Protocol (ARP) cache
of the bridge.
Refer to arp on page 512 for a detailed description of the arp structure.
bridgeCache Default:learning
Use this attribute to determine how the bridge group should act: as a
repeater, a filter or a switch.
The bridgeCache attribute has the following values:
Value Description
disabled The bridge group acts as a

repeater.
All the data which origi-
nates from network 1 will
be let through to network
2. Even if the data is not
destined for that network.
learning The bridge group acts as a filter.

Data coming from network 1, will only be let through by the bridge if this data has
a destination outside network 1 or if it has a broadcast or multicast address. This
means the bridge filters the data and decreases the amount of data traffic on the
separated LAN segments.
switching The bridge group acts as a VLAN switch.

VLANs on network 1 are switched to VLANs on network 2. Use the vlanSwitching
attribute to specify which VLANs you want to switch. Refer to …
What is the bridge cache?
Whereas the ARP cache keeps MAC address - IP address pairs, the bridge cache (also called address
database) keeps MAC address - interface pairs. This allows the bridge to know which device is reacha-
ble through which interface. Refer to bridgeCache on page 980 for an example of such a table.
bridgeTimeOut Default:00000d 00h 05m 00s

Range: 00000d 00h 00m 00s-
Use this attribute to set the ageing time of the bridge cache entries. 24855d 03h 14m 07s
The bridge cache time-out
If devices on the network are (re)moved then the MAC address - interface relation changes (refer to
What is the bridge cache?). Therefore, the bridge cache entries are automatically removed from the
cache after a fixed time-out. This time-out period can be set with the bridgeTimeOut attribute. This in case
no topology change is detected, otherwise the time-out is equal to the value of the bridgeForwardDelay ele-
ment of the spanningTree attribute.
When checking the bridgeCache it may appear that some entries are present for a longer time than is con-
figured with the bridgeTimeOut attribute. This because the entries in the bridgeCache are not monitored con-
tinuously, but once per minute. As a result, some entries may appear to be “overtime”. However, this
should be no more than ± 75 seconds.
spanningTree Default:-
Use this attribute to configure the bridging related parameters.
Whereas the bridging attribute groups the bridging related parameters per interface, the spanningTree
attribute groups the bridging related parameters of the bridge as a whole.
The spanningTree structure contains the following elements:
Element Description
protocol Use this element to select the bridging protocol. Default:none

The protocol element has the following values: Range: enumerated, see below
• none. The 1424 SHDSL Router uses the self-learning principle.

This means that the bridge itself learns which data it has to forward and which
data it has to block. I.e. it builds its own bridging table.
• p802.1D. The 1424 SHDSL Router uses the self-learning principle in conjunction
with the Rappid Spanning Tree protocol.
This is backwards compatible with the old spanning tree protocol. As a result,
existing configurations will automatically change to the Rappid Spanning Tree
protocol.
Refer to 8.1.2 - The self-learning and Transparent Spanning Tree bridge on
page 300 for more information about the Spanning Tree Protocol.
• p802.1D - STP compatibility. Use this value if is absolutely necessary that the old
Spanning Tree protocol is used.
• p802.1Q. The 1424 SHDSL Router uses the Multiple Spanning Tree protocol.
When using Frame Relay or ATM encapsulation on the WAN interface

together with the Spanning Tree protocol, every DLCI or PVC link is consid-
ered as a separate bridge port. Each link is than considered as a special
kind of LAN with only both end points connected.
bridgePriority Use this element to set the priority of the bridge. Default:32768
The bridge its MAC address together with the Range: 0 … 65535
bridgePriority element form a unique bridge identifier. This identifier is used to deter-
mine which bridge becomes the root bridge.
The bridge with the lowest bridgePriority value becomes the root bridge. If two
bridges have the same bridgePriority value, then the bridge with the lowest MAC
address becomes the root bridge.
bridgeMaxAge Use this element to set the time the bridge retains Default:00000d 00h 00m 20s
bridging information before discarding it. Range: 00000d 00h 00m 06s -
00000d 00h 00m 40s
bridgeHelloTime Use this element to set the interval by which the root Default:00000d 00h 00m 02s
bridge sends Configuration BPDUs, also called Hello Range: 00000d 00h 00m 01s -
messages. 00000d 00h 00m 10s
Element Description
bridgeForwardDelay Use this element to set … Default:00000d 00h 00m 15s

• the delay a bridge port applies to move from listen- Range: 00000d 00h 00m 04s -
00000d 00h 00m 30s
ing state to learning state or from learning state to
forwarding state. Refer to 8.1.6 - The Spanning Tree bridge port states on
page 306 for more information on the possible states of a bridge port.
• the time-out (or ageing) for purging MAC addresses from the bridge cache in
case a topology change is detected.
transmitHoldCount Use this element to limit the transmission rate, i.e. the Default:6
rate with which configuration messages are transmit- Range: 1 ... 10
ted.
Spanning tree configuration messages are transmitted if the information they con-
vey changes. This is subject to the maximum transmission rate configured here.
The transmitHoldCount is expressed in seconds, and can vary between 1 and 10 sec-
onds, with a default of 6.
Although transmitHoldCount is configured here in the bridge group, it is actually

the maximum tranmission rate for each bridging interface.
mstConfigId Use this element to configure the Multiple Spanning Default:-

Tree Configuration Identifier. The mstConfigId structure Range: structure, see below
• name. This is the configuration name of the MST Default:<empty>
identifier. Range: 1 … 32 characters
• revisionLevel. This is an integer, unique within this Default:0

MST domain. Range: 0 ... 65535
Appropriate use of the name and revisionLevel portions of the identifier can remove
the possibility of an accidental match between MST Configuration Identifiers that
are derived from different configurations within a single administrative domain.
maxHops Use this element to set the maximum number of hops Default:20
that the MSTconfiguration information may traverse Range: 6 ... 40
before being discarded.
The use of a separate hop count, on top of the age of stored configuration infor-
mation, provides superior reconfiguration performance.
For more information about the elements messageAge, maxAge, and bridgeTimes, refer
to the spanningTree status attribute in 12.10.1 - Bridge group status attributes on
page 977.
localAccess Default:permitted
Use this attribute to allow or deny access to the bridge group itself.
The localAccess attribute has the following values:
Value Description
permitted Bridged packets can be delivered to the bridge group itself.
restricted No bridged packets can be delivered to the bridge group itself. This adds some
security, because the 1424 SHDSL Router can not be accessed through the bridge
group.
You could for instance create one bridge group specifically for …
• management purposes. In this bridge group, set the localAccess attribute to peri-
mitted.
• the actual data coming from the customers. In this bridge group, set the localAc-
cess attribute to restricted. In this way, the customer can never access the 1424
SHDSL Router itself.
macAddress Default:<deviceMac> lan

Range: choice, see below
Use this attribute to determine whether a fixed, a random or a user defined
MAC address is associated with the bridge group.
The macAddress attribute has the following values:
Value Description
deviceMac A MAC address from the 1424 SHDSL Router itself is associated with the bridge
group.
Use the second part of the macAddress attribute to define which MAC address has
to be selected:
• lan. The LAN interface its MAC address is associated with the bridge group.
• random. The 1424 SHDSL Router generates a random MAC address and this is
associated with the bridge group.
userMac A user defined MAC address is associated with the bridge group.
Use the second part of the macAddress attribute to enter the MAC address.
Use this attribute to set up (a) VLAN(s) on the bridge group in case you want
to manage the 1424 SHDSL Router over (a) VLAN(s).
Although the 1424 SHDSL Router bridges VLAN tagged frames when connected to a VLAN aware
switch, the 1424 SHDSL Router itself can only be managed via IP if a VLAN is configured on the bridge
group. In other words, if you want that the data carried by a VLAN can be delivered to the protocol stack
of the 1424 SHDSL Router (e.g. so that it can be routed), then you have to configure the VLAN on the
bridge group.
The table contains the following elements:
Element Description

the VLAN. Range: 0 … 24 characters

the VLAN. Range: up / down

ters of the VLAN. Range: structure, see below
Refer to …
ing IP addresses.
structure.
vlan Use this element to configure the specific VLAN Default:-

Refer to vlan/vlan on page 780 for a detailed description of the vlan structure.
vlan/vlan Default:-
Use this structure to configure the specific VLAN related parameters of a
VLAN.
Element Description
vid Use this element to set the VLAN ID. Default:1

Range: 1 … 4095
txCos Use this element to set the default user priority Default:0
(802.1P, also called COS) of the transmitted VLAN Range: 0 … 7
frames.
changeTos Use this element to enable or disable the COS to TOS Default:disabled
mapping. Range: enabled / disabled
Note that the TOS to COS mapping is always enabled, irrespective with the
setting of the changeTos attribute.
cosTosMap Use this element to determine how the VLAN user pri- Default:-
ority (COS) maps onto the IP TOS byte value. Range: structure, see below
The cosTosMap structure contains the following elements:
• p0 … p7. Use these elements to define which VLAN Default:0
user priority (0 up to 7) maps onto which IP TOS Range: 0 … 7
byte value (0 up to 255).
Element Description
tosCosMap Use this element to determine how the IP TOS byte Default:-
value maps onto the VLAN user priority (COS). Range: table, see below
The tosCosMap table contains the following elements:
• startTos and endTos. Use these elements to set the Default:0
TOS byte value range that has to be mapped. Range: 0 … 255
• cos. Use this element to set the VLAN user priority Default:0
(COS) value on which the specified TOS byte Range: 0 … 7
value range has to be mapped.
arp Use this element to configure the Address Resolution Default:-

Protocol (ARP) cache. Range: structure, see below
Refer to arp on page 512 for more information.
vlanSwitching Default:<empty>
Use this attribute specify which VLANs you want to switch in case the bridge
group is used as a VLAN switch. Note that you have to enable VLAN switching on the bridge group by
setting the bridgeCache attribute to switching. Refer to …
The vlanSwitching attribute contains the following elements:
Element Description
sourceIntf Use this element to enter the name of the (physical) Default:<empty>
source interface which carries the VLAN that has to Range: 0 … 24 characters
be switched.
sourceVlan Use this element to enter the VLAN ID of the VLAN Default:1
that has to be switched. Range: 0 … 4094
Stripping the VLAN tag
Entering 0 as VLAN ID strips the VLAN tag of the Ethernet frame.

Example: suppose you enter 1 as srcVlan and 0 as dstVlan. So VLAN 1 is switched
from the source interface to the destination interface. But before it is sent out on
the destination interface, the VLAN tag is stripped. So instead of VLAN tagged
Ethernet frames, plain Ethernet frames are sent out. In the opposite direction how-
ever, the VLAN tag is added again.
sourcePFilter Use this element to apply a filter on the priority bits of Default:<OPT>
the source VLAN packets. Selecting value -1 leaves Range: -1 ... 7
the sourcePFilter element as optional, so no filtering is
done.
sourcePMap Use this element to, if desired, remap the VLAN prior- Default:-
ities. The priorities defined in the sourcePMap are Range: structure, see below
applied when the VLAN is switched from sourceVlan to
destinationVlan.
The structure contains the elements p0 up to p7, which represent priority
0 up to priority 7. If you want to remap priorities, then enter the new priority
value under one of these priority elements.
Example: suppose you want to remap priority 5 to priority 7, then enter 7
as value of the p5 element.
destinationIntf Use this element to enter the name of the (physical) Default:<empty>
destination interface which carries the VLAN when it Range: 0 … 24 characters
has been switched.
The destination interface can also be a bridge group, in that case just enter the
name of the bridge group.
Element Description
destinationVlan Use this element to enter the VLAN ID of the VLAN Default:1
when it has been switched. Range: 0 … 4094
Entering 0 as VLAN ID strips the VLAN tag of the Ethernet frame. Refer to Strip-
ping the VLAN tag for more information.
destinationPFilter Use this element to apply a filter on the priority bits of Default:<OPT>
the destination VLAN packets. Selecting value -1 Range: -1 ... 7
leaves the destinationPFilter element as optional, so no
filtering is done.
destinationPMap Use this element to, if desired, remap the VLAN prior- Default:-
ities. The priorities defined in the destinationPMap are Range: structure, see below
applied when the VLAN is switched from destinationVlan
to sourceVlan.
Refer to the sourcePMap element for more information on this structure.
tunnel Enabling this element inserts an extra VLAN tag, the Default:disabled
IEEE 802.1Q-in-Q VLAN Tag, to the tagged packets; Range: enabled/disabled
this results in double-tagged frames.
This allows for extra services on specific VLANs. QinQ was originally designed to
expand the number of VLANs by adding a tag to an 802.1Q tagged packet. With
this extra tag, the number of VLANs is increased to 4K×4K.
Note that, when this element is set to enabled:
• the setting of the sourcePMap element is applied to the outer VLAN header.
• the setting of the destinationPMap element is ignored.
bidirectional Use this element to set in which direction the switch- Default:yes
ing will take place. Possible values are: Range: no / yes
• yes. The switching happens in both directions, i.e. from source to destination
and vice versa.
• no. The switching happens from source to destination.
accessControl Default:-
Use this attribute to control the incoming datapackets that are delivered to
the bridge group.
The accessControl structure contains following elements:
Element Description
inAccessList Use this element to apply an inbound access list on Default:<empty>

the bridge group. Range: 0 … 24 characters
Do this by entering the index name of the access list you want to use. You can cre-
ate the access list itself by adding an accessList object under the bridge object and
by configuring the attributes in this object.
Example
If you created an accessList object with index name my_access_list

(i.e. accessList[my_access_list]) and you want to apply this access list
here, then enter the index name as value for the inAccessList ele-
ment.
Refer to …
• 8.5 - Bridge traffic classification by filtering on page 344 for an introduction on
access lists.
• 11.10.2 - Bridge access list configuration attributes on page 786 for more infor-
mation on bridge access lists.
limitBroadcasts Use this element to limit the number of broadcasts Default:disabled

getting through to the bridge group. Range: enabled/disabled
Normally, if data has a broadcast address, it will be let through by the bridge. This
can be limited by enabling the limitBroadcasts element.
vlanLearningMode Default:shared
Use this attribute to set how learned MAC addresses are treated; this
attribute allows for VLAN aware bridge caching.
The vlanLearningMode attribute has the following values:
Value Description
shared This value means that the bridge cache (i.e. the learned MAC addresses) is shared
between all VLAN ‘s.
This means that the filterid element in the bridgeCache status attribute of the VLAN
group is 0; refer to 12.10.3 - VLAN group status attributes on page 988 for more
information.
independent This value means that the bridge cache (i.e. the learned MAC addresses) is not
shared over all VLAN ‘s; each VLAN individually keeps track of its bridge cache.
group is equal to the VLAN ID; refer to 12.10.3 - VLAN group status attributes on
grouped This value means that each VLAN group has its own bridge cache, i.e. the learned
MAC addresses within one VLAN group are shared among the members of that
VLAN group. Refer to 8.3 - Configuring VLANs on page 325 for more information
about VLAN groups.
group is as configured in the VLAN group; refer to 12.10.3 - VLAN group status
attributes on page 988 and 11.10.3 - VLAN group configuration attributes on

11.10.2 Bridge access list configuration attributes
router1424/bridge/accessList[ ]/

• advancedFilter on page 788
page 45.
macAddress Default:<empty>
Use this attribute to filter bridged frames based on the source MAC address.
This is an outbound access list. Packets coming from MAC addresses that are specified in the access
list are not sent out on the interface on which the access list is applied.
To apply the access list on a bridge interface, type the index name of the accessList[ ] object as value of
the accessList element in the bridging structure.
Example
If you created an accessList object with index name my_access_list (i.e. access-
List[my_access_list]) and you want to apply this access list on a bridge interface, then
enter the index name as value for the accessList element in the bridging structure.
Range: 0 ... 65535
advancedFilter Default:<empty>
Use this attribute to create (an) advanced filter(s) in order to filter bridged
frames, taking into account source and destination MAC address ranges, the layer 3 protocol field, the
number of TCP SYN packets per minute and VLAN tag and priority bits.
Important remarks
• The advanced filters specified here can be applied in inbound and outbound direction.
• The advanced filters always have priority above the filters defined using the macAddress attribute, refer
to macAddress on page 787, i.e. the advanced filters will overrule the filters defined using the macAddress
attribute.
The advancedFilter table contains following elements:
Element Description
name Use this element to set a name for the advanced filter. Default:<empty>
sourceMacStart Use this element to set the start address of the source Default:<OPT>
MAC address range that will be filtered. Range: up to ff:ff:ff:ff:ff:ff
When you want to filter just one MAC address, fill it in here.
When you only fill in this field and leave the sourceMacEnd element blank, then all
addresses, starting with this one, up to ff:ff:ff:ff:ff:ff will be filtered.
sourceMacEnd Use this element to set the end address of the source Default:<OPT>
MAC address range that will be filtered. Range: up to ff:ff:ff:ff:ff:ff
When you only fill in this field and leave the sourceMacStart element blank, then all
addresses starting from 0:0:0:0:0:0 up to this address, will be filtered.
destinationMacStart Use this element to set the start address of the desti- Default:<OPT>
nation MAC address range that will be filtered. Range: up to ff:ff:ff:ff:ff:ff
When you want to filter just one MAC address, fill it in here.
When you only fill in this field and leave the destinationMacEnd element blank, then
all addresses, starting with this one, up to ff:ff:ff:ff:ff:ff will be filtered.
destinationMacEnd Use this element to set the end address of the desti- Default:<OPT>
nation MAC address range that will be filtered. Range: up to ff:ff:ff:ff:ff:ff
When you only fill in this field and leave the destiantionMacStart element blank, then
all addresses starting from 0:0:0:0:0:0 up to this address, will be filtered.
vlan Use this element to filter out specific VLAN ‘s. Default:<OPT>,4097
Any value between 0 and 4098 can be filled in here. Range: choice, see below
There are however a few special cases:
• 0 = priorityTagged. This filters out VLAN ‘s with VLAN tag equal to 0.
• 4096 = untagged. This filters out VLAN ‘s with no VLAN header.
• 4097= any (<OPT>). This leaves the vlan element as optional, so no filtering is
done.
• 4098 = anyVlan. This filters out VLAN ‘s with a VLAN header.
Element Description
priority Use this element to filter bridged frames based on the Default:<OPT>,8
priority bits in the VLAN header. Possible values are Range: 0 ... 8
between 0 and 7; filling in 8 leaves the priority element
as optional (<OPT>), so no filtering is done.
protocol Use this element to filter bridged frames based on the Default:<OPT>,65536
used protocol. Possible values are: any, ip, arp, rarp, Range: choice, see below
vlanTagged, ipv6, mplsUnicast, mplsMulticast, llcsnap.
action Use this element to set the action that has to be exe- Default:deny, 0
cuted on the filtered frames. Possible actions are: Range: 0,1,2
• deny (or 0). Packets matching this line are dropped.
• permit (or 1). Packets matching this line are passed to the advanced action (if
present) or permitted (refer to advancedFilter/advanced on page 790 for more infor-
mation about the advanced action). No further lines are checked.
• continue (or 2). Packets matching this line are passed to the advanced action (if
present) and processing of the ACL continues (refer to advancedFilter/advanced on
page 790 for more information about the advanced action).
advanced Use this element to set the advanced features of the Default:none
advancedFilter attribute. Refer to advancedFilter/advanced Range: structure, see below
on page 790 for a detailed description of the advanced
element.
advancedFilter/advanced
Use this element to set the advanced features of the advancedFilter attribute.
The advanced element contains following elements:
Element Description
none No advanced features are used in the filter.
limitTcpSyn Use this element to limit the number of TCP SYN packets. The limitTcpSyn structure
contains following elements:
• mode. Use this element to set the way how the Default:perMac
number of TCP SYN packets are limited. Possible Range: global/perMac
values are:
- global. The total number of TCP SYN packets is taken into account.
- perMac. The number of TCP SYN packets per MAC address is taken into
account.
• rate(SynPerMinute). Use this element to set the Default:5
number of TCP SYN packets that are allowed per Range: 0 ... 2147483647
minute.
jumpOver Use this element to set the number of lines that have Default:1
to be skipped when jumping to the next filter, i.e. the Range: 1 ... 100
number of filters that have to be skipped.
The jumpOver action is only useful when the continue action has been chosen in the
advancedFilter on page 788 attribute, described above.
jumpTo Use this element to enter the name of the advanced Default:<empty>
filter to jump to. A name filled in here, must match a Range: 0 ... 24 characters
name entered in the name element of the advancedFilter
element, refer to advancedFilter on page 788.
The jumpTo action is only useful when the continue action has been chosen in the
advancedFilter on page 788 attribute, describe above.
mark
This element only applies to outbound access lists.
Use this element to color bridged packets, i.e. make certain changes to the bridged
packets; refer to advancedFilter/advanced/mark on page 791.
iptrafficPolicy Use this element to apply an IP traffic policy, by filling Default:<empty>

in the name of an IP traffic policy here. Range: 0 ... 24 characters
advancedFilter/advanced/mark
This element only applies to outbound access lists.
Use this element to color bridged packets, i.e. make certain changes to the bridged packets.
The mark element contains following elements:
Element Description
setQueue Use this element to set a destination queue for the filtered packets.
The setQueue structure contains following elements:
• queue. Use this element to assign the data packets Default:queue1
to a certain queue. Possible values are: queue1, Range: enumerated, see below
queue2, queue3, queue4, queue5, lowDelayQueue.
• dropLevel. Use this element to define how many Default:100
packets may be queued before they are dropped. Range: 0 ... 1000
Selecting 0 (or dropOnQueue) means that packets
may not be dropped.
setTosAndCos Use this element to set the TOS and COS value of the filtered packets.
• tos. Use this elements to set the TOS byte value. Default:0
Enter 256 to leave the TOS value unchanged. Range: 0 ... 256
• cos. Use this element to set the default user priority Default:0
value(COS). Enter 8 to leave the COS value Range: 0 ... 8
unchanged.

may not be dropped.
Element Description
mapTosToCos Use this element to determine how the IP TOS byte value maps onto the VLAN
user priority (COS). The mapTosToCos table contains following elements:
• startTos. Use this element to set the start of the TOS Default:0
byte value range that has to be mapped. Enter 256 Range: 0 ... 256
for nonIP data.
• endTos. Use this element to set the end of the TOS Default:255
byte value range that has to be mapped. Enter 256 Range: 0 ... 256
for nonIP data.
• cos. Use this element to set the VLAN user prior- Default:0
ity(COS) value on which the specified TOS byte- Range: 0 ... 8
value range has to be mapped. Enter 8 to leave the
COS value unchanged.
may not be dropped.
11.10.3 VLAN group configuration attributes
router1424/bridge/bridgeGroup/vlanGroup[ ]

• filteringId on page 794
• vlanMembers on page 794
• importBridgePorts on page 795
• mst on page 795
page 45.
filteringId Default:1
Range: 1 ... 4094
Use this attribute to set a unique identifier for the VLAN group.
vlanMembers Default:<empty>
Use this attribute to add VLAN ‘s to the VLAN group by means of their VLAN
ID. VLAN ‘s can be added individually, or by entering a range.
The vlanMembers attribute has the following values:
Value Description
single Use this element to add a single VLAN. Default:1

Range: 1 ... 4095
range Use this element to add a range of VLAN ID’s, by set- Default:none
ting the from and to elements. Range: structure, see below
In both elements, a range of 1 up to 4095 can be set.
importBridgePorts Default:disabled
Use this attribute to automatically import all bridging interfaces, which are
members of this bridge group, into the VLAN group. Do this by setting this attribute to enabled.
ports Default:<empty>
Use this attribute to:
• manually add interfaces to the VLAN group, or:
• to overrule the configuration values of the interfaces, which have been imported using the importBridge-
Ports attribute, for this VLAN group.
The ports table has the following elements:
Value Description
name This is the name of the interface. Default:<empty>

priority This is the priority of the interface. Default:128

Range: 0 ... 255
internalPathCost This is the cost to traverse the interface. Default:500

Range: 1 ... 200000000
mst Default:32768
Range: 0 ... 61440
Use this attribute to set the priority of the VLAN group for Multiple Spanning
Tree or MST.
Range: 0 ... 65535
11.11 SNMP configuration attributes
router1424/snmp

• trapDestinations on page 797
• mib2Traps on page 798
trapDestinations Default:<empty>
Use this attribute to define to which IP address the SNMP traps have to be
sent.
The 1424 SHDSL Router translates all alarm status changes into SNMP traps. These traps can then be
sent to a management system. To enable this, configure in the trapDestinations table the IP addresses to
which the traps have to be sent. If the trapDestinations table is empty then no traps are sent.
The trapDestinations table contains the following elements:
Element Description
sourceIp Use this element to set the IP address that will be the Default:<opt>
source of the SNMP traps. Range: up to 255.255.255.255
When this element is not filled in, the default value will
be used, which is the IP address of the LAN interface.
address Use this element to set the IP address of the manage- Default:0.0.0.0
ment station to which the SNMP trap messages have Range: up to 255.255.255.255
to be sent.
community Use this element to set the community string which is Default:public
included in the SNMP traps that are sent to the man- Range: 0 … 20 characters
agement station. It is used as a password in the
SNMP communication. Give it the same value as on your SNMP management sta-
tion.
type Use this element to set which kind of SNMP trap will Default:v1Trap
be sent. Range: enumerated, see below
• v1Trap. An SNMPv1 trap will be sent.
• v2Inform. An SNMPv2 inform will be sent.
• v3Inform. An SNMPv3 inform will be sent.
Refer to 5.3 - Managing devices using SNMP on page 65 for more information
about the different SNMP versions.
timeOut This element is only relevant for SNMPv2. Default:<opt>, 00000d 00h
Use this element to set the time out period, after which 00m 05s
Range: 00000d 00h 00m 00s-
a trap is sent again.
24855d 03h 14m 07s
retryCount This element is only relevant for SNMPv2. Default:<opt>, 3

Use this element to set the number of times a trap is Range: o ... max
sent again.
Element Description
user This element is only relevant for SNMPv3. Default:<empty>

Because of the extra security in SNMPv3, a username Range: 0 … 20 characters
must always be set here when using SNMPv3.
This username must also be set in the password element of the security attribute,
refer to security on page 505.
mib2Traps Default:off
Range: on / off
Use this attribute to enable (on) or disable (off) the sending of SNMP traps
as MIB2 traps.
If you want to send the SNMP traps as MIB2 traps, proceed as follows:
Step Action
1 Select the snmp/trapDestinations attribute. Add an entry to this table for each network man-
agement station that should receive SNMP traps. Refer to trapDestinations on page 797.
2 Configure the mib2Traps attribute:

• on. The alarms coldBoot, warmBoot and linkDown are sent as MIB2 traps instead of enter-
prise specific (private) MIB traps.
• off. All alarms are sent as enterprise specific (private) MIB traps.
3 Set for each object of the 1424 SHDSL Router:

• the alarms that you want to send using the attribute alarmMask.
• the importance of each alarm using the attribute alarmLevel.
By default only the most important alarms are enabled.

11.12 Management configuration attributes
router1424/management/
router1424/management/loopback
router1424/management/usrLoopback[ ]
The management object contains the following attributes:

• sysLog on page 801
• timeServer on page 803
• timeZone on page 803
• cms2Address on page 804
• accessList on page 805
• snmp on page 806
• telnet on page 806
• tftp on page 806
• ftp on page 806
• accessPolicy on page 806
• consoleNoTrafficTimeOut on page 807
• alarmFilter on page 807
• timedStatsAvailability on page 807
• atwinGraphics on page 808
• accessControl on page 809
• maxPingReplies on page 809
• ctrlPortProtocol on page 810
• alignStatsToRtc on page 810
• logStatsToFile on page 810
• userInfo on page 814
The management/loopback object contains the following attributes:

• ipAddress on page 815
• ipNetMask on page 816
• sNet on page 816
• vrfRouter on page 816
The management/usrLoopback[ ] object must be added manually, and contains the same configuration
attributes as the management/loopback object, except for:
The router1424/management/usrLoopback[ ] object must be added manually. All other attributes under this
object are the same as the ones under the router1424/management/loopback object.
sysLog Default:-
Use this attribute to configure the sending of syslog messages.
The sysLog structure contains the following elements:
Element Description
separator Use this element to specify the separator character in Default:;

the syslog messages. Refer to What is syslog? on Range: 1 character
page 801 for more information on the syslog mes-
ages.
destinations Use this element to enter the IP address(es) of the Default:<empty>

syslog server(s). Up to 3 addresses can be entered. Range: table, see below
As soon a valid syslog server address is entered, a syslog message is sent to this
server for each (unmasked) alarm that occurs. If multiple syslog server addresses
are sent, then the syslog messages are sent to all servers.
The syslog messages are not sent in case the interface or the route through which
they have to be sent is down. In this case, the syslog messages are kept in a his-
tory list (maximum 31 messages). These pending messages are sent as soon as
the interface and/or route comes up again.
What is syslog?
The syslog protocol (RFC 3164) is used for the transmission of event notification messages across net-
works.
A syslog message is sent on UDP port 514. It has the following format:
"<facility*8+severity> date hostname message"
where …
• the priority value is the number contained within the angle brackets, i.e. <facility*8+severity>.
• facility is a part of the priority value: facility = 23 * 8 = 184
In this case no facility has been explicitly assigned and therefore a "local use" facility is used (numer-
ical code value 23).
• severity is a part of the priority value: severity = 6 - <alarmLevel of the alarm>
The severity only ranges from 0 up to 6. So in case the alarm level of an alarm is bigger than 6, the
severity is limited to 0.
• date is the date the syslog message was generated: Mmm dd hh:mm:ss (e.g. Jan 01 12:45:55).
• hostname is the IP address of the interface through which the syslog message was sent (e.g.
10.0.28.3).
• message is the alarm message. It has the following format:
"alarm:<sysName>;<realTimeClock>;<sysUpTime>;<devSeverityLevel>;<severit-
yLevel>;<alarmMessage>"
where …
- <sysName> is the sysName configured in the 1424 SHDSL Router.
- <realTimeClock> is the value of the real time clock at the moment the alarm was generated: dd/
mm/yy hh:mm:ss (e.g. 25/12/02 22:45:55).
- <sysUpTime> is the system up-time of the 1424 SHDSL Router at the moment the alarm was gen-
erated: xxxxxd xxh xxm xxs (e.g. 00025d 08h 45m 55s).
- <devSeverityLvl> is the device severity level: devSeverityLvl = 6 - <totalAlarmLevel of

the device>. The device severity level only ranges from 0 up to 6. So in case the total alarm level
of the 1424 SHDSL Router is bigger than 6, the device severity level is limited to 0.
- <severityLvl> is the alarm severity level: severityLvl = 6 - <alarmLevel of the alarm>.
The alarm severity level only ranges from 0 up to 6. So in case the alarm level of an alarm is bigger
than 6, the alarm severity level is limited to 0.
- <alarmMessage> is the alarm itself: path.alarmName on|off (e.g. router1424/lanInter-
face.linkDown on).
- ; is the separator character. If desired, you can specify another separator character. Refer to the
configuration element separator on page 801.
Example:
The following gives an example of a complete syslog message. In this case, the separator is the ^ char-
acter.
"<189>Feb 28 16:56:15 10.0.28.2 alarm:router1424^28/02/03 16:56:15^130^3^5^
router1424.configChanged on"
Note that, when the 1424 SHDSL Router has been switched off for more than 15 days, the <realTime-
Clock> is not stable anymore.
timeServer Default:0.0.0.0
Range: up to 255.255.255.255
Use this attribute to enter the IP address of the SNTP time server with which
the 1424 SHDSL Router can synchronise its clock. Date and time are displayed in the status attributes
router1424/date and router1424/time.
You can also set the time zone and the daylight saving time using the configuration attribute timeZone on
page 803.
What is SNTP?
Short for Simple Network Time Protocol, a simplified version of NTP. SNTP is used when the ultimate
performance of the full NTP implementation described in RFC 1305 is not needed or justified.
The 1424 SHDSL Router can only act as an SNTP client, not as an SNTP server.
timeZone Default:-
Use this attribute to set the time zone when using an SNTP time server.
Refer to timeServer on page 803.
The timeZone structure contains the following elements:
Element Description
timeZone Use this element to set the time zone. Default:utc+1

The timeZone element has the following values: utc, Range: enumerated, see below
utc+1 up to utc+12 and utc-1 up to utc-12.
What is UTC?
UTC is the coordinated universal time, formerly known as Greenwich mean time
(GMT). It is the international time standard.
daylightSaving Use this element to set the daylight saving time. Default:europeanUnion
The daylightSaving element has the following values: Range: europeanUnion / none
europeanUnion and none.
cms2Address Default:0
Range: 0 … 65535
Use this attribute to assign an absolute address to the 1424 SHDSL Router.
What is relative and absolute addressing?
If you want to connect with TMA to a OneAccess device, you have to specify the address of the device
in the Connect… window. Refer to 4 - Maintaining the 1424 SHDSL Router on page 31.
There are two different address types: relative and absolute. The following table explains the difference
between these address types:
Type Description
relative This type of addressing is meant for a network topology where the OneAccess
devices are connected in-line on management level. I.e. with extended manage-
ment connections between two OneAccess devices. An extended management
connection is realised with a crossed cable between the control connectors of two
OneAccess devices.
To enable relative addressing, no address has to be specified in the OneAccess

device. In other words, leave the cms2Address attribute at its default value, being 0.
absolute This type of addressing is meant for a network topology where the OneAccess
devices are not connected in-line on management level. I.e. when there is a digital
multipoint device present (e.g. an Orchid DM).
To enable absolute addressing, an address has to be specified in the OneAccess

device. Do this using the cms2Address attribute. The absolute addressing range
goes from 1 up to 65535.
accessList Default:<empty>
Use this attribute to set up an inbound simple access list on the protocol
stack. Refer to 9.2 - Configuring the access restrictions on page 370 for more information on inbound
access lists.
The access list filters incoming traffic, based on the source IP address. You can specify multiple entries
within the access list. When more than one entry applies to the same packet, then only the most specific
one is taken in consideration. I.e. the entry covering the smallest range. If not one entry matches, then
the packet is dropped. If the access list is empty, then all packets are forwarded.
The accessList table contains the following elements:
Element Description
sourceAddress Use this element to set the IP source address of the Default:0.0.0.0
packet. The address may be a (sub)network address. Range: up to 255.255.255.255
mask Use this element to set the IP subnet mask for the Default:255.255.255.255
sourceAddress. By combining an IP address with a Range: up to 255.255.255.255
mask you can uniquely identify a range of addresses.
action Use this element to set the action when a packet Default:deny
arrives with a source IP address that falls within the Range: enumerated, see below
specified address range.
The possible actions are:
• deny. The packet is dropped.
• allow. The packet is forwarded.
If you specify one entry or multiple entries for which the action is set to deny, then also specify at least
one entry for which the action is set to allow. Else all packets are dropped!
Example 1
This example shows an access list that only allows

traffic from subnet 192.168.48.0, except for packets
from station 192.168.48.10.
Example 2
The next example shows an access list that allows all

traffic, except the traffic from subnet 192.168.48.0.
The second entry is the rule to add if you want all pack-
ets that do not match the previous entries to be
allowed.
accessPolicy Default:<empty>
Use this attribute to apply an inbound extended access list on the protocol
stack.
Do this by entering the index name of the traffic policy you want to apply. You can create the traffic policy
itself by adding a trafficPolicy object and by configuring the attributes in this object.
Important remark
It is possible that the 1424 SHDSL Router has to answer to DHCP requests or terminate L2TP and IPSec
tunnels. In that case, if you set up an access list on the protocol stack, then make sure that these proto-
cols are allowed access to the protocol stack.
Refer to 9.2 - Configuring the access restrictions on page 370 for more information on inbound access
lists.
Example
If you created a trafficPolicy object with index name my_traffic_policy (i.e.

trafficPolicy[my_traffic_policy]) and you want to apply this traffic policy here, then enter the
index name as value for the trafficPolicy element.
snmp Default:enabled
Use this attribute to accept (enabled) or discard (disabled) SNMP requests.
telnet Default:enabled
Use this attribute to accept (enabled) or discard (disabled) Telnet sessions.
Use this attribute also to accept (enabled) or discard (disabled) HTTP (Web Interface) sessions.
tftp Default:enabled
Use this attribute to accept (enabled) or discard (disabled) TFTP sessions.
ftp Default:enabled
Use this attribute to accept (enabled) or discard (disabled) FTP sessions.
consoleNoTrafficTimeOut Default:00000d 00h 30m 00s

Range: 00000d 00h 00m 00s -
Use this attribute to set the time-out period after which a management ses- 24855d 03h 14m 07s
sion is closed when there is no user interaction. The purpose of such a timer
is to protect the 1424 SHDSL Router against unauthorised access in case the last user did not close his
session.
This timer applies on …
• terminal (emulation) sessions (through the control port).
• Telnet and HTTP sessions (over IP).
It does not apply on TMA or TMA CLI sessions (nor through the control port, nor over IP). They have a
fixed time-out of 15 minutes.
alarmFilter Default:0
Range: 0 … 50000
Use this attribute to selectively ignore / drop alarms in TMA for HP Open-
View if these alarms are below a certain level.
The filter number that you define using the alarmFilter attribute, has to correspond with a filter that you
have to define in the Alarm Manager of TMA for HP OpenView. In the Alarm Manager, it is possible to
specify a minimum alarm level that is needed before alarms are logged in HP OpenView. This can be
specified for each filter number.
timedStatsAvailability Default:basic
Use this attribute to determine whether the nested tables in the timed per-
formance statistics (i.e. 2 hour, 24 hour and 7 days performance statistics) are visible or not.
The timedStatsAvailability attribute has the following values:
Value Description
none Only the “first level” timed performance statistics are available. In other words, the
nested tables (i.e. a table in a table) in the timed performance statistics are not dis-
played.
basic The full performance statistics are available on the physical interfaces only (e.g.
the LAN interface, etc.). Not on the logical interfaces (e.g. a PVC, a VLAN, etc.).
full The full performance statistics are available on both the physical (e.g. the LAN
interface, etc.) and logical (e.g. a PVC, a VLAN, etc.) interfaces
If you have a lot of PVCs this may require quite some memory space and
processing power.
atwinGraphics Default:enabled
Use this attribute to enable or disable the graphical symbols in the ATWIN
user interface.
One of the tools that allows you to manage the 1424 SHDSL Router is ATWIN (refer to 1.4 - Maintenance
and management tools on page 8). ATWIN is a basic, menu-driven user interface. You can start it using
a terminal (emulation program) on the control port or using Telnet on an IP interface (e.g. the LAN inter-
face) and by typing atwin at the command prompt (refer to the Maintenance tools manual (PDF) for
more information).
By default, ATWIN uses graphical symbols to draw the borders of the “windows”. In some cases how-
ever, these graphical symbols are displayed incorrectly. In that case you can choose to disable the
graphical symbols. By doing so, the window borders are drawn using + and - signs.
The atwinGraphics attribute has the following values:
Value Description
enabled The ATWIN window borders are drawn using graphical symbols.
disabled The ATWIN window borders are drawn using + and - signs.
accessControl Default:-
Use this attribute to configure the monitoring of management access to the
device.
The loginControl structure contains the following elements:
Element Description
alarm Use this element to determine when the access failure Default:-
alarm should be logged in the accessLog table and a Range: structure, see below
syslog message is sent.
The alarm structure contains the following elements:
• maxFailCnt. Use this element to set the access fail- Default:3
ure alarm threshold. If this value is exceeded Range: 0 … 100
within the access failure alarm period, then the
access failure alarm is raised.
• period. Use this element to set the access failure Default:00000d 00h 15m 00s
alarm period. If within this period the access failure Range: 00000d 00h 00m 00s -
alarm threshold is exceeded, then the access fail- 00001d 00h 00m 00s
ure alarm is raised.
Example
By default, if within a period of 15 minutes 3 access attempts fail, then the access
failure alarm is logged in the accessLog table as follows:
Jul 13 11:00:00 00000d 00h 15m 58s accessFailureOn
If within the consecutive period of 15 minutes no or less than 3 access attempts

fail, then the access failure alarm is cleared in the accessLog table as follows:
Jul 13 11:15:00 00000d 00h 30m 58s accessFailureOff
Also see accessLog on page 997.
maxPingReplies Default:-disabled
Range: disabled/0...65535
Use this attribute to set the number of times the 1424 SHDSL Router will
reply to received pings. When disabled, the 1424 SHDSL Router will always answer to pings.
ctrlPortProtocol Default:console
Use this attribute to set the function of the control connector.
The ctrlPortProtocol attribute has the following values:
Value Description
management Select this value if you want to connect the control connector of the 1424 SHDSL
Router to …
• a management concentrator for management purposes.
• the control connector of another OneAccess device using a crossed cable (i.e.
they are connected back-to-back) in order to create an extended management
link. Refer to What is relative and absolute addressing? on page 804 for more
information on extended management links.
When connecting the control connector of the 1424 SHDSL Router to a COM port
of your computer, you can still open a TMA session on the 1424 SHDSL Router.
You can however not open a CLI or ATWIN session.
console Select this value if you want to connect the control connector of the 1424 SHDSL
Router to a COM port of your computer in order to manage the 1424 SHDSL
Router using TMA, CLI, ATWIN, etc.
alignStatsToRtc Default:disabled
Use this attribute to synchronize the statistics to the real time clock. This
means that:
• for the 7 days statistics, each day interval starts at exactly midnight.
• for the 24 hours statistics, every 2 hour interval starts at exactly an even hour of the day.
• for the 2 hours statistics, each 15 minutes interval starts at exactly an hour or 15, 30 or 45 minutes
after the hour.
These statistics, more specifically h2Performance, h24Performance and d7Performance, are present in many
objects in the containment tree, and described in 13 - Performance attributes on page 1013.
logStatsToFile Default:<empty>
Use this attribute to log statistics to a file that is stored on the file system of
the device, so that they can be retrieved and processed by the user, for instance in a spreadsheet pro-
gram.
The system will clean the file system automatically: day files will be kept on the system for 15 days; week
files will be kept on the system for 5 weeks; month files will be kept on the system for 2 months. This
mechanism will make sure that the file system of the device can never get full.
Refer to 9.10 - Logging of performance statistics on page 479 for more information.
The logStatsToFile table contains the following elements:
Element Description
interval Use this element to set the time interval in which the Default:2h
file will be updated. Possible values are 30 minutes, 1 Range: enumerated, see below
hour, 2 hours or 1 day: 30min, 1h, 2h, 1d.
type Use this element to set the type of data that will actu- Default:-
ally be logged in the file. The type element contains a Range: structure, see below
table structure; refer to logStatsToFile/type/table on page 812
fileType Use this element to set the type of file, with regard to Default:day
time, that is stored: whether dayly statistics, weekly Range: enumerated, see below
statistics or monthly statistics are logged in the file. So
possible values are: day, week or month.
A day file will contain the statistics of one day (starting at 0h and ending at 23.59h).
A week file will contain the data of one week; the week starts on Monday and ends
on Sunday.
A month file will contain the data of exactly one month.
fileName Use this element to set the first part of the name of the Default:<empty>
file that will be stored on the file system of the device. Range: 0 … 10 characters
The second part of the file name depends on the fileType and the date when the file
is logged. For a full description of the fileName, refer to the logStats status attribute in
12.12 - Management status attributes on page 993.
logStatsToFile/type/table Default:-
The table structure contains the following elements:
Element Description
element Use this element to set for which object of the contain- Default:<empty>
ment tree, and for which attribute, the statistics have Range: 0 … 90 characters
to be logged.
Enter the full path of the object, as you would when using CLI; this means:
• the path of the object, including the attribute itself,
• followed by the group that the attribute belongs to.
In the example below, looking at the first line of the table:
• the h24Line table of the WAN line interface is retrieved: wanInterface/line/h24Line.
• this is followed by :Performance since the h24Line table belongs to the Performance
group.
So the full path that must be entered is: wanInterface/line/h24Line:Performance.
Refer to the TMA CLI manual for more detailed information about the CLI code if
necessary.
samples Use this element to set the number of samples that Default:1
have to be taken from the statistics of the containment Range: 0 … 48
tree object.
For example, when interval is set to 30min, and samples to 2, this means that every 15
minutes a sample is taken.
conversion When the data is logged, it might be necessary to Default:0000

remove some specific characters from the actual log- Range: bit string, see below
ging, or convert certain data to a different format; for
instance, for processing the data in a program like Microsoft Excel.
With the conversion bit string, following automatic modifications or conversions can
be made to the logged data; they are all disabled by default:
• removeQuotes. Enabling this bit will remove quotes from the logged data.
• dateToSeconds. Enabling this bit will convert the logged date and time information
into seconds.
• removeUnits. Enabling this bit will remove the unit of a value, for instance 2dB will
become 2.
• changeDecimalPnt. Enabling this bit will convert a decimal point into a comma, for
instance 2.5 will become 2,5.
The following figure shows an example of a logStatsToFile table, with seven containment tree objects for
which data is logged:
userInfo Default:<empty>
Use this attribute to type in any information you want. Each line in the userInfo
table can contain up to 128 characters.
The main purpose of this attribute is to copy values of certain attributes that have a SNMP OID that is
higher than 231-1. Some SNMP platforms cannot handle such high OID 's.
https Default:disabled
ssh Default:disabled
ipAddress Default:<OPT>
Range: up to 255.255.255.255
Use this attribute to assign an IP address to the loopback interface.
The loopback interface is a software interface which can be used for management purposes. This inter-
face is always up, regardless of the state of the physical interfaces. This means the router will always
respond to ICMP echo requests sent to this address. In every other respect the loopback address
behaves the same as an IP address of a physical interface.
If the loopback address is used and RIP is active, then a host route to the loopback address is included
in the RIP updates.
ipNetMask Default:<OPT>
Range: up to 255.255.255.255
Use this attribute to assign an IP netmask to the loopback interface.
Also see ipAddress on page 815.
sNet Default:<OPT>
Use this attribute to add the loopback interface to a secure network (SNet)
so that it can be controlled by a (virtual) firewall.
The sNet element is a choice element. The first part of the sNet element has the following values:
Value Description
name Select this value to add the interface to the standard secure network. In the second
part of the sNet element, use the drop-down box to select the standard SNet: self.
Note that if you select the value <OPT> (default), then the interface is not added
to the secure network.
vrfRouter Default:0
Range: 0 ... 65535
Use this attribute to add the loopback interface to a VRF router. Do this by
entering the index name of the VRF router here.
Range: 0 ... 65535
User manual Status attributes
12 Status attributes
This chapter discusses the status attributes of the 1424 SHDSL Router. The following gives an overview
of this chapter:
• 12.1 - Status attribute overview on page 818
• 12.2 - General status attributes on page 827
• 12.3 - LAN interface status attributes on page 831
• 12.4 - WAN interface status attributes on page 843
• 12.5 - Encapsulation status attributes on page 846
• 12.6 - SHDSL line status attributes on page 887
• 12.7 - End and repeater status attributes on page 896
• 12.8 - Bundle status attributes on page 900
• 12.9 - Router status attributes on page 911
• 12.10 - Bridge status attributes on page 976
• 12.11 - SNMP status attributes on page 991
• 12.12 - Management status attributes on page 993
• 12.13 - File system status attributes on page 1000
• 12.14 - Operating system status attributes on page 1011
12.1 Status attribute overview
Refer to 4.3 - The objects in the 1424 SHDSL Router containment tree on page 42 to find out which
objects are present by default, which ones you can add yourself and which ones are added automati-
cally.
> router1424
sysDescr
sysObjectID
sysUpTime
sysServices
flash1Version
flash2Version
activeFlash
flashVersions
bootVersion
tdreVersion
messages
deviceId
configurationSaving
date
time
Action: Set Date
Action: Set Time
>> lanInterface
ifDescr
ifType
ifOperStatus
ifLastChange
ifSpeed
ifMtu
ip
macAddress
arpCache
bridging
adapter1
vlan
ports2
ipAdEntBcastAddr
ipAdEntReasmMaxSize
pppOEClient
snmpIndex
oam
switchCache
Action: clearArpCache
Action: oamRemoteLoopback
Action: clearSwitchCache
>> dslInterface
ifDescr
ifType
ifOperStatus
ifLastChange
ifSpeed
snmpIndex
>>> channel[wan_1 ]
ifDescr
ifType
ifOperStatus
ifLastChange
ifSpeed
ifMtu
snmpIndex
>>>> atm
atmSync
pvcTable
vp
1. Only present on the single port LAN interface.

>>>> efm
ip
arpCache
bridging
macAddress
ifDescr
ifType
ifMtu
ifOperStatus
ifLastChange
ifSpeed
ipAdEntBcastAddr
ipAdEntReasmMaxSize
vlan
pppoEClient
oamDiscovery
oamRemoteLoopback
oamRemoteInfo
>>> line
ifDescr
ifType
ifOperStatus
ifSpeed
region
minLinePairSpeed
maxLinePairSpeed
framerType
testType
testOriginator
testStatus
eocAlarmThresholds
numDiscoveredRepeaters
spanStatus
snmpIndex
Action: testActivation
Action: stopAllTests
psdMeasurement
>>>> linePair[ ]
ifSpeed
ifOperStatus
status
timeSinceLastRetrain
lineAttenuation
noiseMargin
actualBitRate
stepupThreshold
transmitPower
snmpIndex
adminStatus
>>> repeater[ ]
vendorId
vendorModel
vendorSerial
vendorSoftVersion
eocSoftVersion
shdslVersion
eocState
eocAlarmThresholds
testType
snmpIndex
>>>> networkLinePair[ ]
lineAttenuation
noiseMargin
snmpIndex
>>>> customerLinePair[ ]
lineAttenuation
noiseMargin
snmpIndex
>>> end
vendorId
vendorModel
vendorSerial
vendorSoftVersion
eocSoftVersion
shdslVersion
eocState
eocAlarmThresholds
testType
>>>> linePair[ ]
lineAttenuation
noiseMargin
snmpIndex
>> profiles
>>> policy
>>>> priority
>>>>> priorityPolicy[ ]
snmpIndex
>>>> traffic
snmpIndex
>>>>> bridgingTrafficPolicy[ ]
snmpIndex
>> ip
>>> router
routingTable
igmpTable
dhcpBinding
dhcpStatistics
dhcpBlackList
dhcpRelayInfo
radius
dns
dnsServers
addrPools
poolReservations
dnsUpdateClient
Action: unBlacklist
Action: forceDnsUpdate
>>>> defaultNat
addresses
natSockets
>>>> nat[ ]
addresses
natSockets
snmpIndex
>>>> tunnels
ifDescr
ifType
ifOperStatus
snmpIndex
l2tpTunnels
ipsecL2tpTunnels
ipsecTunnels
greTunnels
ipsecGreTunnels
snmpIndex
>>>> ikeSA[ ]
phase1
phase2.
snmpIndex
>>>> manualSA[ ]
snmpIndex
>>>> ospf
type
routers
externalRoutes
asExtLsas
snmpIndex
>>>>> area
interfaces
hosts
neighbors
routers
stub
routerLsas
networkLsas
summLsas
asbrLsas
nssaLsas
snmpIndex
>>>> bgp
networks
aggregates
rib
peers
>>>>> ePeer
status
upTime
remote
timers
adjSoftIn
adjRibIn
adjRibOut
warning
snmpIndex
Action:shutDown
Action:restart
Action:softReset
>>>>> iPeer
<contains the same attributes as the ePeer object>
>>>>> routeFilter
users
snmpIndex
>>>>> routeMap
users
snmpIndex
>>>> vrrp[ ]
macAddress
interfaces
criticals
snmpIndex
>>>> firewall
sessions
reverseSessions
log
sNet
>>> vrfRouter[ ]
snmpIndex
routingTable
dhcpBinding
dhcpStatistics
dhcpRelayInfo
dhcpBlacklist
addrPools
poolReservations
dns
dnsServers
igmpTable
>>>> ospf
type
routes
externalRoutes
asExtLsas
snmpIndex
snmpIndex
>> bridge
>>> bridgeGroup
ifDescr
ifType
ifOperStatus
ifMtu
ip
arpCache
bridgeCache
bridging
spanningTree
snmpIndex
macAddress
vlan
Action: clearArpCache
Action: clearBridgeCache
<contains the same attributes as the bridgeGroup object>
>>> accessList[ ]
snmpIndex
>> snmp
trapDestinations
engineId
>> management
cms2Address
logStats
timeServer
alarmLog
accessLog
syslog
>>> loopback
ifDescr
ifType
ifOperStatus
ifMtu
ipAddress
mask
snmpIndex
>>> usrLoopback[ ]
<contains the same attributes as the loopback object>
>> fileSystem
fileList
freeSpace
status
corruptBlocks
trustedCertificates
selfCertificates
Action: Delete File
Action: Rename File
Action: loadTrustedCertificate
Action: generateSelfCertificateRequest
Action: loadSelfCertificate
Action: getTrustedCertificateScep
Action: getSelfCertificateScep
Action: getCrlScep
Action: saveCertificates
>> operatingSystem
taskInfo
coreDump
12.2 General status attributes
This section describes the following status attributes:

• router1424/sysDescr on page 828
• router1424/sysObjectID on page 828
• router1424/sysUpTime on page 828
• router1424/sysServices on page 828
• router1424/flash1Version on page 828
• router1424/flash2Version on page 828
• router1424/activeFlash on page 829
• router1424/flashVersions on page 829
• router1424/bootVersion on page 829
• router1424/tdreVersion on page 829
• router1424/messages on page 829
• router1424/deviceId on page 830
• router1424/configurationSaving on page 830
• router1424/date on page 830
• router1424/time on page 830
• router1424/Set Date on page 830
• router1424/Set Time on page 830
router1424/sysDescr
This attribute displays a textual description of the device.

Example: 1424 SHDSL Router Txxxx/xxxxx 01/01/00 12:00
In this example the following parameters are visible:
• 1424 SHDSL Router is the device name.
• Txxxx/xxxxx is the application software code and version.
• 01/01/00 12:00 is the application software release date and time.
router1424/sysObjectID
This attribute displays the identification string.
router1424/sysUpTime
This attribute displays the elapsed time since the last power-on or cold boot of the 1424 SHDSL Router.
router1424/sysServices
This attribute displays the service identification.
router1424/flash1Version
This attribute displays the code and version of the application software stored as CONTROL1.
Example: Txxxx/xxxxx 01/01/00 12:00
• Txxxx is the application software code for this device.
• /xxxxx is the application software version.
• 01/01/00 is the application software release date.
• 12:00 is the application software release time.
router1424/flash2Version
This attribute displays the code and version of the application software stored as CONTROL2.
Example: Txxxx/xxxxx 01/01/00 12:00
• Txxxx is the application software code for this device.
• /xxxxx is the application software version.
• 01/01/00 is the application software release date.
• 12:00 is the application software release time.
router1424/activeFlash
This attribute displays which application software is currently active. Possible values are:
Value Description
flash1 The application software CONTROL1 is active.
flash2 The application software CONTROL2 is active.
router1424/flashVersions
This attribute displays how many application software versions can be stored in the file system.
router1424/bootVersion
This attribute displays the code, version, release date and time of the boot software currently used in the
1424 SHDSL Router.
router1424/tdreVersion
This attribute displays the version of the TDRE (Total Dynamic Routing Engine) currently used in the
1424 SHDSL Router.
Example: xxx.yyy.zzz
• xxx is the major TDRE version. This number is incremented only when a complete new version of the
TDRE is released.
• yyy is the minor TDRE version. This number is incremented every time new features are added to the
TDRE.
• zzz is the build version. This number is incremented every time a new TDRE version is built (also in
case of bug fixes etc.).
router1424/messages
This attribute displays informative and error messages, e.g. Reconfigured, Cold Boot, … The messages table
displays maximum 20 messages.
If you open a TMA session on the 1424 SHDSL Router over IP, i.e. not through the control port, then the
messages are also sent to the control port. This means that if you open a terminal emulation session on
the control port, you can monitor these messages. If you hit the ENTER key, the messages stop and you
get the (CLI) password prompt.
router1424/deviceId
This attribute displays a unique code. This code is programmed into the 1424 SHDSL Router before it
leaves the factory. You can use this code for inventory purposes.
router1424/configurationSaving
This attribute indicates when the 1424 SHDSL Router is writing its (new) configuration to the flash mem-
ory. Possible values are:
Value Description
busy The 1424 SHDSL Router is busy writing its configuration to the flash memory. Dur-
ing this state, do not power-down or reboot the 1424 SHDSL Router else the new
configuration will be lost.
done The 1424 SHDSL Router has finished writing its configuration to the flash memory.
router1424/date
This attribute displays the current date in the format dd/mm/yy (e.g. 01/01/00).
router1424/time
This attribute displays the current time in the format hh:mm:ss (e.g. 12:30:45).
router1424/Set Date
Use this action to set the current date. Enter the date as argument value in the format dd/mm/yy (e.g. 01/
01/00). Then execute the action.
router1424/Set Time
Use this action to set the current time. Enter the time as argument value in the format hh:mm:ss (e.g.
12:30:45). Then execute the action.
12.3 LAN interface status attributes
This section describes the status attributes of the following object:
router1424/lanInterface/
The LAN interface status attributes are:

• ifDescr on page 832
• ifType on page 832
• ifOperStatus on page 832
• ifLastChange on page 832
• ifSpeed on page 832
• ifMtu on page 832
• ip on page 833
• arpCache on page 834
• ipAdEntBcastAddr on page 839
• ipAdEntReasmMaxSize on page 839
• snmpIndex on page 841
• oam on page 841
The following attributes are only present on the 4 port Ethernet LAN interface:
• switchCache on page 839
The following attribute is only present on the single port Ethernet LAN interface:
• adapter on page 837

• clearArpCache on page 842
• oamRemoteLoopback on page 842
The following action is only present on the 4 port Ethernet LAN interface:
• clearSwitchCache on page 842
ifDescr
This attribute displays the interface description.
ifType
This attribute displays the interface type.
ifOperStatus
This attribute displays the current operational status of the interface.
ifLastChange
This attribute shows the system-up time on the moment the interface entered its current operational
state. I.e. the moment the value of the ifOperStatus status attribute changes (from up to down or vice versa),
the system-up time value is written into the ifLastChange status attribute.
ifSpeed
This attribute displays the interface speed in bits per second (bps).
ifMtu
This attribute displays the interface its Maximum Transfer Unit, i.e. the maximum number of bytes that
one packet can contain on this interface.
Important remark
The following explanation applies to all interfaces of the OneAccess devices:

The ifMtu is actually the MRU (Maximum Receive Unit) on a certain interface, so the maximum layer 1
frame size that can be received on a certain interface:
• On a LAN interface, this is the maximum ethernet frame size.
• On a SHDSL line running ppp, it is the maximum ppp frame size.
• On a bridgeGroup and vpnBridgeGroup interface, it has been implemented in the OneAccess devices that
the ifMtu is the MRU on IP level.
So the ifMtu is not configurable in the OneAccess devices and depends on the used hardware and is
coded in the firmware.
Note that there is no relation whatsoever between the ifMtu status attribute and the mtu configuration
attribute in the ip structure (refer to 5.2.3 - Explaining the ip structure on page 56): the mtu is configurable
and is on layer 2.
ip
This attribute displays the IP information of the interface.

Element Description
status This is the current operational status of the IP layer (layer 3).
address This is the IP address of the interface. It is either configured or retrieved automat-
ically.
netMask This is the IP subnet mask of the interface. It is either configured or retrieved auto-
matically.
secondaryIp This is the secondary IP address that has been configured on the LAN interface.
The secondaryIp table contains following elements:
• address. This is the secondary IP address.
• netMask. This is the secondary IP subnet mask.
macAddress
This attribute displays the MAC address of the 1424 SHDSL Router its LAN interface.
The LAN interface has been allocated a fixed Ethernet address, also called MAC (Medium Access Con-
trol) address. The MAC address is globally unique and can not be modified. It is a 6 byte code, repre-
sented in hexadecimal format. Each byte in the code is separated by a colon.
Refer to What is the ARP cache? on page 512 for more information on the MAC addresses.
arpCache
This attribute displays all the MAC address - IP address pairs from ARP requests and replies received
on the LAN interface. Refer to What is the ARP cache? on page 512 for more information.
The arpCache table contains the following elements:
Element Description
macAddress This is the MAC address.
ipAddress This is the associated IP address.
type This is the ARP cache entry type. Possible values are:
• dynamic. The MAC - IP address pair is retrieved from an ARP request or reply
message.
• static. The MAC - IP address pair is configured.
There is only one static entry, i.e. the 1424 SHDSL Router its own IP and MAC
address.
timeOut This is the time the entry will remain in the ARP cache. For the static entry, this
value is 0.
Example
The following figure shows part of an ARP cache table as an example:

bridging
This attribute displays the bridging status of the interface.

Element Description
status This displays the current state of the port. Possible values are:
• discarding1. The port does not participate in frame forwarding.
• learning. The port prepares to participate in frame forwarding, and it learns the
present MAC addresses.
• forwarding1. The port participates in frame forwarding.
Refer to 8.1.6 - The Spanning Tree bridge port states on page 306 for more infor-
mation on port states2.
Element Description
spanningTree This displays the current spanning tree state. The spanningTree element contains
• portRole. This the role of the port in the STP. Refer to 8.1.5 - The Spanning Tree
topology on page 304 for more information.
• portId. This the unique port identifier. It is a combination of MAC address and
priority of the port. This assures the uniqueness of the unique port identifier
among the ports of a single bridge.
• portPathCosts. This element contains:
- extPathCost. This is the pathCost as configured in the bridging structure, refer
to 8.2.6 - Explaining the bridging structure on page 318 for more information.
- intPathCost. This is the internalPathCost as configured in the bridging structure.
• extRootPathCost. This is the path cost from this port to the root bridge.
• inRootPathCost. This is the path cost to the root bridge within this MST region.
• designatedBridgeId. This element itself consists of 2 elements: priority and macAd-
dress. Together, these two elements form a unique bridge identifier. Depending
whether the current port is a designated port or not, these two elements display
the unique bridge identifier of …
- the bridge to which this port belongs, in case of a designated port.
- the bridge believed to be the designated bridge for the LAN that is currently
connected to this port, in all other cases.
This bridge identifier is used …
- together with the designatedPortId element, to determine whether this port
should be the designated port for the LAN that is currently connected to this
port.
- to test the value of the bridge identifier parameter conveyed in received
Configuration BPDUs.
• designatedPortId. This displays the unique port identifier of the bridge port through
which the designated bridge transmits the configuration message information
stored by this port. This port identifier is used …
- together with the designatedBridgeId element to determine whether this port
should be the designated port for the LAN that is currently connected to this
port.
- by the management system to determine the topology of the bridged LAN.
• designatedOrInternal. This element indicates if the status of a port is designated
whithin the global spanning tree, or if the MSTP packet is received from the
same region.
• edgeDetection. This element indicates whether or not a port is an edge port.
However, if a port is defined as an edge port, and it receives an incoming STP
packet, the edge status is automatically lost.
1. These are the only possible port states for a bridge that is not running the Spanning Tree pro-
tocol (IEEE p802.1D).
2. Only relevant when the bridge uses the Spanning Tree Protocol.
adapter

This attribute displays the Ethernet mode of the LAN interface as set using the adapter configuration
attribute.
The adapter structure contains the following elements:
Element Description
speed This is the Ethernet speed in Mbps. Possible values are: 10 and 100.
duplex This is the Ethernet duplex mode. Possible values are: halfDuplex and fullDuplex.
vlan
This attribute displays the status of the VLAN(s) on this interface.

Element Description
name This is the name of the VLAN as you configured it. If you did not configure a name,
then this element displays: <LAN interface name> “vlan” <VLAN ID>.
E.g. lan vlan 2
mode This element displays the VLAN mode, possible values are: ces, routing, bridging, rout-
ingAndBridging, switching, frf5, frf8, multilink.
ifOperStatus This is the current operational status of the VLAN.
ifLastChange This is the system-up time on the moment the VLAN entered its current operational
state. I.e. the moment the value of the ifOperStatus element changes (from up to down
or vice versa), the system-up time value is written into the ifLastChange element.
ip This displays the IP address and subnet mask of the VLAN.
bridging This displays the bridging information of the VLAN.

Refer to bridging on page 835 for a detailed description of the bridging structure.
vlan This displays the specific VLAN related status information.

• vid. This element displays the VLAN identifier.
• arpCache. This element displays all the MAC address - IP address pairs from
ARP requests and replies received on the VLAN.
Refer to arpCache on page 834 for a detailed description of the arpCache table.
ports

This attribute displays the status of each port of the 4 port Ethernet interface (including the local port).
The ports table contains the following elements:
Element Description
portName This element displays the port name. Possible values are port1, port2, port3, port4 or
localPort. Refer to What is the 4 port Ethernet switch? on page 337 for more infor-
mation on what the local port is.
ifOperStatus This element displays the current operational status of the port.
speed This element displays the port speed in megabits per second (Mbps).
duplex This element displays the duplex mode of the port. Possible values are: fullDuplex
or halfDuplex.
autoNegotiate This element displays the status of the Ethernet mode auto negotiation process.
Possible values are:
• disabled. The adapter element in ports configuration attribute is set to fixed. I.e. the
auto negotiation process is disabled.
• done. The adapter element in ports configuration attribute is set to autoNegotiate and
the auto negotiation process is finished.
• notDone. The adapter element in ports configuration attribute is set to autoNegotiate
but the auto negotiation process is not finished (yet).
linkPartnerCaps This element displays the Ethernet mode capabilities of the port its link partner. So
this structure contains the following elements: 10Mb/halfDuplex, 10Mb/fullDuplex, 100Mb/
halfDuplex, 100Mb/fullDuplex, flowControl. Each element can have the value capable or
notCapable.
vlanMembership This element displays the VLAN membership of the port. The vlanMembership table
• vid. This element displays the VLAN ID.
• portMembership. This element displays which port is a member (yes) or no mem-
ber (no) of the corresponding VLAN.
switchCache

This attribute displays the MAC address cache.
The switchCache table contains the following elements:
Element Description
macAddress This element displays the MAC address.
port This element displays the port that is linked to the MAC address: port1, port2, port3,
port4 or localPort.
type This element displays the type of entry in the MAC address cache, static or dynamic.
ipAdEntBcastAddr
This attribute displays the value of the least-significant bit in the IP broadcast address. This address is
used for sending packets on the interface which is associated with the IP address of this entry. The value
applies to the general broadcast, the subnet and network broadcasts.
ipAdEntReasmMaxSize
This attribute displays the size of the largest IP packet which this entity can re-assemble from incoming
IP fragmented packets received on this interface.
pppoEClient
This attribute displays the PPPoE status of the interface.

The pppoEClient table contains the following elements:
Element Description
name This element displays the administrative name of the PPPoE link.
mode This element displays by which process the packets are treated. Possible values
are:
• bridging. All packets are bridged.
• routing. The IP packets are routed. All other protocols are discarded.
• routingAndBridging. IP packets are routed. Non-IP packets are bridged.
ifOperState This element displays the current operational status of the PPPoE link.
ifLastChange This element shows the system-up time on the moment the PPPoE link entered its
current operational state. I.e. the moment the value of the ifOperStatus element
changes (from up to down or vice versa), the system-up time value is written into the
ifLastChange element.
Element Description
ip This element displays IP related parameters of the PPPoE link.

• address. This is the IP address of the interface. It is either configured or retrieved
automatically.
• netMask. This is the IP subnet mask of the interface. It is either configured or
retrieved automatically.
• remote. This is the IP address to the remote end of the PPPoE connection.
pppOverEth When the 1424 SHDSL Router wants to initiate a PPP over Ethernet (PPPoE) ses-
sion, it must first perform a discovery to identify the Ethernet MAC address of the
host and to establish a PPPoE session ID. The pppOverEth structure displays infor-
mation on the PPPoE discovery.
The pppOverEth structure contains the following elements:
• discState. This is the state of the discovery. The discovery goes as follows:
- The 1424 SHDSL Router sends a PADI packet (PPPoE Active Discovery
Initiation).
- When the host receives a PADI that it can serve, it replies by sending a
PADO packet (PPPoE Active Discovery Offer).
- The 1424 SHDSL Router then sends one PADR packet (PPPoE Active Dis-
covery Request) to the host that it has chosen.
- When the host receives a PADR packet, it prepares to begin a PPP session.
It generates a unique session ID for the PPPoE session and replies to the
1424 SHDSL Router with a PADS packet (PPPoE Active Discovery Ses-
sion-confirmation).
So possible discState values are: idle, waitForPADO, waitForPADS, established.
• remoteMacAddress. This is the MAC address of the remote system as learned dur-
ing the discovery.
ppp This element displays PPP related parameters of the PPPoE link.
The ppp structure contains the following elements:
• lcpState. This element reflects the status of the LCP (Link Control Protocol) pro-
tocol. Possible values are:
- Initial. LCP handshake has not started yet.
- Starting, Closed, Stopped, Closing, Stopping. These values correspond with the
transient states in the LCP state diagram.
- Req-Sent. The local side of the PPP link has sent an LCP request. The remote
side did not answer yet.
- Ack-Rcvd. The local side of the PPP link has received an LCP acknowledge
from the remote side. This is a transient state.
- Ack-Sent. The local side of the PPP link has acknowledged the LCP request
from the remote side.
- Opened. The LCP handshake succeeded.
Element Description
• ipcpState. This attribute reflects the status of the IPCP (Internet Protocol Control
Protocol) protocol. The possible values are the same as those of the lcpState
attribute above.
• myAuthenState. This element displays the authentication state of the router at this
side (local side) of the link. i.e. the state of the authenticator. Possible values
are:
- No-Authentication. The local side does not request PPP authentication or still
has to start the CHAP authentication (LCP handshake is busy).
- Wait-On-Response. The local side has sent a challenge packet and is waiting
for an answer.
- Authen-Successful. The response packet is found to be correct. This is the
state when authentication succeeded.
- Authen-Failure. The response packet is found to be incorrect. This is a tran-
sient state since the router starts the LCP handshake again after a failing
authentication.
• hisAuthenState. This attribute displays the authentication state of the router at the
other side (remote side) of the link. i.e. the state of the peer. Possible values
are:
- No-Authentication. This is the start-up state.
- Wait-On-Challenge. During the LCP handshake the authenticator already indi-
cates it wants to authenticate. From that moment on, the peer awaits a chal-
lenge packet.
- Wait-On-Success. Once the peer has sent a response, it awaits a success or
failure message.
- Authen-Successful. The peer has received a success packet. It remains in this
state during data transfer.
- Authen-Failure. The peer has received a failure packet. This is a transient state
since the router starts the LCP handshake again after a failing authentica-
tion.
- Authen-Not-Allowed. This state only occurs when the peer does not accept the
authentication request during the LCP handshake. A possible reason might
be that the peer router does not support CHAP.
snmpIndex
This attribute displays the SNMP index, which is a unique number, assigned to each object in the con-
tainment tree. Refer to 5.3.7 - Introducing attributes snmpIndex and snmpIndexOffset on page 74 for more
information.
The snmpIndex attribute appears in many objects of the 1424 SHDSL Router containment tree.
oam
This attribute has already been explained in 12.5.5 - EFM status attributes on page 877, refer to the oam
attribute there.
clearArpCache
Use this action to clear the ARP cache table.
oamRemoteLoopback
Use this action to set up an OAM loop at the network side. Select start as argument value, and execute
the action.
To stop the OAM loop, select stop as argument value, and execute the action.
clearSwitchCache

Use this action to remove the dynamic entries from the switchCache.
12.4 WAN interface status attributes
This section only applies to:

• 1431 SHDSL CPE
• 1432 SHDSL CPE

• router1424/wanInterface/ifDescr on page 844
• router1424/wanInterface/ifType on page 844
• router1424/wanInterface/ifSpeed on page 844
• router1424/wanInterface/ifMtu on page 844
• router1424/wanInterface/ifLastChange on page 844
• router1424/wanInterface/ifOperStatus on page 844
router1424/wanInterface/ifDescr
router1424/wanInterface/ifType
router1424/wanInterface/ifSpeed
router1424/wanInterface/ifMtu
router1424/wanInterface/ifLastChange
router1424/wanInterface/ifOperStatus
This attribute displays the current operational status of the interface. Possible values are:
Value Description
up The WAN interface is up, data transfer is possible.
down The WAN interface is down, data transfer is not possible.

The ifOperStatus attribute is down in case of …
• ATM, when …
- the ATM synchronisation status is “not synched”.
- the bit pump is not synchronised.
• PPP(oA), when …
- LCP is not open.
- the bit pump is not synchronised.
Important remarks
• Whether the 1424 SHDSL Router is configured in bridging or routing has no effect on the value of the
attributes wanInterface/ifOperStatus:Status and wanInterface/alarmInfo/linkDown:Alarms.
• In case of ATM, if the configuration element pvcTable/atm/oamF5Loopback is set to disabled, then the ifOp-
erStatus of the PVC becomes up when the ATM is synchronised globally. However, this does not guar-
antee that the PVC is configured (correctly) on the remote side. However, the other conditions as
stated in the table above remain.
• In case of PPP(oA), if the configuration element linkMonitoring/operation is set to disabled, then it is pos-
sible that the wanInterface/ifOperStatus value does not go down even if the link quality is too bad for a
proper data link. This because the link monitoring mechanism is the only PPP mechanism that will
start a renegotiation of the LCP layer.
• In case of Frame Relay, if the configuration element lmi/auto is set to noLmi, then the value of the status
element lmi/status:Status is always up. However, the other conditions as stated in the table above
remain.
12.5 Encapsulation status attributes
This section discusses the status attributes of the encapsulation protocols that can be used on the 1424
SHDSL Router.
• 12.5.1 - ATM status attributes on page 847
• 12.5.2 - ATM IMA status attributes on page 859
• 12.5.3 - Frame Relay status attributes on page 864
• 12.5.4 - PPP status attributes on page 870
• 12.5.5 - EFM status attributes on page 877
12.5.1 ATM status attributes
router1424/dslInterface/channel[wan_1]/atm

• atmSync on page 848
• pvcTable on page 848
• vp on page 858
atmSync
This attribute displays the ATM synchronisation status. Possible values are: synced, notSynced.
pvcTable
This attribute gives the complete status information of all known PVCs.
The pvcTable table contains the following elements:
Element Description
name This is the name of the PVC as you configured it. If you did not configure a name,
then this element displays: <interface name> “vpi” <vpi number> “vci” <vci number>.
E.g. wan vpi 102 vci 102
mode This displays by which process the packets are treated. Possible values are:
• bridging. All packets received on the PVC are bridged.
• routing. All packets received on the PVC are routed.
ifOperStatus This is the current operational status of the PVC.

In case OAM F5 …
• LoopBack (LB) or Continuity Check (CC) is disabled, i.e. no OAM F4 LB/CC
cells are sent, then the ifOperStatus of the PVC becomes up when the ATM is syn-
chronised globally. However, this does not guarantee that the PVC is config-
ured (correctly) on the remote side.
• LoopBack (LB) is enabled, i.e. OAM F5 loopback cells are sent at regular inter-
vals, then the ifOperStatus of the PVC becomes up when the loopback cells are
returned and down when the loopback cells are not returned by the remote side.
ifLastChange This is the system-up time on the moment the PVC entered its current operational
ip This displays the IP information of the PVC.

Refer to pvcTable/ip on page 850 for a detailed description of the ip structure.
bridging This displays the bridging information of the PVC.

atm This displays the specific ATM related status information of the PVC.
Refer to pvcTable/atm on page 851 for a detailed description of the atm structure.
Element Description
frameRelay This displays the specific Frame Relay related status information of the PVC.
The frameRelay structure contains following elements:
• lmi. This attribute gives a complete LMI status information overview for each
PVC. Refer to lmi on page 867 for a detailed description.
• dlciTable. This attribute gives the complete status information of all known DLCIs
for this PVC. Refer to pvcTable/frameRelay/dlciTable on page 856 for a detailed
description.
pvcTable/ip
The ip structure in the pvcTable displays the IP information of the PVC.

Element Description
address This is the IP address of the PVC. It is either configured or retrieved automatically.
netMask This is the IP subnet mask of the PVC. It is either configured or retrieved automat-
ically.
remote This is the IP address of the remote end of the PVC. It is either configured or
pvcTable/atm
The atm structure in the pvcTable displays the specific ATM related status information of the PVC.
Element Description
vpi This displays the Virtual Path Identifier (VPI).
vci This displays the Virtual Channel Identifier (VCI).

The VPI in conjunction with the VCI identifies the next destination of a cell as it
passes through a series of ATM switches on the way to its destination.
peakCellRate This displays the Peak Cell Rate (PCR) of the PVC in bps.
sustCellRate This displays the Sustainable Cell Rate (SCR) of the PVC in bps.
maxBurstSize This displays the Maximum Burst Size (MBS) of the PVC in cell times.
Initiation).
sion-confirmation).
ing the discovery.
ppp This displays the PPP information of the PVC.

Refer to 12.5.4 - PPP status attributes on page 870 for a detailed description of the
elements in the ppp structure.
serviceCategory This element displays the ATM service category.

For more information on ATM service categories, refer to 6.2.1 - Introducing ATM
on page 98.
Element Description
oamF5 This displays the state of the OAM F5 protocol.

The oamF5 structure contains the following elements:
• segment. Refer to pvcTable/atm/oamF5/segment on page 853 for more information
about the segment structure.
• endToEnd. Refer to pvcTable/atm/oamF5/endToEnd on page 854 for more information
about the endToEnd structure.
• segmentEndPoint. This element indicates whether the 1424 SHDSL Router is a
segment endpoint or not.
• connectionEndPoint. This element indicates whether the 1424 SHDSL Router is a
connection endpoint or not.
pvcTable/atm/oamF5/segment
This structure displays status information about the OAM F5 protocol.

The segment structure contains the following elements:
Element Description
oamLB This element displays whether or not the OAM loopback mechanism is active or
not.
oamCC This element displays the status of the the OAM continuity check mechanism. Pos-
sible values are:
• Deactivated: this mode will not start CC in any case.
• Activated: CC is started, no negotiation is done with the remote endpoint.
• Passive: the 1424 SHDSL Router is willing to accept activation/deactivation
messages and responds to it.
• InitActivation: this mode initiates the activation of the CC process by sending acti-
vation messages.
oamPM This element displays whether or not the OAM performance monitoring mecha-
nism is active or not.
The oamPM structure contains the following elements:
• status. This element shows the status of the OAM performance monitoring
mechanism. Possible values are:
- Deactivated: this mode will not start PM in any case.
- Activated: PM is started, no negotiation is done with the remote endpoint.
- Passive: the 1424 SHDSL Router is willing to accept activation/deactivation
messages and responds to it.
- InitActivation: this mode initiates the activation of the PM process by sending
activation messages.
• blocksizeAB. This element displays the size of the block of cells, after which an
activation/deactivation cell is inserted in the cell flow, in the direction away from
the activator/deactivator.
• blocksizeBA. This element displays the size of the block of cells, after which an
activation/deactivation cell is inserted in the cell flow, in the direction towards
the activator/deactivator.
aisState This element displays whether or not the AIS state is active or not.
rdiState This element displays whether or not the RDI state is active or not.
pvcTable/atm/oamF5/endToEnd
The endToEnd structure contains the same elements as the segment structure. Refer to pvcTable/atm on
page 851.
pvcTable/frameRelay/lmi
This attribute gives a complete LMI status information overview.

Element Description
mode This displays the Frame Relay mode. Possible values are: noLmi, user, network, auto.
Refer to pvcTable/frameRelay/common/lmi on page 547 for more information on these val-
ues.
type This displays the LMI variant. Possible values are: lmiRev1, ansiT1-617-d, q933-Annex-
A, frf1-2.
Refer to pvcTable/frameRelay/common/lmi on page 547 for more information on these val-
ues.
status This displays the current state of LMI. Possible values are:
• up. LMI messages can and are exchanged.
• down. No LMI messages can be exchanged.
lastStatusChange This is the system-up time when the LMI status entered its current state. I.e. the
moment the value of the status element changes (from up to down or vice versa), the
system-up time value is written into the lastStatusChange element.
lastError This displays the last error condition reported by LMI. Possible values are: none,
protocol error, unknown information element, sequence error, unknown report, timer expired,
invalid report type, unsolicited status.
netTxSeqNum This is the sequence number of the last LMI Status Response frame that was sent.
Since only a Frame Relay network or DCE can transmit Status Responses, the
value of this element only changes in case the 1424 SHDSL Router is defined as
a Frame Relay network or both user and network. I.e. in case the mode element is
set to network, auto or nni.
netRxSeqNum This is the sequence number of the last LMI Status Enquiry frame that was
received.
Since only a Frame Relay network or DCE can receive Status Enquiries, the value
of this element only changes in case the 1424 SHDSL Router is defined as a
Frame Relay network or both user and network. I.e. in case the mode element is
netErrors This is the number of errors on LMI commands issued by the Frame Relay network
or DCE during the last monitoredEvents period.
Element Description
userTxSeqNum This is the sequence number of the last LMI Status Enquiry frame that was sent.
Since only a Frame Relay user or DTE can transmit Status Enquiries, the value of
this element only changes in case the 1424 SHDSL Router is defined as a Frame
Relay user or both user and network. I.e. in case the mode element is set to user,
auto or nni.
userRxSeqNum This is the sequence number of the last LMI Status Response frame that was
received.
Since only a Frame Relay user or DTE can receive Status Responses, the value
Frame Relay user or both user and network. I.e. in case the mode element is set to
user, auto or nni.
userErrors This is the number of errors on LMI commands issued by the Frame Relay user or
DTE during the last monitoredEvents period.
userWaitFullEnquiry This is the number of LMI frames still to be sent before a Full Status Enquiry will
be requested.
userLastReport- This displays the type of the most recent report that was sent. Possible values are:
TypeSent
• full status. The last report contained the full status.
• link integrity. The last report only contained the link integrity information.
pvcTable/frameRelay/dlciTable
This attribute gives the complete status information of all known DLCIs.
The dlciTable table contains the following elements:
Element Description
name This is the name of the DLCI as you configured it. If you did not configure a name,
then this element displays: <interface name> “dlci” <dlci number>.
E.g. wan dlci 16
mode This element displays the mode of the DLCI. Possible modes are: ces, routing, bridg-
ing, routingAndBridging, switching, frf5, frf8, multilink.
ifOperStatus This is the current operational status of the DLCI.
ifLastChange This is the system-up time on the moment the DLCI entered its current operational
ip This displays the IP information of the DLCI.

Refer to ip on page 833 for a detailed description of the ip structure.
bridging This displays the bridging information of the DLCI.

frameRelay This displays the specific Frame Relay related status information of the DLCI.
Refer to pvcTable/frameRelay/dlciTable/frameRelay for a detailed description of the
frameRelay structure.
pvcTable/frameRelay/dlciTable/frameRelay
The frameRelay structure in the dlciTable displays the specific Frame Relay related status information of the
DLCI.
Element Description
dlci This is the DLCI identification number.
active This indicates whether the corresponding DLCI is active (on) or not (off).
new This is set to on if the DLCI has just been created, else it is off.
deleted This is set to on if the DLCI has been deleted, else it is off.
rr This element is only relevant for LMI revision 1. It is the flow control flag. If it is on,
then no traffic can be sent on this DLCI. Else it is off.
bandwidth This element is only relevant for LMI revision 1 (in all other cases this value is 0).
It is the CIR value, in bps, as it is configured on the remote.
cllmLastCongestion- CLLM (Consolidated Link Layer Management) is a Frame Relay protocol used for
Cause traffic management. The cllmLastCongestionCause element indicates the last reason,
which was received from the network, for congestion on the corresponding DLCI.
• none
• short term, excessive traffic
• long term, excessive traffic
• short term, equipment failure
• long term, equipment failure
• short term, maintenance action
• long term, maintenance action
• short term, unknown cause
• long term, unknown cause
• unknown cause
vp
Whereas the pvcTable gives the current operational status for each Virtual Channel, the vp table gives the
current operational status of a complete Virtual Path.
Element Description
vpi This is the Virtual Path Identifier (VPI).
ifOperStatus This is the current operational status of the Virtual Path.

In case OAM F4 …
• LoopBack (LB) or Continuity Check (CC) is disabled, i.e. no OAM F4 LB/CC
cells are sent, then the ifOperStatus of the VP becomes up when the ATM is syn-
chronised globally. However, this does not guarantee that the VP is configured
(correctly) on the remote side.
• LoopBack (LB) is enabled, i.e. OAM F4 loopback cells are sent at regular inter-
vals, then the ifOperStatus of the VP becomes up when the loopback cells are
returned and down when the loopback cells are not returned by the remote side.
In case a VP goes down, also all VCs belonging to the VP go down.
oamF4 This displays the state of the OAM F4 protocol.

The elements contained in this structure are the same as those in the oamF5 struc-
ture. For a detailed description of these elements refer to oamF5 on page 852.
12.5.2 ATM IMA status attributes
router1424/dslInterface/channel[wan_1]/atm/ima

• neState on page 860
• feState on page 860
• neTxClockMode on page 861
• feTxClockMode on page 861
• nrActRxLinks on page 861
• nrActTxLinks on page 861
• memebers on page 862
nrActTxLinks on page 861
neState
This attribute displays the current operational status of the near-end of the IMA group. Possible values
are:
Element Description
notConfigured This is a group state indicating that the group does not exist yet.
startUp This is a group state indicating that the group is waiting to see the far-end in star-
tup.
startUpAck This is a group transitional state, when both groups are in startup and the far-end
group parameters have been accepted.
configAbortUnsup- This is a group state indicating that the group has rejected the group parameters
portedM proposed by the far-end IMA group. The reason in this case is “unsupported IMA
frame size”.
configAbortIncom- This is a group state indicating that the group has rejected the group parameters
patibleSymmetry proposed by the far-end IMA group. The reason in this case is “incompatible group
symmetry”.
configAbortInvalid This is a group state indicating that the group has rejected the group parameters
ImaVersion proposed by the far-end IMA group. The reason in this case is “unsupported IMA
version”.
configAbortOther This is a group state indicating that the group has rejected the group parameters
proposed by the far-end IMA group. The reason in this case is any other reason
than configAbortUnsupportedM, configAbortIncompatibleSymmetry or configA-
bortInvalidImaVersion.
insufficientLinks Group state indicating that the group does not have sufficient links in the active
state to be in the operational state.
blocked This is a group state indicating that the group has been inhibited.
operational Group state indicating than the group has sufficient links in both transmit and
receive directions to carry ATM layer cells.
feState
This attribute displays the current operational status of the far-end of the IMA group. The possible values
are the same as those of the neState attribute above.
neTxClockMode
This attribute displays the transmit clock mode that is currently being used by the near-end. Possible
values are: common or independent.
feTxClockMode
This attribute displays the transmit clock mode that is currently being used by the far-end. Possible val-
ues are: common or independent.
nrActRxLinks
This attribute displays the number of active, receiving links.
nrActTxLinks
This attribute displays the number of active, transmitting links.

memebers
This attribute gives the complete status information of all the members of the IMA group.
The members table contains the following elements:
Element Description
inteface This element displays the name of the interface that is a member of the IMA group.
id This element displays the logical ID of the link on the interface that makes up the
IMA bundle.
neRxState This element displays the current status of the near-end receive side of the link.
• notInGroup. This is a state indicating that the link is no longer configured within
an IMA group.
• unusableNoGivenReason. This is a state indicating that the link is not in use. No
reason can be given why the link is not in use.
• unusableFault. This is a state indicating that the link is not in use. The reason is
fault. This means a fault has been detected either on the link or in the link pro-
tocol.
• unusableMisconnected. This is a state indicating that the link is not in use because
of a connection problem.
• unusableInhibited. This is a state indicating that the link is not in use. The reason
is inhibited. This means that operation of the link is blocked for some locally
defined application or implementation dependent reason.
• unusableFailed. This is a state indicating the link is not in use. The reason in this
case is failed. This means that the link fails due to the persistence of a defined
defect.
• usable. This is a state indicating that the link is ready to be used.
• active. This is a state indicating that the link is capable of passing cells from the
ATM layer.
• deleted. This is a state indicating that the link has been removed from the IMA
group.
neTxState This element displays the current status of the near-end transmit side of the link.
The possible values are the same as those of the neRxState element, explained
above.
feRxState This element displays the current status of the far-end receive side of the link. The
possible values are the same as those of the neRxState element, explained above.
feTxState This element displays the current status of the far-end transmit side of the link. The
possible values are the same as those of the neRxState element, explained above.
Element Description
neRxFailure This element displays the current failure status of the near-end receive side of the
link. Possible values are:
• noFailure. There is no failure. The near-end side of the link is up.
• imaLinkFailure. The complete link is down.
• lifFailure. A LIF (Loss of IMA Frame) defect is detected. The LIF defect is the
occurrence of persistent OIF (Out of IMA Frame) anomalies for at least 2 IMA
frames.
• lodsFailure. A LODS (Link Out of Delay Synchronization) defect is detected. The
LODS is a link event indicating that the link is not synchronized with the other
links within the IMA group.
• misConnected. This is reported when the IMA unit has determined that the receive
link is not connected to the same far-end IMA unit as the other receive links in
the group.
• blocked. The link is blocked.
• fault. A fault is detected either on the link or in the link protocol.
• farEndTxLinkUnusable. The far-end transmit side of the link is unusable.
• farEndRxLinkUnusable. The far-end receive side of the link is unusable.
trl This element displays whether or not this link is selected as the reference to derive
the IDCR. Possible values are: yes or no.
TRL stands for Timing Reference Link, and is used to pass synchronization from
the transmit to the receive end.
IDCR stands for IMA Data Cell Rate, and represents the rate at which IMA data
cells should be exchanged between the IMA sublayer and the ATM layer.
12.5.3 Frame Relay status attributes
This section describes the status attributes of the following object(s):
router1424/dslInterface/channel[wan_1]/frameRelay/
The Frame Relay status attributes are:

• ip on page 865
• lmi on page 867
• cllmLastCongestionCause on page 869
ip
This attribute displays the IP information of the Frame Relay link.

dlciTable
This attribute gives the complete status information of all known DLCIs.
Element Description
name This is the name of the DLCI as you configured it. If you did not configure a name,
then this element displays: <interface name> “dlci” <dlci number>.
E.g. wan dlci 16
ifOperStatus This is the current operational status of the DLCI.
ifLastChange This is the system-up time on the moment the DLCI entered its current operational
ip This displays the IP information of the DLCI.

bridging This displays the bridging information of the DLCI.

frameRelay This displays the specific Frame Relay related status information of the DLCI.
Refer to dlciTable/frameRelay on page 866 for a detailed description of the frameRelay
structure.
dlciTable/frameRelay
The frameRelay structure in the dlciTable displays the specific Frame Relay related status information of the
DLCI.
Element Description
active This indicates whether the corresponding DLCI is active (on) or not (off).
new This is set to on if the DLCI has just been created, else it is off.
deleted This is set to on if the DLCI has been deleted, else it is off.
rr This element is only relevant for LMI revision 1. It is the flow control flag. If it is on,
then no traffic can be sent on this DLCI. Else it is off.
bandwidth This element is only relevant for LMI revision 1 (in all other cases this value is 0).
It is the CIR value, in bps, as it is configured on the remote.
cllmLastCongestion- CLLM (Consolidated Link Layer Management) is a Frame Relay protocol used for
Cause traffic management. The cllmLastCongestionCause element indicates the last reason,
which was received from the network, for congestion on the corresponding DLCI.
Refer to cllmLastCongestionCause on page 869 for the possible values of the cllmLastCon-
gestionCause element.
lmi
This attribute gives a complete LMI status information overview.

Element Description
mode This displays the Frame Relay mode. Possible values are: noLmi, user, network, auto.
Refer to lmi on page 561 for more information on these values.
type This displays the LMI variant. Possible values are: lmiRev1, ansiT1-617-d, q933-Annex-
A, frf1-2.
Refer to lmi on page 561 for more information on these values.
status This displays the current state of LMI. Possible values are:
• up. LMI messages can and are exchanged.
• down. No LMI messages can be exchanged.
lastStatusChange This is the system-up time when the LMI status entered its current state. I.e. the
moment the value of the status element changes (from up to down or vice versa), the
system-up time value is written into the lastStatusChange element.
lastError This displays the last error condition reported by LMI. Possible values are: none,
protocol error, unknown information element, sequence error, unknown report, timer expired,
invalid report type, unsolicited status.
netTxSeqNum This is the sequence number of the last LMI Status Response frame that was sent.
Since only a Frame Relay network or DCE can transmit Status Responses, the
value of this element only changes in case the 1424 SHDSL Router is defined as
a Frame Relay network or both user and network. I.e. in case the mode element is
netRxSeqNum This is the sequence number of the last LMI Status Enquiry frame that was
received.
Since only a Frame Relay network or DCE can receive Status Enquiries, the value
Frame Relay network or both user and network. I.e. in case the mode element is
netErrors This is the number of errors on LMI commands issued by the Frame Relay network
or DCE during the last monitoredEvents period.
userTxSeqNum This is the sequence number of the last LMI Status Enquiry frame that was sent.
Since only a Frame Relay user or DTE can transmit Status Enquiries, the value of
this element only changes in case the 1424 SHDSL Router is defined as a Frame
Relay user or both user and network. I.e. in case the mode element is set to user,
auto or nni.
Element Description
userRxSeqNum This is the sequence number of the last LMI Status Response frame that was
received.
Since only a Frame Relay user or DTE can receive Status Responses, the value
Frame Relay user or both user and network. I.e. in case the mode element is set to
user, auto or nni.
userErrors This is the number of errors on LMI commands issued by the Frame Relay user or
DTE during the last monitoredEvents period.
userWaitFullEnquiry This is the number of LMI frames still to be sent before a Full Status Enquiry will
be requested.
userLastReport- This displays the type of the most recent report that was sent. Possible values are:
TypeSent
• full status. The last report contained the full status.
• link integrity. The last report only contained the link integrity information.
cllmLastCongestionCause
This attribute indicates the last reason, which was received from the network, for congestion on any of
the DLCIs. Possible values are:
• none
• short term, excessive traffic
• long term, excessive traffic
• short term, equipment failure
• long term, equipment failure
• short term, maintenance action
• long term, maintenance action
• short term, unknown cause
• long term, unknown cause
• unknown cause
12.5.4 PPP status attributes
This section describes the status attributes of the following objects:
router1424/lanInterface/pppoEClient/ppp
router1424/dslInterface/channel[wan_1]/atm/pvcTable/atm/ppp/
router1424/wanEfm/efm/pppoEClient/ppp
The PPP status attributes are:

• ip on page 871
• lcpState on page 871
• ipcpState on page 872
• bcpState on page 872
• ccpState on page 872
• lcpMyOptions on page 872
• lcpHisOptions on page 873
• ipcpMyOptions on page 873
• ipcpHisOptions on page 873
• bcpMyOptions on page 874
• bcpHisOptions on page 874
• ccpMyOptions on page 875
• ccpHisOptions on page 875
• myCompressionRatio on page 875
• hisCompressionRatio on page 875
• myAuthenState on page 876
• hisAuthenState on page 876
ip
This attribute displays the IP information of the PPP link.

Element Description
status This is the current operational status of the IP layer (layer 3) of the PPP link.
address This is the IP address of the PPP link. It is either configured or retrieved automat-
ically.
netMask This is the IP subnet mask of the PPP link. It is either configured or retrieved auto-
matically.
remote This is the IP address of the remote end of the PPP link. It is either configured or
bridging
This attribute displays the bridging status of the PPP link.

lcpState
This attribute reflects the status of the LCP (Link Control Protocol) protocol. Possible values are:
Value Description
Initial LCP handshake has not started yet.
Starting, Closed, These values correspond with the transient states in the LCP state diagram.
Stopped, Closing,
Stopping
Req-Sent The local side of the PPP link has sent an LCP request. The remote side did not
answer yet.
Ack-Rcvd The local side of the PPP link has received an LCP acknowledge from the remote
side. This is a transient state.
Ack-Sent The local side of the PPP link has acknowledged the LCP request from the remote
side.
Opened The LCP handshake succeeded.

ipcpState
This attribute reflects the status of the IPCP (Internet Protocol Control Protocol) protocol. The possible
values are the same as those of the lcpState attribute.
Refer to lcpState on page 871.
bcpState
This attribute reflects the status of the BCP (Bridging Control Protocol) protocol. The possible values are
the same as those of the lcpState attribute.
ccpState
This attribute reflects the status of the CCP (Compression Control Protocol) protocol. The possible val-
ues are the same as those of the lcpState attribute.
lcpMyOptions
During the LCP handshake, a number of options can be exchanged between the local and remote side
of the link. This attribute lists the LCP options for the router at this side (local side) of the link.
The lcpMyOptions table contains the following elements:
Element Description
option The 1424 SHDSL Router supports the following LCP options:
• 3: the Authentication-Protocol option.
• 5: the Magic-Number option.
For more information on the LCP configuration options, refer to RFC 1661.
length This is the length of the option field.
value This is the option value represented as an octet string (hexadecimal ASCII repre-
sentation).
lcpHisOptions
This attribute lists the LCP options for the router at the other side (remote side) of the link. The
lcpHisOptions table contains the same elements as the lcpMyOptions table. Refer to lcpMyOptions on page 872.
Other option values than the ones supported by the 1424 SHDSL Router may be present.
ipcpMyOptions
During the IPCP handshake, a number of options can be exchanged between the local and remote side
of the link. This attribute lists the IPCP options for the router at this side (local side) of the link.
The ipcpMyOptions table contains the following elements:
Element Description
option The 1424 SHDSL Router supports the following IPCP option:
• 3: the IP-Address option.
• ip-vso: the IP-Vendor Specific option. This is used to negotiate the netmask.
For more information on the IPCP configuration options, refer to RFC 1332.
sentation).
ipcpHisOptions
This attribute lists the IPCP options for the router at the other side (remote side) of the link. The
ipcpHisOptions table contains the same elements as the ipcpMyOptions table. Refer to ipcpMyOptions on
page 873.
bcpMyOptions
During the BCP handshake, a number of options can be exchanged between the local and remote side
of the link. This attribute lists the BCP options for the router at this side (local side) of the link.
The bcpMyOptions table contains the following elements:
Element Description
option The 1424 SHDSL Router supports the following BCP options:
• 1: the Bridge-Identification option.
• 2: the Line-Identification option.
• 3: the MAC-Support option.
• 4: the Tinygram-Compression option.
• 5: the LAN-Identification option.
• 6: the MAC-Address option.
• 7: the Spanning-Tree-Protocol option.
For more information on the BCP configuration options, refer to RFC 2878.
sentation).
bcpHisOptions
This attribute lists the BCP options for the router at the other side (remote side) of the link. The
bcpHisOptions table contains the same elements as the bcpMyOptions table. Refer to bcpMyOptions on page 874.
ccpMyOptions
During the CCP handshake, a number of options can be exchanged between the local and remote side
of the link. This attribute lists the CCP options for the router at this side (local side) of the link.
The ccpMyOptions table contains the following elements:
Element Description
option The 1424 SHDSL Router supports the following CCP option:
• 1: the Predictor1 option.
For more information on the CCP configuration options, refer to RFC 1962.
sentation).
ccpHisOptions
This attribute lists the CCP options for the router at the other side (remote side) of the link. The
ccpHisOptions table contains the same elements as the ccpMyOptions table. Refer to ccpMyOptions on page 875.
myCompressionRatio
When PPP compression is enabled, this attribute displays the compression ratio achieved by the router
at this side (local side) of the link.
hisCompressionRatio
When PPP compression is enabled, this attribute displays the compression ratio achieved by the router
at the other side (remote side) of the link.
myAuthenState
This attribute displays the authentication state of the router at this side (local side) of the link. I.e. the
state of the authenticator. Possible values are:
Value Description
No-Authentication The local side does not request PPP authentication or still has to start the CHAP
authentication (LCP handshake is busy).
Wait-On-Response The local side has sent a challenge packet and is waiting for an answer.
Authen-Successful The response packet is found to be correct. This is the state when authentication
succeeded.
Authen-Failure The response packet is found to be incorrect. This is a transient state since the
router starts the LCP handshake again after a failing authentication.
hisAuthenState
This attribute displays the authentication state of the router at the other side (remote side) of the link. I.e.
the state of the peer. Possible values are:
Value Description
No-Authentication This is the start-up state.
Wait-On-Challenge During the LCP handshake the authenticator already indicates it wants to authen-
ticate. From that moment on, the peer awaits a challenge packet.
Wait-On-Success Once the peer has sent a response, it awaits a success or failure message.
Authen-Successful The peer has received a success packet. It remains in this state during data trans-
fer.
Authen-Failure The peer has received a failure packet. This is a transient state since the router
starts the LCP handshake again after a failing authentication.
Authen-Not-Allowed This state only occurs when the peer does not accept the authentication request
during the LCP handshake. A possible reason might be that the peer router does
not support CHAP.
12.5.5 EFM status attributes
router1424/wanEfm/efm

• ip on page 878
• ifLastChange on page 880
• ipAdEntBcastAddr on page 881
• ipAdEntReasmMaxSize on page 881
• oam on page 885
• oamRemoteLoopback on page 886
ip
This attribute displays the IP information of the EFM link.

Element Description
status This is the current operational status of the IP layer (layer 3).
address This is the IP address of the interface. It is either configured or retrieved automat-
ically.
matically.
secondaryIp This is the secondary IP address that has been configured on the EFM interface.
• address. This is the secondary IP address itself.
arpCache
on the EFM link. Refer to What is the ARP cache? on page 512 for more information.
Element Description
message.
address.
value is 0.
bridging
This attribute displays the bridging status of the EFM interface.

This has already been described in the context of the LAN interface. Refer to the bridging attribute in 12.3
- LAN interface status attributes on page 831 for detailed information.
macAddress
This attribute displays the MAC address of the 1424 SHDSL Router its EFM interface.
The EFM interface has been allocated a fixed Ethernet address, also called MAC (Medium Access Con-
trol) address. The MAC address is globally unique and can not be modified. It is a 6 byte code, repre-
sented in hexadecimal format. Each byte in the code is separated by a colon.
Refer to What is the ARP cache? on page 512 for more information on the MAC addresses.
ifDescr
ifType
This attribute displays the interface type, for example: ethernet-csmacd
ifMtu
Important remark
The following explanation applies to all interfaces of the OneAccess devices:

The ifMtu is actually the MRU (Maximum Receive Unit) on a certain interface, so the maximum layer 1
frame size that can be received on a certain interface:
• On a LAN interface, this is the maximum ethernet frame size.
• On a SHDSL line running ppp, it is the maximum ppp frame size.
• On a bridgeGroup and vpnBridgeGroup interface, it has been implemented in the OneAccess devices that
the ifMtu is the MRU on IP level.
So the ifMtu is not configurable in the OneAccess devices and depends on the used hardware and is
coded in the firmware.
Note that there is no relation whatsoever between the ifMtu status attribute and the mtu configuration
attribute in the ip structure (refer to 5.2.3 - Explaining the ip structure on page 56): the mtu is configurable
and is on layer 2.
ifOperStatus
This attribute displays the current operational status of the interface.
ifLastChange
ifSpeed
ipAdEntBcastAddr
This attribute displays the value of the least-significant bit in the IP broadcast address. This address is
used for sending packets on the interface which is associated with the IP address of this entry. The value
applies to the general broadcast, the subnet and network broadcasts.
ipAdEntReasmMaxSize
This attribute displays the size of the largest IP packet which this entity can re-assemble from incoming
IP fragmented packets received on this interface.
vlan
This attribute displays the status of the VLAN(s) on the EFM link.
Element Description
E.g. lan vlan 2
mode This element displays the VLAN mode, possible values are: ces, routing, bridging, rout-
ingAndBridging, switching, frf5, frf8, multilink.
bridging This displays the bridging information of the VLAN.

Refer to the bridging attribute in 12.3 - LAN interface status attributes on page 831
for a detailed description of the bridging structure.

• identifier. This element displays the VLAN identifier.
Refer to the arpCache attribute in 12.3 - LAN interface status attributes on
page 831 for a detailed description of the arpCache table.
pppoEClient
This attribute displays the PPPoE status of the interface.

Element Description
name This element displays the administrative name of the PPPoE link.
mode This element displays by which process the packets are treated. Possible values
are:
• bridging. All packets are bridged.
• routing. The IP packets are routed. All other protocols are discarded.
• routingAndBridging. IP packets are routed. Non-IP packets are bridged.
ifOperState This element displays the current operational status of the PPPoE link.
ifLastChange This element shows the system-up time on the moment the PPPoE link entered its
current operational state. I.e. the moment the value of the ifOperStatus element
changes (from up to down or vice versa), the system-up time value is written into the
ifLastChange element.
ip This element displays IP related parameters of the PPPoE link.

• address. This is the IP address of the interface. It is either configured or retrieved
automatically.
• netMask. This is the IP subnet mask of the interface. It is either configured or
• remote. This is the IP address to the remote end of the PPPoE connection.
Initiation).
sion-confirmation).
ing the discovery.
Element Description
ppp This element displays PPP related parameters of the PPPoE link.
The ppp structure contains the following elements:
• lcpState. This element reflects the status of the LCP (Link Control Protocol) pro-
tocol. Possible values are:
- Initial. LCP handshake has not started yet.
- Starting, Closed, Stopped, Closing, Stopping. These values correspond with the
transient states in the LCP state diagram.
- Req-Sent. The local side of the PPP link has sent an LCP request. The remote
side did not answer yet.
- Ack-Rcvd. The local side of the PPP link has received an LCP acknowledge
from the remote side. This is a transient state.
- Ack-Sent. The local side of the PPP link has acknowledged the LCP request
from the remote side.
- Opened. The LCP handshake succeeded.
• ipcpState. This attribute reflects the status of the IPCP (Internet Protocol Control
Protocol) protocol. The possible values are the same as those of the lcpState
attribute above.
• myAuthenState. This element displays the authentication state of the router at this
side (local side) of the link. i.e. the state of the authenticator. Possible values
are:
- No-Authentication. The local side does not request PPP authentication or still
has to start the CHAP authentication (LCP handshake is busy).
- Wait-On-Response. The local side has sent a challenge packet and is waiting
for an answer.
- Authen-Successful. The response packet is found to be correct. This is the
state when authentication succeeded.
- Authen-Failure. The response packet is found to be incorrect. This is a tran-
sient state since the router starts the LCP handshake again after a failing
authentication.
Element Description
• hisAuthenState. This attribute displays the authentication state of the router at the
other side (remote side) of the link. i.e. the state of the peer. Possible values
are:
- No-Authentication. This is the start-up state.
- Wait-On-Challenge. During the LCP handshake the authenticator already indi-
cates it wants to authenticate. From that moment on, the peer awaits a chal-
lenge packet.
- Wait-On-Success. Once the peer has sent a response, it awaits a success or
failure message.
- Authen-Successful. The peer has received a success packet. It remains in this
state during data transfer.
- Authen-Failure. The peer has received a failure packet. This is a transient state
since the router starts the LCP handshake again after a failing authentica-
tion.
- Authen-Not-Allowed. This state only occurs when the peer does not accept the
authentication request during the LCP handshake. A possible reason might
be that the peer router does not support CHAP.
oam
For detailed information, refer to section 5 of IEEE Std. 802.3-2005, more specifically section 57. Oper-
ations, Administration, and Maintenance (OAM).
The oam structure contains the following elements:
Element Description
discovery This element displays the status of the OAM discovery process. Possible values
are:
• fault. This state indicates to the remote device that there is a link fault. This is
also the initial condition.
• sendLocal. While in this state, the 1424 SHDSL Router waits for Information
OAMPDUs received from the remote device.
• passiveWait. This state indicates that the 1424 SHDSL Router is in passive mode,
waiting to receive Information OAMPDUs with Local Information TLVs (Type
Length Value) from the remote.
• sendLocalRemote. While in this state, the 1424 SHDSL Router is sending Local
and Remote Information TLVs. Once the 1424 SHDSL Router has received an
Information OAMPDU with the Local Information TLV from the remote device,
the 1424 SHDSL Router begins sending Information OAMPDUs that contain
both the Local and Remote Information TLVs.
• sendLocalRemoteOk. If the OAM settings of both the local and remote devices are
acceptable, the 1424 SHDSL Router enters the sendLocalRemoteOk state.
• sendAny. Finally, once an OAMPDU has been received indicating that the
remote device is satisfied with the respective settings, the 1424 SHDSL Router
enters the sendAny state. This is the normal operating state for OAM on fully
operational links.
loopback This element displays the status of the OAM remote loopback mechanism. Possi-
ble values are:
• idle. The loopback mechanism is not active.
• waiting. The 1424 SHDSL Router is waiting for the remote device to reply. Note
that switching from idle to active state goes so quickly, that the waiting state will
hardly be noticable.
• active. The 1424 SHDSL Router has received an answer from the remote
device, and the loopback mechanism is active.
Element Description
localinfo These elements display specific information about the local and remote device
remoteInfo with regard to EFM OAM.
The localInfo and remoteInfo structures contain following elements:
• version. This field indicates the OAM version supported by the remote device.
• revision. This field indicates the current revision of the Information TLV (Type
Length Value). The value of this field starts at zero and will be incremented
each time something in the Information TLV changes.
• state. This field indicates indicates state information of the remote device.
• oui. This field indicates the Organizationally Unique Identifier of the vendor.
• vendorInfo. This field indicates the identifier that can be used to differentiate a
vendor’s product models and versions. This field contains the Vendor Specific
Information field.
• varRetrieval, linkEvents, loopback, unidirectional, mode, maxPduSize. For more informa-
tion about these elements, refer to IEEE Std. 802.3-2005, section 57.5.2.1
Local Information TLV, Table 57–8—OAM Configuration field and Table 57–
9—OAMPDU Configuration field.
clearArpCache
oamRemoteLoopback
Use this action to set up an OAM loop at the network side. Select start as argument value, and execute
the action.
To stop the OAM loop, select stop as argument value, and execute the action.
12.6 SHDSL line status attributes
router1424/dslInterface/line
The SHDSL line status attributes are:

• region on page 889
• eocAlarmThresholds on page 892
• numDiscoveredRepeaters on page 890
• minLinePairSpeed on page 891
• maxLinePairSpeed on page 891
• framerType on page 891
• spanStatus on page 891
• wireMode on page 891
• nrOfActivePairs on page 891
• pairOrder on page 891
This section describes the following line pair status attributes:

• status on page 893
• timeSinceLastRetrain on page 893
• lineAttenuation on page 893
• noiseMargin on page 894
• transmitPower on page 894
• actualBitRate on page 894
• stepupTreshold on page 894
• modulation on page 895
• adminStatus on page 895
• psdMeasurement on page 892
ifDescr
ifType
ifOperStatus
This attribute displays the current operational status of the line. Possible values are:
Value Description
up The line is up, data transfer is possible.
down The line is down, data transfer is not possible.
testing A line test is active.
ifSpeed
This attribute displays the current line speed in bits per second (bps).
In case of a 1424 SHDSL Router 2 pair version, the line/ifSpeed attribute displays the sum of the speed of
line pair 1 and 2.
region
This attribute displays the SHDSL standard currently used. Possible values are: auto, annexA, annexB.
Refer to region on page 581 for more information on these values.
numDiscoveredRepeaters
This attribute displays the number of Crocus SHDSL repeaters that the 1424 SHDSL Router discovered
on the SHDSL line.
minLinePairSpeed
This attribute displays the selected lowest linepair speed of the 1424 SHDSL Router.
maxLinePairSpeed
This attribute displays the selected highest linepair speed of the 1424 SHDSL Router.
framerType
This attribute displays the encapsulation that is currently being used, atm or efm.
spanStatus
The spanStatus table displays EOC related information of the local and remote device (and is linked to the
eocHandling line configuration attribute).
The spanStatus table displays eocState as Online or Offline. Online means that the EOC channel between local
and remote device has been synchronised; Offline means that there is no connection with the remote
device.
snmpIndex
This attribute displays the snmpIndex, which is a unique number, assigned to each object in the contain-
ment tree. Refer to 5.3.7 - Introducing attributes snmpIndex and snmpIndexOffset on page 74 for more infor-
mation.
wireMode
This attribute displays the current wire mode settings. Possible values are singlePair or multiPair.
nrOfActivePairs
This attribute displays the number of line pairs that are currently activated:
• If wireMode is multPair, than this attibute indicates how many line pairs are currently bundled.
• If EFM or IMA is used as encapsulation, this attribute indicates how many line pairs are currently used
by EFM or IMA (wireMode is singlePair in this situation).
pairOrder
This attribute indicates in what order the lines are present in the bundle when ATM in multi-pair mode is
used. This attribute is used as an extension of the linePairsSwapped attribute for modems that support max-
imum 2 pairs.
eocAlarmThresholds
What this attribute displays depends on the setting of the eocHandling attribute:
If eocHandling is then …
set to …
none the eocAlarmThresholds attribute does not display relevant information. It always dis-
plays 0.0.
discovery • on the central1 device, the eocAlarmThresholds attribute displays the values as set
in the linkAlarmThresholds attribute.
inventory
• on the remote2 device, the eocAlarmThresholds attribute does not display relevant
info information. It always displays 0.0.
alarmConfiguration the eocAlarmThresholds attribute displays the values as set in the linkAlarmThresholds
attribute on the central device.
The eocAlarmThresholds structure contains the following elements:

• lineAttenuation
• noiseMargin
psdMeasurement
Use this action to measure the frequency spectrum of the line signal of the 1424 SHDSL Router. Once
this action is started, the frequency and amplitude of the line signal can be measured. The 1424 SHDSL
Router will not start the handshaking process after this action has been executed.
ifOperStatus
This attribute displays the current operational status of the line pair. Possible values are:
Value Description
up The line pair is up, data transfer is possible. This is the case when the value of the
linePair[ ]/status attribute is dataState.
down The line pair is down, data transfer is not possible.
testing A line test is active.
ifSpeed
This attribute displays the line pair speed, in bits per second (bps), when the line pair is in data state.
status
This attribute displays the current status of the line pair. Possible values are:
Value Description
idle No link is present.
training A training cycle is in progress.
dataState A data link is present.
timeSinceLastRetrain
This attribute displays the elapsed time since the last retrain cycle.
lineAttenuation
This attribute displays the current line pair attenuation in dB.
The lineAttenuation attribute does not display meaningful information when the line is not trained. It is only
relevant for a line that is in data state for at least 5 minutes.
noiseMargin
This attribute displays the current signal to noise ratio on the line pair in dB.
The signalNoise attribute does not display meaningful information when the line is not trained. It is only
relevant for a line that is in data state for at least 5 minutes.
transmitPower
This attribute displays the transmit power on the line pair in dB.
actualBitRate
This attribute displays the maximum speed, in bits per second (bps), that could be negotiated on the line
pair during the training sequence.
snmpIndex
information.
stepupTreshold
This attribute displays the step-up threshold in dB.

If step-up retraining is enabled (i.e. the stepupMargin element in the line/retrain configuration structure is set
to any value other than disabled), then the 1424 SHDSL Router will retrain at a higher speed if the meas-
ured noise margin exceeds the step-up threshold value.
The stepupThreshold value =
• the noise margin at the moment the line entered the data state (i.e. shortly after a successful training
cycle)
+
• the stepupMargin value.
Refer to retrain on page 582 for more information.
If the stepupThreshold attribute displays 0.0, then this means that step-up retraining is disabled (i.e. the
stepupMargin element in the line/retrain configuration is set to disabled).
modulation
This attribute displays the modulation mode that is used on the line pair: tc-pam16, tc-pam32 or auto.
adminStatus
This attribute displays the current condition of the line pair. Possible values are:
Value Description
up This means that the linePair is currenlty activated.
down This means that the linePair is currently not activated or used.
12.7 End and repeater status attributes

• router1424/wanInterface/end/vendorId on page 897
• router1424/wanInterface/end/vendorModel on page 897
• router1424/wanInterface/end/vendorSerial on page 897
• router1424/wanInterface/end/vendorSoftVersion on page 897
• router1424/wanInterface/end/eocSoftVersion on page 897
• router1424/wanInterface/end/shdslVersion on page 898
• router1424/wanInterface/end/eocState on page 898
• router1424/wanInterface/end/eocAlarmThresholds on page 898
• router1424/wanInterface/end/linePair[ ]/lineAttenuation on page 899
• router1424/wanInterface/end/linePair[ ]/signalNoise on page 899
• router1424/wanInterface/repeater/loopbackActivation on page 899
• Exactly which information is retrieved from the remote SHDSL device(s) through the EOC channel
depends on the setting of the eocHandling attribute. Refer to 5.5.4 - Which standard EOC information
is retrieved? on page 83 for an overview.
• The repeater[ ] and end objects contain the same attributes, therefore only the attributes of the end
object are listed here.
router1424/wanInterface/end/vendorId
This attribute is only retrieved in case the eocHandling attribute is set to discovery, inventory, info or alarmCon-
figuration.
This attribute displays information about the vendor of the repeater or end device. The vendorId structure
• countryCode E.g. 65295 for Belgium.
• providerCode E.g. TLS_ for OneAccess.
• vendorSpecific
router1424/wanInterface/end/vendorModel
This attribute is only retrieved in case the eocHandling attribute is set to inventory, info or alarmConfiguration.
This attribute displays the model of the repeater or end device. E.g. SHDSL TT 2P for a Crocus SHDSL
Table Top 2 pair version.
router1424/wanInterface/end/vendorSerial
This attribute displays the serial number of the repeater or end device. For a OneAccess devices this is
the deviceId attribute (refer to router1424/deviceId on page 830).
router1424/wanInterface/end/vendorSoftVersion
This attribute displays the version of the firmware used on the repeater or end device. For a OneAccess
device this is the part after “/” of the T-code string displayed in the flashVersion attribute (refer to router1424/
flash1Version on page 828).
router1424/wanInterface/end/eocSoftVersion
figuration.
This attribute displays the EOC software version used on the repeater or end device.
router1424/wanInterface/end/shdslVersion
figuration.
This attribute displays the SHDSL version used on the repeater or end device.
router1424/wanInterface/end/eocState
figuration.
This attribute displays the state of the EOC channel.
router1424/wanInterface/end/eocAlarmThresholds
This attribute is only retrieved in case the eocHandling attribute is set to info or alarmConfiguration.
What this attribute displays depends on the setting of the eocHandling attribute:
If eocHandling is then …
set to …
info the eocAlarmThresholds attribute displays the values as set in the linkAlarmThresholds
attribute on the remote1 device.
alarmConfiguration the eocAlarmThresholds attribute displays the values as set in the linkAlarmThresholds
attribute on the central2 device.
The eocAlarmThresholds structure contains the following elements:

• lineAttenuation
• noiseMargin
router1424/wanInterface/end/linePair[ ]/lineAttenuation
This attribute displays the line attenuation, in dB, as it is measured on the line pair of the repeater or end
device.
router1424/wanInterface/end/linePair[ ]/signalNoise
This attribute displays the noise margin, in dB, as it is measured on the line pair of the repeater or end
device.
router1424/wanInterface/repeater/loopbackActivation
This action is only present in the repeater[ ] object.

Use this action to set up a loop at the network side of the Crocus SHDSL Repeater:
network loop- customer

side back side
central device repeater
Set the loop by selecting the action argument value initiateNetworkLoopback and executing the action (in
TMA, double-click the loopbackActivation string). Stop the loop by selecting the action argument value
clearAllMaintenanceStates and executing the action (in TMA, double-click the loopbackActivation string).
Important remarks
• You can only set up a loop at the network side of the Crocus SHDSL Repeater. Not at the customer
side.
• You can only start the loopbackActivation action on the central device. Not on the remote device.
• You can only start the loopbackActivation action in case the eocHandling attribute is set to alarmConfiguration.
12.8 Bundle status attributes
This section describes the status attributes of the different bundles that can be set up on the 1424
SHDSL Router. The following gives an overview of this section:
• 12.8.1 - PPP bundle status attributes on page 901
12.8.1 PPP bundle status attributes

• router1424/bundle/pppBundle[ ]/ifDescr on page 902
• router1424/bundle/pppBundle[ ]/ifType on page 902
• router1424/bundle/pppBundle[ ]/ifOperStatus on page 902
• router1424/bundle/pppBundle[ ]/ifSpeed on page 902
• router1424/bundle/pppBundle[ ]/members on page 903
• router1424/bundle/pppBundle[ ]/ip on page 904
• router1424/bundle/pppBundle[ ]/ipcpState on page 904
• router1424/bundle/pppBundle[ ]/ipcpMyOptions on page 905
• router1424/bundle/pppBundle[ ]/ipcpHisOptions on page 905
• router1424/bundle/pppBundle[ ]/bridging on page 906
• router1424/bundle/pppBundle[ ]/bcpState on page 906
• router1424/bundle/pppBundle[ ]/bcpMyOptions on page 906
• router1424/bundle/pppBundle[ ]/bcpHisOptions on page 907
• router1424/bundle/isdnBundle[ ]/bacpState on page 907
• router1424/bundle/isdnBundle[ ]/bacpMyOptions on page 907
• router1424/bundle/isdnBundle[ ]/bacpHisOptions on page 908
• router1424/bundle/pppBundle[ ]/multiclassInterfaces on page 909
• router1424/bundle/pppBundle[ ]/snmpIndex on page 910
router1424/bundle/pppBundle[ ]/ifDescr
This attribute displays the interface description of the PPP bundle.
router1424/bundle/pppBundle[ ]/ifType
This attribute displays the interface type of the PPP bundle.
router1424/bundle/pppBundle[ ]/ifOperStatus
This attribute displays the current operational status of the PPP bundle.
router1424/bundle/pppBundle[ ]/ifSpeed
This attribute displays the current speed of the PPP bundle in bits per second (bps). It is the sum of the
speeds of all the bundle links in the bundle.
router1424/bundle/pppBundle[ ]/members
This attribute displays the status of the different bundle links in the PPP bundle.
The members table contains the following elements:
Element Description
ifDescr This element displays the name of the bundle link as you entered it in the members
Refer to 6.7.11 - Setting up multilink PPP on page 177 for more information.
memberStatus This element displays the member status of the bundle link in the bundle. Possible
values are:
• notJoined. The bundle link is currently not an active member of the bundle. E.g.
because the bundle link is down.
• joined. The bundle link is currently an active member of the bundle.
• notFound. The bundle link that you specified in the members configuration attribute
could not be found. E.g. because you entered a wrong channel index name or
because you did not create a channel yet.
Refer to 6.7.11 - Setting up multilink PPP on page 177 for more information for
more information on the channels and channel index names.
ifLastChange This element displays the system-up time on the moment the bundle link entered
its current operational state. I.e. the moment the value of the memberStatus status
element changes (from notJoined to joined or vice versa), the system-up time value
is written into the ifLastChange status element.
ifSpeed This element displays the current speed of the bundle link in bits per second (bps).
router1424/bundle/pppBundle[ ]/ip
This attribute displays the IP information of the PPP bundle.

Element Description
status This is the current operational status of the IP layer (layer 3) of the PPP bundle.
address This is the IP address of the PPP bundle. It is either configured or retrieved auto-
matically.
netMask This is the IP subnet mask of the PPP bundle. It is either configured or retrieved
automatically.
remote This is the IP address of the remote end of the PPP bundle. It is either configured
or retrieved automatically.
router1424/bundle/pppBundle[ ]/ipcpState
This attribute reflects the status of the IPCP (Internet Protocol Control Protocol) protocol. Possible val-
ues are:
Value Description
Initial IPCP handshake has not started yet.
Starting, Closed, These values correspond with the transient states in the IPCP state diagram.
Stopped, Closing,
Stopping
Req-Sent The local side of the PPP link has sent an IPCP request. The remote side did not
answer yet.
Ack-Rcvd The local side of the PPP link has received an IPCP acknowledge from the remote
side. This is a transient state.
Ack-Sent The local side of the PPP link has acknowledged the IPCP request from the remote
side.
Opened The IPCP handshake succeeded.

router1424/bundle/pppBundle[ ]/ipcpMyOptions
During the IPCP handshake, a number of options can be exchanged between the local and remote side
of the link. This attribute lists the IPCP options for the router at this side (local side) of the link.
The ipcpMyOptions table contains the following elements:
Element Description
option The 1424 SHDSL Router supports the following IPCP option:
• 3: the IP-Address option.
• ip-vso: the IP-Vendor Specific Option. This is used to negotiate the netmask.
For more information on the IPCP configuration options, refer to RFC 1332.
sentation).
router1424/bundle/pppBundle[ ]/ipcpHisOptions
This attribute lists the IPCP options for the router at the other side (remote side) of the link. The
ipcpHisOptions table contains the same elements as the ipcpMyOptions table. Refer to router1424/bundle/ppp-
Bundle[ ]/ipcpMyOptions on page 905.
router1424/bundle/pppBundle[ ]/bridging
This attribute displays the bridging status of the PPP bundle.

router1424/bundle/pppBundle[ ]/bcpState
This attribute reflects the status of the BCP (Bridging Control Protocol) protocol. The possible values are
the same as those of ipcpState attribute. Refer to router1424/bundle/pppBundle[ ]/ipcpState on page 904.
router1424/bundle/pppBundle[ ]/bcpMyOptions
During the BCP handshake, a number of options can be exchanged between the local and remote side
of the link. This attribute lists the BCP options for the router at this side (local side) of the link.
The bcpMyOptions table contains the following elements:
Element Description
option The 1424 SHDSL Router supports the following BCP options:
• 1: the Bridge-Identification option.
• 2: the Line-Identification option.
• 3: the MAC-Support option.
• 4: the Tinygram-Compression option.
• 5: the LAN-Identification option.
• 6: the MAC-Address option.
• 7: the Spanning-Tree-Protocol option.
For more information on the BCP configuration options, refer to RFC 2878.
sentation).
router1424/bundle/pppBundle[ ]/bcpHisOptions
This attribute lists the BCP options for the router at the other side (remote side) of the link. The
bcpHisOptions table contains the same elements as the bcpMyOptions table. Refer to router1424/bundle/pppBun-
dle[ ]/bcpMyOptions on page 906.
router1424/bundle/isdnBundle[ ]/bacpState
This attribute reflects the status of the BACP (Bandwidth Allocation Control Protocol) protocol. The pos-
sible values are the same as those of ipcpState attribute. Refer to router1424/bundle/pppBundle[ ]/ipcpState on
page 904.
router1424/bundle/isdnBundle[ ]/bacpMyOptions
During the BACP handshake, a number of options can be exchanged between the local and remote side
of the link. This attribute lists the BACP options for the router at this side (local side) of the link.
The bacpMyOptions table contains the following elements:
Element Description
option The 1424 SHDSL Router supports the following BACP options:
• 1: the Favored-Peer option.
For more information on the BACP configuration options, refer to RFC 2125.
sentation).
router1424/bundle/isdnBundle[ ]/bacpHisOptions
This attribute lists the BACP options for the router at the other side (remote side) of the link. The
bacpHisOptions table contains the same elements as the bacpMyOptions table. Refer to router1424/bundle/isdn-
Bundle[ ]/bacpMyOptions on page 907.
router1424/bundle/pppBundle[ ]/multiclassInterfaces
This attribute displays the status of the different multiclass PPP links in the PPP bundle.
The multiclassInterfaces table contains the following elements:
Element Description
name This element displays the name of the multiclass PPP link as you defined it in the
multiclassInterfaces configuration attribute.
ifOperStatus This element displays the current operational status of the multiclass PPP link.
ifLastChange This element shows the system-up time on the moment the multiclass PPP link
entered its current operational state. I.e. the moment the value of the ifOperStatus
status attribute changes (from up to down or vice versa), the system-up time value
is written into the ifLastChange status attribute.
ip This element displays the IP information of the multiclass PPP link.

bridging This element displays the bridging information of the multiclass PPP link.
ppp This element displays the PPP information of the multiclass PPP link.
multiclass This element displays the multiclass identifier of the multiclass PPP link.
router1424/bundle/pppBundle[ ]/snmpIndex
information.
12.9 Router status attributes
This section discusses the status attributes concerned with routing. First it describes the general routing
status attributes. Then it explains the status attributes of the extra features as there are NAT, L2TP tun-
nelling, etc…
• 12.9.1 - General router status attributes on page 912
• 12.9.2 - NAT status attributes on page 924
• 12.9.3 - L2TP tunnel status attributes on page 926
• 12.9.4 - GRE tunnel status attributes on page 931
• 12.9.5 - Native IPSEC tunnel status attributes on page 934
• 12.9.6 - IKE SA status attributes on page 936
• 12.9.7 - OSPF status attributes on page 938
• 12.9.8 - BGP status attributes on page 956
• 12.9.9 - VRRP status attributes on page 970
• 12.9.10 - Firewall status attributes on page 972
• 12.9.11 - Virtual Routing and Forwarding (VRF) status attirbutes on page 975
12.9.1 General router status attributes

• router1424/ip/router/routingTable on page 913
• router1424/ip/router/igmpTable on page 916
• router1424/ip/router/dhcpBinding on page 918
• router1424/ip/router/dhcpStatistics on page 918
• router1424/ip/router/dhcpRelayInfo on page 919
• router1424/ip/router/dhcpBlackList on page 919
• router1424/ip/router/radius on page 920
• router1424/ip/router/dns on page 920
• router1424/ip/router/dnsServers on page 920
• router1424/ip/router/addrPools on page 921
• router1424/ip/router/poolReservations on page 921
• router1424/ip/router/dnsUpdateClient on page 922
• router1424/ip/router/unBlacklist on page 923
• router1424/ip/router/forceDnsUpdate on page 923
router1424/ip/router/routingTable
This attribute lists all known routes (both static and learned routes) with their operating status.
The routingTable contains the following elements:
Element Description
network This is the IP address of the destination network.
mask This is the network mask of the destination network.
gateway This is the IP address of the next router on the path to the destination network.
interface This is the interface through which the destination network can be reached. Pos-
sible values are:
• internal. The own protocol stack is used.
• <name>. The destination network can be reached through this particular inter-
face. The <name> of the interface is the name as you configured it.
Note that the “interface” can also be a DLCI, an ATM PVC, a tunnel, etc.
• discard. Packets for this destination are discarded.
encapsulation This is the used encapsulation. It is related to the interface for this route. Possible
values are:
• none. The IP packets are not encapsulated.
• ethernet. The IP packets are encapsulated with the ARPA MAC header.
• frameRelay. The IP packets are encapsulated in Frame Relay.
• ppp. The IP packets are encapsulated in PPP.
• atm. The IP packets are encapsulated in ATM.
Element Description
status This is the route status. Possible values are:

• up. The route is up, data transfer is possible.
• down. The route is down, data transfer is not possible.
• spoofing. This applies to routes through an L2TP outgoing tunnel.
It means that the route is available, but that it is not truly up (yet). I.e. the con-
nection can be made, but is currently not up. As soon as a connection is estab-
lished, then the status of the route changes from spoofing to up.
• holdDown. This applies on RIP routes.
A route enters into a hold-down state when an update packet is received that
indicates the route is unreachable. The route is marked inaccessible and adver-
tised as unreachable. However, the route is still used for forwarding packets.
When hold-down expires, routes advertised by other sources are accepted and
the route is no longer inaccessible.
Refer to ripHoldDownTime on page 623 for more information.
• closed. This applies on L2TP tunnels and VRRP. In case of …
- L2TP tunnels where you configure a main and a backup tunnel (refer to
9.4.4 - Setting up a main and back-up tunnel on page 386) and the main tun-
nel goes down, then it is not desirable that the route to the main tunnel its
status returns from up to spoofing because in that case the 1424 SHDSL
Router will keep trying to send data across the main route/tunnel. That is
why in such a case the route to the main tunnel is “artificially” blocked. I.e.
its status is set to closed.
- VRRP (refer to 7.9 - Configuring VRRP on page 247), it is sometimes desir-
able that the IP address on an Ethernet interface no longer answers to
pings, even if the Ethernet interface is up. That is why in such a case the
host route is “artificially” blocked. I.e. its status is set to closed.
preference This displays the route preference. If more than one route matches the IP destina-
tion address, this attribute determines which route is used. The route with the low-
est preference value will be used.
type This is the type of the route. Possible values are:

• host. This is a host route, i.e. a route to a single IP address instead of a complete
network. This is also used for the router its own IP address.
• internal. A route with this status is irrelevant.
• local. This is a route to a directly connected network.
• rip. This is a route that has been received via a RIP update.
• static. This is a route that has been configured, i.e. it is a static route.
• float. This is a route that has been added for a PPP link for which no local or
remote IP address was configured. These were learned from the other side.
Refer to 6.7.4 - Imposing IP addresses on the remote in PPP on page 168 for
more information.
Element Description
metric If two routes exist with the same preference, then the route with the lowest metric
value is chosen. The metric attribute serves as a cost for using the route. In most
cases it indicates the number of hops (= routers) required to reach a destination.
timeOut In case of a RIP route, the timeOut attribute displays the time the route will remain
in the routing table if no RIP updates are received anymore. For other routes this
attribute always displays 00000d 00h 00m 00s.
Example
The following figure displays an example of a routing table:
The lines in the routing table depicted above represent the following:
• Line 1 represents the default gateway, which is not defined.
• Lines 2 and 5 represent the subnets on the LAN and WAN interface respectively.
• Lines 3 and 6 represent the interface its IP addresses.
• Line 7 represents the static route to the remote LAN.
• Finally, line 4 represents the multicast address for RIP version 2.
Remark
If the LAN is not connected to the 1424 SHDSL Router, it is still possible to contact the 1424 SHDSL
Router with e.g. TMA or Telnet over the WAN link by using the IP address of the LAN interface. This
means that the status attribute router1424/lanInterface/ip/status still indicates up, although in the routingTable
the corresponding route to the network is down. This implementation seems not logical but is necessary
to insure correct operation with HP OpenView.
router1424/ip/router/igmpTable
This attribute shows the multicast address, reported by one or more clients. The igmpTable is always
updated, even if no proxy is configured.
The igmpTable contains the following elements:
Element Description
multicast This is the multicast address.
interface This is the interface name of the client(s). In case of multiple interface names, they
are separated from each other by a comma.
What is IGMP?
Internet Group Management Protocol (IGMP) is defined in RFC 1112 as the standard for IP multicasting
in the Internet.
It is used to establish host memberships in particular multicast groups on a single network. The mecha-
nisms of the protocol allow a host to inform its local router, using Host Membership Reports, that it wants
to receive messages addressed to a specific multicast group.
All hosts conforming to level 2 of the IP multicasting specification require IGMP.
IGMP topology
Consider the following multicasting topology:
In this topology …
• Client 1 and Client 2 are multicast clients.
• Router 1, 2 and 3 are multicast enabled routers.
• Server 1 is a multicast server.
The following are some characteristics of an IGMP topology:

• Only 1 IGMP proxy can be defined per device.
• The TTL of an IGMP frame is always 1. IGMP messages are never forwarded.
• An IGMP frame contains an IP router alert option.
• IGMPv1 routers may be present in the network.
The multicasting IGMP protocol can be configured on every IP interface. Refer to the igmp element in
5.2.3 - Explaining the ip structure on page 56.
A client can leave or join a multicast group by erasing or adding a multicast address from a table, defined
in the client application. A list of multicast group addresses is maintained in the routers. The reported
multicast addresses can be seen in the igmpTable. Refer to router1424/ip/router/igmpTable on page 916.
On a router interface, IGMP join and leave messages are interpreted and the multicast member list is
adapted accordingly. Multicast frames are forwarded if they are present in the multicast member list. On
a proxy interface, IGMP join and leave messages are transmitted according to the multicast member list.
Multicast frames are always forwarded.
Since IGMP is send in UDP (join/leave can be lost), the clients (proxies) are polled every 125 seconds:
• A general query is send to 224.0.0.1 (poll all systems).
• A leave group message is send to 224.0.0.2 (all routers).
router1424/ip/router/dhcpBinding
This attribute contains a list of dynamically assigned (i.e. leased) IP addresses.

The dhcpBinding table contains the following elements:
Element Description
ipAddress This is the IP address that is dynamically assigned to a client.
macAddress This is the MAC address of the client.
leaseTime This is the remaining lease time.
hostName This is the hostname of the client.
interface This is the name of the interface on which the client has been bound.
state This is the state of the lease. Possible values are leased and onHold.
router1424/ip/router/dhcpStatistics
This attribute contains the statistics of all IP address ranges that have been specified in the configuration
attribute dhcpDynamic.
The dhcpStatistics table contains the following elements:
Element Description
startRange Displays the IP start address of an IP address range.
endRange Displays the IP end address of an IP address range.
interface For the corresponding IP address range, this is the name of the interface on which
the clients have been bound.
free For the corresponding IP address range, this displays the number of IP addresses
that are still free.
leased For the corresponding IP address range, this displays the number of IP addresses
that are leased.
hold For the corresponding IP address range, this displays the number of IP addresses
that are on hold.
During power-down of the DHCP server, some leased IP addresses can still be active. Because the
duration of the power-down can not be known, all timer information about lease and hold time becomes
meaningless. Therefore, the DHCP server incorporated in the 1424 SHDSL Router sends a ping to all
leased addresses after a warm boot. When the client responds to this ping, the DHCP server resets all
timers to their default value and keeps the lease with this client.
router1424/ip/router/dhcpRelayInfo
This attribute displays the status information of the DHCP relay process in case the 1424 SHDSL Router
is configured to act as DHCP relay agent.
The dhcpRelayInfo table contains the following elements:
Element Description
sourceIntf This is the name of the interface on which the DHCP request has been received.
mac This is the MAC address of the client.
assignedIp This is the IP address that has been dynamically assigned to the client by the
remote DHCP server.
serverIp This is the IP address of the remote DHCP server.
dhcpStatus This is the status of the DHCP process. Possible values are: discover, offer, request,
decline, ack, nack, release, inform, idle.
leaseTime This is the remaining lease time.
router1424/ip/router/dhcpBlackList
This attribute displays the MAC and IP address of blacklisted clients and the reason why they are on the
black list.
The dhcpBlackList table contains the following elements:
Element Description
ipAddress This is the IP address of the blacklisted client.
macAddress This is the MAC address of the blacklisted client.
reason This is the reason why the client is on the black list. Possible values are:
• arp. The ARP request probing indicated that the IP address is already in use by
a client on the network. Refer to dhcpCheckAddress on page 633.
• ping. The ICMP Echo Request (ping) probing indicated that the IP address is
already in use by a client on the network. Refer to dhcpCheckAddress on page 633.
• alienAck. Another DHCP server assigned an IP address to the client.
• declined. The client explicitly declined the IP address that was assigned.
• networkOrBroadcast. The DHCP server tried to assign a network or broadcast
address to a client. This indicates that the IP address ranges in the DHCP
server have been misconfigured.
router1424/ip/router/radius
This attribute shows some RADIUS status information. Refer to What is RADIUS? on page 441 for more
information.
The radius structure contains the following elements:
Element Description
authServer This is the IP address of the authentication server the 1424 SHDSL Router is con-
nected to.
acctServer This is the IP address of the accounting server the 1424 SHDSL Router is con-
nected to.
pendingRequests This is the amount of pending requests on these servers.
router1424/ip/router/dns
This attribute shows some DNS status information. Refer to What is DNS? on page 1148 for more infor-
mation.
The dns table contains the following elements:
Element Description
ipAddress This is the IP address of the DNS server.
hostname This is the hostname of the DNS server.
ttl This is the time-to-live of the cached DNS data.
infiniteTimeOut This indicates that the DNS record has an infinite TTL or at least longer than 24
days.
router1424/ip/router/dnsServers
This attribute displays the IP address(es) of the DNS server(s) that have been configured or learned.
The dns table contains the following elements:
Element Description
primaryDns This is the IP address of the primary DNS server.
secondaryDns This is the IP address of the secondary DNS server.

router1424/ip/router/addrPools
This attribute shows which IP address pools have been configured. Refer to What is an IP address pool?
The addrPools table contains the following elements:
Element Description
name This is the name of the IP address pools that have been configured.
type This is the type of IP address pools that have been configured.
nrOfAddresses This is the number of IP addresses that have been configured in each address
pool.
availAddresses This is the number of IP addresses that are available in each address pool.
router1424/ip/router/poolReservations
This attribute shows which IP addresses have already been picked out of the IP address pool. Refer to
What is an IP address pool? on page 60 for more information.
The addrPools table contains the following elements:
Element Description
name This is the name of the IP address pool, as you configured it, from which the IP
addresses have been picked.
type This is the type of IP address pool from which the IP addresses have been picked.
Possible values are: list or interval.
local This is the local IP address that has been picked out of the IP address pool.
remote This is the remote IP address that has been picked out of the IP address pool.
netMask This is the subnet mask that has been picked out of the IP address pool.
interface This is the name of the interface on which the IP addresses are used.
router1424/ip/router/dnsUpdateClient
This attribute shows the status of the DNS update client.

The dnsUpdateClient table contains the following elements:
Element Description
name This is the name of each entry in the configuration table.
dnsProvider This is the selected DNS provider.

Currrently, only dynDns can be selected. In the future, other DNS providers can be
added, each with their own set of configuration and status parameters.
The dynDns structure contains following elements:
• state. This element displays the state of the update state-machine. Possible val-
ues are:
- disabled. The update state-machine is disabled.
- enabledIdle. This is the normal running state of the update state-machine, or
the update state-machine is (re)configuring.
- updating. An update communication is busy.
- stopped. An error return code caused the state-machine to stop normal oper-
ation.
- unbound. The DNS update client is not bound to any interface in the 1424
SHDSL Router. Reasons can be: a bad configuration of the interface string,
a non-existing interface is configured, or the routing application of the inter-
face is not up.
• tcpSocket. This element displays the state of the TCP socket.
• updateReturnCode. This element displays the return code.
• hostName. This element displays the fully-qualified domain name of the host that
is being updated.
• updateServer. This element displays the fully-qualified domain name of the DNS
Update Server. For DynDNS, this will be members.dyndns.org.
• lastUpdateIpAddress. This element displays the IP address that is returned in the
update communication. It should correspond to the IP address of the bound
interface.
• lastUpdateTimePassed. This element displays the time passed since the last
update communication.
router1424/ip/router/unBlacklist
This action removes an entry from the blacklist.

The unBlacklist action contains the following argument values:
Element Description
startIp Use this element to specify an IP address (range) that has to be removed from the
blacklist.
If you want to specify …
• a single IP address, then just enter the IP address in the startIp element and
leave the stopIp element at its default value (<opt>).
• an IP address range, then enter the first IP address of the range in the startIp
element and the last IP address of the range in the stopIp element.
stopIp Use this element to specify the last IP address of an IP address range that has to
be removed from the blacklist.
mac Use this element to specify a MAC address of an entry that has to be removed from
the blacklist.
router1424/ip/router/forceDnsUpdate
This action can unblock the Dynamic DNS status-machine from stopped to enabledIdle so that automatic
DNS update can recover from an errored situation.
This action is accompanied with an argument dnsUpdateName, to indicate which of the entries in the dnsUp-
dateClient table is subject to the action.
When a reconfiguration of the dnsUpdateClient table is done after an errored situation, the update state-
machine will resume operation automatically, i.e. its state will change from stopped to enabledIdle.
12.9.2 NAT status attributes

• router1424/ip/router/defaultNat/addresses on page 925
router1424/ip/router/defaultNat/addresses
This attribute displays the status of each official IP address that is configured in the configuration
attribute addresses.
The addresses table contains the following elements:
Element Description
officialAddress This is the official IP address as you entered it in the addresses configuration
attribute.
privateAddress This is the private IP address that is currently linked with the official IP address.
status This is the status of the official IP address. Possible values are:
• free. This official IP address is currently not in use.
• fixed. This address has a pre-configured mapping between the official and pri-
vate IP address.
• allocated. This official IP address is currently assigned to a private IP address,
but it is not fixed.
uses This indicates how many sessions are currently used by this official IP address.
If the attribute value becomes zero, the assigned official IP address becomes free
again and can be assigned to another private IP address.
12.9.3 L2TP tunnel status attributes

• router1424/ip/router/tunnels/l2tpTunnels on page 927
• router1424/ip/router/tunnels/ipsecL2tpTunnels on page 928
router1424/ip/router/tunnels/l2tpTunnels
This attribute displays status information of the L2TP tunnels.

Element Description
name This is the name of the tunnel as you configured it. If you did not configure a name,
then this element displays: “tunnel” <local IP address of the tunnel>.
E.g. tunnel 192.168.5.1
ifOperStatus This displays the operational status of the tunnel. Possible values are:
• up. The tunnel is up, data transfer is possible.
• down. The tunnel is down, data transfer is not possible.
• dormant. The tunnel is "stand-by". As soon as data has to be sent over the tun-
nel, control connect messages are exchanged and the operational status of the
tunnel becomes up.
ifLastChange This is the system-up time on the moment the tunnel entered its current opera-
tional state. I.e. the moment the value of the ifOperStatus status element changes
(from up to down or vice versa), the system-up time value is written into the
ifLastChange status element.
ip This displays the IP information of the tunnel.

bridging This displays the bridging information of the tunnel.

l2tp This displays the specific L2TP related status information of the tunnel.
Refer to the router1424/ip/router/tunnels/l2tpTunnels/l2tp on page 928 for a detailed descrip-
tion of the l2tp structure.
ppp This displays the PPP information of the tunnel.

router1424/ip/router/tunnels/l2tpTunnels/l2tp
The l2tp structure in the l2tpTunnels table displays the specific L2TP related status information of the tun-
nel.
The l2tp structure contains the following elements:
Element Description
localIpAddress This displays the official IP address that serves as start point of the L2TP connec-
tion.
remoteIpAddress This displays the official IP address that serves as end point of the L2TP connec-
tion.
sendingSeqNr In case sequence numbering on the data messages is enabled (dataChannelSequen-

ceNumbering = on), then this displays the transmit data sequence numbers.
receivingSeqNr In case sequence numbering on the data messages is enabled (dataChannelSequen-

ceNumbering = on), then this displays the receive data sequence numbers.
l2tpType This displays which L2TP server type the 1424 SHDSL Router currently is: LAC or
LNS.
If you set the configuration attribute l2tpMode to auto, then the status attribute l2tpType
displays the auto value until the 1424 SHDSL Routers have mutually decided who
will be the LAC and who the LNS.
controlState This displays the states associated with the LNS or LAC control connection estab-
lishment. Refer to L2TP status - control states on page 929 for more information.
callState This displays the states associated with the LNS or LAC incoming or outgoing
calls. Refer to L2TP status - call states on page 929 for more information.
deliveryState This displays the states associated with the LNS or LAC packet delivery. Refer to
L2TP status - delivery states on page 930 for more information.
authenState This displays the states associated with the LNS or LAC authentication. Refer to
L2TP status - authentication states on page 930 for more information.
router1424/ip/router/tunnels/ipsecL2tpTunnels
This attribute displays status information of the IPSEC L2TP tunnels.

The ipsecL2tpTunnels table contains the same elements as the l2tpTunnels table. Refer to router1424/ip/router/
tunnels/l2tpTunnels on page 927.
L2TP status - control states
The states associated with the LNS or LAC for control connection establishment are:
Value Description
idle No control connection is present.

Both initiator and recipient start from this state. An initiator transmits a Start Control
Connection Request, while a recipient remains in the idle state until receiving a
Start Control Connection Request.
waitCtlReply This is the state where a Start Control Connection Reply is awaited.
waitCtlConn This is the state where a Start Control Connection Connected is awaited. Upon
receipt, the challenge response is checked. The tunnel either is established, or is
torn down if an authorisation failure is detected.
established The control connection is established.

An established connection may be terminated by either a local condition or the
receipt of a Stop Control Connection Notification. The session then returns to the
idle state.
L2TP status - call states
The states associated with the LNS or LAC incoming or outgoing calls are:
Value Description
idle No data is exchanged over the tunnel.
waitTunnel This is the state in which is waited …

• either for the control connection to be opened,
• or for verification that the tunnel is already open.
Once an indication is received that the tunnel has/was opened, session control
messages may be exchanged. The first of these is the Incoming Call Request.
waitReply This is the state where an Incoming or Outgoing Call Reply message is awaited. If
an Incoming or Outgoing Call Reply message is received, an incoming or Outgoing
Call Connected message is sent and the session moves to the established state.
waitConnect This is the state where an Incoming or Outgoing Call Connected message is
awaited. If an Incoming or Outgoing Call Connected message is received, the call
was successful and the session moves to the established state.
established Data is exchanged over the tunnel.

The session is terminated when receiving or sending a Call Disconnect Notify mes-
sage. The session then returns to the idle state.
L2TP status - delivery states
The states associated with the packet delivery are:
Value Description
operating The 1424 SHDSL Router has sent a packet, but has not received an acknowledge-
ment on this packet yet.
idle All transmitted packets have been acknowledged.
L2TP status - authentication states
The states associated with the LNS or LAC authentication are:
Value Description
noAuthentication Authentication is not enabled. This is also the start-up state for the authentication
process.
authenSuccessful Authentication was successful. The 1424 SHDSL Router remains in this state dur-
ing data transfer.
authenFailure Authentication failed. This is a transient state since the 1424 SHDSL Router starts
the handshake again after a failing authentication.
12.9.4 GRE tunnel status attributes

• router1424/ip/router/tunnels/greTunnels on page 932
• router1424/ip/router/tunnels/ipsecGreTunnels on page 933
router1424/ip/router/tunnels/greTunnels
This attribute displays status information of the GRE tunnels.

Element Description
name This element displays the unique interface name of the GRE Tunnel.
mode This element displays the mode of the interface.
ifOperStatus This element displays the status of the GRE tunnel. Possible values are:
• down. The tunnel is not operational.
• up. The tunnel is operational.
• dormant. The tunnel is dormant.
(from up to down or vice versa), the system-up time value is written into the ifLastCh-
ange status element.

•
gre The gre structure displays the GRE related parameters of the tunnel. The gre struc-
ture contains following elements:
• localIpAddress. This is the local IP address of tunnel endpoint.
• remoteIpAddress. This is the remote IP address of tunnel endpoint.
• state. This element displays the current state of the GRE tunnel. Possible values
are:
- setup. The proces of bringing up the tunnel has started.
- resolvingRemote. The remote address will be resolved through DNS resolving.
- resolvingLocal. The local address will be resolved by finding a valid (up) route
for the remote address.
- open. The GRE tunnel is waiting for a tunnel endpoint to connect.
- spoofing. The GRE tunnel is configured as on-data, waiting for user data to
be operational.
- down. The GRE tunnel is not operational (no route found).
- up. The GRE tunnel is operational.
router1424/ip/router/tunnels/ipsecGreTunnels
This attribute displays status information of the IPSEC GRE tunnels.

The ipsecGreTunnels table contains the following elements:
Element Description
name This element displays the unique interface name of the IPSEC GRE Tunnel.
mode This element displays the mode of the interface.
ifOperStatus This element displays the status of the IPSEC GRE tunnel. Possible values are:
• down. The tunnel is not operational.
• dormant. The tunnel is dormant.
(from up to down or vice versa), the system-up time value is written into the ifLastCh-
ange status element.

•
gre The gre structure displays the IPSEC GRE related parameters of the tunnel. The
gre structure contains following elements:
• localIpAddress. This is the local IP address of tunnel endpoint.
• remoteIpAddress. This is the remote IP address of tunnel endpoint.
• ike. This element displays the IKE state for this tunnel. Possible values are:
- idle. IKE is not configured.
- down. IKE is down.
- setup. IKE is being set up.
- up. IKE is up.
- rollover. The re-keying process is busy.
• state. This element displays the current state of the IPSEC GRE tunnel. Possi-
ble values are:
- setup. The proces of bringing up the tunnel has started.
- resolvingRemote. The remote address will be resolved through DNS resolving.
- resolvingLocal. The local address will be resolved by finding a valid (up) route
for the remote address.
- open. The IPSEC GRE tunnel is waiting for a tunnel endpoint to connect.
- spoofing. The IPSEC GRE tunnel is configured as on-data, waiting for user
data to be operational.
- down. The IPSEC GRE tunnel is not operational (no route found).
- up. The IPSEC GRE tunnel is operational.
12.9.5 Native IPSEC tunnel status attributes

• router1424/ip/router/tunnels/ipsecTunnels on page 935
router1424/ip/router/tunnels/ipsecTunnels
This attribute displays status information of the IPSEC tunnels.

Element Description
name This is the administrative name of the tunnel.
localIpAddress This is the official IP address that serves as start point of the IPSEC tunnel.
remoteIpAddress This is the IP address that serves as end point of the IPSEC tunnel.
This could be the result after the DNS resolving of the configuration attribute remot-
eDnsName.
operStatus This element displays the status of the IPSEC tunnel. Possible values are:
• down. The tunnel is not operational, probably IKE is down.
• resolvingRemote. The endpoint of the tunnel remoteDnsName will be resolved by
means of a DNS request.
• resolvingLocal. The local address should be resolved by finding a valid route for
the remote address. This route should be up.
• setup. The tunnel is being configured.
• delete. The tunnel will be deleted soon.
• new. A new tunnel has been added and has not yet been configured.
• waitDnsReply. Waiting for a DNS reply, which means the tunnel endpoint is being
resolved.
• spoofing. The tunnel is in spoofing state. Outgoing dial tunnels will stay in spoof-
ing state as long as no data is present to send through the tunnel.
• initSA. The SA will be configured next, this could either be an IKE SA or a Manual
SA.
• waitUp. The tunnel is putting routes up and will change its state to up after 1s.
lastChange This element displays the system up time on the moment the tunnel entered its
current operational state.
ike This element displays the IKE state for this tunnel. Possible values are:
• idle. IKE is not configured.
• down. IKE is down.
• setup. IKE is being set up.
• up. IKE is up.
• rollover. The re-keying process is busy.
12.9.6 IKE SA status attributes

• router1424/ip/router/ikeSA[ ]/clearSAs on page 937
router1424/ip/router/ikeSA[ ]/phase1
This attribute displays status information of phase 1 in the IKE negotiation process.
The phase1 table contains the following elements:
Element Description
remoteIp This element displays the IP address of the remote.
remainingSecs This element displays the time the IKE SA will remain active for.
router1424/ip/router/ikeSA[ ]/phase2
This attribute displays status information of phase 2 in the IKE negotiation process.
Element Description
tunnel This element displays the L2TP tunnel name.
direction This element displays the direction of the IPSEC SA. Possible values are: inbound
or outbound.
spi This element displays the Security Parameter Index of the IPSEC SA.
protocol This element displays which protocol is used in the IPSEC SA. Possible values
are: esp or ah.
encapsulation This element displays which encapsulation is used in the IPSEC SA. Possible val-
ues are: transport l2tp, transport gre and tunnel.
localIp This element displays the local IP address.
remoteIp This element displays the remote IP address.
natTraversel This element displays whether natTraversel is active or not. Possible values are:
active and inactive.
encryptionAlgorithm This element displays which encryption algorithm is used on the IPSEC SA. Pos-
sible values are: null, des, 3des or disabled.
authenticationAlgo- This element displays which authentication algorithm is used on the IPSEC SA.
rithm Possible values are: hmac_md5, hmac_sha-1 or disabled.
age This element displays the age of the IPSEC SA.
softLifeTime This element displays the soft life time of the IPSEC SA.
When the soft life time expires, the IKE peers know that the hard lifetime is about
to expire. This gives them the time to rekey the SA without disrupting communica-
tion before the hard lifetime expires.
hardLifeTime This element displays the hard life time of the IPSEC SA.
When the hard life time expires, the IPSEC SA is actually disconnected.
router1424/ip/router/ikeSA[ ]/clearSAs
Use this action to clear all SAs.

12.9.7 OSPF status attributes
This section discusses the status attributes concerned with OSPF. First it describes the general OSPF
status attributes. Then it explains the OSPF area status attributes.
• General OSPF status attributes on page 939
• Area status attributes on page 944
General OSPF status attributes

• router1424/ip/router/ospf/type on page 940
• router1424/ip/router/ospf/routes on page 941
• router1424/ip/router/ospf/externalRoutes on page 942
• router1424/ip/router/ospf/asExtLsas on page 943
router1424/ip/router/ospf/type
This attribute indicates the kind of router link being described.

The type structure contains the following elements
Element Description
areaBorder This element indicates whether the router is an Area Border Router.
asbr This element indicates whether the router is an Autonomous System Border
Router.
Refer to 7.6.1 - Introducing OSPF on page 213 for more information.
virtualLink This element indicates whether a virtual link is present on the router.
wildCardMulticast This element indicates whether multicast extensions are supported by the router.
Note that wildcard multicast is not yet supported by the 1424 SHDSL
Router.
nssaTranslator This element indicates whether the router is an NSSA border router translator.
router1424/ip/router/ospf/routes
This attribute displays all detected routes in the OSPF network. All detected routes are transferred to the
routing table of this router as type OSPF.
The routes table contains the following elements:
Element Description
network This element displays the IP address of the sub network.
mask This element displays the network mask.
type This element displays the type of the network. Possible values are:
• direct. This value indicates a direct route. This is a route to a host connected
directly to the router.
• intra. This value indicates an intra-area route. This is a route with destinations
belonging to one of the router's attached areas.
• inter. This value indicates an inter-area route.This is a route with destinations in
other OSPF areas.
• extType1. This value indicates an external route of type 1.
• extType2. This value indicates an external route of type 2.
• reject. This value indicates a rejected route.
• static. This value indicates a static route.
• none. This value indicates a non-existing route.
cost This element displays the cost of the route.

There are two exceptions, when another value is displayed. These are:
• unknown. This value indicates that the cost of the route is unknown.
• infinite. This value indicates that the route is not available.
gateway This element displays the IP address of the next interface on the path to the des-
tination network.
outgoingIp This element displays the IP address of the outgoing router interface.
interface This element displays the administrative name of the interface.

router1424/ip/router/ospf/externalRoutes
This attribute displays all external routes which are injected into the OSPF network by this router.
The externalRoutes table contains following elements:
Element Description
network This element displays the IP address of the sub network.
mask This element displays the network mask.
gateway This element displays the IP address of the next interface on the path to the des-
tination network.
interface This element displays the administrative name of the interface.
costType This element displays the type of cost of the external route. Possible values are:
• type1. The type of cost of the external route is type 1.
Also refer to router1424/ip/router/ospf/importFilter on page 708.

There are two exceptions, when another value is displayed. These are:
• unknown. This value indicates that the cost of the route is unknown.
• infinite. This value indicates that the route is not available.
tag This element displays the 32-bit field attached to each external route. This is not
used by the OSPF protocol itself. It is used to communicate information between
AS boundary routers.
advertise This element displays whether the router advertises the external route to the rest
of the OPSF network. Possible values are:
• yes. The router advertises the external route to the rest of the OPSF network.
• no. The router does not advertise the external route to the rest of the OPSF net-
work.
routeType This element displays how the external route is injected into OSPF. Possible val-
ues are:
• static. Static route configured by the user.
• rip. This route was learned through the rip protocol.
router1424/ip/router/ospf/asExtLsas
This attribute displays the database entries for all external routes in the OSPF network.
The asExtLsas table contains following elements:
Element Description
linkStateId This element displays the portion of the network that is being described by the
LSA. The contents of this field depend on the type of LSA.
advRouterId This element displays the router ID of the router that originated the LSA.
age This element displays the time in seconds since the LSA was originated.
sequenceNr This element displays the LS sequence number (successive instances of an LSA
are given successive LS sequence numbers).
options This element indicates if the advertising router supports optional OSPF capabili-
ties. Routers of differing capabilities can be mixed within an OSPF routing domain.
The options structure contains the following elements:
• floodExternal. Entire OSPF areas can be configured as "stubs". AS-external-
LSAs will not be flooded into stub areas. This capability is represented by the
element floodExternal.
• multicast. This element indicates whether IP multicast datagrams are forwarded.
• nssa. This element indicates whether the router supports nssa area‘s.
• externalAttributes. This element indicates the router's willingness to receive and
forward external LSAs.
• demandCircuit. This element indicates the router's handling of demand circuits.
• opaque. This element indicates if the router can handle opaque-LSAs.
netMask This element displays the IP address mask for the advertised destination.
Also refer to router1424/ip/router/ospf/importFilter on page 708.
cost This element displays the cost of this route.
tag This element displays a 32-bit field attached to each external route. This is not
forwardAddress This element displays the address to which data traffic for the advertised destina-
tion is forwarded to.
Area status attributes

• router1424/ip/router/ospf/area[ ]/interfaces on page 945
• router1424/ip/router/ospf/area[ ]/hosts on page 947
• router1424/ip/router/ospf/area[ ]/neighbors on page 947
• router1424/ip/router/ospf/area[ ]/routers on page 949
• router1424/ip/router/ospf/area[ ]/routerLsas on page 950
• router1424/ip/router/ospf/area[ ]/networkLsas on page 952
• router1424/ip/router/ospf/area[ ]/summLsas on page 953
• router1424/ip/router/ospf/area[ ]/asbrLsas on page 954
• router1424/ip/router/ospf/area[ ]/nssaLsas on page 955
router1424/ip/router/ospf/area[ ]/interfaces
This attribute displays all interfaces available in the area. If an interface is part of more than one network,
the interface belongs to the network with the most significant subnet mask.
The interfaces table contains following elements:
Element Description
name This element displays the name of the interface.
address This element displays the IP address of the interface.
netMask This element displays the subnet mask.
network This element displays the name of the sub network the interface is part of.
type This element displays the interface type. Possible values are:
• pointToPoint: The interface is a point-to-point interface.
• broadcast: The interface is a broadcast interface.
• virtualLink: The interface is a virtual link interface.
• loopback: The interface is a loopback interface.
cost This element displays the cost of the link.
priority This element displays the priority of the network.
status This element displays the status of the router interface.

Refer to router1424/ip/router/ospf/area[ ]/interfaces/status on page 946 for more information.
dr This element displays the IP address of the Designated Router of the sub network.
backupDr This element displays the IP address of the Backup Designated Router.
neighbors This element displays the amount of neighbors of the router.
adjNeighbors This element displays the amount of adjacent neighbors of the router.
bandwidth This element displays the bandwidth of the link.

router1424/ip/router/ospf/area[ ]/interfaces/status
The states are listed in order of progressing functionality. For example, the inoperative state is listed
first, followed by a list of intermediate states before the final, fully functional state is achieved.
Value Description
unknown The router status is unknown.
down This is the initial interface state. No protocol traffic at all will be sent or received.
loopback The router's interface to the network is looped back. The interface will be unavail-
able for regular data traffic.
waiting The router is trying to determine the identity of the (Backup) Designated Router for
the network. To do this, the router monitors the Hello Packets it receives. The
router is not allowed to elect a Backup Designated Router nor a Designated Router
until it transitions out of Waiting state. This prevents unnecessary changes of
(Backup) Designated Router.
pointToPoint The interface is operational, and connects either to a physical point-to-point net-
work or to a virtual link. Upon entering this state, the router attempts to form an
adjacency with the neighbouring router. Hello Packets are sent to the neighbour
every helloInterval seconds.
drOther The interface is connected to a broadcast or NBMA network on which another

router has been selected to be the Designated Router. In this state, the router itself
has not been selected Backup Designated Router either. The router forms adja-
cencies to both the Designated Router and the Backup Designated Router (if they
exist).
backupDr The router itself is the Backup Designated Router on the attached network. It will
be promoted to Designated Router when the present Designated Router fails. The
router establishes adjacencies to all other routers attached to the network.
dr In this state, this router itself is the Designated Router on the attached network.
Adjacencies are established to all other routers attached to the network. The router
must also originate a network-LSA for the network node.
router1424/ip/router/ospf/area[ ]/hosts
This attribute displays all hosts in the OSPF network.

Loopback interfaces that are added to the OSPF network are referred to as hosts. The loop-back inter-
face is a software interface which can be used for management purposes. This interface is always up,
regardless of the state of the physical interfaces.
The hosts table contains following elements
Element Description
intfName This element displays the administrative name of the loop-back interface.
address This element displays the IP address of the loop-back interface.
netMask This element displays the subnet mask of the loop-back interface.
network This element displays the administrative name of the network that the loop-back
interface is part of.
cost This element displays the cost of the loop-back interface link.
router1424/ip/router/ospf/area[ ]/neighbors
This attribute displays the neighbours of the router.

Routers that share a common segment become neighbours on that segment. Neighbours are discov-
ered via the Hello protocol. Bidirectional communication is indicated when the router sees itself listed in
the neighbour’s Hello Packet.
The neighbors table contains following elements:
Element Description
interface This element displays the administrative name of the neighbouring interface.
routerId This element displays the unique sequence number for the router in the OSPF net-
work.
routerPriority This element displays the priority of the neighbouring router.
ipAddress This element displays the IP address of the neighbouring interface.
status This element displays the status of the neighbouring router.

Refer to router1424/ip/router/ospf/area[ ]/neighbors/status on page 948 for more information.
router1424/ip/router/ospf/area[ ]/neighbors/status
The states are listed in order of progressing functionality. For example, the inoperative state is listed
first, followed by a list of intermediate states before the final, fully functional state is achieved.
Value Description
down This is the initial state of a neighbour conversation. It indicates that there has been
no recent information received from the neighbour.
attempt This state is only valid for neighbors attached to NBMA networks. It indicates that
no recent information has been received from the neighbour, but that a more con-
certed effort should be made to contact the neighbour. This is done by sending
the neighbour Hello packets at intervals of helloInterval
init An Hello packet has recently been seen from the neighbour. However, bidirec-
tional communication has not yet been established with the neighbour (i.e., the
router itself did not appear in the neighbour’s Hello packet). All neighbors in this
state (or higher) are listed in the Hello packets sent from the associated interface.
2way Communication between the two routers is bidirectional. This has been assured
by the operation of the Hello Protocol.
exchangeStart This is the first step in creating an adjacency between the two neighbouring rout-
ers. The goal of this step is to decide which router is the master. Neighbour con-
versations in this state or greater are called adjacencies.
exchange The router is describing its entire link state database by sending Database
Description packets to the neighbour. Link State Request Packets may also be
sent asking for the neighbour’s more recent LSAs.
loading Link State Request packets are sent to the neighbour asking for the more recent
LSAs that have been discovered (but not yet received) in the Exchange state.
fullAdjacency The neighbouring routers are fully adjacent. These adjacencies will now appear in
router-LSAs and network-LSAs.
router1424/ip/router/ospf/area[ ]/routers
This attribute displays all routers in the current area.

The routers table contains following elements:
Element Description
routerId This element displays the unique sequence number for the router in this OSPF
autonomous system.
gateway This element displays the IP address of the next interface on the path to reach this
router.
routerType This element indicates which type of router is detected.

The routerType structure contains the following elements:
• areaBorder. This element indicates that the detected router is an Area Border
Router (ABR).
• asbr. This element indicates that the detected router is an Autonomous System
Border Router (ASBR).
• virtualLink. This element indicates that the link to the detected router is a virtual
link.
• wildCardMulticast. This element indicates if multicast extensions are supported by
the router.
router1424/ip/router/ospf/area[ ]/routerLsas
This attribute displays the router-LSAs.

Each router in an area originates router-LSAs. The LSA describes the state and cost of the router's links
(i.e., interfaces) to the area. All of the router's links to the area must be described in a single router-LSA.
The routerLsas table contains following elements:
Element Description
linkStateId This element displays the router's OSPF Router ID.

It displays the portion of the network that is being described by the LSA. The con-
tents of this field depend on the type of LSA.
advRouterId This element displays the router ID of the router that originated the LSA.
The options structure contains following elements:
routerType This element indicates the kind of router link being described. The routerType struc-
ture contains following elements:
• areaBorder. This element indicates a link to an ABR.
• asbr. This element indicates a link to an ASBR.
• virtualLink. This element indicates a virtual link.
• wildCardMulticast. This element indicates a multicast link.
linkNr This element displays the number of router links described in this LSA.
linkId This element identifies the object that this router link connects to. When connecting
to an object that also originates an LSA (i.e., another router or a transit network)
the Link ID is equal to the neighbouring LSAs Link State ID. This provides the key
for looking up the neighbouring LSA in the link state database during the routing
table calculation.
Element Description
linkData The value of this element depends on the linkType:

• For connections to stub networks, linkData specifies the network's IP address
mask.
• For unnumbered point-to-point connections, it specifies the interface's MIB-II
interface Index value.
• For the other link types it specifies the router interface's IP address.
This latter piece of information is needed during the routing table build process,
when calculating the IP address of the next hop.
linkType This element displays the type of the link. Possible values are:
• pointToPoint. The link is a point-to-point connection.
• transit. The link is a transit connection.
• stub. The link is a connection within a stub area.
• virtualLink. The link is a virtual link.
cost This element displays the cost of this link.

router1424/ip/router/ospf/area[ ]/networkLsas
This attribute displays the network-LSAs.

A network-LSA is originated for each network in the area which supports two or more routers. The net-
work-LSA is originated by the network's Designated Router. The LSA describes all routers attached to
the network, including the Designated Router itself.
The networkLsas table contains following elements:
Element Description
linkStateId This element displays the IP interface address of the Designated Router.
It displays the portion of the network that is being described by the LSA. The con-
tents of this field depend on the type of LSA.
AdvRouterId This element displays the router ID of the router that originated the LSA.
netMask This element displays the IP address mask for the network.
linkNr This element displays the number of router links described in this LSA.
routerId This element displays the router IDs of each of the routers attached to the network.
Only those routers that are fully adjacent to the Designated Router are listed. The
Designated Router itself is included in this list.
router1424/ip/router/ospf/area[ ]/summLsas
This attribute displays the Summary-LSAs. Summary-LSAs are originated by area border routers and
describe inter-area destinations.
The summLsas table contains following elements:
Element Description
linkStateId If the destination is an IP network, then the linkStateId element is an IP network

number. If the destination is an AS boundary router, then the linkStateId element is
the AS boundary router's OSPF Router ID.
This element displays the portion of the network that is being described by the
netMask This element displays the IP address mask for the destination network.

router1424/ip/router/ospf/area[ ]/asbrLsas
This attribute displays the ASBR-LSAs.

The asbrLsas table contains following elements:
Element Description

router1424/ip/router/ospf/area[ ]/nssaLsas
This attribute displays the NSSA-LSAs.

The nssaLsas table contains following elements:
Element Description
netMask This element displays the IP address mask for the advertised destination.
tag This element displays a 32-bit field attached to each external route. This is not
forwardAddress This element displays the address to which data traffic for the advertised destina-
tion is forwarded to.
12.9.8 BGP status attributes
This section discusses the status attributes concerned with BGP. First it describes the general BGP sta-
tus attributes, followed by the ePeer, iPeer, routeFilter and routeMap status attributes.
As the BGP protocol encodes route networks in [prefix, length] format, all status information is displayed
in this internal BGP format:
• prefix: This is the IP address prefix.
• length: This is the length in bits of the IP address prefix. A length of zero indicates a prefix that
matches all IP addresses.

• General BGP-4 status attributes on page 957
• ePeer and iPeer status attributes on page 962
• routeFilter status attributes on page 966
• routeMap status attributes on page 968
General BGP-4 status attributes

• router1424/ip/router/bgp/networks on page 958
• router1424/ip/router/bgp/aggregates on page 958
• router1424/ip/router/bgp/rib on page 959
• router1424/ip/router/bgp/peers on page 961
router1424/ip/router/bgp/networks
This attribute displays displays the configured networks in the internal BGP format.
The networks table contains the following elements:
Element Description
prefix This element displays the IP address prefix.
length This element displays the length in bits of the IP address prefix. A length of zero
indicates a prefix that matches all IP addresses.
router1424/ip/router/bgp/aggregates
This attribute displays displays the configured aggregates in the internal BGP format.
The aggregates table contains the following elements:
Element Description
prefix This element displays the IP address prefix of the configured aggregates.
length This element displays the length in bits of the IP address prefix of the configured
aggregates. A length of zero indicates a prefix that matches all IP addresses.
summaryOnly This element displays whether or not all advertisements of more-specific routes
from the updates are suppressed. Possible values are:
• enabled: Only the aggregate will be distributed.
• disabled: All advertisements of more-specific routes will be distributed.
asSet This element displays whether or not the aggregate route with the atomic aggre-
gate attribute present, is distributed. Possible values are:
• enabled: The path advertised for this route will consist of all elements contained
in all paths that are being summarized.
• disabled: The atomic aggregate attribute is not present in the distributed aggre-
gate route.
router1424/ip/router/bgp/rib
This attribute displays the routing information base, which shows the entries in the BGP routing table.
The rib table contains the following elements:
Element Description
prefix This element displays the IP address prefix.
length This element displays the length in bits of the IP address prefix. A length of zero
indicates a prefix that matches all IP addresses.
status This element displays the status of the BGP route. Possible values are:
• invalid. The route is not valid.
• valid. The route is a valid BGP route but another route for same the destination
is preferred.
• selected. The route is selected by the BGP route selection process.
• suppressed. The route falls into an aggregate range with flag summaryOnly ena-
bled and will not be forwarded.
type This element displays the properties of the BGP route. Possible values are:
• ibgp. The route is received through an iPeer.
• ebgp. The route is received through an ePeer.
• network. The route is imported locally through a network definition.
• aggregate. The route is distributed through an aggregate definition.
• local. The route is imported locally from the system routing table.
• static. The route is imported locally from the system routing table.
• rip. The route is imported locally from the system routing table.
• ospf. The route is imported locally from the system routing table.
• radius. The route is imported locally from the system routing table.
Element Description
attributes This element displays the values of the different attributes as defined in the BGP
protocol. There is however one exception: weight, which is a parameter local to
each router. The attributes structure contains following elements:
• nextHop. This is the IP address of the router that should be used as the next hop
of the prefix destination.
• weight. This is the local weight of the route as set on the incoming peer or
through routeMaps. Routes learned through another BGP peer have a default
weight of zero, and routes sourced by the local router have a default weight of
32768.
• localPref. This is the degree of preference when advertising a route to its internal
peers.
• asPath. This element identifies the autonomous systems through which the rout-
ing information in this update message has passed.
• origin. This element is generated by the BGP speaker that originates the asso-
ciated routing information. Possible values are: igp, egp, incomplete.
• med. This is the metric used by the BGP decision process.
• atomicAggr. This element indicates whether or not the atomicAggregate attribute is
included in the aggregated route. Possible values are: yes or no.
If an aggregate is configured with the asSet flag disabled, dropping the asSet
path which is normally formed by combining the different paths of the aggre-
gated routes, the atomicAggregate attribute should be included in the aggregated
route.
• aggregator. The aggregator structure contains the AS number and IP address of
the BGP speaker that formed the aggregate route.
• unknownTrans. This element is a binary representation of transitive attributes
which are not recognized by this BGP speaker, but which should be passed
along to other BGP peers.
router1424/ip/router/bgp/peers
This attribute gives an overview of the created iPeers and ePeers. The peers table contains following ele-
ments:
Element Description
type This element displays the type of peer. Possible values are:
• ibgp. The peer is an internal peer.
• ebgp.The peer is an external peer.
name This element displays the name of the peer.
remote This structure displays BGP information about the remote speaker. The remote
• address. This is the IP address of the remote speaker.
• asNr. This is the number of the Autonomous System the remote speaker is part
of.
• id. This is the router ID that identifies the remote speaker within the BGP sys-
tem.
status This element displays the status of the peer. Possible values are:
• shutdown. The peer is shut down by a user action and will not try to make a con-
nection again.
• idle, connect, active, openSent, openConfirm, established. These are states of the BGP
peer state machine when trying to make a connection.
upTime This element displays the period during which this peer has reached the estab-
lished state.
warning This element displays messages informing the user if a restart or softReset action is
required to have a consistent RIB (routing information base) table due to certain
reconfigurations, e.g. routeFilter or routeMap reconfigurations.
ePeer and iPeer status attributes

• router1424/ip/router/bgp/ePeer[ ]/status on page 963
• router1424/ip/router/bgp/ePeer[ ]/upTime on page 963
• router1424/ip/router/bgp/ePeer[ ]/remote on page 963
• router1424/ip/router/bgp/ePeer[ ]/timers on page 963
• router1424/ip/router/bgp/ePeer[ ]/adjSoftIn on page 964
• router1424/ip/router/bgp/ePeer[ ]/adjRibIn on page 964
• router1424/ip/router/bgp/ePeer[ ]/adjRibOut on page 964
• router1424/ip/router/bgp/ePeer[ ]/warning on page 965
• This section describes the following actions:
• router1424/ip/router/bgp/ePeers[ ]/shutDown on page 965
• router1424/ip/router/bgp/ePeer[ ]/restart on page 965
• router1424/ip/router/bgp/ePeer[ ]/softReset on page 965
The attributes above all refer to the ePeer object. The attributes of the iPeer object are identical.
router1424/ip/router/bgp/ePeer[ ]/status
This attribute displays the status of the external peer. Possible values are: shutDown, idle, connect, active,
openSent, openConfirm, established.
router1424/ip/router/bgp/ePeer[ ]/upTime
This attribute displays the period during which this peer has reached the established state.
router1424/ip/router/bgp/ePeer[ ]/remote
This attribute displays BGP information of the remote speaker. The remote structure contains following
elements:
• asNr. This element shows the number of the Autonomous System the remote speaker is part of.
• id. This element shows the router ID that identifies the remote speaker withing the BGP system.
router1424/ip/router/bgp/ePeer[ ]/timers
This attribute displays timer values, resulting from the negotiation between the peer neighbors. The timers
• keepAlive: This element displays the value of the keepAlive interval.
• holdTime: the holdTime is the smallest of its configured holdTime and the holdTime received in the open
message from the neighbor. The holdTime must be either zero or at least three seconds. If the nego-
tiated holdTime interval is zero, periodic keep alive messages must not be sent.
router1424/ip/router/bgp/ePeer[ ]/adjSoftIn
This attribute displays the unfiltered, unmodified incoming updates from this neighbor when softReconfig
is enabled. They are stored separately and displayed in this table.
This attribute contains the elements prefix, length and attributes. For a detailed explanation, refer to
router1424/ip/router/bgp/rib on page 959.
router1424/ip/router/bgp/ePeer[ ]/adjRibIn
This attribute displays the entries in the rib table of the BGP router object which are received through
this peer after filtering and routeMapping.
This attribute contains the elements prefix, length, status, type and attributes. For a detailed explanation, refer
to router1424/ip/router/bgp/rib on page 959.
router1424/ip/router/bgp/ePeer[ ]/adjRibOut
This attribute displays the entries in the rib table of the BGP router object which are sent out through this
peer in update packets, after applying the outbound routeFilters and routeMaps on this peer.
This attribute contains the elements prefix, length and attributes. For a detailed explanation, refer to
router1424/ip/router/bgp/rib on page 959.
router1424/ip/router/bgp/ePeer[ ]/warning
This attribute displays a message informing the user if a restart or softReset action is required to have a
consistent RIB table due to certain reconfigurations, e.g. routeFilter or routeMap reconfigurations
router1424/ip/router/bgp/ePeers[ ]/shutDown
Use this action to close the peer.
router1424/ip/router/bgp/ePeer[ ]/restart
Use this action to execute a full restart of the peer, bringing down the TCP connection, and start from
zero.
router1424/ip/router/bgp/ePeer[ ]/softReset
Use this action to execute a softReset of the peer.

The softReset action has the following argument values:
Value Description
inBound Use this value to reset the inbound connection.

If softReset is enabled on this peer, re-apply the inbound filters and inbound maps
on the adjSoftIn tables; refer to router1424/ip/router/bgp/ePeer[ ]/adjSoftIn on page 964.
outBound Use this value to reset the outbound connection.

If softReset is enabled on this peer, re-apply the outbound filters and outbound maps
to the rib table (refer to router1424/ip/router/bgp/rib on page 959), and send new updates
to the neighbor.
both Use this value to execute both an inbound and outbound softReset.
routeFilter status attributes

• router1424/ip/router/bgp/routeFilter[ ]/snmpIndex on page 967
• router1424/ip/router/bgp/routeFilter[ ]/users on page 967
router1424/ip/router/bgp/routeFilter[ ]/snmpIndex Default:<empty>

This attribute displays the snmpIndex, which is a unique number, assigned to
each object in the containment tree. Refer to 5.3.7 - Introducing attributes snmpIndex and snmpIndexOffset
router1424/ip/router/bgp/routeFilter[ ]/users
This attribute displays a list of all BGP entities which refer to and use this routeFilter object.
The users table contains following elements:
Element Description
type This element shows the object type which is refering to this routeFilter object. Pos-
sible values are:
• iPeer. An internal peer is refering to this routeFilter object.
• ePeer. An external peer is refering to this routeFilter object.
• routeMap. A route map is refering to this routeFilter object.
name This element shows the instance name of the iPeer, ePeer or routeMap object which
is refering to this routeFilter object.
mode In case of an internal or external peer, this element shows whether the route filter
is applied as an inbound or outbound filter. Possible values are: inBound and out-
Bound.
routeMap status attributes

• router1424/ip/router/bgp/routeMap[ ]/snmpIndex on page 969
• router1424/ip/router/bgp/routeMap[ ]/users on page 969
router1424/ip/router/bgp/routeMap[ ]/snmpIndex Default:<empty>

This attribute displays the snmpIndex, which is a unique number, assigned to
each object in the containment tree. Refer to 5.3.7 - Introducing attributes snmpIndex and snmpIndexOffset
router1424/ip/router/bgp/routeMap[ ]/users
This attribute displays a list of all BGP entities which refer to and use this routeMap object.
The users table contains following elements:
Element Description
type This element shows the object type which is refering to this routeMap object. Possi-
ble values are:
• iPeer. An internal peer is refering to this routeMap object.
• ePeer. An external peer is refering to this routeMap object.
• bgp. The bgp router object is refering to this routeMap object.
name This element shows the instance name of the iPeer or ePeer object which is refering
to this routeMap object.
mode Possible values are:

• inbound. On iPeers or ePeers, the routeMap is applied as inbound map.
• outbound. On iPeers or ePeers, the routeMap is applied as outbound map.
• originateDefault. On iPeers or ePeers, the routeMap is applied to change the attribute
values when originating a default route.
• importFilter. On the bgp router object, a routeMap is used to change the attribute
values when importing routes from the system routing table.
• network. On the bgp router object, a routeMap is used to change the attribute val-
ues when configuring networks to be inserted in the BGP system.
• aggregate. On the bgp router object, a routeMap is used to change the attribute val-
ues when configuring aggregates to be inserted in the BGP system.
12.9.9 VRRP status attributes

• router1424/ip/router/vrrp[ ]/macAddress on page 971
• router1424/ip/router/vrrp[ ]/interfaces on page 971
• router1424/ip/router/vrrp[ ]/criticals on page 971
router1424/ip/router/vrrp[ ]/macAddress
This attribute displays the for VRRP reserved MAC address. The first 5 bytes are fixed (00:00:5e:00:01).
The last byte is the virtual router ID.
router1424/ip/router/vrrp[ ]/interfaces
This attribute displays the status of the virtual router its interfaces.
The interfaces table contains the following elements:
Element Description
name This element displays the interface name.
priority This element displays the interface priority.
status This element displays the interface status. Possible values are:
• initial: The virtual router interface is in an initial state (e.g. during the master/
backup election process).
• master: The virtual router interface is elected master after the master/backup
election process.
• backup: The virtual router interface is elected backup after the master/backup
election process.
• inactive: The virtual router interface is inactive (e.g. because VRRP is not active).
router1424/ip/router/vrrp[ ]/criticals
This attribute displays the status of the virtual router interfaces that you defined as critical (refer to criticals
on page 741).
The criticals table contains the following elements:
Element Description
interface This element displays the name of the critical interface.
status This element displays the operational status (e.g. up, down, etc.) of the critical
interface.
12.9.10 Firewall status attributes

• router1424/ip/router/firewall/sessions on page 973
• router1424/ip/router/firewall/reverseSessions on page 973
• router1424/ip/router/firewall/log on page 974
• router1424/ip/router/firewall/sNet on page 974
• router1424/ip/router/firewall/clearLog on page 974
router1424/ip/router/firewall/sessions
This attribute displays the status of the sessions that are currently going through the firewall.
The sessions table contains the following elements:
Element Description
sNet This element displays the name of the source SNet. I.e. the SNet in which the orig-
inator of the session is located.
policyDirection This element displays the direction of the policy that applies on the session. Pos-
sible values are: inbound or outbound.
sourceIp This element displays the source IP address.
destIp This element displays the destination IP address.
protocol This element displays the protocol that is used. Possible values are: icmp, tcp, udp,
esp, ah, other.
destPort This element displays the destination port number.
bytesTransferred This element displays the number of bytes transferred in this session.
natIp This element displays the IP address of the NAT gateway (if NAT is enabled for
this session).
name This element displays the name of the policy that applies on the session.
router1424/ip/router/firewall/reverseSessions
This attribute displays the status of the reverse sessions that are currently going through the firewall.
You do not have to set up policies to allow the reverse session (i.e. the return path) of a session that was
initiated. These reverse sessions are set up and allowed automatically.
For example, if you define an outbound policy from the corporate network to the Internet to allow web
browsing (HTTP) and if a HTTP session from the corporate network to the Internet is set up, then a
reverse session from the Internet to the corporate network is set up and allowed automatically.
The reverseSessions table contains the same elements as the sessions table. Refer to router1424/ip/router/fire-
wall/sessions on page 973.
router1424/ip/router/firewall/log
This attribute displays the firewall log.

The sessions table contains the following elements:
Element Description
date This element displays the date and time the event was logged.
sysUpTime This element displays the system-up time at the moment the event was logged.
priority This element displays the priority of the event. Possible values are: debug, info,
notice, warning, error, critical, alert, emergency.
event This element displays a description of the event.

E.g. “access policy not found, dropping packet from corp n/w”.
sourceIp This element displays the source IP address.
destIp This element displays the destination IP address.
sourcePort This element displays the source port number.
destPort This element displays the destination port number.
protocol This element displays the protocol that is used. Possible values are: icmp, tcp, udp,
esp, ah, other.
router1424/ip/router/firewall/sNet
This attribute displays the SNets that are available (standard and custom). However, it says nothing
about which SNets are actually in use (i.e. assigned to an interface).
router1424/ip/router/firewall/clearLog
Use this action to clear the log.

12.9.11 Virtual Routing and Forwarding (VRF) status attirbutes
This object contains the following elements:

• snmpIndex
• routingTable
• dhcpBinding
• dhcpStatistics
• dhcpRelayInfo
• dhcpBlacklist
• addrPools
• poolReservations
• dns
• dnsServers
• igmpTable
These attributes have already been described in 12.9.11 - Virtual Routing and Forwarding (VRF) status
attirbutes on page 975. Refer to this section for more information.
router1424/ip/vrfRouter[ ]/ospf
• type
• routes
• externalRoutes
• asExtLsas
• snmpIndex
These attributes have already been described in 12.9.7 - OSPF status attributes on page 938. Refer to
this section for more information.
• snmpIndex
12.10 Bridge status attributes
This section discusses the status attributes concerned with bridging. First it describes the general bridg-
ing status attributes. Then it explains the status attributes of the extra feature, access listing.
• 12.10.1 - Bridge group status attributes on page 977
• 12.10.2 - Bridge access list status attributes on page 986
• 12.10.3 - VLAN group status attributes on page 988
12.10.1 Bridge group status attributes

• ip on page 978
• spanningTree on page 983
• bridgeCacheSize on page 985
• clearBridgeCache on page 985
• restart on page 985
ifDescr
ifType
ifOperStatus
This attribute displays the current operational status of the bridge group.
ifMtu
Refer to ifMtu on page 832 for more information.
ip
This attribute displays the IP information of the bridge.

Element Description
address This is the IP address of the bridge. It is either configured or retrieved automati-
cally.
matically.
secondaryIp This is the secondary IP address that has been configured on the bridge group.
• address. This is the secondary IP address.
macAddress
This attribute displays the MAC address of the bridge group.

arpCache
on the LAN interface. Refer to What is the ARP cache? on page 512 for more information.
Element Description
message.
address.
value is 0.
bridgeCache
When a port of the bridge enters the learning state, it stores the MAC addresses of the stations situated
on the network that is connected to this port. The MAC addresses are stored in a MAC address database
or bridge cache. The bridgeCache attribute visualises this address database. Refer to What is the bridge
cache? on page 775 for more information.
The bridgeCache table contains the following elements:
Element Description
interface This is the interface through which the station can be reached.
macAddress This is the MAC address of the station situated on the network connected to the
interface.
vlanId If the station belongs to a VLAN, then this element displays the VLAN ID.
filterId This is the ID that identifies the VLAN group the VLAN belongs to.
type This displays whether the MAC address entry is static or dynamic:
• dynamic. The corresponding MAC address is learned on one of the interfaces.
• static. There are only two static entries:
- the 1424 SHDSL Router its own MAC address.
- a MAC address used for Spanning Tree.
age This is the elapsed time since a frame was received from the station.
Example
The following figure shows part of a bridge cache table as an example:

bridging
The bridging attributes or elements in the individual interface objects display the bridging information for
that particular interface. This bridging attribute, however, displays the bridging information of all the
(bridged) interfaces of the 1424 SHDSL Router.
Element Description
name This is the name of the bridge interface as configured.
state This element displays the current state of the port. Possible values are:
• discarding1. The port does not participate in frame forwarding.
• learning. The port prepares to participate in frame forwarding, and it learns the
present MAC addresses.
• forwarding1. The port participates in frame forwarding.
Refer to 8.1.6 - The Spanning Tree bridge port states on page 306 for more infor-
mation on port states2.
cacheSize This attribute displays the actual number of dynamically learned MAC addresses
in the bridge cache, i.e. the current size of the bridge cache.
maxCacheSize This element displays the maximum allowed number of dynamically learned MAC
addresses in the bridge cache. If it is 0, this means this number is unlimited.
vlanMembership This element displays to which VLAN ‘s a bridging interface belongs to. Possible
values are:
• all. The bridging interface belongs to all VLAN ‘s.
• none. The bridging interface does not belong to any VLAN.
• grouped. The membership is based on the defined VLAN groups.
spanningTree This element has already been described in the context of the LAN interface. Refer
to the spanningTree element in bridging on page 835 for detailed information.
1. These are the only possible port states for a bridge that is not running the Spanning Tree pro-
tocol (IEEE p802.1D).
2. Only relevant when the bridge uses the Spanning Tree Protocol.
vlan
This attribute displays the status of the VLAN(s) on this interface.

Element Description
E.g. lan vlan 2

• vid. This element displays the VLAN identifier.
Refer to arpCache on page 834 for a detailed description of the arpCache table.
spanningTree
This attribute gives you the Spanning Tree status information of the bridge group.
The spanningTree structure contains the following elements:
Element Description
bridgePriority Together, these two attributes form the unique bridge identifier of this bridge.
bridgeMacAddress
bridgeTimes The bridgeTimes element displays some timing information with regard to spanning
tree.
The bridgeTimes structure contains the following elements:
• messageAge. This is the actual age of stored configuration information.
• maxAge. This is the time-out value to be used by all bridges in the bridged LAN
for discarding bridging information. The maxAge element displays the value as it
is set by the root bridge. This information is conveyed by the root bridge to
ensure that each bridge in the bridged LAN has a consistent value against
which to test the age of stored configuration information.
• forwardDelay. This is the time-out value to be used by all bridges in the bridged
LAN …
- before a bridge port moves from listening state to learning state or from
learning state to forwarding state.
- for purging MAC addresses from the bridge cache in case a topology
change is detected (time-out or ageing).
The forwardDelay element displays the value as it is set by the root bridge. This
information is conveyed by the root bridge to ensure that each bridge in the
bridged LAN has a consistent value for the forward delay timer.
• nrHops. This is the number of hops the configuration information has traversed.
rootBridgeId The rootBridgeId structure contains the following elements:

• priority.
• macAddress.
Together, these two elements form the unique bridge identifier.
They display the unique bridge identifier of the root bridge as it is indicated in the
root identifier parameter of the Configuration BPDUs. These BPDUs are transmit-
ted by the designated bridge for the LAN that is currently connected to this port.
This bridge identifier is used to test the value of the root identifier parameter con-
veyed in received Configuration BPDUs.
rootPortId This is the port identifier of the port that offers the lowest cost path to the root.
If two or more ports offer equal least cost paths to the root bridge, then the root port
is selected to be that with the highest designatedPriority (i.e. the lowest numerical
value).
If two or more ports offer equal least cost paths to the root bridge and the same
designatedPriority, then the root port is selected to be that with the highest
designatedPortPriority (i.e. the lowest numerical value).
Element Description
extRootPathCost This is the cost of the path from this bridge to the root bridge.
If this bridge is the root bridge, the rootPathCost value equals 0. Else, the extRootPath-
Cost value equals the sum of …
• the path cost as it is up to the designated bridge for the LAN that is currently
connected to this port (this cost is transmitted in Configuration BPDUs by the
designated bridge)
and
• the path cost as it is configured for the root port.

The extRootPathCost element is used …
• to test the value of the root path cost parameter conveyed in received Config-
uration BPDUs.
• as the value of the root path cost parameter in transmitted Configuration
BPDUs.
The total cost of the path to the root bridge should not exceed 65500.
intRootPathCost This is the cost of the path from this bridge to the regional root in MSTP.
mstConfigId This is the Multiple Spanning Tree Configuration Identifier.

The mstConfigId structure contains the following elements:
• formatSelector. This is the value 0 encoded in a fixed field of one octet, and is
inherent to the IEEE 802.1Q protocol.
• name. This is the configuration name of the MST identifier, as configured.
• revisionLevel. This is an integer, unique within this MST domain, as configured.
• digest. This value is calculated by the IEEE 802.1Q protocol, using the formatSe-
lector, name and revisionLevel.
bridgeCacheSize
This attribute displays information about the bridge cache.

The bridgeCacheSize structure contains the following elements:
Element Description
size This attribute displays the actual number of dynamically learned MAC addresses
in the bridge cache, i.e. the current size of the bridge cache.
maxSize This attribute displays the maximum allowed number of dynamically learned MAC
addresses in the bridge cache.
clearArpCache
clearBridgeCache
Use this action to clear the bridge cache table.
restart
Use this action to restart the bridge group.

12.10.2 Bridge access list status attributes

• router1424/bridge/accessList[ ]/snmpIndex on page 987
router1424/bridge/accessList[ ]/snmpIndex
mation.
12.10.3 VLAN group status attributes
router1424/bridge/bridgeGroup/vlanGroup[ ]

• vlanMembers on page 989
• mst on page 990
snmpIndex
mation.
vlanMembers
This attribute displays the VLAN’s which are part of the VLAN group, by means of their vlanId.
bridgeCache
Here, in the context of a VLAN group, this means that each VLAN group has its own bridge cache, i.e.
the learned MAC addresses within one VLAN group are shared among the members of that VLAN group.
Refer to 8.3 - Configuring VLANs on page 325 for more information about VLAN groups.
Element Description
interface.
vlanId If the station belongs to a VLAN, then this element displays the VLAN ID.
filterId This is the ID that identifies the VLAN group, as configured.
type This displays whether the MAC address entry is static or dynamic:
• dynamic. The corresponding MAC address is learned on one of the interfaces.
• static. There are only two static entries:
- the 1424 SHDSL Router its own MAC address.
- a MAC address used for Spanning Tree.
age This is the elapsed time since a frame was received from the station.
ports
This attribute displays the ports that are part of the VLAN group.
The ports table contains the following elements:
Element Description
name This is the name of the interface.
portRole This is the role of the interface within the Spanning Tree domain.
portId This the unique port identifier. It is a combination of MAC address and priority of
the port. This assures the uniqueness of the unique port identifier among the ports
of a single bridge.
priority This is the priority of the interface, as configured in the bridging interface, or as
configured using the ports configuration attribute of the VLAN group. Refer to 8.2.6
- Explaining the bridging structure on page 318 and 11.10.3 - VLAN group configu-
ration attributes on page 793 respectively.
internalPathCost This is the path cost of the interface for MSTP as configured in the bridging inter-
face, or as configured using the ports configuration attribute of the VLAN group.
Refer to 8.2.6 - Explaining the bridging structure on page 318 and 11.10.3 - VLAN
group configuration attributes on page 793 respectively.
intRootPathCost This is the cost to the MST Regional Root Bridge for this region.
designatedBridgeId This is the ID of the designated bridge. It consists of the priority and macAddress.
designatedPortId This is the ID of the designated port.
mst
This attribute displays specific MSTP (Multiple Spanning Tree Protocol) information.
The mst structure contains the following elements:
Element Description
bridgePriority This is the priority of the VLAN group for Multiple Spanning Tree or MST, as con-
figured.
bridgeMacAddress This is the MAC address associated with the bridge group.
maxHops This is the maximum number of hops that the MSTconfiguration information may
traverse before being discarded.
regionalRootId This is the ID of the MST Regional Root Bridge for this region. It consists of the
priority and macAddress.
rootPortId This is the ID of the root port.
intRootPathCost This is the cost to the MST Regional Root Bridge for this region.
12.11 SNMP status attributes

• router1424/snmp/trapDestinations on page 992
• router1424/snmp/engineId on page 992
router1424/snmp/trapDestinations
This attribute displays status information about the management system the SNMP traps are sent to.
The trapDestinations table contains the following elements:
Element Description
address This element displays the IP address of the management station to which the
SNMP traps are sent.
state This element displays the state of the traps that are sent. Possible values are:
• ok. The traps are sent succesfully.
• badSource. A bad source IP address is being used.
• duplicateIpAddress. A duplicate destination IP address is being used.
lastFail This element displays the last error that occurred.
router1424/snmp/engineId
This attribute displays the snmpEngineId of the 1424 SHDSL Router.

Refer to 5.3.4 - SNMP entity on page 70 for more information.
12.12 Management status attributes
router1424/management/
router1424/management/loopback
router1424/management/usrLoopback[ ]
The management object contains the following status attributes:

• cms2Address on page 994
• logStats on page 994
• timeServer on page 995
• alarmLog on page 996
• accessLog on page 997
The management/loopback object contains the following status attributes:

• ipAddress on page 999
• mask on page 999
The management/usrLoopback[ ] object must be added manually, and contains the same status attributes as
the management/loopback object.
cms2Address
This attribute displays the absolute device address as you configured it.
logStats
This attribute displays the statistics files that have been logged on the file system of the device.
The logStats table contains the following elements:
Element Description
fileName This is the full name of the file as it it stored on the file system of the device. The
following figure explains the composition of the file name by means of an example:
• The first part of the file name is the fileName as configured in the logStatsToFile
• The second part of the file name is added automatically, depending on the set-
ting of the fileType configuration attribute.
In the example above:
- the first 4 files are month files, showing the data of exactly one month: the
year and month are mentioned in the file name.
- the last three are week files, showing the data of exactly one week: the year
and week number are mentioned in the file name.
error This element displays a message relating to the actual logging of the files. If there
are no problems, the message NOERROR is displayed.
timeServer
This attribute displays the status of the SNTP function.

The timeServer structure contains the following elements:
Element Description
state This is the state of the 1424 SHDSL Router its clock. Possible values are:
• notConfigured. The 1424 SHDSL Router is not configured for SNTP.
• notSynchronised. The 1424 SHDSL Router its clock is not synchronised with the
time server.
• synchronised. The 1424 SHDSL Router its clock is synchronised with the time
server.
connection This is the state of the connection with the time server. Possible values are:
• notConfigured. The 1424 SHDSL Router is not configured for SNTP.
• notSynchronised. The connection with the time server is not synchronised.
• synchronised. The connection with the time server is synchronised.
• noContact. The connection with the time server is lost.
stratum This is the stratum level of the time server its reference clock. Possible values are:
• 0: unspecified or unavailable
• 1: primary reference (e.g. radio clock)
• 2 - 15: secondary reference (via SNTP)
delay This is the total roundtrip delay of the time server with its reference clock.
alarmLog
This attribute displays the alarm log. It displays the 32 most recent alarms that occurred on the 1424
SHDSL Router.
The alarmLog table contains the following elements:
Element Description
timeStamp This is the value of the real time clock at the moment the alarm was generated.
sysUpTime This is the system up-time of the 1424 SHDSL Router at the moment the alarm
was generated.
totalAlarmLevel This is the total alarm level of the 1424 SHDSL Router.
alarmLevel This is the alarm level of the alarm.
alarm This is the alarm itself in the format path.alarmName on|off (e.g. router1424/lanInter-
face.linkDown on).
accessLog
This attribute displays the access log. It displays the 32 most recent login events that occurred on the
1424 SHDSL Router.
The accessLog table contains the following elements:
Element Description
timeStamp This element displays the value of the real time clock at the moment the access
event occurred.
sysUpTime This element displays the system up-time of the 1424 SHDSL Router at the
moment the access event occurred.
type This element displays the type of access event. Possible values are:
• login. A successful login was detected.
• loginFailure. A failed login was detected.
• accessFailureOn. The number of failed logins exceeded the access failure thresh-
old within the access failure period. Refer to accessControl on page 809.
• accessFailureOff. After an accessFailureOn event was logged, the number of failed
logins dropped below the access failure threshold within the access failure
period. Refer to accessControl on page 809.
user This element displays the name of the user who caused the access event. If you
entered a …
• password string only in the password element of the security table, then the user
element displays nothing.
• user/password string in the password element of the security table (of the type
"username:password"), then the user element displays the username part of
the user/password string. Also see security on page 505.
application This element displays the type of application that caused the access event. Possi-
ble values are:
• cms2. The access event is caused by any maintenance application. For exam-
ple, TMA, TMA CLI, CLI or ATWIN (via a Telnet or terminal session), WebInter-
face, etc.
• ftp. The access event is caused by FTP.
• fileSystem. The access event is caused by any maintenance application access-
ing the file system. For example, FTP, TFTP, TML, etc. when downloading
firmware.
• snmp. The access event is caused by SNMP. Note that since SNMP is not ses-
sion oriented, each successful SNMP request would result in an access event.
So an SNMP walk would result in thousands of access events being logged.
Therefore, in case of SNMP, only the failed requests are logged.
• proxy. The access event is caused by any maintenance application accessing a
CMS device through the 1424 SHDSL Router (i.e. the 1424 SHDSL Router acts
as proxy). This since the password of the 1424 SHDSL Router is used to control
the access to the CMS devices.
accessRights This element displays the access rights that are associated with the access event.
Note that some applications may cause more than one access event. For example, suppose you access
the 1424 SHDSL Router with FTP and download a file to the file system. In that case two events are
logged in the accessLog table:
1. One event logging the access of the FTP application to the 1424 SHDSL Router.
2. One event logging the access of the FTP application to the file system when downloading the file.
ifDescr
ifType
ifOperStatus
This attribute displays the current operational status of the loopback interface.
The loopback interface is always up.
ifMtu
Refer to ifMtu on page 832 for more information.
ipAddress
This attribute displays the IP address of the loopback interface as you configured it.
mask
This attribute displays the subnet mask of the loopback interface as you configured it.
12.13 File system status attributes

• router1424/fileSystem/fileList on page 1001
• router1424/fileSystem/freeSpace on page 1001
• router1424/fileSystem/status on page 1001
• router1424/fileSystem/corruptBlocks on page 1001
• router1424/fileSystem/trustedCertificates on page 1002
• router1424/fileSystem/selfCertificates on page 1002
• router1424/fileSystem/Delete File on page 1003
• router1424/fileSystem/Rename File on page 1003
• router1424/fileSystem/loadTrustedCertificate on page 1003
• router1424/fileSystem/generateSelfCertificateRequest on page 1004
• router1424/fileSystem/loadSelfCertificate on page 1006
• router1424/fileSystem/getTrustedCertificateScep on page 1007
• router1424/fileSystem/getSelfCertificateScep on page 1008
• router1424/fileSystem/getCrlScep on page 1010
• router1424/fileSystem/saveCertificates on page 1010
router1424/fileSystem/fileList
Part of the flash memory of the 1424 SHDSL Router is organised as a file system and a number of files
are stored in it. The fileList attribute shows all the files that are present on the file system. Usually, the
following files are present:
• The configuration file of the 1424 SHDSL Router (file config1.db).
• Up to two application software files of the 1424 SHDSL Router (files CONTROL1 and CONTROL 2).
The fileList table contains the following elements:
Element Description
name This is the filename. Maximum length of the filename is 24 characters. All charac-
ters are allowed (including spaces). The filename is case sensitive.
length This is the length of the file in bytes.
router1424/fileSystem/freeSpace
This attribute displays the number of free bytes on the file system.
router1424/fileSystem/status
This attribute displays the status of the file system. Possible values are:
Value Description
ready Normal situation.
formatting The file system is being formatted. This can be triggered when the file system is
found to be corrupt at boot.
corrupt The file system is in a state were no guarantee can be given about the correct
operation of the file system. The file system will be formatted at the following boot.
corruptBlocks A certain block can not be erased.
router1424/fileSystem/corruptBlocks
The file system of the 1424 SHDSL Router consists of several blocks. When a block can not be erased,
the corruptBlocks count is incremented. This block can no longer be used to store data.
router1424/fileSystem/trustedCertificates
This attribute displays the trusted certificates that are currently loaded.
The trustedCertificates table contains the following elements:
Element Description
name This element displays the certificate name. Possible values are: ca-0, ca-1, ca-2.
expiry This element displays when the certificate expires.
issuer This element displays who issued the certificate.
subject This element displays the subject information of the certificate. In case of a trusted
certificate this is information of the CA.
router1424/fileSystem/selfCertificates
This attribute displays the signed self-certificates that are currently loaded.
The selfCertificates table contains the following elements:
Element Description
name This element displays the certificate name. In this case, this is the same string as
entered in the privateKeyName element of the loadSelfCert action.
expiry This element displays when the certificate expires.
issuer This element displays who issued the certificate.
subject This element displays subject information of the certificate. In case of a self-certif-
icate this is information of the device (e.g. the IP address).
router1424/fileSystem/Delete File
Use this action to remove obsolete files from the file system. You have to enter the filename you want to
delete as argument value.
Filenames are case sensitive!
router1424/fileSystem/Rename File
Use this action to rename a file on the file system. You have to enter the old and new filename in a struc-
ture.
Filenames are case sensitive!
router1424/fileSystem/loadTrustedCertificate
This action is used in the procedure where security certificates are obtained and loaded manually in
order to set up an L2TP tunnel secured with IPSEC using an IKE certificate SA. Refer to 9.6.7 - Setting
up an IPSEC secured L2TP tunnel using a manual SA on page 421.
Use this action to load the trusted certificate you obtained from your Certificate Authority (CA) into the
memory of the 1424 SHDSL Router. Enter the filename of the trusted certificate as argument value and
execute the action.
• The trusted certificate file has to be present on the file system of the 1424 SHDSL Router.
• The filename is case sensitive.
• The saveCertificats action has to be executed after the loadTrustedCertificate action so that the trusted cer-
tificate is also loaded every time the 1424 SHDSL Router reboots.
router1424/fileSystem/generateSelfCertificateRequest
Use this action to create a request for a signed self-certificate. Then this request has to be submitted to
your Certificate Authority (CA) which signs it and returns a signed self-certificate. Fill in the elements in
the argument value structure and execute the action.
The argument value structure of the generateCertReq action contains the following elements:
Element Description
fileName Use this element to specify the name of the self-certif- Default:<empty>
icate request file. Range: 0 … 24 characters
After you filled in all the elements and executed the generateCertReq action, a file is
written to the file system of the 1424 SHDSL Router. The name of this file is the
name you specified using the fileName element.
type Use this element to set the authentication algorithm. Default:rsa-md5

The type element has the following values: rsa-md5, rsa- Range: enumerated, see below
sha1, dss-sha1.
subject Use this element to specify the subject. It can contain Default:<empty>
following elements: Range: 0 … 24 characters
• CN. This is the subject name.
• OU. This is the department name.
• O. This is the name of the organisation or company.
• L. This is the city where you are located.
• S. This is the state or province where you are located.
• C. This is the country where you are located.
These elements are official abbreviations, and can also be found in the certificate
itself. They can be verified by the remote device.
privateKeyName Use this element to specify the name of the private Default:<empty>
key. Range: 0 … 8 characters
Remember the private key name. You need it to load the associated signed self-
certificate into the memory of the 1424 SHDSL Router. Refer to router1424/fileSystem/
loadSelfCertificate on page 1006.
ipAddress Use this element to specify the IP address that will be Default:0.0.0.0
used in the self-certificate. This is then used for Range: up to 255.255.255.255
authentication purposes.
hostname Use this element to specify the hostname that will be Default:<empty>
used in the self-certificate. This is then used for Range: 0 … 32 characters
The hostname has to be of the form “host.domain.com”.
Element Description
user Use this element to specify the username that will be Default:<empty>
The username has to be of the form “my.name@company.com”.
keyLength Use this element to specify the length of the public/pri- Default:512
vate keys. Note that the longer the key length, the Range: 512 / 1024 / 2048
It is important to note that at least one of the three following elements may not be left empty: ipAddress,
hostname and/or username. This information is written in the Subject Alternative Name field of the certificate
itself.
router1424/fileSystem/loadSelfCertificate
Use this action to load the signed self-certificate you first submitted and then retrieved from your Certif-
icate Authority (CA) into the memory of the 1424 SHDSL Router. Fill in the elements in the argument
value structure and execute the action.
The argument value structure of the loadSelfCert action contains the following elements:
Element Description
fileName Use this element to specify the name of the signed Default:<empty>
self-certificate file. Range: 0 … 24 characters
This has to be exact the same name as you specified in the privateKeyName element
of the generateCertReq action. Refer to router1424/fileSystem/generateSelfCertificateRequest
on page 1004.
• The signed self-certificate file has to be present on the file system of the 1424 SHDSL Router.
• The filename is case sensitive.
• The saveCerts action has to be executed after the loadSelfCert action so that the signed self-certificate
is also loaded every time the 1424 SHDSL Router reboots.
router1424/fileSystem/getTrustedCertificateScep
This action is used in the procedure where security certificates are obtained and loaded through SCEP
in order to set up an L2TP tunnel secured with IPSEC using an IKE certificate SA. Refer to 9.6.7 - Setting
Use this action to obtain and load the trusted certificate from a SCEP server. Fill in the elements in the
argument value structure and execute the action.
The argument value structure of the getTrustedCertScep action contains the following elements:
Element Description
server Use this element to specify the IP address of the Default:0.0.0.0

SCEP server. Range: up to 255.255.255.255
Together with the url element this makes up the complete path to which the SCEP
requests are submitted.
url Use this element to specify the URL to which the Default:<empty>
SCEP requests have to be submitted. Range: 0 … 40 characters
Together with the server element this makes up the complete path to which the
SCEP requests are submitted. Consult the manual of your SCEP server to find out
which URL you have to specify.
Example
Suppose you set the server element to 172.31.127.6 and the url element to certsrv/
mscep/mscep.dll, then the SCEP requests are submitted to http://172.31.127.6/certsrv/
mscep/mscep.dll.
caName Use this element to set the name of the CA. Default:<empty>
This element is more for information purposes. It may Range: 0 … 20 characters
be omitted.
port Use this element to set the port on which the SCEP Default:<opt>
requests are sent. By default, this is port 80. Range: 1 … 65535
The saveCerts action has to be executed after the getTrustedCertScep action so that the trusted certificate is
also loaded every time the 1424 SHDSL Router reboots.
router1424/fileSystem/getSelfCertificateScep
This action is used in the procedure where security certificates are obtained and loaded through SCEP
in order to set up an L2TP tunnel secured with IPSEC using an IKE certificate SA. Refer to 9.6.7 - Setting
Use this action to obtain and load the self-certificate from a SCEP server. Fill in the elements in the argu-
ment value structure and execute the action.
The argument value structure of the getSelfCertScep action contains the following elements:
Element Description

SCEP requests are submitted.
Example
mscep/mscep.dll.
type Use this element to set the authentication algorithm. Default:rsa-md5

Range: rsa-md5 / rsa-sha1
subject Use this element to specify the subject. Refer to the Default:<empty>
explanation of the subject field in router1424/fileSystem/ Range: 0 … 20 characters
generateSelfCertificateRequest on page 1004 for more infor-
mation.
challenge Use this element to specify the challenge phrase. Default:<empty>

When installing a SCEP server, you usually have the Range: 0 … 20 characters
possibility to specify a challenge phrase. If you specify a challenge phrase on the
SCEP server, then also enter this phrase in the challenge element. If you do not
specify a challenge phrase, then any user can enrol for a certificate.
caName Use this element to select a certificate. Default:ca-0

Range: ca-0 / ca-1 / ca-2
ipAddress Use this element to specify the IP address that will be Default:0.0.0.0
used in the self-certificate. This is then used for Range: up to 255.255.255.255
Element Description
hostname Use this element to specify the hostname that will be Default:<empty>
The hostname has to be of the form “host.domain.com”.
user Use this element to specify the username that will be Default:<empty>
The username has to be of the form “my.name@company.com”.
keyLength Use this element to specify the length of the public/pri- Default:512
vate keys. Note that the longer the key length, the Range: 512 / 1024 / 2048
• The saveCertificates action has to be executed after the getSelfCertificateScep action so that the signed
self-certificate is also loaded every time the 1424 SHDSL Router reboots.
• It is important to note that at least one of the three following elements may not be left empty: ipAddress,
hostname and/or username. This information is written in the Subject Alternative Name field of the cer-
tificate itself.
router1424/fileSystem/getCrlScep
Use this action to get the Certificate Revocation List (CRL). A CRL is a list of certificates that have been
revoked before their scheduled expiration date. Fill in the elements in the argument value structure and
execute the action.
The argument value structure of the getCertRevListScep action contains the following elements:
Element Description

SCEP requests are submitted.
Example
mscep/mscep.dll.
caName Use this element to select a certificate. Default:ca-0

Range: ca-0 / ca-1 / ca-2
router1424/fileSystem/saveCertificates
This action is used in the procedure where security certificates are obtained and loaded in order to set
up an L2TP tunnel secured with IPSEC using an IKE certificate SA. Refer to 9.6.7 - Setting up an IPSEC
secured L2TP tunnel using a manual SA on page 421.
Use this action to save the trusted certificate and the signed self-certificate that were either obtained and
loaded manually or by using SCEP. Saving the certificates ensures that they are loaded every time the
1424 SHDSL Router reboots.
12.14 Operating system status attributes

• router1424/operatingSystem/taskInfo on page 1012
• router1424/operatingSystem/coreDump on page 1012
router1424/operatingSystem/taskInfo
This attribute displays status information about the operating system.

The taskInfo table contains the following elements:.
Element Description
taskName This is the name of the task.
taskStatus This is the current status of the task. Possible values are:
• awake. This task is actually running.
• asleep. This task is waiting on an event.
• inactive. This task slot is not active, i.e. no task has been assigned to this slot.
load30s This is the load on the processor, in percent, during the last 30 seconds.
load5m This is the load on the processor, in percent, during the last 5 minutes.
runningInMedium Each task can be running with a low, medium or high priority. This element gives
the percentage of time this task has been running with medium priority during the
last 30 seconds.
runningInHigh Each task can be running with a low, medium or high priority. This element gives
the percentage of time this task has been running with high priority during the last
30 seconds.
The percentage of time this task has been running with low priority can be calcu-
lated using the following formula:
running in low priority = 100% - runningInMedium - runningInHigh
programCounter This is the current value of the program counter. The program counter is the mem-
ory address for the current instruction of this task.
router1424/operatingSystem/coreDump
This structure is empty under normal conditions. If the device software however would ever crash, it will
reboot. After this reboot this attribute contains operating system information at the time of the crash. If a
crash has occurred the user can export this information to a file together with other information of the
set-up including configuration(s). He can send all this information to his technical contact who should
forward it to OneAccess Support for further analysis.
For more information on how to export the information, refer to the TMA manual.
User manual Performance attributes
13 Performance attributes
This chapter discusses the performance attributes of the 1424 SHDSL Router. The following gives an
overview of this chapter:
• 13.1 - Performance attributes overview on page 1014
• 13.2 - General performance attributes on page 1022
• 13.3 - LAN interface performance attributes on page 1024
• 13.4 - WAN interface performance attributes on page 1032
• 13.5 - Encapsulation performance attributes on page 1033
• 13.6 - SHDSL line performance attributes on page 1046
• 13.7 - End and repeater performance attributes on page 1050
• 13.8 - Bundle performance attributes on page 1051
• 13.9 - Router performance attributes on page 1054
• 13.10 - IP traffic policy performance attributes on page 1097
• 13.11 - Bridge performance attributes on page 1099
• 13.12 - SNMP performance attributes on page 1109
• 13.13 - Management performance attributes on page 1112
• 13.14 - Operating system performance attributes on page 1115
13.1 Performance attributes overview
> router1424
Action: clearAllCounters
>> lanInterface
ifInOctets
ifInUcastPkts
ifInNUcastPkts
ifInDiscards
ifInErrors
ifInUnknownProtos
ifOutOctets
ifOutUcastPkts
ifOutNUcastPkts
ifOutDiscards
ifOutErrors
ifOutQLen
ifInQLen
h2Performance
h24Performance
d7Performance
ifInDropLevelExceeded
ifOutDropLevelExceeded
ifInPriorityQueues
ifOutPriorityQueues
vlan
mibCounters1
pppoEClient
Action: clearCounters

>> dslInterface
ifInOctets
ifInUcastPkts
ifInNUcastPkts
ifInDiscards
ifInErrors
ifInUnknownProtos
ifInQLen
ifInPriorityQueues
ifOutOctets
ifOutUcastPkts
ifOutNUcastPkts
ifOutDiscards
ifOutErrors
ifOutQLen
ifOutPriorityQueues
h2Performance
h24Performance
d7Performance
>>> channel[wan_1]
<contains the same attributes as the dslInterface object>
>>>> atm
pvcTable
unknownCells
vp
>>>> efm
ifInOctets
ifInUcastPkts
ifInNUcastPkts
ifInDiscards
ifInErrors
ifInUnknownProtos
ifInQLen
ifOutOctets
ifOutUcastPkts
ifOutNUcastPkts
ifOutDiscards
ifOutErrors
ifOutQLen
h2Performance
h24Performance
d7Performance
ifDropLevelExceeded
ifOutPriorityQueues
vlan
pppOEClient
oam
>>> line
h2Line
h24Line
d7Line
line
Action: retrain
Action: psdMeasurement
>>>> linePair[ ]
h2LineParameters
h2Performance
h24LineParameters
h24Performance
d7LineParameters
d7Performance
lineParameters
performance
Action: retrain
>>> repeater[ ]
h2Line
h24Line
d7Line
line
h2LineParameters
h2Performance
h24LineParameters
h24Performance
d7LineParameters
d7Performance
lineParameters
performance
h2LineParameters
h2Performance
h24LineParameters
h24Performance
d7LineParameters
d7Performance
lineParameters
performance
>>> end
h2Line
h24Line
d7Line
line
>>>> linePair[ ]
h2LineParameters
h2Performance
h24LineParameters
h24Performance
d7LineParameters
d7Performance
lineParameters
performance
>> profiles
>>> policy
>>>> traffic
discards
trafficShaping
>> ip
>>> router
routingTable
radiusAuth
radiusAcct
pingResults
tracertResults
qualityMonitor
igmpProxy
Action: startPing
Action: stopPing
Action: startTracert
Action: stopTracert
Action: clearTracert
>>>> defaultNat
socketsFree
allocFails
discards
addressesAvailable
tcpSocketsUsed
udpSocketsUsed
icmpSocketsUsed
tcpAllocs
udpAllocs
icmpAllocs
espAllocs
greAllocs
espSocketsUsed
greSocketsUsed
packetsToPublic
octetsToPublic
packetsToPrivate
octetsToPrivate
h2Nat
h24Nat
d7Nat
Action: reset
>>>> tunnels
l2tpTunnels
ipsecL2tpTunnels
greTunnels
ipsecGreTunnels
ipsecTunnels
>>>> manualSA[ ]
inPackets
outPackets
espAuthenticationFailure
espDecryptionFailure
espSequenceNrReplay
espDroppedFrames
>>>> ikeSA[ ]
negotiations
phase1Errors
phase2Sessions
>>>> bgp
>>>>> ePeer[ ]
sessions
messagesSent
messagesRcvd
prefixesSent
prefixesRcvd
inboundFilters
outboundFilters
inboundMaps
outboundMaps
>>>>> iPeer[ ]
<contains the same attributes as the ePeer object>
>>>>> routeFilter[ ]
uses
filters
>>>>> routeMap[ ]
uses
>>>> firewall
h24General
d7General
h24Attack
d7Attack
>>> vrfRouter[ ]
routingTable
pingResults
tracerResults
igmpProxy
filter
>> bridge
>>> bridgeGroup
bridgeCache
bridgeDiscards
bridgeFloods
bridgeBroadcasts
bridgeMulticasts
vlan
vlanSwitching
<contains the same attributes as the bridgeGroup object>
>>> accessList[ ]
bridgeAccessList
advancedFilter
>> snmp
mib2Counters
mpdStats
usmStats
>> management
cms2SessionCount
tftpSessionCount
cliSessionCount
tcpSessionCount
tcpSession
ipStackEvents
>> operatingSystem
currUsedProcPower
usedProcPower
freeDataBuffers
totalDataBuffers
freeMemory
totalMemory
taskInfo
memAllocations
memOutstanding
memOverview
freeShortBuffers
totalShortuffers
13.2 General performance attributes
There are no general performance attributes. However, there is one general performance action:
• router1424/clearAllCounters on page 1023
router1424/clearAllCounters
Use this action to clear all counters in all objects in the containment tree of the 1424 SHDSL Router.
You can also clear the counters per object. To do so, use the clearCounters action located in the corre-
sponding object.
13.3 LAN interface performance attributes
This section describes the performance attributes of the following object:
router1424/lanInterface

• ifInOctets on page 1025
• ifInUcastPkts on page 1025
• ifInNUcastPkts on page 1025
• ifInDiscards on page 1025
• ifInErrors on page 1025
• ifInUnknownProtos on page 1025
• ifOutOctets on page 1026
• ifOutUcastPkts on page 1026
• ifOutNUcastPkts on page 1026
• ifOutDiscards on page 1026
• ifOutErrors on page 1026
• ifOutQLen on page 1026
• ifInQLen on page 1026
• h2Performance on page 1027
• d7Performance on page 1028
• ifOutPQLen on page 1028
• ifOutDropLevelExceeded on page 1028
• ifInDropLevelExceeded on page 1028
• ifOutPriorityQueues on page 1029
• ifInPriorityQueues on page 1030
• mibCounters on page 1030
• oam on page 1031
ifInOctets
This attribute displays the number of octets (bytes) received on this interface.
ifInUcastPkts
This attribute displays the number of unicast packets received on this interface and delivered to a higher-
layer protocol. Unicast packets are all non-multicast and non-broadcast packets.
ifInNUcastPkts
This attribute displays the number of non-unicast packets received on this interface and delivered to a
higher-layer protocol. Non-unicast packets are all the multicast and broadcast packets.
ifInDiscards
This attribute displays the number of incoming packets that were discarded, to prevent their deliverance
to a higher-layer protocol. This even though no errors were detected in these packets.
ifInErrors
This attribute displays the number of incoming packets that could not be delivered to a higher-layer pro-
tocol because they contained errors.
ifInUnknownProtos
This attribute displays the number of incoming packets that were discarded because they contained an
unknown or unsupported protocol.
ifOutOctets
This attribute displays the total number of octets (bytes) transmitted by the interface, including framing
characters.
ifOutUcastPkts
This attribute displays the total number of packets that higher-level protocols requested to be transmitted
to a unicast address, including those that were discarded or not sent.
ifOutNUcastPkts
This attribute displays the number of non-unicast packets that higher-level protocols requested to be
transmitted to a non-unicast (i.e. a broadcast or multicast) address, including those that were discarded
or not sent.
ifOutDiscards
This attribute displays the number of outgoing packets that were discarded, to prevent they are transmit-
ted by the interface. This could be due to, for instance, the presence of an access list.
ifOutErrors
This attribute displays the number of outgoing packets that could not be transmitted by the interface
because they contained errors. On the LAN interface ifOutErrors are also generated in case of extensive
collisions.
ifOutQLen
This attribute displays the length, expressed in packets, of the output packet queue on the interface.
As of TDRE 12.0, with improved buffer management, it is important that this value is not too big. Other-
wise all Mbuf ‘s will be used up at some point, especially when small packets are used.
ifInQLen
This attribute displays the length, expressed in packets, of the input packet queue on the interface.
h2Performance
This attribute displays the 2 hours performance summary of the LAN interface.
The h2Performance table contains the following elements:
Element For the corresponding period, this element displays …
sysUpTime the elapsed time since the last cold boot.
ifUpTime the time during which the interface was up.
ifStatusChanges the number of times the ifOperStatus value of the interface changed (from up to down
or vice versa).
ifInOctets the number of octets (bytes) received on this interface.
ifInPackets the number of packets received on this interface.
ifInErrors the number of packets received on this interface that could not be delivered to a
higher-layer protocol because they contained errors.
ifOutOctets the number of octets (bytes) transmitted by the interface, including framing char-
acters.
ifOutPackets the number of packets transmitted by the interface.
ifOutDiscards the number of outgoing packets that were discarded, to prevent they were trans-
mitted by the interface. This could be due to, for instance, the presence of an
access list.
ifOutErrors the number of packets that could not be transmitted by the interface because they
contained errors.
h24Performance
This attribute displays the 24 hours performance summary of the LAN interface. The h24Performance table
contains the same elements as the h2Performance table.
d7Performance
This attribute displays the 7 days performance summary of the LAN interface. The d7Performance table
contains the same elements as the h2Performance table.
ifOutPQLen
In case an overload condition occurs and priority queuing is activated, then this attribute displays how
many packets the different queues contain.
Refer to 7.11.2 - Introducing traffic and priority policy on page 262 for more information on the priority
queues.
This attribute displays how many times the drop levels of the outbound user configurable queues have
been exceeded (and hence packets have been dropped).
Refer to dropLevels on page 598 for more information on the drop levels.
This attribute displays how many times the drop levels of the inbound user configurable queues have
been exceeded (and hence packets have been dropped).
Refer to dropLevels on page 598 for more information on the drop levels.
vlan
This attribute displays the SNMP MIB2 performance parameters of the VLANs that are present on the
LAN interface.
Element Description
name This element displays the name of the VLAN as you configured it.
vlan This element displays the VLAN ID.
mibCounters This element displays the SNMP MIB2 performance parameters of the VLAN.
Refer to 13.3 - LAN interface performance attributes on page 1024 for an explana-
tion of the individual SNMP MIB2 performance parameters.
pppoEClient
This attribute displays the PPPoE performance parameters that are present on the LAN interface.
Element Description
name This element displays the administrative name of the PPPoE link as you config-
ured it.
mibCounters This element displays the SNMP MIB2 performance parameters of the PPPoE link.
ifOutPriorityQueues
This attribute displays the performance summary of the outbound priority queues on the LAN interface.
The ifOutPriorityQueues table contains the following elements:
Element Description
name This element displays the name of the queue.
length This element displays the length, expressed in packets, of the output priority
queues.
packets This element displays packet information of the priority queues.

The packets structure contains the following elements:
• directTx. This is the number of packets that were transmitted directly.
• queued. This is the number of packets that were first queued before they were
sent.
• dropped. This is the number of dropped packets.
• cirTx. This is the total number of packets sent conform the CIR value.
• eirTx. This is the total number of packets sent conform the EIR value.
Element Description
octets This element displays the same information as the packets element above, except
that it is expressed in octets (or bytes).
h2Performance This element displays the 2 hours performance summary with regards to the out-
pur priority queues; refer to ifOutPriorityQueues/h2Performance on page 1030 for a
detailed explantion.
h24Performance This element displays the 24 hours performance summary with regards to the out-
pur priority queues. The h24Performance table contains the same elements as the
ifOutPriorityQueues/h2Performance on page 1030 table.
d7Performance This element displays the 7 days performance summary with regards to the outpur
priority queues. The h24Performance table contains the same elements as the ifOut-
PriorityQueues/h2Performance on page 1030 table.
ifOutPriorityQueues/h2Performance
This element displays the 2 hours performance summary with regards to the output priority queues.
sysUptime the elapsed time since the last cold boot.
directTxPkts the number of packets that were transmitted directly.
QueuedPkts the number of packets that were first queued before they were sent.
droppedPkts the number of dropped packets.
cirTxPkts the total number of packets sent conform the CIR value.
eirTxPkts the total number of packets sent conform the EIR value.
directTxOctets the number of bytes that were transmitted directly.
QueuedOctets the number of bytes that were first queued before they were sent.
droppedOctets the number of dropped bytes.
cirTxOctets the total number of bytes sent conform the CIR value.
eirTxOctets the total number of bytes sent conform the EIR value.
ifInPriorityQueues
This attribute displays the performance summary of the inbound priority queues of the LAN interface.
The ifInPriorityQueues table contains the same elements as the ifOutPriorityQueues table described above.
mibCounters
Only present on the 4 port LAN interface.

This attribute displays the performance parameters for each port of the Ethernet switch.
Element Description
portName This element displays the port name of each port.
ifInPkts This element displays the number of packets received on each port.
ifOutPkts This element displays the number of packets transmitted on each port.
h2Performance This element displays the 2 hours performance summary of each port.
This h2Performance table contains the following elements: sysUpTime, ifUpTime, ifSta-
tusChanges, ifInPkts, ifOutPkts. These have already been described in the h2Performance
table of the LAN interface itself:
h24Performance This element displays the 24 hours performance summary of each port. It contains
the same elements as the h2Performance tabel.
d7Performance This element displays the 7 days performance summary of each port. It contains
the same elements as the h2Performance tabel above.
oam
This attribute lists the performance information with regard to received and sent OAM data.
Note that:
• PduDiscardRx (the number of OAMPDU discards) is linked to the discovery process.
• dataDiscardTx and dataDiscardTx (the number of data discards) are linked to the loopback process.
Refer to IEEE Std. 802.3-2005, section 57.4.2 Structure and section 57.4.3 OAMPDU descriptions for
more detailed information.
13.4 WAN interface performance attributes

• 1431 SHDSL CPE
• 1432 SHDSL CPE
All performance attributes of the WAN interface are the same as on the LAN interface. Therefore, they
are not explained here again. Refer to 13.3 - LAN interface performance attributes on page 1024 for a
complete description of these attributes.
13.5 Encapsulation performance attributes
This section discusses the performance attributes of the encapsulation protocols that can be used on
• 13.5.1 - ATM performance attributes on page 1034
• 13.5.2 - Frame Relay performance attributes on page 1042
13.5.1 ATM performance attributes
This section describes the following performance attributes:

• router1424/dslInterface/channel[wan_1]/atm/pvcTable on page 1035
• router1424/dslInterface/channel[wan_1]/atm/unknownCells on page 1041
• router1424/dslInterface/channel[wan_1]/atm/vp on page 1041
router1424/dslInterface/channel[wan_1]/atm/pvcTable
This attribute lists the complete performance information of all known PVCs.
The pvcTable table contains the following elements:
Element Description
name This is the name of the PVC as you configured it.
mibCounters This displays the SNMP MIB2 parameters of the PVC.

These are the same as the SNMP MIB2 parameters on the LAN interface. Refer
to 13.3 - LAN interface performance attributes on page 1024.
priorityQLengths In case an overload condition occurs and priority queuing is activated, then this
elements displays how many packets the different queues contain.
Refer to 7.11.2 - Introducing traffic and priority policy on page 262 for more infor-
mation on the priority queues.
atm This displays the specific ATM related performance information of the PVC.
Refer to router1424/dslInterface/channel[wan_1]/atm/pvcTable/atm on page 1036 for a detailed
description of the atm structure
frameRelay This displays the specific Frame Relay related performance information of the
PVC.
The frameRelay structure contains following elements:
• lmi. This attribute gives a complete LMI performance information overview for
each PVC. Refer to router1424/dslInterface/channel[wan_1]/atm/pvcTable/frameRelay/lmi
on page 1039 for a detailed description.
• dlciTable. This attribute gives the complete performance information of all known
DLCIs for this PVC. Refer to router1424/dslInterface/channel[wan_1]/atm/pvcTable/
frameRelay/dlciTable on page 1039 for a detailed description.
router1424/dslInterface/channel[wan_1]/atm/pvcTable/atm
The atm structure in the pvcTable displays the specific ATM related performance information of the PVC.
Element Description
vpi This element displays the Virtual Path Identifier (VPI).
vci This element displays the Virtual Channel Identifier (VCI).

The VPI in conjunction with the VCI identifies the next destination of a cell as it
passes through a series of ATM switches on the way to its destination.
oamF5 This element displays the performance information of the OAM F5 loopback cells.
• segment: this element displays performance information with regard to the seg-
ment the 1424 SHDSL Router is part of. Refer to router1424/dslInterface/chan-
nel[wan_1]/atm/pvcTable/atm/oamF5/segment on page 1037 for a detailed description of
the elements of the segment structure.
• endToEnd: this element displays performance information with regard to the
entire end-to-end conenction the 1424 SHDSL Router is part of. Refer to
router1424/dslInterface/channel[wan_1]/atm/pvcTable/atm/oamF5/endToEnd on page 1038 for
a detailed description of the elements of the endToEnd structure.
What is OAM segment/end-to-end VP/VC AIS and RDI?
OAM VP/VC AIS (Alarm Indication Signal) and RDI (Remote Defect Indication) are
cells that are used for identifying and reporting VP/VC defects on a segment/end-
to-end level. When a physical link error, interface failure or loss of continuity (LOC)
occurs, segment endpoints insert AIS cells into all the downstream VP/VCs
affected by the failure. Upon receiving an AIS cell on a VP/VC, the router marks
the logical interface down and sends an RDI cell on the same VP/VC to let the
remote end know the error status. When an RDI cell is received on a VP/VC, the
router sets the logical interface status to down. Also refer to 6.3 - Configuring OAM
on ATM interfaces on page 125 for more information.
router1424/dslInterface/channel[wan_1]/atm/pvcTable/atm/oamF5/segment
This element displays performance information of the OAM F5 loopback cells with regard to the segment
the 1424 SHDSL Router is part of.
The segment structure contains the following elements:
Element Description
lbRx This displays the number of received loopback cells.
lbTx This displays the number of transmitted loopback cells.
ccRx This displays the number of received continuity check cells.
ccTx This displays the number of transmitted continuity check cells.
fpmRx This displays the number of received FPM (Forward Performance Managenent)
cells.
fpmTx This displays the number of transmitted FPM (Forward Performance Managenent)
cells.
brRx This displays the number of received BR (Backward Reporting) cells.
brTx This displays the number of transmitted BR (Backward Reporting) cells.
actDeactRx This displays the number of received continuity check activator/deactivator cells.
actDeactTx This displays the number of transmitted continuity check activator/deactivator

cells.
aisRx This displays the number of received Alarm Indication Signals.
aisTx This displays the number of transmitted Alarm Indication Signals.
rdiRx This displays the number of received Remote Defect Indications.
rdiTx This displays the number of transmitted Remote Defect Indications.
pmRxStats This displays the performance monitoring statistics with regard to the received
ATM cells.
Refer to router1424/dslInterface/channel[wan_1]/atm/pvcTable/atm/oamF5/segment/pmRxStats
on page 1038 for a detailed description of the elements of the pmRxStats structure
pmTxStats This displays the performance monitoring statistics with regard to the transmitted
ATM cells.
The pmTxStats structure contains the same elements as the pmRxStats structure
above, refer to router1424/dslInterface/channel[wan_1]/atm/pvcTable/atm/oamF5/segment/
pmRxStats on page 1038.
router1424/dslInterface/channel[wan_1]/atm/pvcTable/atm/oamF5/endToEnd
This element displays performance information of the OAM F5 loopback cells with regard to the end-to-
end connection the 1424 SHDSL Router is part of.
The endToEnd structure contains the same elements as the segment structure. Refer to router1424/dslInter-
face/channel[wan_1]/atm/pvcTable/atm/oamF5/segment on page 1037.
router1424/dslInterface/channel[wan_1]/atm/pvcTable/atm/oamF5/segment/pmRxStats
This element displays the performance monitoring statistics with regard to the received ATM cells.
The pmRxStats structure contains the following elements:
Element Description
lostOamCells This displays the number of transferred OAM cells that were lost.
lostUserCells This displays the number of transferred user cells that were lost.
errUserCells This displays the number of errored user cells.
misInsertUserCells This displays the number of transferred user cells that were misinserted.
cellErrRatio This displays the ratio of total errored cells to the total of successfully transferred
cells, plus tagged cells, plus errored cells.
cellLosRatio This displays the ratio of total lost cells to total transmitted cells.
cellMisinsertRatio This displays the total number of misinserted cells observed during a specified
time interval divided by the time interval duration (equivalently, the number of
misinserted cells per connection second).
sevErrCellBlckRatio This displays the ratio of total severely errored cell blocks to total cell blocks.
router1424/dslInterface/channel[wan_1]/atm/pvcTable/frameRelay/lmi
This attribute gives a complete LMI performance overview.

Element Description
inStatusEnquiry This is the number of Status Enquiries received from the network.
inStatus This is the number of Status Reports received from the network.
inStatusUpdate This is the number of unsolicited Status Updates received from the network.
outStatusEnquiry This is the number of Status Enquiries sent to the network.
outStatus This is the number of Status Reports sent to the network.
outStatusUpdate This is the number of unsolicited Status Updates sent to the network.
netPollNotRcvd This is the number of times the expectedPollInterval expired without an incoming sta-
tus enquiry.
userNoResponse- This is the number of times a response was not received.

Rcvd
userBadResponses- This is the number of times an invalid response was received.

Rcvd
router1424/dslInterface/channel[wan_1]/atm/pvcTable/frameRelay/dlciTable
This attribute lists the complete performance information of all known DLCIs.
Element Description
name This is the name of the DLCI as you configured it.
mibCounters This displays the SNMP MIB2 parameters of the DLCI.

DLCI.
Refer to router1424/dslInterface/channel[wan_1]/atm/pvcTable/frameRelay/dlciTable/frameRelay
on page 1040 for a detailed description of the frameRelay structure.
router1424/dslInterface/channel[wan_1]/atm/pvcTable/frameRelay/dlciTable/frameRelay
The frameRelay structure in the dlciTable displays the specific Frame Relay related performance information
of the DLCI.
Element Description
inFecn This is the number of frames received from the network indicating forward conges-
tion and this since the virtual circuit was created.
inBecn This is the number of frames received from the network indicating backward con-
gestion and this since the virtual circuit was created.
inDe This is the number of frames received with the Discard Eligibility bit set.
inOctets This is the number of octets received over this virtual circuit since it was created.
inFrames This is the number of frames received over this virtual circuit since it was created.
outFecn This is the number of frames sent to the network indicating forward congestion and
this since the virtual circuit was created.
outBecn This is the number of frames sent to the network indicating backward congestion
and this since the virtual circuit was created.
outDe This is the number of frames sent to the network with the Discard Eligibility bit set.
outOctets This is the number of octets sent over this virtual circuit since it was created.
outFrames This is the number of frames sent over this virtual circuit since it was created.
router1424/dslInterface/channel[wan_1]/atm/unknownCells
This attribute displays the number of received cells that are not in-band for a certain PVC.
Example
Suppose router A sends OAM F4 loopback cells on VPI 5. On router B no VPI 5 is configured or no OAM
F4 loopback cells are configured for VPI 5. In that case, the unknownCells value on router B will increase.
router1424/dslInterface/channel[wan_1]/atm/vp
Whereas the atm structure in the pvcTable displays the OAM F5 loopback cell performance information for
each Virtual Channel, the vp table displays the OAM F4 loopback cell performance information of a com-
plete Virtual Path.
Element Description
vpi This is the Virtual Path Identifier (VPI).
oamF4 This displays the performance information of the OAM F4 loopback cells.
• segment: this element displays performance information with regard to the seg-
ment the 1424 SHDSL Router is part of. Refer to router1424/dslInterface/chan-
nel[wan_1]/atm/vp on page 1041 for a detailed description of the elements of the
segment structure.
• endToEnd: this element displays performance information with regard to the
entire end-to-end conenction the 1424 SHDSL Router is part of. Refer to
router1424/dslInterface/channel[wan_1]/atm/vp/endToEnd on page 1041 for a detailed
description of the elements of the endToEnd structure.
router1424/dslInterface/channel[wan_1]/atm/vp/segment
This element displays performance information of the OAM F4 loopback cells with regard to the segment
the 1424 SHDSL Router is part of.
The segment structure for OAM F4 loopback cells contains the same elements as the segment structure for
OAM F5 loopback cells; refer to router1424/dslInterface/channel[wan_1]/atm/pvcTable/atm on page 1036 for more
information.
router1424/dslInterface/channel[wan_1]/atm/vp/endToEnd
This element displays performance information of the OAM F4 loopback cells with regard to the end-to-
end connection the 1424 SHDSL Router is part of.
The segment structure for OAM F4 loopback cells contains the same elements as the segment structure for
OAM F5 loopback cells; refer to router1424/dslInterface/channel[wan_1]/atm/pvcTable/atm/oamF5/endToEnd on
13.5.2 Frame Relay performance attributes
This section describes the status attributes of the following object(s):
router1424/dslInterface/channel[wan_1]/frameRelay/
The Frame Relay status attributes are:

• lmi on page 1045
• cllmInFrames on page 1045
dlciTable
This attribute lists the complete performance information of all known DLCIs.
Element Description
name This is the name of the DLCI as you configured it.
mibCounters This displays the SNMP MIB2 parameters of the DLCI.

DLCI.
Refer to dlciTable/frameRelay on page 1044 for a detailed description of the frameRelay
structure.
dlciTable/frameRelay
The frameRelay structure in the dlciTable displays the specific Frame Relay related performance information
of the DLCI.
Element Description
inFecn This is the number of frames received from the network indicating forward conges-
tion and this since the virtual circuit was created.
inBecn This is the number of frames received from the network indicating backward con-
gestion and this since the virtual circuit was created.
inDe This is the number of frames received with the Discard Eligibility bit set.
inOctets This is the number of octets received over this virtual circuit since it was created.
inFrames This is the number of frames received over this virtual circuit since it was created.
outFecn This is the number of frames sent to the network indicating forward congestion and
this since the virtual circuit was created.
outBecn This is the number of frames sent to the network indicating backward congestion
and this since the virtual circuit was created.
outDe This is the number of frames sent to the network with the Discard Eligibility bit set.
outOctets This is the number of octets sent over this virtual circuit since it was created.
outFrames This is the number of frames sent over this virtual circuit since it was created.
lmi
This attribute gives a complete LMI performance overview.

Element Description
inStatusEnquiry This is the number of Status Enquiries received from the network.
inStatus This is the number of Status Reports received from the network.
inStatusUpdate This is the number of unsolicited Status Updates received from the network.
outStatusEnquiry This is the number of Status Enquiries sent to the network.
outStatus This is the number of Status Reports sent to the network.
outStatusUpdate This is the number of unsolicited Status Updates sent to the network.
netPollNotRcvd This is the number of times the expectedPollInterval expired without an incoming sta-
tus enquiry.
userNoResponse- This is the number of times a response was not received.

Rcvd
userBadResponses- This is the number of times an invalid response was received.

Rcvd
cllmInFrames
This attribute displays the total number of received CLLM (Consolidated Link Layer Management)
frames.
13.6 SHDSL line performance attributes
This section describes the following line performance attributes:

• router1424/wanInterface/line/h2Line on page 1047
• router1424/wanInterface/line/h24Line on page 1047
• router1424/wanInterface/line/d7Line on page 1047
• router1424/wanInterface/line/line on page 1047
This section describes the following line pair performance attributes:
• router1424/wanInterface/line/linePair[ ]/h2LineParameters on page 1048
• router1424/wanInterface/line/linePair[ ]/h24LineParameters on page 1048
• router1424/wanInterface/line/linePair[ ]/d7LineParameters on page 1048
• router1424/wanInterface/line/linePair[ ]/lineParameters on page 1048
• router1424/wanInterface/line/linePair[ ]/h2Performance on page 1049
• router1424/wanInterface/line/linePair[ ]/h24Performance on page 1049
• router1424/wanInterface/line/linePair[ ]/d7Performance on page 1049
• router1424/wanInterface/line/linePair[ ]/performance on page 1049
• router1424/wanInterface/line/retrain on page 1047
router1424/wanInterface/line/h2Line
This attribute displays the 2 hours performance information summary of the line.
The h2Line table contains the following elements:
linkDownCount the number of times the link went down.
linkDownTime the total amount of time the link was down.
router1424/wanInterface/line/h24Line
This attribute displays the 24 hours performance information summary of the line. The h24Line table con-
tains the same elements as the router1424/wanInterface/line/h2Line table.
router1424/wanInterface/line/d7Line
This attribute displays the 7 days performance information summary of the line. The d7Line table contains
the same elements as the router1424/wanInterface/line/h2Line table.
router1424/wanInterface/line/line
This attribute displays the performance information summary of the line since the last cold boot. Except
for the sysUpTime, the line structure contains the same elements as the router1424/wanInterface/line/h2Line
table.
router1424/wanInterface/line/retrain
Use this action to force a retrain on the line.

router1424/wanInterface/line/linePair[ ]/h2LineParameters
This attribute displays the 2 hours line parameter summary.

The h2LineParameters table contains the following elements:
lineAttenuationMin the minimum line attenuation that was measured.
lineAttenuationAvrg the average line attenuation that was calculated
lineAttenuationMax the maximum line attenuation that was measured.
signalNoiseMin the minimum signal to noise ratio that was measured.
signalNoiseAvrg the average signal to noise ratio that was calculated.
signalNoiseMax the maximum signal to noise ratio that was measured.
router1424/wanInterface/line/linePair[ ]/h24LineParameters
This attribute displays the 24 hours line parameter summary. The h24LineParameters table contains the
same elements as the router1424/wanInterface/line/linePair[ ]/h2LineParameters table.
router1424/wanInterface/line/linePair[ ]/d7LineParameters
This attribute displays the 7 days line parameter summary. The d7LineParameters table contains the same
elements as the router1424/wanInterface/line/linePair[ ]/h2LineParameters table.
router1424/wanInterface/line/linePair[ ]/lineParameters
This attribute displays the line parameter summary since the last cold boot. Except for the sysUpTime, the
lineParameters table contains the same elements as the router1424/wanInterface/line/linePair[ ]/h2LineParameters
table.
router1424/wanInterface/line/linePair[ ]/h2Performance
This attribute displays the 2 hours performance summary of the line.

codeViolations the number of line errors that was counted.
errSec the number of erroneous seconds that was counted.
sevErrSec the number of severely erroneous seconds that was counted.
unavailSec the number of unavailable seconds that was counted.
loswSec the number of lost synchronisation words seconds that was counted.
moniSec the number of monitored seconds.
• Errors are counted based on the SHDSL frame CRC.

• For the correct and unambiguous definition of code violations, errored and severely errored seconds,
unavailability and lost synchronisation words seconds, refer to the recommendation G.826.
router1424/wanInterface/line/linePair[ ]/h24Performance
This attribute displays the 24 hours performance summary of the line. The h24Performance table contains
the same elements as the router1424/wanInterface/line/linePair[ ]/h2Performance table.
router1424/wanInterface/line/linePair[ ]/d7Performance
This attribute displays the 7 days performance summary of the line. The d7Performance table contains the
same elements as the router1424/wanInterface/line/linePair[ ]/h2Performance table.
router1424/wanInterface/line/linePair[ ]/performance
This attribute displays the performance summary of the line since the last cold boot. Except for the sysUp-
Time, the performance table contains the same elements as the router1424/wanInterface/line/linePair[ ]/
h2Performance table.
13.7 End and repeater performance attributes
Exactly which information is retrieved from the remote SHDSL device(s) through the EOC channel
depends on the setting of the eocHandling attribute. Refer to 5.5.4 - Which standard EOC information is
retrieved? on page 83 for an overview.
The performance information of the line pairs of the repeater and end device is only retrieved in case the
eocHandling attribute is set to info or alarmConfiguration. Other than that, the repeater[ ]/linePair[ ] and end/linePair[
] objects contain the same performance attributes as the line/linePair[ ] object. Refer to 13.6 - SHDSL line
performance attributes on page 1046 for more information on these attributes.
Note that the sysUpTime in the performance attributes of the repeater[ ]/linePair[ ] and end/linePair[ ] objects is
not the elapsed time since the last cold boot, but the elapsed time since the creation of the repeater[ ] or
end object.
13.8 Bundle performance attributes
This section describes the performance attributes of the different bundles that can be set up on the 1424
• 13.8.1 - PPP bundle performance attributes on page 1052
13.8.1 PPP bundle performance attributes
All performance attributes, except one, of the PPP bundle are the same as those of the LAN interface.
Therefore, they are not explained here again. Refer to 13.3 - LAN interface performance attributes on
page 1024 for a complete description of these attributes.
However, the following attribute is only present in the PPP bundle object and therefore explained in this
section:
• router1424/bundle/pppBundle[ ]/multiclassinterfaces on page 1053
router1424/bundle/pppBundle[ ]/multiclassinterfaces
This attribute displays the performance of the different multiclass PPP links in the PPP bundle.
The multiclassinterfaces table contains following elements:
Element Description
name This element displays the name of the multiclass PPP link as you defined it in the
multiclassInterfaces configuration attribute.
mibCounters This element displays the SNMP MIB2 parameters of the multiclass PPP link.
These are the same as the SNMP MIB2 parameters of the LAN interface. Refer to
13.3 - LAN interface performance attributes on page 1024.
13.9 Router performance attributes
This section discusses the performance attributes concerned with routing. First it describes the general
routing performance attributes. Then it explains the performance attributes of the extra features as there
are NAT, filtering, L2TP tunnelling, etc…
• 13.9.1 - General router performance attributes on page 1055
• 13.9.2 - NAT performance attributes on page 1064
• 13.9.3 - L2TP tunnel performance attributes on page 1069
• 13.9.4 - Native IPSEC tunnel performance attributes on page 1072
• 13.9.5 - GRE tunnel performance attributes on page 1074
• 13.9.6 - Manual SA performance attributes on page 1076
• 13.9.7 - IKE SA performance attributes on page 1078
• 13.9.8 - BGP performance attributes on page 1081
• 13.9.9 - Routing filter performance attributes on page 1090
• 13.9.10 - Firewall performance attributes on page 1092
• 13.9.11 - Virtual Routing and Forwarding (VRF) performance attirbutes on page 1096
13.9.1 General router performance attributes

• router1424/ip/router/routingTable on page 1056
• router1424/ip/router/radiusAuth on page 1057
• router1424/ip/router/radiusAcct on page 1057
• router1424/ip/router/pingResults on page 1058
• router1424/ip/router/tracertResults on page 1058
• router1424/ip/router/qualityMonitor on page 1059
• router1424/ip/router/startPing on page 1061
• router1424/ip/router/stopPing on page 1061
• router1424/ip/router/startTracert on page 1062
• router1424/ip/router/stopTracert on page 1063
• router1424/ip/router/clearTracert on page 1063
router1424/ip/router/routingTable
This attribute lists all known routes and how many times they are used.
The routingTable contains the following elements:
Element Description
network This element displays the IP address of the destination network.
mask This element displays the network mask of the destination network.
gateway This element displays the IP address of the next router on the path to the destina-
tion network.
interface This element displays the interface through which the destination network can be
reached. Possible values are:
• internal. The own protocol stack is used.
• <name>. The destination network can be reached through this particular inter-
face. The <name> of the interface is the name as you configured it.
Note that the “interface” can also be a DLCI, an ATM PVC, a tunnel, etc.
uses This element displays how many times the route has been used since it is listed in
the routing table.
For each IP packet that matches this route, the attribute value is incremented by
one. RIP routes may disappear from the routing table, and re-appear afterwards.
The attribute value is reset when a RIP route disappears from the routing table.
router1424/ip/router/radiusAuth
This attribute lists the RADIUS authentication server performance information.

The radiusAuth table contains the following elements:
Element Description
server This element displays the IP address of the authentication server.
requests This element displays the number of access requests that is sent to the authenti-
cation server.
accepts This element displays the number of access accepts that is received from the
authentication server.
rejects This element displays the number of access rejects that is received from the
challenges This element displays the number of access challenges that is received from the
badAuthenticators This element displays the total number of packets that contained invalid Message-
Authenticator attributes.
timeOuts This element displays the authentication time-out.
droppedPackets This element displays the number of incoming packets dropped for reasons other
than being malformed, bad authenticators, or unknown types.
router1424/ip/router/radiusAcct
This attribute lists the RADIUS accounting server performance information.

The radiusAcct structure contains the following elements:
Element Description
server This element displays the IP address of the accounting server.
requests This element displays the number of accounting requests that is sent to the
accounting server.
responses This element displays the number of accounting responses that is received from
the accounting server.
badAuthenticators This element displays the number of packets that contained invalid Signature
attributes.
timeOuts This element displays the accounting time-out.
droppedPackets This element displays the number of incoming packets dropped for reasons other
than being malformed, bad authenticators, or unknown types.
router1424/ip/router/pingResults
This attribute displays the results of a ping to an IP address started with the startPing action.
The pingResults structure contains the following elements:
Element Description
ipAddress This element displays the IP address of the host that is being pinged.
numOfTxPackets This element displays the number of transmitted pings.
numOfRxPackets This element displays the number of correct answers on the transmitted pings.
minReplyTime This element displays the lowest reply time of all correct answers.
maxReplyTime This element displays the highest reply time of all correct answers.
avrgReplyTime This element displays the average reply time of all correct answers.
router1424/ip/router/tracertResults
This attribute displays the results of a traceroute to an IP address/host started with the startTracert action.
The tracertResults table contains the following elements:
Element Description
ttl This element displays the Time To Live.
ipAddress This element displays the IP address of the hop that has been passed.
hostName This element displays the hostname of the hop that has been passed. Note that
this only displays
nrTx This element displays the number of traceroute queries that have been transmitted
to the hop.
nrRx This element displays the number of correct answers on the transmitted traceroute
queries that have been received from the hop.
minRtt This element displays the minimum Round-Trip Time that has been measured.
maxRtt This element displays the maximum Round-Trip Time that has been measured.
avrgRtt This element displays the average Round-Trip Time that has been calculated.
successRate This element displays the success rate. It is the ratio of nrRx/nrTx expressed in per-
cents.
comment This element displays some comments. E.g. Destination reached, Maximum number of
hops reached, etc.
router1424/ip/router/qualityMonitor
This attribute displays the performance statistics of the network links that are being monitored by the
quality monitor.
The qualityMonitor table contains the following elements:
Element Description
ipAddress This element displays the IP address of the end device of the link.
hostName This element displays the name of the end device of the link.
sourceIp This element displays the IP source address from which the quality monitoring is
initiated.
nbrOfTxPackets This element displays the total number of transmitted packets since the qualityMon-
itor was activated.
nbrOfRxPackets This element displays the total number of received packets since the qualityMonitor
was activated.
error This element displays the total number of received erroneous packets since the
qualityMonitor was activated.
delay This element displays the current delay of the link.

This element is expressed in seconds (sec).
jitter This element displays the current jitter of the link.

loss This element displays the current loss of the link within the defined loss window.
lossDelay This element displays the current loss of the link within the defined delay window.
When the loss window and delay window are equal, loss and lossDelay will have the
same value.
minDelay This element displays the minimum delay that was measured in the link.
avgDelay This element displays the average delay that was measured in the link.
maxDelay This element displays the maximum delay that was measured in the link.
maxJitterMin This element displays the maximum negative jitter deviation that was measured.
avgJitter This element displays the average jitter that was measured in the link.
maxJitterPlus This element displays the maximum positive jitter deviation that was measured.
Element Description
logging The logging table contains the data that is effectively logged to a file that is saved
on the file system of the device. It contains the following elements: sysUpTime,
nbrOfTxPackets, nbrOfRxPackets, error, loss, lossDelay, minDelay, avgDelay, maxDelay, maxJitter-
Min, avgJitter, maxJitterPlus.
The sysUpTime is the elapsed time since the quality monitor was activated.
The other elements have already been described in this table.
alarm This element provides more information about alarms that have been raised by the
quality monitor.
It is a bit string of which each bit corresponds to an alarm condition. The following
alarm conditions can be seen:
• loss.
• avgDelay.
• maxDelay.
• minMaxDelay.
• avgJitter.
• maxJitterPlus.
• maxJitterMin.
Of each alarm, it is indicated whether it is on or off.
router1424/ip/router/startPing
Use this action to start transmitting pings to an IP address or host. The result of the ping can be seen in
the pingResults attribute. Refer to router1424/ip/router/pingResults on page 1058.
The argument value structure of the startPing action contains the following elements:
Argument Description
ipAddress Use this element to specify the IP address of the host Default:0.0.0.0
you want to ping. Range: up to 255.255.255.255
If you fill in the ipAddress element you may omit the hostName element.
hostName Use this element to specify the hostname of the host Default:<empty>
you want to ping. Range: 0 … 255 characters
If you fill in the hostName element you may omit the ipAddress element.
sourceIp Use this element to specify the source IP address. Default:0.0.0.0

This can be used to force the source address to be Range: up to 255.255.255.255
something other than the IP address of the interface on which the traceroute query
is sent. If this IP address is not one of the 1424 SHDSL Router interface
addresses, then nothing is sent.
iterations Use this element to specify the number of pings. Default:5

If you set the iterations element to 0, then the host is Range: 0 …
pinged an indefinite number of times. The only way to stop the ping session is by
executing the stopPing action.
interval Use this element to specify the interval, in seconds, Default:1

between consecutive pings. Range: 0 … 100
dataLength Use this element to specify the length, in bytes, of the Default:31
data transmitted in a ping. Range: 0 … 1300
timeOut Use this element to specify the time-out period. Default:00000d 00h 00m 05s
If a ping is sent, the 1424 SHDSL Router waits during Range: 00000d 00h 00m 00s -
24855d 03h 14m 07s
this time-out period on the answer. If the answer is
received …
• within this time-out period, then ping is considered successful.
• outside this time-out period, then the ping is considered unsuccessful.
router1424/ip/router/stopPing
Use this action to stop pending pings.

router1424/ip/router/startTracert
Use this action to start a traceroute to an IP address or host. The result of the traceroute can be seen in
the tracertResults attribute. Refer to router1424/ip/router/tracertResults on page 1058.
The argument value structure of the startTracert action contains the following elements:
ipAddress Use this element to specify the IP address of the host Default:0.0.0.0
you want to trace. Range: up to 255.255.255.255
If you fill in the ipAddress element you may omit the hostName element.
hostName Use this element to specify the hostname of the host Default:<empty>
you want to trace. Range: 0 … 255 characters
If you fill in the hostName element you may omit the ipAddress element.
sourceIp Use this element to specify the source IP address. Default:0.0.0.0

This can be used to force the source address to be Range: up to 255.255.255.255
something other than the IP address of the interface on which the traceroute query
is sent. If this IP address is not one of the 1424 SHDSL Router interface
addresses, then nothing is sent.
startTtl Use this element to specify from which TTL onwards Default:1
you want to see the traceroute results. Range: 1 … 255
For example, if you set the startTtl element to 5, then the traceroute result displayed
in the tracertResult attribute starts from TTL number 5. 1 up to 4 is not displayed.
maxHops Use this element to specify the maximum number of Default:30

hops. Range: 1 … 255
If the maximum number of hops is reached but the destination host is still not
reached, then the last traceroute result displays the comment “Maximum number of
hops reached“.
The default of 30 hops is the same default used for TCP connections.
queriesPerHop Use this element to specify how many traceroute que- Default:3
ries have to be sent to each hop. Range: 1 … 65536
resolveHosts Use this element to enable or disable the resolving of Default:enabled

hop IP addresses to hostnames. Range: enabled / disabled
If you set the resolveHosts elements to …
• enabled (default), then the hostName element in the tracertResults attribute displays
the hostname of the hop.
• disabled, then the hostName element in the tracertResults attribute remains empty.
dnsTimeOut Use this element to set the DNS time-out. Default:00000d 00h 00m 03s
When hop IP addresses are resolved to hostnames, Range: 00000d 00h 00m 00s -
24855d 03h 14m 07s
then the DNS replies are expected within this time-out
period. Else they are no longer accepted.
icmpTimeOut Use this element to set the ICMP time-out. Default:00000d 00h 00m 03s
When a hop is queried, then the ICMP replies are Range: 00000d 00h 00m 00s -
24855d 03h 14m 07s
expected within this time-out period. Else they are no
longer accepted.
tos Use this element to set the Type Of Service in the Default:0
traceroute query. Range: 0 … 255
This can be used to investigate whether different service types result in different
paths. Useful values are 16 (low delay) and 8 (high throughput).
packetLength Use this element to set the traceroute query datagram Default:32
length in bytes. Range: 32 … 1300
router1424/ip/router/stopTracert
Use this action to stop pending traceroute queries.
router1424/ip/router/clearTracert
Use this action to clear the tracertResults table.

13.9.2 NAT performance attributes
ip/router/defaultNat

• socketsFree on page 1065
• allocFails on page 1065
• discards on page 1065
• addressesAvailable on page 1066
• tcpSocketsUsed on page 1066
• udpSocketsUsed on page 1066
• icmpSocketsUsed on page 1066
• tcpAllocs on page 1067
• udpAllocs on page 1067
• icmpAllocs on page 1067
• espSocketsUsed on page 1067
• greSocketsUsed on page 1067
• espAllocs on page 1067
• greAllocs on page 1067
• packetsToPublic on page 1067
• octetsToPublic on page 1067
• packetsToPrivate on page 1067
• octetsToPrivate on page 1067
• h2Nat on page 1068
• h24Nat on page 1068
• d7Nat on page 1068
• reset on page 1068
socketsFree
This attribute shows the remaining number of new connections (i.e. sockets) that can be initiated. A
socket is a set of source and destination IP addresses and port numbers.
Initially, 2048 simultaneous sockets can be initiated. Sockets are freed using a garbage mechanism.
This means that every five minutes all sockets are checked. If a socket has been released by PAT or
NAT, then this socket is returned to the pool of free sockets.
ICMP and UDP sockets are released when they have no data traffic during five minutes. TCP sockets
are released after the TCP session has been closed or when the session has been idle for 24 hours.
allocFails
If no sockets are available anymore but an attempt to set up a new connection is being made, then the
natAllocFails attribute value is incremented by 1.
Because the sockets are distributed using a hashing function, it is possible that natAllocFails increases
even though natSocketsFree still indicates free sockets.
Before TDRE12, ICMP required a new socket for each transmitted packet; this implied that, for instance,
a permanent ping or trace-route command could eventually use all free sockets.
As of TDRE12 however, this is not the case anymore: different ping sessions from the same source
address are reusing the same sockets.
discards
This attribute indicates how many times a packet has been discarded for reasons other than a lack of
free sockets. This could be, for instance, because an attempt was made to connect from the Internet to
a service that was not present in the servicesAvailable table.
addressesAvailable
This attribute displays the number of NAT addresses that are currently free.
tcpSocketsUsed
This attribute displays the number of sockets currently in use by PAT and NAT for TCP applications.
udpSocketsUsed
This attribute displays the number of sockets currently in use by PAT and NAT for UDP applications.
icmpSocketsUsed
This attribute displays the number of sockets currently in use by PAT and NAT for ICMP applications.
tcpAllocs
This attribute indicates how many TCP sockets have been allocated since cold boot. Together with the
performance attributes udpAllocs, icmpAllocs, espAllocs and greAllocs, it gives an indication of the type of traffic
that is being routed.
udpAllocs
This attribute indicates how many UDP sockets have been allocated since cold boot. Together with the
performance attributes tcpAllocs, icmpAllocs, espAllocs and greAllocs, it gives an indication of the type of traffic
icmpAllocs
This attribute indicates how many ICMP sockets have been allocated since cold boot. Together with the
performance attributes udpAllocs, tcpAllocs, espAllocs and greAllocs, it gives an indication of the type of traffic
espSocketsUsed
This attribute displays the number of sockets currently in use by PAT and NAT for ESP applications.
greSocketsUsed
This attribute displays the number of sockets currently in use by PAT and NAT for GRE applications.
espAllocs
This attribute indicates how many ESP sockets have been allocated since cold boot. Together with the
performance attributes udpAllocs, icmpAllocs, greAllocs and tcpAllocs, it gives an indication of the type of traffic
greAllocs
This attribute indicates how many GRE sockets have been allocated since cold boot. Together with the
performance attributes udpAllocs, tcpAllocs, icmpAllocs and espAllocs, it gives an indication of the type of traffic
packetsToPublic
This attribute indicates how many packets have been sent to the public network since cold boot.
octetsToPublic
This attribute indicates how many bytes have been sent to the public network since cold boot.
packetsToPrivate
This attribute indicates how many packets have been sent to the private network since cold boot.
octetsToPrivate
This attribute indicates how many packets have been sent to the private network since cold boot.
h2Nat
This attibute displays the 2 hours performance summary with regard to the connections on the 1424
SHDSL Router, showing the number of socket allocations and transferred data over a given interval.
The elements of the h2Nat table have already been described in this section.
h24Nat
This attibute displays the 24 hours performance summary with regard to the connections on the 1424
The elements of the h24Nat table have already been described in this section.
d7Nat
This attibute displays the 7 days performance summary with regard to the connections on the 1424
The elements of the d7Nat table have already been described in this section.
reset
Use this action to release all sockets currently in use and return them to the free socket pool.
In other words, executing this action resets all NAT/PAT sessions that are currently established. It also
releases all official IP addresses that are dynamically assigned to a private IP address. If any TCP ses-
sions are still active, these sessions will be aborted.
Take care when using this action! All TCP information is lost when the sockets are released with this
action. Any TCP sessions in use at the time of the reset will go into a hang-up state. These applications
will need to restart.
13.9.3 L2TP tunnel performance attributes

• router1424/ip/router/tunnels/l2tpTunnels on page 1070
• router1424/ip/router/tunnels/ipsecL2tpTunnels on page 1071
router1424/ip/router/tunnels/l2tpTunnels
This attribute displays the performance information of the L2TP tunnels.

Element Description
name This is the name of the tunnel as you configured it.
mibCounters This displays the SNMP MIB2 parameters of the tunnel.

inPriorityQueues This element displays the performance summary of the input priority queues on the
L2TP tunnel. In case an overload condition occurs and priority queuing is acti-
vated, then this elements displays how many packets the different queues contain.
The elements of the inPriorityQueues table have already been described in the ifOut-
PriorityQueues attribute of the LAN interface; refer to 13.3 - LAN interface perform-
ance attributes on page 1024 for a detailed description. Note that, here, they apply
on the input priority queues of the L2TP tunnel.
the priority queues.
outPriorityQueues This element displays the performance summary of the output priority queues on
the L2TP tunnel. In case an overload condition occurs and priority queuing is acti-
The elements of the outPriorityQueues table have already been described in the ifOut-
ance attributes on page 1024 for a detailed description.
ppp This element displays PPP related performance information of the L2TP tunnel.
The PPP structure contains the following elements:
• port. This is the interface index of the L2TP tunnel.
• lcp. This element displays LCP events of the L2TP tunnel.
• auth. This element displays authentication events of the L2TP tunnel.
• ipcp. This element displays IPCP events of the L2TP tunnel.
router1424/ip/router/tunnels/ipsecL2tpTunnels
This attribute displays the performance information of the L2TP tunnels.

The ipsecL2tpTunnels table contains the same elements as the l2tpTunnels table. Refer to router1424/ip/router/
tunnels/l2tpTunnels on page 1070.
13.9.4 Native IPSEC tunnel performance attributes
This section describes the following performance attribute:

• router1424/ip/router/tunnels/ipsecTunnels on page 1073
router1424/ip/router/tunnels/ipsecTunnels
This attribute displays the performance information of the IPSEC tunnels.

Element Description

13.9.5 GRE tunnel performance attributes

• router1424/ip/router/tunnels/greTunnels on page 1075
• router1424/ip/router/tunnels/ipsecGreTunnels on page 1075
router1424/ip/router/tunnels/greTunnels
This attribute displays the performance information of the GRE tunnels.

Element Description

inPriorityQueues This element displays the performance summary of the input priority queues of the
GRE tunnel. In case an overload condition occurs and priority queuing is activated,
then this elements displays how many packets the different queues contain.
The elements of the inPriorityQueues table have already been described in the ifOut-
ance attributes on page 1024 for a detailed description. Note that, here, they apply
on the input priority queues of the GRE tunnel.
outPriorityQueues This element displays the performance summary of the output priority queues of
the GRE tunnel. In case an overload condition occurs and priority queuing is acti-
The elements of the outPriorityQueues table have already been described in the ifOut-
ance attributes on page 1024 for a detailed description.
router1424/ip/router/tunnels/ipsecGreTunnels
This attribute displays the performance information of the IPSEC GRE tunnels.
The ipsecGreTunnels table contains the same elements as the greTunnels table. Refer to router1424/ip/router/
tunnels/greTunnels on page 1075.
13.9.6 Manual SA performance attributes

• router1424/ip/router/manualSA[ ]/inPackets on page 1077
• router1424/ip/router/manualSA[ ]/outPackets on page 1077
• router1424/ip/router/manualSA[ ]/espDecryptionFailure on page 1077
• router1424/ip/router/manualSA[ ]/espAuthenticationFailure on page 1077
• router1424/ip/router/manualSA[ ]/espSequenceNrReplay on page 1077
• router1424/ip/router/manualSA[ ]/espDroppedFrames on page 1077
router1424/ip/router/manualSA[ ]/inPackets
Upon receipt of a (reassembled) packet containing an ESP Header, the receiver determines the appro-
priate SA, based on the destination IP address, security protocol (ESP), and the SPI. Once the appro-
priate SA is determined, the inPackets attribute is incremented for this SA.
router1424/ip/router/manualSA[ ]/outPackets
ESP is applied to an outbound packet only after it is determined that the packet is associated with an SA
that calls for ESP processing. Once the appropriate SA is determined, the outPackets attribute is incre-
mented for this SA.
router1424/ip/router/manualSA[ ]/espDecryptionFailure
This attribute displays the number of times the decryption of an incoming ESP packet failed.
router1424/ip/router/manualSA[ ]/espAuthenticationFailure
This attribute displays the number of times the authentication of an incoming ESP packet failed.
router1424/ip/router/manualSA[ ]/espSequenceNrReplay
For each incoming ESP packet, the receiver verifies that the packet contains a sequence number that
does not duplicate the sequence number of any other packets received during the life of this SA. Should
this be the case, then these packets are dropped and the espSequenceNrReplay attribute is incremented for
this SA.
router1424/ip/router/manualSA[ ]/espDroppedFrames
This attribute displays the number of ESP packets that were successfully decrypted and authenticated,
but that could not be delivered to the L2TP tunnel (e.g. because the tunnel was down) and had to be
dropped.
13.9.7 IKE SA performance attributes

• router1424/ip/router/ikeSA[ ]/phase2Negotiations on page 1079
• router1424/ip/router/ikeSA[ ]/phase2Sessions on page 1079
router1424/ip/router/ikeSA[ ]/phase2Negotiations
This attribute displays performance information of the IKE phase 2 negotiation process.
The phase2Negotiations table contains the following elements:
Element Description
initStarted This element displays the number of IKE phase 2 negotiation initiations that were
started.
respStarted This element displays the number of IKE phase 2 negotiation responses that were
started.
succeeded This element displays the number of IKE phase 2 negotiations that succeeded.
failed This element displays the number of IKE phase 2 negotiations that failed.
expiredSA This element displays the number of IKE SAs that expired.
router1424/ip/router/ikeSA[ ]/phase2Sessions
This attribute displays performance information of the IKE phase 2 sessions.

Element Description
direction This element displays the direction of the IPSEC SA. Possible values are: inbound
or outbound.
spi This element displays the Security Parameter Index of the IPSEC SA.
protocol This element displays which protocol is used in the IPSEC SA. Possible values
are: esp or ah.
outPackets This element displays the number of outbound packets for which an appropriate
SA could be determined.
Only after an appropriate SA could be determined, the security protocol (ESP or
AH) is applied to the outbound packet.
outOctets This element displays the number of outbound octets (bytes) for which an appro-
priate SA could be determined.
inPackets This element displays the number of inbound packets for which an appropriate SA
could be determined.
Only after an appropriate SA could be determined, the inbound packet is accepted.
inOctets This element displays the number of inbound octets (bytes) for which an appropri-
ate SA could be determined.
authenticationFail- This element displays the number of times the authentication of an incoming
ure packet failed.
Element Description
decryptionFailure This element displays the number of times the decryption of an incoming packet
failed.
sequenceNrReplay For each incoming packet, the receiver verifies that the packet contains a
sequence number that does not duplicate the sequence number of any other pack-
ets received during the life of this SA. Should this be the case, then these packets
are dropped and the sequenceNrReplay attribute is incremented for this SA.
droppedFrames This element displays the number of packets that were successfully decrypted and
authenticated, but that could not be delivered to the L2TP tunnel (e.g. because the
tunnel was down) and had to be dropped.
13.9.8 BGP performance attributes
This section discusses the performance attributes concerned with BGP. First, the ePeer and iPeer BGP
performance attributes are discussed, followed by the routeFilter and routeMap performance attributes.
• ePeer and iPeer performance attributes on page 1082
• routeFilter performance attributes on page 1086
• routeMap performance attributes on page 1088
ePeer and iPeer performance attributes

• router1424/router/bgp/ePeer[ ]/sessions on page 1083
• router1424/router/bgp/ePeer[ ]/messagesSent on page 1083
• router1424/router/bgp/ePeer[ ]/messagesRcvd on page 1083
• router1424/router/bgp/ePeer[ ]/prefixesSent on page 1084
• router1424/router/bgp/ePeer[ ]/prefixesRcvd on page 1084
• router1424/router/bgp/ePeer[ ]/inboundFilters on page 1084
• router1424/router/bgp/ePeer[ ]/outboundfilters on page 1085
• router1424/router/bgp/ePeer[ ]/inboundMaps on page 1085
• router1424/router/bgp/ePeer[ ]/outboundMaps on page 1085
The attributes above all refer to the ePeer object. The attributes of the iPeer object are identical.
router1424/router/bgp/ePeer[ ]/sessions
This attribute displays counters which are useful to check the stability of a BGP peer session.
The sessions structure contains the following elements:
Element Description
established This element displays the number of times the peer has reached the established
state.
dropped This element displays the number of times the peer has dropped out of the estab-
lished state.
router1424/router/bgp/ePeer[ ]/messagesSent
This attribute displays counters keeping track of the number of different BGP messages sent.
The messagesSent structure contains the following elements:
Element Description
open This element displays the number of open messages sent.
keepAlive This element displays the number of keep alive messages sent.
update This element displays the number of update messages sent.
notify This element displays the number of notify messages sent.
router1424/router/bgp/ePeer[ ]/messagesRcvd
This attribute displays counters keeping track of the number of different BGP messages received.
The messagesSent structure contains the following elements:
Element Description
open This element displays the number of open messages received.
keepAlive This element displays the number of keep alive messages received.
update This element displays the number of update messages received.
notify This element displays the number of notify messages received.

router1424/router/bgp/ePeer[ ]/prefixesSent
This attribute displays the number of prefixes in the update messages sent over a peer.
The prefixesSent structure contains the following elements:
Element Description
announced This element displays the number of announced prefixes, which are new or have
changed in the routing table.
withdrawn This element displays the number of prefixes, withdrawn from the routing table.
router1424/router/bgp/ePeer[ ]/prefixesRcvd
This attribute displays the number of prefixes in the update messages received over a peer.
The prefixesSent structure contains the following elements:
Element Description
announced This element displays the number of announced prefixes, which are new or have
to be changed in the routing table.
withdrawn This element displays the number of prefixes, which must be withdrawn from the
routing table.
router1424/router/bgp/ePeer[ ]/inboundFilters
This attribute displays a list of the BGP routeFilter objects which will be applied on all announced prefixes
in incoming update packets.
The inboundFilters table contains the following elements:
Element Description
name This element displays the name of the routeFilter object.
uses This element displays the number of matching prefixes received on this peer, on
which this inbound filter is applied.
router1424/router/bgp/ePeer[ ]/outboundfilters
This attribute displays a list of the BGP routeFilter objects which will be applied on all announced prefixes
in outgoing update packets.
The outboundFilters table contains the following elements:
Element Description
name This element displays the name of the routeFilter object.
uses This element displays the number of matching prefixes scheduled to be sent out
on this peer, on which this outbound filter is applied.
router1424/router/bgp/ePeer[ ]/inboundMaps
This attribute displays a list of the BGP routeMap objects which will be applied on all announced prefixes
in incoming update packets.
The inboundMaps table contains the following elements:
Element Description
name This element displays the name of the routeMap object.
uses This element displays the number of matching prefixes received on this peer, on
which this inbound map is applied.
router1424/router/bgp/ePeer[ ]/outboundMaps
This attribute displays a list of the BGP routeMap objects which will be applied on all announced prefixes
in outgoing update packets.
The outboundMaps table contains the following elements:
Element Description
name This element displays the name of the routeMap object.
uses This element displays the number of matching prefixes scheduled to be sent out
on this peer, on which this outbound map is applied.
routeFilter performance attributes

• router1424/router/bgp/routeFilter[ ]/uses on page 1087
• router1424/router/bgp/routeFilter[ ]/filters on page 1087
router1424/router/bgp/routeFilter[ ]/uses
This attribute displays the number of times a match has been found within the filter table.
router1424/router/bgp/routeFilter[ ]/filters
This attribute displays a more detailed overview of the filter rows and the matches per row.
The filters table contains the following elements:
Element Description
network This element displays the configured network after applying the prefixLength.
prefixLength This element displays the prefixLength configuration, displayed in maskLength [min-
Len .. maxLen] format.
nextHop This element displays the configured nextHop value.
asPath This element displays the asPath filtering configuration, displayed as a regular
expression.
origin This element displays the configured origin value.
med This element displays the configured med value.
mode This element displays the configured action.
uses This element displays the number of times a match has been found for this filter
row.
routeMap performance attributes
This section describes the following performance attribute:

• router1424/router/bgp/routeMap[ ]/uses on page 1089
router1424/router/bgp/routeMap[ ]/uses
This attribute displays the number of times this routeMap has been applied.
13.9.9 Routing filter performance attributes
This section describes the performance attributes of the following objects:
router1424/ip/router/routingFilter[ ]
This object contains the following attribute:

• filter on page 1091
filter
This attribute displays the performance of the routing update filter.

The filter table contains the following elements:
Element Description
network This is the IP address of the network.
mask This is the IP subnet mask of the network.
uses This is the number of times the network has been forwarded.
13.9.10 Firewall performance attributes

• router1424/ip/router/firewall/h24General on page 1093
• router1424/ip/router/firewall/d7General on page 1093
• router1424/ip/router/firewall/h24Attack on page 1094
• router1424/ip/router/firewall/d7Attack on page 1095
router1424/ip/router/firewall/h24General
This attribute displays the 24 hours general performance summary.

The h24General table contains the following elements:
maxConn the number of times that the maximum number of connections was reached.
maxResource the number of times that the used resources exceeded 80%. This could indicate
flooding.
serviceAcc the number of service access requests that were successful.
noSrcRoute the number of times that no route to the source could be found.
srcBcast the number of source address broadcasts.
synUnable the number of times that no SYN packet could be sent.
finalAckFail the number of times that no final ACK could be sent.
denyPolicy the number of times that a deny policy matched.
connLimit the number of times that the maximum number of connections was reached.
srcRouteOpt the number of times that the source routing option was set for an IP packet.
policyDeleted the number of times that the policy was already deleted.
noDestRoute the number of times that no route to the destination could be found.
rejToSelf the number of times that packets to self were rejected.
destBcast the number of destination address broadcasts.
noInPol the number of times that no inbound policy could be found.
noOutPol the number of times that no outbound policy could be found.
router1424/ip/router/firewall/d7General
This attribute displays the 7 days general performance summary.

The d7General table contains same elements as the h24General table. Refer to router1424/ip/router/firewall/
h24General on page 1093.
router1424/ip/router/firewall/h24Attack
This attribute displays the 24 hours attack summary.

The h24Attack table contains the following elements:
landAttack the number of (possible) land attacks.
spoofedPacket the number of spoofed packets.
badTcpConnReq the number of invalid TCP connection requests.
badTcpAck the number of invalid TCP ACKs.
unexpUdpE- the number of received UDP echo responses for uninitiated requests.
choResp
unexpIcmpE- the number of received ICMP echo responses for uninitiated requests.
choResp
genAttack the number of general attacks.
minIpHdrLen the number of packets with an IP header length less than the minimum length.
emptyPacket the number of packets without data.
badTcpLen the number of times the TCP packet length was invalid.
shortTcpHdr the number of packets with short TCP header length.
tcpNullScan the number of TCP null scan attacks.
badUdpLen the number of times the UDP packet length was invalid.
shortUdpHdr the number of packets with short UDP header length.
shortIcmpLen the number of packets with short ICMP length.
synAttack the number of SYN attacks.
postTcpRst the number of data packets received after reset.
blindSpoofing the number of blind spoofing attacks.
zeroBytes the number of times zero bytes were transferred for a connection.
seqNumOutOf- the number of packets with an out-of-range sequence number.

Range
winNuke the number of WinNuke attacks.
badTcpSeqNumRst the number of invalid sequence numbers with reset.
zeroLenIpOpt the number of zero length IP options detected.
badIpTimeStamp the number of unaligned timestamp options detected.
unexpData the number of times unexpected data was received for uninitiated traffic.
unexpIcmpErr the number of received ICMP error messages for uninitiated requests.
badSrcIf the number of times the source interface was invalid.

router1424/ip/router/firewall/d7Attack
This attribute displays the 7 days attack summary.

The d7Attack table contains same elements as the h24Attack table. Refer to router1424/ip/router/firewall/
h24Attack on page 1094.
13.9.11 Virtual Routing and Forwarding (VRF) performance attirbutes
This section describes the performance attributes of the following objects:

• routingTable
• pingResults
• tracertResults
• igmpProxy
These attributes have already been described in 13.9.1 - General router performance attributes on

• filter
This attribute has already been described in 13.9.9 - Routing filter performance attributes on page 1090.
Refer to this section for more information.
13.10 IP traffic policy performance attributes

• router1424/profiles/policy/traffic/ipTrafficPolicy[ ]/discards on page 1098
• router1424/profiles/policy/traffic/ipTrafficPolicy[ ]/trafficShaping on page 1098
router1424/profiles/policy/traffic/ipTrafficPolicy[ ]/discards
This attribute indicates how many packets have been discarded based on the criteria that are defined by
the IP traffic policy.
router1424/profiles/policy/traffic/ipTrafficPolicy[ ]/trafficShaping
This attribute shows the usage of each line in the traffic shaping table.
The trafficShaping table contains the following elements:
Element Description
name This is the name of the line in the traffic shaping table as you configured it.
uses This is the number of times this line in the traffic shaping table is used.
sourceIpStart- This is the IP source address range as you configured it.

Address
sourceIpEnd-
Address
destinationIpStart- This is the IP destination address range as you configured it.

Address
destinationIpEnd-
Address
tosStartValue This is the TOS range as you configured it.
tosEndValue Packets that fall within the specified range are forwarded and queued if applicable.
ipProtocolStart This is the protocol range as you configured it.
ipProtocolEnd Packets that have the specified protocol field are forwarded and queued if applica-
ble.
sourcePortStart This is the source port range as you configured it.
sourcePortEnd Packets that fall within the specified range are forwarded and queued if applicable.
destinationPortStart This is the destination port range as you configured it.
destinationPortEnd Packets that fall within the specified range are forwarded and queued if applicable.
newTosValue This is the new TOS value as you configured it.
priority This is the destination queue as you configured it.

In case an overload condition occurs, then a packet that matches an entry in the
trafficShaping table is sent to the specified queue.
octets This is the number of octets that were treated by the line in the traffic shaping table.
destination This is the destination interface. It could also be discard, meaning that these packets
were denied.
13.11 Bridge performance attributes
This section discusses the performance attributes concerned with bridging. First it describes the general
bridging performance attributes. Then it explains the performance attributes of the extra features as
there are access listing, etc…
• 13.11.1 - Bridge group performance attributes on page 1100
• 13.11.2 - Bridge access list performance attributes on page 1107
13.11.1 Bridge group performance attributes

• bridgeDiscards on page 1102
• bridgeFloods on page 1102
• bridgeBroadcasts on page 1102
• bridgeMulticasts on page 1102
• cacheEvents on page 1104
• bridgeRxPkts on page 1104
• bridgeTxPkts on page 1104
• d7Performance on page 1106
bridgeCache
Element Description
interface.
vlanId This element displays the VLAN ID of the VLAN the interface is part of.
filterId This is the ID that identifies the VLAN group the VLAN belongs to.
rxPkts This is the number of packets received from the corresponding MAC address.
txPkts This is the number of packets forwarded to the corresponding MAC address.
staticViolations This is the number of packets that have been counted as static violation, for the
respective interface and macAddress.
When a packet arrives on an interface with a source address which is not known
in the bridge cache, the packet is discarded and counted as a static violation. This
normally only occurs when learning is disabled on the bridging interface.
Also note that, when learning is disabled and there is no entry in the staticBridgeCache,
staticViolations are still counted when packets are received (eventhough the static-
BridgeCache is empty).
When this kind of staticViolations occurs, there is no possibility for searching which
MAC address is the cause of the static violation, since there is no entry of this MAC
address in the bridgeCache.
Refer to 8.2.6 - Explaining the bridging structure on page 318 for more information
about the learning element.
relearns This is the number of packets that have been relearned via the respective interface
and macAddress. This indicates that some inconsistency is present in the network.
relearnDrops This is the number of relearned packets on the interface that have been dropped.
bridgeDiscards
This attribute displays the number of times a frame was discarded because …
• it was received on the same interface as the one through which the destination address can be
reached.
• it was received on an interface that is not in the forwarding state.
bridgeFloods
This attribute displays the number of times a frame was flooded on all interfaces because the position of
the station with the destination MAC address was not known (yet).
bridgeBroadcasts
This attribute displays the number of times a frame was flooded on all interfaces because it was a broad-
cast.
bridgeMulticasts
This attribute displays the number of times a frame was flooded on all interfaces because it was a mul-
ticast.
vlan
This attribute displays the SNMP MIB2 performance parameters of the VLANs that are present on the
bridge group.
Element Description
name This element displays the name of the VLAN as you configured it.
vlan This element displays the VLAN ID.
mibCounters This element displays the SNMP MIB2 performance parameters of the VLAN.
vlanSwitching
This attribute displays the performance information of the VLAN switching process.
The vlanSwitching table contains the following elements:
Element Description
sourceIntf This element displays the name of the source interface which carries the VLAN
that is being switched.
sourceVlan This element displays the VLAN ID of the source VLAN.
sourcePFilter This element displays the filter that is applied on the priority bits of the source
VLAN packets.
destinationIntf This element displays the name of the destination interface.
destinationVlan This element displays the VLAN ID of the destination VLAN.
tunnelMode This element displays wheather or not tunnel mode has been enabled or disabled
between source and destination.
uses This element displays the number of packets that have been switched.
cacheEvents
This attribute displays some unusual events with regard to the bridge cache.
The cacheEvents table contains the following elements:
Element Description
sizeOverflows This element displays the number of times the maximum allowed bridge cache
size has been exceeded.
staticViolations This is the total number of packets that have been counted as static violation.
When a packet arrives on an interface with a source address which is not known
in the bridge cache, the packet is discarded and counted as a static violation. This
normally only occurs when learning is disabled on the bridging interface.
Also note that, when learning is disabled and there is no entry in the staticBridgeCache,
staticViolations are still counted when packets are received (eventhough the static-
BridgeCache is empty).
When this kind of staticViolations occurs, there is no possibility for searching which
MAC address is the cause of the static violation, since there is no entry of this MAC
address in the bridgeCache.
Refer to 8.2.6 - Explaining the bridging structure on page 318 for more information
about the learning element.
relearns This is the total number of packets that have been relearned within the bridge
group on the different interfaces. This indicates that some inconsistency is present
in the network.
relearnDrops This is the total number of relearned packets that have been dropped within the
bridge group on the different interfaces.
bridgeRxPkts
This is the total number of packets received by the bridge group.
bridgeTxPkts
This is the total number of packets forwarded by the bridge group.

bridging
This attribute displays bridging performance information per individual bridging interface.
The bridging table contains the following elements:
Element Description
name This is the name of the bridging interface.
rxPkts This is the total number of packets received on the interface.
txPkts This is the total number of packets forwarded on the interface.
rxDiscards This is the number of times a frame was discarded on the interface.
rxFloods This is the number of times a frame was received that was flooded on all interfaces.
rxBroadcasts This is the number of times a broadcast frame was received on the interface.
rxMulticasts This is the number of times a multicast frame was received on the interface.
cache The cache structure contains the following elements: sizeOverflows, staticViolations,
relearns and relearnDrops.
Refer to cacheEvents on page 1104 for a detailed explanation; here, they apply to the
specific interface.
h2Performance This attribute displays the 2 hours bridging performance summary of the interface.
h24Performance This attribute displays the 24 hours performance summary of the bridge group.
d7Performance This attribute displays the 7 days performance summary of the bridge group.
h2Performance
This attribute displays the 2 hours performance summary of the bridge group.
rxPkts the total number of received packets.
txPkts the total number of transmitted packets.
discards the number of frames that were discarded.
floods the number of received frames that were flooded on all interfaces.
broadcasts the number of broadcast frames that were received.
multicasts the number of multicast frames that were received.
cacheSizeOverflows the number of times the maximum allowed bridge cache size has been
exceeded.
staticCacheViolations the number of packets that have been counted as static violations.
cacheRelearns the number of packets that have been relearned.
cacheRelearnDrops the number of relearned packets that have been dropped.
h24Performance
This attribute displays the 24 hours performance summary of the bridge group. The h24Performance table
contains the same elements as the h2Performance.
d7Performance
This attribute displays the 7 days performance summary of the bridge group. The d7Performance table con-
tains the same elements as the h2Performance.
13.11.2 Bridge access list performance attributes

• router1424/bridge/accessList[ ]/bridgeAccessList on page 1108
• router1424/bridge/accessList[ ]/advancedFilter on page 1108
router1424/bridge/accessList[ ]/bridgeAccessList
This attribute shows information on the use of the bridge access list.
The bridgeAccessList table contains the following elements:
Element Description
macAddress This is the MAC address as configured in the configuration attribute router1424/
bridge/accessList[ ]/bridgeAccessList.
uses This indicates the number of times a packet has been discarded for the corre-
sponding MAC address.
router1424/bridge/accessList[ ]/advancedFilter
This attribute shows information on the advanced filters as configured in advancedFilter on page 788.
For every advanced filter that was defined, one line appears here in the advancedFilter table. This table
gives an indication of the efficiency of the defined filter(s).
Ideally, the filter with the highest number of matches, should be at the top of the table. When this is not
the case, it is recommendable the redefine the advancedFilter table (refer to advancedFilter on page 788).
The advancedFilter table contains the following elements:
Element Description
name This is the name of the advanced filter.
matched This is a counter that displays the number of packets that matched the defined fil-
ter.
checked This is a counter that displays the total number of packets that were checked by
the defined filter.
sourceMacStart This is the start address of the source MAC address range that was filtered.
sourceMacEnd This is the end address of the source MAC address range that was filtered.
destinationMacStart This is the start address of the destination MAC address range that was filtered.
destinationMacEnd This is the end address of the destination MAC address range that was filtered.
vlan This is the VLAN that was defined in the advanced filter.
priority This is the value of the priority bits, in the VLAN header of the filtered frames, that
was defined in the advanced filter.
protocol This is the protocol that was defined in the advanced filter.
action This is the action that was executed on the filtered frames.
advanced This is the advanced action that was executed on the filtered frames.
13.12 SNMP performance attributes

• router1424/snmp/mib2Counters on page 1110
• router1424/snmp/mpdStats on page 1111
• router1424/snmp/usmStats on page 1111
router1424/snmp/mib2Counters
This attribute displays the SNMP performance parameters.

The mib2Counters structure contains the following elements:
Element Description
inPkts This is the total number of received SNMP messages.
outPkts This is the total number of SNMP Messages that were sent.
inBadVersions This is the total number of received SNMP Messages that were for an
unsupported SNMP version.
inBadCommunityNames This is the total number of SNMP Messages delivered to the 1424 SHDSL
Router which used an unknown SNMP community name.
inAsnParseErrs This is the total number of ASN.1 or BER errors encountered by the 1424
SHDSL Router when decoding received SNMP Messages.
inTotalReqVars This is the total number of MIB objects which have been retrieved success-
fully by the 1424 SHDSL Router as the result of receiving valid SNMP Get-
Request and Get-Next PDUs.
inTotalSetVars This is the total number of MIB objects which have been altered successfully
by the 1424 SHDSL Router as the result of receiving valid SNMP Set-
Request PDUs.
inGetRequests This is the total number of SNMP Get-Request PDUs which have been
accepted and processed by the 1424 SHDSL Router.
inGetNexts This is the total number of SNMP Get-Next PDUs which have been
inSetRequests This is the total number of SNMP Set-Request PDUs which have been
inGetResponses This is the total number of SNMP Get-Response PDUs which have been
inTraps This is the total number of SNMP Trap PDUs which have been accepted
and processed by the 1424 SHDSL Router.
outTooBigs This is the total number of SNMP PDUs which were generated by the 1424
SHDSL Router and for which the value of the error status field is tooBig.
outNoSuchNames This is the total number of SNMP PDUs which were generated by the 1424
SHDSL Router and for which the value of the error status field is
noSuchName.
outBadValues This is the total number of SNMP PDUs which were generated by the 1424
SHDSL Router and for which the value of the error status field is badValue.
outGenErrs This is the total number of SNMP PDUs which were generated by the 1424
SHDSL Router and for which the value of the error status field is genErr.
outGetResponses This is the total number of SNMP Get-Response PDUs which have been
generated by the 1424 SHDSL Router.
Element Description
outTraps This is the total number of SNMP Trap PDUs which have been generated
by the 1424 SHDSL Router.
router1424/snmp/mpdStats
This attribute displays the SNMP Message Processing and Dispatching parameters.
The mpdStats structure contains the following elements:
Element Description
unknownsecurityModels This is the total number of packets received by the SNMP engine which
were dropped because they referenced a security model that was not known
to or supported by the SNMP engine.
invalidMsgs This is the total number of packets received by the SNMP engine which
were dropped because there were invalid or inconsistent components in the
SNMP message.
unknownPduHandlers This is the total number of packets received by the SNMP engine which
were dropped because the PDU contained in the packet could not be
passed to an application responsible for handling the PDU type.
router1424/snmp/usmStats
This attribute displays the SNMP User-based Security Model parameters.

The mpdStats structure contains the following elements:
Element Description
unsupportedSecLevels This is the total number of packets received by the SNMP engine which
were dropped because they requested a security level that was unknown to
the SNMP engine or otherwise unavailable.
notInTimeWindows This is the total number of packets received by the SNMP engine which
were dropped because they appeared outside of the authoritative SNMP
engine's window.
unknownUserNames This is the total number of packets received by the SNMP engine which
were dropped because they referenced a user that was not known to the
SNMP engine.
unknownEngineIds This is the total number of packets received by the SNMP engine which
were dropped because they referenced an snmpEngineId that was not known
to the SNMP engine.
wrongDigests This is the total number of packets received by the SNMP engine which
were dropped because they did not contain the expected digest value.
decryptionErrors This is the total number of packets received by the SNMP engine which
were dropped because they could not be decrypted.
13.13 Management performance attributes

• router1424/management/cms2SessionCount on page 1113
• router1424/management/cliSessionCount on page 1113
• router1424/management/tftpSessionCount on page 1114
• router1424/management/tcpSessionCount on page 1114
• router1424/management/ipStackEvents on page 1114
router1424/management/cms2SessionCount
This attribute displays the number of CMS2 sessions that are currently active on the 1424 SHDSL
Router.
There are always minimum two fixed sessions active. Connecting with TMA, TMA CLI, Telnet, etc. opens
additional sessions. This is explained in the following table:
Session count Purpose
1 fixed session A fixed session for SNMP.
1 fixed session A fixed session for O10.
+ 2 sessions When connecting with TMA.
+ 1 session When connecting with TMA for HP OpenView or the Alarm Manager.
+ 1 session When connecting with TMA CLI.
+ 2 sessions When downloading a config.cli or config.cms file.
+ 1 session When connecting with Telnet.
+ 1 session When downloading software.
+ 1 session When connecting with the Web Interface.
router1424/management/cliSessionCount
This attribute displays the number of CLI sessions that are currently active on the 1424 SHDSL Router.
There are always minimum two fixed sessions active. Connecting with TMA CLI, the Web Interface, etc.
opens additional sessions. This is explained in the following table:
1 fixed session A fixed session for the control port.
1 fixed session A fixed session for Web Interface.
+ 1 session When connecting with TMA CLI or starting a CLI session.

router1424/management/tftpSessionCount
This attribute displays the number of TFTP sessions that are currently active on the 1424 SHDSL Router.
router1424/management/tcpSessionCount
This attribute displays the number of TCP sessions that are currently active on the 1424 SHDSL Router.
The following table shows when a TCP session opens:
+ 1 session When connecting with Telnet.
router1424/management/ipStackEvents
This attribute gives an indication of the internal load of the protocol stack.
13.14 Operating system performance attributes

• router1424/operatingSystem/currUsedProcPower on page 1116
• router1424/operatingSystem/usedProcPower on page 1116
• router1424/operatingSystem/freeDataBuffers on page 1116
• router1424/operatingSystem/totalDataBuffers on page 1116
• router1424/operatingSystem/largestFreeBlockSize on page 1116
• router1424/operatingSystem/freeBlockCount on page 1116
• router1424/operatingSystem/freeMemory on page 1117
• router1424/operatingSystem/totalMemory on page 1117
• router1424/operatingSystem/taskInfo on page 1117
router1424/operatingSystem/currUsedProcPower
This attribute displays the amount of processing power used during the last 650 milliseconds, expressed
as a percentage of the total available processing power.
router1424/operatingSystem/usedProcPower
This attribute lists the used processing power for the 11 most recent 30 seconds intervals. The process-
ing power is expressed as a percentage of the total processing power.
The usedProcPower table contains the following elements:
Element Description
sysUpTime This is the elapsed time since the last cold boot. The next values are for the 30
seconds period before this relative time stamp.
min This is the minimum percentage of processing power in use during the last 30 sec-
onds.
average This is the average percentage of processing power in use during the last 30 sec-
onds.
max This is the maximum percentage of processing power in use during the last 30 sec-
onds.
router1424/operatingSystem/freeDataBuffers
The processor uses buffers for storing the packets during processing and/or queuing. Each buffer has a
256 byte size, headers included. This attribute is the number of data buffers currently not in use and
available for e.g. incoming data.
router1424/operatingSystem/totalDataBuffers
This attribute displays the total number of available data buffers.
router1424/operatingSystem/largestFreeBlockSize
The processor uses RAM memory for storing internal information and buffering. The different tasks allo-
cate RAM memory on request. Tasks may also free memory again. In this way the total RAM memory
becomes fragmented. This attribute gives the size of the largest contiguous free memory block
expressed in bytes.
router1424/operatingSystem/freeBlockCount
This attribute displays the number of free contiguous memory blocks.

router1424/operatingSystem/freeMemory
This attribute displays the total free memory expressed in bytes.
router1424/operatingSystem/totalMemory
This attribute displays the total RAM memory expressed in bytes.
router1424/operatingSystem/taskInfo
This attribute contains status information concerning the different tasks running on the processor. It is a
table grouping up to 31 task slots, which is the maximum number of parallel tasks running on the proc-
essor's operating system.
This attribute contains the same elements as the status attribute router1424/operatingSystem/taskInfo on
page 1012.
User manual Alarm attributes
14 Alarm attributes
This chapter discusses the alarm attributes of the 1424 SHDSL Router. The following gives an overview
of this chapter:
• 14.1 - Alarm attributes overview on page 1120
• 14.2 - Introducing the alarm attributes on page 1123
• 14.3 - General alarms on page 1126
• 14.4 - LAN interface alarms on page 1128
• 14.5 - WAN interface alarms on page 1129
• 14.6 - EFM alarms on page 1131
• 14.7 - SHDSL line alarms on page 1132
• 14.8 - SHDSL line pair alarms on page 1133
• 14.9 - End and repeater alarms on page 1135
• 14.10 - Bundle alarms on page 1139
• 14.11 - Router and vrfRouter[ ] alarms on page 1140
• 14.12 - Bridge group alarms on page 1141
• 14.13 - BGP ePeer and iPeer alarms on page 1142
14.1 Alarm attributes overview
> router1424
totalAlarmLevel
alarmInfo
notResponding
alarmSyncLoss
configChanged
access
unknownStatus
coldBoot
warmBoot
codeConsistencyFail
configConsistencyFail
>> lanInterface
alarmInfo
linkDown
>> dslInterface
alarmInfo
linkDown
>>> channel[ ]
linkDown
>>>> efm
linkDown
>>> line
alarmInfo
linkDown
invalidNumRepeaters
testActive
>>>> linePair[ ]
alarmInfo
linkDown
lineAttenuation
noiseMargin
errSecRatioExceeded
bbErrRatioExceeded
>>> repeater[ ]
alarmInfo
linkDown
remoteAlarmHigh
remoteAlarmLow
unknownState
alarmInfo
lineAttenuation
noiseMargin
errSecRatioExceeded
bbErrRatioExceeded
alarmInfo
lineAttenuation
noiseMargin
errSecRatioExceeded
bbErrRatioExceeded
>>> end
alarmInfo
linkDown
remoteAlarmHigh
remoteAlarmLow
unknownState
>>>> linePair[ ]
alarmInfo
lineAttenuation
noiseMargin
errSecRatioExceeded
bbErrRatioExceeded
>> router
alarmInfo
pingActive
qMonLoss
qMonDelay
qMonJitter
>>> bgp
>>>> ePeer
alarmInfo
sessionDown
>>>> iPeer
alarmInfo
sessionDown
>> bridge
>>> bridgeGroup
alarmInfo
linkDown
linkShutdown
>> vrfRouter[ ]
alarmInfo
pingActive
qMonLoss
qMonDelay
qMonJitter
14.2 Introducing the alarm attributes
Before discussing the alarm attributes of the 1424 SHDSL Router in detail, some general information on
the alarm attributes of the 1424 SHDSL Router is given.
• 14.2.1 - Configuration alarm attributes on page 1124
• 14.2.2 - General alarm attributes on page 1125
14.2.1 Configuration alarm attributes
This section describes the following alarm attributes:

• router1424/…/alarmMask
• router1424/…/alarmLevel
router1424/…/alarmMask
Use this attribute to mask or unmask the alarms of an object. This determines whether an active alarm
is forwarded to the central management system (e.g. HP OpenView) or not.
The alarms in the alarmMask attribute have the following values:
Value Is the active alarm being forwarded to the central management system?
enabled Yes. So the alarm is unmasked.
disabled No. So the alarm is masked.
Alarms are always seen in the alarmInfo alarm attribute of an object, regardless of the masking of the
alarm. I.e. even if an alarm is set to disabled in the alarmMask of an object, if the alarm condition is fulfilled
then the alarm will be set to on in the alarmInfo of that object. However, because this alarm is disabled it
will not be sent to the central management system (e.g. HP OpenView).
Only the most important alarms are unmasked (i.e. enabled) by default. All other alarms are masked (i.e.
disabled).
router1424/…/alarmLevel
Use this attribute to assign a priority level to each alarm of the corresponding object. The alarm level
range goes from 0 to 254, where 0 is the lowest and 254 is the highest priority level.
The alarmLevel of an unmasked, active alarm is sent to the totalAlarmLevel alarm attribute of the top object
router1424.
14.2.2 General alarm attributes
This section describes the following alarm attributes:

• router1424/totalAlarmLevel
• router1424/…/alarmInfo
router1424/totalAlarmLevel
This attribute is only present in the top object of the containment tree of the 1424 SHDSL Router, being
router1424.
It displays the priority level of an unmasked, active alarm. When several alarms are generated at the
same time, the highest priority level is shown. If the alarm levels are set in a structured manner, one look
at the totalAlarmLevel attribute enables the operator to make a quick estimation of the problem.
The value of the totalAlarmLevel attribute is also communicated to the central management system (e.g.
HP OpenView) where it determines the colour of the icon. This colour is an indication of the severity of
the alarm.
router1424/…/alarmInfo
This attribute contains the actual alarm information of the corresponding object.
The alarmInfo structure contains the following elements:
Element This element displays for the corresponding object …
discriminator the total alarm count since the last cold boot.
currentAlarms the current alarms.
previousAlarms the second most recent alarms.
alarmMask the alarmMask as you configured it.
alarmLevel the alarmLevel as you configured it.

14.3 General alarms
This section describes the alarms of the alarm attribute router1424/alarmInfo.
Refer to 14.2 - Introducing the alarm attributes on page 1123 for general information on the alarm
attributes.
router1424/alarmInfo
The different alarms related to the router1424 object together with their explanation and default alarmMask
and alarmLevel value are given in the following table:
The alarm … is generated … Default value
alarmMask alarmLevel
notResponding by the management concentrator when the 1424 enabled 4

SHDSL Router does not respond on its polling session.
alarmSyncLoss when the internal alarm buffer overflows. enabled 4
configChanged when the local configuration has been changed. disabled 1
access when a management session is started on the 1424 disabled 1

SHDSL Router itself. This alarm is not activated when
the management session is established through a man-
agement concentrator.
Example
The alarm is activated in case of …

• a TMA, TMA CLI, terminal (CLI or ATWIN) or Easy-
Connect session via the control connector of the
1424 SHDSL Router.
• a TMA, TMA CLI, TMA for HP OpenView, Telnet (CLI
or ATWIN), HTTP (Web Interface) or TFTP session
using the LAN / WAN IP address of the 1424 SHDSL
Router.
The alarm is not activated in case of …

• any management session (TMA, terminal, Telnet,
HTTP, etc.) established through a management con-
centrator on the 1424 SHDSL Router.
• SNMP management.
unknownState each time a new 1424 SHDSL Router is added to the disabled 0
network and before the management concentrator has
completed a first successful polling session.
coldBoot each time the 1424 SHDSL Router performs a cold boot. disabled 1
warmBoot each time the 1424 SHDSL Router performs a warm disabled 1
boot.
codeConsistency- when the software consistency imposed by the manage- disabled 1

Fail ment concentrator on the 1424 SHDSL Router fails. For
example, because of a loss of contact.
In the management concentrator that manages the 1424
SHDSL Router (e.g. the Orchid 1003 LAN, 1035 Orchid,
etc.), check the status attribute nmsgroup/softConsisten-
cyStatus to determine the problem.
configConsistency- when the configuration consistency imposed by the disabled 1

Fail management concentrator on the 1424 SHDSL Router
fails. For example, because of a loss of contact.
In the management concentrator that manages the 1424
SHDSL Router (e.g. the Orchid 1003 LAN, 1035 Orchid,
etc.), check the status attribute status attributes
nmsgroup/objectTable/configState and configDiag to determine
the problem.
14.4 LAN interface alarms
This section describes the alarms of the alarm attribute router1424/lanInterface/alarmInfo.
attributes.
router1424/lanInterface/alarmInfo
The alarm related to the lanInterface object together with its explanation and default alarmMask and
alarmLevel value is given in the following table:
linkDown when no valid LAN data is detected. I.e. when the con- enabled 3
nection between the interface and the LAN is down.
14.5 WAN interface alarms

• 1431 SHDSL CPE
• 1432 SHDSL CPE
This section describes the alarm attribute of the following objects:
router1424/dslInterface/
router1424/dslInterface/channel[ ]/
The alarm attribute is:

• alarmInfo on page 1130
alarmInfo
The alarm related to the wanInterface object together with its explanation and default alarmMask and
linkDown when an error situation is detected in the encapsulation enabled 3

protocol; for instance, no ATM synchronisation, a failed
PPP authentication, …
The linkDown alarm remains on as long as the encapsu-

lation is not up.
For the encapsulation to come up, one or more of the fol-
lowing conditions have to be met:
• the line object should be up (i.e. the linkDown alarm of
the line is off); refer to 14.7 - SHDSL line alarms on
• if running EFM or IMA, the requirement of the config-
ured minActiveLinks should be fulfilled; refer to minAc-
tiveLinks in 11.5.2 - ATM IMA configuration attributes
on page 551 or 11.5.5 - EFM configuration attributes
• if running ATM (native or over IMA), ATM synchroni-
sation should be achieved (i.e. alignment on the ATM
cells is found); refer to the status attribute atmSync in
12.5.1 - ATM status attributes on page 847 for more
information.
14.6 EFM alarms
This section describes the alarms of the alarm attribute:
router1424/wanEfm/efm/alarmInfo
The alarm related to the efm object together with its explanation and default alarmMask and alarmLevel value
is given in the following table:
linkDown when no valid EFM data is detected. I.e. when the EFM enabled 3
connection is down.
14.7 SHDSL line alarms
This section describes the alarms of the alarm attribute router1424/wanInterface/line/alarmInfo.
attributes.
router1424/wanInterface/line/alarmInfo
The alarms related to the line object together with their explanation and default alarmMask and alarmLevel
value are given in the following table:
linkDown when the line is down. I.e. no data can be transmitted enabled 3
over the line.
Pay attention to the following:

• when bonding is done on SHDSL level (in ATM
encapsulation), the linkDown alarm remains on as long
as not all configured line pairs are in dataState.
• when bonding is done on higher encapsulation level
(in EFM or IMA encapsulation), which means that the
different SHDSL line pairs run in independent sin-
glePair mode, the linkDown alarm switches off as soon
as one line pair is in dataState.
invalidNum- if the number of repeaters you entered in the numExpect- disabled 1

Repeaters edRepeaters attribute does not match the actual number
of repeaters discovered by the 1424 SHDSL Router.
The actual number of repeaters discovered by the 1424
SHDSL Router can be seen in the numDiscoveredRepeaters
attribute.
testActive when a line test is active. disabled 1

14.8 SHDSL line pair alarms
This section describes the alarms of the alarm attribute router1424/wanInterface/line/linePair[ ]/alarmInfo.
attributes.
router1424/wanInterface/line/linePair[ ]/alarmInfo
The alarms related to the linePair[ ] object together with their explanation and default alarmMask and
alarmLevel value are given in the following table:
linkDown when the line pair is down. I.e. no data can be transmit- disabled 3
ted over the line pair.
This alarms remains on as long as the line pair is not in

dataState; refer to the line pair status attribute status in
12.6 - SHDSL line status attributes on page 887 for
more information.
lineAttenuation when the line attenuation exceeds the value configured disabled 1
in the linkAlarmThresholds for at least 10 seconds. The
alarm is cleared when the line attenuation drops below
this value for at least 10 seconds.
Note that in case the eocHandling attribute is set to alarm-
Configuration, the central SHDSL device forces the remote
SHDSL device to use the linkAlarmThresholds/lineAttenuation
as configured on the central device.
• 5.5.3 - Controlling the standard EOC message
exchange on page 81
• 5.5.4 - Which standard EOC information is retrieved?
on page 83
noiseMargin when the signal noise exceeds the value configured in disabled 1
the linkAlarmThresholds for at least 10 seconds. The alarm
is cleared when the signal noise drops below this value
for at least 10 seconds.
Note that in case the eocHandling attribute is set to alarm-
Configuration, the central SHDSL device forces the remote
SHDSL device to use the linkAlarmThresholds/signalNoise as
configured on the central device.
exchange on page 81
on page 83
errSecRatioEx- when the amount of erroneous seconds exceeds the disabled 1

ceeded value configured in the linkAlarmThresholds within a 15 min-
utes period1. The alarm is cleared when the amount of
erroneous seconds drops below this value within a 15
minutes period.
sevErrSecRatioEx- when the amount of severely erroneous seconds disabled 2

ceeded exceeds the value configured in the linkAlarmThresholds
within a 15 minutes period1. The alarm is cleared when
the amount of severely erroneous seconds drops below
this value within a 15 minutes period.
bbErrRatioEx- when the background block error ratio exceeds the disabled 1
ceeded value configured in the linkAlarmThresholds configuration
attribute within a 15 minute period1. The alarm is cleared
when the background block error ratio drops below this
value within a 15 minute period.
is exceeded, then the errSecExceeded alarm is raised. The alarm stays on for the remainder of
the 15 minutes period. The alarm is only cleared if also in the next 15 minutes period the
14.9 End and repeater alarms
This section describes the alarms of the following object:
router1424/dslInterface/end/

This section also describes the alarms of the following object:
router1424/dslInterface/end/linePair[ ]

The repeater[ ] and end objects contain the same attributes, therefore only the alarms of the end object are
described.
alarmInfo
The alarm related to the end object together with its explanation and default alarmMask and alarmLevel value
is given in the following table:
linkDown when the end or repeater device is down. disabled 3
unknownState each time a new 1424 SHDSL Router is added to the disabled 4
network and before the management concentrator has
completed a first successful polling session.
alarmInfo
The alarm related to the end/linePair[ ] object together with its explanation and default alarmMask and
lineAttenuation when the lineAttenuation value configured in the linkAlarm- disabled 1

Thresholds of the local device is exceeded for at least 10
seconds. The alarm is cleared when the line attenuation
drops below this value for at least 10 seconds.
Note however that in case the eocHandling attribute is set
to alarmConfiguration, the central SHDSL device forces the
remote SHDSL device to use the linkAlarmThresholds/lineAt-
tenuation as configured on the central device.
exchange on page 81
on page 83
noiseMargin when the noiseMargin value configured in the linkAlarm- disabled 1

Thresholds of the local device is exceeded for at least 10
seconds. The alarm is cleared when the signal noise
drops below this value for at least 10 seconds.
Note however that in case the eocHandling attribute is set
to alarmConfiguration, the central SHDSL device forces the
remote SHDSL device to use the linkAlarmThresholds/signal-
Noise as configured on the central device.
exchange on page 81
on page 83
errSecRatioEx- when the errSecOn value configured in the linkAlarmThresh- disabled 1

ceeded olds of the local device is exceeded within a 15 minutes
period1. The alarm is cleared when the amount of erro-
neous seconds drops below this value within a 15 min-
utes period.
sevErrSecRatioEx- when the sevErrSecOn value configured in the linkAlarm- disabled 2

ceeded Thresholds of the local device is exceeded within a 15
minutes period1. The alarm is cleared when the amount
of severely erroneous seconds drops below this value
within a 15 minutes period.
bbErrRatioEx- when the background block error ratio exceeds the disabled 1
ceeded value configured in the linkAlarmThresholds configuration
attribute within a 15 minute period1. The alarm is cleared
when the background block error ratio drops below this
value within a 15 minute period.
is exceeded, then the errSecExceeded alarm is raised. The alarm stays on for the remainder of
the 15 minutes period. The alarm is only cleared if also in the next 15 minutes period the
14.10 Bundle alarms
This section describes the alarms of the alarm attribute router1424/bundle/pppBundle[ ]/alarmInfo.
router1424/bundle/pppBundle[ ]/alarmInfo
The alarm related to the xxxBundle[ ] object together with its explanation and default alarmMask and
linkDown when all the bundle links in the bundle are down. enabled 3
14.11 Router and vrfRouter[ ] alarms
This section describes the alarms of the following objects:
router1424/ip/router/
router1424/ip/router/vrfRouter[ ]
attributes.
These objects contain the following element:
router1424/ip/router/alarmInfo
The alarm related to the router object together with its explanation and default alarmMask and alarmLevel
value is given in the following table:
pingActive when a ping is pending (for example, an indefinite ping). enabled 3

This notification is necessary because you can only
transmit one ping at a time. Furthermore, there is no pro-
tection when a new ping is started before the previous is
stopped.
qMonLoss is generated when more packets have been lost than disabled 3
allowed in the configuration of the qualityMonitor.
Refer to the qualityMonitor attribute in 11.9.1 - General
router configuration attributes on page 617 for more
qMonDelay is generated when the delay is bigger than allowed in the disabled 3
configuration of the qualityMonitor.
qMonJitter is generated when the jitter is bigger than allowed in the disabled 3
configuration of the qualityMonitor.
14.12 Bridge group alarms
This section describes the alarms of the following object:
router1424/bridge/bridgeGroup
alarmInfo
The alarm related to the bridgeGroup object together with its explanation and default alarmMask and
linkDown when the bridge group is down. disabled 3
linkShutdown as long as a bridging interface is in shutDown state. disabled 3

14.13 BGP ePeer and iPeer alarms
This section describes the alarms of the alarm attribute router1424/ip/router/bgp/ePeer/alarmInfo.
attributes.
The attribute below refers to the ePeer object. The attribute of the iPeer object is identical.
router1424/ip/router/bgp/ePeer/alarmInfo
The alarm related to the ePeer object together with its explanation and default alarmMask and alarmLevel
value is given in the following table:
sessionDown when a BGP ePeer/iPeer connection is down. disabled 1

User manual TMA sub-system picture
15 TMA sub-system picture

The sub-system picture is a TMA tool that visualises the status information of the 1424 SHDSL Router.
This chapter explains how to display the sub-system picture, and how to interpret the visual indications.
How to display the sub-system picture?
To display the sub-system picture of the 1424 SHDSL Router, click on the sub-system picture button
located in the TMA toolbar: .
Structure of the sub-system picture
This paragraph displays and labels the different elements of the sub-system picture. It also explains how
the visual indications should be interpreted.
Below, the 1424 SHDSL Router sub-system picture is displayed:

The following table gives an overview of the sub-system picture elements and what they indicate:
Element Description
LEDs These reflect the actual status of the device.

The LED indication on the sub-system picture corresponds with the LED indication
on the 1424 SHDSL Router itself. Refer to 2.7 - The front panel LED indicators on
page 22 for more information on the interpretation of the LEDs.
LAN This reflects the status of the LAN interface. The possible indications are:
• green. There is no alarm active in the corresponding lanInterface object.
• red. An alarm is active in the corresponding lanInterface object.
The colour of the LAN interface only changes if the alarms related to the
lanInterface object are set to enabled in the alarmMask.
LINE This reflects the status of the WAN interface and of the line pair(s). The possible
indications are:
• green outside. There is no alarm active in the corresponding
wanInterface object.
• red outside. An alarm is active in the corresponding wanInterface
object.
• green inside, left. There is no alarm active in the corresponding linePair[1] object.
• red inside, left. An alarm is active in the corresponding linePair[1] object.
• green inside, right. There is no alarm active in the corresponding linePair[2]
object.
• red inside, right. An alarm is active in the corresponding linePair[2] object.
The colours of the WAN interface / line pair(s) only change if the alarms
related to the wanInterface / linePair[ ] objects are set to enabled in the alarm-
Mask.
User manual Auto installing the 1424 SHDSL Router
16 Auto installing the 1424 SHDSL Router

Auto-install includes a number of features that allow you to partially or completely configure the 1424
SHDSL Router without on-site intervention. This is shown in this chapter.
• 16.1 - Introducing the auto-install protocols on page 1148
• 16.2 - Auto-install on the LAN interface on page 1150
• 16.3 - Auto-install on the WAN interface on page 1155
• 16.4 - Creating a configuration file on page 1162
• 16.5 - Restoring a configuration file on page 1169
16.1 Introducing the auto-install protocols
The 1424 SHDSL Router uses several protocols during its auto-install sequence. These are introduced
below.
What is BootP?
BootP (RFC 951) is used by IP devices that have no IP address to obtain one.
The client IP device sends a limited broadcast request on its interfaces requesting an IP address. The
request contains the client its MAC address, which is a unique identifier (refer to What is the ARP cache?
on page 512 for more information).
A workstation with a BootP server interprets incoming BootP requests. You can configure a file on the
server with MAC address and IP address/subnet mask pairs for all devices in the network you want to
service. If the MAC address in the BootP request matches a MAC address in this file, the BootP server
replies with the corresponding IP address and subnet mask.
Assigning an IP address in this way is done through a simple request - response handshake.
The 1424 SHDSL Router, being a router, always requests a static IP address.
What is DHCP?
DHCP (RFC 2131 and RFC 2132) is used by IP devices that have no IP address to obtain one.
The client IP device sends a limited broadcast request on its interfaces requesting an IP address. The
request contains the client its MAC address, which is a unique identifier (refer to What is the ARP cache?
on page 512 for more information).
A workstation with a DHCP server works in a similar way as with a BootP server. The difference with
BootP is that you can additionally configure a list of IP addresses on the server. These IP addresses are
dynamically assigned to the IP devices requesting an IP address, independently of their MAC address.
Those address assignments are limited in time.
Assigning an IP address in this way is done through a 4-way handshake and with regular renewals.
The 1424 SHDSL Router, being a router, always requests a static IP address.
What is DNS?
The Domain Name Service (DNS) is an Internet service that translates domain names into IP addresses.
Because domain names are alphabetic, they are easier to remember. The Internet however, is really
based on IP addresses. Therefore, every time you use a domain name, a DNS service must translate
the name into the corresponding IP address. For example, the domain name www.mywebsite.com might
translate to 198.105.232.4.
The DNS system is, in fact, its own network. If one DNS server doesn't know how to translate a particular
domain name, it asks another one, and so on, until the correct IP address is returned.
What is TFTP?
Trivial File Transfer Protocol (TFTP) is an Internet software utility for transferring files that is simpler to
use than the File Transfer Protocol (FTP) but less capable. It is used where user authentication and
directory visibility are not required. TFTP uses the User Datagram Protocol (UDP) rather than the Trans-
mission Control Protocol (TCP). TFTP is described formally in Request for Comments (RFC) 1350.
TFTP is typically used in combination with BootP or DHCP to obtain the configuration of a device from
a TFTP server. The configuration file on this TFTP can be in a binary or an ASCII (CLI) format. How to
build such files is explained in 16.4 - Creating a configuration file on page 1162.
The 1424 SHDSL Router as relay agent
Being broadcast packets, BootP, DHCP, DNS and TFTP requests can cross a router using IP helper
addresses. The 1424 SHDSL Router is a relay agent for these protocols. This means it adds additional
information to the request packets allowing servers on distant networks to send back the answer.
16.2 Auto-install on the LAN interface
This section shows the auto-install sequence on the 1424 SHDSL Router its LAN interface.
• 16.2.1 - Set-up for auto-install on the LAN interface on page 1151
• 16.2.2 - Auto-install in case of Ethernet on page 1152
• 16.2.3 - Example of auto-install on the LAN interface on page 1153
16.2.1 Set-up for auto-install on the LAN interface
The following figure shows the set-up for auto-install on the LAN interface:
16.2.2 Auto-install in case of Ethernet

16.2.3 Example of auto-install on the LAN interface
Suppose you have the following situation:

• The 1424 SHDSL Router is still in its default configuration (absolutely nothing is configured). This
means that the LAN interface …
- is in bridging mode.
- no IP address is configured on the LAN interface.
- no IP address is configured on the bridge group.
⇒This means that if an IP address is obtained through BootP/DHCP, then it will be assigned to the
bridge group, not to the LAN interface itself (since it is in bridging mode)!
• A BootP server is present on the LAN, containing the 1424 SHDSL Router MAC address
(00:C0:89:00:94:6F) and a corresponding IP address (192.168.47.1).
• A DNS server is present on the LAN, containing the 1424 SHDSL Router its hostname “TlsRouter“.
• A TFTP server is present on the LAN, containing the 1424 SHDSL Router its binary configuration file
“TlsRouter.cms”.
• The 1424 SHDSL Router is plugged on to the LAN.
The following shows how the 1424 SHDSL Router obtains an IP address and its configuration file:
Note again that the obtained IP address is assigned to the bridge group, not to the LAN interface itself
(since it is in bridging mode)! So if you check the status of the bridge group, you will see the IP address
there:
16.3 Auto-install on the WAN interface
This section shows the auto-install sequence on the 1424 SHDSL Router its WAN interface.
• 16.3.1 - Set-up for auto-install on the WAN interface on page 1156
• 16.3.2 - Auto-install in case of ATM on page 1157
• 16.3.3 - Auto-install in case of Frame-Relay on page 1158
• 16.3.4 - Example of auto-install on the WAN interface running ATM on page 1159
16.3.1 Set-up for auto-install on the WAN interface
The following figure shows the set-up for auto-install on the WAN interface:
16.3.2 Auto-install in case of ATM

16.3.3 Auto-install in case of Frame-Relay

16.3.4 Example of auto-install on the WAN interface running ATM
Suppose you have the following situation:

• On the local OneAccess Router you add an ATM PVC to the atm/pvcTable. For this ATM PVC you spec-
ify the VPI/VCI values 1/100. All other elements of the ATM PVC remain at their default value.
• On the central OneAccess Router you also add an ATM PVC to the atm/pvcTable. For this ATM PVC
you specify …
- the VPI/VCI values 1/100.
- the helper IP addresses 192.168.47.251 (DHCP server) and 192.168.47.252 (TFTP server).
- the helper protocols DHCP (68) and TFTP (69).
• A DHCP server is present on the remote network, containing the 1424 SHDSL Router MAC address
(00:C0:89:00:94:6F), a corresponding IP address (192.168.100.1) and a corresponding configuration
filename “TlsRouterConfig.cms”.
• A TFTP server is present on the remote network, containing the 1424 SHDSL Router its binary con-
figuration file “TlsRouterConfig.cms”.
• The OneAccess Router is plugged on to the WAN.
So the initial configuration on the local OneAccess Router is as shown below:

In order for the auto-install of the local OneAccess Router to be successful, the following must be con-
figured on the central OneAccess Router:
The following shows how the local OneAccess Router obtains an IP address and its configuration file:
16.4 Creating a configuration file

• 16.4.1 - The different configuration file formats on page 1163
• 16.4.2 - Creating a binary file using TMA on page 1164
• 16.4.3 - Creating an ASCII CLI file using TMA on page 1165
• 16.4.4 - Creating an ASCII CLI file using TFTP on page 1167
• 16.4.5 - Creating an ASCII CLI file using Telnet on page 1168
16.4.1 The different configuration file formats
In 16.2 - Auto-install on the LAN interface on page 1150 , you can see how the configuration file is
retrieved using TFTP during the auto-install sequence. The two possible configuration file formats used
for this purpose are:
File type Extension How to create the configuration file
binary .cms Use the TMA export utility and choose the CMS file type. This
is the most compact format.
Refer to 16.4.2 - Creating a binary file using TMA on
page 1164.
ASCII CLI .cli • Use the TMA export utility and choose the CLI file type.
• Use the TFTP get command.
• Use the CLI get command.
Refer to …
• 16.4.3 - Creating an ASCII CLI file using TMA on page 1165
• 16.4.4 - Creating an ASCII CLI file using TFTP on
page 1167
• 16.4.5 - Creating an ASCII CLI file using Telnet on
page 1168
When you download an ASCII CLI (*.cli) configuration

file to the 1424 SHDSL Router, make sure that each line
in this file contains no more than 500 characters.
16.4.2 Creating a binary file using TMA
To create a configuration file in binary (*.cms) format using TMA, proceed as follows:
Step Action
1 Start a TMA session on the 1424 SHDSL Router.
2 Make changes to its configuration (if necessary) in order to obtain the desired configura-
tion.
3 Click on the Export data to file button: .
4 In the Export configuration parameters window, select the following:

• Choose a directory where to save the file.
• Enter a name for the file.
• Make sure the file type is CMS.
• Make sure the Full configuration option is selected.
5 Click on the Save button.

The edited configuration of the 1424 SHDSL Router is stored on the PC in binary format.
The file contains the complete configuration including the Activate Configuration com-
mand. As a result, the configuration is immediately activated if you download it to the
device again.
16.4.3 Creating an ASCII CLI file using TMA
To create a configuration file in ASCII CLI (*.cli) format using TMA, proceed as follows:
Step Action
2 Make changes to its configuration (if necessary) in order to obtain the desired configura-
tion.
3 Click on the Export data to file button: .
4 In the Export configuration parameters window, select the following:

• Choose a directory where to save the file.
• Enter a name for the file.
• Make sure the file type is CLI.
• Make sure the Full configuration option is selected.
Do not select the file extension for ASCII text (*.txt)! This is for documentation pur-
poses only, not for configuration purposes.
Step Action
5 Click on the Save button.

⇒The edited configuration of the 1424 SHDSL Router is stored on the PC in ASCII
CLI format. The file contains the configuration attributes that differ from their
default value including the Load Default Configuration command at the beginning
of the file and the Activate Configuration command at the end of the file. As a
result, the configuration is immediately activated if you download it to the device
again.
16.4.4 Creating an ASCII CLI file using TFTP
To create a configuration file in ASCII CLI (*.cli) format using TFTP, proceed as follows:
Step Action
1 Start a TFTP session on the 1424 SHDSL Router.

For example by typing tftp 10.0.11.1 at the command prompt of your workstation,
where 10.0.11.1 is the IP address of the 1424 SHDSL Router.
2 Get the configuration file of the 1424 SHDSL Router.
Example
tftp> get CONFIG.CLI dest_file.cli

Where …
• get is the TFTP command to retrieve a file.
• CONFIG.CLI (in capitals!) is the source file (i.e. the 1424 SHDSL Router configuration
file).
• dest_file.cli is the destination file.
3 When the file transfer is finished, close the TFTP session.
Note that the procedure described above does not work with FTP.
16.4.5 Creating an ASCII CLI file using Telnet
To create a configuration file in ASCII CLI (*.cli) format using Telnet logging and the CLI get command,
proceed as follows:
Step Action
1 Start a Telnet session on the 1424 SHDSL Router. You are automatically in CLI mode.
2 You are automatically located in the top object (router1424) and in the "Edit Configuration"
group. Check to make sure (just press the Enter key).
3 Log the CLI output to a file. Refer to the documentation of your Telnet software how to
do so.
4 Execute the get -r -d command.

>get -r -d
5 Stop the logging.
6 The log file you now obtained, modify it as follows:

• At the beginning of the log file …
- remove all logging before the get -r -d command.
- remove the get -r -d command itself.
- change the string GET into SET.
- type the string action “Load Default Configuration” (case sensitive!) on the line
above the SET command.
• At the end of the log file…
- remove all logging until the last character is a closing curled bracket “}”.
- type the string action “Activate Configuration” (case sensitive!) on the line below
the closing curled bracket “}”.
7 Save this file to a file with an extension *.cli.

16.5 Restoring a configuration file
In 16.2 - Auto-install on the LAN interface on page 1150 , you can see how the configuration file is
retrieved using TFTP during the auto-install sequence. It is, however, also possible to restore previously
saved configuration files by downloading them yourself to the 1424 SHDSL Router. You can do this by
using various applications. This is explained in this section.
• 16.5.1 - Downloading a configuration file using TMA on page 1170
• 16.5.2 - Downloading a configuration file using (T)FTP on page 1171
• 16.5.3 - Downloading a configuration file using Telnet on page 1172
16.5.1 Downloading a configuration file using TMA
To download a configuration file using TMA, proceed as follows:
Step Action
2 Click on the Import data from file button: .
3 In the Import configuration window, select the following:

• Select the directory where the configuration file is located.
• Select which type of configuration file you want to import: CMS or CLI.
• Select the configuration file you want to import.
4 Click on the Open button.

⇒The configuration is downloaded to the 1424 SHDSL Router.
16.5.2 Downloading a configuration file using (T)FTP
To download a configuration file using (T)FTP, proceed as follows:
Step Action
1 Start a (T)FTP session on the 1424 SHDSL Router.

For example by typing (t)ftp 10.0.11.1 at the command prompt of your computer,
where 10.0.11.1 is the IP address of the 1424 SHDSL Router. If a write access password
is configured on the 1424 SHDSL Router, then enter it as well.
2 Set the transfer mode to binary (octet) format. The syntax to do this is typically binary or
octet.
3 Type the following command:

(t)ftp> put source_file.cli CONFIG.CLI
or
(t)ftp> put source_file.cms CONFIG.CMS
Where …
• put is the (T)FTP command to send a file.
• source_file.* is the source file. This may either be a CLI or CMS file1.
• CONFIG.* (in capitals!) is the destination file (i.e. the 1424 SHDSL Router configura-
tion file). This may either be a CLI or CMS file1.
4 When the file transfer is finished, close the (T)FTP session.
1. However, make sure that source and destination file format are both the same!
16.5.3 Downloading a configuration file using Telnet
To download a configuration file using Telnet, proceed as follows:
Step Action
1 Start a Telnet session on the 1424 SHDSL Router. You are automatically in CLI mode.
2 You are automatically located in the top object (router1424) and in the "Edit Configuration"
group. Check to make sure (just press the Enter key).
3 Use the “send” feature of your Telnet software to send the ASCII CLI configuration file to
the 1424 SHDSL Router. Refer to the documentation of your Telnet software how to do
so.
User manual Downloading software
17 Downloading software
This chapter explains how to download application software to the 1424 SHDSL Router. It also shows
how to download any other file to the file system of the 1424 SHDSL Router. But first it explains the dif-
ference between boot and application software.
• 17.1 - What is boot and application software? on page 1174
• 17.2 - Downloading application software using TMA on page 1175
• 17.3 - Downloading application software using TFTP on page 1176
• 17.4 - Downloading application software using TML on page 1177
• 17.5 - Downloading application software using FTP on page 1178
• 17.6 - Downloading files to the file system on page 1179
17.1 What is boot and application software?
What is boot software?
The boot software takes care of the initial phase in the start-up sequence of the 1424 SHDSL Router. It
is located on the lowest software level. If the 1424 SHDSL Router only loads its boot software, then we
say that the 1424 SHDSL Router runs in boot mode.
The 1424 SHDSL Router …
• runs in boot mode if no application software is present.
• can temporarily be forced to run in boot mode by using the -b option of the TML command. Refer to
17.4 - Downloading application software using TML on page 1177.
In boot mode …
• you can download application software (using TML).
• you cannot establish a TMA session. You can only use TML to download application software.
What is application software
The application software, also called control software or firmware, completely controls the 1424 SHDSL
Router. It is located on the highest software level. If the 1424 SHDSL Router loads its boot, loader and
application software, then we say that the 1424 SHDSL Router runs in application mode.
In application mode …
• you can download application software (using TMA, TFTP or TML).
• you can establish a TMA session.
17.2 Downloading application software using TMA
To download application software to the 1424 SHDSL Router using TMA, proceed as follows:
Step Action
1 Establish a link between TMA and the 1424 SHDSL Router either over a serial or an IP
connection. Refer to 4 - Maintaining the 1424 SHDSL Router on page 31.
2 In the TMA window select Tools → Download…
3 In case you made …

• an IP connection, skip this step.
• a serial connection, select the Options tab in
the TMA - Download window. Then set the
following:
- Set the initial transfer speed to 9600 bps.
- Select a maximum transfer speed. If you
select e.g. 57600 bps, then the actual
transfer speed will be negotiated between
9600 bps and 57600 bps.
4 In the TMA - Download window, select the Configuration tab and click on Add…
5 In the Remote filename window, do the

following:
1. Select the file you want to download
(e.g. T1234001.00).
2. Type CONTROL in the Remote file
field.
3. Click on Open.
6 If you are currently connected to the 1424 SHDSL Router without write access, then you
can enter a password in the Password tab which gives you write access. Else leave the
Password tab blank.
7 When the TMA - Download window reappears,

click on OK.
⇒A window opens and shows the download
progress.
17.3 Downloading application software using TFTP
When downloading with TMA over an IP connection, you actually evoke TFTP (Trivial File Transfer Pro-
tocol) through TMA. You can also use TFTP without opening TMA.
To download application software to the 1424 SHDSL Router using TFTP, proceed as follows:
Step Action
1 Start a TFTP session on the 1424 SHDSL Router.

For example by typing tftp 10.0.11.1 at the command prompt of your computer, where
10.0.11.1 is the LAN IP address of the 1424 SHDSL Router. If a write access password
is configured on the 1424 SHDSL Router, you can either enter it now or when you actually
download the application software (see step 3).
2 Set the following TFTP parameters:

• Set the retransmission time-out to at least 20 seconds. The syntax to do this is typi-
cally rexmt 20.
• Set the total TFTP time-out sufficiently large (e.g. 40 seconds). The syntax to do this
is typically timeout 40.
• Set the transfer mode to binary (octet) format. The syntax to do this is typically binary
or octet.

tftp> put Txxxxxxx.00 CONTROL?my_pwd
Where …
• put is the TFTP command to send a file.
• Txxxxxxx.00 is the application software file (e.g. T1234001.00).
• CONTROL (in capitals!) specifies that the file being downloaded is an application soft-
ware file.
• ?my_pwd is the write access password as configured in the 1424 SHDSL Router. If no
password has been configured or if you already entered one when starting the TFTP
session (see step 1), you may omit the ? and the password.
4 When the file transfer is finished, close the TFTP session.

17.4 Downloading application software using TML
When downloading with TMA over a serial connection, you actually evoke TML (Total Memory Loader)
through TMA. You can also use TML without opening TMA.
To download application software to the 1424 SHDSL Router using TML, proceed as follows:
Step Action
1 Connect a serial port of your computer

(e.g. COM1) through a straight DB9-
RJ45 cable with the control connector
of the 1424 SHDSL Router.
2 Open a DOS window on your computer.
3 Go to the directory where the TML executable is located. Typically this is

C:\Program Files\TMA\bin.
4 Place the software file you want to download in this directory.
5 Type the following command to download application software:

tml -c1 -v -fTxxxxxxx.00@CONTROL?my_pwd
where …
• tml is the executable (Total Memory Loader) to download files to the OneAccess
devices through their control port.
• -c1 specifies the COM port of the computer connected to the 1424 SHDSL Router (in
this example COM1).
• -v returns graphical information on the download status.
• -fTxxxxxxx.00 is the software file you want to download (e.g. T1234001.00).
• CONTROL (in capitals!) specifies that the file being downloaded is an application or
loader software file.
password has been configured, you may omit the ? and the password.
To see a list of all the possible TML options: type TML in your DOS windows and press
the ENTER key.
6 If you press the ENTER key, the software download begins.

If you used the -v option together with the TML command, a graphical bar shows the
download progress.
17.5 Downloading application software using FTP
To download application software to the 1424 SHDSL Router using FTP, proceed as follows:
Step Action
1 Start an FTP session on the 1424 SHDSL Router.

For example by typing ftp 10.0.11.1 at the command prompt of your computer, where
10.0.11.1 is the LAN IP address of the 1424 SHDSL Router. If a write access password
is configured on the 1424 SHDSL Router, you can either enter it now or when you actually
download the application software (see step 3).
2 Make sure the transfer mode is set to binary (octet) format. The syntax to do this is typi-
cally binary.

ftp> put Txxxxxxx.00 CONTROL?my_pwd
Where …
• put is the FTP command to send a file.
• Txxxxxxx.00 is the application software file (e.g. T1234001.00).
• CONTROL (in capitals!) specifies that the file being downloaded is an application soft-
ware file.
password has been configured or if you already entered one when starting the FTP
session (see step 1), you may omit the ? and the password.
4 When the file transfer is finished, close the FTP session.

17.6 Downloading files to the file system
You might want to download other files than the firmware files only. In fact, any file can be downloaded
to the file system of the 1424 SHDSL Router. You can do this using the same tools you use to download
application software. These tools are:
• TMA (refer to 17.2 - Downloading application software using TMA on page 1175).
• TFTP (refer to 17.3 - Downloading application software using TFTP on page 1176).
• TML (refer to 17.4 - Downloading application software using TML on page 1177).
• FTP (refer to 17.5 - Downloading application software using FTP on page 1178).
The major difference is that instead of specifying CONTROL as target filename for the application software,
you now can specify any filename as target filename.
Tool Example
TMA In the Remote filename window,

do the following:
1. Select the file you want to
download (e.g. sdsltt.mod).
2. Type the target filename in the
Remote file field (e.g.
sdsltt.mod).
3. Click on Open.
(T)FTP and TML • tftp> put filename1.ext filename2.ext?my_pwd

• ftp> put filename1.ext filename2.ext?my_pwd
• tml -c1 -v -ffilename1.ext@filename2.ext?my_pwd
Where …
• filename1.ext is the source filename. This is a file on your computer.
• filename2.ext is the target filename. This is the filename the source file will
get when it is placed on the file system. Source and target filename may be the
same, but if wanted, you may specify a different target filename.
Example:
• tftp> put models.nms models.nms?pwd123
• tml -c1 -v -fmodels.nms@models.nms?pwd123
User manual Technical specifications
18 Technical specifications
This chapter gives the technical specifications of the 1424 SHDSL Router. The following gives an over-
view of this chapter:
• 18.1 - SHDSL line specifications on page 1182
• 18.2 - LAN interface specifications on page 1183
• 18.3 - 4 port Ethernet switch specifications on page 1184
• 18.4 - Console port specifications on page 1185
• 18.5 - IP address assignment and auto-provisioning on page 1186
• 18.6 - ATM encapsulation specifications on page 1187
• 18.7 - Frame Relay encapsulation specifications on page 1188
• 18.8 - PPP encapsulation specifications on page 1189
• 18.9 - EFM encapsulation specifications on page 1190
• 18.10 - IP routing specifications on page 1191
• 18.11 - Bridging specifications on page 1193
• 18.12 - Network address translation specifications on page 1194
• 18.13 - Tunnelling and VPN specifications on page 1195
• 18.14 - Priority and traffic policy specifications on page 1196
• 18.15 - Firewall specifications on page 1199
• 18.16 - Access security specifications on page 1200
• 18.17 - Maintenance and management specifications on page 1200
• 18.18 - Memory specifications on page 1201
• 18.19 - Power requirements on page 1202
• 18.20 - Dimensions on page 1203
• 18.21 - Safety compliance on page 1204
• 18.22 - Over-voltage and over-current protection compliance on page 1204
• 18.23 - EMC compliance on page 1204
• 18.24 - Environmental compliance on page 1204
18.1 SHDSL line specifications
• Single pair, dual pair, 4 pair line access

• Connector: RJ45
• Impedance: 135 Ω
• Cable to be used: 2*2*CAT5E twisted pair
• Coding: TCPAM, compliant to ITU-T G.991.2; G.SHDSL, and G.SHDSL.bis via TCPAM-16 and
TCPAM-32
• Line speeds:
- Single pair: 192 … 5696 in steps of 64kbps
- Two pair: 384 … 11392 in steps of 128kbps
- Four pair: 768 … 22784 in steps of 256kbps
• Handshaking: compliant G.994.1 (automatic speed negotiation) or fixed speed
• Performance monitoring: compliant G.826 (errored seconds, severely errored seconds, unavailability
seconds)
The line connector lay-out
The following table shows the connector layout of the RJ45 line connector:
Pin Signal Figure
1 line 2 (only on the 2P and 4P versions)
2 line 2 (only on the 2P and 4P versions)
3 line 3 (only on the 4P versions)
4 line 1
5 line 1

18.2 LAN interface specifications
• Connector: RJ45 (EIA/TIA 568B)

• Cable to be used: standard Ethernet cable (shielded UTP Cat. 5)
• Applicable standards: IEEE 802.3 (10Mbps Ethernet), IEEE 802.3u (100Mbps Ethernet),
IEEE 802.1ag (OAM on Ethernet interface), ITU-T Y.1731 (OAM on Ethernet interface)
• Speed: 10/100 Mbps auto-sense
• Auto cross-over MDI/MDI-X for automatic connection to a terminal or switch
• VLAN support (up to 12 VLANs)
• The following LEDs are available built-in on each Ethernet interface connector:
Colour Description
Green • OFF: link inactive.

• ON: link active.
Yellow • OFF: no traffic in progress.

• ON: traffic in progress.
The following table shows the connector layout of the RJ45 Ethernet LAN interface connector:
Pin Signal DTE DCE Figure
1 transmit (+) Out In
2 transmit (-) Out In
3 receive (+) In
4 not used -
5 not used -
6 receive (-) In Out
7 not used -
8 not used -
18.3 4 port Ethernet switch specifications
• Number of ports: 4
• Connectors: RJ45 (EIA/TIA 568B)
• Applicable standards: IEEE 802.3 (10Mbps Ethernet), IEEE 802.3u (100Mbps Ethernet)
• Characteristics:
- 10 / 100 Mbps auto-sense
- Half or full duplex
- Auto-negotiation
- Auto cross-over MDI/MDI-X for automatic connection to a terminal or switch
• Meaning of LED colours:
- Lit green LED: link active
- Blinking yellow LED: traffic in progress
• The layout of the connectors is identical to the LAN interface: transmission pairs 1-2, receive pairs 3-6
• Cable to be used: shielded crossover/straight cables with 4 twisted pairs
18.4 Console port specifications
• Connector: RJ45 (EIA/TIA 568B)

• Data:
- RS232
- 9600 bps
- 8 data bits
- no parity
- 1 stop bit
The following table shows the connector layout of the RJ45 Console connector:
Pin Abbreviation Signal DCE Figure
1 RD Received data Out
2 TD Transmitted data In
3 GND Ground -
4 NC Not connected -
5 NC Not connected -
6 Cable type -
7 - - -
8 - - -
• A console cable for router configuration and maintenance only requires TX, RX and GND to be con-
nected; refer to Annex C: - Console cable on page 1211 for more information about the cable.
18.5 IP address assignment and auto-provisioning
• BOOTP/DHCP server (RFC 2131, RFC 2132) with static or dynamic address assignment
• DHCP server major features:
- IP address ranges are configurable per interface
- If no gateway is configured in the DHCP server, the router gives its own address
- The DHCP server collects the DNS names of all DHCP clients and acts as a local DNS server for
these names
• DHCP relay agent (RFC 2131, RFC 2132)
• DNS proxy
• Static IP address assignment
• Possible assignment of secondary IP address on the LAN interface
• Numbered or unnumbered mode on WAN interfaces
• Automatic IP address assignment through:
- BootP client (RFC 951)
- DHCP client (RFC 2131, RFC 2132)
- IPCP
• Automatic IP gateway assignment through Inverse ARP (RFC 2390, in Frame-Relay and ATM)
• Automatic default route assignment on remotely learned IP address in PPP
• Automatic configuration file upload through DHCP client
• DHCP client requests are transmitted if an interface is in routing mode and has no IP address yet
• DHCP client requests can be blocked from being transmitted on the LAN interface and bridge groups
18.6 ATM encapsulation specifications
• ATM cell format ITU-T I.311, I.321, I.361, I.432

• ATM forum UNI 3.1/4.0 PVCs
• ATM forum ILMI 3.1/4.0
• OAM F4/F5 LB and CC support (ITU-T I.610)
• Inverse ARP for automatic gateway configuration
• ATM Forum Traffic Management 4.0 service type UBR, VBR and CBR
• PCR, SCR and MBS configurable per ATM PVC
• Support of up to 31 ATM PVCs
• ATM VPI range 0 - 255
• ATM VCI range 32 - 10000
• Supported higher layer protocols:
- Classical IP (RFC 1577)
- Ethernet (RFC 2684)
- PPPoA (RFC 2364)
- PPPoE (RFC 2516)
• Multi-protocol encapsulation:
- LLC
- VC
18.7 Frame Relay encapsulation specifications
• Encapsulation compliant with RFC 1490, RFC 2427

• LMI (revision 1 LMI, ANSI T1.617 D, ITU-T Q.933 Annex A and FRF 1&2)
• CIR configurable per DLCI
• EIR configurable per DLCI
• Inverse ARP for automatic gateway configuration
• Support of up to 40 Frame Relay PVCs (DLCIs)
• Frame Relay DLCI range 16 - 1022
• Multi-link Frame Relay (FRF.16)
• Frame Relay fragmentation (FRF.12)
18.8 PPP encapsulation specifications
• Encapsulation compliant with RFC 1661, RFC 1662

• LCP
• IPCP (RFC 1332)
• BCP (RFC 2878)
• CCP (RFC 1962) with Predictor compression algorithm (RFC 1978)
• PAP authentication (RFC 1334), unidirectional or bi-directional authentication
• CHAP authentication with MD5 hashing (RFC 1994), unidirectional or bi-directional authentication
• MS-CHAP1 (RFC 2433) and MS-CHAP2 (RFC 2759) CHAP authentication protocol extension
• MLPPP (RFC 1990)
• MLPPP bundle name exchange
• PPP fragmentation (RFC 1990), enabled to fixed size of 200 bytes or disabled
• MCPPP (RFC 2686)
18.9 EFM encapsulation specifications
• Applicable standard: IEEE 802.3ah

• Ethernet solution for local loop lengths of up to 2700 meters.
• OAM (Operation, Administration, and Maintenance):
- Section5: IEEE Std. 802.3-2005
• 2BASE-TL -- Full-duplex long reach Point-to-Point link over voice-grade copper wiring. Can deliver a
minimum of 2 Mbit/s and a maximum of 5.69 Mbit/s over distances of up to 2700 m, using ITU-T
G.991.2 (G.SHDSL.bis) technology over a single copper pair.
• VLAN support (up to 12 VLANs)
18.10 IP routing specifications
The 1424 SHDSL Router complies to the router requirements as stated in RFC 1812 and supports the
routing of standard IP packets (RFC 791) between the different interfaces of the 1424 SHDSL Router
according to the routing protocols listed below.
Static routing
• Routing is based on destination IP address

• Routing is based on static routing entries in the routing table
• Alternate routing is possible through the use of different preferences for different routes to the same
destination
Policy based routing
• Routing is based on additional higher layer information

• Traffic is routed to a certain interface or gateway based on one or more of the following parameters:
- Source IP address range
- Destination IP address range
- Source port range for UDP / TCP packets
- Destination port range for UDP / TCP packets
RIP
• RIP1 compliant with RFC 1058

• RIP2 compliant with RFC 2453
• Split horizon and selective router updates per interface
• Broadcasting of selective RIP updates limited to information on specific network subnets
• RIP2 authentication with MD5 hashing or clear text
OSPF
• Compliant with RFC 2328 (OSPF version 2)

• Import of statically configured routes
• Route summarisation and route suppression through range definitions on areas
• Encryption through simple password or MD5 encryption chains
ICMP
Support of ICMP messages (RFC 792):

• TTL exceeded
• Destination unreachable
Multicasting and broadcasting
The 1424 SHDSL Router supports the handling of broadcasts and multicasts and includes the following
related functionalities:
• IGMPv2 (Internet Group Management protocol, RFC 2236), as the standard for IP multicasting
• IGMP proxy function
• Forwarding of directed broadcasts can be enabled or disabled per interface
• Helper address can be configured for broadcasts
Filtering
• Filtering of outgoing traffic on all interfaces based on extended access lists

• Filtering of incoming traffic on all interfaces based on extended access lists
• Filtering of incoming traffic on the IP protocol stack based on an extended access list
• IP extended access lists filter on the following parameters:
IP MTU
• The IP MTU can be configured on the WAN and LAN interfaces (between 500 and 1650 bytes)
VRRP
• Support of VRRP (RFC 2338)

18.11 Bridging specifications
• Bridging can be enabled or disabled per interface

• Bridging can be combined with routing on the same interface
Bridging protocols
• Self-learning bridging can be enabled or disabled

• Cache of at least 10,000 MAC addresses
• Support of Spanning Tree protocol (IEEE 802.1D)
Bridge groups
• Multiple bridge groups possible

• IP address assignment per bridge group (for management purposes)
• Secondary IP addresses can be configured per bridge group
• MAC address configurable per bridge group
• Routing between different bridge groups possible
VLANs
• Support of VLANs (IEEE 802.1Q and IEEE 802.1ad)

• Up to 255 VLANs per LAN interface
• Support of VLAN priority tagging (IEEE 802.1P)
• Multiple VLANs within a bridge group towards the IP router possible
• IP TOS to 802.1P COS mapping and COS to TOS mapping are available on the LAN interface to
maintain priority information when changing from IP to VLAN or vice versa
• IP TOS to 802.1P COS mapping and COS to TOS mapping are available on the data sent between
a bridge group and the IP router to maintain priority information when changing from IP to VLAN or
vice versa
• MIB2 performance counters are available per VLAN
VLAN switching
• Bridge group can be configured as VLAN switch

• Q in Q as defined in IEEE 802.1ad possible
• No practical limit on the number of VLANs in VLAN switching mode
• VLAN switching mode can be combined with bridging mode for packets on the same interface
Filtering
• Filtering of outgoing bridged traffic on all interfaces based on access lists

• Bridge access lists filter on source MAC address
• Limit broadcasts in a bridge group per interface
• Proxy ARP cache
18.12 Network address translation specifications
• Compliant with RFC 3022

• NAT mode for one-to-one private to public IP address translation
• PAT mode for many-to-one private to public IP address translation
• NAT/PAT configurable on any interface (the interface with the public address(es))
• Up to 5 NAT/PAT interfaces
• Static and dynamic assignment of NAT official addresses
• List of UDP/TCP port numbers that should not be translated
• List of incoming UDP/TCP port numbers destined for a server
• Easy NAT: CPE learns official IP address via PPP
• Application Layer Gateway (ALG) support including:
- General: FTP, ICMP (Echo, Echo Response, Destination Unreachable, Time Exceed & Source
Quench), SQLNet
- Microsoft Games
- Video / Streaming applications: RTSP, QuickTime, Real Player (Real Audio / Real Video), H.323
(ASN1 PER encoding and decoding included), NetMeeting, Intel Video Phone, CuseeMe 5.0, SIP
Audio
- Communication: Internet Chat, IRC, MIRC, AOL Instant Messenger, AOL enhanced chat,
ICQ2000b, Net2Phone, Microsoft Messenger
- Security Related: PPTP, IPSec ESP (IPSec client from internal network), IKE, L2TP
18.13 Tunnelling and VPN specifications
L2TP tunnelling
• Compliant with RFC 2661

• Up to 10 L2TP tunnels
• Available on LAN and WAN interfaces
• Static and dynamic tunnels
• Tunnel authentication
• Available for IP and bridged PDUs
• One L2TP tunnel between each pair of IP addresses
• One PPP session per L2TP tunnel
• L2TP tunnels can be set up from an interface running NAT/PAT
• L2TP backup tunnels
• RIP snapshot routing on L2TP tunnels
IPSEC security
• Compliant with RFC 2401 up to RFC 2406

• L2TP transport mode (RFC 3193)
• Up to 10 IPSEC tunnels (independently of the number of L2TP tunnels)
• ESP (RFC 2406)
• DES (56 bits; RFC 2405), 3DES (3 * 56 bits; RFC 2451) and NULL (RFC 2410) encryption
• HMAC based on MD5 (RFC 2403) and SHA-1 (RFC 2404) for integrity and authentication
• Manual SAs
• IPSec Key management protocol framework compliant with:
- RFC 2408: Internet Security Association and Key Management Protocol
- RFC 2407: IP Security Domain of Interpretation for ISAKMP
- RFC 2409: Internet Key Exchange (IKE)
18.14 Priority and traffic policy specifications
This section gives the specifications of the priority and traffic policies that are available on the 1424
• 18.14.1 - Priority policy on page 1197
• 18.14.2 - IP traffic policy on page 1197
• 18.14.3 - Bridge traffic policy on page 1198
18.14.1 Priority policy
• 7 forwarding queues per interface:

- 5 standard, configurable queues
- 1 low delay queue
- 1 system queue
• Quotum and weight configurable per standard queue
• Supported algorithms to empty the standard queues:
- FIFO
- Round robin
- Absolute priority
- Weighted fair queueing
- Low delay weighted fair queueing
• CIR configurable per standard queue
18.14.2 IP traffic policy
Supported IP traffic policies:
Traffic shaping
• Traffic is forwarded to a certain priority queue based on the following parameters:

• TOS value can be changed during traffic shaping
• Configurable maximum queue length
• Performance information on classified traffic
TosDiffServ
• Traffic is forwarded to a certain priority queue based on DiffServ (RFCs 2474, 2475) regarding class
and drop precedence
TosMapped
• Traffic is forwarded to a certain priority queue based on a user-defined range of the TOS field
QueueMapped
• Traffic is forwarded to a certain priority queue based on previous colouring.

18.14.3 Bridge traffic policy
• Traffic is forwarded to a certain priority queue based on the 802.1P tag of VLAN tagged Ethernet traf-
fic
18.15 Firewall specifications
• Firewall with 3 zones (Internet, Corporate, DMZ) and IP protocol stack (Self)
• Outbound and inbound policies based on …
- Source and destination IP address range
- Application (IP protocol and port range)
• PAT can be applied per outbound / inbound policy
• Outbound and inbound policies for the IP protocol stack (Self)
• Protection again attacks: SYN flooding, Source Routing, WinNuke, FTP Bounce, IP Unaligned
Timestamp, MIME Flood, Sequence Number Prediction, Sequence Number Out Of Range, ICMP
Error Messages
• Firewall logging with different priorities
18.16 Access security specifications
• Password protected
• Several access levels possible:
- Read access
- Write access
- Security access
- File system access
• Radius client (RFC 2865)
• Management access can be enabled or disabled per interface
• Overall management access can be prohibited (Telnet, HTTP, SNMP, FTP, TFP)
18.17 Maintenance and management specifications
• Local console (Command Line Interface or ATWIN) via serial control port
• TELNET (Command Line Interface or ATWIN) (RFC 854)
• HTTP web interface1 (RFC 2616)
• Easy Configurator (customisable JAVA based web interface)
• TMA (Total Maintenance Application) via serial control port or IP connection (UDP port 1728)
• TMA CLI2
• TMA Element Management2
• TMA for HP OpenView2
• TML (Total Memory Loader) for configuration and software download via serial control port
• FTP configuration and software download (RFC 414)
• TFTP configuration and software download (RFC 1350)
• PING (RFC 792)
• SNMP (RFC 1157)
• SNMP MIB2 (RFC 1213), private MIB
• SNMP traps (RFC 1215)
• SYSLOG event logging (RFC 3164)
• SNTP (RFC 2030)
• IP loopback address
1. HTTP interfaces are available on both port 80 and port 8080. This allows connecting to the
HTTP interfaces in case a NAT service is defined on port 80.
2. Not included.
18.18 Memory specifications
• Flash memory: 32 MB
• RAM: 64 MB
18.19 Power requirements
Power adapter to be used: Switched Power Module 100-240 VAC, 20W, Vout=12 Vdc, Iout=1A. Note
that a 24/48VDC power adapter can also be delivered.
Do not use another type of power supply than the one recommended by OneAccess.
18.20 Dimensions
The standard version of the 1424 SHDSL Router has a metal housing with the following characteristics:
• Width: 275 mm
• Height: 55 mm
• Depth: 146 mm
• Weight: 1,26 kg
Alternatively, a plastic housing may be offered with the following characteristics:

• Width: 270 mm
• Height: 65 mm
• Depth: 145 mm
• Weight: 0,8 kg
The weight of the external power adaptors is as follows:
Sales code Description Weight (kg)
202752 PWR-PLUG (EUR VERSION) 230VAC->12VDC 0,1
202753 PWR-PLUG (UK VERSION) 230VAC->12VDC 0,1
202754 PWR-PLUG (US VERSION) 110VAC->12VDC 0,1
191706 PWR-PLUG +/-48/24VDC FOR 7,5 /12VDC CPE DEVICES 0,3

18.21 Safety compliance
• EN60950-1 - 1st edition: Safety of information technology equipment, including electrical business
equipment.
• Class 2 equipment.
18.22 Over-voltage and over-current protection compliance
The over-voltage and over-current protection complies with ITU-T K.44 and ETSI ETS 300 386-2 recom-
mendations.
18.23 EMC compliance
• EN55022 B Emissions
• EN55024 Immunity
• EN61000-3-2 Harmonics
• EN61000-3-3 Voltage fluctuations and flicker
• EN61000-4-2 ESD
• EN61000-4-3 Radiated immunity
• EN61000-4-4 EFT/burst
• EN61000-4-5 Surge
• EN61000-4-6 Conducted immunity
• EN61000-4-8 Power magnetic field immunity
• EN61000-4-11 Voltage dips & drops
• ENV50204 Radiated immunity against digital radio telephone
• EN300386 V.1.3.3 Ems Requirements
18.24 Environmental compliance
• Storage conditions: ETSI ETS 300 019-1-1 Class 1.1. In addition, the storage temperature has to be
between -25 to +70°C, with a relative humidity between 0 and 95% non-condensing.
• Transport conditions: ETSI ETS 300 019-1-2 Class 2.3
• Stationary use conditions: ETSI ETS 300 019-1-3 Class 3.2. In addition, a relative humidity between
0 and 95% non-condensing and an ambient operational temperature between -10 to 50°C is sup-
ported.
• Maximum altitude: 3000m
• International protection (IP) class of protection against solid and liquids: IP40
• In use: Temperature Controlled.
- Test specification (Part1 Classification of environmental conditions):
› Class T3.1 (normal)
› Class T3.1 (exceptional)
1424 SHDSL Router 1205
Annex
Annex
Annex
1424 SHDSL Router Annex A: 1207
Annex common TCP and UDP numbers
Annex A: common TCP and UDP numbers

The following table shows the port numbers for a number of common protocols using TCP and UDP as
transport protocol. As far as possible, the same port numbers are used for TCP as for UDP. A complete
list can be found on http://www.iana.org/assignments/port-numbers.
Port No Protocol UDP/TCP Description
20 ftp-data TCP File Transfer (Default Data)
21 ftp TCP File Transfer (Control)
23 telnet TCP Telnet
25 smtp TCP Simple Mail Transfer Protocol
37 time UDP/TCP Time Server
42 nameserver UDP Host Name Server
53 domain UDP/TCP Domain Name Server
65 tacacs-ds UDP/TCP TACACS-Database Service
67 bootps UDP Bootstrap Protocol Server
68 bootpc UDP Bootstrap Protocol Client
69 tftp UDP Trivial File Transfer
80 www-http TCP World Wide Web HTTP
119 nntp TCP Network News Transfer Protocol
137 netbios-ns UDP NETBIOS Name Service
138 netbios-dgm UDP NETBIOS Datagram Service
139 netbios-ssn UDP NETBIOS Session Service
161 snmp UDP SNMP
162 snmptrap UDP SNMPTRAP
1728 OneAccess UDP OneAccess Protocol used by TMA

1208 1424 SHDSL Router Annex A:
Annex common TCP and UDP numbers
1424 SHDSL Router Annex B: 1209
Annex product information
Annex B: product information

The following table displays the product information of the 1424 SHDSL Router:
Sales code Product name Description

208594 1424 SHDSL 1P ROUTER 230VAC IP router and bridge with SHDSLbis 1 pair line interface. 4
port 10/100Mbit/s Ethernet switch and a second 10/
100Mbit/s Ethernet interface. Supports ATM and EFM
over the line. Delivered with European AC power adapter.
208595 1424 SHDSL 1P ROUTER NPWR IP router and bridge with SHDSLbis 1 pair line interface. 4
over the line. Delivered without power adapter.
202752 PWR-PLUG (EUR VERSION) 230VAC- Wallplug Switched Power Module EUR type, 230Vac ->
>12VDC 12Vdc for Desktop units delivered without power adapter.
(xxx NPWR). See doc OneAccess Product Quick
Reference for compatibility with xxx NPWR item
202753 PWR-PLUG (UK VERSION) 230VAC- Wallplug Switched Power Module UK type, 230Vac ->
202754 PWR-PLUG (US VERSION) 110VAC- Wallplug Switched Power Module US type, 110Vac ->
191706 PWR-PLUG +/-48/24VDC FOR 7,5 /12VDC Wallplug power module with input range: 18 to 72Vdc and
CPE DEVICES output: 7,5 / 12Vdc for Desktop units delivered without
power adapter. (xxx NPWR). Fully isolated input. Suitable
for + & - DC input voltages.
1210 1424 SHDSL Router Annex B:
Annex product information
1424 SHDSL Router Annex C: 1211
Annex Console cable
Annex C: Console cable

The following figure shows the console cable assembly:
1212 1424 SHDSL Router Annex C:
Annex Console cable
1424 SHDSL Router Index 1213
Annex
Index NAT, how works 238

PAT and NAT, combining 240
PAT, enabling on an interface 228
Symbols PAT, how works 230
<Struct>, what is 40 PAT, limitations and work-around 233
what is 226
<Table>, what is 40 why use 226
Numerics addressing, relative and absolute 804
3DES chip AF PHB, what is 264
identifying the 3DES version 439 alarm attributes 1119
standard versus 3DES version 439 configuration 1124
status 439 general 1125
4 port Ethernet switch introduction 1123
introducing 337 overview 1120
what is 337 alarms
BGP ePeer and iPeer 1142
A
bundle 1139
absolute and relative addressing 804 end 1135
general 1126
access list
basic configuration 370 LAN interface 1128
line 1132
access lists as advanced filter line pair 1133
configuring 346 MLPPP 1139
access lists as simple filter router 1140
configuring 345 WAN interface 1129
access lists on the bridged interface application mode, what is 1174

configuring 344 application software
access restrictions downloading
bridge interface 371 using FTP 1178
IP interface 370 using TFTP 1176
protocol stack 373 using TMA 1175
using TML 1177
access security what is 1174
specifications 1200
ARP cache
action, what is 41 how works the 512, 574
activating the configuration 91 proxy ARP 513, 574
time-out 512, 574
adding an object to the containment tree 45
what is 512, 574
how 47
in (TMA) CLI 47 ATM
in ATWIN 48 basic configuration 97
in the Web Interface 48 bridged/routed Ethernet/IP over ATM (RFC
in TMA 47 2684), configuring 121
referring to the added object 49 CBR, configuring 118
when 46 Classical IP (IPoA), configuring 122
which objects 46 configuration attributes 533
why 46 introducing 98
IP addresses
additional features
automatically obtaining 112
basic configuration 363
configuring 113
address translation performance attributes 1034
basic configuration 225 PPPoA, configuring 123
introducing 226 PPPoE, configuring 124
NAT, adding multiple NAT objects 236 PVCs, configuring 110
NAT, easy NAT 240 status attributes 847
NAT, enabling on an interface 234 UBR, configuring 115
1214 1424 SHDSL Router Index
Annex
VBR-nrt, configuring 116 reset 1068

VBR-rt, configuring 117 retrain 1047
VPI and VCI, configuring 114 saveCertificates 1010
what is 98 Set Date 830
Set Time 830
ATM Adaptation Layers (AAL), what are 99
startPing 1061
ATM layers, what are 99 startTracert 1062
ATM PVC stopPing 1061
bandwidth assignment 119 stopTracert 1063
configuring 110 unBlacklist 923
what is 98 attribute - alarm
ATM service categories alarmInfo 1125
Maximum burst Size(MBS) 101 alarmLevel 1124
traffic parameters 100 alarmMask 1124
what are 100 totalAlarmLevel 1125
attack attribute - configuration

FTP Bounce, what is 455 728
ICMP Error Message, what is 456 accessControl 784, 809
IP Option, what is 456 accessList 805
IP Spoofing, what is 456 accessPolicy 806
IP Unaligned Timestamp, what is 455 adapter 513
MIME, what is 455 addresses 655
Ping Of Death, what is 456 addrPools 637
Sequence Number Out Of Range, what is advancedFilter 788, 790, 791
456 advertiseInterval 742
Sequence Number Prediction, what is 456 aggregates 721
source routing, what is 455 alarmFilter 807
SYN Flooding, what is 455 alarmLevel
WinNuke, what is 455 LAN interface object 527
line object 590
attacks PPP bundle object 615
types, which are the different 454 router object 651
attribute top object 506
overview 50 WAN interface object 531
what is 40 alarmMask
LAN interface object 527
attribute - action
line object 590
Activate Configuration 507
PPP bundle object 615
clearAllCounters 1023
router object 651
clearArpCache 842, 985
top object 506
clearBridgeCache 985
WAN interface object 531
clearCounters 1023
alg 767
clearSAs 937
algorithm 606
clearTracert 1063
alignStatsToRtc 810
Cold Boot 508
alternativeRoutes 622
Delete File 1003
areaId 711
forceDnsUpdate 923
arp 512, 573, 774
generateSelfCertificateRequest 1004
asNr 720
getCrlScep 1010
astranslation 729
getSelfCertificateScep 1008
attacks 763
getTrustedCertificateScep 1007
atwinGraphics 808
Load Default Configuration 507
authenPeriod 569
Load Preconfiguration 507
authentication 569
Load Saved Configuration 508
bandwidth 522, 575, 609
loadSelfCertificate 1006
bcastStormProtection 529
loadTrustedCertificate 1003
bestPath 720
loopbackActivation 899
bootFromFlash 504
Rename File 1003
bridgeCache 775
Annex
bridgeTimeOut 776 lowdelayQuotum 608

bridging 511, 575, 612 macAddress 779, 787
channel 580 management 589
cms2Address 804 maxFifoQLen 531
compression 567 maxFifoQlen 614
consoleNoTrafficTimeOut 807 maxPingReplies 809
countingPolicy 608 med 735
criticals 741 members 612
ctrlPortProtocol 810 method 593
defaultQueue 615 mib2Traps 798
defaultRoute 618 mode 510, 572, 612
delayOptimisation 564 modeLearnedDlci 564
dhcpCheckAddress 633 mru 565
dhcpDynamic 631 multiclassInterfaces 613
dhcpStatic 629 multiHop 730
dlciTable 556 name 510, 531, 572, 773
dmzHost 656 networks 712, 721
dns 636 nextHop 735
dnsUpdateClient 644, 645 nextHopSelf 730
dropLevels 598, 604 numExpectedRepeaters 589
encapsulation 531 oamMode 577
eocHandling 589 origin 735
espAuthenticationAlgorithm 694 originateDefault 726
espAuthenticationKey 694 outboundFilters 727
espEncryptionAlgorithm 692 outboundMaps 728
espEncryptionKey 693 outboundPolicies 745
filter 735, 737 outboundSelfPolicies 755
filters 732 patAddress 653
fragmentation 564, 613 phase1 697
ftp 806 phase2 701
gateway 655 ports 528
greTunnels 684 portTranslations 653
helperProtocols 626 pppoEClient 525, 576
importDefault 709 pppSecretTable 625
importFilter 723 preemptMode 742
importMetrics 707, 708, 722 prependAsPath 735
inboundFilters 727 priorityPolicy 511, 531, 575, 614
inboundMaps 728 pvcTable 534
inboundPolicies 750 queueConfigurations 608
inboundSelfPolicies 759 radius 634
inspection 745 ranges 717
interfaces 740 refBandwidth 706
ip 510, 555, 572, 612, 774 region 581
ipAddress (loopback) 815 remoteAs 729
ipAddresses 739 remoteIp 725
ipNetMask (loopback) 816 retrain 582
ipsecGreTunnels 687 ripHoldDownTime 623
ipsecL2tpTunnels 666 ripUpdateInterval 622
ipsecTunnels 674 ripv2SecretTable 624
keyChains 706 routerId 706, 720
l2tpTunnels 659 routingProtocol 622
linkAlarmThresholds 588 routingTable 620
linkMonitoring 568 security 505
lmi 561 sendAdminUnreachable 628
localAccess 779 sendHostUnreachable 643
localIp 725 sendPortUnreachable 628
localPreference 720, 735 sendTtlExceeded 627
log 765 servicesAvailable 654
logStatsToFile 810 sessionName 570
Annex
sessionSecret 570 d7LineParameters 1048

sNet 816 d7Performance 1028, 1049, 1106
snmp 806 discards 1065, 1098
snmpIndexOffset 602, 604, 609, 614, 657, dlciTable 1043
695, 703, 728, 732, 735, 737, 743, 787, espAuthenticationFailure 1077
816 espDecryptionFailure 1077
softReconfig 726 espDroppedFrames 1077
spanningTree 777 espSequenceNrReplay 1077
spi 694 filter 1091
startupMargin 584 filters 1087
stub 711 freeBlockCount 1116
switchMode 527 freeDataBuffers 1116
sysContact 504 freeMemory 1117
sysLocation 504 greTunnels 1075
sysLog 801 h24Attack 1094
sysName 504 h24General 1093
sysSecret 625 h24Line 1047
tcpSockets 656 h24LineParameters 1048
tcpSocketTimeOut 655 h24Performance 1028, 1049, 1106
telnet 806 h2Line 1047
tftp 806 h2LineParameters 1048
timedStatsAvailability 807 h2Performance 1027, 1049, 1106
timers 725 icmpAllocs 1067
timeServer 803 icmpSocketsUsed 1066
timeZone 803 ifDropLevelExceeded 1028
tos2QueueMapping 600 ifInDiscards 1025
trafficShaping 595 ifInErrors 1025
trapDestinations 797 ifInNUcastPkts 1025
udpSockets 656 ifInOctets 1025
udpSocketTimeOut 656 ifInQLen 1026
userInfo 814 ifInUcastPkts 1025
virtualLinks 715 ifInUnknownProtos 1025
vlan 515, 575, 779 ifOutDiscards 1026
vlanPriorityMap 604 ifOutErrors 1026
vlanSwitching 782 ifOutNUcastPkts 1026
vp 549 ifOutOctets 1026
vrfRouter 602, 816 ifOutPQLen 1028
vrId 739 ifOutQLen 1026
weight 726, 735 ifOutUcastPkts 1026
attribute - performance inboundFilters 1084
addressesAvailable 1066 inboundMaps 1085
advancedFilter 1108 inPackets 1077
allocFails 1065 ipsecGreTunnels 1075
bridgeAccessList 1108 ipsecTunnels 1073
bridgeBroadcasts 1102 ipStackEvents 1114
bridgeCache 1101 l2tpTunnels 1070, 1071
bridgeDiscards 1102 largestFreeBlockSize 1116
bridgeFloods 1102 line 1047
bridgeMulticasts 1102 lineParameters 1048
bridging 1105 lmi 1045
cacheEvents 1104 messagesRcvd 1083
cliSessionCount 1113 messagesSent 1083
mib2Counters 1110
cllmInFrames 1045
mpdStats 1111
cms2SessionCount 1113
multiclassinterfaces 1053
currUsedProcPower 1116
multiVlans 1103
d7Attack 1095
outboundfilters 1085
d7General 1093
outboundMaps 1085
d7Line 1047
outPackets 1077
Annex
performance 1049 ccpHisOptions 875

phase2Negotiations 1079 ccpMyOptions 875
phase2Sessions 1079 clearLog 974
pingResults 1058 cllmLastCongestionCause 869
pppoEClient 1029 cms2Address 994
prefixesRcvd 1084 configurationSaving 830
prefixesSent 1084 coreDump 1012
pvcTable 1035 corruptBlocks 1001
qualityMonitor 1059 criticals 971
radiusAcct 1057 date 830
radiusAuth 1057 deviceId 830
routingTable 1056 dhcpBinding 918
sessions 1083 dhcpBlackList 919
socketsFree 1065 dhcpStatistics 918, 919
taskInfo 1117 dlciTable 865
tcpAllocs 1067 dns 920
tcpSessionCount 1114 dnsServers 920
tcpSocketsUsed 1066 engineId 992
tftpSessionCount 1114 eocAlarmThresholds 892, 898
totalDataBuffers 1116 eocSoftVersion 897
totalMemory 1117 eocState 898
tracertResults 1058 externalRoutes 942
trafficShaping 1098 fileList 1001
udpAllocs 1067 flash1Version 828
udpSocketsUsed 1066 flash2Version 828
unknownCells 1041 flashVersions 829
usedProcPower 1116 freeSpace 1001
uses 1087, 1089 greTunnels 932
usmStats 1111 hisAuthenticationStatus 876
vlan 1029 hisCompressionRatio 875
vlanSwitching 1103 hosts 947
vp 1041 ifDescr 832, 844, 889, 902, 978, 999
ifLastChange 832, 844
attribute - status
ifMtu 832, 844, 978, 999
abrs 949
ifOperStatus 832, 844, 889, 893, 902, 978,
accessLog 997
999
activeFlash 829
ifSpeed 832, 844, 889, 893, 902
actualBitRate 894
ifType 832, 844, 889, 902, 978, 999
adapter 837
igmpTable 916
addresses 925
interfaces 945, 971
addrPools 921, 922
adjRibIn 964 ip 833, 865, 871, 878, 904, 978
adjRibOut 964 ipAddress 999
adjSoftIn 964 ipAdEntBcastAddr 839
aggregates 958 ipAdEntReasmMaxSize 839
alarmLog 996 ipcpHisOptions 873, 905
arpCache 834, 878, 979 ipcpMyOptions 873, 905
asbrLsas 954 ipcpState 872, 904
asExtLsas 943 ipsecGreTunnels 933
atmSync 848 ipsecL2tpTunnels 928
bacpHisOptions 908 ipsecTunnels 935
bacpMyOptions 907 l2tpTunnels 927
bacpState 907 lcpHisOptions 873
lcpMyOptions 872
bcpHisOptions 874, 907
lcpState 871
bcpMyOptions 874, 906
lineAttenuation 893, 899
bcpState 872, 906
lmi 867
bootVersion 829
log 974
bridgeCache 980
macAddress 833, 971, 978
bridging 835, 871, 906, 981
mask 999
Annex
members 903 warning 965

messages 829
attribute string, reading an viii
multiclassInterfaces 909
myAuthenticationStatus 876 auto-install 1147
myCompressionRatio 875 on the LAN interface 1150
neighbors 947 example 1153
networkLsas 952 in case of Ethernet 1152
networks 958 set-up 1151
nssaLsas 955 on the WAN interface 1155
numDiscoveredRepeaters 890 example 1159
peers 961 in case of ATM 1157
phase1 937 in case of Frame-Relay 1158
phase2 937 setup 1156
poolReservations 921 protocols, introducing 1148
ports 838 specifications 1186
pppoEClient 839
pvcTable 848 B
radius 920 BAP
region 889 what is 164
remote 963
reverseSessions 973
access list 370
rib 959
additional features 363
routerLsas 950
address translation 225
routes 941
ATM 97
routingTable 913
BGP 221
selfCertificates 1002
bridging 297
sessions 973
CIR and EIR 157
shdslVersion 898
DHCP 364
shutDown 965
encapsulation 95
signalNoise 894, 899
firewall 450
sNet 974
Frame Relay 145
snmpIndex 841, 894, 910, 967, 969, 987
GRE tunnels 389
softReset 965
IP address on the LAN interface 63
spanningTree 983
IP addresses 53
status 893, 963, 1001
IPSEC 407
stepupTreshold 894
L2TP tunnel 379
summLsas 953
line 75
sysDescr 828
OAM 125
sysObjectID 828
OSPF 212
sysServices 828
passwords 87
sysUpTime 828
policy based routing 197
taskInfo 1012
PPP 160
tdreVersion 829
RADIUS 440
time 830
RIP 204
timers 963
routing 185
timeServer 995
static routing 188
timeSinceLastRetrain 893
traffic and priority policy
transmitPower 894
on the router 259
trapDestinations 992
VLAN 325
trustedCertificates 1002
VLANs on the 4 port Ethernet switch 336
type 940
VRRP 247
upTime 963
users 967, 969 BC
vendorId 897 what is 147
vendorModel 897 BCP, what is 161
vendorSerial 897
vendorSoftVersion 897 BE
vlan 837, 982 what is 147
vp 858 BE PHB, what is 264
Annex
BECN configuring 313

what is 148 IP address, configuring 313
multiple bridge groups, what are 312
BGP
performance attributes 1100
specifications 1193
configuration attributes 718
what is 312
introducing 221
key attributes 222 bridge interface
performance attributes 1081 access restrictions 371
route selection process 223
bridge port
routeFilter attribute 224 state transition diagram 306
routeMap attribute 224 states 306
status attributes 956
transport protocol 221 bridged traffic
applying QoS 352
BGP ePeer and iPeer
alarms 1142 bridged/routed Ethernet/IP over ATM (RFC
configuration attributes 724 2684)
performance attributes 1082 configuring 121
status attributes 962 bridging
BGP general basic configuration 297
configuration attributes 719 bridge group, adding 314
status attributes 957 bridge group, configuring 313
bridging attributes, introducing 312
BGP route filter
configuring 311
configuring on an interface 317
enabling on an interface 316
explaining the bridging structure 318
BGP route map introducing 298
configuration attributes 734 versus routing 186
performance attributes 1088 what is 299
bridging and routing in a network, a configuration
bit string, what is 40 example 360
boot mode, what is 1174 bridging structure
explanation 318
boot software, what is 1174
where to find 317
BootP
what is 1148 broadcasting
specifications 1192
bridge
bundle
alarms 1139
general configuration attributes 772
performance attributes 1099 configuration attributes 610
specifications 1193 performance attributes 1051
status attributes 976 status attributes 900
bridge access list C

CBR
configuring 118
bridge cache what is 105
time-out 776
CCP, what is 161
what is 775
CHAP
bridge filtering authentication in both directions 175
specifications 1193
authentication in one direction 174
bridge group configuring 173
adding 314 how works 174
bridge priority, setting 313 use sysName/sysSecret or sessionName/
bridging protocol, selecting 313 sessionSecret? 176
configuration attributes 772 what is 162
Annex
child object, what is 40 router 616

router, general 617
CIR
routing filter 736
SNMP 796
what is 147
traffic policy
Classical IP (IPoA), configuring 122 bridging 603
CLP, what is? 109 IP 592
VRRP 738
colouring of bridged packets WAN interface 530
QoS 354
configuration examples 485
common TCP and UDP numbers 1207
configuration file
compatibility with other SHDSL devices 78 creating 1162
complex value, what is 40 creating a binary file using TMA 1164
creating an ASCII CLI file
configuration
using Telnet 1168
activating the 91
using TFTP 1167
loading the default
using TMA 1165
using the action 91
downloading 1169
loading the preconfiguration 92
using (T)FTP 1171
configuration action using Telnet 1172
executing 89 using TMA 1170
what is 90 formats 1163
configuration alarm attributes 1124 restoring 1169
configuration attributes 491 configuration type

ATM 533 active 90
BGP 718 default 90
BGP ePeer and iPeer 724 explaining the 90
BGP general 719 non-active 90
BGP route filter 731 what is 90
BGP route map 734 configuring
bridge 771 access lists as advanced filter 346
bridge access list 786 access lists as simple filter 345
bridge group 772 access lists on the bridged interface 344
bundle 610
connecting the device 18
encapsulation 532
firewall 744 connecting with TMA
Frame Relay 554 over an IP network 36
general 503 through the control connector 34
GRE tunnels 683 connection precautions 17
IKE SA 696
L2TP tunnel 658 console cable 1211
LAN interface 509 containment tree
line 578 adding an object 45
line pair 578 of the device 42
management 799 terminology 40
manual SA 691 what is 40
MLPPP 610
conventions in this manual
NAT 652
graphical vii
native IPSEC tunnel 673
OSPF 704 typographical vi
OSPF area 710 copyright notice ii
OSPF, general 705
COS, what is 265
overview 492
PPP 566 creating passwords in the security table 88
PPP bundle 611 CS PHB, what is 264
priority policy 605
profiles 591
Annex
D graphical vii
typographical vi
DE
copyright notice ii
what is 148
documentation set v
default queue environmental information iv
configuring 286 intended audience ix
versus traffic policy profile 286 organisation v
what is 286 properties ii
default route statements iii
configuring 190 TDRE version described in this ix
what is 189 your feedback ix
DES and 3DES, what is 410 documentation set v
DHCP downloading a configuration file 1169

basic configuration 364 using (T)FTP 1171
combining static and dynamic tables 365 using Telnet 1172
DHCP server reaction on a BootP request using TMA 1170
365 downloading application software
dynamic IP addresses, assigning 367 using FTP 1178
introducing 365 using TFTP 1176
relay agent using TMA 1175
configuring the OneAccess device as 369 using TML 1177
what is 365
downloading files to the file system 1179
releasing IP addresses, DHCP versus BootP
365 downloading software 1173
static IP addresses, assigning 366
DSCP, what is 263
what is 365, 1148
Diff-Serv E
PHB, what is 263 easy NAT
DiffServ example 241
AF PHB, what is 264 what are the conditions 240
BE PHB, what is 264 what does 240
CS PHB, what is 264 what is 240
DSCP, what is 263 EF PHB, what is 264
EF PHB, what is 264
IP Precedence, what is 263 EFCI, what is 109
TOS byte, what is 263 EIR
what is 263 basic configuration 157
dimensions of the device 1203 what is 147
DIP switch table, reading a viii element, what is 41
DIP switches 27 EMC compliance 1204

opening and closing the housing 29 encapsulation
position on the motherboard 28 basic configuration 95
directed broadcast, what is 61 configuration attributes 532
DLCI selecting an 96
what is 146
end
DMZ alarms 1135
what is 656 performance attributes 1050
DNS status attributes 896
what is 636, 1148 environmental compliance 1204
DNS proxy environmental information iv
what is 636
EOC message exchange
document discovering devices on the SHDSL line 82
conventions enabling 79
Annex
proprietary configuration attributes 744

controlling 80 introducing 451
retrieved standard EOC information 83 performance attributes 1092
standard policies, SNet and self in- and outbound 453
controlling 81 policy, defining
standard versus proprietary 80 determining which policies have to be de-
fined 472
example
inbound self 466
bridge group, adding multiple 315
inbound SNet 462
default queue, configuring 287
outbound self 464
default route, configuring 190
outbound SNet 460
extended access list, configuring 284
protocol stack, allowing access to 469
L2TP tunnel, configuring 384
rules of thumb when configuring 468
NAT, configuring 239
SNet, adding an interface to 458
PAT, configuring 229
SNet, what is 452
policy based routing, configuring 200
specifications 1199
priority policy on the router, configuring 294
stateful inspection, what is 451
priority policy, applying on an interface 293,
351
types 451
priority policy, creating 292
types of attacks 454
RIP, configuring 207
VFS, what is 451
static route (WAN IP address not present),
configuring 193 Frame Relay
static route (WAN IP address present), con- basic configuration 145
figuring 192 configuration attributes 554
traffic policy on the router, configuring 294 DLCI global IP addresses 154
traffic policy, applying on an interface of the DLCI specific IP addresses 155
router 277 DLCIs, configuring 150
traffic policy, creating on the router 275 fragmentation, enabling 159
VLAN switching, configuring 334 introduction 146
VRRP master/backup with owner, configuring IP addresses
251 automatically obtaining 152
VRRP master/backup without owner, config- configuring 153
uring 253 LMI, configuring 156
examples 485
specifications 1188
combining bridging and routing in a network
360
what is 146
connecting a LAN to the Internet using NAT
and PAT 243 Frame Relay DLCI
LAN extension over a PDH/SDH network 486 configuring 150
using PAT with a minimum of official IP ad-
Frame Relay fragmentation
dresses 245
enabling 159
executing configuration actions 89 end-to-end fragmentation, what is 149
extended access list interface fragmentation, what is 148
setting up 375 FTP Bounce attack, what is 455
what is 278
G
F general
FECN alarm attributes 1125
what is 148 alarms 1126
feedback ix
file system status attributes 827
downloading files to 1179
GRE tunnels
firewall combining with IPSEC 394
activating 457 configuration attributes 683
Annex
introducing 390 introducing

performance attributes 1074 4 port Ethernet switch 337
some remarks 394 address translation 226
status attributes 931 alarm attributes 1123
when does a GRE tunnel come up? 393 ATM 98
BGP 221
group, what is 41
bridging 298
H DHCP 365
firewall 451
HMAC MD5 and SHA-1, what is 410 Frame Relay 146
housing, opening and closing 29 GRE tunnels 390
IKE 411
HWA chip 439
IPSEC 408
I L2TP tunnel 380
maintenance and management tools 8
ICMP management terminology 38
specifications 1191 native IPSEC tunnel 416
ICMP Error Message attack, what is 456 OSPF 213
policies, traffic and priority 262
ICMP message policy based routing 198
communication prohibited 628
PPP 161
port unreachable 628 RADIUS 441
TTL exceeded 627 RIP 205
ICMP redirect, what is 61 routing 186
static routing 189
IEEE 802.1P, what is 265
the device 4
IGMP VLAN 326
topology 916 VRRP 248
what is 916
introduction 3
IKE
authentication 412 IP addresses
encryption 411
IKE DH group, what is 412 in ATM 112
introducing 411 in Frame Relay 152
in PPP 165
IPSEC DH group, what is 412
NAT-T, what is 415
configuring
negotiation 411
in ATM 113
PFS, what is 412
in Frame Relay 153
preshared key authentication, what is 412
in PPP 167
security certificate
on the LAN interface 63
how to obtain 413
explaining the IP structure 56
terminology 413
imposing on the remote in PPP 168
security certificate authentication, what is 413
private range 226
what is 411
specifications 1186
IKE SA where to find the IP parameters 55
IP filtering
specifications 1192
IP interface
index name, what is 40
access restrictions 370
index, what is 40
IP MTU
installing and connecting the device 11 specifications 1192
instance name, what is 40 IP Option attack, what is 456
instance value, what is 40 IP Precedence, what is 263
interface IP security
what is 52 performance attributes 1076
Annex
IP Spoofing attack, what is 456 LAC, what is 380

IP structure LAN extension over a PDH/SDH network, a con-
explanation 56 figuration example 486
where to find 55
LAN interface
IP Unaligned Timestamp attack, what is 455 alarms 1128
IPCP, what is 161
IPSEC status attributes 831
AH, what is 409
LAN to Internet connection using NAT and PAT,
authentication 410
a configuration example 243
compatibility 408 LCP, what is 161
encryption 410
LED indicators 22
ESP, what is 409 introduction 23
HWA chip 439
introducing 408 line
manual SA, what is 410 alarms 1132
modes 408 auto speed 77
NAT-T, what is 415 basic configuration 75
protocols (ESP and AH) 408 compatibility with other SHDSL devices 78
SA, what is 410 configuration attributes 578
setting up an IPSEC secured L2TP tunnel essential configuration attributes 76
using a manual SA 421 fall-back speed 77
using an IKE certificate SA 425 performance attributes
using an IKE preshared SA 423 performance attributes
specifications 1195 line pair 1046
SPI, what is 410 power back-off, what is 78
transport mode, what is 408 retrain criteria 582
tunnel mode, what is 408 selecting a fixed speed 77
what is 408 selecting a speed (range) 77
selecting a speed range 77
IPsec
setting up an IPsec secured GRE tunnel specifications 1182
using a manual SA 427 status attributes 887
using an IKE certificate SA 431 line pair
using an IKE preshared SA 429 alarms 1133
IPSEC combined with GRE tunnels 394
L status attributes 887
L2TP status LIP

authentication states 930 what is 149
call states 929 LMI
control states 929 configuring 156
delivery states 930 what is 146
L2TP tunnel LNS, what is 380
loading the default configuration
using the action 91
encapsulation 381
how works 385 loading the preconfiguration 92
introducing 380
performance attributes 1069 M
setting up 382 maintaining the device 31
setting up a main and back-up tunnel 386 with TMA 32
specifications 1195
status attributes 926 maintenance and management
terminology 380 connection possibilities 10
what is 380 specifications 1200
Annex
maintenance and management tools specifications 1194

introducing 8 status attributes 924
what is 226
management
when use 227
performance attributes 1112 NAT on the LAN interface, a remark 235
Native IPSEC tunnel
management terminology, introducing 38 setting up an IPSEC secured tunnel
using a manual SA 417
manual SA
configuration attributes 691 using an IKE certificate SA 420
using an IKE preshared SA 419
native IPSEC tunnel
Maximum burst Size(MBS) 101
MBS, what is 100 introducing 416
memory performance attributes 1072
specifications 1201 status attributes 934
MIME attack, what is 455 NAT-T, what is 415
MLFR O
what is 149
OAM
MLPPP activation/deactivation mechanism 137
alarms 1139 basic configuration 125
configuration attributes 610 concepts 129
setting up 177 continuity check (CC) 134
on a BRI interface in leased line mode 181 fault and performance management 131
motherboard, position of the DIP switches 28 functional overview 128
loopback(LB) 133
MPoA performance management (PM) 136
what is 106 what is 126
MRU OAM AIS, what is 1036
what is 565
OAM RDI, what is 1036
MS-CHAP
version 1, what is 162 object, what is 40
version 2, what is 163 operating system
MS-CHAP, what is 162 performance attributes 1115
MTU
what is 59, 664, 676, 686, 690 organisation of this manual v
multicasting OSPF
specifications 1192 activating 218
authentication, enabling 219
multiclass PPP basic configuration 212
setting up 183 configuration attributes 704
what is 164 configuration attributes, general 705
multi-protocol over ATM introducing 213
encapsulation mechanisms, which are 107 specifications 1191
what is 106 status attributes 938
status attributes, general 939
N what is 213
NAT adjacency 216
adding multiple NAT objects 236 area 0 214
combining with PAT 240 areas 214
configuration attributes 652 authentication 217
easy NAT 240 backbone area 214
enabling on an interface 234 border routers 214
how works 238 cost 216
performance attributes 1064 link states 213
Annex
neighbours 216 general 1022

NSSA 215 GRE tunnels 1074
stub areas 215 IKE SA 1078
virtual links 216 IP security 1076
L2TP tunnel 1069
OSPF area
LAN interface 1024
line 1046
management 1112
overview manual SA 1076
alarm attributes 1120 NAT 1064
configuration attributes 492 native IPSEC tunnel 1072
performance attributes 1014 operating system 1115
status attributes 818 overview 1014
over-voltage and over-current protection compli- PPP bundle 1052
ance 1204 router 1054
router, general 1055
P traffic policy
IP 1097
PAP
WAN interface 1032
authentication in both directions 172
authentication in one direction 171 Ping Of Death attack, what is 456
configuring 170 policies on the router
how works 171 basic configuration 259
use sysName/sysSecret or sessionName/
sessionSecret? 176 policies, traffic and priority
what is 162 configuring on the router 273
introducing 262
parent object, what is 40 on routed and on bridged data 266
passwords specifications 1196
basic configuration 87 policy based routing
creating in the security table 88 basic configuration 197
entering in the different management tools 88 introducing 198
remarks on 506 setting up 199
PAT specifications 1191
combining with NAT 240 what is 198
enabling on an interface 228 power requirements 1202
how works 230
limitations and work-around 233 PPP
specifications 1194 basic configuration 160
what is 226 CHAP, configuring 173
when use 227 CHAP, how works 174
PAT with a minimum of official IP addresses, a fragmentation, enabling 182
configuration example 245 handshake 161
PCR, what is 100 introducing 161
IP addresses
ATM 1034
configuring 167
BGP 1081
imposing on the remote 168
BGP ePeer and iPeer 1082
link monitoring, configuring 169
BGP route filter 1086
MLPPP, setting up 177
BGP route map 1088
on a BRI interface in leased line mode 181
bridge 1099
multiclass PPP, setting up 183
bridge access list 1107
PAP, configuring 170
bridge group 1100
PAP, how works 171
bundle 1051
specifications 1189
encapsulation 1033
end 1050
what is 161
firewall 1092
Frame Relay 1042 PPP bundle
Annex
configuration attributes 611 queueMapped IP traffic policy 272

performance attributes 1052 tosMapped IP traffic policy 271
status attributes 901 traffic classes 261
traffic shaping IP traffic policy 269
PPP fragmentation
what is 260
enabling 182
what is 164 R
PPP link monitoring RADIUS
configuring 169 accounting 442
what is 161
accounting, enabling 446
PPPoA authentication 442
configuring 123 authorisation 442
what is 108 basic configuration 440
device access authentication, enabling 443
PPPoE
introducing 441
configuring 124
IP settings
what is 108
client (calling) 449
PPPoE over ATM NAS (called) 449
what is 108 network access authentication, enabling 445
priority policy supported attribute types 447
creating 291 reading a
QoS on bridged traffic 352 DIP switch table viii
specifications 1197
what is 262 reading an
attribute string viii
priority queuing, what is 262
referring to an added object
product information 1209 example 49
profiles how to 49
protocol stack relative and absolute addressing 804

access restrictions 373 relay agent
inbound extended access list 375 the OneAccess Router as 1149
proxy ARP, what is 513, 574 remarks on
accessing a proxied device via its IP address
Q 512
QoS CIR 157
applying on bridged traffic 352 DHCP requests and access lists 366, 368
applying priority policy on bridged traffic 352 dhcpStatistics attribute 918
colouring of bridged packets 354 extended access list on the protocol stack
defining TOS and COS 353 375, 806
DiffServ IP traffic policy 270 filter on port numbers 282
IP SLA or traffic quality monitoring 474 firewall, TMA access when firewall is active
alarms 478 458
introducing 474 helperProtocols attribute 626
jitter or delay variation 476 host routes to local interface IP address 915
qualityMonitor 474 ifOperStatus of the WAN interface 845
statistics 478 IP address on the LAN interface in case of
time window 475 bridging 55, 187, 316, 317, 510, 572, 774
logging of performance statistics 479 ipIntervalPool attribute 641
cleaning of the file system 480 ipListPool attribute 638
configuration 479 L2TP tunnels, auto element 662
example 482 L2TP tunnels, type element 662
file logging 479 l2tpTunnels configuration attribute 383
real time clock 480 loopbackActivation action 899
statistics 480 messages attribute 829
status 481
Annex
NAT in the ip structure versus NAT in the fire- what is 186

wall 62, 749, 754
routing filter
natAddresses attribute 235
passwords 506
PPP fragmentation 182, 183 routing table
rerouting principle 196 configuring 191
resetNat action 1068 rules of thumb when configuring 194
rip2Authentication attribute 210 what is 189
ripv2SecretTable attribute 624 rxCir, rxEir and rxExcess relationship 560
routing update filter 737
selecting a speed range on the 2 pair version S
77
safety
supported line speeds when using ATM or
compliance 1204
EFM 75, 579
instructions 12
telnet attribute 806
requirements ii
trafficShaping table 595
tunnels, main and back-up 388 sales codes 1209
VLAN ID 0 330, 517 SCR, what is 100
VLANs on the 4 port Ethernet switch 339
vlanSwitching attribute 333 selecting a site 14
rerouting principle, what is 196 selecting an encapsulation 96
restoring a configuration file 1169 self test 25
RIP self-learning bridge, what is 300

authentication, enabling on an interface 211 Sequence Number Out Of Range attack, what is
basic configuration 204 456
enabling on an interface 206
explaining the RIP structure 208 Sequence Number Prediction attack, what is 456
how works 205 SNet
introducing 205 what is 452
specifications 1191
SNMP
support 205
what is 205
SNTP, what is 803
RIP authentication
enabling on an interface 211 software
what is 205 downloading 1173
what is boot and application 1174
RIP hold-down timer, what is 623
source routing attack, what is 455
RIP structure, explanation 208
Spanning Tree
router behaviour 308
alarms 1140
bridge failure 308
bridging loops 308
general configuration attributes 617
network extension 308
general performance attributes 1055
BPDU 307
general status attributes 912
propagation of 307
introduction 186
what is 307
bridge port states 306
bridge priority, what is 309
routing path cost, what is 309
basic activities 186 port priority, what is 309
basic configuration 185 priority and cost 309
determining the optimal path 186 root bridge 303
enabling on an interface 187 how selected 303
specifications 1191 what is 303
static versus dynamic 189 topology 304
transporting packets 186
specifications
versus bridging 186
access security 1200
Annex
auto-install 1186 end 896

bridge group 1193 file system 1000
bridging 1193 firewall 972
broadcasting 1192 Frame Relay 864
dimensions 1203 general 827
EMC compliance 1204 GRE tunnels 931
environmental compliance 1204 IKE SA 936
firewall 1199 L2TP tunnel 926
Frame Relay encapsulation 1188 LAN interface 831
ICMP 1191 line 887
IP filtering 1192 line pair 887
IP MTU 1192 management 993
IPaddresses 1186 NAT 924
IPSEC 1195 native IPSEC tunnel 934
L2TP tunnel 1195 operating system 1011
line 1182 OSPF 938
maintenance and management 1200 OSPF area 944
memory 1201 OSPF, general 939
multicasting 1192 overview 818
NAT 1194 PPP 870
OSPF 1191 PPP bundle 901
over-voltage and over-current protection router 911
compliance 1204 router, general 912
PAT 1194 VRRP 970
policies, traffic and priority 1196 WAN interface 843
policy based routing 1191
structured value, what is 40
power requirements 1202
PPP encapsulation 1189 SYN Flooding attack, what is 455
priority policy 1197 syslog, what is 801
RIP 1191
routing 1191 T
safety compliance 1204
target margin, what is 584
static routing 1191
traffic policy on the bridge 1198 TC
traffic policy on the router 1197 what is 147
tunnelling 1195 TDRE
VLAN 1193 version ix
VLAN switching 1193 what is ix
VPN 1195
VRRP 1192 technical specifications 1181
stateful inspection firewall, what is 451 TFTP

what is 1149
statements iii
Time To Live (TTL), what is 627
static routing
basic configuration 188 TMA
default route, configuring 190 connecting over an IP network 36
introducing 189 connecting through the control connector 34
routing table, configuring 191 how to connect 33
specifications 1191 maintaining the device with 32
what is 33
ATM 847 TMA sub-system picture 1143
BGP 956 how to display 1143
BGP ePeer and iPeer 962 structure 1143
BGP general 957 TOS
BGP route filter 966 TOS field, what is 263
BGP route map 968
traffic policy
bridge 976
applying on an interface of the router 276
bundle 900
Annex
configuration attributes of the bridge 603 example 2 341

configuration attributes of the router 592 example 3 342
creating on the router 274 example 4 342
default queue, configuring 286 example 5 343
performance attributes of the router 1097 example 6 343
specifications of the bridge 1198 introducing 337
specifications of the router 1197 setting up 339
what is 262 vlan attribute versus ports attribute 337
VLAN switching restrictions 338
traffic policy profile
versus default queue 286 VPI
configuring 114
Transparent Spanning Tree bridge, what is 300
what is 98
troubleshooting
the device 93 VPN
specifications 1195
tunnelling
VRRP
specifications 1195
backup virtual router, what is 248
U basic configuration 247
UBR introducing 248
configuring 115 IP address owner, what is 248
what is 102 master virtual router
unpacking 13 how is it elected 249
what is 248
UTC, what is 803
primary IP address, what is 248
V setting up 250
specifications 1192
value, what is 40 status attributes 970
VBR-nrt virtual router, what is 248
configuring 116 VRRP router, what is 248
what is 103 what is 248
VBR-rt W
configuring 117
what is 104 wall mounting 15
VCI WAN interface

configuring 114 alarms 1129
what is 98 configuration attributes 530
Virtual Firewall System, what is 451 status attributes 843
VLAN warning
basic configuration 325 earth stud 21
introducing 326 ESD 17
local or global tag significance 521 important safety instructions 12
setting up on the bridge group 331 safety 12
setting up on the LAN interface 329 selecting a site 14
specifications 1193
what is 326 WinNuke attack, what is 455
VLAN double tagging, what is 327

VLAN switching
configuring 332
specifications 1193
stripping the VLAN tag 782
VLAN tag, what is 326
VLANs on the 4 port Ethernet switch
example 1 340

Telindus 1424

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Telindus 1424

Uploaded by

Copyright:

Available Formats

1424 SHDSL Router

User and reference manual

Subject 1424 SHDSL Router

Manual type User and reference manual

Modification date 26 January 2009 ©OneAccess

www.oneaccess-net.com → Products → Choose a product → Downloads → Certificates

Organisation of this manual

This manual contains the following main parts:

Part This part …

Annex gives additional information, such as product sales codes.

The following typographical conventions are used in this manual:

The format … indicates …

Normal normal text.

Italic • new or emphasised words

Blue references to other parts in the manual.

Blue underline • a hyperlink to a web site. E.g. www.oneaccess-net.com

The following icons are used in this manual:

Icon Name This icon indicates …

Remark remarks or useful tips.

Caution text to be read carefully in order to avoid damage to the device.

Warning text to be read carefully in order to avoid injury.

DIP switch a DIP switch or strap table.

Action an action in the containment tree of the 1424 SHDSL Router.

Reading a DIP switch table

Number This position displays …

1 the DIP switch icon.

2 the DIP switch name.

3 the DIP switch position on the DIP switch bank.

5 the function associated with the corresponding DIP switch setting.

Reading an attribute string

The following table explains the attribute string layout:

Number This position displays …

2 the attribute name and its position in the containment tree.

3 the default value of a configuration attribute.

2 Installing and connecting the 1424 SHDSL Router ........................................11

3 DIP switches of the 1424 SHDSL Router .........................................................27

4 Maintaining the 1424 SHDSL Router................................................................31

5 Basic configuration ...........................................................................................51

6 Configuring the WAN encapsulation protocols ..............................................95

7 Configuring routing .........................................................................................185

8 Configuring bridging and VLANs ...................................................................297

9 Configuring the additional features ...............................................................363

10 Configuration examples ..................................................................................485

Reference manual .............................................................................. 489

12 Status attributes ..............................................................................................817

13 Performance attributes .................................................................................1013

14 Alarm attributes .............................................................................................1119

15 TMA sub-system picture ...............................................................................1143

16 Auto installing the 1424 SHDSL Router.......................................................1147

17 Downloading software ..................................................................................1173

18 Technical specifications ...............................................................................1181

Annex ................................................................................................ 1205

Annex B:product information .............................................................................1209

Annex C:Console cable .......................................................................................1211

Index .................................................................................................. 1213

1 Introducing the 1424 SHDSL Router

1.1 General description

A general description of the OneAccess TDRE devices is given in following sections:

1.1.1 1424 SHDSL Router

High speed DSL access

High network availability

Full service router

Accelerated deployment and service provisioning