ARP ออกอากาศเครือข่ายที่มีน้ำท่วมและการใช้งาน cpu สูง

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

แม้ว่าชื่อเรื่องจะกล่าวถึงการออกอากาศ ARP และการใช้งาน CPU สูง แต่เราไม่แน่ใจว่าเกี่ยวข้องหรือไม่เกี่ยวข้องในขั้นตอนนี้

ปัญหาดั้งเดิมได้รับการโพสต์ในชุมชนออนไลน์ INE

เราถอดเครือข่ายออกเป็นลิงก์เดียวโดยไม่ต้องติดตั้งซ้ำซ้อนคิดว่าเป็นโครงสร้างแบบดาว

ข้อเท็จจริง:

• เราใช้สวิตช์ 3750x, 4 ในหนึ่งกอง รุ่น 15.0 (1) SE3 Cisco TAC ยืนยันว่าไม่มีปัญหาที่ทราบสำหรับ cpu หรือ ARP ที่มีข้อบกพร่องสูงสำหรับรุ่นนี้โดยเฉพาะ
• ไม่มีการเชื่อมต่อฮับ / สวิตช์ที่ไม่มีการจัดการ
• โหลดแกนสแต็กใหม่
• เราไม่มีเส้นทางเริ่มต้น "เส้นทาง IP 0.0.0.0 0.0.0.0 f1 / 0" ใช้ OSPF สำหรับการกำหนดเส้นทาง
• เราเห็นแพ็คเก็ตออกอากาศขนาดใหญ่จาก VLAN 1, VLAN 1 ที่ใช้สำหรับอุปกรณ์เดสก์ท็อป เราใช้ 192.168.0.0/20
• Cisco TAC กล่าวว่าพวกเขาไม่เห็นอะไรผิดปกติกับการใช้ / 20 แต่อย่างอื่นเรามีโดเมนออกอากาศจำนวนมาก แต่ยังคงทำงานได้
• อินเตอร์เน็ตไร้สายการจัดการเครื่องพิมพ์ ฯลฯ ล้วนแล้วแต่แตกต่างกันใน VLAN
• แผนผังสแปนนิ่งได้รับการยืนยันโดยบุคคลที่ผ่านการรับรองของ Cisco TAC & CCNP / CCIE เราปิดการเชื่อมโยงซ้ำซ้อนทั้งหมด
• การกำหนดค่าบนแกนได้รับการตรวจสอบแล้ว Cisco TAC
• เรามีการหมดเวลา ARP เริ่มต้นในสวิตช์ส่วนใหญ่
• เราไม่ได้ใช้คำถาม & คำตอบ
• ไม่มีการเพิ่มสวิตช์ใหม่ (อย่างน้อยเราก็ไม่รู้)
• ไม่สามารถใช้การตรวจสอบ arp แบบไดนามิกบนสวิตช์ขอบได้เนื่องจากนี่คือ 2950
• เราใช้อินเตอร์เฟสการแสดง | inc line | ออกอากาศเพื่อดูว่าการออกอากาศมาจากที่ไหนจำนวนมากอย่างไรก็ตามทั้ง Cisco TAC และวิศวกรอีก 2 คน (CCNP & CCIE) ยืนยันว่านี่เป็นพฤติกรรมปกติเนื่องจากสิ่งที่เกิดขึ้นบนเครือข่าย (เช่นใน mac flaps จำนวนมาก ทำให้การออกอากาศใหญ่ขึ้น) เราตรวจสอบว่า STP ทำงานอย่างถูกต้องบนสวิตช์ขอบ

อาการบนเครือข่ายและสวิตช์:

• อวัยวะเพศหญิง MAC จำนวนมาก
• การใช้งาน CPU สูงสำหรับกระบวนการอินพุต ARP
• แพ็คเก็ต ARP จำนวนมากเพิ่มขึ้นอย่างรวดเร็วและมองเห็นได้
• Wiresharks แสดงให้เห็นว่าคอมพิวเตอร์กว่าร้อยเครื่องกำลังโจมตีเครือข่ายด้วย ARP Broadcast
• เพื่อจุดประสงค์ในการทดสอบเราใส่เครื่องเดสก์ทอปประมาณ 80 เครื่องที่แตกต่างกัน vlan แต่เราทดสอบสิ่งนี้และไม่เห็นความแตกต่างกับ cpu หรือ arp input ที่สูง
• ใช้ AV / มัลแวร์ / สปายแวร์ต่างกัน แต่ไม่มีไวรัสปรากฏบนเครือข่าย
• การนับตารางที่อยู่ของ sh mac แสดงให้เราเห็นที่อยู่ mac ที่แตกต่างกันประมาณ 750 รายการตามที่คาดไว้ใน vlan 1

