पारदर्शी फ़ायरवॉल पैकेट हानि का पता लगाना

19

हम एक लेयर 2 पारदर्शी मोड में सिस्को एएसए 5585 का उपयोग करते हैं। कॉन्फ़िगरेशन हमारे व्यापार भागीदार dmz और हमारे अंदर के नेटवर्क के बीच सिर्फ दो 10GE लिंक है। एक साधारण नक्शा इस तरह दिखता है।

10.4.2.9/30                    10.4.2.10/30
core01-----------ASA1----------dmzsw

एएसए में 8.2 (4) और एसएसपी 20 है। स्विच 12.2 के साथ 6500 Sup2T हैं। किसी भी स्विच या एएसए इंटरफ़ेस पर कोई पैकेट ड्रॉप नहीं हैं !! हमारा अधिकतम ट्रैफ़िक स्विच के बीच लगभग 1.8Gbps है और ASA पर CPU लोड बहुत कम है।

हमें एक अजीब समस्या है। हमारे nms व्यवस्थापक को बहुत खराब पैकेट हानि दिखाई देती है जो जून में किसी समय शुरू हुई थी। पैकेट का नुकसान बहुत तेजी से बढ़ रहा है, लेकिन हम नहीं जानते कि क्यों। फ़ायरवॉल के माध्यम से ट्रैफ़िक निरंतर बना हुआ है, लेकिन पैकेट हानि जल्दी से बढ़ रही है। ये फ़ायरवॉल के माध्यम से हम देखते हैं कि नगियोस पिंग विफलताओं हैं। नागिओस हर सर्वर पर 10 पिंग्स भेजता है। सभी विफलताओं में से कुछ सभी पिंग को ढीला करती हैं, सभी विफलताओं को सभी दस पिंग को ढीला नहीं करती हैं।

यहाँ छवि विवरण दर्ज करें

अजीब बात यह है कि अगर हम नगिओस सर्वर से mtr का उपयोग करते हैं, तो पैकेट का नुकसान बहुत बुरा नहीं है।

                             My traceroute  [v0.75]
nagios    (0.0.0.0)                                    Fri Jul 19 03:43:38 2013
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                  Packets               Pings
 Host                           Loss%   Snt Drop   Last  Best   Avg  Wrst StDev
 1. 10.4.61.1                    0.0%  1246    0    0.4   0.3   0.3  19.7   1.2
 2. 10.4.62.109                  0.0%  1246    0    0.2   0.2   0.2   4.0   0.4
 3. 10.4.62.105                  0.0%  1246    0    0.4   0.4   0.4   3.6   0.4
 4. 10.4.62.37                   0.0%  1246    0    0.5   0.4   0.7  11.2   1.7
 5. 10.4.2.9                     1.3%  1246   16    0.8   0.5   2.1  64.8   7.9
 6. 10.4.2.10                    1.4%  1246   17    0.9   0.5   3.5 102.4  11.2
 7. dmz-server                   1.1%  1246   13    0.6   0.5   0.6   1.6   0.2

जब हम स्विच के बीच पिंग करते हैं, तो हम कई पैकेट ढीले नहीं करते हैं, लेकिन यह स्पष्ट है कि समस्या स्विच के बीच कहीं शुरू होती है।

core01#ping ip 10.4.2.10 repeat 500000

Type escape sequence to abort.
Sending 500000, 100-byte ICMP Echos to 10.4.2.10, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (499993/500000), round-trip min/avg/max = 1/2/6 ms
core01#

हम कैसे कई पिंग विफलताओं और इंटरफेस पर कोई पैकेट नहीं छोड़ सकते हैं? हम यह कैसे पता लगा सकते हैं कि समस्या कहां है? सिस्को टीएसी इस समस्या पर हलकों में जा रहा है, वे इतने सारे अलग-अलग स्विच से शो टेक मांगते रहते हैं और यह स्पष्ट है कि समस्या betwen core01 और dmzsw है। क्या कोई मदद कर सकता है?

अद्यतन जुलाई ३०, २०१३

