AV200 Alma Autoconfiguration CXP-HD200-WMEFe ENG

Corinex AV200
Alma 5.0.0.1.1
Auto-configuration
Copyright
This document, as well as the software described in it, is furnished under license and
may be used or copied only in accordance with the terms of the license. The content
of this document is furnished for informational use only, it is subject to change without
notice, and it does not represent a commitment on the part of Corinex Communications
Corp.
Corinex Communications Corp. assumes no responsibility or liability for any errors or

inaccuracies that may appear in this document.
It is our policy to enhance our products as new technologies, hardware components,

software and firmware become available; therefore, the information contained in this
document is subject to change without notice.
Some features, functions, and operations described in this document may not be included
and sold in certain countries due to government regulations or marketing policies.
The use of the product or its features described in this document may be restricted or
regulated by law in some countries. If you are unsure which restrictions or regulations
apply, you should consult your regional Corinex office or the authorized reseller.
Published by:
1
Corinex Communications Corp.
1200-570 Granville St.
Vancouver, B.C.
Canada V6C 3P1
Tel.: +1 604 692 0520
Fax: +1 604 694 0061
Corinex is a registered trademark of Corinex Communications Corp.

Microsoft, MS-DOS, MS, Windows are either registered trademarks or trademarks of
Microsoft Corporation in the U.S.A. and/or other countries.
All products or company names mentioned herein may be the trademarks of their
respective owners.
Copyright (c) 2001-2010 by Corinex Communications Corp.
2010-11-05 ver. 4.2
Corinex ALMA Auto-configuration

End User License Agreement
CORINEX COMMUNICATIONS CORPORATION

This End User License Agreement (“EULA”) is a legal agreement between you and CORINEX
COMMUNICATIONS CORPORATION (“CORINEX”) with regard to the copyrighted Software
provided with this EULA.
Use of any software and related documentation (“Software”) provided with a CORINEX hardware
product, or made available to you by CORINEX via download or otherwise, in whatever form or media,
will constitute your acceptance of these terms, unless separate terms are provided by the software
supplier, in which case certain additional or different terms may apply. If you do not agree with the terms
of this EULA, do not download, install, copy or use the Software.
1. Licence Grant. CORINEX grants to you a personal, non-transferable and non-exclusive right to use
the copy of the Software provided with this EULA. You agree you will not copy the Software except
as necessary to use it on a single hardware product system. You agree that you may not copy the
written materials accompanying the Software. Modifying, translating, renting, copying, transferring
or assigning all or part of the Software, or any rights granted hereunder, to any other persons, and
removing any proprietary notices, labels or marks from the Software is strictly prohibited. Furthermore,
you hereby agree not to create derivative works based on the Software. You may permanently transfer
all of your rights under this EULA, provided you retain no copies, you transfer all of the Software, and
the recipient agrees to the terms of this EULA. If the Software is an upgrade, any transfer must include
all prior versions of the Software.
2. Copyright. The Software is licensed, not sold. You acknowledge that no title to the intellectual property
in the Software is transferred to you. You further acknowledge that title and full ownership rights to 2
the Software will remain the exclusive property of Corinex Communications Corporation and/or its
suppliers, and you will not acquire any rights to the Software, except as expressly set forth above. All
copies of the Software will contain the same proprietary notices as contained in or on the Software.
3. Reverse Engineering. You agree that you will not attempt, and if you are a corporation, you will use
your best efforts to prevent your employees and contractors from attempting to reverse compile,
modify, translate or disassemble the Software in whole or in part. Any failure to comply with the above
or any other terms and conditions contained herein will result in the automatic termination of this
license and the reversion of the rights granted hereunder to CORINEX.
4. Disclaimer of Warranty. The Software is provided “AS IS“ without warranty of any kind. CORINEX
and its suppliers disclaim and make no express or implied warranties and specifically disclaim warranties
of merchantability, fitness for a particular purpose and non-infringement of third-party rights. The
entire risk as to the quality and performance of the Software is with you. Neither CORINEX nor its
suppliers warrant that the functions contained in the Software will meet your requirements or that the
operation of the Software will be uninterrupted or error-free.
5. Limitation of Liability. Corinex’s entire liability and your exclusive remedy under this EULA shall not
exceed the price paid for the Software, if any. In no event shall CORINEX or its suppliers be liable to
you for any consequential, special, incidental or indirect damages of any kind arising out of the use or
inability to use the software, even if CORINEX or its supplier has been advised of the possibility of such
damages, or any claim by a third party.
6. Applicable Laws. This EULA will be governed by the laws of Canada, excluding its conflict of law
provisions.

End User License Agreement
7. Export Laws. This EULA involves products and/or technical data that may be controlled under any
applicable export control laws, and regulation, and may be subject to any approval required under such
laws and regulations.
8. Precedence. Except as set out above, where separate terms are provided by the software supplier,
then, subject to this EULA, those terms also apply and prevail, to the extent of any inconsistency with
this EULA.

Contents
Contents
1 Introduction 6
2 Prerequisites 7
3 Auto-configuration Overview 8
3.1 Auto-configuration at Modem Boot 9
4 PTTP Protocol 11
4.1 PTTP Booting 11
4.2 Incompatibilities 12
5 Translation Table 13
5.1 Transferring the Translation Table 14
5.2 Example of a Translation Table 14
5.3 Additional Information about PTTP Transfers 15
6 AV200 Nodes 17
7 Auto-configuration and Networking 18
7.1 VLAN Network Description 18
7.2 noVLAN Network 18
7.3 OVLAN Configuration and Root Interface 19 4
8 Auto-configuration Files 21
8.1 Introduction 21
8.2 Parameter Types 21
8.3 Parameter Format 21
8.4 Supported Parameters in Auto-configuration Files 22
9 NVRAM 47
10 Equipment Requirements 48
10.1 MV Equipment 48
10.2 LV Equipment 50
10.3 End User Equipment 51
11 Master-Side Access Protocol Processes & User Profiles 53
11.1 User Profiles 53
11.2 Working with RADIUS Authentication 53
11.3 Working without RADIUS Authentication 53
12 DHCP Support 55
12.1 DHCP Client 55
12.2 DHCP Server 55
12.3 DHCP Server Configuration File Example 56
13 RADIUS Support 57
13.1 RADIUS Client 57
13.2 RADIUS Server 57

Contents
14 Auto-configuration Console 60
14.1 Configuring Boot Mode from the Console 60
Appendix A: Auto-configuration Example 64
A.1 Setting Up the Equipment on the DHCP Server 65
A.2 Generating the Auto-configuration Files 66
A.3 Configuring the RADIUS Server 69
A.4 Preparing the Equipment 70
A.5 Placing the Equipment in the Field 70
Appendix B: VPN using Private OVLANs 71
Appendix C: “CUSTOM_VLAN_OVLAN” Examples 73

Introduction
1 Introduction
This document describes the auto-configuration of Corinex AV200 devices
running the Alma firmware. This includes the following products:
• Enterprise versions of the AV200 Powerline Ethernet Adapter, AV200

Powerline Ethernet Wall Mount, HD200 Powerline Wall Mount F,
AV200 CableLAN Adapter, HD200 CableLAN Wall Mount which will all be
designated as CPEs (Customer Premises Equipment) in this document
• Low Voltage Access Gateway (LV)
• High Density Access Gateway (HD)
• Medium Voltage Access Gateway (MV)
• GPON BPL Gateway
Some parameters for the auto-configuration are product specific. These

can be found in the general product manual delivered with each product.
6

Prerequisites
2 Prerequisites
This document assumes the following basic prerequisites and

information :
1. The network operator has the MAC address of each piece of network
equipment - prior to installation at electric meters or in customers’
homes.
2. Each piece of equipment has a reserved static management IP address

assigned by DHCP.
3. The network operator has detailed configuration information for each

piece of network equipment (associated with its PLC MAC) stored in a
database prior to installation. If this information is not available, a
default configuration can be utilized.
4. The Management VLAN for connected PLC equipment may be

different at each transformer, but no transformer will have more than
one Management VLAN. (The Management VLAN provides configuration
7
information to all of its hosted devices.)
5. There may be more than one Data VLAN per transformer.
6. Only the end user devices (CPEs) can connect to different transformers.
However, if a CPE is not a generic CPE (meaning it’s on a private VLAN or
private OVLAN), this CPE can only connect to its assigned transformer
and MDU Gateway.
7. Adding a new, non-generic CPE requires manual configuration over

all access equipment. Automatic VLAN/OVLAN reconfiguration is not
allowed.
8. Every MV node has a specific configuration file. The MV node gets the
translation table from this file and distributes it to all connected LV
nodes.
9. The transformer of each MDU Gateway and LV Gateway is known. The

MDU and LV repeaters cannot switch over to other transformers.

Auto-configuration Overview
3 Auto-configuration Overview
The objective of the auto-configuration process is to centralize the
management of an AV200 network using configuration files stored in a
database. These files are transferred to each piece of network equipment
at startup. These files contain all of the information and instructions that a
modem needs in order to function as expected.
Below is a brief description of this process :
1. Every modem starts with the same default factory configuration:

Access CPE.
2. Using PTTP (explained later in this document), the modem discovers if

it is booting into a network with VLANs or not. If a network has been
built using VLANs to isolate traffic between data, and management
traffic, it is necessary to know the Management VLAN of that network
segment, in order for the DHCP request to reach the backbone. The
information passed between modems during PTTP is called the
translation table.
8
3. Using DHCP protocol, each modem gets an IP configuration (IP address,
netmask and gateway), the phone number (in the case of CPEs), and the
name of the corresponding auto-configuration file.
4. Using TFTP protocol, each modem downloads the auto-configuration

file and configures the firmware accordingly.
The four points mentioned above are the main ones, but there is another
point to consider :
• In order to achieve a secure network, PLC authentication is introduced.

When a new slave is tries to access the PLC network by connecting to
a Master or Repeater, the Master or Repeater performs a RADIUS
request to authenticate the user. The RADIUS server replies with
information used to configure the Master’s interface to the new user.
The autoconfiguration also has a way to avoid using the RADIUS
server if desired, which consists of declaring a list of MACs, profiles
and FW types in the auto-configuration file and using this list
instead of RADIUS to authenticate users. See Sections 11 and 13 for
more Information on this topic.

If the modem is the first modem in the network and is connected to the
backbone directly through the Ethernet port, the process is different:
• This modem starts with the same default factory configuration:

Access CPE.
• Using DHCP protocol, each modem gets an IP configuration (IP
address, netmask and gateway, and the name of the corresponding
auto-configuration file). Also, there is another parameter called ifcp-
code, which indicates whether or not VLAN is used and the value of
the Management VLAN if needed. Once this parameter is obtained,
the PTTP protocol closes.
• Using TFTP protocol, the each modem downloads the autoconfiguration
file and configures the firmware accordingly.
3.1 Auto-configuration at Modem Boot

When any modem boots up, there is a parameter stored in the NVRAM
called GENERAL_USE_AUTOCONF. When this value is yes, the modem
boots in auto-configuration mode. When this value is no, the modem
boots in NVRAM mode. Within the auto-configuration boot mode there
are two possible bootup processes, depending on whether or not PTTP is 9
performed.
3.1.1 Auto-configuration-PTTP Boot
IIn this auto-configuration boot mode, the modem always starts up as a

Slave (CPE) and begins sending PTTP requests. When this protocol closes,
the modem has the minimum information necessary to successfully connect
to the backbone and execute DHCP and TFTP. The modem then sends a
DHCP request to get an IP configuration, the phone number (if required),
and the name of the auto-configuration file, as well as the TFTP server
where the file is located. Then it downloads the file and configures the
firmware accordingly.
3.1.2 Auto-configuration-noPTTP Boot
In this auto-configuration boot mode, the modem has already been

configured (see Section 4 for more information) to successfully execute
DHCP and TFTP, so it skips PTTP.
3.1.3 NVRAM Boot
When a modem starts in NVRAM mode, it collects all of the configured

parameters from NVRAM memory and configures the firmware

accordingly.
There are some basic parameters that are always configured in this mode:
• GENERAL_TYPE: Modem type – HE, CPE, or TDREPEATER.

• GENERAL_IP_USE_DHCP: Use DHCP – yes or no. If this parameter is
set to no, the IP configuration parameters and the phone number are
also configured from NVRAM.
All of the other parameters are only configured if they have been
downloaded from a file first, and a GENERAL_USE_AUTOCONF = no line
was in that auto-configuration file. This is equivalent to performing a Save
as Permanent.
10

PTTP Protocol
4 PTTP Protocol
The PTTP (Parametric Translation Table Protocol) is used to transfer the
translation table (explained later in this document) between modems
atbootup.
Although the translation table is comprised mainly of VLAN parameters,

there is one parameter that is not related to VLAN – the TRANSLATION_
ROOTPATH_OVLAN. Also in future versions, new parameters independent of
VLANs may be included in the translation table. Due to these circumstances,
it is advisable to discontinue the relationship between PTTP and the use of
VLANs.
With the current FW version, when a modem boots in auto-configuration

mode, it ALWAYS performs PTTP requests if a byte allocated in the NVRAM
has not been written (by default, the NVRAM is set to run the PTTP client).
4.1 PTTP Booting

When a modem boots in auto-configuration mode, it begins sending PTTP
requests. It does not know whether or not it is booting into a network 11
with VLANs and the modem needs to know this before requesting an IP
through DHCP. For this reason, and because the LV node does not know if
communication to the MV node is through PLC or Ethernet, and because if
communication is via Ethernet the LV node does not know the MAC address
of the MV node, the FW-to-FW protocol uses a special PTTP MAC (01:80:
C2:00:00:0E). The PTTP requests are processed as described below :
• Step 1: An PTTP request is made without VLANs and waits for

a response.
• Step 2: The modem switches to VLAN mode and makes an PTTP
request using tag #1 (reserved in the AV200 network) and waits for
a response.
• Step 3: Back to Step 1.
When a modem receives a packet with this PTTP MAC, the packet is sent to
the FW. In transmission, this request is forwarded to all active interfaces.
Finally it will connect to a node that will transfer the translation table. The
modem switches automatically to use or not use VLANs with the same
configuration as the node from which it receives the translation table.
In this way, all modems configure themselves to use or not use VLANs.