#sh processes cpu sorted | exc 0.00%
CPU utilization for five seconds: 99%/12%; one minute: 99%; five minutes: 99%

 PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process
  12   111438973    18587995       5995 44.47% 43.88% 43.96%   0 ARP Input
 174    59541847     5198737      11453 22.39% 23.47% 23.62%   0 Hulc LED Process
 221     7253246     6147816       1179  4.95%  4.25%  4.10%   0 IP Input
  86     5459437     1100349       4961  1.59%  1.47%  1.54%   0 RedEarth Tx Mana
  85     3448684     1453278       2373  1.27%  1.04%  1.07%   0 RedEarth I2C dri

• Ran show mac address-table บนสวิตช์ที่แตกต่างกันและแกนตัวเอง (บนแกนเช่นเสียบโดยตรงบนเดสก์ท็อป, เดสก์ท็อปของฉัน) และเราสามารถเห็นที่อยู่ฮาร์ดแวร์ MAC ที่แตกต่างกันหลายรายการที่ลงทะเบียนกับอินเตอร์เฟส มีคอมพิวเตอร์เพียงเครื่องเดียวที่เชื่อมต่อกับสิ่งนี้:

 Vlan    Mac Address       Type        Ports
 ----    -----------       --------    -----
    1    001c.c06c.d620    DYNAMIC     Gi1/1/3
    1    001c.c06c.d694    DYNAMIC     Gi1/1/3
    1    001c.c06c.d6ac    DYNAMIC     Gi1/1/3
    1    001c.c06c.d6e3    DYNAMIC     Gi1/1/3
    1    001c.c06c.d78c    DYNAMIC     Gi1/1/3
    1    001c.c06c.d7fc    DYNAMIC     Gi1/1/3

• แสดงการใช้ประโยชน์ tcam ของแพลตฟอร์ม

 CAM Utilization for ASIC# 0                      Max            Used
                                              Masks/Values    Masks/values

  Unicast mac addresses:                       6364/6364       1165/1165
  IPv4 IGMP groups + multicast routes:         1120/1120          1/1
  IPv4 unicast directly-connected routes:      6144/6144        524/524
  IPv4 unicast indirectly-connected routes:    2048/2048         77/77
  IPv4 policy based routing aces:               452/452          12/12
  IPv4 qos aces:                                512/512          21/21
  IPv4 security aces:                           964/964          45/45

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

ปรับปรุง

ขอขอบคุณ @MikePennington และ @RickyBeam สำหรับการตอบกลับอย่างละเอียด ฉันจะลองและตอบสิ่งที่ฉันทำได้

