คลังเก็บผู้เขียน: panya.w

การใช้ Wireshark สร้างกราฟเพื่อดูสรุปภาพรวมของเหตุการณ์

อันนี้เป็นหัวข้อสั้นๆและจะยังไม่ลงเนื้อหาทางเทคนิคนะครับ โดยบทความนี้จะต่อจากบทความที่แล้วในเรื่อง มาทลายกำแพงของ 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 ส่วน ดังนี้

  1. แก้ไขโดยใช้ Command บนอุปกรณ์ที่เชื่อมต่ออยู่ด้วยช่วยแก้ไขการทำงาน
  2. แก้ไขโดยการแก้ Firmware ของโมเด็มใหม่

จากรูปตัวอย่างที่ผมเอามาทำบทความนี้เอามาจากการแก้ไขโดยใช้ Command บนอุปกรณ์ที่เชื่อมต่ออยู่ด้วยช่วยแก้ไขการทำงานในส่วนที่ 1 เมื่อลองใส่ Command ใหม่ลงไปแล้วก็ทดสอบใน Lab เหมือนเดิมและก็ไม่ลืมที่จะเก็บ Packet มาวิเคราะห์ปัญหาด้วยเหมือนเดิม จากรูปด้านล่างที่เห็นคือหลังจาก Session timeout แล้วอุปกรณ์สามารถกลับมาเชื่อมต่อได้อย่างปกติ

ซึ่งการนำ Wireshark มาช่วยในส่วนนี้จะพบว่า Command ที่เราใส่ลงไปนั้นสามารถแก้ปัญหาได้อย่างแท้จริงจาก Root cause โดยสามารถยืนยันได้จากผลที่เกิดขึ้นในกราฟที่แสดงให้ดูครับ และสามารถย้อนกลับไปดูในรายละเอียดในส่วนของ Packet ที่เกิดขึ้นในช่วงเวลานั้นๆได้อีกด้วย

ที่สำคัญเมื่อผลที่ทดสอบสามารถทำออกมาได้เป็นกราฟแล้ว ดังนั้นการนำผลที่ได้ไปนำเสนอต่อไปกับหัวหน้าหรือลูกค้าก็สามารถนำไปใช้ได้ทันที และสามารถนำไปสื่อสารได้อย่างตรงจุดเข้าใจได้ในทันที ดีกว่าการเปิด Wireshark และให้หัวหน้าดู Packet ที่เกิดขึ้นทีละบรรทัดแล้วก็ไม่เข้าใจสิ่งที่เราจะนำเสนออยู่ดีครับ

หวังว่าบทความนี้จะเป็นตัวอย่างการเอา Wireshark ไปใช้งานได้ดีขึ้นในส่วนนึงนะครับ

 

แล้วเจอกันในบทความหน้า (ถ้าพอมีเวลาและขยันเขียน) ขอบคุณที่เสียสละเวลาอันมีค่าเข้ามาอ่านด้วยครับ _/|\_

มาทลายกำแพงของ Wireshark เพื่อนำไปใช้งานกันเถอะ

สวัสดีครับ

กลับมาอีกครั้งในรอบครึ่งปี หลังจากเริ่มเข้าที่เข้าทางกลับที่ทำงานใหม่ ตามที่แจ้งไว้เมื่อช่วงต้นเดือนวันนี้จะมาเขียนบทความเพื่อก้าวข้ามกำแพงของ Wireshark GUI กัน

ก่อนอื่นก็ต้องตั้งคำถามกับตัวเองกันก่อนว่าขอ้มูลที่เราเอามาใส้ให้กับ Wireshark นั้นเราสามารถหามาได้กันทุกคนแน่ๆ ตั้งแต่ Network admin, Server admin, Firewall admin ทุกๆคนน่าจะเคยเปิดโปรแกรม Wireshark เพื่อเอามาเปิดไฟล์ PCAP ขึ้นมาดูอย่างแน่นอน แต่คำถามคือหลายๆคนเปิดข้อมูลขึ้นมาแล้วเอามาทำอะไรต่อ? น่าจะมีอาการดังต่อไปนี้เกิดขึ้นไม่มากก็น้อยแน่นอน

  1. เปิดขึ้นมาเจอข้อมูลที่เป็น Packet หลายหมื่นหลายพันบรรทัดแล้วนั่งดูสักพัก แล้วก็ไม่รู้ว่าจะเริ่มยังไงแล้วก็ถอดใจปิดโปรแกรมไป
  2. เปิดขึ้นมาแล้วก็ลองหาสิ่งที่คิดว่าน่าจะเป็นสิ่งที่ต้องการอย่าง Protocol แล้วก็ใส่ลงไป ถ้าโชคดีใช้ได้ก็จะสามารถลดปริมาณของข้อมูลลงมาได้ แต่ก็ยังไม่รู้อยู่ดีกว่าปัญหามันอยู่ตรงไหน แล้วจะไปเริ่มหาสาเหตุยังไง
  3. ขั้นนี้เริ่มหาข้อมูลเพื่อ filter ข้อมูลที่ไม่ต้องการทิ้งออกไปได้ ทำให้สามารถเลือกข้อมูลที่ต้องการมาแสดงผลได้ดีขึ้นและตรงประเด็น
  4. ขั้นต่อมาก็เรียกว่าอึดขึ้นมาหน่อยคือหลังจากเริ่มตัดให้เหลือแต่ข้อมูลที่คิดว่าถูกต้องขึ้นมาได้แล้ว เริ่มต้นจากเวลาที่เกิดปัญหาขึ้นและลงมือไล่ไปทีละ Packet จนกว่าจะเจอสิ่งที่น่าสนใจใน Packet ที่ดูอยู่โดยใช้ filter ช่วย
  5. ต่อมาก็จะเป็นกลุ่มที่เริ่มมองหาเครื่องมือในโปรแกรมมาช่วยหาข้อมูลที่สนใจบ้างแล้ว เช่น Statistics อย่าง Endpoint, Conversations, Flow graph, TCP stream graph กลุ่มนี้ก็จะสามารถหาและเชื่อมโยงความสัมพันธ์ของ Packet และสามารถ Scope ปัญหาได้อย่างช่ำชองแล้ว
  6. กลุ่มที่เริ่มเข้าสู่การหาและวิเคราะห์สาเหตุจะเริ่มที่กลุ่มนี้ เนื่องจากงานที่ต้องใช้ Packet จะมีความซับซ้อนมากและยังจะต้องนำไปเสนอให้คนอื่นเข้าใจสิ่งที่เราจะต้องการสื่อออกไปด้วย ดังนั้นเครื่องมือที่ใช้ก็จะต้องเริ่มเป็นกราฟที่มีสีสัน และมีการฝึกใช้งาน command filter ที่ค่อนข้างแม่นยำแล้ว เพื่อให้ได้ผลตามที่ต้องการ และสามารถนำผลการวิเคราะห์ไปนำเสนอให้คนอื่นเข้าใจได้ด้วย ว่าเกิดอะไรขึ้นใน Packet ที่มีปัญหานั้นๆ

ทั้งหมดด้านบนที่กล่าวมาเกิดขึ้นกับตัวผมเองมาแล้วทั้งสิ้น จนถึงในเวลานี้เองก็ยังต้องเรียนรู้การใช้งานโปรแกรม Wireshark ในด้านต่างๆ เพื่อหาสาเหตุของปัญหาที่เจออยู่เรื่อยๆ เพราะงานที่เราเจอนั้นจะมีปัญหาหรือสิ่งใหม่ๆเข้ามาให้เราเรียนรู้อยู่เสมอ ดังนั้นเมื่อเคยเจอปัญหานี้มาก่อนทำให้เราเองรู้ว่าคนอื่นๆก็จะต้องเจอปัญหานี้เหมือนกัน และปัญหาการใช้งานโปรแกรม Wireshark นี้ก็เป็นกำแพงที่สูงมากทีเดียวสำหรับการเรียนรู้ด้วยตนเอง ดังนั้นก็เลยมีความคิดที่จะมาเขียนบทความชุดนี้ขึ้นมา อย่างไรก็ตามการที่ผมเองก็มีงานประจำที่ค่อนข้างวุ่นวายอยู่สักหน่อยดังนั้นบทความก็อาจจะไม่ได้มาแบบต่อเนื่องดังนั้นก็ขอให้อดใจรอกันสักหน่อยนะครับ

