1 / 26

Understanding Network Failures

Understanding Network Failures. 2.1 "ping usage”. Please enable audio (speakers, volume) & full-screen <F11>. Click to continue. 2.1. Understanding Network Failures. Click to continue. 1.0 Understanding Network Failures (program overview)

sondra
Download Presentation

Understanding Network Failures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Understanding Network Failures 2.1 "ping usage” Please enable audio (speakers, volume) & full-screen <F11> Click to continue. . . 2.1

  2. Understanding Network Failures Click to continue. . . 1.0 Understanding Network Failures (program overview) 2.0 Intro to ping2.1 Usage Intro (Strybd prototype) 2.2 Lab 2.3 Assessment Plus addt’l e-Learning Modules, labs and assessments: 3.0 Intro to traceroute, lab, assessment 4.0 Intro to netstat, lab, assessment 5.0 Intro to ipconfig (ifconfig), lab, assessment 6.0 Intro to nslookup, lab, assessment 7.0 Intro to whois, lab, assessment 8.0 Pre-Assessment Modules (pre-tests for each module) 9.0 Assessment Modules 10.0 Labs: User Tools & Network Utilities (telnet short-cuts, PCHAR/TTCP,…?)

  3. 2.1 Lesson Objectives Click to continue. . . In this lesson, students will utilize “ping” to validate network connections, and analyze responses reported from “ping” Audience information: • Call Center I & II/CCNA I & II • 20 Minutes (duration) 2.1.1

  4. ? Network failures: The sky is falling! 2 1 Server 1 Click to continue. . . Customer Support: “How may I help you?” The Internet e0 Click to continue. . . s2 User: “My Internet is down!” Center s0 s1 s0 s0 CS: “Can you describe Boaz Eva e0 e0 the problem for me?" User: “Becky isn't getting my text messages!: (demo) Click to run demo. . . 3 4 5 6 Recent policy change: No "text" Recent policy change: No "text" “Becky” Becky 2.1.2 Click to continue. . .

  5. Before escalating this call . . . ? Policy change or local failure? • Do the interfaces show a link light? • LAN/WAN connectivity? (# ping yahoo.com) For most users: The browser is “The Internet” Example: Text messages are being dropped by “Boaz” router . . . the sky isn’t falling! 2.1.3

  6. Review: Before escalating a customer call . . . The browser is “The Internet” (for most users) Consider local failures first! • Does the interface show a link light? Identify recent (local) modifications • Are new patches applied? Applied correctly?

  7. Experience suggests . . . Many local network “failures” are due to operator error • Un-skilled users, un-trained personnel, invalid configurations . . . Suspect recent changes or modifications • Have all required patches been applied correctly? • Check the logs (recent activity? upgrades?)

  8. 1.0 (Review): Common Causes of Network Failures Alert: s2is “down”! Circuit “outages” are a common cause of real (actual) network faults • Example: Heavy equipment workers & sea dredging have cut cabling, power lines, deep sea fibre (very rare!) • Example: Denial of Service (DoS): More common. . .? Click the "heavy equipment worker". . . DoS Attacks = Sluggish network segments For our example, the Internet is down! Example: “ping” may be used to verify all subnets “up” during DoS attack Click to validate networks (demo) Status: (ping or traceroute script) • All Routers and sub-nets “up” (reachable), except . . • Center-s2 (Serial_2) “unreachable” during attack 2.1.4 (1.0)

  9. 2 Boaz WS4 192.168.10.62 # ping 192.16.10.62 Server 1 Round-trip: A Request/Reply “pair” Sw1-8 Center-sw1 Echo Request: “Is WS4 online?” (demo) e0 s2 Click to continue. . . Echo Reply: Center “Request received!” (demo) s0 s1 s0 Click to continue. . . s0 Eva e0 e0 What if this ping fails? Reduce scope of test. . . How many intervening devices, as shown? Boaz-sw1 Sw1-2 3 5 6 2.1.5 Click to continue. . .

  10. 2 Center Example: Using ping Server 1 Initial troubleshooting # ping <IP-address> (e.g. ping<local nodes>) e0 s2 Demonstration:“ping Serial_0” Serial_0 Serial_0 Serial_0 s1 s0 s0 # ping 192.168.10.65 Boaz Eva e0 e0 Type <ESC> to abort. Sending 5, 100-byte ICMP Echosto 192.168.10.65, timeout is 2 seconds: ! ! ! ! ! Success rate is100 percent (5/5), round-trip Min/Avg/Max = 4/6/9 ms 3 4 5 6 Click to continue. . . 2.1.6 Click to continue. . .

  11. Using “ping” continued. . . ping uses ICMP Echo Request/Reply ICMP Message types: • EchoRequest/EchoReply: “ping” connectivity • Dest unreachable: Packet delivery problem • Time exceeded: Packet discarded (TTL) • Redirect: Better route via “router_ip_address” There are many ways to utilize “ping” . . .

  12. Extended “ping” (options) • Specify data length, source and dest. addresses • Specify “next hop” • Set timeout interval (default: 2 seconds) • Specify ping count (repeated ping attempts) • Specify data pattern (sliding “1s”, or 0xABCD) • Validate response data (data validity) • Set: Don’t Fragment, include Timestamp, etc

  13. Initial Network Tests “My internet is down” could be a sluggish network segment, slow server, or equipment fault . . . ? • How many intervening devices? (firewall, appliance, proxy server, CSU/DSU, …) • Is it a recurring fault or temporary slowness or random outages? Collecting accurate failure data is crucial!

  14. Review: Initial Network Tests: What to consider? User: “My internet is down . . .” • Could be an intervening application server, device or appliance • Intermittent faults may appear as temporary service outages (e.g. threshold exceeded, server rebooting, . . .) “ping yahoo.com” = “Are you there?”

  15. ping: Validate Connectivity Standard diagnostics using “ping”: # ping 127.0.0.1 # ping <IP address of local host> # ping <default-gateway IP address> # ping <remote destination IP address> # ping <remote destination hostname>

  16. What is a 20% success rate? ECHO Request (from WS2): Are you "online", WS4? # ping 192.168.10.62 Type <ESC> to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.62 ECHO Request (from WS2): 5 Request/Reply "pairs" 100-byte, ICMP packets timeout is 2 seconds: . . . . ! (.) period after 2 sec. Success rate is 20 percent (1/5), round-trip _min/avg/max = 76/76/76 ms ECHO Reply (to WS2): 1 of 5 = 20% success Temporary? Recurring? ping responses:(.) = timeout, (!) = success, (N) = Net-Unreachable, (U) = Dest-Unreachable 2.1.7

  17. Review: Using ping “ping 192.168.10.65” will validate network connectivity (between source and destination) • “Are you there?” (ECHO Request sent from source) • “I am connected” (ECHO Reply received from destination) • 5 of 5 packets = 100% success rate See, also, www.cwdotson.com/NetFailures,dd2

  18. Questions: Using ping Recall the ping responses: An exclamation (!) indicates which test result? A) Failure; B) Success; C) Time out B) Success Recall the ping responses, and exclamation (.) indicates: A) Failure; B) Success; C) Time out C) Timeout False (True/False) Ping is an excellent performance monitor (True/False) 2 of 5 successful packets indicates a success rate of 20% False (40% success) (True/False) When ping is executed, the source issues an Echo Request to the destination. True 2.1.8

  19. Intermittent Vs. Recurring Failures Intermittent faults: Difficult to identify & fix • Occasional errors (“Time exceeded”) • Errors may occur only under certain conditions (e.g. temporary outages, threshold exceeded) Recurring faults: Easier to identify (Server, router, or interface is “down”) • Chronic fault (“Network unreachable”)

  20. Limitations of “ping” ping can validate “connectivity”only! # ping yahoo.com Type <ESC> to abort. Sending 5, 100-byte ICMP Echos to 209.131.36.159 timeout is 2 seconds: ! ! ! ! ! • “100%” success expected! • ICMP packets do NOT represent “real world” traffic Success rate is 100 percent (5/5), round-trip _min/avg/max = 23/26/29 ms • ping: Response is for few, small pkts Caution:pingis a poor tool for performance monitoring! • Network performance varies for ”real world” traffic • Text traffic is much different than streaming video or VoIP

  21. Review: ping limitations ping: Validates network paths • Sends a few, small packets (e.g. 100-byte, ICMP packets are not “real world” traffic) • For small, idle networks 100% success rates are common (not “real world”) Only confirms basic connectivity between remote nodes

  22. Lesson Summary In this lesson we: • Examined LAN/WAN failures (DoS, circuit breaks) • Used “ping” to validate a network connection with remote nodes • Examined responses reported by “ping” to analyze network performance 2.1.9 The End. . . The End. . .

  23. Destination Unreachable Hosts/Routers return “Dest. Unreachable” when: Data cannot be completely delivered to receiving application at the destination host • Example: ICMP messages sent back to WS2 is reponse to “ping” (e.g. # ping serial_0) • Network unreachable: No matching route • Host unreachable: packet is routable but host not responding • Can’t fragment: Older router/Large pkts (must fragmnt but “do not frag” bit set) • Protocol unreachable: Transport layer protocol “down” at host • Port unreachable: Host application fault (port un-opened by app)

  24. Isolating IP Routing Problems: Use ping to trace a path (identify “last” router) telnet to last last “traced” router or node # telnet <IP address-router_lastknown>

More Related