PTTP Protocol
Avoid writing the use or non-use of VLANs directly to the NVRAM of each
modem, because it will be extremely frustrating if an operator wants to
change the entire network to use VLANs and finds that it must be changed
on each modem individually.
A modem must not do PTTP (Auto-configuration-noPTTP Boot) in the

NVRAM in the following two cases:
• It is the first node of the network (directly connected to the

backbone).
• It will receive the translation table in the auto-configuration file.
In the first case, there is no other modem from which to request the
autoconfiguration file because it is the first modem on the network.
To avoid the use of PTTP at bootup, the following two methods are available:
• Using the DHCP server (must be accessible through VLAN #1 or

without VLAN), the PTTP protocol can be skipped. The server can
supply the modem with the Management VLAN in the DHCP reply
(if the modem is to boot in VLAN mode) or tell the modem not to use
VLANs. 12
• Write a byte to NVRAM via console. In this type of bootup, the

modem reads its instructions in NVRAM to check whether it should
use or not use VLANs. The Management VLAN (if needed), requests
an IP from the DHCP server and receives the auto-configuration file
via TFTP. This method is not advisable, because access to the console is
poor while PTTP is running, due to the change between VLAN and
noVLAN modes. So Method 1 should be used if possible.
To disable PTTP through DHCP (Method 1), see Section 12.
If no OVLANs/VLANs are to be used in the network, the PTTP protocol can

be disabled on all modems. To disable PTTP manually (Method 2), at the
next modem boot, see Section 14.1.3.
4.2 Incompatibilities
A Slave with this version of the ALMA firmware, which is not using VLANs,
will not work with a Master running ALMA v2.5. The reason for this is that
with the new FW version, the Slave always makes PTTP requests at bootup,
and for this reason, LV nodes always start their PTTP servers, whether using
VLANs or not. A Master with a previous FW version and VLANs turned off,
does not start the PTTP server to answer the requests of the Slave, so it will
not be able to complete this stage of the auto-configuration.

Translation Table
5 Translation Table
The translation table contains information about the VLAN/OVLANs used
for all nodes connected to the MV/LV equipment. (More parameters may
be added in future versions.) The auto-configuration file of each piece of
LV equipment is a parametric file, which means that, for example, the LV
equipment knows, from the auto-configuration file, that the VLAN DATA
OPERATOR 1 is allowed, but the device needs the number of this VLANDATA
OPERATOR 1 on the LV equipment.
See the following figure:
13
In the example in the figure above, Node A does not need any informa-
tion about translations because no LV nodes are connected at the HV/MV
substation.
Node B gets the auto-configuration file via TFTP. In the file, Node B gets the
translations for all LV nodes connected to it. This translation information
is different from the translation information used by Node C and the LV
nodes connected to it.
The translation file is useful because Node D and Node F might have the
same auto-configuration file, if the network operator prefers. This means,
for example, that the Data VLAN on Node D and Node F is DATA VLAN
OPERATOR 2, but the translation table that Node D gets from Node B

Translation Table
indicates that DATA VLAN OPERATOR 2 is VLAN 34, while the translation
table on Node F indicates that it is VLAN 55. From the point of view of the
network operator, this is easier than having two separate files for Node D
and Node F.
5.1 Transferring the Translation Table