จากเหตุการณ์ต่างๆที่เกิดขึ้นทั้ง 6 ข้อที่เขียนมาก็พอจะสรุปลำดับการใช้งานโปรแกรม Wireshark ได้เป็นกลุ่มๆดังนี้

  1. การใช้งาน Filter เพื่อช่วยให้เราหาข้อมูลที่เราต้องการให้ง่ายขึ้น เช่น การหา sync, fin packet เพื่อเริ่มต้นการวิเคราะห์การทำงาน หรือจะเป็นการแยกเฉพาะโปรโตคอลที่เราสนใจออกมาจาก Packet ที่มีเป็นล้านบรรทัด เช่น RADIUS protocol เพื่อใช้ authentication
  2. การใช้งานเครื่องมือเพื่อแสดงสถิติหรือกราฟเพื่อแสดงพฤติกรรมของ Packet ในรูปแบบต่างๆ เช่น การหาค่า MAC address ที่ใช้สื่อสารกันทั้งหมดใน Packet ที่มี การหาหรือแสดงการเกิด TCP retransmission โดยใช้กราฟ
  3. การนำข้อมูลที่ได้มาทำการเปรียบเทียบปัญหาที่เกิดขึ้น หรือนำมาแสดงให้เห็นเป็นพฤติกรรมที่เกิดขึ้นในลักษณะของกราฟ เช่น แสดง LCP message interval ของ CPE ย่อห้อต่างๆเปรียบเทียบกันเพื่อหาอุปกรณ์ที่ดีที่สุดในการใช้งาน หรือพฤติกรรมที่ผิดปกติในระดับ Protocol เพื่อหาสาเหตุและแก้ไขจุดที่ Software ทำงานผิดพลาด

ทั้ง 3 หัวข้อนี้คือหัวข้อหลักในบทความที่จะเขียนต่อๆไป รูปแบบการยกตัวอย่างเพื่อช่วยให้หลายๆคนที่ติดตามเพจนี้สามารถทลายกำแพงของ Wireshark ลงและนำโปรแกรมนี้ไปใช้งานได้ตามที่หวังกันครับ

แสดงค่า Round Trip Time ของ Network ในรูปแบบของกราฟเพื่อแสดงเวลาที่ Packet ใช้เวลาใน Network

วันนี้เป็นเรื่องการแสดงค่า Round Trip Time (RTT) หรือค่าเวลาที่ Packet ใช้เวลาในการเดินทางใน Network จากต้นทางไปยังปลายทางและกลับมาที่เครื่องต้นทางอีกครั้งหนึ่ง “ซึ่งค่าที่ได้นี้จะเป็นค่าอ้างอิงของเวลาที่ Packet ใช้เวลาในการเดินทางระหว่างอุปกรณ์ต้นทางและอุปกรณ์ปลายทาง คู่หนึ่งเท่านั้น” ไม่ใช่ค่าเวลาที่สามารถใช้อ้างอิงเวลาที่ใช้ในระบบ Network ของอุปกรณ์ทุกตัวได้

ตัวอย่างการหาค่า RTT อาจจะเป็นการใช้งานคำสั่ง Ping ไปที่ปลายทางต่างๆ ดังนี้

จากรูปด้านบนทั้งสองรูปเราก็จะเห็นว่าค่า “time” ที่อยู่ในกรอบสีแดงทั้งสองค่ามีค่าไม่เท่ากันซึ่งค่าที่เปลี่ยนไปนี้จะมีค่าไม่ท่ากันในทุกๆปลายทาง ซึ่งค่านี้จะเปลี่ยนไปตามอุปกรณ์ต้นทางและอุปกรณ์ปลายทางคู่หนึ่งเท่านั้น ดังที่อธิบายไปแล้วก่อนหน้านี้

สำหรับ Diagram ที่ใช้อธิบายการทำงานของ RTT จะมีรูปแบบดังรูปด้านล่างนี้

หรือถ้าจะมองในรูปแบบของคู่การสื่อสารในรูปแบบการ Request data แบบ peer-to-peer ก็จะได้รูปแบบเป็นตาม Diagram ตามรูปด้านล่างนี้

คราวนี้กลับมาที่หัวข้อของเรากันดีกว่า คราวนี้เราจะนำค่า RTT พวกนี้มาแสดงให้เป็นกราฟเพื่อนำกราฟที่ได้มาใช้ในการดูค่า RTT ของแต่ละ peer ได้อย่างไรบ้าง

ก่อนอื่นก็ให้เราเปิด Packet ที่เรามีอยู่ขึ้นมาด้วยโปรแกรม Wireshark ก่อนจากนั้นก็ให้ทำการเลือกเพ็คเก็ตที่เราต้องการหาค่า RTT จากในรูปตัวอย่างผมจะเลือก Packet ที่มี Source IP address = 172.16.4.115 และมี Destination IP address = 192.168.1.2 ซึ่งการทำแบบนี้ก็คือการที่เราเลือกอุปกรณ์ต้นทางและปลายทางนั่นเอง

ต่อมาให้ไปที่เมนู Statistics -> TCP StreamGraph -> Round Trip Time Graph ตามรูปด้านล่างนี้

จากนั้นก็รอสักพักนึงเพื่อให้โปรแกรม Wireshark ทำการคำนวนค่า RTT ของอุปกรณ์ที่มีค่า IP address = 172.16.4.115 ไปที่อุปกรณ์ปลายทางที่มีค่า IP address = 192.168.1.2 ตามกราฟด้านล่างนี้

กรณีที่เราต้องการแสดงค่า RTT ของคู่การสื่อสารอื่นๆก็สามารถทำได้โดยการเลือก Packet ใหม่โดยอาจจะเปลี่ยน Source IP address หรือ Destination IP address ไปตามที่เราต้องการ จากรูปตัวอย่างด้านล่างผมจะเปลี่ยน Destination IP address = 192.168.1.3

หลังจากที่ได้กราฟที่มีค่า RTT แล้วต่อมาเราจะสามารถสรุปอะไรได้บ้าง ผมขอยกตัวอย่างการสรุปข้อมูลที่ได้จากกราฟดังนี้ครับ

  • ค่า RTT ของ Source IP address = 172.16.4.115 ไปยัง Destination IP address = 192.168.1.2 มีค่าเฉลี่ยประมาณ >0.001 วินาที โดยพิจารณาจากความหนาแน่นของ Packet ที่มีค่าเกือบเป็นเส้นตรงที่ค่านี้เกือบตลอดเวลา
  • ค่า RTT ของ Source IP address = 172.16.4.115 ไปยัง Destination IP address = 192.168.1.3 มีค่าเฉลี่ยประมาณ 0.0003 – 0.004 วินาที โดยพิจารณาจากความหนาแน่นของ Packet
  • จากกราฟทั้งสองจะเห็นว่า Source IP address = 172.16.4.115 มีการสื่อสารไปที่ Destination IP address = 192.168.1.2 มากกว่าเครื่องอื่นและมีค่า RTT ที่ค่อนข้างคงที่ซึ่งหมายความว่าการสื่อสารนั้นมีประสิทธิภาพที่ดีจากกราฟที่เห็นคือ Packet มีความต่อเนื่องกันมากจนกลายเป็นเส้นต่อเนื่อง
  • จากกราฟที่สองถึงแม้ว่าค่า RTT จะมีค่าไม่คงที่เมื่อเทียบกับค่า RTT ของกราฟที่หนึ่งแต่ค่า RTT โดยเฉลี่ยยังมีค่าที่ใกล้เคียงกับค่าที่ได้จากกราฟที่หนึ่ง
  • ในมุมมองของการสื่อสารระหว่าง Network 172.16.4.0/24 ไปที่ Network 192.168.1.0/24 จะสามารถสรุปได้ว่าค่า RTT ที่ได้จากการสื่อสารระหว่าง Network มีประสิทธิภาพไม่มีปัญหาในเรื่องการ Delay เกิดขึ้นจน User รู้สึกได้

