Tìm mất gói tường lửa trong suốt

Chúng tôi sử dụng Cisco ASA 5585 ở chế độ trong suốt layer2. Cấu hình chỉ là hai liên kết 10GE giữa dmz đối tác kinh doanh của chúng tôi và mạng bên trong của chúng tôi. Một bản đồ đơn giản trông như thế này.

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

ASA có 8.2 (4) và SSP20. Các công tắc là 6500 Sup2T với 12.2. Không có gói tin nào bị rơi trên bất kỳ công tắc hay giao diện ASA nào !! Lưu lượng tối đa của chúng tôi là khoảng 1,8Gbps giữa các thiết bị chuyển mạch và tải CPU trên ASA là rất thấp.

Chúng tôi có một vấn đề kỳ lạ. Quản trị viên nms của chúng tôi thấy mất gói rất tệ bắt đầu vào tháng 6. Mất gói đang tăng rất nhanh, nhưng chúng tôi không biết tại sao. Lưu lượng truy cập thông qua tường lửa vẫn không đổi, nhưng mất gói đang tăng nhanh. Đây là những lỗi ping nagios mà chúng ta thấy thông qua tường lửa. Nagios gửi 10 ping đến mọi máy chủ. Một số thất bại làm mất tất cả các ping, không phải tất cả các thất bại đều mất tất cả mười ping.

nhập mô tả hình ảnh ở đây

Điều kỳ lạ là nếu chúng ta sử dụng mtr từ máy chủ nagios, việc mất gói không quá tệ.

                             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

Khi chúng ta ping giữa các công tắc, chúng ta không mất nhiều gói, nhưng rõ ràng vấn đề bắt đầu ở đâu đó giữa các công tắc.

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#

Làm thế nào chúng ta có thể có rất nhiều lỗi ping và không có gói tin nào bị rơi trên các giao diện? Làm thế nào chúng ta có thể tìm thấy vấn đề là ở đâu? Cisco TAC đang gặp rắc rối về vấn đề này, họ liên tục yêu cầu trình diễn công nghệ từ rất nhiều thiết bị chuyển mạch khác nhau và rõ ràng vấn đề là betwen core01 và dmzsw. Ai đó có thể giúp gì không?

Cập nhật ngày 30 tháng 7 năm 2013

Cảm ơn mọi người đã giúp tôi tìm ra vấn đề. Đó là một ứng dụng hoạt động sai đã gửi rất nhiều gói UDP nhỏ trong khoảng 10 giây một lần. Những gói tin này đã bị tường lửa từ chối. Có vẻ như người quản lý của tôi muốn nâng cấp ASA của chúng tôi để chúng tôi không gặp vấn đề này nữa.

Thêm thông tin

Từ các câu hỏi trong các ý kiến:

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#

— người dùng2096
nguồn

Liệu mất gói có trùng với khi mức lưu lượng đang đạt đỉnh? môi trường này đã bao giờ được phát hành miễn phí trước đây chưa? những gì đã được thực hiện để khắc phục sự cố cho đến nay?

— DrBru

Mức độ giao thông không quan trọng. Mất gói xảy ra khi lưu lượng truy cập qua tường lửa thấp hoặc cao. Chúng tôi có một trường hợp mở với TAC trong một tuần và họ không thể tìm thấy mất gói trên bất kỳ giao diện nào. Không có vấn đề CPU trên thiết bị chuyển mạch hoặc tường lửa. Chúng tôi đã có dmz trong gần một năm và mất gói chỉ bắt đầu trong tháng trước hoặc lâu hơn.

— dùng2096

Xin chào, Bạn có bật IPS trên một trong hai giao diện ASA không? Tôi tin rằng chúng ta có thể tìm ra thủ phạm.

— LAF

Dựa trên thông tin mtr và bạn có thể ping giữa các công tắc mà không gặp sự cố, tôi đề nghị rằng vấn đề nằm giữa công tắc core1 của bạn và bước nhảy tiếp theo của nó đối với nms của bạn.

— Santino

