স্বচ্ছ ফায়ারওয়াল প্যাকেটের ক্ষতি অনুসন্ধান করা


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 সুপ 2 টি। কোনও সুইচ বা এএসএ ইন্টারফেসে কোনও প্যাকেট ড্রপ নেই !! আমাদের সর্বোচ্চ ট্র্যাফিকটি সুইচগুলির মধ্যে প্রায় 1.8 জিবিপিএস এবং এএসএতে সিপিইউ লোড খুব কম।

আমাদের একটা অদ্ভুত সমস্যা আছে। আমাদের এনএমএস প্রশাসক খুব খারাপ প্যাকেটের ক্ষতি দেখতে পান যা জুনের কিছু সময় শুরু হয়েছিল। প্যাকেটের ক্ষতি খুব দ্রুত বাড়ছে, তবে কেন তা আমরা জানি না। ফায়ারওয়ালের মাধ্যমে ট্র্যাফিক স্থির থাকে, তবে প্যাকেটের ক্ষতি খুব দ্রুত বাড়ছে। এই ফায়ারওয়ালের মাধ্যমে আমরা দেখতে পাই নাগিওস পিং ব্যর্থতা। নাগিও প্রতিটি সার্ভারে 10 টি পিং পাঠায়। কিছু ব্যর্থতা সমস্ত পিংগুলি আলগা করে, সমস্ত ব্যর্থতা সমস্ত দশ পিংগুলি looseিলে করে না।

এখানে চিত্র বর্ণনা লিখুন

আশ্চর্যের বিষয় হ'ল আমরা যদি নাগিও সার্ভার থেকে এমটিআরটি ব্যবহার করি তবে প্যাকেটের ক্ষতি খুব খারাপ নয়।

                             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#

ইন্টারফেসে আমরা কীভাবে এতগুলি পিং ব্যর্থতা এবং প্যাকেট ড্রপ করতে পারি না? সমস্যাটি কীভাবে আমরা খুঁজে পাব? সিসকো টিএসি এই সমস্যাটি নিয়ে চেনাশোনাগুলিতে চলেছে, তারা এতগুলি ভিন্ন ভিন্ন সুইচ থেকে শো টেকের জন্য জিজ্ঞাসা করে রাখে এবং এটি স্পষ্টতই সমস্যা যে কোরওট 01 এবং dmzsw রয়েছে। কেউ সাহায্য করতে পারেন?

30 জুলাই, 2013 আপডেট করুন

সমস্যাটি খুঁজে পেতে আমাকে সহায়তা করার জন্য সকলকে ধন্যবাদ। এটি একটি দুর্ব্যবহারকারী অ্যাপ্লিকেশন যা একবারে প্রায় 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#

ট্র্যাফিকের স্তর যখন শীর্ষে উঠছে তখন কি প্যাকেটের ক্ষতির সাথে মিল রয়েছে? এই পরিবেশ কি এর আগে কখনও ইস্যু মুক্ত ছিল? এখন পর্যন্ত সমস্যা সমাধানের জন্য কী করা হয়েছে?
ডাঃব্রু

ট্র্যাফিকের স্তরগুলি কোনও বিষয় নয়। ফায়ারওয়ালের মাধ্যমে ট্রাফিক কম বা বেশি হলে প্যাকেটের ক্ষতি হয়। টিএসি-এর কাছে আমাদের এক সপ্তাহের জন্য কেস খোলা আছে এবং তারা কোনও ইন্টারফেসে প্যাকেট হারাতে পারে না। সুইচ বা ফায়ারওয়ালে কোনও সিপিইউ সমস্যা নেই। আমাদের প্রায় এক বছর ধরে ডিএমজেড ছিল এবং প্যাকেটের ক্ষতি কেবল গত মাসে বা তার মধ্যে শুরু হয়েছিল।
ব্যবহারকারী 2096

হাই সাথী, আপনি দুটি এএসএ ইন্টারফেসের কোনওটিতে আইপিএস সক্ষম করেছেন? আমি বিশ্বাস করি সেখানে আমরা অপরাধীকে খুঁজে পেতে পারি।
লাফ

2
এমআরটি তথ্যের উপর ভিত্তি করে এবং আপনি ইস্যু ছাড়াই সুইচগুলির মধ্যে পিং করতে পারেন, আমি প্রস্তাব দেব যে বিষয়টি আপনার কোর 1 সুইচ এবং এর পরবর্তী হ্যাপটি আপনার এনএমএসের মধ্যে রয়েছে।
সান্টিনো