IP SLA graph บอกอะไรได้บ้าง

หนึ่งภาพสามารถแทนความหมายมากมาย ภาพที่เกิดจากการ monitor อุปกรณ์ network ก็ทำได้ในแนวเดียวกัน ^^

ภาพที่อยู่ด้านล่างเป็น graph ที่เกิดจากการ “ping” ไปที่ปลายทาง “แค่นั้น” แต่ความหมายที่แสดงอยู่มีค่ามากกว่านั้น ยกตัวอย่างที่เห็นจากภาพไม่ต้องคิดเลยก็มีประมาณนี้
1. ค่าเฉลี่ยของการตอบสนอง ping ไปที่ปลายทางคือ 30 ms.
2. มีบางช่วงที่ ping ไปที่ปลายทางไม่ได้
3. link ที่ใช้ไม่ค่อยจะเสถียรเท่าไร แต่ยอมรับได้
4. ต้องไปมีใครสักคนเปลี่ยนอะไรสักอย่างในช่วง week 20 – week 30

แล้วกราฟนี้มาจากไหน??
ตามหัวข้อ IP SLA เลยกราฟนี้มากจากการใช้ IP SLA command บน Catalyst 3750X ทำการส่งคำสั่ง ping ไปที่ปลายทางที่ต่างประเทศผ่าน internet ส่วน command ก็ประมาณนี้

ip sla X
 icmp-echo Y.Y.Y.Y
 threshold 1000
 timeout 1000
 frequency 10
ip sla schedule X life forever start-time now

เท่านี้ L3 ของเราก็จะ ping ไปที่ IP Y.Y.Y.Y แล้วก็เอามาพล็อตกราฟก็จบ แต่ประโยชน์ของมันไม่ได้มีแค่นั้นถ้าเรารู้เบื้องหลังและที่มาก็จะได้ข้อมูลเพื่อเอามาใช้ประโยชน์ได้อีกประมาณนี้

1. เนื่องจากการต่อใช้งาน internet แบบ BGP multihome ทำให้รู้ว่า Best path ไปที่ปลายทาง Y.Y.Y.Y ของ ISP1 แย่กว่า ISP2 จากกราฟในช่วงที่ใช้ ISP1 ทำงานเป็น default route ในหมายเลข 1 และ 4 มี respond time ที่เกิดจากการ ping สูงกว่าเมื่อช่วงที่ ISP2 ทำงานแทนในหมายเลข 3
2. ในช่วงหมายเลข 2 อาจจะมีการ cutoff ระบบแล้วเกิดปัญหากับ ISP1 ทำให้ ISP1 ไม่สามารถทำงานได้แต่ BGP ยังคงทำงานเมื่อ on ระบบขึ้นมาหลังจากทำงานเสร็จแล้ว ISP2 สามารถใช้งานได้ทำให้อุปกรณ์ใน site สามารถใช้งานได้เป็นปกติ
3. ในช่วงที่ ISP2 ทำงานพบว่า respond time ไปที่ IP Y.Y.Y.Y ต่ำกว่าตอนที่ ISP1 ทำงานแสดงว่า ISP2 มี Best path ไปที่ IP Y.Y.Y.Y ดีกว่า ISP1 จุดนี้สามารถนำไปทำ Optimize route ต่อได้อีก
4. เมื่ออุปกรณ์ของ ISP1 กลัมาทำงานได้เป็นปกติ Respond time ของ IP Y.Y.Y.Y กลับมาอยู่ที่ค่าเฉลี่ยประมาณ 70 ms เท่าเดิมแสดงว่าสำหรับ IP ปลายทางนี้ ISP2 มี best path ดีกว่า ISP1 แน่นอน
5. ถ้าลองตรวจสอบย้อนกลับไปที่ช่วงเวลา week ที่ 20 จะพบว่ามีการเปลี่ยนแปลงระบบทำให้สามารถ focus ความผิดพลาดที่เกิดขึ้นได้ว่าพอจะมาจากสาเหตุอะไรกันแน่ได้แม่นยำขึ้น
6. อันนี้ไม่ได้ใส่รูป graph ของ IP ปลายทางตัวอื่นแต่จะพบว่าถึงแม้ ISP2 จะทำงานแต่ Respond time ของ IP ปลายทางอื่นๆยังเท่าเดิมแสดงว่าไปทำการ optimize route แค่ชุดเดียวก็พอ

จะเห็นได้ว่าแค่การ ping ก็สามารถบอกข้อมูลได้เยอะแล้วดังนั้นใครที่ยังไม่ได้ทำระบบ monitor ก็ไปทำเพิ่มซะหน่อยดีกว่าปล่อยให้ระบบ network เป็น black box เวลามีปัญหาก็แก้ไขอะไรไม่ได้ จะเริ่มตรงไหนก็ไม่ถูก เมื่อตอบปัญหาไม่ได้ก็ต้องตกเป็นจำเลยของชาวบ้านเขาเรื่อยไป 😛

ปล. คัดลอกมาเป็นบทความบน Blog จาก Facebook note ของผมเองที่เขียนไว้เมื่อปี 2014 จาก ที่นี่ ครับ

Pro-active monitor เพื่อการตรวจสอบระบบ Network แบบ realtime

ผมคิดว่าเพื่อนๆที่ทำงานตำแหน่ง Network admin หรือ System admin ในบริษัทหลายท่านอาจจะมีความรู้สึกว่า “User ของท่านหลายๆคนจะรู้ว่าจะรบบที่ทำงานอยู่นั้นมีปัญหาได้เร็วกว่าคนที่ทำงานด้าน Network หรือ System ที่ดูแลระบบด้านนั้นๆอยู่เสมอ” ไม่ว่าจะเป็นเรื่องการใช้งานระบบ Database หรือการใช้งาน Internet จนทำให้เวลาที่ระบบมีปัญหาเรามาักจะใช้ “User เป็น Alert system ได้ดีกว่า” การเปิดหน้าจอโปรแกรม System monitor เพื่อดูสถานะของระบบไว้ซะอีก 🙂

ทำไม User จึงสามารถรับรู้ว่าระบบนั้นๆมีปัญหาได้เร็วกว่าเรา? ผู้ดูแลระบบหลายคนก็อาจจะคิดเช่นนั้น รวมทั้งผมเองในช่วงแรกๆ 🙂 แต่เมื่อมองถึงการใช้งานของ User ในด้านที่แตกต่างๆจากผู้ดูแลระบบก็จะพบว่าการที่ User นั้นรับรู้ปัญหาที่เกิดขึ้นได้เร็วกว่าเราก็คือ “พฤติกรรมการใช้งาน” ที่มีมากกว่าเรานั่นเอง เช่น ฝ่ายบัญชีมักจะมีการเรียกข้อมูลหรือเพิ่มข้อมูลลงไปที่ Database บ่อยๆ หรือกำลังดู Youtube อยู่แล้วภาพกระตุก 😛 ในขณที่เราอาจจะพิมพ์ Word อยู่ก็เป็นด้ายยยยย!!! จากพฤติกรรมการใช้งานที่เกี่ยวข้องกับระบบ Network นี้เองทำให้ User รับรู้ได้ถึงการเปลี่ยนแปลงบางอย่างที่เปลี่ยนแปลงไปจากเดิม ความแตกต่างที่ User สามารถรับรู้ได้นั้นจึงเป็นที่มาของการแจ้งความผิดปกติเข้ามาที่ผู้ดูแลระบบอย่างเราๆนั่นเอง

เมื่อเข้าใจถึงพฤติกรรมที่เกิดขึ้นดังนั้นผู้ผลิตอุปกรณ์หลายรายจึงได้ทำการพัฒนา Feature บนอุปกรณ์ขึ้นมาเพื่อให้ผู้ดูแลระบบมาไปใช้งานเพื่อนำค่าที่ได้มาเปรียบเทียบว่าทีอะไรเกิดขึ้นในระบบ Network บ้าง เช่น

  • Cisco – IP SLA
  • Juniper – RPM
  • HP – NQA
  • Huawei – NQA
  • Nokia (Alcatel-Lucent) – SAA

