จะเกิดอะไรขึ้นเมื่อแคช ARP โอเวอร์โฟลว์?

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

ยกตัวอย่างเช่นผ้า NetIron XMR และ Brocade MLX เราเตอร์มีการกำหนดค่าip-arpสูงสุดของระบบ ค่าเริ่มต้นในกรณีนั้นคือ 8192; ขนาดของ a / 19 subnet ไม่ชัดเจนจากเอกสารประกอบไม่ว่าจะเป็นแบบต่ออินเตอร์เฟสหรือสำหรับเราเตอร์ทั้งหมด แต่เพื่อจุดประสงค์ของคำถามนี้เราสามารถสันนิษฐานได้ว่าเป็นแบบต่ออินเตอร์เฟส

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

+----+ iface0    +----+
| R1 |-----------| R2 |---> (10.1.0.0/16 this way)
+----+.1       .2+----+
      10.0.0.0/30

ก่อนการโยกย้าย R1 เป็น Cisco และมีเส้นทางต่อไปนี้

ip route 10.1.0.0 255.255.0.0 iface0 10.0.0.2

หลังจากการโยกย้าย R1 เป็นผ้าและมีเส้นทางต่อไปนี้

ip route 10.1.0.0 255.255.0.0 iface0

R2 เป็นเราเตอร์ของซิสโก้และเราเตอร์ของซิสโก้ดำเนินการproxy ARPตามค่าเริ่มต้น นี่คือการกำหนดค่า (mis-) ในการผลิตที่ตั้งค่าระยะสำหรับสิ่งที่กลายเป็น ARP cache overflow

1. R1 ได้รับแพ็กเก็ตปลายทางสำหรับเครือข่าย 10.1.0.0/16
2. บนพื้นฐานของเส้นทางอินเตอร์เฟสแบบคงที่ R1 ARPs สำหรับปลายทางบน iface0
3. R2 รับรู้ว่ามันสามารถเข้าถึงปลายทางและตอบสนองต่อ ARP ด้วย MAC ของตัวเอง
4. R1 แคชผลลัพธ์ ARP ที่รวม IP ในเครือข่ายระยะไกลกับ MAC ของ R2

สิ่งนี้เกิดขึ้นสำหรับทุกจุดหมายปลายทางที่แตกต่างใน 10.1.0.0/16 ดังนั้นแม้ว่า / 16 จะถูกย่อยอย่างเหมาะสมเกินกว่า R2 และมีเพียงสองโหนดในลิงค์ที่อยู่ติดกับ R1 และ R2 แต่ R1 นั้นมีปัญหา ARP cache overload เพราะมันทำให้ R2 ทำงานเหมือนว่าที่อยู่ 65k ทั้งหมดนั้นเชื่อมต่อโดยตรง

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

แก้ไข 1เพื่อความชัดเจนฉันถามเกี่ยวกับส่วนหนึ่งของเลเยอร์กาวระหว่างดาต้าลิงค์ (เลเยอร์ 2) และเครือข่าย (เลเยอร์ 3) ไม่ใช่ตารางฟอร์เวิร์ด MAC ภายในดาต้าลิงค์เลเยอร์ โฮสต์หรือเราเตอร์สร้างที่อยู่เดิมเพื่อจับคู่ที่อยู่ IP กับที่อยู่ MAC ในขณะที่สวิตช์จะสร้างที่อยู่หลังเพื่อจับคู่ที่อยู่ MAC กับพอร์ต

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

แก้ไข 3คำถามอื่นที่ไม่ใช่ "ฉันจะป้องกัน ARP cache ไม่ให้ล้นได้อย่างไร"

แก้ไข 2 :

ตามที่คุณพูดถึง ...

ip route 10.1.0.0 255.255.0.0 iface0

กองกำลังของโบรเคดพร็อกซี-ARP สำหรับปลายทางใน 10.1.0.0/16 iface0ทุกราวกับว่ามันถูกเชื่อมต่อโดยตรงกับ

ฉันไม่สามารถตอบสนองเกี่ยวกับการใช้แคช ARP ของ Brocade ได้ แต่ฉันจะชี้ให้เห็นวิธีแก้ปัญหาที่ง่ายสำหรับคุณ ... กำหนดค่าเส้นทางของคุณแตกต่างกัน:

