อันนี้เป็นหัวข้อสั้นๆและจะยังไม่ลงเนื้อหาทางเทคนิคนะครับ โดยบทความนี้จะต่อจากบทความที่แล้วในเรื่อง มาทลายกำแพงของ Wireshark เพื่อนำไปใช้งานกันเถอะ ในหัวข้อนี้เป็นการยกตัวอย่างการนำโปรแกรม Wireshark ไปใช้ในส่วนของการดูภาพรวมที่เกิดขึ้นในระบบ Network กันดีกว่าครับ
คำถามที่เกิดขึ้นเลยคำถามแรกคือจะเอามาดูภาพรวมทำไมในเมื่อโปรแกรม Wireshark สามารถดูข้อมูลได้ล฿กได้ถึงข้อมูลในระดับ Bit ของ Protocol อย่างเช่น DSCP หรือ Reset flag ใน TCP header!!! ทำไมไม่เอาความสามารถของโปรแกรมที่มีอยู่มาใช้ให้ถูกต้อง!!!
ลองมาดูการแสดงผลของ Wireshark ที่แสดง TCP reset bit กันก่อนว่ามีหน้าตาเป็นยังไงกันตามรูปนี้เลยครับ
คำถามนี้เราจะไม่ตอบเพราะเราจะถามกลับไปว่าถ้าไม่ดูสรุปในภาพรวมก่อนแล้วเราจะมีจุดเริ่มต้นให้เรานำไปใช้ในการหาข้อมูลที่อยู่ในส่วนที่ลึกลงไปได้อย่างไรเพราะตัวโปรแกรม Wireshark เองสามารถแสดงผลได้ถึงระดับ Bit แต่ว่าการที่เราจะไปเริ่มหาข้อมูลในระดับ Bit จากข้อมูลที่แสดงผลของแต่ละ Packet ในช่วงเวลา 15 นาทีซึ่งมีอยู่เป็นหลัก 1,000,000 บรรทัดแล้วพิจารณาความสัมพันธ์ต่างๆที่เกิดขึ้นและทำให้เกิดผลคือปัญหาที่เกิดขึ้นในช่วงเวลาหนึ่งๆคงจะไม่สามารถทำงานได้ทันตามเวลาอย่างแน่นอน!!!
ลองดูตัวอย่าง Packet ที่เคยเอามาเขียนบทความดูครับว่าเราใช้จำนวน Packet เป็นจำนวนเท่าไรในการเอาข้อมูลนั้นๆมาหาความสัมพันธ์และสาเหตุของปัญหาที่เกิดขึ้นกัน
ดังนั้นจะดีกว่าหรือไม่ที่เราสามารถที่จะเอาโปรแกรม Wireshark มาใช้ในการแสดงภาพรวมของ Packet ที่เรามีอยู่มาแสดงผลก่อนที่จะลงมือค้นหาสาเหตุที่อยู่ในระดับที่ลึกลงไปอีกทีหนึ่ง อย่าลืมว่า Packet ที่เรานำมาเปิดด้วยโปรแกรม Wireshark นั้นอาจจะไม่ใช่ Packet ที่มีปัญหาอยู่ด้วยก็ได้ ลองนึกย้อนกลับไปในส่วนของการทำงานจริงดูว่าปัญหาจะเกิดขึ้นได้ในช่วงเวลาได้ได้บ้าง ตำตอบคือไม่รู้!!! เพราะถ้าเรารู้แล้วเราก็จะสามารถหาทางแก้ไขได้อย่างแน่นอน แต่ในชีวิตจริงเราไม่สามารถรู้ได้เลยว่าปัญหาจะเกิดขึ้นได้ในช่วงไหน ดังนั้นการจับ Packet ก็อาจจะต้องทำทิ้งไว้เป็นเวลาหลายชั่วโมง หรืออาจจะเป็นวันเลยก็ตาม เพื่อให้ครอบคลุมในช่วงเวลาที่มีปัญหาเกิดขึ้น ซึ่งอาจจะเกิดขึ้นแค่เพียง 1 หรือ 2 นาทีในเวลา 24 ชั่วโมง (เราจะไม่จับ Packet ค้างไว้ทั้งวันเพราะเราจะไม่สามารถเปิดไฟล์ที่มีขนาดใหญ่เกินไปได้ ให้ลองนึกถึงการเปิด .txt ที่มีขนาด 1GB ดูครับ) ดังนั้นการไล่เปิดไฟล์และค้นหาเหตุการณ์ต่างๆจะเสียเวลามากไปถ้าใช้การพิจารณาในระดับที่ละเอียดมากเกินไปนั่นเอง (ยังไม่นับกรณีที่ปัญหาเกิดในช่วงเวลาที่คาบเกี่ยวกันในระหว่างที่เราแยกไฟล์เป็นชิ้นตามช่วงเวลาและต้องนำไฟล์มารวมกันเป็นก้อนใหม่เพื่อวิเคราะห์ปัญหาอีกต่างหาก ผมเคยต้องเอาไฟล์มารวมกันจนได้ขนาด 16GB และเอามาหาความผิดปกติ T^T)
ส่วนนี้จะเป็นตัวอย่างการใช้งานจริงในส่วนของการนำเอา Wireshark มาใช้ในการดูภาพรวมของปัญหากันครับ
ตัวอย่าง เบื้องต้นเราต้องการทราบว่าโมเด็มที่เราใช้งานอยู่มีอาการ Disconnect ในทุกวันเราก็นำโมเด็มนั้นมาทดสอบใน Lab และกำหนดค่า Timeout ให้เป็น 15 นาทีเพื่อดูปัญหาที่เกิดขึ้นในระยะเวลาที่จำกัด หลังจากการทดสอบและเก็บข้อมูลใน Lab ออกมาได้จะพบว่าปัญหาที่เกิดขึ้นเกิดจากการที่ Session ไม่ Reestablish ใหม่หลังจากหมดช่วงเวลา Timeout จาก Protocol LCP เมื่อได้ผลารุปมาแล้วก็นำไปหาวิธีการแก้ปัญหา โดยแบ่งวิธีการแก้ปัญหาเป็น 2 ส่วน ดังนี้
จากรูปตัวอย่างที่ผมเอามาทำบทความนี้เอามาจากการแก้ไขโดยใช้ Command บนอุปกรณ์ที่เชื่อมต่ออยู่ด้วยช่วยแก้ไขการทำงานในส่วนที่ 1 เมื่อลองใส่ Command ใหม่ลงไปแล้วก็ทดสอบใน Lab เหมือนเดิมและก็ไม่ลืมที่จะเก็บ Packet มาวิเคราะห์ปัญหาด้วยเหมือนเดิม จากรูปด้านล่างที่เห็นคือหลังจาก Session timeout แล้วอุปกรณ์สามารถกลับมาเชื่อมต่อได้อย่างปกติ
ซึ่งการนำ Wireshark มาช่วยในส่วนนี้จะพบว่า Command ที่เราใส่ลงไปนั้นสามารถแก้ปัญหาได้อย่างแท้จริงจาก Root cause โดยสามารถยืนยันได้จากผลที่เกิดขึ้นในกราฟที่แสดงให้ดูครับ และสามารถย้อนกลับไปดูในรายละเอียดในส่วนของ Packet ที่เกิดขึ้นในช่วงเวลานั้นๆได้อีกด้วย
ที่สำคัญเมื่อผลที่ทดสอบสามารถทำออกมาได้เป็นกราฟแล้ว ดังนั้นการนำผลที่ได้ไปนำเสนอต่อไปกับหัวหน้าหรือลูกค้าก็สามารถนำไปใช้ได้ทันที และสามารถนำไปสื่อสารได้อย่างตรงจุดเข้าใจได้ในทันที ดีกว่าการเปิด Wireshark และให้หัวหน้าดู Packet ที่เกิดขึ้นทีละบรรทัดแล้วก็ไม่เข้าใจสิ่งที่เราจะนำเสนออยู่ดีครับ
หวังว่าบทความนี้จะเป็นตัวอย่างการเอา Wireshark ไปใช้งานได้ดีขึ้นในส่วนนึงนะครับ
แล้วเจอกันในบทความหน้า (ถ้าพอมีเวลาและขยันเขียน) ขอบคุณที่เสียสละเวลาอันมีค่าเข้ามาอ่านด้วยครับ _/|\_
ความเห็นล่าสุด