The MV node reads instructions from NVRAM telling it to either perform or
not perform PTTP. If it is not to perform PTTP, the modem checks whether
it needs to use VLANs and a Management VLAN. It received the IP and
autoconfiguration file via DHCP. And finally, using TFTP, the MV node gets
the auto-configuration file with the translation table.
All LV nodes perform PTTP at boot (in the default boot mode), but they
have no VLAN information in NVRAM. LV nodes need this information be-
fore they request an IP through DHCP, and they also have to check whether
or not they are included in a VLAN network. So they perform PTTP as ex-
plained before.
As explained in Section 4.1, PTTP is performed in a mixed state (with VLAN

#1 and without VLAN). Eventually, one of the requests will succeed and 14
the nearest node will reply, transferring the translation table, which in-
cludes the following :
• Parameter “USE VLAN” (explained later) to fix the VLAN mode;

• Parameters related to VLAN (if needed), the main one being the
Management VLAN. If the parameter USE VLAN = 1, then the modem
configures itself to use the Management VLAN included in the
translation table;
• Parameter “TRANSLATION_ROOTPATH_OVLAN” (explained later).
NOTE: VLAN 1 is reserved in an AV200 PLC network.
5.2 Example of a Translation Table

TRANSLATION_MNMT_VLAN = 5
TRANSLATION_DATA_VLAN.1 = 10
TRANSLATION_ROOTPATH_OVLAN = 77

Translation Table
The node can be configured using this information and the autoconfigu-
ration file. When the node receives an auto-configuration file with the
following parameter,
VLAN_DATA_TAG = %DATA2
the correct value (11) is obtained from the translation table.
There is one mandatory parameter included in the translation table which

is not configurable by the user :
USE VLAN = [0|1]
If the modem is using VLANs, the parameter will be set to 1, otherwise the
parameter will be set to 0. This information is transferred when it receives
an PTTP request. This parameter tells the modem performing the PTTP re-
quest whether or not it needs to use VLANs.
5.3 Additional Information about PTTP Transfers

Exercise caution with PTTP when a modem is able to connect to modems 15
not belonging to its network, because they might have different VLAN
configurations (this may occur in MV rings or LV nodes that can commu-
nicate with MV nodes). The translation table transferred via PTTP might be
incompatible with the real network, of which the modem must remain a
member. To resolve this situation (where a modem receives PTTP from the
wrong Master), if the auto-configuration file downloaded by the modem
includes the translation table, this information is re-written, solving the
problem. That the modem temporarily has the wrong translation table is
not a problem, because even in this state, the modem should be able to
reach the backbone and download the necessary file.
Be careful with one issue: only the parameters declared explicitly in the
file are changed in the translation table; any parameters not declared will
retain the same values that were received via PTTP. This should not be a
problem, because all parameters in use on the network should be declared
explicitly, and any not declared, should not be in use.
For example, modem “A” has its translation table with the following val-
ues and transfers this information to modem “B”:
#Translation Table Modem A


Translation Table
After PTTP, modem “B” downloads its file including the following transla-
tion table:
#Translation Table in the Autoconf file on Modem B

Then the translation table that the modem will use, and the one it will
transfer if requested from another node, is as follows:
16
#New Translation Table on Modem B

AV200 Nodes
6 AV200 Nodes
There are several types of nodes in a PLC network, depending on the po-
sition in the line. The type of node is described using two parameters
– GENERAL_MAC_MODE, which indicates the MAC running on the mo-
dem (ACCESS or MV), and GENERAL_FW_TYPE, which indicates the role of
the modem in the network (MV, LV or EU).
• MV Network: The GENERAL_MAC_MODE in this case should be MV

and the GENERAL_FW_TYPE is also MV.
• LV Network: All run the LV Access MAC, but there are two types,
depending on the role they play in the network
» LV Nodes: These are modems installed at transformers, in meter
rooms, etc. They should be configured with GENERAL_MAC_MODE
set to ACCESS and GENERAL_FW_TYPE set to LV.
» EU Nodes (End User): These are the terminal nodes installed in
customers’ homes. The configuration of this modem is always ori
ented towards protection against harmful customer mistakes, and
this node should be associated with a QoS profile requested by the
customer. The configuration of GENERAL_MAC_MODE should be
set to ACCESS and the GENERAL_FW_TYPE set to EU. 17
The main differences between configuring a modem as EU or LV are as

follows:
• Local VLAN Configuration

» The EU node configures the Ethernet port as an ACCESS port, which
means that all traffic coming into the PLC network is untagged and
the EU modem will add the tag.
» The LV node will configure the Ethernet port as a TRUNK port with
a list of allowed tags in the translation table.
• Remote Profile Configuration: All EU nodes have a profile known by

their Master, and when a node enters the network, its Master reads
from the RADIUS server or its own list, the node type and the profile
assigned to the user. If the node is an:
» LV Node: The profile is not taken into account. The configuration
on the Master side for this node sets the PLC port to TRUNK with
all allowed tags from the translation table.
» EU Node: The configuration on the Master side for this node
depends on the profile that describes the VLAN and OVLAN
allowed for this user and the QoS configuration.

Auto-configuration and Networking
7 Auto-configuration and Networking

7.1 VLAN Network Description
The network model is described as follows:
• The PLC network is a switched network with different VLAN tags.

• The firmware of all nodes is in the Management VLAN and also in
VLAN 1. PLC management protocols (PTTP, BPC, etc.) use VLAN 1,
while high-level management protocols (DHCP, TFTP, HTTP, NTP, SNMP,
etc.) use the Management VLAN configured by the autoconfiguration
process. The Management VLAN may be different in different LV
cells.
• The End User node receives untagged traffic from the external
interface and this traffic is tagged with the correct Data VLAN,
according to the ISP operator to which the customer belongs, so it’s
possible to have more than one Data VLAN per LV cell.
• It is possible to add private VLANs between certain customers who
don’t have an ISP or voice operator. In this case, VLAN trunks must be
defined in the intermediary equipment, to allow this tagged traffic.
• All traffic is tagged on the PLC network. 18
Each AV200 node must receive its VLAN configuration in its autoconfigu-
ration file. In addition to this, and in order to reduce the number of auto-
configuration files for End User (EU) nodes, a translation table is trans-
ferred between nodes which contains information about the Management
and Data VLANs used in that LV cell.
7.2 noVLAN Network

The use of VLANs is not mandatory, but it is advisable for privacy reasons.
Nevertheless, this privacy can be implemented with other tools and the
operator may simply want to establish a LAN.
In this type of network, a modem will not have the problems of a VLAN
network. It will perform its PTTP requests, switch from VLAN 1 to noVLAN,
and finally, a Master will answer with the translation table that will, at a
minimum, contain the parameter “USE VLAN”.
Once the modem has received the translation table and does not need to
configure anything with regards to VLANs, it can complete the DHCP, TFTP
and configuration processes.

7.3 OVLAN Configuration and Root Interface

The basic OVLAN configuration in AV200 networks eliminates visibility be-
tween customers connected to the End User nodes in a simple way. All
customer data packets in an LV cell are tagged with the Rootpath OVLAN.
This tag is the only allowed tag in the entire path to the backbone. In the
path from the backbone to the customers, the packets are tagged with the
ALL_VLAN tag (4095), and no tag is allowed in this path. However, packets
with the ALL_VLAN tag are not filtered.
An example of the basic OVLAN configuration is shown in the figure on

the following page. OVLAN filtering is done with egress lists. The lists are
shown between {…}. The root interface lists are always filled with the
Rootpath OVLAN, while the other interfaces are void-allowed lists (only
packets with the ALL_VLAN tag are allowed). The result is that only the
specified downstream and upstream paths are allowed.
The root interface is discovered automatically as the root port of the span-
ning tree protocol, so the OVLAN can not function unless the STP is ena-
bled. When a node is the root node (the HE in the figure on next page for
instance), the root interface must be specified in the auto-configuration 19
file. It will always be one of the external interfaces.

20
So, in all of the end users, the following configuration must be set:
OVLAN_ENABLE = yes
OVLAN_DATA_TAG = %ROOTPATH
The node that connects to the backbone must have:
GENERAL_IFACE_ROOT = EXTA
…
OVLAN_ENABLE = yes
OVLAN_DATA_TAG = 4095

Auto-configuration Files
8 Auto-configuration Files
8.1 Introduction
Auto-configuration files contain the configuration parameters required to
configure each node.
In the case of MV nodes, there are no parametric values. MV autoconfigu-

ration files are specific to each node and contain the translation table for
the MV, LV and End User nodes connected to that MV node. Each MV node
has a unique auto-configuration file.
As stated before, LV, EU and certain MV nodes have parametric autocon-

figuration files. Any EU modem with no specificied Quality of Service or
VLAN/OVLAN configuration can use the same auto-configuration file. LV
nodes with no specific QoS or VLAN/OVLAN parameters should receive a
different generic file, a default LV auto-configuration file. The network
operator can use specific configuration files for non-generic LV, EU and
MV nodes.
21
8.2 Parameter Types
There are three types of parameters inside the autoconfiguration file:
1. Scalar: PARAMETER = value
2. List: PARAMTER.index1 = value
3. Table: PARAMETER.index1.index2 = value
The first valid index for lists and tables is 1.
8.3 Parameter Format

The format of concrete parameters is as follows:
• PARAMETER_LABEL[.x][.y] = value for constant parameter values.
• PARAMETER_LABEL[.x][.y] = %parametric_value for parametric

parameter values.
For example, the following parameter could be inside an end user auto-
configuration file:
VLAN_DATA_TAG = 452
or

In the second case, the parametric value must be translated to its correct
value using the translation table.
8.4 Supported Parameters in Auto-configuration Files

It is important that the order in which these parameters appear in the au-
toconfiguration file is preserved.
All of the parameters that do not appear inside the autoconfiguration files
keep their default values. Parsing is case-insensitive for parameter values
only (all values except ones like the RADIUS shared secret where there is a
difference between upper and lowercase letters).
8.4.1 General Parameters
• GENERAL_USE_AUTOCONF = [yes|no]
This is the first parameter in the autoconfiguration file. When this param-
eter is set to no, all of the parameters in the file are stored in the NVRAM
when the file is downloaded, and the node boots in NVRAM mode the
next time. Default value: yes.
22
WARNING: When the modem boots in NVRAM mode, PTTP is not
performed, so the translation table is not exchanged between differ-
ent nodes. It is mandatory to add the translation table to all files in
the network to configure the modem for booting from NVRAM.
• GENERAL_TYPE = [HE|CPE|TDREPEATER]
Configures the type of node. Default value: CPE
• GENERAL_FW_TYPE = [MV|LV|EU]
Configures the firmware type of the node. This parameter affects the QoS
and VLAN/OVLAN configuration. Default value: EU (it will be
automatically changed to LV if the node type is not a CPE).
• GENERAL_AUTHENTICATION = [RADIUS|AUTHLIST|NONE]
Authentication method:
» If RADIUS is selected, a RADIUS server is in charge of accepting
new users and assigning the profile and fw_type;
» If AUTHLIST is selected, authentication is done by checking a list
provided in the autoconfiguration file. This option avoids the
installation of a RADIUS server;
» If NONE is selected, all of the users are accepted.
Default value: NONE.

• GENERAL_MID = <0x0000 – 0xFFFFF>

Master ID (MID) is defined in the HE node and is propagated to all the
nodes of the network. When visibility with a neighbour network can
not be avoided different MID should be configured in order to avoid
possible interferences. Default value is the last two bytes of the MAC
in reverse order.
WARNING: This parameter is not configured by the autoconfigura-

tion module if autoconfiguration boot mode is NVRAM.
• GENERAL_STP = [yes|no]
Enables/disables the Spanning Tree Protocol in the node. Default
value: yes.
• GENERAL_COMMON_STP_EXTA = [yes|no]
Enables/disables the Common STP feature in Ethernet interface A
(EXTA). It only makes sense to use this parameter if VLANs are
enabled. If it is set to “yes”, STP packets will be released and accepted
through EXTA without VLAN tags (even if VLANs are enabled). If its
value is “no”, STP packets will be released with the management
VLAN tag (if VLANs are active).
23
WARNING: With this parameter enabled, all packets without VLAN

tags will be accepted through EXTA.
• GENERAL_COMMON_STP_EXTB = [yes|no]
Same as GENERAL_COMMON_STP_EXTA but for EXTB.
• GENERAL_IP_ADDRESS = <ddd.ddd.ddd.ddd>
IP address of the modem (for the next boot if DHCP is disabled).
• GENERAL_IP_NETMASK = <ddd.ddd.ddd.ddd>
IP netmask of the modem (for the next boot if DHCP is disabled).
• GENERAL_IP_GATEWAY = <ddd.ddd.ddd.ddd>
IP default gateway of the modem (for the next boot if DHCP is
disabled).
• GENERAL_IP_USE_DHCP = [yes|no]
The node does/does not use DHCP for the next boot if NVRAM mode
is used.
• GENERAL_SIGNAL_MODE = [1-14]
In HE: Signal mode for transmitting. Mode 9 does not exist; now the

same configuration corresponds to a mode 5 submode 4. Default

value: mode 6.
• GENERAL_SIGNAL_MODE_LIST.x = [1-14]
In CPE and TDREPEATER: The list represents the allowed signal modes
used by the Search Link to find a master. (x=1…12). CPE and TDERE
PEATER nodes that do not implement Search Link can use this
parameter, but only the last mode in the autoconfiguration file will
be taken into consideration. Default value: all modes allowed.
• GENERAL_SIGNAL_POWER_MASK = 00Ffa0(…)00FF
This parameter sets the power mask. Each pair of two characters
represents the attenuation for a carrier, so this parameter is 1536x2
characters long. Default value: 0A in all carriers.
WARNING: This power mask is only set after getting the file. When
the modem boots, it starts transmitting without power mask. There-
fore this is not a secure parameter to avoid interfering with radio-
amateur transmissions.
• GENERAL_SIGNAL_REG_POWER_MASK_ENABLE= [yes|no] 24
This parameter enables or disables the use of the Regulation Power
Mask (RPM). It is always saved in NVRAM to be used in the next boot
without need for the autoconfiguration file. The RPM notches should
be previously stored in NVRAM. By default the radio-amateur notches
are stored in the NVRAM.
• GENERAL_IFACE_ROOT = [EXTA|EXTB]
Root interface assignment. The root interface is the interface where
the autoconfiguration file is received. The system automatically
obtains the root interface from the STP root port, but in some cases
it must be fixed to EXTA or EXTB (for example when the node is the
STP root).
The STP bridge priority in AV200 modems has been modified in the 2
bytes reserved by the standard in the following way:
0x9010 MV MASTER
0x9020 MV TDREPEATER
0x9030 LV MASTER
0x9040 LV TDREPEATER
0x9050 LV CPE

The tree topology of the STP can be affected by FD repeaters (MV or

LV) because it is compounded by a master modem. To avoid this
happening, when the parameter GENERAL_IFACE_ROOT is defined,
the 2 bytes reserved will change to:
( (MV MASTER) – 0x8) = 0x9008 for MV nodes

( (LV MASTER) – 0x8) = 0x9028 for LV nodes
In this way, a stand-alone master will have preference over a master

allocated in a FD repeater, regardless of its particular MAC.
• DISABLE_EXTA = [yes/no]
This parameter enables or disables EXTA interface. Default value: no.
• SIGNAL_SUB_MODE = [0| 2| 4| 6]
In HE: Signal mode for transmitting.
Each mode has several submodes: 0, 2, 4 and 6. 0 is the default
submode and is equivalent to the current definition of mode. The
characteristic that distinguishes the submodes is that every submode
cannot communicate with a different submode from the same mode
and all submodes of a given mode occupy almost the same 25
spectrum.
• GENERAL_RETRANS_MODE = [FAST | SECURE]

Sets the retransmission mode in the MAC layer. FAST mode has higher
efficiency and does not avoid duplicated packets in case of noise.
SECURE mode avoids duplicated packets in case of noise and has a
lower efficiency. Default value: FAST.
Example of use: use SECURE mode if there are UDP-RAW video flows
in the network. If all video flows are FTP or RTP, it is recommended to
use FAST mode.
• NODE NUMBER = [1 ... 99]

For MV Gateway identity. It is mandatory that parameter NODE_
NUMBER is included in every auto configuration file and placed be
fore parameter GENERAL_TYPE (first line of the auto‐configuration
file). If it is not included, the modem will not be successfully
configured. Default value: 0.
• PLC_SIGNAL_COUPLING = [COAX/LV]
To allow coupling the BPL signal into coaxial or low voltage line.
Parameter is available in MV Gateway (A1 and A2 type), High Density
Low Voltage Access Gateway and GPON BPL Gateway.

8.4.2 Reception and Transmission Gain Control Parameters
The following parameters must be handled with special care. A poor con-
figuration can produce loss of communication with the modem through
PLC. Normally all of these settings are related to a SIGNAL_MODE. Correct
settings in one mode do not mean it is correct in others.
8.4.2.1 Reception Gain Parameters

(Automatic Gain Control parameters)
• AGC_RX_ENABLE = [0|1]
Disables/enables the HW AGC. Default value: 1.
WARNING: If the AGC is disabled, it will remain disabled, even if the

signal mode changes.
• AGC_RX_FIX_GAIN = [0-7]
Fix reception gain, only valid if the HW AGC is disabled.
Default value: 7.
WARNING: If the reception gain is fixed, it will remain fixed, even if

the signal mode changes. 26
• AGC_MAX_RX_GAIN = [0-7]
Fix the maximum reception gain for the HW AGC. Default value: 7.
WARNING: If the maximum reception gain is fixed, it will remain

fixed, even if the signal mode changes.
• AGC_MIN_RX_GAIN = [0-7]
Fix the minimum reception gain for the HW AGC. Default value: 0.
WARNING: If the minimum reception gain is fixed, it will remain

fixed, even if the signal mode changes.
8.4.2.2 Transmission Gain Parameters (Power Control Parameters)
• AGC_TX_GAIN = [0|1]
Configures the transmission gain of the DSS7700. The gains are
separated in steps of 12 dB. Default value: 1.
WARNING: If the transmission gain is configured, it will remain con-

figured, even if the mode changes. If the AFE is different from the
DS2 AFE then it is possible to configure the AGC_TX_GAIN from 0
to 7.

• POWER_CONTROL_ENABLE = [YES | NO]

It allows the node to change its transmitted power following certain
rules. The node tries to minimize the power injected into the
powerline while maintaining a good throughput with the other
nodes.
WARNING: The power control is only allowed in CPEs. It must never

be used in a HE or TD repeater.
8.4.3 RADIUS Parameters
• RADIUS_SERVER_IP = <ddd.ddd.ddd.ddd>
RADIUS server IP address
• RADIUS_SERVER_PORT = ddddd
RADIUS client UDP port
• RADIUS_SHARED_SECRET = <string>
RADIUS shared secret. It is limited to 16 characters.
All three parameters must be configured in order for the RADIUS client to 27
work properly.
8.4.4 Class of Service (COS) Parameters
Using the autoconfiguration file, two classes of service criteria can be

defined, assigning priorities from 0 to 7. Referring to offset parameters
(COS_CUSTOM_CRITERION_OFFSET.i and COS_CUSTOM_CRITERION_
CLASSES_OFFSET.i) it is important to consider that the 802.1Q tag (VLAN
tag) is always present, even if VLANs are not used. This field is placed
between the source MAC address and the EtherType field in the Ethernet
frame and its length is 4 bytes.
• COS_CUSTOM_CRITERION_OFFSET.i = [0-511]
Custom i-criterion frame offset, in bytes (i = 1, 2).
• COS_CUSTOM_CRITERION_PATTERN.i = 0xXXXXXXXXXXXXXXXX
Custom i-criterion 8-byte pattern, in hexadecimal digits (i = 1, 2).
• COS_CUSTOM_CRITERION_BITMASK.i = 0xXXXXXXXXXXXXXXX
Custom i-criterion 8-byte bitmask, in hexadecimal digits (i = 1, 2).
• COS_CUSTOM_CRITERION_CLASSES_OFFSET.i = [0-511]
Custom i-criterion classes frame offset, in bytes (i = 1, 2).

• COS_CUSTOM_CRITERION_CLASSES_BITMASK.i =
0xXXXXXXXXXXXXXXX
Custom i-criterion classes 8-byte bitmask, in hexadecimal digits
(i = 1, 2).
• COS_CUSTOM_CRITERION_CLASSES_PATTERN.i.j =
0xXXXXXXXXXXXXXXX
Custom i-criterion j-class 8-byte pattern, in hexadecimal digits
(i=1, 2; j = 1…8).
• COS_CUSTOM_CRITERION_CLASSES_PRIO.i.j = [0-7]
Custom i-criterion j-class priority (i=1, 2; j = 1…8).
• COS_CRITERION.k = [CUSTOM1|CUSTOM2|8021p|TOS|ARP|
TCP_8021p|TCP_TOS]
k-criterion definition (k = 1, 2). Assigns up to 2 criteria to classify
traffic. There are two custom criteria defined with the parameters
above and some predefined criteria: 8021p is based on VLAN tag
priority field, TOS on the IP type of service field. The criteria TCP_8021p
and TCP_TOS are modifications of 8021p and TOS to prioritize, in ad
dition, data TCP ACK packets to improve the performance of 28
bidirectional TCP flows; these two criteria are combined criteria that
set both criterion 1, 2 and the default priority. This means that TCP_
8021p and TCP_TOS can only be set as criterion 1 and in that case,
the criterion 2 an the default priority will take fixed values defined by
these criteria. The default criteria is TCP_8021p. Finally, the criterion
ARP can be used to prioritize the transmission of ARP packets.
• COS_DEFAULT_PRIO = [0-7]
Configures the CoS default priority, that is, the priority assigned to
packets that do not match a criterion. It cannot be modified if COS_
CRITERION.1 is either TCP_8021p or TCP_TOS. Default value: 0.
8.4.5 Quality of Service (QOS) Parameters
• QOS_ENABLE = [YES|NO]
This parameter enables/disables the quality of service in the node.
If this parameter is set to no, all other parameters related to QoS are
not configured. Default value is NO.
• QOS_PRIOACK.prio+1 = [0|1]
This list configures the Layer-2 ACK protocol depending on the
priority transmitted by the modem (can be useful for those
applications with tough settings in latency but not in PLR). If

several priorities are sniffed, the policy will be fixed by the maximum
priority detected. Keep in mind that Layer-2 ACK does not use
priorities. There is not an independent Layer-2 ACK for every priority.
If the Layer-2 ACK is disabled for one priority, then if this priority is
present in the line, the Layer-2 ACK protocol is stopped. This means
that for the period when packets with this priority are present, the
Layer-2 ACK is not used and no packets have Layer-2 ACK,
independent of their priority. Default value: 1 for all priorities.
• QOS_LATENCY_STEP = [20-400] (in ms)

Configures the minimum latency step for the different slaves when
using QoS. Default value: 60. If bandwidth limitation is disabled, it is
enough to configure this parameter only in the master, otherwise it
must be configured (with the same value) in all nodes in the
network.
8.4.5.1 Slave Node Parameters (CPE or REPEATER)
• QOS_MAX_TXPUT_TX = xxxx (in kbps)

Configures the maximum transmission throughput for that
CPE/TDREPEATER. Default value is 4096. 29
• QOS_UPBWLIMIT = [YES|NO]
In a slave, limits its own transmission. Set to NO by default. If
disabled, the user will transmit data constantly. Every time it receives
a data token, no limit will be imposed by the slave when transmitting
data back to its master.
8.4.5.2 Master Node Parameters (HE or REPEATER)
• QOS_BW_POLICY = [0|1|2]
Configures the policy in which the QoS manages the excess of band
width. 0 is fair mode and 1 is priority-based mode and 2 disabled the
bandwidth manager (in this case, saturation situations are solved
by other QoS functionalities). Default value: 2 (bandwidth manager
disabled).
• QOS_LATENCY.prio+1 = [1|2|4|8]
This list configures the latency for each priority level in
QOS_LATENCY_STEP unities.
» QOS_LATENCY.1 =8
» QOS_LATENCY.2 =8
» QOS_LATENCY.3 =4
» QOS_LATENCY.4 =4

» QOS_LATENCY.5 =4
» QOS_LATENCY.6 =2
» QOS_LATENCY.7 =1
» QOS_LATENCY.8 =8
8.4.6 Profile Parameters
To define a profile at least five parameters are needed. If any of them is not
present, it will take the default value:
• PROFILE_MAX_TXPUT_TX.i = xxxx (in kbps)

Maximum transmission throughput (from the CPE point of view:
upstream) for users with profile i. Default value is 4096. This
parameter will not be applied to slave nodes which are TDRs; for
TDRs, it is enough to set QOS_MAX_TXPUT_TX in order to configure
the maximum transmission throughput to its master (upstream).
• PROFILE_MAX_TXPUT_RX.i = xxxx (in kbps)

Maximum reception throughput (from the EU point of view:
downstream) for users with profile i. Default value is 4096.
30
• PROFILE_PRIORITIES.i = [0x00-0xFF]
Priorities allowed for a user of profile i. Each bit represents a priority.
The default value is 0x85, so priorities 7, 2 and 0 are allowed. To
include another priority, set the appropriate bit in the profile
priorities flag. The maximum and minimum priorities are always
set even if they are not configured (0x81).
• PROFILE_UPBWLIMIT.i = [YES|NO]
In a master or a TD repeater, limit the upstream (CPE’s transmission)
for users with profile i. If disabled, the user will receive tokens
constantly. Every time the master node has transmitted all required
tokens to all the slaves with upstream bandwidth limited, then it will
transmit tokens to the slaves without upstream bandwidth limited
until the rest of the slaves can receive tokens again. Default value is
NO. This parameter will not be applied to slave nodes which are TDRs;
for TDRs it is enough to set QOS_UPBWLIMIT = YES in order to con
figure its upstream bandwidth limitation.
• PROFILE_DWBWLIMIT.i = [YES|NO]
In a master or a TD repeater, limit the downstream (slave’s
reception) for users with profile i. If disabled, the master node will
never stop transmitting data to that user. Every time the master node

has transmitted all required data to all slaves with downstream

bandwidth limited, then it will transmit data to the slaves without
downstream bandwidth limited untilthe rest of slaves can receive
again. Default value is NO.
The following parameters can be added to the profile definition but they
are not mandatory if VLAN or OVLAN is not enabled, otherwise they should
be configured to allow connectivity:
• PROFILE_MNMT_VLAN.i = [2-4093] | %<PARAMETRIC VALUE>

Management VLAN for that user. In the case that a management
VLAN tag is not explicitly defined for a given profile, the Master
assigns the management VLAN tag of its own translation table to
prevent a case in that the slave gets isolated and cannot be
configured. Default value: 1 (not valid).
• PROFILE_DATA_VLAN.i = [2-4093] | %<PARAMETRIC VALUE>

Data VLAN for that user. Default value: 1 (not valid).
• PROFILE_VLAN_ADD_TAG.i.j = [2-4093] or parametric

This parameter is of table type. For the user of profile i, up to 16 31
VLANs can be defined in the filter list. When the list is ALLOWED, these
tags are added to the base configuration. Otherwise, if the list is
changed to FORBIDDEN, the base tags are removed and only the tags
defined here are included for security reasons. Default value: 9999
(not valid).
• PROFILE_VLAN_TAGGED_ONLY_IFACE_USER.i = [yes/no]
For the user of profile i, this parameter indicates whether or not to
drop input packets without a VLAN tag from the user with profile i
(PL interface). Default value: no.
• PROFILE_VLAN_OUTFORMAT_TAG_IFACE_USER.i = [yes/no]
send packets with a VLAN tag to the user interface with this profile.
Default value: yes.
• PROFILE_VLAN_IS_ALLOWED_IFACE_USER.i = [yes/no]
Indicates if the tags on the list are allowed or forbidden for the user
with profile i. When the list is ALLOWED the tags are added to the
base configuration; when the list is FORBIDDEN, the list is reset and
only tags defined with PROFILE_VLAN_ADD_TAG will be in the list.
Default value: yes.

• PROFILE_OVLAN_ADD_TAG.i.j = [2-4094] or parametric

This parameter is of table type. For the user of profile i, up to 16
OVLANs can be defined in the filter list. When the list is ALLOWED,
these tags are added to the base configuration. Otherwise, if the
list is changed to FORBIDDEN, the base tags are removed and
only the tags defined here are included for security reasons.
Default value: 9999 (not valid).
• PROFILE_OVLAN_TAGGED_ONLY_IFACE_USER.i = [yes/no]
drop input packets without an OVLAN tag from the user with profile
i (PL interface). Default value: no.

• PROFILE_OVLAN_OUTFORMAT_TAG_IFACE_USER.i = [yes/no]

send packets with a VLAN tag to the user interface with this profile.
Default value: yes.
• PROFILE_OVLAN_IS_ALLOWED_IFACE_USER.i = [yes/no]
Indicates if the tags on the list are allowed or forbidden for the user
with profile i. When the list is ALLOWED the tags are added to the 32
base configuration; when the list is FORBIDDEN, the list is reset and
only tags defined with PROFILE_OVLAN_ADD_TAG will be in the list.
Default value: yes.
• PROFILE_FWTYPE.i = [MV|LV|EU]
Indicates the firmware type of the user of profile i. If this parameter
is not defined, the firmware type of the RADIUS response or the
authorization list will be applied, if they are available. Otherwise, the
value EU will be applied (except for TDRs that will be configured
internally as LV nodes). Default value: invalid.
The maximum number of profiles is the maximum number of PLC ports

allowed in the ASIC.
8.4.7 Translation Table Parameters
• TRANSLATION_MNMT_VLAN = [2-4093]
Translation table management VLAN tag. Default value: 0
(not valid).
• TRANSLATION_DATA_VLAN.i = [2-4093]
Translation table data operator i VLAN tag. Up to 16 tags.

• TRANSLATION_ROOTPATH_OVLAN = [2-4094]
Translation table rootpath OVLAN. Default value: 0 (not valid).
WARNING: When the modem is going to boot in NVRAM mode,

IGMP is not performed, so the translation table is not exchanged
between the different PLC nodes. It is mandatory to add the transla-
tion table to all configuration files (MV, LV and EU) to configure any
modem for booting from NVRAM.
8.4.8 VLAN Parameters
• VLAN_ENABLE = [yes|no]
Enables/disables the use of VLAN.
WARNING: Normally this parameter is not needed because the mo-

dem itself discovers the use of VLAN, but it is necessary in case of
booting from NVRAM.
• VLAN_MNMT_TAG = [2-4093] | %<PARAMETRIC VALUE>

Management VLAN tag of high-level FW management protocols.
Often taken from the translation table. Default value: 0 (not valid). 33
WARNING: This parameter is mandatory to add in all autoconfigura-

tion files (MV, LV or EU modems) if the modems are going to boot
from NVRAM after the next reset.
• VLAN_MNMT_PRIO = [0-7]
Configures the VLAN priority for the high-level management (FW)
packets. Default value: 5.
• VLAN_DATA_TAG = [2-4093] | %<PARAMETRIC VALUE>

Parameter for EU nodes. Configures the VLAN tag for the data
packets (packets coming from the external interfaces). Default value:
0 (not valid).
• VLAN_DATA_PRIO = [0-6]
Parameter for EU nodes. Configures the VLAN priority for the data
packets (packets coming from the external interfaces).
Default value: 2.
• VLAN_TRUNK.i = [2-4093]
Parameter for LV and MV nodes. Configures a list of VLAN trunks
different from the ones inside the translation table that must be
allowed in the node interfaces. It is necessary to configure these

trunks for private VLANs between EUs in all intermediary equipment.

• VLAN_RETAG_EXTA_SRC = [0 | 2-4095]
VLAN retagging: External (Ethernet) interface A (EXTA) source tag.
When a packet comes from EXTA with a tag specified in this
parameter, it is sent through PLC with the tag specified in the
VLAN_RETAG_EXTA_DST parameter. With 0, the retagging is disabled
in the EXTA interface. Default value: 9999 (not valid).
• VLAN_RETAG_EXTA_DST = [0 | 2-4095]
VLAN retagging: External (Ethernet) interface A (EXTA) destination
tag. When a packet coming from PLC with a tag specified in this pa
rameter is sent through EXTA, the tag will be changed to the tag
indicated in VLAN_RETAG_EXTA_SRC. With 0, the retagging is dis
abled in the EXTA interface. Default value: 9999 (not valid).
• VLAN_RETAG_EXTB_SRC = [0 | 2-4095]
VLAN retagging: External (Ethernet) interface B (EXTB) source tag.
When a packet comes from EXTB with a tag specified in this
parameter, it is sent through PLC with the tag specified in the 34
VLAN_RETAG_EXTB_DST parameter. With 0, the retagging is disabled
in the EXTB interface. Default value: 9999 (not valid).
• VLAN_RETAG_EXTB_DST = [0 | 2-4095]
VLAN retagging: External (Ethernet) interface B (EXTB) destination
tag. When a packet coming from PLC with a tag specified in this pa
rameter is sent through EXTB, the tag will be changed to the tag
indicated in VLAN_RETAG_EXTB_SRC. With 0, the retagging is
disabled in the EXTB interface. Default value: 9999 (not valid).
8.4.9 OVLAN Parameters
The OVLAN parameters are used to configure the basic OVLAN configu-
ration, which avoids visibility between different customers in the access
network.
• OVLAN_ENABLE = [yes|no]
Enables/disables the use of OVLAN filtering. Default value is no.
• OVLAN_DATA_TAG = [2-4094] | %ROOTPATH

OVLAN tag assigned to the packets coming from the external
interfaces. It should be the same as in the translation table to perform
the basic OVLAN operation in all equipment except the one

connected to the backbone, which will have the ALL_VLAN tag (4095).
• OVLAN_ARP_TAG_ENABLE = [ yes | no ]
If enabled, ARP packets sent by the modem are tagged with the
ROOTPATH ovlan tag. This prevents Forwarding Tables of LV equip
ments becoming filled with MAC addresses and overflow in very large
networks (hundreds of nodes). MAC addresses learnt do not always
belong to the same branch as the overflowed modem. If the OVLAN
feature is enabled, these entries will never be used because
communication between paths other than the ROOT_PATH is
forbidden. The ARP OVLAN tag prevents the modem from learning
MAC addresses from paths other than the ROOTPATH. With this
solution, it is necessary to have a device acting as a local proxy arp in
the backbone. Default value: no.
• OVLAN_TRUNK.i = [2-4094]
Parameter for LV and MV nodes. Configures a list of OVLAN trunks
different from the one inside the translation table that must be
allowed in the node interfaces. It is necessary to configure these
trunks for private OVLANs between EUs in all intermediary 35
equipment. Default value: 0 (not valid).
8.4.10 Access Protocol Parameters
• AP_MIN_NUMBER_HOPS = [0|1|…]
Configures the minimum number of hops to the HE from a slave.
0 means that no extra hop must be taken to reach the HE, so the slave
always connects to the HE directly (if able). 1 means 1 extra hop is
forced to reach the HE, that is, the equipment will connect to a TD
repeater (if able).
• AP_FORBID_MASTER.i = 0xXXXXXXXXXXXX
List of forbidden masters for a given slave by MAC address.
• AP_PREFER_MASTER = 0xXXXXXXXXXXXX
Preferred master for a given slave by MAC address. This parameter is
useful because the slave will try to connect to the preferred master if
it is present and the AP_MIN_NUMBER_HOPS is valid with that mas
ter. If not, it will connect to any other master.
• AP_FIX_MASTER = 0xXXXXXXXXXXXX
Fixed master for a given slave by MAC address. If the slave was
connected to other master, disconnects and only will connect to this
FIXED master.

WARNING: This parameter can be dangerous because the slave can-

not connect to other masters.
The selection of the best master will be modified according to the four
autoconfiguration parameters presented above:
» If AP_FIX_MASTER is configured, this will be the only master

possible for the new node (regardless of the number of hops,
reception gain, or values of the other autoconfiguration
parameters);
» If AP_PREFER_MASTER is configured (and AP_FIX_MASTER is not
used) the best master selected will be the preferred master value
if that selected master is detected in the network; and it has a
number of hops above or equal to AP_MIN_NUMBER_HOPS.
» The list of masters of the AP_FORBID_MASTER will not be selected
as best master (they will never be adequate masters regardless of
number of hops, gain, BPS, etc.);
» Masters that have a number of hops less than AP_MIN_NUMBER_
HOPS will not be selected as best master (they will never be
adequate masters regardless of gain, BPS, etc.).
36
The order of precedence is AP_FIX_MASTER, AP_PREFER_MASTER, AP_FOR-
BID_MASTER and AP_MIN_NUMBER_HOPS.
When a parameter AP_FIX_MASTER, AP_PREFER_MASTER or AP_FORBID_

MASTER is present in the downloaded autoconfiguration file, the list of
fixed, preferred and forbidden masters already configured before this au-
toconfiguration operation is discarded. This implies that only complete
lists of masters can be configured in each autoconfiguration operation.
The parameter AP_PREFER_MASTER (with any valid MAC address) can be

used to discard the configured list of fixed, preferred and forbidden mas-
ters.
• AP_CHECK_BEST_MASTER_ENABLE = [yes|no]
Enables/disables a periodical check of the best master of the access
protocol. Default value: yes.
• AP_CHECK_BEST_MASTER_PERIOD = <time>
Configures the period time of the best master check. The time is in
minutes. Default value: 180.
• AP_CURRENT_MASTER_MIN_BPS = <bps_thr>
Minimum bits per symbol with the current master that forces a

change of master in check best master phase. Default value: 2150.
• AP_NEW_MASTER_MIN_BPS = <bps_thr>
Minimum bits per symbol of a master to be considered as a possible
best master in check best master phase. Default value: 2150.
• AP_RADIUS_UPDATE_PERIOD = [0-255]
Period of the RADIUS update process. A value of 0 means that no
periodic RADIUS update is performed. A value of [1-255] means that
the RADIUS update is performed with this period, in hours. Default
value: 24.
• ACCESSP_AUTHLIST_MAC.i = 0xXXXXXXXXXXXX
List of allowed MAC addresses. The length of the list is 128
(i=1…128).
• ACCESSP_AUTHLIST_PROFILE.i = [1-x]
List of profiles associated to a MAC address, where x is the maximum
number of PLC ports allowed in the ASIC (see 8.4.6) The length of the
list is 128 (i=1…128). Default value: 1.
37
• ACCESSP_AUTHLIST_FWTYPE.i = [MV|LV|EU]
List of FWTYPE. The length of the list is 128 (i=1…128).
Default value: LV.
NOTE: This parameter is obsolete and is maintained to ensure back-

wards compatibility. The firmware type of the new node should be
assigned by means of the parameter PROFILE_FWTYPE. ACCESSP_
AUTHLIST_FWTYPE is only applied if the parameter PROFILE_FWTYPE
is not defined in the corresponding profile.
8.4.11 Parameters
• STP_PRIO = [0-65535]
Configures the 2 bytes added to the MAC used by the STP standard
to decide the root path. Default values:
» 36880 = 0x9010 MV MASTER

» 36880 = 0x9010 MV MASTER
» 36896 = 0x9020 MV TDREPEATER
» 36912 = 0x9030 LV MASTER
» 36928 = 0x9040 LV TDREPEATER
» 36944 = 0x9050 LV CPE

• STP_PORT.i = [EXTA|EXTB|PLC]
The following two parameters will be configured depending on this
parameter. For instance if STP_PORT.2 = EXTA, then STP_PORT_PRIO.2
= xx and STP_PORT_COST.2 = xxx are referred to EXTA. Only EXTA,
EXTB and PLC can be configured. If PLC is selected, the priority and
cost will be changed for ALL PLC ports.
• STP_PORT_PRIO.i = [0-255]
Priority of the port (necessary if costs are equal). Default value (for
ETHA, ETHB and PLC): 80.
• STP_PORT_COST.i = [0-200000000]
Cost of the port is represented by 4 bytes. It is recommended not to
use a number greater than 200000000 so as not to exceed the ac
cumulated maximum of 4294967296.
Default values:
» ETHA = 2000000
» ETHB = 2000000
» PLC = 4000000
38
• STP_HELLO_TIME = [10-100]
Hello time expressed in decisecs. Default value: 20 decisecs.
• STP_MAX_AGE = [60-400]
Max. age time expressed in decisecs. Default value: 200 decisecs.
• STP_FORWARD_DELAY = [40-300]
Forward delay time expressed in decisecs. Default value:
150 decisecs.
NOTE: Although values are configured in tenths of a second, the

bridge has a time resolution of 1 second.Non integer values will be
correctly codified but changes will take effect in the next integer
second. For example: if a hello time of 3.1 seconds is set, hellos are
sent every 4 seconds.
• STP_FRONTIER = [NONE|EXTA|EXTB]
Drops all STP packets in an external port. Default value: NONE.
• STP_MODE = [STP|RSTP]
STP protocol version: Common (802.1d) or Rapid (802.1w).
Default value: RSTP.

• STP_PTP_EXTA = [yes|no]
Configure the EXTA interface to be considered as point-to-point
(by default if connected through the backplane).
• STP_PTP_EXTB = [yes|no]
Configure the EXTB interface to be considered as point-to-point
(by default if connected through the backplane)
8.4.12 MAC Ingress Filtering Parameters
• MAC_INGRESS_FILTERING_ENABLE = [yes|no]
Enables the use of MAC ingress filtering. If enabled, the modem
filters by the source MAC address. If the source MAC of the frame
coming from Ethernet is not in the list, the frame is discarded. Default
value: no.
• MAC_INGRESS_FILTERING_MAX_ALLOWED = [1-4]
Sets length of the MAC filtering ingress list. The maximum is 4 instead
of 5 to allow the WISC MAC to be in the FW; this is done
automatically. Default value: 4.
39
• MAC_INGRESS_FILTERING_MODE = [FIXED|AUTO]
» If FIXED: Enables the INGRESS MAC FILTERING and registers the list
of MAC_INGRESS_FILTERING_FIXED_MAC (the following
parameter) in the list, up to the MAC_INGRESS_FILTERING_MAX_
ALLOWED.
» If AUTO: Deletes all MACs registered in the bridge associated to
ETH ports, and sets the AUTO flag. When the bridge receives a new
MAC coming from ETH, it registers it in the INGRESS_MAC_FILTER
ING list. If the length of this list reaches the maximum allowed then
it enables the MAC_INGRESS_FILTERING.
Default value: FIXED.
• MAC_INGRESS_FILTERING_FIXED_MAC.i = 0xXXXXXXXXXXXX
Only valid in FIXED mode, up to 4 MACs. If the MAX is set to lower
than 4, then only the first MACs until the length of MAX is completed
are registered.
8.4.13 Custom VLAN/OVLAN Parameters
• USE_CUSTOM_VLAN_OVLAN = [yes/no]
This parameter enables other VLAN/OVLAN parameters.
Default value: no.

If set to no, the previous configuration is used. If set to yes, it will configure
the parameters that are set in the autoconfiguration file. If set to yes, the
connection will be lost if the new parameters are not properly configured
in the autoconfiguration file. It is necessary to specify several parameters
with care or no connection will be possible between the modems.
As a general rule, this configuration overrides the basic VLAN/OVLAN con-

figuration. In order to decrease the risk of loosing the connection, the
VLAN/OVLAN filtering follows these rules:
» When the list is ALLOWED, the tags specified here are
added to the existing ones. This solution simplifies the
configuration and decreases the risk of misconfiguration.
» When the list is FORBIDEN, the lists are reset before inserting the
tags specified here, for the same reasons.
The VLAN/OVLAN custom configuration must be complemented with the

profileparameters referring to VLAN/OVLAN to configure interfaces differ-
ent from EXTA, EXTB, ROOT and OTHERS.
8.4.13.1 Custom VLAN Parameters

40
• VLAN_FILTER_INGRESS = [yes/no]
VLAN filtering using input interface. By default only egress filtering
(output interface) is performed. Default value: no.
• VLAN_TAGGED_ONLY_IFACE_ROOT = [yes/no]
Drops packets without a VLAN tag entering the root interface
(IFACE_ROOT). Default value: no.
• VLAN_TAGGED_ONLY_IFACE_EXTA = [yes/no]
Drops packets without a VLAN tag entering external (Ethernet)
interface A. Default value: no.
• VLAN_TAGGED_ONLY_IFACE_EXTB = [yes/no]
Drops packets without a VLAN tag entering external (Ethernet)
interface B. Default value: no.
• VLAN_TAGGED_ONLY_IFACE_OTHER = [yes/no]
Drops packets without a VLAN tag entering other interfaces
(IFACE_OTHER). Default value: no.
• VLAN_OUTFORMAT_TAG_IFACE_ROOT = [yes/no]
Sends packets with a VLAN tag to the root interface (IFACE_ROOT).
Default value: yes.

• VLAN_OUTFORMAT_TAG_IFACE_EXTA = [yes/no]
Sends packets with a VLAN tag to external (Ethernet) interface A.
Default value: yes.
• VLAN_OUTFORMAT_TAG_IFACE_EXTB = [yes/no]
Sends packets with a VLAN tag to external (Ethernet) interface B.
Default value: yes.
• VLAN_OUTFORMAT_TAG_IFACE_OTHER = [yes/no]
Sends packets with a VLAN tag to other interfaces (IFACE_OTHER).
Default value: yes.
• VLAN_PVID_PL = [2-4095]
802.1Q VLAN tag for tagging untagged packets from the powerline
interface (PL). Default value: 0.
• VLAN_PVID_EXTA = [2-4095]
802.1Q VLAN tag for tagging untagged packets from the external
interface A (EXTA). If EU, default value: VLAN_DATA_TAG. If LV or MV,
default value: 0.
41
• VLAN_PVID_EXTB = [2-4095]
802.1Q VLAN tag for tagging untagged packets from the external
interface B (EXTB). If EU, default value: VLAN_DATA_TAG. If LV or MV,
default value: 0.
• VLAN_PVID_FW = [2-4095]
802.1Q VLAN tag for tagging untagged packets from the firmware
interface (FW). Default value: 1.
• VLAN_DEFAULT_PRIO_PL = [0-7]
802.1p priority for tagging untagged packets from the powerline
• VLAN_DEFAULT_PRIO_EXTA = [0-7]
802.1p priority for tagging untagged packets from external
(Ethernet) interface A (EXTA). If EU, default value: VLAN_DATA_PRIO.
Default value: 0.
• VLAN_DEFAULT_PRIO_EXTB = [0-7]
802.1p priority for tagging untagged packets from external
(Ethernet) interface B (EXTB). If EU, default value: VLAN_DATA_PRIO.
Default value: 0.

• VLAN_DEFAULT_PRIO_FW = [0-7]
802.1p priority for tagging untagged packets from the firmware
interface (FW). Default prio: 0.
• VLAN_IS_ALLOWED_IFACE_ROOT = [yes/no]
Private VLANs list: Root interface (IFACE_ROOT) list is an allowed tag
list if YES or forbidden if NO. Default value: yes.
• VLAN_LIST_IFACE_ROOT.i = [2-4095]
Private VLANs list: Root interface (IFACE_ROOT) tag list. Up to
16 values can be configured.
• VLAN_IS_ALLOWED_IFACE_EXTA = [yes/no]
Private VLANs list: External (Ethernet) interface list is an allowed tag
if YES or forbidden if NO. Default value: yes.
• VLAN_LIST_IFACE_EXTA.i = [2-4095]
Private VLANs list: External (Ethernet) interface tag list. Up to
16 values can be configured.
• VLAN_IS_ALLOWED_IFACE_EXTB = [yes/no] 42
Private VLANs list: External (Ethernet) interface list is an allowed tag
• VLAN_LIST_IFACE_EXTB.i = [2-4095]
Private VLANs list: External (Ethernet) interface tag list. Up to
16 values can be configured. 8.4.14.2 Custom OVLAN Parameters
• OVLAN_FILTER_INGRESS = [yes/no]
OVLAN filtering using input interface. By default only egress filtering
(output interface) is performed. Default value: no.
WARNING: Enabling the OVLAN ingress filtering is very dangerous

because the basic OVLAN configuration relies on avoiding ingress
filtering. In the downstream interfaces, there are empty lists, which
imply that no packet will pass if ingress filtering is activated and the
OVLAN rootpath tag is not allowed. Enabling ingress filtering needs
a complete OVLAN configuration.

8.4.13.2 Custom OVLAN Parameters
• OVLAN_TAGGED_ONLY_IFACE_ROOT = [yes/no]
Drops packets without an OVLAN tag entering the root interface
(IFACE_ROOT).
• OVLAN_TAGGED_ONLY_IFACE_EXTA = [yes/no]
Despite the name of this parameter, the meaning of it is different for
Ethernet interfaces. If set to NO, drops packets with an OVLAN tag
entering external (Ethernet) interface A. If set to YES, accepts tagged
packets with an OVLAN tag. Default value: no.
• OVLAN_TAGGED_ONLY_IFACE_EXTB = [yes/no]
Despite the name of this parameter, the meaning of it is different for
Ethernet interfaces. If set to NO, drops packets with an OVLAN tag
entering external (Ethernet) interface B. If set to YES, accepts tagged
packets with an OVLAN tag. Default value: no.
WARNING: If the root port is an Ethernet port, the meaning of the

parameter OVLAN_TAGGED_ONLY_IFACE_ROOT is the same as the
parameters described previously, OVLAN_TAGGED_ONLY_IFACE_
EXTA or OVLAN_TAGGED_ONLY_IFACE_EXTB.
43
• OVLAN_TAGGED_ONLY_IFACE_OTHER = [yes/no]
Drops packets without an OVLAN tag entering other interfaces
(IFACE_OTHER).
• OVLAN_OUTFORMAT_TAG_IFACE_ROOT = [yes/no]
Sends packets with an OVLAN tag to the root interface (IFACE_ROOT).
Default value: yes.
• OVLAN_OUTFORMAT_TAG_IFACE_EXTA = [yes/no]
Sends packets with an OVLAN tag to external (Ethernet) interface A.
Default value: yes.
• OVLAN_OUTFORMAT_TAG_IFACE_EXTB = [yes/no]
Sends packets with an OVLAN tag to external (Ethernet) interface B.
Default value: yes.
• OVLAN_OUTFORMAT_TAG_IFACE_OTHER = [yes/no]
Sends packets with an OVLAN tag to other interfaces (IFACE_OTHER).
Default value: yes.
• OVLAN_PVID_PL = [2-4095]
OVLAN tag for tagging untagged packets from the powerline

• OVLAN_PVID_EXTA = [2-4095]
OVLAN tag for tagging untagged packets from external interface A
(EXTA). If EU, the default value is equal to OVLAN_DATA_TAG. If LV or
MV, the default value is 0.
• OVLAN_PVID_EXTB = [2-4095]
OVLAN tag for tagging untagged packets from external interface B
(EXTB). If EU, the default value is equal to OVLAN_DATA_TAG. If LV or
MV, the default value is 0.
• OVLAN_PVID_FW = [2-4095]
OVLAN tag for tagging untagged packets from the firmware
interface (FW). Default value: 0.
• OVLAN_IS_ALLOWED_IFACE_ROOT = [yes/no]
Private OVLANs list: Root interface (IFACE_ROOT) list is an allowed tag
• OVLAN_LIST_IFACE_ROOT.i = [2-4095]
Private OVLANs list: Root interface (IFACE_ROOT) tag list. Up to 16
values can be configured. 44
• OVLAN_IS_ALLOWED_IFACE_EXTA = [yes/no]
Private OVLANs list: External (Ethernet) interface list is an allowed tag
• OVLAN_LIST_IFACE_EXTA.i = [2-4095]
Private OVLANs list: External (Ethernet) interface tag list. Up to 16
values can be configured.
• OVLAN_IS_ALLOWED_IFACE_EXTB = [yes/no]
Private OVLANs list: External (Ethernet) interface list is an allowed tag
• OVLAN_LIST_IFACE_EXTB.i = [2-4095]
Private OVLANs list: External (Ethernet) interface tag list. Up to 16
values can be configured.
8.4.14 Powerline Header Parameters
• PLC_HEADER_EXTA = [0-1]
Powerline header extension. Default value: 0. The two peers must be
configured in the same way.

» 0: The PLC header is not sent/received.

» 1: Forces external interface A to keep the Powerline header for
outgoing traffic.
• PLC_HEADER_EXTB = [0-1]
Powerline header extension for interface B. Default value: 0.
NOTE: These parameters configure the PLC out format of the exter-
nal interfaces. Changing these parameters on the fly can cause loss
of connection so the autoconfiguration of those parameters does
not imply the use of that configuration. The values of those param-
eters are stored in the NVRAM and will be used in the next boot.
8.4.15 SNMP Parameters
• SNMP_TRAP_IP_ADDRESS = <ddd.ddd.ddd.ddd>
Configures the IP address to which traps are sent when produced.
• SNMP_TRAP_COMMUNITY_NAME = community
Configures the trap community access. This parameter is a string with
maximum length 23 characters. 45
8.4.16 Multicast Protocol Parameters
• MCAST_IGMP_SNOOPING = [yes/no]
Configures the IGMP SNOOPING feature in a node. If enabled the
node is able to translate IGMP messages to MPP SNAP messages that
can be propagated through the PLC network. Default value: no.
IMPORTANT: This parameter must be set to Yes ONLY in CPEs con-

nected to a STB. Modems with the IGMP Snooping feature enabled
have the upstream throughput limited because all frames incom-
ing from the external interface are parsed by the firmware. IGMP
frames are encapsulated into MPP frames and sent through the PLC
network and the rest are regenerated and resent. The maximum up-
stream throughput (from the external interface to the PLC network)
measured is 120 packets/second with a 0% packet loss rate. (this is
independent of packet size). The bigger the packet size, the bigger
the upstream throughput measured in megabits/sec.
• MCAST_MPP2IGMP_PORT = [none/exta/extb/root]
Configures the translation of MPP SNAP message to IGMP format.
The destination of IGMP messages is specified in the parameter. If
“none” is configured no translation is performed, otherwise the

destination interface is the one specified (“root” means spanning tree

root). Default value: none.
Example of use: In the HE that is connected to the network where the
video server exists, configure MCAST_MPP2IGMP_PORT = root. In in
termediate nodes (including the HE of Frequency Division Repeaters),
leave MCAST_MPP2IGMP_PORT = none.
• MCAST_IGMP_AGING = [yes/no]
This parameter enables or disables IGMP aging for multicast packets
in a node. Default value: yes.
8.4.17 Multiplier Parameter
• TD_MULTIPLIER = [-300, -265, -220, -190, -170, -150, -135, -125,

-115, -105, -95, -85, -80, -70, -65, -60, -55, -50, -45, -40, -35, -30,
-25, -20, -15, -10, -5, 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, 60,
65, 70, 75, 80, 85, 90, 95, 100, 105, 110, 115, 120]
Value of gain of the time domain multiplier. The values that can be
configured to go from - 30dB to +12dB, allowed values are shown
above. The format in which the value is read is thevalue in dB
multiplied by 10. The value must be divisible by 5. For example, 46
-3.5dB will be expressed: TD_MULTIPLIER = -35. Each transmission
mode and product has a different maxim value.Be careful to avoid
saturation in the DAC.
WARNING: Be careful with positive values because if the impedance

in the line is low, a positive value can break the line driver (damage
the modem).

NVRAM
9 NVRAM
The NVRAM contains the following information, which the modem needs
before receiving the auto-configuration file :
• Its own MAC address.

• If necessary, the PLC signal bandwidth and the central
frequency. This is needed if auto-configuration is done through PLC
and the frequency band is not a standard mode. When the
firmware detects a non-standard signal mode in NVRAM, it creates a
new mode for it and adds it to the Search Link list with the highest
priority.
• A variable describing VLANs as ON or OFF, necessary only if the PTTP
client is to be disabled. Otherwise, it will be discovered automatically
by the modem.
• A variable describing the PTTP client as ON or OFF.
• A variable describing the boot mode as auto-configuration or
NVRAM.
• MV nodes: The default Management VLAN tag value used by DHCP
and TFTP protocols. This value can be changed manually. In this
configuration, the PTTP client must be disabled. 47
Because the MV FW has to get the translation table information via TFTP,
the MV stores the Management VLAN for receiving the IP through DHCP
in NVRAM. The PTTP client also must be disabled. Otherwise, the Manage-
ment VLAN will not be used.
Note that this tag is only mandatory when there is no other node from
which to receive the Management VLAN tag via PTTP.
When the PTTP client is enabled, the node must perform an PTTP request
to get the translation table, just as the LV and EU nodes do.
All of the necessary values in NVRAM can be modified using autoconfigu-

ration console commands. See Section 14: Auto-configuration Console for
more information.

Equipment Requirements
10 Equipment Requirements
48
10.1 MV Equipment
The equipment setup at an HV/MV substation might be one of the fol-
lowing, depending on whether the MV node is using time or frequency
division :
1. Frequency division at an HV/MV substation (this example illustrates

just one of several possibilities):
» The auto-configuration file comes from Gigabit Ethernet on both
chipsets.
2. Time division at an HV/MV substation (this example illustrates just

one of several possibilities) :
» The auto-configuration file comes from Gigabit Ethernet on
this chipset.
The equipment setup at an MV/LV substation might be one of the fol-

lowing, depending on whether the MV node is using time or frequency
division :

1. Frequency division at an MV/LV substation (this example illustrates

just one of several possibilities) :
» The auto-configuration file comes from MV PLC on one chipset,
and the other chipset obtains the auto-configuration file via Gi
gabit Ethernet. The LV FW also gets its auto-configuration file via
Gigabit Ethernet. The node receiving its auto-configuration file via
PLC needs the frequency band if it is not standard. Otherwise, this
chipset tries to find the correct link (using the Access Protocol FW
process).
2. Time division at an MV/LV substation (this example illustrates just one

of several possibilities) :
» TThe auto-configuration file comes from MV Powerline on this
chipset. The LV FW gets the auto-configuration file via Ethernet.
10.1.1 MV NVRAM
Because the MV FW has to get the translation table information via TFTP,
the MV stores the management VLAN for receiving the IP through DHCP
in NVRAM. If there is a node that already has the translation table, the
MV node can get the translation table using PTTP. So only the MV equip- 49
ment connected to the backbone needs the translation table written in
NVRAM.
The MV NVRAM has information about the MAC of this node and, if neces-
sary, the signal bandwidth and the central frequency.
10.1.2 MV FW: Auto-configuration Process
The auto-configuration of the FW on the MV consists of the following

steps:
» The MAC and the Management VLAN are discovered via either
NVRAM or PTTP.
» Using DHCP (through the Management VLAN and all enabled
interfaces), the node gets the IP address of the TFTP server and
the name of the auto-configuration file.
» Using TFTP (through the Management VLAN), the node gets the
auto-configuration file. In this auto-configuration file are
configuration parameters for this node as well as the translation
table and profile information.

10.1.3 MV FW: Translation Table Transfer Process
When the MV node is configured, this node should be running PTTP. When
a packet with an PTTP MAC is received, the MV node can discover, using
the source MAC of this packet, which MV or LV node is connected to it via
Ethernet. When the MV node answers this translation request packet, the
LV node receives the response and discovers the Management VLAN tag
via Ethernet/Gigabit Ethernet. Of course if the MV node is not configured,
the translation table information is not known and the PTTP request is not
processed.
10.2 LV Equipment
An LV equipment setup might look like one of the following:
1. Frequency division at an MV/LV substation (this example

illustratesjust one of several possibilities):
» The FW auto-configuration file on the LV is received via Gigabit
Ethernet.
2. Example of time division at an MV/LV substation (this example 50

illlustrates just one of several possibilities):
» The FW auto-configuration file on the LV is received via Ethernet.
3. LV repeater or HG using frequency division:

One of these chipsets gets the auto-configuration file via LV
Powerline, and the other via Ethernet.
4. Example of a LV repeater or HG using time division:

The FW auto-configuration file is received via LV Powerline.
10.2.1 LV NVRAM
The LV NVRAM contains information about the MAC of this node and, if
necessary, the signal bandwidth and the central frequency.
10.2.2 LV FW: Auto-configuration Process
The FW auto-configuration process on the LV consists of the following

steps:
» Via the same protocol used to transfer the translation table, the FW
on the LV receives the translation table from the FW of another LV
or MV. The LV FW sends the translation request packet to all

enabled interfaces.
» Using DHCP (through the Management VLAN), the node gets an IP
Address and the name of the auto-configuration file.
» Using TFTP (through the Management VLAN), the node receives
the auto-configuration file. This auto-configuration file
containsconfiguration parameters for this node, and is decoded by
means of the translation table.
10.2.3 LV FW: Translation Table Transfer Process
When the LV node is configured, this node should be running PTTP. When
a packet with an PTTP MAC is received, the LV node can discover, using the
source MAC of this packet, which LV or EU node is requesting the transla-
tion table. When the LV node answers this translation request packet, the
LV or EU node receives the response and discovers the Management VLAN
tag via Ethernet/Gigabit Ethernet.
Of course if the LV node is not configured, the translation table informa-

tion is not known and the PTTP request is not processed.
10.3 End User Equipment 51
End User equipment will always consist of only one chipset and two con-
nections - one Ethernet and one LV PLC (with LV FW on the other side of
the connection).
10.3.1 End User NVRAM
The EU NVRAM contains information about the MAC of this node and, if
necessary, the signal bandwidth and the central frequency.
10.3.2 End User FW: Auto-configuration Process
The auto-configuration process for the FW of the End User node consists
of the following steps:
» At first, no Ethernet interface is enabled. This node only searches

for the correct band for synchronization with another node.
» When the EU is synchronized with an LV node, it sends the PTTP
request packet to the PLC interface to get the Management VLAN.
» Using DHCP (through the Management VLAN), the node gets an IP
address, the phone number (if required) and the name of the auto

configuration file.
» Using TFTP (through the Management VLAN), the node receives
the auto-configuration file. This auto-configuration file contains
configuration parameters for this node, and is decoded by means
of the translation table.
10.3.3 End User FW: Translation Table Transfer Process
When a packet with an PTTP MAC is received by the FW, the packet is not
handled.
52

Master-Side Access Protocol Processes & User Profiles
11 Master-Side Access Protocol Processes &

User Profiles
MV and LV Masters and Repeater nodes must search for Slave nodes. When
a new Slave is found, it can be authenticated using the RADIUS protocol,
or, if authentication is disabled, simply added to the system.
The Master should also configure its interface to that new user in reference
to its QoS and LAN/OVLAN configuration, as specified in the user profiles.
11.1 User Profiles

User profiles are contained in the auto-configuration file on each HE and
TD REPEATER. These profiles contain the information Masters need in or-
der to configure a port for a new user (Slave) joining the network. The
configuration mainly concerns QoS and VLAN/OVLAN settings.
There will be always a reserved default profile, profile number 1, applied

to any user without a profile, whether because no profile has been creat-
ed, or because the corresponding profile is just not available. This reserved 53
profile, like all profiles, can be redefined via auto-configuration.
11.2 Working with RADIUS Authentication

When RADIUS authentication is active, the Repeater or HE sends an Access-
Request message to the RADIUS server, which checks the MAC address
against the one that was accepted. When the MACs match, the server
responds with an Access-Accept message containing the profile number
as an attribute. The message can also contain the type of firmware (MV,
LV or EU), but it is recommended to associate this information with the
profile by means of the parameter PROFILE_FWTYPE. Otherwise, the server
replies with a RADIUS Access-Reject message and the authentication fails.
Once authentication is achieved, the Slave is authorized and the QoS and
VLAN/OVLAN are configured between Master and Slave. The Master uses
the profile number to get these parameters. The Slave uses the parameters
from the downloaded auto-configuration file. The Slave node downloads
the file during its auto-configuration process, which takes place after a
successful RADIUS request on the Master side.
11.3 Working without RADIUS Authentication

When there is no RADIUS authentication, two modes of operation are pos-
sible.

Master-Side Access Protocol Processes & User Profiles
The first one is ‘NO AUTHENTICATION’. The Master will set a default QoS
and VLAN/OVLAN configuration (the reserved profile) for the Slave.
The other one is authorization checked against an ‘AUTHORIZATION LIST’.

As many as 128 unique users can be added to ‘ACCESSP_AUTHLIST_x’ with
their related profiles and fw_type. When an entry matches a new user, the
QoS and VLAN/OVLAN configuration related to that entry is assigned to
the new user. If no match if made, the user is rejected.
54

DHCP Support
12 DHCP Support
12.1 DHCP Client

AV200 nodes perform a DHCP request with extended custom options. So
not only the basic IP configuration (IP address, netmask and gateway) is
requested, but the client also requests three custom options in order to
obtain the auto-configuration file:
• tftp-server-name: String with the IP address of the TFTP server.

• extensions-path-name: String with the path and file name of the
auto-configuration file on the TFTP server.
• ifcp-code: 32-bit integer representing how to handle PTTP:
» 0 : Boot without VLANs and skip PTTP.
» 1 : Continue requesting PTTP (does nothing).
» [2-4095] : Boot with Management VLAN = ifcp-code. Skip PTTP.
On the other hand, if the phone number must be downloaded via DHCP,
another custom option should be requested:
55
• phone-number: Text and the phone number.
12.2 DHCP Server

A DHCP server that supports DHCP extensions is needed in order to provide
the different AV200 nodes with the custom options.
WARNING: Although the first two custom options needed by the

DHCP client are should be standard, sometimes it is necessary to
define the extensions-path-name option in the header of the dhcpd.
conf file. The ifcp-code option is mandatory to define:
option extensions-path-name code 18 = string;

option ifcp-code code 120 = unsigned integer 32;
The phone number must also be defined in the header of the dhcpd.conf
file if phone-number is to be configured on some CPEs via DHCP :
option phone-number code 135 = text;
WARNING: The option phone-number code number has changed

from previous versions to conform to MADBRIC (135).

DHCP Support
12.3 DHCP Server Configuration File Example

The following is an example of the dhcpd.conf file (Linux DHCP server
configuration file):
option extensions-path-name code 18 = string;

option ifcp-code code 120 = unsigned integer 32;
option phone-number code 135 = text;
subnet 10.10.1.0 netmask 255.255.255.0 {
default-lease-time 36000;
max-lease-time 36000;
# --- default gateway

option routers 10.10.1.1;
option subnet-mask 255.255.255.0;
option domain-name “ds2.es”;
option domain-name-servers 154.15.255.230;
option time-offset -5; # Eastern Standard Time
range dynamic-bootp 10.10.1.30 10.10.1.55;
option nis-domain “ds2.es”;
56
host node1 {
hardware ethernet 00:50:C2:00:00:11;
fixed-address 10.10.1.41;
option phone-number “961366004”;
option tftp-server-name “10.10.1.28”;
option extensions-path-name “cpe.txt”;
}
host node2 {
option extensions-path-name “he.txt”;
option ifcp-code 35;
}
host node3 {
hardware ethernet 00:50:C2:12:6b:b3;
option extensions-path-name “du100.txt”;
}

RADIUS Support
13 RADIUS Support
Every AV200 Master and Repeater node implements a RADIUS client to
authenticate users (Slaves) connected via Powerline to that node. The mo-
dem acts as a NAS, which requests authentication, grants authorization,
and allocates resources.
13.1 RADIUS Client

The RADIUS client implemented in the AV200 nodes is configured via the
auto-configuration file with three parameters:
• RADIUS server IP address

• RADIUS server UDP port
• Shared secret password between client and server
Each RADIUS request sends the following two RADIUS standard at-
tributes:
• MAC address of the slave trying to join the network as User name.
• MAC address of the master as NAS-Identifier. 57
13.2 RADIUS Server

13.2.1 Installing Freeradius Server (v0.8.1)
Any RADIUS server will function with AV200 RADIUS clients. The following
is an example with the Linux freeradius server:
Extract the freeradius tar file, compile, and install the RADIUS server:
tar zxvf freeradius 0.8.1.tar.gz

cd freeradius 0.8.1
./configure
make
make install
Then the configuration RADIUS files are installed in /usr/local/etc/raddb/

and the log file can be seen at /usr/local/var/log/radius/radius.log.
IMPORTANT: Each time a configuration file is changed, the RADIUS server

daemon must be restarted as follows:
killall radiusd
radiusd

RADIUS Support
13.2.2 Configuring Freeradius Server with DS2 Options
The RADIUS server must be configured to handle client queries in the cor-
rect way. It must supply the client with the following information:
• Access-Accept or Access-Reject message.

• Profile number. Attribute DS2-profile.
Optionally, the RADIUS server can also supply the client with the following
information:
• Type of firmware: MV, LV or EU. Attribute DS2-fw.
NOTE: This optional information will not be used if the parameter

PROFILE_FWTYPE is defined in the profile associated with the new
user. It is recommended to use the PROFILE_FWTYPE parameter rath-
er than include this information in the RADIUS response.
The first point is decided by RADIUS standard procedures, according to the

user name and NAS-Identifier attributes sent by the client. The last two are
vendor-specific attributes (from DS2) and are defined in a new RADIUS dic- 58
tionary file, dictionary.ds2, which must be included in the RADIUS server
(dictionary file in the Linux RADIUS server) as follows:
$INCLUDE dictionary.ds2

Then, all possible clients must be defined in the clients.conf file on the
RADIUS server. A set of clients in the same sub-network can be included in

the same declaration:
client 10.10.1.0/8 {
secret = test
shortname = private-network-2
}
To use only a specific RADIUS client (Master), write its IP address (without
netmask) as follows:
client 10.10.1.15 {
secret = test
}
The secret password must be the same as the one configured in the auto-
configurationfiles on the AV200 nodes.

RADIUS Support
Finally, the file USERS must contain all of the MAC addresses to be authen-
ticated with their corresponding attributes, including USER-PASSWORD
with the value “ANONYMOUS”. Another option is to force the NAS-Identi-
fier. If the NAS-Identifier is defined, the user will be authenticated only if
the requesting client (the Master) is the one configured in the file. Other-
wise, the user will be rejected:
0050C2000011 Auth-Type := Local, User-Password ==

“anonymous”, NAS-Identifier == “0050C2000015”
DS2-profile = 2
To set a special configuration for connection to a specific Master, and a

default profile for connection to all other Masters, the file USERS can be
written as follows:
DEFAULT
Fall-Through = Yes
0050C2000011 Auth-Type := Local, User-Password == “anonymous”,
NAS-Identifier == “0050C2000015”
DS2-profile = 2
0050C2000011 Auth-Type := Local, User-Password == “anonymous” 59
DS2-profile = 2
DEFAULT
Auth-Type := Reject

Auto-configuration Console

14 Auto-configuration Console

14.1 Configuring Boot Mode from the Console

The boot mode can be obtained and changed through the console. Navi-
gate to the auto-configuration menu (ac) and type i for information (i) to
display the following:
Autoconfiguration Info
======================
…
Autoconf Boot Mode: NVRAM|AUTOCONF
Autoconf_next: NVRAM|AUTOCONF
DHCP status: enabled|disabled
Autoconf VLAN mode: ENABLED
Management VLAN: 5
...
The first line shows the current auto-configuration boot mode. It can be
AUTO for auto-configuration or NVRAM. The next line is only shown if the
current boot mode is AUTO, and it refers to the boot mode setting for the 60
next boot up. For example, if a node has been auto-configured, but the
GENERAL_USE_AUTOCONF parameter of the file was set to no, the auto-
configuration information will show the following:
Autoconf Boot Mode: AUTOCONF

Autoconf_next: NVRAM
The DHCP status only appears when in NVRAM boot mode, and it shows
whether DHCP is enabled or disabled.
14.1.1 Boot Mode
To change the boot mode, use the bm command as follows:
bm [AUTO|NVRAM]
To enable or disable DHCP while working in DHCP mode, use the dhcp
command:
dhcp [enable|disable]

14.1.2 VLAN Configuration
The VLAN mode is also displayed in the auto-configuration information,

and can be enabled or disabled. When the VLAN mode is enabled,the
Management VLAN in NVRAM is also displayed, or the PTTP, if the Man-
agement VLAN was obtained through PTTP.
To change the VLAN working mode, the vconf command can be used as
follows:
vconf [0|1] <mnmt_vlan_msb> <mnmt_vlan_lsb>
The first argument enables or disables the VLAN mode. Then enter the
two bytes of the Management VLAN. All of this information is stored in
NVRAM and takes effect at the next boot.
14.1.3 PTTP MODE
By default, the modem starts with PTTP enabled; that is, upon booting up,

the modem will try to acquire the translation table via PTTP requests. Some
modems should not boot in PTTP mode (see Section 4: PTTP Protocol). 61
To disable PTTP manually (at the next boot), execute the following steps:
• Using a DHCP server, set an IP on the modem. This can take some
time because sometimes the modem will be sending DHCP requests
with VLAN #1, and others may not have VLAN active.
• Once the modem has an IP, log in to the console and execute the
following commands:
NOTE: Due to VLAN switching, the console might appear to hang; if

this occurs, simply log out of the console and log in again.
» ac stop: Stops the auto-configuration process (and also PTTP) and

disables the VLANs. It is advisable to execute this command first in
order to work with the modem more comfortably. This command
writes nothing to NVRAM, so it only takes effect after the modem
is reset.
» ac pttpmode set 0: Disables PTTP at the next boot, writes to
NVRAM. (“ac pttpmode set 1” enables PTTP in the next boot, writes
to NVRAM.)
» ac pttpmode get: Checks the PTTP state for the next boot, reads
from NVRAM.

NOTE: DHCP should be used (if possible) to disable PTTP.
14.1.4 Configuration Show Command
To show the running or stored NVRAM configuration, use the csh com-
mand as follows:
csh {RUN|NVRAM|?} [params_set]
To show help, execute the csh ? command.
Usage: csh {run|nvram|?} [params_set]

run : Shows the running configuration
nvram: Shows the configuration stored in NVRAM
? : Shows this help
params_set:
all : All parameter sets
general: General configuration parameter set
radius : Radius parameter set
cos : Class of Service parameter set
qos : Quality of Service parameter set 62
profile: Profile parameter set
transt : Translation table parameter set
vlan : VLAN parameter set
ovlan : OVLAN parameter set
accessp: Access Protocol parameter set
stp : Spanning Tree Protocol parameter set
macfilt: MAC filtering parameter set
custv : Custom VLAN parameter set
custProfv : Custom VLAN Profile parameter set
custov : Custom OVLAN parameter set
custProfov: Custom OVLAN profile parameter set
Ntp : Network time protocol parameter set
agc : Automatic Gain Control parameter set
bp : Backplane parameter set
plch : PLC Header extension parameter set
snmp : SNMP Trap parameter set
td : Time domain Multiplier parameter set
To get the currently running configuration for STP parameters, execute the
csh run stp command as follows:

Showing running-configuration...
# - Spanning Tree Protocol Parameters Set -
STP_PRIO = 780
STP_PORT.1 = EXTA
STP_PORT.2 = PLC
STP_PORT.3 = EXTB
STP_PORT_PRIO.1 = 5
STP_PORT_PRIO.2 = 60
STP_PORT_PRIO.3 = 73
STP_PORT_COST.1 = 1480
STP_HELLO_TIME = 15
STP_MAX_AGE = 250
STP_FORWARD_DELAY = 50
Any one of the parameter sets described above in the csh ? command can
be used.
To get the NVRAM-stored configuration, execute the csh nvram stp com-
mand as follows:
63
Showing NVRAM-stored configuration...
# - Spanning Tree Protocol Parameters Set –
If the parameters are not stored in NVRAM, that is ‘use_autoconf = no’, no

parameters will be shown except for the basic configuration which must
be present before the auto-configuration process is performed. Called the
general set, csh nvram general, these basic parameters are as follows:
Showing NVRAM-stored configuration...

# - General Configuration Parameters Set -
GENERAL_USE_AUTOCONF = YES
GENERAL_MAC_MODE = ACCESS
GENERAL_TYPE = HE
GENERAL_FW_TYPE = LV
GENERAL_STP = YES
GENERAL_IP_ADDRESS = 10.0.0.101
GENERAL_IP_NETMASK = 255.0.0.0
GENERAL_IP_GATEWAY = 10.0.0.1
GENERAL_SIGNAL_MODE = 6
NOTE: The csh run all command can be copied and pasted in a new
autoconfiguration file for the next time.

Appendix A: Auto-configuration Example

In this example, a small PLC network will be built using autoconfiguration,
including VLAN and OVLAN configuration and RADIUS authentication.
The basic network depicted below represents 4 AV200 nodes: 1 HE, 1

TDREPEATER and 2 CPEs, each belonging to a different data operator.
DHCP, TFTP and RADIUS server

Backbone
TRANSLATION TABLE:
MNMT VLAN = 5
DATA VLAN 1 = 45
MAC: 000BC2000011 HE DATA VLAN 2 = 46
DATA VLAN 3 = 47
ROOTHPATH OVLAN = 77
VLAN TRUNK:
64
VLAN ACCESS:
REP MAC: 000BC2000011
MAC: 000BC2000014 MAC: 000BC2000015

DATA OP: 1 DATA OP: 3
CPE #1 TX/RX txput: 1000/2000
CPE #2 TX/RX txput: 500/500
Laptop computer Laptop computer

A.1 Setting Up the Equipment on the DHCP Server

The first thing to do is enter the equipment on the DHCP server. Each
AV200 node must have an entry on the DHCP server, with the assigned IP
address, the IP address of the TFTP server, the phone number (in the case
of a CPE) and the name of its auto-configuration file:
host he {
option extensions-path-name “he.txt”;
option ifcp-code 5;
}
host tdrepeater {
option extensions-path-name “tdrepeater.txt”;
}
host cpe#1 { 65
option extensions-path-name “cpe_op1.txt”;
}
host cpe#2 {
option extensions-path-name “cpe_op3.txt”;
}
The Master node, being the one connecting to the backbone, must be
configured to skip PTTP and use VLAN #5 as the Management VLAN. The
DHCP server must be accessible via VLAN #1 or without VLAN (in addition
to Management VLAN #5).