समस्या को सुलझाने में मेरी मदद करने के लिए सभी को धन्यवाद। यह एक दुर्व्यवहारपूर्ण अनुप्रयोग था जिसने एक समय में लगभग 10 सेकंड के लिए बहुत सारे छोटे यूडीपी पैकेट भेजे। इन पैकेटों को फ़ायरवॉल द्वारा अस्वीकार कर दिया गया था। ऐसा लगता है कि मेरा प्रबंधक हमारे एएसए को अपग्रेड करना चाहता है, इसलिए हमें फिर से यह समस्या नहीं है।

अधिक जानकारी

टिप्पणियों में प्रश्नों से:

ASA1# show inter detail | i ^Interface|overrun|error
Interface GigabitEthernet0/0 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/1 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/2 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/3 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/4 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/5 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/6 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/7 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface Internal-Data0/0 "", is up, line protocol is up
     2749335943 input errors, 0 CRC, 0 frame, 2749335943 overrun, 0 ignored, 0 abort
         0 output errors, 0 collisions, 0 interface resets
           RX[00]: 156069204310 packets, 163645512578698 bytes, 0 overrun
           RX[01]: 185159126458 packets, 158490838915492 bytes, 0 overrun
           RX[02]: 192344159588 packets, 197697754050449 bytes, 0 overrun
           RX[03]: 173424274918 packets, 196867236520065 bytes, 0 overrun
Interface Internal-Data1/0 "", is up, line protocol is up
    26018909182 input errors, 0 CRC, 0 frame, 26018909182 overrun, 0 ignored, 0 abort
    0 output errors, 0 collisions, 0 interface resets
           RX[00]: 194156313803 packets, 189678575554505 bytes, 0 overrun
           RX[01]: 192391527307 packets, 184778551590859 bytes, 0 overrun
           RX[02]: 167721770147 packets, 179416353050126 bytes, 0 overrun
           RX[03]: 185952056923 packets, 205988089145913 bytes, 0 overrun
Interface Management0/0 "Mgmt", is up, line protocol is up
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface Management0/1 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface TenGigabitEthernet0/8 "Inside", is up, line protocol is up
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface TenGigabitEthernet0/9 "DMZ", is up, line protocol is up
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets

ASA1#
cisco  switch  cisco-asa  firewall  packet-loss 
— user2096
स्रोत
क्या पैकेट का नुकसान तब होता है जब यातायात का स्तर चरम पर होता है? क्या इससे पहले यह पर्यावरण कभी मुक्त हुआ है? इस प्रकार से समस्या निवारण के लिए क्या किया गया है?
— DrBru
ट्रैफिक का स्तर मायने नहीं रखता। पैकेट नुकसान तब होता है जब फ़ायरवॉल के माध्यम से यातायात कम या अधिक होता है। हमारे पास एक सप्ताह के लिए टीएसी के साथ एक मामला खुला है और वे किसी भी इंटरफ़ेस पर पैकेट नुकसान नहीं पा सकते हैं। स्विच या फ़ायरवॉल पर सीपीयू की कोई समस्या नहीं है। हमारे पास लगभग एक वर्ष के लिए dmz था और पैकेट का नुकसान केवल पिछले महीने या इसके बाद शुरू हुआ था।
— user2096
हाय दोस्त, क्या आप दोनों एएसए इंटरफेस में से किसी पर IPS सक्षम हैं? मुझे विश्वास है कि हम अपराधी को ढूंढ सकते हैं।
— लाफ
2
Mtr की जानकारी के आधार पर, और आप बिना किसी समस्या के स्विच के बीच पिंग कर सकते हैं, मैं यह पेशकश करूँगा कि समस्या आपके core1 स्विच और इसके अगले भाग के बीच आपके nms की ओर है।
— सैंटिनो
2
@ सैंटिनो, यह कहना समय से पहले की बात है कि क्या यह कोर 01 के अपस्ट्रीम में नुकसान है, या कहीं और इसके बीच में है। user2096, के उत्पादन में पोस्ट करें show interface detail | i ^Interface|overrun|errorऔर show resource usageफ़ायरवॉल पर
— माइक पेनिंगटन

जवाबों:

8 
Interface Internal-Data0/0 "", is up, line protocol is up
     2749335943 input errors, 0 CRC, 0 frame, 2749335943 overrun, 0 ignored, 0 abort
                                              ^^^^^^^^^^^^^^^^^^
         0 output errors, 0 collisions, 0 interface resets

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

