🥦 🌬️ 👨🏽‍⚕️ घबराना / पैकेट खो जाने से चैनल की स्थिति की निगरानी #⃣ 👝 💇🏽

शुभ दोपहर, सहकर्मी।

अपने विचारों को इकट्ठा करने के बाद, मैंने उस समाधान को ठीक से तैयार करने का फैसला किया जो मेरे लिए पैदा हुआ था।

तो, समस्या का बयान :

अंक ए और बी के बीच दो चैनल हैं, जो अक्सर विभिन्न प्रदाताओं से होते हैं। इन चैनलों पर सेवा की गुणवत्ता का लेखा-जोखा सुनिश्चित करना आवश्यक है:

1. नुकसान के लिए> चैनल पर 0.5%, चैनल का उपयोग नहीं किया जाना चाहिए।

2. जब घबराना> 10ms, चैनल का उपयोग नहीं किया जाना चाहिए।

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

मूल निर्णय ।

प्रारंभ में, वहाँ भी दो अनाड़ी विकल्प थे। पहले tsiska पर एक पिंगोवल्का उठाना था, चैनल की उत्तरजीविता की जांच करना और उसकी मृत्यु पर स्विच करना। समाधान तब तक काम करता रहा जब तक हमें नुकसान के अभाव में घबराहट की समस्या नहीं हुई।

दूसरा उपाय udp पैकेट के आधार पर एक मॉनिटर बनाना था जो G729 कोडेक की नकल करता है। मॉनिटर ने नुकसान और घबराहट दिखाई, संचार समस्याओं के मामले में, व्यवस्थापक ने बिल्ली पर चढ़कर, उस पर घबराना और नुकसान के मौजूदा मूल्यों को देखा और, परिस्थितियों के अनुसार, चैनल को अक्षम करने का निर्णय लिया। यह काम किया, बिल्कुल। लेकिन यह किसी तरह का अर्ध-स्वचालित सिस्टम निकला है। इसलिए, मैंने खुद को एक साथ खींच लिया और इस स्थिति को कुछ अंतिम समाधान के लिए लाया।

वर्तमान समाधान ।

इसलिए, दूसरे मामले में, हम एक चैनल गुणवत्ता udp मॉनिटर बनाते हैं जो G729a कोडेक (तथाकथित SLA मॉनिटर) की नकल करता है।

ip sla 33 
      

        
        
        
      

     udp-jitter 172.16.1.66 49333 source-ip 172.16.1.65 codec g729a codec-size 20 
      

        
        
        
      

     tos 70 
      

        
        
        
      

     threshold 10

यह मॉनिटर गंतव्य पर 49333 पोर्ट के लिए 1000 पैकेट प्रति मिनट के अंतराल पर भेजेगा, अंकन = 70 = 0x46 = EF। गंतव्य सक्षम होना चाहिए

ip sla responder

अगला, हम एक स्थिर ट्रैक बनाते हैं (विशेष रूप से एप्लेट की सहायता से इसे नियंत्रित करने के लिए बनाया गया है, और इसे SLA मॉनिटर पर कसकर बाँधने के लिए नहीं):

track 20 stub-object 
      

        
        
        
      

     default-state up

अब हमारा काम एसएलए मॉनिटर से परिणामों को निकालना है और, उनके मूल्यों के अनुसार, यूपी राज्य में ट्रैक 20 को छोड़ दें या डाल दें। यह किया जा सकता है, उदाहरण के लिए, सिस्को ईईएम (एंबेडेड इवेंट मैनेजर) का उपयोग करके, जो आपको अपने हार्डवेयर की वर्तमान स्थिति की निगरानी करने और कुछ कार्यों को करने की अनुमति देता है।

ऐसा करने के लिए, दो एप्लेट बनाएं। यदि कोई कम से कम एक पैरामीटर (घबराना या नुकसान की संख्या) में से एक को नीचे की स्थिति में ट्रैक करेगा तो वह हमारे अनुरूप नहीं होगा। यदि दूसरा पैरामीटर सामान्य है, तो दूसरा इसे वापस उठाएगा।

विन्यास

1. पहला एप्लेट बनाएँ:

event manager applet LB trap

हम अपने SLA मॉनीटर से RTT और घबराना के लिए SNMP OID पर आधारित दो इवेंट बनाते हैं:

event tag jitter snmp oid 1.3.6.1.4.1.9.9.42.1.5.2.1.46.33 get-type exact entry-op ge entry-val "10" entry-type value poll-interval 4 
      

        
        
        
      

     event tag loss snmp oid 1.3.6.1.4.1.9.9.42.1.5.2.1.1.33 get-type exact entry-op le entry-val "994" entry-type value poll-interval 4

यहां, एसएनएमपी ओआईडी में अंतिम अंक 33 एसएलए उदाहरण संख्या है। 10 - घबराना (एमएस में) के लिए, 994 - भेजे गए एक हजार में से लौटे पैकेटों की न्यूनतम स्वीकार्य संख्या (1000 - पैकेट_लॉस)। पोल-इंटरवल - वह अंतराल जिस पर बिल्ली मूल्यों की स्थिति का सर्वेक्षण करती है। यहाँ 4 थी।