A.2 Generating the Auto-configuration Files

Next, the necessary auto-configuration files are generated, paying special
attention to the profile issues because the RADIUS server will have to be
configured accordingly.
# File: he.txt
# General parameters
GENERAL_USE_AUTOCONF = yes
GENERAL_TYPE = HE
GENERAL_STP = yes
GENERAL_AUTHENTICATION = RADIUS
# Signal parameters
#Translation Table
TRANSLATION_DATA_VLAN.3 = 47 66
#Radius parameters
RADIUS_SERVER_IP = 10.10.1.28
RADIUS_SERVER_PORT = 1812
RADIUS_SHARED_SECRET = test
# Class of Service parameters
COS_CRITERION.1 = 8021p
#QoS Configuration
QOS_ENABLE = no
#Vlan additional configuration
#Ovlan configuration
OVLAN_ENABLE = yes
#Profile information
Profile information for the HE is not necessary because in this example,

there is no End User node connecting directly to the HE. Additional VLAN
configuration (private VLANs) is also not necessary. The translation table
needs to be configured because in this example, there is no MV node at-
tached to the LV HE.
# File: tdrepeater.txt

GENERAL_TYPE = TDREPEATER
GENERAL_STP = yes
GENERAL_AUTHENTICATION = RADIUS
# Signal parameters
GENERAL_SIGNAL_MODE_LIST.1 = 7
# Radius parameters
RADIUS_SERVER_IP = 10.10.1.28
RADIUS_SERVER_PORT = 1812
RADIUS_SHARED_SECRET = test
# Class of Service parameters
COS_CRITERION.1 = 8021p
#QoS Configuration
QOS_ENABLE = yes
QOS_LATENCY_STEP = 40
QOS_BW_POLICY = 1
QOS_LATENCY.3 = 8
# Vlan additional configuration 67
OVLAN_ENABLE = yes
#Profile information
PROFILE_MAX_TXPUT_TX.2 = 1000
PROFILE_MAX_TXPUT_RX.2 = 2000
PROFILE_PRIORITIES.2 = FF
PROFILE_MNMT_VLAN.2 = %MNMT
PROFILE_DATA_VLAN.2 = %DATA1
PROFILE_FWTYPE.2 = EU
PROFILE_FWTYPE.3 = EU
Profiles are defined within the properties of the End User in terms of QoS
and VLANs. Note that parametric values are used, which will be resolved
with the translation table, transferred from the HE via PTTP. Finally, there
are the End User auto-configuration files, one per operator and product
(in bandwidth terms):

