Siemens RUGGEDCOM ROX II, User Manual

Page: 796 / 798

Chapter 19
Troubleshooting
RUGGEDCOM ROX II
CLI User Guide
750 Multicast Filtering
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.
Section 19.3
Multicast Filtering
The following describes common problems related to multicast filtering.
Problem Solution
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.
IMPORTANT!
Multicasting will introduce latency in all traffic on the network. Plan the
network carefully in order to account for capacity and latency concerns.
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.