ip route 10.1.0.0 255.255.0.0 CiscoNextHopIP

ด้วยการทำเช่นนี้คุณจะป้องกันโบรเคดจาก ARP-ing สำหรับ 10.1.0.0/16 ทั้งหมด (หมายเหตุคุณอาจต้องกำหนดหมายเลขลิงก์ระหว่าง R1 และ R2 ใหม่ให้อยู่นอก 10.1.0.0/16 ทั้งนี้ขึ้นอยู่กับการใช้งานของโบรเคด) .

คำตอบเดิม :

ฉันคาดหวังว่าในการใช้งานส่วนใหญ่หรือทั้งหมดมีข้อ จำกัด อย่างหนักเกี่ยวกับความสามารถของตาราง ARP

เราเตอร์ Cisco IOS ของ Cisco จะถูก จำกัด ด้วยจำนวน DRAM ในเราเตอร์ แต่โดยทั่วไปจะไม่เป็นปัจจัย จำกัด สวิตช์บางตัว (เช่น Catalyst 6500) มีข้อ จำกัด อย่างหนักในตาราง adjacency (ซึ่งสัมพันธ์กับตาราง ARP) Sup2T มี 1 ล้าน adjacencies

ดังนั้นจะเกิดอะไรขึ้นเมื่อแคช ARP เต็มและแพ็กเก็ตจะถูกนำเสนอด้วยปลายทาง (หรือถัดไปฮอป) ที่ไม่ได้แคช

เราเตอร์ซีพียู Cisco IOS ไม่หมดพื้นที่ในตาราง ARP เนื่องจาก ARP เหล่านั้นถูกเก็บไว้ใน DRAM สมมติว่าคุณกำลังพูดถึง Sup2T คิดว่ามันเป็นอย่างนี้สมมติว่าคุณมี Cat6500 + Sup2T และคุณได้กำหนดค่า Vlans ทั้งหมดที่เป็นไปได้ทางเทคนิคนั่นคือ

4094 total Vlans - Vlan1002 - Vlan1003 - Vlan1004 - Vlan1005 = 4090 Vlans

สมมติว่าคุณทำ Vlan แต่ละอันด้วย / 24 (นั่นคือ 252 ARP ที่เป็นไปได้) และคุณแพ็ค Vlan ทุกตัวให้เต็ม ... นั่นคือ 1 ล้าน ARP รายการ

4094 * 252 = 1,030,680 ARP Entries

หนึ่งใน ARP เหล่านั้นจะใช้หน่วยความจำจำนวนหนึ่งในตาราง ARP เองรวมทั้งตาราง adjacency ของ IOS ฉันไม่รู้ว่ามันคืออะไร แต่สมมุติว่าค่าใช้จ่าย ARP ทั้งหมดคือ 10 ไบต์ ...

นั่นหมายความว่าคุณได้ใช้ 10MB สำหรับค่าใช้จ่าย ARP แล้ว ก็ยังคงเป็นพื้นที่ไม่มาก ... %SYS-2-MALLOCFAILถ้าคุณอยู่ในระดับต่ำในหน่วยความจำที่คุณจะเห็นสิ่งที่ต้องการ

ด้วย ARP จำนวนมากและการหมดเวลา ARP สี่ชั่วโมงคุณจะต้องให้บริการโดยเฉลี่ย 70 ARP ต่อวินาทีโดยเฉลี่ย มีโอกาสมากที่การบำรุงรักษารายการ ARP 1 ล้านรายการจะทำให้ CPU ของเราเตอร์หมดไป (อาจเป็นข้อความ CPUHOG)

ณ จุดนี้คุณสามารถเริ่มตีกลับการกำหนดเส้นทาง adjacencies และมี IP ที่ไม่สามารถเข้าถึงได้เนื่องจากเราเตอร์ CPU ไม่ว่างที่จะ ARP สำหรับ IP

เฉพาะประสบการณ์จริงที่ฉันมีกับสิ่งนี้เกิดขึ้นกับสวิตช์ C3550 (ขีด จำกัด MAC 2-8k ขึ้นอยู่กับเทมเพลต sdm) และมันทำให้รายการที่เก่าที่สุดออกมาจากตาราง