ซึ่ง Feature ที่ได้กล่าวถึงไว้ที่ด้านบนจะทำหน้าที่เป็นตัว “สร้าง Traffic” การใช้งานระบบ Network แทน User นั่งเอง โดยเรามาสามารถกำหนดให้อุปกรณ์ทำการตรวจสอบ(หรือใช้งานระบบ) Network เป็นช่างเวลา หรือตรวจสอบการใช้งานตลอดเวลาก็ได้ในกรณีที่เราต้องการนำมาใช้งานเป็นระบบ Real-time monitor

ประโยชน์ของการนำ Feature เช่น IP SLA มาใช้งานเป็นระบบ Real-time monitor คือ Network หรือ System admin จะได้ทราบถึงพฤติกรรมบนระบบที่เกิดขึ้นและเปลี่ยนแปลงไปในช่วงเวลาต่างๆ ซึ่งการใช้งานระบบ Network monitor ทั่วไปที่ให้แต่ผลการใช้งานแค่เรื่อง Traffic (Bandwidth) ที่เกิดขึ้นในระบบทั่วๆไปไม่สามารถให้คำตอบได้ เช่น

1.การตอบสนองการ Query ของ DNS server ว่ามีการตอบสนองการ Query ได้เร็วหรือช้าเป็นเวลาเท่าใด

2.การตอบสนองของ WAN ที่เชื่อมต่อระหว่างสาขานั้นมีค่า Round Trip Time(RTT) ใน WAN เส้นนั้นๆเป็นเวลาเท่าใด

3. การตอบสนองของ Service port บน Server ที่เปิดใช้งานบน Server เครื่องหนึ่งนั้นมีค่าเป็นเท่าใด

4. ค่าเวลาตอบสนองในการทดสอบการ Download ไฟล์จาก FTP server มีค่าเป็นเท่าใด

5. การใช้งาน Web site หนึ่งมีค่าตอบสนองของ TCP/DNS/HTTP เพื่อทำให้โหลดข้อมูลหน้านั้นๆขึ้นมาได้มีค่าเป็นเท่าไร

จากตัวอย่างที่กล่าวมาด้านบนทั้ง 5 แบบเป็นข้อมูลที่ผู้ดูและระบบส่วนใหญ่ต้องการทราบเพื่อนำไปตรวจสอบความผิดปกติหรือทำให้ทราบถึงพฤติกรรมการใช้งานเชิงลึกในระบบ Network ได้มากขึ้นเพื่อให้สามารถนำไปปรับปรุงหรือตรวจสอบการใช้งานที่ผิดปกติได้นั่นเอง

ผมขอยกตัวอย่างสำหรับการนำใช้งานข้อมูลไปใช้งานในบางกรณีดังนี้

ระบบ Internet มีปัญหาในช่วงเวลา 9.30น. ทำให้ User ใช้งาน Internet ไม่ได้ ต่อมา Internet กลับมาใช้งานได้ในช่วงเวลา 9.35น. ในช่วงเวลาที่เหลื่อมกันนั้นเวลา 9.34น. Network admin ได้โทรไปที่ ISP ให้ทำการตรวจสอบ Internet ต้องรอสายจนเวลา 9.36น.จึงจะได้คุยกับ Engineer ของ ISP และ Engineer ได้ขอผล Ping และ Traceroute ไปเพื่อนำไปตรวจสอบ Network admin จึงได้ส่งผลไปให้แต่เป็นผลการ Ping และ Traceroute ที่เวลา 9.37น.

กรณีที่ 1 ไม่มี Proactive monitor: จากช่วงเวลาด้านบน เมื่อส่งผล Ping/Traceroute ไปให้ Engineer ของ ISP ตรวจสอบก็จะพบว่าไม่มีความผิดปกติเกิดขึ้นในการเชื่อมต่อ Internet และเมื่อใช้โปรแกรม Monitor ทั่วไปดูจะพบว่ามี Bandwidth ที่ Interface จากมี Traffic เกิดขึ้นที่ Interface ที่เชื่อมต่อกับ Router ของ ISP ซึ่งอาจจะมีข้อมูลหากันตามปกติ เช่น Routing protocol หรือ L2 protocol อื่นๆ

กรณีที่ 2 มี Proactive monitor: เราจะมีผลการเชื่อต่อของ WAN-to-WAN, การตอบสนองของ Web site ปลายทาง หรือเวลาในการตอบสนองของ DNS server แล้วส่งเป็นกราฟไปให้ ISP ดูซึ่งจำทำให้เกิดความชัดเจนมากกว่าเพราะการทำ Real-time monitor จะต้องมีการเก็บข้อมูลไว้เป็น History ในระดับชั่วโมง วัน เดือน และปี ดังนั้นการที่เราเห็นความผิดปกติที่เกิดขึ้นจะทำให้เรามองเห็นปัญหาได้ชัดเจนและรวดเร็วขึ้นได้เป็นอย่างมาก

จากการแนะนำ Feature pro-active monitor และตัวอย่างการนำไปใช้งานในบทความนี้หวังว่าจะทำให้เพื่อนๆหลานคนได้ Idea ในการทำ Pro-active monitor ไว้ใช้งานในบริษัทของตัวเองกันมากขึ้น เพื่อใช้ในการตรวจสอบและใช้ในการประกอบการวิเคราะห์ปัญหาที่เกิดขึ้นกันได้นะครับ 🙂

ลองหาข้อมูลเพิ่มเติมเกี่ยวกับ Cisco IP SLA เพื่อใช้งานต่อได้ที่

http://www.bloggang.com/mainblog.php?id=likecisco&month=09-07-2015&group=3&gblog=50

http://www.cisco.com/c/en/us/td/docs/ios/12_4/ip_sla/configuration/guide/hsla_c/hsoverv.html

ปล. รูปตัวอย่างในบทความมากจาก Cacti โดยใช้ Template ที่ Modify ใหม่เองครับ เพื่อนๆที่สนใจสามารถหา Software อื่นๆมาใช้งานได้เองเช่นเดียวกันนะครับ 🙂

หมายเหตู: การทำ Pro-active monitor ไม่สามารถตอบคำถามทุกอย่างที่เกิดขึ้นได้ จะต้องมีการทำงานที่เกี่ยวข้องกับ Resource monitor อื่นๆด้วยเพื่อทำให้การวิเคราห์ปัญหาทำได้สะดวกและชัดเจนมากขึ้นด้วย การใช้เครื่องที่ดีตัวหนึ่ง อาจจะไม่ได้เหมาะสมกับทุกปัญหาที่เกิดขึ้นครับ

 

[Training] UnetLab for Network enginner

Network engineer หลายๆท่านน่าจะเคยประสบปัญหาต่างๆดังนี้มาก่อน

  • ต้องการฝึก Configure อุปกรณ์ให้เชี่ยวชาญเพื่อนำไปสอบ Certification ในระดับสูง เช่น Cisco CCNP, CCNP แต่ในบริษัทไม่มีอุปกรณ์ให้ใช้ฝึกฝน
  • ต้องออกไปติดตั้งอุปกรณ์ให้ลูกค้าแค่ยังไม่เคยใช้งานอุปกรณ์นั้นๆมาก่อน
  • ต้องออกแบบระบบให้กับลูกค้าแต่ไม่แน่ใจว่าสิ่งที่คิดไว้จะสามารถทำงานได้ตาม Concept ที่คิดไว้หรือเปล่า
  • ต้องการออกแบบ Solution เพื่อนำไปเสนอให้กับลูกค้า
  • ต้องการจำลองระบบเพื่อทำ POC ให้กับลูกค้าแต่อุปกรณ์ที่มีไม่เพียงพอ
  • ต้องการจำลองระบบของลูกค้าเพื่อนำมาทดสอบการก่อน Implement เพื่อให้แน่ใจว่า Design ที่ออกแบบไว้สามารถทำงานเข้ากับระบบเดิมได้ก่อนติดตั้ง