• ดังที่กล่าวไว้ 192.168.0.0/20 เป็นระเบียบ อย่างไรก็ตามเราตั้งใจที่จะแยกเรื่องนี้ออกในอนาคต แต่น่าเสียดายที่ปัญหานี้เกิดขึ้นก่อนที่เราจะทำสิ่งนี้ ฉันเองก็เห็นด้วยกับเสียงส่วนใหญ่ด้วยเหตุนี้โดเมนการออกอากาศใหญ่เกินไป
• การใช้ Arpwatch นั้นเป็นสิ่งที่เราสามารถลองได้ แต่ฉันสงสัยว่าเพราะพอร์ตการเข้าถึงหลายแห่งกำลังลงทะเบียนที่อยู่ mac แม้ว่ามันจะไม่ได้เป็นของพอร์ตนี้ก็ตามข้อสรุปของ arpwatch อาจไม่เป็นประโยชน์
• ฉันเห็นด้วยอย่างสมบูรณ์กับการไม่แน่ใจ 100% ว่าการค้นหาลิงก์ที่ซ้ำซ้อนและสวิตช์ที่ไม่รู้จักทั้งหมดบนเครือข่าย แต่สิ่งที่ดีที่สุดในการค้นหาของเรานี่คือกรณีนี้จนกว่าเราจะพบหลักฐานเพิ่มเติม
• การรักษาความปลอดภัยของพอร์ตได้รับการพิจารณา แต่น่าเสียดายที่ฝ่ายบริหารตัดสินใจที่จะไม่ใช้สิ่งนี้ด้วยเหตุผลหลายประการ เหตุผลทั่วไปคือเราย้ายคอมพิวเตอร์ไปรอบ ๆ (สภาพแวดล้อมของวิทยาลัย) อย่างต่อเนื่อง
• เราใช้ spanning-tree portfast ร่วมกับ spanning-tree bpduguard โดยปริยายบนพอร์ต access ทั้งหมด (เครื่องเดสก์ท็อป)
• เราไม่ได้ใช้ switchport nonnegotiate ในขณะนี้บนพอร์ตการเข้าถึง แต่เราไม่ได้รับการโจมตี Vlan กระโดดข้ามกระเด้งข้าม Vlans หลายรายการ
• จะแจ้งเตือนไปที่ mac-address-table และดูว่าเราสามารถหารูปแบบใด ๆ ได้หรือไม่

"เนื่องจากคุณได้รับ MAC จำนวนมากระหว่าง flapsport มันเป็นการยากที่จะค้นหาว่าผู้กระทำความผิดอยู่ที่ไหน (สมมติว่าคุณพบที่อยู่ mac สองหรือสามที่ส่ง arps จำนวนมาก

• เราเริ่มต้นด้วยการเลือก MAC flaps ใด ๆ และดำเนินการต่อผ่านสวิตช์หลักทั้งหมดไปยังสวิตช์การเข้าถึง แต่สิ่งที่เราพบคืออีกครั้งอินเตอร์เฟสพอร์ตการเข้าถึงกำลัง hogging ที่อยู่ของ mac หลายอันดังนั้น mac flaps กลับไปที่สี่เหลี่ยมจัตุรัส
• การควบคุมพายุเป็นสิ่งที่เราพิจารณา แต่เรากลัวว่าแพ็กเก็ตที่ถูกกฎหมายบางอย่างจะถูกทิ้งไว้ซึ่งจะทำให้เกิดปัญหาเพิ่มเติม
• จะสามตรวจสอบการกำหนดค่า VMHost
• @ytti ที่อยู่ MAC ที่อธิบายไม่ได้นั้นอยู่ด้านหลังพอร์ตการเข้าถึงจำนวนมาก ไม่พบลูปใด ๆ บนอินเทอร์เฟซเหล่านี้ ที่อยู่ MAC ยังมีอยู่ในส่วนต่อประสานอื่นซึ่งจะอธิบายถึงอวัยวะเพศหญิงของ MAC จำนวนมาก
• @ RickyBeam ฉันเห็นด้วยกับเหตุผลว่าทำไมโฮสต์กำลังส่งคำขอ ARP จำนวนมาก นี่เป็นหนึ่งในปัญหาที่ทำให้งง Rouge wireless bridge เป็นสิ่งที่น่าสนใจที่ฉันไม่เคยคิดมาก่อนว่าเราตระหนักดีว่า wireless นั้นอยู่บน VLAN ที่แตกต่างกัน แต่คนโกงจะเห็นได้ชัดว่ามันอาจจะเป็นใน VLAN1
• @ RickyBeam ฉันไม่ต้องการถอดปลั๊กทุกอย่างจริงๆเพราะจะทำให้การหยุดทำงานเป็นจำนวนมาก อย่างไรก็ตามนี่คือที่ที่มันอาจจะมุ่งหน้าไป เรามีเซิร์ฟเวอร์ Linux แต่ไม่เกิน 3 ตัว
• @RickyBeam คุณสามารถอธิบายเซิร์ฟเวอร์ DHCP "ใช้งานจริง" ได้หรือไม่

เรา (Cisco TAC, CCIEs, CCNP) ทั่วโลกยอมรับว่านี่ไม่ใช่การกำหนดค่าสวิตช์ แต่โฮสต์ / อุปกรณ์ทำให้เกิดปัญหา

