อะไรเป็นสาเหตุทำให้ผลผลิตรวมลดลงในส่วนต่อประสานสวิตช์ของซิสโก้?


16

ฉันมีแชสซีเบลด HP c7000 ซึ่งมีสวิตช์ Cisco 3120X และสวิตช์ Cisco 3120G ที่ใช้ ios 12.2 (58) SE1 เบลดตัวเองนั้นเบาบางมาก แต่อินเตอร์เฟสจำนวนมากบนสวิตช์สวิตช์ที่แตกต่างกันในแชสซีแสดงจำนวนเอาต์พุตที่ค่อนข้างสูง ถ้าฉันตรวจสอบจำนวนเอาต์พุตลดลงซ้ำ ๆ ฉันไม่เพียงเห็นตัวนับเพิ่มขึ้น แต่บางครั้งก็ลด ตัวเลขไม่สัมพันธ์กับแพ็กเก็ต / s ที่บันทึกบนอินเทอร์เฟซ การตั้งค่า QoS เป็นค่าเริ่มต้นสำหรับแพลตฟอร์ม

ตัวอย่างต่อไปนี้ถ่ายในช่วงเวลา 30 วินาที:

bc1019-3120-stack> sh int gi2 / 0/7 | ฉันส่งออกลดลง
  อินพุตคิว: 0/75/0/0 (ขนาด / สูงสุด / หยด / ฟลัช); การส่งออกรวมลดลง: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | ฉันส่งออกลดลง
  อินพุตคิว: 0/75/0/0 (ขนาด / สูงสุด / หยด / ฟลัช); การส่งออกรวมลดลง: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | ฉันส่งออกลดลง
  อินพุตคิว: 0/75/0/0 (ขนาด / สูงสุด / หยด / ฟลัช); การส่งออกรวมลดลง: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | ฉันส่งออกลดลง
  อินพุตคิว: 0/75/0/0 (ขนาด / สูงสุด / หยด / ฟลัช); การส่งออกรวมลดลง: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | ฉันส่งออกลดลง
  อินพุตคิว: 0/75/0/0 (ขนาด / สูงสุด / หยด / ฟลัช); การส่งออกรวมลดลง: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | ฉันส่งออกลดลง
  อินพุตคิว: 0/75/0/0 (ขนาด / สูงสุด / หยด / ฟลัช); การส่งออกรวมลดลง: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | ฉันส่งออกลดลง
  อินพุตคิว: 0/75/0/0 (ขนาด / สูงสุด / หยด / ฟลัช); การส่งออกลดลงทั้งหมด: 451110
bc1019-3120-stack> sh int gi2 / 0/7 | ฉันส่งออกลดลง
  อินพุตคิว: 0/75/0/0 (ขนาด / สูงสุด / หยด / ฟลัช); การส่งออกลดลงทั้งหมด: 451110
bc1019-3120-stack> sh int gi2 / 0/7 | ฉันส่งออกลดลง
  อินพุตคิว: 0/75/0/0 (ขนาด / สูงสุด / หยด / ฟลัช); การส่งออกลดลงทั้งหมด: 902220
bc1019-3120-stack> sh int gi2 / 0/7 | ฉันส่งออกลดลง
  อินพุตคิว: 0/75/0/0 (ขนาด / สูงสุด / หยด / ฟลัช); การส่งออกลดลงทั้งหมด: 1353330
bc1019-3120-stack> sh int gi2 / 0/7 | ฉันส่งออกลดลง
  อินพุตคิว: 0/75/0/0 (ขนาด / สูงสุด / หยด / ฟลัช); เอาท์พุทรวมลดลง: 1804440
bc1019-3120-stack> sh int gi2 / 0/7 | ฉันส่งออกลดลง
  อินพุตคิว: 0/75/0/0 (ขนาด / สูงสุด / หยด / ฟลัช); เอาท์พุทรวมลดลง: 1804440
bc1019-3120-stack> sh int gi2 / 0/7 | ฉันส่งออกลดลง
  อินพุตคิว: 0/75/0/0 (ขนาด / สูงสุด / หยด / ฟลัช); เอาท์พุทรวมลดลง: 1804440
bc1019-3120-stack> sh int gi2 / 0/7 | ฉันส่งออกลดลง
  อินพุตคิว: 0/75/0/0 (ขนาด / สูงสุด / หยด / ฟลัช); การส่งออกรวมลดลง: 451490

bc1019-3120-stack> sh int gi2 / 0/7 | ฉันอัตราการส่งออก
  อัตราการส่งข้อมูล 5 นาที 301000 บิต / วินาที 119 แพ็คเก็ต / วินาที

1) มีอะไรอีกบ้างที่ทำให้เอาต์พุตลดลงนอกเหนือจากเซิร์ฟเวอร์ที่ไม่ได้รับเฟรมเร็วพอ?

2) จำนวนสูงสุดของการส่งออกลดลงที่เคาน์เตอร์อินเตอร์เฟซสามารถบันทึกคืออะไร? มันมีค่ามากกว่าเมื่อถึงค่าสูงสุดหรือไม่?