# File: cpe_op1.txt
GENERAL_TYPE = CPE
GENERAL_FW_TYPE = EU
GENERAL_STP = yes
QoS parameters
QOS_ENABLE = yes
QOS_MAX_TXPUT_TX = 1000
#Vlan configuration
VLAN_DATA_PRIO = 3
OVLAN_ENABLE = yes
#Access protocol parameters
#AP_FORBID_MASTER.1 = 0x0050c2000010
# File: cpe_op3.txt
# General parameters 68
GENERAL_TYPE = CPE
GENERAL_STP = yes
# QoS parameters
QOS_ENABLE = yes
QOS_MAX_TXPUT_TX = 500
# Vlan configuration
VLAN_DATA_PRIO = 3
# Ovlan configuration
OVLAN_ENABLE = yes
# Access protocol parameters
#AP_FORBID_MASTER.1 = 0x0050c2000010
Note that the QoS and VLAN configuration must correspond with the pro-
file definition in the TDREPEATER file. The Access protocol parameters sec-
tion can be used to fix or forbid masters, but RADIUS authentication with
NAS-Identifier is used to accomplish this job here, avoiding the need to
connect the Slaves directly to the HE.

A.3 Configuring the RADIUS Server

Once the DHCP server is set up and the files are written and ready to
download from the TFTP server, the RADIUS server must be configured.
The NAS-Identifier option is used to forbid access to the network by un-
expected Masters (for example if a CPE tries to access the PLC network
through the HE).
A.3.1 clients.conf File
The file clients.conf contains a list of the allowed RADIUS clients for the
system. An entire subnetwork can be configured as a client, with all of
them using the same shared secret password (in the auto-configuration
file) as follows:
client 10.10.1.0/8 {
secret = test
}
This declaration allows all the RADIUS clients (Masters and Repeaters) in 69
the subnetwork to use the RADIUS server.
A.3.2 users File
The users file contains all users (Slaves) that access the PLC network and
need to be authenticated, so all the Repeaters and Slaves to be authenti-
cated must be added. The RADIUS server will also provide additional in-
formation to configure the port to the user in QoS and VLAN terms as
follows:

DS2-profile = 1
DS2-profile = 2
DS2-profile = 3
Each user has a new entry in the file. The NAS-Identifier is specified. If the
access request comes from another Master, the user will be rejected. If the
NAS-Identifier is not configured, the user can access the network from any

Master. The decision whether or not to use the NAS-Identifier depends on

the network deployment.
The RADIUS client is also provided with information about the node type
(MV, LV or EU) and the profile. With this information, the Master config-
ures the port to the new user.
A.4 Preparing the Equipment

This step is only required if the ifcp-code DHCP custom option to skip the
PTTP code in the node attached to the backbone is not used. If this is ac-
complished, no intervention in the modems is required.
The equipment must be set up to use auto-configuration (default). In the

case of the HE, the Management VLAN must be written in the NVRAM (if
needed), because it is the first node attached to the backbone and it will
fix the use of VLAN and also disable the use of PTTP (active by default). The
rest of the equipment is configured by default because the PTTP will start
requesting the translation table and checking the use of VLAN.
Inside the HE console, the Management VLAN tag is set up and the use of 70
PTTP client is disabled as follows:
vconf 1 0 5
pttpmode set 0
A.5 Placing the Equipment in the Field

The AV200 nodes are now ready to be deployed in the field.

Appendix B: VPN using Private OVLANs
This section provides a solution for implementing VPN by means of a

