สวัสดีครับ อ.ศุภเดชครับ
เวลาที่อุปกรณ์คอมพิวเตอร์ใดๆมีปัญหา การดู Error Message หรือ Error Log ก็คือวิธีที่จะทำให้เรารู้ได้ว่าปัญหามันอยู่ตรงไหน ในอุปกรณ์ Network อย่าง Mikrotik เอง ก็มี syslog ไว้แจ้งปัญหาในระบบเหมือนกันครับ ซึ่งจากที่ผมอยู่ตามกลุ่มหรือ Line Group ต่างๆ มีเพื่อนๆหลายท่านมาแจ้งปัญหา แต่บางทีก็ยังไม่ได้ไปดูใน Log ซึ่งการเอา Error ใน Log มาถามจะทำให้เข้าใจปัญหาได้เร็วขึ้นครับ
bridge port received packet with own address as source address
อาการนี้ หมายถึง มี Loop เกิดขึ้นในระบบครับ ถ้าจะอธิบายแบบง่ายๆก็คือ มันมีสาย LAN หรือ การ Config อะไรซักอย่างที่ผิดพลาดในระบบของ Switch ที่ทำให้ข้อมูลที่ Mikrotik ปล่อยออกไปวนกลับมาหาตัวเอง
แนวทางการแก้ไข
ถ้าคุณใช้ Managed Switch อยู่ ส่วนใหญ่จะมีแจ้งใน Log ของ Switch ว่ามันมี Loop เกิดที่ Port ไหน ก็ไปหาต้นตอของสายแล้วก็ไปดึงออกซะ
ถ้าคุณไม่ได้ใช้ Managed Switch ก็อยากจะบอกว่า นรกเรียกหาแล้วครับ เพราะคุณต้องไล่หาไปทีละ Port ว่าจุดที่ทำให้เกิด Loop มันอยู่ตรงไหน ถ้ามี Switch ไม่กี่ตัวก็อาจจะไม่เหนื่อยมาก แต่ถ้า Office ใหญ่ๆมี Switch หลายตัว ก็ขอให้โชคดีครับ
จากประสบการณ์ที่ผมเจอมา ผมเจอ Loop จากการไม่ตั้งใจซะเป็นส่วนใหญ่ เช่นแม่บ้าน เจอสายกองอยู่กับพื้นเลยเอาไปเสียบกับ Outlet ให้ หรือ User เอาอุปกรณ์อะไรมาเสียบเองแล้วทำไม่เป็นเลย Loop แต่ครั้งที่โหดร้ายที่สุดที่ผมเคยเจอก็คือ เคยเจอปัญหา Loop ใน Network ของบริษัทนึงที่แบ่ง Office ออกเป็นสามตึก แต่ละตึกมี 4 ชั้น แต่ละชั้นสาย LAN ไม่มีผัง และมี Switch 5 – 8 Port ต่อกันเป็นต่อนเต็มไปหมด กว่าจะไล่ตัดออกไปได้ว่าปัญหาอยู่ที่ไหนก็แทบตายแล้ว ปรากฏว่า Loop เกิดจาก Server 1 เครื่อง ที่เสียบสาย LAN อยู่เส้นเดียว
พอไล่ไปไล่มา ปรากฏว่า เป็น VM Server ที่ Config Virtual Switch ผิดทำให้เกิด Loop ใน Server จ้า น้ำตาไหล
warning dhcp offering lease without success
Error นี้ เกิดขึ้นจาก DHCP Server ของ Mikrotik ทำงานได้ไม่ครบ Process การทำงานของมันครับ
หน้าที่ของ DHCP Server คือทำการแจกค่า IP Setting ให้กับ Client ที่ร้องขอใน LAN ของเราครับ
Step ของมันมี 4 ขั้นตอนด้วยกัน
- Client ทำการ Broadcast ใน LAN ว่า ใครคือ DHCP Server บ้าง ฉันขอ IP Address และค่า Setting หน่อย
- DHCP ได้รับการร้องขอ ก็ตอบกลับไปว่า ฉันนี่แหละคือ DHCP Server นี่คือค่า Setting ของเอ็ง เอาไปซะ
- Client Broadcast ไปใน Network เพื่อประกาศให้รู้ว่า เฮ้ ทุกคน ฉ้นคือ IP Address นี้นะ
- DHCP Server รับทราบการประกาศ แล้วก็บันทึกว่า เจ้าเครื่องนี้มันเอา IP นี้ไปนะ เดี๋ยวพอครบ Leased time จะมาเอาคืน อะไรก็ว่าไป
หลักๆก็มี 4 ข้อประมาณนี้ครับ
แล้ว Error นี้มาจากไหน ทำไมถึงเกิดขึ้นได้??
Error “leased without success” นี้ก็คือเกิดจาก DHCP Server ผ่าน Step หนึ่งไปจนถึงสองครับ คือ Client ร้องขอ แล้ว DHCP Server ก็ให้ไป แต่ เอ๊ะ ทำไม Client ไม่ประกาศกลับมาว่าฉันได้แล้ว พอถึงเวลาที่กำหนดไว้ DHCP Server ก็แจ้ง Error ว่า เฮ้ย คนที่มาเอา IP Address มันไม่ประกาศว่ามันได้แฮะ
ซึ่งตามหลักแล้ว ถ้าไม่ได้ IP Address ก็แปลว่าจะไม่สามารถใช้งานใน Network นี้ได้นั่นเองครับ
แล้วสาเหตุน่าจะเกิดจากอะไรบ้าง??
สาเหตุที่หนึ่ง – IP Pool เต็ม
IP Pool คือกลุ่มของ IP Address ที่เรา เตรียมไว้ให้ DHCP Server แจก ซึ่งตรงนี้ มันมีปัจจัยในการวิเคราะห์ปัญหาหลายแบบ เช่น Client ในองค์กรเยอะเกินกว่าที่เราจะแจกจริงๆ อันนี้ทางแก้ก็คือ ขยาย Network Subnet แล้วก็ขยาย IP Pool หรือจะเอา VLAN มาแบ่งวง Network เพื่อลด Broadcast อะไรก็ว่าไป
อีกปัญหาที่เจอบ่อยจาก IP Pool เต็มก็คือ กำหนด Leased time ไม่เหมาะสมกับ จำนวน Client ที่เกิดขึ้น เช่นเราเป็นร้านกาแฟ มีลูกค้าเข้าๆออกๆ ร้านตลอดเวลา คนนึงใช้บริการไม่นาน แต่ดันกำหนด Leased time ที่แจก IP Address ไป 24 ชั่วโมง แจก IP ไปแปบเดียวก็หมดแล้ว อะไรแบบนี้ครับ
ปัญหา IP Pool ไม่พอจึงต้องไปค้นหาต้นตอจริงๆให้เจอ ว่ามันไม่พอจริงๆ หรือเรากำหนดค่า Setting ไม่เหมาะสมกันแน่
สาเหตุที่สอง – มี DHCP Server อีกตัว ทำการปล่อย IP Address สวนกับเราในระบบ
น่าจะเป็นปัญหาที่หลายๆคนโดนกันโคตรบ่อย เช่น User อวดเก่งที่อยากจะเอา Router มาต่อเพื่อปล่อย WIFI ของตัวเอง แต่ดันเสียบ LAN ผิด Port ทำให้ DHCP ของตัว Router ที่ User ใข้มันสวนเข้ามาชนกับ DHCP Server หลัก
ซึ่งตรงนี้ อยากให้ย้อนกลับไปดูภาพของ DHCP Step 4 ขั้นตอนนะครับ จากขั้นตอนที่ 1 ที่ Client ทำการ Broadcast ไปทั่ว Network เพื่อถามว่าใครบ้างเป็น DHCP Server ถ้าใน Network ที่เราดูแลอยู่มี DHCP Server อยู่ 2 ตัว คือของเราตัวนึง ของ User ที่ไม่ถูกต้องตัวนึง
เมื่อ Client ทำการ Broadcast ในระบบเพื่อถามว่าใครเป็น DHCP Server บ้าง
DHCP Server ตัวไหน ตอบเร็วกว่า Client ก็จะรับ IP Address จาก DHCP Server ตัวนั้นไปครับ ดังนั้นมันก็มีโอกาสที่จะรับ IP Address ที่ถูกต้อง แล้วก็มีโอกาสที่จะรับผิดเหมือนกัน
พอ DHCP Server (ที่ถูกต้องของเรา) แจก IP Address ไปใน Step 2 แต่ Client ไม่ตอบกลับมาใน Step 3 ก็จะได้ Error นี้เช่นกันครับ
ทางแก้เรื่องของ DHCP Server สวน ก็คือ ต้องเปลี่ยน Network Switch ทั้งหมดให้เป็น “Managed Switch” (ซึ่ง Managed Switch ดียังไง ไปดูวีดีโอได้ที่นี่เลยครับ) พอเปลี่ยนเสร็จ ก็ต้องทำ DHCP Snooping ขึ้นมาในระบบครับ ซึ่ง DHCP Snooping ก็คือ จะมีการกำหนด “Trusted Port” หรือ Port ที่เราเชื่อถือและอนุญาตให้ DHCP Frame วิ่งผ่านได้
ดังนั้น ถ้ามีการส่ง DHCP Frame มาจาก Untrusted Port ก็ตัว Managed Switch ก็จะเตะทิ้งไปไม่สนใจ ทำให้ Client ของเรา รับ IP Address อย่างถูกต้องนั่นเองครับ
สาเหตุที่สาม – กำหนดค่า VLAN ผิด
โอ้โห ข้อนี้ต้นตอของการกำหนดผิดเยอะมากครับ เสียบสายผิด , Untag ผิด , ลืมใส่ VLAN ID , ลืมกำหนด Trunk Port สารพัดไปหมด ซึ่งถ้าปัญหาไม่ใช่ข้อหนึ่งและสอง ก็คือสามนี่แหละครับ แต่การจะหาต้นตอปัญหาของสามนี่ แล้วแต่ Network ของแต่ละคนเลยครับ
FCS Error on Link
FCS ย่อมาจาก Frame Check Sequence มันคือลำดับของการส่งเฟรมไปบนสาย หรือบน Media ต่างๆนี่แหละครับ สรุปง่ายๆก็คือ มีปัญหาที่สาย หรือ ที่หัวต่อ ทำให้ค่า FCS Error มันเพิ่มขึ้นอย่างมหาศาลจนแทบส่งข้อมูลไม่ได้
ปัญหานี้บางครั้งก็แก้ง่าย บางครั้งก็แก้ยาก
คือถ้ามันเป็นสาย LAN ในระบบแบบเส้นสั้นๆ หาสาย LAN มาเปลี่ยนใหม่ก็จบ ซึ่ง 70-80% จะแก้ได้ด้วยวิธีนี้ครับ แต่ถ้าสายยาวๆ จะลากใหม่ก็อาจจะต้องทำใจหน่อย
ทางแก้ต่อมาคือถ้าเป็นสาย LAN การลองทำหัว หรือย้ำหัวเดิมให้แน่นขึ้นบางทีก็ช่วยได้เหมือนกัน
แต่ปัญหานี้จะเริ่มยากแล้ว ถ้าเปลี่ยนสายแล้วไม่ให้ เพราะบางครั้งมันไม่ได้เป็นที่เรา แต่มันอยู่กับการ์ด LAN ของฝั่งตรงข้ามเรา เช่นมีเคสนึง ผมไปวางระบบให้ลูกค้าแล้วลูกค้าบอกว่า มี Router 4G ตัวเก่า อยากจะเอามาทำเป็น 4G Backup ด้วยได้ไหม
อันนี้ไม่ยาก ผมก็จัดไป ใส่ Routing แปบเดียวเสร็จ ปรากฏว่า Network อืดมากๆ เล่นแทบไม่ได้ผ่าน 4G เลยงง
พอไปเปิด Log ก็เจอ FCS Error on Link บน Port ที่เสียบกับ 4G Router ตัวนี้ ก็งง เอ๊ะ สายเสียหรอ เพราะทุกทีผมใช้สาย Patch แท้จริง Link แกะใหม่ๆจากซองให้ลูกค้าเสมอ
ก็ลองเปลี่ยนสาย อื้มมม ไม่หายแฮะ อาการเดิมยังอยู่
งานนี้ท่าทางจะเป็นที่ 4G Router ของลูกค้าแฮะ เพราะสายเดียวกัน เอามาเสียบ Router อื่น ก็อาการปกติไม่มีอะไร พอเสียบเจ้า 4G Router นี่ปั๊บ ปัญหามาเลย
ซึ่งผมแก้ไขด้วยการ ปลดการทำ auto negotiation speed ของฝั่ง Mikrotik ออก แล้วกำหนดให้ Mikrotik ลดความเร็ว Port จาก Auto เป็น fix ที่ 10mbps ถึงจะใช้ได้ครับ
ดังนั้น ปัญหาของ FCS Link Error เนี่ย ส่วนใหญ่จะอยู่ที่สาย ถ้าไม่ใช่สายก็อาจจะอยู่ที่ LAN ฝั่งตรงข้ามนั่นเอง ส่วนวิธีที่ผมแนะนำไป อาจจะแก้ได้หรือไม่ได้ก็ได้นะครับ
เอาล่ะครับ 3 Error นี้ก็เป็น Error หลักที่ผมเจอบ่อยๆ จริงๆยังมี Error อื่นอีกนะครับ ไว้จะมาอัพเดมเพิ่มเติมอีกที
สำหรับใครที่เจอปัญหานี้ อยากจะแก้แต่แก้ไม่เป็น ก็ แนะนำให้มาลงเรียนครับ สาเหตุส่วนใหญ่เกิดจากงานออกแบบระบบที่ไม่ได้ออกแบบตามมาตรฐาน แต่เป็นการออกแบบง่ายๆ ให้พอใช้งานได้ ซึ่งช่วงแรกมันอาจจะเพียงพอ แต่พอมีผู้ใช้งานเยอะขึ้น หรือเจอปัญหา กลายเป็นระบบที่เรามี ไม่ได้ออกแบบเพื่อป้องกันเรื่องแบบนี้ไว้เลย ทำให้เกิดความเสียหายหรือ Downtime ขึ้นมาในระบบครับ
