ifconfig eth0 RX скинув пакети


16

Проблема

Команда ifconfig показує все більше і більше скинутих пакетів у розділі RX. Тож, мабуть, є проблема з деякими пакетами, які надходять з Інтернету на мій сервер.

Питання

  1. Які пакети враховує цей лічильник крапель? Чи потрібно, щоб усі пакети, що надходять, до досягнення брандмауера iptables або після прийняття пакетів iptables?

  2. Як вирішити ситуацію, щоб лічильник пакетів крапель ipconfig перестав збільшуватися?

Корисна інформація щодо усунення несправностей

Оскільки я не знаю, у чому полягає моя проблема, сміливо попросіть мене заповнити цей розділ, якщо ви думаєте, що потрібна ще якась інша інформація.

ifconfig

eth0      Link encap:Ethernet  HWaddr 00:cc:cc:cc:cc:cc  
          inet adr:90.0.0.2  Bcast:90.0.0.255  Masque:255.255.255.0
          adr inet6: fe80::21c:c0ff:feb9:829c/64 Scope:Lien
          adr inet6: 2001:a100:1:bbbb::1/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:113264620 errors:0 dropped:2523 overruns:0 frame:0
          TX packets:168526529 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          RX bytes:59171827564 (55.1 GiB)  TX bytes:223993117711 (208.6 GiB)

Зверніть увагу на " випав: 2523 " у розділі RX. Це найважливіше. Ця кількість постійно зростає.

ip -4 показ маршруту

default via 90.0.0.254 dev eth0 
90.0.0.0/24 dev eth0  proto kernel  scope link  src 90.0.0.2

ip -6 показ маршруту

2001:a100:1:bbbb::1/64 dev eth0  proto kernel  metric 256 
fe80::/64 dev eth0  proto kernel  metric 256 
default via 2001:a100:1:bbff:ff:ff:ff:ff dev eth0  metric 1024

munin графік плагіна if_err_eth0_day

введіть тут опис зображення


1
ifconfigбуде перед брандмауером. Вони є статистикою на рівні інтерфейсу. Це посилання може запропонувати один варіант усунення несправностей.
ПП.

Я вже пробував це, на жаль відповідьRing parameters for eth0: Cannot get device ring settings: Operation not supported
Фокс

Ви скидаєте 0,002% вхідних пакетів. Чому ти турбуєшся про це?
freiheit

3
Тому що цього раніше не сталося і раптом почалося. Хороша конфігурація показує пакет, що випав ZERO (вони повинні бути відкинуті пізніше, якщо потрібно, брандмауером). Є втрата інформації, яка повинна дійти до мого сервера, і я хочу знати, чому.
Фокс

1
@Fox: Чи знайшли ви причину падіння пакетів? Я зіткнувся з тією ж проблемою на своєму новому rooter-сервері.
Biggie

Відповіді:


10

http://www.novell.com/support/kb/doc.php?id=7007165

Починаючи з ядра 2.6.37, було змінено значення кількості скинутих пакетів. Раніше скинуті пакети, швидше за все, були через помилку. Тепер лічильник rx_dropped показує статистику для скинутих кадрів через:

  • Забій Softnet повний
  • Неправильні / ненавмисні теги VLAN
  • Невідомі / незареєстровані протоколи
  • IPv6 кадри, коли сервер не налаштований для IPv6

[...]

Якщо лічильник rx_dropped припиняє збільшуватися під час роботи tcpdump; то більш ніж ймовірно виявляти краплі через причини, перелічені раніше.


Що робити, якщо він збільшується?
Жан-Поль Кальдероне

1
"" "Використовуйте ethtool -S, щоб підтвердити відсутність фактичних помилок на інтерфейсах." "" Source access.redhat.com/solutions/657483
bgtvfr

2

Я теж намагався відшукати цю проблему безрезультатно. Я також помітив падіння пакетів RX зі швидкістю близько однієї секунди на моїй коробці Ubuntu 12. Під час пошуку я знайшов людей з подібними проблемами на різних інших платформах Linux, SUSE, Rpi та інших. Схоже, щось із ядром Linux. Ще кілька цікавих підказок, які я помітив, змушують проблему зникнути тимчасово, але не зовсім пояснення.

  1. Якщо я зміню конфігурацію зі статичної на DHCP в інтерфейсах / etc / network / interface, то RX-пакети краплі припиняються.

  2. Якщо я запускаю tcpdump, пакети крапель припиняються під час роботи дампа і повертаються, коли я його зупиняю.

Можливо, ці підказки допоможуть дійти до цього?

В цілому моя мережева продуктивність виглядає просто чудово, цікаво, чому це теж відбувається.


Те саме тут, супер послідовна швидкість 1 / с (здається, вони приходять групами по 2 кожну другу секунду, але не цитуйте мене про це, поки я не можу їх реально спостерігати), і коли я запускаю tcpdump, раптом більше не виникає проблем для тривалість захоплення пакету. Також з --no-promiscuous-modeним все ще вирішується питання Oo
Luc
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.