สำหรับ IOS และ JunOS และกองการค้าอื่น ๆ ที่คุณต้องทดสอบมันไม่ได้โชคดีมาก

แต่สำหรับlinux , freebsd, netbsd, openbsd, uIP, lwIP และการใช้งานอื่น ๆ มากมายคุณสามารถตรวจสอบซอร์สโค้ดของพวกเขาสำหรับพฤติกรรม

ใน Linux คุณต้องตรวจสอบ 'net / core / neighbour.c' (เริ่มด้วยบรรทัด 'if (รายการ> = tbl-> gc_thresh3' | | '') และ 'net / ipv4 / arp.c'
ใน Linux คุณดูเหมือนจะ มีสามระดับเต็ม

1. gc_thresh1 - ไม่มีการดำเนินการใด ๆ จนกว่าจะมีการโจมตี
2. gc_thresh2 - สามารถถูกโจมตีได้ในไม่ช้า
3. gc_thresh3 - ต้องไม่เกินขนาดนี้

เมื่อ gc_thresh3 พยายามเกินกว่านั้นจะพยายามบังคับให้มีการเรียกใช้การรวบรวมขยะยกเว้นว่าจะมีการเรียกใช้ไปแล้วเมื่อเร็ว ๆ นี้ การรวบรวมขยะดูเหมือนจะลบรายการที่ไม่ได้อ้างถึงอีกต่อไปดังนั้นจึงไม่ได้หมายถึงเก่าที่สุดหรือใหม่ที่สุด แต่เกินกว่า gc_staletime ดูเหมือนจะเป็นวิธีหนึ่งในการยกเลิกการลงทะเบียนซึ่งแปลเป็นรายการที่เก่าที่สุดอีกครั้ง
หากไม่สามารถรันการรวบรวมขยะรายการใหม่จะไม่ถูกเพิ่ม gc_threshN และช่วงเวลารวบรวมขยะเหล่านี้ทั้งหมดสามารถปรับได้
รหัสคือตระกูลที่อยู่ (ipv4, ipv6) ไม่เชื่อเรื่องพระเจ้าดังนั้นตาราง IPv6 ND และ IPv4 ARP จะได้รับการจัดการโดยรหัสเส้นทางเดียวกันแน่นอนไม่ใช่เส้นทางที่ซ้ำกัน

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

สวิตช์จะไปที่ ARP สำหรับ IP ปลายทางนั้นเพื่อรับที่อยู่ MAC (ซึ่งจะเติมตาราง CAM พร้อมการตอบกลับด้วย) คำขอ ARP นั้นออกอากาศไปยังพอร์ตทั้งหมด สิ่งนี้ต้องใช้ CPU และเกี่ยวข้องกับARP Inputกระบวนการ หาก ARP ร้องขอสำหรับ IP เดียวกันเนื่องจากตาราง ARP ล้นบ่อยสวิตช์ควร จำกัด อัตรา ARP ไว้ที่หนึ่งครั้งทุกๆสองวินาที หากคำขอนั้นมีการสุ่ม IP บ่อยพอ CPU อาจขัดขวางเนื่องจาก CPU นั้นเกี่ยวข้องกับทั้งคำขอ ARP และการตอบกลับ

จากการโจมตีที่ฉันเรียนรู้จากสวิตช์ Cisco 3550, 3560 และอื่น ๆ คุณสามารถเปลี่ยนให้กลายเป็นฮับยักษ์ได้เมื่อคุณโอเวอร์โหลดขีด จำกัด ที่อยู่ MAC สวิตช์มีขีด จำกัด ที่ตั้งของที่อยู่ MAC (ประมาณ 6,000) ที่สามารถจัดเก็บได้และเมื่อถึงขีด จำกัด นั้นจะทำให้ข้อมูลทั้งหมดออกจากอินเตอร์เฟส จำไม่ได้ว่าเป็นไปสำหรับแพ็คเก็ต 802.1q หรือไม่เพราะฉันไม่ต้องทำนาน อาจต้องลุกไหม้ห้องปฏิบัติการเครือข่ายของฉันที่บ้านเพื่อค้นหา