Wireshark in the Large Enterprise June 16, 2010 Hansang Bae

1. Wireshark in the Large Enterprise June 16, 2010 Hansang Bae Senior Vice President | Citi (f.k.a. Citigroup) Email: hansang@gmail.com Please refer to the “answersheet.docx” file for additional information about this presentation. These sessions will be available on youtube: http://www.youtube.com/user/hansangb SHARKFEST‘10 Stanford University June 14-17, 2010

2. Please Let TCP Do Its Job. Problem: Application developers escalate an issue with slow file (MQ) transfers. Troubleshooting Steps: • What should you rule out immediately? • What affects throughput and why? • Look for patterns and ask the right questions. Quick examination would reveal what? Doesn’t it look normal? Can you spot the issue quickly? Were you guys paying attention yesterday?!? • Use the graphing tools. Picture is worth a thousand words. • Setup your Wireshark environment in a standard way. Use Configuration Manager to help you.

3. Don’t Jump to Conclusions! Another application development team escalates a “slowness” problem. Troubleshooting Steps: • Trust But Verify (tcp.analysis.flags) • Look for telltale signs of problems. • Who’s sending and who’s receiving? Besides looking at the name of the file….can you figure it out? • Apply Occam’s Razor when solving problems.

4. Another (unusual) Hidden Danger! Application testing with an external vendor doesn’t work. It tested fine when tested with intra-resources. Troubleshooting Steps: • If it works internally but not with an external vendor (reachable via Internet) what device should you suspect? Learn to Divide and Conquer – the power of binary search! • Have “High Bandwidth Conversations” with qualified peers. • Look out for “Defaults” HSB’ism: Defaults are the guardian angels for the clueless! • Another case of “picture is worth a thousand words”

5. Odd Numbers are Evil? Really? Software Update System is slow in delivering packages to staging servers. It impacts 300,000+ users! Troubleshooting Steps: • Usual Suspects (Duplex, Window size, Pkt loss, and LFN) • Use the information in the trace to eliminate some of the “usual suspects.” Not all inefficiencies come into play. Does Window come into play here? • Do I need to see the SYN/SYN+ACK to see what environment this is? What other options are there? • Use Time Reference markings liberally? • Case of “too much of a good thing”

6. Another Zebra Case! Users are calling into the helpdesk because the Citrix sessions are dying. Main Concept: • Applications traversing the Internet play by a different set of rules/standards. Packet loss is a way of life. • Do you **REALLY** know TCP? • Did you pick up on why the 500ms delay is significant? • What is Fast Retransmit and how is it different from “regular” Retransmission? • Learn the art of spotting something unusual. But first, you need to understand “what’s unusual.”

7. Wan Optimization After upgrading WAN optimization appliances, tellers started reporting intermittent printing issues. Transient problems like these are the toughest to resolve. What was the time to Resolution? Three days - thanks to packet captures. Main Concept: • Last change was OS upgrade on the wan optimization appliance, so start there. • Capturing in the right capture points is critical. Why? • Is it worth looking at TCP Session #2? • What should you compare? What can you compare? • Sake Blok’s session last year on SSL decryption was VERY helpful!

8. Wan Optimization (Con’t)

9. Wan Optimization (Con’t)