ปัญหาหาที่เกิดขึ้นนี้อาจจะแก้ได้หลาก เช่น การเช่า Rack ต่างจากประเทศเพื่อใช้ทดลอง Lab หรือซื้ออุปกรณ์จริงมาลองใช้งาน แต่สิ่งที่จะกระทบต่อการแก้ปัญหาเหล่านี้คือ “การลงทุน” ซึ่งอาจจะไม่คุ้มกับการลงทุนก็ได้ เนื่องจากอุปกรณ์ที่ต้องการมีราคาสูงเกินไป หรือบริษัทไม่มีนโยบายสนับสนุนตัวอย่างคือ บริษัทขายอุปกรณ์ยี่ห้อ “J” แต่งานติดตั้งจะต้องนำไปใช้งานกับอุกรณ์ “C”

ทางออกสำหรับ Network engineer หลายๆท่านก็จะหันไปใช้งาน Emulator อย่าง GNS3 นำมาจำลองระบบเพื่อจำลองให้มีการทำงานใกล้เคียงกับระบบที่เราจะต้องไปทำงานด้วย การใช้งานก็สะดวกสบายเพราะมี GNS3 appliance ที่สามารถโหลดมาใช้งานได้อย่างง่ายดาย ซึ่งก็จะสามารถนำมาใช้แก้ปัญหาในการทำงานได้ส่วนหนึ่ง

แต่จะดีกว่าไหมถ้ามี Emulator ตัวอื่นที่สามารถทำงานได้ในฟังก์ชั่นที่ทำงานได้เหมือนกันและดีกว่า นั่นคือการใช้งาน UnetLab แทนการใช้งาน GNS3 เพียงอย่างเดียว โดยการใช้งาน UnetLab จะมีข้อดีที่เหนือกว่า GNS3 ในบางส่วนดังนี้

เมื่อเทียบกับ GNS3

  • การใช้งาน UnetLab จะใช้ VM เพียงตัวเดียวไม่ต้องทำการลงโปรแกรมเพิ่มเติมเหมือน GNS3 ซึ่งต้องจะต้องมีทั้ง Local server และ Remote server (VirtualBox หรือ VMware) ในกรณีที่ต้องการใช้งานอุปกรณ์ใหม่ๆ เช่น F5 Big IP
  • GNS3 ยังไม่สามารถควบคุมการทำงานของ VirtualBox และ VMware ได้ 100% จึงยังพบปัญหาในการใช้งาน เช่น การปิด VM โดยใช้ GNS3 จะทำให้ VirtualBox VM Crash ได้

จุดเด่นของ UnetLab

  • ใช้ VM guest เพียงตัวเดียวในการใช้งานไม่ต้องมี Local หรือ Remote server
  • ไม่ต้องติดตั้งโปรแกรมเพิ่มเติมเนื่องจาก UnetLab ใช้งานบน Web browser ได้ทันที
  • ทำการควบคุมอุปกรณ์ที่ใช้ในการกดลองได้อย่างสมบูรณ์ในตัวเอง
  • รองรับอุปกรณ์ได้หลากหลาย สามารถเช็ครายการของอุปกรณ์ที่รองรับได้ ที่นี่
  • สามารถ Update version ได้ทันทีไม่ต้อง Uninstall โปรแกรม

ทำไมต้องมาเรียน UnetLab กับเรา

  • เราคอยแจ้ง ร่วมหาและทดสอบ Bug กับทีมงานของ UnetLab อยู่เสมอ
  • เราอ่าน Script โฟลวการทำงานของ UnetLab และทดสอบการใช้งาน Image ของอุปกรณ์ด้วยเราเอง
  • เราเข้าใจการทำงานของ Backend ที่ UnetLab นำมาใช้งานทั้ง 3 แบบคือ Dynamips IOL และ QEMU
  • เข้าใจโครงสร้างของ UnetLab ที่อยู่ภายใต้ OS Ubuntu โดยจะแสดงให้เห็นถึงโครงสร้างและการเชื่อมต่อของอุปกรณ์ใน Lab ได้ที่ระดับ OS เพื่อให้สามารถเข้าใจการทำงานและแก้ปัญหาได้
  • สามารถสาธิตและแนะนำการสร้าง Image ที่ UnetLab ไม่รองรับ ให้นำมาใช้งานเองได้ เช่น PFsense, KALI linux หรือ อุปกรณ์อื่นๆที่ผู้เรียนสนใจและ Backend รองรับการทำงาน
  • เรานำ UnetLab มาใช้งานจริงทั้งในการเตรียมสอบ Certified และ Test solution ของลูกค้า
  • เราจะให้ลองใช้งาน UnetLab แทบทุก Feature ที่น่าสนใจ เช่น
    • ใช้งาน Multi user login (เหมาะกับการสร้าง Lab เพื่อการ Training หรือใช้สร้าง LAB ใน Training center)
    • นำ Icon ที่สร้างเองมาใช้งานใน UnetLab
    • Clickable diagram เป็นการนำ Diagram ที่สร้างโดย Visio หรือไฟล์รูป/Diagram มาใช้งานใน UnetLab โดยจะมีลักษณะเหมือนกับที่มีการใช้งานในศูนย์ Training

จากตัวอย่างแนะนำมาข้างต้นผู้ที่สนใจ Workshop สามารถสมัครเรียน Workshop ได้ครับ

ค่าใช้จ่ายในการเรียน 2,000 บาท (1 วัน)

สิ่งที่จะได้รับในการเรียน: UnetLab VM พร้อมใช้งานที่มี Free image นำกลับไปใช้งานต่อได้ทันที

กรณีที่มีความสนใจ Workshop นี้สามารถติดต่อสอบถามได้ที่ Email: info@virtualnetsystems.com

[Training] Wireshark for network troubleshooting

สำหรับคนที่ทำงานในสาย Network ไม่ว่าจะอยู่ในระดับใดก็ตามแต่ ตั้งแต่ในหอพัก โรงเรียน บริษัทเล็กๆ หรือบริษัทข้ามชาติขนาดใหญ่ สิ่งที่จะต้องเคยเจอและได้ยินน่าจะเป็นประโยคสุดคลาสสิคนี้ “Network มีปัญหาอะไร ทำไมใช้งานไม่ได้” หรือ “ทำไม Internet ช้าจังสงสัย Network มีปัญหาแน่ๆเลย” ทั้งสองประโยคนี้อาจจะเป็นจริงหรือไม่จริงก็ได้ในช่วงเวลาหนึ่งๆ

แต่จะดีกว่าไหมที่เราสามารถหาสาเหตุที่แท้จริงและนำไปปรับปรุงหรือแก้ไขระบบ Network หรือพฤติกรรมการใช้งานที่มีผลกระทบต่อภาพรวมของการใช้งานระบบ Network ได้อย่างชัดเจน ตรงจุด และ “สามารถสื่อสารให้คนที่ไม่เข้าใจระบบ Network ให้เข้าใจได้ง่ายขึ้นด้วยการใช้กราฟ” เช่น หัวหน้า, ผู้บริหาร หรืออธิบายปัญหาที่เกิดขึ้นกับโปรแกรมที่มีการเขียนใช้งานเองในบริษัทให้โปรแกรมเมอร์เข้าใจได้ หรือจะเป็นการปรับปรุงค่า Configuration ในระบบ Infrastructure ภายในบริษัทเองให้มีความเหมาะสมกับการใช้งาน เพื่อทำให้การใช้งานระบบ Network มีประสิทธิภาพที่ดีที่สุด โดยไม่มีการทิ้งคำถามมาที่คนทำระบบ Network เพียงคนเดียว

Wireshark for network troubleshooting เป็นหัวข้อ Workshop ที่คิดขึ้นเพื่อให้ผู้เรียนที่เป็นผู้ดูและระบบ Network ให้มีความเข้าใจในการทำงานของพื้นฐานการทำงานของระบบ Network โดยใช้รูปแบบการทำงานของ Protocol TCP มาอธิบายให้เห็นว่าในระหว่างการทำงานในระบบ Network ถ้ามีปัญหาเกิดขึ้นกับส่วนใดในการสื่อสารแบบ TCP จะมีปัญหาอย่างไรเกิดขึ้น และจะนำไปสู่การวิเคราะห์ปัญหาที่เกิดขึ้นในลักษณะต่างๆต่อไปได้อย่างเป็นรูปธรรม

