Solwise
Advanced Reference Guide for
Ltd
.
Solwise SAR110
ADSL Router
Please Note: Incorrect usage of CLI commands
can seriously damage the firmware settings
and configuration of your router to the extent
where you might be unable to reset/restore to
an operable state. We reserve the right to
charge for any faulty router returned for repair
which has user corrupted firmware or settings.
April 11, 2003
- 2 -
Notification is hereby given that Solwise Ltd. reserves the right to
modify, change, update or revise this document from time to time as
required without the prior obligation to notify any person, company
or organization. Further, Solwise makes no warranty or
representation, either express or implied, with respect to
merchantability, or fitness of its products for a particular purpose.
Solwise
13/15 Springfield Way
Anlaby
Hull HU10 6RJ
UK
Tel 0845 458 4558 (local rate)
Fax 0845 458 4559
Email sales@solwise.co.uk
Http www.solwise.co.uk
Copyright
All rights reserved. No part of this document may be reproduced in any form or by any means
without written permission from the product manufacturer.
Changes are periodically made to the information in this document. They will be incorporated in
subsequent editions. The product manufacturer may take improvement and/or changes in the
product described in this document at any time.
Ltd.
Table of Contents
1 Introduction..........................................................9
2 Quick Start.........................................................11
3 CLI Introduction.................................................12
4 Unit Configuration..............................................13
- 3 -
4.1 Default Configuration................................................13
4.1.1 System Sizing Parameters........................17
4.2 Modifying the Unit’s MAC Address and
Serial Number..................................................................19
4.3 Modifying the Unit Configuration via Script
Files..................................................................................19
4.3.1 Notes on Using Script File
Configuration
..........................................................20
4.4 Managing Configuration Changes...........................20
4.5 Using FTP/TFTP to Upgrade and Retrieve
the Flash Image...............................................................21
4.5.1 Data configuration Upgrade ......................22
4.5.2 Recovering from a Failed Upgrade ................22
5 Interfaces and Operating Mode ........................24
5.1 Interfaces – Overview...............................................24
5.2 Configuring the Ethernet Port ..................................24
5.3 Configuring Virtual Ethernet Interfaces....................27
5.4 Configuring the WAN ATM Port...............................27
5.5 Configuring Permanent Virtual Circuits ...................28
5.5.1 AAL5 Data Encapsulation Method .................29
5.5.2 ATM Service Categories: UBR,
CBR, GFR, NRTVBR and RTVBR
5.6 Configuring Switched Virtual Circuits (SVCs)..........33
5.7 Configuring PPP Interfaces......................................36
5.7.1 Creating a Login Name and
Password for a PPP Interface
....................30
.............................37
5.7.2 PPPoE Interfaces........................................38
5.7.3 PPPoA Interfaces........................................39
5.7.4 Checking the IP Address of a PPP
Interface
...................................................................40
- 4 -
5.7.5 Configuring the PPP Auto
start/stop Feature
..................................................40
5.7.6 IP Unnumbered PPP Interfaces...............40
5.8 Configuring the Operating Mode..............................43
5.8.1 Bridge Mode.................................................43
5.8.2 WAN to WAN bridging ...............................46
5.8.3 Router Mode ...................................................46
5.8.4 Bridge Router Autosense (BRAS)...........49
5.8.5 Zero Installation PPPoE Bridge
(ZIPB) Mode
...........................................................50
6 Viewing and Modifying DSL Information...........54
6.1 Modifying the DSL Configuration.............................54
6.2 Viewing DSL Parameters and Statistics..................55
7 Configuring IP and Routing Management.........57
7.1 Configuring Routing on LAN Hosts..........................57
7.2 Configuring Routes...................................................57
7.3 Routing Mode ...........................................................58
7.4 RIP ............................................................................59
7.4.1 RIP Global Configuration...........................59
7.4.2 RIP Interface Configuration.......................59
7.5 IGMP.........................................................................60
8 Virtual Private Network......................................64
8.1 Overview...................................................................64
8.2 L2TP .........................................................................65
8.3 Configuration details.................................................67
8.4 L2TP Traps...............................................................72
9 Configuring DNS Relay.....................................73
9.1 Overview of DNS Relay ...........................................73
9.2 Configuration Details ................................................73
10 Configuring DHCP Server and DHCP
Relay ..............................................................74
10.1 Default DHCP Configuration on the
SAR110 Reference Unit..................................................74
10.2 Configuring Unit as DHCP Server..........................74
10.2.1 Creating DHCP Pools..............................75
10.2.2 Excluding Addresses from a Pool .........77
10.2.3 Modifying and Deleting Pools.................78
- 5 -
10.2.4 Creating Static DHCP Assignments.............78
10.2.5 Enabling the DHCP Server...........................79
10.2.6 DHCP- DNS Relay Interaction...............80
10.2.7 Viewing DHCP Server Address
Assignments
10.3 Configuring DHCP Relay........................................80
...........................................................80
10.3.1 Configuring the DHCP Relay
Interfaces
................................................................80
10.3.2 Specifying the DHCP Server IP
Address
10.3.3 Enabling DHCP Relay Mode........................81
10.4 Using a DHCP Server on the LAN .........................82
10.5 DHCP Traps............................................................82
...................................................................81
10.5.1 Duplicate IP Address Trap......................82
10.5.2 Low Threshold Hit Trap ...........................82
10.6 ForceRenew............................................................83
11 Simple Network Time Protocol..........................84
11.1 Overview .................................................................84
11.2 SNTP implementation details .................................84
11.3 Configuration details ...............................................86
12 Layer 2 Security ................................................88
12.1 Raw Filtering – Overview........................................88
12.1.1 Using Raw Filtering Rules and
Subrules
12.1.2 Raw Filtering Global Configuration...............91
12.2 Protocol Blocking ....................................................91
12.3 L2 Wall.....................................................................92
12.3.1 Overview.....................................................92
12.3.2 Configuration Files....................................93
12.3.3 AutoDetect Algorithm...............................93
12.3.4 Assumptions ..............................................94
12.3.5 Sample Configuration Files ..........................94
..................................................................89
13 Layer 3 Security ................................................96
13.1 NAT .........................................................................96
13.1.1 Default NAT Configuration on the
SAR110 Unit.............................................................97
13.1.2 Configuring NAT Direction ......................98
- 6 -
13.1.3 The napt rule .................................................98
13.1.4 The rdr Rule.............................................100
13.1.5 The basic and filter Rules......................102
13.1.6 The bimap Rule.......................................103
13.1.7 The pass Rule .........................................103
13.1.8 Configuring ALGs........................................103
13.1.9 Enabling NAT ..........................................106
13.2 Firewall ..................................................................106
13.2.1 Attack protection .....................................106
13.2.2 Firewall features......................................110
13.2.3 Configuration details...............................111
13.3 IP Filtering and IP Sessions..................................113
13.3.1 Using IP Filtering Rules .........................115
13.3.2 Configuring Time-of- day based
rules
117
13.3.3 IP Sessions – Advanced
Configuration Issues
...........................................120
13.3.4 IP Filtering Global Configuration..........122
14 Usage Control .................................................124
14.1 Overview ...............................................................124
14.2 User Authentication process.................................125
14.3 Configuration using CLI ........................................130
15 Application Security – Surfing Profile..............132
15.1 Surfing Profile........................................................132
15.2 Invoking the Surfing Profile Feature.....................132
15.3 Types of files .........................................................132
15.3.1 Surfing profile - modes of
operation
15.4 Surfing profile – feature details.............................135
...............................................................133
16 Auto-configuration...........................................136
16.1 AutoDetect.............................................................136
16.1.1 Overview...................................................136
16.1.2 Configuring the Modem to Work with
AutoDetect..............................................................137
16.1.3 AutoDetect Configuration Options..............138
16.1.4 Considerations ............................................140
16.2 Auto-configuration Using ILMI (TR-037) ..............141
- 7 -
16.2.1 Starting Auto- configuration
through Default
....................................................142
16.2.2 Starting auto- configuration at run
time
144
16.2.3 Viewing auto- configured VCs..............144
16.2.4 Best effort configuration.........................145
16.2.5 VCC change and Cold Start Trap........146
16.2.6 Configuration Conflicts...........................146
16.2.7 Configuration mismatch Traps.............146
16.2.8 Constraints ...............................................146
16.2.9 Recommended parameters
required from network
.........................................147
17 Other Device Access Mechanisms.................148
17.1 Simple Network Management Protocol
(SNMP) ..........................................................................148
17.1.1 SNMP Communities...............................148
17.1.2 SNMP Hosts ............................................148
17.1.3 SNMP Traps ............................................149
17.1.4 Providing SNMP Access Across
the Modem
17.2 Web-based Interface ............................................150
............................................................149
17.2.1 Accessing the Web- based
Interface
.................................................................150
17.2.2 Accessing the Quick
Configuration Page
17.2.3 User Instructions .........................................152
.............................................151
17.2.4 Web-based Diagnostics ........................152
17.3 L2 Agent Module...................................................153
18 System Maintenance.......................................155
18.1 Diagnostics............................................................155
18.1.1 Checking IP Connectivity ......................155
18.2 Diagnostics page of the HTTP Agent...................155
18.2.1 Diagnostics - categories........................155
18.3 ATM Traffic Diagnostics........................................156
18.3.1 OAM F5 CC .............................................157
18.3.2 OAM Loopback ...........................................159
18.4 Traps .....................................................................160
- 8 -
18.5 Requesting Status and Statistical
Information.....................................................................161
18.6 Viewing complete system configuration...............163
18.7 Managing User Accounts .....................................164
18.7.1 Creating User Accounts.........................164
18.7.2 Deleting User Accounts ..............................165
18.8 Changing the Login Password .............................165
18.9 Modifying System Parameters .............................166
18.10 Configuring Host Name and Domain
Name on the Modem ....................................................166
18.11 Debugging using Memory Location ...................169
18.12 Serial Port Authentication ...................................169
18.12.1 Using CLI Commands .........................169
19 Shell Tutorial ...................................................171
19.1 Shell Tutorial - Overview.......................................171
19.2 Shell Programming Tutorial..................................172
19.2.1 A First Script.............................................173
19.2.2 Variables...................................................174
19.2.3 IF-ELSE Construct..................................175
19.2.4 Goto...........................................................177
19.2.5 Readout and Search..............................179
19.2.6 Return........................................................182
19.2.7 Keywords..................................................185
19.2.8 Symbols....................................................185
20 Glossary ..........................................................186
1 Introduction
- 9 -
This document contains the following chapters:
Introduction, provides basic information on this
document.
Chapter 2 shows how to set up, configure, and operate
the SAR110.
Chapter 3 gives a brief overview of the main features of
the Command Line Interface (CLI).
Chapter 4 defines and describes the reference unit’s
default configuration, and explains how you can alter the
current configuration using flat files.
Chapter 5 shows how to configure the unit’s interfaces,
and how to change its operating mode.
Chapter 6 explains the CLI commands that can be used
to modify and display DSL-related parameters and statistics.
Chapter 7 shows how to use CLI to configure IP routes.
Chapter 8 shows how to use the Layer 2 Tunneling
protocol (L2TP) to enable the unit to provide VPN services.
Chapter 9 shows how to configure the modem as a DNS
relay server.
Chapter 10 shows how to use CLI to configure the
Dynamic Host Configuration Protocol (DHCP) server and or
client functions.
Chapter 11 describes the configuration options of the
Simple Network Transfer Protocol.
Chapter 12 describes raw filtering, protocol blocking and
the L2 Wall feature.
Chapter 13 details information on configuring NAT,
Firewall and IP Filtering.
Chapter 14 discusses the new Usage Control feature of
the unit.
Chapter 15 discusses the surfing profile feature that
provides application security.
Chapter 16 discussing how auto configuration is possible
with auto detect and TR-37 support.
Chapter 17 discusses mechanisms for management
access to the modem, using SNMP, Web-based interface,
and L2 Agent.
Chapter 18 shows how to perform basic maintenance
functions using CLI.
Chapter 19 helps you understand how to use shell scrips
- 10 -
to your advantage, and provides a tutorial on shell
programming.
A glossary of terms used in this document is also provided.
2 Quick Start
- 11 -
See Setup documention supplied with your router
- 12 -
3 CLI Introduction
See full SAR110 CLI manual.
4 Unit Configuration
This chapter describes the default configuration programmed into
the flash memory, as well as how to modify the configuration after
boot-up.
4.1 Default Configuration
The unit’s default configuration is established by the factory defaults
file named TEFacs.txt. You customize the default configuration by
modifying this file, then creating and loading a new flash image (a
description of this process and sample factory defaults files are
provided in the Image Handling User Manual). At boot-up, the CLI
commands in this file are automatically executed. Once the unit is
operational, its configuration can be changed interactively using CLI,
or in batch mode by script file upload (described in section ).
- 13 -
The following list describes example settings that may
default TEFacs.txt:
CLI user accounts
One superuser account: name = ‘DSL’, password = ‘DSL’
Maximum number of VCs: 8
Maximum number of IP sessions: 192
LAN interfaces
Ethernet port: eth-0, IP address 192.168.7.1, subnet mask 255.255.255.0
DSL — configured for multimode coding standard
WAN interfaces
ATM port: atm-0; maximum VCs allowed = 8
ATM VC: aal5-0, lower interface atm-0, VPI = 0, VCI = 38
PPPoE interface: ppp-0, lower interface aal5-0, default route
PPP user name ‘guest’, password ‘guest’, PAP authentication
RIP — Enabled on PPP interface
DHCP — enabled with one pool for LAN computers:
Pool ID = 1, address range = 192.168.7.3 to 192.168.7.34,
mask 255.255.255.0
NAT — enabled with an NAPT rule for translating
local private addresses to the public address assigned to
ppp-0
Bridging — enabled with ethernet interface defined
as bridgeable
appear in the
- 14 -
IP Filter — enabled, with various rules configured for
high, medium, and low security.
Below lists the CLI commands in the factory defaults file that
configures the unit as a router.
create user name DSL passwd DSL root
modify system logthresh 1
size maxvc 8 max1483vc 8 maxppe 8
modify nbsize maxipsess 192
create ethernet intf ifname eth-0 ip 192.168.7.1
mask 255.255.255.0 inside
modify dsl config gdmt
create atm port ifname atm-0 maxvc 8
create atm trfdesc trfindex 0 NOCLP_NOSCR
create atm vc intf ifname aal5-0 lowif atm-0 vpi
0 vci 38 vcmux
create ppp security ifname ppp-0 CHAP login guest
passwd guest
create ppp intf ifname ppp-0 start lowif aal5-0
droute true PPOA usedhcp false outside usedns
true
create rip intf ifname ppp-0
create dhcp relay intf ifname ppp-0
create nat rule entry ruleid 1 napt
modify nat global enable
modify ipf global pubdefact accept
modify ipf global pvtdefact deny
modify ipf global dmzdefact accept
create ipf rule entry ruleid 10 dir in act deny
destaddr bcast seclevel high
create ipf rule entry ruleid 20 dir in act deny
destaddr eq 255.255.255.255 seclevel high
create ipf rule entry ruleid 30 ifname private
dir in act accept storestate enable seclevel high
medium low
- 15 -
create ipf rule entry ruleid 40 ifname private
dir out srcaddr self act accept storestate enable
seclevel high medium low
create ipf rule entry ruleid 50 ifname private
dir out inifname dmz transprot eq udp destport eq
num 53 act accept storestate enable seclevel high
medium low
create ipf rule entry ruleid 60 ifname private
dir out inifname dmz transprot eq tcp destport eq
num 53 act accept storestate enable seclevel high
medium low
create ipf rule entry ruleid 70 ifname private
dir out inifname dmz transprot eq tcp destport eq
num 25 act accept storestate enable seclevel high
medium low
create ipf rule entry ruleid 80 ifname private
dir out inifname dmz transprot eq tcp destport eq
num 110 act accept storestate enable seclevel
high medium low
create ipf rule entry ruleid 90 ifname private
dir out inifname dmz transprot eq tcp destport eq
num 21 act accept storestate enable seclevel
medium low
create ipf rule entry ruleid 100 ifname private
dir out inifname dmz transprot eq tcp destport eq
num 80 act accept storestate enable seclevel
medium low
create ipf rule entry ruleid 110 ifname private
dir out inifname dmz transprot eq tcp destport eq
num 23 act accept storestate enable seclevel low
create ipf rule entry ruleid 120 ifname private
dir out inifname dmz transprot eq icmp act accept
storestate enable seclevel low
create ipf rule entry ruleid 130 ifname dmz dir
out inifname private transprot eq tcp destport eq
num 23 act deny seclevel high
create ipf rule entry ruleid 140 ifname dmz dir
out inifname public transprot eq udp destport eq
num 53 act deny seclevel high
create ipf rule entry ruleid 150 ifname dmz dir
out inifname public transprot eq tcp destport eq
num 53 act deny seclevel high
create ipf rule entry ruleid 160 ifname dmz dir
out inifname public transprot eq tcp destport eq
num 21 act deny seclevel high
- 16 -
create ipf rule entry ruleid 170 ifname dmz dir
out inifname public transprot eq tcp destport eq
num 23 act deny seclevel high medium low
create ipf rule entry ruleid 180 ifname dmz dir
out inifname public transprot eq icmp act deny
seclevel high medium
create ipf rule entry ruleid 190 ifname public
dir out transprot eq tcp destport eq num 23 act
deny seclevel high
create ipf rule entry ruleid 200 ifname public
dir out srcaddr self act accept storestate enable
seclevel high medium low
create ipf rule entry ruleid 210 ifname public
dir in act deny destaddr bcast seclevel medium
create ipf rule entry ruleid 220 ifname public
dir in act deny destaddr eq 255.255.255.255
seclevel medium
create ipf rule entry ruleid 230 ifname public
dir in act deny transprot eq udp destport eq num
7 seclevel high medium
create ipf rule entry ruleid 240 ifname public
dir in act deny transprot eq udp destport eq num
9 seclevel high medium
create ipf rule entry ruleid 250 ifname public
dir in act deny transprot eq udp destport eq num
19 seclevel high medium
create ipf rule entry ruleid 260 ifname public
dir in destaddr self transprot eq tcp destport eq
num 80 act deny seclevel high medium low
create ipf rule entry ruleid 270 ifname public
dir in destaddr self transprot eq udp destport eq
num 53 act deny seclevel high
create ipf rule entry ruleid 280 ifname public
dir in destaddr self transprot eq tcp destport eq
num 53 act deny seclevel high
create ipf rule entry ruleid 290 ifname public
dir in destaddr self transprot eq tcp destport eq
num 21 act deny seclevel high medium low
create ipf rule entry ruleid 300 ifname public
dir in destaddr self transprot eq tcp destport eq
num 23 act deny seclevel high medium low
create ipf rule entry ruleid 310 ifname public
dir in destaddr self transprot eq icmp act deny
seclevel high medium
create ipf rule entry ruleid 320 ifname public
dir in destaddr self transprot eq udp destport eq
- 17 -
num 53 act accept storestate enable seclevel
medium low
create ipf rule entry ruleid 330 ifname public
dir in destaddr self transprot eq tcp destport eq
num 53 act accept storestate enable seclevel
medium low
create ipf rule entry ruleid 340 ifname public
dir in act deny isipopt yes seclevel high
create ipf rule entry ruleid 350 ifname public
dir in act deny isfrag yes seclevel high
create ipf rule entry ruleid 360 ifname dmz dir
in destaddr self transprot eq tcp destport eq num
80 act deny seclevel high medium
create ipf rule entry ruleid 370 ifname dmz dir
in destaddr self transprot eq tcp destport eq num
21 act deny seclevel high medium
create ipf rule entry ruleid 380 ifname dmz dir
in destaddr self transprot eq tcp destport eq num
23 act deny seclevel high medium
4.1.1
create ipf rule entry ruleid 390 ifname dmz dir
in act accept storestate enable seclevel high
medium low
end
For detailed information on all CLI commands (except modify
nbsize and size, which are described in section ), see the
SAR110CLI Manual.
System Sizing Parameters
The first two lines of the factory defaults file specify “sizing”
parameters. These parameters set upper limits on some of the basic
elements of the system, e.g., the number of VCs or IP sessions.
The sizing parameters are specified using the size and modify
nbsize commands. While these commands are available in CLI,
they are “hidden” from the user; they do not appear in the output of
the help command and are otherwise undocumented. This is
because these commands are only for OEM use; end users should
have no knowledge of these commands.
Because parts of the system, the size and modify nbsize commands must come at the beginning of the
factory defaults file.
- 18 -
The size command
This command sets upper limits on certain system properties. Its
parameters are:
maxvc and max1483vc – Maximum number of VCs
(both: default 2)
maxppe – Maximum number of PPPoE sessions (default
1)
maxmac – Maximum number of MAC addresses that are
learned by the bridge forwarding table (default 256)
maxpfrawrule – Maximum number of raw filter rules
(default 8)
maxpfrawsubrule – Maximum number of raw filter
subrules (default 8)
maxipfrule - Maximum number of IP filter rules
(default 8)
You should set these parameters in accordance with the anticipated
needs of a typical end user of your product.
The modify nbsize command
This command is used to modify
the maximum number of IP sessions that can be
active at any given time the TELNET server port
the FTP server port
the HTTP server port.
An IP session is a connection between two applications, one running on one of your LAN’s hosts
and the other running on a host on the WAN, e.g., a connection between a host on your LAN
and an Internet web site.
To see the maximum number of IP sessions currently configured or port on which
TELNET, HTTP, FTP servers are running, enter:
$ get nbsize
To limit the maximum number of active IP sessions to 256, enter:
$ modify nbsize maxipsess 256
To modify the TELNET server port to 9000, enter:
$ modify nbsize telnetport 8000
$ modify nbsize ftpport 9000
To modify the FTP server port to 1000, enter:
To modify the HTTP server port to 8000, enter:
$ modify nbsize httpport 10000
The modify nbsize command does not take effect until the next
system reboot occurs. To initiate a system reboot, enter the
following pair of commands:
$ commit
$ reboot last
4.2 Modifying the Unit’s MAC Address and Serial Number
When you build a software image, it is coded with a default MAC
address and serial number. You can change this data on a particular
unit using the CLI.
- 19 -
Serializing an image
To change the MAC address and serial number on a board, enter:
do serialize AA-BB-CC-DD-FF-12 111122233334444
The MAC address is a 12-digit hexadecimal number, which can be entered with dashes, as
shown, or as a single string. The same MAC address applies to all the unit’s LAN-side
interfaces (e.g., eth-0 and usb-0).
The serial number can contain up to 24 alphanumeric characters.
4.3 Modifying the Unit Configuration via Script Files
Besides CLI, another way of modifying the unit’s current
configuration is to use the script file upload method. Unlike CLI, this
method does not require a serial port. This method is meant to be
used primarily by ISPs, as a quick and easy way to update the
configuration of their customers’ boxes.
The script file is uploaded to the unit’s IP address via ftp or tftp.
Once the script file has been uploaded to the unit, the file may be
executed immediately or at a later time, depending on the
autoupdate flag (see note below). If the autoupdate flag is set to
true, the CLI commands in the configuration file are executed
immediately. If however, the autoupdate flag is set to false, then the
CLI commands are held in RAM and are not executed until the
apply command is issued via CLI.
- 20 -
Please refer to section in this document for details on CLI Scripting and Script Programming.
The autoupdate flag indicates whether configuration files will be executed immediately or only upon
issue of an apply command. For more details on the autoupdate flag and the commands related to its use, see
the CLI Reference Manual.
4.3.1 Notes on Using Script File Configuration
Important points concerning script file configuration include:
The script file can only be used to change the
current configuration. It cannot be used to update or
replace the factory defaults file (default configuration
file) in the flash image.
In order to modify an existing interface, it may be
necessary for the script file to delete the interface first,
and then recreate it.
In order for the new configuration to be saved to
flash memory, the script file must contain the commands
commit and reboot.
4.4 Managing Configuration Changes
Whenever you change the unit's configuration and do a commit, the
changes are saved into the flash. Doing a reboot after a commit
reboots the unit with the latest changes. The reboot command
supports the following options.
last: to reboot the unit using the latest saved
configuration use the reboot last command.
backup: to reboot the unit using the configuration of the
operation that was committed before the last commit
operation, use the reboot backup command.
Default: to reboot the unit using the default
configuration, use the reboot default command.
Clean: to reboot the unit with zero configuration, use the
reboot clean command. This assumes that the user has a
serial port connected to the unit. This is so, because in a
clean configuration even Ethernet is not configured.
Minimum - to reboot the unit with only the size (with all
default parameters), create ethernet intf and create
user commands executed, use the reboot minimum
command.
The Ethernet interface and the user are created with the parameters used in the default configuration. The
minimum configuration aims to configure the unit so as to allow a telnet to it from the LAN.
Note that when you reboot with a given configuration, say reboot clean, the other configurations are not
lost. To go back to the last saved configuration after you have done a reboot clean, just do a reboot last.
4.5 Using FTP/TFTP to Upgrade and Retrieve the Flash Image
You can use FTP/TFTP to upload/download code to/from a unit’s
flash memory, assuming that a functioning image is already loaded
on the unit. Uploads and downloads can be performed from a
computer connected to the device through an IP-enabled interface,
such as its LAN interface.
Uploading to the unit enables you to upgrade the image as you
obtain new software releases from your router supplier.
Downloading from the unit to your PC enables you to store code and
configuration files before overwriting them with new code.
You can transfer an entire or a partial flash image. The filename
must be one of those described in Table below.
Files Used with TFTP Upload/Download
- 21 -
Filename Description
TEImage.bin
TEPatch.bin
Compressed file containing patch code representing
one or more of the code blocks (for example, the DSL
firmware and application code blocks). You can use
TEPatch.bin to upgrade several blocks at a time,
without overwriting all blocks. See the Image Handling
User’s Manual for more information about the content
of TEPatch.bin and how to modify it to create the
To upload a file to the unit, you can type a command such as the
following at a DOS prompt on your PC (replace the IP address
shown with the LAN port port IP address on the unit):
TFTP -i 192.168.1.1 put TEImage.bin
Reboot the unit when the upload is complete. See the section
Recovering from a Failed Upgrade if the upload is not
successful.
Entire binary image.
desired patch file.
Uploading Example
Downloading Example
To download a file, such as the configuration file, use a command
such as the following:
- 22 -
TFTP -i 192.168.1.1 get TECfg.bin
If you later change the unit’s configuration and find that it the device
is not working properly, you can upload this file to restore a knowngood configuration.
4.5.1
Data configuration Upgrade
Data configuration upgrade using TEpatch.bin will be required if you
have committed certain CLI commands in a previous release, and
want the same commands to work in an upgraded release.
For a list of supported releases, please refer to the relevant release notes. Normally, if the board fails to
come up with the committed configuration, it reboots and tries to come up with the default configuration.
But, while upgrading only a best effort attempt is made to recreate the older configuration. That is, errors
are ignored. Hence, always check, after an upgrade, whether the new configuration appears as desired.
4.5.2 Recovering from a Failed Upgrade
If the upgrade process fails while uploading the application code file,
(for example, your FTP/TFTP connection is lost during the process),
or if for any reason the new application code fails to boot after
loading, the device may boot to a special TFTP mode that enables
you to continue the upgrade. This procedure enables you avoid
having to re-flash the device with an entire image using a serial
connection to the flash header.
This TFTP server mode is invoked automatically when the
application checksum test fails during boot-up. If you have a serial
connection to the board, the following message will display on the
terminal:
Testing Application Checksum ... Failed
TFTP Server Started ... Please upload flash image to 192.168.1.1
In addition, all the software controlled test LEDs will blink at about
twice per second. This indicates that the application code has not
been loaded and all subsequent routine boot processes were
aborted. The unit’s built-in TFTP server is invoked and an IPenabled Ethernet interface is set up with the following properties:
IP Address: 192.168.1.1
Mask: 255.255.255.0
To continue the image upgrade via TFTP, verify that the IP
properties on the PC assign it to the same subnet as this Ethernet
interface. Then, upload the new application code file via TFTP (FTP
is not supported in this mode). The LEDs will blink rapidly as the
image is uploaded.
- 23 -
You can also access this mode as a shortcut if you want to boot a
board solely to perform an image upgrade via TFTP. To force a unit
into this mode, begin booting the board and monitor the boot
messages on your PC. Before “Testing Application Checksum.....”
displays (or during), type “tao” and press <Backspace>. The
ordinary boot process will be aborted and the board will boot in the
TFTP mode as described above.
- 24 -
5 Interfaces and Operating Mode
This chapter briefly discusses the unit’s interfaces, and explains how
to create and configure the interfaces needed for the bridge and
router operating modes, as well as how to select each mode.
5.1 Interfaces – Overview
At the physical level, the unit provides WAN-LAN connectivity
through its physical WAN, and LAN ports. At the logical level, the
connection can be made in a number of ways, depending on the
virtual interfaces configured on top of the physical ports and how
these interfaces are connected.
Figure below shows the virtual interfaces you can define on each
physical port
Virtual Ethernet
interfaces
USB
interface
usb-0
USB Port
Ethernet
interface
LAN Port
In order to create an interface, you first create all the interfaces
below it, starting at the lowest interface. For instance, to create a
PPP interface, you first create the ATM port, then a VC.
5.2 Configuring the Ethernet Port
The Ethernet port is a physical port on that enables you to connect
the unit to a computer or Ethernet network. You can configure only
one physical Ethernet port, eth-0; however, you can define multiple
virtual ethernet interfaces over this port, as described in section on
page -27. This port can be created with or without an IP address (no
IP address is required if it is a bridge port).
veth-0
eth-0
bridge or routerrouter
PPP*
interfaces
ppp-0 eoa-0
VCs
ATM
interface
* Per VC: 1 PPPoA, or 1 or more PPPoE
aal5-0
atm-0
WAN/DSL Port
EoA
interfaces
Virtual
Interfaces
Physical
Interfaces
When creating the Ethernet port, you may need to consider the
following:
IP address and subnet – To connect the unit to an
existing LAN whose subnet differs from the Ethernet
port’s default subnet (192.168.1.1, mask 255.255.255.0),
assign the Ethernet port an IP address in the same
subnet as your LAN. (Alternatively, you would have to
assign to each LAN computer a new IP address and
mask that places it in the same subnet as the Ethernet
port.)
Commands related to the Ethernet port are briefly described below.
For a complete listing of these commands, including parameters and default values, refer to the
SAR110CLI Manual
Creating the Ethernet port
To create the Ethernet port eth-0, enter:
- 25 -
$ create ethernet intf ifname eth-0 ip 192.168.1.1 mask 255.255.255.0
To display information on the Ethernet port, enter:
$ get ethernet intf
Setting Interface security type
You can set the interface security type to either pvt, pub, dmz, while creating the Ethernet
interface.
$ create ethernet intf ifname eth-0 ip 192.168.1.1 mask 255.255.255.0
ifsectype private
Changing the Ethernet port’s IP address
To change the Ethernet port’s IP address to 10.1.1.1 with mask 255.0.0.0, enter:
$ modify ethernet intf ifname eth-0 ip 10.1.1.1 mask 255.0.0.0
If you are connecting the unit to an existing LAN, and if the Ethernet port’s default subnet—IP
address 192.168.1.1, mask 255.255.255.0—is different from the LAN’s subnet, change the
Ethernet port’s IP address, as follows:
- 26 -
Set any LAN host’s IP address to 192.168.1.3, mask 255.255.255.0.
Using this host, Telnet to 192.168.1.1 and log in to the system.
Enter the modify ethernet intf command (described above) to change the IP address
and/or mask of the eth-0 interface.
Enter commit to save the changes.
Change the host’s IP address and/or mask to the original value(s).
Reboot the host.
If you are connecting the unit to a new LAN, i.e., one whose subnet is not yet determined, you
do not need to change the Ethernet port’s IP address. Instead, assign each LAN host an IP
address from the Ethernet port’s default subnet, i.e., 192.168.1.2, 192.168.1.3, etc. Or,
configure each PC as a DHCP client so that it will be assigned an appropriate address from the
unit’s default DHCP pool (assuming that this pool has been configured).
Using a LAN DHCP server to assign the port’s IP address
To reconfigure the unit to get its LAN IP address from a DHCP server running on a LAN
host, enter:
$ modify ethernet intf ifname eth-0 ip 0.0.0.0 mask 0.0.0.0 usedhcp
true
Both the IP address and mask must be set to 0.0.0.0. Setting usedhcp to true
(default=false) invokes a DHCP client to obtain an IP address for this interface from a DHCP
server.
The get ethernet intf command will show the IP address as
0.0.0.0 , while the get ip address command will show
the address obtained from the dhcp server.
If you are changing the IP address of the Ethernet address over a telnet or HTTP connection, the
connection will be lost once the address is modified.
Displaying the Ethernet port’s IP address
To see the current configuration of the Ethernet interface, enter:
$ get ethernet intf ifname eth-0
If the displayed IP address is 0.0.0.0, the unit has been configured to get its LAN IP address
from a LAN DHCP server (as explained in “Using a LAN DHCP server to assign the port’s IP
address” in this section). To see the actual IP address, use the get ip address command.
To see the IP address obtained from a DHCP server (plus the IP addresses for all
configured IP-enabled interfaces), enter:
$ get ip address
Deleting an Ethernet Interface
To delete an Ethernet interface, enter:
$ delete ethernet intf ifname eth-0
5.3 Configuring Virtual Ethernet Interfaces
Virtual Ethernet interfaces give the impression of multiple subnets on
a single physical subnet, by dividing your LAN hosts into groups,
each with its own subnet mask. You can up to two virtual Ethernet
interfaces, named veth-0 and veth-1, over the single physical
Ethernet interface.
- 27 -
To create a virtual interface, enter:
$ create ethernet intf ifname veth-0 ip 172.25.1.1 mask 255.255.255.0
phyif eth-0
The phyif parameter indicates that the virtual interface veth-0 actually sits on the physical
interface eth-0. Unlike the physical Ethernet interface, the virtual Ethernet interfaces can be
deleted using the delete ethernet intf command.
To list the virtual Ethernet interfaces (as well as physical Ethernet interfaces), enter:
$ get ethernet intf
5.4 Configuring the WAN ATM Port
Data traffic is carried over the DSL cable in ATM cells. To enable the
DSL port (i.e., the WAN port) to carry ATM cells, you need to
configure an ATM port on the unit. You can configure only one ATM
port, atm-0.
When creating the ATM port, consider the following:
ATM priority scheduling – The relative priorities of
the ATM service categories (described in section ). By
default, the priorities are in this order - CBR, RTVBR,
NRTVBR, GFR, UBR.
- 28 -
Commands related to creating the ATM port are briefly described
below.
For a complete listing of these commands, including parameters and default values, refer to the CLI
Reference Manual.
Creating the ATM port
To create the ATM port atm-0, enter:
$ create atm port ifname atm-0
To display information on the ATM port, enter:
$ get atm port
Setting ATM service category priorities
The
create atm port command is also used to assign relative
priorities to ATM service categories (described in section ).
To give the UBR service category priority over GFR (GFR has higher priority by default),
enter:
$ create atm port ifname atm-0 ubrpriority 2 gfrpriority 1
nrtvbrpriority 3 rtvbrpriority 4 cbrpriority 5
5.5 Configuring Permanent Virtual Circuits
Virtual Circuits (VCs), named aal5-0, aal5-1, etc., sit on top of the
ATM port. Each VC has an associated Virtual Path Identifier (VPI)
and Virtual Circuit Identifier (VCI) that identify a data path through
the ATM network.
Besides the VPI and VCI, you should also consider the following
when creating a VC:
AAL5 data encapsulation – VC-muxing, LLC-muxing
(default), or none.
Service category – Unspecified Bit Rate (UBR)
(default) or Guaranteed Frame Rate (GFR), Non RealTime Variable Bit Rate (NRTVBR), Real-Time Variable Bit
Rate (RTVBR), or Constant Bit Rate (CBR).
A UBR traffic descriptor usually exists as part of the default configuration. So a UBR
VC can be created right away. For any other type of VC - GFR, NRTVBR, RTVBR, or
CBR, you must also create a traffic descriptor of the same category if you have not
yet done so.
Priority – The relative transmission priority of the VC
vs. other VCs in the same service category.
The commands used to create VCs statically are briefly described
below. VCs can also be created automatically using the AutoDetect
feature, which is described in detail in Chapter .
For a complete listing of these commands, including parameters and default values, refer to the CLI
Reference Manual.
Creating a VC
To create a VC-muxed VC named aal5-0 with VPI 0 and VCI 35, enter:
$ create atm vc intf ifname aal5-0 vpi 0 vci 35 vcmux lowif atm-0
- 29 -
This creates VC aal5-0, with VPI 0 and VCI 35, on top of ATM port atm- 0. Since the default
values for all other parameters are used, the traffic descriptor (described in section ) is 0, and
thus the ATM service category is UBR.
The number of VCs you can create is limited by the maxvc parameter in the create atm port command
and the maxvc and max1483vc parameters in the size command. All three parameters are typically set to the
same value.
To see a list of all currently configured VCs, enter:
$ get atm vc intf
5.5.1 AAL5 Data Encapsulation Method
The unit supports two data encapsulation methods: VC mux and
LLC mux. Each allows you to create different types of interfaces on
the VC. A third mode with no encapsulation is also supported.
VC-muxed VC
The allowed interfaces are:
EoA
PPPoA
IPoA
EoA + PPPoE
EoA + bridge port over EoA
EoA + bridge port over EoA + PPPoE
- 30 -
LLC-muxed VC
The allowed interfaces are:
EoA 1
PPPoE
PPPoA
IPoA
EoA + PPPoE
EoA + PPPoE + PPPoA
EoA + PPPoE + IPoA
PPPoA + IPoA
EoA + IPoA
EoA + bridge port over EoA
EoA + bridge port over EoA + PPPoE
EoA + PPPoE + PPPoA + bridge port over EoA 2
EoA + bridge port over EoA + PPPoE + IPoA 3
5.5.2
EoA + PPPoA + IPoA
EoA + PPPoE + PPPoA + IPoA
ATM Service Categories: UBR, CBR, GFR, NRTVBR and RTVBR
Every VC has an associated ATM service category. The following
service categories can be defined, based on the Quality of Service
(QoS) provided:
Unspecified Bit Rate (UBR) – ATM provides no rate
guarantee; data is transmitted on the VC only as and when
bandwidth is available.
Guaranteed Frame Rate (GFR) – ATM guarantees a
minimum bandwidth, called the Minimum Cell Rate (MCR),
for the VC. Depending on available bandwidth, GFR also
provides a maximum bandwidth, called the Peak Cell Rate
(PCR).
Non Real-Time Variable Bit Rate (NRTVBR) - ATM
guarantees a Sustained Cell Rate (SCR) and allows the user
to go up to a Peak Cell Rate (PCR) for a duration derived
from the Maximum Burst Size (MBS). This category is used
by non-real time applications.
Real-Time Variable Bit Rate (RTVBR) - ATM guarantees
a Sustained Cell Rate (SCR) and allows the user to go up to
a Peak Cell Rate (PCR) for a duration derived from the
Maximum Burst Size (MBS). This category is used by real
1 if the a5maxproto parameter in create atm vc command is >= 1
2 if the a5maxproto parameter in create atm vc command is >= 2
3 if the a5maxproto parameter in create atm vc command is >= 3
time applications like voice and video.
Constant Bit Rate (CBR) - ATM guarantees bandwidth
up to a Peak Cell Rate (PCR).
You specify a VC’s service category when you create the VC, using
a traffic descriptor. Traffic descriptors are explained in detail in
section .
5.5.2.1 UBR, GFR, and CBR, NRTVBR and RTVBR Transmission Priorities
Each service category’s transmission priority can be set using the
create atm port command’s ubrpriority, gfrpriority,
nrtvbrpriority, rtvbrpriority, and cbrpriority
parameters. The three parameters must have different values (by
default, cbrpriority is 5 (highest), rtvbrpriority is 4,
nrtvbrpriority is 3, gfrpriority is 2, and ubrpriority
is 1).
When creating the ATM port, the relative priorities of the ATM
service categories are, by default: CBR, RTVBR, NRTVBR, GFR,
UBR.
- 31 -
5.5.2.2 Transmission Priorities of VCs
You can also assign relative priorities to the VCs within each service
category, using the vcweight parameter in the create atm vc
intf command (for details, refer to the CLI Reference Manual). The
Weighted Fair Queuing (WFQ) algorithm is used to ensure fair and
efficient bandwidth allocation for both service categories.
5.5.2.3 Traffic Descriptors
A VC’s service category is assigned indirectly, using a traffic
descriptor. A traffic descriptor defines a set of ATM traffic-related
properties, the most important property being the service category,
i.e., UBR, GFR, , NRTVBR, RTVBR or CBR.
When you create a VC using the create atm vc intf
command, you define its service category using the trfdesc
parameter. The default value of this parameter is 0, corresponding
to the default traffic descriptor.
The default configuration provides an initial traffic descriptor with
index 0. This default traffic descriptor specifies the UBR service
category.
To create a UBR VC, omit the trfdesc parameter when creating
the VC. To create a GFR, NRTVBR, VBR or CBR VC, you must
create a traffic descriptor of the same category.
- 32 -
Creating a GFR traffic descriptor
To create traffic descriptor 1, for GFR VCs with MCR=50 and PCR=150:
$ create atm trfdesc trfindx 1 GFR CLP_NOTAG_MCR mcr 50 pcr 150
The CLP_NOTAG_MCR flag indicates that if PCR is exceeded, the VC will drop extra cells
without tagging the Cell Loss Priority (CLP) bit.
To create a VC using the preceding traffic descriptor:
$ create atm vc intf ifname aal5-0 trfindx 2 vpi 5 vci 50 lowif atm-0
Creating a VBR Traffic Descriptor
To create traffic descriptor 3, for RTVBR VCs with PCR=150, SCR=75 and MBS=15:
$ create atm trfdesc trfindx 3 RTVBR NOCLP_SCR pcr 150 scr 75 mbs 15
The NOCLP_SCR flag indicates that the traffic parameters are valid for the aggregate flow and
that an SCR is required.
To create a VC using the preceding traffic descriptor:
$ create atm vc intf ifname aal5-2 trfindx 3 vpi 5 vci 52 lowif atm-0
Creating a CBR Traffic Descriptor
To create traffic descriptor 2, for CBR VCs with PCR=150:
$ create atm trfdesc trfindx 2 CBR NOCLP_NOSCR pcr 150
The NOCLP_NOSCR flag indicates that the traffic parameters are valid for the aggregate flow
and that no Sustained Cell Rate is required.
To create a VC using the preceding traffic descriptor:
$ create atm vc intf ifname aal5-1 trfindx 2 vpi 5 vci 51 lowif atm-0
To display all currently defined traffic descriptors, enter:
$ get atm trfdesc
Creating a RTVBR traffic descriptor:
To create traffic descriptor 3, for RTVBR VCs with PCR=150, SCR=75 and MBS=15:
$ create atm trfdesc trfindx 3 RTVBR NOCLP_SCR pcr 150 scr 75 mbs 15
The NOCLP_SCR flag indicates that the traffic parameters are valid for the aggregate flow and
that an SCR is required.
To create a VC using the preceding traffic descriptor:
$ create atm vc intf ifname aal5-2 trfindx 3 vpi 5 vci 52 lowif atm-0
5.6 Configuring Switched Virtual Circuits (SVCs)
The modem supports Switched Virtual Circuits (SVCs) created
through UNI version 3.1 or 4.0 signalling. To create an SVC, first
create a signaling channel for UNI. This is simply a PVC which
usually has the VPI = 0 and VCI = 5.
- 33 -
Create PVC for UNI signaling
$ create atm vc intf ifname aal5-0 vpi 0 vci 5 none
Here, none specifies the encapsulation as none.
To configure UNI signaling to run on this VC, give
the following command:
$ create atm uni ifname aal5-0 nplan atmes saddr
0x47000580ffde0000000000010500000000000000 version uni40
The parameter saddr is the ATM address of the modem, while
nplan specifies this address to be an ATM End System type of
address. With ATMES, the address must be specified as a string of
hex bytes. Conversely, the nplan could be specified as ISDN, in
which case the address should be given as a string of decimal digits.
The version parameter specifies the UNI signaling version, which
here, is 4.0. The default version is 3.1.
Configuring UNI
Signaling ATM Adaptation Layer (SAAL) is a layer in the SVC
signaling stack that provides reliable transfer of signaling messages
between peer UNI entities. If the signaling channel with the remote
host is established, the SAAL status is set to UP, and the following
trap is generated.
- 34 -
STATUS ALARM : SAAL UP
Otherwise, the SAAL status is DOWN. SAAL may come up later
when the signaling channel gets established with the remote host.
The following trap is generated when SAAL goes down:
STATUS ALARM : SAAL DOWN
You can check the SAAL status at any time, using the command:
get atm uni ifname aal5-0
With UNI configured, you can now initiate the creation of an SVC by giving the following
command:
Creating an SVC
$ create atm svccfg ifname aal5-1 nplan atmes daddr
0x39000760ff890000000000011900000000000000
This tells the modem to establish an SVC with the host having the
ATMES address specified by daddr. The ifname parameter
indicates that the created SVC should be identified by the name
aal5-1. Other parameters in the command (assumed default here)
specify what characteristics you want for the SVC: the traffic
descriptor, multiplexing type and so on, as with a PVC. After the
command is executed, establishing the SVC with the remote host
depends on the Signaling ATM Adaptation Layer (SAAL) status.
If SAAL status is UP the modem negotiates SVC parameters with
the remote host by exchanging signaling messages. Once the VC is
established the following trap is generated:
STATUS ALARM : ATM VC Up : Interface - aal5-1, PortId = 7, Vpi = 0,
Vci = 33
This indicates that the negotiated SVC has the VPI = 0 and VCI = 33
and has been created with the interface name aal5-1 on the modem.
Giving the get atm vc intf command will now show this new
VC as well. The allocated VPI and VCI values can also be seen
using the get atm svccfg command.
If SAAL status is DOWN, the modem does not exchange signaling
messages with the remote host. So, SVC is not established at this
point in time. In future, whenever SAAL comes up, the SVC gets
established on its own.
- 35 -
To check out, at any time, if an SVC is established or not, its VPI
and VCI value should be checked by issuing the "get atm
svccfg" command. If it is not established, then, you see the printed
value as "-" . Otherwise, the valid numerical value is printed.
All SVCs are disconnected when SAAL goes down. So, VPI and VCI value become unassigned for these
VCs. Whenever SAAL comes up, the SVCs get established on their own.
To delete an SVC, use the delete atm svccfg command.
SVC configuration can be specified in the tefacs.txt file (default configuration). Also, SVC configuration is
committed when the commit command is invoked. SVC configuration is retained across boots.
Starting and Stopping an SVC
You can force SVC establishment or disconnection using the start
and stop commands, discussed below.
To start/stop an SVC by exchanging appropriate signaling messages with the network
side, enter:
modify atm svccfg ifname aal5-1 start
modify atm svccfg ifname aal5-1 stop
Start is particularly useful when an SVC is disconnected by the
network side. If an upper layer protocol such as PPPOE is bound
over this VC, and you want to re-establish the SVC, you can do so
using the start command, without any configuration overheads. If
you specify start command for an already established SVC, or a
stop command for an already disconnected SVC, it is ignored.
The trap message “ATM VC Up” displays after the SVC is
established. The trap message “ATM VC down” displays when the
SVC is disconnected.
To delete an SVC, enter
delete atm svccfg ifname aal5-1
Deleting an SVC
- 36 -
SVC deletion fails if an upper layer, such as PPPoE, is bound over the VC.
To verify SVC deletion, use the get atm svccfg command. It
should not show an entry corresponding to the specified interface
name.
To delete a configured UNI signaling channel, enter:
delete atm uni ifname aal5-0
To verify UNI deletion, use the get atm uni ifname aal5-0
command. It should not show any entry corresponding to the
specified interface name.
Deleting PVC for UNI signaling
Deleting UNI
To delete the PVC for UNI signaling, enter:
delete atm vc intf ifname aal5-0
5.7 Configuring PPP Interfaces
The unit supports two types of PPP interfaces—PPPoA and PPPoE.
For authentication, both Password Authentication Protocol (PAP)
and Challenge Handshake Authentication Protocol (CHAP) are
supported. Each PPP interface is IP-enabled, i.e., it has an
associated IP address. You may specify this IP address in the
create ppp intf command, if the address is allocated statically
by the ISP. If the IP address is obtained dynamically using IPCP, do
not specify it as part of the command.
To use the peer IP address as the gateway address, enter:
$ create ppp intf ifname ppp-0 start lowif aal5-0 PPOA droute true
usedns true usegw remote
In this case, the PPP stack adds the peer IP address obtained
through IPCP, as the gateway address in default route.
The IP address passed in IPCP negotiation may also be the same as the PPP interface IP address.
Alternately, the peer PPP may not send the gateway address in IPCP negotiation. In either of the two
cases, the gateway address in the default route will be the same as the self IP address. In all other cases,
the gateway address in the default route will be the one sent from the peer PPP.
- 37 -
To use the self IP address as the gateway address, enter:
$ create ppp intf ifname ppp-0 start lowif aal5-0 PPOE droute true
usedns true usegw local
In this case, the PPP stack will always ignore the peer IP address
obtained through IPCP negotiation from the other side, and will
always use its own IP address as the gateway address in the default
route.
If a PPP interface is to be used as the default route, set the droute parameter to true in the create ppp
intf command.
PPP interfaces are named ppp-0, ppp-1, etc. To create a PPP
interface:
Create a login name and password for the PPP interface.
Create the PPPoE or PPPoA interface itself.
The commands related to both of these steps are briefly discussed
in sections through .
For a complete listing of these commands, including parameters and default values, refer to the CLI Reference
Manual.
5.7.1 Creating a Login Name and Password for a PPP Interface
To create the login name and password for the ppp-0 interface, enter:
$ create ppp security ifname ppp-0 pap login user1 passwd paswd1
This creates the login user1 and password paswd1 for PPP interface ppp-0 and configures it to
use PAP authentication. Typically, each PPP interface has a unique login and password
created by this command.
If you create a PPP interface without issuing this command, the interface will use the login and password
of the PPP security default entry. To create this default entry, either include the command create ppp
security ifname all in the factory defaults file, or enter this command at the CLI prompt, specifying the login
and password parameters as shown above.
To show the currently configured PPP user names, enter:
$ get ppp security
To change the password for the ppp-0 interface, enter:
$ modify ppp security ifname ppp-0 passwd newpwd
The new password newpwd will not take effect until a new PPP session is established, either
by rebooting the unit, or by stopping and starting the session using the modify ppp intf
command.
- 38 -
5.7.2 PPPoE Interfaces
Use the following commands to create PPPoE interfaces.
For a complete listing of these commands, including parameters and default values, refer to the CLI
Reference Manual.
Creating a PPPoE interface with a fixed IP address
To configure a PPPoE interface with a fixed IP address, enter:
$ create ppp intf ifname ppp-0 lowif aal5-0 ip 202.1.1.1 ppoe sname
internet
This configures PPPoE interface ppp-0 to run on VC aal5-0, using the service name internet
and the fixed address 202.1.1.1. (The service name identifies a paid service subscribed to by
the end user.)
You must supply the sname parameter for a PPPoE interface. The ISP uses this to identify the type of
connection to use for the interface.
Creating a PPPoE interface with a dynamic IP address
Enter the same command as above, but without the IP address:
$ create ppp intf ifname ppp-0 lowif aal5-0 ppoe sname internet
To retrieve additional configuration information from the ISP’s DHCP server, use the
usedhcp parameter. To do so, set the usedhcp parameter to true (this parameter is
normally set to false).
5.7.2.1 Access Concentrator Selection
ISPs use Access Concentrators (ACs) to handle PPPoE
connections from end users. Although an AC can handle more than
one connection at a time, ISPs need multiple ACs to handle large
numbers of subscribers. As a result, more than one AC may reply to
a connection request. By default, the unit accepts only the first
response from any AC (“first-come” policy).
An ISP may, however, require the user to accept responses only
from a specific AC for a specific service; e.g., the user must use the
AC ac-i to access the internet service. In this case, a service-to-AC-
name mapping must be created, and the AC selection policy must
be changed using the modify ppe cfg command.
Creating service-to-AC-name mapping
To create a mapping between the service called internet and AC ac-i:
$ create ppe pconf srvname internet acname ac-i
Changing the AC selection policy
To configure the unit to use service-to-AC-name mapping, enter:
$ modify ppe cfg serv-to-ac
When a subsequent connection is made for a specific service, the unit will only accept
responses from the AC specified in the mapping.
Listing the available ACs
To list an ISP’s ACs and the services supported by each AC, enter:
- 39 -
$ get ppe acserv ifname aal5-0
5.7.3
PPPoA Interfaces
Use the following commands to create PPPoA interfaces.
For a complete listing of these commands, including parameters and default values, refer to the CLI
Reference Manual.
Creating a PPPoA interface with a fixed IP address
To create a PPPoA interface with a fixed IP address, enter:
$ create ppp intf ifname ppp-0 ip 202.1.1.1 lowif aal5-0 ppoa
This creates PPPoA interface ppp-0 on VC aal5-0 with address 202.1.1.1.
Creating a PPPoA interface with a dynamic IP address
Enter the same command as above, but without the IP address:
$ create ppp intf ifname ppp-0 lowif aal5-0 ppoa
- 40 -
To retrieve additional configuration information from the ISP’s DHCP server, use the
usedhcp parameter. To do so, set the usedhcp parameter to true (this parameter is
normally set to false).
5.7.4
Checking the IP Address of a PPP Interface
Whenever you create a PPP interface, its IP address is negotiated
using the IPCP protocol, even if you specify the IP address.
Because of this, you should check the IP address after creating a
PPP interface.
You should also check a PPP interface’s IP address if a “link up”
trap is reported for that interface.
Displaying the requested address for a PPP interface
To see the IP address you specified when creating the interface, enter:
$ get ppp intf
Displaying the actual address of a PPP interface
To see the actual addresses of all PPP interfaces (and all IP-enabled interfaces), enter:
$ get ip address
5.7.5
5.7.6
Configuring the PPP Auto start/stop Feature
IP Unnumbered PPP Interfaces
A PPP interface, once created, remains operational all the time. This
proves to be a security risk sometimes. The modem allows you to
take care of this with the PPP auto start/stop feature. The
pppsesstimer parameter in the size command specifies a timeout
value. If specified, say as 2, it means that if the configured PPP
interface is lying unused for more than 2 minutes, it will be made
unoperational automatically. Later, if you try to connect to the WAN
side, the modem will automatically restart the PPP interface. Having
the PPP interface operational only when required also helps in
efficient bandwidth utilization for the ISP where many such PPP
connections are being handled simultaneously.
Setting the pppsesstimer as 0, or not specifying it at all indicates
that you do not want to use the auto start/stop feature, in which case
the PPP interface will remain operational all the time.
The modem’s PPP interface is typically assigned a unique IP
address from the ISP’s PPP server. This IP address must be in a
- 41 -
different subnet than the IP addresses assigned to the modem’s
LAN interfaces, such as eth-0 and usb-0.
The IP Unnumbered feature provides an alternative configuration
that enables the PPP interface to be created with an IP address that
is the same as that assigned to the modem’s Ethernet interface, eth-
0. Using this feature, the PPP interface does not need to obtain an
IP address from the ISP.
The PPP interface borrows the IP address from eth-0 to facilitate
routing. During IPCP negotiations with the ISP’s server, the PPP
interface conveys this address to the other side as its own. If the
ISP’s server is configured to allow IP Unnumbered connections,
then it does not provide another IP address to the PPP interface, as
it would in normal operation.
If the ISP’s PPP server is not configured to allow IP Unnumbered connections, then the server would respond with
an IPCP negative acknowledgement (NAK) and instead assign a new IP address to the interface, as it would in
normal operation.
The IP Unnumbered feature can be useful in environments in which
conserving IP addresses is a priority.
It is assumed that the LAN hosts are configured with IP addresses that are visible to the ISP (i.e, not
translated via NAT). In typical scenarios where the modem is configured with only one WAN interface (in
this case, the IP Unnumbered PPP interface), users will not need to configure NAT in conjunction with
this feature.
5.7.6.1 Configuration
To configure a PPP interface as IP Unnumbered interface, the PPP
interface must be created without an IP address and must specify
the interface from which to borrow an IP address (only eth-0 is
supported):
Creating an IP Unnumbered interface
The following command creates a PPPoA unnumbered interface that borrows the IP address of
eth-0 and specifies this interface as the default route.
create ppp intf ifname ppp-0 ppoa lowif aal5-0 numif eth-0 droute true
PPPoE interfaces can also be created in this manner. A gateway IP address can also be
specified using the gwy parameter, or can be learned during the IPCP handshake. A specified
gateway IP address will override any address learned via IPCP.
5.7.6.2 Limitations
The following limitations apply when implementing an IP
Unnumbered interface:
- 42 -
Only point-to-point interfaces can be IP Unnumbered.
This feature is not relevant for EoA or IPoA interfaces.
The interface from which the PPP interface borrows the
IP address must be the modem’s Ethernet interface, eth-0 ; it
cannot be usb-0 or any other LAN interface.
The interface eth-0 cannot be configured to receive its IP
address through DHCP, and the IP address cannot be
modified during an active PPP connection.
The ISP’s access server must be configured with an IP
route that specifies the LAN’s network address as the
destination and the interface associated with that user’s
VPI/VCI as the gateway.
Figure below provides an illustration of IP Unnumbered
configuration.
5.7.6.3 IP Unnumbered with NAT
The configuration shown above requires each LAN PC to have a
public IP address (within a range given by the ISP) and does not
make use of Network Address Translation (NAT). However,
because each public IP address is normally available only at a cost
to the user, there may be cases where the customer has more LAN
PCs than available public IP addresses.
For example, a customer may obtain four public IP address from the
ISP for use with servers on the LAN (web server, mail server, etc.),
but may have 10 additional PCs that use private IP addresses in the
subnet 192.168.1.x, mask 255.255.255.0.
The user can configure NAT to enable these 10 PCs to access the
internet. This can be achieved by creating a virtual IP (VIP) LAN
interface on the modem with private IP address (say, 192.168.1.1,
mask 255.255.255.0). The user would then create a NAT rule
(NAPT flavor) to translate the PCs’ local IP addresses to the VIP IP
address. The following CLI commands create a rule of this type and
enable the NAT service:
create nat rule entry ruleid 1 napt lcladdrfrom 192.168.1.2 lcladdrto
192.168.1.254
modify nat global enable
5.8 Configuring the Operating Mode
The reference unit is preconfigured to boot up as a router. Once the
unit is running, however, you can use CLI commands to interactively
reconfigure the unit to run in either operating mode (router or bridge)
or to configure special features of routing mode, such as
simultaneous bridging and bridged IP.
For your own product, you can preconfigure the operating mode
(and other settings) by modifying the factory defaults file and using it
to create your own flash image. For complete information on this
process, refer to the Image Handling User Manual.
- 43 -
5.8.1
Bridge Mode
Refer to section
Refer to section
To change the reference unit’s operating mode to bridge mode:
create an EoA WAN interface without an IP address;
create the Ethernet LAN interface without an IP
address;
configure the EoA and LAN interfaces as bridge
ports; and
enable bridge mode.
Creating the EoA interface
Creating the Ethernet interface
To enable bridging on the eth-0, usb-0, and eoa-0 interfaces, enter:
$ create bridge port intf ifname eth-0
$ create bridge port intf ifname eoa-0
Configuring bridge ports
Bridge ports can be created on the physical Ethernet interface (eth-
0), and on the EoA interfaces (eoa-0, eoa-1, etc.).
- 44 -
To list all interfaces on which bridge ports have been created, enter:
$ get bridge port intf
To enable bridging, enter:
$ modify bridge mode enable
To disable bridging, enter:
$ modify bridge mode disable
To see whether bridge mode is enabled or disabled, enter:
$ get bridge mode
Enabling bridging
5.8.1.1 Bridge Forwarding Table
In bridge mode, the unit is a learning bridge, i.e., it automatically
learns the association between MAC addresses and interfaces. The
unit stores this information in the bridge forwarding table, which
maps each LAN host’s MAC address to one of the bridge’s
interfaces.
To display the bridge forwarding table, enter:
$ get bridge forwarding
An entry remains in the bridge forwarding table for the duration
specified by the aging parameter. After an entry is deleted, the
bridge will relearn that entry the next time the associated host sends
any data across the bridge.
Displaying the bridge forwarding table
Setting an entry’s timeout period
To set the aging parameter to 300 seconds, enter:
$ modify bridge info aging 300
- 45 -
To see the current value of the aging parameter, enter:
$ get bridge info
5.8.1.2 Static Bridge Entries
Because of the aging parameter, every entry is eventually deleted
from the bridge forwarding table (and later relearned), except for
static entries. Static entries are not affected by the aging
parameter; they never time out and are never deleted from the
bridge forwarding table.
Creating a static entry in the bridge forwarding table
To create a static entry in the bridge forwarding table that maps MAC address 0:1:2:3:4:5 to
a specific interface such as eth-0, enter:
$ create bridge static macaddr 0:1:2:3:4:5 ifname eth-0
5.8.1.3 MAC Address Conflicts in Bridge Mode
In bridge mode, the unit by default filters (i.e., does not forward) data
for a set of 17 reserved MAC addresses, per the 802.1d bridge
specification. These MAC addresses are 01:80:C2:00:00:00 through
01:80:C2:00:00:10.
Conflicts can arise if an application uses any of these reserved MAC
addresses (one such application is 802.1x Dialup). If this occurs, you
must override the default list of reserved MAC addresses, as follows:
Edit the text file resvmac.txt in createfi\TEFileSys\bridge.
Delete the address(es) that should not be filtered and save the file.
Run Createfi to create a new image.
Load the image into the unit, then bring up the unit in bridge mode.
When in bridge mode, the unit performs filtering as follows:
If resvmac.txt specified any MAC addresses, the unit filters all those addresses.
If resvmac.txt was left blank, the unit performs no filtering at all.
If resvmac.txt was omitted from createfi\TEFileSys\bridge, the unit will filter the default set
of 17 MAC addresses.
For information on Createfi, refer to the Image Handling User
Manual.
5.8.1.4 Spanning Tree Protocol
The Spanning Tree Protocol (STP) prevents the formation of loops
among interconnected bridges.
- 46 -
By default, STP is enabled on all bridge ports. It is recommended that STP be enabled whenever three or
more bridges are interconnected and at least one physical loop (multiple paths between two bridges)
exists.
Modifying STP on all ports
To configure STP parameters applicable to all ports, use the command:
$ modify stp global
Modifying STP on a specific port
To configure STP parameters for a specific interface such as eth-0, use the command:
$ modify stp port ifname eth-0
You must create the bridge port before you can use this command.
To disable the STP ports, enter both of the following commands:
$ modify stp port ifname eth-0 disable
$ modify stp port ifname usb-0 disable
$ modify stp port ifname eoa-0 disable
5.8.2
WAN to WAN bridging
The unit does not allow WAN-to-WAN bridging, as this behavior may
not be desired by users in some configuration, for reasons such as
security or bandwidth constraint. However, it allows LAN-to-WAN
and WAN-to-LAN bridging. WAN-to-WAN bridging is enabled, by
default.
To disable bridging packets between WAN ports,
enter:
modify bridge mode wan2wan disable
To disable WAN-to-WAN bridging using the HTTP
interface, use the Bridging Menu.
5.8.3 Router Mode
Disabling STP
If the reference unit is not currently operating in router mode, you
can change it to router mode as follows:
set the LAN interface as the default gateway for the
LAN hosts;
create one or more WAN interfaces (PPPoE, PPPoA,
EoA, or IPoA); and
configure one of the WAN interfaces as the default
route.
Making the LAN interface the default gateway
You can configure the IP properties on each LAN host to reflect the LAN interface IP
address as their default gateway. Or, if you are using the unit as a DHCP server, you can
configure the DHCP properties to automatically assign the LAN IP addresses.
Creating the WAN interfaces
PPP interfaces: refer to section
EoA interfaces: refer to section
IPoA interfaces: refer to section
- 47 -
Making the PPP Interface the Default Route
To make the PPP interface ppp-0 the default route, set the droute parameter to true while
creating the interface:
$ create ppp intf ifname ppp-0 lowif aal5-0 ppoe sname games droute
true
5.8.3.1 Simultaneous Bridging and Routing
In this special feature of router mode, the reference unit
simultaneously acts as a router for IP traffic and as a bridge for nonIP traffic. To configure the reference unit as a router with
simultaneous bridging and routing:
configure the unit as a router as described in section
but with at least one IP-enabled EoA interface with a static
default route;
configure the Ethernet interface and an IP- enabled
EoA interface as bridge ports; and
enable bridge mode.
Creating the IP-enabled EoA interface
- 48 -
Refer to section
Creating the Ethernet interface
Refer to section
Configuring bridge ports
To enable bridging on the eth-0, usb-0, and the eoa-0 interfaces, enter:
$ create bridge port intf ifname eth-0
$ create bridge port intf ifname usb-0
$ create bridge port intf ifname eoa-0
To list all interfaces on which bridge ports have been created, enter:
$ get bridge port intf
To enable bridging, enter:
$ modify bridge mode enable
To disable bridging, enter:
$ modify bridge mode disable
To see whether bridge mode is enabled or disabled, enter:
$ get bridge mode
5.8.3.2 Bridged IP
In this special feature of router mode, the reference unit functions as
a bridge over the WAN interface and as a router over the LAN
interface. To configure the reference unit as a router with bridged IP:
configure the unit as a router as described in section
but with at least one IP-enabled EoA interface
Enabling bridging
Creating the IP-enabled EoA interface
Refer to section
Creating the Ethernet interface
Refer to section
Configuring bridge ports
To enable bridging on the eth-0, usb-0, and the eoa-0 interfaces, enter:
$ create bridge port intf ifname eth-0
$ create bridge port intf ifname usb-0
$ create bridge port intf ifname eoa-0
To list all interfaces on which bridge ports have been created, enter:
$ get bridge port intf
- 49 -
To enable bridging, enter:
$ modify bridge mode enable
To disable bridging, enter:
$ modify bridge mode disable
To see whether bridge mode is enabled or disabled, enter:
$ get bridge mode
5.8.4
Bridge Router Autosense (BRAS)
The Bridge Router Autosense feature will be useful in the following
scenario. The unit is pre-configured completely, for the unit to run in
either routing mode or bridging mode. Basically the unit would have
both PPPoE and EoA interfaces pre-configured. When the unit is
plugged in to the user's network, it is able to detect the mode in
which it is required to operate. This means that, the user would be
able to use either the unit's PPPoE client, or one on the LAN PCs,
as the need may be, without having to configure anything on the
unit. The unit would be able to withdraw it's PPPoE client at run time
if it detects any PPPoE traffic.
Enabling bridging
- 50 -
5.8.4.1 Configuration details
When the unit boots, configured PPPs will try to come up as usual. If
PPPoE traffic is detected from the LAN end, then the PPPoE client
on the modem will get disabled. The PPPoE packet received from
the LAN will get forwarded to the WAN side, because of the
preconfigured bridge ports.
If later on, the user wants to switch to the unit's PPP, he just needs to re- enable the
PPPoE client on the unit using the following CLI command:
modify bras <selfppe restart>
This will bring up the unit’s PPPoE. Thereafter, starting the LAN
PPPoE client again, will disable the unit’s client.
To enable or disable the BRAS feature, the user can use the following CLI command:
modify bras enable | disable
A reboot is not required to switch back and forth between enabling
and disabling this feature.
5.8.5
Zero Installation PPPoE Bridge (ZIPB) Mode
Configuring the modem in the Zero Installation PPPOE Bridge or
ZIPB mode enables service providers to avoid installing a PPPoE
client on subscriber PCs as well as avoid running NAT on the
modem. ZIPB combines the advantages of routing and bridging
modes.
5.8.5.1 Advantages of the ZIPB mode
Configuring the modem in the ZIPB mode:
does not require you to install any software on
subscriber PCs
does not require you to run NAT on the modem
allows you to manage modem for both LAN and
WAN sides, because the modem has an IP address on
both LAN as well as WAN interfaces.
allows you to run Firewall/filtering feature on the
modem.
allows you to use bandwidth efficient PPPoA, on the
modem’s WAN interface.
5.8.5.2 ZIPB mode - operation details
LAN PCs get their global addresses through the DHCP server
functionality. If a PPP IP address is available to the unit, the LAN PC
gets this address on a DHCP request.
Initially, when PPP is not yet up, the IP address allocated to the LAN
PC comes from the Ethernet pool, and PPP is triggered to come up.
When the LAN PC sends a renewed request for an IP address
allocation, the unit checks if any PPP IP address is free to be
allocated. If a PPP IP address is free, then, it will send a NACK to
the renewal request for the Ethernet pool IP address. This will force
the LAN PC to go in to the DHCP discovery state. Now, when the
unit receives a fresh DHCP discovery message, it will allocate the
PPP IP address and simultaneously de- allocate the IP address
allocated from the Ethernet pool.
For proper functioning of ZIPB, PPP should be configured with the
‘startondata’ option. This will ensure that PPP comes up only when
the LAN PC is up and that PPP goes down when the LAN PC is
switched off.
- 51 -
The behavior of ‘startondata’ is different when ZIPB is enabled. With ZIPB enabled, PPP comes up only if
the LAN PC sends a DHCP request for an IP address, and not on any other data activity.
The unit remembers the PPP IP address even after PPP goes
down. The unit continues to allocate this same PPP IP address to
the LAN PC. So, the user can access the Internet the minute PPP is
up. He does not need to wait for IP address allocation, provided
PPP comes up with the same IP address.
If the PPP IP address is different from the previously allocated
address, it will send a ForceRenew message to the LAN PC. The
next time the PC tries to get an IP address, it will get the new PPP
IP address.
To enable ZIPB at the modem, enter,
modify zipb cfg enable
5.8.5.2.1 Management from LAN end
When the unit is working in ZIPB mode, the LAN side PCs get the
PPP IP addresses allocated to the modem using IPCP or DHCP. If
the PPP interface is not up, the PC gets an IP address from the
DHCP server pool 0. The DHCP pool has a small default lease and
clients will keep sending renew requests after 30 seconds.
Each request for renewing an IP address from DHCP pool 0, results in writing to NVRAM and more writes
to NVRAM. This reduces the NVRAM life.
- 52 -
LAN machines can access the modem in ZIPB mode, as they
would, in non-ZIPB mode, using the Ethernet IP address.
Instead of trying to access an IP address, the LAN side PC user should use the DNS relay capability of the
modem. Please refer to the chapter on DNS relay for details on this feature.
5.8.5.2.2 Management from WAN end
When in ZIPB mode, with the PPP link up, all requests coming to the
modem from the WAN end are passed on to the PC behind it, as the
PPP IP address of the modem is considered the IP address of the
PC behind the modem. The standard Telnet, FTP and HTTP
services on the PC behind the modem, run on ports 21, 20 and 80
respectively. However, if you want to access any of the telnet, ftp or
HTTP services on the modem, you can configure the ports to be
other than the standard ones used on the PC behind the modem.
To access the modem from the WAN end, using telnet or http, use
the PPP IP address allocated to the modem. The ports you will
specify during WAN- end access should be the same as those
specified for the modem in the nbsize command.
While configuring telnet and http ports, above, from both LAN and WAN ends, the user needs to
remember to use the same ports as those mentioned in the get nbsize command.
5.8.5.2.3 Use of ForceRenew in ZIPB mode
When configured in the ZIPB mode, the modem is able to detect
that the LAN PC is switched off, and it automatically brings down
PPP. When the LAN PC comes up again, the modem senses it, and
brings up PPP too.
ForceRenew, as defined in RFC 3203 is used in the ZIPB mode in
the following scenarios.
If a LAN client is up with an IP address from the Ethernet pool, and
the PPP interface comes up, a ForceRenew message is sent to the
client. When the client sends a renew, it is sent a NACK by the
server. The Client then sends a Discover and now it can be given
any of the free PPP IP addresses maintained by the DHCP server.
The DHCP server initiates ForceRenew for the following trigger
points:
ZIPB is enabled
ZIPB disabled
PPP Up trigger
5.8.5.3 Preconditions to configuring the modem in ZIPB mode
create ethernet intf ifname eth-0 ip 192.168.1.1 mask 255.255.0.0
An Ethernet interface should be created. You
can use the following syntax,
You need to create and enable a DHCP server pool
with poolId 0 and an Ethernet subnet with small lease
time. For example, you can use the following syntax.
create dhcp server pool poolid 0 start-ip 192.168.1.2 end- ip
192.168.1.5 mask 255.255.0.0 lease 60 mlease 120
Enable dhcp server, by entering,
dhcp server cfg enable
You should also configure PPP with startondata.
$ create ppp intf ifname ppp-0 ppoe sname test lowif aal5-0
droute true startondata
Configure the ftp, telnet and http ports to be different from the standard ports 23, 20 and
80 respectively, if you want to provide these services on the LAN PC as well.
5.8.5.4 Configuring ZIPB
- 53 -
You can either enable or disable the ZIPB mode on the modem. It is
disabled by default. You can set the mode by using either the default
configuration (factory defaults file) or CLI commands.
You can dynamically configure the modem to work in the ZIPB
mode. When disabled, the modem runs either in bridging or routing
mode. When enabled, it runs in the ZIPB mode.
To enable ZIPB enter:
$ modify zipb cfg enable
Run the createfi utility and upload the image to flash.
On the command line interface, use this command to enable ZIPB:
$ modify zipb cfg enable
Configuring using the factory defaults file
Configuring using CLI
The preconditions to configuring ZIPB, as mentioned in the section above, need to be met.
- 54 -
6 Viewing and Modifying DSL Information
The CLI enables you to configure various parameters that control
how data is transmitted on the DSL line. You can also view statistics
relating to the DSL line performance.
6.1 Modifying the DSL Configuration
You may need to modify various DSL parameters to ensure proper
operation of the reference design with your test equipment, or to
prepare your customer units for operation in the particular
environment in which they will be deployed. DSL-related information
can be modified using the following command:
$ modify dsl config <parameters>
The command parameters enable you to change a variety of
properties, including the DSL standard to which the firmware
complies and the DSL annex type. You can also start and stop
operation of the DSL loop and set various operating characteristics,
such as the coding gain due to Reed- Solomon or trellis coding, the
level of framing overhead, and the power attenuation in dB.
Several examples follow. A complete list of parameters and their
descriptions is provided in the CLI Reference Manual.
Modifying the DSL configuration
To change the DSL standard to G.dmt (G.992.1), enter:
$ modify dsl config gdmt
To change the DSL annex to Annex C, enter:
$ modify dsl config annexc
To enable (default) or disable the operation of the DSL loop, enter:
$ modify dsl config loop start
$ modify dsl config loop stop
Viewing the DSL configuration
To view current DSL configuration information, enter:
$ get dsl config
6.2 Viewing DSL Parameters and Statistics
You can use the following commands to view a variety of nonmodifiable DSL parameters and performance statistics. For a
complete list of all parameter values for all the following commands,
see the CLI Reference Manual.
Viewing DSL parameters
To view DSL parameters, enter the following command:
$ get dsl params
The output displays static DSL information such as the vendor ID and serial number, and
calculated values such as far- and near-end RS errors, the signal-to-noise ratio, the calculated
line attenuation, and other statistics.
- 55 -
Viewing DSL statistics
To view the number of errored, severely errored, and unavailable seconds in the past 15-
minute interval and in the past 24 hours, type the following command:
$ get dsl stats curr
To view the number of errored, severely errored, and unavailable seconds for eight 15-
minute intervals, starting with four intervals ago (i.e., statistics for the intervals from 1
hour ago to 3 hours ago), enter:
$ get dsl stats hist 8 4
The display also shows the number of intervals in which valid data was transmitted. You can
specify up to 96 past intervals to display.
To view near- and far-end errors counts relating to Reed-Solomon, CRC, and other errors
types accumulated since the last reboot, enter:
$ get dsl stats cntrs
To view local and remote transmission failures accumulated since the last reboot, enter:
$ get dsl stats flrs
- 56 -
The output displays loss-of-signal defects (LOS), severely errored frame defects (SEF), no-cell
delineation errors, and loss-of-cell delineation errors for the data stream.
Resetting DSL statistics
The DSL counters and failure statistics accumulate starting from the last reboot. You can
use the following commands to reset these statistics to zero without rebooting:
$ reset dsl stats flrs
$ reset dsl stats cntrs
7 Configuring IP and Routing Management
This chapter shows you how to configure routes on the modem and
on the LAN hosts.
Before you begin this chapter, configure the WAN and LAN interfaces as described above.
7.1 Configuring Routing on LAN Hosts
In routing mode, because the unit acts as the gateway for the LAN
hosts, the LAN hosts should be configured to use the LAN IP
address as their default gateway.
7.2 Configuring Routes
- 57 -
Of the WAN interfaces, the PPP, EoA, and IPoA interfaces are IPenabled, i.e., can have IP addresses. A PPP, EoA, or IPoA interface
can therefore be used as the default route for the unit itself.
Configuring a PPP interface as the default route
The create ppp intf command has a droute parameter that, when set to true, makes the
interface the default route. In this case, PPP automatically creates the default route entry,
where the default gateway address is the IP address of the other end of the PPP interface.
Only one PPP interface can be made the default route using droute.
There can be only one default route on the modem.
You can use the create ip route command to create other,
non- default routes also. These are called static routes. The ip and
mask parameters indicate the destination for which the route is
being created. If the mask is 255.255.255.255 then the route is
towards a single host whose IP address is given by the ip
parameter. Any other value of the mask indicates that the route is
towards a subnet, the subnet address being determined by masking
the ip parameter with the given mask.
To create a static route to the subnet 172.25.0.0 (mask 255.255.255.0), via the gateway
10.2.1.1, enter:
$ create ip route ip 172.25.0.0 mask 255.255.255.0 gwyip 10.2.1.1
Creating a static route
- 58 -
Be sure to verify that your modem can reach the gateway. This can be done beforehand using
the ping command, e.g., ping 10.2.1.1.
A dynamic route is one created automatically by the modem, either
when you create an IP-enabled interface, or by learning through
RIP.
To see the current routes, both static and dynamic, enter:
$ get ip route
Deleting a route
To delete a route, enter:
$ delete ip route ip 172.25.0.0 mask 255.255.255.0
Modifying an IP route
To modify an IP route, delete the existing route using the delete
ip route command, then recreate the route using the create ip
route command.
Suppose you create a static route to subnet 172.25.0.0 via gateway 10.2.1.1. To modify the
route to use a different gateway, say 20.1.1.1:
First delete the existing entry by entering:
$ delete ip route 172.25.0.0 mask 255.255.255.0
Next, recreate the route with the new gateway address by entering:
$ create ip route ip 172.25.0.0 mask 255.255.255.0 gwyip 20.1.1.1
7.3 Routing Mode
Routing (or more appropriately, forwarding) is enabled by default. It
can be disabled using the modify ip cfg command.
To disable IP forwarding on the modem, type the command:
$ modify ip cfg forwarding disable
To see the current state, type the command:
$ get ip cfg
7.4 RIP
Routing Information Protocol (RIP) is a dynamic routing protocol
typically used inside the organization to exchange routes between
various routers within the organization. The modem’s RIP is an
implementation of RIPv2 with compatibility with RIPv1 and can be
configured to run as either RIPv1, RIPv2, or RIPv2-with-RIPv1
compatibility mode.
- 59 -
7.4.1
RIP Global Configuration
To enable or disable RIP on the IAD use the command :
$ modify rip global
The command also allows you to modify RIP timing parameters
such as updatetime which is the frequency at which the modem
broadcasts its routes, and agetime which is the time after which the
modem would delete a route for which no updates have been
received.
To see the current state and currently active global configuration, use the command:
$ get rip global
7.4.2
RIP Interface Configuration
To configure RIP on an IP enabled interface with the desired configuration, use the create
rip intf command :
$ create rip intf ifname ppp-0 metric 1 send rip2 receive rip2
senddefroute enable recvdefroute enable auth text abcd
The above command enables RIP on ppp-0 interface.
The send and receive parameters indicate that RIPv2 is to be
used for both sending and receiving RIP updates. The
senddefroute parameter simply tells whether the modem should
send updates for default routes or not. Similarly, the
recvdefroute parameter tells whether the modem should process
updates for default routes received from other routers or not. The
auth parameter says that RIP authentication is to be provided using
the clear text password abcd. Routers sending RIP updates to the
modem on this interface must include this password in their
messages. The same password is also used by the modem when it
- 60 -
sends out RIP updates to other routers on this interface. If no
authentication is required, the auth parameter is set to none. In
case of RIPv1, auth must be set to none.
The metric is a kind of path cost associated with the interface. The higher the metric, the costlier it is to use that
interface to get to a particular destination.
When a router sends its routing updates to the modem it associates
a metric value with each route. Suppose the modem receives RIP
updates for routes to the same destination A from two of its
interfaces, ppp-0 and ppp-1. The metric in the messages received
on the two interfaces is, say, the same,3. Further suppose that we
created the RIP interface on ppp-0 with the metric 1 and on ppp-1
with the metric 2. Now when the modem tries to decide whether to
use ppp-0 or ppp-1 to reach the destination A, it adds the metric
given during the create rip intf command to that update
received in the RIP message. So reaching A via ppp-0 has a metric
cost of 3 + 1 = 4, while reaching A via ppp-1 has a metric cost of 3 +
2 = 5. The route chosen finally is the one with the minimum metric
cost, i.e. ppp- 0. The metric associated with the RIP interface is also
used while sending RIP updates to neighboring routers. For a route
received on ppp-0 with metric 2, the update to a router connected to
ppp-1 would contain the metric calculated as follows -
Original metric + metric of ppp-0 = 2 + 1 = 3
The metric can be any number between 1 and 15. Setting the metric
to 15 effectively disables that interface for IP traffic, i.e. routes using
that interface are deleted from the routing table.
To modify RIP parameters, use the command:
$ modify rip intf
To view the current configuration, use the command:
$ get rip intf
7.5 IGMP
The Internet Group Management Protocol (IGMP) is used by
multicast- enabled hosts to tell routers on their LAN that they want to
receive multicast packets. Multicast routers use IGMP messages to
learn the presence of multicast groups on their LAN so that they can
forward relevant multicast packets to them. The modem supports
IGMP version 1.0 and version 2.0.
- 61 -
Creating IGMP interfaces is useful only when the unit is configured in routing or ZIPB mode. When the
unit is configured for routing and bridging simultaneously, then all multicast packets will go through
routing path —and not through the bridging path — if the IGMP interface is created as described in this
section. If you require that multicast packets go through bridge mode only, do not create an IGMP
interface on the unit.
IGMP is enabled on the modem by configuring IGMP router and
host interfaces.
IGMP router interfaces are typically the LAN side
interfaces, and these can be multiple.
The IGMP host interface is typically one of the WAN
side interfaces (PPP, EoA or IPoA); there can be only one
IGMP host interface.
The modem listens to IGMP reports on its router interface(s),
consolidates them, and forwards the consolidated reports out its
host interface, thereby acting as an IGMP proxy agent for its LAN
hosts. The reports generated on the LAN also help the modem learn
what groups are currently active on each of its LAN interfaces. This
information can be viewed using the get igmp groups command.
If a packet is received for a group which the modem knows is active
on at least one of its router interfaces, it forwards the packet out that
interface.
The IGMP version can be configured individually for each of the
modem’s IGMP-enabled interfaces. As IGMPv2 can fall back to
IGMPv1, it is preferable to configure all interfaces with IGMPv2; the
modem will still be able to communicate with an IGMPv1-compliant
LAN PC or uplink router.
Configuring IGMP router interface on eth-0
To configure an IGMP router interface on eth-0 with the default values, enter:
$ create igmp intf ifname eth-0 router
You can add these parameters to the command (see the example
that follows).
query interval: the interval at which the modem
periodically queries the hosts for currently active groups
maximum response time (IGMPv2 only): the amount
of time a host has to respond to a query
last member query interval (IGMPv2 only): After
receiving a “leave group” message from a host, the
modem will send a query to determine if other hosts
remain in the group, and wait for responses. This
parameter determines the amount of time the modem
waits for responses.
- 62 -
For any IGMPv2 router interface, if you set the last member query interval as 0 seconds, then as soon as
an IGMP “leave group” message is received from any LAN side host, the group will be detached from that
router interface. This means that the modem will not send an IGMPv2 group- specific query to find other
LAN hosts still interested in receiving data for this multicast group.
If you know that there is only one LAN host for a group particular group (e.g., if an IGMP-compliant video
set-top box is connected to the modem), set this parameter to 0 so that the modem will detach the group
immediately.
robustness indicator: a whole number used to
multiply the specified query and response intervals, or to
set the number of repeated queries that must be sent out
when determining whether any hosts remain in a group.
Specify a higher number when the network has a greater
tendency to lose messages.
Configuring an IGMP router interface with parameters
The following command configures an IGMP router interface on eth0 with version IGMPv2, a last member query interval of 1 second, a
robustness indicator of 3, and a query interval of 60 seconds:
$ create igmp intf ifname eth-0 router version igmpv2 lmqinterval 1
robust 5 qinterval 60
Configuring an IGMP host interface on ppp-0
To configure an IGMP host interface on ppp-0 with the default values, enter:
$ create igmp intf ifname ppp-0 host
To configure an IGMP host interface on ppp-0 with IGMPv1, enter:
$ create igmp intf ifname ppp-0 host version igmpv1
Viewing IGMP groups
To see which groups are currently registered on the modem's IGMP router interfaces,
enter:
$ get igmp groups
If, for example, the command output reports group 224.1.1.1 on the eth-0 and usb-0 interfaces,
then when a packet with the destination of 224.1.1.1 is received on the IGMP router interface, it
will be forwarded to the eth-0 and usb-0 interfaces.
To delete an IGMP host interface on eth-0, enter:
delete igmp intf ifname eth-0
To delete an IGMP host interface on ppp-0, enter:
delete igmp intf ifname ppp-0
- 63 -
Deleting IGMP interfaces
- 64 -
8 Virtual Private Network
An internet-based virtual private network (VPN) uses the open,
distributed infrastructure of the Internet to transmit data between
corporate sites. This chapter explains how the modem uses the
Layer 2 Tunneling Protocol (L2TP) to provide the benefits of a VPN.
8.1 Overview
Businesses today are faced with supporting a broader variety of
communications among a wider range of sites even as they seek to
reduce the costs of their communications infrastructure. Employees
are looking to access the resources of their corporate intranets while
they are mobile, or from customer sites. Businesses are finding
traditional solutions to wide- area networking between the main
corporate network and the branch offices, inflexible and
expensive.VPNs using the Internet have the potential to solve many
of these business networking problems. VPNs allow network
managers to connect to remote branch offices and project teams to
the main corporate network, economically, while providing remote
access to employees without increasing the in-house requirements
for equipment and support.
Why VPNs?
How a VPN functions
Organizations using Internet VPNs set up connections to the local
connection points of their ISPs and let the ISPs ensure that the data
is transmitted to the appropriate destinations via the Internet, leaving
the rest of the connectivity details to the ISP’s network and the
Internet infrastructure.
In VPNs, connections are set up according to organizational needs.
The network is formed logically, regardless of the physical structure
of the underlying Internet. Unlike leased lines used in traditional
corporate networks, VPNs do not maintain permanent links between
the end points that make up the corporate network. Instead, a
connection is created only when it is required between two points.
When the connection is no longer required, it is torn down, making
the bandwidth and other network resources available to other users.
L2TP for VPNs
8.2 L2TP
- 65 -
These connections or tunnels are set up between the remote client
and the corporate network it is trying to access. The client initiates
the creation of the tunnel in order to exchange traffic with the
corporate network. To do so, the client uses special client software,
which uses L2TP, to communicate with the gateway protecting the
LAN.
L2TP is one of the various protocols suggested for creating VPNs
over the Internet. L2TP uses PPP to provide dial-up access that can
be tunneled through the Internet to a site. L2TP uses the
authentication mechanisms within PPP, because it uses PPP for
dial-up links. L2TP also supports PPP’s use of the extensible
authentication protocols for other authentication systems.
The modem-based VPN service is actually an add-on software that
is a low-cost solution for client to LAN connections. This can run on
existing servers and share server resources.
The Layer 2 Tunneling Protocol (L2TP) enables the user to connect
to the corporate server directly, while using the local ISP. The user
of a PPP session gets authenticated by the corporate server. This
cuts down on costs that the user would have otherwise incurred on
leased lines for branch offices or remote users.
The modem is a Customer Premises Equipment (CPE) used for
transportation of data over Digital Subscriber Line (DSL). The
modem uses Asynchronous Transfer Mode (ATM) technology over
DSL to transport data to its counterpart at the Central Office. The
software for the modem implements the protocol stack of ATM and
its adaptation layers. In addition to this, the modem incorporates
routing and bridging support for data protocols. Hence, all software
components such as the IP stack and requisite drivers, such as the
Ethernet driver, are also included.
L2TP is a tunneling protocol used for tunneling PPP packets through
IP networks. In an xDSL environment, user ATM PVCs extend from
the CPE to a centrally located NAS function. L2TP tunnels originate
from the CPE and terminate on the LNS at the corporate servers
connected to the Internet. The main application of this protocol is in
Virtual Private Dial in Networks, providing access to corporate
networks from mobile and remote users, and interconnecting
various corporate offices together for access across the globe.
The diagram below shows the user or the Client connected to a
LAN, talking to the modem installed at the CPE end. The modem
creates a tunnel through the ISP to the network server of the
corporate office, for gaining remote access. Here, the modem
functions a the L2TP access client (LAC), creating the tunnel to the
LAN network server (LNS), sitting at the corporate office router. The
- 66 -
link PPP-2 is first used to connect to the ISP. IPoA, EoA are
interfaces that could also be used for this link. The link PPP-1, that
connects the modem to the corporate server, uses L2TP.
Client-Corporate Office Connection using L2TP
L2TP Tunnel
A tunnel exists between an LAC-LNS pair. The Tunnel consists of a
Control Connection and zero or more L2TP Sessions. The tunnel
carries encapsulated PPP datagrams and Control Messages
between the LAC and the LNS.
L2TP Session
The LNS and LAC maintain state for each call that is initiated or
answered by an LAC. An L2TP Session is created between the LAC
and LNS when an end-to-end PPP connection is established
between a Remote System and the LNS. Datagrams related to the
PPP connection are sent over the Tunnel between the LAC and the
LNS. There is a one-to-one relationship between established L2TP
Sessions and their associated Calls.
The L2TP protocol manages the tunnel in a way that makes it
transparent to the PPP session inside it. L2TP clients are like "dialup" users, and L2TP servers are like access concentrators or
modem banks. Once the connection is "dialed", authenticated, and
connected, data starts to flow through the tunnel in much the same
8.3 Configuration details
- 67 -
manner as a modem dial-up, except that the call is placed through
the Internet (IP network) instead of the PSTN (telephone network).
If the tunnel server is on the corporate LAN, all branch office LANs
can connect to the centrally located server in order to talk to each
other. The user is connected to a LAN talking to the modem at the
CPE. The modem creates a tunnel through the ISP to the network
server of the corporate office in order to gain remote access. Here,
the modem acts as a L2TP access client (LAC), creating the tunnel
to the L2TP Network Server (LNS), at the corporate office router.
Configuring number of sessions over an L2TP tunnel
The maximum sessions over an L2tp tunnel can be configured using
the size command in the following manner:
size maxl2tpsessionpertunnel 2 maxl2tptunnel b
The default value for the maximum number of L2TP tunnels is 1,
and the maximum number of sessions possible over an L2tp tunnel
is 1.
Modifying L2TP global configuration
To modify L2TP global configuration, enter:
modify l2tp global config timeout 180
The timeout value is specified in seconds. You can also specify the timeout value as infinite. If the user
has configured the idle timeout (idletimeout) as infinite and the value for global config timeout is also set
to infinite then the tunnel will never come down. This is because, the peer does not send a response to a
control message, or , the upper PPP link goes down due to inactivity. The user should take care that
these timers should not have infinite values.
Getting global information on L2TP tunnel configuration
To get L2TP tunnel global configuration information, enter:
get l2tp global config
Getting L2TP global information
- 68 -
To get L2TP global information such as protocol Version and Vendor name, enter:
get l2tp global info
Creating L2TP tunnel
To create an L2TP tunnel, enter:
create l2tp tunnel config ifname l2t-0 localip 178.10.10.10 remoteip
178.10.11.10 start authtype simple secret passwd hellointerval 300
idletimeout num 100 crws 5 maxretx 10 maxretxtimeout 10 payloadseq
always transport udpip initiator local localhostname titanium
remotehostname columbia
While creating an L2TP tunnel, peers are authenticated, either in a Simple mode, or in a Challenge mode.
While creating a tunnel, if the 'initiator' type is LOCAL then the localip and remoteip fields in the command
are mandatory. If the initiator type is REMOTE then localip is mandatory while the remoteip is optional.
Before deleting an L2TP tunnel it is necessary to delete all sessions
above that tunnel, or else the tunnel deletion fails.
To delete a L2TP tunnel, enter:
delete l2tp tunnel config ifname interface-name
A tunnel can be created with one of the two initiator modes - LOCAL
or REMOTE.
When the tunnel is created with initiator as Local, the first message
(SCCRQ) for the process of tunnel establishment is sent to the peer
only on receiving the start tunnel trigger.
When the tunnel is created with initiator as Remote, a dormant state
is evoked, and the first message for the process of tunnel
establishment has to be sent by the peer.
Deleting L2TP tunnel
Tunnel Initiator Modes
Getting information on L2TP tunnel
To get information on one L2TP tunnel, or, all tunnels, enter:
get l2tp tunnel config ifname l2t-0
Modifying L2TP tunnel configuration
To modify L2TP tunnel configuration, enter:
modify l2tp tunnel config
ifname interface-name
localip local-ip-address
localhostname local-host-name
remoteip remote-ip-address
- 69 -
remotehostname remote-host-name
start|stop
[authtype simple|challenge|none]
[secret tunnel-secret]
[hellointerval hello-interval]
[idletimeout {infinite|{num <decValue>}]
[crws contol-recv-windowsize]
[maxretx max-retransmission]
[maxretxtimeout max-retransmission-timeout]
[payloadseq never|always}]
[transport udpip]
[initiator local|remote]
[enable|disable]
- 70 -
Starting and Stopping Tunnels
A Tunnel is created with two options START and STOP.
When the tunnel is created using the start option, creation and
establishment of tunnel happens simultaneously. If you create a
tunnel using the stop option, you can decide to start the tunnel later.
To stop an L2TP tunnel, issue the Stop Tunnel command. An L2TP
peer can also stop the tunnel by sending a StopCCN message.
Creating PPP Session over L2TP
You can create a PPP session over an L2TP tunnel in any one of
the three following modes.
Start - In this mode, the PPP session is created and
started simultaneously.
Starton data - In this mode, a PPP session is created
but not started till the data activity over that session starts.
Stop - In this mode, a PPP session is created with stop
option and can be started later.
To create a PPP session over L2TP, enter:
create ppp intf ifname ppp-1 start lowif l2t-0 L2TP usedhcp false
outside
Creation of PPP session fails if the lower layer (L2TP tunnel) doesn't exists.
Establishing and Ending Sessions
Once the tunnel is established, the process of establishment of
L2TP session over this tunnel also begins, if there are PPP sessions
configured with the lower layer as L2TP. Stopping an L2TP tunnel
brings down the L2TP tunnel and all the sessions over that tunnel.
When the user stops the PPP session over an L2TP session by
entering the following command, the particular L2TP session stops.
The command is
modify ppp intf ifname ppp-0 stop
Inactivity timer in lower layer PPP
When the link to the ISP is lost due to inactivity timer, L2TP brings
down all the tunnels configured with that IP address and all the
- 71 -
sessions over those tunnels are also torn down. Whenever the link
is restored, L2TP starts the process of establishment of all the
tunnels, which are configured with that IP address. The process of
establishment of all the sessions for those tunnels also begins once
the tunnel is established.
When the link comes up after going down, it should come up with the fixed IP address. If the link comes
up with an IP address which does not belong to the list of IP addresses configured for any of the tunnels,
then the tunnel that has gone down due to the link going down, will not come up.
Getting L2TP tunnel statistics
To get L2TP tunnel status and statistics for a particular tunnel interface, enter:
get l2tp tunnel stats ifname l2t-0
To get the same information for all L2TP sessions omit the ifname parameter.
Getting L2TP UDP statistics
To get L2TP UDP statistics, enter:
get l2tp udp stats l2t-0
Getting L2TP session statistics
To get L2TP session status for a particular PPP/ PPPoE session interface:
get l2tp session stats pppifname ppp-o
To get the same information fof all L2TP sessions omit the ppifname parameter.
Resetting L2TP Session statistics
To reset L2TP session statistics for a L2TP session for particular PPP interface, enter:
reset l2tp session stats pppifname ppp-0
To reset L2TP tunnel statistics for a particular tunnel interface, enter:
reset l2tp tunnel stats
Resetting L2TP tunnel statistics
- 72 -
8.4 L2TP Traps
L2TP sends traps for:
Tunnel establishment - This trap is generated when
the tunnel establishment with the peer is successful.
Tunnel down - This trap is generated when the tunnel
goes down due to stop tunnel command from user, or , due
to stop tunnel message from peer.
Session establishment - This trap is generated when
L2TP session is established successfully.
Session down - This trap is generated when an L2TP
session goes down.
9 Configuring DNS Relay
This chapter describes the commands for configuring the unit as a
DNS relay server.
9.1 Overview of DNS Relay
PCs on a LAN can set the IP address of the unit as the DNS server.
The SAR110 unit will thus act as a DNS relay server and forward the
requests received from the PCs on the LAN to the actual DNS
servers, whose addresses have been learned from PPP. If the PPP
connection is not available (because of inactivity) at the time a DNS
request is received from the LAN, the PPP link will start
automatically. All the responses received from the DNS server will
be forwarded to the LAN PCs.
- 73 -
When the unit is configured as a DNS relay server, a user will not
need to change the DNS server IP address on their PC whenever
their ISP changes DNS servers, or when the user connects to a
different ISP.
9.2 Configuration Details
To enable or disable DNS relay, enter:
modify dns relay cfg [enable|disable]
To display the current DNS relay statistics, enter:
get dns relay cfg
Enabling/Disabling DNS Relay
Displaying Current Status
- 74 -
10 Configuring DHCP Server and DHCP Relay
This chapter describes the commands for configuring the unit as a
Dynamic Host Configuration Protocol (DHCP) server, DHCP relay
agent, and DHCP client.
As a DHCP server, the unit maintains a pool of IP
addresses and distributes them to LAN hosts whenever
they are switched on.
As a DHCP relay agent, the unit forwards requests
for IP addresses from LAN hosts to a DHCP server (often
at the ISP’s location), and then returns the IP information
from the DHCP server to the hosts.
If the LAN uses its own DHCP server, then the LAN
interface on the unit can be configured as a DHCP client
of that server.
10.1 Default DHCP Configuration on the SAR110 Reference Unit
By default, the SAR110 reference unit is configured as a DHCP
server, with two pools of IP addresses. The following commands are
included in the default configuration file to set this configuration:
$ create dhcp server pool start-ip 192.168.1.2 end-ip 192.168.1.13
mask 255.255.255.0 gwy 192.168.1.1 enable
$ modify dhcp server cfg enable
The first line creates a single pool of IP addresses from 192.168.1.2
through 192.168.1.13 for distribution to up to 12 LAN hosts.
For the unit to operate as a DHCP server, LAN hosts must be configured to accept IP information
dynamically.
For more information about the default configuration see above.
10.2 Configuring Unit as DHCP Server
The two commands used in the default configuration provide the
basic instructions for configuring the device as a DHCP server. This
section explains those commands in detail and describes additional
commands and parameters you can use in your own configuration.
- 75 -
10.2.1 Creating DHCP Pools
A DHCP pool is a range of IP addresses made available on a server
for distribution to LAN hosts.
Creating a Basic DHCP Pool
To create a basic DHCP pool, enter:
$ create dhcp server pool start-ip 192.168.1.2 end-ip 192.168.1.13
mask 255.255.255.0
This command configures a pool of 12 IP addresses, from 192.168.1.2 to 192.168.1.13. The
mask indicates that this pool is applicable to the subnet 192.168.1.0.
The IP addresses specified in the pool must belong to same subnet as the physical ethernet interface or
one of the virtual ethernet interfaces.
Viewing Pools
To see the pool(s) you have created, along with other configurable parameters, enter:
$ get dhcp server pool
In addition to specifying the address ranges and network mask, you
can add parameters to the create command, to:
Assign a specific ID number to the pool (if not
specified, the next sequential number will be assigned
by default, starting from 0 as first pool).
Specify a lease period, which identifies how long
computers can use a particular IP address before it is
returned to the address pool (if not specified, the lease
period is set to 1 day by default)
Specify a low threshold, which determines when the
unit will send an alert that the available pool of
addresses is getting low.
Specify a domain name for hosts that receive
addresses from this pool (for the administrator’s
reference).
Specify IP addresses that hosts should use to
access various network servers (such as DNS, WINS,
POP3 servers).
Enable or disable the pool. IP addresses cannot be
assigned from a disabled pool, but the configuration
remains on the system for future activation.
- 76 -
Assigning a Pool ID
You can configure multiple pools for assignment to different subnets
on the LAN. Each pool is distinguished by a pool id. If the pool id is
not specified in the create command, the pool is assigned the first
available pool id.
To assign a particular pool id number include it in the command:
$ create dhcp server pool poolid 2 start-ip 192.168.1.3 end- ip
192.168.1.34 mask 255.255.255.0
Specifying a Lease Period
The DHCP server allocates IP addresses to clients for a specified
duration, called the lease. You can specify a default lease period
and a maximum lease period for each DHCP pool. If you do not
specify a lease period when you create the pool, the default lease
period is set to 2592000 seconds (30 days) and the maximum lease
is set to 31536000 seconds (365 days).
When the lease period expires, the client may again request an IP
address from the DHCP server. The client can request an address
for a specific lease duration. The server will grant the request if the
duration is less than the maximum lease period configured for the
pool. If the client request does not specify a lease duration, the
server assigns an IP address for the default lease period.
To specify a lease period of one day, for example, create pool as follows:
$ create dhcp server pool poolid 2 start-ip 192.168.1.2 end- ip
192.168.1.13 mask 255.255.255.0 dlease 86400 mlease 4294967295
If you do not want to limit the lease period, you can set the default
lease and maximum lease periods to the maximum of 4294967295
seconds (greater than 136 years).
Specifying a Low Threshold Value
Each DHCP pool has a low threshold value associated with it.
Whenever the number of available IP addresses in the pool drops
below this threshold, the server produces the low threshold hit trap.
This trap indicates that available addresses from the pool may soon
be exhausted and hosts coming up on the LAN will not be allocated
IP addresses dynamically.
By default, the low threshold parameter is given a value of 0. Since
the number of available addresses can never fall below 0, this
means that the trap will be generated only if you have specifically set
the low threshold to a non-zero value.
To specify the low threshold value, type:
$ create dhcp server pool poolid 2 start-ip 192.168.1.2 end- ip
192.168.1.13 mask 255.255.255.0 lthres 3
Enabling and Disabling Pools
By default, when you create a new pool it is enabled for use. You
can disable a pool if you do not want to use it currently, but want to
retain the information for future use.
To disable a pool, type the command:
- 77 -
$ modify dhcp server pool poolid 0 disable
To re-enable the pool, type the command:
$ modify dhcp server pool poolid 0 enable
10.2.2
Excluding Addresses from a Pool
If you do not want particular addresses to be assigned to LAN hosts,
you can add these to a pool exclusion table.
To mark an address as unusable (for example 192.168.1.13) from an existing pool, type the
command:
$ create dhcp server exclude ip 192.168.1.13
To remove the entry from the pool exclusion table and make it available for use, type the
command:
$ delete dhcp server exclude ip 192.168.1.13
To view the pool exclusion table entries, type the command:
$ get dhcp server exclude
- 78 -
10.2.3 Modifying and Deleting Pools
You can modify the lease and other configurable parameters using
the modify command or by giving the relevant parameters directly
in the create command.
Modifying Pools
To modify a DHCP pool, use the command:
modify dhcp server pool poolid 0 [parameter value]
For example, to modify the DNS server assigned to DHCP clients, use:
$ modify dhcp server pool poolid 0 dns 192.168.1.11
The modification will be reflected on the host whenever it reboots next and gets its address and
other parameters from the modem.
Deleting Pools
To delete a pool with pool id 2, use the command:
$ delete dhcp server pool poolid 2
If you delete a pool or modify its settings while IP addresses are currently allocated from the pool, the
hosts will continue to use the allocated IP addresses with the original settings, till the next renewal.
10.2.4 Creating Static DHCP Assignments
The DHCP server will attempt to assign the same address to a host
each time the host boots; however, this may not always be possible.
A host may be assigned an IP address, different from the one it
previously used, depending on the available addresses. In some
situations, it may be important that the DHCP server always assigns
the same IP address to a particular host.
The unit’s static hosts table enables you to create a permanent oneto-one association between a host and an IP address. On the LAN,
a particular host is uniquely identified by its MAC address. A static
host entry stores the association between the MAC address and a
fixed IP address, as in the following example.
Adding an Entry to the Static Hosts Table
- 79 -
To create an entry in the static hosts table that associates the MAC address 00:80:48:CB: B8:
83 with the fixed IP address 192.168.1.2, type the command:
$ create dhcp server host ip 192.168.1.2 mask 255.255.255.0 hwaddr
00:80:48:CB:B8:83 dlease 4294967295 mlease 4294967295
The lease periods carry the same meaning as for a pool. You can
set them to 4294967295 if you do not want to limit the lease period.
The hardware address parameter (hwaddr) refers to the MAC
address or the Ethernet address. The specified IP address is
reserved for the host regardless of whether the host is currently
switched on. The IP address will not be allocated to any other host.
Viewing the Static Hosts Table
To see the details of all configured static hosts, type the command:
$ get dhcp server host
Deleting an Entry from the Static Hosts Table
To delete a static host entry that is no longer required, use the command:
$ delete dhcp server host ip 192.168.1.3
To delete all static hosts, type the command without specifying an IP address:
$ delete dhcp server host
After you delete the entry, the client will continue to use the IP address, but only for the next renewal.
10.2.5 Enabling the DHCP Server
After configuring DHCP pools, you must enable the DHCP server.
In the default software setting, DHCP server is disabled. However, on your reference board, DHCP has
been enabled.
To enable the server, type the command:
$ modify dhcp server cfg enable
To disable the DHCP server, type the command:
$ modify dhcp server cfg disable
- 80 -
To see the current state of the server, type the command:
$ get dhcp server cfg
10.2.6
DHCP- DNS Relay Interaction
The DHCP server indicates the DNS Server addresses to DHCP
clients in the following manner.
If the primary/secondary DNS addresses are provided as part of the pool configuration
(using the DNS and SDNS parameters in the create/ modify dhcp server pool commands),
then these are indicated to the client.
If the DNS and SDNS addresses are not specified in the pool configuration, then one of the
following cases will arise.
If the DNS relay is enabled, the DHCP server gives the modem’s LAN IP address as the
DNS server address to the clients.(The actual DNS servers are learned by the
modem, dynamically, via the PPP link. These can be viewed using the get dhcp
server cfg command.)
If the DNS relay is disabled, the DNS addresses indicated to the client are the ones that
are dynamically learned from the PPP link. That is, they are the same as the ones
displayed by the get dhcp server cfg command.
10.2.7
Viewing DHCP Server Address Assignments
Once the server starts assigning IP addresses to clients, you can
see the currently allocated addresses.
To see the currently allocated addresses, type the command:
$ get dhcp server address
10.3 Configuring DHCP Relay
To use the ISP’s DHCP server, you can configure the unit to act as
a DHCP relay agent. As a relay agent, the unit forwards DHCP
requests from the LAN hosts on to the ISP. The ISP’s DHCP server
then sends back IP addresses and other configuration information,
which the unit forwards to the LAN hosts.
To configure the unit as a DHCP relay agent, you first specify the
interfaces on which the unit will listen for DHCP requests and
responses. Then, you enable DHCP relay mode.
10.3.1 Configuring the DHCP Relay Interfaces
The unit’s LAN interface must be enabled for DHCP relay in order to
receive requests from the LAN hosts for IP information. If multiple
LAN interfaces are defined on the unit, the DHCP relay service can
be enabled on each interface simultaneously.
To receive responses from the ISP, the unit’s WAN interface must
also be enabled for DHCP relay. The WAN interface could be a
PPP, EoA, or an IPoA interface.
Specifying the DHCP Relay Interfaces
To specify that the unit will receive DHCP requests on the LAN (eth-0) interface and the
WAN (ppp-0) interface, enter these commands:
$ create dhcp relay intf ifname eth-0
$ create dhcp relay intf ifname ppp-0
Viewing DHCP Relay Interfaces
To see all the interfaces on which DHCP relay is enabled, type the command:
$ get dhcp relay intf
- 81 -
10.3.2
Specifying the DHCP Server IP Address
You can specify the IP address of the DHCP server by modifying the
DHCP relay configuration. It is not mandatory to configure this
address. The ISP should be able to route the request to the
appropriate server. If you assign the DHCP server IP address, you
should also define a route in the unit’s IP routing table.
Specifying the DHCP Server IP address
To specify the IP address of the ISP’s DHCP server (202.64.23.4 in this example), use the
command:
$ modify dhcp relay cfg ip 202.64.23.4
10.3.3 Enabling DHCP Relay Mode
To enable the DHCP relay use the command:
$ modify dhcp relay cfg enable
You can enable only one DHCP server or relay at a time. To enable DHCP relay, the DHCP server must be
disabled.
To see the current configuration of the DHCP relay agent, type the command:
$ get dhcp relay cfg
- 82 -
10.4 Using a DHCP Server on the LAN
If the unit is connected to a LAN that uses one of its own hosts as
the DHCP server, the unit’s LAN interface must be configured as a
DHCP client so that it also gets its LAN-side IP address from the
server.
Specifying the LAN interface as a DHCP client
To configure the modem’s LAN interface as a DHCP client, create an ethernet interface
without specifying an IP address. To do so, use the command:
$ create ethernet intf ifname eth-0 usedhcp true
To see the state of the DHCP client, type the command:
$ get dhcp client info ifname eth-0
The Status field will show Bound, once the modem has obtained an IP address from the
DHCP server.
To see the actual IP address assigned to the modem, type the command:
$ get ip address
This command shows the IP addresses assigned to all the modem’s interfaces. The entry for
eth-0 will show the IP address assigned to the modem by the DHCP server.
10.5 DHCP Traps
The DHCP server not only provides automatic configuration for LAN
hosts, but also watches for potential errors in configuration and
informs you about them via the following traps.
10.5.1
Duplicate IP Address Trap
The duplicate IP address trap may occur when the unit is operating
as a DHCP server. Before assigning an address to a requesting
host, the unit probes the LAN to see if another host on the LAN is
already using the address. If so, the server raises a duplicate IP
address trap and assigns the next available address to the host.
10.5.2
Low Threshold Hit Trap
This trap is generated when the number of available IP addresses in
a DHCP pool is below the low threshold assigned to the pool. For
10.6 ForceRenew
- 83 -
instructions on setting the threshold value, please refer to the
create dhcp server pool command.
ForceRenew is supported by the DHCP server configured at the
modem, according to RFC 3203. If DHCP client(s) also support
ForceRenew, it is possible to increase the lease time defined in the
pool. Authentication, as defined in RFC 3118, should also be sent in
a ForceRenew message. At the client end too, there should exist a
mechanism to configure authentication information to use
ForceRenew procedure effectively.
- 84 -
11 Simple Network Time Protocol
11.1 Overview
The SAR110 software implements Simple Network Time Protocol
(SNTP), Version 4, RFC 2030, to enable it to periodically
synchronize its clock with a reference clock on the Internet. The
firewall feature of the modem requires synchronized wall clock time.
Firewall rules, which triggers a particular instance of time, require the
triggering time to be absolute, i.e., hr:min:sec, mm/dd/yyyy, or
periodic. Absolute time refers to an exact and particular point in time,
while Periodic time indicates the lapse of time with reference to a
pre-defined moment in time. This time synchronization protocol
(SNTP) enables the wall clock time to be first initialized on the
modem. Subsequently, SNTP enables the wall clock time to remain
synchronized with an external reference clock on the Internet.
Simple Network Time Protocol (SNTP) is a simplified adaptation of
the Network Time Protocol (NTP), that is used to synchronize
computer clocks on the Internet. SNTP exchanges timekeeping
information between servers and clients via the Internet. Extremely
reliable sources, such as radio clocks and GPS satellite timing
receivers, typically act as primary servers.
The SNTP client sends a request to a designated server at its
unicast address and expects a reply. This reply helps it to determine
the time and optionally, the round-trip delay and local clock offset,
relative to the server.
SNTP uses User Datagram Protocol (UDP) for the transport and the
UDP port number assigned to SNTP is 123.
11.2 SNTP implementation details
The SNTP client, at the modem end, sends an SNTP request to the
SNTP server for synchronization. The user can configure up to five
SNTP servers, and the SNTP client sends an SNTP request to the
first SNTP server in the list. If this server stops responding then the
server mentioned in the next entry, is contacted. These periodic
requests help the modem SNTP clock to be synchronized with the
Network Time.
Synchronization Request and Response
- 85 -
Polling Interval and Packet Time-out
The SNTP Polling Interval, or the time after which an SNTP request
is sent, can be between 64 seconds to 1024 seconds, both
inclusive. The polling interval adjusts automatically, depending on
the clock drift.
The maximum number of retries, in case of no response from
server, is 2. The wait time for the response, or the packet time-out is
5 seconds.
Response validation
Validation of responses from the server occurs at the modem end. A
response is rejected if:
the timestamp stored at the time of sending request does not match with the
Originated Timestamp field of SNTP response.
the deviation (calculated from SNTP response) in local clock is more than the polling
interval.
Amortization
The very first time synchronization happens, the local clock is simply
set to the server time. Very sudden or large changes in time never
occur, due to amortization. If the local clock is lagging behind the
Network clock, for less than a second, the local clock may jump to
cover the lagging time. However, if the gap is more than one
second, the time gradually increments at the local clock end, over a
period of time, which is divided in to smaller synchronization periods.
If the local clock is leading, it does not go back to get synchronized
with the network time.If the local clock is leading by 1 second or less,
it will pause for the leading time period. If it is leading for a value
greater than 1 second, it will gradually decrement the time. In this
scheme whole synchronization period will be divided in to time
intervals, and the time change will gradually occur over smaller
synchronization periods.
Alarm Timer
It is possible to set periodic and one-shot alarms, synchronized with
the network time, on applications connected to the modem. It is also
possible to set the absolute time alarm system.
The system clock cannot be configured using CLI commands, while SNTP is enabled. You must first
disable SNTP before modifying the system clock. All the SNTP time-based alarms will be affected by this
operation. They will either expire early or late. Also, few may expire simultaneously.
- 86 -
11.3 Configuration details
Enabling or Disabling SNTP service
To modify the SNTP configuration, enter:
modify sntp cfg [enable | disable]
Configuring SNTP server address
To configure the SNTP server address, enter:
create sntp servaddr <ip-address> | dname <domain-name>
To delete the SNTP server address you have configured, enter:
delete sntp servaddr < ip-address | dname domain-name >
Obtaining SNTP server address information
To get SNTP server address information, enter:
get sntp servaddr [<ip-address> | dname <domain-name>]
Obtaining SNTP configuration information
To get SNTP configuration information, enter:
get sntp cfg
This command indicates whether the SNTP service is enabled or
disabled.
Obtaining SNTP statistical information
To get statistical information about SNTP, enter:
get sntp stats
This command displays
the number of SNTP Requests sent to the SNTP server
the number of valid SNTP responses received from the SNTP server
the number of invalid SNTP responses received from the SNTP server
the number of lost responses against the SNTP request
the time at which the local clock was last set or corrected.
To reset SNTP statistics, enter:
reset sntp stats
- 87 -
Resetting SNTP statistics
- 88 -
12 Layer 2 Security
Traffic flowing towards the modem can be blocked or filtered at
different levels. Bridge mode (layer 2) traffic does not reach the IP
layer (layer 3), and therefore requires its own security settings. This
chapter describes methods for filtering traffic at layer 2. These
include,
Configuring raw filters
Protocol blocking
Implementing L2 Wall
12.1 Raw Filtering – Overview
This section provides details about the SAR110 unit’s raw filtering
capability and how to configure the rules and subrules for raw
filtering.
The SAR110 unit’s raw filtering feature allows it to examine each
packet traveling in either direction (incoming or outgoing) and to filter
out packets based on rules and subrules that you define. Because
the raw filter scans packets at the layer 2 level (e.g., Ethernet), it can
be used with either operating mode (i.e., bridge or router).
You can specify multiple rules, each with one or more subrules that
apply only to that rule. Each rule tells what to do (accept or deny) to
a packet that is moving in the specified direction (incoming or
outgoing) on the specified interface, if that packet also matches the
pattern(s) specified by the rule’s subrule(s).
Each rule and subrule is also assigned an ID number. Rule IDs must
be unique; subrule IDs must be unique within a rule. Like NAT rules,
these ID numbers determine the order in which rules are
evaluated—from lowest to highest number. A rule’s subrules are
evaluated in this manner as well.
To allow you to retain full control over the order of rule evaluation, do not number rules/subrules
consecutively, e.g., 1, 2, 3, etc., but in increments, e.g., 10, 20, 30, etc. This will allow you to insert more
rules/subrules between the existing ones at a later time. If you number your rules/subrules consecutively,
you will have to delete and recreate all existing rules that are to follow the new rule.
When raw filtering is enabled, the unit scans the raw filter rules
whenever a packet is received; if a rule is found that matches the
packet, the packet is accepted or denied as specified by the rule.
- 89 -
A rule is said to match the packet only if all of its subrules match the
packet. This is true whether a rule has one or many subrules. If a
subrule is found that does not match the packet, that rule is skipped.
If none of the rules matches the packet, the default action is taken
for that packet. The default action is specified as part of the raw filter
global configuration.
The maximum number of rules and subrules is determined by the
maxpfrawrule and maxpfrawsubrule parameters in the size
command.
12.1.1
Using Raw Filtering Rules and Subrules
Rules specify, at a minimum, the interface and direction to be
monitored, and the action to take if a packet matches the rule.
Subrules specify the actual pattern to be searched for in each
packet.
12.1.1.1 Commands for rules
The basic commands used to create, modify and delete raw filter
rules are described below.
Creating a raw filter rule
To create a raw filter rule, enter:
$ create pfraw rule entry ruleid 100 ifname ppp-0 dir in enable log
match act deny
It is also possible to specify an interface type, either private, public, or demilitarized, while specifying a
rule for an interface type. For LAN interfaces such as Ethernet, you can specify private interfaces. For
WAN interfaces, you can specify public interfaces.
$ modify pfraw rule entry ruleid 100 act accept
This command creates a rule with rule ID 100 on interface ppp-0, for
packets traveling in the incoming direction (dir in). The enable
parameter indicates that the rule is enabled; log match indicates that
all matching packets will be logged, and act deny indicates that if a
packet matches the rule, the action is to deny the packet.
Modifying a raw filter rule
To modify a rule, enter:
Deleting a raw filter rule
- 90 -
To delete a rule, enter:
$ delete pfraw rule entry ruleid 1
In order to delete a rule, you must first delete all of its subrules. (For information on deleting a subrule,
refer to the following section.)
12.1.1.2 Commands for subrules
The basic commands used to create, modify and delete raw filter
subrules are described below.
Creating a raw filter subrule
To create a subrule, enter:
$ create pfraw subrule entry ruleid 100 subruleid 10 start linkh
offset 0 mask 0xffffffffffff cmpt eq 0xffffffffffff enable
This creates subrule 10 of rule 100. This subrule examines packets
at an offset of 0 relative to the link layer header. If masking with
0xffffffffffff gives a result of 0xffffffffffff, the match is successful and
the packet is accepted or denied as specified by rule 100.
Modifying a raw filter subrule
To modify a subrule, enter:
$ modify pfraw subrule entry ruleid 100 subruleid 10 disable
Deleting a raw filter subrule
To delete a subrule, enter:
$ delete pfraw subrule entry ruleid 2 subruleid 1
12.1.1.3 Displaying rule/subrule configuration
The basic commands used to show the current configuration of rules
and subrules are described below.
Viewing raw filter rules
To see the configuration of all rules and subrules,
enter:
$ get pfraw rule info
To see the configuration of rules applicable to
- 91 -
incoming packets on a particular interface, such as eth0, enter:
$ get pfraw rule info ifname eth-0 dir in
To see the configuration of rules applicable to
outgoing packets on a particular interface, such as eth-0,
enter:
$ get pfraw rule info ifname eth-0 dir out
Example
The following rule and subrule can be used to block all incoming
Telnet requests on the ppp-0 interface:
$ create pfraw rule entry ruleid 200 ifname ppp-0 dir in act deny log
match enable
$ create pfraw subrule entry ruleid 200 subruleid 20 mask 0xffff start
tcph offset 2 cmpt eq 0x0017 enable
The subrule matches packets with the value 0x0017 (the Telnet port
number) at offset 2 in the TCP header; the rule specifies that the
action is deny; thus, all incoming Telnet packets will be dropped.
12.1.2 Raw Filtering Global Configuration
To enable or disable raw filtering and to set the
default action, enter:
$ modify pfraw global enable accept
This command enables raw filtering and specifies that the default
action (i.e., the action taken if no rules are matched) is to accept the
packet.
Do not enable raw filtering without first configuring raw filter rules.
Do not enable raw filtering without first configuring raw filter rules.
12.2 Protocol Blocking
The protocol blocking feature is provided for end users to have a
simple way of preventing certain protocols from being trasmitted on
their network (i.e., without having to create IP filter or raw filter rules).
In the Web-based interface, users simply click on the protocol by
name to enable it to be blocked; an the software invokes an IP filter
or raw filter rule already defined in the system.
- 92 -
Note:
by name that they want to prevent from a protocol displaying a set
of protocols in the HTTP a simple way for you to stop certain
protocols from transmission, without having to create a raw filter or
IP filter rule (in fact, the blocking command simply invokes the
corresponding built-in filtering rules).
To view the list of protocols that have predefined
filter rules, use the following command:
$ get pfraw block?
To modify the pfraw blocking status for the PPPoE
protocol, for example, enter:
$ modify pfraw block protocol ppe enable
12.3 L2 Wall
The SAR110 software supports the L2 Wall security feature, which
allows a LAN host to prevent accesses to it when the user is not
using the Internet.
When active, L2 Wall causes all packets incoming to the host to be
dropped, except for packets whose protocols have been specified
as “transparent” to the L2 Wall. For example, DHCP and ARP can
be specified as transparent protocols to allow DHCP renewals and
ARP requests.
In this chapter, the term “dropped traffic” does not include transparent traffic.
12.3.1 Overview
L2 Wall has three modes, which can be set by the end user:
On
Off
Automatic
When L2 Wall is On, no traffic may pass to or from the host. When
L2 Wall is Off, all traffic may pass in both directions.
In Automatic mode, L2 Wall is activated and deactivated
automatically, depending on whether there has been recent nontransparent traffic in the outgoing direction. Whenever such traffic is
transmitted, a timer is set. If the timer expires without further
outgoing traffic, L2 Wall is activated and no further incoming traffic is
allowed. When the host again sends outgoing non-transparent
traffic, L2 Wall is deactivated and the timer is reset.
- 93 -
The timer counts down an interval called the activation time, which is
set by the user and can vary from 1 minute up to 1 day. During this
interval, traffic can pass in both directions.
12.3.2
Configuration Files
L2 Wall filtering is controlled by three configuration files that are
merged into the software image when you create it using the
Createfi utility:
In the factory defaults file TEFacs.txt, you set L2 Wall
to automatic mode (unless already set by default in the
software), and then add CLI commands that create raw
filtering rules to be activated when the L2 Wall is on. These
rules allow certain types of traffic (i.e., trasparent traffic) to be
passed even though the L2 Wall is on. See section for
instructions on creating raw filter rules.
The text file l2wall_on.cfg contains a CLI command that
configures the raw filtering global setting to deny all traffic.
You add commands that enable the raw filtering rules defined
in TEFacs.txt that configure transparent traffic.
The text file l2wall_off.cfg contains a CLI command that configures
the raw filtering global setting to accept all traffic. You add CLI
commands that disable the same raw filtering rules that were
enabled in l2wall_on.cfg.
Whenever the L2 Wall mode is set to On, the system executes
l2wall_on.cfg, and whenever the mode is set to Off, the system
executes l2wall_off.cfg.
The file l2wall_on.cfg turns on the raw filter, specifying that
packets not matching any raw filtering rules should be dropped, and
defines the raw filter rules to be applied, while l2wall_off.cfg
deletes the raw filter rules created by l2wall_on.cfg. The rules in
l2wall_on.cfg thus define the “transparent” protocols, i.e., those
protocols that can pass through while L2 Wall is active.
L2 Wall can be controlled by the following CLI commands
(described in the CLI Reference Manual):
modify L2wall cfg
get L2wall cfg
12.3.3
AutoDetect Algorithm
The basic algorithm for the L2 Wall feature is as follows.
If (L2Wall is OFF) OR
(L2Wall is AUTO) AND (time since last activity < activation time)
Continue operating normally (i.e. bridged traffic)
Elseif (L2Wall is AUTO) AND (time since last activity > activation time)
If the packet’s protocol is transparent to L2Wall
- 94 -
//i.e. the protocol is enabled in l2wall_on.cfg
Forward the packet //from LAN to WAN or vice versa
Else //not a transparent protocol
If packet originated from LAN
Reset the time since last activity
Apply l2wall_off.cfg to disable filter rules
Forward the packet to the WAN
Else //packet originated from WAN
Packet is dropped due to filter in l2wall_on.cfg
Endif
Endif
Else //L2Wall is ON
If the packet’s protocol is transparent to L2Wall
//i.e. the protocol is enabled in l2wall_on.cfg
Forward the packet //from LAN to WAN or vice versa
Else //not a transparent protocol
Packet is dropped due to filter enabled in l2wall_on.cfg
Endif
Endif
12.3.4 Assumptions
L2 Wall assumes the following to be true:
The SAR110 unit is operating in bridging mode.
12.3.5 Sample Configuration Files
Below shows an example of a factory defaults file that configures the
L2wall feature in automatic mode, sets the timer to 5 minutes, and
establishes rules for enabling transparent traffic.
.
.
modify l2wall cfg auto inacttime 5
create pfraw rule entry ruleid 1 ifname all dir in enable act accept log match
create pfraw subrule entry ruleid 1 subruleid 1 mask 0xFFFF start linkh offset
12 cmpt eq 0x0806
create pfraw rule entry ruleid 2 ifname all dir out enable act accept log match
create pfraw subrule entry ruleid 2 subruleid 1 mask 0xFFFF start linkh offset
12 cmpt eq 0x0806
create pfraw rule entry ruleid 3 ifname all dir in enable act accept
create pfraw subrule entry ruleid 3 subruleid 1 mask 0xFFFF start linkh offset
12 cmpt eq 0x8863
create pfraw rule entry ruleid 4 ifname all dir out enable act accept
create pfraw subrule entry ruleid 4 subruleid 1 mask 0xFFFF start linkh offset
12 cmpt eq 0x8863
create pfraw rule entry ruleid 5 ifname all dir in enable act accept
create pfraw subrule entry ruleid 5 subruleid 1 mask 0xFFFF start udph offset 0
cmpt range 0x43 0x44
create pfraw rule entry ruleid 6 ifname all dir out enable act accept
create pfraw subrule entry ruleid 6 subruleid 1 mask 0xFFFF start udph offset 0
cmpt range 0x43 0x44
create pfraw rule entry ruleid 7 ifname eth-0 dir in enable act callmgmt log
match
create pfraw subrule entry ruleid 7 subruleid 1 mask 0xFFFF start linkh offset
12 cmpt eq 0x0800
create pfraw rule entry ruleid 8 ifname eth-0 dir in enable act callmgmt
create pfraw subrule entry ruleid 8 subruleid 1 mask 0xFFFF start linkh offset
12 cmpt eq 0x8864
.
.
Below shows an example l2wall_on.cfg file that globally denies all
traffic, and then enables the raw filter rules in TEFacs.txt that allow
specific types of transparent traffic.
modify pfraw global deny
modify pfraw rule entry ruleid 1 enable
modify pfraw rule entry ruleid 2 enable
modify pfraw rule entry ruleid 3 enable
modify pfraw rule entry ruleid 4 enable
modify pfraw rule entry ruleid 5 enable
modify pfraw rule entry ruleid 6 enable
modify pfraw rule entry ruleid 7 enable
modify pfraw rule entry ruleid 8 enable
exit
Below shows an example l2wall_off.cfg file that globally accepts all
traffic and disables the raw filter rules.
modify pfraw global accept
modify pfraw rule entry ruleid 1 disable
modify pfraw rule entry ruleid 2 disable
modify pfraw rule entry ruleid 3 disable
modify pfraw rule entry ruleid 4 disable
modify pfraw rule entry ruleid 5 disable
modify pfraw rule entry ruleid 6 disable
modify pfraw rule entry ruleid 7 disable
modify pfraw rule entry ruleid 8 disable
exit
- 95 -
- 96 -
13 Layer 3 Security
Layer 3 filtering at the IP layer enables easier configuration, as it
allows working with various fields in the IP header. Also, as more
information about the traffic flow is available at this layer, it allows
you to provide increased protection.
To enable this protection, you need to configure NAT, Firewall and
IP Filter.
13.1 NAT
This section describes how to create and use Network Address
Translation (NAT) rules and application level gateways (ALGs).
A NAT rule specifies when and how to translate IP addresses. As
data packets are received on the unit’s interfaces, data in their
protocol headers is compared to criteria established in the NAT
rules. The criteria includes ranges of source or destination
addresses. If the packet meets the criteria of one of the rules, the
packet header undergoes the translation specified by the rule and
the revised packet is forwarded. If the packet does not match any
rule criteria, it is forwarded without translation.
Six types, or flavors, of NAT rules are supported. They are: basic,
napt, filter, rdr, bimap, and pass. The most commonly used flavors
are napt and rdr. NAPT rules are used to translate multiple private
addresses on a LAN to a single public IP address for external
communication. An rdr rule can be used to allow external access to
a privately addressed LAN computer. The flavors are described in
sections through .
Application Level Gateways
Creating rules is sufficient to handle most applications. However,
applications such as FTP, H.323, Real Audio, CUseeMe, and others
require additional configuration in the form of application level
gateways (ALGs). These applications require ALGs because their
payloads—not just the packet headers—contain IP addresses.
When an ALG is configured, NAT translations occur not only on data
in a packet’s header, but also on data in the packet’s payload.
The list here details ALGs supported by the modem.
ALGs for Protocols and Applications
- 97 -
ALG
FTP TCP 21
SNMP UDP 161
H.323 TCP 1720
L2TP UDP 1701
PPTP TCP 1723
RTSP TCP 554
MSN Messenger TCP 1863
MIRC TCP 6661 to 6669
H225 RAS TCP 1719
CuSeeMe TCP 7648
NetMeeting An application which
RealPlayer TCP 7070
Timbuktu 200 UDP 407
RCMD TCP 514
SGI-VoD UDP 6301
T.120 Not configurable
LDAP TCP 389
PROTOCOL PORT
uses
H323,H245,LDAP,T120
etc.
externally
ALGs for Games:
Quake
Asheron Call
Delta Force
Half Life
Heretic II
Diablo
Star Craft
13.1.1 Default NAT Configuration on the SAR110 Unit
By default, NAT is enabled on the SAR110 reference unit, with an
napt rule that translates all LAN side addresses to the public IP
address assigned to the PPP-0 interface.
The following commands are included in the default configuration file
to set this configuration:
$ create nat rule entry ruleid 1 napt
$ modify nat global enable
- 98 -
The first line creates a rule of type napt (Network Address Port
Translation) and assigns it a rule ID of 1. The second line enables
the NAT service.
For more information about the default configuration, see Chapter .
13.1.2
Configuring NAT Direction
NAT distinguishes between inside interfaces and outside interfaces.
An inside interface is one on which you can use private IP
addresses. An outside interface is one on which you can use only
public IP addresses. Usually, the Ethernet is the inside interface and
the PPP or EoA interfaces are the outside interfaces.
The direction of an interface is used to determine how to apply NAT
rules. The basic, napt, filter, and pass rules manage the address
translation for connections initiated from the inside interface and
destined for the outside interface. These rules also translate the
responses coming from outside to inside. The rdr rules manage
address translations for connections initiated from the outside and
destined for the inside interface. The bimap rule is unique because it
works in both directions. You can use it for inside to outside as well
as outside to inside connections. The pass rule is helpful when you
want specific inside to outside connections passed through the unit
without any change.
A connection, as used here, is simply a network access from one
side of the unit to the other. A web browser on the LAN that
accesses a web site on the WAN would be an inside to outside
connection.
Configuring the NAT Direction
You can specify the NAT direction of these interfaces directly, as
part of the corresponding create command. By default, the LAN
interfaces (Ethernet) have the direction as inside while the WAN
interfaces (PPP, EoA and IPoA) have the direction as outside.
For example, to configure the NAT direction, while creating the
Ethernet interface, specify the direction as inside.
$ create ethernet intf ifname eth-0 ip 192.168.1.1 mask 255.255.255.0
inside
13.1.3 The napt rule
A Network Address and Port Translation (napt) rule translates the
source address as well as the port number for inside to outside
connections.
To create a napt rule, type the command:
$ create nat rule entry napt ruleid 1
Although the command takes quite a few parameters, the default
values suffice in most cases.
Note that the rule is assigned a rule ID. Rules are scanned in order
of their rule IDs, lowest to highest. When the packet data does not
match a rule, the next rule is tested for a match. You should always
create NAT rules with gaps in the rule IDs so that you can add a
new rule that you want to be applied between two existing rules. For
instance, if you initially create two rules with rule IDs 10 and 20, then
later create another with rule ID 15, this new rule would be applied
after 10 but before 20. But if you had created the first two rules with
rule IDs 10 and 11, then this sequence would not be possible
without first deleting one of the rules.
- 99 -
Creating an napt Rule with a Rule ID
Viewing NAT Rules
To see the existing NAT rules, type the command:
$ get nat rule entry
You can specify a rule ID to view a specific rule:
$ get nat rule entry ruleid 1
Creating an napt Rule with All Parameters
The following command includes all parameters for creating an napt rule:
$ create nat rule entry ruleid 1 napt ifname ppp-0 lcladdrfrom 0.0.0.0
lcladdrto 255.255.255.255 glbaddrfrom 0.0.0.0 glbaddrto 0.0.0.0
The ifname parameter says that the rule is applicable to the ppp-0
interface. If you do not specify the interface, NAT assumes that the
rule is applicable on all outside interfaces.
The lcladdrfrom and lcladdrto parameters tell NAT which
outgoing packets to translate. If the source address in a packet lies
within the range specified by these two parameters, the match is
considered successful and the packet is translated using this rule.
Setting lcladdrfrom to 0.0.0.0 and lcladdrto to
- 100 -
255.255.255.255 indicates that rule will be matched for all packets
going out on the interface.
Suppose you have two subnets on the LAN: 192.168.1 and 172.25,
and you want NAT to work for only one of them - 192.168.1 (if for
example, the other subnet never needs to access the Internet).
Then, setting lcladdrfrom to 192.168.1.0 and lcladdrto to
192.168.1.255 will indicate that the translation is required only if the
first three numbers in the source IP address are 192.168.1.
The glbaddrfrom and glbaddrto parameters tell NAT what the
source addresses should be translated into. If the ISP provides a
fixed IP address, such as 202.1.1.1, then setting both
glbaddrfrom and glbaddrto to 202.1.1.1 will specify that the
source address should be translated into 202.1.1.1. Setting both to
0.0.0.0 indicates that you want the translated address to be the
address of the outgoing interface. This is used when the IP address
of the interface is not fixed. If glbaddrfrom and glbaddrto are
not the same, i.e., if they indicate a range of IP addresses, then the
translated address is chosen from among this range on a per
connection basis.
To delete a rule use the delete command and specify the rule ID:
$ delete nat rule entry ruleid 1
13.1.3.1 Configuring Port Numbers for napt
A napt rule translates the source IP address as well as the source
port number. The IP address to be used for translation is picked up
from the NAT rule parameters. The port numbers for translations are
specified using the portstart and portend parameters in the
modify nat global command. These parameters can be
modified only when NAT is disabled.
13.1.4
The rdr Rule
The rdr, or redirect, rule enables you to route incoming connection
requests referencing your public IP address and a specific port
number to a private IP addresses and port number on your LAN.
Suppose there is a web server installed on one of the LAN hosts. If
someone from outside tries to connect to this server, the connection
request will arrive on the unit with the same destination address as
the public IP address, 202.1.1.1. However, the web server on the
LAN has the address, say 192.168.1.3. NAT allows you to forward
such connections to the correct internal destination using the rdr
rule. To handle such a case, use the command:
Deleting a Rule
Loading...