private OVLAN. The VLAN can have any configuration; this setup can even
be used without VLANs.
71
In Figure 13, a private OVLAN has been defined between EUs #2 and
#3. EU #1 has the basic OVLAN configuration with rootpath. In order to
achieve the private OVLAN the following steps are necessary:
• All EUs in the private OVLAN must have an OVLAN_TAG different

from the %ROOTPATH. In this example, the OVLAN is 43. So the
autoconfiguration file of EU #2 and #3 must be the following:

OVLAN_DATA_TAG = 43
• The corresponding Master of each EU belonging to the private

OVLAN must allow the OVLAN tag in their port to the EU. This is
profile information. In the profile parameters of the REP and HE,
the following parameter must be added:
PROFILE_OVLAN_ADD_TAG.profile = 43
• Intermediary equipment between EUs belonging to the same

private OVLAN must set up an OVLAN trunk for that tag. In both
HE and REP, add the following:
OVLAN_TRUNK.1 = 43
72

Appendix C: “CUSTOM_VLAN_OVLAN” Examples

When activating the “use_custom_vlan” parameter, it is essential to as-
sign permissible values for the parameters, or there will be no connection
between the modems.
The figure below is an example of a simple scenario. We want to configure

the Ethernet port of an EU as a trunk port to accept tagged packets. We
also want to configure the Ethernet port of an LV node as an access port
to tag the untagged traffic. In order to create this scenario, the following
autoconfiguration files are needed.
73

