การค้นหาการสูญเสียแพ็กเก็ตไฟร์วอลล์แบบโปร่งใส

19

เราใช้ 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 ที่เราเห็นผ่านไฟร์วอลล์ Nagios ส่ง 10 ปิงไปยังเซิร์ฟเวอร์ทุกเครื่อง ความล้มเหลวบางส่วนทำให้สูญเสียการ Ping ทั้งหมดไม่ใช่ความล้มเหลวทั้งหมดที่สูญเสียการส่ง Ping ทั้งหมดสิบครั้ง

ป้อนคำอธิบายรูปภาพที่นี่

สิ่งที่แปลกคือถ้าเราใช้ mtr จากเซิร์ฟเวอร์ nagios การสูญเสียแพ็กเก็ตนั้นไม่เลวร้ายนัก

                             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

เมื่อเรา ping ระหว่างสวิตช์เราไม่หลวมหลายแพ็กเก็ต แต่เห็นได้ชัดว่าปัญหาเริ่มขึ้นระหว่างสวิตช์

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#

เราจะมีความล้มเหลวในการ ping จำนวนมากได้อย่างไรและไม่มีแพ็กเก็ตตกลงบนอินเตอร์เฟส? เราจะพบปัญหาได้อย่างไร Cisco TAC กำลังเป็นวงกลมในปัญหานี้พวกเขายังคงถามหาเทคโนโลยีการแสดงจากสวิตช์ที่แตกต่างกันมากมายและเห็นได้ชัดว่าปัญหานั้นเกิดขึ้นระหว่าง core01 และ dmzsw ใครช่วยได้บ้าง

อัปเดต 30 กรกฎาคม 2556

ขอบคุณทุกคนที่ช่วยฉันหาปัญหา มันเป็นแอปพลิเคชันที่ทำงานผิดปกติซึ่งส่งแพ็คเก็ต UDP ขนาดเล็กจำนวนมากเป็นเวลาประมาณ 10 วินาทีในแต่ละครั้ง แพ็กเก็ตเหล่านี้ถูกปฏิเสธโดยไฟร์วอลล์ ดูเหมือนว่าผู้จัดการของฉันต้องการอัปเกรด ASA ของเราดังนั้นเราจึงไม่มีปัญหานี้อีก

ข้อมูลมากกว่านี้

จากคำถามในความคิดเห็น:

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
ระดับการจราจรไม่สำคัญ การสูญหายของแพ็คเก็ตเกิดขึ้นเมื่อทราฟฟิกผ่านไฟร์วอลล์ต่ำหรือสูง เรามีกรณีเปิดกับ TAC เป็นเวลาหนึ่งสัปดาห์และพวกเขาไม่สามารถหาแพ็กเก็ตที่สูญหายได้ในส่วนต่อประสานใด ๆ ไม่มีปัญหา CPU เกี่ยวกับสวิตช์หรือไฟร์วอลล์ เรามี dmz เป็นเวลาเกือบปีและการสูญเสียแพ็กเก็ตเริ่มต้นในเดือนที่แล้วเท่านั้น
— user2096
สวัสดีคุณเปิดใช้งาน IPS บนทั้งสองอินเทอร์เฟซ ASA หรือไม่ ฉันเชื่อว่ามีเราอาจพบผู้กระทำผิด
— laf
2
จากข้อมูล mtr และคุณสามารถ ping ระหว่างสวิตช์ที่ไม่มีปัญหาฉันขอเสนอว่าปัญหาระหว่างสวิตช์ core1 ของคุณกับการกระโดดครั้งต่อไปที่ nms ของคุณ
— Santino
2
@Santino มันเร็วเกินไปที่จะบอกว่านี่คือการสูญเสีย upstream ของ core01 หรือบางแห่งระหว่างมันกับ dmzsw user2096 โปรดโพสต์ผลลัพธ์ของshow interface detail | i ^Interface|overrun|errorและshow resource usageบนไฟร์วอลล์
— Mike 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

คุณแสดงโอเวอร์รันบนอินเทอร์เฟซ InternalData ดังนั้นคุณจึงลดทราฟฟิกผ่าน ASA เมื่อหยดลงหลายครั้งมันก็ไม่ยากที่จะจินตนาการว่านี่จะช่วยแก้ปัญหาได้ การโอเวอร์รันเกิดขึ้นเมื่อ Rx FIFO ภายในคิวล้น (ปกติเนื่องจากปัญหาบางอย่างกับโหลด)

