การค้นหาสาเหตุของการส่ง TCP ใหม่ภายใน LAN

25

สวัสดีชาวเซิร์ฟเวอร์ล้มเหลว

ฉันมีปัญหากับ LAN ของคอมพิวเตอร์ประมาณ 100 เครื่อง, เซิร์ฟเวอร์โดเมน Windows 2 เครื่องและโทรศัพท์ VoIP 12 เครื่อง นับตั้งแต่การติดตั้งเมื่อประมาณหนึ่งปีที่ผ่านมาทุกสัปดาห์หรือมากกว่านั้นเราสังเกตว่าโทรศัพท์ VoIP กำลังรีเซ็ตตัวเอง - บางครั้งอาจอยู่ระหว่างการโทร ในขณะเดียวกันก็มักจะมีสัญญาณของการสูญเสียการเชื่อมต่อชั่วคราวบนคอมพิวเตอร์: ค้างใน explorer ในขณะที่ใช้งานเครือข่ายร่วมกัน, ข้อผิดพลาดในซอฟต์แวร์การบริหารของเราเนื่องจากการขาดการเชื่อมต่อกับเซิร์ฟเวอร์ฐานข้อมูล

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

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

คุณมีความคิดที่จะช่วยวินิจฉัยสาเหตุของปัญหาเช่นนี้หรือไม่? สิ่งหนึ่งที่ฉันยังไม่ได้ลอง แต่ควรมีคือการอัปเดตเฟิร์มแวร์ของสวิตช์ทั้งหมด

networking tcp voip

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

1

สวิตช์รุ่นใด proccessor, memeory, etc stats มีลักษณะอย่างไร คุณอยู่ในโดเมนออกอากาศหรือไม่ คุณเห็นว่าเครือข่ายใกล้เคียงกับปริมาณงานสูงสุดเท่าใด

— Zypher

คุณกำลังใช้โปรโตคอล VoIP อะไร ยังใช้ UDP หรือ TCP?

— Chris S

สวิตช์ทั้งหมดคือ 3Com: Baseline 2924 - PWR Plus (3CBLSG24PWR) x 2, 4200 (3C17304A) x 3, 4200 (3C17304) x 2, 2824-SPF Plus (3C16487), 2250 บวก (3C16476CS) ฉันไม่คิดว่าพวกเขาให้สถิติกับโปรเซสเซอร์หรือหน่วยความจำ แต่ฉันยินดีเป็นอย่างยิ่งที่จะเรียนรู้อย่างอื่น ใช่เราอยู่ในโดเมนออกอากาศหนึ่ง ฉันไม่รู้เกี่ยวกับปริมาณงานฉันจะตรวจวัด

— Surreal

17

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

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

9

นอกจากนี้การส่งสัญญาณ TCP ไม่ใช่สาเหตุของปัญหาของคุณ แต่เป็นอาการของปัญหา

— joeqwerty

ฉันควรได้กล่าวว่าฉันได้ดูการออกอากาศ UDP และพวกเขาไม่ได้มีความสัมพันธ์กับการส่งสัญญาณซ้ำ มีเหตุการณ์ retransmission สองสามตัวที่มี spikes ในการถ่ายทอด UDP แต่ส่วนใหญ่ทำไม่ได้ ฉันมีรูปลักษณ์อื่นและพบว่าการออกอากาศ UDP ไม่เกิน 1.5% ของปริมาณการใช้งาน (ประมาณ 350 แพ็คเก็ต) ในช่วงเวลา 10 นาทีใด ๆ และการเข้าถึงระดับนั้นนั้นหายาก อย่างไรก็ตามฉันไม่ได้ดูการออกอากาศของอีเธอร์เน็ต ฉันกำลังเรียกใช้สคริปต์ตอนนี้เพื่อกรองบันทึกการใช้งานของฉันทั้งหมด กฎง่ายๆ 3% สำหรับการออกอากาศ UDP และการออกอากาศอีเทอร์เน็ตแยกกันหรือรวมกัน?

— Surreal

1

3% ไม่ได้เป็นกฎง่ายๆ มันเป็นสิ่งที่ฉันได้รับการบอกเล่าและสิ่งที่ฉันได้เห็นในสภาพแวดล้อมของฉันเอง ฉันเคยได้ยินตัวเลขตั้งแต่ 10 ถึง 20% แต่ฉันพบว่าเมื่อเกิน 3 ถึง 5% มักจะทำให้เกิดปัญหา คุณต้องดูทราฟฟิกที่ออกอากาศทั้งหมด: อีเธอร์เน็ต, เครือข่ายและการออกอากาศแบบหลายผู้รับเนื่องจากอาจทำให้เกิดความแออัด โดยทั่วไปการรับส่งข้อมูลใด ๆ ที่ออกอากาศไปยังพอร์ตสวิตช์ทั้งหมดเป็นการรับส่งข้อมูลที่จำเป็นต้องวิเคราะห์และลดหรือกำจัด