You can configure the modems using parametric values or fixed values.
Examples for both cases are given below:
Parametric values example:
-he_autoc.txt
GENERAL_TYPE = HE
GENERAL_AUTHENTICATION = AUTHLIST
GENERAL_STP = yes
SIGNAL_SUB_MODE = 0
# Access Protocol parameters
ACCESSP_AUTHLIST_MAC.1=0x0050C22CF340 #This is the MAC of
the TD repeater
ACCESSP_AUTHLIST_PROFILE.1=3
ACCESSP_AUTHLIST_FWTYPE.1=LV
#Profiles 74
#Translation Table
TRANSLATION_MNMT_VLAN=5
TRANSLATION_DATA_VLAN.1=7
#VLAN parameters
VLAN_ENABLE = yes
VLAN_MNMT_TAG = %MNMT
VLAN_MNMT_PRIO = 4
#Ovlan parameters
OVLAN_ENABLE = yes
# Custom vlan parameters
USE_CUSTOM_VLAN_OVLAN = yes
VLAN_FILTER_INGRESS = yes #For this example not needed but is
good for security

The file for the Master only needs to add the new tags to the translation
table. We have also enabled the custom VLANs only to enable the ingress
filtering because it provides a more secure network configuration.
-tdrep_autoc.txt
GENERAL_STP = yes
GENERAL_IP_USE_DHCP = yes
# Vlan parameters
VLAN_ENABLE = yes
# Ovlan parameters
OVLAN_ENABLE = yes
# Profiles
PROFILE_MAX_TXPUT_RX.1 = 512 75
# We add this new tag to the profile. We can use the parameter
PROFILE_DATA_VLAN if the tag is only one.
# But if we want more than one data tag in the profile we have to use
the next parameter
PROFILE_VLAN_ADD_TAG.2.1 = %DATA3
VLAN_FILTER_INGRESS = yes
AP_MIN_NUMBER_HOPS = 0

ACCESSP_AUTHLIST_MAC.1=0x0050C22CF446
ACCESSP_AUTHLIST_FWTYPE.1=EU
The file for the Repeater includes the new tags in the profiles and also
enables the ingress filtering.
-eucpe_autoc.txt
GENERAL_TYPE = CPE
# Vlan parameters
VLAN_ENABLE = yes
VLAN_DATA_TAG= %DATA1 76
VLAN_DATA_PRIO= 4
# Ovlan parameters
OVLAN_ENABLE = yes
VLAN_OUTFORMAT_TAG_IFACE_EXTA=yes
VLAN_IS_ALLOWED_IFACE_EXTA=yes
VLAN_LIST_IFACE_EXTA.1=%DATA3
VLAN_IS_ALLOWED_IFACE_ROOT=yes
VLAN_LIST_IFACE_ROOT.1=%DATA3
The EU file only needs to add the new tag to the allowed list of the Ether-
net and ROOT ports.
-lvcpe_autoc.txt
GENERAL_TYPE = CPE

# Vlan parameters
LAN_ENABLE = yes
VLAN_DATA_TAG= %DATA2
VLAN_DATA_PRIO= 4
# Ovlan parameters
OVLAN_ENABLE = yes
VLAN_PVID_EXTB=%DATA4 #We configure the EXTB as access port
VLAN_OUTFORMAT_TAG_IFACE_EXTB=no
The LV CPE file only needs to configure the Ethernet as access port (by de-
fault, it is a trunk port). It is not necessary to add the new tag to any list.
Because it is in the translation table, the tag will be allowed by both the 77
ROOT port and the Ethernet port (because this node is an LV CPE).
Fixed values example (non-parametric):
-he_autoc.txt
GENERAL_TYPE = HE
GENERAL_STP = yes
SIGNAL_SUB_MODE = 0
ACCESSP_AUTHLIST_MAC.1=0x0050C22CF340 #This is the TDrepeater
#Profiles
#Translation Table
TRANSLATION_MNMT_VLAN=5

#VLAN parameters
VLAN_ENABLE = yes
VLAN_MNMT_TAG = %MNMT
VLAN_MNMT_PRIO = 4
VLAN_TRUNK.1=300 #for this example we use trunk vlans.
VLAN_TRUNK.2=1500
#Ovlan parameters
OVLAN_ENABLE = yes
#You don’t need to use custom vlans in the HE for this example.
#Only if you are interested in enable Ingress Filtering
USE_CUSTOM_VLAN_OVLAN = no
Now the new tags are not in the translation table. In the HE file we have to
add the tags as trunk tags. We do not need to use custom VLANs for this.
-tdrep_autoc.txt
# General parameters 78
GENERAL_STP = yes
GENERAL_IP_USE_DHCP = yes
# Vlan parameters
VLAN_ENABLE = yes
# Ovlan parameters
OVLAN_ENABLE = yes
# Profiles

PROFILE_VLAN_ADD_TAG.2.1 = 300
PROFILE_VLAN_ADD_TAG.3.1 = 1500
VLAN_LIST_IFACE_ROOT.1=300
ACCESSP_AUTHLIST_FWTYPE.1=EU
ACCESSP_AUTHLIST_FWTYPE.2=EU 79
The repeater needs to add the new tags to the corresponding profiles and
also to the ROOT port list. We use the custom VLANs to configure this.
-eucpe_autoc.txt
GENERAL_TYPE = CPE
# Vlan parameters
VLAN_ENABLE = yes
VLAN_DATA_TAG= %DATA1
VLAN_DATA_PRIO= 4
# Ovlan parameters
OVLAN_ENABLE = yes
VLAN_OUTFORMAT_TAG_IFACE_EXTA=yes

VLAN_IS_ALLOWED_IFACE_EXTA=yes
VLAN_LIST_IFACE_EXTA.1= 300
VLAN_LIST_IFACE_ROOT.1= 300
The configuration for the EU is the same before but using the fixed value
instead of a parametric one.
-lvcpe_autoc.txt
GENERAL_TYPE = CPE
# Vlan parameters
VLAN_ENABLE = yes
VLAN_DATA_TAG= %DATA2 80
VLAN_DATA_PRIO= 4
# Ovlan parameters
OVLAN_ENABLE = yes
VLAN_PVID_EXTB=1500
VLAN_OUTFORMAT_TAG_IFACE_EXTB=no
VLAN_IS_ALLOWED_IFACE_EXTB=yes
VLAN_LIST_IFACE_EXTB.1=1500
Now the LV CPE has to add the new tag to the Ethernet list and the ROOT
port list because the new tag is not in the translation table. We can see
that the configuration using the translation table and parametric values is
a bit simpler.

AV200 Alma Autoconfiguration CXP-HD200-WMEFe ENG

Uploaded by

Copyright:

Available Formats

AV200 Alma Autoconfiguration CXP-HD200-WMEFe ENG

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AV200 Alma Autoconfiguration CXP-HD200-WMEFe ENG

Uploaded by

Copyright:

Available Formats

Corinex AV200

Corinex Communications Corp. assumes no responsibility or liability for any errors or

It is our policy to enhance our products as new technologies, hardware components,

Corinex is a registered trademark of Corinex Communications Corp.

Copyright (c) 2001-2010 by Corinex Communications Corp.

2010-11-05 ver. 4.2

Corinex ALMA Auto-configuration

CORINEX COMMUNICATIONS CORPORATION

Corinex ALMA Auto-configuration

Corinex ALMA Auto-configuration

Corinex ALMA Auto-configuration

Corinex ALMA Auto-configuration

• Enterprise versions of the AV200 Powerline Ethernet Adapter, AV200

• Low Voltage Access Gateway (LV)

• High Density Access Gateway (HD)

• Medium Voltage Access Gateway (MV)

• GPON BPL Gateway

Some parameters for the auto-configuration are product specific. These

Corinex ALMA Auto-configuration

This document assumes the following basic prerequisites and

2. Each piece of equipment has a reserved static management IP address

3. The network operator has detailed configuration information for each

4. The Management VLAN for connected PLC equipment may be

5. There may be more than one Data VLAN per transformer.

7. Adding a new, non-generic CPE requires manual configuration over

9. The transformer of each MDU Gateway and LV Gateway is known. The

Corinex ALMA Auto-configuration

Below is a brief description of this process :

1. Every modem starts with the same default factory configuration:

2. Using PTTP (explained later in this document), the modem discovers if

4. Using TFTP protocol, each modem downloads the auto-configuration

• In order to achieve a secure network, PLC authentication is introduced.

Corinex ALMA Auto-configuration

• This modem starts with the same default factory configuration:

3.1 Auto-configuration at Modem Boot

3.1.1 Auto-configuration-PTTP Boot

IIn this auto-configuration boot mode, the modem always starts up as a

3.1.2 Auto-configuration-noPTTP Boot

In this auto-configuration boot mode, the modem has already been

3.1.3 NVRAM Boot

When a modem starts in NVRAM mode, it collects all of the configured

Corinex ALMA Auto-configuration

parameters from NVRAM memory and configures the firmware

• GENERAL_TYPE: Modem type – HE, CPE, or TDREPEATER.

Corinex ALMA Auto-configuration

Although the translation table is comprised mainly of VLAN parameters,

With the current FW version, when a modem boots in auto-configuration

4.1 PTTP Booting

• Step 1: An PTTP request is made without VLANs and waits for

Corinex ALMA Auto-configuration

A modem must not do PTTP (Auto-configuration-noPTTP Boot) in the

• It is the first node of the network (directly connected to the

• Using the DHCP server (must be accessible through VLAN #1 or

• Write a byte to NVRAM via console. In this type of bootup, the

To disable PTTP through DHCP (Method 1), see Section 12.

If no OVLANs/VLANs are to be used in the network, the PTTP protocol can

Corinex ALMA Auto-configuration

Corinex ALMA Auto-configuration

5.1 Transferring the Translation Table