แก้ไข

ปัญหาคือมี SCCM SP1 2012, บริการที่เรียกว่า: ConfigMrg ปลุกพร็อกซี่ 'คุณสมบัติ' ไม่ได้อยู่ใน SCM 2012 RTM

ภายใน 4 ชั่วโมงหลังจากปิดสิ่งนี้ภายในนโยบายเราเห็นการใช้ CPU ลดลงอย่างต่อเนื่อง เมื่อเวลาผ่านไป 4 ชั่วโมงการใช้ ARP เพียง 1-2%!

โดยสรุปบริการนี้ทำการปลอมแปลงที่อยู่ MAC! ไม่สามารถเชื่อได้ว่ามันเกิดความเสียหายได้มากแค่ไหน

ด้านล่างเป็นข้อความเต็มจาก Microsoft Technet เนื่องจากฉันรู้สึกว่าเป็นเรื่องสำคัญที่จะต้องเข้าใจว่าสิ่งนี้เกี่ยวข้องกับปัญหาที่โพสต์ได้อย่างไร

สำหรับผู้ที่สนใจด้านล่างนี้คือรายละเอียดทางเทคนิค

เครื่องมือจัดการการกำหนดค่ารองรับเทคโนโลยีเครือข่ายท้องถิ่น (LAN) สองตัวเพื่อปลุกคอมพิวเตอร์ในโหมดสลีปเมื่อคุณต้องการติดตั้งซอฟต์แวร์ที่จำเป็นเช่นการอัปเดตซอฟต์แวร์และแอพพลิเคชั่น: แพ็คเก็ตปลุกแบบดั้งเดิมและคำสั่งเปิดเครื่อง AMT

เริ่มต้นด้วย Configuration Manager SP1 คุณสามารถเสริมวิธีการแพคเก็ตการปลุกแบบเดิมโดยใช้การตั้งค่าพร็อกซีไคลเอ็นต์การปลุก พร็อกซี Wake-up ใช้โปรโตคอลแบบ peer-to-peer และคอมพิวเตอร์ที่ได้รับการแต่งตั้งเพื่อตรวจสอบว่าคอมพิวเตอร์เครื่องอื่น ๆ ในเครือข่ายย่อยนั้นตื่นหรือไม่และจะปลุกพวกเขาหากจำเป็น เมื่อไซต์ถูกกำหนดค่าสำหรับ Wake On LAN และไคลเอนต์ได้รับการกำหนดค่าสำหรับพร็อกซีการปลุกกระบวนการทำงานดังนี้:

1. คอมพิวเตอร์ที่ติดตั้งไคลเอนต์ตัวจัดการการกำหนดค่า SP1 ติดตั้งและไม่ได้หลับบนเครือข่ายย่อยตรวจสอบว่าคอมพิวเตอร์เครื่องอื่น ๆ ในเครือข่ายย่อยนั้นตื่นหรือไม่ พวกเขาทำได้โดยส่งคำสั่ง ping TCP / IP ซึ่งกันและกันทุก 5 วินาที

2. หากไม่มีการตอบสนองจากคอมพิวเตอร์เครื่องอื่น ๆ พวกเขาจะถือว่าเป็นหลับ คอมพิวเตอร์ที่ตื่นขึ้นมาจะกลายเป็นคอมพิวเตอร์ผู้จัดการสำหรับซับเน็ต

3. เนื่องจากเป็นไปได้ว่าคอมพิวเตอร์อาจไม่ตอบสนองเนื่องจากสาเหตุอื่นที่ไม่ใช่หลับ (ตัวอย่างเช่นปิดเครื่องลบออกจากเครือข่ายหรือไม่ได้ใช้การตั้งค่าไคลเอ็นต์การปลุกพร็อกซี) คอมพิวเตอร์จะไม่ทำงานอีกต่อไป ส่งแพ็คเก็ตปลุกทุกวันเวลา 14.00 น. ตามเวลาท้องถิ่น คอมพิวเตอร์ที่ไม่ตอบสนองจะไม่ถูกสันนิษฐานว่าเป็นหลับอีกต่อไปและจะไม่ถูกปลุกให้ตื่นด้วยการปลุก

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

คอมพิวเตอร์ของผู้จัดการขอให้สวิตช์เครือข่ายเปลี่ยนเส้นทางการรับส่งข้อมูลของเครือข่ายเพื่อให้คอมพิวเตอร์หลับนอนด้วยตนเอง

การเปลี่ยนเส้นทางทำได้โดยคอมพิวเตอร์ผู้จัดการกระจายสัญญาณเฟรม Ethernet ที่ใช้ที่อยู่ MAC ของคอมพิวเตอร์ที่กำลังหลับอยู่เป็นที่อยู่ต้นทาง สิ่งนี้ทำให้สวิตช์เครือข่ายทำงานเหมือนกับว่าคอมพิวเตอร์หลับได้ย้ายไปยังพอร์ตเดียวกับที่คอมพิวเตอร์จัดการเปิดอยู่ คอมพิวเตอร์ผู้จัดการยังส่งแพ็คเก็ต ARP สำหรับคอมพิวเตอร์ที่หลับเพื่อให้รายการใหม่ในแคช ARP คอมพิวเตอร์ผู้จัดการจะตอบกลับคำขอ ARP ในนามของคอมพิวเตอร์ sleep และตอบกลับด้วยที่อยู่ MAC ของคอมพิวเตอร์ sleep

ในระหว่างกระบวนการนี้การแมป IP กับ MAC สำหรับคอมพิวเตอร์สลีปจะยังคงเหมือนเดิม Wake-up proxy ทำงานโดยแจ้งสวิตช์เครือข่ายว่าอะแดปเตอร์เครือข่ายอื่นกำลังใช้พอร์ตที่ลงทะเบียนโดยอะแดปเตอร์เครือข่ายอื่น อย่างไรก็ตามพฤติกรรมนี้เรียกว่าพนัง MAC และไม่ปกติสำหรับการดำเนินการเครือข่ายมาตรฐาน เครื่องมือตรวจสอบเครือข่ายบางตัวค้นหาลักษณะการทำงานนี้และสามารถสันนิษฐานได้ว่ามีบางอย่างผิดปกติ ดังนั้นเครื่องมือตรวจสอบเหล่านี้สามารถสร้างการแจ้งเตือนหรือปิดพอร์ตเมื่อคุณใช้ proxy-up proxy อย่าใช้พร็อกซีการปลุกหากเครื่องมือและบริการตรวจสอบเครือข่ายของคุณไม่อนุญาตให้ใช้ลิ้นอากาศ MAC

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

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

Ref: http://technet.microsoft.com/en-us/library/dd8eb74e-3490-446e-b328-e67f3e85c779#BKMK_PlanToWakeClients

ขอบคุณสำหรับทุกคนที่โพสต์ที่นี่และให้ความช่วยเหลือในกระบวนการแก้ไขปัญหาชื่นชมมาก

พายุ ARP / Broadcast

• เราเห็นแพ็คเก็ตออกอากาศขนาดใหญ่จาก VLAN 1, VLAN 1 ที่ใช้สำหรับอุปกรณ์เดสก์ท็อป เราใช้ 192.168.0.0/20 ...
• Wiresharks แสดงให้เห็นว่าคอมพิวเตอร์กว่าร้อยเครื่องกำลังประสบปัญหาเครือข่ายด้วย ARP Broadcast ...

กระบวนการป้อนข้อมูล ARP ของคุณอยู่ในระดับสูงซึ่งหมายความว่าสวิตช์ใช้เวลาในการประมวลผล ARP เป็นจำนวนมาก สาเหตุที่พบบ่อยมากอย่างหนึ่งของการเกิดน้ำท่วม ARP คือการวนซ้ำระหว่างสวิตช์ของคุณ หากคุณมีการวนซ้ำคุณสามารถรับ mac flaps ที่คุณกล่าวถึงข้างต้นได้ สาเหตุที่เป็นไปได้อื่น ๆ ของน้ำท่วม ARP คือ:

• การกำหนดค่าที่อยู่ IP ผิดพลาด
• การโจมตี layer2 เช่นarp spoofing

