Professional Documents
Culture Documents
EDA 1200
Copyright
Disclaimer
No part of this document may be reproduced in any form without the written
permission of the copyright owner.
The contents of this document are subject to revision without notice due to
continued progress in methodology, design and manufacturing. Ericsson shall
have no liability for any error or damage of any kind resulting from the use
of this document.
Legal Notice
The Linux Core system is the operating system for the Ethernet Node Controller
in ECN. The Linux distribution for ECN is based on standard open source
packages widely used in the Linux community. For more information about the
license refer to Third Party License Agreement.
Only the telnet part and some supporting libraries have been included from the
Commons Net package by Ericsson Denmark.
Please refer to the Third Party License Agreements for the license terms.
Trademark List
Contents
1 Introduction 1
1.1 Conventions 1
1.2 Revision Information 2
1.2.1 This Revision (F) 2
1.2.2 Version E 2
1.2.3 Version D 2
1.2.4 Version C 2
1.2.5 Version B 2
1.2.6 Version A 3
3.4 ECN330 29
3.4.1 Fixed Topology 29
3.4.2 Fixed Topology - Supported embedded units 30
3.4.3 Fixed Topology - Daisy Chain Scenario 32
3.4.4 Fixed Topology - Star Scenario 33
3.4.5 Flexible Topology 34
3.4.6 Port Designation 34
3.5 ECN320 34
3.5.1 Fixed Topology 34
3.5.2 Flexible Topology 34
3.5.3 Port Designation 34
3.6 Topology Limitation with Old ECN HW Versions 35
3.6.1 ECN330 up to R1D 35
3.6.2 ECN320 R3B or Higher (128 MB Flash) 35
3.6.3 ECN320 Versions up to R3A (64 MB Flash) 35
3.7 Line and Node Identification 36
3.7.1 Basic Line and Node ID for Fixed Topology 36
3.7.2 Line and Node ID for an Extension Switch 36
3.7.3 Line and Node ID for Flexible Blocks 37
3.7.4 Line and Node ID for EXN104 38
3.8 Security 40
3.8.1 IP Packet Filter 40
3.8.2 SNMPv3 40
3.9 Time Synchronization in the EAN 41
4 User Interface 43
4.1 Ethernet Connections 44
4.1.1 ECN430 44
4.1.1.1 LEDs User Interface 44
4.1.1.2 Power Supply Input Connectors 47
4.1.2 ECN330 47
4.1.2.1 PoE Ports 48
4.1.2.2 LEDs User Interface 49
4.1.2.3 Power Supply Input Connector 50
5 Installation 51
7 Maintenance 55
7.1 Replacing ECN 55
7.1.1 Roll Back the ECN 56
7.2 Replacing a Fuse 57
7.3 Replacing a Fan Tray 57
8 Troubleshooting 61
8.1 Diagnose Switch Indicators 61
8.2 Power and Cooling Problems 62
8.3 Embedded units 62
8.4 CLI 64
9 Reference Information 65
9.1 Using a MIB Browser 65
9.2 Backup Using SNMP 69
9.2.1 Specify an FTP Server 70
9.2.2 Create the Backup Job 70
9.2.2.1 Automatic Backup 70
9.2.2.2 Manual Backup 71
9.2.2.3 Scheduled Backup 72
9.2.3 Backup Job Timers 73
9.2.4 Random Start Interval 75
9.2.5 Backup Job Activation 76
9.3 Restore Using SNMP 76
9.4 Built-in Local Configuration 76
9.4.1 Modifying Default Configuration Files 79
9.4.2 Exporting profiles 79
9.4.2.1 Importing profiles 79
9.4.2.2 Creating and Modifying ESN212 Configuration Files 80
9.5 Configuration of VLANs in Star Topology with ESN410 and
ECN330 81
9.5.1 General Configuration 81
9.5.2 VLAN Configuration in Daisy Chained Topology 81
9.5.2.1 Management VLAN Configuration for the First ESN410
Extension Switch 82
9.5.2.2 Configuration of the ECN330 83
9.5.3 VLAN Configuration in Star Topology 84
9.5.3.1 Management VLAN Configuration for the ESN410
Extension Switches 85
9.5.3.2 Configuration of the ECN330 86
9.6 Programs Packages under Open Source Licenses 87
9.6.1 Linux Kernel 88
9.6.2 Linux Applications 88
9.6.3 Linux Libraries 89
1 Introduction
This guide describes the EDA Ethernet Controller Node ECN and is valid for
ECN430, ECN330 and ECN320. The term ECN refers to all variants. The term
ECN330/ECN320 switch refers to ECN320 or ECN330 in switch mode.
The guide describes the concept, the hardware and the functionality.
Furthermore, it provides an overview of software features.
The guide is intended for both operation personnel and system administrators
responsible for operating and maintaining network equipment.
The guide does not attempt to give a complete explanation of the various
standards, but rather the implementation of the standards in the ECN. For more
information of the standards, please refer to the standard specifications.
In order to fully understand the function and use of the ECN within the EDA
context, read the System Description.
The guide can be printed on a monochrome printer, but illustrations are easier
to understand if a color printer is used.
1.1 Conventions
The following conventions apply for textual instructions (not screen dumps):
Tools->Options Means: Choose the Tools menu item, choose the Options
menu item.
Bold monospace letters mark text typed by the user (input) in Command
Line Interface (CLI).
[argument] the brackets indicate that this argument is optional and can be
omitted. If used, the brackets must not be typed.
Other than editorial changes, this document has been revised as follows:
1.2.2 Version E
This revision is made for EDA 1200 4.1 R7A.
Other than editorial changes, this document has been revised as follows:
1.2.3 Version D
This revision is made for EDA 1200 4.1 R6A.
Other than editorial changes, this document has been revised as follows:
1.2.4 Version C
Other than editorial changes, this document has been revised as follows:
1.2.5 Version B
This revision is made for EDA 1200 4.1 R3A.
Other than editorial changes, this document has been revised as follows:
1.2.6 Version A
This revision is made for EDA 1200 4.1 R2A. This is the first version of this
document and is based on the ECN User Guide 5/1553-HSC 901 101/2 Uen B.
Other than editorial changes, this document has been revised as follows:
The Ethernet Controller Node, referred to as the ECN, is composed of two main
components: The EMP (Ethernet Management Proxy), and the Ethernet switch.
The ECNs are: ECN430, ECN330 and ECN320. When differences between
the ECNs appear in the following this will be explained.
The ECN is a unit that is able to control and aggregate EDA nodes, which are
referred to as embedded units. Together, the ECN and the embedded units
constitute one logical node the Ethernet Access Node (EAN). The EAN is
managed as a single node.
The EAN can be configured in several ways depending on the type and number
of the embedded units connected to the ECN.
The following EDA nodes can be used as embedded units (for further details
refer to Section 3 on page 11):
ESN410
ECN330 switch
EFN324
Other 3rd party unmanaged switches can also be used in the EAN. These are
not considered embedded units.
All embedded elements are Plug and Play, and the EAN elements may be
placed in one cabinet, appearing physically as a single node, or distributed in
different sites on different locations. For information about the ECN430 switch,
refer to ECN430 Switch/EMN120 User Guide.
For information about the ECN330 switch, refer to ECN330-switch User Guide.
For information about the ECN320/ESN310 switch refer to the ESN310 User
Guide. For information about other nodes, please refer to the user guides
for the specific node.
As mentioned before, the EAN can be realized in many ways, using different
embedded units. The EDN288 is an EAN solution, which is, delivered in a
subrack. The EDN288 contains one ECN with 24 EDN312x IP DSLAMs
connected to all downlink ports, and thus supports 288 End-users. For a more
detailed description of this specific EAN, see the EDN288 Installation Guide.
The EAN topology is described in more detail in Section 3.1 on page 12.
The LCT can be accessed through the serial connection (console) on the ECN.
The IP address of the ECN is static only, and must be configured using the
Local Craft Tool (LCT).
All management options (except visual monitoring) require a User name and
Password before the ECN management can be accessed.
Alarms (SNMP traps or notifications) from embedded units and switching unit
are always sent to the EMP.
The alarms can also be inspected using the LCT Web. It is possible to see
two alarm views: Active and History. The following figure show the Active
alarm view.
Click details to see all the parameters of the alarm. All alarms are shown in the
alarm history, but only alarms that have a matching clearing alarm are shown in
the Active alarms. When an alarm is cleared (a clearing alarm received) the
original alarm will be removed from the Active alarms. Up to 100 alarms can be
shown in each alarm viewer. The oldest alarm will be deleted If 100 alarms are
shown and a new alarm is received, when there are 100 alarms in the active
view, an alarm will be sent each time a new active alarm is received (as long as
there are still 100 alarms in the view).
The ECN also contains an alarm filter. The filter function is always active, but
by default it is empty, and thus all alarms are allowed. The filter is configured
using the CLI by adding the alarms Object Identifier (OID) to the filter list.
Alarms that are defined in the filter will be discarded. They will not be shown in
the LCT and not sent to any alarm receiver.
For more information about the alarm viewers and alarm filter please refer to
the EMP Web Interface User Guide.
As described in the introduction, the ECN is the key element in the EAN.
Several nodes can be connected to the ECN, see Section 2 on page 5.
The basic topologies supported by the EDA system are described in more
detail in this section.
The EMP manages all the embedded units. From a management point of view,
the switching unit is also an embedded unit, even though it is located and
integrated in the ECN.
The whole EAN will appear in a management system as one large node with
many End-user lines. All End-user lines are terminated by a Line Termination
Unit (LTU). The LTU can be based on different drop technologies such as DSL,
Fiber or POTS. The traffic can be aggregated through the ECN or by another
Ethernet Switch unit.
The EMP has all the functions necessary to support embedded units like first
level alarm handling, device polling, network topology discovery, fault and
performance management.
The internal management VLAN of an EAN is (and must be) a different VLAN
than the external management VLAN, in order to separate the two logical
networks. Two different EANs may use the same VLAN for the internal
management traffic. This will have no consequences in terms of security,
since this VLAN is invisible to the rest of the network, outside the EAN. Apart
from the internal management VLAN, other VLANs are reserved for internal
use of the EAN.
End-user traffic must not be directed to any of the reserved VLANs. VLANs are
discussed in more detail in Section 3.1.7 on page 22.
In Section 3.1 on page 12 and Section 3.2 on page 24 the concepts and
topologies that are common for the ECN430, ECN330 and ECN320 are
described. Section 3.3 on page 28 describes specific features for ECN430.
Section 3.4 on page 29 describes specific features for ECN330 and Section 3.4
on page 29 describes specific features for ECN320.
The DMV concept deploys two VLANs for management. When an EDA node
restarts, it issues a DHCP discovery message. This message notifies any
DHCP server in the network that a node needs the services of the DHCP
server. The message is sent with the VLAN stored in the node. At this point
there are two possible scenarios:
1. The Management VLAN in the network is the same as the VLAN stored
in the node. When this is the case, everything in the network behaves
as usual.
2. The Management VLAN in the network is different from the VLAN stored
in the node. This is where DMV is used. The concept is explained in the
following.
The concept incorporates two IP address pools in the EMP: Temporary that is
used only during the VLAN change, and Real that is used when the node is
using the correct VLAN ID during normal operation.
3. The EMP will send a reply tagged with VLAN 248 containing IP address
from the temporary IP range and the Management VLAN. The VLAN tag
is stripped by the switching unit before sending it back to the node as
untagged traffic.
4. The node does not use the IP address but stores the new Management
VLAN ID.
5. A new DHCP discover message is issued tagged with the new VLAN ID
(246).
6. After verifying that the request came from VLAN 246, the EMP assigns a
real IP address to the node.
In order to extend the number of line terminations per EAN, it is possible to add
switches to the EAN. These switches can be either embedded switches in a
fixed topology or flexible block switches in a flexible topology.
In the Flexible Topology the ECN identifies the Flexible Block by the Switch ID
of the Flexible Block switch (ESN212, ESN204g) or EFN324. The Flexible
Blocks are automatically recognized by the ECN by their DHCP request. The
Flexible Block switch intercepts the DHCP requests of the underlying nodes
and inserts its own Switch ID as DHCP option 60. When the ECN assigns an IP
address to the node, this IP address is also entered into the inventory table of
the ECN. This enables the ECN to communicate and recognize all embedded
units in the Flexible Blocks. Note that if there is already an SID in a DHCP
request (for example, when two Flexible Block switches are daisy chained), the
switch will not intercept the request.
The two uplinks depicted in Figure 9 on page 17 may be on the same interface
and link.
The SID must be unique under one ECN in order for the node to act and be
recognized as a flexible block. Range of the SID: 1-254.
One EFN324
The SID must be set in the ESN212, ESN204g using DIP switches or EFN324
using the CLI. EDN612 IP DSLAMs connected to ESN212 (or ESN204g) are
identified using the SID of the ESN212 (or ESN204g) that the IP DSLAMs
are connected to.
Redundancy for a Flexible Block level can only be used with the ESN212. The
following is an example of a supported scenario:
ECN:
Configure the switching unit ports (using RCLI) for Link aggregation according
to the ECN Switch CLI Guide. This is only relevant when the Flexible block is
connected directly to the ECN.
ESN212:
Configure the ESN212 using RCLI or console for RSTP according to the
ESN212 CLI User Guide.
The VLANs for the daisy chained EANS must be setup to ensure that:
Service traffic can flow in both directions in VLAN A, D and E in the third
EAN.
As illustrated End-user traffic from the third EAN through VLAN A, D and E.
The uplink and downlink ports of the second EAN must there be manually
configured with VLAN A, D and E otherwise only traffic through service VLAN
B and C would be allowed.
For the same reasons the downlink ports of the first EAN have to be configured
with service VLAN A, B, C, D and E.
The uplink ports of the first EAN thus have to be manually configured with
service VLAN C, D and E. If End-users using A or B in the first switch in the
chain are removed, the VLAN will dissapear as well, therefore it is relevant to
consider configuring all service VLANs in the upper switch manually.
Link aggregation on a Flexible Block level can only be used with ESN212.
The following scenarios are supported:
Service VLANS need not be configured manually. The EMP will configure the
Service VLANs in the aggregated links automatically.
Static Link aggregation is set using CLI, by doing the following (the example
shows aggregated links between ports 3-4 on the ECN430 and 11-12 on the
ESN212 with flexible block id 43):
ECN430 Configuration
Start a terminal emulator (for example telnet) and login to the ECN430 with the
user name: admin and password: admin
ecn#rcli 0.0
switch#exit
switch#interface ge1/4
switch# static-channel-group 1
switch#exit
switch#exit
switch#exit
ESN212 Configuration
Start a terminal emulator (for example telnet) and login to the ECN430 with the
user name: admin and password: admin
ecn#rcli 1043.0
switch#configure terminal
switch#set port-channel enable
switch#interface port-channel 77
switch#no shutdown
switch#exit
Connect internal management VLAN to all ports and link aggregation group
(channel group number 77 is used)
switch#vlan 247
switch#ports gigabitethernet 0/1-10 port-channel 77
switch#exit
switch#exit
switch#exit
Both static and dynamic link aggregation can be used using the RCLI towards
each ESN212. For detailed information about how to configure link aggregation
please refer to command descriptions and example in the ESN212, ESN204g
CLI User Guide.
The ECN supports mixing any fixed and any flexible topology on node basis.
But it is not possible to mix different topologies per ECN port.
Apart from the mentioned VLANs, the EAN VLAN ID 4093-4095 are used
internally.
Thus VLAN IDs that can be used as Service VLAN IDs (with default
management VLANs) are:
Figure 16 Redundancy
In the ring structure, spanning tree must be used (configured using CLI) to
avoid loops in the network.
In each ECN the service VLANs from the other EANs must be configured using
a management system. The system does not set a limit to the number of
EANs that can be connected in a ring. However, other considerations such as
bandwidth or spanning tree size limit the practical size. The same scenario is
also valid for daisy chaining several EANs. In practice, because of the spanning
tree, this scenario is a daisy chain that changes the traffic direction if a link fails.
It is possible to use link aggregation with EANs. Static link aggregation is used.
Static Link aggregation is set using CLI, by doing the following (the example
shows aggregated links between ports 10-12 on the ECN430 and 25-27 on the
ECN330, and configure Service VLAN 7):
ECN430 Configuration
Start a terminal emulator (for example telnet) and login to the ECN430 with the
user name: admin and password: admin
ecn#rcli 0.0
switch#configure terminal
switch#interface ge1/22
switch#static-channel-group 1
switch#exit
switch#interface ge1/23
switch# static-channel-group 1
switch#exit
switch#exit
In the switching unit create link aggregation on auxiliary ports towards ECN330.
switch#configure terminal
switch#interface ge1/10
switch#static-channel-group 2
switch#exit
switch#interface ge1/11
switch# static-channel-group 2
switch#exit
switch#interface ge1/12
switch# static-channel-group 2
switch#exit
switch#exit
ECN330 Configuration
Start a terminal emulator (for example telnet) and login to the ECN330 with the
user name: admin and password: admin
3.3 ECN430
For a description of how the ECN430 is used in a fixed topology, see Section
3.1.2 on page 15.
The following figure shows the supported embedded units in EAN with Fixed
Topology using ECN430.
For a description of how the ECN430 is used in a flexible topology, see Section
3.1.3 on page 16.
3.4 ECN330
For a description of how the ECN330 is used in a fixed topology, see Section
3.1.2 on page 15. Additionally it is possible to expand the number of line
terminations in an EAN by adding extension switches when a ECN330 is used
in a topology.
Extension Switches
The ECN can be used for control of the extension switches with or without
aggregating the End-user traffic coming from these nodes. The management
VLAN and IP settings are configured manually in the extension switches using
the CLI. The ECN recognizes the extension switches by their IP address. The
EMP CLI is used to add the extension switches to the ECN. Refer to Section
9.1 on page 65 for detailed information about how to configure the ECN and
extension switches for the scenarios described in this section.
While embedded units are always fully managed by the ECN, the degree of
management on extension switches can vary depending on the extension
switch type. The following switches are supported as extension switches:
ESN310
ESN410
It is also possible to use ECN330 Switch (ECN acting as a switch only after
downgrading it from the CLI) or a third party switch. When an unmanaged
switch is used, all VLANs including internal management VLAN must be
manually configured in the switch with whichever tool that is available for the
specific switch. Up to 8 unmanaged switches can be connected to any of the
downlink ports. The only embedded unit that can be connected under an
unmanaged switch is EDN312.
The EXN104 converter on the remote site will in some cases (3, 4 and 6) need
a power node to supply the necessary power. When the ESN108 switch is
used to aggregate the EXN104 converter (combination 6) can supply both
the upstream and downstream converters with power through the Ethernet
cables. As indicated, the ESN108 is connected to the uplink EXN104 through
the electrical port 8, which must be configured in the ESN108 in order to
supply power through the uplink port 8. The configuration is done through the
command line interface of the EMP.
Note that the ECN330 has a 16K MAC table. The performance will be affected
if the maximum number of all nodes it forwards traffic to (including End-user
devices) exceeds 16,000.
Note: When daisy chaining Switch extensions, all extension switches must
be of the same type (for example, all extension switches are ECN330
switch).
For information about how to configure the VLAN settings, see Section 9.5
on page 81.
The first ESN410 is denoted Extension switch 1, the second Extension Switch
2 and so on. It is not possible to remove a lower extension switch from the
inventory, while a higher one exists (for example, one cannot remove extension
switch 2, while extension switch 3 is still in the inventory).
When the ESN410 extension switches are created (using the CLI), they must
be created as a switch extension with type esn410-uplink, so that the EMP
configures both internal and external management VLANs on the ECN ports.
When the ESN410 extension switches are created (using the CLI), they must
be created as a switch extension with type esn410-uplink, so that the EMP
configures both internal and external management VLANs on the ECN port.
ECN330 must be connected to the aggregation switch using one of the optical
ports 25 or 26 of the ECN. One or more of the ports 9 12 of the extension
ESN410s must be connected to the aggregation switch. Note that even though
the extension switches are not daisy chained, they are configured in the ECN
as if they are. Therefore, the same rule applies also for star topology: it is
not possible to remove a lower extension switch from the inventory, while a
higher one exists.
Note: If two star topology EANs has to be connected it must be done through
a third aggregation switch to ensure a separation of the internal
management VLANs of the two EANs.
The Gigabit Ethernet ports (25, 26 and 27) of the ECN330 must be used to
connect a flexible block.
For a description of how the ECN330 is used in a fixed topology, Section 3.1.2
on page 15.
ECN330 has two types of ports: Uplink ports (25, 26, 27) and Downlink ports
(1-24):
3.5 ECN320
ECN320 has two types of ports: Uplink ports (25 and 26) and Downlink ports
(1-24):
The ECN is identified with 0 and the ECN switch with 0.0.
If the EDN is connected directly to the ECN the ESN Port Number is 0.
The nodes are identified in the same way as the lines, except that the last
number is always 0.
uplink port 25, 26 or 27 on the ECN. The extension switch ports (ESN410) are
numbered according to the port number. Port 1 is numbered 101, port 2 is
numbered 102 and so on up to number 108. As a consequence the ports on
the IP DSLAM will be designated as follows:
The EAN can be extended with up to 7 switches, which are daisy chained or
star connected. The node number of the next switches will be Node 0.2, 0.3
0.4 and so on. The ports of the switches (ESN410) will be numbered from
201 to 212 and 301 to 312 and so on.
Note that for the EFN324, the Flexible Block Switch port is 0.
EXN104 converters inserted between the ECN and the ESN108 are identified
by the node numbers 100 (central) and 200 (remote) and EXN104 converters
inserted between an ESN108 and an IP DSLAM, are identified by the node
number 101 (central) and 102 (remote), see Figure 26 on page 39.
3.8 Security
Different features are implemented in the ECN to ensure security in the network
management system.
The firewall access control lists can be applied on the external management
interface (default VLAN 246) on the ECN. Applying access control lists makes it
possible to check all incoming traffic by the source IP address, the protocol and
the destination port number. All protocols and port numbers relevant for the
ECN can be included in rules in the firewall access lists.
A similar access control list is also implemented in the switch unit. For more
information refer to the ECN430 Switch/EMN120 User Guide.
3.8.2 SNMPv3
3 different groups (Context names) are defined with access to different MIBs,
and a user must belong to one of these groups. Access rights (read-only
and read-write) and a security level (no authentication, authentication
or authentication and encryption) are defined for each group. For more
information, refer to the System Description.
The local NTP server in the EMP synchronizes with the NTP client.
If a central NTP server is not used the CLI command calendar is used to set
time and date in the local NTP server of the ECN. See EMP CLI User Guide for
more information about the commands calendar and ntp.
4 User Interface
All connectors and LED indicators for ECN430, ECN330 and ECN320 are
located in the front panels.
4.1.1 ECN430
The ECN430 has the following Ethernet connections:
0 10G Module, 2*XFP and 2*elec: with two XFP (10G Small Form
Factor Pluggable) transceiver slots (optical), and two built-in Infiniband
X4 transceivers (electrical). The Infiniband X4 transceiver uses IEEE
802.3ak 10GBASE CX4 signals over Infiniband cable. The maximum
approved length of the cable for the ECN430 is 3m.
0 10G Module 4*XFP ports: with four XFP (10G Small Form Factor
Pluggable) transceiver slots (optical).
The ECN430 automatically detects the type of XFP module plugged in.
The unit also includes a display panel for key system and port indications that
simplify installation and network troubleshooting. The LEDs for the base unit,
which are located on the front panel for easy viewing, are shown in Figure 31
on page 44.
The optional 10 Gigabit slide-in module includes its own integrated LED
indicators on the modules front panel, as shown in Figure 32 on page 46 and
described in Table 3 on page 46.
The dual power supply input connectors are located on the front panel of the
ECN430. The standard power supply for the ECN430 is -48 VDC, and includes
protection through a disposable fuse (located beneath a plastic cover in the
top left corner of the front panel). Power redundancy can be established by
connecting both power inputs. If for some reason one of the power supplies
is out of order the other supply will automatically take over without any
disturbances.
4.1.2 ECN330
The PoE enables DC power to be supplied to the connected nodes through the
Ethernet cable. IP DSLAMs attached to a port can draw power directly from the
ECN over the Ethernet cable without requiring a separate power source. The
ECN automatically detects an EDA node by its authenticated PoE signature
and senses its required load before turning on DC power to the port. An electric
port of ESN108 (which is also a PoE node) can also be connected to the ECN.
The sense circuit in both nodes (ECN and ESN108) will sense that no power is
required. This detection mechanism also prevents damage to other network
equipment that is not an EDA node.
The ECN delivers power to the IP DSLAM using the two wire pairs in UTP or
STP CAT 5 cable that are not used for 10BASE-T/100BASE-TX connections
(for details, see ECN330-switch Users Guide). Each line is individually
controlled with an auto-detect circuit that opens up if a load within the
EDA-specified range is detected, and shuts down if the load exceeds the limit of
23.1 W. Each line is filtered for surge currents and has a 4 ms backup reservoir,
should short voltage drop outs occur.
The ECN can provide up to 600 mA continuously on each 10/100 Mbps port, or
up to 23.1 W of power. However, taking into account some power loss over
the cable, the amount of power that can be delivered to an EDA node is about
21 W. If a device draws more than 625 mA from a port, an overload condition
occurs and the port turns off the power.
The ports also support auto-negotiation, so the optimal transmission mode (half
or full duplex), and data rate (10 or 100 Mbps) can be selected automatically,
if this feature is also supported by the attached device. If a device connected
to one of these ports does not support auto-negotiation, the correct speed
will be sensed by the port, but the transmission mode will by default be half
duplex. Each port also supports auto-negotiation of flow control, so the ECN
can automatically prevent port buffers from becoming saturated.
The ECN controls the power and data on a port independently. Power can be
requested from a device that already has a data link to the ECN. In addition, the
ECN can supply power to a device even if the ports data connection has been
disabled. The power on a port is continuously monitored by the ECN and it will
be turned off as soon as a device connection is removed.
The unit also includes a display panel for key system and port indications that
simplify installation and network troubleshooting. The LEDs, which are located
on the front panel for easy viewing, are shown in Figure 34 on page 49 and
described in Table 4 on page 49.
The ECN has a dual power input with the purpose of achieving redundancy.
The power will be supplied by both power inputs.
If for some reason one of the power supplies is out of order the other supply will
automatically take over without any disturbances.
The power supply input connector is located on the front panel of the ECN.
The standard power supply for the ECN is -48 V DC, which includes protection
through a disposable fuse (located on the rear panel).
5 Installation
The ECN is configured with the initial parameters using the ECN Local Craft
Tool, see ECN430 Installation Guide and ECN330 Installation Guide for more
information. The configuration includes some basic configuration parameters
such as IP address, subnet mask and SNMP parameters.
The embedded units are configured automatically. When the nodes are
connected to the ECN, the Ethernet Management Proxy (EMP) recognizes the
new embedded unit and supplies it with all the necessary SW and configuration
parameters. For extensions switches configuration must be done manually.
Any embedded unit can be replaced at any given time, without the need of
registration. If the new node is the same type of node as the old one (for
example by replacing an EDN312 with another EDN312), all the configuration
of the old node including line provisioning will be configured automatically in
the new node. The line provisioning must be redone when changing to a new
type of node (for example, an EDN312x instead of an EDN312),. Special
requirements apply to the replacement of an ESN204g, see the EDA 1200
Generic User Guide for more information.
SW for the embedded units is installed on the ECN using management system,
CLI or the Web interface connecting to a FTP server.
This section describes the backup, restore and factory defaults functions in
the ECN.
Manual backup, which can be done using either the web interface, the
CLI or SNMP.
How to perform a manual backup and restore of the configuration using the
Web or CLI interface is described in the EMP CLI User Guide (CLI) and EMP
Web Interface User Guide (Web).
7 Maintenance
ECN320 can be replaced with ECN330 without reprovisioning provided that the
same ports are used.
To replace an ECN with the another ECN of the same type or ECN320 with
ECN330 using the same ports:
2. Disconnect the power and Ethernet connections from the ECN. The
Ethernet connections must be marked, so they can be reconnected to the
same port number in the new HW.
5. Connect the power and perform the basic configuration according to the
instructions in the ECN430 Installation Guide or the ECN330 Installation
Guide. Note that the IP address of the new node must be the same as
the old one.
6. Update the software if necessary. Note that this update should include
the EMP software as well as the software for all the embedded units. If
possible, use the EAN package to perform this update.
8. Connect the Ethernet connections to the downlink ports and any daisy
chained connections.
Note: When replacing an ECN with embedded units that do not use
Power over Ethernet (ESN108, ESN204g, ESN212 and EFN324),
the embedded unit must be restarted to be registered in inventory
of the ECN.
10. If multicast is used and the new element is an ECN, the proxy query
address should be configured in the new ECN switch for the corresponding
service VLANs. For example:
1. The Ethernet connections must be marked, if not already done, so that they
can be reconnected to the same port number. Disconnect the power and
Ethernet connections from the ECN.
Note: When replacing an ECN with embedded units that do not use
Power over Ethernet (in other words, ESN108, ESN204g, ESN212
and EFN324), the embedded unit must be restarted to be
registered in inventory of the ECN. If a node is not restarted, it will
be registered when it next sends a DHCP request. Registration is
required for communication between the ECN and the node.
the MAC address of the new node, and download the configuration to all
the embedded units.
Warning!
Power off the ECN before replacing a DC power supply fuse.
2. Unscrew the fuse holder counter-clockwise from its socket. Pull out the
blown fuse and discard it.
3. Insert a new 20 A, 250 V type T fuse into the fuse holder and screw the
holder clockwise back into the fuse socket.
To ensure proper cooling of the ECN, both fans must be operational. If one
fan fails the ECN will continue to run, but the fan tray should be replaced as
soon as possible.
The fan tray of the ECN can be completely removed without powering off the
unit. To replace a fan tray, follow these steps:
1. Remove the fan tray plastic access cover on the right side of the front panel
by pulling it open from the right.
3. Grasp the fan trays handle and pull it outward to disconnect it from the
ECN. Carefully slide the fan tray out of the ECN.
Do!
The new fan tray must be inserted immediately after the old one is removed.
4. Install a new fan tray in the ECN by sliding it into the empty slot. Push firmly
so that the fan trays connector is fully engaged with the ECN.
6. Check that the FAN status LED on the ECN front panel is off and that both
new fans are running.
7. Replace the fan tray plastic access cover on the ECN front panel by
pushing the covers right edge in until it snaps into place.
8 Troubleshooting
A port status There is no Verify that the ECN and attached device
LED is off valid link on the are powered on.
port
Be sure the cable is plugged into both the
ECN and corresponding device.
Verify that the proper cable type is used
and its length does not exceed specified
limits.
Check the adapter on the attached
device and cable connections for possible
defects. Replace the defective adapter or
cable if necessary.
A port status There is a Remove the connection to the port.
LED is flashing power overload
red or short circuit Check the connection cable and
on the port connectors for defects and possible short
circuits. Replace the network cable if
necessary.
If the network cable is verified to be OK,
replace the EDA device.
8.4 CLI
Table 7 Troubleshooting Chart
Symptom Action
Cannot connect Be sure the agent is configured with a valid IP address,
using Telnet or subnet mask and default gateway.
SNMP software
If trying to connect to the agent using the IP address for
a tagged VLAN group, the management station must
include the appropriate tag in its transmitted frames.
Check that there is a valid network connection to the
switch and that the port being used has not been disabled.
Check network cabling between the management station
and the switch.
If a Telnet session cannot connect, the switch may have
exceeded the maximum number of concurrent Telnet
sessions permitted. Try connecting again at a later time.
Cannot access Be sure the terminal emulator program is set to VT100
the on-board compatible, 8 data bits, 1 stop bit, no parity and 9600 bps.
configuration Check that the null-modem serial cable conforms to the
program through pin-out connections, see ECN330 Installation Guide or
a serial port ECN320 Installation Guide.
connection
Cannot connect If a connection using SSH fails, the maximum number
using Secure of concurrent SSH sessions permitted may have been
Shell exceeded. Try connecting again at a later time.
Be sure the SSH server is enabled and its control
parameters properly configured on the ECN430-switch,
and that the SSH client software is properly configured
on the management station.
Be sure a public key has been generated on the
ECN430-switch and this key exported to the SSH client.
Be sure an account has been set up on the ECN430-switch
for each SSH user, including user name, authentication
level, and password.
Be sure the clients public key has been imported to the
ECN430-switch (if public key authentication is used).
9 Reference Information
This section gives some additional information that is not needed for daily
operation.
Stop!
Do not set MIB parameters using a MIB browser if PEM is used. Use the
Advanced Node configuration if needed.
Since leading zeroes may be omitted, the digits are always counted from the
right. The following table explains the identifiers.
Table 8 Identifiers
Identifier Fixed Topology Flexible Topology
ECN Port or Switch ID Port no. on the ECN or Switch ID + 1000
(5 digits) extension switch :
ECN: 0+port No.
Switch ext. 1: 100+port
No.
Switch ext. 2: 200+port
No.
*
Switch ext. 7: 700+port
No.
Aggregation Switch Port Port No. Port No.
(2 digits)
For IP DSLAM For IP DSLAM
connected directly to connected directly to
the ECN/ext switch or the ECN/ext switch or
for EFN324, always 00. for EFN324, always 00.
OID type (1 digit) 0 : Line OID 0 : Line OID
1: Channel 0 OID (DSL 1: Channel 0 OID (DSL)
only)
2: Channel 1 OID (DSL)
2: Channel 1 OID (DSL
only)
Line No (2 digits) Line number on the Line number on the
node node
Table 9 Examples
ECN Port or Port on OID type Line No Identifier
Switch ID Aggregation
Switch
Port 1 on 3 Line 4 103004
ECN
Port 3 on ext. None Channel 0 10 20300110
switch 2
Switch ID = None Line 19 103500019
35
Switch ID = 4 Channel 1 12 112404212
124
Figure 36 on page 67 illustrates how the Line Identifier is used in the instance.
Note that not all OIDs have a PVC as an instance, in which case, only the Line
Identifier is added to the OID.
This query is performed toward the ECN and therefore no line identifier is
needed.
Refer to the ECN430 MIB Overview, the ECN430 MIB Description, the ECN330
and ECN320 MIB Overview and the ECN330 and ECN320 MIB Description for
detailed information about the MIBs.
Specify an FTP server. This includes specifying the name of the FTP
server, the IP address, the user name and the password of the FTP server.
Furthermore it is necessary to specify the file name and the path to the
directory where the backup file will be stored. It is possible to specify
several servers.
Create a backup job. This includes specifying the type of backup: manual,
scheduled or automatic. The name of the backup file and the path to the
directory where it will be stored needs to be specified as well.
Define timers for the backup job (optional). Timers are used for all SNMP
configured backups. For more information please refer to Section 9.2.3
on page 73.
Define random start interval for the job (optional). For more information
please refer to Section 9.2.4 on page 75.
Activate the backup job. For more information please refer to Section 9.2.5
on page 76.
User name: Define the user name for accessing the server.
Password: Specify the password for the user of the FTP server.
FTP server: This is the index that defines the FTP server to be used.
FTP server name: The name of the FTP server specified when it was created.
Either the index or the name or both can be used to specify the FTP server.
If no server is specified, the backup file will be placed locally on the ECN in
the directory: /var/backuptmp/.
Path: Specify the path to the directory on the FTP server where the backup file
is going to be stored (optional). If not specified the backup file will be stored in
the home directory of the user. Please note that Windows and Solaris servers
have different ways of specifying directories.
The name of the backup file can be extended. The following values can be
used:
Example: If the name of the backup file is fullbackup, setting the extension
value to 1 will add the date to the file name. The backup file will thus be
renamed to fullbackup20061005. If the value 2 is set, the name of the file
will be fullbackup1, the next backup will have the name fullbackup2 and
so on. Note that if the file extension is set to two for example, then after ten
backups, the new backup file will again have number 1 appended.
Timers: Set MinWait and MaxWait (both optional). Per default MaxWait is set
to zero and the backup will be executed immediately.
FTP server: This is the index that defines the FTP server to be used.
FTP server name: The name of the FTP server specified when it was created.
Either the index or the name or both can be used to specify the FTP server. If
no server is specified, the backup file will be placed locally on the ECN in the
directory: /var/backuptmp/
Path: Specify the path to the directory on the FTP server where the backup file
is going to be stored (optional). If not specified the backup file will be stored in
the home directory of the user. Please note that Windows and Solaris servers
have different ways of specifying directories.
The name of the backup file can be extended. The following values can be
used:
A scheduled backup is a backup job that will start running at a specified time.
The job can be configured to run a number of times at a specified interval.
The parameters are almost the same as described for a manual backup in
Section 9.2.4 on page 75 and the same MIB table is used.
The parameters specific for the scheduled backup is listed in the following. The
other parameters are set as for the manual backup.
Timers: Set MinWait and MaxWait (both optional). Per default MaxWait is set
to zero and the backup will be executed immediately.
Start: Specify the time when the backup will start. The time is the local time
on the ECN and must be specified in bytes. The two first bytes specify the
year, followed by month, day, hours, minutes and seconds all specified by one
byte each. The values must be converted to hexadecimal. Example: The date
2006-09-26 21:30:00 is specified as (2006 is 07D6): # 0x07 0xD6 0x09 0x1A
0x15 0x1E 0x00. The start time must be a time in the future.
Period: Specify the period between periodic backups. If the value is set to 0,
the backup will be run only once. The time must be specified in bytes in the
same way as for the start. Example: A period of one week can be specified as:
# 0x00 0x00 0x00 0x07 0x00 0x00 0x00.
Number of times: Specify the number of times the periodic backup will run. If
the value 0 is specified, the backup job will run after each period (interval) as
long as the backup job is not deleted.
MinWait a global parameter for all back jobs (default 1 hour). This timer
restarts every time a configuration change occurs.
MaxWait a specific parameter that can be set explicitly for each backup
job. This timer starts when there is a backup request. The default value for
this timer depends on the job type:
These timers are mostly effective when automatic backup is used. However,
they are active in all jobs initiated through SNMP. As long as the MaxWait is
zero, the timers will not have any effect, but by keeping them active, there is a
possibility to use them also in the manual or scheduled backup. The purpose
of the timers is to avoid initiation of a backup during a series of configuration
commands. The following figure illustrates what will happen if there are no
timers and the ECN is configured with multiple parameters (backup is set to
auto):
As can be seen from Figure 39 on page 73, three backup jobs will be initiated,
causing a lot of traffic on the links and load on the ECN processor. By
introducing some delay (timers) it is possible to wait until the configuration is
finished and then make one backup that includes all the new parameters. In
order to do that, the two timers are used. It is the timers that initiate the backup
job upon expiry, and the configuration (or activation of a backup through SNMP)
is a backup request that activates the timers.
As illustrated, if MinWait timer has a reasonable value, only one backup will be
made when the configuration is finished. However, as long as the node is being
configured, no backup will be taken. In order to ensure that a backup will be
taken at some point, MaxWait timer is used.
A backup will be initiated when any of the timers expires. Note that the MaxWait
timer is not restarted by new backup requests after it is started. For both
MinWait and MaxWait, the action to take when they expire can be defined. The
possible actions are:
None: Do nothing.
A start interval can be specified in hours indicating when a new job may start
after it is first created and ready to start. A random start time within an interval
may prevent bottleneck problems at the FTP server. If set to zero, the job
must start as soon as it is activated.
Start the backup job by setting the status to active(1). If the status after the
backup has been done has the value backupSuccess(4), the backup was done
successfully. When the status of the backup job has been read, the backup job
can be deleted by setting the status to destroy(6).
During a restore, the EMP will be restarted, so that the operator needs to
reconnect to the ECN. A restore must be defined as a manual job that will start
immediately after it is defined, and only run once. It cannot be scheduled. The
restore process will restore the configuration files saved in the backup file. The
restore will only succeed if the following conditions are fulfilled:
The hardware configuration must be the same as when the backup was
made (that is the same type of embedded elements must be connected).
The EMP must be configured with the same external and internal
management IP-Address and VLAN and the same uplink and downlink
ports must be used.
As for the backup procedure an FTP server must be created first, as described
in Section 9.2.1 on page 70.
If the FTP server is not specified, the restore job will look for the backup file in
the local directory: /var/backuptmp/on the ECN.
A status parameter for the restore job indicates whether the job is running or
completed. The status will be in the state of completed when the restore job
has finished. The restore job will fetch the specified backup file, and the result
is kept until the restore job is deleted.
The configuration is done using profiles, which can be created and edited in
the LCT. A profile is a collection of configuration parameters. It has a name
and an index, and by assigning it to a line, the line is configured with the values
defined in the profile. The ECN can contain multiple profiles for the same profile
type. It is possible to create new profiles and edit existing profiles. A profile
cannot be edited while in use (assigned to a line).
When the ECN boots for the first time, it will automatically generate the
following default profile files:
As illustrated in Figure 42 on page 78, there can be several profile files of each
type. Each of these files has an index number. If a line is not configured with a
specific profile, then according to the node type, the following profiles are used:
EDN612 Line profile 1 (VDSL line profile), VDSL PSD profile 1, ADSL
PSD profile 1, Alarm profile 1
EDN312x Line profile 2 (ADSL line profile), ADSL PSD profile 1, Alarm
profile1
As mentioned before, the default configuration files are only loaded when
a node is first discovered by the ECN. If it is desired to load a new default
configuration file, the node must be disconnected and removed from the ECN
/var/cfgProfileStorage/alarmProfiles
/var/cfgProfileStorage/lineProfiles
/var/cfgProfileStorage/vdslPsdProfiles
1. Configure the ESN212 to the desired functionality using the ESN212 CLI
(please refer to the ESN212 and ESN204g CLI User Guide).
2. Backup the running configuration using the ESN212 CLI: esn212# write
startup-config.
convention:
For example:
1. Find the IP address of the ESN212 using the EMP CLI and locate the node
according to the Port No.:
esn212# restart
If the restore is made for a backup file created by the ECN use the file
name: 102.0_10.0.1.8_back.startup.conf (102.0_10.0.1.8 is the
node identification according to the file naming convention described in
this section). For example:
esn212# restart
Note that the ESN212 must be restarted after the restore in order to run
with the new configuration.
In both daisy chain topology and star topology, the ESN410 must be defined as
a switch-extension in the EMP using the EMP CLI interface.
When the first extension switch is added, using the add esn410-uplink
command, the VLAN configuration of the specified uplink port on the ECN330
switch will be changed in order to allow traffic on both the internal and external
management VLAN, instead of the external management VLAN only.
Note: All configuration of the EMP unmanaged aggregation switch (the star
center) must be done manually.
9.5.2.1 Management VLAN Configuration for the First ESN410 Extension Switch
This configuration must be done using CLI. Connect to the first ESN410 switch
using a console connection. The following sequence of commands must be
entered to change the VLAN settings for the ESN410 extension switch:
Console# conf
Console(config)#vlan database
Console(config-vlan)# exit
Console(config-if)# exit
Console(config-if)# exit
Console(config-if)# exit
The IP address assigned to the ESN410 must be within the range 10.0.0.1 to
10.0.0.254. In the example, the IP address 10.0.0.37 is used.
Console# configure
Console(config)# exit
The following command is used to copy the configuration to the start up file,
to be used at restart of the switch. This will end the configuration of the
ESN410 switch. When the command is executed accept the default name:
esn410configuration.cfg.
Console# copy running-config startup-config
For the first ESN410 extension switch use the following command example:
(25 refers to the port that the first extension switch is connected to on the
ECN330, while 10.0.0.37 is the IP address of the first ESN410 extension
switch.)
For the second to seventh ESN410 extension switch use the following
command example (changing the IP address as required):
(11 refers to the port that the extension switch is connected to on the previous
extension switch.)
Finally, to prevent service traffic between the daisy chained ESN410s, use
the following command:
In the ESN410 aggregation switch, the port connected to the ECN330 must
have both the external and internal management VLANs configured, but no
Service VLANs should be configured on this port.
For each ESN410 switch, the internal management VLAN and Service VLANs
must be configured on the uplink port used to connect to the aggregation
ESN410 switch.
In the ESN410 extension switches, the internal management VLAN (on all
ports), IP address, internal management VLAN, SNMP alarm receiver, alarm
type, and NTP server configuration has to be done manually. The ECN will
configure all the service VLANs automatically.
The uplink ports on the ESN410 extension switches must allow VLAN 247
and VLAN 248. VLAN 246 must be removed from all switch ports. This
configuration must be done using CLI. Connect to each the switch using a
console connection. The following sequence of commands must be entered to
change the VLAN settings:
Console# conf
Console(config-vlan)#exit
Console(config-if)# exit
The IP address assigned to the ESN410 switch must be within the range of
10.0.0.1 to 10.0.0.254. In the example, the IP address 10.0.0.37 is used
Console# configure
Console(config-if)# exit.
The following command is used to copy the configuration to the start up file
to be used at restart of the switch. This will end the configuration of the
ESN410 switch. When the command is executed accept the default name:
esn410configuration.cfg.
Each extension ESN410 switch must be configured in the ECN330 using the
switch-extension command.
For the first ESN410 extension switch use the following command example:
(25 refers to the port that the first extension switch is connected to on the
ECN330, while 10.0.0.37 is the IP address of the first ESN410 extension
switch.)
Note: In star topology, the first extension switch refers to the switch
connected first chronologically, in other words, at a time before the
connection of the other extension switches. (Unlike for daisy-chain
topology, in star topology, there is no physical configuration limitation
on which extension switch is first.) The other extension switches are
also registered in the time order in which they are connected.
For the second to seventh ESN410 extension switches use the following
command example (changing the IP address as required):
The Linux Core system is the operating system for the Ethernet Node Controller
in ECN. The Linux distribution for ECN is based on standard open source
packages widely used in the Linux community.
These programs are free software; you can redistribute them and/or modify
them under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 2 of the License, or (at your option)
any later version.
See the GNU General Public License in the Third Party License Agreement
for more details.
The EMP application contains standard open source packages from Jakarta
Commons Net.
The programs are distributed in the hope that they will be useful, but WITHOUT
ANY WARRANTY.
The EMP application contains open source code from Enterprise Edt, called
edtFTPj. This is available for distribution under an LGPL license and should
not be modified.
ftp-hotel.Ericsson.net
Login: eda-gpl
Password: q5prst