सीरियल इंटरफ़ेस पर आउटपुट ड्रॉप्स: बेहतर कतार या आउटपुट कतार आकार?

Question

एक से अधिक वाहक और iBGP से एक-दूसरे के लिए ईबीजीपी बोलने वाले इंटरनेट एज राउटर पर, प्रत्येक राउटर पर एक सीरियल फुल-डीएस 3 (~ 45Mbps) को छोड़कर LAN और WAN साइड पर सभी इंटरफेस जीई हैं। हालांकि मुझे लगता है कि मैं धारावाहिक इंटरफेस पर मुश्किल से ज्यादा ट्रैफिक भेज रहा हूं - 3-10Mbps रेंज में - मुझे लगातार आउटपुट क्यू ड्रॉप्स (OQD) दिखाई देते हैं। क्या इस बात की संभावना है कि वास्तव में वहाँ बहुत ट्रैफ़िक है जो मैं देख नहीं रहा हूँ क्योंकि लोड-अंतराल 30 सेकंड के न्यूनतम पर है और एसएनएमपी मतदान 5 मिनट से अधिक का औसत ट्रैफ़िक है, इसलिए वे फटने को रोशन नहीं करेंगे?

प्लेटफॉर्म सिस्को 7204VXR NPE-G2 है। सीरियल कतारबद्ध है फोजो ।

Serial1 / 0 ऊपर है, लाइन प्रोटोकॉल ऊपर है
  हार्डवेयर M2T-T3 + pa है
  विवरण:
  इंटरनेट का पता abcd / 30 है
  MTU 4470 बाइट्स, BW 44210 Kbit, DLY 200 usec,
     विश्वसनीयता 255/255, txload 5/255, rxload 1/255
  एचडीपीएससी एन्कैप्सुलेशन, सीआरसी 16, लूपबैक सेट नहीं
  मुख्य सेट (10 सेकंड)
  रिस्टार्ट-डिले 0 सेकंड है
  अंतिम इनपुट 00:00:02, आउटपुट 00:00:00, आउटपुट हैंग कभी नहीं
  "शो इंटरफ़ेस" काउंटरों की अंतिम समाशोधन 00:35:19
  इनपुट कतार: 0/75/0/0 (आकार / अधिकतम / ड्रॉप / फ्लश); कुल उत्पादन बूँदें: 36
  क्युइंग रणनीति: फिफो
  आउटपुट कतार: 0/40 (आकार / अधिकतम)
  30 सेकंड इनपुट दर 260000 बिट्स / सेकंड, 208 पैकेट / सेक
  30 दूसरी आउटपुट दर 939000 बिट्स / सेक, 288 पैकेट / सेक
     410638 पैकेट इनपुट, 52410388 बाइट्स, 0 कोई बफर नहीं
     212 प्रसारण, 0 रन, 0 दिग्गज, 0 थ्रोटल्स प्राप्त किए
              0 समता
     0 इनपुट त्रुटियां, 0 सीआरसी, 0 फ्रेम, 0 ओवररन, 0 अनदेखा, 0 एबॉर्ट
     515752 पैकेट आउटपुट, 139195019 बाइट्स, 0 अंडररन
     0 आउटपुट एरर, 0 एप्लाइक, 0 इंटरफेस रिसेट
     0 आउटपुट बफ़र विफल, 0 आउटपुट बफ़र्स बाहर बदली
     0 वाहक संक्रमण
   rxLOS निष्क्रिय, rxLOF निष्क्रिय, rxAIS निष्क्रिय
   txAIS निष्क्रिय, rxRAI निष्क्रिय, txRAI निष्क्रिय

24 घंटे बाद हजारों OQD दिखाएंगे। हम प्रत्येक दिन लगभग 3 बजे अधिक ट्रैफ़िक को धक्का देते हैं, इसलिए हो सकता है कि यहाँ कुछ धमाकेदार ट्रैफ़िक हो, मैं पर्याप्त वजन नहीं दे रहा हूँ।

Last clearing of "show interface" counters 1d01h
Input queue: 0/75/0/158 (size/max/drops/flushes); Total output drops: 12049