ก่อนกำจัดความเป็นไปได้ของการกำหนดค่าผิดพลาดหรือการโจมตีเลเยอร์ 2 ที่กล่าวถึงข้างต้น วิธีที่ง่ายที่สุดคือการใช้arpwatchบนเครื่อง linux (แม้ว่าคุณจะต้องใช้livecdบนแล็ปท็อป) หากคุณมีการกำหนดค่าที่ผิดพลาดหรือการโจมตีเลเยอร์ 2 ดังนั้น arpwatch จะให้ข้อความเช่นนี้ใน syslog ซึ่งจะแสดงรายการที่อยู่ Mac ที่กำลังต่อสู้กับที่อยู่ IP เดียวกัน ...
Oct 20 10:31:13 tsunami arpwatch: flip flop 192.0.2.53 00:de:ad:85:85:ca (00:de:ad:3:d8:8e)

เมื่อคุณเห็น "flip flops" คุณจะต้องติดตามที่มาของที่อยู่ mac และหาสาเหตุที่พวกเขาต่อสู้กับ IP เดียวกัน

• อวัยวะเพศหญิง MAC จำนวนมาก
• แผนผังสแปนนิ่งได้รับการยืนยันโดยบุคคลที่ผ่านการรับรองของ Cisco TAC & CCNP / CCIE เราปิดการเชื่อมโยงซ้ำซ้อนทั้งหมด

การพูดในฐานะคนที่ผ่านช่วงเวลานี้มานานกว่าที่ฉันต้องการเรียกคืนอย่าคิดว่าคุณพบลิงก์ที่ซ้ำซ้อนทั้งหมด ... เพียงแค่ทำให้ switchports ของคุณมีพฤติกรรมอยู่ตลอดเวลา

เนื่องจากคุณได้รับ mac flaps จำนวนมากระหว่าง switchport มันยากที่จะค้นหาว่าผู้กระทำความผิดอยู่ที่ไหน (สมมติว่าคุณพบที่อยู่ mac สองหรือสามที่ส่ง arps จำนวนมาก แต่ที่อยู่ mac ต้นทางจะกระเพื่อมระหว่างพอร์ต) หากคุณไม่ได้บังคับใช้ขีด จำกัด อย่างหนักในที่อยู่ mac ต่อพอร์ต Edge มันเป็นเรื่องยากมากที่จะติดตามปัญหาเหล่านี้โดยไม่ต้องถอดสายเคเบิลด้วยตนเอง (ซึ่งเป็นสิ่งที่คุณต้องการหลีกเลี่ยง) สวิตช์แบบวนซ้ำทำให้เกิดเส้นทางที่ไม่คาดคิดในเครือข่ายและคุณสามารถปิดท้ายด้วย mac หลายร้อยเครื่องที่เรียนรู้เป็นระยะ ๆ จากสิ่งที่ควรจะเป็นสวิตช์พอร์ตของเดสก์ท็อป

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

switchport mode access
switchport access vlan 1
!! switchport nonegotiate disables some Vlan-hopping attacks via Vlan1 -> another Vlan
switchport nonnegotiate
!! If no IP Phones are connected to your switches, then you could lower this
!!   Beware of people with VMWare / hubs under their desk, because 
!!   "maximum 3" could shutdown their ports if they have more than 3 macs
switchport port-security maximum 3
switchport port-security violation shutdown
switchport port-security aging time 5
switchport port-security aging type inactivity
switchport port-security
spanning-tree portfast
!! Ensure you don't have hidden STP loops because someone secretly cross-connected a 
!!   couple of desktop ports
spanning-tree bpduguard enable

ในกรณีที่เกิดเหตุการณ์น้ำท่วม mac / ARP ส่วนใหญ่การใช้การกำหนดค่านี้กับพอร์ตสวิตช์ขอบทั้งหมดของคุณ (โดยเฉพาะอย่างยิ่งพอร์ตพอร์ต) จะทำให้คุณกลับสู่สถานะมีสติเนื่องจากการกำหนดค่าจะปิดพอร์ตใด ๆ ที่เกินสามที่อยู่ mac พอร์ตพอร์ตแบบคล้องพอร์ต Macs สามตัวต่อพอร์ตเป็นตัวเลขที่ทำงานได้ดีในสภาพแวดล้อมเดสก์ท็อปของฉัน แต่คุณสามารถเพิ่มได้ถึง 10 และอาจใช้ได้ หลังจากที่คุณทำสิ่งนี้แล้วเลเยอร์ 2 ใด ๆ ที่ขาดหายไปอวัยวะเพศหญิงแม็คเร็วจะหยุดและทำให้การวินิจฉัยง่ายขึ้นมาก

อีกสองคำสั่งทั่วโลกที่มีประโยชน์สำหรับการติดตามพอร์ตที่เกี่ยวข้องกับการออกอากาศพายุ (mac-move) และน้ำท่วม (เกณฑ์) ...

mac-address-table notification mac-move
mac address-table notification threshold limit 90 interval 900

หลังจากเสร็จสิ้นคุณสามารถเลือกที่clear mac address-tableจะเร่งการรักษาจากตาราง CAM แบบเต็ม

• Ran show mac address-table บนสวิตช์ที่แตกต่างกันและแกนตัวเอง (บนแกนเช่นเสียบโดยตรงบนเดสก์ท็อป, เดสก์ท็อปของฉัน), และเราสามารถเห็นที่อยู่ฮาร์ดแวร์ MAC ที่แตกต่างกันหลายอัน มีคอมพิวเตอร์เพียงเครื่องเดียวที่เชื่อมต่อกับ ...

คำตอบทั้งหมดนี้ถือว่า 3750 ของคุณไม่มีข้อผิดพลาดที่ทำให้เกิดปัญหา (แต่คุณบอกว่า wireshark ระบุว่าพีซีที่กำลังท่วม) สิ่งที่คุณแสดงให้เราเห็นนั้นผิดอย่างชัดเจนเมื่อมีคอมพิวเตอร์เพียงเครื่องเดียวเชื่อมต่อกับ Gi1 / 1/3 ยกเว้นว่าพีซีนั้นมีบางอย่างเช่น VMWare อยู่

ความคิดอื่น ๆ

จากการสนทนาที่เรามีฉันอาจไม่ต้องพูดถึงสิ่งที่ชัดเจน แต่ฉันจะทำเพื่อผู้เข้าชมในอนาคต ...

• การใส่ผู้ใช้ใน Vlan1 เป็นความคิดที่ไม่ดี (ฉันเข้าใจว่าคุณอาจได้รับสิ่งที่ไม่ดี)
• ไม่ว่า TAC จะบอกอะไรกับคุณ 192.168.0.0/20 มีขนาดใหญ่เกินไปที่จะจัดการในโดเมนที่มีการสับเปลี่ยนครั้งเดียวโดยไม่มีความเสี่ยงจากการโจมตีของเลเยอร์ 2 ยิ่งซับเน็ตมาสก์ของคุณใหญ่ขึ้นเท่าไรคุณก็จะได้รับการโจมตีจากเลเยอร์ 2 มากขึ้นเนื่องจาก ARP เป็นโปรโตคอลที่ไม่ได้รับการตรวจสอบสิทธิ์และอย่างน้อยเราเตอร์จะต้องอ่าน ARP ที่ถูกต้องจากเครือข่ายย่อยนั้น
• การควบคุมสตอร์มบนพอร์ตเลเยอร์ 2 มักเป็นความคิดที่ดีเช่นกัน อย่างไรก็ตามการเปิดใช้งานการควบคุมพายุในสถานการณ์เช่นนี้จะทำให้การจราจรที่ดีกับการจราจรที่ไม่ดี หลังจากที่เครือข่ายได้รับการรักษาให้ใช้นโยบายการควบคุมพายุบนพอร์ตขอบและอัปลิงค์ของคุณ

คำถามที่แท้จริงคือทำไมโฮสต์จึงส่ง ARP จำนวนมากตั้งแต่แรก จนกว่าจะตอบคำถามนี้สวิตช์จะยังคงมีปัญหากับพายุ arp ต่อไป Netmask ไม่ตรงกัน? ตัวนับ arp ต่ำของโฮสต์? โฮสต์หนึ่ง (ขึ้นไป) ที่มีเส้นทาง "อินเทอร์เฟซ" หรือไม่ สะพานไร้สายสีแดง "arp ฟรี" หายไปบ้า? การตรวจสอบเซิร์ฟเวอร์ DHCP "ใช้งานอยู่" ดูเหมือนว่าจะไม่มีปัญหากับสวิตช์หรือเลเยอร์ 2 คุณมีโฮสต์ที่ทำสิ่งไม่ดี

