Brand: SIEMENS
Category: Control Unit
Document Type: Manual
Language: EN
Manual for RUGGEDCOM ROX II v2.12
Uploaded: Nov. 21, 2025, 7:23 p.m.
Manual Publish Date: 2018-07-01
Warranty Information
Refer to the License Agreement for applicable warranty terms and conditions.
This manual provides detailed instructions for using the Command Line Interface (CLI) of the RUGGEDCOM ROX II device. It covers a wide range of functionalities including system administration, security configurations, network utilities, device management, and troubleshooting. Users can learn to navigate the CLI, configure various network services, manage users and security settings, monitor device status, and resolve common issues. The document is structured into chapters, each focusing on a specific area of the device's operation.
Troubleshooting and error codes
| Problem | Solution |
| A link seems fine when traffic levels are low, but fails as traffic rates increase OR a link can be pinged but has problems with FTP/SQL/HTTP/etc. | A possible cause of intermittent operation is that of a duplex mismatch. If one end of the link is fixed to full-duplex and the peer auto-negotiates, the auto-negotiating end falls back to half-duplex operation. 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 Link Fault Indication (LFI) protection feature. | Make sure LFI is not enabled on the peer as well. If both sides of the link have LFI enabled, then both sides will withhold link signal generation from each other. |
| When started, a multicast traffic feed is always distributed to all members of the VLAN. | Is IGMP enabled for the VLAN? Multicasts will be distributed to all members of the VLAN unless IGMP is enabled. |
| Computers connected to the switch receive multicast traffic, but not when they are connected to a router. | Is the port used to connect the router included in the Router Ports list? To determine whether the multicast stream is being delivered to the router, view the statistics collected for switched Ethernet ports. For more information, refer to Section 8.1.3, "Viewing Switched Ethernet Port Statistics". Verify the traffic count transmitted to the router is the same as the traffic count received from the multicasting source. |
| The video stream at an end station is of poor quality. | Video serving is a resource-intensive application. Because it uses isochronous workload, data must be fed at a prescribed rate or end users will see glitches in the video. Networks that carry data from the server to the client must be engineered to handle this heavy, isochronous workload. Video streams can consume large amounts of bandwidth. Features and capacity of both server and network (including routers, bridges, switches and interfaces) impact the streams. Do not exceed 60% of the maximum interface bandwidth. For example, if using a 10 Mbps Ethernet, run a single multicasting source at no more than 6 Mbps, or two sources at 3 Mbps. It is important to consider these ports in the network design, as router ports will carry the traffic of all multicast groups. |
| Multicast streams of some groups are not forwarded properly. Some segments without subscribers receive the traffic, while some segments with subscribers do not. | Make sure different multicast groups do not have multicast IP addresses that map to the same multicast MAC address. The switch forwarding operation is MAC address-based and will not work properly for several groups mapping to the same MAC address. |
| Computers on the switch issue join requests, but do not receive multicast streams from a router. | Is the multicast route running IGMP version 2? It must run IGMP version 2 in order for IGMP Snooping to operate properly. |
| Unable to connect or disconnect some switch ports, and multicast goes everywhere. Is IGMP broken? | IGMP is not broken. This may in fact be proper switch behavior. When the switch detects a change in the network topology through RSTP, it acts to avoid loss of multicast traffic. If configured to do so, it starts forwarding all multicast traffic to all ports that are not RSTP Edge ports (because they may potentially link to routers). This may result in some undesired flooding of multicast traffic, which will stop after a few minutes. However, it guarantees that all devices interested in the traffic will keep receiving it without interruption. The same behavior will be observed when the switch resets or when IGMP Snooping is being disabled for the VLAN. |