Workshop จะเน้นให้ลงมือทำโดยเนื้อหาจะถูกแบ่งออกเป็น 3 ส่วนที่สำคัญคือ

ส่วนที่ 1

เริ่มต้นด้วยการปูพื้นให้ทุกคนเห็นภาพการทำงานของ Reference model แบบต่างๆและรูปแบบการนำไปใช้งานเมื่อใช้งานร่วมกับ Wireshark สำหรับ Lab จะเป็นการทดลองที่เน้นการเก็บข้อมูลเพื่อนำมาใช้งานกับ Wireshark ในรูปแบบต่างๆ

  • เริ่มต้นด้วยการพิจารณา OSI, TCP model และเปรียบเทียบกับการแสดงผลของ Wireshark
  • ตัวอย่างการทำงานของ Protocol TCP เพื่อใช้ในการอ้างอิงเมื่อเกิดปัญหาค่างๆ
  • การทำงานของ Protocol ARP
  • การเก็บข้อมูลในลักษณะต่างๆเพื่อนำมาเป็นข้อมูล Input ให้กับ Wireshark เช่น TCPdump, Remote capture

ส่วนที่ 2

เริ่มลงมือใช้งาน Wireshark เพื่อให้เห็นการทำงานของ Protocol ต่างๆแบบชัดเจน เช่น การเปิดการสื่อสารด้วย Packet SYN และวิเคราะห์การทำงานของระบบ Network โดยรวมได้แบบง่ายๆและรวดเร็ว ในส่วนนี้ทุกคนจะบอกได้อย่างเต็มปากว่า “ระบบ Network ไม่มีปัญหา” ระบบทำงานได้เร็วปกติ” โดยมีหลักฐานที่สามารถแสดงให้เห็นได้อย่างชัดเจน

  • เมนูใช้งานของโปรแกรม Wireshark, Coloring rules
  • รูปแบบ Input แบบต่างๆเพื่อใช้เป็น Filter string ของ Wireshark เพื่อใช้ในการกรองข้อมูลที่ต้องการนำมาวิเคราะห์ด้วย Wireshark ต่อไป
  • การใช้งาน Follow TCP stream
  • การใช้งาน TCP stream graph เพื่อพิจารณาและวิเคราะห์เหตุการณ์ต่างๆที่เกิดขึ้นใน Network

ส่วนที่ 3

ส่วนสุดท้ายของ Workshop เน้นการใช้งานเพื่อนำไปวิเคราะห์ปัญหาที่เกิดขึ้นได้อย่างรวดเร็วโดยสามารถหา Packet ที่คาดว่าจะเป็นต้นเหตุของปัญหาได้อย่างรวดเร็วและแม่นยำ “การหาจุดเริ่มต้นในการวิเคราะห์ปัญหาอย่าง Network ช้า” โดยการพิจารณา Packet ที่สนใจได้อย่างรวดเร็ว และปิดท้ายด้วยการวิเคราะห์การทำงาน Application ที่มีปัญหาด้วยคนเอง เพื่อสร้างความมั่นใจในการทำงานต่อไป

  • การสร้าง Profile และการเพิ่ม Column เพื่อให้เหมาะสมกับการวิเคราะห์ปัญหาในแบบต่างๆ
  • การ Export HTTP object
  • การใช้งาน IO graph
  • การใช้งาน Expert info
  • วิเคราะห์การทำงานที่ผิดปกติของ Application

Workshop ทั้ง 3 ส่วนจะใช้เวลาทั้งหมด 2 วันเพื่อให้ผู้เรียนได้ทำความเข้าใจการนำโปรแกรม Wireshark ไปใช้งานได้อย่างมีประสิทธิภาพ เนื้อหาทั้งหมดได้ผ่านกระบวนการคิดทดสอบและลงมือทำผ่านโปรแกรมอย่าง GNS3 และ VirtualBox หรือ EVE-NG จากผู้สอนก่อนที่จะลงมือทำเอกสารทุกขั้นตอน เพื่อให้แน่ใจว่าผู้เรียนจะสามารถกลับไปทำการทดลองซ้ำต่อที่บ้านหรือบริษัทต่อไปได้ ทำให้มีความสะดวกในการทบทวนเนื้อหาที่ได้เรียนผ่านไป โดยสามารถทำการทดลองซ้ำตามเอกสารเพื่อให้เกิดความชำนาญจนสามารถนำไปประยุกต์ใช้งานได้อย่างสะดวกตามความต้องการต่อไป

สำหรับเนื้อหาการใช้งานโปรแกรม Wireshark ที่ผู้สอนได้มีการเผยแพร่เป็นวิทยาทานแก่ผู้สนใจได้ทำการอ่านและศึกษาได้ฟรีมีตามหัวข้อดังต่อไปนี้

  1. ใช้ Wireshark เพื่อวิเคราะห์ความผิดปกติในการทำงานของ Application
  2. การนำค่า Delay ที่เกิดขึ้นในระบบ Network มาแสดงผลเป็นกราฟ
  3. ร่วมร่างไฟล์ให้กลับมาจากแพ็คเก็ตที่ได้จาก Wireshark ^^
  4. TCP zerowindow กับปัญหาที่เกิดขึ้นใน network
  5. การหาค่า TCP Delay และนำมาแสดงบน Column ใน WireShark

จากตัวอย่างบทความที่แนะนำมาข้างต้นผู้ที่สนใจ Workshop สามารถใช้อ่านและพิจารณาเนื้อหาเบื้อต้นก่อนสมัครเรียน Workshop ได้ทันทีครับ

ค่าใช้จ่ายในการเรียน 5,000 บาท

สิ่งที่จะได้รับในการเรียน

  1. เอกสารประกอบการเรียนที่มีเนื้อหาและขั้นตอนเป็นภาษาไทยในรูปแบบ PDF
  2. ตัวอย่าง Packet file ประกอบการทดลองต่างๆ
  3. เอกสารอ้างอิงประกอบการสอน
  4. โปรแกรมที่เกี่ยวข้องในการทำ Workshop
  5. VM Image file สำหรับประกอบการทำ Lab เพื่อให้สามารถทำการทดลองและนำไปใช้ทบทวนที่บ้านได้

หมายเหตุุ: เนื่องจากมีการใช้งาน EVE-NG ในการทดลอง ดังนั้นผู้เรียนจึงควรมี Notebook ที่มี Spec ขั้นต่ำดังนี้ เพื่อให้การทดลองได้ประโยชน์สูงสุด

1. CPU Intel core i3

2. Free space on HDD 80G (SSD for best performance)

3. RAM 8G

ระยะเวลาในการอบรม : ระหว่างวันที่ 28-29 ตุลาคม 2560 เวลา 9:00น. – 17:00น.
จำนวนผู้เข้าอบรม : สูงสุด 12 ท่าน
ค่าอบรม : ท่านละ 5,000 บาท -> โอนเงินมัดจำ 2,500 บาทล่วงหน้า ส่วนที่เหลือ จ่ายในวันที่เริ่มเรียน Workshop เพื่อยืนยันในการพิมพ์เอกสารประกอบการเรียน
สถานที่อบรม : Comscicafe ติดสถานีรถไฟฟ้า BTS แบริ่ง (มีที่จอดรถให้ผู้เข้าอบรมทุกท่าน)

แผนที่ของ ComSci cafe ใน Google maps คลิกดู ที่นี่

กรณีที่มีความสนใจ Workshop นี้สามารถติดต่อสอบถามได้ที่ Email: info@virtualnetsystems.com หรือ Dowload รายละเอียดเพื่อนำเสนอหน่วยงานได้ ที่นี่

ใช้ Wireshark เพื่อวิเคราะห์ความผิดปกติในการทำงานของ Application

หลังจากเขียนเรื่องเกี่ยวกับ Wireshark มาระยะหนึ่งแล้วหลายๆท่านก็น่าจะได้แนวคิดในการใช้งานโปรแกรมนี้กันมากขึ้นกันแล้ว วันนี้ผมขอเสนอการเอาโปรแกรม Wireshark มาใช้วิเคราะห์ความผิดปกติของ Application ที่เกิดขึ้นโดยใช้งาน Feature IO graph เพื่อแสดงให้เห็นการทำงานที่ผิดปกติได้ชัดเจนและเป็นรูปธรมมมากขึ้น