แก้ไขเพื่อตอบคำถามในความคิดเห็น :

ฉันไม่เข้าใจว่าเพราะเหตุใดไฟร์วอลล์จึงโอเวอร์โหลดมันไม่ใกล้เคียงกับการใช้ 10Gbps คุณช่วยอธิบายได้ไหมว่าทำไมเราถึงเห็นว่าโอเวอร์ซีถึงแม้ว่า CPU และแบนด์วิดธ์ต่ำ? ซีพียูประมาณ 5% และแบนด์วิดท์ทั้งสองทิศทางไม่เคยสูงกว่า 1.4Gbps มากนัก

ฉันได้เห็นสิ่งนี้เกิดขึ้นซ้ำแล้วซ้ำอีกเมื่อมีการเชื่อมโยงที่เห็นmicrobursts การจราจรซึ่งเกินกว่าแบนด์วิดธ์การเชื่อมต่อต่อวินาทีหรือแรงม้าแพ็คเก็ตต่อวินาทีของอุปกรณ์ หลายคนอ้างราคาสถิติ 1 หรือ 5 นาทีราวกับว่าปริมาณการใช้ข้อมูลค่อนข้างคงที่ในช่วงเวลานั้น

ฉันจะดูไฟร์วอลล์ของคุณโดยใช้คำสั่งเหล่านี้ทุกสองหรือสามวินาที (เรียกใช้term pager 0เพื่อหลีกเลี่ยงปัญหาการเพจ) ...

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

ทีนี้กราฟปริมาณการรับส่งข้อมูลที่คุณเห็นทุกสองสามวินาทีเทียบกับการลดลง หากคุณเห็นหนามแหลมขนาดใหญ่ในนโยบายลดลงหรือถูกบุกรุกเมื่อทราฟฟิกพุ่งเข้ามาคุณก็จะพบผู้ร้ายมากขึ้น

อย่าลืมว่าคุณสามารถสูดดม ASA โดยตรงได้หากคุณต้องการความช่วยเหลือในการระบุว่ากำลังฆ่า ASA ... คุณต้องรีบจับมันในบางครั้ง

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

Netflow บนสวิตช์ต้นน้ำของคุณอาจช่วยได้เช่นกัน

— ไมค์เพนนิงตัน
แหล่งที่มา
หวาน! ขอบคุณสำหรับข้อมูลเกี่ยวกับ 'แสดงรายละเอียด int' ~
— Nachos
การรุกล้ำของเราเพิ่มขึ้นอย่างรวดเร็วดังนั้นนี่จึงเป็นปัญหา แต่ฉันไม่เข้าใจว่าเพราะเหตุใดไฟร์วอลล์จึงโอเวอร์โหลดมันไม่ใกล้เคียงกับการใช้ 10Gbps คุณช่วยอธิบายได้ไหมว่าทำไมเราถึงเห็นว่าโอเวอร์ซีถึงแม้ว่า CPU และแบนด์วิดธ์ต่ำ? ซีพียูประมาณ 5% และแบนด์วิดท์ทั้งสองทิศทางไม่เคยสูงกว่า 1.4Gbps มากนัก
— user2096
@ user2096 ฉันแก้ไขคำตอบของฉันเพื่อตอบ ...
— Mike Pennington
สิ่งนี้ดูเหมือนจะไม่สมเหตุสมผล - มันเป็นไฟร์วอลล์โปร่งใสที่มี 10GE ในและ 10GE ดาต้าแพทภายในไม่ได้รับการจัดอันดับสำหรับ 10GE หรือไม่ ดูเหมือนว่าความล้มเหลวในการออกแบบผลิตภัณฑ์
— นิโคติน
2
@ นิโคติน OP ซื้อ SSP-20 และ SSP-20 ถูก จำกัด ภายในไม่เกิน 5Gbps (อ้างอิงแผ่นข้อมูลของ Cisco ) หากคุณต้องการไฟร์วอลล์ 10Gbps เต็มคุณจะต้องซื้อตัวเลือกอื่น (อาจเป็น SSP-60 หาก CPS เป็นปัญหา) มันเป็นเพียงความล้มเหลวในการออกแบบถ้าคุณเกินขีดความสามารถในการบัฟเฟอร์ภายในของกล่อง ฉันได้เห็นกรณีใช้งานที่ SSP-20 พร้อม 10GE นั้นใช้ได้
— Mike Pennington
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.