Ericsson EFN324 User Manual
EFN324 User Guide
EDA 1200
Copyright
Copyright Ericsson AB 2008-2009. All rights reserved.
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.
Trademark List
Windows
®
Windows is a registered trademark of Microsoft
Corporation.
Apache
™
Apache is a trademark of The Apache Software
Foundation.
Extreme Networks
®
Extreme Networks is a registered trademark of
Extreme Networks, Inc.
Linux
®
Linux is a registered trademark of Linus Torvalds.
Wind River
®
Wind River is a registered trademark of Wind River
Systems, Inc.
vMAN
™
vMAN is a trademark of Extreme Networks, Inc.
All trademarks are properties of their respective owners.
Legal Notice
The EFN324 software is built using Open Source Licensed software. Refer to
the Third Party License Agreements document for copies of the licenses.
Contents
1
1 Introduction.................................................................................................1
2 Introduction to the EFN324.........................................................................5
3 Front Panel Description..............................................................................6
4 Basic Concepts...........................................................................................8
5 Switching Functions.................................................................................27
6 Topologies.................................................................................................48
7 Configuring Connections.........................................................................54
8 Security Functions....................................................................................60
9 Network Functions....................................................................................72
10 System Functions....................................................................................77
11 Maintenance.............................................................................................81
12 EFN324 Alarms........................................................................................84
13 Command Line Interface.........................................................................93
14 Software Components under Open Source Licences.........................166
Error! No text of specified style in document.
Glossary 168
Index 170
Glossary
1 Introduction
This guide describes how to use the EFN324. It describes its functions,
Command Line Interface (CLI) and use in EDA. This guide is intended for
operation and maintenance personnel.
Some of the EFN324 functions are described in the EDA 1200 System Description.
Reading the System Description before reading this guide is recommended.
Important!
When used with PEM or ServiceOn PEM, most of the EFN324 functions
(including VLANs) are configured automatically by the management
system. Any duplicate configurations created using the Command Line
Interface (CLI) commands described in this manual will be overwritten by
the management system.
Throughout this guide, the EFN324 is also referred to as the EFN and an
Ethernet access switch. These terms are interchangeable.
The guide can be printed on a monochrome printer, but the pictures and
illustrations may be more difficult to understand.
1.1 Revision History
This guide is valid for the EFN324 software released in EDA 4.3. This guide is
also valid for ELN220 running the same software. Other product version with
functions not described in this guide may be available.
1.1.1 This Version (S)
Other than editorial changes, this document has been revised as follows:
Flows section (section 4.11 on page 22) updated with better explanations.
A note added in Table 16 for the statistics command.
1.1.2 Version N
Other than editorial changes, this document has been revised as follows:
IndexIndex
Section 13.8.20 (SNMP) has been updated with SNMPv3 support.
Section 13.8.17, Section 13.9.10 and section 13.9.2 have been updated
with SFTP and FTPS support.
Section 13.8.12 has been updated with dynamic VLAN management
support.
1.1.3 Version M
Other than editorial changes, this document has been revised as follows:
Reference in section 4.10.1 on page 21 corrected
1.1.4 Version L
Other than editorial changes, this document has been revised as follows:
Section 4.8 on page 13 (Virtual LAN and VLAN tag) has been updated
The illustrations and descriptions in section 5.5 on page 39 updated to
make them easier to understand
Connection Bandwidth limitation description added in section 4.10.1 on
page 21
Connect VLAN command corrected (second_ethertype, second_tags) in
section 13.8.6 on page 114
1.1.5 Version K
Other than editorial changes, this document has been revised as follows:
The maximum number of daisy chained stand-alone EFN324 has been
corrected to two (2) in section 9.1 on page 72 and Figure 29 on page 73.
1.1.6 Revision J
The guide is based on the EFN324 User Guide 1553-CXP 901 0022 Uen H.
Other than editorial changes, this document has been revised as follows:
Changes made to the document structure.
Glossary
EFN324 as an embedded flexible block added. A number of changes
flowed from this, including the following:
Additional CLI commands, and extensions to existing CLI commands.
A virtual MAC description for an embedded node.
Additional topology description.
Replacement of an EFN324 added in section 11.2 on page 82.
Quality of Service for EFN324 added.
Further DHCP Option 82 options added.
PPPoE added.
Configurable first Ethertype added.
The default snmp write_community has been changed, from private
to public. See section 13.8.20 on page 137.
Descriptions of the debugging commands, including packet_logger and
trace_logger commands included, see section 13.10 on page 158.
1.2 Conventions
The following conventions apply to textual instructions (not screen shots):
Tools Options means: Choose the Tools menu item, then choose the
Options menu item.
Bold Courier letters mark field titles in a Graphical User Interface
(GUI), or text typed by the user (input) in files or the Command Line Interface
(CLI, such as Command prompt).
Regular Courier letters mark text output in a CLI.
OK : A button in a GUI.
<Server> is a parameter that should be replaced with the actual value. <>
symbols are not typed.
[argument] the brackets indicate that this argument is optional and can be
omitted. If the argument is used, the brackets must not be typed.
IndexIndex
{argument1|argument2} the brackets and pipe indicate that either
argument1 or argument 2 can be used as a value for this parameter.
Press CTRL+X means hold down the Ctrl key and press the x key.
Glossary
2 Introduction to the EFN324
The EFN324 is designed for use in a Public Ethernet environment. Public
Ethernet systems require enhanced functions and characteristics, such as
increased security and reliability, when compared to with traditional Ethernet
based LAN systems.
The EFN324 is used as an Ethernet access switch in an Ethernet based fiber
access system. The EFN324 aggregates physical fiber or electrical links
directly from the End-users. It then relays End-user traffic to and from
aggregation nodes on higher levels.
The EFN works primarily as an Access Node but it may also, when required,
interact with higher levels as a Layer 2 Ethernet switch. Such interventions are
broad ranging and include, for example, the following:
Snooping information from higher level as input for packet switching
decisions.
Changing header contents.
Discarding packets.
VLAN technology (IEEE 802.1Q) plays a central role in the EFN324. VLANs
are used for enhanced security and for distinguishing different services with
different requirements for transport characteristics, like delay and jitter,
availability and so on. EFN324 also supports double VLAN Tags.
EFN324 can be used as a stand-alone node, that is, a node not managed by
an ECN, but managed directly by PEM.
Alternatively, EFN324 can be used as an embedded node, that is, a node
managed by an ECN.
IndexIndex
3 Front Panel Description
The EFN324 front panel houses all connections and interfaces.
Power input
A and B
Console
(RS232)
FE
Port 1
FE
Port 24
FE
Port 23
FE
Port 2
Gb
Port 25GbPort 26
System
LEDs
Fan tray
cover
Gb ports LEDsFE ports LEDs
Figure 1 EFN324f Front Panel
The EFN324df and EFN324f have 24 FE optical interfaces and two combo
optical-electrical Gb ports. The EFN324c has 24 FE electrical interfaces and
two combo optical-electrical Gb ports.
Figure 2 EFN324c Front Panel
All EFN324 are power fed through one or two power inputs. A 9 pin D-SUB
connector (Serial console) is used for CLI management and initial
configuration.
Power input
A and B
Console
(RS232)
FE
Port 23
FE
Port 24
FE
Port 1
FE
Port 2
Gb
Port 25GbPort 26
11
1210
9
System
LEDs
Fan tray
cover
Glossary
Table 1 LED Indication
System LEDs Node Status
Green
Red
______
█████
Power-on: Initial LED state
During operation: major HW error
Green
Red
█████
______
Normal operation
Port LEDs Port Status (The Gb ports indicators are O or E,
indicating whether the optical or electrical port is
used)
Green
______
The port is unconnected
Green █████ The port is connected
Green █_█_█_ Traffic ongoing
Legend: █ or █ : LED is On _ : LED is Off
IndexIndex
4 Basic Concepts
The concepts described in this chapter are the starting-point for what an
operator sees, and needs to understand.
4.1 Physical View
The most important concepts are the following:
Ethernet port is the physical interface between an external physical
Ethernet link and the network processor.
Host port is the physical interface between the network processor and the
host processor.
Network processor handles receiving of incoming packets from and
sending of out-going packets to the Ethernet links. It handles most
switching decisions independently of the host processor.
Host processor (also called control processor) controls the Network
Processor. This includes assistance in program loading and restart,
executing of control commands and reception of counters. In exceptional
cases the host processor may be involved in switching decisions for
individual packets.
Figure 3 on page 9 illustrates the basic physical view of the EFN234, showing
the listed items.
Glossary
Figure 3 Basic Physical View of the EFN324
The network and host processors communicate physically through shared
memory. The communication may logically be divided into the following two
groups:
Management traffic to an external management site. This is traffic over IP.
In order for this traffic to flow, a connection through the switch between an
Ethernet port and the host port must be configured. The operator must
also configure an IP address for the host processor.
All other communication. From an operator’s point of view this traffic takes
place ‘under the surface’, since no special configuration or other
involvement from the operator is required for it to happen. Examples of this
type of traffic are control messages from host processor to network
processor, and packets forwarded from the network processor to the host
processor during the switching procedure, for example, IGMP messages.
It is also possible for an operator to directly communicate with the Ethernet
access switch from a terminal through a local COM port.
4.2 Management Interface
An operator communicates with the system through a management interface.
EFN324 offers both a CLI and a MIB interface. The latter may be used by
management systems like PEM. The MIB interface may also be used for
machine-machine communication with overlying management systems.
EFN324
Network processor -
switch
Host processor
. . .
Ethernet
links
Ethernet
Ports
Host
Port
Local
COM port
Memory
commonly
shared between
host and network
processors
IndexIndex
4.3 Stand-alone and Embedded Nodes
A stand-alone node in EDA 1200 is managed directly by PEM. It is
transparent to any ECN that may be present in the network.
An embedded node is managed by an ECN using SNMP. The EFN324 is
configured as a flexible block, with a Switch ID.
4.4 Ethernet Access Switch IP Address
The EFN324 IP address can be determined in either of the following ways:
configured as a static IP address, for stand-alone Ethernet access
switches, see section 4.4.1 on page 10.
fetched from the ECN using DHCP, for embedded Ethernet access
switches, see section 4.4.2 on page 10.
4.4.1 Static IP Address
If the EFN324 is a stand-alone node, its IP address is defined during initial
configuration. The initial configuration (using CLI commands) also defines the
network mask and default gateway IP address. See the EFN324 Installation Guide
for the commands used during initial configuration.
4.4.2 DHCP IP Address
If the EFN324 is an embedded node, it fetches its IP address from the ECN
using DHCP when it starts up after its initial configuration.
When the IP address is requested, the Ethernet access switch uses the
Management VLAN configured during installation. If a reply is not received,
four retries, using exponential timeout values, are sent. The process is
illustrated in Figure 4 on page 11. There is no support for using an unmanaged
VLAN.
DHCP options 43, 60 and 161 are used. Option 43 contains “<IP address of TFTP
server storing the configuration file>;<Configuration filename>;<IP address of trap receiver>”.
See Table 2 on page 11 for details of the strings used for options 60 and 161.
Glossary
Table 2 DHCP Values for Options 60 and 161
Option 60 Option 161
Value Ethernet access switch’s
hardware ID and Switch ID
Ethernet access switch’s
software version number
Examples “KDU137389/1,R1A;SID=42” “CXP 901 0022 R8B01”
Send tagged DHCP request
Use IP Address from DHCP
DHCP Response
received?
Yes
No
DHCP Response
Valid?
Yes
No
Timeout
Retrieve Management VLAN ID
from flash
Figure 4 DHCP Procedure
4.5 Resource
All the functions of the system are expressed, or modeled, in the CLI as
Resources. The MIB interface uses a similar model.
The Resource concept resembles objects in object-oriented programming.
Instead of ‘resource’, words like ‘resource object’, ‘resource instance’ or ‘object’
could be used. A Resource can also be referred to by only its name. For
example, instead of using ‘the autologout parameter in the CLI resource’, refer
to ‘autologout in CLI’.
Examples of resource objects in the EFN324 CLI include main_board,
ethernet_port and host_port. ethernet_port is an example of an
indexed resource type, in that there are multiple instances, separated using an
index:
ethernet_port 1
IndexIndex
ethernet_port 2
ethernet_port 3
…
ethernet_port 25
ethernet_port 26
4.6 Attribute
Each resource object contains data in the form of attributes. There are three
types of attributes:
Configuration attributes. These are also called parameters or
configuration parameters. Their values are determined and set by an
operator.
Status attributes. Their values are determined and set by the system itself.
Info attributes. Info parameters are set at the factory, during production,
and are not supposed to be changed during the system lifetime.
The values of all types of parameters may be read using ‘get’ commands.
Figure 5 on page 12 shows examples of different attributes of the main_board
resource object.
Figure 5 Example of Different Attribute Types of a Resource Object
4.7 Command
Interact with the system by directing commands to its resource objects.
main_board
Information:
# serial no = 1234
Status:
# temperature = 56
Configuration:
# temperature_limit = 80
Glossary
Parameter values (configuration attributes) may be read from the system using
get commands.
The configuration attributes values are set, modified or deleted using set, add,
remove, connect, disconnect and other commands.
There are also some system commands that do not relate to objects. For
example, exit.
4.8 Virtual LAN and VLAN tag
Virtual LAN (VLAN) is a technique used to logically separate several
independent networks that share a common physical infrastructure.
The IEEE 802.1Q standard describes how a 4-byte tag is inserted into
Ethernet packets, between the source address and the length or type field, to
specify the VLAN for the packet.
The 4 byte tag consists of the following:
A 2-byte Tag Protocol Identifier
A 2-byte Tag Control Information
The Tag Control Information consists of a 12-bit VLAN ID, a 3-bit priority field
and a 1-bit Canonical Format Indicator. The latter is only used for Token Ring
transmissions.
IndexIndex
Figure 6 IEEE 802.1Q tag
EFN324 supports zero, one and two VLAN tags as described above. Within
the CLI and in the MIB, the terms ‘tag’ and ‘second_tag’ are used for historical
reasons, but there is no direct mapping to the more common terms “Outer and
Inner VLAN tag”.
Pre-
amble
Dest.
address
Source
address
Type/
length
field
Frame
check
sequence
Data (0 – 1500 bytes)
and
Pad (46 – 0 bytes)
Original (”DIX type II”)
Ethernet frame; also called “untagged”:
Dest.
address
Source
address
Type/
length
field
Frame
check
sequence
Data
and
Pad
8 bytes 6 bytes 6 bytes 4 bytes 2 bytes 46 – 1500 bytes 4 bytes
802.1Q VLAN tagged
Ethernet frame:
Pream-
ble
802.1Q
VLAN
Tag
Tag
Protocol
Identifier
(0x8100)
User priority CFI VLAN ID
3 bits 1 bit 12 bits
Tag Control Information
2 bytes 2 bytes
8 bytes 6 bytes 6 bytes 2 bytes 46 – 1500 bytes 4 bytes
Glossary
Ethernet
Header
VLAN Data
Frame check
sequence (FCS)
Ethernet
Header
Outer
VLAN
Data
Frame check
sequence (FCS)
Inner
VLAN
tag
second_tag tag
CLI notation:
CLI notation:
Single tag frame
Double tag frame
Figure 7 Definition of tag and second_tag for EFN324
In the CLI, the VLAN ID is called tag, the ethertype is called
first_ethertype and the 3 bit priority field is called p_tag. Similarly, for
second tag the prefix <second_> is added.
As shown in Figure 7 on page 15, the EFN is inconsistent in relating the terms
Outer and Inner VLAN and the terms used in the CLI (tag, second_tag).
When one tag is present, tag denotes the Outer VLAN, but with two VLAN
tags, tag denotes the Inner VLAN.
The following figure illustrates the Ingress and Egress connections. Note that
to enable traffic in both directions, both the ingress and egress connections
must be configured for a switching domain.
EFN324
Egress
connection
Ingress
connection
Service VLAN
Switching
Domain
Ingress
connection
Egress
connection
Downstream
Upstream
Figure 8 Ingress and Egress Connections
On the ingress connection, the EFN324 will allow packets with the following
Tag Protocol Identifiers (Ethertype):
IndexIndex
Q-VLAN (0x8100)
S-VLAN (0x88a8)
Extreme Networks vMAN (0x9100)
S-VLAN (0x9200)
The values for these Tag Protocol Identifiers cannot be configured at the
ingress connection.
Only one of the Tag Protocol types may be used within the same service. The
VLAN ID (and optionally, the upstream destination IP address) of the incoming
frames defines the switching domain that the frame is forwarded to. If the
incoming frame has either an Ethertype that is not allowed or VLAN ID that is
not defined, the frame is discarded. If the frame is not discarded, VLAN
mapping and tagging takes place.
Table 3 on page 16 lists the possible ways to define the ingress configuration.
The outer VLAN ID is the only mandatory parameter.
Table 3 Ingress Connection Definitions
Outer VLAN ID
(tags for singletagged frames
second_tags for
double-tagged
frames)
Inner VLAN ID
(tags for
double-tagged
frames)
Destination
IP address
Single VLAN
tag frame
Specific value
Range
All (using *)
Untagged
None
Specific
address
IP network
Double VLAN
tag frame
Specific value Specific
value
Wild card
(using *)
Specific
address
IP network
Table 4 on page 18 lists the VLAN mapping possibilities in the EFN324. The
table lists the configurable parameters for the egress connection and what are
the results of each specific configuration. It is also possible to configure the pbit in exactly the same way as the Ethertype, just using a
Glossary
p-bit value instead of Ethertype. The way that the ingress connection is
configured must be taken into consideration when settings the egress
connection.
EFN324
Egress
connection
Ingress
connection
Service VLAN
Switching
Domain
Upstream
tags
tag
Figure 9 Ingress and Egress tag Configuration
For example if tags in the ingress connection is configured as untagged,
setting the tag in the egress connection to transparent will have no meaning
since there is no VLAN ID to copy.
The table shows four main scenarios that are depended on the incoming
format of the frame and the desired output:
1 Untagged traffic: use this to send untagged traffic from the EFN, with no
regards to the format of the incoming packets.
2 Single tagged frame in - Single tagged frame out: use this to send a single
tagged frame out where the sent VLAN can either be translated or copied
from the incoming frame.
3 Single tagged frame in – Double tagged frame out: Use this to send
double tagged frames out with a fixed outer VLAN and an Inner VLAN that
is either translated or copied from the VLAN tag of the incoming traffic.
4 Double tagged frame in – Double tagged frame out: Use this to send
double tagged frames out with an outer VLAN that is copied from the outer
VLAN of the incoming frame and an Inner VLAN that is either translated or
copied from the inner VLAN tag of the incoming traffic.
See also the explanation of terms after the table.
IndexIndex
Table 4 Configuration Possibilities for VLAN Mapping
Egress Connection Configuration Outgoing packet Sent
Type and Value
configuration for
second_tag
(Outer VLAN for
doubletagged)
Type and Value
configuration for tag
(Inner VLAN for doubletagged,
Outer VLAN for singletagged )
Outer VLAN Tag Inner VLAN Tag
VLAN ID Ethertype VLAN ID Ethertype VLAN ID Ethertype VLAN ID Ethertype
Not
applicable
Not
applicable
untagged
Not
applicable
None – untagged packet
Untagged Not applicable
tagged
<Idx>
<Ethertype>
<Idx>
<Ethertype>
None
transparent
<Idx>
Ethertype of
incoming outer
tag
transparent
<Ethertype>
VLAN ID of
incoming
outer tag
<Ethertype>
transparent
VLAN ID of
incoming
outer tag
Ethertype of
incoming outer
tag
tagged
<Idy>
<Ethertyp
e> or
transparent
tagged
<Idx>
<Ethertype>
<Idy>
<Ethertyp
e>
or Ethertype of
incoming outer
tag
<Idx>
<Ethertyp
e>
transparent
<Idy>
<Etherty
pe>
or Ethertype
of incoming
outer tag
<Idx>
Ethertype of
incoming outer
tag
transparent
<Ethertype>
<Idy>
<Etherty
pe> or
Ethertype of
incoming outer
tag
VLAN ID of
incoming
outer tag
<Ethertype>
transparent
<Idy>
<Etherty
pe> or
Ethertype of
incoming outer
tag
VLAN ID of
incoming
outer tag
Ethertype of
incoming outer
tag
transparent
<Ethertyp
e> or
transparent
tagged
<Idx>
<Ethertyp
e>
VLAN ID
of
incoming
outer tag
<Ethertyp
e> or
Ethertype of
incoming outer
tag
<Idx>
<Ethertyp
e>
transparent
VLAN ID of
incoming
outer tag
<Etherty
pe> or
Ethertype of
incoming outer
tag
<Idx>
Ethertype of
incoming inner
tag
transparent <Ethertype> VLAN ID of
incoming
outer tag
<Etherty
pe> or
Ethertype of
incoming outer
VLAN ID of
incoming
inner tag
<Etherty
pe>
Glossary
tag
transparent
VLAN ID of
incoming
outer tag
<Etherty
pe> or
Ethertype of
incoming outer
tag
VLAN ID of
incoming
inner tag
Ethertype of
incoming inner
tag
Note: If the incoming packet from the End-user is untagged and the egress
tag VLAN ID is set to transparent, then the outgoing packet is sent as
untagged, regardless of how the second_tag and the tag Ethertype
are configured.
Explanation of terms:
tagged <Idy>: VLAN ID for outer VLAN.
tagged <Idx>: VLAN ID for inner VLAN. Note that <Idx> is also used
when there is only one VLAN tag in the outgoing packet.
<Ethertype>: Ethertype. The following types can be specified:
q_vlan (0x8100)
s-vlan (0x88A8)
vman_vlan (0x9100)
s_vlan (0x9200)
Not applicable: This value must be specified in the CLI, but is ignored later
in the VLAN mapping.
Note that VLAN ID is called tag or second_tag and Ethertype is called
first_ethertype or second_ethertype in the CLI.
4.9 Switching Domain
In the EFN324 design the switching domain is a central resource. For
historical reasons, the switching domain is called ‘vlan’, with small letters, in
the CLI.
The switching domain is used by the operator as a connection point in the
switch for ports belonging to a particular VLAN. The switching domain is
IndexIndex
capable of performing much more sophisticated switching than an ordinary
learning-bridge switch.
In the descriptions in this guide, ‘switching domain’ is used, for the sake of
clarity, instead of the ‘vlan’ notation used in the CLI.
4.10 Connections
Ports, switching domains and connections are central concepts for switching in
the EFN324. A port is either an Ethernet port (called ethernet_port in the
CLI) or the Host port (called host_port in the CLI).
For a packet to travel through the switch, the following two connections must
be defined:
The ingress connection: the connection between the ingress port on
which the packet arrived and a switching domain.
The egress connection: the connection between the switching domain
and an egress port.
Figure 10 Ingress and Egress Connections
Even though the 26 Ethernet ports and 200 switching domain resources are,
by default, present from the start, connections must be defined (configured) by
the operator. A connection is created or deleted using the connect or disconnect
Incoming packet Outgoing packet
Ethernet
port x
Ethernet
port y
Egress
connection
Ingress
connection
EFN324
Switching
domain
Glossary
commands. Note that apart from the management VLAN, which is configured
during initial configuration, the connections are made automatically by the
Public Ethernet Manager (PEM).
4.10.1 Bandwidth Limitation
A bandwidth limitation may be imposed on each connection (ingress and
egress). It is implemented as a bandwidth profile (se set
bandwidth_limitation in section 13.8.8 on page 118), which is then
selected for a specific connection with the connect vlan command (see
section 13.8.6 on page 114. Up to 32 profiles can be used. Eight profiles are
created per default and can be modified.
When a bandwidth limitation profile is applied to a connection it will limit the
following traffic types:
Applied on an Ingress connection: unicast and broadcast packets
Applied on an Egress connection: unicast Multicast and broadcast packets
Unless VLAN per End-user is used, only the connections from the switching
domain to the downlink port should be configured with bandwidth limitation.
That is egress connection for the downstream and ingress for the upstream.
The reason is that these are the only connections that are connected to a
single End-user. The connection from the switching domain will transport
traffic from several End-users and there is therefore no meaning in applying
bandwidth limitation to that connection.
EFN324
Switching
domain
Ingress
Egress
Ingress
Egress
Ingress
Egress
BW
Ingress
Egress
BW
BW
BW
BW
BW
Uplink
Figure 11 Bandwidth Limitation for Multi-user Service VLAN
IndexIndex
4.11 Flows
Flows are used to distinguish the different levels of Quality of Service (QoS)
within a connection (see section 4.10 on page 20). A group of packets within a
connection can be given preferential treatment by classifying them into a flow.
Each flow is identified by either the p-bits or the DSCP values in the packet.
The flow determines the priority and reliability for the packets, along with the
bandwidth limitation or the policing to be applied on the flow. The priority
designates an output queue. The reliability indicates whether the packet
should be discarded if the EFN324 has insufficient empty buffers. The higher
the priority, the faster the packets are sent out. The higher the reliability, the
lower the probability of the packets getting discarded in overflow situations.
Flows within a connection to an uplink port handles traffic from all End-users
using the VLAN flow (see Figure 12 on page 23). This must be taken in
consideration when the connections and flows from the switching domain to
the uplink port are configured.
4.11.1 Flows in Connections
The EFN does not differentiate between uplink and downlink packet
processing. The flows must be configured correctly, accordingly to their
direction.
Glossary
Port
x
Port
z
EFN324
VLAN
1+2
VLAN
1+2
Port
Y
VLAN
2
Flow1
Ingress Connection
(Downstream traffic)
Flow1
Ingress Connection
(upstream traffic)
Flow1
Ingress Connection
(upstream traffic)
Connections
VLAN1Port z
Connections
VLAN2Port z
Connections
VLAN2Port x
Connections
VLAN2Port Y
Connections
VLAN1Port x
Network
Flow1
Flow2
Ingress Connection
(Downstream traffic)
Flow1
Flow2
Ingress Connection
(upstream traffic)
Switching
Domain
VLAN 2
Switching
Domain
VLAN 1
output stream toward
port Z
output stream toward
port Z
output stream toward
port Y
output stream toward
the port X
output stream toward
port X
Figure 12 Flow Directions
As illustrated, flows within the connections between the switching domain and
the uplink port (Port z), handles all traffic transferred from all End-users using
this specific VLAN. Any flow configured within a connection to an End-user
port for this VLAN, must also be configured in the uplink connection.
For downstream traffic (from the network to the End-users), the uplink ingress
flow configuration (reliability and priority) will apply to all End-users using this
flow.
4.11.2 Number of Flows
Four flows are globally available on the entire EFN324; to each flow can be
assigned a numerical value, 1 to 4.
IndexIndex
The flow selector parameter used in the configuration of the connect command
discriminate which flow description is applied.
Four cases are available:
Flow 1 – flow id values p-bits 0, 1 or dscp 0-15
Flow 2 – flow id values p-bits 2, 3 or dscp 16-31
Flow 3 – flow id values p-bits 4, 5 or dscp 32-47
Flow 4 – flow id values p-bits 6, 7 or dscp 48-63
Flow 1 is applied in case the flow selector in the connect vlan command is defined
as p-bits; in this case all frames belonging to the configured vlan and tagged
with p-bit 0 or 1 will experience the configuration defined for Flow 1. Flow 1 is
as well applied in case the flow selector in the connect vlan command is defined as
dscp; in this case all frames belonging to the configured vlan and tagged with
a dscp between 0 to 15 will experience the configuration defined for Flow 1.
When the flow selector in the connect vlan command is defined as p-bits; in this
case all frames belonging to the configured vlan and tagged with any p-bit 0-7
will go through the corresponding flows 1-4. There is no configuration possible
that can be specified to discard frames with certain p_bits. The parameter
flows in the connect vlan command does not have any significance in choosing
the flows but it is only used as a validation criteria for defining default flow. This
is because default flow in connect vlan command should be one of the flows
configured.
Same is the case with flow selector as dscp.
Example:
connect vlan 10 ethernet_port 10 ingress flow 1-2 flow_selector p-bits
default_flow 2
connect vlan 10 ethernet_port 10 ingress flow 1-3 flow_selector p-bits
default_flow 2
connect vlan 10 ethernet_port 10 ingress flow 1-4 flow_selector p-bits
default_flow 2
All the above commands do not have any significance for flows parameter. All
the above commands will result in the same behavior of the traffic handling.
connect vlan 10 ethernet_port 10 ingress flow 1-2 flow_selector p-bits
default_flow 4
Glossary
The above command will throw an error message. So the default_flow should
be one of the flows defined in connect command.
connect vlan 10 ethernet_port 10 ingress flow 1-5 flow_selector p-bits
default_flow 5
If default_flow is configured as >4 then behavior of the default_flow traffic is
unknown.
In case the flow selector is defined as none, all traffic belonging to that vlan will
experience the configuration of the connection flows.
4.11.3 Default Flow
One of the flows configured for the connection is the default flow. The default
flow accepts the packets that do not match the flow selection criteria.
When DSCP is the flow selection criteria on the connection, it is important to
configure a default flow. All the non-IP traffic is forwarded to the default flow,
since non-IP packets do not contain the DSCP field, for example, ARPs and
PPPoE packets.
When p-bit is the flow selection criteria on the connection, the default flow will
be used for untagged traffic.
All the other packets, which contain the configured flow selection criteria, are
forwarded to their corresponding flows.
4.12 IPsec
The EFN324 in R. 4.3, in-line with the EDA products, support the IPSec.
The IPSec can be enabled or disabled depending on the option 43 message
of the DHCP ACK message. The IPSec implementation is based on Wind
River Linux.
The IPsec feature on the EFN324 can be enabled or disabled without
restarting the node; the feature is active or inactive depending on the option 43
information of DHCP ACK.
In case IPSec is enabled, the RS232 connection is blocked.
In case the IPSec option is enabled, the software download might be
significantly slower, e.g. 40% slower then usual.
IndexIndex
4.12.1 Enabling of IPSec
IPSec is enabled after the reception of a DHCP ACK message from the DHCP
server with the option-43 contains the string “:01:EMPMAC”.
If the option-43 value contains the vendor-encapsulated-options from the
DHCP server and the IPSec flag set (first bit of the 4th parameter set), it
indicates IPSec is enabled in the network. E.g.,
"172.31.25.21:Configuration.cfg:172.31.64.50:01:EMPMAC”.
4.12.2 Monitor IPSec connection
Once the EFN is in IPSec Enabled state, periodic ping requests are sent
towards the EMP every 60 seconds (using ipseccontrol verify). If there is no
response from the EMP for three consecutive ping requests (180 seconds), the
IPSec connection is considered as failed and IPSecMonitorFailed event is
generated.
4.12.3 Fallback to restarting DHCP
IPSec negotiation can be restarted by doing a new DHCP discover this implies
that state will fallback to idle.
The fallback to idle is implemented by reusing the code that is executed when
a DHCP renew fails (basically stop and start DHCP).
As next DHCP offer may not set IPSec, then the key is deleted to protect it.
At no time a fallback to idle will cause interruption of the user traffic on the
nodes. Only management traffic may be interrupted.
The EFN324 is able to restart the DHCP sequence from DHCP Discover by
restarting the DHCP client. When the DHCP is restarted then the normal
procedure is followed depending on if “IPSec” string is present in the DHCP
option 43.
The CLI command “set cpu restart_dhcp start” can be used to restart the
DHCP client in EFN.
The CLI command “get cpu ipsec_status” will give the ipsec status in EFN.
Weather the IPSec is enabled or disabled in EFN.
Loading...