Network diag

Procedure for debugging a network connectivity problem:

(This is not complete, some steps may be missing.)

Or you can try an interactive version of this which is somewhat more complete.

Please see Help:Wifi for wireless networking issues.

Verify physical connectivity

• Check that network cable is plugged in.
• Check that network card is active -- lights should be lit and blinking.
  • If lights are not blinking, unplug the cable and see what goes out to make sure you know which light shows is the link light.
• Check network configuration (ipconfig on windows) to see if an ip address is available.
  • If ip address is valid, #Verify local connectivity.
  • If network cards are not listed, fix network card drivers.
  • If network card shows DISCONNECTED, diagnose physical wire and port for problems.
  • If network card shows DISABLED, right click and enable it or push the hardware switch (on some laptops)
  • If ip address is blank, zero, or bogus, try: (see also #Verify local connectivity)
    • if relevant, record and remove bogus hardcoded static configuration
    • also check static configuration for bogus DNS servers or web proxies (added by malware?)
    • ipconfig /release and then ipconfig /renew to attempt to force a new address.
• If no link is found on cable, or ip address fails to renew, use the fluke to diagnose the cable.
  • If another machine or fluke works, machine may be blocked for virus problems.
• If fluke does not work, trace cable back to wiring closet and repair there.

Bogus IP address

If a machine has an ip address obtained through DHCP that is not in the correct vlan: (especially 192.168 which indicates a rogue dhcp server)

• find the port in the wiring closet, and verify the port is configured to the correct vlan (check with fluke: look at other IP's on that network)
• Find the dhcp server
  1. use ipconfig /all and determine the address of the dhcp server; if it is not one of the engineering servers...
  2. ping the dhcp server
  3. use arp -a (or arp -na in unix) to get the ethernet address of the dhcp server (look for ip in list)
  4. report these numbers back for tracing

Common bogus ip addresses are:

0.0.0.0

this is a "null" ip address, and usually indicates the network is unconfigured and possibly windows is currently querying the dhcp server (you may need to wait a bit and try ipconfig /all again to see if it has changed)

169.254.*

this is the default "self assigned" address and indicates no dhcp server responded; likely the network is disconnected; try an ip release/renew cycle.

192.168.*

this is the "local network" address assigned by cable modem routers in a default configuration (these are generally illegal on the campus network); Please follow the arp -s procedure above and send the ip and ethernet address of the dhcp server to support.

10.0.*

bogus, from several on campus private networks; port is on the wrong vlan (or a reserved port was mistakenly used)

Correct ip addresses for most of campus might be:

10.170.*

10.173.*

10.174.*

A more detailed list of known vlans is available.

Verify local connectivity

Machine has valid ip address...

• Find the dhcp server and gateway router the local machine uses (ipconfig /all in windows, netstat -nr in unix)
  • Try to ping local gateway, dhcp server, and other servers in the same building.
  • if this fails, record ip addresses of these servers, then run arp -a and record the ethernet addresses for those ip's
• Try to access web pages on machines in the same building. (Suggest http://www.cecs.ucf.edu )
• Try to access web pages on machines outside the building. (Suggest http://www.ucf.edu/)
• Try to access web pages off campus (suggest http://google.com/ )

Note: ping is likely firewalled for off campus networks and normally will fail, and so ping is not a good connectivity test for hosts off campus.

Verify local servers are working

• verify local servers working correctly
  • try website locally
  • verify (with nslookup) nameservers are responding correctly
• Check other webservers on campus from remote site (done--failed?)
• Try failing websites by ip address instead of hostname to discriminate between a network failure and a DNS failure.
  • first resolve dns address to ip on another (working) machine
  • Suggested hostnames are www.ucf.edu and www.cecs.ucf.edu
• If DNS failure, at remote site, use nslookup to verify the paths through the DNS servers.
• if DNS failure for local sites only, this is a possible split horizon DNS problem
  • remove external DNS servers
  • (windows) remove proxy software and malware
  • linux:
    • remove dnsmasq
    • systemd-resolve --status
    • resolvectrl status
• If website by ip address does not work, use traceroute from both ends to determine the failure point and / or report connectivity problems to NOC.

cant map network drive in windows

1. First verify network connectivity -- ping server by hostname and ip
2. check network settings in ncpa.cpl --> interface --> properties
   1. Client for Microsoft Windows should be listed
   2. tcp/IPv4 -> properties
      1. check for hardcoded ip
      2. advanced -> dns -> check for hardcoded dns
      3. advanced -> wins -> default or enable NetBIOS over TCP/IP
3. Try network stack reset