ROS v4.3 RSG2100 User-Guide EN
ROS v4.3 RSG2100 User-Guide EN
Introduction
RUGGEDCOM ROS
v4.3
User Guide
07/2016
RC1289-EN-03
RUGGEDCOM ROS
User Guide
Disclaimer Of Liability
Siemens has verified the contents of this document against the hardware and/or software described. However, deviations between the product
and the documentation may exist.
Siemens shall not be liable for any errors or omissions contained herein or for consequential damages in connection with the furnishing,
performance, or use of this material.
The information given in this document is reviewed regularly and any necessary corrections will be included in subsequent editions. We
appreciate any suggested improvements. We reserve the right to make technical improvements without notice.
Registered Trademarks
RUGGEDCOM™ and ROS™ are trademarks of Siemens Canada Ltd.
Other designations in this manual might be trademarks whose use by third parties for their own purposes would infringe the rights of the
owner.
Open Source
RUGGEDCOM ROS contains Open Source Software. For license conditions, refer to the associated License Conditions document.
Security Information
Siemens provides products and solutions with industrial security functions that support the secure operation of plants, machines, equipment
and/or networks. They are important components in a holistic industrial security concept. With this in mind, Siemens' products and solutions
undergo continuous development. Siemens recommends strongly that you regularly check for product updates.
For the secure operation of Siemens products and solutions, it is necessary to take suitable preventive action (e.g. cell protection concept) and
integrate each component into a holistic, state-of-the-art industrial security concept. Third-party products that may be in use should also be
considered. For more information about industrial security, visit http://www.siemens.com/industrialsecurity .
To stay informed about product updates as they occur, sign up for a product-specific newsletter. For more information, visit http://
support.automation.siemens.com .
Warranty
Refer to the License Agreement for the applicable warranty terms and conditions, if any.
For warranty details, visit www.siemens.com/ruggedcom or contact a Siemens customer service representative.
2
RUGGEDCOM ROS
User Guide
Contacting Siemens
Address
Telephone E-mail
3
RUGGEDCOM ROS
User Guide
4
RUGGEDCOM ROS
User Guide Table of Contents
Table of Contents
Preface...........................................................................................................................................................................xiii
Conventions.................................................................................................................................................. xiii
Related Documents..................................................................................................................................................xiv
System Requirements...................................................................................................................................xiv
Accessing Documentation............................................................................................................................xiv
Training..........................................................................................................................................................xv
Customer Support.........................................................................................................................................xv
Chapter 1
Introduction..................................................................................................................................................... 1
1.1 Features and Benefits............................................................................................................................. 1
1.2 Security Recommendations and Considerations.....................................................................................3
1.2.1 Security Recommendations.........................................................................................................3
1.2.2 Credential Files............................................................................................................................5
1.2.2.1 SSL Certificates.................................................................................................................6
1.2.2.2 SSH Key Pairs................................................................................................................... 8
1.3 Supported Networking Standards...........................................................................................................9
1.4 Port Numbering Scheme.........................................................................................................................9
1.5 Available Services by Port................................................................................................................................10
1.6 SNMP Management Interface Base (MIB) Support.........................................................................................12
1.6.1 Supported Standard MIBs....................................................................................................................12
1.6.2 Supported Proprietary RUGGEDCOM MIBs........................................................................................13
1.6.3 Supported Agent Capabilities....................................................................................................13
1.7 SNMP Traps.......................................................................................................................................................14
1.8 ModBus Management Support........................................................................................................................15
1.8.1 ModBus Function Codes............................................................................................................16
1.8.2 ModBus Memory Map.........................................................................................................................17
1.8.3 ModBus Memory Formats...................................................................................................................22
1.8.3.1 Text................................................................................................................................ 22
1.8.3.2 Cmd................................................................................................................................23
1.8.3.3 Uint16.............................................................................................................................23
1.8.3.4 Uint32.............................................................................................................................23
1.8.3.5 PortCmd.........................................................................................................................23
1.8.3.6 Alarm..............................................................................................................................24
1.8.3.7 PSStatusCmd..................................................................................................................25
5
RUGGEDCOM ROS
Table of Contents User Guide
1.8.3.8 TruthValues....................................................................................................................25
1.9 SSH and SSL Keys and Certificates........................................................................................................26
1.9.1 Certificate and Keys Life Cycle...................................................................................................26
1.9.2 Certificate and Key Requirements.............................................................................................27
Chapter 2
Using ROS....................................................................................................................................................... 29
2.1 Connecting to ROS................................................................................................................................29
2.1.1 Connecting Directly....................................................................................................................29
2.1.2 Connecting via the Network......................................................................................................30
2.2 Logging In..............................................................................................................................................31
2.3 Logging Out........................................................................................................................................... 32
2.4 Using the Web Interface..................................................................................................................................33
2.5 Using the Console Interface..................................................................................................................34
2.6 Using the Command Line Interface.......................................................................................................36
2.6.1 Available CLI Commands............................................................................................................36
2.6.2 Tracing Events............................................................................................................................39
2.6.3 Executing Commands Remotely via RSH...................................................................................40
2.6.4 Using SQL Commands................................................................................................................40
2.6.4.1 Finding the Correct Table..............................................................................................41
2.6.4.2 Retrieving Information...................................................................................................41
2.6.4.3 Changing Values in a Table............................................................................................43
2.6.4.4 Resetting a Table.....................................................................................................................44
2.6.4.5 Using RSH and SQL........................................................................................................44
2.7 Selecting Ports in RUGGEDCOM ROS..............................................................................................................44
2.8 Managing the Flash File System............................................................................................................45
2.8.1 Viewing a List of Flash Files.......................................................................................................45
2.8.2 Viewing Flash File Details..........................................................................................................45
2.8.3 Defragmenting the Flash File System........................................................................................46
2.9 Accessing BIST Mode.............................................................................................................................46
2.10 Managing SSH Public Keys..................................................................................................................47
2.10.1 Adding a Public Key.................................................................................................................47
2.10.2 Viewing a List of Public Keys...................................................................................................49
2.10.3 Updating a Public Key..............................................................................................................49
2.10.4 Deleting a Public Key...............................................................................................................50
Chapter 3
Device Management................................................................................................................................ 51
3.1 Viewing Product Information................................................................................................................51
3.2 Viewing CPU Diagnostics.......................................................................................................................53
3.3 Restoring Factory Defaults...............................................................................................................................54
6
RUGGEDCOM ROS
User Guide Table of Contents
3.4 Uploading/Downloading Files................................................................................................................55
3.4.1 Uploading/Downloading Files Using XMODEM.........................................................................56
3.4.2 Uploading/Downloading Files Using a TFTP Client....................................................................57
3.4.3 Uploading/Downloading Files Using a TFTP Server...................................................................58
3.4.4 Uploading/Downloading Files Using an SFTP Server.................................................................58
3.5 Managing Logs...................................................................................................................................... 59
3.5.1 Viewing Local Logs.....................................................................................................................59
3.5.2 Clearing Local Logs....................................................................................................................60
3.5.3 Configuring the Local System Log..............................................................................................60
3.5.4 Managing Remote Logging........................................................................................................61
3.5.4.1 Configuring the Remote Syslog Client............................................................................61
3.5.4.2 Viewing a List of Remote Syslog Servers........................................................................62
3.5.4.3 Adding a Remote Syslog Server.....................................................................................63
3.5.4.4 Deleting a Remote Syslog Server...................................................................................64
3.6 Managing Ethernet Ports...................................................................................................................... 65
3.6.1 Controller Protection Through Link Fault Indication (LFI)..........................................................66
3.6.2 Viewing the Status of Ethernet Ports..................................................................................................67
3.6.3 Viewing Statistics for All Ethernet Ports.............................................................................................68
3.6.4 Viewing Statistics for Specific Ethernet Ports.....................................................................................68
3.6.5 Clearing Statistics for Specific Ethernet Ports.....................................................................................71
3.6.6 Managing SFP Transceivers.......................................................................................................72
3.6.6.1 Configuring an SFP Port.................................................................................................72
3.6.6.2 Monitoring an SFP Port...........................................................................................................72
3.6.6.3 Displaying Information for an SFP Port..................................................................................73
3.6.7 Configuring a PoE Port (For RSG2100P Only)............................................................................74
3.6.8 Configuring an Ethernet Port.....................................................................................................75
3.6.9 Configuring Port Rate Limiting...................................................................................................78
3.6.10 Configuring Port Mirroring......................................................................................................80
3.6.11 Configuring Link Detection......................................................................................................81
3.6.12 Detecting Cable Faults.............................................................................................................82
3.6.12.1 Viewing Cable Diagnostics Results...............................................................................83
3.6.12.2 Performing Cable Diagnostics......................................................................................85
3.6.12.3 Clearing Cable Diagnostics...........................................................................................86
3.6.12.4 Determining the Estimated Distance To Fault (DTF)....................................................87
3.6.13 Resetting Ethernet Ports....................................................................................................................87
3.7 Managing IP Interfaces.....................................................................................................................................88
3.7.1 Viewing a List of IP Interfaces.............................................................................................................88
3.7.2 Adding an IP Interface.........................................................................................................................89
3.7.3 Deleting an IP Interface.......................................................................................................................91
3.8 Managing IP Gateways.....................................................................................................................................92
7
RUGGEDCOM ROS
Table of Contents User Guide
3.8.2 Adding an IP Gateway..........................................................................................................................93
3.8.3 Deleting an IP Gateway.......................................................................................................................94
3.9 Configuring IP Services..........................................................................................................................95
3.10 Managing Remote Monitoring............................................................................................................97
3.10.1 Managing RMON History Controls..........................................................................................98
3.10.1.1 Viewing a List of RMON History Controls.............................................................................98
3.10.1.2 Adding an RMON History Control.........................................................................................98
3.10.1.3 Deleting an RMON History Control............................................................................100
3.10.2 Managing RMON Alarms.......................................................................................................101
3.10.2.1 Viewing a List of RMON Alarms.................................................................................102
3.10.2.2 Adding an RMON Alarm.............................................................................................103
3.10.2.3 Deleting an RMON Alarm...........................................................................................105
3.10.3 Managing RMON Events........................................................................................................106
3.10.3.1 Viewing a List of RMON Events..................................................................................107
3.10.3.2 Adding an RMON Event.............................................................................................107
3.10.3.3 Deleting an RMON Event...........................................................................................109
3.11 Upgrading/Downgrading Firmware...................................................................................................109
3.11.1 Upgrading Firmware..............................................................................................................110
3.11.2 Downgrading Firmware.........................................................................................................110
3.12 Resetting the Device.....................................................................................................................................111
3.13 Decommissioning the Device............................................................................................................112
Chapter 4
System Administration..........................................................................................................................115
4.1 Configuring the System Information...................................................................................................115
4.2 Customizing the Login Screen.............................................................................................................116
4.3 Configuring Passwords........................................................................................................................116
4.4 Clearing Private Data...........................................................................................................................119
4.5 Enabling/Disabling the Web Interface...........................................................................................................120
4.6 Managing Alarms................................................................................................................................120
4.6.1 Viewing a List of Pre-Configured Alarms.................................................................................121
4.6.2 Viewing and Clearing Latched Alarms.....................................................................................122
4.6.3 Configuring an Alarm...............................................................................................................122
4.6.4 Authentication Related Security Alarms...........................................................................................125
4.6.4.1 Security Alarms for Login Authentication....................................................................125
4.6.4.2 Security Messages for Port Authentication..........................................................................127
4.7 Managing the Configuration File.........................................................................................................128
4.7.1 Configuring Data Encryption....................................................................................................128
4.7.2 Updating the Configuration File..............................................................................................130
4.8 Managing an Authentication Server....................................................................................................130
8
RUGGEDCOM ROS
User Guide Table of Contents
4.8.1.1 Configuring the RADIUS Server....................................................................................132
4.8.1.2 Configuring the RADIUS Client.....................................................................................132
4.8.2 Managing TACACS+ Authentication.........................................................................................134
4.8.2.1 Configuring TACACS+...................................................................................................134
4.8.2.2 Configuring User Privileges..........................................................................................135
Chapter 5
Setup and Configuration......................................................................................................................137
5.1 Managing Virtual LANs........................................................................................................................137
5.1.1 VLAN Concepts........................................................................................................................138
5.1.1.1 Tagged vs. Untagged Frames.......................................................................................138
5.1.1.2 Native VLAN.................................................................................................................139
5.1.1.3 The Management VLAN...............................................................................................139
5.1.1.4 Edge and Trunk Port Types...................................................................................................139
5.1.1.5 Ingress and Egress Rules..............................................................................................140
5.1.1.6 Forbidden Ports List...............................................................................................................140
5.1.1.7 VLAN-Aware and VLAN-Unaware Modes.............................................................................140
5.1.1.8 GARP VLAN Registration Protocol (GVRP)............................................................................141
5.1.1.9 PVLAN Edge..................................................................................................................143
5.1.1.10 QinQ...........................................................................................................................143
5.1.1.11 VLAN Advantages.......................................................................................................144
5.1.2 Viewing a List of VLANs...........................................................................................................146
5.1.3 Configuring VLANs Globally.....................................................................................................146
5.1.4 Configuring VLANs for Specific Ethernet Ports........................................................................148
5.1.5 Managing Static VLANs............................................................................................................150
5.1.5.1 Viewing a List of Static VLANs......................................................................................150
5.1.5.2 Adding a Static VLAN...................................................................................................150
5.1.5.3 Deleting a Static VLAN.................................................................................................152
5.2 Managing Spanning Tree Protocol......................................................................................................153
5.2.1 RSTP Operation..................................................................................................................................154
5.2.1.1 RSTP States and Roles...........................................................................................................155
5.2.1.2 Edge Ports....................................................................................................................156
5.2.1.3 Point-to-Point and Multipoint Links......................................................................................157
5.2.1.4 Path and Port Costs...............................................................................................................157
5.2.1.5 Bridge Diameter...........................................................................................................158
5.2.1.6 eRSTP......................................................................................................................................158
5.2.1.7 Fast Root Failover..................................................................................................................159
5.2.2 RSTP Applications...............................................................................................................................159
5.2.2.1 RSTP in Structured Wiring Configurations....................................................................160
5.2.2.2 RSTP in Ring Backbone Configurations.........................................................................161
9
RUGGEDCOM ROS
Table of Contents User Guide
5.2.3 MSTP Operation.................................................................................................................................163
5.2.3.1 MSTP Regions and Interoperability.......................................................................................164
5.2.3.2 MSTP Bridge and Port Roles.................................................................................................165
5.2.3.3 Benefits of MSTP...................................................................................................................166
5.2.3.4 Implementing MSTP on a Bridged Network.................................................................167
5.2.4 Configuring STP Globally..........................................................................................................168
5.2.5 Configuring STP for Specific Ethernet Ports.............................................................................169
5.2.6 Configuring eRSTP....................................................................................................................172
5.2.7 Viewing Global Statistics for STP.......................................................................................................174
5.2.8 Viewing STP Statistics for Ethernet Ports..........................................................................................176
5.2.9 Managing Multiple Spanning Tree Instances...........................................................................178
5.2.9.1 Viewing Statistics for Global MSTIs......................................................................................178
5.2.9.2 Viewing Statistics for Port MSTIs..........................................................................................180
5.2.9.3 Configuring the MST Region Identifier.........................................................................181
5.2.9.4 Configuring a Global MSTI...........................................................................................182
5.2.9.5 Configuring an MSTI for an Ethernet Port....................................................................183
5.2.10 Clearing Spanning Tree Protocol Statistics............................................................................185
5.3 Managing Classes of Service...............................................................................................................185
5.3.1 Configuring Classes of Service Globally...................................................................................186
5.3.2 Configuring Classes of Service for Specific Ethernet Ports.......................................................187
5.3.3 Configuring Priority to CoS Mapping.......................................................................................189
5.3.4 Configuring DSCP to CoS Mapping..........................................................................................190
5.4 Managing MAC Addresses...................................................................................................................191
5.4.1 Viewing a List of MAC Addresses......................................................................................................192
5.4.2 Configuring MAC Address Learning Options............................................................................193
5.4.3 Configuring MAC Address Flooding Options............................................................................193
5.4.4 Managing Static MAC Addresses.............................................................................................195
5.4.4.1 Viewing a List of Static MAC Addresses...............................................................................195
5.4.4.2 Adding a Static MAC Address...............................................................................................195
5.4.4.3 Deleting a Static MAC Address....................................................................................197
5.4.5 Purging All Dynamic MAC Addresses................................................................................................198
5.5 Managing Time Services......................................................................................................................198
5.5.1 Configuring the Time and Date...............................................................................................199
5.5.2 Managing NTP.........................................................................................................................200
5.5.2.1 Enabling/Disabling NTP Service.............................................................................................200
5.5.2.2 Configuring NTP Servers...............................................................................................201
5.6 Managing SNMP..................................................................................................................................202
5.6.1 Managing SNMP Users............................................................................................................203
5.6.1.1 Viewing a List of SNMP Users......................................................................................203
1
0
RUGGEDCOM ROS
User Guide Table of Contents
5.6.2 Managing Security-to-Group Mapping....................................................................................208
5.6.2.1 Viewing a List of Security-to-Group Maps............................................................................208
5.6.2.2 Adding a Security-to-Group Map..........................................................................................208
5.6.2.3 Deleting a Security-to-Group Map........................................................................................210
5.6.3 Managing SNMP Groups..........................................................................................................210
5.6.3.1 Viewing a List of SNMP Groups...................................................................................211
5.6.3.2 Adding an SNMP Group...............................................................................................211
5.6.3.3 Deleting an SNMP Group.............................................................................................213
5.7 Managing Network Discovery.............................................................................................................214
5.7.1 Network Discovery Concepts.............................................................................................................214
5.7.1.1 Link Layer Discovery Protocol (LLDP)....................................................................................214
5.7.1.2 RUGGEDCOM Discovery Protocol (RCDP)............................................................................215
5.7.2 Configuring LLDP Globally........................................................................................................215
5.7.3 Configuring LLDP for an Ethernet Port....................................................................................217
5.7.4 Enabling/Disabling RCDP....................................................................................................................218
5.7.5 Viewing Global Statistics and Advertised System Information.................................................219
5.7.6 Viewing Statistics for LLDP Neighbors.....................................................................................220
5.7.7 Viewing Statistics for LLDP Ports.......................................................................................................221
5.8 Managing Multicast Filtering...............................................................................................................222
5.8.1 Managing IGMP.......................................................................................................................222
5.8.1.1 IGMP Concepts......................................................................................................................222
5.8.1.2 Viewing a List of Multicast Group Memberships.................................................................226
5.8.1.3 Viewing Forwarding Information for Multicast Groups.......................................................227
5.8.1.4 Configuring IGMP.........................................................................................................228
5.8.2 Managing GMRP......................................................................................................................229
5.8.2.1 GMRP Concepts.....................................................................................................................230
5.8.2.2 Viewing a Summary of Multicast Groups.....................................................................232
5.8.2.3 Configuring GMRP Globally..........................................................................................232
5.8.2.4 Configuring GMRP for Specific Ethernet Ports.............................................................233
5.8.2.5 Viewing a List of Static Multicast Groups.....................................................................235
5.8.2.6 Adding a Static Multicast Group...........................................................................................235
5.8.2.7 Deleting a Static Multicast Group................................................................................236
5.9 Managing DHCP...................................................................................................................................237
5.9.1 DHCP Concepts........................................................................................................................238
5.9.1.1 DHCP Snooping............................................................................................................238
5.9.1.2 Trusted and Untrusted Ports................................................................................................238
5.9.1.3 DHCP Binding Table.....................................................................................................239
5.9.1.4 DHCP Relay Agent (Option 82).....................................................................................239
1
1
RUGGEDCOM ROS
Table of Contents User Guide
5.9.4 Configuring DHCP Port Parameters.........................................................................................243
5.9.5 Configuring the Static DHCP Binding Table..............................................................................244
5.9.6 Viewing the DHCP Binding Table.............................................................................................246
5.9.7 Saving the Static DHCP Binding Table......................................................................................247
5.10 Managing Port Security.....................................................................................................................247
5.10.1 Port Security Concepts....................................................................................................................248
5.10.1.1 Static MAC Address-Based Authentication.........................................................................248
5.10.1.2 IEEE 802.1x Authentication........................................................................................248
5.10.1.3 IEEE 802.1X Authentication with MAC Address-Based Authentication.............................249
5.10.1.4 Assigning VLANS with Tunnel Attributes....................................................................250
5.10.2 Viewing a List of Authorized MAC Addresses.................................................................................250
5.10.3 Configuring Port Security.......................................................................................................251
5.10.4 Configuring IEEE 802.1X.........................................................................................................253
5.11 Managing Link Aggregation...............................................................................................................255
5.11.1 Link Aggregation Concepts....................................................................................................256
5.11.1.1 Rules and Limitations.................................................................................................257
5.11.1.2 Link Aggregation and Layer 2 Features......................................................................257
5.11.1.3 Link Aggregation and Physical Layer Features...........................................................258
5.11.2 Managing Port Trunks...........................................................................................................258
5.11.2.1 Viewing a List of Port Trunks.....................................................................................258
5.11.2.2 Adding a Port Trunk...................................................................................................259
5.11.2.3 Deleting a Port Trunk.................................................................................................260
Chapter 6
Troubleshooting........................................................................................................................................263
6.1 General................................................................................................................................................263
6.2 Ethernet Ports.................................................................................................................................................264
6.3 Spanning Tree......................................................................................................................................264
6.4 VLANs.................................................................................................................................................. 265
1
2
RUGGEDCOM ROS
User Guide Preface
Preface
This guide describes v4.3 of ROS (Rugged Operating System) running on the RUGGEDCOM RSG2100/RSG2100P/
M2100. It contains instructions and guidelines on how to use the software, as well as some general theory.
It is intended for use by network technical support personnel who are familiar with the operation of networks. It is
also recommended for use by network and system planners, system programmers, and line technicians.
IMPORTANT!
Some of the parameters and options described may not be available depending on variations in the device hardware. While every attem
Conventions
This User Guide uses the following conventions to present information clearly and effectively.
Alerts
The following types of alerts are used when necessary to highlight important information.
DANGER!
DANGER alerts describe imminently hazardous situations that, if not avoided, will result in death or serious injury.
WARNING!
WARNING alerts describe hazardous situations that, if not avoided, may result in serious injury and/or equipment damage.
CAUTION!
CAUTION alerts describe hazardous situations that, if not avoided, may result in equipment damage.
IMPORTANT!
IMPORTANT alerts provide important information that should be known before performing a procedure or step, or using a feature.
NOTE
NOTE alerts provide additional information, such as facts, tips and details.
Conventions xiii
RUGGEDCOM ROS
Preface User Guide
Example Description
command parameter1 parameter2 Parameters are listed in the order they must be entered.
command parameter1 parameter2 Parameters in italics must be replaced with a user-defined value.
command [ parameter1 | parameter2 ] Alternative parameters are separated by a vertical bar (|).
Square brackets indicate a required choice between two or more
parameters.
Related Documents
Other documents that may be of interest include:
• RUGGEDCOM RSG2100 Installation Guide
• RUGGEDCOM RSG2100P Installation Guide
• RUGGEDCOM M2100 Installation Guide
System Requirements
Each workstation used to connect to the RUGGEDCOM ROS interface must meet the following system
requirements:
• Must have one of the following Web browsers installed:
▫ Microsoft Internet Explorer 8.0 or higher
▫ Mozilla Firefox
▫ Google Chrome
▫ Iceweasel/IceCat (Linux Only)
• Must have a working Ethernet interface compatible with at least one of the port types on the RUGGEDCOM
device
• The ability to configure an IP address and netmask on the computer’s Ethernet interface
Accessing Documentation
The latest user documentation for RUGGEDCOM ROS v4.3 is available online at www.siemens.com/ruggedcom. To
request or inquire about a user document, contact Siemens Customer Support.
Training
Siemens offers a wide range of educational services ranging from in-house training of standard courses on
networking, Ethernet switches and routers, to on-site customized courses tailored to the customer's needs,
experience and application.
Siemens' Educational Services team thrives on providing our customers with the essential practical skills to make
sure users have the right knowledge and expertise to understand the various technologies associated with critical
communications network infrastructure technologies.
Siemens' unique mix of IT/Telecommunications expertise combined with domain knowledge in the utility,
transportation and industrial markets, allows Siemens to provide training specific to the customer's application.
For more information about training services and course availability, visit www.siemens.com/ruggedcom or
contact a Siemens Sales representative.
Customer Support
Customer support is available 24 hours, 7 days a week for all Siemens customers. For technical support or
general information, contact Siemens Customer Support through any of the following methods:
Online
Visit http://www.siemens.com/automation/support-request to submit a Support Request (SR) or check
on the status of an existing SR.
Telephone
Call a local hotline center to submit a Support Request (SR). To locate a local hotline center, visit http://
www.automation.siemens.com/mcms/aspa-db/en/automation-technology/Pages/default.aspx .
Mobile App
Install the Industry Online Support app by Siemens AG on any Android, Apple iOS or Windows mobile
device and be able to:
• Access Siemens' extensive library of support documentation, including FAQs and manuals
• Submit SRs or check on the status of an existing SR
• Contact a local Siemens representative from Sales, Technical Support, Training, etc.
• Ask questions or share knowledge with fellow Siemens customers and the support community
Training xv
RUGGEDCOM ROS
User Guide Preface
Introduction
Welcome to the RUGGEDCOM ROS v4.3 Software User Guide for the RSG2100. This Guide describes the wide array
of carrier grade features made available by ROS (Rugged Operating System).
CONTENTS
• Section 1.1, “Features and Benefits”
• Section 1.2, “Security Recommendations and Considerations”
• Section 1.3, “Supported Networking Standards”
• Section 1.4, “Port Numbering Scheme”
• Section 1.5, “Available Services by Port”
• Section 1.6, “SNMP Management Interface Base (MIB) Support”
• Section 1.7, “SNMP Traps”
• Section 1.8, “ModBus Management Support”
• Section 1.9, “SSH and SSL Keys and Certificates”
Section 1.1
SSH/SSL Extends capability of password protection to add encryption of passwords and data as they
cross the network
802.1Q VLAN Provides the ability to logically segregate traffic between predefined ports on switches
Section 1.2
CONTENTS
• Section 1.2.1, “Security Recommendations”
• Section 1.2.2, “Credential Files”
Section 1.2.1
Security Recommendations
To prevent unauthorized access to the device, note the following security recommendations:
Authentication
• Replace the default passwords for all user accounts and processes (where applicable) before the device is
deployed.
• Use strong passwords with high randomization (i.e. entropy), without repetition of characters. Avoid weak
passwords such as password1, 123456789, abcdefgh, and any dictionary words or proper names in any
combination. For more information about creating strong passwords, refer to the password requirements in
Section 4.3, “Configuring Passwords” .
• Make sure passwords are protected and not shared with unauthorized personnel.
• Passwords should not be re-used across different user names and systems, or after they expire.
• If RADIUS authentication is done remotely, make sure all communications are within the security perimeter or
on a secure channel.
Physical/Remote Access
• Do not connect the device to the Internet. Deploy the device only within a secure network perimeter.
• Restrict physical access to the device to only authorized personnel. A person with malicious intent could extract
critical information, such as certificates, keys, etc. (user passwords are protected by hash codes), or reprogram
the device.
• Control access to the serial console to the same degree as any physical access to the device. Access to the serial
console allows for potential access to the RUGGEDCOM ROS boot loader, which includes tools that may be used
to gain complete access to the device.
• Only enable services that will be used on the device, including physical ports. Unused physical ports could
potentially be used to gain access to the network behind the device.
• If SNMP is enabled, limit the number of IP addresses that can connect to the device and change the community
names. Also configure SNMP to raise a trap upon authentication failures. For more information, refer to
Section 5.6, “Managing SNMP” .
• Avoid using insecure services such as Telnet and TFTP, or disable them completely if possible. These services are
available for historical reasons and are disabled by default.
• Limit the number of simultaneous Web Server, Telnet and SSH sessions allowed.
• Configure remote system logging to forward all logs to a central location. For more information, refer
to Section 3.5, “Managing Logs” .
• Configuration files are provided in the CSV (comma separated values) format for ease of use. Make sure
configuration files are properly protected when they exist outside of the device. For instance, encrypt the files,
store them in a secure place, and do not transfer them via insecure communication channels.
• Management of the configuration file, certificates and keys is the responsibility of the device owner.
Consider using RSA key sizes of at least 2048 bits in length and certificates signed with SHA256 for increased
cryptographic strength. Before returning the device to Siemens for repair, make sure encryption is disabled (to
create a cleartext version of the configuration file) and replace the current certificates and keys with temporary
throwaway certificates and keys that can be destroyed upon the device's return.
• Be aware of any non-secure protocols enabled on the device. While some protocols, such as HTTPS and SSH, are
secure, others, such as Telnet and RSH, were not designed for this purpose. Appropriate safeguards against non-
secure protocols should be taken to prevent unauthorized access to the device/network.
• Configure port security features on access ports to prevent a third-party from launching various attacks that can
harm the network or device. For more information, refer to Section 5.10, “Managing Port Security” .
Hardware/Software
• Make sure the latest firmware version is installed, including all security-related patches. For the latest
information on security patches for Siemens products, visit the Industrial Security website [http://
www.industry.siemens.com/topics/global/en/industrial-security/news-alerts/Pages/alerts.aspx] or the
ProductCERT Security Advisories website [http://www.siemens.com/innovation/en/technology-focus/
siemens-cert/cert-security-advisories.htm] . Updates to Siemens Product Security Advisories can be obtained
by subscribing to the RSS feed on the Siemens ProductCERT Security Advisories website, or by following
@ProductCert on Twitter.
• Configure port security features on access ports to prevent a third-party from launching various attacks that can
harm the network or device. For more information, refer to Section 5.10, “Managing Port Security” .
4 Security Recommendations
RUGGEDCOM ROS Chapter 1
User Guide Introduction
• Enable BPDU Guard on ports where RSTP BPDUs are not expected.
• Use the latest Web browser version compatible with RUGGEDCOM ROS to make sure the most secure Transport
Layer Security (TLS) versions and ciphers available are employed. Additionally, 1/n-1 record splitting is
enabled in the latest web browser versions of Mozilla Firefox, Google Chrome and Internet Explorer, and
mitigates against attacks such as SSL/TLS Protocol Initialization Vector Implementation Information Disclosure
Vulnerability (BEAST) for Non-Controlled (NC) versions of RUGGEDCOM ROS.
• Modbus can be deactivated if not required by the user. If Modbus activation is required, then it is recommended
to follow the security recommendations outlined in this User Guide and to configure the environment according
to defense-in-depth best practices.
• Prevent access to external, untrusted Web pages while accessing the device via a Web browser. This can assist in
preventing potential security threats, such as session hijacking.
• For optimal security, use SNMPv3 whenever possible. Use strong passwords without repetitive strings ( e.g.
abc or abcabc) with this feature. For more information about creating strong passwords, refer to the
password requirements in Section 4.3, “Configuring Passwords” .
• Unless required for a particular network topology, the IP Forward setting should be set to { Disabled } to prevent
the routing of packets.
NOTE
For configuration compatibility reasons, the configured setting will not change when upgrading from RUGGEDCOM ROS versions olde
Policy
• Periodically audit the device to make sure it complies with these recommendations and/or any internal security
policies.
• Review the user documentation for other Siemens products used in coordination with device for further security
recommendations.
Section 1.2.2
Credential Files
RUGGEDCOM ROS uses security keys to establish secure remote logins (SSH) and Web access (SSL).
It is strongly recommended that a unique SSL certificate and SSH keys be created and provisioned. New
RUGGEDCOM ROS-based units from Siemens will be shipped with a unique certificate and keys preconfigured in
the ssl.crt and ssh.keys flash files.
The default and auto-generated SSL certificates are self-signed. It is recommended to use an SSL certificate that
is either signed by a trusted third-party Certificate Authority (CA) or by an organization's own CA. This technique
is described in the Siemens application note: Creating/Uploading SSH Keys and SSL Certificates to ROS Using
Windows, available from www.siemens.com/ruggedcom.
The sequence of events related to Key Management during an upgrade to RUGGEDCOM ROS v4.3 or later is as
follows:
NOTE
The auto-generation of SSH keys is not available for Non-Controlled (NC) versions of RUGGEDCOM ROS.
• On first boot, RUGGEDCOM ROS will start the SSH and SSL services using the default keys.
Credential Files 5
Chapter 1 RUGGEDCOM ROS
Introduction User Guide
• Immediately after boot, RUGGEDCOM ROS will start to generate a unique SSL certificate and SSH key pair, and
save each one to its corresponding flash file. This process may take several minutes to complete. As each one is
created, the corresponding service is immediately restarted with the new keys.
• At any time during the key generation process, custom keys can be uploaded. The custom keys will take
precedence over both the default and auto-generated keys.
• On subsequent boot, if there is a valid ssl.crt file, the default certificate will not be used for SSL. If there is
a valid ssh.keys file, the default SSH key will not be used.
• At any time, new keys may be uploaded or generated by RUGGEDCOM ROS using the sslkeygen or
sshkeygen CLI commands.
CONTENTS
• Section 1.2.2.1, “SSL Certificates”
• Section 1.2.2.2, “SSH Key Pairs”
Section 1.2.2.1
SSL Certificates
RUGGEDCOM ROS supports SSL certificates that conform to the following specifications:
• X.509 v3 digital certificate format
• PEM format
• For RUGGEDCOM ROS Controlled verions: RSA key pair, 1024, 2048 or 3072 bits; or EC 256, 384 or 521 bits
• For RUGGEDCOM ROS Non-Controlled (NC) verions: RSA key pair, 512 to 2048 bits
The RSA key pair used in the default certificate and in those generated by RUGGEDCOM ROS uses a public key of
1024 bits in length.
NOTE
RSA keys smaller than 2048 bits in length are not recommended. Support is only included here for compatibility with legacy equipm
NOTE
The default certificate and keys are common to all RUGGEDCOM ROS versions without a certificate or key files. That is why it is imp
NOTE
RSA key generation times increase depending on the key length. 1024 bit RSA keys may take several minutes to generate, whereas
The following (bash) shell script fragment uses the openssl command line utility to generate a self-signed
X.509 v3 SSL certificate with a 1024 bit RSA key suitable for use in RUGGEDCOM ROS. Note that two standard PEM
files are required: the SSL certificate and the RSA private key file. These are concatenated into the resulting
ssl.crt file, which may then be uploaded to RUGGEDCOM ROS:
# RSA key
size:
BITS=1024
6 SSL Certificates
RUGGEDCOM ROS Chapter 1
User Guide Introduction
DAYS=7305
########################################################################
# Make the self-signed SSL certificate and RSA key pair:
# Concatenate Cert and Key into a single file suitable for upload to ROS:
# Note that cert must precede the RSA key: cat ros_ssl.crt ros_ssl.key > ssl.crt
For information on creating SSL certificates for use with RUGGEDCOM ROS in a Microsoft Windows environment,
refer to the following Siemens application note: Creating/Uploading SSH Keys and SSL Certificates to ROS Using
Windows.
The following is an example of a self-signed SSL certificate generated by RUGGEDCOM ROS:
Certificat
e:
Data:
Version: 3
(0x2) Serial
Number:
ca:01:2d:c0:bf:f9:fd:f2
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=CA, ST=Ontario, L=Concord, O=RuggedCom.com, OU=RC,
CN=ROS Validity
Not Before: Dec 6 00:00:00 2012 GMT
Not After : Dec 7 00:00:00 2037 GMT
Subject: C=CA, ST=Ontario, L=Concord, O=RuggedCom.com, OU=RC,
CN=ROS Subject Public Key Info:
Public Key Algorithm:
rsaEncryption RSA Public Key:
(1024 bit)
Modulus (1024 bit):
00:83:e8:1f:02:6b:cd:34:1f:01:6d:3e:b6:d3:45:
b0:18:0a:17:ae:3d:b0:e9:c6:f2:0c:af:b1:3e:e7:
fd:f2:0e:75:8d:6a:49:ce:47:1d:70:e1:6b:1b:e2:
fa:5a:1b:10:ea:cc:51:41:aa:4e:85:7c:01:ea:c3:
1e:9e:98:2a:a9:62:48:d5:27:1e:d3:18:cc:27:7e:
a0:94:29:db:02:5a:e4:03:51:16:03:3a:be:57:7d:
3b:d1:75:47:84:af:b9:81:43:ab:90:fd:6d:08:d3:
e8:5b:80:c5:ca:29:d8:45:58:5f:e4:a3:ed:9f:67:
44:0f:1a:41:c9:d7:62:7f:3f
Exponent: 65537
(0x10001) X509v3 extensions:
X509v3 Subject Key Identifier:
SSL Certificates 7
Chapter 1 RUGGEDCOM ROS
Introduction User Guide
DirName:/C=CA/ST=Ontario/L=Concord/O=RuggedCom.com/OU=RC/CN=ROS
serial:CA:01:2D:C0:BF:F9:FD:F2
X509v3 Basic
Constraints:
CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
64:cf:68:6e:9f:19:63:0e:70:49:a6:b2:fd:09:15:6f:96:1d:
4a:7a:52:c3:46:51:06:83:7f:02:8e:42:b2:dd:21:d2:e9:07:
5c:c4:4c:ca:c5:a9:10:49:ba:d4:28:fd:fc:9d:a9:0b:3f:a7:
84:81:37:ca:57:aa:0c:18:3f:c1:b2:45:2a:ed:ad:dd:7f:ad:
00:04:76:1c:f8:d9:c9:5c:67:9e:dd:0e:4f:e5:e3:21:8b:0b:
37:39:8b:01:aa:ca:30:0c:f1:1e:55:7c:9c:1b:43:ae:4f:cd:
e4:69:78:25:5a:a5:f8:98:49:33:39:e3:15:79:44:37:52:da:
Section 1.2.2.2
SSH Key Pairs
Controlled versions of RUGGEDCOM ROS support SSH public/private key pairs that conform to the following
specifications:
• PEM format
• DSA key pair, 1024, 2048 or 3072 bits in length; or RSA 1024, 2048 or 3072 bits in length
The DSA key pair used in the default key pair and in those generated by RUGGEDCOM ROS uses a public key of
1024 bits in length.
NOTE
DSA or RSA keys smaller than 2048 bits in length are not recommended, and support is only included here for compatibility with le
NOTE
DSA/RSA key generation times increase depending on the key length. 1024 bit RSA keys may take several minutes to generate, whe
The following (bash) shell script fragment uses the ssh-keygen command line utility to generate a 1024 bit
DSA key suitable for use in RUGGEDCOM ROS. The resulting ssh.keys file, which may then be uploaded to
RUGGEDCOM ROS:
# DSA key
size:
BITS=1024
Private-Key: (1024
bit) priv:
00:b2:d3:9d:fa:56:99:a5:7a:ba:1e:91:c5:e1:35:
77:85:e8:c5:28:36
pub:
6f:f3:9e:af:e6:d6:fd:51:51:b9:fa:d5:f9:0a:b7:
ef:fc:d7:7c:14:59:52:48:52:a6:55:65:b7:cb:38:
2e:84:76:a3:83:62:d0:83:c5:14:b2:6d:7f:cc:f4:
b0:61:0d:12:6d:0f:5a:38:02:67:a4:b7:36:1d:49:
0a:d2:58:e2:ff:4a:0a:54:8e:f2:f4:c3:1c:e0:1f:
9b:1a:ee:16:e0:e9:eb:c8:fe:e8:16:99:e9:61:81:
ed:e4:f2:58:fb:3b:cb:c3:f5:9a:fa:ed:cd:39:51:
47:90:5d:6d:1b:27:d5:04:c5:de:57:7e:a7:a3:03:
e8:fb:0a:d5:32:89:40:12
P:
00:f4:81:c1:9b:5f:1f:eb:ac:43:2e:db:dd:77:51:
6e:1c:62:8d:4e:95:c6:e7:b9:4c:fb:39:9c:9d:da:
60:4b:0f:1f:c6:61:b0:fc:5f:94:e7:45:c3:2b:68:
9d:11:ba:e1:8a:f9:c8:6a:40:95:b9:93:7c:d0:99:
96:bf:05:2e:aa:f5:4e:f0:63:02:00:c7:c2:52:c7:
1a:70:7c:f7:e5:fe:dd:3d:57:02:86:ae:d4:89:20:
ca:4b:46:80:ea:de:a1:30:11:5c:91:e2:40:d4:a3:
82:c5:40:3b:25:8e:d8:b2:85:cc:f5:9f:a9:1d:ea:
0a:ac:77:95:ee:d6:f7:61:e3
Q:
00:d5:db:48:18:bd:ec:69:99:eb:ff:5f:e1:40:af:
20:80:6d:5c:b1:23
G:
01:f9:a1:91:c0:82:12:74:49:8a:d5:13:88:21:3e:
32:ea:f1:74:55:2b:de:61:6c:fd:dd:f5:e1:c5:03:
68:b4:ad:40:48:58:62:6c:79:75:b1:5d:42:e6:a9:
97:86:37:d8:1e:e5:65:09:28:86:2e:6a:d5:3d:62:
50:06:b8:d3:f9:d4:9c:9c:75:84:5b:db:96:46:13:
f0:32:f0:c5:cb:83:01:a8:ae:d1:5a:ac:68:fb:49:
f9:b6:8b:d9:d6:0d:a7:de:ad:16:2b:23:ff:8e:f9:
3c:41:16:04:66:cf:e8:64:9e:e6:42:9a:d5:97:60:
c2:e8:9e:f4:bc:8f:6f:e0
Section 1.3
Section 1.4
1 3 5 7 9 11 13 15 17 19
2 4 6 8 10 12 14 16 18 20
Section 1.5
• Port Default
The default state of the port (i.e. open or closed).
• Access Authorized
Denotes whether the ports/services are authenticated during access.
Service Enabled/
Services Port Number Disabled Access Authorized Note
Service Enabled/
Services Port Number Disabled Access Authorized Note
RADIUS Yes
UDP/1812 to send Disabled
Only
(configurable), (configurable)
available
opens random port
through two
to listen to management
Remote Syslog UDP/514 Disabled No Only
(configurable) (configurable) available
through two
management
interfaces.
TCP Modbus (Server) TCP/502 Disabled No Only
(configurable) available
through two
management
interfaces.
TCP Modbus (Switch) TCP/502 Disabled No
(configurable)
No
DHCP, DHCP Agent UDP/67, 68 sending Disabled
msg if enabled - if (configurable)
received, always
come to CPU,
dropped if service
not configured
Yes
— Disabled
(configurable)
Section 1.6
CONTENTS
• Section 1.6.1, “Supported Standard MIBs”
• Section 1.6.2, “Supported Proprietary RUGGEDCOM MIBs”
• Section 1.6.3, “Supported Agent Capabilities”
Section 1.6.1
IANAifType Enumerated Values of the ifType Object Defined ifTable defined in IF-
MIB
IP-MIB
RFC 2011 SNMPv2 Management Information Base for Internet Protocol using
SMIv2
RFC 2012 TCP-MIB SNMPv2 Management Information Base for the Transmission Control
Protocol using SMIv2
RFC 2013 UDP-MIB Management Information Base for the UDP using SMIv2
RFC 1659 RS-232-MIB Definitions of Managed Objects for RS-232-like Hardware Devices
RFC 2863 IF-MIB The Interface Group MIB
RFC 2819 RMON-MIB Remote Network Monitoring (RMON) management Information base
RSTP-MIB
RFC 4318 Definitions of Managed Objects for Bridges with Rapid Spanning Tree
Protocol
RFC 3411 SNMP-FRAMEWORK-MIB An Architecture for Describing Simple Network Management
Protocol (SNMP) Management Framework
RFC 3414 SNMP-USER-BASED-SM-MIB User-based Security Model (USM) for Version 3 of the Simple
Network Management Protocol (SNMPv3)
RFC 3415 SNMP-VIEW-BASED-ACM-MIB View-bsed Access Control Model (VACM) for the Simple
Management Protocol (SNMP)
IEEE8023-LAG-MIB Management Information Base Module for Link Aggregation
IEEE 802.3ad
IEEE 802.1AB-2005 LLDP-MIB Management Information Base Module for LLDP Configuration,
Statistics, Local System Data and Remote Systems Data Components
Q-BRIDGE-MIB Definitions of Managed Objects for Bridges with Traffic Classes,
RFC 4363
Multicast Filtering, and Virtual LAN Extensions
Section 1.6.2
Section 1.6.3
Section 1.7
SNMP Traps
The device generates the following standard traps:
Trap MIB
linkDown IF-MIB
linkUp
authenticationFailure SNMPv2-MIB
coldStart
newRoot BRIDGE-MIB
topologyChage
risingAlarm RMON-MIB
fallingAlarm
lldpRemoteTablesChange LLDP-MIB
Trap MIB
RUGGEDCOM-TRAPS-MIB
genericTrap
powerSupplyTrap
14 SNMP Traps
RUGGEDCOM ROS Chapter 1
User Guide Introduction
Trap MIB
swUpgradeTrap
cfgChangeTrap
weakPasswordTrap
defaultKeysTrap
Generic traps carry information about events in their severity and description objects. They are sent at the same
time an alarm is generated for the device. The following are examples of RUGGEDCOM generic traps:
NOTE
Information about generic traps can be retrieved using the CLI command alarms. For more information about the alarms comman
Trap Severity
The device generates the following traps when specific events occur:
Section 1.8
CONTENTS
• Section 1.8.1, “ModBus Function Codes”
• Section 1.8.2, “ModBus Memory Map”
• Section 1.8.3, “ModBus Memory Formats”
Section 1.8.1
Section 1.8.2
Product Info
The following data is mapped to the Productinfo table:
Alarms
The following data is mapped to the alarms table:
R PortCmd
03FE 2 Port Link Status
Ethernet Statistics
The following data is mapped to the rmonStats table:
Serial Statistics
The following data is mapped to the uartPortStatus table:
Address #Registers Description (Reference Table in UI) R/W Format
Section 1.8.3
CONTENTS
• Section 1.8.3.1, “Text”
• Section 1.8.3.2, “Cmd”
• Section 1.8.3.3, “Uint16”
• Section 1.8.3.4, “Uint32”
• Section 1.8.3.5, “PortCmd”
• Section 1.8.3.6, “Alarm”
• Section 1.8.3.7, “PSStatusCmd”
• Section 1.8.3.8, “TruthValues”
Section 1.8.3.1
Text
The Text format provides a simple ASCII representation of the information related to the product. The most
significant register byte of an ASCII characters comes first.
For example, consider a Read Multiple Registers request to read Product Identification from location 0x0000.
0x04 0x00 0x00 0x00 0x08
0x04 0x10 0x53 0x59 0x53 0x54 0x45 0x4D 0x20 0x4E 0x41 0x4D 0x45
In this example, starting from byte 3 until the end, the response presents an ASCII representation of the
characters for the product identification, which reads as SYSTEM NAME. Since the length of this field is smaller
than eight registers, the rest of the field is filled with zeros (0).
Section 1.8.3.2
Cmd
The Cmd format instructs the device to set the output to either true or false. The most significant byte comes first.
• FF 00 hex requests output to be True
• 00 00 hex requests output to be False
• Any value other than the suggested values does not affect the requested operation
For example, consider a Write Multiple Registers request to clear alarms in the device.
0x10 0x00 0x80 0x00 0x01 2 0xFF 0x00
Section 1.8.3.3
Uint16
The Uint16 format describes a Standard ModBus 16 bit register.
Section 1.8.3.4
Uint32
The Uint32 format describes Standard 2 ModBus 16 bit registers. The first register holds the most significant
16 bits of a 32 bit value. The second register holds the least significant 16 bits of a 32 bit value.
Section 1.8.3.5
PortCmd
The PortCmd format describes a bit layout per port, where 1 indicates the requested action is true, and 0 indicates
the requested action is false.
PortCmd provides a bit layout of a maximum of 32 ports. Therefore, it uses two ModBus regsiters:
• The first ModBus register corresponds to ports 1 – 16
• The second ModBus register corresponds to ports 17 – 32 for a particular action
Cmd 23
Chapter 1 RUGGEDCOM ROS
Introduction User Guide
Bits that do not apply to a particular product are always set to zero (0).
A bit value of 1 indicates that the requested action is true. For example, the port is up.
A bit value of 0 indicates that the requested action is false. For example, the port is down.
The response depends on how many parts are available on the device. For example, if the maximum number of
ports on a connected RUGGEDCOM device is 20, the response would be similar to the following:
0x00 0x05
0x04 0x04 0xF2 0x76
In this example, bytes 3 and 4 refer to register 1 at location 0x03FE, and represent the status of ports 1 – 16.
Bytes 5 and 6 refer to register 2 at location 0x03FF, and represent the status of ports 17 – 32. The device only
has 20 ports, so byte 6 contains the status for ports 17 – 20 starting from right to left. The rest of the bites in
register 2 corresponding to the non-existing ports 21 – 31 are zero (0).
A bit value of 1 clears Ethernet statistics on the corresponding port. A bit value of 0 does not clear the Ethernet
statistics.
0x10 0x00 0x81 0x00 0x02
Section 1.8.3.6
Alarm
The Alarm format is another form of text description. Alarm text corresponds to the alarm description from the
table holding all of the alarms. Similar to the Text format, this format returns an ASCII representation of alarms.
NOTE
Alarms are stacked in the device in the sequence of their occurence (i.e. Alarm 1, Alarm 2, Alarm 3, etc.).
The first eight alarms from the stack can be returned, if they exist. A zero (0) value is returned if an alarm does not
exist.
24 Alarm
RUGGEDCOM ROS Chapter 1
User Guide Introduction
Section 1.8.3.7
PSStatusCmd
The PSStatusCmd format describes a bit layout for providing the status of available power supplies. Bits 0-4 of the
lower byte of the register are used for this purpose.
• Bits 0-1: Power Supply 1 Status
• Bits 2-3: Power Supply 2 Status
Other bits in the register do not provide any system status information.
Bit Value Description
The values used for power supply status are derived from the RUGGEDCOM-specific SNMP MIB.
The lower byte of the register displays the power supply's status. In this example, both power supplies in the unit
are functional.
Section 1.8.3.8
TruthValues
The Truthvalues format represents a true or false status in the device:
• 1 indicates the corresponding status for the device to be true
• 2 indicates the corresponding status for the device to be false
The register's lower byte shows the FailSafe Relay status. In this example, the FailSafe Relay is energized.
PSStatusCmd 25
Chapter 1 RUGGEDCOM ROS
Introduction User Guide
The register's lower byte shows the ErrorAlarm status. In this example, there is no active ERROR, ALERT or CRITICAL
alarm in the device.
Section 1.9
CONTENTS
• Section 1.9.1, “Certificate and Keys Life Cycle”
• Section 1.9.2, “Certificate and Key Requirements”
Section 1.9.1
NOTE
Network exposure to a ROS unit operating with the default keys, although always only temporary
by design, should be avoided. The best way to reduce or eliminate this exposure is to provision user- created certificate and keys a
• Default
A default certificate and SSL/SSH keys are built in to RUGGEDCOM ROS and are common across all RUGGEDCOM
ROS units sharing the same firmware image. In the event that valid SSL certificate or SSL/SSH key files are not
available on the device (as is usually only the case when upgrading from an old ROS version that does not
support user-configurable keys and therefore does was not shipped with unique, factory-generated keys), the
default certificate and keys are put into service *temporarily* so that SSH and SSL (https) sessions can be served
until generated or provisioned keys are available.
• Auto-Generated
If a default SSL certificate and SSL/SSH keys are in use, RUGGEDCOM ROS immediately begins to generate a
unique certificate and SSL/SSH keys for the device in the background. This process may take several minutes to
complete depending on the requested key length and how busy the device is at the time. If a custom certificate
and keys are loaded while auto-generated certificates and keys are being generated, the generator will abort
and the custom certificate and keys and will be used.
• User-Generated (Recommended)
Custom certificates and keys are the most secure option. They give the user complete control over certificate
and key management, allow for the provision of certificates signed by a public or local certificate authority,
enable strictly controlled access to private keys, and allow authoritative distribution of SSL certificates, any CA
certificates, and public SSH keys.
NOTE
The RSA key pair corresponding to the SSL certificate must be appended to the certificate in the
ssl.crt file.
Section 1.9.2
-----BEGIN CERTIFICATE-----
MIIC9jCCAl+gAwIBAgIJAJh6rrehMt3iMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYD
VQQGEwJDQTEQMA4GA1UECBMHT250YXJpbzEQMA4GA1UEBxMHQ29uY29yZDESMBAG
A1UEChMJUnVnZ2VkY29tMRkwFwYDVQQLExBDdXN0b21lciBTdXBwb3J0MSYwJAYD
VQQDEx1XUy1NSUxBTkdPVkFOLlJVR0dFRENPTS5MT0NBTDEkMCIGCSqGSIb3DQEJ
ARYVc3VwcG9ydEBydWdnZWRjb20uY29tMB4XDTEyMTAyMzIxMTA1M1oXDTE3MTAy
MjIxMTA1M1owgZwxCzAJBgNVBAYTAlVTMRAwDgYDVQQIEwdPbnRhcmlvMRAwDgYD
VQQHEwdDb25jb3JkMRIwEAYDVQQKEwlSdWdnZWRDb20xGTAXBgNVBAsTEEN1c3Rv
bWVyIFN1cHBvcnQxFDASBgNVBAMTCzE5Mi4xNjguMS4yMSQwIgYJKoZIhvcNAQkB
FhVTdXBwb3J0QHJ1Z2dlZGNvbS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBALfE4eh2aY+CE3W5a4Wz1Z1RGRP02COHt153wFFrU8/fFQXNhKlQirlAHbNT
RSwcTR8ZFapivwYDivn0ogOGFXknYP90gv2oIaSVY08FqZkJW77g3kzkv/8Zrw3m
W/cBsZJ8SyKLIDfy401HkHpDOle5NsQFSrziGUPjAOIvvx4rAgMBAAGjLDAqMAkG
A1UdEwQCMAAwHQYDVR0OBBYEFER0utgQOifnrflnDtsqNcnvRB0XMA0GCSqGSIb3
DQEBBQUAA4GBAHtBsNZuh8tB3kdqR7Pn+XidCsD70YnI7w0tiy9yiRRhARmVXH8h
5Q1rOeHceri3JFFIOxIxQt4KgCUYJLu+c9Esk/nXQQar3zR7IQCt0qOABPkviiY8
c3ibVbhJjLpR2vNW4xRAJ+HkNNtBOg1xUlp4vOmJ2syYZR+7XAy/OP/S
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
MIICXAIBAAKBgQC3xOHodmmPghN1uWuFs9WdURkT9Ngjh7ded8BRa1PP3xUFzYSp
UIq5QB2zU0UsHE0fGRWqYr8GA4r59KIDhhV5J2D/dIL9qCGklWNPBamZCVu+4N5M
5L//Ga8N5lv3AbGSfEsiiyA38uNNR5B6QzpXuTbEBUq84hlD4wDiL78eKwIDAQAB
AoGBAI2CXHuHg23wuk9zAusoOhw0MN1/M1jYz0k9aajIvvdZT3Tyd29yCADy8GwA
eUmoWXLS/C4CcBqPa9til8ei3rDn/w8dveVHsi9FXjtVSYqN+ilKw+moMAjZy4kN
/kpdpHMohwv/909VWR1AZbr+YTxaG/++tKl5bqXnZl4wHF8xAkEA5vwut8USRg2/
TndOt1e8ILEQNHvHQdQr2et/xNH4ZEo7mqot6skkCD1xmxA6XG64hR3BfxFSZcew
Wr4SOFGCtQJBAMurr5FYPJRFGzPM3HwcpAaaMIUtPwNyTtTjywlYcUI7iZVVfbdx
4B7qOadPybTg7wqUrGVkPSzzQelz9YCSSV8CQFqpIsEYhbqfTLZEl83YjsuaE801
xBivaWLIT0b2TvM2O7zSDOG5fv4I990v+mgrQRtmeXshVmEChtKnBcm7HH0CQE6B
2WUfLArDMJ8hAoRczeU1nipXrIh5kWWCgQsTKmUrafdEQvdpT8ja5GpX2Rp98eaU
NHfI0cP36JpCdome2eUCQDZN9OrTgPfeDIXzyOiUUwFlzS1idkUGL9nH86iuPnd7
WVF3rV9Dse30sVEk63Yky8uKUy7yPUNWldG4U5vRKmY=
-----END RSA PRIVATE KEY-----
For SSH, RUGGEDCOM ROS requires a DSA or RSA host key pair in PEM format. The key must be 1024, 2048 or
3072 bits in length for Controlled versions. The key file is uploaded to the ssh.keys flash file on the device.
The following is an example of a PEM formatted SSH key:
For more information about encryption key management, refer to Section 1.2, “Security Recommendations and
Considerations” .
Using ROS
This chapter describes how to use the RUGGEDCOM ROS interface.
CONTENTS
• Section 2.1, “Connecting to ROS”
• Section 2.2, “Logging In”
• Section 2.3, “Logging Out”
• Section 2.4, “Using the Web Interface”
• Section 2.5, “Using the Console Interface”
• Section 2.6, “Using the Command Line Interface”
• Section 2.7, “Selecting Ports in RUGGEDCOM ROS ”
• Section 2.8, “Managing the Flash File System”
• Section 2.9, “Accessing BIST Mode”
• Section 2.10, “Managing SSH Public Keys”
Section 2.1
Connecting to ROS
This section describes the various methods for connecting the device.
CONTENTS
• Section 2.1.1, “Connecting Directly”
• Section 2.1.2, “Connecting via the Network”
Section 2.1.1
Connecting Directly
RUGGEDCOM ROS can be accessed through a direct RS-232 serial console connection for management and
troubleshooting purposes. A console connection provides access to the console interface and CLI.
To establish a console connection to the device, do the following:
1. Connect a workstation (either a terminal or computer running terminal emulation software) to the RS-232
serial console port on the device. For more information about the RS-232 serial console port, refer to the
RSG2100 Installation Guide.
NOTE
The baud rate for the device is printed on the chassis exterior near the RS-232 serial console port.
Connecting to ROS 29
Chapter 2 RUGGEDCOM ROS
Using ROS User Guide
Section 2.1.2
3. In the address bar, type the IP address for the port that is connected to the network. For example, to access
the device using its factory default IP address, type https://192.168.0.1 and press Enter. Once the
connection is established, the login screen for the Web interface appears.
For more information about logging in to the device, refer to Section 2.2, “Logging In” . For more information
about the Web interface, refer to Section 2.4, “Using the Web Interface” .
Section 2.2
Logging In
To log in to the device, do the following:
1. Connect to the device either directly or through a Web browser. For more information about how to connect
to the device, refer to Section 2.1, “Connecting to ROS” .
Once the connection is established, the login form appears.
1 2
Logging In 31
Chapter 2 RUGGEDCOM ROS
Using ROS User Guide
NOTE
The following default usernames and passwords are set on the device for each user type:
GuestOperatorAdmin
Username: guestUsername: operatorUsername: admin Password: guestPassword: operatorPassword: admin
CAUTION!
To prevent unauthorized access to the device, make sure to change the default guest, operator, and admin passwords before
For more information about changing passwords, refer to .
2. In the User Name field, type the username for an account setup on the device.
3. In the Password field, typ the password for the account.
4. Click Enter or click Submit (Web interface only).
Section 2.3
Logging Out
To log out of the device, navigate to the main screen and do the following:
• To log out of the Console or secure shell interfaces, press CTRL + X.
• To log out of the Web interface, click Logout.
NOTE
If any pending configuration changes have not been committed, RUGGEDCOM ROS will request confirmation before discarding the
Figure 4: Web Interface (Example)
1. Logout
32 Logging Out
RUGGEDCOM ROS Chapter 2
User Guide Using ROS
Section 2.4
2
3
Side The side frame contains a logout option and a collapsible list of links that open various
screens in the main frame. For information about logging out of RUGGEDCOM ROS, refer to
Section 2.3, “Logging Out” .
Main The main frame displays the parameters and/or data related to the selected feature.
Each screen consists of a title, the current user's access level, parameters and/or data (in form or table format),
and controls (e.g. add, delete, refresh, etc.). The title provides access to context-specific Help for the screen that
provides important information about the available parameters and/or data. Click on the link to open the Help
information in a new window.
When an alarm is generated, an alarm notification replaces the current user's access level on each screen until
the alarm is cleared. The notification indicates how many alarms are currently active. For more information about
alarms, refer to Section 4.6, “Managing Alarms” .
1 3
NOTE
If desired, the web interface can be disabled. For more information, refer to .
Section 2.5
Each screen consists of a system identifier, the name of the current menu, and a command bar. Alarms are also
indicated on each screen in the upper right corner.
1 5
NOTE
The system identifier is user configurable. For more information about setting the system name, refer to .
Configuring Parameters
Use the following controls to select and configure parameters in the Console interface:
Up/Down Arrow Keys Use the up and down arrow keys to select parameters.
Enter Select a parameter and press Enter to start editing a parameter. Press Enter again to commit the change.
Esc When editing a parameter, press Esc to abort all changes.
Commands
The command bar lists the various commands that can be issued in the Console interface. Some commands are
specific to select screens. The standard commands include the following:
Ctrl + A Commits configuration changes made on the current screen.
NOTE
Before exiting a screen, RUGGEDCOM ROS will automatically prompt the user to save any changes that have not been committed.
Ctrl + X Terminates the current session. This command is only available from the main menu.
Ctrl + Z Displays important information about the current screen or selected parameter.
Section 2.6
CONTENTS
• Section 2.6.1, “Available CLI Commands”
• Section 2.6.2, “Tracing Events”
• Section 2.6.3, “Executing Commands Remotely via RSH”
• Section 2.6.4, “Using SQL Commands”
Section 2.6.1
clearethstats [ all
port ] Clears Ethernet statistics for one or more ports.
| Optional and/or required parameters include:
• all clears statistics for all ports
Command Description
clrcblstats [ all | port ] Clears cable diagnostics statistics for one or more ports.
Optional and/or required parameters include:
• all clears statistics for all ports
• port is a comma separated list of port numbers (e.g. 1,3-5,7)
factory Enables factory mode, which includes several factory-level commands used for testing and
troubleshooting. Only available to admin users.
CAUTION!
Misuse of the factory commands may corrupt the operational state of device
and/or may permanently damage the ability to recover the device without
manufacturer intervention.
flashleds timeout Flashes the LED indicators on the device for a specified number of seconds.
Optional and/or required parameters include:
• timeout is the number of seconds to flash the LED indicators. To stop the LEDs from
flashing, set the timeout period to 0 (zero).
fpgacmd Provides access to the FPGA management tool for troubleshooting time synchronization.
help command Displays a brief description of the specified command. If no command is specified, it displays
a list of all available commands, including a description for each.
Optional and/or required parameters include:
• command is the command name.
ipconfig Displays the current IP address, subnet mask and default gateway. This command provides
the only way of determining these values when DHCP is used.
ping address { count Sends an ICMP echo request to a remotely connected device. For each reply received, the
| round trip time is displayed. Use this command to verify connectivity to the next connected
timeout } device. It is a useful tool for testing commissioned links. This command also includes the
ability to send a specific number of pings with a specified time for which to wait for a
response.
Optional and/or required parameters include:
Available CLI 37
Commands
Chapter 2 RUGGEDCOM ROS
Using ROS User Guide
Command Description
• address is the target IP address.
• count is the number of echo requests to send. The default is 4.
• timeout is the time in milliseconds to wait for each reply. The range is 2 to
5000 seconds. The default is 300 milliseconds.
NOTE
The device to be pinged must support ICMP echo. Upon commencing the
ping, an ARP request for the MAC address of the device is issued. If the
device to be pinged is not on the same network as the device pinging the
other device, the default gateway must be programmed.
resetport { all | ports } Resets one or more Ethernet ports, which may be useful for forcing re-negotiation of speed
and duplex, or in situations where the link partner has latched into an inappropriate state.
Optional and/or required parameters include:
• all resets all ports
• ports is a comma separated list of port numbers (e.g. 1,3-5,7)
sfp port { base | alarms | Displays SFP (Small Form Factor Pluggable) device information and diagnostics. If optional
diag | calibr | thr | all | or required parameters are not used, this command displays the base and extended
no parameter specified } information.
Optional and/or required parameters include:
• port is the port number for which the data are required
• base displays the base information
• alarms displays alarms and warning flags
• diag displays measured data
• calibr displays calibration data for external calibration
• thr displays thresholds data
• all displays all diagnostic data
sql { default | delete | help Provides an SQL-like interface for manipulating all system configuration and status
| info | insert | save | parameters. All commands, clauses, table, and column names are case insensitive.
select | update }
Optional and/or required parameters include:
• default sets all records in a table(s) to factory defaults
• delete allows for records to be deleted from a table
• help provides a brief description for any SQL command or clause
• info displays a variety of information about the tables in the database
• insert enables new records to be inserted into a table
• save saves the database to non-volatile memory storage
• select queries the dtabase and displays selected records
• update enable existing records in a table to be updated
For more information about the sql command, refer to Section 2.6.4, “Using SQL
Commands” .
38 Available CLI
Commands
RUGGEDCOM ROS Chapter 2
User Guide Using ROS
Command Description
Section 2.6.2
Tracing Events
The CLI trace command provides a means to trace the operation of various protocols supported by the device.
Trace provides detailed information, including STP packet decodes, IGMP activity and MAC address displays.
NOTE
Tracing has been designed to provide detailed information to expert users. Note that all tracing is disabled upon device startup.
trace ?
If an option such as allon or alloff is required, determine which options are available for the desired
protocol by typing:
Tracing Events 39
Chapter 2 RUGGEDCOM ROS
Using ROS User Guide
trace protocol ?
NOTE
If required, expand the trace scope by stringing protocols and their associated options together using a vertical bar (|).
trace
Section 2.6.3
NOTE
Any output from the command will be returned to the workstation submitting the command. Commands that start interactive dial
Section 2.6.4
• Restoring the contents of a specific table, but not the whole configuration, to their factory defaults.
• Search tables in the database for specific configurations.
• Make changes to tables predicated upon existing configurations.
When combined with RSH, SQL commands provide a means to query and configure large numbers of devices from
a central location.
NOTE
For a list of parameters available under the sql command, refer to .
NOTE
Read/write access to tables containing passwords or shared secrets is unavailable using SQL commands.
CONTENTS
• Section 2.6.4.1, “Finding the Correct Table”
• Section 2.6.4.2, “Retrieving Information”
• Section 2.6.4.3, “Changing Values in a Table”
• Section 2.6.4.4, “Resetting a Table”
• Section 2.6.4.5, “Using RSH and SQL”
Section 2.6.4.1
Finding the Correct Table
Many SQL commands operate upon specific tables in the database, and require the table name to be specified.
Navigating the menu system in the console interface to the desired menu and pressing Ctrl-Z displays the name of
the table. The menu name and the corresponding database table name will be cited.
Another way to find a table name is to type the following in the CLI:
Table Description
-------------------------------------------------------------------------------
alarms Alarms
cpuDiags CPU Diagnostics
ethPortCfg Port Parameters
ethPortStats Ethernet
Statistics ethPortStatus Port
Status
Section 2.6.4.2
Retrieving Information
The following describes various methods for retrieving information about tables and parameters.
1 records selected
IP
Address
192.168.0
.1
42 Retrieving Information
RUGGEDCOM ROS Chapter 2
User Guide Using ROS
Port Name ifName Media StateAutoN Speed Dupx FlowCtrl LFI Alarm
1 Port 1 1 1000T Enabled On Auto Auto Off Off On
2 Port 2 2 1000T Enabled On Auto Auto Off Off On
3 Port 3 3 1000T Enabled On Auto Auto Off Off On
4 Port 4 4 1000T Enabled On Auto Auto Off Off On
4 records selected
sql select from table where parameter = value [ { and | or } | parameter | = | value ...]
Where:
• table is the name of the table
• parameter is the name of the parameter
• value is the value of the parameter
Example:
>sql select from ethportcfg where media = 1000T and State = enabled
Port Name ifName Media StateAutoN Speed Dupx FlowCtrl LFI Alarm
1 Port 1 1 1000T Enabled On Auto Auto Off Off on
2 Port 2 2 1000T Enabled On Auto Auto Off Off On
3 Port 3 3 1000T Enabled On Auto Auto Off Off On
4 Port 4 4 1000T Enabled On Auto Auto Off Off On
4 records selected
Section 2.6.4.3
Changing Values in a Table
Use the following command to change the value of parameters in a table:
Conditions can also be included in the command to apply changes only to parameters that meet specific criteria.
In the following example, flow control is enabled on ports that are operating in 100 Mbps full-duplex mode with
flow control disabled:
>sql update ethportcfg set FlowCtrl = Off where ( Media = 100TX and FlowCtrl = On )
2 records updated
Section 2.6.4.4
Resetting a Table
Use the following command to reset a table back to its factory defaults:
Section 2.6.4.5
Using RSH and SQL
The combination of remote shell scripting and SQL commands offers a means to interrogate and maintain a
large number of devices. Consistency of configuration across sites may be verified by this method. The following
presents a simple example where the devices to interrogate are drawn from the file Devices:
1 records selected
Section 2.7
Select a range of ports using a dash (-) between the first port and the last port in the list:
1-4
1,4,6,9
44 Resetting a Table
RUGGEDCOM ROS Chapter 2
User Guide Using ROS
Use the All option to select all ports in the device, or, if available, use the None option to select none of the
ports.
Section 2.8
CONTENTS
• Section 2.8.1, “Viewing a List of Flash Files”
• Section 2.8.2, “Viewing Flash File Details”
• Section 2.8.3, “Defragmenting the Flash File System”
Section 2.8.1
>flashfiles
-----------------------------------------------------------------
FilenameBaseSize SectorsUsed
-----------------------------------------------------------------
boot.bin 00000000 110000 0-16 1095790
main.bin 00110000 140000 17-36 1258403
fpga.xsvf 00250000 010000 37-37 55882
syslog.txt 00260000 140000 38-57 19222
ssh.keys 003A0000 010000 58-58 915
ssl.crt 003B0000 010000 59-59 1970
banner.txt 003C0000 010000 60-60 256
crashlog.txt 003D0000 010000 61-61 256
config.bak 003E0000 010000 62-62 15529
config.csv 003F0000 008000 63-63 15529
factory.txt 003FC000 004000 66-66 407
-----------------------------------------------------------------
Section 2.8.2
Section 2.8.3
flashfiles defrag
Section 2.9
IMPORTANT!
Do not connect the device to the network when it is in BIST mode. The device will generate excess multicast traffic in this mode.
>
5. Type help to view a list of all available options under BIST.
Section 2.10
CONTENTS
• Section 2.10.1, “Adding a Public Key”
• Section 2.10.2, “Viewing a List of Public Keys”
• Section 2.10.3, “Updating a Public Key”
• Section 2.10.4, “Deleting a Public Key”
Section 2.10.1
The key must be in RFC4716 or PEM format, with any of the following header and footer lines:
The following is an example of a valid entry in the sshpub.keys file in PEM format:
1,userkey,admin,active,alice
---- BEGIN SSH2 PUBLIC KEY ----
AAAAB3NzaC1yc2EAAAABIwAAAQEA4mRrqfk+RKXnmGRvzMyWVDsbq5VwpGGrlLQYCrjVEa
NdbXsphqYKop8V5VUeXFRAUFzOy82yk8TF/5JxGPWq6wRNjhnYR7IY2AiMBq0+K8XeURl/
z5K2XNRjnqTZSFwkhaUVJeduvjGgOlNN4yvgUwF3n0idU9k3E1q/na+LmYIeGhOwzCqoAc
ipHAdR4fhD5u0jbmvjv+gDikTSZIbj9eFJfP09ekImMLHwbBry0SSBpqAKbwVdWEXIKQ47
zz7ao2/rs3rSV16IXSq3Qe8VZh2irah0Md6JFMOX2qm9fo1I62q1DDgheCOsOiGPf4xerH
rI2cs6FT31rAdx2JOjvw==
---- END SSH2 PUBLIC KEY ----
The following is an example of a valid entry in the sshpub.keys file in in RFC4716 format:
2,userkey,admin,active,bob
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDH0NivR8zzbTxlecvFPzR/
GR24NrRJa0Lc7scNsWRgi0XulHuGrRLRB5RoQ39+spdig88Y8CqhRI49XJx7uLJe0Su3RvyNYz1jkdSwHq2hSZCpukJxJ6CK95Po/
sVa5Gq2gMaHowiYDSkcx+AJywzK/eM6i/jc125lRxFPdfkj74u+ob3PCvmIWz5z3WAJBrQU1IDPHDets511WMu8O9/
mAPZRwjqrWhRsqmcXZuv5oo54wIopCAZSo20SPzM2VmXFuUsEwDkvYMXLJK1koJPbDjH7yFFC7mwK2eMU/
oMFFn934cbO5N6etsJSvplYQ4pMCw6Ok8Q/bB5cPSOa/rAt bob@work
IMPORTANT!
The content of the sshaddpub.keys file must follow the same syntax as the sshpub.keys file.
RUGGEDCOM ROS allows only 16 user key entries to be stored. Each key entry must meet the following limits:
• Key type must be either RSA 2048 bits or RSA 3072 bits
• Key size must not exceed 4000 base64 encoded characters
• Entry Type in the header must not exceed 8 ASCII characters
• Access Level in the header must not exceed 8 ASCII characters (operator is maximum)
• Revocation status in the header must not exceed 8 ASCII characters (inactive is maximum)
• User Name must not exceed 12 ASCII characters
There are two ways to update sshpub.keys. Users can either upload a locally-created file directly to the
sshpub.keys file, which will replace the content in flash with the uploaded content. Or, users can upload a locally-
created file to the sshaddpub.keys file, which will keep the existing entries in the sshpub.keys file and append the
new entries.
To add keys, do the following:
1. Create a public key file via a host computer.
2. Transfer the public key file to the device using SFTP or Xmodem. For more information about transferring
files, refer to Section 3.4, “Uploading/Downloading Files” .
3. Log in to the device as an admin user and access the CLI shell. For more information about accessing the CLI
shell, refer to Section 2.6, “Using the Command Line Interface” .
48 Adding a Public
Key
RUGGEDCOM ROS Chapter 2
User Guide Using ROS
4. Check the system log to make sure the files were properly transferred. For more information about viewing
the system log, refer to Section 3.5.1, “Viewing Local Logs” .
Section 2.10.2
sshpubkey list
A list of public keys will appear, including their key ID, access level, revocation status, user name and key
fingerprint.
Section 2.10.3
sshpubkey list
A list of public keys will appear, including their key ID, access level, revocation status, user name and key
fingerprint.
3. Type the following commands to update the public keys:
Command Description
NOTE
The user public key ID must be a number between 0 and 9999.
sshpubkey update_rs RS Updates the revocation status (active, inactive) of a user public key.
• RS is the revocation status of the public key to be updated
sshpubkey update_un UN Updates the user name of a user public key.
• UN is the user name of the public key to be updated
Section 2.10.4
sshpubkey list
A list of public keys will appear, including access level, revocation status, user name and key fingerprint.
3. Type the following commands to delete the public key(s):
Command Description
Device Management
This chapter describes how to configure and manage the device and its components, such as module interfaces,
logs and files.
NOTE
For information about how to configure the device to work with a network, refer to .
CONTENTS
• Section 3.1, “Viewing Product Information”
• Section 3.2, “Viewing CPU Diagnostics”
• Section 3.3, “Restoring Factory Defaults”
• Section 3.4, “Uploading/Downloading Files”
• Section 3.5, “Managing Logs”
• Section 3.6, “Managing Ethernet Ports”
• Section 3.7, “Managing IP Interfaces”
• Section 3.8, “Managing IP Gateways”
• Section 3.9, “Configuring IP Services”
• Section 3.10, “Managing Remote Monitoring”
• Section 3.11, “Upgrading/Downgrading Firmware”
• Section 3.12, “Resetting the Device”
• Section 3.13, “Decommissioning the Device”
Section 3.1
This screen displays the following information: Figure 8: Product Information Form (Example)
1. MAC Address Box2. Order Code Box3. Classification Box4. Serial Number Box5. Boot Version Box6. Main Version Box
7. Required Boot Box8. Hardware ID Box9. Reload Button
Parameter Description
Parameter Description
Rev C1), RSG2100, RS900G, RSG2200, RS969, RS900 (v2,
40-00-0066), RS900 (v2, 40-00-0067), , RS416 (40-00-0078),
RMC30 (v2), RS930 (40-00-0089), RS969 (v2, 40-00-0090), RS910
(40-00-0091-001 Rev A), RS920L (40-00-0102-001 Rev A), RS940G
(40-00-0097-000 Rev A), RSi80X series CPU board, RSG2300,
RS416v2, ... }
Shows the type, part number, and revision level of the hardware.
Section 3.2
Parameter Description
The total size of RAM in the system.
Synopsis: 0 to 4294967295
Free Tx Bufs
Free Tx Buffers.
Section 3.3
2 3
Parameter Description
3. Click Apply.
Section 3.4
Uploading/Downloading Files
Files can be transferred between the device and a host computer using any of the following methods:
• Xmodem using the CLI shell over a Telnet or RS-232 console session
• TFTP client using the CLI shell in a console session and a remote TFTP server
• TFTP server from a remote TFTP client
• SFTP (secure FTP over SSH) from a remote SFTP client
IMPORTANT!
Scripts can be used to automate the management of files on the device. However, depending on the size of the target file(s), a delay be
Uploading/Downloading Files 55
Chapter 3 RUGGEDCOM ROS
Device Management User Guide
NOTE
The contents of the internal file system are fixed. New files and directories cannot be created, and existing files cannot be deleted.
CONTENTS
• Section 3.4.1, “Uploading/Downloading Files Using XMODEM”
• Section 3.4.2, “Uploading/Downloading Files Using a TFTP Client”
• Section 3.4.3, “Uploading/Downloading Files Using a TFTP Server”
• Section 3.4.4, “Uploading/Downloading Files Using an SFTP Server”
Section 3.4.1
NOTE
Xmodem transfers can only be performed through the serial console, which is authenticated during login.
1. Establish a direct connection between the device and the host computer. For more information, refer
to Section 2.1.1, “Connecting Directly” .
2. Log in to the device as an admin user and access the CLI shell. For more information about accessing the CLI
shell, refer to Section 2.6, “Using the Command Line Interface” .
NOTE
The send option sends files to the host computer, while the receive option pulls files from the host computer.
NOTE
If available in the terminal emulation or Telnet software, select the XModem 1K protocol for transmission over the standard XM
>xmodem receive
main.bin Press Ctrl-X
to cancel Receiving
data now ...C
Received 1428480 bytes. Closing file
Section 3.4.2
NOTE
This method requires a TFTP server that is accessible over the network.
Section 3.4.3
NOTE
This method requires a host computer that has TFTP server software installed.
IMPORTANT!
Interaction with TFTP servers is strictly controlled within the device to prevent unauthorized access. Make sure the device is co
1. Establish a direct connection between the device and the host computer. For more information, refer
to Section 2.1.1, “Connecting Directly” .
2. Initialize the TFTP server on the host computer and launch the TFTP transfer. The server will indicate when the
transfer is complete.
The following is an example of a successful TFTP server exchange:
Section 3.4.4
1. Establish an SFTP connection between the device and the host computer.
2. Launch the SFTP transfer. The client will indicate when the transfer is complete.
The following is an example of a successful SFTP server exchange:
user@host$ sftp
admin@ros_ip Connecting to
ros_ip... admin@ros_ip's
password:
sftp> put ROS-CF52_Main_v3-7-0.bin main.bin
Uploading ROS-CF52_Main_v3-7-0.bin to
/main.bin
Section 3.5
Managing Logs
The crash (crashlog.txt) and system (syslog.txt) log files contain historical information about events that
have occurred during the operation of the device.
The crash log contains debugging information related to problems that might have resulted in unplanned restarts
of the device or which may effect the operation of the device. A file size of 0 bytes indicates that no unexpected
events have occurred.
The system log contains a record of significant events including startups, configuration changes, firmware
upgrades and database re-initializations due to feature additions. The system log will accumulate information until
it is full, holding approximately 2 MB of data.
CONTENTS
• Section 3.5.1, “Viewing Local Logs”
• Section 3.5.2, “Clearing Local Logs”
• Section 3.5.3, “Configuring the Local System Log”
• Section 3.5.4, “Managing Remote Logging”
Section 3.5.1
Managing Logs 59
Chapter 3 RUGGEDCOM ROS
Device Management User Guide
Section 3.5.2
clearlogs
To clear only the local system log, log in to the Web interface and do the following:
1. Navigate to Diagnostics » Clear System Log . The Clear System Log form appears.
Section 3.5.3
1. Navigate to Administration » Configure Syslog » Configure Local Syslog . The Local Syslog form appears.
2 3
Parameter Description
3. Click Apply.
Section 3.5.4
CONTENTS
• Section 3.5.4.1, “Configuring the Remote Syslog Client”
• Section 3.5.4.2, “Viewing a List of Remote Syslog Servers”
• Section 3.5.4.3, “Adding a Remote Syslog Server”
• Section 3.5.4.4, “Deleting a Remote Syslog Server”
Section 3.5.4.1
Configuring the Remote Syslog Client
To configure the remote syslog client, do the following:
1. Navigate to Administration » Configure Syslog » Configure Remote Syslog Client . The Remote Syslog
Client form appears.
2 3
Parameter Description
3. Click Apply.
Section 3.5.4.2
Viewing a List of Remote Syslog Servers
To view a list of known remote syslog servers, navigate to Administration » Configure Syslog » Configure
Remote Syslog Server . The Remote Syslog Server table appears.
Section 3.5.4.3
Adding a Remote Syslog Server
RUGGEDCOM ROS supports up to 5 remote syslog servers (or collectors). Similar to the local system log, a remote
system log server can be configured to log information at a specific severity level. Only messages of a severity
level equal to or greater than the specified severity level are written to the log.
To add a remote syslog server to the list of known servers, do the following:
1. Navigate to Administration » Configure Syslog » Configure Remote Syslog Server . The Remote Syslog
Server table appears.
5 4
7
Parameter Description
Parameter Description
Default: 514
The UDP port number on which the remote server listens.
4. Click Apply.
Section 3.5.4.4
Deleting a Remote Syslog Server
To delete a remote syslog server from the list of known servers, do the following:
1. Navigate to Administration » Configure Syslog » Configure Remote Syslog Server . The Remote Syslog
Server table appears.
2. Figurethe
Select 18:server
Remotefrom
Syslog Server
the Table
table. The Remote Syslog Server form appears.
5 4
7
3. Click Delete.
Section 3.6
CONTENTS
• Section 3.6.1, “Controller Protection Through Link Fault Indication (LFI)”
• Section 3.6.2, “Viewing the Status of Ethernet Ports”
• Section 3.6.3, “Viewing Statistics for All Ethernet Ports”
• Section 3.6.4, “Viewing Statistics for Specific Ethernet Ports”
• Section 3.6.5, “Clearing Statistics for Specific Ethernet Ports”
• Section 3.6.6, “Managing SFP Transceivers”
• Section 3.6.7, “Configuring a PoE Port (For RSG2100P Only) ”
• Section 3.6.8, “Configuring an Ethernet Port”
• Section 3.6.9, “Configuring Port Rate Limiting”
• Section 3.6.10, “Configuring Port Mirroring”
• Section 3.6.11, “Configuring Link Detection”
• Section 3.6.12, “Detecting Cable Faults”
Section 3.6.1
1 2
3 4
If the transmit path from the controller to Switch A fails, Switch A still generates a link signal to the controller
through the receive path. The controller still detects the link with Switch A and does not failover to the backup
port.
This situation illustrates the need for a notification method that tells a link partner when the link integrity signal
has stopped. Such a method natively exists in some link media, but not all.
100Base-TX, 1000Base-T, 1000Base-X Includes a built-in auto-negotiation feature (i.e. a special flag called Remote Fault Indication
is set in the transmitted auto-negotation signal).
100Base-FX Links Includes a standard Far-End-Fault-Indication (FEFI) feature defined by the IEEE 802.3
standard for this link type. This feature includes:
• Transmitting FEFI
Transmits a modified link integrity signal in case a link failure is detected (i.e. no link
signal is received from the link partner)
• Detecting FEFI
Indicates link loss in case an FEFI signal is received from the link partner
10Base-FL links do not have a native link partner notification mechanism and FEFI support in 100Base-FX links is
optional according to the IEEE 802.3 standard, which means that some links partners may not support it.
Siemens offers an advanced Link-Fault-Indication (LFI) feature for the links that do not have a native link partner
notification mechanism. With LFI enabled, the device bases the generation of a link integrity signal upon its
reception of a link signal. In the example described previously, if switch A fails to receive a link signal from the
controller, it will stop generating a link signal. The controller will detect the link failure and failover to the backkup
port.
IMPORTANT!
If both link partners have the LFI feature, it must not be enabled on both sides of the link. If it is enabled on both sides, the link will nev
The switch can also be configured to flush the MAC address table for the controller port. Frames destined for the
controller will be flooded to Switch B where they will be forwarded to the controller (after the controller transmits
its first frame).
Section 3.6.2
Parameter Description
Section 3.6.3
Section 3.6.4
This table
Figure 23:displays
Ethernet the
Portfollowing information:
Statistics Table
Parameter Description
Synopsis: 0 to 18446744073709551615
OutPkts
The number of transmitted good packets.
TotalInOctets Synopsis: 0 to 18446744073709551615
The total number of octets of all received packets. This includes data
octets of rejected and local packets which are not forwarded to the
switching core for transmission. It should reflect all the data octets
received on the line.
Synopsis: 0 to 18446744073709551615
InBroadcasts
The number of good Broadcast packets received.
InMulticasts Synopsis: 0 to 18446744073709551615
The number of good Multicast packets received.
Parameter Description
• Packet data length is between 64 and 1536 octets inclusive.
• Packet has invalid CRC.
• Collision Event has not been detected.
• Late Collision Event has not been detected.
Parameter Description
as dropped and local received packets. This does not include rejected
received packets.
Section 3.6.5
2. Select one or more Ethernet ports. Figure 24: Clear Ethernet Port Statistics Form (Typical)
1. Port Check Boxes2. Confirm Button
3. Click Confirm.
Section 3.6.6
CONTENTS
• Section 3.6.6.1, “Configuring an SFP Port”
• Section 3.6.6.2, “Monitoring an SFP Port”
• Section 3.6.6.3, “Displaying Information for an SFP Port”
Section 3.6.6.1
Configuring an SFP Port
Depending on the required link media type, an SFP port may require some explicit configuration:
• For 1000Base-X or 1000Base-T links, the speed of the SFP port must be set to 1 Gbps.
• For 100Base- TX links, the speed must be set to 100 Mbps.
• Auto-negotiation can be configured to On when the port speed is set to 1 Gbps, or to Off when the port speed is
set to 100 Mbps.
• Duplex mode cannot be configured on an SFP port and is always forced to full duplex.
For more information about configuring SFP transceiver ports and other Ethernet ports on the device, refer to
Section 3.6.8, “Configuring an Ethernet Port” .
Section 3.6.6.2
Monitoring an SFP Port
RUGGEDCOM ROS supports hot-swapping of SFP transceivers on SFP ports and will automatically detect when an
SFP transceiver is removed or installed.
When RUGGEDCOM ROS detects that an SFP transceiver is plugged into an SFP port, it reads the transceiver
information and determines the transceiver type. This decision results in RUGGEDCOM ROS either accepting,
accepting and reconfiguring, or rejecting the SFP port.
The following table shows in which cases an SFP transceiver is accepted or accepted and reconfigured.
Configured Speed Detected SFP Type: 1000Base-X Detected SFP Type: 1000Base-T
Configured Speed Detected SFP Type: 1000Base-X Detected SFP Type: 1000Base-T
If the transceiver is accepted, the Media parameter under Ethernet Ports » Configure Port Parameters shows
detailed information about the SFP transceiver, including Gigabit Ethernet Compliance Code, transmission media,
connector type, and link length. For example:
SFP 1000LX SM LC 10
km SFP 1000T 100 m
If the transceiver is not recognized, it is rejected. An alarm is also generated and the port is blocked so that no link
can be established until the transceiver is replaced. The Media parameter shows the rejected SFP transceiver is
unidentified. For example:
SFP Unidentified
If no transceiver is installed on an SFP port, the Media parameter shows the SFP transceiver is unplugged:
SFP Unplugged
Section 3.6.6.3
Displaying Information for an SFP Port
To display detailed information about an SFP port, do the following:
1. Log in to the device and access the CLI shell. For more information about accessing the CLI shell, refer to
Section 2.6, “Using the Command Line Interface” .
2. Type the following command:
sfp port
Where:
• port is the port number
Information about the SFP port is displayed. For example:
>sfp 1
ID: SFP
Extended ID: GBIC/SFP function is defined by serial ID
only Connector: LC
Transceiver:
Gigabit Ethernet Compliance
Codes: 1000LX
Fibre Channel link
length: Long Distance
(L)
Fibre Channel transmitter
technology: Longwave laser (LC)
Fibre Channel transmission
media: Single Mode (SM)
Fibre Channel speed:
100 MBytes/Sec
Baud Rate, nominal: 1300
MBits/sec Encoding type: 8B10B
Length(9um): 10000 m
Length(50um): 550 m
Length(62.5um): 550 m
Length(Copper): Not
specified Vendor: xxxxxxx
IEEE company ID:
xxxxxxx Part number:
xxxxxxxxxx Revision:
0000
Laser wavelength: 1310 nm
Section 3.6.7
2. Figure
Select an25:Ethernet
Port PoE port.
Parameters TablePoE Parameters form appears.
The Port
7 8
6
Parameter Description
4. Click Apply.
Section 3.6.8
1. Navigate to Ethernet Ports » Configure Port Parameters . The Port Parameters table appears.
8
10
11
9
12
Parameter Description
Parameter Description
A descriptive name that may be used to identify the device
connected on that port.
NOTE
Disabling a port whose media type is set to 802.11g
disables the corresponding wireless module.
Parameter Description
NOTE
This feature must not be enabled at both ends of
a fiber link.
NOTE
If one end of the link is fixed to a specific speed and duplex type and the peer auto-negotiates, there is a strong possibility tha
as such or else severe frame loss will occur during heavy network traffic. At lower traffic volumes the link may display few, if a
These problems can be avoided by always configuring ports to the appropriate fixed values.
4. Click Apply.
Section 3.6.9
4
5 6
Parameter Description
4. Click Apply.
Section 3.6.10
IMPORTANT!
Before configuring port mirroring, note the following limitations:
Traffic will be mirrored onto the target port irrespective of its VLAN membership. It could be the same as or different from the sou
Network management frames (such as RSTP, GVRP etc.) may not be mirrored
Switch management frames generated by the switch (such as Telnet, HTTP, SNMP, etc.) may not be mirrored
4
5 6
Parameter Description
Parameter Description
Enabling port mirroring causes all frames received and
transmitted by the source port(s) to be transmitted out of the
target port.
3. Click Apply.
Section 3.6.11
3 4
Parameter Description
Parameter Description
device or a mis-matching fiber port is connected to the unit, a
large number of continuous link state changes could be reported
in a short period of time. These large number of bogus link state
changes could render the system unresponsive as most, if not
all, of the system resources are used to process the link state
changes. This could in turn cause a serious network problem as
the unit's RSTP process may not be able to run, thus allowing
network loop to form.
Three different settings are available for this parameter:
• ON_withPortGuard - This is the recommended setting. With this
setting, an extended period (~2 minutes) of excessive link state
changes reported by a port will prompt Port Guard feature to
disable FAST LINK DETECTION on that port and raise an alarm.
By disabling FAST LINK DETECTION on the problematic port,
excessive link state changes can no longer consume substantial
amount of system resources. However if FAST LINK DETECTION
is disabled, the port will need a longer time to detect a link
failure. This may result in a longer network recovery time of
up to 2s. Once Port Guard disables FAST LINK DETECTION of a
particular port, user can re-enable FAST LINK DETECTION on the
port by clearing the alarm.
• ON - In certain special cases where a prolonged excessive link
state changes constitute a legitimate link operation, using
this setting can prevent Port Guard from disabling FAST LINK
DETECTION on the port in question. If excessive link state
changes persist for more than 2 minutes, an alarm will be
generated to warn user about the observed bouncing link. If
the excessive link state changes condition is resolved later on,
the alarm will be cleared automatically. Since this option does
not disable FAST LINK DETECTION, a persistent bouncing link
could continue affect the system in terms of response time. This
setting should be used with caution.
• OFF - Turning this parameter OFF will disable FAST LINK
DETECTION completely. The switch will need a longer time to
detect a link failure. This will result in a longer network recovery
time of up to 2s.
3. Click Apply.
Section 3.6.12
CONTENTS
• Section 3.6.12.1, “Viewing Cable Diagnostics Results”
82 Detecting Cable
Faults
RUGGEDCOM ROS Chapter 3
User Guide Device Management
Section 3.6.12.1
Viewing Cable Diagnostics Results
To view the results of previous diagnostic tests, navigate to Ethernet Ports » Configure/View Cable
Diagnostics Parameters . The Cable Diagnostics Parameters table appears.
NOTE
For information about how to start a diagnostic test, refer to .
Parameter Description
Parameter Description
• Connect an Ethernet cable with a known length (e.g. 50m) to
the port
• DO NOT connect the other end of the cable to any link partner
• Run cable diagnostics a few times on the port. OPEN fault should
be detected
• Find the average distance to the OPEN fault recorded in the log
and compare it to the known length of the cable. The difference
can be used as the calibration value
• Enter the calibration value and run cable diagnostics a few more
times
• The distance to OPEN fault should now be at similar distance as
the cable length
• Distance to fault for the selected port is now calibrated
NOTE
For each successful diagnostic test, the values for Good, Open, Short or Imped will increment based on the number of cable pairs
NOTE
When a cable fault is detected, an estimated distance-to-fault is calculated and recorded in the system log. The log lists the cable p
Section 3.6.12.2
Performing Cable Diagnostics
To perform a cable diagnostic test on one or more Ethernet ports, do the following:
1. Connect a CAT-5 (or better quality) Ethernet cable to the selected Ethernet port.
IMPORTANT!
Both the selected Ethernet port and its partner port can be configured to run in Enabled mode with auto-negotiation, or in Disab
2. Connect the other end of the cable to a similar network port. For example, connect a 100Base-T port to a
100Base-T port, or a 1000Base-T port to a 1000Base-T port.
3. In ROS, navigate to Ethernet Ports » Configure/View Cable Diagnostics Parameters . The Cable
Diagnostics Parameters table appears.
10 8
11
5. Under Runs, enter the number of consecutive diagnostic tests to perform. A value of 0 indicates the test will
run continuously until stopped by the user.
6. Under Calib., enter the estimated Distance To Fault (DTF) value. For information about how to determine the
DTF value, refer to Section 3.6.12.4, “Determining the Estimated Distance To Fault (DTF)” .
7. Select Started.
IMPORTANT!
A diagnostic test can be stopped by selecting Stopped and clicking Apply. However, if the test is stopped in the middle of a di
8. Click Apply. The state of the Ethernet port will automatically change to Stopped when the test is complete.
For information about how to monitor the test and view the results, refer to Section 3.6.12.1, “Viewing Cable
Diagnostics Results” .
Section 3.6.12.3
Clearing Cable Diagnostics
To clear the cable diagnostic results, do the following:
1. Navigate to Ethernet Ports » Clear Cable Diagnostics Statistics . The Clear Cable Diagnostics Statistics
form appears.
86 Clearing Cable
Diagnostics
RUGGEDCOM ROS Chapter 3
User Guide Device Management
2. Select one or more Ethernet ports. Figure 36: Clear Cable Diagnostics Statistics Form
1. Port Check Boxes2. Apply Button
3. Click Apply.
Section 3.6.12.4
Determining the Estimated Distance To Fault (DTF)
To determine the estimate Distance To Fault (DTF), do the following:
1. Connect a CAT-5 (or better quality) Ethernet cable with a known length to the device. Do not connect the
other end of the cable to another port.
2. Configure the cable diagnostic utility to run a few times on the selected Ethernet port and start the test.
For more information, refer to Section 3.6.12.2, “Performing Cable Diagnostics” . Open faults should be
detected and recorded in the system log.
3. Review the errors recorded in the system log and determine the average distance of the open faults. For more
information about the system log, refer to Section 3.5.1, “Viewing Local Logs” .
4. Subtract the average distance from the cable length to determine the calibration value.
5. Configure the cable diagnostic utility to run a few times with the new calibration value. The distance to the
open fault should now be the same as the actual length of the cable. The Distance To Fault (DTF) is now
calibrated for the selected Ethernet port.
Section 3.6.13
2. Select one or more Ethernet ports to reset. Figure 37: Reset Port(s) Form
1. Ports2. Apply Button
3. Click Apply. The selected Ethernet ports are reset.
Section 3.7
Managing IP Interfaces
RUGGEDCOM ROS allows one IP interface to be configured for each subnet (or VLAN), up to a maximum of 255
interfaces. One of the interfaces must also be configured to be a management interface for certain IP services,
such as DHCP relay agent.
Each IP interface must be assigned an IP address. In the case of the management interface, the IP address type can
be either static, DHCP, BOOTP or dynamic. For all other interfaces, the IP address must be static.
CAUTION!
Configuration hazard – risk of communication disruption. Changing the ID for the management VLAN will break any active Raw Soc
CONTENTS
• Section 3.7.1, “Viewing a List of IP Interfaces”
• Section 3.7.2, “Adding an IP Interface”
• Section 3.7.3, “Deleting an IP Interface”
Section 3.7.1
88 Managing IP Interfaces
RUGGEDCOM ROS Chapter 3
User Guide Device Management
Section 3.7.2
Adding an IP Interface
To add an IP interface, do the following:
1. Navigate to Administration » Configure IP Interfaces . The IP Interfaces table appears.
Adding an IP Interface 89
Chapter 3 RUGGEDCOM ROS
Device Management User Guide
7 9
6
Parameter Description
ID Synopsis: 1 to 4094
Default: 1
Specifies the ID of the interface for which this IP interface is
created. If the interface type is VLAN, this represents the VLAN ID.
90 Adding an IP Interface
RUGGEDCOM ROS Chapter 3
User Guide Device Management
Parameter Description
Specifies the IP address of this device. An IP address is a 32-
bit number that is notated by using four numbers from 0
through 255, separated by periods. Only a unicast IP address
is allowed, which ranges from 1.0.0.0 to 233.255.255.255.
Synopsis: ###.###.###.### where ### ranges from 0 to 255
Subnet
Default: 255.255.255.0
Specifies the IP subnet mask of this device. An IP subnet mask
is a 32-bit number that is notated by using four numbers from
0 through 255, separated by periods. Typically, subnet mask
numbers use either 0 or 255 as values (e.g. 255.255.255.0) but
other numbers can appear.
IMPORTANT!
Each IP interface must have a unique network address.
4. Click Apply.
Section 3.7.3
Deleting an IP Interface
To delete an IP interface configured on the device, do the following:
1. Navigate to Administration » Configure IP Interfaces . The IP Interfaces table appears.
2. Figure
Select 41:IPIPinterface
the Interfacesfrom
Tablethe table. The IP Interfaces form appears.
Deleting an IP Interface 91
Chapter 3 RUGGEDCOM ROS
Device Management User Guide
7 9
6
3. Click Delete.
Section 3.8
Managing IP Gateways
RUGGEDCOM ROS allows up to ten IP gateways to be configured. When both the Destination and Subnet
parameters are blank, the gateway is considered to be a default gateway.
NOTE
The default gateway configuration will not be changed when resetting all configuration parameters to their factory defaults.
CONTENTS
• Section 3.8.1, “Viewing a List of IP Gateways”
• Section 3.8.2, “Adding an IP Gateway”
• Section 3.8.3, “Deleting an IP Gateway”
Section 3.8.1
92 Managing IP Gateways
RUGGEDCOM ROS Chapter 3
User Guide Device Management
Section 3.8.2
Adding an IP Gateway
To add an IP gateway, do the following:
1. Navigate to Administration » Configure IP Gateways . The IP Gateways table appears.
Adding an IP Gateway 93
Chapter 3 RUGGEDCOM ROS
Device Management User Guide
3
4 6
Parameter Description
4. Click Apply.
Section 3.8.3
Deleting an IP Gateway
To delete an IP gateway configured on the device, do the following:
1. Navigate to Administration » Configure IP Gateways . The IP Gateways table appears.
94 Deleting an IP Gateway
RUGGEDCOM ROS Chapter 3
User Guide Device Management
2. Select the IP gateway from the table. The IP Gateways form appears.
3
4 6
3. Click Delete.
Section 3.9
Configuring IP Services
To configure the IP services provided by the device, do the following:
1. Navigate to Administration » Configure IP Services . The IP Services form appears.
Configuring IP 95
Services
Chapter 3 RUGGEDCOM ROS
Device Management User Guide
12 13
10
11
Figure 48: IP Services Form
1. Inactivity Timeout Box2. Telnet Sessions Allowed Box3. Web Server Users Allowed Box4. TFTP Server Box5. Modbus Address Box6. SSH Sessions Allowe
10. Failed Attempts Window Box11. Lockout Time Box12. Apply Button13. Reload Button
Parameter Description
96 Configuring IP
Services
RUGGEDCOM ROS Chapter 3
User Guide Device Management
Parameter Description
Determines the Modbus address to be used for Management through Modbu
NOTE
When upgrading to ROS v4.3, the default will be set to { Enabled }.
3. Click Apply.
Section 3.10
CONTENTS
• Section 3.10.1, “Managing RMON History Controls”
• Section 3.10.2, “Managing RMON Alarms”
Section 3.10.1
CONTENTS
• Section 3.10.1.1, “Viewing a List of RMON History Controls”
• Section 3.10.1.2, “Adding an RMON History Control”
• Section 3.10.1.3, “Deleting an RMON History Control”
Section 3.10.1.1
Viewing a List of RMON History Controls
To view a list of RMON history controls, navigate to Ethernet Stats » Configure RMON History Controls . The
RMON History Controls table appears.
Section 3.10.1.2
Adding an RMON History Control
To add an RMON history control, do the following:
1. Navigate to Ethernet Stats » Configure RMON History Controls . The RMON History Controls table
appears.
2. Click InsertRecord.
Figure The Controls
50: RMON History RMON History
Table Controls form appears.
1. InsertRecord
7 10
6
8 9
Parameter Description
Parameter Description
4. Click Apply.
Section 3.10.1.3
Deleting an RMON History Control
To delete an RMON history control, do the following:
1. Navigate to Ethernet Stats » Configure RMON History Controls . The RMON History Controls table
appears.
7 10
6
8 9
3. Click Delete.
Section 3.10.2
There are two methods to evaluate a statistic in order to determine when to generate an event: delta and
Figure 54: The Alarm Process
absolute.
For most statistics, such as line errors, it is appropriate to generate an alarm when a rate is exceeded. The
alarm defaults to the delta measurement method, which examines changes in a statistic at the end of each
measurement period.
It may be desirable to alarm when the total, or absolute, number of events crosses a threshold. In this case, set the
measurement period type to absolute.
CONTENTS
• Section 3.10.2.1, “Viewing a List of RMON Alarms”
• Section 3.10.2.2, “Adding an RMON Alarm”
• Section 3.10.2.3, “Deleting an RMON Alarm”
Section 3.10.2.1
Viewing a List of RMON Alarms
To view a list of RMON alarms, navigate to Ethernet Stats » Configure RMON Alarms . The RMON Alarms table
appears.
Section 3.10.2.2
Adding an RMON Alarm
To add an RMON alarm, do the following:
1. Navigate to Ethernet Stats » Configure RMON Alarms . The RMON Alarms table appears.
2. Click InsertRecord.
Figure The Table
56: RMON Alarms RMON Alarms form appears.
1. InsertRecord
12 10
14
11
13
Parameter Description
Parameter Description
The index of the event that is used when a falling threshold is
crossed. If there is no corresponding entryl in the Event Table,
then no association exists. In particular, if this value is zero, no
associated event will be generated.
4. Click Apply.
Section 3.10.2.3
Deleting an RMON Alarm
To delete an RMON alarm, do the following:
1. Navigate to Ethernet Stats » Configure RMON Alarms . The RMON Alarms table appears.
12 10
14
11
13
3. Click Delete.
Section 3.10.3
CONTENTS
• Section 3.10.3.1, “Viewing a List of RMON Events”
• Section 3.10.3.2, “Adding an RMON Event”
Section 3.10.3.1
Viewing a List of RMON Events
To view a list of RMON events, navigate to Ethernet Stats » Configure RMON Events . The RMON Events table
appears.
Section 3.10.3.2
Adding an RMON Event
To add an RMON alarm, do the following:
1. Navigate to Ethernet Stats » Configure RMON Events . The RMON Events table appears.
2. Click InsertRecord.
Figure The Table
61: RMON Events RMON Events form appears.
1. InsertRecord
7 9
6
Parameter Description
4. Click Apply.
Section 3.10.3.3
Deleting an RMON Event
To delete an RMON event, do the following:
1. Navigate to Ethernet Stats » Configure RMON Events . The RMON Events table appears.
7 9
6
3. Click Delete.
Section 3.11
Upgrading/Downgrading Firmware
The following section describes how to upgrade and downgrade the firmware.
CONTENTS
• Section 3.11.1, “Upgrading Firmware”
Section 3.11.1
Upgrading Firmware
Upgrading RUGGEDCOM ROS firmware, including the main, bootloader and FPGA firmware, may be necessary
to take advantage of new features or bug fixes. Binary firmware images are available from Siemens. Visit
www.siemens.com/ruggedcom to determine which versions/updates are available or contact Siemens Customer
Support.
Binary firmware images transferred to the device are stored in non-volatile Flash memory and require a device
reset in order to take effect.
IMPORTANT!
Non-Controlled (NC) versions of RUGGEDCOM ROS can not be upgraded to Controlled firmware versions. However, Controlled firm
NOTE
The IP address set for the device will not be changed following a firmware upgrade.
>version
Current ROS-CF52 Boot Software v2.20.0 (Jan 29 2013 13:25)
Current ROS-CF52 Main Software v4.0 (Feb 2 2013 09:33)
Section 3.11.2
Downgrading Firmware
Downgrading the RUGGEDCOM ROS firmware is generally not recommended, as it may have unpredictable
effects. However, if a downgrade is required, do the following:
IMPORTANT!
Before downgrading the firmware, make sure the hardware and FPGA code types installed in the device are supported by the olde
IMPORTANT!
Non-Controlled (NC) versions of RUGGEDCOM ROS can not be downgraded to Controlled firmware versions. However, Controlled fi
110 Upgrading
Firmware
RUGGEDCOM ROS Chapter 3
User Guide Device Management
CAUTION!
Do not downgrade the RUGGEDCOM ROS boot version.
4. Restore the device to its factory defaults. For more information, refer to Section 3.3, “Restoring Factory
Defaults” .
5. Upload and apply the older firmware version and its associated FPGA files using the same methods used to
install newer firmware versions. For more information , refer to Section 3.11.1, “Upgrading Firmware” .
6. Press Ctrl-S to access the CLI.
7. Clear all logs by typing:
clearlogs
8. Clear all alarms by typing:
clearalarms
IMPORTANT!
After downgrading the firmware and FPGA files, be aware that some settings from the previous configuration may be lost or rever
Section 3.12
Section 3.13
type banner.txt
7. Clear the system and crash logs by typing:
clearlog
8. Generate a random SSL certificate by typing:
sslkeygen
This may take several minutes to complete. To verify the certificate has been generated, type:
type syslog.txt
When the phrase
Generated ssl.crt was saved
appears in the log, the SSL certificate has been generated.
9. Generate random SSH keys by typing:
sshkeygen
This may take several minutes to complete. To verify the keys have been generated, type:
type syslog.txt
When the phrase
Generated ssh.keys was saved
appears in the log, the SSH keys have been generated.
10. De-fragment and erase all free flash memory by typing:
flashfile defrag
This may take several minutes to complete.
System Administration
This chapter describes how to perform various administrative tasks related to device identification, user
permissions, alarm configuration, certificates and keys, and more.
CONTENTS
• Section 4.1, “Configuring the System Information”
• Section 4.2, “Customizing the Login Screen”
• Section 4.3, “Configuring Passwords”
• Section 4.4, “Clearing Private Data”
• Section 4.5, “Enabling/Disabling the Web Interface”
• Section 4.6, “Managing Alarms”
• Section 4.7, “Managing the Configuration File”
• Section 4.8, “Managing an Authentication Server”
Section 4.1
3
4 5
Parameter Description
Parameter Description
The system name is displayed in all RUGGEDCOM ROS menu
screens. This can make it easier to identify the switches within
your network provided that all switches are given a unique name.
3. Click Apply.
Section 4.2
Section 4.3
Configuring Passwords
RUGGEDCOM ROS allows for up to three user profiles to be configured locally on the device. Each profile
corresponds to one of the following access levels:
• Guest
• Operator
• Admin
The access levels provide or restrict the user's ability to change settings and execute various commands.
User Type
Rights
Guest Operator Admin
View Settings ü ü ü
Clear Logs û ü ü
Reset Alarms û ü ü
Clear Statistics û ü ü
User Type
Rights
Guest Operator Admin
Run Commands û û ü
Default passwords are configured for each user type initially. It is strongly recommended that these be changed
before the device is commissioned.
NOTE
Users can also be verified through a RADIUS or TACACS+ server. When enabled for authentication and authorization, the RADIUS or TAC
CAUTION!
To prevent unauthorized access to the device, make sure to change the default passwords for each profile before commissioning the de
To configure passwords for one or more of the user profiles, do the following:
1. Navigate to Administration » Configure Passwords . The Configure Passwords form appears.
12 13
10
11
Figure 67: Configure Passwords Form
1. Auth Type Box2. Guest Username Box3. Guest Password Box4. Confirm Guest Password Box5. Operator Username Box
6. Operator Password Box7. Confirm Operator Password Box8. Admin Username Box9. Admin Password Box10. Confirm Admin Password Box11. Password M
NOTE
RUGGEDCOM ROS requires that all user passwords meet strict guidelines to prevent the use of weak passwords. When creatin
Must not be less than 8 characters in length.
Must not include the username or any 4 continous characters found in the username. For example, if the username is Subnet
Must have at least one alphabetic character and one number. Special characters are permitted.
Must not have more than 3 continuously incrementing or decrementing numbers. For example,
Sub123 and Sub19826 are permitted, but Sub12345 is not.
An alarm will generate if a weak password is configured. The weak password alarm can be disabled by the user. For more info
Parameter Description
NOTE
For console access, local credentials will always be checked first regardle
Parameter Description
Related password is in field Oper Password; cannot change
settings; can reset alarms, statistics, logs, etc.
Synopsis: 1 to 17
Password Minimum Length
Default: 1
Configure the password string minimum length. The new
password shorter than the minimum length will be
3. Click Apply.
Section 4.4
1. Connect to the device via the RS-232 serial console port. For more information, refer to Section
2.1.1, “Connecting Directly” .
2. Cycle power to the device. As the device is booting up, the following prompt will appear:
>
4. Type the following command, then press Enter within 30 seconds:
Section 4.5
1. Log in to the device as an admin user and access the CLI shell. For more information about accessing the CLI
shell, refer to Section 2.6, “Using the Command Line Interface” .
2. Navigate to Administration » Configure IP Services » Web Server Users Allowed .
3. Select Disabled to disable the web interface, or select the desired number of web server users allowed to
enable the interface.
Section 4.6
Managing Alarms
Alarms indicate the occurrence of events of either importance or interest that are logged by the device.
There are two types of alarms:
• Active alarms signify states of operation that are not in accordance with normal operation. Examples include
links that should be up, but are not, or error rates that repeatedly exceed a certain threshold. These alarms are
continuously active and are only cleared when the problem that triggered the alarms is resolved.
• Passive alarms are a record of abnormal conditions that occurred in the past and do not affect th current
operation state of the device. Examples include authentication failures, Remote Network MONitoring (RMON)
MIB generated alarms, or error states that temporarily exceeded a certain threshold . These alarms can be
cleared from the list of alarms.
NOTE
For more information about RMON alarms, refer to .
When either type of alarm occurs, a message appears in the top right corner of the user interface. If more than
one alarm has occurred, the message will indicate the number of alarms. Active alarms also trip the Critical Failure
Relay LED on the device. The message and the LED will remain active until the alarm is cleared.
NOTE
Alarms are volatile in nature. All alarms (active and passive) are cleared at startup.
CONTENTS
• Section 4.6.1, “Viewing a List of Pre-Configured Alarms”
• Section 4.6.2, “Viewing and Clearing Latched Alarms”
• Section 4.6.3, “Configuring an Alarm”
• Section 4.6.4, “Authentication Related Security Alarms”
Section 4.6.1
NOTE
This list of alarms (configurable and non-configurable) is accessible through the Command Line Interface (CLI) using the alarms. F
For information about modifying a pre-configured alarm, refer to Section 4.6.3, “Configuring an Alarm” .
Section 4.6.2
2. Figure
Click 70: Clear Latched Alarms Form
Confirm.
1. Confirm Button
Section 4.6.3
Configuring an Alarm
While all alarms are pre-configured on the device, some alarms can be modified to suit the application. This
includes enabling/disabling certain features and changing the refresh time.
To configuring an alarm, do the following:
IMPORTANT!
Critical and Alert level alarms are not configurable and cannot be disabled.
6
8 9
7
Parameter Description
Level Synopsis: { EMRG, ALRT, CRIT, ERRO, WARN, NOTE, INFO, DEBG }
Severity level of the alarm:
• EMERG - The device has had a serious failure that caused a
system reboot.
• ALERT - The device has had a serious failure that did not cause a
system reboot.
• CRITICAL - The device has a serious unrecoverable problem.
• ERROR - The device has a recoverable problem that does not
seriously affect operation.
• WARNING - Possibly serious problem affecting overall system
operation.
• NOTIFY - Condition detected that is not expected or not
allowed.
• INFO - Event which is a part of normal operation, e.g. cold start,
user login etc.
• DEBUG - Intended for factory troubleshooting only.
This parameter is not configurable.
Parameter Description
Enables logging the occurrence of this alarm in syslog.txt.
Synopsis: 0 s to 60 s
Refresh Time Default: 60 s
Refreshing time for this alarm.
4. Click Apply.
Section 4.6.4
CONTENTS
• Section 4.6.4.1, “Security Alarms for Login Authentication”
• Section 4.6.4.2, “Security Messages for Port Authentication”
Section 4.6.4.1
Security Alarms for Login Authentication
RUGGEDCOM ROS provides various logging options related to login authentication. A user can log into a
RUGGEDCOM ROS device in three different ways: Console, SSH or Telnet. RUGGEDCOM ROS can log messages
in the syslog, send a trap to notify an SNMP manager, and/or raise an alarm when a successful and unsuccessful
login event occurs. In addition, when a weak password is configured on a unit or when the primary authentication
server for TACACS+ or RADIUS is not reachable, RUGGEDCOM ROS will raise alarms, send SNMP traps and log
messages in the syslog.
The following is a list of log and alarm messages related to user authentication:
• Weak Password Configured
• Login and Logout Information
• Excessive Failed Login Attempts
• RADIUS Server Unreachable
• TACACS Server Unreachable
• TACACS Response Invalid
• SNMP Authentication Failure
NOTE
All alarms and log messages related to login authentication are configurable. For more information about configuring alarms, refer to
Section 4.6.4.2
Security Messages for Port Authentication
The following is the list of log and alarm messages related to port access control in RUGGEDCOM ROS:
• MAC Address Authorization Failure
• Secure Port X Learned MAC Addr on VLAN X
• Port Security Violated
Section 4.7
CONTENTS
• Section 4.7.1, “Configuring Data Encryption”
• Section 4.7.2, “Updating the Configuration File”
Section 4.7.1
NOTE
Data encryption is not available in Non-Controlled (NC) versions of RUGGEDCOM ROS. When switching between Controlled and Non-Co
NOTE
Only configuration data is encrypted. All comments and table names in the configuration file are saved as clear text.
NOTE
When sharing a configuration file between devices, make sure both devices have the same passphrase configured. Otherwise, the confi
NOTE
Encryption must be disabled before the device is returned to Siemens or the configuration file is shared with Customer Support.
IMPORTANT!
Never downgrade the RUGGEDCOM ROS software version beyond RUGGEDCOM ROS v4.3 when encryption is enabled. Make sure the d
1. Navigate to Administration » Configure Data Storage . The Data Storage form appears.
3
4 5
Parameter Description
Parameter Description
This passphrase is used as a secret key to encrypt the
configuration data.
Encrypted data can be decrypted by any device configured with
the same passphrase.
3. Click Apply.
Section 4.7.2
• Any text editing program capable of reading and writing ASCII files
• Difference/patching tools (e.g. the UNIX diff and patch command line utilities)
• Source Code Control systems (e.g. CVS, SVN)
CAUTION!
Configuration hazard – risk of data loss. Do not edit an encrypted configuration file. Any line that has been modified manually will b
RUGGEDCOM ROS also has the ability to accept partial configuration updates. For example, to update only the
parameters for Ethernet port 1 and leave all other parameters unchanged, transfer a file containing only the
following lines to the device:
# Port
Parameters
ethPortCfg
Port,Name,Media,State,AutoN,Speed,Dupx,FlowCtrl,LFI,Alarm,
Section 4.8
CONTENTS
• Section 4.8.1, “Managing RADIUS Authentication”
Section 4.8.1
IMPORTANT!
RADIUS messages are sent as UDP messages. The switch and the RADIUS server must use the same authentication and encryption key.
IMPORTANT!
RUGGEDCOM ROS supports both Protected Extensible Authentication Protocol (PEAP) and EAP-MD5. PEAP is more secure and is recom
In a RADIUS access request, the following attributes and values are typically sent by the RADIUS client to the
RADIUS server:
Attribute Value
User-Password { password }
Service-Type 1
Vendor-Specific Vendor-ID: 15004
Type: 1
Length: 11
String: RuggedCom
A RADIUS server may also be used to authenticate access on ports with 802.1X security support. When this is
required, the following attributes are sent by the RADIUS client to the RADIUS server:
Attribute Value
User-Name { The username as derived from the client's EAP identity response }
Frame-MTU 1500
Attribute Value
a
EAP-Message { A message(s) received from the authenticating peer }
a
EAP-Message is an extension attribute for RADIUS, as defined by RFC 2869.
CONTENTS
• Section 4.8.1.1, “Configuring the RADIUS Server”
• Section 4.8.1.2, “Configuring the RADIUS Client”
Section 4.8.1.1
Configuring the RADIUS Server
The Vendor-Specific attribute (or VSA) sent to the RADIUS server as part of the RADIUS request is used to
determine the access level from the RADIUS server. This attribute may be configured within the RADIUS server
with the following information:
Attribute Value
NOTE
If no access level is received in the response packet from the RADIUS server, access is denied.
Section 4.8.1.2
Configuring the RADIUS Client
The RADIUS client can be configured to use two RADIUS servers: a primary server and a backup server. If the
primary server is unavailable, the device will automatically attempt to connect with the backup server.
NOTE
The RADIUS client uses the Password Authentication Protocol (PAP) to verify access.
To configure access to either the primary or backup RADIUS servers, do the following:
1. Navigate to Administration » Configure Security Server » Configure RADIUS Server . The RADIUS Server
table appears.
2. Select either
Figure Primary
74: RADIUS or Backup
Server Table from the table. The RADIUS Server form appears.
4
6
7
5
Parameter Description
4. Click Apply.
Section 4.8.2
CONTENTS
• Section 4.8.2.1, “Configuring TACACS+”
• Section 4.8.2.2, “Configuring User Privileges”
Section 4.8.2.1
Configuring TACACS+
RUGGEDCOM ROS can be configured to use two TACACS+ servers: a primary server and a backup server. If the
primary server is unavailable, the device will automatically attempt to connect with the backup server.
To configure access to either the primary or backup TACACS+ servers, do the following:
1. Navigate to Administration » Configure Security Server » Configure TacPlus Server » Configure TACACS
Plus Server . The TACACS Plus Server table appears.
2. Select
Figureeither Primary
76: TACACS Plusor Backup
Server Tablefrom the table. The TACACS Plus Server form appears.
6 7
5
Parameter Description
4. Set the privilege levels for each user type (i.e. admin, operator and guest). For more information, refer
to Section 4.8.2.2, “Configuring User Privileges” .
5. Click Apply.
Section 4.8.2.2
Configuring User Privileges
Each TACACS+ authentication request includes a priv_lvl attribute that is used to grant access to the device. By
default, the attribute uses the following ranges:
• 15 represents the admin access level
• 2-14 represents the operator access level
• 1 represents the guest access level
To configure the privilege levels for each user type, do the following:
1. Navigate to Administration » Configure Security Server » Configure TacPlus Server » Configure
TACPLUS Serv Privilege Config . The TACPLUS Serv Privilege Config form appears.
3
4 5
Parameter Description
3. Click Apply.
CONTENTS
• Section 5.1, “Managing Virtual LANs”
• Section 5.2, “Managing Spanning Tree Protocol”
• Section 5.3, “Managing Classes of Service”
• Section 5.4, “Managing MAC Addresses”
• Section 5.5, “Managing Time Services”
• Section 5.6, “Managing SNMP”
• Section 5.7, “Managing Network Discovery”
• Section 5.8, “Managing Multicast Filtering”
• Section 5.9, “Managing DHCP”
• Section 5.10, “Managing Port Security”
• Section 5.11, “Managing Link Aggregation”
Section 5.1
For more information about VLANs, refer to Section 5.1.1, “VLAN Concepts” .
CONTENTS
• Section 5.1.1, “VLAN Concepts”
• Section 5.1.2, “Viewing a List of VLANs”
• Section 5.1.3, “Configuring VLANs Globally”
• Section 5.1.4, “Configuring VLANs for Specific Ethernet Ports”
• Section 5.1.5, “Managing Static VLANs”
Section 5.1.1
VLAN Concepts
The following section describes some of the concepts important to the implementation of VLANs in RUGGEDCOM
ROS.
CONTENTS
• Section 5.1.1.1, “Tagged vs. Untagged Frames”
• Section 5.1.1.2, “Native VLAN”
• Section 5.1.1.3, “The Management VLAN”
• Section 5.1.1.4, “Edge and Trunk Port Types”
• Section 5.1.1.5, “Ingress and Egress Rules”
• Section 5.1.1.6, “Forbidden Ports List”
• Section 5.1.1.7, “VLAN-Aware and VLAN-Unaware Modes”
• Section 5.1.1.8, “GARP VLAN Registration Protocol (GVRP)”
• Section 5.1.1.9, “PVLAN Edge”
• Section 5.1.1.10, “QinQ”
• Section 5.1.1.11, “VLAN Advantages”
Section 5.1.1.1
Tagged vs. Untagged Frames
VLAN tags identify frames as part of a VLAN network. When a switch receives a frame with a VLAN (or 802.1Q)
tag, the VLAN identifier (VID) is extracted and the frame is forwarded to other ports on the same VLAN.
When a frame does not contain a VLAN tag, or contains an 802.1p (prioritization) tag that only has prioritization
information and a VID of 0, it is considered an untagged frame.
Section 5.1.1.3
The Management VLAN
Management traffic, like all traffic on the network, must belong to a specific VLAN. The management VLAN is
configurable and always defaults to VLAN 1. This VLAN is also the default native VLAN for all ports, thus allowing
all ports the possibility of managing the product. Changing the management VLAN can be used to restrict
management access to a specific set of users.
Section 5.1.1.4
Edge and Trunk Port Types
Each port can be configured as an edge or trunk port.
An edge port attaches to a single end device, such as a PC or Intelligent Electronic Device (IED). An edge port
carries traffic on the native VLAN.
Trunk ports are part of the network and carry traffic for all VLANs between switches. Trunk ports are automatically
members of all VLANs configured in the switch.
The switch can 'pass through' traffic, forwarding frames received on one trunk port out of another trunk port. The
trunk ports must be members of all VLANs that the 'pass through' traffic is part of, even if none of those VLANs are
used on edge ports.
Frames transmitted out of the port on all VLANs other than the port's native VLAN are always sent tagged.
NOTE
It may be desirable to manually restrict the traffic on the trunk to a specific group of VLANs. For example, when the trunk connects to a
For more information about the Forbidden Ports list, refer to .
Edge 1 (Native) Untagged VLAN Unaware Networks: All frames are sent and received without
Configured the need for VLAN tags.
Trunk All Configured Tagged or Untagged Switch-to-Switch Connections: VLANs must be manually created and
administered, or can be dynamically learned through GVRP.
Multiple-VLAN End Devices: Implement connections to end devices
that support multiple VLANs at the same time.
a Priority Tagged
Frame Received (VID = 0)
Untagged Tagged (Valid VID)
VLAN ID associated with the frame PVID PVID VID in the Tag
a
Does not depend on the ingress port's VLAN configuration parameters.
Egress rules are applied as follows to all frames when they are transmitted by the switch.
On Other VLAN
Section 5.1.1.6
Forbidden Ports List
Each VLAN can be configured to exclude ports from membership in the VLAN using the forbidden ports list. For
more information, refer to Section 5.1.5.2, “Adding a Static VLAN” .
Section 5.1.1.7
VLAN-Aware and VLAN-Unaware Modes
The native operation mode for an IEEE 802.1Q compliant switch is VLAN-aware. Even if a specific network
architecture does not use VLANs, RUGGEDCOM ROS's default VLAN settings allow the switch to still operate in a
VLAN-aware mode, while providing functionality required for almost any network application. However, the IEEE
802.1Q standard defines a set of rules that must be followed by all VLAN-aware switches:
• Valid VIDs are within the range of 1 to 4094. VIDs equal to 0 or 4095 are invalid.
• Each frame ingressing a VLAN-aware switch is associated with a valid VID.
• Each frame egressing a VLAN-aware switch is either untagged or tagged with a valid VID. Priority-tagged frames
with an invalid VID will never sent out by a VLAN-aware switch.
NOTE
Some applications have requirements conflicting with IEEE 802.Q1 native mode of operation. For example, some applications expli
To avoid conflicts and provide full compatibility with legacy (VLAN-unaware) devices, RUGGEDCOM ROS can be configured to work
In that mode:
Frames ingressing a VLAN-unaware device are not associated with any VLAN
Frames egressing a VLAN-unaware device are sent out unmodified (i.e. in the same untagged, 802.1Q-tagged or priority-tagged format
Section 5.1.1.8
GARP VLAN Registration Protocol (GVRP)
GARP VLAN Registration Protocol (GVRP) is a standard protocol built on GARP (Generic Attribute Registration
Protocol) to automatically distribute VLAN configuration information in a network. Each switch in a network needs
only to be configured with VLANs it requires locally. VLANs configured elsewhere in the network are learned
through GVRP. A GVRP-aware end station (i.e. PC or Intelligent Electronic Device) configured for a particular VID
can be connected to a trunk on a GVRP-aware switch and automatically become part of the desired VLAN.
When a switch sends GVRP bridge protocol data units (BPDUs) out of all GVRP-enabled ports, GVRP BPDUs advertise
all the VLANs known to that switch (configured manually or learned dynamically through GVRP) to the rest of the
network.
When a GVRP-enabled switch receives a GVRP BPDU advertising a set of VLANs, the receiving port becomes a
member of those advertised VLANs and the switch begins advertising those VLANs through all the GVRP-enabled
ports (other than the port on which the VLANs were learned).
To improve network security using VLANs, GVRP-enabled ports may be configured to prohibit the learning of any
new dynamic VLANs but at the same time be allowed to advertise the VLANs configured on the switch.
The following is an example of how to use GVRP:
D2 D
D1
B3 B
B1 B2
B4
A1 A E1 E C1 C
1
A2 E2 C2
A E C 2
For more information about how to configure GVRP, refer to Section 5.1.4, “Configuring VLANs for Specific
Ethernet Ports” .
Section 5.1.1.9
PVLAN Edge
Private VLAN (PVLAN) Edge isolates multiple VLAN Edge ports from each other on a single device. When VLAN
Edge ports are configured as protected, they are prohibited from sending frames to one another, but are still
permitted to send frames to other, non-protected ports within the same VLAN. This protection extends to all traffic
on the VLAN, including unicast, multicast and broadcast traffic.
For more information about how to configure a port as protected, refer to Section 5.1.4, “Configuring VLANs
for Specific Ethernet Ports” .
NOTE
This feature is strictly local to the switch. PVLAN Edge ports are not prevented from communicating with ports outside of the switch, w
Section 5.1.1.10
QinQ
QinQ, also referred to as Stacked VLANs, port bridging, double VLAN-tagging and Nested VLANs, is used to
overlay a private Layer 2 network over a public Layer 2 network.
A large network service provider, for example, might have several clients whose networks each use multiple
VLANs. It is likely the VLAN IDs used by these different client networks would conflict with one another, were
they mixed together in the provider's network. Using double QinQ, each client network could be further tagged
using a client-specific VID at the edges where the clients' networks are connected to the network service provider's
infrastructure.
Any tagged frames ingressing an edge port of the service provider's switch are tagged with VIDs of the customer’s
private network. When those frames egress the switch's QinQ-enabled port into the service provider network, the
switch always adds an extra tag (called an outer tag) on top of the frame's original VLAN tag (called an inner tag).
The outer tag VID is the PVID of the frame's ingress edge port. This means that traffic from an individual customer
is tagged with their unique VID and is thus segregated from other customer's traffic. For untagged ingress frames,
the switch will only add the outer VLAN tag.
Within the service provider network, switching is based on the VID in the outer tag.
When double-tagged frames leave the service provider network, they egress a QinQ-enabled port of another
switch. The switch strips the outer tag while associating the frames with the VID extracted from it before
stripping. Thus, the frames are switched to appropriate edge ports ( i.e. customers).
The following figure shows an example of traffic flow using
QinQ. For tagged frames:
• Frames received from customer 1 with VID 100 would carry an inner tag of 100 and an outer tag of VID X
(i.e. VLAN 110) which is configured on the edge port connected to customer 1.
• Next, the frames from customer 1 are forwarded through the QinQ port carrying an inner and an outer tag.
• Finally, upon arrival of the frames in the peer switch, the outer VLAN tag is removed and the frames are
forwarded with the inner VLAN tag towards customer 1.
For untagged frames:
• Frames received from customer 2 would carry an outer tag of VID Y(i.e VLAN 220) which is configured on
the edge port connected to customer 2.
• Next, the frames from customer 2 are forwarded through the QinQ port carrying the outer tag.
• Finally, upon arrival of the frames in the peer switch, the outer VLAN tag is removed before the frames are
forwarded to customer 2.
2 1
5 5
4 4
1 2
NOTE
Depending on the hardware installed, some switch models allow only one switch port be configured to QinQ mode at a time.
NOTE
When QinQ is enabled, all non-QinQ ports will be untagged and cannot be changed, and all QinQ ports will be tagged, and cannot b
Section 5.1.1.11
VLAN Advantages
The following are a few of the advantages offered by VLANs.
144 VLAN
Advantages
RUGGEDCOM ROS Chapter 5
User Guide Setup and
Configuration
1 3
2 4
5
Administrative Convenience
VLANs enable equipment moves to be handled by software reconfiguration instead of by physical cable
management. When a host's physical location is changed, its connection point is often changed as well. With
VLANs, the host's VLAN membership and priority are simply copied to the new port.
Reduced Hardware
Without VLANs, traffic domain isolation requires the use of separate bridges for separate networks. VLANs
eliminate the need for separate bridges.
The number of network hosts may often be reduced. Often, a server is assigned to provide services for
independent networks. These hosts may be replaced by a single, multi-horned host supporting each network on
its own VLAN. This host can perform routing between VLANs.
Multi-VLAN hosts can assign different traffic types to different VLANs.
VLAN 145
Advantages
Chapter 5 RUGGEDCOM ROS
Setup and User Guide
Configuration
199.85.245.1/25
1 4
199.85.245.128/26
199.85.245.192/26
Section 5.1.2
Section 5.1.3
4 5
Parameter Description
NOTE
Ingress filtering has no effect when ports are
in either VLAN-unaware mode or Q-in-Q
mode.
NOTE
When QinQ is enabled, all non-QinQ ports will
be untagged and cannot be changed, and all
3. Click Apply.
6 7
5
Parameter Description
Parameter Description
Default: Edge
This parameter specifies how the port determines its membership
in VLANs. There are few types of ports:
• Edge - the port is only a member of one VLAN (its native VLAN
specified by the PVID parameter).
• Trunk - the port is automatically a member of all configured
VLANs. Frames transmitted out of the port on all VLANs
except the port's native VLAN will be always tagged. It can
also be configured to use GVRP for automatic VLAN
configuration.
• PVLANEdge - the port is only a member of one VLAN (its native
VLAN specified by the PVID parameter), and does not
forward traffic to other PVLANedge ports within the same
VLAN.
• QinQ - the port is a trunk port using double-VLAN tagging, or
nested VLANs. An extra VLAN tag is always added to all frames
egressing this port. VID in the added extra tag is the PVID of the
frame's ingress port. VLAN tag is always stripped from frames
ingressing this port.
NOTE
Depending on the hardware installed, some
switch models allow only one switch port
PVID Synopsis: 1 to 4094
Default: 1
The Port VLAN Identifier specifies the VLAN ID associated with
untagged (and 802.1p priority tagged) frames received on this
port.
Frames tagged with a non-zero VLAN ID will always be associated
with the VLAN ID retrieved from the frame tag.
Modify this parameter with care! By default, the switch is
programmed to use VLAN 1 for management and every port on
the switch is programmed to use VLAN 1. If you modify a switch
port to use a VLAN other than the management VLAN, devices on
that port will not be able to manage the switch.
NOTE
When QinQ is enabled, all non-QinQ ports will
be untagged and cannot be changed, and all
QinQ ports will be tagged, and cannot be
changed.
4. Click Apply.
Section 5.1.5
CONTENTS
• Section 5.1.5.1, “Viewing a List of Static VLANs”
• Section 5.1.5.2, “Adding a Static VLAN”
• Section 5.1.5.3, “Deleting a Static VLAN”
Section 5.1.5.1
Viewing a List of Static VLANs
To view a list of static VLANs, navigate to Virtual LANs » Configure Static VLANs . The Static VLANs table
appears.
Section 5.1.5.2
Adding a Static VLAN
To add a static VLAN, do the following:
1. Navigate to Virtual LANs » Configure Static VLANs . The Static VLANs table appears.
7 9
6
Parameter Description
Parameter Description
The VLAN Identifier is used to identify the VLAN in tagged
Ethernet frames according to IEEE 802.1Q.
Forbidden Ports Synopsis: Any combination of numbers valid for this parameter
These are ports that are not allowed to be members of the VLAN.
Examples:
• None - all ports of the switch are allowed to be members of the
VLAN
• 2,4-6,8 - all ports except ports 2, 4, 6, 7 and 8 are allowed to be
members of the VLAN
MSTI Synopsis: 0 to 16
Default: 0
This parameter is only valid for Multiple Spanning Tree Protocol
(MSTP) and has no effect if MSTP is not used. The parameter
specifies the Multiple Spanning Tree Instance (MSTI) to which the
VLAN should be mapped.
4. Click Apply.
Section 5.1.5.3
Deleting a Static VLAN
To delete a static VLAN, do the following:
1. Navigate to Virtual LANs » Configure Static VLANs . The Static VLANs table appears.
2. Select the
Figure 90:static
Static VLAN
VLANs from
Table the table. The Static VLANs form appears.
7 9
6
3. Click Delete.
Section 5.2
Section 5.2.1
RSTP Operation
The 802.1D Spanning Tree Protocol (STP) was developed to enable the construction of robust networks that
incorporate redundancy while pruning the active topology of the network to prevent loops. While STP is effective,
it requires that frame transfer halt after a link outage until all bridges in the network are guaranteed to be aware
of the new topology. Using the values recommended by 802.1D, this period lasts 30 seconds.
The Rapid Spanning Tree Protocol (RSTP, IEEE 802.1w) was a further evolution of the 802.1D Spanning Tree
Protocol. It replaced the settling period with an active handshake between bridges that guarantees the rapid
propagation of topology information throughout the network. RSTP also offers a number of other significant
innovations, including:
• Topology changes in RSTP can originate from and be acted upon by any designated bridges, leading to more
rapid propagation of address information, unlike topology changes in STP, which must be passed to the root
bridge before they can be propagated to the network.
• RSTP explicitly recognizes two blocking roles - Alternate and Backup Port - which are included in computations
of when to learn and forward. STP, however, recognizes only one state - Blocking - for ports that should not
forward.
• RSTP bridges generate their own configuration messages, even if they fail to receive any from the root bridge.
This leads to quicker failure detection. STP, by contrast, must relay configuration messages received on the root
port out its designated ports. If an STP bridge fails to receive a message from its neighbor, it cannot be sure
where along the path to the root a failure occurred.
• RSTP offers edge port recognition, allowing ports at the edge of the network to forward frames immediately
after activation, while at the same time protecting them against loops.
While providing much better performance than STP, IEEE 802.1w RSTP still required up to several seconds to
restore network connectivity when a topology change occurred.
A revised and highly optimized RSTP version was defined in the IEEE standard 802.1D-2004 edition. IEEE
802.1D-2004 RSTP reduces network recovery times to just milliseconds and optimizes RSTP operation for
various scenarios.
RUGGEDCOM ROS supports IEEE 802.1D-2004 RSTP.
CONTENTS
• Section 5.2.1.1, “RSTP States and Roles”
• Section 5.2.1.2, “Edge Ports”
• Section 5.2.1.3, “Point-to-Point and Multipoint Links”
• Section 5.2.1.4, “Path and Port Costs”
• Section 5.2.1.5, “Bridge Diameter”
• Section 5.2.1.6, “eRSTP”
Section 5.2.1.1
RSTP States and Roles
RSTP bridges have roles to play, either root or designated. One bridge - the Root Bridge - is the logical center of
the network. All other bridges in the network are Designated bridges. RSTP also assigns each port of the bridge a
state and a role. The RSTP state describes what is happening at the port in relation to address learning and frame
forwarding. The RSTP role basically describes whether the port is facing the center or the edges of the network
and whether it can currently be used.
State
There are three RSTP states: Discarding, Learning and Forwarding.
The discarding state is entered when the port is first put into service. The port does not learn addresses in this
state and does not participate in frame transfer. The port looks for RSTP traffic in order to determine its role in
the network. When it is determined that the port will play an active part in the network, the state will change to
learning.
The learning state is entered when the port is preparing to play an active part in the network. The port learns
addresses in this state but does not participate in frame transfer. In a network of RSTP bridges, the time spent in
this state is usually quite short. RSTP bridges operating in STP compatibility mode will spend six to 40 seconds in
this state.
After learning, the bridge will place the port in the forwarding state. The port both learns addresses and
participates in frame transfer while in this state.
IMPORTANT!
RUGGEDCOM ROS introduces two more states - Disabled and Link Down. Introduced purely for purposes of management, these states
RSTP is enabled but are currently down.
Role
There are four RSTP port roles: Root, Designated, Alternate and Backup. If the bridge is not the root bridge, it must
have a single Root Port. The Root Port is the "best” (i.e. quickest) way to send traffic to the root bridge.
A port is marked as Designated if it is the best port to serve the LAN segment it is connected to. All bridges on the
same LAN segment listen to each others’ messages and agree on which bridge is the Designated Bridge. The ports
of other bridges on the segment must become either Root, Alternate or Backup ports.
1
C 3
1 2
3 3
4 4
1 1
2 2
2 3 2
5 6 3
A port is alternate when it receives a better message from another bridge on the LAN segment it is connected to.
The message that an Alternate Port receives is better than the port itself would generate, but not good enough to
convince it to become the Root Port. The port becomes the alternate to the current Root Port and will become the
new Root Port should the current Root Port fail. The Alternate Port does not participate in the network.
A port is a Backup Port when it receives a better message from the LAN segment it is connected to, originating
from another port on the same bridge. The port is a backup for another port on the bridge and will become active
if that port fails. The Backup Port does not participate in the network.
Section 5.2.1.2
Edge Ports
A port may be designated as an Edge Port if it is directly connected to an end station. As such, it cannot create
bridging loops in the network and can thus directly transition to forwarding, skipping the listening and learning
stages.
Edge ports that receive configuration messages immediately lose their Edge Port status and become normal
spanning tree ports. A loop created on an improperly connected edge port is thus quickly repaired.
Because an Edge Port services only end stations, topology change messages are not generated when its link
toggles.
Section 5.2.1.4
Path and Port Costs
The STP path cost is the main metric by which root and designated ports are chosen. The path cost for a
designated bridge is the sum of the individual port costs of the links between the root bridge and that designated
bridge. The port with the lowest path cost is the best route to the root bridge and is chosen as the root port.
NOTE
In actuality the primary determinant for root port selection is the root bridge ID. Bridge ID is important mainly at network startup when
To remedy this problem in future applications, the IEEE 802.1w specification limits port costs to values of 1 to
20000000, and a link speed up to 10 Tb per second can be represented with a value of 2.
RUGGEDCOM bridges support interoperability with legacy STP bridges by selecting the style to use. In practice,
it makes no difference which style is used as long as it is applied consistently across the network, or if costs are
manually assigned.
Section 5.2.1.5
Bridge Diameter
The bridge diameter is the maximum number of bridges between any two possible points of attachment of end
stations to the network.
The bridge diameter reflects the realization that topology information requires time to propagate hop by hop
through a network. If configuration messages take too long to propagate end to end through the network, the
result will be an unstable network.
There is a relationship between the bridge diameter and the maximum age parameter. To achieve extended ring
sizes, Siemens eRSTP™ uses an age increment of ¼ of a second. The value of the maximum bridge diameter is thus
four times the configured maximum age parameter.
NOTE
The RSTP algorithm is as follows:
STP configuration messages contain age information.
Messages transmitted by the root bridge have an age of 0. As each subsequent designated bridge transmits the configuration mess
When the age exceeds the value of the maximum age parameter the next bridge to receive the message immediately discards it.
IMPORTANT!
Raise the value of the maximum age parameter if implementing very large bridged networks or rings.
Section 5.2.1.6
eRSTP
Siemens's enhanced Rapid Spanning Tree Protocol (eRSTP) improves the performance of RSTP in two ways:
• Improves the fault recovery time performance (< 5 ms per hop)
• Improves performance for large ring network topologies (up to 80 switches)
eRSTP is also compatible with standard RSTP for interoperability with commercial switches.
For example, in a network comprised of 15 RUGGEDCOM hardened Ethernet switches in a ring topology, the
expected fault recovery time would be less than 75 ms (i.e. 5 ms x 15). However, with eRSTP, the worst case
fault recovery time is less than 26 ms.
Section 5.2.2
RSTP Applications
The following section describes various applications of RSTP.
CONTENTS
• Section 5.2.2.1, “RSTP in Structured Wiring Configurations”
Section 5.2.2.1
RSTP in Structured Wiring Configurations
RSTP may be used to construct structured wiring systems where connectivity is maintained in the event of link
failures. For example, a single link failure of any link between A and N in Figure 93 would leave all the ports of
bridges 555 through 888 connected to the network.
1 A 1
111222
2B2
4343
C F
D E
1 2 1 2
444 444
6363
5454
G I H K J M L N
1 2 1 2 1 2 1 2
Section 5.2.2.2
RSTP in Ring Backbone Configurations
RSTP may be used in ring backbone configurations where rapid recovery from link failure is required. In normal
operation, RSTP will block traffic on one of the links, for example, as indicated by the double bars through link H
in Figure 94 . In the event of a failure on link D, bridge 444 will unblock link H. Bridge 333 will communicate with
the network through link F.
A 1
111 222
B 1 2 C
33
L D
1
K 3 666333
2 E
2 3
J F
1 1
I 3 2 H 3
555 444
2 G
Section 5.2.2.3
RSTP Port Redundancy
In cases where port redundancy is essential, RSTP allows more than one bridge port to service a LAN. In the
following example, if port 3 is designated to carry the network traffic of LAN A, port 4 will block traffic. Should an
interface failure occur on port 3, port 4 will assume control of the LAN.
1 2
4 3
Section 5.2.3
MSTP Operation
The Multiple Spanning Tree (MST) algorithm and protocol provide greater control and flexibility than RSTP and
legacy STP. MSTP (Multiple Spanning Tree Protocol) is an extension of RSTP, whereby multiple spanning trees may
be maintained on the same bridged network. Data traffic is allocated to one or another of several spanning trees
by mapping one or more VLANs onto the network.
The sophistication and utility of the Multiple Spanning Tree implementation on a given bridged network is
proportional to the amount of planning and design invested in configuring MSTP.
If MSTP is activated on some or all of the bridges in a network with no additional configuration, the result will be a
fully and simply connected network, but at best, the result will be the same as a network using only RSTP. Taking
full advantage of the features offered by MSTP requires a potentially large number of configuration variables
to be derived from an analysis of data traffic on the bridged network, and from requirements for load sharing,
redundancy, and path optimization. Once these parameters have all been derived, it is also critical that they are
consistently applied and managed across all bridges in an MST region.
By design, MSTP processing time is proportional to the number of active STP instances. This means that MSTP will
likely be significantly slower than RSTP. Therefore, for mission critical applications, RSTP should be considered a
better network redundancy solution than MSTP.
CONTENTS
• Section 5.2.3.1, “MSTP Regions and Interoperability”
• Section 5.2.3.2, “MSTP Bridge and Port Roles”
• Section 5.2.3.3, “Benefits of MSTP”
• Section 5.2.3.4, “Implementing MSTP on a Bridged Network”
Section 5.2.3.1
MSTP Regions and Interoperability
In addition to supporting multiple spanning trees in a network of MSTP-capable bridges, MSTP is capable of inter-
operating with bridges that support only RSTP or legacy STP, without requiring any special configuration.
An MST region may be defined as the set of interconnected bridges whose MST Region Identification is identical.
The interface between MSTP bridges and non-MSTP bridges, or between MSTP bridges with different MST Region
Identification information, becomes part of an MST Region boundary.
Bridges outside an MST region will see the entire region as though it were a single (R)STP bridge; the internal
detail of the MST region is hidden from the rest of the bridged network. In support of this, MSTP maintains
separate hop counters for spanning tree information exchanged at the MST region boundary versus that
propagated inside the region. For information received at the MST region boundary, the (R)STP Message Age is
incremented only once. Inside the region, a separate Remaining Hop Count is maintained, one for each spanning
tree instance. The external Message Age parameter is referred to the (R)STP Maximum Age Time, whereas the
internal Remaining Hop Counts are compared to an MST region-wide Maximum Hops parameter.
MSTI
An MSTI (Multiple Spanning Tree Instance) is one of sixteen independent spanning tree instances that may be
defined in an MST region (not including the IST – see below). An MSTI is created by mapping a set of VLANs (in
RUGGEDCOM ROS, via the VLAN configuration) to a given MSTI ID. The same mapping must be configured on all
bridges that are intended to be part of the MSTI. Moreover, all VLAN to MSTI mappings must be identical for all
bridges in an MST region.
RUGGEDCOM ROS supports 16 MSTIs in addition to the IST.
Each MSTI has a topology that is independent of every other. Data traffic originating from the same source and
bound to the same destination but on different VLANs on different MSTIs may therefore travel a different path
across the network.
IST
An MST region always defines an IST (Internal Spanning Tree). The IST spans the entire MST region, and carries all
data traffic that is not specifically allocated (by VLAN) to a specific MSTI. The IST is always computed and is defined
to be MSTI zero.
The IST is also the extension inside the MST region of the CIST (see below), which spans the entire bridged
network, inside and outside of the MST region and all other RSTP and STP bridges, as well as any other MST
regions.
CST
The CST (Common Spanning Tree) spans the entire bridged network, including MST regions and any connected
STP or RSTP bridges. An MST region is seen by the CST as an individual bridge, with a single cost associated with its
traversal.
CIST
The CIST (Common and Internal Spanning Tree) is the union of the CST and the ISTs in all MST regions. The CIST
therefore spans the entire bridged network, reaching into each MST region via the latter’s IST to reach every
bridge on the network.
Section 5.2.3.2
MSTP Bridge and Port Roles
MSTP supports the following bridge and port roles:
Bridge Roles
Role Description
CIST Root The CIST Root is the elected root bridge of the CIST (Common and
Internal Spanning Tree), which spans all connected STP and RSTP
bridges and MSTP regions.
CIST Regional Root The root bridge of the IST within an MSTP region. The CIST Regional
Root is the bridge within an MSTP region with the lowest cost path
to the CIST Root. Note that the CIST Regional Root will be at the
boundary of an MSTP region. Note also that it is possible for the CIST
Regional Root to be the CIST Root.
MSTI Regional Root The root bridge for an MSTI within an MSTP region. A root bridge is
independently elected for each MSTI in an MSTP region.
Port Roles
Each port on an MSTP bridge may have more than one CIST role depending on the number and topology of
spanning tree instances defined on the port.
Role Description
CIST Port Roles The Root Port provides the minimum cost path from the bridge
to the CIST Root via the CIST Regional Root. If the bridge itself happens to be the
A Designated Port provides the minimum cost path from an attached LAN, via th
Role Description
• Alternate and Backup Ports function the same as they do in RSTP,
but relative to the CIST Regional Root.
Section 5.2.3.3
Benefits of MSTP
Despite the fact that MSTP is configured by default to arrive automatically at a spanning tree solution for each
configured MSTI, advantages may be gained from influencing the topology of MSTIs in an MST region. The fact
that the Bridge Priority and each port cost are configurable per MST makes it possible to control the topology of
each MSTI within a region.
Load Balancing
MSTP can be used to balance data traffic load among sets of VLANs, enabling more complete utilization of a
multiply interconnected bridged network.
A bridged network controlled by a single spanning tree will block redundant links by design, in order to avoid
harmful loops. Using MSTP, however, any given link may have a different blocking state for MSTI, as maintained
by MSTP. Any given link, therefore, might be in blocking state for some VLANs, and in forwarding state for other
VLANs, depending on the mapping of VLANs to MSTIs.
It is possible to control the spanning tree solution for each MSTI, especially the set of active links for each tree,
by manipulating, per MSTI, the bridge priority and the port costs of links in the network. If traffic is allocated
judiciously to multiple VLANs, redundant interconnections in a bridged network which, using a single spanning
tree, would have gone unused, can now be made to carry traffic.
Section 5.2.3.4
Implementing MSTP on a Bridged Network
It is recommended the configuration of MSTP on a network proceed in the sequence outlined below.
Naturally, it is also recommended that network analysis and planning inform the steps of configuring the VLAN
and MSTP parameters in particular.
Begin with a set of MSTP-capable Ethernet bridges and MSTP disabled. For each bridge in the network:
NOTE
MSTP does not need to be enabled to map a VLAN to an MSTI. However, the mapping must be identical for each bridge that belongs to
1. Configure and enable STP globally and/or for specific Ethernet ports. For more information, refer to
Section 5.2.4, “Configuring STP Globally” or Section 5.2.5, “Configuring STP for Specific Ethernet Ports” .
NOTE
Static VLANs must be used in an MSTP configuration. GVRP is not supported.
2. Add static VLANs and map them to MSTIs. For more information, refer to Section 5.1.5.2, “Adding a
Static VLAN” .
NOTE
The Region Identifier and Revision Level must be the same for each bridge in the MST region.
3. Configure the revision level for the MST Region Identifier. For more information, refer to Section
5.2.9.3, “Configuring the MST Region Identifier” .
4. Make sure the read-only digest for the MST Region Identifier is identical for each bridge in the MST region. If
the digest is different, the set of mappings from VLANs to MSTIs differs.
5. Configure the Bridge Priority for the global MSTI. For more information, refer to Section 5.2.9.4,
“Configuring a Global MSTI” .
6. Configure the Port Cost and Priority per Port for each MSTI. For more information, refer to Section
5.2.9.5, “Configuring an MSTI for an Ethernet Port” .
7. Set the STP Protocol Version to MSTP and enable STP. For more information, refer to Section 5.2.4,
“Configuring STP Globally”
Section 5.2.4
7
9 10
8
Parameter Description
Parameter Description
Bridge Priority provides a way to control the topology of the STP
connected network. The desired Root and Designated bridges
can be configured for a particular topology. The bridge with the
lowest priority will become root. In the event of a failure of the
root bridge, the bridge with the next lowest priority will then
become root. Designated bridges that (for redundancy purposes)
service a common LAN also use priority to determine which
bridge is active. In this way careful selection of Bridge Priorities
can establish the path of traffic flows in normal and abnormal
conditions.
Synopsis: 6 to 40
Default: 20
Max Hops
Only applicable to MSTP. The maximum possible bridge diameter
inside an MST region.
MSTP BPDUs propagating inside an MST region specify a time-
to-live that is decremented by every switch that propagates the
BPDU. If the maximum number of hops inside the region exceeds
the configured maximum, BPDUs may be discarded due to their
time-to-live setting.
3. Click Apply.
Section 5.2.5
10 8
11
9
Figure 98: Port RSTP Parameters Form
1. Port(s) Box2. Enabled Options3. Priority List4. STP Cost Box5. RSTP Cost Box6. Edge Port List7. Point to Point List
8. Restricted Role Box9. Restricted TCN Box10. Apply Button11. Reload Button
Parameter Description
Parameter Description
Enabling STP activates the STP or RSTP protocol for this port per
the configuration in the STP Configuration menu. STP may be
disabled for the port ONLY if the port does not attach to an STP
enabled bridge in any way. Failure to meet this requirement WILL
result in an undetectable traffic loop in the network. A better
alternative to disabling the port is to leave STP enabled but to
configure the port as an edge port. A good candidate for disabling
STP would be a port that services only a single host computer.
Priority Synopsis: { 0, 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176,
194, 208, 224, 240 }
Default: 128
Selects the STP port priority. Ports of the same cost that attach to
a common LAN will select the port to be used based upon the port
priority.
Parameter Description
cannot run the link in full-duplex mode. Force the parameter false
when the port operates the link in full-duplex mode, but is still not
point-to-point (e.g. a full-duplex link to an unmanaged bridge that
concentrates two other STP bridges).
4. Click Apply.
Section 5.2.6
Configuring eRSTP
To configure eRSTP, do the following:
1. Navigate to Spanning Tree » Configure eRSTP Parameters . The eRSTP Parameters form appears.
5
6
7
Parameter Description
NOTE
• This feature is only available in RSTP mode.
In MSTP mode, the configuration parameter
is ignored.
• In a single ring topology, this feature is not
needed and should be disabled to avoid
longer network recovery times due to extra
RSTP processing.
Parameter Description
These are the supported configuration options:
• Off - Fast Root Failover algorithm is disabled and hence a root
switch failure may result in excessive connectivity recovery
time.
• On - Fast Root Failover is enabled and the most robust
algorithm is used, which requires the appropriate support in the
root switch.
• On with standard root - Fast Root Failover is enabled but a
"relaxed" algorithm is used, allowing the use of a standard
switch in the root role.
3. Click Apply.
Section 5.2.7
Parameter Description
Bridge Status Synopsis: { , Designated Bridge, Not Designated For Any LAN,
Root Bridge }
Spanning Tree status of the bridge. The status may be root or
designated. This field may show text saying not designated for any
LAN if the bridge is not designated for any of its ports.
1. Bridge Status Box2. Bridge ID Box3. Root ID Box4. Root Port Box
7. Learned
Bridge ID Hello Time Box8. Configured Forward Delay Box9. Learned Forward Delay Box10.
Synopsis: $$ /Configured Max Age where
##-##-##-##-##-## Box11. $$
Learned Max
is 0 to Age Box12.
65535, ## is 0Total Topology Change
to FF
Bridge Identifier of this bridge.
Synopsis: 0 to 4294967295
Root Path Cost
Total cost of the path to the root bridge composed of the sum
of the costs of each link in the path. If custom costs have not
been configured. 1Gbps ports will contribute 4, 100 Mbps
ports will
contribute 19 and 10 Mbps ports will contribute a cost of 100 to this
figure.
For the CIST instance of MSTP, this is an external root path cost,
which is the cost of the path from the IST root (i.e. regional root)
Configured Hello Time Synopsis: 0 to 65535
The configured Hello time from the Bridge RSTP Parameters menu.
Parameter Description
The actual Hello time provided by the root bridge as learned in
configuration messages. This time is used in designated bridges.
Section 5.2.8
Parameter Description
Parameter Description
The count of STP topology change notification messages received
on this port. Excessively high or rapidly increasing counts signal
network problems.
Section 5.2.9
CONTENTS
• Section 5.2.9.1, “Viewing Statistics for Global MSTIs”
• Section 5.2.9.2, “Viewing Statistics for Port MSTIs”
• Section 5.2.9.3, “Configuring the MST Region Identifier”
• Section 5.2.9.4, “Configuring a Global MSTI”
• Section 5.2.9.5, “Configuring an MSTI for an Ethernet Port”
Section 5.2.9.1
Viewing Statistics for Global MSTIs
To view statistics for global MSTIs, navigate to Spanning Tree » View Bridge MSTI Statistics . The Bridge MSTI
Statistics form appears.
1 2
Parameter Description
Bridge Status Synopsis: { , Designated Bridge, Not Designated For Any LAN,
Root Bridge }
Spanning Tree status of the bridge. The status may be root or
designated. This field may show text saying not designated for any
LAN if the bridge is not designated for any of its ports.
Synopsis: 0 to 4294967295
Root Path Cost
Total cost of the path to the root bridge composed of the sum
of the costs of each link in the path. If custom costs have not
been configured. 1Gbps ports will contribute 4, 100 Mbps
ports will
contribute 19 and 10 Mbps ports will contribute a cost of 100 to this
figure.
For the CIST instance of MSTP, this is an external root path cost,
which is the cost of the path from the IST root (i.e. regional root)
Total Topology Changes Synopsis: 0 to 65535
A count of topology changes in the network, as detected on this
bridge through link failures or as signaled from other bridges.
Parameter Description
Excessively high or rapidly increasing counts signal
network problems.
Section 5.2.9.2
Viewing Statistics for Port MSTIs
To view statistics for port MSTIs, navigate to Spanning Tree » View Port MSTI Statistics . The Port MSTI
Statistics form appears.
1 2
Parameter Description
Parameter Description
Role of this port in Spanning Tree. This may be one of the following:
• Designated - The port is designated for (i.e. carries traffic towards
the root for) the LAN it is connected to.
• Root - The single port on the bridge, which provides connectivity
towards the root bridge.
• Backup - The port is attached to a LAN that is serviced by another
port on the bridge. It is not used but is standing by.
• Alternate - The port is attached to a bridge that provides
connectivity to the root bridge. It is not used but is standing by.
• Master - Only exists in MSTP. The port is an MST region boundary
port and the single port on the bridge, which provides connectivity
for the Multiple Spanning Tree Instance towards the Common
Spanning Tree root bridge (i.e. this port is the root port for the
Common Spanning Tree Instance).
Section 5.2.9.3
Configuring the MST Region Identifier
Configuring the region identifier and revision level puts the MSTP bridge in a defined group. Other bridges that
have the same identifier and revision level are interconnected within this region. For more information, refer to
Section 5.2.3.1, “MSTP Regions and Interoperability” .
To configure the Multiple Spanning Tree (MST) region identifier, do the following:
1. Navigate to Spanning Tree » Configure MST Region Identifier . The MST Region Identifier form appears.
3
4 5
Parameter Description
3. Click Apply.
Section 5.2.9.4
Configuring a Global MSTI
To configure a global Multiple Spanning Tree Instance (MSTI) for the Spanning Tree Protocol (STP), do the
following:
1. Navigate to Spanning Tree » Configure Bridge MSTI Parameters . The Bridge MSTI Parameters form
appears.
1 2
4 5
2. Under Instance ID, type an ID number for a Multiple Spanning Tree Instance (MSTI) and click GET. The
settings for the MSTI are displayed. Any changes made to the configuration will be applied specifically to this
instance ID.
3. Configure the following parameter(s) as required:
Parameter Description
4. Click Apply.
Section 5.2.9.5
Configuring an MSTI for an Ethernet Port
To configure a Multiple Spanning Tree Instance (MSTI) for an Ethernet port, do the following
1. Navigate to Spanning Tree » Configure Port MSTI Parameters . The Port MSTI Parameters table appears.
1 2
7 6
8
3. Under Instance ID, type an ID number for a Multiple Spanning Tree Instance (MSTI) and click GET. The
settings for the MSTI are displayed. Any changes made to the configuration will be applied specifically to this
instance ID.
4. Configure the following parameter(s) as required:
Parameter Description
Priority Synopsis: { 0, 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176,
192, 208, 224, 240 }
Default: 128
Selects the STP port priority. Ports of the same cost that attach to
a common LAN will select the port to be used based upon the port
priority.
Parameter Description
as negotiated (20,000 for 1Gbps, 200,000 for 100 Mbps links
and 2,000,000 for 10 Mbps links).
For MSTP, this parameter applies to both external and internal
path cost.
5. Click Apply.
Section 5.2.10
Section 5.3
The process of controlling traffic based on CoS occurs over two phases:
1. Inspection Phase
In the inspection phase, the CoS priority of a received frame is determined from either:
• A specific CoS based upon the source and destination MAC address (as set in the Static MAC Address Table)
• The priority field in the IEEE 802.1Q tags
• The Differentiated Services Code Point (DSCP) component of the Type Of Service (TOS) field in the IP
header, if the frame is IP
• The default CoS for the port
Each frame’s CoS will be determined once the first examined parameter is found in the frame.
NOTE
For information on how to configure the Inspect TOS parameter, refer to .
Received frames are first examined to determine if their destination or source MAC address is found in
the Static MAC Address Table. If they are, the CoS configured for the static MAC address is used. If neither
destination or source MAC address is in the Static MAC Address Table, the frame is then examined for IEEE
802.1Q tags and the priority field is mapped to a CoS. If a tag is not present, the frame is examined to
determine if it is an IP frame. If the frame is an IP frame and Inspect TOS is enabled in RUGGEDCOM ROS, the
CoS is determined from the DSCP field. If the frame is not an IP frame or Inspect TOS is disabled, the default
CoS for the port is used.
After inspection, the frame is forwarded to the egress port for transmission.
2. Forwarding Phase
Once the CoS of the frame is determined, the frame is forwarded to the egress port, where it is collected into
one of the priority queues according to the assigned CoS.
CoS weighting selects the degree of preferential treatment that is attached to different priority queues. The
ratio of the number of higher CoS to lower CoS frames transmitted can be configured. If desired, lower CoS
frames can be transmitted only after all higher CoS frames have been serviced.
CONTENTS
• Section 5.3.1, “Configuring Classes of Service Globally”
• Section 5.3.2, “Configuring Classes of Service for Specific Ethernet Ports”
• Section 5.3.3, “Configuring Priority to CoS Mapping”
• Section 5.3.4, “Configuring DSCP to CoS Mapping”
Section 5.3.1
2 3
Parameter Description
3. Click Apply.
4. If necessary, configure CoS mapping based on either the IEEE 802.1p priority or Differentiated Services (DS)
field set in the IP header for each packet. For more information, refer to Section 5.3.3, “Configuring Priority to
CoS Mapping” or Section 5.3.4, “Configuring DSCP to CoS Mapping” .
Section 5.3.2
3
4 5
Parameter Description
Parameter Description
is enabled the switch will use the Differentiated Services bits in
the TOS field.
4. Click Apply.
Section 5.3.3
3 4
Parameter Description
Priority Synopsis: 0 to 7
Default: 0
Parameter Description
Value of the IEEE 802.1p priority.
4. Click Apply.
Section 5.3.4
3 4
Parameter Description
DSCP Synopsis: 0 to 63
Default: 0
Differentiated Services Code Point (DSCP) - a value of the 6 bit
DiffServ field in the Type-Of-Service (TOS) field of the IP header.
4. Click Apply.
5. Configure the CoS parameters on select switched Ethernet ports as needed. For more information, refer
to Section 5.3.2, “Configuring Classes of Service for Specific Ethernet Ports” .
Section 5.4
CONTENTS
• Section 5.4.1, “Viewing a List of MAC Addresses”
• Section 5.4.2, “Configuring MAC Address Learning Options”
• Section 5.4.3, “Configuring MAC Address Flooding Options”
• Section 5.4.4, “Managing Static MAC Addresses”
Section 5.4.1
2
3 4
Parameter Description
3. Click Apply.
Section 5.4.3
1. Navigate to MAC Address Tables » Configure MAC Address Flooding Options . The Flooding Options
table appears.
3 4
Parameter Description
4. Click Apply.
CONTENTS
• Section 5.4.4.1, “Viewing a List of Static MAC Addresses”
• Section 5.4.4.2, “Adding a Static MAC Address”
• Section 5.4.4.3, “Deleting a Static MAC Address”
Section 5.4.4.1
Viewing a List of Static MAC Addresses
To view a list of static MAC addresses configured on the device, navigate to MAC Address Tables » Configure
Static MAC Addresses . The Static MAC Addresses table appears.
Section 5.4.4.2
Adding a Static MAC Address
To add a static MAC address to the Static MAC Address Table, do the following:
1. Navigate to MAC Address Tables » Configure Static MAC Addresses . The Static MAC Addresses table
appears.
4
5 7
Parameter Description
Parameter Description
VLAN Identifier of the VLAN upon which the MAC address
operates.
Option ANY allows learning a MAC address through the Port
Security module on any VLAN's that are configured on the switch.
4. Click Apply.
Section 5.4.4.3
Deleting a Static MAC Address
To delete a static MAC address from the Static MAC Address Table, do the following:
1. Navigate to MAC Address Tables » Configure Static MAC Addresses . The Static MAC Addresses table
appears.
2. Select the
Figure MAC
123: address
Static from the
MAC Addresses table. The Static MAC Addresses form appears.
Table
4
5 7
3. Click Delete.
Section 5.4.5
Section 5.5
CONTENTS
• Section 5.5.1, “Configuring the Time and Date”
• Section 5.5.2, “Managing NTP”
Section 5.5.1
6 5
7
Parameter Description
Parameter Description
This setting allows for the conversion of UTC (Universal
Coordinated Time) to local time.
03.2.0/02:00:00 11.1.0/02:00:00
Section 5.5.2
Managing NTP
RUGGEDCOM ROS may be configured to refer periodically to a specified NTP server to correct any accumulated
drift in the on-board clock. RUGGEDCOM ROS will also serve time via the Simple Network Time Protocol (SNTP) to
hosts that request it.
Two NTP servers (primary and backup) may be configured for the device. The primary server is contacted first for
each attempt to update the system time. If the primary server fails to respond, the backup server is contacted. If
either the primary or backup server fails to respond, an alarm is raised.
CONTENTS
• Section 5.5.2.1, “Enabling/Disabling NTP Service”
• Section 5.5.2.2, “Configuring NTP Servers”
Section 5.5.2.1
Enabling/Disabling NTP Service
To enable or disable NTP Service, do the following:
1. NOTE
If the device is running as an NTP server, NTP service must be enabled.
Navigate to Administration » System Time Manager » Configure NTP » Configure NTP Service . The SNTP
Parameters form appears.
2 3
Section 5.5.2.2
Configuring NTP Servers
To configure either the primary or backup NTP server, do the following:
1. Navigate to Administration » System Time Manager » Configure NTP » Configure NTP Servers . The NTP
Servers table appears.
3
4 5
Parameter Description
4. Click Apply.
Section 5.6
Managing SNMP
RUGGEDCOM ROS supports versions 1, 2 and 3 of the Simple Network Management Protocol (SNMP), otherwise
referred to as SNMPv1, SNMPv2c and SNMPv3 respectively. SNMPv3 provides secure access to the devices through
a combination of authentication and packet encryption over the network. Security features for this protocol
include:
Feature Description
Message Integrity Makes sure that a packet has not been tampered with in-transit.
Authentication Determines if the message is from a valid source.
Encryption Encrypts the contents of a packet to prevent it from being seen by an unauthorized source.
SNMPv3 provides security models and security levels. A security model is an authentication strategy setup for
a user and the group in which the user resides. A security level is a permitted level of security within a security
model. A combination of a security model and level will determine which security mechanism is employed
when handling an SNMP packet.
Before configuring SNMPv3, note the following:
• Each user belongs to a group
• A group defines the access policy for a set of users
• An access policy defines what SNMP objects can be accessed for (i.e. reading, writing and creating notifications)
• A group determines the list of notifications its users can receive
• A group also defines the security model and security level for its users
For SNMPv1 and SNMPv2c, a community string can be configured. The string is mapped to the group and
access level with a security name, which is configured as User Name.
CONTENTS
• Section 5.6.1, “Managing SNMP Users”
• Section 5.6.2, “Managing Security-to-Group Mapping”
• Section 5.6.3, “Managing SNMP Groups”
Section 5.6.1
CONTENTS
• Section 5.6.1.1, “Viewing a List of SNMP Users”
• Section 5.6.1.2, “Adding an SNMP User”
• Section 5.6.1.3, “Deleting an SNMP User”
Section 5.6.1.1
Viewing a List of SNMP Users
To view a list of SNMP users configured on the device, navigate to Administration » Configure SNMP »
Configure SNMP Users . The SNMP Users table appears.
If users
Figure have not been
130: SNMP Users configured,
Table add users as needed. For more information, refer to Section 5.6.1.2,
“Adding an SNMP User” .
Section 5.6.1.2
Adding an SNMP User
Multiple users (up to a maximum of 32) can be configured for the local SNMPv3 engine, as well as SNMPv1
and SNMPv2c communities.
NOTE
When employing the SNMPv1 or SNMPv2c security level, the User Name parameter maps the community name with the security
9
10
12
11
Parameter Description
Parameter Description
generated to trap receivers if request was received from this user,
but from any other IP address.If IP address is empty, traps can not
be generated to this user, but SNMP requests will be served for
this user from any IP address.
4. Click Apply.
Section 5.6.1.3
Deleting an SNMP User
To delete an SNMP user, do the following:
1. Navigate to Administration » Configure SNMP » Configure SNMP Users . The SNMP Users table appears.
2. Select the user from the table. The SNMP Users form appears.
Figure 133: SNMP Users Table
9
10
12
11
3. Click Delete.
Figure 134: SNMP Users Form
1. Name Box2. IP Address Box3. v1/v2c Community Box4. Auth Protocol Box5. Priv Protocol Box6. Auth Key Box
7. Confirm Auth Key Box8. Priv Key Box9. Confirm Priv Key Box10. Apply Button11. Delete Button12. Reload Button
CONTENTS
• Section 5.6.2.1, “Viewing a List of Security-to-Group Maps”
• Section 5.6.2.2, “Adding a Security-to-Group Map”
• Section 5.6.2.3, “Deleting a Security-to-Group Map”
Section 5.6.2.1
Viewing a List of Security-to-Group Maps
To view a list of security-to-group maps configured on the device, navigate to Administration » Configure SNMP
» Configure SNMP Security to Group Maps . The SNMP Security to Group Maps table appears.
Section 5.6.2.2
Adding a Security-to-Group Map
Multiple combinations of security models and groups can be mapped (up to a maximum of 32) for SNMP.
To add a security-to-group map, do the following:
1. Navigate to Administration » Configure SNMP » Configure SNMP Security to Group Maps . The SNMP
Security to Group Maps table appears.
3
4 6
Parameter Description
4. Click Apply.
2. Select the
Figure map
138: from
SNMP the table.
Security The
to Group SNMP
Maps Security to Group Maps form appears.
Table
3
4 6
3. Click Delete.
Section 5.6.3
CONTENTS
• Section 5.6.3.1, “Viewing a List of SNMP Groups”
• Section 5.6.3.2, “Adding an SNMP Group”
Section 5.6.3.1
Viewing a List of SNMP Groups
To view a list of SNMP groups configured on the device, navigate to Administration » Configure SNMP »
Configure SNMP Access . The SNMP Access table appears.
Section 5.6.3.2
Adding an SNMP Group
To add an SNMP group, do the following:
1. Navigate to Administration » Configure SNMP » Configure SNMP Access . The SNMP Access table appears.
3. Configure the following parameter(s) as required: Figure 142: SNMP Access Form
1. Group Box2. Security Model Box3. Security Level Box4. ReadViewName Box5. WriteViewName Box6. NotifyViewName Box7. Apply Button8. Delete Butt
Parameter Description
4. Click Apply.
Section 5.6.3.3
Deleting an SNMP Group
To delete an SNMP group, do the following:
1. Navigate to Administration » Configure SNMP » Configure SNMP Access . The SNMP Access table appears.
5
7
9
6
3. Click Delete.
CONTENTS
• Section 5.7.1, “Network Discovery Concepts”
• Section 5.7.2, “Configuring LLDP Globally”
• Section 5.7.3, “Configuring LLDP for an Ethernet Port”
• Section 5.7.4, “Enabling/Disabling RCDP”
• Section 5.7.5, “Viewing Global Statistics and Advertised System Information”
• Section 5.7.6, “Viewing Statistics for LLDP Neighbors”
• Section 5.7.7, “Viewing Statistics for LLDP Ports”
Section 5.7.1
CONTENTS
• Section 5.7.1.1, “Link Layer Discovery Protocol (LLDP)”
• Section 5.7.1.2, “ RUGGEDCOM Discovery Protocol (RCDP)”
Section 5.7.1.1
Link Layer Discovery Protocol (LLDP)
LLDP is an IEEE standard protocol, IEEE 802.11AB, that allows a networked device to advertise its own basic
networking capabilities and configuration.
LLDP allows a networked device to discover its neighbors across connected network links using a standard
mechanism. Devices that support LLDP are able to advertise information about themselves, including their
capabilities, configuration, interconnections, and identifying information.
LLDP agent operation is typically implemented as two modules: the LLDP transmit module and LLDP receive
module. The LLDP transmit module, when enabled, sends the local device’s information at regular intervals, in
IEEE 802.1AB standard format. Whenever the transmit module is disabled, it transmits an LLDPDU (LLDP data unit)
with a time-to-live (TTL) type-length-value (TLV) containing 0 in the information field. This enables remote devices
to remove the information associated with the local device in their databases. The LLDP receive module, when
enabled, receives remote devices’ information and updates its LLDP database of remote systems. When new or
updated information is received, the receive module initiates a timer for the valid duration indicated by the TTL TLV
in the received LLDPDU. A remote system’s information is removed from the database when an LLDPDU is
received from it with TTL TLV containing 0 in its information field.
NOTE
LLDP is implemented to keep a record of only one device per Ethernet port. Therefore, if there are multiple devices sending LLDP inform
Section 5.7.1.2
RUGGEDCOM Discovery Protocol (RCDP)
RUGGEDCOM Discovery Protocol (RCDP) supports the deployment of RUGGEDCOM ROS-based devices that
have not been configured since leaving the factory. RUGGEDCOM ROS devices that have not been configured
all have the default IP (Layer 3) address. Connecting more than one of them on a Layer 2 network means that
one cannot use standard IP-based configuration tools to configure them. The behavior of IP-based mechanisms
such as the web interface, SSH, telnet, or SNMP will all be undefined.
Since RCDP operates at Layer 2, it can be used to reliably and unambiguously address multiple devices even
though they may share the same IP configuration.
Siemens's RUGGEDCOM Explorer is a lightweight, standalone Windows application that supports RCDP. It is
capable of discovering, identifying and performing basic configuration of RUGGEDCOM ROS-based devices via
RCDP. The features supported by RCDP include:
• Discovery of RUGGEDCOM ROS-based devices over a Layer 2 network.
• Retrieval of basic network configuration, RUGGEDCOM ROS version, order code, and serial number.
• Control of device LEDs for easy physical identification.
• Configuration of basic identification, networking, and authentication parameters.
For security reasons, RUGGEDCOM Explorer will attempt to disable RCDP on all devices when Explorer is shut
down. If RUGGEDCOM Explorer is unable to disable RCDP on a device, RUGGEDCOM ROS will automatically disable
RCDP after approximately one hour of inactivity.
NOTE
RCDP is not compatible with VLAN-based network configurations. For correct operation of RUGGEDCOM Explorer, no VLANs (tagged or
NOTE
RUGGEDCOM ROS responds to RCDP requests only. It does not under any circumstances initiate any RCDP-based communication.
Section 5.7.2
5
6 7
Parameter Description
Tx Hold Synopsis: 2 to 10
Default: 4
The multiplier of the Tx Interval parameter that determines the
actual time-to-live (TTL) value used in a LLDPDU. The actual TTL
value can be expressed by the following formula:
Synopsis: 1 to 8192 s
Tx Delay Default: 2 s
The delay in seconds between successive LLDP frame
transmissions initiated by value or status changed. The
recommended value is set by the following formula:
3. Click Apply.
4 5
Parameter Description
Parameter Description
rxTx: the local LLDP agent can both transmit and receive LLDP
frames through the port.
txOnly: the local LLDP agent can only transmit LLDP frames.
rxOnly: the local LLDP agent can only receive LLDP frames.
disabled: the local LLDP agent can neither transmit or receive
LLDP frames.
4. Click Apply.
Section 5.7.4
Enabling/Disabling RCDP
RUGGEDCOM ROS supports the RUGGEDCOM Discovery Protocol (RCDP). RCDP supports the deployment of
RUGGEDCOM ROS-based devices that have not been configured since leaving the factory. RUGGEDCOM ROS
devices that have not been configured all have the default IP (Layer 3) address. Connecting more than one of
them on a Layer 2 network means that one cannot use standard IP-based configuration tools to configure
them. The behavior of IP-based mechanisms such as the web interface, SSH, telnet, or SNMP will all be
undefined.
Since RCDP operates at Layer 2, it can be used to reliably and unambiguously address multiple devices even
though they may share the same IP configuration.
Siemens's RUGGEDCOM Explorer is a lightweight, standalone Windows application that supports RCDP. It is
capable of discovering, identifying and performing basic configuration of RUGGEDCOM ROS-based devices via
RCDP. The features supported by RCDP include:
• Discovery of RUGGEDCOM ROS-based devices over a Layer 2 network.
• Retrieval of basic network configuration, RUGGEDCOM ROS version, order code, and serial number.
• Control of device LEDs for easy physical identification.
• Configuration of basic identification, networking, and authentication parameters.
For security reasons, RUGGEDCOM Explorer will attempt to disable RCDP on all devices when Explorer is shut
down. If RUGGEDCOM Explorer is unable to disable RCDP on a device, RUGGEDCOM ROS will automatically disable
RCDP after approximately one hour of inactivity.
NOTE
RCDP is not compatible with VLAN-based network configurations. For correct operation of RUGGEDCOM Explorer, no VLANs (tagge
NOTE
RUGGEDCOM ROS responds to RCDP requests only. It does not under any circumstances initiate any RCDP-based communication.
2 3
Section 5.7.5
This form displays the following information: Figure 149: LLDP Global Remote Statistics Form
1. Inserts Box2. Deletes Box3. Drops Box4. Ageouts Box5. Reload Button
Parameter Description
Synopsis: 0 to 4294967295
Drops
Parameter Description
A number of times an entry was deleted from LLDP Neighbor
Information Table because the information timeliness interval has
expired.
Section 5.7.6
Parameter Description
CONTENTS
• Section 5.8.1, “Managing IGMP”
• Section 5.8.2, “Managing GMRP”
Section 5.8.1
Managing IGMP
IGMP is used by IP hosts to report their host group memberships with multicast routers. As hosts join and leave
specific multicast groups, streams of traffic are directed to or withheld from that host.
The IGMP protocol operates between multicast routers and IP hosts. When an unmanaged switch is placed
between multicast routers and their hosts, the multicast streams will be distributed to all ports.This may introduce
significant traffic onto ports that do not require it and receive no benefit from it.
IGMP Snooping, when enabled, will act on IGMP messages sent from the router and the host, restricting traffic
streams to the appropriate LAN segments.
IMPORTANT!
RUGGEDCOM ROS restricts IGMP hosts from subscribing to the following special multicast addresses:
• 224.0.0.0 to 224.0.0.255
• 224.0.1.129
These addresses are reserved for routing protocols and IEEE 1588. If an IGMP membership report contains one of these addresses,
CONTENTS
• Section 5.8.1.1, “IGMP Concepts”
• Section 5.8.1.2, “Viewing a List of Multicast Group Memberships”
• Section 5.8.1.3, “Viewing Forwarding Information for Multicast Groups”
• Section 5.8.1.4, “Configuring IGMP”
Section 5.8.1.1
IGMP Concepts
The following describes some of the concepts important to the implementation of multicast filtering using IGMP:
IGMP In Operation
The following network diagram provides a simple example of the use of IGMP.
P1
2M1M22
3 3
C3 C4 C1 C2
4 4 5 4 4
One producer IP host (P1) is generating two IP multicast streams, M1 and M2. There are four potential consumers
of these streams, C1 through C4. The multicast router discovers which host wishes to subscribe to which stream
by sending general membership queries to each segment.
In this example, the general membership query sent to the C1-C2 segment is answered by a membership report
(or join) indicating the desire to subscribe to stream M2. The router will forward the M2 stream to the C1-C2
segment. In a similar fashion, the router discovers that it must forward stream M1 to segment C3-C4.
A consumer may join any number of multicast groups, issuing a membership report for each group. When a host
issues a membership report, other hosts on the same network segment that also require membership to the same
group suppress their own requests, since they would be redundant. In this way, the IGMP protocol guarantees the
segment will issue only one membership report for each group.
The router periodically queries each of its segments in order to determine whether at least one consumer still
subscribes to a given stream. If it receives no responses within a given time period (usually two query intervals),
the router will prune the multicast stream from the given segment.
A more common method of pruning occurs when consumers wishing to unsubscribe issue an IGMP leave group
message. The router will immediately issue a group-specific membership query to determine whether there are
any remaining subscribers of that group on the segment. After the last consumer of a group has unsubscribed, the
router will prune the multicast stream from the given segment.
• Passive Mode
When such a switch is used in a network with a multicast router, it can be configured to run Passive IGMP. This
mode prevents the switch from sending the queries that can confuse the router causing it to stop issuing IGMP
queries.
NOTE
A switch running in passive mode requires the presence of a multicast router or it will be unable to forward multicast streams at al
NOTE
At least one IGMP Snooping switch must be in active mode to make IGMP functional.
If RSTP detects a change in the network topology, IGMP will take some actions to avoid the loss of multicast
connectivity and reduce network convergence time:
• The switch will immediately issue IGMP queries (if in IGMP Active mode) to obtain potential new group
membership information.
• The switch can be configured to flood multicast streams temporarily out of all ports that are not configured as
RSTP Edge Ports.
P1 2 3
P2 4
C1 C2 C3
In this example:
• P1, Router 1, Router 2 and C3 are on VLAN 2
• P2 and C2 are on VLAN 3
• C1 is on both VLAN 2 and 3
Assuming that router 1 is the querier for VLAN 2 and router 2 is simply a non-querier, the switch will periodically
receive queries from router 1 and maintain the information concerning which port links to the multicast router.
However, the switch port that links to router 2 must be manually configured as a router port. Otherwise, the
switch will send neither multicast streams nor joins/leaves to router 2.
Note that VLAN 3 does not have an external multicast router. The switch should be configured to operate in its
routerless mode and issue general membership queries as if it is the router.
• Processing Joins
If host C1 wants to subscribe to the multicast streams for both P1 and P2, it will generate two membership
reports. The membership report from C1 on VLAN 2 will cause the switch to immediately initiate its own
membership report to multicast router 1 (and to issue its own membership report as a response to queries).
The membership report from host C1 for VLAN 3 will cause the switch to immediately begin forwarding
multicast traffic from producer P2 to host C2.
• Processing Leaves
When host C1 decides to leave a multicast group, it will issue a leave request to the switch. The switch will poll
the port to determine if host C1 is the last member of the group on that port. If host C1 is the last (or only)
member, the group will immediately be pruned from the port.
Should host C1 leave the multicast group without issuing a leave group message and then fail to respond to a
general membership query, the switch will stop forwarding traffic after two queries.
When the last port in a multicast group leaves the group (or is aged-out), the switch will issue an IGMP
leave report to the router.
Section 5.8.1.2
Viewing a List of Multicast Group Memberships
Using IGMP snooping, RUGGEDCOM ROS records group membership information on a per-port basis based on
membership reports it observes between the router and host.
To view a list of multicast group memberships, navigate to Multicast Filtering » View IGMP Group Membership
. The IGMP Group Membership table appears.
Parameter Description
Section 5.8.1.3
Viewing Forwarding Information for Multicast Groups
Multicast forwarding information for every source, group and VLAN combination learned by RUGGEDCOM ROS is
recorded in the IGMP Multicast Forwarding table.
To view the IGMP Multicast Forwarding table, navigate to Multicast Filtering » View IGMP Multicast
Forwarding . The IGMP Multicast Forwarding table appears.
Parameter Description
7 8
6
Parameter Description
Section 5.8.2
Managing GMRP
The GMRP is an application of the Generic Attribute Registration Protocol (GARP) that provides a Layer 2
mechanism for managing multicast group memberships in a bridged Layer 2 network. It allows Ethernet switches
and end stations to register and unregister membership in multicast groups with other switches on a LAN, and for
that information to be disseminated to all switches in the LAN that support Extended Filtering Services.
GMRP is an industry-standard protocol first defined in IEEE 802.1D-1998 and extended in IEEE 802.1Q-2005. GARP
was defined in IEEE 802.1D-1998 and updated in 802.1D-2004.
NOTE
GMRP provides similar functionality at Layer 2 to what IGMP provides at Layer 3.
CONTENTS
• Section 5.8.2.1, “GMRP Concepts”
• Section 5.8.2.2, “Viewing a Summary of Multicast Groups”
• Section 5.8.2.3, “Configuring GMRP Globally”
• Section 5.8.2.4, “Configuring GMRP for Specific Ethernet Ports”
• Section 5.8.2.5, “Viewing a List of Static Multicast Groups”
• Section 5.8.2.6, “Adding a Static Multicast Group”
Section 5.8.2.1
GMRP Concepts
The following describes some of the concepts important to the implementation of multicast filtering using GMRP:
In this scenario, there are two multicast sources, S1 and S2, multicasting to Multicast Groups 1 and 2,
respectively. A network of five switches, including one core switch (B), connects the sources to two hosts, H1
and H2, which receive the multicast streams from S1 and S2, respectively.
1 S1
D1
D
D2
B3
B1
B B2
B4 E1
A1 E C1
E2
A C 2
A2 C2
H1 H2 3
1 S2
The hosts and switches establish membership with the Multicast Group 1 and 2 as follows:
1. Host H1 is GMRP unaware, but needs to see traffic for Multicast Group 1. Therefore, Port E2 on Switch E is
statically configured to forward traffic for Multicast Group 1.
2. Switch E advertises membership in Multicast Group 1 to the network through Port E1, making Port B4 on
Switch B a member of Multicast Group 1.
3. Switch B propagates the join message, causing Ports A1, C1 and D1 to become members of Multicast Group 1.
4. Host H2 is GMRP-aware and sends a join request for Multicast Group 2 to Port C2, which thereby becomes a
member of Multicast Group 2.
5. Switch C propagates the join message, causing Ports A1, B2, D1 and E1 to become members of
Multicast Group 2.
Once GMRP-based registration has propagated through the network, multicast traffic from S1 and S2 can reach
its destination as follows:
• Source S1 transmits multicast traffic to Port D2 which is forwarded via Port D1, which has previously become a
member of Multicast Group 1.
• Switch B forwards the Group 1 multicast via Port B4 towards Switch E.
• Switch E forwards the Group 1 multicast via Port E2, which has been statically configured for membership in
Multicast Group 1.
• Host H1, connected to Port E2, thus receives the Group 1 multicast.
• Source S2 transmits multicast traffic to Port A2, which is then forwarded via port A1, which has previously
become a member of Multicast Group 2.
• Switch B forwards the Group 2 multicast via Port B2 towards Switch C.
• Switch C forwards the Group 2 multicast via Port C2, which has previously become a member of Group 2.
• Ultimately, Host H2, connected to Port C2, receives the Group 2 multicast.
Section 5.8.2.2
Viewing a Summary of Multicast Groups
To view a summary of all multicast groups, navigate to Multicast Filtering » View Multicast Group Summary .
The Multicast Group Summary table appears.
Parameter Description
Section 5.8.2.3
Configuring GMRP Globally
To configure global settings for GMRP, do the following:
1. Navigate to Multicast Filtering » Configure Global GMRP Parameters . The Global GMRP Parameters form
appears.
3
4 5
Parameter Description
3. Click Apply.
Section 5.8.2.4
Configuring GMRP for Specific Ethernet Ports
To configure GMRP for a specific Ethernet port, do the following:
1. Make sure the global settings for GMRP have been configured. For more information, refer to Section
5.8.2.3, “Configuring GMRP Globally” .
2. Navigate to Multicast Filtering » Configure Port GMRP Parameters . The Port GMRP Parameters table
appears.
3 4
Parameter Description
5. Click Apply.
Section 5.8.2.6
Adding a Static Multicast Group
To add a static multicast group from another device, do the following:
1. Navigate to Multicast Filtering » Configure Static Multicast Groups . The Static Multicast Groups table
appears.
2. Click InsertRecord.
Figure The Static
163: Static Multicast Multicast
Groups Table Groups form appears.
1. InsertRecord
4
5 7
Parameter Description
4. Click Apply.
Section 5.8.2.7
Deleting a Static Multicast Group
To delete a static multicast group, do the following:
1. Navigate to Multicast Filtering » Configure Static Multicast Groups . The Static Multicast Groups table
appears.
4
5 7
3. Click Delete.
Section 5.9
Managing DHCP
Dynamic Host Configuration Protocol (DHCP) is a communications protocol that allows network administrators
to centrally manage and automate the network configuration of devices attached to an Internet Protocol (IP)
network.
CONTENTS
• Section 5.9.1, “DHCP Concepts”
• Section 5.9.2, “Configuring the DHCP Relay Agent”
• Section 5.9.3, “Configuring DHCP Snooping”
• Section 5.9.4, “Configuring DHCP Port Parameters”
• Section 5.9.5, “Configuring the Static DHCP Binding Table”
Section 5.9.1
DHCP Concepts
The following section describes concepts important to the configuration and application of DHCP.
CONTENTS
• Section 5.9.1.1, “DHCP Snooping”
• Section 5.9.1.2, “Trusted and Untrusted Ports”
• Section 5.9.1.3, “DHCP Binding Table”
• Section 5.9.1.4, “DHCP Relay Agent (Option 82)”
• Section 5.9.1.5, “Preventable Network Attacks”
Section 5.9.1.1
DHCP Snooping
DHCP snooping is a network security feature that protects the network from untrusted DHCP servers and untrusted
clients by keeping track of ports where DHCP clients and servers reside. This information is tracked by building
a DHCP binding table that contains all MAC-IP associations the switch has learned by snooping client and server
DHCP communications. The binding table contains MAC-IP information which can be further utilized by DHCP
snooping applications. RUGGEDCOM ROS will log messages in the syslog and/or raise an alarm when DHCP
violations are detected.
RUGGEDCOM ROS will log messages in the syslog and/or raise an alarm when DHCP violations are detected.
NOTE
DHCP Snooping is enabled on the device on a per-VLAN basis. For more information about enabling DHCP snooping on individual V
Section 5.9.1.2
Trusted and Untrusted Ports
DHCP Snooping classifies ports as trusted and untrusted. This port classification determines how a DHCP message
is handled by the switch. DHCP messages received on trusted ports are forwarded without any further checking,
while messages received from untrusted ports are verified to determine if the message is legitimate. The user is
expected to configure the ports as trusted or untrusted.
From a deployment perspective, it is also expected the user configures network ports as trusted. Network ports
typically connect to another switch or a router. This is necessary because a DHCP server may not be directly
connected to a switch port.
For more information about configuring ports as trusted or untrusted, refer to Section 5.9.4, “Configuring DHCP
Port Parameters” .
Section 5.9.1.4
DHCP Relay Agent (Option 82)
A DHCP Relay Agent is a device that forwards DHCP packets between clients and servers when they are not on
the same physical LAN segment or IP subnet. The feature is enabled if the DHCP server IP address and a set of
access ports are configured.
DHCP Option 82 provides a mechanism for assigning an IP Address based on the location of the client device in the
network. Information about the client’s location can be sent along with the DHCP request to the server. Based on
this information, the DHCP server makes a decision about an IP Address to be assigned.
The DHCP Relay Agent takes the broadcast DHCP requests from clients received on the configured access port and
inserts the relay agent information option (Option 82) into the packet. Option 82 contains the VLAN ID (2 bytes)
and the port number of the access port (2 bytes: the circuit ID sub-option) and the switch’s MAC address (the
remote ID sub-option). This information uniquely defines the access port’s position in the network. For example,
the Circuit ID for VLAN 1 on port 1 is 00:01:00:01.
The DHCP Server supporting DHCP Option 82 sends a unicast reply and echoes Option 82. The DHCP Relay Agent
removes the Option 82 field and broadcasts the packet to the port from which the original request was received.
These parameters provide the ability to configure the switch to act as a relay agent for DHCP Option 82.
The DHCP Relay Agent communicates to the server on a management interface. The agent’s IP address is the
address configured for the management interface.
For more information about configuring the DHCP Relay Agent, refer to Section 5.9.2, “Configuring the DHCP
Relay Agent” .
Section 5.9.1.5
Preventable Network Attacks
The following network attacks can be prevented by enabling DHCP snooping on the switch. For more
information, refer to Section 5.9.3, “Configuring DHCP Snooping” .
• Host Misconfiguration by a Rogue DHCP Server
A rogue DHCP server can assign an incorrect IP address, default gateway and/or DNS server parameters to the
client. A misconfigured client is susceptible to a potential network attack. Switches that support DHCP snooping
can identify DHCP messages from a rogue DHCP server and block these messages in the switch itself.
1 3
1 4
3
2
1 4
3
2
Section 5.9.2
3 4
Parameter Description
DHCP Server Address Synopsis: ###.###.###.### where ### ranges from 0 to 255
IP address of the DHCP server to which DHCP requests will be
forwarded. DHCP server IP must be configured for Relay Agent to
work.
3. Click Apply.
4. Navigate to Network Access Control » DHCP Snooping » Configure DHCP Port Parameters . The DHCP
Port Parameters table appears.
5. Select an171:
Figure Ethernet port.
DHCP Port The DHCP
Parameters Port Parameters form appears.
Table
3
4 5
Parameter Description
7. Click Apply.
Section 5.9.3
NOTE
DHCP Snooping is enabled on the device on a per-VLAN basis. For more information about enabling DHCP snooping on individual V
1. Navigate to Network Access Control » DHCP Snooping » Configure DHCP Parameters . The DHCP
Parameters form appears.
3 4
Parameter Description
3. Click Apply.
Section 5.9.4
2. Select an174:
Figure Ethernet port.
DHCP Port The DHCP
Parameters Port Parameters form appears.
Table
3
4 5
Parameter Description
4. Click Apply.
Section 5.9.5
2. Figure
Click 176: Static DHCP
InsertRecord. TheBinding
Static Table
DHCP Binding Table form appears.
1. InsertRecord
4
5 7
Parameter Description
4. Click Apply.
2. Figurean178:
Select View DHCP
Ethernet port.Binding Table Binding Table form appears.
The DHCP
7 8
6
Parameter Description
Parameter Description
4. Click Reload.
Section 5.9.7
Section 5.10
CONTENTS
• Section 5.10.1, “Port Security Concepts”
• Section 5.10.2, “Viewing a List of Authorized MAC Addresses”
• Section 5.10.3, “Configuring Port Security”
Section 5.10.1
CONTENTS
• Section 5.10.1.1, “Static MAC Address-Based Authentication”
• Section 5.10.1.2, “IEEE 802.1x Authentication”
• Section 5.10.1.3, “IEEE 802.1X Authentication with MAC Address-Based Authentication”
• Section 5.10.1.4, “Assigning VLANS with Tunnel Attributes”
Section 5.10.1.1
Static MAC Address-Based Authentication
With this method, the switch validates the source MAC addresses of received frames against the contents in the
Static MAC Address Table.
RUGGEDCOM ROS also supports a highly flexible Port Security configuration which provides a convenient means
for network administrators to use the feature in various network scenarios.
A Static MAC address can be configured without a port number being explicitly specified. In this case, the
configured MAC address will be automatically authorized on the port where it is detected. This allows devices to
be connected to any secure port on the switch without requiring any reconfiguration.
The switch can also be programmed to learn (and, thus, authorize) a pre-configured number of the first source
MAC addresses encountered on a secure port. This enables the capture of the appropriate secure addresses when
first configuring MAC address-based authorization on a port. Those MAC addresses are automatically inserted into
the Static MAC Address Table and remain there until explicitly removed by the user.
Section 5.10.1.2
IEEE 802.1x Authentication
The IEEE 802.1x standard defines a mechanism for port-based network access control and provides a means of
authenticating and authorizing devices attached to LAN ports.
Although IEEE 802.1x is mostly used in wireless networks, this method is also implemented in wired switches.
The IEEE 802.1x standard defines three major components of the authentication method: Supplicant,
Authenticator and Authentication server. RUGGEDCOM ROS supports the Authenticator component.
1 2 3 4
IMPORTANT!
RUGGEDCOM ROS supports both Protected Extensible Authentication Protocol (PEAP) and EAP-MD5. PEAP is more secure and is recom
IEEE 802.1x makes use of the Extensible Authentication Protocol (EAP), which is a generic PPP authentication
protocol that supports various authentication methods. IEEE 802.1x defines a protocol for communication
between the Supplicant and the Authenticator, referred to as EAP over LAN (EAPOL).
RUGGEDCOM ROS communicates with the Authentication Server using EAP over RADIUS.
NOTE
The switch supports authentication of one host per port.
NOTE
If the host’s MAC address is configured in the Static MAC Address Table, it will be authorized, even if the host authentication is rejected
Section 5.10.1.3
IEEE 802.1X Authentication with MAC Address-Based Authentication
This method, also referred to as MAB (MAC-Authentication Bypass), is commonly used for devices, such as VoIP
phones and Ethernet printers, that do not support the 802.1x protocol. This method allows such devices to be
authenticated using the same database infrastructure as that used in 802.1x.
IEEE 802.1x with MAC-Authentication Bypass works as follows:
1. The device connects to a switch port.
2. The switch learns the device MAC address upon receiving the first frame from the device (the device usually
sends out a DHCP request message when first connected).
3. The switch sends an EAP Request message to the device, attempting to start 802.1X authentication.
4. The switch times out while waiting for the EAP reply, because the device does not support 802.1x.
5. The switch sends an authentication message to the authentication server, using the device MAC address as
the username and password.
6. The switch authenticates or rejects the device according to the reply from the authentication server.
Section 5.10.2
Parameter Description
Parameter Description
Section 5.10.3
7 8
6
Parameter Description
Parameter Description
Only applicable when the 'Security' field has been set to 'Static
MAC'. Change the behaviour of the port to either sticky or non-
sticky.
If Sticky is 'Yes', MACs/Devices authorized on the port 'stick' to the
port and the switch will not allow them to move to a different
port.
If Sticky is 'No', MACs/Devices authorized on the port may move to
another port.
NOTE
There are a few scenarios in which static MAC addresses can move:
When the link is up/down on a non-sticky secured port
When traffic switches from or to a non-sticky secured port
NOTE
Traffic is lost until the source MAC Address of the incoming traffic is authorized against the static MAC address table.
4. Click Apply.
Section 5.10.4
10 8
11
Parameter Description
Parameter Description
reAuthMax Synopsis: 1 to 10
Default: 2
The number of re-authentication attempts that are permitted
before the port becomes unauthorized.
maxReq Synopsis: 1 to 10
Default: 2
The maximum number of times to retransmit the authentication
server's EAP Request packet to the Supplicant before the
authentication session times out.
4. Click Apply.
Section 5.11
1 2
RUGGEDCOM ROS allows up to 15 port trunks to be configured on a single device, with each consisting of up to 8
ports.
NOTE
The maximum number of port trunks for each device depends on the number of ports available. At least two ports are required to
NOTE
The aggregated port with the lowest port number is called the Port Trunk Primary Port. Other ports in the trunk are called Seconda
CONTENTS
• Section 5.11.1, “Link Aggregation Concepts”
• Section 5.11.2, “Managing Port Trunks”
Section 5.11.1
CONTENTS
• Section 5.11.1.1, “Rules and Limitations”
Section 5.11.1.1
Rules and Limitations
The implementation of link aggregation must adhere to the following rules and limitations:
• Each port can belong to only one port trunk at a time.
• A port mirroring target port can not be member of a port trunk. However, a port mirroring source port can be
member of a port trunk.
• If only one QinQ port is supported by the switch, the port working in QinQ mode cannot be a secondary
member of a port trunk.
• DHCP Relay Agent Client port cannot be a member of a port trunk.
• Load balancing between the links of a bundle is randomized and may not be ideal. For instance, if three 100
Mbs links are aggregated, the resulting bandwidth of the port trunk may not be precisely 300 Mbs.
• A Static MAC Address should not be configured to reside on an aggregated port – it may cause some
frames destined for that address to be dropped.
• A secure port cannot be a member of a port trunk.
• The IEEE 802.3ad Link Aggregation standard requires all physical links in the port trunk to run at the same speed
and in full-duplex mode. If this requirement is violated, the performance of the port trunk will drop.
The switch will raise an appropriate alarm, if such a speed/duplex mismatch is detected.
• STP dynamically calculates the path cost of the port trunk based on its aggregated bandwidth. However, if the
aggregated ports are running at different speeds, the path cost may not be calculated correctly.
• Enabling STP is the best way for handling link redundancy in switch-to-switch connections composed of more
than one physical link. If STP is enabled and increased bandwidth is not required, Link Aggregation should not
be used because it may lead to a longer fail-over time.
Section 5.11.1.2
Link Aggregation and Layer 2 Features
Layer 2 features (e.g. STP, VLAN, CoS, Multicast Filtering) treat a port trunk as a single link.
• If the Spanning Tree Protocol (STP) puts an aggregated port in blocking/forwarding, it does it for the whole port
trunk.
• If one of the aggregated ports joins/leaves a multicast group (e.g. via IGMP or GMRP), all other ports in the trunk
will join/leave too.
• Any port configuration parameter (e.g. VLAN, CoS) change will be automatically applied to all ports in the trunk.
• Configuration/status parameters of the secondary ports will not be shown and their port numbers will be simply
listed next to the primary port number in the appropriate configuration/status UI sessions.
• When a secondary port is added to a port trunk, it inherits all the configuration settings of the primary port.
When this secondary port is removed from the port trunk, the settings it had previous to the aggregation are
restored.
Section 5.11.2
CONTENTS
• Section 5.11.2.1, “Viewing a List of Port Trunks”
• Section 5.11.2.2, “Adding a Port Trunk”
• Section 5.11.2.3, “Deleting a Port Trunk”
Section 5.11.2.1
Viewing a List of Port Trunks
To view a list of port trunks configured on the device, navigate to Link Aggregation » Configure Port Trunks
. The Port Trunks table appears.
1. Navigate to Link Aggregation » Configure Port Trunks . The Port Trunks table appears.
3
4 6
Parameter Description
Trunk ID Synopsis: 1 to 2
Default: 1
Trunk number. It doesn't affect port trunk operation in any way
and is only used for identification.
4. Click Apply.
Section 5.11.2.3
Deleting a Port Trunk
To delete a port trunk, do the following:
1. Navigate to Link Aggregation » Configure Port Trunks . The Port Trunks table appears.
3
4 6
3. Click Delete.
Troubleshooting
This chapter describes troubleshooting steps for common issues that may be encountered when using
RUGGEDCOM ROS or designing a network.
IMPORTANT!
For further assistance, contact a Customer Service representative.
CONTENTS
• Section 6.1, “General”
• Section 6.2, “Ethernet Ports”
• Section 6.3, “Spanning Tree”
• Section 6.4, “VLANs”
Section 6.1
General
The following describes common problems.
Problem Solution
The switch is not responding to ping Is the switch being pinged through a router? If so, the switch gateway address must be
attempts, even though the IP address and configured as well. The following figure illustrates the problem.
gateway have been configured. The switch
is receiving the ping because the LEDs are
flashing and the device statistics are
logging the pings. What is going on?
1 2 3
192.168.0.1 10.10.0.2
10.10.0.1
192.168.0.2
The router is configured with the appropriate IP subnets and will forward the ping from the
workstation to the switch. When the switch responds, however, it will not know which of its
interfaces to use in order to reach the workstation and will drop the response. Programming
a gateway of 10.0.0.1 will cause the switch to forward unresolvable frames to the router.
This problem will also occur if the gateway address is not configured and the switch tries to
General 263
Chapter 6 RUGGEDCOM ROS
Troubleshooting User Guide
Section 6.2
Ethernet Ports
The following describes common problems related to Ethernet ports.
Problem Solution
A link seems fine when traffic levels are low, A possible cause of intermittent operation is that of a ‘duplex mismatch’. If one end of the
but fails as traffic rates increase OR a link can link is fixed to full-duplex and the peer auto-negotiates, the auto-negotiating end falls back
be pinged but has problems with FTP/SQL/ to half-duplex operation.
HTTP/etc. At lower traffic volumes, the link may display few if any errors. As the traffic volume
rises, the fixed negotiation side will begin to experience dropped packets while the auto-
negotiating side will experience collisions. Ultimately, as traffic loads approach 100%,
the link will become entirely unusable.
The ping command with flood options is a useful tool for testing commissioned links. The
command ping 192.168.0.1 500 2 can be used to issue 500 pings each separated
by two milliseconds to the next switch. If the link used is of high quality, then no pings
should be lost and the average round trip time should be small.
Links are inaccessible, even when using the Make sure LFI is not enabled on the peer as well. If both sides of the link have LFI enabled,
Link Fault Indication (LFI) protection then both sides will withhold link signal generation from each other.
feature.
Section 6.3
Spanning Tree
The following describes common problems related to the Spanning Tree Protocol (STP).
Problem Solution
The network locks up when a new port is Is it possible that one of the switches in the network or one of the ports on a switch in the
connected and the port status LEDs are network has STP disabled and accidentally connects to another switch? If this has occurred,
flashing rapidly. then a traffic loop has been formed.
If the problem appears to be transient in nature, it is possible that ports that are part of the
Occasionally, the ports seem to experience
spanning tree have been configured as edge ports. After the link layers have come up on
significant flooding for a brief period of time.
edge ports, STP will directly transition them (perhaps improperly) to the forwarding state.
If an RSTP configuration message is then received, the port will be returned to blocking. A
A switch displays a strange behavior where traffic loop may be formed for the length of time the port was in forwarding.
the root port hops back and forth between
If one of the switches appears to flip the root from one port to another, the problem may be
two switch ports and never settles down.
one of traffic prioritization. For more information refer to "The network becomes unstable
when a specific application is started."
Another possible cause of intermittent operation is that of an auto-negotiation mismatch.
If one end of the link is fixed to full-duplex mode and the peer auto-negotiates, the auto-
negotiating end will fall back to half-duplex operation. At lower traffic, the volumes the
link may display few if any errors. As the traffic volume rises, the fixed negotiation side
will begin to experience dropped packets while the auto-negotiating side will experience
collisions. Ultimately, as traffic loads approach 100%, the link will become entirely unusable.
At this point, RSTP will not be able to transmit configuration messages over the link and
the spanning tree topology will break down. If an alternate trunk exists, RSTP will activate it
in the place of the congested port. Since activation of the alternate port often relieves the
congested port of its traffic, the congested port will once again become reliable. RSTP will
promptly enter it back into service, beginning the cycle once again. The root port will flip
back and forth between two ports on the switch.
A computer or device is connected to a Is it possible that the RSTP edge setting for this port is set to false? If Edge is set to false, the
switch. After the switch is reset, it takes a bridge will make the port go through two forward delay times before the port can send or
long time for it to come up. receive frames. If Edge is set to true, the bridge will transition the port directly to forwarding
upon link up.
Problem Solution
Another possible explanation is that some links in the network run in half-duplex mode.
RSTP uses a peer-to-peer protocol called Proposal-Agreement to ensure transitioning in the
event of a link failure. This protocol requires full-duplex operation. When RSTP detects a
non-full duplex port, it cannot rely on Proposal-Agreement protocol and must make the port
transition the slow (i.e. STP) way. If possible, configure the port for full-duplex operation.
Otherwise, configure the port’s point-to-point setting to true.
Either one will allow the Proposal-Agreement protocol to be used.
When the switch is tested by deliberately Is it possible that some ports participating in the topology have been configured to STP mode
breaking a link, it takes a long time before or that the port’s point-to-point parameter is set to false? STP and multipoint ports converge
devices beyond the switch can be polled. slowly after failures occur.
Is it possible that the port has migrated to STP? If the port is connected to the LAN segment
by shared media and STP bridges are connected to that media, then convergence after link
failure will be slow.
Delays on the order of tens or hundreds of milliseconds can result in circumstances where
the link broken is the sole link to the root bridge and the secondary root bridge is poorly
chosen. The worst of all possible designs occurs when the secondary root bridge is located
at the farthest edge of the network from the root. In this case, a configuration message will
have to propagate out to the edge and then back in order to reestablish the topology.
The network is composed of a ring A properly operating unmanaged bridge is transparent to STP configuration messages. The
of bridges, of which two (connected managed bridges will exchange configuration messages through the unmanaged bridge
to part of the ring as if it is non-existent. When a link in the unmanaged part of the ring fails
each other) are managed and the rest are however, the managed bridges will only be able to detect the failure through timing out of
unmanaged. Why does the RSTP protocol hello messages. Full connectivity will require three hello times plus two forwarding times to
work quickly when a link is broken between be restored.
the managed bridges, but not in the
unmanaged bridge part of the ring?
The network becomes unstable when a RSTP sends its configuration messages using the highest possible priority level. If CoS is
specific application is started. The network configured to allow traffic flows at the highest priority level and these traffic flows burst
returns to normal when the application is continuously to 100% of the line bandwidth, STP may be disrupted. It is therefore advised
stopped. not to use the highest CoS.
When a new port is brought up, the root Is it possible that the port cost is incorrectly programmed or that auto-negotiation derives an
moves on to that port instead of the port it undesired value? Inspect the port and path costs with each port active as root.
should move to or stay on.
An Intelligent Electronic Device (IED) or Certain low CPU bandwidth controllers have been found to behave less than perfectly when
controller does not work with the device. they receive unexpected traffic. Try disabling STP for the port.
If the controller fails around the time of a link outage, there is the remote possibility that
frame disordering or duplication may be the cause of the problem. Try setting the root port
of the failing controller’s bridge to STP.
Polls to other devices are occassionally lost. Review the network statistics to determine whether the root bridge is receiving Topology
Change Notifications (TCNs) around the time of observed frame loss. It may be possible there
are problems with intermittent links in the network.
The root is receiving a number of TCNs. Examine the RSTP port statistics to determine the port from which the TCNs are arriving.
Where are they coming from? Sign-on to the switch at the other end of the link attached to that port. Repeat this step until
the switch generating the TCNs is found (i.e. the switch that is itself not receiving a large
number of TCNs). Determine the problem at that switch.
Section 6.4
VLANs
The following describes common problems related to the VLANs.
VLANs 265
Chapter 6 RUGGEDCOM ROS
Troubleshooting User Guide
Problem Solution
VLANs are not needed on the network. Can Yes. Simply leave all ports set to type edge and leave the native VLAN set to 1. This is the
they be turned off? default configuration for the switch.
Two VLANs were created and a number of If the devices need to communicate at the physical address layer, they must be members
ports were made members of them. Now of the same VLAN. If they can communicate in a Layer 3 fashion (i.e. using a protocol such
some of the devices in one VLAN need to as IP or IPX), use a router. The router will treat each VLAN as a separate interface, which
send messages to devices in the other VLAN. will have its own associated IP address space.
On a network of 30 switches, management At the switch where the management station is located, configure a port to use the new
traffic needs to be restricted to a separate management VLAN as its native VLAN. Configure a host computer to act as a temporary
domain. What is the best method for doing management station.
this while staying in contact with these At each switch, configure the management VLAN to the new value. Contact with each
switches? individual switch will be lost immediately as they are being configured, but it should be
possible re-establish communication from the temporary management station. After all
switches have been taken to the new management VLAN, configure the ports of all attached
management devices to use the new VLAN.
NOTE
Establishing a management domain is often accompanied with
the establishment of an IP subnet specifically for the managed
devices.
266 VLANs