हम इंगित करते हैं कि हमारे एप्लेट को किसी भी घटना के साथ काम करना चाहिए, अर्थात्। तार्किक या उपयोग किया जाता है।

trigger 
      

        
        
        
      

     correlate event loss or event jitter

आगे की कार्रवाई:

action 20 track set 20 state down

यानी हमारा ट्रैक डाउन पर सेट है।

दूसरा एप्लेट समान है:

event manager applet LB2 trap 
      

        
        
        
      

     event tag jitter snmp oid 1.3.6.1.4.1.9.9.42.1.5.2.1.46.33 get-type exact entry-op lt entry-val "10" entry-type value poll-interval 4 
      

        
        
        
      

     event tag loss snmp oid 1.3.6.1.4.1.9.9.42.1.5.2.1.1.33 get-type exact entry-op gt entry-val "994" entry-type value poll-interval 4 
      

        
        
        
      

     trigger 
      

        
        
        
      

     correlate event loss and event jitter 
      

        
        
        
      

     action 20 track set 20 state up

केवल एप्लेट को एक तार्किक और घटनाओं के बीच ट्रिगर किया जाता है। और ट्रैक को चार्ज किया जाता है।

यह देखा जा सकता है कि सर्वेक्षण 4 एस के अंतराल के साथ होता है और ट्रैक की वर्तमान स्थिति को ध्यान में नहीं रखा जाता है, अर्थात। गैंगवे लगातार आग, हर 4 जी। मैंने खुद ट्रैक की स्थिति पर नजर रखने की कोशिश की, लेकिन इसने बहुत काम किया, यह हमेशा काम नहीं करता था। इसलिए मैंने कुछ प्रतिशत दान दिया और इसे ऐसे ही छोड़ दिया।

इसके अतिरिक्त, चैनल पर समस्याओं और उनके लापता होने के बारे में मुझे सूचित करने वाले अधिक एप्लेट हैं:

event manager applet LB_info 
      

        
        
        
      

     event syslog pattern "20 stub Up->Down" 
      

        
        
        
      

     action 10 syslog msg "applet works!" 
      

        
        
        
      

     action 11 cli command "enable" 
      

        
        
        
      

     action 12 cli command "show ip sla stat 33" 
      

        
        
        
      

     action 13 mail server "192.168.6.20" to "ilya@tut_domen.ru" from "alert@tut_domen.ru" subject "Frame loss or high jitter on NiS channel" body "$_cli_result"

और

चर $ _cli_result में अंतिम कमांड के आउटपुट का परिणाम है, अर्थात। हमारे मामले में, आईपी एसएलए स्टेट 33 दिखाएँ।

event manager applet LB2_info 
      

        
        
        
      

     event syslog pattern "20 stub Down->Up" 
      

        
        
        
      

     action 10 syslog msg "applet 2 works!" 
      

        
        
        
      

     action 11 cli command "enable" 
      

        
        
        
      

     action 12 cli command "show ip sla stat 33" 
      

        
        
        
      

     action 13 mail server "192.168.6.20" to "ilya@tut_domen.ru" from "alert@tut_domen.ru" subject "NiS channel is correct" body "$_cli_result"

दूसरे शब्दों में, हम खुद को एक पत्र भेज रहे हैं, जिसके शरीर में एसएलए-मॉनीटर के अंतिम लॉन्च का परिणाम है, जो वास्तव में ट्रैक के स्विचिंग का कारण बना।

तो, अब वास्तव में इसे कैसे ध्यान में रखना है । मैं दो तरीके देखता हूं:

1. रूट-मैप में लाइन (जैसा कि यह मेरे लिए काम करता है, वास्तव में, लेकिन बस एक मुश्किल योजना है)

set ip next-hop verify-availability 172.16.1.66 1 track 20

2. ट्रैकिंग स्टैटिक्स जब हमारे पास फॉर्म का एक मार्ग है

ip route 172.16.0.0 255.255.255.0 192.168.1.1 track 20

चैनल पर नुकसान या घबराहट के मामले में, इस मार्ग को बस रूटिंग टेबल से हटा दिया जाएगा और यातायात वैकल्पिक मार्ग के साथ जाएगा।

शायद अनाड़ी, लेकिन मैं कुछ भी नहीं आया से बेहतर एक सप्ताह के लिए सताया। जैसा कि वे कहते हैं कि अमीर क्या है।

पीएस मेरा मतलब है कि पाठक सिस्को कंसोल की मूल बातें से थोड़ा परिचित है

PPS IP sla कमांड का सिंटैक्स 12.4T और 12.4 से भिन्न होता है, लेकिन अर्थ समान होता है।

पीपीएस यदि स्पष्टीकरण की आवश्यकता होती है जो कई लाइनों की सीमाओं से आगे नहीं जाते हैं - लिखो, मैं जोड़ूंगा।

निष्ठा से,

पोडकोपायेव इल्या

_________

UPD : CPU के बारे में। सामान्य तौर पर, एप्लेट के बिना लोड के तहत, मेरे पास औसतन लगभग 42% का एक राउटर लोड (ISR 3845) है, जिसमें एक एप्लेट - 43-44 है।

घबराना / पैकेट खो जाने से चैनल की स्थिति की निगरानी

More articles: