Dr. Michael J. Chudobiak wrote:
Blaming the 3com switch is very likely to be the wrong root cause.
High probability the 3com was not configured properly for the phone.
Just curious - what configuration issues did you have in mind?
A partial list of issues that we've seen in the last 12 years include:
- auto negotiation of duplex settings (mismatch)
- spanning tree disabling ports for first 30 seconds after any link
state change (some attached devices don't like that)
- spanning tree loops that end up isolating devices from the backbone
(spanning tree is usually implemented by the manufacture by default)
- various switch manufacturers have licensed/implemented cisco's
discovery protocol, and the user doesn't realize some equipment attached
to such ports actually use the cdp data to change port configuration,
while other devices might barf on those packets.
- assumptions that all switches operate at wire speeds and "buffer"
packets (eg, no such thing as a switch buffer; packets will be dropped
under high load conditions)
- distributing vlans across multiple switches where assumptions are made
relative to what happens when two or more vlans are transporting traffic
volumes that when combined exceed a trunk's port speed (eg, don't forget
about broadcast storms).
- switch forwarding tables that are too small (eg, workgroup switches)
and the table fills, essentially turning the switch into a hub
- bad assumptions relative to rate limiting broadcast and multicast
packets, and how that impacts normal traffic.
- etc, etc.
In the case of switch forwarding tables, its very common to see
experienced engineers (and others) "assume" a workgroup switch can be
used in a large network environment where 23 ports are used for devices
within a small workgroup. However, all switches on the market listen
for traffic from "any" source (including upstream link), and populates
the switch forwarding table with the mac addresses observed. Most
"workgroup" switches are limited to 1,024 table entries (sometimes
less), and when that table is full, does "something" that is vendor
dependent. Some vendors actually clear the table (resulting in the
switch operating as a hub until the table is rebuilt again), while other
vendors replace the oldest entries with the newest mac address observed.
Some vendors will timeout table entries in very short periods of time.
The end result from those actions is packets appearing on switch ports
for which the attached device has no need to hear (eg, increases the
packet traffic on a per port basis).
There are lots of other cases where a switch will forward multicast
packets to all ports (eg, poor/incorrect multicast support), and the
device attached to the port isn't designed to handle such packets. For
example, MS systems (and others) spew UPNP multicast packets looking for
or advertising gateways and other network resources. If a Snom device
hasn't been programmed correctly to ignore such packets, it might roll
over (I don't have a clue if that example is reasonable or even
accurate; its just an example only). Changing from one vendor's switch
to another might lead one to believe the switch was at fault, when in
fact the problem is more related to the switch implementor not properly
configuring the first switch. (And, in most cases, the implementor
doesn't have a clue what type of packets are flowing across the network,
let along which ones result in problems for attached devices.)
R.
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