2
@ সান্টিনো, এটি कोर01 এর প্রবাহিত ক্ষতি, না কোথাও এটির এবং ডিএমজেএসডব্লিউর মধ্যে কোথাও বলা অকাল। user2096, আউটপুট পোস্ট করুন show interface detail | i ^Interface|overrun|errorএবং show resource usageফায়ারওয়াল উপর
মাইক Pennington,

উত্তর:


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

আপনি দেখাতে overruns InternalData ইন্টারফেসের, তাই আপনি হয় এএসএ মাধ্যমে ট্রাফিক ড্রপ। অনেকগুলি ড্রপ সহ, এটি ভাবতে অসুবিধা হয় না যে এটি সমস্যায় অবদান রাখছে। অভ্যন্তরীণ আরএক্স ফিফোর সারিগুলি ওভারফ্লো হয়ে গেলে সাধারণত ঘটে থাকে (সাধারণত লোড নিয়ে কিছু সমস্যার কারণে)।

মন্তব্যগুলিতে একটি প্রশ্নের জবাব দিতে সম্পাদনা করুন :

আমি বুঝতে পারছি না যে ফায়ারওয়াল কেন অতিরিক্ত লোড হয়, এটি 10 ​​জিবিপিএস ব্যবহারের কাছাকাছি নয়। আপনি কি ব্যাখ্যা করতে পারেন যে সিপিইউ এবং ব্যান্ডউইথ কম থাকলেও আমরা কেন বাড়াবাড়ি দেখছি? সিপিইউ প্রায় 5% এবং ব্যান্ডউইথ উভয় দিকই কখনও 1.4 জিবিপিএসের চেয়ে বেশি যায় না।

কোনও লিঙ্কে ট্র্যাফিক মাইক্রোবার্টস দেখতে পেলে এটি ঘটতে দেখেছি এবং এটি ডিভাইসের ব্যান্ডউইথ, সংযোগ-প্রতি-সেকেন্ড বা প্যাকেট-প্রতি-সেকেন্ড অশ্বশক্তি অতিক্রম করে ower অনেক লোক 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>

আপনার উজানের সুইচগুলিতে নেটফ্লো পাশাপাশি সহায়তা করতে পারে।


মিষ্টি! 'প্রদর্শন বিশদ বিবরণ' সম্পর্কে তথ্যের জন্য
থেক্স

আমাদের অভ্যন্তরীণ ডেটা খুব দ্রুত বাড়ছে, সুতরাং এটি সমস্যার মতো দেখায়। তবে আমি বুঝতে পারি না যে ফায়ারওয়াল কেন অতিরিক্ত লোড হয়, এটি 10 ​​জিবিপিএস ব্যবহারের কাছাকাছি নয়। আপনি কি ব্যাখ্যা করতে পারেন যে সিপিইউ এবং ব্যান্ডউইথ কম থাকলেও আমরা কেন বাড়াবাড়ি দেখছি? সিপিইউ প্রায় 5% এবং ব্যান্ডউইথ উভয় দিকই কখনও 1.4 জিবিপিএসের চেয়ে বেশি যায় না।
ব্যবহারকারী 2096

@ ইউজার ২০৯,, আমি উত্তর দেওয়ার জন্য আমার উত্তর সম্পাদনা করেছি ...
মাইক পেনিংটন

এটি কোনও তাৎপর্যপূর্ণ বলে মনে হচ্ছে না - এটি একটি স্বচ্ছ ফায়ারওয়াল, 10 জিই ইন এবং 10 জিই আউট। অভ্যন্তরীণ ডেটাপথ 10GE এর জন্য রেট করা হয়নি? একটি পণ্য নকশা ব্যর্থতা মনে হচ্ছে।
নিকোটিন

2
@ নোটোটিন, ওপি একটি এসএসপি -20 কিনেছিল এবং এসএসপি -20 অভ্যন্তরীণভাবে 5 জিবিপিএস (রেফারেন্স সিসকো ডেটা শিট ) এর মধ্যে সীমাবদ্ধ নয় । আপনি যদি একটি পূর্ণ 10 জিবিপিএস ফায়ারওয়াল চান তবে আপনাকে অন্য একটি বিকল্প কিনতে হবে (এমনকি এসএসপি -60, যদি সিপিএসের সমস্যা হয়)। আপনি যদি বাক্সটির অভ্যন্তরীণ বাফারিং ক্ষমতাটি ছাড়িয়ে যান তবে এটি কেবল একটি ডিজাইনের ব্যর্থতা। আমি ব্যবহারের ক্ষেত্রে দেখেছি যেখানে 10GE সহ একটি এসএসপি -20 ঠিক আছে।
মাইক পেনিংটন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.