मैं DS3 पर अधिक आउटबाउंड ट्रैफ़िक पुश करना चाहता हूं, लेकिन OQD पर मेरी चिंता के साथ नहीं। DS3 के पीछे के टियर 2 ISP में 6+ टियर 1 के साथ पीयरिंग-पॉइंट्स के रूप में पीओपी है, इसलिए विचार यह है कि क्लाइंट के साथ ट्रैफ़िक ऑन-नेट प्राप्त करें जैसा कि जीई पर हमारे प्राथमिक आईएसपी के विपरीत है जो एक टियर 1 है , लेकिन अपने सहकर्मी एक्सचेंजों की ओर अपने तरीके से काम करना चाहिए। आवक यातायात एक चिंता का विषय नहीं है।

क्या इस स्थिति में फीफो की तुलना में बेहतर कतारबद्ध रणनीति है? इनपुट और आउटपुट कतार ड्रॉप्स पर सिस्को डॉक्स को देखते हुए, आउटबाउंड कतार आकार को बढ़ाने की अनुशंसा नहीं की जाती है क्योंकि पैकेट पहले से ही राउटर पर हैं और इनपुट पर ड्रॉप करना बेहतर होगा ताकि टीसीपी ऐप को वापस थ्रॉटल कर सके। हमारे जीई लिंक पर बहुत सारे बैंडविड्थ हैं, इसलिए वास्तव में इनपुट को थ्रॉटल करने की कोई आवश्यकता नहीं है। इन राउटर्स पर कोई पॉलिसी-मैप नहीं हैं। 90% आउटबाउंड ट्रैफ़िक हमारी HTTP प्रतिक्रियाओं से आता है; एफ़टीपी और एसएमटीपी से अधिकांश बाकी। GE लिंक 50-200 + एमबीपीएस पुश करता है।

क्या आप आउटपुट कतार आकार बफर के लिए किसी भी समायोजन की सिफारिश करेंगे? ये सीरियल इंटरफेस हमारे बैकअप लिंक हैं जो मैं पहले दिए गए कारण (यदि मान्य) के लिए अधिक उपयोग करता हूं, लेकिन मेरी बीजीपी नीतियों के साथ गुस्सा है जो उस धारावाहिक इंटरफ़ेस को अधिभारित करने का प्रयास करते हैं (जो कि अधिकांश समय बहुत कम भारित दिखाई देता है)।

Answer 1

आप सही हैं, आप वास्तव में SNMP पर आसानी से फूटते नहीं दिखेंगे। 1GE 1.48Mpps भेज सकता है, इसलिए 45Mbps की भीड़भाड़ करने में बहुत कम समय लगता है, जो कि 75kpps से कम संभाल सकता है।

यदि आपकी अंतर्ग्रहण 1GE है और egress 45Mbps है, तो जाहिर है कि 45Mbps की भीड़ बिंदु को पैकेट छोड़ने की आवश्यकता होगी। यह सामान्य और अपेक्षित है। यदि आप बफ़र्स बढ़ाते हैं तो आप अधिक विलंब का परिचय देंगे।
1GE को 40 1500B आईपी फ्रेम भेजने के लिए 0.45ms लगते हैं, जो अभी फटने की मात्रा है जिसे आप संभाल सकते हैं। हालाँकि 45Mbps पर उन्हें डिलीट करने में पहले से ही 10ms लगते हैं।

यदि आपको कोई गंभीर समस्या नहीं है, तो मैं शायद इसके बारे में कुछ नहीं करूंगा। लेकिन अगर कुछ ट्रैफ़िक अन्य की तुलना में छोड़ने के लिए अधिक योग्य हैं, तो आपको फ़िफ़ो को क्लास-आधारित कतार के साथ बदलना चाहिए। कहो शायद आप प्राथमिकता देना चाहते हैं ताकि अधिक ftp कम हो और कम वीओआइपी हो।
फिर यह ftp ट्रैफ़िक पर अधिक बफ़रिंग जोड़ने के लिए और अधिक समझदार बना देगा, क्योंकि यह देरी के लिए वास्तव में संवेदनशील नहीं है।

यदि आप गहरी बफ़र्स के साथ अपनी किस्मत आजमाना चाहते हैं, तो इस तरह से कुछ करना चाहिए:

policy-map WAN-OUT
 class class-default
    fair-queue
    queue-limit 200 packets
!
interface Serial1/0
  service-policy output WAN-OUT

