Showing posts with label Networking. Show all posts
Showing posts with label Networking. Show all posts

Friday, December 20, 2013

Volts / Watts / Amps Converter

Category: — SkyHi @ Friday, December 20, 2013
How to use this tool:
Watts = Amps x Volts
Watts is also known as volt-amps and is typically used in conjunction with AC power circuits. Fill in any of the two fields to find the value of the third.
Example 1
You have a 12 Volt power supply that delivers 1 Amp of current. Fill in the Volts and Amps fields to find the Watts.
Example 2
The AC24-40 power supply is a 24V AC power supply that can power up to 40 VA.
  1. Enter 24 under volts
  2. Enter 40 under watts
  3. Click calculate
  4. You get 1.66 in this example.
Thus, the AC24-40 can supply up to 1.6 Amps at 24V AC.

 References:

Wednesday, September 12, 2012

Symptoms of duplex mismatches

Category: — SkyHi @ Wednesday, September 12, 2012

In Ethernet, a duplex mismatch is a condition where two connected devices operate in different duplex modes, that is, one operates in half duplex while the other one operates in full duplex. The effect of a duplex mismatch is a network that works but is often much slower than its nominal speed. Duplex mismatch may derive from manually setting two connected network interfaces at different duplex modes, but also derives from connecting a device that performs autonegotiation to one that is manually set to a full duplex mode.

Communication is possible over a connection in spite of a duplex mismatch. Single packets are sent and acknowledged without problems. As a result, a simple ping command fails to highlight a duplex mismatch because single packets and their resulting acknowledgments at 1-second intervals do not cause any problem on the network. A terminal session which sends data slowly (in very short bursts) can also communicate successfully. However, as soon as either end of the connection attempts to send any significant amount of data, the network suddenly slows to very low speed. Since the network is otherwise working, the cause is not so readily apparent.

A duplex mismatch causes problems when both ends of the connection attempts to transfer data at the same time. This happens even if the channel is used (from a high-level or user's perspective) in one direction only, in case of large data transfers. Indeed, when a large data transfer is sent over a TCP, data is sent in multiple packets, some of which will trigger an acknowledgment packet back to the sender. This results in packets being sent in both directions at the same time.

In such conditions, the full-duplex end of the connection sends its packets while receiving other packets; this is exactly the point of a full-duplex connection. Meanwhile, the half-duplex end cannot accept the incoming data while it is sending -- it will sense it as a collision. As a result, almost all of the packets sent by the full-duplex end will be lost because the half-duplex end is streaming either data packet or acknowledgments at the time.

The lost packets force the TCP protocol to perform error recovery, but the initial (streamlined) recovery attempts fail because the retransmitted packets are lost in exactly the same way as the original packets. Eventually, the TCP transmission window becomes full and the TCP protocol refuses to transmit any further data until the previously-transmitted data is acknowledged. This, in turn, will quiesce the new traffic over the connection, leaving only the retransmissions and acknowledgments. Since the retransmission timer grows progressively longer between attempts, eventually a retransmission will occur when there is no reverse traffic on the connection, and the acknowledgment are finally received. This will restart the TCP traffic, which in turn immediately causes lost packets as streaming resumes.

The end result is a connection that is working but performs extremely poorly because of the duplex mismatch.



Netgear FS728TS setting:
-Full duplex and MDIX
-Manually set cisco to full duplex

REFERENCES

Wednesday, March 14, 2012

How to test for packet loss on a broadband connection

Category: — SkyHi @ Wednesday, March 14, 2012
Measuring packet loss from home over a broadband connection can be a difficult task. Packet loss can occur anywhere along the path between your computer and the destination you are trying to reach over the Internet. Packet loss is typically a result of one or more of the following: network congestion, overworked routers and switches, slow roundtrip times, or possibly a result of traffic prioritization schemes used by service providers or the company hosting the site you are trying to access.

Without actively measuring the TCP flows of actual retransmissions (these products are usually too expensive to use for a home broadband connection), it is hard to determine if there are real retransmissions occurring. The mechanisms you mentioned, ping and trace route, are the most readily available tools for at-home users for helping to determine where there is slowness on the Internet. Ping measures the roundtrip time between your computer and the IP address you are pinging. Trace route measures the response times of the routers along the path between your computer and the IP address you are trace routing.

Using Ping

The best way to measure packet loss using ping is to send a large number of pings to an IP address, and then look for failed responses to those pings. For instance, if you ping something 50 times in a rapid fashion, you can measure the number of failed responses and use this as an estimate of "packet loss." Anything over five percent is probably something to be concerned about.

On a Windows machine, this can be accomplished by using the following command at the command prompt:

Ping -n 50 (IP Address or domain name [www.website.com])>
The "–n" tells ping to send a set number of pings, and "50" is the number to send.

Afterwards, you will get a summary of the test that includes the number lost and a percentage:

Ping statistics for 199.181.132.250:
Packets: Sent = 6, Received = 6, Lost = 0 (0%)
Approximate round trip times in milliseconds:
Minimum = 26ms, Maximum = 29ms, Average = 27ms
If you see a very high average roundtrip time (greater then 100ms), this will also cause you to experience slow network downloads.

One way to try to eliminate certain parts of the network that may be the cause of packet loss is to do the ping test along various segments along the path. The first place I normally start testing is the local "default gateway." This is the first router that all your data is transmitted to on the network. If there is high packet loss on this segment, then the problem is localized to your service provider's network.

You can find the IP address of your default router by typing in the "ipconfig" command at your Windows command prompt. This will display the following:

Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix_: domainname.com
IP Address. . . . . . . . . . . . : 192.168.2.189
Subnet Mask . . . . . . . . . . . : 255.255.252.0
Default Gateway . . . . . . . . . : 10.10.0.1
What you are looking for is the default gateway IP address. In the example above, it is 10.10.0.1.

Using Trace route

Trace routes can be run by using the trace route command at the Windows command prompt. On Windows XP this is:

tracert (IP Address or Hostname)
While the output doesn't show you packet loss, it will show you if there are slow-responding routers along the path.

The output will show you the response time of all the routers. The following is an example:

5 ms 2 ms 3 ms malibu.domain.com [10.10.0.1]
10 ms 6 ms 7 ms 10.60.0.6
9 ms 7 ms 7 ms 10.20.0.1
6 ms 7 ms 7 ms x130.cd9e68.sj.concentric.net [205.158.104.130]
7 ms 7 ms 8 ms ge9-0.dcr2.dc-fremont-ca.us.xo.net [205.158.60.169]
7 ms 7 ms 7 ms ge2-0.dcr1.dc-fremont-ca.us.xo.net [65.106.2.205]
10 ms 7 ms 8 ms p5-1-0-2.rar2.sanjose-ca.us.xo.net [65.106.2.153]
10 ms 9 ms 11 ms p1-0.ir1.paloalto-ca.us.xo.net [65.106.5.178]
9 ms 10 ms 15 ms 206.111.12.114.ptr.us.xo.net [206.111.12.114]
9 ms 10 ms 10 ms svl-core-03.inet.qwest.net [205.171.205.29]
29 ms 28 ms 29 ms stl-core-02.inet.qwest.net [205.171.5.85]
30 ms 29 ms 29 ms sea-edge-03.inet.qwest.net [205.171.26.42]
* * * Request timed out.
* * * Request timed out.
28 ms 28 ms 29 ms sam.abcnews.go.com [199.181.132.250]
If you see trace route roundtrip times along the path greater than 100ms (1/10th of a second), this can cause slow transfer times over the network.

From the above, you can see that data travels along lots of different networks (XO, Qwest, ABC). This is part of the beauty of the Internet. The downside is that it places the ability to resolve slow response times out of the hands of individual users. The best place to start is to make sure that there is not packet loss between yourself and your service provider.



Measuring packet loss

n continuing on with my commitment to describe my favorite network utilities, I bring to you mtr:
$ mtr -r -c 10 mail.prefetch.net
HOST: me                           Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 10.238.4.1                    0.0%    10    9.2   8.2   5.4  12.6   2.1
  2. 68.86.108.13                  0.0%    10    9.2   9.4   6.3  14.9   2.8
  3. 68.86.106.45                  0.0%    10   15.1  10.1   6.9  17.5   3.5
  4. 68.86.106.13                  0.0%    10   14.0  11.0   5.7  22.1   4.8
  5. 68.86.106.9                   0.0%    10   14.6  11.4   7.2  18.5   3.6
  6. 12.118.120.89                 0.0%    10   10.2  10.3   8.2  14.6   2.2
  7. tbr1-p012201.attga.ip.att.ne  0.0%    10   23.8  25.8  21.8  33.9   3.6
  8. tbr2-cl1.wswdc.ip.att.net     0.0%    10   27.3  26.9  23.7  33.4   3.0
  9. ggr2-p390.wswdc.ip.att.net    0.0%    10   23.0  27.6  22.6  41.0   5.6
 10. so6-3-0-2488M.ar1.DCA3.gblx.  0.0%    10   26.0  30.4  23.9  43.3   6.3
 11. so0-0-0-622M.ar2.CLE1.gblx.n  0.0%    10  130.3  49.8  37.7 130.3  28.4
 12. Enet-Inc-Internet.so-0-3-3.a  0.0%    10   51.2  45.9  42.5  54.9   4.0
 13. extreme.xlhost.com            0.0%    10   44.2  67.1  41.4 261.4  68.3
 14. mail.prefetch.net            0.0%    10   48.3  56.6  41.5 172.9  40.9
mtr allows you to view hop-by-hop latency metrics, and is invaluable for finding busy devices between two endpoints. Some routers will place low QOS priorities on ICMP traffic, so it is important to capture traffic at various intervals to see if a device is truly overloaded.


REFERENCES
http://searchnetworking.techtarget.com/answer/How-to-test-for-packet-loss-on-a-broadband-connection
http://nixcraft.com/centos-rhel-fedora/15483-showing-packet-loss-interface.html
http://prefetch.net/blog/index.php/2005/08/29/measuring-packet-loss/

Wednesday, December 21, 2011

Troubleshooting faulty network connectivity

Category: — SkyHi @ Wednesday, December 21, 2011

part 1: A step-by-step guide

“My computer won’t connect to the Internet”.
“I can’t get online”.
“I’m getting ‘page cannot be displayed’ errors”.
If you have worked as a network administrator or help desk specialist, you have probably heard these complaints and variants of them more times than you can count. Between improper IP addressing, malfunctioning hardware or faulty cables, incorrect DNS resolution, incorrect access permissions and a slew of other factors, there are many reasons why modern computer users could experience difficulty getting their client machines online and/or connecting to the resources that they need (i.e., the Internet in general, a certain website, a network share, a printer, etc).
Given the many interconnected technologies that work together to provide modern computer networking, it is no surprise that the inability to get online is one of the most common complaints of computer users. An inspection of any Web discussion forum focusing on technical support will reveal that networking problems are among the most common challenges that users face (see, for example, Computer Hope and Tech Support Guy).
Difficulties can range from the inability to get an IP address from a DHCP server, incorrect DNS server IP addresses on the client, malfunctioning DNS servers, a faulty network interface card (NIC) or NIC driver, malware attacks, strict firewall rules, misconfigured Web browsers, etc.
Since so many networking component technologies could be the culprits behind a lack of connectivity, a unified methodology towards troubleshooting network errors and outages is ideal for technicians. Why? To help ensure that you do not overlook any steps, or do any unnecessary or repetitive work as you attempt to establish the required connectivity.
The CompTIA Network+ troubleshooting model provides a broad, high level plan of action for remedying faulty connectivity.
  1. Identify the symptoms and potential causes. In this first step you define and determine the nature of the problem. Is it the user or computer that is problematic? Are all websites unreachable, or just one or a few? Is the computer consistently online or is the connection flapping? Are websites reachable by IP address but not by name? Are there any error messages indicating what type of error was encountered? Based on your answers to these questions you can begin to make educated guesses as to the cause.Gather detailed information.
  2. Identify the affected area. This step is similar to the first step, but here you determine the extent of the problem. Is it affecting one computer or user, or multiple computers or users? Are all computers in the subnet (or all users in the domain) affected? Is the whole network down? If you are providing support to another user, can you reproduce the error yourself? Gather detailed information.
  3. Establish what has changed. This is where you try to put the connectivity problem in some kind of time frame. Find out if the user was ever able to successfully do what he now cannot do. When did the error first appear? Before the appearance of the error were there any programs or operating system updates installed? How about new drivers or browser plugins? Were any new nodes (clients, servers, networking devices, printers, etc) added to the network? Any new users, user groups, or Active Directory objects such as domains, OUs, or sites?
  4. Establish the most probable cause. Use your technical expertise to isolate and explain the cause of the problem. Some in-depth investigation and diagnostic tools will probably be required. This step is described in more detail below.
  5. Determine if escalation is necessary. If you believe that the connectivity error is outside your scope of administration, you will need to transfer responsibility for its resolution to another entity. For example, if you cannot connect to the Internet and you strongly believe that the problem is not your computer, router, or other equipment, you will need to contact your Internet service provider (ISP) and ask them to investigate…perhaps one of their lines or routers is down. Another scenario might involve a piece of equipment on your network that is contractually administered by a third party.
  6. Implement an action plan and solution including potential effects. Whether the responsibility to fix the error falls on you or if you need to transfer it to another party, you must devise a resolution and start checking off action items.
  7. Test the result. When you believe the steps of the action plan have been fulfilled, try to re-create the error. Observe the results of the implementation. Is the problem gone? If not, repeat steps 4, 5, and 6.
  8. Identify the results and effects of the solution. Once a solution has been found, ensure that normal network operation has been restored and that no new problems have been introduced.
  9. Document the solution and process. Describe the error conditions and the steps taken for a solution. This will aid you in troubleshooting the same or similar problems in the future. Make sure you include a sufficient amount of detail, including operating system versions, application versions, driver versions, software vendor update numbers, etc.

Step 4 in detail

Step 4, ‘Establish the most probable cause’, is the one that will require the most time and effort on your part. To troubleshoot TCP/IP connectivity on a technical level, this step involves its own set of steps. When a network host cannot connect to a desired resource, the following procedures will help you narrow down the cause of the problem.
  1. Ping the local loopback address of your network adapter, which is 127.0.0.1. If you get replies, you know that the TCP/IP protocol suite is installed and functioning correctly. If this ping fails, it might be because the TCP drivers are corrupted or the network adapter might not be working.
  2. Ping your own IP address. Use the command ipconfig (or ifconfig for Linux/Unix) to determine your IP address. If you don’t have one, this is a very useful clue as to the nature of your problem…if your computer’s routing table is correct, this ping is simply forwarded to the loopback address of 127.0.0.1.Note: If your IP address is returned as 169.254.x.x, you have been assigned an APIPA IP address. This means that the local DHCP server is not configured properly or cannot be reached from your computer, and an IP address has been assigned automatically. APIPA is a feature of Microsoft Windows that acts as a DHCP failover mechanism. When a DHCP request or server fails, APIPA allocates addresses in the private range 169.254.0.1 to 169.254.255.254. This functionality is also known as Link-Local address assignment or zero configuration networking.
  3. Ping the IP address of a known good host in your subnet.This will determine if your IP address and subnet mask are valid, and if the switch or router you are connected to is functioning properly; perhaps you are plugged into a faulty port or your network cable is faulty. Also, can other hosts in the subnet ping your IP address? If pings in this step fail, ensure that the network cable is plugged into the network adapter and ensure that you get a link light. The link light indicates whether a network connection exists between the NIC and the network. If the link light is off, the cable or switch port are probably at fault, or perhaps the NIC itself is toast. If you can ping both the loopback address and your own IP address but not hosts in the local subnet, try to clear out the ARP cache and reload it. This can be done by using the Arp utility on the command line interface (CLI). First display the cache entries with thearp -a or arp -g commands. Delete the entries with arp -d <IP address>.
  4. Ping the IP address of the default gateway. This is important if the error revolves around the inability to access hosts and resources in other networks, such as networks at remote sites or on the Internet. The default gateway on a local area network (LAN) is the network host to which all data traffic bound for other subnets is sent. If network hosts do not know the IP address of the default gateway, they cannot send data traffic to remote networks. Therefore the default gateway serves as an access point to other networks. Similarly it acts as the entry point into the network for remote hosts sending data to local hosts.
  5. Ping the IP address of a host in another subnet. If you can reach the default gateway, this step will verify that there is proper routing between your subnet and the destination subnet.
  6. Ping the host name of a host in another subnet. This step will help ensure proper DNS resolution of host names of remote hosts. If you cannot successfully ping the remote host name after successfully pinging the remote host’s IP address, the problem is with DNS and not with network connectivity itself.
  7. Run a Tracert (traceroute in Linux/Unix) and PathPing analysis to a remote host to verify that the routers between you and the destination host are operating correctly.Traceroute/tracert is a network diagnostic tool for displaying the route (path) and measuring transit delays of packets across an IP network. PathPing combines the features of the ping and tracert commands. It sends packets to each router (hop) over a period of time and computes results for each hop. In this way PathPing can show if there are any problematic routers between you and the destination.
  8. Other troubleshooting steps you might try include:
    • Issue the ipconfig /release and ipconfig /renew commands.
    • Issue the ipconfig /flushdns and ipconfig /registerdns commands.
    • Right-click the network icon in the system tray and choose ‘Diagnose and repair’ (Vista) or ‘Troubleshoot problems’ (Windows 7). In Windows XP right-click the network connection and choose ‘Repair’.
    • Reboot your computer. Power cycle your switch, router, and cable/DSL modem (unplug them and plug them back in). Does the router firmware need to be updated? It should be at the latest release. Are all cables plugged in properly on all components, such as the network adapter on the computer and on all other devices until the cable goes into the wall?
    • Is the computer joined to the proper workgroup or domain? In a workgroup all computers are peers and each computer has its own set of user accounts. To log on to any computer in the workgroup, you must have an account on that computer. All computers must be in the same subnet and use the same workgroup name.
      A domain is a group of accounts and network resources that share a common directory database and set of security policies. One or more computers are servers. Network administrators use servers to control the security and permissions for all computers on the domain. Domain users must provide a password or other credentials each time they access the domain. If you have a user account on the domain, you can log on to any computer on the domain without needing an account on that particular computer. The computers can be on different local networks.
    • Take a peek at the Windows Event Logs using the Event Viewer (Control Panel -> Administrative Tools -> Event Viewer, or Start, type eventvwr, hit Enter. In Linux take a look at/var/log/messages using the tail or less commands. Graphical tools for reading event logs in Linux will vary based on your distribution and desktop environment (such as Gnome or KDE).
For some other in-depth articles dealing with network connectivity troubleshooting, you may want to read Mitch Tulloch’s TCP/IP Troubleshooting: A Structured Approach and Brien Posey’s Troubleshooting Connectivity Problems on Windows Networks.
Go to Part 2 of this series.
In my previous article describing the troubleshooting steps for faulty TCP/IP connections, I mentioned several commands such as ping, traceroute, and ipconfig that could assist you in pinpointing problematic network components. These commands and several others like them are commonly referred to as TCP/IP utilities because they are tools that let you perform diagnostics and queries on the network which you are examining.
To compliment Part 1 of this two-part series, Part 2 is a reference list of the TCP/IP utilities which will describe the intended uses and options for each. These tools natively run in command line interface (CLI) environments (or in Linux and Unix, “shell prompts”), but as several entries in this blog show, there are a great many graphical utilities available that let you use the TCP/IP utilities (and view their output) in graphical format. In this article, however, I will stick with the default CLI usage and functionality.
When working in a CLI environment in Windows, I prefer to use Windows PowerShell as opposed to the default Windows command prompt (cmd.exe).
Remember: the best way to learn and understand these tools is to practice and experiment with them. Also bear in mind that knowledge of these commands is essential during ethical hacking efforts.
Jump to:


REFERENCES

Tuesday, November 8, 2011

Testing Network Performance and Throughput with Iperf

Category: — SkyHi @ Tuesday, November 08, 2011

Testing Network Performance and Throughput with Iperf
Scenario 1: You you have two servers located a large geographical distance apart, say one in The US, the other in the UK. You are copying a large file between these two locations via scp but you are only averaging 200Kbps. You know it should be faster and want to increase the TCP window scaling size according to the bandwidth delay product, but want a reliable way to test the changes easily to see if there is improvement.
Scenario 2: You have a local two server gigabit network where each server has a nice GigE network card connected via a good gigabit switch. You want higher transfer speeds between the servers and are considering enabling jumbo packets on the servers and network switch but need a way to verify that the changes have actually increased throughput.
Scenario 3: You use VOIP for your phone system and have a remote office that has terrible call quality to your Asterisk server. You think the network connection is to blame but need a way to verify the amount of jitter and packet loss.

For all three of the above scenarios Iperf is a great tool that can be used to measure the maximum network throughput and quality of a network connection between two separate servers. Iperf is available for pretty much every Linux distribution and is available for Windows as well.
Using Iperf in the simplest way possible, you can perform a TCP bandwidth test between two servers. By default Iperf uses TCP and listens on port 5001. When testing, one server will be the ‘server’ while the other is the ‘client’. In this configuration you will be testing bandwidth from the client to the server.
Lets test performance between two servers on a local 100Mbit LAN. First start the server on the server:
1
2
3
4
5
]$ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
Notice it has opened a listening socket on TCP 5001, make sure there are no issues with firewalls on this port. You can override the default port and specify a different one with the -p option.
Now on the other machine which will be the client, lets start a test:
1
2
3
4
5
6
7
8
$ iperf -c 10.20.20.100
------------------------------------------------------------
Client connecting to 10.20.20.100 TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 10.20.20.105 port 53423 connected with 10.20.20.100 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec   117 MBytes  97.2 Mbits/sec
I used the -c (client) option and specified the ip of the machine we started Iperf on as the server which has an ip of 10.20.20.100. Throughput of this test resulted in 97.2Mbps transfer rate which is excellent for a 100Mbps link.
This test was only in one direction from the client to the server. If we wanted to test throughput in both directions we could add either the -r option which will run a bidirectional test individually one after the other, or the -d option which runs a bidirectional test simultaneously.
The default length of the test is 10 seconds. If you wanted to increase the length of the test to better benchmark a connection for a sustained period of time you can use the -t option to specify the run time in seconds.
UDP testing is a crucial test that you can perform to diagnose issues with VOIP and other udp based protocols. A UDP test can detect jitter and packet loss between servers. To perform a UDP test, use the -u option when starting iperf:
1
2
3
4
5
$ iperf -s -u
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:  126 KByte (default)
Then start a UDP test on the client:
1
# iperf -c 10.20.20.100 -u
When completed you will have a report similar to the following:
1
2
3
4
------------------------------------------------------------
[  3] local 69.160.56.100 port 5001 connected with 69.160.56.105 port 36002
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec   0.002 ms    0/  893 (0%)
The above results are typical for a small local network with little network congestion, very low jitter and zero packet loss. Connections over larger distances that have more congestion can begin to cause excessive jiter and packet loss which will result in poor voice quality using VOIP. High levels of packet loss above one or two percent will also result in a lot of TCP retransmission of packets which can further increase network congestion.
A couple notes on these tests to keep in mind. Iperf is performing a test between memory on each server. In the real world when copying files between servers disk io is involved. Depending on the type of drives, interfaces being used, and any raid card or operating system file caching, you may see different results than what Iperf is reporting since it is only showing performance between memory and is not including any possible latency from disk io. Iperf has functionality to test by reading a file with the -F option and should be used if you want to rule out your disks being a bottleneck.
If you are seeing very poor performance transferring files between servers and have ruled out any type of physical layer issues causing the errors, look into the network card type and expansion slot type that is being used. Many cheaper network cards have very software based drivers that offload most of the network processing to the host cpu. Bus speeds are also important. If you have a gigabit network card in a 32bit 66Mhz PCI slot, you are limited to the maximum throughput that slot can provide which is 266.7MBps. Proper 64bit PCI-X or PCIe NICs should always be used for best performance with gigabit connections.

REFERENCES
Subscribe to: Posts (Atom)