3) อะไรจะได้รับการพิจารณาว่าเป็นอัตราที่ดีต่อสุขภาพของการส่งออก?


ดังที่ Leonardo Abdalla ชี้ให้เห็นว่าการลดลงของเอาท์พุทที่ผิดปกติบนเบลดแชสซีของเรานั้นเป็นผลมาจากข้อผิดพลาด CSCtq86186
123456

มันเป็นข้อผิดพลาด เราเข้าชมสิ่งเดียวกันอัพเกรดเป็น c3750e-universalk9-mz.150-2.SE4.bin และทุกอย่างดี JB

คำตอบ:


14

หากไม่มีใครล้างตัวนับคุณไม่ควรเห็นตัวนับประเภทเครื่องวัดระยะทาง ส่วนนั้นฟังดูเหมือนบั๊ก

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

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


ฉันสงสัยว่าในกรณีนี้มีการตกหล่นจำนวนมากหรือไม่เคาน์เตอร์ล้อมรอบ
เลขที่

1
พวกมันคือเคาน์เตอร์ 32 บิตดังนั้นคุณจะไม่มีที่ไหนใกล้ขีด จำกัด (และอาจเป็น 64 บิตภายใน)
Ricky Beam

8

ความคิดแรกของฉันคือน้ำท่วม unicast โดยเฉพาะถ้าเคาน์เตอร์เพิ่มขึ้นพร้อมเพรียงข้ามพอร์ตจำนวนหนึ่งใน vlan เดียวกัน ฉันเห็นด้วยกับ Aaron ว่าตัวนับลดเสียงดูเหมือนแมลง ตัวนับอาจเกลือกกลิ้งที่ 2 ^ 64 แต่นั่นจะไม่เกิดขึ้นภายในไม่กี่วินาที ฉันจะพิจารณาว่าอัตราการส่งออกที่ลดลงเป็นศูนย์ แต่นี่ไม่ใช่ความจริง - แม้ในดาต้าเซ็นเตอร์ คุณกำลังอัปโหลด 10G หรือไม่


ใช่อัปโหลด 10gig หนึ่งตัวจากแต่ละ 3120X สองตัวในเบลดแชสซี (หนึ่งพอร์ตที่ถูกปิดกั้นเนื่องจาก stp)
123456

เช่นเดียวกับการอัปลิงค์ 1G จะทำให้การดาวน์สตรีม 100M ง่ายขึ้นฉันมั่นใจว่าเป็นเช่นเดียวกันกับ 10G / 1G โดยเฉพาะอย่างยิ่งเมื่อเกิดเหตุการณ์น้ำท่วม unicast ฉันสงสัยว่าน้ำท่วมแบบ unicast จะเห็นได้ชัดในสถิติแบนด์วิดท์ / pps
Dennis Olvany

5

ดูเหมือนว่าคุณกำลังกดปุ่มข้อผิดพลาด CSCtq86186 ข้อผิดพลาดนี้ถูกพบใน 3750s, 2960s แต่มันอาจจะส่งผลกระทบต่อสวิตช์ใบมีดเช่นกัน


นี่คือข้อผิดพลาดที่เรากำลังกดปุ่มบน 3120 ของเรา - แก้ไขใน 15.0 (2) SE ขอบคุณ!
User123456

4

หากคุณกำลังประสบกับเหตุการณ์น้ำท่วม unicast การรัน wireshark บนโฮสต์ใดโฮสต์หนึ่งหรือการขยายพอร์ตใดพอร์ตหนึ่งควรแสดงให้เห็นว่าค่อนข้างเร็ว

ดูเหมือนว่าคุณมีแกนซ้ำซ้อนในโครงสร้างสี่เหลี่ยมหรือไม่? ถ้าเป็นเช่นนั้นลองเพิ่มคำสั่งนี้ไปยังอินเตอร์เฟส vlan ของคุณ:

arp timeout 300

ตาราง CAM เก็บข้อมูลเป็นเวลา 5 นาทีในขณะที่ตาราง ARP ถูกเก็บไว้เป็นเวลาสี่ชั่วโมง (ค่าเริ่มต้น) การตั้งค่า ARP ให้ตรงกับ CAM อาจช่วยลดปัญหาอุทกภัยยูนิคาสต์โดยมีค่าใช้จ่ายเพิ่มขึ้นเล็กน้อยสำหรับซีพียู Catalyst 6500/6000 Switches ARP หรือ CAM Table ปัญหาการแก้ไขปัญหา


1

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

เหตุผลเฉพาะคือส่วนหัวของการปิดกั้นบรรทัด (HOLB) ​​ซึ่งมีหลายพอร์ตต้นทางที่ส่งไปยังปลายทางเดียวและเราจึงได้รับความแออัด อีกสาเหตุที่พบบ่อยคือเมื่อไปจากความเร็วพอร์ตที่สูงขึ้นถึงต่ำกว่าเช่น 10G ถึง 1G หรือ 40G ถึง 10G

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.