คำถามติดแท็ก packet-loss

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Network Engineering Stack Exchange ปิดให้บริการในวันที่ 11 เดือนที่ผ่านมา บางทีฉันอาจจะพลาดบางสิ่งบางอย่างที่ค่อนข้างธรรมดา แต่ฉันไม่รู้ฉันเลยคิดว่าจะถาม ในแง่ของการทดสอบความไวของ TDMoE ต่างๆที่มีต่อ BER และความล่าช้าของแพ็คเก็ตนั้นคืออะไรฉันกำลังหาวิธีจำลองการหน่วงเวลาและการสุ่มแพ็คเก็ตแบบสุ่มที่ระดับอีเธอร์เน็ต สำหรับการทดสอบเหล่านี้ฉันอาจจะเรียกใช้ iptables ตามเอกสารในคำถาม StackOverflow ที่คล้ายกัน อย่างไรก็ตามถึงแม้ว่าจะใช้งานได้ที่นี่ฉันไม่แน่ใจว่ามันจะทำงานในกรณีทั่วไปมากขึ้น (อาจทดสอบ BER ที่ยอมรับได้ระหว่างเซิร์ฟเวอร์ Windows และสิ่งอื่นที่คล้ายคลึงกัน) ดังนั้นนี่ทำให้ฉันคิด มีอุปกรณ์การทดสอบเครือข่ายราคาไม่แพงหรือไม่ที่อนุญาตให้หนึ่งหน่วงเวลาเทียมหรือปล่อยแพ็กเก็ตเพื่อทดสอบโปรโตคอลโปรโตคอลและประเมินความไวต่อความล่าช้าในการตอบสนองและการสูญเสียแพ็กเก็ต ความต้องการของฉันจะสามารถทำได้ในระดับอีเธอร์เน็ต ฉันไม่ได้มองหาอุปกรณ์แบรนด์หรืออื่น ๆ ที่เฉพาะเจาะจงมากเท่า "สิ่งที่พวกเขาทำเช่นนี้" และถ้าเป็นเช่นนั้นบางทีความคิดทั่วไปของสิ่งที่พวกเขาชอบ ฉันกำลังมองหาการสร้างสะพานง่าย ๆ ที่ใช้ Linux และ iptables เพื่อทำสิ่งนี้ แค่สงสัยว่านี่เป็นวิธีที่ถูกต้องหรือไม่

23 ethernet  ber  packet-loss  testing 

เราใช้ Cisco ASA 5585 ในโหมดโปร่งใสเลเยอร์ 2 การกำหนดค่าเป็นเพียงสองลิงก์ 10GE ระหว่างคู่ค้าทางธุรกิจของเราและเครือข่ายภายในของเรา แผนที่ง่าย ๆ จะมีหน้าตาแบบนี้ 10.4.2.9/30 10.4.2.10/30 core01-----------ASA1----------dmzsw ASA มี 8.2 (4) และ SSP20 สวิทช์ 6500 Sup2T พร้อม 12.2 ไม่มีแพ็กเก็ตตกลงบนสวิตช์หรืออินเตอร์เฟส ASA !! ปริมาณการใช้งานสูงสุดของเราคือประมาณ 1.8Gbps ระหว่างสวิตช์และโหลด CPU บน ASA ต่ำมาก เรามีปัญหาแปลก ๆ ผู้ดูแลระบบ nms ของเราเห็นการสูญเสียแพ็คเก็ตที่แย่มากซึ่งเริ่มในช่วงเดือนมิถุนายน การสูญเสียแพ็คเก็ตกำลังเติบโตอย่างรวดเร็ว แต่เราไม่รู้ว่าทำไม การรับส่งข้อมูลผ่านไฟร์วอลล์ยังคงมีอยู่อย่างต่อเนื่อง แต่การสูญหายของแพ็คเก็ตก็เพิ่มขึ้นอย่างรวดเร็ว นี่คือความล้มเหลวในการ pag ของ nagios ที่เราเห็นผ่านไฟร์วอลล์ …

19 cisco  switch  cisco-asa  firewall  packet-loss 

