LVS-TUN: ifconfig показывает ошибки и коллизии для интерфейса tunl0?

Check_MK прислал мне электронное письмо следующего содержания:

***** Nagios *****

Notification Type: PROBLEM

Service: Interface 5
Host: foo
Address: x.y.z.t
State: CRITICAL

Date/Time: Fri May 3 10:02:40 ICT 2013

Additional Info: CRIT - [tunl0] (up) speed unknown, in: 3.39MB/s, out: 0.00B/s, out-errors: 100.00%(!!) = 0.1

Бег ifconfig, Я получил:

tunl0     Link encap:IPIP Tunnel  HWaddr   
          inet addr:x.y.z.t  Mask:255.255.255.255
          UP RUNNING NOARP  MTU:1480  Metric:1
          RX packets:92101704629 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:652 dropped:0 overruns:0 carrier:0
          collisions:652 txqueuelen:0 
          RX bytes:18941091817671 (17.2 TiB)  TX bytes:0 (0.0 b)

Обратите внимание на ошибки и коллизии. Я знаю, что ненулевое значение поля коллизий указывает на возможность перегрузки сети. Но:

Что может быть точной причиной? Как я могу устранить неполадки?
Есть ли что-нибудь похожее на ethtool для интерфейса IPIP Tunnel?

modinfo ipip

filename:       /lib/modules/2.6.18-194.17.1.el5/kernel/net/ipv4/ipip.ko
license:        GPL
srcversion:     288C625C7521D577F7AD9E4
depends:        tunnel4
vermagic:       2.6.18-194.17.1.el5 SMP mod_unload gcc-4.1
module_sig: 883f3504ca37590565662cff69dd0be11277ff0a08d3a3...

IP туннель шоу

tunl0: ip/ip  remote any  local any  ttl inherit  nopmtudisc

ОБНОВЛЕНИЕ в понедельник, 6 мая, 10:05:01 ICT 2013

@ Данила Ладнер: Поискав в Google, я нашел этот ссылка имеет то же мнение с вами:

Мой туннель не работает:

ifconfig tunl<n> сообщает об ошибках и коллизиях

Ты использовал ifconfigвозможно ifconfig ... pointopoint ... настроить свой туннель?

Закрой это; удали это; начать снова с ip.

Но не могли бы вы уточнить подробности?

@ Сергей Власов:

tunl0     Link encap:IPIP Tunnel  HWaddr   
          inet addr:x.y.z.t  Mask:255.255.255.255
          UP RUNNING NOARP  MTU:1480  Metric:1
          RX packets:81621711099 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:692 dropped:0 overruns:0 carrier:0
          collisions:692 txqueuelen:0 
          RX bytes:16915649263419 (15.3 TiB)  TX bytes:120 (120.0 b)

Я не понимаю, почему есть 2 переданных пакета из tunl0 интерфейс? Я собираюсь настроить обработчик события бежать tcpdump когда бы ни collisions счетчик увеличен. Подождем, что получится.

ОБНОВЛЕНИЕ во вторник, 7 мая, 14:05:39 ICT 2013

@ Данила Ладнер: Чтобы исключить возможность, я попробовал ваше предложение:

ifdown tun0
modprobe -r ipip
modprobe ipip
ip addr add dev tunl0 x.y.z.t/32 brd x.y.z.t
ip link set tunl0 up

Жду, решена ли проблема:

tunl0     Link encap:IPIP Tunnel  HWaddr   
          inet addr:x.y.z.t  Mask:255.255.255.255
          UP RUNNING NOARP  MTU:1480  Metric:1
          RX packets:19630041 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4083271398 (3.8 GiB)  TX bytes:0 (0.0 b)

В collisions счетчик для ipip Интерфейс туннеля увеличен в двух случаях:

Если следующим переходом инкапсулированного пакета является тот же туннельный интерфейс: ipip.c строка 437.
Если MTU пути следующего перехода для инкапсулированного пакета меньше 68: ipip.c строка 447.

Оба эти случая обычно могут произойти только в том случае, если инкапсулированный трафик возвращается в тот же туннель (первый случай - прямое зацикливание, второй случай - когда MTU пути уменьшается до нуля из-за более сложного зацикливания, которое не было немедленно обнаруживается по первому условию). Одна из возможных причин заключается в том, что нормальный маршрут для инкапсулированных пакетов временно не работает, и следующим лучшим маршрутом для этих пакетов оказался сам туннель, что привело к возникновению петли.

Однако в случае LVS-TUN в туннель вообще ничего не должно было быть отправлено (туннельный интерфейс в этом случае предназначен только для приема), если какое-то ошибочное программное обеспечение не добавило ненужные маршруты через tunl0.

Как заметили кванты, я предложил ему снести туннель, если он был построен из ifconfig и перестроить с помощью ip. Поскольку несколько лет назад у меня была аналогичная проблема с ядром Centos 5 2.6.25, в моем случае проблема была решена, но я также консультировал сетевых ребят и разработчиков в IRC, почему это было проблемой, поскольку мне нужен этот маршрут в производственной коробке и нужно было запланировать время простоя, чтобы уничтожить его. Я не помню точно, и на данный момент у меня нет никаких веских доказательств, но Кузнецов (оригинальный крупный участник исходного кода ядра по этому вопросу предложил перестроить его с помощью ip поскольку он видел проблемы с ifconfig. Я надеюсь, что это поможет квантам решить его проблему.

НЕ ПО ТЕМЕ: Итак, суть в том, что я сам довольно тупой, использую много ifconfig и сложно перейти на ip, пока продолжаю заниматься старыми ящиками Solaris 8 и bsd.