วันนี้จะขอสมมติเหตการณ์ที่เกิดขึ้นใน Office แห่งหนึ่งซึ่งมีปัญหาการใช้งาน Application server ดังนี้

  • User A รายงานว่าเมื่อใช้งาน App 1 บน Application server 2 ในช่วงเช้าจะสามารถใช้งานได้สักครู่แล้วโปรแกรมจะหลุดเองไม่สามารถใช้งานได้ ต้องรอระยะนึงจึงจะสามารถใช้งานโปรแกรมได้อีกครั้ง
  • User B ซึ่งใช้งาน App 1 เช่นเดียวกันใช้งานบน Application server 1 ในช่วงเวลาเดียวกันกลับไม่มีปัญหา
  • User C ใช้งาน App 2 บน Application server 2 ได้ตั้งแต่เริ่มงานในช่วงเช้ากลับไม่พบปัญหาใดๆเลย

จากการตรวจสอบปัญหาของโปรแกรมเมอร์ที่เขียนโปรแกรม App 1 ที่ติดตั้งลงใน Application server 1 และ 2 รายงานว่าโปรแกรมไม่มีความผิดปกติใดๆ คาดว่าการที่ App 1 บน Application server 2 ใช้งานไม่ได้นั้นน่าจะเกิดจากการที่ ผู้ดูแลระบบ Network มีการทำ QoS ทำให้เมื่อมีการใช้เข้าใช้งาน Network ในช่วงเช้าที่มีปริมาณข้อมูลจำนวนมากทำให้ App 1 บน Application server 2 มีปัญหา

จากรายงานของโปรแกรมเมอร์ที่ได้ส่งไปให้หัวหน้าทีม Network ทำให้ Network engineer ทำการหาสาเหตุของปัญหาที่เกิดขึ้นโดยใช้โปรแกรม Wireshark เพื่อหาสาเหตุที่แท้จริงมารายงานต่อไป

ตอนนี้เราจะใช้ข้อมูลจากบทความตอนที่แล้วนำมาแยกเป็นชุดการสื่อสารแบบ Client-server มาแยกเป็นชุดไว้จะทำให้ได้ชุด Filter string ดังต่อไปนี้

  • ip.addr==172.16.4.115 && ip.addr==192.168.1.9 && tcp.port==2074 -> Application server 1 – App 1
  • ip.addr==172.16.4.115 && ip.addr==192.168.1.2 && tcp.port==2077 -> Application server 2 – App 2
  • ip.addr==172.16.4.115 && ip.addr==192.168.1.2 && tcp.port==2074  -> Application server 2 – App 1

แต่ก่อนที่จะทำการแยกแยะการใช้งานเป็นแบบ Client-server ให้ลองทำการพิจารณาภาพรวมการใช้งานระบบ Network ก่อนโดยใช้ Feature IO graph จะได้ผลดังนี้

ต่อมาลองดูภาพรวมของการเชื่อมต่อไปที่ Application server 2 จากเครื่อง Front end จะได้ดังนี้ (Filter string: ip.addr==172.16.4.115 && ip.addr==192.168.1.2)

จากกราฟภาพรวมของระบบ Network ในรูปแรกและการเชื่อมต่อไปที่ Application server 2 ไม่พบการทำงานของการทำงานของ QoS ซึ่ง Throughput จะต้องมีลักษณะราบเรียบลงในส่วนที่ QoS ทำงานอยู่

ต่อมาลองพิจารณาการทำงานของ App 1 และ App 2 ที่อยู่ที่เครื่อง Application server 2 โดยใช้ Filter string ดังนี้

  • ip.addr==172.16.4.115 && ip.addr==192.168.1.2 && tcp.port==2077 -> Application server 2 – App 2
  • ip.addr==172.16.4.115 && ip.addr==192.168.1.2 && tcp.port==2074  -> Application server 2 – App 1

จากกราฟที่ได้จะพบว่าที่เครื่อง Application server 2 จะมีความผิดปกติที่ App 1 เท่านั้นซึ่งตรงกับที่ User A, C รายงาน

ต่อมาให้ทำการเปรียบเทียบการทำงานของ App 1 และ App 2 ที่ติดตั้งลงบนเครื่อง Application server 2 จะได้ผลดังนี้

จะเห็นได้อย่างชัดเจนว่า App 1 บน Application server 2 มีปัญหาเกิดขึ้นเพียง App เดียวจริง

เพื่อความแน่ใจลองตรวจสอบการทำงานของ App 1 ที่เครื่อง Application server 1 เพื่อลองหาความผิดปกติที่อาจจะเกิดขึ้้นด้วย Filter string: ip.addr==172.16.4.115 && ip.addr==192.168.1.9 && tcp.port==2074 จะได้ผลดังนี้

จากผลที่ได้จะตรงกับที่ User B รายงานว่าสามารถใช้งาน App 1 บนเครื่อง Application server 1 ได้อย่างปกติ

ต่อมาลองทำการเปรียบเทียบค่า Throughput ของ App 1 บน Application server 1 และ Application server 2 เพื่อหาความแตกต่างว่าถ้า QoS เป็นต้นเหตุของปัญหาค่า Throughput ของทั้ง 2 server ควรจะมีค่าที่ต่างกันมากจนทำให้ QoS ทำงานจนตัด Connection ของ Application server 2

จากกกราฟที่ได้แสดงให้เห็นว่า Throughput ของ App 1 บน Application server 1 และ Application server 2 มีค่าใกล้เคียงกันมากในช่วงเข้าจนกระทั่งช่วงเวลาประมาณ 9.30น. App 1 บน Application server 2 จึงเกิดปัญหาไม่สามารถใช้งานได้ และหลังจากที่ App 1 กลับมาใช้งานได้ค่า Throughput ของ App 1 ก็ยังมีค่าใกล้เคียงกันทั้ง 2 server (มีค่าต่างกันบ้างอาจจะเกี่ยวกับการดึงข้อมูล) ดังนั้นการที่กล่าวว่า QoS เป็นสาเหตุของปัญหาที่เกิดขึ้นจึงเป็นเรื่องที่ไม่เป็นความจริงและไม่มีหลักฐานใดที่ระบุได้ว่าระบบ Network มีปัญหาในช่วงเวลาดังกล่าว

และเมื่ออพิจารณาจากภาพรวมที่ได้จากระบบ Network ทั้งหมดจะเห็นได้อย่างชัดเจนว่าปัญหาที่เกิดขึ้นนั้นน่าจะเกิดจาก App 1 ที่มีการใช้งานระหว่างเครื่อง Frontend (172.16.4.115) และ Backend (192.168.1.2) มากกว่าจะมาจากระบบ Network

ผมหวังว่าบทความนี้น่าจะเป็นตัวอย่างการนำโปรแกรม Wireshark ไปประยุกต์ใช้งานให้กับหลายๆท่านได้ต่อไปนะครับ

ถ้าอ่านแล้วถูกใจอยากมาลองเรียนเพิ่มเติมกับเราตั้งแต่พื้นฐานจนทำให้ได้ผลลัพธ์ออกมาเป็นรูปร่างได้เหมือนในบทความและยังสามารถนำความรู้ไปต่อยอดได้ ลองมาเรียนกับเราได้โดยดูรายละเอียดได้ ที่นี่ นะครับ ^^

การสร้าง Initial configuration ของอุปกรณ์ใน UnetLab

กลับมาเขียนบทความลง Blog อีกครั้งหลังจากมีกิจกรรมใหม่ๆอีกครั้งครับ

รอบนี้เป็นบทความที่ค้างไว้จากที่ได้แจ้งไว้ที่หน้า FaceBook page และเป็นเรื่องที่หลายๆคนที่มีเรียน UnetLab แล้วยังมึนๆอยู่ นั่นคือเรื่องของการทำ Initial configure (Exported CFG) ของอุปกรณ์นั่นเอง