@Santino, thật sớm để nói liệu đây có phải là sự mất mát của core01 hay ở đâu đó giữa nó và dmzsw. user2096, vui lòng đăng kết quả đầu ra show interface detail | i ^Interface|overrun|errorvà show resource usagetrên tường lửa

— Mike Pennington

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

Bạn hiển thị vượt mức trên các giao diện InternalData, vì vậy bạn sẽ giảm lưu lượng truy cập thông qua ASA. Với rất nhiều giọt, không khó để tưởng tượng rằng điều này đang góp phần gây ra vấn đề. Tràn ngập xảy ra khi hàng đợi Rx FIFO bên trong tràn (thông thường do một số vấn đề với tải).

EDIT để trả lời một câu hỏi trong các ý kiến :

Tôi không hiểu tại sao tường lửa bị quá tải, nó không gần với việc sử dụng 10Gbps. Bạn có thể giải thích lý do tại sao chúng ta đang nhìn thấy vượt mức ngay cả khi CPU và băng thông thấp? CPU là khoảng 5% và băng thông theo hướng không bao giờ cao hơn 1,4Gbps.

Tôi đã thấy điều này xảy ra lặp đi lặp lại khi một liên kết đang nhìn thấy các vi mạch lưu lượng , vượt quá băng thông, kết nối mỗi giây hoặc mã lực mỗi giây của thiết bị. Vì vậy, nhiều người trích dẫn số liệu thống kê 1 hoặc 5 phút như thể lưu lượng truy cập tương đối ổn định trong khung thời gian đó.

Tôi sẽ xem xét tường lửa của bạn bằng cách chạy các lệnh này cứ sau hai hoặc ba giây (chạy term pager 0để tránh các vấn đề về phân trang) ...

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

Bây giờ hãy vẽ biểu đồ lưu lượng truy cập mà bạn nhìn thấy cứ sau vài giây so với giọt; nếu bạn thấy các đột biến lớn trong chính sách giảm hoặc vượt mức khi lưu lượng truy cập tăng đột biến, thì bạn sẽ tiến gần hơn đến việc tìm ra thủ phạm.

Đừng quên rằng bạn có thể đánh hơi trực tiếp trên ASA bằng điều này nếu bạn cần trợ giúp để xác định những gì đang giết chết ASA ... đôi khi bạn phải nhanh chóng nắm bắt được điều này.

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

Netflow trên thiết bị chuyển mạch ngược dòng của bạn cũng có thể giúp đỡ.

— Mike Pennington
nguồn

ngọt! thanx để biết thông tin về 'hiển thị chi tiết int' ~

— Nachos

Tràn ngập internaldata của chúng tôi đang tăng rất nhanh, vì vậy điều này có vẻ như là vấn đề. NHƯNG tôi không hiểu tại sao tường lửa bị quá tải, nó không gần với việc sử dụng 10Gbps. Bạn có thể giải thích lý do tại sao chúng ta đang nhìn thấy vượt mức ngay cả khi CPU và băng thông thấp? CPU là khoảng 5% và băng thông theo hướng không bao giờ cao hơn 1,4Gbps.

— dùng2096

@ user2096, tôi đã chỉnh sửa câu trả lời của mình để trả lời ...

— Mike Pennington

Điều này dường như không có ý nghĩa - đó là một tường lửa trong suốt, với 10GE trong và 10GE. Bảng dữ liệu nội bộ không được xếp hạng cho 10GE? Có vẻ như một thất bại thiết kế sản phẩm.

— nicotine

@nicotine, OP đã mua SSP-20 và SSP-20 bị giới hạn bên trong không quá 5Gbps ( Bảng dữ liệu của Cisco ). Nếu bạn muốn có tường lửa 10Gbps đầy đủ, bạn phải mua một tùy chọn khác (thậm chí có thể là SSP-60, nếu CPS là một vấn đề). Nó chỉ là một lỗi thiết kế nếu bạn vượt quá khả năng đệm bên trong của hộp. Tôi đã thấy các trường hợp sử dụng trong đó SSP-20 với 10GE là tốt.

— Mike Pennington