यह Serial1 पर 50ms बफ़र्स का कारण होगा और आपको एकल Gige इंटरफ़ेस से फटने वाले 2.25ms को संभालने की अनुमति देगा।

Comments

DS3s पर जाने वाले कुछ प्रतिशत ट्रैफ़िक के साथ हमारे प्राथमिक रास्तों पर प्राथमिक प्रवेश और निकास 1GE हैं। Q को यह दिखाने के लिए संपादित किया गया कि 90% आउटबाउंड FTP और SMTP के साथ HTTP रिस्पांस ट्रैफिक है, जो बाकी है।

— generalnetworkerror

बफ़रिंग के कारण होने वाली देरी के कारण, जब Gige उपलब्ध होता है, तो मैं DS3 का उपयोग करने से बचता हूँ। उन सभी उल्लिखित अनुप्रयोगों को हालांकि बहुत देरी और नुकसान सहिष्णु लगता है।

— यति

अन्य कारण जो मैंने DS3 का अधिक उपयोग करने की कोशिश के लिए उल्लेख नहीं किया है, वह GE WAN लिंक पर फट चार्ज से बचने की कोशिश करना है जो कि किक-इन> 100Mb है। यद्यपि हम 100Mb से ऊपर रोजाना फटते हैं, यह लंबे समय से मामले (अभी तक) के लिए पर्याप्त नहीं है।

— generalnetworkerror

आप DS3 पर अधिक ट्रैफ़िक ला सकते हैं और यहां तक ​​कि अधिक विलंब शुरू करके पैकेट ड्रॉप्स को कम कर सकते हैं। लेकिन अगर आप अपनी ट्रैफ़िक दरों को बढ़ने का अनुमान लगा रहे हैं, तो समस्या बस और बदतर होती जाएगी। याद रखें कि ईथरनेट कुछ और नहीं बल्कि 100% या 0% है, बस 100% कितना समय बदलता है। तो आप हमेशा अपने हाई-स्पीड 1GE नेटवर्क के कारण होने वाली फटने को खत्म करेंगे।

— यति

200 पैकेट के लिए मेरा तर्क यह है कि उन्हें आपके 45Mbps पर भेजने में देरी हो रही है, जो कि 50ms है जो डेटा अनुप्रयोगों के लिए अभी भी सहन करने योग्य देरी है। आपको अपने आप से पूछना चाहिए कि आप कब तक बर्दाश्त करने में देरी कर रहे हैं और फिर उस लक्ष्य को पूरा करने के लिए बफर निर्दिष्ट करें। आपकी स्थिति में, मैं सिर्फ gige का उपयोग करूंगा।

— यति

Answer 2

OQD आमतौर पर दो चीजों में से एक के कारण होता है:

1. आप लिंक का उपयोग कर रहे हैं; या तो निरंतर उच्च उपयोग या बर्फीले ट्रैफ़िक के साथ।

2. आपके पास इंटरफ़ेस पर लागू एक नीति नक्शा है जिसे कुछ या सभी ट्रैफ़िक को पुलिसिंग या आकार देने के लिए कॉन्फ़िगर किया गया है

3. इंटरफ़ेस पर किसी प्रकार की त्रुटि है, त्रुटि काउंटर ( show interface Serial1/0 counters errors) पर एक नज़र डालें और जांचें कि त्रुटि के कारण पैकेट को नहीं छोड़ना है।

आप अपने मिशन क्रिटिकल ट्रैफ़िक को अपनी कतार देने जैसे काम करने के लिए पॉलिसी मैप डाल सकते हैं (यदि आप पहले से ही मिल गए हों तो) नियमित ट्रैफ़िक (WRED) पर भीड़ से बचने या यहाँ तक कि ट्रैफ़िक पर उचित कतारबद्ध करने में सक्षम हो सकते हैं। इंटरफ़ेस को पार करने वाले प्रवाह के बीच बैंडविड्थ को साझा किया जाता है।

जैसा कि आपने उल्लेख किया है, एक अन्य विकल्प इंटरफ़ेस पर आउटपुट कतार आकार में वृद्धि करेगा, लेकिन यदि आप एक नीति मानचित्र का उपयोग करते हैं तो इसके लिए वैसे भी कोई आवश्यकता नहीं होगी क्योंकि नीति अन्य उप-कतारें बनाएगी।