ก่อนอื่นก็ต้องขอเกริ่นกันก่อนว่า Initial configure ที่ว่านี้คืออะไรกันก่อน ลองนึกดูว่าในการทำ Lab ของแต่ละคนจะต้องทำอะไรก่อนเป็นขั้นตอนแรกหลังจากเปิดอุปกรณ์อย่าง Router ขึ้นมา? สิ่งที่หลายๆคนจะทำก็คือการตั้งค่า Hostname และการกำหนด IP address ให้กับ Interface ต่างๆของอุปกรณ์ที่ได้ออกแบบมาไว้แล้วจาก Diagram ที่เราวาดไว้ในกระดาษหรือโปรแกรมก่อนหน้านี้ (ไม่รวมการต่อสายต่างๆนะ) ซึ่งเมื่อทำขั้นตอนนี้เสร็จแล้วส่วนมากเราจะทำการ Save configuration ชุดนี้ไว้ก่อนที่จะเริ่มลงมือทำการทดลอง Lab กันต่อไป ซึ่งขั้นตอนนี้นี้ผมจะขอเรียกว่าการทำ Initial configure ของ UnetLab นั้นเอง

คำถามต่อมาทำไมเราจะต้องมาทำ Initial configure ด้วยล่ะ? ในเมื่อเวลาที่เราทำ Lab ไปแล้วเราก็ลงมือทำต่อไปเรื่อยๆได้อยู่แล้ว ไม่เห็นว่าจะมีความจำเป็นอะไรเลย? ลองย้อนกลับไปที่การทำ Lab ด้วยการใช้อุปกรณ์จริงกันก่อนละกัน ผมจะมีคำถามว่าถ้าเรา Configure อุปกรณ์ผิดไปแล้วหาจุดที่เราทำผิดไม่ได้และทำให้ต้องเริ่ม Configure อุปกรณ์ใหม่ตั้งแต่ต้นอีกครั้งหรือไม่? น่าจะเคยกันมาบ้างสำหรับคนที่ต้องการทำ Lab บ่อยๆ กรณีนี้หลายๆคนก็จะบอกว่าทำผิดก็อย่าเพิ่งไป Save configure ที่ไว้ไว้สิ พอเปิดปิดอุปกรณ์ใหม่มันก็มาเริ่มจุดที่ทำ Save ไว้ วิธีการแบบนี้ก็เป็นที่มาของการใช้งาน Initial configure แบบ Classic แบบนึงครับ แต่ที่มันเหนือกว่านั้นคือใน UnetLab สามารถทำการดึงเอา Initial configure ที่เก็บไว้นำมา Apply กลับเป็น Initial configure ที่ต้องการหลังจากที่เราได้ Save configuration ด้วย Command เช่น Write men หรือ Commit ทับ Initial configure ที่ใช้อยู่ไปแล้วไม่ว่าจะมีการ Save ทับไปแล้วกี่รอบด้วยการกดเมนูเท่านั้น ไม่ต้องทำการ Dump configuration ใหม่อีกรอบ

ประโยชน์ที่ผู้ใช้งานจะได้รับอย่างเต็มที่อีกส่วนหนึ่งก็คือการสร้าง Lab เพื่อฝึกแก้ปัญหาที่เกิดขึ้น เช่น ฝึกทำ Lab สำหรับการสอบ TSHOOT หรือการเตรียมสอบ CCIE ที่มีหัวข้อ Troubleshooting นั้นเอง การแก้ปัญหาหรือ Ticket ในลักษณะนี้มักจะมีการทดลองแก้ Configuration ของอุปกรณ์อยู่เสมอๆ และบ่อยครั้งที่จะทำให้ค่าที่โจทย์ให้มีมีปัญหาหนักมากกว่าเดิม!!! เนื่องจากเราแก้ปัญหาผิดจุดนั้นเอง การนำ Initial configuration มาใช้งานในลักษณะนี้จึงมีประโยชน์อย่างมากนั้นเอง แต่ UnetLab ยังมีการทำงานทีเกี่ยวกับการจัดการ Configuration รูปแบบอื่นอีกซึ่งจะมีตัวอย่างการใช้งานด้านท้ายบทความครับ

เท่านี้ก็คงจะพอเห็นความสำคัญของการนำ Initial configure มาใช้งานกันบ้างแล้วนะครับ ในส่วนนี้เราจะมาเริ่มลงมือสร้าง Initial configure ใน UnetLab กันครับ

ก่อนที่จะลงมือสร้าง Initial configure นั้นเราจะต้องสร้าง Lab ใน UnetLab ขึ้นมาให้เรียบร้อยก่อน โดยในตัวอย่างผมจะใช้ Lab ที่ได้สร้างไว้แล้วในหัวข้อของ Service Provider (ยังไม่ได้เขียนต่อเลย ^^”)

จากรูปตัวอย่างถ้าใครสังเกตุจะเห็นว่ามีการเปลี่ยนแปลงเล็กน้อยที่ CE ทั้งสองฝั่งเมื่อเทียบกับตัวอย่างใน Blog เนื่องจากมีแผนที่จะเพิ่มรูปแบบ Lab นั่นเองครับ ^^

ขั้นตอนต่อมาให้ทำการเปิดอุปกรณ์ขึ้นมาทั้งหมดและ Configure อุปกรณ์โดยใช้ Command ที่อยู่ในหัวข้อ “Service Provider Lab Series Part 1” มาสร้างเป็น Initial configure ครับ เมื่อใส่ Command ให้กับอุปกรณ์ที่ต้องการหมดแล้วต้อง Save configuration ให้อุปกรณ์ทุกตัวด้วย Command “wr” หรือ “commit” เพื่อ Save configuration ที่เราทำไว้

ขั้นตอนนี้จะเป็นขั้นตอนพิเศษสำหรับการสร้าง Initial configure แล้ว ให้เลือกที่เมนู More actions -> Export all CFGs เพื่อให้ UnetLab ทำ Export configuration ที่เรา Save ไว้บนอุปกรณ์ออกมาเก็บไว้

จากนั้นให้ลองตรวจสอบการทำงานของ UnetLab ว่าถูกต้องหรือไม่โดยไปที่เมนู Startup-configures ถ้าเราทำถูกต้องจะต้องมี
รูป Drive A ที่มีเครื่องหมายถูกบนมุมขวาล่างขึ้นมาที่หลังรายชื่ออุปกรณ์ทุกตัวที่ได้ Save configuration ไว้ เพียงเท่านี้เราก็จะมี Initial configure ของอุปกรณ์เก็บไว้ใช้งานแล้ว

มาถึงตอนนี้หลายๆคนจะมีคำถามขึ้นมาคือ แล้วอะเอาไปใช้งานยังไง? สำหรับการใช้งานอะแบ่งออกเป็นลักษณะต่างๆดังนี้

  • เมื่อต้องการนำ Initial configure มาใช้งาน -> กด Set all startup-cfg to exported -> Wipe all nodes
  • เมื่อต้องการให้อุปกรณ์กลับไปที่สถานะที่ไม่มีการตั้งค่าให้อุปกรณ์ใดๆเลย(No configuration) -> กด Set all startup-cfg to none -> Wipe all nodes
  • เมื่อไม่ต้องการลบ Initial configuration ออกไป คือไม่ต้องการให้มีการเก็บ Initial configuration ไว้ใช้งานอีกต่อไป -> กด Delete all startup-cfg -> Wipe all nodes

ลองมาสรุปการทำงานของการสร้าง Initial configuration ใน UnetLab กันด้วยรูปก็น่าจะได้ประมาณนี้ครับ

สำหรับบทความนี้สามารถโหลดบทความในรูปแบบ PDF ได้จาก ที่นี่ ครับ

สำหรับ Video เสริมความเข้าใจดูได้จากด้านล่างนี้เลยครับ

การ Convert disk image เพื่อใช้งานบน UnetLab

ทำตามสัญญาครับวันนี้ทำ Video เรื่องการ Convert disk image บน UnetLab มาให้ดูครับ ตามตัวอย่างมี 3 ตัวคือ Arista, F5 และ HP โดยทั้ง 3 ตัวสามารถไปขอใช้งานได้ฟรีแต่ต้องมีการ Register ก่อนครับ

ลองทำตามกันดูครับติดขัดยังไงก็ลอง Post ถามกันได้ครับ