การติดตามที่อยู่ mac ต้นทางไม่ถูกต้อง

ฉันได้รับการสนับสนุนไซต์ระยะไกลซึ่งมี Cisco 4500 และเชื่อมต่อกับสวิตช์การเข้าถึงของซิสโก้ ~ 2 โหล - 2960 วินาทีส่วนใหญ่มี 3750 และ 3560 วินาที ไม่ใช่สวิตช์การเข้าถึงทั้งหมดที่เชื่อมต่อโดยตรงกับ 4500 - มีการผูกมัดเดซี่บางส่วนซึ่งเห็นได้ชัดว่าเป็นผลมาจากการเดินสายที่ไม่เพียงพอ เมื่อเร็ว ๆ นี้ฉันได้สังเกตเห็นข้อความ serror ใน 4500 ซึ่งบ่งชี้ว่าได้รับเฟรมพร้อมที่อยู่ mac ต้นทางไม่ถูกต้อง:

*Sep 10 09:29:48.609: %C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET: (Suppressed 102563 times)Packet received with invalid source MAC address (00:00:00:00:00:00) on port Te5/1 in vlan 1460

อุปกรณ์ที่เชื่อมต่อกับ Te5 / 1 เป็นสวิตช์การเข้าถึง (Cisco 3750) ในทางกลับกันจะเชื่อมต่อกับ 6 สวิตช์การเข้าถึงอื่น ๆ หลังจาก googling เล็กน้อยปรากฏว่า 4500 เป็นแพลตฟอร์ม cisco เดียวที่บันทึกที่อยู่ mac ต้นทางที่ไม่ถูกต้อง จากการอ่านของฉันแพลตฟอร์มอื่น ๆ (2960, 3750, ฯลฯ ) ดูเหมือนจะส่งต่อเฟรมไป แต่ไม่บันทึกไว้ว่าไม่ถูกต้องและพวกเขาไม่เพิ่มรายการลงในตารางที่อยู่ของ Mac ฉันสงสัยว่าสาเหตุที่แท้จริงของที่อยู่ Mac ที่ไม่ถูกต้องอาจเป็นความผิดพลาดข้อบกพร่องของซอฟต์แวร์หรือเซิร์ฟเวอร์ vmware ที่กำหนดค่าผิดพลาด มีเครื่องมืออะไรบ้างที่สวิตช์การเข้าถึงเพื่อติดตามพอร์ตที่ละเมิด

cisco switch layer2

— User123456
แหล่งที่มา

ลบโพสต์ของฉันไม่ทราบว่าพวกเขาไม่ปรากฏเลย หากสวิตช์ไม่ได้ใส่ไว้ใน CAM ฉันคิดว่าทางออกที่ดีที่สุดของคุณคือการเรียกใช้งานเซสชัน SPAN บนสวิตช์ แต่ถึงอย่างนั้นมันก็ยากที่จะหาพอร์ตต้นทาง อีกตัวเลือกหนึ่งคือปิดใช้งาน unicast ที่ไม่รู้จักและดูว่ามีอะไรผิดพลาดหรือไม่ ฉันประหลาดใจที่การสื่อสารทำงาน หากโฮสต์ที่มี MAC นั้นส่งอะไรบางอย่างออกไปข้างนอกซับเน็ต GW จะต้องไปที่ ARP เพื่อดู MAC ของโฮสต์และใส่กรอบเข้าไปในนั้น GW จะมีการแมป ARP แปลก ๆ หรือไม่

— Daniel Dib

ตามsupportforums.cisco.com/docs/DOC-36000เฟรมเหล่านี้ควรลดลงใน HW ดังนั้นอย่างน้อยก็ไม่ควรส่งผลกระทบต่อประสิทธิภาพของสวิทช์

— Daniel Dib

