Archive for the ‘Networking’ Category

Wireless Routers – What is their REAL signal range?

Thursday, November 25th, 2010

There are too many variable to evaluate when trying to determine the range of a wireless router. Range is not the only important aspect of wireless as well. Throughput is also critical. None the less if we have a simple objective we can make some useful range estimates.  The objective we have is to create a wireless environment with acceptable internet speeds of 10 Mb/sec. (more…)

Images Backups & NAS – Essential for All

Sunday, November 21st, 2010

Image-Based Backup

A disk image backup is basically a backup of your whole hard drive. The basic idea is for backup software to use low-level disk I/O to just copy all the bits on your hard disk to another disk, without any particular regard for concepts like files. When you have a backup image, there’s no question of accidentally forgetting to backup a particular file,  if it was on the hard disk, then it got backed up. Due to the lost cost of both internal storage and Network attached storage (NAS) there is no reason not to image every server and workstation on your network. (more…)

Have you Spoken to your ISP lately?

Sunday, November 21st, 2010

Internet Service Providers (ISP’s) are really difficult to deal with. Not many business want to disrupt their operations so long as their service is reliable.  I think this is a mistake, especially if you do not have access to low cost high speed broadband.  Optimum from Cablevision and FIOS from Verizon are great bargains, and if you have them you probably don’t need to read further. (more…)

50 Mbit/S Fiber-Optic Circuit

Sunday, December 7th, 2008

We have been testing a 50 Mbit business class fiber circuit. It’s very difficult to measure the performance since so many external factors influence the real throughput. The ISP does not have tools to allow us to measure circuit performance. There are many speed tests on the internet, but they each produce significantly different results. Another factor influencing speed is the distance between the test sites. Most circuits show a dramatic drop off in performance when measured to a point more than a few hundred miles away. (more…)

Terminating the Terminator

Saturday, November 29th, 2008

Otherwise titled: “The Danger of Repairing Computer Systems Instead of Replacing Them”

We sent a one year old Sony Tape library out for repair. Was it worth it? It seems impossible that a three thousand five hundred dollar device should be scrapped that quickly. But in critical networks, it’s debatable if this equipment should be used again. (more…)

Duplex Mismatch on Managed Switches

Wednesday, November 26th, 2008

Duplex mismatch is a hidden problem on many networks. On an Ethernet network each device has a duplex setting, half or full; when two devices disagree about duplex, a duplex mismatch occurs. This degrades network performance. In business networks ISP’s usually manage routers and end users usually manage firewalls. Does either party check the duplex setting of the others device? Usually not! The result is collisions and performance issues. A typical cause of this problem is when one device (often the ISP’s router) is hard coded to full duplex and the end users device is set to auto-negotiate. One would expect the auto-negotiate setting to be capable of matching the setting of the ISP’s router, but it is not. This combination will result in a half duplex connection and less then optimum performance. Auto-negotiate works best when both devices are set in this mode. If your devices are connected to a managed switch, see how your devices are linking up to each other then correct the duplex setting if necessary. If you are NOT using a managed switch it will be more difficult to see or correct this issue.

MTU and Site-to-Site VPN tunnels

Wednesday, November 26th, 2008

Fragmented packets are not always easy to detect and many people do not realize that this can cause significant network problems, especially with VPN tunnels. Selecting the correct MTU size in Site-To-Site Tunnels is critical because an IP packet with a size of 1500, which is the standard ethernet MTU size, will often be too large. The encoded VPN packet is somewhat larger that the origiaal packet size, resulting in fragmentation. This fragmentation can cause VPN tunnels to drop, and is hard to detect.

Using the “ping” command you can test to find the optimum packet size and then adjust the MTU accordingly. There are a number of PC programs that will also adjust the MTU.

Typing ‘ping -f -l 1492 www.google.com’ where 1492 represent the packet size, will display the ping response time and will also display a message if the packets are too large and will be fragmented. You can adjust the packet size up or down in 8 byte increments until the best response that does not get fragmented is produced.