ความแตกต่างการการใช้งาน filter ในการมองหาปัญหาที่อาจจะเกิดขึ้น

ซินจ่าวววววววว 😉

อาทิตย์นี้มาทำงานที่เวียดนามครับ ขอสลับโหมดจากงานมาเขียน Blog สักหน่อยแก้ปวดหัว ^^”

จากใน Facebook page ครั้งก่อนมีการเกริ่นว่าจะแนะนำข้อแตกต่างของการใช้งาน Command filter สองตัวคือ tcp.port และ telnet ซึ่ง Telnet ก็เป็น Application ตัวหนึ่งซึ่งใช้ Protocol TCP ในการสื่อสาร และเมื่อใช้ Command ตัวอย่างไปแล้วก็ได้ผลลัพธ์ออกมาคล้ายกันมากทีเดียว แล้วการใช้งาน Command ในรูปแบบไหนจะดีกว่ากัน วันนี้เราจะมาอธิบายกันในหัวข้อวันนี้ครับ

ก่อนจะไปไกลที่ Application เรามาเริ่มที่ Protocol กันก่อน โดยส่วนตัวแล้วคิดว่าใครก็ตามที่ได้เรียนด้าน Computer มาก็จะรู้จักคำว่า TCP handchecking กันมาบ้างแน่นอน (ผมเพิ่งมารู้จักตอนทำงานนี่ล่ะ ข้อเสียของการจบไม่ตรงสาย ^^”) โดยทั่วไปแล้วจะมีการกล่าวถึง TCP handchecking กันอยู่ 2 packet คือ

1. Sync
2. Sync/Ack
3. Ack

ตามที่เรียนมาทั้ง 3 packet นั้นก็จะอยู่ในรูปด้านบนในส่วนของ Open connaction ที่เขียนด้วยตัวอักษรสีม่วงด้านซ้ายมือ เมื่อสามารถ Open connection ได้แล้วตัว Application ก็จะเริ่มเข้าสู่การสื่อสาร โดยจะเริ่มส่งข้อมูลกันในลำดับถัดไปนั่นเอง และเมื่อได้ข้อมูลครบแล้ว เมื่อเลิกใช้งานก็จะมีการปิดการสื่อสารตรงส่วนนี้เองก็จะเกิด Close connection ในส่วนของตัวหลังสือสีแดงด้านซ้ายมือในรูป เป็นอันจบเรื่องของ TCP แบบคร่าวๆครับ

คราวนี้ลองมาดูใน Wireshark กันดีกว่า ในตัวอย่างนี้เอามาจากใน Lab ที่สอนในห้องเรียนมาเพื่อที่จะได้ประหยัดเวลา ตัวอย่างที่ใช้เป็นการ Telnet เข้าไปที่ Cisco router ตัวหนึ่งซึ่งเราใช้ EVE-NG จำลองขึ้นมาตามในรูปด้านล่างนี้ แล้วก็เปิด Terminal ขึ้นมาเพื่อ Telnet เข้าสู่ Virtual router ตัวนี้ และก็ได้เก็บ Packet ตัวอย่างออกมาครับ

คราวนี้เรามาลองใช้งาน Command filter กันเลยเริ่มต้นด้วย “telnet” ที่เป็นชื่อของ Application ที่เราใช้ลงในช่อง Filter expression ตามในรูปด้านล่างนี้ สิ่งที่ Wireshark แสดงผลออกมาให้คือ

จากผลที่ได้จะเห็นว่า Packet แรกที่ได้เป็น Data ที่ถูกส่งมาเป็น Packet แรกถูกส่งออกมาจากฝั่ง Server และหลังจากนั้นจะเป็น Packet ที่มีการรับส่งระหว่างกันไปเรื่อยๆ ตราบเท่าที่มีการร้องขอ Data

ต่อมาก็ลองใช้ Filter command ใหม่อีกตัวหนึ่ง “tcp.port==23” การใช้ Command นี้ก็มาจากพื้นฐานของ Application Telnet ใช้ Protocol TCP และใช้ Port หมายเลข 23 ดังนั้นจึงเป็นที่มาของ Command filter นี้

จากผลที่ได้จะเห็นว่า Packet แรกที่ได้เป็น TCP handcheck แล้ว และเป็นการเปิด Connection มาจาก Client ตามที่ได้เรียนมาตามทฤษฎีเป๊ะเลย

มาต่อกันที่ว่าไอ้แบบที่ใช้ Command filer “telnet” กับ “tcp.port==23” จะเอามาใช้ในกรณีไหนบ้าง

1. ใช้ Command “telnet” ก็ต่อเมื่อไม่ได้มีปัญหาในการเชื่อมต่อ และต้องการดูเฉพาะข้อมูลที่อยู่ข้างใน หัวข้อนี้เดี๋ยวมาต่อในบทความหน้านะครับ ^^
2. ใช้ Command “tcp.port==23” ข้อดีจากที่เห็นจากตัวอย่างคือ การที่เราเห็นขั้นตอนตั้งแต่การเปิด TCP connection แบบ TCP handcheck ดังนั้น การใช้งาน Command นี้จะใช้ในกรณีที่การเชื่อต่อมีปัญหา ดังนั้นเมื่อเราไม่สามารถใช้งาน Application ได้ เราก็จะต้องมาให้ความสนใจกับการเปิด TCP connection นั่นเองครับ

สำหรับบทความนี้ก็ขอจบไว้เท่านี้ครับ

ตัวอย่างการใช้งาน Filter เพื่อหาข้อมูล Protocol ที่ต้องการ

บทความแรกของปี 2019 หลังจากหายไปเกือบ 2 ปี!!!

เป็นตัวอย่างการใช้งาน Filter ใน Wireshark เพื่อให้เราสามารถเลือกเฉพาะ Protocol ที่เราสนใจมาแสดงผลได้อย่างเหมาะสมต่อไป ทำไมเราต้องใช้ Filter? คำตอบคือ Packet มีเป็นล้านแล้วคุณจะหาข้อมูลที่คุณต้องการได้ยังไงถ้าไม่ใช้มัน!!!

จากการที่เราหายไปเป็นปีๆ เรามีตัวอย่างจาก Diagram ด้านล่างนี้เราเอามาทำเป็น Lab เล็กๆใน EVE-NG สักหน่อย สังเกตุว่าในรูปจะมี Client แค่ตัวเดียว แต่ในงานจริงอาจจะมีได้เป็นแสนหรือล้าน Client นะครับ

พอลองจับ Packet ที่ Gatewat ที่รับข้อมูลเข้ามาจาก Access ในเวลาไม่เกิน 5 นาทีจากรูปด้านล่างนี้เราจะได้ Packet มาทั้งหมด 3,967 Packet ถ้าเราต้องการการการเปิด PPPoE discovery session จาก Client โดยไม่ใช้การ Filter เลยเราก็อาจจะเสียเวลาไปอาจจะหลายชั่วโมงเลยทีเดียว

คราวนี้ลองมาใส่ Filter กันดูบ้างว่าจะได้ผลเป็นยังไงบ้าง

จากตัวอย่างเรารู้ว่าเราต้องการหาการเปิด PPPoE discovery session จาก Client เราก็ลองใส่ Filter ลงไปเลยในช่องของ Expression ถ้าเราใส่ Filter ถูกต้องสีของช่อง Expression ก็จะเป็นสีเขียวแล้วเราก็จะได้ PPPoE discovery ออกมาแล้ว

สำหรับ Packet ของ PPPoE discovery จะมีอยู่ 5 ตัวย่อยคือ PADI, PADO,PADR, PADS กรณีปิด session เราจะเจอ PADT เป็นตัวสุดท้ายนะครับ

เช่นกันในฝั่งของ RADIUS เราก็จะลองใช้ Filter เข้ามาช่วยดูกันด้วยจากจากใน Lab ที่เตรียมมาจะได้ผลแบบนี้

สุดท้ายเราก็มาดูตัวอย่างจากข้อมูลที่ได้จาก Message ของ RADIUS access-accept กันดู

จากตัวอย่างนี้จะเห็นข้อมูลใน Message access-accept ที่มาจาก RADIUS server กันแล้ว คำถามคือแล้วยังไงต่อล่ะครับ??

แน่นอนพอเราเห็นข้อมูลได้แบบนี้แล้วเราก็จะสามารถคาดเดาการทำงานได้ประมาณนี้

1. เนื่องจากเป็น Message access-accept ดังนั้น กรณีนี้จึงเป็นการใช้ที่เป็นไปตามปกติ
2. แต่ถ้าเป็น Message access-reject แสดงว่าอาจจะเกิดจากสาเหตุ ต่างๆได้อีกดังนี้
   • ใส่ Username หรือ Password ผิด
   • Session ที่ใช้งานเต็ม

ซึ่งจะต้องเอาข้อมูลที่ได้จาก Message เหล่านี้มาลองวิเคราะห์ปัญหาที่เกิดขึ้นต่อไปนั่นเอง อย่างกรณีของ RADIUS อาจจะให้ส่ง Message เพิ่มเติมในความผิดปกติเกี่ยวกับการ Login แบบนี้ได้ด้วย เช่น การส่งค่า Redirect page หรือส่งค่า IP address แบบเฉพาะเจาะจงให้ User เข้าไปอยู่ใน Screen zone ทำให้ไม่สามารถใช้งานได้เป็นต้นครับ

การใช้ 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 ไปใช้งานได้ดีขึ้นในส่วนนึงนะครับ

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

แสดงค่า 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 ก็ประมาณนี้

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