EDIT टिप्पणियों में एक सवाल का जवाब देने के लिए :

मुझे समझ नहीं आता कि फ़ायरवॉल क्यों अतिभारित है, यह 10Gbps का उपयोग करने के करीब नहीं है। क्या आप बता सकते हैं कि सीपीयू और बैंडविड्थ कम होने पर भी हम ओवररन क्यों देख रहे हैं? CPU लगभग 5% है और बैंडविड्थ या तो दिशा कभी भी 1.4Gbps से अधिक नहीं होती है।

मैंने ऐसा तब देखा है जब एक लिंक ट्रैफिक माइक्रोबर्स्ट को देख रहा है , जो डिवाइस के बैंडविड्थ, कनेक्शन-प्रति-सेकंड, या पैकेट-प्रति-सेकंड प्रति सेकंड से अधिक है। इतने सारे लोग 1 या 5 मिनट के आंकड़े उद्धृत करते हैं जैसे कि यातायात उस समय सीमा में अपेक्षाकृत स्थिर है।

मैं हर दो या तीन सेकंड में इन कमांडों को चलाकर आपके फ़ायरवॉल पर नज़र term pager 0डालूँगा ( पेजिंग मुद्दों से बचने के लिए) ...

show clock
show traffic detail | i ^[a-zA-Z]|overrun|packets dropped
show asp drop

अब यह देखें कि आप हर कुछ सेकंड में कितनी ट्रैफ़िक देख रहे हैं; यदि आप अपने ट्रैफ़िक स्पाइक्स के दौरान पॉलिसी ड्रॉप्स या ओवररन में बड़े पैमाने पर स्पाइक्स देखते हैं, तो आप अपराधी को खोजने के करीब हैं।

यह मत भूलो कि आप एएसए पर सीधे तौर पर सूँघ सकते हैं यदि आपको यह पहचानने में मदद की आवश्यकता है कि एएसए को मारना क्या है ... आपको इसे कभी-कभी पकड़ने के लिए जल्दी होना होगा।

capture FOO circular-buffer buffer <buffer-size> interface <intf-name>

आपके अपस्ट्रीम स्विच पर नेटफ्लो मदद कर सकता है।

— माइक पेनिंगटन
स्रोत
मिठाई! 'शो इंट डिटेल' ~ के बारे में जानकारी के लिए thanx ~
— नाचोस
हमारे इंटेरडेटा ओवररन बहुत तेज़ी से बढ़ रहे हैं, इसलिए यह समस्या की तरह दिखता है। लेकिन मुझे समझ में नहीं आ रहा है कि क्यों फ़ायरवॉल अतिभारित है, यह 10 जीबीपीएस का उपयोग करने के करीब नहीं है। क्या आप बता सकते हैं कि सीपीयू और बैंडविड्थ कम होने पर भी हम ओवररन क्यों देख रहे हैं? सीपीयू लगभग 5% है और बैंडविड्थ या तो दिशा कभी भी 1.4Gbps से अधिक नहीं जाती है।
— user2096
@ user2096, मैंने जवाब देने के लिए अपना उत्तर संपादित किया ...
— माइक पेनिंगटन
यह समझ में नहीं आता है - यह एक पारदर्शी फ़ायरवॉल है, जिसमें 10GE और 10GE बाहर है। आंतरिक डेटापाठ 10GE के लिए रेट नहीं किया गया है? एक उत्पाद डिजाइन विफलता की तरह लगता है।
— निकोटीन
2
@nicotine, ओपी ने एक SSP-20 खरीदा और SSP-20 आंतरिक रूप से 5Gbps (रेफरी सिस्को डेटा शीट ) से अधिक तक सीमित नहीं है । यदि आप पूर्ण 10Gbps फ़ायरवॉल चाहते हैं, तो आपको एक और विकल्प खरीदना होगा (शायद SSP-60, यदि CPS एक समस्या है)। यह केवल एक डिज़ाइन विफलता है यदि आप बॉक्स की आंतरिक बफरिंग क्षमता से अधिक है। मैंने ऐसे उपयोग-मामलों को देखा है जहां 10GE के साथ एक एसएसपी -20 ठीक है।
— माइक पेनिंगटन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.