[Asterisk-Users] Snom firmwares suck <--additional datapoint to consider

[Rich Adamson]

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.