ใช่ตามลิงค์นั้น: "โปรดทราบว่าแพ็กเก็ตที่มีที่อยู่ MAC ที่ไม่ถูกต้องจะถูกทิ้งไว้สวิตช์ Cisco Catalyst อื่น ๆ ทั้งหมดจะส่งแพ็กเก็ตเหล่านี้ใน HW, แพลตฟอร์ม 4k กำลังสร้างข้อความบันทึกอย่างชัดเจนเมื่อสังเกตเห็นเหตุการณ์ดังกล่าว" ... แต่ฉันรู้ว่ามันไม่เป็นเช่นนั้นจริง ๆ เพราะ 4500 กำลังบ่นเกี่ยวกับเฟรมที่มาถึง Te5 / 1 ซึ่งเป็นพอร์ตที่เชื่อมต่อกับ 3750 นี่จะบ่งบอกว่า 3750 กำลังส่งต่อเฟรมที่ไม่ถูกต้อง source mac แม้จะมีสิ่งที่ DOC-36000 พูด

— 123456

หาร & พิชิต!

— Generalnetworkerror

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

— Ron Maupin

คำตอบ:

คุณสามารถลองใช้หากเฟรมสามารถบล็อกได้โดยใช้ MAC ACL บนอินเตอร์เฟสและ / หรือบน vlans บนสวิตช์การเข้าถึง โดยการใช้บล็อกที่เลือกและตรวจสอบว่าข้อความแสดงข้อผิดพลาดใน 4500 หายไปหรือไม่คุณสามารถกลับบ้านได้ในแหล่งที่มาของการรับส่งข้อมูล

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

— Gerben
แหล่งที่มา

โดยทั่วไปเมื่อฉันเห็นสิ่งนี้มันมาจาก VM ที่ตั้งค่าไม่ดี (มักโฮสต์บนเครื่องผู้ใช้) ขึ้นอยู่กับสถานการณ์และสภาพแวดล้อมพวกเขาอาจติดตามได้ยาก (เห็นสิ่งเหล่านี้จำนวนมากที่มหาวิทยาลัยในอาคารแผนก CS และ ECE ซึ่งย้ายและมา / ไป / กลับตามที่นักเรียนทำ)

คุณมีคำตอบที่ดีอยู่แล้ว แต่อีกทางเลือกหนึ่งที่คุณสามารถทำได้คือการเพิ่มการกำหนดค่าต่อไปนี้ลงในสวิตช์ดาวน์สตรีม (37xx, 36xx, 29xx):

   mac address-table static 0000.0000.0000 vlan <VLAN ID> drop

การทำเช่นนี้จะลดทราฟฟิกใด ๆ ของ MAC นี้แทนที่จะส่งต่อและเนื่องจากควรทำในฮาร์ดแวร์ (ยกเว้นคุณสมบัติ / ปัญหาใด ๆ ที่ทำให้การค้นหา MAC ต้องทำในซอฟต์แวร์) จึงไม่ควรมีผลกระทบด้านลบต่อประสิทธิภาพ

— YLearn
แหล่งที่มา

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

— 123456

@fcorrao น่าเสียดายที่ไม่ได้มีการกำหนดค่านี้ คุณต้องลองทำตามที่ Gerben แนะนำและใช้ MAC ACL หรือข้อเสนอแนะของ Dave ในการจับภาพการรับส่งข้อมูลจากพอร์ต แต่สิ่งที่ฉันทำก็คือมีเพียงอุปกรณ์ที่กำหนดค่าผิดพลาดเท่านั้นที่จะได้รับผลกระทบในทางลบดังนั้นพวกเขาจะทำให้เป็นที่รู้จักหรือไม่แม้แต่จะสังเกตเห็นตัวเอง

— YLearn

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

หลักสูตรที่ดีที่สุดของคุณอาจปล่อยให้สุนัขนอนหลับนี้นอนจนกว่าจะถึงเวลาที่ผู้ใช้บางคนรายงานปัญหา หรือถ้าคุณมีเวลาว่างคุณสามารถเรียกใช้เซสชัน SPAN ตามที่ @Daniel Dib แนะนำและให้การตรวจสอบผลลัพธ์อย่างใกล้ชิดจนกว่าคุณจะกำหนดพอร์ตหรืออุปกรณ์ที่ต้องสงสัย

— เดฟในโอไฮโอ
แหล่งที่มา