Professional Documents
Culture Documents
COGE1 Coge1 - r7b: User Manual
COGE1 Coge1 - r7b: User Manual
COGE1 coge1_r7b
MileGate
MileGate
COGE1 User Manual
Copyright and Confidentiality Copyright in this document vests in KEYMILE. This document contains confi-
dential information which is the property of KEYMILE. It must be held in con-
fidence by the recipient and may not be used for any purposes except those
specifically authorised by contract or otherwise in writing by KEYMILE. This
document may not be copied in whole or in part, or any of its contents dis-
closed by the recipient to any third party, without the prior written agreement
of KEYMILE.
Disclaimer KEYMILE has taken reasonable care in compiling this document, however
KEYMILE accepts no liability whatsoever for any error or omission in the
information contained herein and gives no other warranty or undertaking as
to its accuracy.
KEYMILE reserves the right to amend this document at any time without
prior notice.
Published by KEYMILE
http://www.keymile.com
User Manual
COGE1
Table of Contents
1 Preface 12
1.1 Precautions and safety 12
1.2 Associated MileGate documents 14
1.3 Technical support 15
1.4 Product training 16
1.5 About this document 17
1.6 Document history 18
1.7 Symbols and notations 19
1.7.1 Symbols in syntax descriptions 19
1.7.2 Use of tab names in the MCST GUI 20
2 Introduction 22
2.1 General 22
2.2 Definition of terms 22
2.3 Specification 23
2.3.1 Feature licences 23
2.3.2 COGE1 function overview 23
2.3.3 Versions 26
3 Architectural description 28
3.1 Block diagram 28
3.1.1 CPU 28
3.1.2 Switching 29
3.1.3 Synchronisation & redundancy control 29
3.1.4 GbE front interfaces 29
3.1.4.1 Management ports 29
3.1.4.2 VLAN trunk and subtending ports 29
3.1.4.3 Mirror ports 29
3.1.5 USB local management interface 30
3.1.6 Alarm block 30
3.1.7 Backplane access 30
3.1.8 Power 30
4 Installation 31
4.1 Prerequisites 31
4.2 Slots 32
4.3 Connections and cables 34
4.3.1 Front panel connections 34
4.3.2 SFP GbE optical modules cable 35
4.3.3 Electrical Ethernet interface cable (675.0461.00) 35
4.3.4 Synchronisation interface cable (675.0460.00) 37
4.3.5 USB management interface cable 37
4.3.6 Cable fixing 38
4.3.7 Cabling with COGE1 redundancy 38
5 Functional description 40
5.1 Applications 40
5.1.1 Hardware control 40
5.1.2 System management 40
5.1.3 Management traffic and network topologies 41
5.1.4 Switching 42
5.1.4.1 Switch characteristics 42
5.1.4.2 VLAN (802.1Q) 43
5.1.4.3 VLAN tagging 44
5.1.4.4 1:1 VLAN bridging mode 45
5.1.4.5 N:1 VLAN bridging mode 46
5.1.4.6 CoS, 802.1p 47
5.1.4.7 Multicasting (IGMP v2 and v3) 50
5.1.4.8 Packet buffer configuration for standard frames 51
5.1.4.9 Packet buffer configuration for jumbo frames 52
5.1.5 Link protection functions 53
5.1.5.1 RSTP, 802.1D-2004 53
5.1.5.2 MSTP, 802.1s (future release) 54
5.1.5.3 Link aggregation, 802.3ad 54
5.1.6 Security features 54
5.1.6.1 Access control list 55
5.1.6.2 Rapid MAC movement protection 55
5.2 Interfaces 57
5.2.1 Trunk ports 57
5.2.2 Management ports 58
5.2.2.1 USB 1.1 58
5.2.2.2 Ethernet 58
5.2.2.3 In-band management interface 59
5.2.3 Mirror ports 59
5.2.4 Service ports 59
5.4 Synchronisation 69
5.5 Unit Optical Indicators 70
5.5.1 COGE1 unit status indications 71
5.5.1.1 Booting 71
5.5.1.2 Waiting 71
5.5.1.3 Active 71
5.5.1.4 Failure 72
5.5.1.5 Standby 72
6 Commissioning 73
6.1 Introduction 73
6.1.1 Definitions 73
6.1.2 Management concept 73
Figures
Tables
1 Preface
Before you handle any unit of the type COGE1 you must comply with the fol-
lowing safety advices:
Please note the following safety precautions:
Training courses are available for a wide range of KEYMILE products and
applications.
For contact information, course descriptions, locations and dates, go to the
Website: http://www.keymile.com, then select “Services - Training” from the
menu.
The MileGate User Manual for COGE1 covers the aspects of the installation,
commissioning and operation of the COGE1 unit of MileGate. It handles also
the functional aspects and technical specification of the unit.
You find MileGate technical information and the description of the commis-
sioning procedures and operation as follows:
[201] System Description “MileGate R3B”.
The MileGate System Description describes the MileGate 2500, the
MileGate 2510, MileGate 2300 and the MileGate 2310, their features
and elements and the system architecture, and provides all the rele-
vant technical data and information for system planning.
[301] User Guide “MileGate 2500/2510 Installation”.
[310] User Guide “MileGate 2300/2310 Installation”
The Installation Guides cover the aspects of the MileGate equipment
installation.
[302] User Guide “MileGate 2500/2510”.
[317] User Guide “MileGate 2300/2310”
The MileGate User Guides describe the elements of the basic Mile-
Gate system (system control, software, alarms, synchronisation,
inventory function, etc.) and the principles of commissioning and oper-
ation of these subsystems.
[304] User Guide “MileGate & MCST”.
The User Guide “MileGate & MCST” provides all the information
required for the installation and commissioning of the MCST. It
describes the generic functions of MileGate and of the MCST GUI
(graphical user interface) and the CLI (command line interface).
User Guides for MileGate applications.
User Guides for MileGate applications are created and updated with
the implementation of new and/or enhanced functionality in the Mile-
Gate system. Application oriented User Guides provide dedicated
information on commissioning and operation of selected applications
and services provided with the MileGate (e.g. the user guide “Triple
Play Applications”).
Unit User Manuals (refer to the paragraph below) and the MileGate
User Guides together provide all information required for the basic unit
and system commissioning and operation.
User Manuals for MileGate units.
User Manuals are created for the individual MileGate control and ser-
vice units. The User Manuals provide information of the installation,
commissioning, and operation of the units in the MileGate system. The
User Manuals include also detailed unit specifications.
Service relevant unit parameters are not handled in the unit User Man-
uals but described in the application User Guides (refer to the para-
graph above).
Please note:
Shows a significant information.
The graphical user interface (GUI) in MCST uses tabs to present different
functional areas of the unit’s properties.
Please note:
The description of the path to access these tabs uses a syntax with man-
aged object names (see MOM description), management functions, and tabs
as follows:
/ managed object / child managed object, Management Function - Tab
Examples:
/ unit-9 / port-1, Configuration – Security
/ unit-9 / port-1 / interface-1, Configuration – Traceability
In the headings and CLI syntax statements, the unit numbers, port numbers,
and interface numbers are given with a variable name like “x”, “y”, “z”, or “u”.
Examples:
/ unit-x / port-y
/ unit-x / port-y / interface-z
2. With the context menu button of your pointing device, click on the
selected managed object.
- The context menu opens. Example:
3. Select the management function from the context menu by clicking on its
name.
2 Introduction
2.1 General
The COGE1 unit represents the core control unit for the multiservice access
nodes MileGate 2500, MileGate 2510, MileGate 2300 and MileGate 2310.
This unit combines the typical management functions of a core unit like
embedded software distribution, system alarming, performance monitoring,
etc., with an Ethernet switch including VLAN functionality.
The COGE1 unit provides several interface types in the front panel like SFP
cages for backhaul connectivity, electrical GbE as for subtending MileGate
systems or co-located Ethernet equipment, micro D-Sub 9 for synchronisa-
tion and USB 1.1 for management purposes.
All network elements MileGate 2500, MileGate 2510, MileGate 2300 and
MileGate 2310 permit full redundancy of the control unit and its traffic inter-
faces when operated in slot 11 by inserting and configuring a second control
unit in slot 13.
The details described in this document base on a specific COGE1 embed-
ded software (ESW) version. For more details about the ESW version
required for the described functionality, please refer to "[012] Release Note
“MileGate R3B”".
2.3 Specification
The COGE1 unit provides the following functions and supports the following
standards:
2.3.3 Versions
For detailed information about the released COGE1 hardware (HW) and
embedded software (ESW) versions supporting all the previously mentioned
features, please refer to "[012] Release Note “MileGate R3B”"
The figure below shows the COGE1 unit with its front panel and interfaces.
3 Architectural description
COGE1
Optical
Alarm indicator
(4 LEDs )
1
Local
Alarm USB
Management IF
CPU
Power 1
Synchronisation
& Redundancy Sync
Control
PBUS
20
GbE Backplane
Trunk IF, 5
1 Subtending IF, GbE
Switching
CBUS Management IF
Management
internal IF
3.1.1 CPU
The CPU functional block controls and monitors all the other functional
blocks of COGE1. The local CPU also processes external information arriv-
ing from other units or as external alarms.
3.1.2 Switching
This functional block is responsible for the switching between all Ethernet
traffic arriving at the unit, including management traffic that will be processed
by the CPU. It also supports VLAN, prioritization of traffic, RSTP, etc. as
described in section General (on page 22).
This block provides a PETS synchronisation system for the MileGate sys-
tem. The signal can be derived from different sources, e.g. external clock
source 2’048 kHz, internal oscillator, clock recovery from external interfaces,
etc.
It also provides a supervision of the redundant core unit that is plugged in
slot 13.
Any of the GbE front interfaces can be configured as mirror port. A mirror
port can mirror traffic from any of the other front ports, or from any of the
internal ports, or from the host processor port of the COGE1. The mode for
any of the mirrored ports can be ingress, egress, or both directions. For
more details, please refer to sections AP: / unit-x / port-a, Configuration –
Port Mode (on page 136) and AP: / unit-x / port-a, Configuration – Mirroring
(on page 154).
It provides the interface to the fault indications system (four LEDs) situated in
the front panel. It is also in charge of processing the 12 external alarms con-
nected to the backplane via the fan unit FANU4 and delivering to it the two
possible output alarms if necessary.
It provides the control signals access to the backplane allowing the manage-
ment of the units. It also grants access to the double Gigabit Ethernet star for
every unit. The backplane is formed by the following buses:
• C-BUS (for control signals),
• Double GbE star (for customer traffic), and
• PBUS (PDH bus for voice and other applications).
COGE1 provides the PBUS timing circuits and uses the ICN circuits for
the network element internal communication.
3.1.8 Power
COGE1 is directly powered from battery (-48 VDC or -60 VDC nominal). A
power block is available on the unit for the conversion of these voltages into
those needed by the unit HW (5V, 3.3V, etc.).
4 Installation
This section describes how to install the COGE1 core unit in a MileGate and
the connectors and cables that are required for installation.
4.1 Prerequisites
The required local manager (MCST) version to commission and operate the
MileGate system must be according to [012] Release Note “MileGate R3B”.
Along with this MCST version, an embedded software (ESW) according to
[012] Release Note “MileGate R3B” must be installed in the COGE1 unit.
4.2 Slots
For MileGate systems with only one COGE1 unit, this unit must be placed in
slot 11, as shown in Figure 3 for the MileGate 25x0, and in Figure 4 for the
MileGate 23x0.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
S S S S S S S S S S C S S S S S S S S S S
U U U U U U U U U U U U U U U U U U U U U
7 8 9 10 11 12 13 14
S S S S C S S S
U U U U U U U U
S S S S S S S S S S C S C S S S S S S S S
U U U U U U U U U U U U U U U U U U U U U
Figure 5: MileGate 25x0 with core unit COGE1 in slot 11 and redun-
dant core unit COGE1 in slot 13
7 8 9 10 11 12 13 14
S S S S C S C S
U U U U U U U U
Figure 6: MileGate 23x0 with core unit COGE1 in slot 11 and redun-
dant core unit COGE1 in slot 13
mini-USB connector:
Local management interface
port-5
port-3
port-2
SFP module cages: optical GbE interfaces
(usable as trunk, subtending or management interface )
port-1 Tx
Rx
Pull-out handle
Fixing screw
The 1000FX optical interfaces on COGE1 consist of two SFP (Small Form
factor Pluggable) cages.
The COGE1 unit only provides the mechanical infrastructure for such mod-
ules: This is a cage and a host board connector. COGE1 allows hot swap-
ping of SFP modules.
Please note:
SFP modules must be fully MSA (Multi-Source Agreement) compliant [INF-
8074]. Please note that only KEYMILE’s recommended SFP modules should
be used in order to guarantee inter-working with the COGE1 unit.
→ In order to get the latest list of KEYMILE’s recommended SFP mod-
ules please refer to the KEYMILE Extranet
(via http://www.keymile.com) → Documentation & Software → Mile-
Gate / MCST → Techn. Documentation → Bulletins.
Then go to Technical Bulletins, and open the “MileGate R2 supported
SFP transceivers” document once you have logged in.
The recommended SFP module types are:
• 1000BASE-SX (850 nm)
• 1000BASE-LX (1310 nm)
• 1000BASE-EX (1310 nm)
• 1000BASE-ZX (1550 nm)
The selection of the transceiver and the media type will determine the maxi-
mum distance allowed according to the transmission media specifications.
For details on connectors and pins for this interface, please refer to [INF-
8074].
SFP Modules plugged into the COGE1 operate by default in auto negotiation
mode.
Please note:
GbE optical interfaces only support 1000 Mbit/s Full Duplex fixed operation
mode.
SFP DDM (Digital Diagnostic & Monitoring) is supported on the SFP mod-
ules that are plugged in the SFP cages of the COGE1 unit provided that the
module itself is supporting this feature.
Please note:
For error free transmission, category 5e Ethernet cables are required at
least. This assumes that the equipment on the remote end also supports
transmission on category 5e cables. If this is not the case, we recommend
the use of category 6 cables.
Electrical 10BASE-T/100BASE-TX/1000BASE-T ports on COGE1 support
auto-negotiation with parallel detection.
Auto-Negotiation allows the highest performance mode to be automatically
selected on a given link.
Please note:
COGE1 Ethernet electrical interfaces are configured in auto negotiation
mode by default.
Please note:
With auto negotiation switched off, a crossed cable has to be used to con-
nect to another COGE1 since the interface cannot automatically select the
mode.
The following table shows the behaviour of COGE1 when connecting an
external Ethernet device:
Please note:
When using LACP, full duplex is mandatory.
Please note:
When connecting Ethernet ports configured in manual mode (no auto-negoti-
ation) to Ethernet ports in auto-negotiation mode, the link may be up but the
duplex settings may be inconsistent. This can result in poor throughput per-
formance on the link.
The previous note applies to any Ethernet device and is a consequence of
the behaviour of Auto-Negotiation and Parallel Detection. When a port sup-
porting auto-negotiation is connected to a port not supporting auto-negotia-
tion, the port supporting auto-negotiation will revert to parallel detection: This
can detect the link type (10BASE-T or 100BASE-TX) but will assume half-
duplex operation (reference IEEE 802.3 clause 28.2.3.1 note 2). If the far
side port is manually configured in full-duplex mode, then there is an incon-
Please note:
This cable can be ordered from KEYMILE.
For details on available Ethernet cables, please refer to "[506] User Manual
“MileGate cables”".
Please note:
This cable can be ordered from KEYMILE.
For details on available synchronisation cables, please refer to "[506] User
Manual “MileGate cables”".
Please note:
A USB cable length above 5 m may lead to an unstable connection or may
not allow a connection at all. It is hence not recommended to use USB
cables longer than 5 m for the connection to the COGE1 unit.
In the MileGate 25x0, cables connecting to the COGE1 unit or other units in
general should be guided and attached to the cable tray as indicated in the
following figure.
Figure 8: Side view of the subrack including cabling and cable tray
In the MileGate 23x0, cables connecting to the COGE1 unit or other units
should be guided and attached similarly to the way shown in Figure 8 above.
For more detailed information, please refer to "[310] User Guide “MileGate
2300/2310 Installation”".
When using a redundant core unit in slot 13, cabling is different. Since the
core unit HW is duplicated, some of the front connections have to be dupli-
cated as well. The cables that have to be connected twice are the following:
• USB cable to the USB local management interface
The USB cables to the two COGE1 units can be connected e.g. via a
USB hub to the local manager. Note that the two USB ports of the two
COGE1 units have different addresses on the local management PC.
• Synchronisation interface cable
The two cables need to be connected to an appropriate analogue switch
or multiplexer if a switch-over is required.
• Ethernet cables – for maximum protection against failures, also electrical
and optical cables from a switching or routing device to ports 1 to 5 of the
COGE1 unit need to be connected to both units, the working and the
standby COGE1. In this case, RSTP might be required. Please read the
important note on RSTP configuration in section Equipment protection
EQP (core unit redundancy) (on page 65).
5 Functional description
This section provides a functional description of the COGE1 core unit and its
interfaces. For a description of configuration parameters, refer to section
Commissioning (on page 73).
5.1 Applications
The COGE1 core unit controls the configuration and operation of the Mile-
Gate system, maintains an updated database with relevant information for
each configured unit and it performs switching between every traffic unit,
backhaul and subtending interfaces. It also provides redundancy through 1:1
equipment protection when two core units are plugged and configured. The
following sections cover these aspects in more detail.
One of the main functions of the COGE1 unit is to control the peripheral units
at hardware level. This comprises the following functions:
• Check the presence of peripheral units
• Supervise the core unit redundancy status
• Activate/deactivate the units
• Reset the units
• Read the unit alarm status
• Read the unit inventory data
• Provide clock information
• Control signals to the redundant COGE1
Please note:
For the configuration of the management VLAN ID, refer to "[304] User
Guide “MileGate & MCST”".
Please note:
Care must be taken that the VLAN ID assignment follows a proper strategy.
When trying to re-configure the management VLAN ID, a warning is issued
by the management system.
In case of direct connection from a management system (UNEM or MCST)
to a MileGate using untagged traffic, the port must be configured as a ‘Man-
agement Port’ and will be accepting untagged traffic only. Once the manage-
ment traffic from the management system has reached the port, it will be
tagged with the management VLAN ID that is currently configured (for details
see sections AP: / unit-x / port-a, Configuration – Port Mode (on page 136)
and AP: / unit-x / port-a, Configuration – VLAN list (on page 142), and [304]
User Guide “MileGate & MCST”).
The third scenario is the case where there are subtending MileGate nodes.
In this case, ports connecting to and from the head end must be configured
as ‘VLAN trunk’ interfaces.
Please note:
COGE1 is a switch and not a routing gateway. Therefore it is not able to con-
vey routing information to hosts.
→ The COGE1 management IP address must not be configured as
default gateway in a connected host.
Please note:
For further information on the management connection to the MileGate,
please refer to [302] User Guide “MileGate 2500/2510”, [317] User Guide
“MileGate 2300/2310”, and [304] User Guide “MileGate & MCST”.
5.1.4 Switching
The main traffic function of the MileGate system is switching customer’s traf-
fic towards the network and vice versa. This function is performed in the
COGE1 unit that implements a switch based on IEEE 802.1D with VLAN
support according to IEEE 802.1Q and IEEE 802.1ad.
This switch has five external Ethernet interfaces; three electrical GbE and
two SFP modules for optical or electrical GbE as described in the next sec-
tion. Moreover, it has 20 internal ports in the backplane of 1Gbit/s each
granting access to every other unit in the subrack, and it has one internal
port of 100 Mbit/s to the CPU.
COGE1 permits switching traffic at wire speed between all its ports.
Please note:
Under heavy load situations from the tributary side and when using the same
VLAN priority (CoS) for all or many traffic streams, congestion might occur in
upstream direction due to the limited packet buffer resources in the switching
circuit.
Please note:
Management traffic coming from the CPU and coming from a management
port is tagged with a VLAN priority CoS4.
→ To avoid collisions of tagged management traffic with user traffic it is
recommended to use other VLAN priorities for the user traffic.
The following table summarises the main features of the COGE1 switch.
Virtual LANs (VLANs) enable the interconnection of LAN segments that are
far apart, extending their reach. When the transport between VLAN seg-
ments is done over optical networks, the distance between segments is virtu-
ally unlimited.
Besides the ability to interconnect separated LAN segments, VLANs provide
an enhanced level of security compared to shared media LANs where traffic
can be seen by any other end station.
VLAN segments are connected to VLAN-aware switches, and upon configu-
ration (frame filtering, ingress rules, and filtering), they will forward frames
accordingly.
In general, in switched networks, the performance of the network is improved
by splitting collision domains. In this way, other end stations can still commu-
nicate because collisions are not passed to other segments of the network.
The links interconnecting VLAN segments are defined as:
• ‘Access’ links if they carry either:
− untagged frames or
− priority tagged frames (VLAN ID=0)
• ’Trunk’ links if they carry:
− tagged frames only
Ethernet front interfaces in COGE1 can be associated with trunk links, there-
fore all traffic expected in these interfaces should be VLAN tagged. Ingress
filtering is not enabled, hence all VLAN IDs are accepted, i.e. these ports are
transparent for all VLAN IDs.
When using the port VLAN feature of the COGE1 unit incoming untagged
traffic is assigned the port VLAN ID. Outgoing traffic with the port VLAN ID
gets the VLAN tag removed.
On subscriber interfaces like e.g. SUAD1 ADSL2+ interfaces, untagged or
priority tagged frames are assumed since these interfaces correspond to
access links.
COGE1 supports VLAN tagging and VLAN tag stacking as proposed both in
IEEE 802.1Q and in IEEE 802.1ad.
VLAN tag stacking allows customer’s VLAN tags (C-VID) to be forwarded
through the operator’s network. This way, the internal virtual network struc-
ture is kept and priority information can be sent over.
Tag stacking adds a second VLAN tag (S-VID) as a tagged frame arrives to
the operator’s network from the customer. When arriving to the remote LAN
segment of the customer’s network, the second VLAN tagged is removed
again.
Customer Service Provider Customer
VLAN West LAN/VLAN VLAN East
S-Tag C-Tag
add / remove tag
VLAN tag stacking is also used to overcome the limitation of 4096 VLAN IDs
with single VLAN tagging.
According to IEEE 802.1ad terminology, the outer or only tag is called S-tag
(Service tag) and the inner tag, used in case of tag stacking, is called C-tag
(Customer tag).
The resulting frames after applying tag stacking can be bigger than 1522
bytes and are called jumbo frames. Jumbo frames are supported by the
COGE1 switch up to a maximum packet length of 10’000 octets.
The bridging mode (802.1Q, or 802.1ad) can be configured in the MileGate
on network element level. Note that the mode selection should be done care-
fully since the two modes are not compatible.
With service units as e.g. SUAD1, two VLAN configuration modes are availa-
ble:
• 1:1 VLAN bridging
• N:1 VLAN bridging
With the 1:1 VLAN bridging mode, a unique VLAN ID is assigned to each
service of each subscriber in the service unit. This allows the isolation of the
traffic from different subscribers and the control of the connectivity between
the subscriber and the service provider.
The main disadvantage of this single tagging method is the poor scalability
due to the range of VLAN IDs being limited to 4089.
However, the scalability problem can be overcome by using 1:1 double
VLAN tagging. In that case both, the C-tag and the S-tag are assigned in the
service unit, e.g. SUAD1. The COGE1 only supervises the VLAN tags.
Please note:
An S-tag can be assigned to 1:1 double tagged services from different ser-
vice units.
The following figure illustrates this concept.
5/39 37 500
500
ATM VCC
Figure 10: 1:1 VLAN cross connect mode with double tagging
1:1 VLAN cross connect mode with double tagging is the typical VLAN mode
used with the Broadband Internet Access service based on PPPoE encapsu-
lation.
With the N:1 VLAN bridging mode, a service delivered to several subscribers
is assigned to a single VLAN, as shown in the following figure.
ATM VCC
Note *: PPPoE and IPoE via one ATM VCC, mapping to two VLANs based on the Ethertype value
Note **: three VLANs based on one DSL or Ethernet port
Figure 11: N:1 VLAN bridging, single tagging, with COGE1 and service
units
This mode is typically used with single tagging only (tag assigned in the traf-
fic unit, e.g. SUAD1). In downstream direction, the identification of the sub-
scriber is achieved with its MAC address.
Security and filter mechanisms are implemented in MileGate to parry attacks
like source MAC flooding or source MAC spoofing etc.
N:1 VLAN cross connect with single tagging is the typical VLAN mode used
with connections to IP edge routers, TV servers and Voice Gateways, based
on IPoE encapsulation.
Please note:
Mixed VLAN modes (N:1-single tagging / 1:1-single tagging and N:1-single
tagging / 1:1-double tagging) are supported in the same unit.
priority to
queue Ethernet 0
mapping Switch Eth.
GbE priority to port
backplane 7 queue
mapping
The default mapping of the user priority levels to the 8 traffic classes
(queues) is shown in Table 15.
Note that the queue 7 is reserved by default for the MileGate internal man-
agement communication and is therefore not used for service traffic. This
avoids that the internal management communication could be disturbed by
the service traffic or external management traffic. Nevertheless the default
mapping can be modified in the MileGate according to the operator’s prefer-
ences.
With the standard queue mode enabled (default) the priority to queue map-
ping is modified so that the queue 7 is reserved for the internal management
traffic. The user packets are mapped to the next lower queue. Packets that
are mapped to queue 0 and queue 1 according to the configuration will all be
mapped to queue 0. For an example refer to Table 16.
Table 16: Traffic to priority mapping with and without standard queue
mode
Priority to queue mapping Effective packet priority mapping,
configuration (example) Standard Queue Mode
Queue Priority disabled or enabled
queue 7 priority 7 priority 7 internal management
queue 6 priority 6 priority 6 priority 7
queue 5 priority 5 priority 5 priority 6
queue 4 priority 4 priority 4 priority 5
queue 3 priority 3 priority 3 priority 4
queue 2 priority 0 priority 0 priority 3
queue 1 priority 2 priority 2 priority 0
queue 0 priority 1 priority 1 priority 1 and priority 2
With the standard queue mode enabled (default) the packet scheduling is
modified so that the queue 7, which is reserved for the internal management
traffic, will have strict scheduling. The lower queues inherit the scheduling
type of the next higher queue, the configured scheduling type of the queue 0
is discarded. The weight of the remaining weighted queues is adapted pro-
portionally so that the total weight remains at 100%. For an example refer to
Table 17.
Table 17: Packet scheduling with and without standard queue mode
Packet scheduling profile configura- Effective Scheduling,
tion (example) Standard Queue Mode
Queue Scheduling Weight disabled or enabled
queue 7 Strict - Strict Strict
queue 6 Weighted 4 Weighted 40% Strict
queue 5 Strict - Strict Weighted 44.4%
queue 4 Weighted 3 Weighted 30% Strict
queue 3 Strict - Strict Weighted 33.3%
queue 2 Weighted 2 Weighted 20% Strict
queue 1 Strict - Strict Weighted 22.2%
queue 0 Weighted 1 Weighted 10% Strict
IGMP
Initiates IGMP oper- monitors IGMP packets, and sends Processing of IGMP oper -
ations to receive or IGMP reports to the IGMP router, ations, i.e. IGMP requests from
stop receiving multi- hosts are terminated in the
cast flows builds multicast forwarding tables IGMP Router
accordingly ,
e .g. join a multicast IGMP Router requests for the
group to receive its distributes multicast flows (content traffic) appropriate video stream from
multicast stream, or to all members of a group according to the video server
leave a group to stop multicast forwarding tables. (with PIM / SSM) .
its multicast stream
With the proxy reporting functionality, reports and queries are intercepted
and processed in COGE1 in order to reduce the signalling traffic to the IGMP
router.
The MileGate supports also static multicast. Static multicast can forward
specific multicast streams directly to member ports without any interaction
required from the subscriber or from a network server.
For more details, please refer to "[303] User Guide “Triple Play Applica-
tions”".
The packet buffer sizes for all switch ports on the COGE1 unit can be config-
ured. The configuration is done with a profile.
The total available buffer memory of 1’048’576 bytes is distributed to
• the incoming traffic for all ports and priorities per unit,
• the outgoing traffic, per port and per priority.
Queue0 Queue0 Queue0
Queue1 Queue1 Queue1
Outgoing and port-1 port-2 ... slot-1 ... slot-21 cpu incoming buffer size
incoming buffer
sizes per unit Total available buffer
The packet buffer profile allows an operator to configure the buffer sizes of
all outgoing switch ports, i.e.
• the 5 front ports (port-1 to port-5),
• the 20 ports to the service units (slot-1 to slot-10, slot-11/slot-13, slot-12,
slot-14 to slot-21), and
• the processor port (cpu).
On each port the buffer size for each priority (queue) can be given, together
with a maximum buffer size. If the sum of the priority buffer sizes is smaller
than the maximum buffer size, the difference buffer memory is used for any
priority.
The buffer size for all incoming switch ports is the total available buffer
size minus the sum of all outgoing port maximum buffer sizes.
When configuring the packet buffer profile some rules must be observed:
• All buffer sizes must be multiples of 64 bytes.
• On each port the sum of the priority buffer sizes must be equal or smaller
than the maximum buffer size.
• The incoming buffer size must be at least 79’664 bytes, i.e. the sum of all
maximum buffer sizes of the outgoing ports must be equal or smaller than
968’912 bytes.
• The maximum buffer size of the cpu port should be at least 30’720 bytes
to be able to handle all management traffic.
Please note:
There is no check of the above rules when a packet buffer profile is created,
but a profile with invalid settings will be rejected when applying it in the unit
configuration (AP: /unit-x, Configuration - Packet Buffer).
The default packet buffer profiles assigns the packet buffer sizes as follows:
• port-1 to port-5:
− Queue7 to Queue0: 4*1’536 = 6’144 Bytes,
− Maximum buffer size: 49’152 Bytes.
• slot-1 to slot-21, slot-11/slot-13:
− Queue7 to Queue3: 3*1’536 = 4’608 Bytes,
− Queue2 to Queue0: 2*1’536 = 3’072 Bytes,
− Maximum buffer size: 32’256 Bytes.
• cpu:
− Queue7: 7’808 Bytes,
− Queue6 to Queue0: 0 Bytes,
− Maximum buffer size: 59’136 Bytes,
− Buffer for any CoS: 51’328 Bytes.
• Total packet buffer for outgoing traffic:
− Sum of all port, slot and cpu maximum buffer sizes =
5*49’152 + 20*32’256 + 59’136 = 950’016 Bytes.
• Total packet buffer for incoming traffic:
− 1’048’576 - 950’016 = 98’560 Bytes.
Jumbo frames with a packet size up to 10’000 octets are supported by the
MileGate on specific ports:
• Between 2 COGE1 front ports, or
• Between 1 COGE1 front port and up to 2 Ethernet ports on a service unit,
or
• Between 1 COGE1 front port and 1 Ethernet ports on two service units
and between 2 COGE1 front ports.
Please note:
RSTP is applied per COGE1 port or link aggregation group, and not per
VLAN.
Multiple Spanning Tree Protocol (MSTP), according to IEEE 802.1s will allow
having multiple active spanning tree topologies on one physical network.
COGE1 together with service units offers security features (according to DSL
Forum TR-101) to protect the NE from attacks of a malicious user.
These security features are appropriate for N:1 VLAN mode, but several also
apply to 1:1 VLAN mode, and some of the security features that are applica-
ble for residential users may not be applicable to some business customer
configurations.
Within the MileGate we can differentiate two types of access control func-
tions:
• MAC access control list for N:1 single tagged VLAN services:
At system level, it is possible to set up a black list with MAC addresses of
devices not allowed to access the network. Their messages will be
blocked before reaching the BRAS. This is a system feature performed
by COGE1 in cooperation with a service unit (e.g. SUAD1).
• White and black lists of VLANs per Ethernet port:
COGE1 allows defining whitelists or blacklists of VLANs per Ethernet
port, allowing the operator to set up a number of VLANs which will not be
allowed (blacklist), or to set up the list with the only VLANs permitted
(whitelist). This feature is not available on management ports. Also refer
to section AP: / unit-x / port-a, Configuration – VLAN list (on page 142).
For more details, please refer to "[302] User Guide “MileGate 2500/2510”",
or refer to "[317] User Guide “MileGate 2300/2310”".
Please note:
Other security features like protection from source MAC spoofing or from L2
peer-to-peer forwarding are implemented in the service units, e.g. SUAD1.
Rapid MAC movement is a risk that may occur because of a broadcast storm
or if a malicious subscriber tries to hijack a MAC address from a running ses-
sion of another subscriber.
The MileGate supports a protection against rapid MAC movement. A learned
MAC address is valid on a port as long as an aging timer of 5 minutes has
not expired. This MAC address is prohibited to access another port on the
MileGate. The MAC address can be learned on another MileGate port only
after the expiry of the aging timer.
The rapid MAC movement protection is a network element feature:
• GUI: AP: ne, Configuration – Packet, MAC Movement Protection =
• CLI: set /cfgm/MACMovement true
Please note:
On a COGE1 port with RSTP enabled the MAC addresses are only learned
if the port is active. The MAC address table on an inactive port is cleared.
→ Port switching within a spanning tree is possible also when MAC
movement protection is enabled.
Please note:
A COGE1 port which is member of a link aggregation group (LAG) the MAC
addresses are only learned with the port number of the leading port of the
LAG.
→ Traffic load distribution within a LAG is possible also when MAC
movement protection is enabled.
Please note:
When enabling the rapid MAC movement protection the actual MAC address
table on an inactive port is cleared.
→ Only MAC addresses newly learned after the enabling are protected
against rapid MAC movement.
For more details, please refer to "[303] User Guide “Triple Play Applica-
tions”".
Please note:
Note that the aging timer is reset also when a learned MAC address
accesses another COGE1 port than the port it has been learned. In this case
the learned MAC address will not be removed from the MAC address table
and the access to another COGE1 port will not be possible.
→ The traffic with a learned MAC address must be stopped on all
COGE1 ports for 5 minutes to automatically remove the corresponding
entry in the MAC address table. If required the MAC address table can
be cleared manually by one of the following procedures:
• Disable the rapid MAC movement protection feature and enable it again.
Note that this clears the MAC address tables on all units of the MileGate.
• Disable the port mode:
− set the administrative state of the port to “down”,
− configure the port mode to “Not Configured”,
− configure the port mode to “VLAN Trunk Port” or “Management Port”
again, and
− set the administrative state of the port to “up”.
Note that all traffic on this port will be interrupted.
5.2 Interfaces
When configured as VLAN trunk ports, these interfaces receive / deliver the
traffic from / towards the network. They concentrate the totality of customer
traffic.
Because of the wide range of available distances that can be covered with
optical interfaces, the SFP interfaces (ports 1 and 2) are considered as back-
haul interfaces.
These interfaces support 1000BASE-SX/-LX/-EX/-ZX according to their
respective standards.
COGE1 provides two SFP cages (port-1 and port-2) where different SFP
modules can be inserted to satisfy network needs. For details about SFP
modules, refer to section SFP GbE optical modules cable (on page 35).
The selection of the transceiver and the media type (single mode or multi
mode fibre) will determine the maximum distance allowed according to SFP
provider specifications.
For details on connectors and pins for this interface please refer to [INF-
8074].
The SFP modules provide duplex LC connectors.
Please note:
SFP modules are hot swappable. This means that you can plug or remove
the modules during operation of the unit. We strongly recommend however
to remove the fibre before plugging or unplugging an SFP module.
In principle, when configured as trunk port, any of the electrical or optical
Ethernet front ports can be used as subtending interface, i.e. a further Mile-
Gate can be connected to this port. However, electrical interfaces have a
limited reach compared with the optical interfaces and are therefore normally
used in subtending configurations.
The three electrical Ethernet interfaces (port-3, port-4, and port-5) support
10/100/1000BASE-T/TX according to IEEE 802.3 specifications. Any of the
interfaces can be used for management communications.
Every one of these three interfaces (ports 3 … 5) is implemented by means
of an RJ-45 connector with auto-negotiation. Fixed operation modes (half/full
duplex modes) are also available.
These interfaces support automatic cross over functionality allowing straight
or cross over cables to be connected.
They support frames bigger than 1522 bytes called jumbo frames, which can
be the result of double VLAN tag stacking. Maximum packet length sup-
ported is 10’000 octets (also refer to section AP: / unit-x / port-a, Status –
MAC (on page 159)).
The internal ports (GbE star) connecting the service units to the Ethernet
switch on the COGE1 unit can also be configured as VLAN trunk port. This
makes it possible to use e.g. an SDH port on an SDH unit as uplink port
towards the network.
Please note:
The internal backplane port to the redundant COGE1 unit has the fixed port
mode “VLAN Trunk Port”.
All of the five Ethernet front ports and the internal ports to the service units
support RSTP and LACP. For more details about RSTP on the Ethernet
ports, please refer to:
• section Commissioning RSTP (on page 80) for RSTP parameters,
• section AP: / unit-x / port-a, Configuration – RSTP (on page 140) for
RSTP configuration, and
• section AP: / unit-x / port-a, Status – RSTP (on page 161) for the RSTP
status.
There are two types of interfaces for management, one for local commission-
ing of the NE, and the other one for inband or out-of-band management
communications.
Please note:
The maximum recommended cable length for this connection is 5 m.
5.2.2.2 Ethernet
Any of the five Ethernet ports (optical, electrical) and the internal ports to the
service units can be configured as a management port.
In order to have a dedicated interface for management it has to be config-
ured as “Management Port” via the MCST GUI or via the CLI. This implies
that the port will only accept untagged frames. Accepted frames will then be
tagged with the VLAN ID for internal use (4089 by default or the configured
management VLAN ID; for details refer to "[304] User Guide “MileGate &
MCST”").
The VLAN ID for management can be configured in the range 1 … 4089. It is
not recommended to use the default VLAN ID 1 as the management VLAN
ID.
This interface will allow the user to access the MileGate system via its con-
figured IP address (192.168.0.1 by default) in the COGE1 unit.
Please note:
To reduce susceptibility of the management connection to broadcast storms,
the COGE1 controls layer 2 multicast and broadcast traffic by counting the
number of broadcast and/or multicast packets within a certain time period. If
a count limit is exceeded, the packets are discarded.
→ The control feature is fixed to a maximum of 16 packets in a 100 ms
time frame for the management VLAN ID.
Any of the five Ethernet front ports and the internal ports to the service units
can be configured to be a mirror port. In this case, frames from any of the
other front ports, or from any of the backplane GbE ports, or from the host
processor port can be mirrored to this port. For each of the ports to be mir-
rored, you can select the direction, i.e. ingress frames, egress frames, or
both.
This is specially helpful if you need to monitor frames that are processed by
the built-in switch on the COGE1 unit. For details, please refer to:
• section AP: / unit-x / port-a, Configuration – Port Mode (on page 136),
and
• section AP: / unit-x / port-a, Configuration – Mirroring (on page 154) and
following.
Any of the internal ports to the service units can be configured to be a ser-
vice port. This is the typical port mode for the connection between a service
unit and the COGE1 unit.
Frames from a subscriber port on a service unit are forwarded to the switch
on the COGE1 unit and vice versa. This requires the configuration of a ser-
vice on the MileGate network element.
Figure 15: Jumper position and setting for esi-1 and esi-2
Please note:
The list of service units that are managed via the GbE star (inband manage-
ment) can be found in section 4.1.1 of the [201] System Description “Mile-
Gate R3B”.
Please note:
The internal backplane port to the redundant COGE1 unit has the fixed port
mode “VLAN Trunk Port”.
The connection with slot 13 is available to allow the 1:1 equipment protection
concept.
5.2.6.2 CBUS
The CBUS (Control BUS) contains signals used for the interworking of the
units in a subrack like slot select control signals, alarms, power supply, and
inventory information.
5.2.6.3 PBUS
The interfaces for external alarms (inputs, outputs) of the MileGate 25x0 are
situated on the FANU4 fan unit, providing a total of 12 alarm inputs and 2
alarm outputs. They are physically connected to the backplane and pro-
cessed on the COGE1 unit.
For more information on these alarm interfaces, please refer to "[302] User
Guide “MileGate 2500/2510”".
The interface for external alarm inputs of the MileGate 23x0 are situated on
the FANU6 fan unit, providing a total of 12 alarm inputs and 2 alarm outputs
(FANU6 R3 only). They are physically connected to the backplane and pro-
cessed on the COGE1 unit.
For more information on this alarm interface, please refer to "[317] User
Guide “MileGate 2300/2310”".
The COGE1 unit provides two output signals, indicating the NE alarm status,
for processing in external equipment. In the MileGate the outputs are gener-
ated and controlled by the COGE1 unit and interfaced
• to the fan unit FANU4 for the MileGate 25x0,
• to the fan unit FANU6 (R3) for the MileGate 23x0.
Please note:
The FANU6 (R1, R2) provides no alarm outputs.
The FANU4 unit is connected to the COGE1 unit via backplane signals and
a D-Sub 15 connector located at the bottom of the subrack.
The FANU6 (R3) unit is connected to the COGE1 unit via backplane signals.
In the event of a failure the COGE1, through the fan unit, will report as exter-
nal alarm one of the following:
• Non-service affecting alarm:
When the NE highest alarm severity or highest propagated alarm severity
is minor, warning, or indeterminate.
• Service affecting alarm:
When the NE highest alarm severity or highest propagated alarm severity
is critical or major.
Please note:
For more information on external input/output alarm interface and features
please refer to the “FANU4” section in [302] User Guide “MileGate 2500/
2510”, or to the “FANU6” section in [317] User Guide “MileGate 2300/2310”.
The COGE1 unit processes external alarms from equipment that is con-
nected to the alarm inputs
• on the fan unit FANU4 for the MileGate 25x0,
• on the fan unit FANU6 for the MileGate 23x0.
From the FANU4, these alarms are connected to the COGE1 unit via cabling
and the backplane D-Sub 15 connector.
From the FANU6, these alarms are connected to the COGE1 via the back-
plane.
A total of 12 external input alarm signals can be integrated into the NE fault
management. For each of these 12 alarm inputs it is possible to:
• enable or disable the input
• configure the active signal level for the input to:
− active ground
− active open
Please note:
For more information on external input/output alarm interface and features
please refer to the “FANU4” section in [302] User Guide “MileGate 2500/
2510”, or to the “FANU6” section in [317] User Guide “MileGate 2300/2310”.
In order to protect the functions and interfaces that are provided by the core
unit it is possible to implement redundancy for the COGE1 unit (in slot 11) by
placing a second COGE1 unit into the subrack, i.e. in slot 13 of the MileGate.
This is called 1:1 equipment protection.
The redundant core unit is in warm standby mode. The MAC address table
on the redundant core unit is continuously updated and thus identical to the
information on the working core unit. The configuration and the MIB data-
base are updated with a “Save” operation on the network element. Any
changes after the “Save” operation will be lost after a protection switching
event.
The ARP table is not mirrored. It is built up from scratch after a protection
switching event.
The basic scheme for 1:1 equipment protection for COGE1 is shown in
Figure 16.
The redundant core unit works as an independent active switch containing
an active RSTP switch; this means that all Ethernet front interfaces are
active for management and subtending.
A switch-over can also be initiated manually via the MCST GUI or the CLI.
For more details, refer to "[302] User Guide “MileGate 2500/2510”" or to
[317] User Guide “MileGate 2300/2310”.
When a protection switch-over occurs, the standby unit and the connected
service units are informed via hardware connection. The following steps will
follow in order to complete the protection switching:
• The service units switch over to the standby core unit (via the redundant
Ethernet star).
• The standby core unit takes control of the MileGate subrack and
becomes the active unit.
• Fault management delivers the appropriate alarms.
• RSTP will establish a new tree accordingly.
• Update of dynamically learnt information, like MAC address table.
MileGate MileGate
GbE ring
connection
blocked by
RSTP*
MileGate
COGE1 COGE1
working unit redundant unit
CPU CPU
active standby
links links
Please note:
The switch-over due to an equipment failure is non-revertive.
Please note:
Be aware that switching (automatic or forced) between the working and
redundant core units may imply an impact on configured services, i.e. ser-
vices may be unavailable for a short time period.
To enable equipment protection for the COGE1 unit some prerequisites must
be met:
• The redundant COGE1 unit must be in the assigned state.
• The redundant unit must be hardware compatible with the working unit.
Check the hardware compatibility status in the AP: /, Status - Redun-
dancy: Core Units Status, Equipments Compatible.
• The redundant unit must be software compatible with the working unit. A
compatible software must be of the same ESW release state, e.g. both
units must use an ESW coge1_r7bxyy.
The COGE1 unit in slot-11 is assigned and configured the same way as an
unprotected COGE1 unit.
The redundant COGE1 unit in slot-13 is running with the same ESW as the
working unit and must be in the assigned state. The unit has to be config-
ured according to the used port connections and switch functions.
5.4 Synchronisation
Please note:
For details on the synchronisation aspects and configuration details at sys-
tem level, please refer to "[314] User Guide “TDM Services and Cross Con-
nections”".
The COGE1 unit has four LED optical indicators showing information about
the unit, traffic, status and lock state.
The following figure shows the LED layout on the unit.
COGE1
control unit
UNIT TRAFFIC
ACTIVE LOCKED
Figure 17: Fault and status indication LEDs on the COGE1 unit
The operating state of the COGE1 unit can be known by reading the unit
LED optical indicator from the NE.
The following table shows the signalling of the COGE1 LEDs and their
meaning.
Please note:
When COGE1 is started up for the first time (from factory default settings),
all LEDs will be “ON”. This state means that the bootloader is active but
there is no application software (ESW) to launch.
For the installation of application software (ESW), please refer to "[304] User
Guide “MileGate & MCST”".
5.5.1.1 Booting
5.5.1.2 Waiting
The control unit is waiting for configuration. The waiting state lasts as long as
the COGE1 has no configuration.
In this status, the COGE1 can only provide the “point to point” type of man-
agement communication. This means that only the USB port will allow a
direct connection for initial commissioning.
5.5.1.3 Active
The internal resources are available and the COGE1 controls the NE. The
“active” state is characterised by a constant active green UNIT LED.
5.5.1.4 Failure
The unit has failed and is not operating. The unit is either
• faulty, or
• the ESW and the unit hardware are not compatible.
5.5.1.5 Standby
The control unit is waiting to take over the control of the NE. The “standby”
operation state is only possible for the redundant unit in an NE with 1+1
equipment protection for the control unit.
6 Commissioning
This section presents how to configure and bring into operation the COGE1
unit and its main functions. For operation, i.e. status and maintenance func-
tions refer to section Operation and maintenance (on page 87).
6.1 Introduction
6.1.1 Definitions
• MO (Managed Object):
Management view of a resource in the NE, e.g. COGE1
• AP (Access Point):
Addressable part of a MO, e.g. port-1: 1000BASE-X/10000BASE-R SFP
• MF (Management Function):
Predefined category of management operations, e.g. configuration, sta-
tus, etc
• Unit-x:
In this context, the COGE1 unit in slot 11 (unit-11, core unit) or in slot 13
(unit-13, redundant core unit).
Please refer to "[304] User Guide “MileGate & MCST”" for information on the
management of a MileGate with the COGE1 as core unit.
The following figure shows the first two levels of the Managed Object Model
(MOM) for MileGate 25x0 with the “unit-x” specially coloured. Each one of
these entries on the tree represents an Access Point (AP). The COGE1 is a
specific “unit-x” instance.
<ap >
MileGate 25x0
<ap >
eoam
<ap >
fan
<ap >
multicast
<ap >
services
<ap >
tdmConnections
As it can be seen from the above model, the MileGate provides an AP for
every plugged unit and APs to configure NE level functions like services.
Every AP provides Management Functions (MF) like “Main”, “Configuration”
(cfgm), “Fault Management”, etc.
The Managed Object Model (MOM) for MileGate 23x0 is essentially identical
to the MOM of the MileGate 25x0. Please refer to Figure 18 above.
The following figure shows the AP tree for the COGE1 unit in a MileGate.
<ap >
MileGate
2 <ap>
esi-y
1 <ap>
internalPorts
1 <ap>
cpu
20 <ap>
slot-b
3 <ap>
lag-z
5 <ap>
port-a
1 <ap>
protocols
1 <ap>
rstp
The AP “port-a” includes both, 1000BASE-X SFP Ethernet ports (port-1 and
port-2), and electrical 10/100/1000BASE-T Ethernet ports (port-3 to port-5).
For a description of the functionality included within these managed objects,
please refer to sections Commissioning (on page 73) and Operation and
maintenance (on page 87).
Please note that service related operations like VLAN tagging, filtering, etc.
are part of the managed object “services” on NE level, which is described in
[303] User Guide “Triple Play Applications”.
6.3.1 Prerequisites
Please note:
When you power up the COGE1 unit for the first time (from factory default
settings), all LEDs will be “ON”. This state means that the bootloader is
active but there is no application software (ESW) to launch. You will need to
install an appropriate ESW. Please refer to "[302] User Guide “MileGate
2500/2510”" or to [317] User Guide “MileGate 2300/2310” for a guide on how
to install ESW the first time.
• a redundant COGE1 unit (if required) must be physically plugged in slot
13 of the MileGate subrack. This is mandatory if you want to implement
core unit redundancy. It is not required if you do not want core unit redun-
dancy.
• MCST must be installed on a PC that is locally available and started. For
more details about MCST installation, refer to "[304] User Guide “Mile-
Gate & MCST”".
• USB and Ethernet cabling must be connected to the corresponding ports.
For details about the installation of a USB driver on your PC, and the ini-
tial connection to your MileGate, please refer to "[302] User Guide “Mile-
Gate 2500/2510”" or to [317] User Guide “MileGate 2300/2310”.
Please note:
Ethernet cabling should be connected to both the master and the redundant
COGE1 if redundancy is implemented.
→ In this case, special care must be taken to correctly configure RSTP
settings in order to avoid broadcast storms (see warning note in sec-
tion Equipment protection EQP (core unit redundancy) (on page 65)).
If you do not want to enable RSTP, you should configure the front
port(s) of the core unit such that they are automatically disabled while
the unit is in the standby mode. For details refer to section AP: / unit-x
/ port-a, Configuration – Port Mode (on page 136).
• You need to create a suitable connection in the MCST to be able to con-
nect to your MileGate. For more details, please refer to "[304] User Guide
“MileGate & MCST”".
• You need to connect to the MileGate in order to be able to install valid
ESW. For more details, please refer to "[304] User Guide “MileGate &
MCST”".
• You need to install valid ESW on the COGE1 unit in slot 11. If you imple-
ment core unit redundancy, you need to install the identical ESW on the
COGE1 units in both slot 11 and slot 13. For details regarding the man-
agement and installation of ESW refer to "[304] User Guide “MileGate &
MCST”". Please make sure the ESW version fulfils the requirements
stated in [012] Release Note “MileGate R3B”.
In order to configure one of the Ethernet front ports in COGE1, the following
steps should be adhered to. If you are using a redundant COGE1, the steps
must be performed on both COGE1, the active core unit (unit-11) and the
standby core unit (unit-13).
The “unit-x” stands for either “unit-11”, or “unit-13”, or for both in a sequential
order; the “port-a” stands for any of the front ports “port-1” … “port-5”.
In the CLI command lines shown below, the vertical bar character “|” means
a delimiter of several possible options. The expression “GUI AP” means the
access point (AP) for the respective action in the MCST GUI.
2 Define the management VLAN (also see [304] User Guide “MileGate & MCST”)
GUI AP: ne, Configuration – Management Interface, Management VLAN
Enter the management VLAN ID according to the network planning, or leave the default (4089).
CLI:/> set /cfgm/VlanId <VlanId>
3 Define the port mode (also see section AP: / unit-x / port-a, Configuration – Port Mode (on page 136))
GUI AP: /unit-x/port-a, Configuration – Port Mode, select either of the port modes:
- Mode = Management Port
- Mode = VLAN Trunk Port
CLI:/> set /unit-x/cfgm/PortMode <Mode>
Note: for mirror ports, refer to sections AP: / unit-x / port-a, Configuration – Port Mode (on page 136) and
AP: / unit-x / port-a, Configuration – Mirroring (on page 154).
Enable “Port Down For Standby” if RSTP is disabled:
- Port Down For Standby =
CLI:/> set /unit-x/cfgm/Redundancy true
Disable the port VLAN:
- Enable Port VLAN =
CLI:/> set /unit-x/cfgm/PortVlan false <VlanId> <CoS>
4 Define the port RSTP mode (also see section AP: / unit-x / port-a, Configuration – RSTP (on page 140))
GUI AP: /unit-x/port-a, Configuration – RSTP
- RSTP Enabled = (recommended)
CLI:/> set /unit-x/port-a/cfgm/Rstp true
For the configuration of the RSTP parameters please refer to section Port and LAG RSTP parameters (on
page 81).
5.1 Configure the VLAN blacklist or VLAN whitelist (also see section AP: / unit-x / port-a, Configuration – VLAN list
(on page 142))
GUI AP: /unit-x/port-a, Configuration – VLAN List, select either of the two list types:
- List Type = Blacklist
- List Type = Whitelist
CLI:/> set /unit-x/port-a/cfgm/ListType Blacklist|Whitelist
5.2 If required, add VLANs to the list, otherwise leave the defaults (empty lists).
CLI:/> set /unit-x/port-a/cfgm/VlanList {<RangeStart> <RangeEnd>;}
e.g.:/> set /unit-11/port-1/cfgm/VlanList {112 120; 212 220}
Note that by default, all ports will become members of all VLANs created. This assignment is done transpar-
ently to the user.
6 Select the scheduling profile (also see section AP: / unit-x / port-a, Configuration – QoS (on page 144))
GUI AP: /unit-x/port-a, Configuration – QoS, Scheduling Profile, Name; select the profile name.
Note that with the default profile, strict priority scheduling with equal weight for each queue is applied. If you
want to have a weighted scheduling, you need to create a profile as described in section Scheduling profiles
(on page 99) and download that profile to the MileGate, then select it from the “Scheduling Profile” list.
CLI:/> set /unit-x/port-a/cfgm/SchedulingProfileName <Name>
7.1 Define the Multicast configuration (also see section AP: / unit-x / port-a, Configuration – Multicast (on
page 146))
GUI AP: /unit-x/port-a, Configuration – Multicast:
- Enable IGMP = (this makes the port multicast capable using IGMP)
- Enable IGMP = (this disables the support of IGMP on the port)
CLI:/> set /unit-x/port-a/cfgm/ EnableIgmpClassifier true|false
Note that you need to enable processing of IGMP router queries if you intend to configure dynamic multicast
services via this port, otherwise disable IGMP.
7.2 - Allow Static Streams= (the corresponding static multicast groups must be configured at the AP: / “multi-
cast”. For further information refer to "[303] User Guide “Triple Play Applications”".
- Allow Static Streams= (no static multicast groups are required).
CLI:/> set /unit-x/port-a/cfgm/ AllowStaticStreams false
7.3 - Multicast Port Mode = Hybrid (recommended for most setups)
- Multicast Port Mode = Trunk (if no IGMP queries shall be sent on this port)
- Multicast Port Mode = Subtending Access (if no IGMP reports shall be sent on this port)
CLI:/> set /unit-x/port-a/cfgm/ MulticastPortMode SubtendingAc-
cess|Trunk|Hybrid
8 Configure Link Aggregation (also see section AP: / unit-x / port-a, Configuration – Link Aggregation (on
page 147))
GUI AP: /unit-x/port-a, Configuration – Link Aggregation, select the link aggregation group membership
- LAG Member = None (the port isn’t a member of any of the three link aggregation groups)
- LAG Member = lag-1 (the port is a member of LA group 1)
- LAG Member = lag-2 (the port is a member of LA group 2)
- LAG Member = lag-3 (the port is a member of LA group 3)
Note that the port cannot be configured for a LAG if there are different settings configured on two ports that
shall become member of the same LAG.
9 Configure the physical layer settings (also see section AP: / unit-x / port-a, Configuration – PHY (on page 151))
GUI AP: /unit-x/port-a, Configuration – PHY, select the speed and duplex settings.
CLI:/> set /unit-11/port-5/cfgm/PhyMode <SpeedAndDuplex>
If required, select one of the fixed modes, otherwise leave the default “Autonegotiation On” (recommended)
10 Configure the EOAM settings (also see section AP: / unit-x / port-a, Configuration – EOAM (on page 152))
GUI AP: /unit-x/port-a, Configuration – EOAM
EOAM NNI Mode Enabled =
EOAM NNI Mode Enabled =
CLI:/> set /unit-x/port-a/cfgm/NetworkNetworkInterface true|false
Note that this setting only affects the behaviour of the port with respect to Ethernet OAM messages. For more
details refer to section AP: / unit-x / port-a, Configuration – EOAM (on page 152), and to [316] User Guide
“Ethernet OAM”.
11 Configure the DSCP to Ethernet priority mapping (also see section AP: / unit-x / port-a, Configuration – Priority
Mapping (on page 153))
GUI AP: /unit-x/port-a, Configuration – Priority Mapping
DSCP To 802.1q Tx Priority Mapping Enabled =
DSCP To 802.1q Tx Priority Mapping Enabled =
CLI:/> set /unit-x/port-a/cfgm/DSCPTo802Dot1qTxPriorityMapping true|false
Note that the VLAN priority of outgoing packets is set according to the IP DSCP value. The mapping is config-
ured at the unit AP and is done per VLAN ID and per DSCP.
12 Activate the port (also see section AP: / unit-x / port-a, Main – Admin And Oper Status (on page 134))
GUI AP: /unit-x/port-a, Main – Admin And Oper Status
Select Administrative Status, State = Up
CLI:/> set /unit-x/port-a/main/AdministrativeStatus Up
Note: once the port is “Up”, no more configuration changes are allowed unless the port administrative state is
set back to “Down”.
End
The following RSTP parameters will allow you to tune the performance of
your switching network:
• Bridge priority
It is used to form the ‘bridge identifier’ (priority + bridge MAC address).
The default value is 32’768. The bridge with the lowest identifier will
become ‘root bridge’ in RSTP.
Please note:
The root bridge should be close to the network resources (e.g. servers, etc.)
in your network to ensure smooth traffic flow. Also refer to more information
given in section AP: / unit-x / protocols / rstp, Configuration – Local Bridge
(on page 173).
• Hello interval
Time between two configuration BPDUs sent on a port. Its default value
is 2 seconds.
• Forwarding delay
Time spent in the listening and learning states. Its default value is 15 sec-
onds.
This value has no big impact in pure RSTP networks. It may need to be
increased if the maximum age is also increased.
• Max age time
Maximum period of time a bridge holds and uses information in a configu-
ration BPDU. Its default value is 20 seconds.
This parameter is important to support large RSTP networks.
Please note:
In the 802.1Q bridging mode (AP: /, Configuration - Packet), the RSTP
BPDU destination address is the 802.1D bridge group address.
Please note:
In the 802.1ad bridging mode (AP: /, Configuration - Packet), the RSTP
BPDU destination address is the provider bridge group address.
The next figure shows the recommended ‘maximum age’ values for different
LAN sizes according to 802.1w when the ‘hello time’ is 1 and 2 seconds.
20 20
18 18
LAN Diameter (bridges)
In Figure 20, the maximum age depends on the end-to-end BPDU propaga-
tion delay and a message age overestimate (which accounts for the age of
the BPDU since its origination), and from the hello time and the number of
hops (switches). Only the first (leftmost) slope of the diagrams is relevant
however.
The following RSTP parameters will allow you to configure the active topol-
ogy of your switching network:
• Port cost
Every bridge has a root path cost associated with it. It is the sum of the
port path costs on the least cost path to the root bridge.
The port path cost is the contribution of the port, when it is the root port,
to the root path cost for the bridge.
IEEE 802.1D-2004 recommends the following port path cost values for
the different link speeds:
If dynamic path cost calculation is disabled the configured port path cost
is the effective port path cost irrespective of the actual link speed.
If dynamic path cost calculation is enabled the configured port path cost
is taken as the cost value of a 1 Gbit/s link. If the link speed is set to
100 Mbit/s the effective port path cost is 10 times the configured port path
cost. If the link speed is set to 10 Mbit/s the effective port path cost is 100
times the configured port path cost:
Please note:
Remember that all members of a LAG must have the same link speed.
• Dynamic path cost calculation
If the dynamic path cost enabled parameter is set to (true), the path
cost of a port or a LAG is calculated according to the effective link speed
and the number of active LAG members.
Please refer to the “port cost” and “LAG per link cost” description above.
By using the dynamic path cost calculation it will be ensured that always
the highest bandwidth path will be taken by the traffic, thereby preventing
loss of traffic over a link failure period.
A disadvantage of dynamic path cost calculation is that RSTP has to con-
verge each time the bandwidth changes, which could lead to traffic loss.
• Port priority
Each port has a unique identifier consisting of two parts,
− the port priority, and
− the port number.
The more significant octet of the port identifier is the port priority.
If a bridge has two or more ports with the same root path cost, then the
port with the best port identifier is selected as the root port.
If a designated bridge has two or more ports connected to the LAN, then
the bridge port with the best port identifier is selected as the designated
port.
The lower numerical value indicates the better port identifier.
IEEE 802.1D-2004 recommends the following port priorities:
• LAG priority
For a LAG, the priority overrides any configured or default port priority of
the individual links being aggregated into a LAG.
In order to commission link aggregation on the COGE1 front ports and the
internal ports, you need to have at least two ports available for link aggrega-
tion. These two ports need to be configured identically, but since this is not
done automatically, you have to either use the default configuration or apply
your individual configuration to all link aggregation group member ports
before enabling LA.
Please note:
You have to make sure that the following settings need to be identical on all
member ports for a LAG before activating LA for the member ports:
• the port mode (see section AP: / unit-x / port-a, Configuration – Port
Mode (on page 136)),
• the RSTP mode, the RSTP port cost, port priority and dynamic path cost
enabled parameters (see section AP: / unit-x / port-a, Configuration –
RSTP (on page 140)),
• the VLAN list (see section AP: / unit-x / port-a, Configuration – VLAN list
(on page 142)),
• the QoS settings (see section AP: / unit-x / port-a, Configuration – QoS
(on page 144)), and
• the multicast settings (see section AP: / unit-x / port-a, Configuration –
Multicast (on page 146)).
Please also note that after having configured and applied all parameters
from the above mentioned dialogues, you go to the “Link Aggregation” dia-
logue (also refer to section AP: / unit-x / port-a, Configuration – Link Aggre-
gation (on page 147)) and set the LA parameters as described in section LA
parameters (on page 84) below.
6.3.4.2 LA parameters
The following parameters can be set when configuring two or more ports for
LA:
• the LA group (“lag-1”, “lag-2”, “lag-3” or “None”)
• the enable state of LACP on each of the ports (enable, disable)
Both of these parameters are set per port as described in section AP: / unit-x
/ port-a, Configuration – Link Aggregation (on page 147).
Please note:
Make sure you set both properties (the LAG membership and the LACP ena-
ble state) as required before applying the changes. Do not apply one after
the other since the two properties depend on each other.
Once the group has been configured for each of the member ports, the LA
group’s administrative state can be set to “up”. This is done as described in
section AP: / unit-x / lag-z, Main – Admin And Oper Status (on page 121).
For the implementation of core unit redundancy, you need a total of two core
units. The position of the first core unit in the MileGate subrack, with or with-
out redundancy, is slot 11. The redundant core unit is placed in slot 13.
Once the redundant core unit is plugged into slot 13 and has started up, you
need to make sure that the following conditions for a correct operation are
fulfilled.
In order to provide core unit redundancy, the two COGE1 units need to:
• be assigned; for unit assignment, you …
− execute the command “Assign” from the context menu on the AP:
“unit-11” and on the AP: “unit-13” (MCST GUI),
or
− execute the command “/unit-13/main/assign” in the CLI.
For equipment handling, also refer to "[304] User Guide “MileGate &
MCST”";
• run the same ESW version (for ESW installation refer to "[304] User
Guide “MileGate & MCST”");
• have the same configuration, i.e.
− the front port settings should be identical. For front port configuration
refer to section AP: / unit-x / port-a, Configuration (on page 136);
• have the same signals connected to their front ports, i.e.
− when connecting the element manager via the serial interface (USB),
they both need an USB connection; an USB hub can be used for this
purpose;
− when using synchronisation signals, the signals need to be connected
to both COGE1 ESI and/or ESO ports;
− the Ethernet cables or fibres need to be connected to both COGE1
units. In this case, please make sure that RSTP is activated on both
ends, the two COGE1 front ports, and the remote equipment.
− section AP: / unit-x / port-a, Configuration – Port Mode (on page 136),
and
− section AP: / unit-x / protocols / rstp, Configuration – Local Bridge (on
page 173).
Once these conditions are fulfilled, the two core units appear as a pair of
units where the unit in slot 13 provides equipment protection for the unit in
slot 11.
7.1 Redundancy
Provided that you have commissioned your MileGate for core unit redun-
dancy, you have the following information available for redundant operation
of the COGE1 unit:
• unit status overview (also see section AP: / unit-x, Status – Redundancy
(on page 111))
• unit fault status (also see section AP: / unit-x, Fault Management (on
page 107))
• redundancy status overview (available on NE level, refer to "[304] User
Guide “MileGate & MCST”")
• database storage overview (available on NE level, refer to "[304] User
Guide “MileGate & MCST”")
The unit status (AP: /unit-11, Status – Redundancy, or AP: /unit-13, Status -
Redundancy) provides you with information of the selected unit. Provided
that core unit redundancy is implemented, the currently active unit shows its
status as “Active” while the standby unit shows “Stand-By”. Both units show
their common information about the presence of the redundant core unit, and
about their synchronisation status:
For more information, refer to section AP: / unit-x, Status – Redundancy (on
page 111).
The unit fault status provides two fault causes related to redundancy that can
activate an alarm if the related conditions are fulfilled. The two fault causes
are
• REDSBN (Redundancy: Standby core unit is not synchronised)
• REDSWF (Redundancy: Switch-over failed)
These two fault causes can be generated by the active core unit and provide
information about the redundancy status.
Both the redundancy status overview and the database storage overview are
NE level status functions that are available on the root AP: ne. They provide
information about
• the core unit status,
• the core unit roles,
• the NE database save status,
• the NE database mirror status,
and they also provide the commands for
• isolating units from protection groups,
• joining units to protection groups,
7.2 Maintenance
It is possible to read inventory data from the COGE1 unit via the MCST GUI
by performing the following action:
AP: / unit-11 / Main / Inventory
or (with a redundant core unit implemented)
AP: / unit-13 / Main / Inventory
In the CLI, you enter the following command line for getting inventory infor-
mation from the COGE1 unit:
Syntax:/> get /unit-11/main/EquipmentInventory
or (with a redundant core unit implemented):
Syntax:/> get /unit-13/main/EquipmentInventory
This will output the inventory information on the CLI.
In certain situations, you may need to monitor frames on any of the internal
or external ports of the COGE1 unit. For this purpose, any of the five Ether-
net front ports or any of the 20 internal ports to a service unit can be config-
ured to be a mirror port.
Assuming the case where you want to monitor all frames that are sent by
two service units in slots 1 and 20 to the COGE1 switch (unit-11), and you
have one front port of the COGE1 yet unused (e.g. port-5), you may proceed
as follows to get the frames to a monitoring equipment connected to that
spare front port.
If you are using the MCST GUI for managing your MileGate, please proceed
as follows (this is an example):
Table 25: Setting up mirror ports with the MCST GUI (continued)
Step Action
2 Define the ports to be mirrored
GUI AP: /unit-11/port-5, Configuration – Mirroring, Port Table, Add
New Entry, Port = Backplane Port 1, Mode = Incoming; press “Apply” to apply
New Entry, Port = Backplane Port 20, Mode = Incoming; press “OK” to apply and close.
Press “OK” in the “GUI AP: /unit-11/port-5, Configuration – Mirroring” dialogue to apply the ports to be mir-
rored.
3 Set the port-5 admin state to “up”
GUI AP: /unit-11/port-5, Main – Admin And Oper Status, Administrative Status, State = “Up”
Press “OK” in the “GUI AP: /unit-11/port-5, Main – Admin And Oper Status” dialogue.
End
Now you connect your monitoring equipment to port-5 of the COGE1 unit
and start monitoring.
If you are using the CLI for managing your MileGate, please proceed as fol-
lows (this is an example):
When you are using RSTP, you check the RSTP status of the COGE1
unit(s) on the AP “unit-11/protocols/rstp, Status”, and optionally (if you oper-
ate a redundant core unit) on the AP “unit-13/protocols/rstp, Status” (please
refer to section AP: / unit-x / protocols / rstp, Status (on page 174)).
The status information displayed in this dialogue shows you the MAC address
and the configured priority for both the local bridge and the root bridge.
For the root bridge, you get additional information, as
• whether the root bridge is local or remote,
• the hello interval,
• the forwarding delay, and
• the max age time.
When network topology changes affecting the RSTP status and causing a
change of the root bridge, a notification indicating “root bridge changed” is
issued and written to the NE event logbook.
The NE event logbook can be found in the “Main” dialogue on NE level. For
more information, please refer to "[304] User Guide “MileGate & MCST”".
The bridge ports and link aggregation groups provide the RSTP status infor-
mation on the following APs:
• “unit-11/port-a, Status - RSTP”, refer to section AP: / unit-x / port-a, Sta-
tus – RSTP (on page 161),
• “unit-11/internalPorts/slot-x, Status - RSTP, refer to section AP: / unit-x /
port-a, Status – RSTP (on page 161), and
• “unit-11/lag-z, Status - RSTP, refer to section AP: / unit-x / lag-z, Status –
RSTP (on page 128).
If you operate a redundant core unit the RSTP status is available also on the
corresponding APs of unit-13.
The status information displayed in this dialogue shows the following information:
• Port state or LAG state
Each bridge port or LAG has an operational port or LAG state that gov-
erns whether or not it forwards MAC frames. A port or LAG can have the
following states:
− Disabled
“Disabled” is a state used in the STP algorithm. A port can be disabled
by the management or by a failure. All received frames are discarded
by a disabled port or LAG.
− Discarding
Any port that is not enabled, or has been excluded from the active
topology by the management or has been dynamically excluded from
forwarding and learning from MAC frames.
− Learning
Any port or LAG that has learning enabled but forwarding disabled.
− Forwarding
A port or LAG that learns and forwards frames.
• Port role or LAG role
The RSTP algorithm assigns one of the following roles to each bridge
port or LAG:
− Root,
A forwarding port or LAG that has been selected for the spanning-tree
topology. The root port or LAG connects the bridge to the root bridge.
− Designated
A forwarding port or LAG for every LAN segment.
− Alternate
An alternate path to the root bridge. This path is different than using
the root port or LAG. The alternate port or LAG is not forwarding.
− Backup
A backup/redundant path to a segment where another bridge port
already connects. Backup ports access a shared medium. The backup
port is not forwarding.
− Disabled.
The disabled port or LAG role is assigned if the port or LAG is not
operational or is excluded from the active topology by the manage-
ment. The disabled port or LAG is not forwarding.
• Port cost or LAG cost
Display of the “Port Cost” or “LAG Cost” configuration parameter if
dynamic path cost calculation is disabled.
If dynamic path cost calculation is enabled, the effective cost according to
the link speed and the number of active LAG members is displayed.
Please refer to section Port and LAG RSTP parameters (on page 81).
• Port priority or LAG priority
Display of the “Port Priority” or “LAG Priority” configuration parameter.
Please refer to section Port and LAG RSTP parameters (on page 81).
• Port enabled or LAG enabled
Display of the “RSTP Enabled” configuration parameter.
• Edge
Ports are edge ports if they are attached to a LAN that has no other
bridges attached, e.g. if they are connected to a PC.
As soon as the bridge detects a BPDU coming to an edge port, the port
becomes a non-edge port.
• Point-to-point
The port or LAG is attached to a point-to-point link, as opposed to a
shared link.
A port or LAG operating in full duplex mode is a point-to-point port or LAG
and can be switched fast.
A port or LAG operating in half duplex mode accessing a shared link
requires a time consuming RSTP negotiation between all attached
bridges when it has to be switched.
• Dynamic path cost enabled.
Display of the “Dynamic Path Cost Enabled” parameter. Please refer to
section Port and LAG RSTP parameters (on page 81).
When you are using Link Aggregation, you can check the status of each of
the three LA groups. The information provided in the status dialogue (refer to
section AP: / unit-x / lag-z, Status (on page 123)) includes
• the “Aggregation” status (see section AP: / unit-x / lag-z, Status – Aggre-
gation (on page 123)),
• the “QoS” status (see section AP: / unit-x / lag-z, Status – QoS (on
page 126)), and
• the “RSTP” status (see section AP: / unit-x / lag-z, Status – RSTP (on
page 128)).
All information displayed in these status dialogues is applicable to the whole
virtual LA link.
7.4.1 LA notifications
8.1 Introduction
Below, you will find a detailed description of all the configuration parameters
and operations belonging to the managed objects model (MOM) for the
COGE1 core unit operated in a MileGate.
The descriptions provide both screen views and descriptions for the MCST
GUI, and a reference for the command line interface (CLI).
The order of appearance of the management functions in this reference is in
accordance with the context menu order for each of the APs in the MCST
GUI AP tree.
A full context menu may look as follows:
Most of the APs only offer a part of the menu items shown above since each
AP provides an individual set of management functions out of the ones
shown above.
For each of the managed objects, properties, and commands, both the GUI
view and the CLI syntax are given. In order to clearly identify the CLI syntax,
a different font is used for the CLI.
This reference section comprises the management functions (CLI names
in brackets):
• “Main” (main),
• “Configuration” (cfgm),
• “Fault Management” (fm),
• “Performance Management” (pm), and
• “Status” (status).
In the tables of the sections below, the parameter default values for proper-
ties are underlined.
Please note:
In the CLI syntax shown for each of the operations, there may be line feeds
applied in this user guide although the command is entered without line
feeds in the CLI. This is due to the restricted line length available in this user
guide.
Please note:
For better legibility of numbers in this user guide, inverted commas are used
when the number’s size exceeds three digits (e.g. 40’000). In parameter
entry fields of the MCST GUI or the CLI, these inverted commas must not be
entered. Instead, the numbers are entered without these inverted commas
(e.g. 40000).
Please note:
Screenshots presented in this reference may show configurations or data
that may not correspond to the GUI you see when managing your MileGate
equipment.
Please note:
Please refer to "[304] User Guide “MileGate & MCST”" for the description of
the MCST functions (GUI and CLI) and refer to "[302] User Guide “MileGate
2500/2510”" for the specific characteristics of the MileGate 25x0 and refer to
"[317] User Guide “MileGate 2300/2310”" for the specific characteristics of
the MileGate 23x0.
8.2 Profiles
8.2.1 General
Please note:
Alternatively profiles can be created with the CLI directly on the NE.
Packet buffer profiles are applicable to the managed objects named “unit-11”
or “unit-13”. The packet buffer profiles are applicable to the layer 2 switch of
the COGE1 unit:
To create a packet buffer profile from a template, start the Profile Tool in the
MCST GUI Tools menu, and click on the “Create…” button.
To modify an existing scheduling profile, start the Profile Tool, select an
existing profile from the “Profiles on Management System” list, and click on
the “Create From…” button. To import an existing profile, click on the
“Import” button in the Profile Tool. For more information on the profile tool,
please refer to "[304] User Guide “MileGate & MCST”".
In the Create New Profile dialogue, select a PktBufProfile_x.yy.yy (where
x.yy.yy is an available version number) as template for a COGE1 unit. Make
sure that the profile type corresponds to the type required by the ESW ver-
sion running on your COGE1 unit. Refer to Table 27.
The packet buffer profile allows you to configure the packet buffer sizes for
all outgoing switch ports and for all priority levels.
To create a scheduling profile from a template, start the Profile Tool in the
MCST GUI / Tools menu, and click on the “Create…” button.
To modify an existing scheduling profile, start the Profile Tool, select an
existing profile from the “Profiles on Management System” list, and click on
the “Create From…” button. To import an existing profile, click on the
“Import” button in the Profile Tool. For more information on the profile tool,
please refer to "[304] User Guide “MileGate & MCST”".
In the Create New Profile dialogue, select a CUWqProfile_x.yy.yy (where
x.yy.yy is an available version number) as template for a COGE1 port. Make
sure that the profile type corresponds to the type required by the ESW ver-
sion running on your COGE1 unit. Refer to Table 29.
The scheduling profile allows you to select a queuing mode for each of the
eight output queues of the port. The eight queues correspond to eight traffic
classes. It also allows you to select a weight for each of the eight queues
when using weighted round robin (WRR) scheduling. With strict scheduling,
the weight is fixed.
Please note:
Per default the queue 7 (highest priority queue) is reserved for the MileGate
internal management traffic. Nevertheless you have to configure a schedul-
ing profile as if all eight queues would be available for user traffic. The
remapping of the scheduling type and weight is done automatically.
→ The effective scheduling can be checked at the AP: /unit-x/port-y, Sta-
tus - QoS and at the AP: /unit-x/lag-y, Status - QoS, x = 11 or 13.
→ For further information please refer to section CoS, 802.1p (on
page 47).
Please note:
To use the queue 7 also for user traffic the standard queue mode must be
disabled at the AP: /, Configuration - QoS.
profiles, by clicking the “Apply” button and continue with the creation of a fur-
ther profile.
When you have finished creating profiles, you download the profiles to the
NE to make them selectable and applicable on your MileGate.
The scheduling profile can be applied to COGE1 ports as described in sec-
tion AP: / unit-x / port-a, Configuration – QoS (on page 144) (front ports and
internal ports).
In this section, all the commands and properties are described that are
required to configure and commission the COGE1 unit level. The parameters
are sorted as they are found in the access point tree.
The name “unit-x” stands for:
• the “unit-11” if only one COGE1 is operated in the MileGate, or
• the “unit-13” if, in addition to unit-11 a redundant COGE1 is operated in
the MileGate.
vice units from a large amount of broadcast messages which need not be
forwarded by them, these broadcast messages can be filtered.
Syntax:cd /unit-x/cfgm
Syntax:set BroadcastFilter {<VlanId> <PPPoE>
<DHCPRequest> <DHCPResponse>;}(0 … 20)
Syntax:get BroadcastFilter
Syntax:cd /unit-x/cfgm
Syntax:set DSCPTo802Dot1qPriorityMapping {<VlanId>
<DscpField> <CoS>;} (0 … 100)
Syntax:get DSCPTo802Dot1qPriorityMapping
The switch packet buffer sizes on the COGE1 unit can be configured in the
outgoing direction per switch port and per priority. The configuration is done
via a profile.
Please refer to section Packet buffer profiles (on page 96) for a description
of the profile creation.
Syntax:cd /unit-x/cfgm
Syntax:set PacketBufferProfileName <Name>
Syntax:get PacketBufferProfileName
Syntax:cd unit-x/status
Syntax:get QosPriorityMappingStatus
Please note:
The packet priority to queue priority assignment shown in the table reflects
the fact that per default the queue 7 is reserved for the MileGate internal
management traffic.
→ For further information please refer to section CoS, 802.1p (on
page 47).
Please note:
To use the queue 7 also for user traffic the standard queue mode must be
disabled at the AP: /, Configuration - QoS.
Syntax:cd unit-x/status
Syntax:get PacketBufferStatus
If core unit redundancy is implemented, the currently active core unit shows
its status as follows:
Syntax:cd /unit-x/status
Syntax:get Status
The core unit that is currently in redundancy standby mode shows its status
as follows:
For the operation names, parameters and their ranges, please refer to the
description above.
For the Main / General dialogue, refer to "[304] User Guide “MileGate &
MCST”".
Please note:
The esi operational state is up, i.e. the icon in the AP tree turns green, when
the esi input is used as a PDH clock source.
→ For more information please refer to "[314] User Guide “TDM Services
and Cross Connections”"
8.6.1.2 AP: / unit-x / internalPorts / cpu, Main – Admin And Oper Status
This dialogue shows the operational status of the switch internal port to the
CPU.
Syntax:cd /unit-x/internalPorts/main
Syntax:get OperationalStatus
This section covers the PM parameters for the internal switch port to the cpu.
The PM parameters are presented in different groups. For the general view
on a PM dialogue of the MCST GUI, refer to "[304] User Guide “MileGate &
MCST”". The following three basic PM properties appear in every PM dia-
logue:
• Status (valid|invalid|incomplete)
• Timestamp
• Elapsed Time
Also, in each of the PM dialogues, the following counter intervals are availa-
ble:
• User Counter
• History 15min
• History 24h
The following counter groups are available for the COGE1 internal port
towards the cpu:
• “RMON Ethernet Statistic” group, see section PM group: RMON Ethernet
Statistic (on page 116),
• “MISC Ethernet Statistic” group, see section PM group: MISC Ethernet
Statistic (on page 117),
• “MIB-2 Interface Table” group, see section PM group: MIB-2 Interface
Table (on page 117).
• “IF-MIB IfXTable” group, see section PM group: IF-MIB IfXTable (on
page 118).
Please note:
Performance alarm thresholds are not implemented in this release.
Please note:
Performance monitoring intervals are marked as “invalid” while the port’s
administrative state is “down”.
All HC counters are high capacity counters with a counter width of 64 bit.
Syntax:cd /unit-x/internalPorts/cpu/status
Syntax:get PortMacStatus
Syntax:cd /unit-x/internalPorts/cpu/status
Syntax:get PortLinkStatus
Please note:
On the internal ports slot-13 and slot-11 some parameters differ from the
parameter handling of the other internal ports configured as “VLAN Trunk
Port”.
→ Differences are outlined in section Port default configuration parame-
ters (on page 131).
Please note:
Slot 13 can also hold a service unit.
The management functions of the internal ports (AP: / unit-x / internalPorts /
slot-b) are nearly identical to the management functions of the front ports
(AP: / unit-x / port-a). Differences are outlined in the parameter descriptions
of the front ports. Please refer to section AP: / unit-x / port-a (on page 130).
Syntax:cd /unit-x/lag-z/main
Syntax:get AdministrativeStatus
Syntax:get OperationalStatus
Please note:
LAG operational state is up when at least one member is active.
Syntax:cd /unit-x/lag-z/cfgm
Syntax:set LagRstp <LagCost> <LagPriority>
<DynamicPathCostEnabled>
Syntax:get LagRstp
Due to the large size of the dialogue window, the screenshot shown below is
split into two parts. Part 1 shows the “Member Status” and the “Aggregator
Information”:
Syntax:cd /unit-x/lag-z/status
Syntax:get MemberStatusTable
Syntax:get AggregateInfo
Syntax:get ActorInformation
Syntax:get PartnerInformation
Please note:
The scheduling status table is empty in the current release.
→ It will be filled with information in a future release.
Syntax:cd /unit-x/lag-z/status
Syntax:get QosStatus
Please note:
The scheduling type and weight shown in the table reflects the fact that per
default the queue 7 is reserved for the MileGate internal management traffic.
→ For further information please refer to section CoS, 802.1p (on
page 47).
Please note:
To use the queue 7 also for user traffic the standard queue mode must be
disabled at the AP: /, Configuration - QoS.
Syntax:get /unit-x/lag-z/status/LagRstp
This section not only shows the management functions of the front ports but
also the management functions of the backplane ports and the redundant
ports, since they are very similar.
The descriptions in the following sections use the access point designations
of the front ports. For the internal port management function replace the AP
“/unit-x/port-a” by the AP “/unit-x/internalPorts/slot-b”.
The COGE1 has different port types used for the Ethernet traffic:
• Front port on the COGE1 unit for the connection to an external equip-
ment.
• Backplane port for the connection to a service unit plugged in the same
network element via the GbE star.
• Redundant port for the connection to the redundant COGE1 unit via the
GbE star.
Depending of the port type the available port modes differ and the handling
of some parameters may differ as well. The figure below shows the available
port modes for the different port types used in the MileGate:
Backplane Port:
- Service Port
- VLAN Trunk Port
- Management Port
- Mirror Port
• Redundant Port:
AP: / unit-x / internalPorts / slot-b, b = 11, 13 (with core unit redundancy)
The tables below show the default configuration parameter values for the dif-
ferent port types, depending of the port mode. Green shaded entries can be
modified, grey shaded entries are fixed.
Please note:
If a port has the default configuration or not is indicated in the port status dia-
logue:
→ Status - Port Mode - Default Config Enabled.
Please note:
The COGE1 implements two different types of Ethernet ports, 2 SFP based
ports, and 3 electrical ports. The SFP based ports are SFP cages for imple-
mentation of SFP modules. The standard SFP modules recommended for
use with COGE1 are Gigabit Ethernet modules supporting only the speed of
1000 Mbit/s (1 Gbit/s). The ports are therefore called
• ”port-x: 1000BASE-X SFP”
in both the MCST GUI and the CLI. The electrical ports provide speeds of
10, 100 or 1000 Mbit/s and are therefore called
• “port-x: 10/100/1000BASE-T”
in both the MCST GUI and the CLI.
The parameters available for the two types of GbE interfaces (“1000BASE-
FX SFP” and “10/100/1000BASE-T”) are identical except
• for the tab “Main - SFP” which is only available for the SFP ports (port-1
and port-2),
• for the tab “Status - DDM” which is only available for the SFP ports (port-
1 and port-2), and
• for the SFP equipment specific alarms
Please note:
The COGE1 implements one type of Ethernet internal ports, 1GbE electrical
ports. The speed of the ports is fixed.
The ports are therefore called
→ ”slot-b: 1 Gbit/s Ethernet”
in both the MCST GUI and the CLI.
The parameters available for the Ethernet internal interfaces are identical to
the Ethernet electrical front ports.
Syntax:cd /unit-x/port-a/main
Syntax:set AdministrativeStatus <State>
Syntax:get AdministrativeStatus
Syntax:get OperationalStatus
The following dialogue is applicable only to the ports that can be equipped
with an SFP, i.e. “port-1” and “port-2”. The dialogue shows SFP information
of the SFP module that is plugged in this Ethernet port. Some fields may be
empty or unavailable, depending on the inventory information provided by
the manufacturer.
Syntax:cd /unit-x/port-a/main
Syntax:get EquipmentInventory
The information in this section is basically valid for both front port types,
1000BASE-X SFP ports (port-1, port-2) and 10/100/1000BASE-T ports (port-
3, port-4 and port-5), for the backplane port types (slot-1 to slot-10, slot-12,
slot-14 to slot-21), and for the redundant port types (slot-11, slot-13).
Differences are stated explicitly where applicable.
Please note:
Configuration parameter default values are listed in section Port default con-
figuration parameters (on page 131).
Syntax:cd /unit-x/port-a/cfgm
Syntax:set PortMode <Mode>
Syntax:get PortMode
Syntax:set Redundancy <PortDownForStandby>
Syntax:get Redundancy
Syntax:set PortVlan <EnablePortVlan> <VlanId> <CoS>
Syntax:get PortVlan
Syntax:set MTUSize <MTUSize>
Syntax:get MTUSize
Please note:
The list of service units that are managed via the GbE star (inband manage-
ment) can be found in section 4.1.1 of the [201] System Description “Mile-
Gate R3B”.
Please note:
The “Redundancy” property in the above dialogue provides you with the
means to prevent loops even with RSTP not being activated. While RSTP is
a good measure for loop prevention, the “Redundancy” property sets the
Ethernet front port of the core unit that is in the standby mode to “down” and
hence allows you to connect both core units to a remote equipment. With
RSTP switched off, this only works if you have just one port per core unit
connected to the remote equipment. Having activated (i.e. administrative
state set to “Up”) more than one front port per core unit absolutely requires
RSTP to be configured on both the two core units and the remote equipment
if more than one front port per core unit is connected to the same remote
equipment.
Please note:
For an overview on the specific characteristics of trunk ports, service ports,
management ports and mirror ports, please refer to section Interfaces (on
page 57).
Syntax:cd /unit-x/port-a/cfgm
Syntax:set Rstp <RstpEnabled>
Syntax:get Rstp
Syntax:set RstpParams <PortCost> <PortPriority>
<DynamicPathCostEnabled>
Syntax:get RstpParams
Please note:
The list of service units that are managed via the GbE star (inband manage-
ment) can be found in section 4.1.1 of the [201] System Description “Mile-
Gate R3B”.
Please note:
In order to prevent loops, we strongly recommend to activate RSTP, i.e. to
set the parameter “RSTP Enabled” to “” in the MCST GUI, or to set the
parameter “RstpEnabled” to “true” in the CLI. Please also activate RSTP on
the remote equipment connected to the COGE1 front port(s) in this case,
and carefully read and follow the instructions in section Commissioning
RSTP (on page 80).
Please note:
In case of a broadcast storm that is occurring due to a loop, you may need to
connect locally to your MileGate and enable RSTP on the ports causing the
loop, or to interrupt one of the Ethernet links causing the loop, by unplugging
the Ethernet cable or fibre. After the loop has been broken, you may recon-
nect to your MileGate and enable RSTP, then re-connect the cabling.
Syntax:cd /unit-x/port-a/cfgm
Syntax:get ManagementVlan
Syntax:set ListType <Type>
Syntax:get ListType
Syntax:set VlanList {<RangeStart> <RangeEnd>;}
Syntax:get VlanList
Syntax:FlushVlanList
Please note:
To remove several entries from the VLAN Blacklist or Whitelist, press and
hold the left-hand mouse button while selecting entries in the table, then click
“Remove”.
Please note:
In order to lower the risk of blocked VLANs, the VLAN list should not be con-
figured on a port configured as “Management Port”.
→ If you configure the VLAN list on a management port, make sure you
do not blacklist the management VLAN ID configured for the network
element, or, if using the whitelist, make sure to add the management
VLAN ID to the whitelist.
The entry range is checked, i.e. if you enter a range with the range end that
is smaller than the range start and apply the list, an error message “Range
check of VLAN IDs: Start and/or end of range are not valid.” is issued (GUI
only).
If you enter a range that is overlapping with an already existing range and
apply the list, an error message “Range check of VLAN IDs: Start and/or end
of range are interfering with other ranges.” is issued (GUI only).
Please note:
In the CLI, no such error messages are issued since the CLI only allows
entering a full list, but not adding, modifying, or removing entries from the
list; i.e. in the CLI, you always have to enter the full new VLAN list if you
want to make changes to the VLAN list.
For possible error messages refer to section AP: / unit-x / port-a, Configuration –
VLAN list, Add… (on page 144) above.
The QoS dialogue allows you to assign a scheduling profile to the port.
In order to select a specific scheduling profile, you need to create that profile
in the Profile Tool, and download it to the MileGate or you need to create
that profile on the NE. Please refer to section Scheduling profiles (on
page 99) above.
Once the scheduling profile is created and downloaded to the NE, you can
select it and apply it to a port:
Syntax:cd /unit-x/port-a/cfgm
Syntax:set SchedulingProfileName <Name>
Syntax:get SchedulingProfileName
The preview dialogue shows the settings in the scheduling profile. This infor-
mation is displayed read-only.
Syntax:cd /unit-x/port-a/cfgm
Syntax:set EnableIgmpClassifier <EnableIgmp>
Syntax:get EnableIgmpClassifier
Syntax:set AllowStaticStreams <AllowStaticStreams>
Syntax:get AllowStaticStreams
Syntax:set MulticastPortMode <MulticastPortMode>
Syntax:get MulticastPortMode
Syntax:cd /unit-x/port-a/cfgm
Syntax:set LinkAggregation <LagMember> <LacpEnabled>
Syntax:get LinkAggregation
Please note:
The list of service units that are managed via the GbE star (inband manage-
ment) can be found in section 4.1.1 of the [201] System Description “Mile-
Gate R3B”.
Please note:
For enabling Link Aggregation on a port you need to set its port mode to
“VLAN Trunk Port” or “Service Port” before activating LA on that port. For
more information on the port mode, please refer to section AP: / unit-x / port-
a, Configuration – Port Mode (on page 136).
Please note:
Make sure that the RSTP mode (“RSTP Enabled” in the GUI, or RstpEna-
bled” in the CLI) and the RSTP port cost, port priority and dynamic path cost
enabled parameters are identical on all ports that shall be member of a spe-
cific LAG instance before activating LA on that port.
Please note:
Make sure that the VLAN settings are identical on all ports that shall be
member of a specific LAG instance. This includes the settings for the List
Type and the VLAN ranges entered into the VLAN List. For more information
on VLAN list settings, please refer to section AP: / unit-x / port-a, Configura-
tion – VLAN list (on page 142).
Please note:
Make sure that the selected scheduling profile is identical on all ports that
shall be member of a specific LAG instance before activating LA on that port.
For more information on setting a scheduling profile, refer to section AP: /
unit-x / port-a, Configuration – QoS (on page 144).
Please note:
Make sure that the multicast settings are identical on all ports that shall be
member of a specific LAG instance. For more information on configuring the
port multicast settings, refer to section AP: / unit-x / port-a, Configuration –
Multicast (on page 146).
Please note:
When moving a port from one LAG instance to another LAG instance the
port LAG member configuration must first be set to “None” before the port
can become a member of the other LAG instance.
The following figure illustrates an example on how COGE1 ports can be
associated with link aggregation groups (LAGs).
port-5
port-4 lag-1
port-3
lag-2
port-2
port-1 lag-3
slot-13
LAGs represent logical ports that replace the individual ports for the pur-
poses of RSTP, VLAN bridging, etc. Once a port becomes a member of a
LAG it will not participate as an individual port in RSTP or VLAN bridging.
A port that is a member of a LAG can become an:
• active member: if the link is up and all remaining LACP conditions are
met. The port can be used to transfer LAGs traffic.
• inactive member: if the link is down or some LACP conditions are not
met. No traffic will pass this port and L2 protocols (RSTP, etc.) will ignore
it.
All five front ports in COGE1, the backplane ports and the redundant ports
can become members of a LAG.
Every port can be configured to be in one of the following aggregation
modes:
Ports can be associated with a LAG either as a static LAG (LACP disabled)
or a dynamic LAG (LACP enabled).
The LA working mode is configured per port as shown in the screenshot fur-
ther above.
Please note:
A LAG cannot contain members with a mixture of LACP enabled and disa-
bled. The working mode of the first member will determine the working mode
of the group. If it is required to modify the group working mode the group
must be recreated.
Please note:
All ports in a LAG must be configured with the same attributes (VLAN and
RSTP mode together with IGMP configuration). MileGate (via the MCST GUI
or via the CLI) will not allow LAG members to come together if the previous
conditions are not met.
The following physical link conditions are enforced:
This dialogue allows you to select the physical operation mode for the Ether-
net port.
Syntax:cd /unit-x/port-a/cfgm
Syntax:set PhyMode <SpeedAndDuplex>
Syntax:get PhyMode
Syntax:set PhyFlowControl <PhyFlowControl>
Syntax:get PhyFlowControl
Please note:
SFP modules only support the “Speed 1000 Full Duplex” mode.
Electrical Ethernet interfaces of the front ports support the whole range of
modes. The 1000 Mbit/s, full duplex mode can be obtained via the speed
and duplex selection “Autonegotiation On” if the remote end also supports
1000 Mbit/s.
Please note:
Electrical Ethernet interfaces of the backplane and redundant ports only sup-
port the 1000 Mbit/s, full duplex mode.
→ This mode can be obtained via the speed and duplex selection “Auto-
discovery”, “Autonegotiation On” or “Speed1000 Full Duplex”.
Syntax:cd /unit-x/port-a/cfgm
Please note:
For more information about Ethernet operation, administration, and mainte-
nance (EOAM), please refer to "[316] User Guide “Ethernet OAM”".
Syntax:cd /unit-x/port-a/cfgm
Syntax:set DSCPTo802Dot1qTxPriorityMapping
<DSCPTo802Dot1qTxPriorityMappingEnabled>
Syntax:get DSCPTo802Dot1qTxPriorityMapping
Syntax:cd /unit-x/port-a/status
Syntax:set MirrorPortList {<port> <mode>;}
Syntax:get MirrorPortList
Please note:
In the CLI, the commands “Add…”, “Modify…”, and “Remove” are not sup-
ported. Instead of using these commands, the port table can be configured
or modified by using the CLI command syntax given above. The whole set of
ports and modes has to be entered every time you want to configure or mod-
ify the port table.
The PM parameters are presented in different groups. For the general view
on a PM dialogue of the MCST GUI, refer to "[304] User Guide “MileGate &
MCST”". The following three basic PM properties appear in every PM dia-
logue:
• Status
• Timestamp
• Elapsed Time
Also, in each of the PM dialogues, the following counter intervals are availa-
ble:
• User Counter
• History 15min
• History 24h
The following counter groups are available for COGE1 front ports, backplane
ports and redundant ports:
• “MCAST Port Statistics” group, see section PM group: MCAST Port Sta-
tistics (on page 157),
• “RMON Ethernet Statistics” group, see section PM group: RMON Ether-
net Statistic (on page 157),
• “MISC Ethernet Statistics” group, see section PM group: MISC Ethernet
Statistic (on page 157),
• “Link Agg. LACP Port” group, see section PM group: Link Agg. LACP
Port (on page 158).
• “MIB-2 Interface Table” group, see section PM group: MIB-2 Interface
Table (on page 158),
• “IF-MIB IfXTable” group, see section PM group: IF-MIB IfXTable (on
page 158).
Please note:
Performance alarm thresholds are not implemented in this release.
Please note:
Performance monitoring intervals are marked as “invalid” while the port’s
administrative state is “down”.
All HC counters are high capacity counters with a counter width of 64 bit.
Syntax:cd /unit-x/port-a/status
Syntax:get DefaultConfigEnabled
Syntax:cd /unit-x/port-a/status
Syntax:get PortMacStatus
Syntax:cd /unit-x/port-a/status
Syntax:get PortLinkStatus
Syntax:cd /unit-x/port-a/status
Syntax:get PortRstpStatus
This dialogue shows the Link Aggregation Operational Status of both the
Actor and the Partner. Due to the large size of the dialogue window, it is split
into three parts.
Part 1 is the “Actor Operational Status”:
Syntax:cd /unit-x/port-a/status
Syntax:get Status
Syntax:cd /unit-x/port-a/status
Syntax:get Status
Collecting Yes The collector for this link is enabled and will not
PartnerOpera- Yes be disabled unless instructed to do so (by man-
tionalSta- agement or LACP)
tus.Collectin No The collector for this link is either disabled or
g No maybe in the process of being disabled
Distributing Yes The distributor for this link is enabled or may be
PartnerOpera- Yes in the process of being enabled.
tionalSta- No The distributor for this link is disabled and will not
tus.Distribut be enabled unless instructed to do so (by man-
ing No
agement or LACP)
Defaulted Yes The device is using Partner information from
PartnerOpera- Yes received LACP messages
tionalSta- No The device is using administratively-configured
tus.Defaulted default Partner information
No
Expired Yes The device’s LACP receive state machine is in
PartnerOpera- Yes the expired state
tionalSta- No The device’s LACP receive state machine is not
tus.Expired in the expired state
No
Part 3 are some more “LA Status” properties:
Syntax:cd /unit-x/port-a/status
Syntax:get Status
The following dialogue is applicable only to the ports that can be equipped
with an SFP, i.e. “port-1” and “port-2”.
Syntax:cd /unit-x/port-a/status
Syntax:get DdmStatus
Syntax:cd /unit-x/port-a/status
Syntax:get QosStatus
Please note:
The scheduling type and weight shown in the table reflects the fact that per
default the queue 7 is reserved for the MileGate internal management traffic.
→ For further information please refer to section CoS, 802.1p (on
page 47).
Please note:
To use the queue 7 also for user traffic the standard queue mode must be
disabled at the AP: /, Configuration - QoS.
Syntax:cd /unit-x/port-a/status
Syntax:get AttachedVlans
For the Main / General dialogue, refer to "[304] User Guide “MileGate &
MCST”".
For the Main / General dialogue, refer to "[304] User Guide “MileGate &
MCST”".
Please note:
The bridge priorities have to be set with care on all equipment that provide
RSTP. You should plan your RSTP settings for the whole RSTP tree in order
to have a stable network. Remember that a lower priority number means a
higher priority, and that the root bridge should have the highest priority, i.e.
the lowest priority value. This applies to both the MileGate and the remote
equipment.