— joeqwerty

ฉันยังไม่ได้กราฟสวย ๆ มาด้วยกันเพื่อตรวจสอบความสัมพันธ์ที่ดีในระยะเวลานาน แต่การออกอากาศของอีเธอร์เน็ตนั้นค่อนข้างจะมีแนวโน้ม บันทึกหนึ่งที่มีการส่งสัญญาณซ้ำมีการออกอากาศมากกว่า 3% และอีก 6% ฉันพบปัญหาอย่างน้อยหนึ่งอย่าง: เซิร์ฟเวอร์เก่ากำลังปล่อยกระแสข้อมูลแพ็คเก็ต ARP ที่ไม่มีค่าใช้จ่าย

— Surreal

1

ฉันพบรายการ ARP มากเกินไปโดยใช้ตัวกรอง Wireshark ของarp- และเพื่อดูรายการออกอากาศเท่านั้นโดยใช้ตัวกรองของeth.addr==ff:ff:ff:ff:ff:ff

— mlhDev

2

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

มองหาคนที่ใช้สื่อสตรีมมิ่งเพราะสามารถดื่มด่ำกับวงดนตรีได้อย่างรวดเร็ว

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

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

2

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

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

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

— Surreal

การทำความคุ้นเคยกับ STP เป็นความคิดที่ดี แต่ถ้าคุณแน่ใจว่าคุณไม่มีลิงก์ที่ซ้ำซ้อน STP จะไม่เป็นปัญหา

— joeqwerty

ใช่ถ้าคุณไม่มีลิงค์ซ้ำซ้อนมันจะไม่เป็นปัญหา โดยสถานะของพอร์ตใช่ฉันหมายถึงการส่งต่อ / บล็อก / การเรียนรู้

— McJeff

2

คุณอาจแก้ปัญหานี้ได้เพราะมันใช้เวลานาน แต่คุณต้องเปิดใช้ "พอร์ตเร็ว" บนพอร์ตที่มีจุดปลาย (โทรศัพท์ voip, เวิร์กสเตชัน, เซิร์ฟเวอร์) โทรศัพท์สามารถส่ง PDU ได้ดังนั้นหากคนนั้นเริ่มต้นใหม่มันจะทำให้การลู่เข้าของ STP เกิดขึ้นทำให้ตาราง FDB ถูกล้างออกและอุปกรณ์ทั้งหมดจะต้องผ่านความสนุก STP 4/5 ขั้นตอน ด้วยการใส่พอร์ตที่มีจุดสิ้นสุดใน "พอร์ตเร็ว" พวกเขาจะข้ามการรอและไปที่โหมดการส่งต่อโดยตรง

— บารัค
แหล่งที่มา

1

หวังว่าโทรศัพท์ของคุณอยู่ในเครือข่ายย่อยและ VLAN อื่นจากคอมพิวเตอร์เครื่องอื่นหรือไม่

— เกร็กเบน
แหล่งที่มา

ไม่มีพวกเขาอยู่บนซับเน็ต IP เดียวกันและฉันค่อนข้างแน่ใจว่า VLAN เดียวกันก็เช่นกัน นี่เป็นปัญหาร้ายแรงหรือไม่? แน่นอนว่ามันจะเป็นความคิดที่ดี ฉันเห็นว่ามันจะแยกโดเมนการออกอากาศสำหรับโทรศัพท์และทุกอย่างอื่น มันจะมีข้อได้เปรียบอื่น ๆ อีกหรือไม่?

— Surreal

ใช่ฉันจะวางโทรศัพท์ไว้กับ VLAN เฉพาะ

— Greg Askew

1

มันอาจเป็นชิ้นส่วนที่ผิดพลาดของอุปกรณ์เช่นสวิตช์ที่ผิดปกติ การส่งสัญญาณใหม่มีความสัมพันธ์กับโทรศัพท์ / คอมพิวเตอร์บนสวิตช์หนึ่งหรือส่วนหนึ่งของเครือข่ายหรือไม่?

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

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

— ด้าน
แหล่งที่มา

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

— Surreal