Tag Archives: speed

Duplex, Speed and MDIX, and an interesting problem

Posted on by

Two features of modern switches and routes is auto negotiation and auto mdix.

Auto Negotiation provides an easy way for network engineers to configure ports, allow automatic detection of speed and duplex settings. In an ideal world auto negotiation would be used on both ports, but in some cases (eg, when a network engineer only has access to one of the devices), a network engineer cannot tell if the port is statically set, or set to auto negotiation.

If a port is set statically on one device, and not the other, the auto negotiation process will detect the speed, but no the duplex. By the IEEE standard, if duplex can’t be detected for 10M or 100M then the duplex by default is set to half. Starting at 1G the duplex is set to full.

So what ends up happening is one port set to half duplex, and the other set to full. This causes a duplex mismatch, resulting in a slow link with packet loss. This leaves two simple solutions, set both to a static setting or set both to auto.

This is all well and good, and you end up statically setting the speed and duplex. Duplex is set to full, and 100 on both sides, and suddenly the link won’t come back up. Why is this?

Well on newer switches and devices, a feature called auto mdix allows network engineers to be lazy and use straight through cables where crossover cables are needed and vice versa. Some implementations even allow use of other pairs of wire when cables are damaged.

In Cisco devices when speed and duplex are set, auto mdix is disabled. Therefore if a network engineer has statically set the speed and duplex on one side, and has used the wrong cable, the link will fail.

Long story short…

  • Use the right cable types when connecting devices
  • Set duplex and speed the same on each device
  • If you can’t swap the cable, use auto on both sides

QOS

Posted on by

When configured correctly in a network QOS can be a wonderful thing. The ability to prioritize network traffic by it’s importance is crucial in most places that use VoIP systems to ensure that normal network traffic doesn’t kill off telephone calls. QOS can be both difficult to configure and simple depending on what systems you use and is being used in industry around the world.

With VoIP moving to home users now problems occur with keeping calls going when other home users are download or the like. Newer modems support QOS but still suffer from a simple flaw which impacts the usefulness of it. These modems can only control QOS for outgoing packets (uploads) and not incoming, becuase the QOS needs to be done on the ISP switches/routers. This flaw means that if someone packet floods your connection, QOS won’t be able to help your VoIP system.

There isn’t really a simple fix to this, however it would be nice if ISPs had a configuration page or the like to allow you to make simple QOS rules. Some people will want QOS on VoIP IPs/ports and others will want it on other services.