กระบวนการแก้จุดบกพร่องของฉันจะถอดปลั๊กทุกอย่างและเฝ้าดูอย่างใกล้ชิดเนื่องจากมีการเชื่อมต่อใหม่อีกครั้งหนึ่งพอร์ต (ฉันรู้ว่ามันห่างไกลจากอุดมคติ แต่ในบางจุดคุณต้องลดความสูญเสียและพยายามแยกแหล่งที่เป็นไปได้ทางร่างกาย) จากนั้นฉันจะพยายามทำความเข้าใจว่าเพราะเหตุใดพอร์ตที่เลือกจึงสร้าง arp จำนวนมาก

(โฮสต์จำนวนมากเหล่านี้จะเป็นระบบ linux หรือไม่ Linux มีระบบจัดการแคช ARP ที่โง่มากความจริงที่ว่า "จะตรวจสอบอีกครั้ง" รายการในเวลาไม่กี่นาทีจะแตกในหนังสือของฉัน มีแนวโน้มที่จะมีปัญหาน้อยกว่าในเครือข่ายขนาดเล็ก แต่ / 20 ไม่ใช่เครือข่ายขนาดเล็ก)

สิ่งนี้อาจหรืออาจจะไม่เกี่ยวข้องกับปัญหาของคุณในมือ แต่ฉันคิดว่ามันอาจเป็นสิ่งที่มีค่าอย่างน้อยโยนออกไปที่นั่น:

ขณะนี้เรามีบางส่วนของ 3750x ที่ซ้อนกันในบางไซต์ระยะไกลของเราส่วนใหญ่ใช้งาน 15.0.2 (SE0 ถึง 4 มีข้อบกพร่อง FRU บางอย่างที่มี SE0 ที่ฉันย้ายออกจากช้า)

ในระหว่างการอัพเดท iOS ตามปกติเริ่มจาก 15.0.2 ถึง 15.2-1 (SE ล่าสุด) เราสังเกตเห็นว่าการเพิ่มขึ้นของซีพียูค่อนข้างสำคัญจากค่าเฉลี่ยประมาณ 30% ถึง 60% และสูงกว่าในช่วงนอกช่วงเวลาเร่งด่วน ฉันได้ตรวจสอบการกำหนดค่าและบันทึกการเปลี่ยนแปลง IOS และทำงานกับ TAC ของ Cisco จากข้อมูลของ TAC ดูเหมือนว่าพวกเขาเชื่อว่านี่เป็นข้อผิดพลาดของ IOS 15.2-1

ขณะที่เราตรวจสอบการเพิ่มขึ้นของ CPU อย่างต่อเนื่องเราเริ่มเห็นปริมาณการรับส่งข้อมูล ARP จำนวนมากจนถึงจุดที่ตาราง ARP ของเราเต็มไปอย่างสมบูรณ์และก่อให้เกิดความไม่เสถียรของเครือข่าย crutch ชั่วคราวสำหรับสิ่งนี้คือการสำรอง ARP timeouts ของเราด้วยตนเองจากค่าเริ่มต้น (14400) ถึง 300 บน vlans เสียงและข้อมูลของเรา

หลังจากลดการหมดเวลา ARP ของเราเรามีเสถียรภาพเป็นเวลาหนึ่งสัปดาห์หรือมากกว่านั้น ณ จุดที่เรากลับสู่ IOS 15.0.2-SE4 และลบการหมดเวลา ARP ที่ไม่ใช่ค่าเริ่มต้นของเรา การใช้งาน CPU ของเรานั้นลดลงเหลือ ~ 30% และปัญหาตาราง ARP ของเรานั้นไม่มีอยู่จริง

คนเรียบง่าย แต่ดูอ่อนไหว ทำลูกค้าของคุณมีเกตเวย์เริ่มต้นที่ถูกต้องไม่ได้เป็นคุณหลักทำ arps พร็อกซี่จำนวนมาก คุณสามารถพิจารณาที่จะลบล้างฟังก์ชั่น ip proxy arp ใน 3750 ของคุณ?