ฉันได้รับความล่าช้าที่เพิ่มขึ้นและ StDev เนื่องจากความแออัดของเส้นทางและการสูญเสียแพ็กเก็ตแต่เส้นทางไปข้างหน้าและย้อนกลับไปตามเครือข่ายที่แตกต่างกัน (เช่นหนึ่งถูก init7.net อีกอันหนึ่งเป็น he.net) ดังนั้นจึงยากที่จะเข้าใจ เครือข่ายหรือโฮสต์ใดรับผิดชอบต่อความแออัดการสูญหายของแพ็กเก็ตการกระวนกระวายใจและความล่าช้าที่เพิ่มขึ้น มีวิธีที่จะจำกัดความผิดหลังจากที่ไปข้างหน้าและย้อนกลับmtrไม่สามารถระบุผู้กระทำผิดที่แน่นอนและผู้ติดต่อ NOC @ ไม่ตอบสนองหรืออ้างว่าประสบกับการสูญเสียบนเส้นทางที่เป็นปัญหาหรือไม่? (ฉันใช้ OpenBSD) ฉันได้ลองทำmtrโดยตรงกับลูกค้าบางส่วนของทั้งสองเครือข่ายที่อาจประสบปัญหาความแออัด แต่ไม่พบปัญหาใด ๆ ที่เกิดขึ้นโดยเฉพาะอย่างยิ่งเช่น he.net มีป๊อปจำนวนมากและบ่อยครั้ง เส้นทางที่แตกต่างกันจะถูกนำมาระหว่างรายการที่กำหนดและออกจาก POP ดังนั้นเมื่อฉันลองไปยังmtrโฮสต์ของพวกเขา (เช่น tserv) โดยตรงที่ทางออก POP ซึ่งฉันอาจจะสูญเสียแพ็กเก็ตในเครือข่ายของพวกเขาเส้นทาง he.net ที่แตกต่างกัน POP เดียวกันและไม่มีการสูญเสียแพ็กเก็ตเกิดขึ้นซึ่งไม่ได้พิสูจน์สิ่งที่น่าสนใจ (นอกเหนือจากข้อเสนอแนะที่เป็นไปได้ว่าพวกเขาอาจเกินเส้นทางบางเส้นทางในขณะที่ทำให้แน่ใจว่าคนอื่น ๆ ไม่ได้หลงลืมโดยไม่สนใจคำขอ NOC @ จากลูกค้า

10 latency  packet-loss  mtr 

ฉันมีเราเตอร์เชื่อมต่อกับโมเด็ม ความตั้งใจของฉันคือการเชื่อมต่อกับเราเตอร์นี้จากสำนักงานที่อยู่ห่างออกไปประมาณ 200 ฟุตและผ่านกำแพง 2 หลัง สัญญาณของเราเตอร์ไม่แรงพอที่จะไปยังที่ตั้งห่างไกลดังนั้นฉันจึงใส่ตัวขยายช่วงเข้าไป สิ่งที่สับสนอย่างยิ่งคือเมื่อคอมพิวเตอร์ของฉัน (หรือไคลเอนต์ใด ๆ ) เชื่อมต่อกับ Extender ในขณะที่นั่งถัดจากมันจะทำงานได้อย่างสมบูรณ์ (ping ครั้งประมาณ 30ms) อย่างไรก็ตามเมื่อฉันย้ายไปยังสถานที่ห่างไกลถึงแม้ว่าความแรงของสัญญาณ wifi จะอยู่ที่ 3/4 หรือ 4/4 บาร์ความสูญเสียของแพ็คเก็ตนั้นใหญ่มาก แต่จากนั้นจะลดลงเหลือ 800+ และประมาณ 10% จะหมดเวลาแพ็คเก็ตทั้งหมด ดังนั้นคำถามของฉันคือ ... ถ้าความแรงของสัญญาณดีทำไมระยะทางนี้จะทำให้เกิดการสูญเสียตที่น่ากลัว และสิ่งที่อาจทำให้เกิดการรบกวนดังกล่าว? ฉันอยู่ในย่านที่อยู่อาศัย แต่ไม่มีอะไรแน่นอนที่เห็นได้ชัดระหว่างแล็ปท็อปและตัวส่งสัญญาณทวนสัญญาณอื่นที่ไม่ใช่ 2 กำแพง (ไม่ว่าจะใช้สายไฟฟ้าอะไรก็ตาม

10 wireless  packet-loss 

ฉันต้องวัดเวลาในการตอบสนองต่อการกระวนกระวายใจและการสูญเสียแพ็กเก็ตต่อลิงก์ในเครือข่ายเมื่อเทียบกับแบบ end-to-endเช่นนี้ s1-eth0 <--> s2-eth0 (~ 20 avs เฉลี่ยเวลาแฝง, มาตรฐานมา 10µs, การสูญเสียแพ็กเก็ต 57% / วินาทีสุดท้าย) s2-eth1 <--> s3-eth0 (ความล่าช้าเฉลี่ย ~ 25µs, มามาตรฐาน 5µs, การสูญเสียแพ็กเก็ต 21% / วินาทีสุดท้าย) ... โซลูชันทั้งหมดที่ฉันสามารถค้นหาได้คือข้อเสนอเชิงวิชาการหรือเกี่ยวข้องกับการใช้ฮาร์ดแวร์เฉพาะสำหรับการตรวจสอบที่ใช้งานอยู่ นี่คือบทสรุปสิ่งที่ตามการวิจัยของฉันไม่ได้ผล: NetFlow:ไม่มีข้อมูลเวลาในการตอบสนอง, แบบครบวงจรเท่านั้น Active Probing:เป็นไปไม่ได้ที่ฉันจะเปลี่ยนการกำหนดค่าเครือข่าย วัดเวลาเดินทางไป - กลับ:ไม่ได้จัดทำต่อสถิติการเชื่อมโยง มีโปรโตคอลเครือข่ายเครื่องมือวัดหรือฟังก์ชั่นอื่น ๆ ที่ให้ข้อมูลสถิติข้างต้นทั้งหมดหรืออย่างน้อยบ้างไหม?

9 router  switch  monitoring  latency  packet-loss 

ฉันมีแพ็กเก็ตจำนวนหนึ่งที่ลดลงในอินเทอร์เฟซ 10gb / s ของฉันใน Cisco 6500 ด้วย Sup 720 คุณสามารถดูจำนวนแพ็กเก็ตที่หลุดได้ภายในหนึ่งนาทีหลังจากที่ฉันเคลียร์เคาน์เตอร์ เราไม่เห็นว่าประสิทธิภาพการทำงานลดลง แต่อย่างใดและลูกค้าของเราก็ไม่บ่น สิ่งนี้จะเป็นปัญหาร้ายแรงในอนาคตหรือไม่ ฉันไม่เคยเห็นแพ็กเก็ตเดียวในคิว ฉันกำลังพิจารณาเปลี่ยนขนาดอินพุตคิวเป็น 1024 เพราะเป็น 75 แพ็คเก็ตในคิวโดยค่าเริ่มต้น แต่ฉันสงสัยว่าทำไมแพ็คเก็ตไม่ได้ป้อนในคิวเลยก่อนที่จะลดลง บน 1gb / s interfaces ฉันไม่เห็นแพ็กเก็ตที่ถูกทิ้งเลยและทุกอย่างเรียบร้อยดี โปรดช่วยฉันแก้ปัญหาด้วยการลดคิว sh int TenGigabitEthernet1/1 Hardware is C6k 10000Mb 802.3, address is 000f.3589.ac00 (bia 000f.3589.ac00) Description: transit Internet address is 192.0.2.1/24 MTU 1500 bytes, …

9 cisco  cisco-6500  packet-loss 

เมื่อเร็ว ๆ นี้หลังจากอัพเกรดวงจร MetroE หลายตัว (การเชื่อมต่อ L2) จาก 100Mbps เป็น 1Gbps ฉันสังเกตเห็นว่าการถ่ายโอนไฟล์ขนาดใหญ่ล้มเหลวระหว่างบางไซต์ อย่างไรก็ตามการถ่ายโอนล้มเหลวในทิศทางเดียว ตัวอย่างเช่นพิจารณาตัวอย่างต่อไปนี้ จาก -> ถึง A -> B = ล้มเหลว B -> A = สำเร็จ A -> C = สำเร็จ C -> A = สำเร็จ B -> C = สำเร็จ C -> B = สำเร็จ แต่ละไซต์เป็นส่วนที่กำหนดเส้นทางหลังสวิตช์ L3 ซึ่งอยู่ที่ไซต์ …

8 packet-loss  metro-ethernet