gre-tunnel - ошибки на интерфейсе

Для начала пусти пинг крупными пакетами до удалённого конца gre-туннеля внутри и снаружи самого туннеля, пакетов по 10000.

Приведи выхлоп последних 4 строк команды ping в обоих случаях.

тесты показали следующее:
1. ping туннеля:
PING 10.255.255.38 (10.255.255.38) from 10.255.255.37 : 1200(1228) bytes of data.
--- 10.255.255.38 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 1000172ms
rtt min/avg/max/mdev = 48.156/57.083/211.264/19.995 ms

2. ping внешних ip-адресов туннеля:
PING 212.248.X.X (212.248.X.X) from 31.193.Y.Y : 1200(1228) bytes of data.
--- 212.248.X.X ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 1000256ms
rtt min/avg/max/mdev = 46.869/55.032/195.380/18.026 ms

Проводил в разное время. Бывало пинг в туннеле терялся, но не значительно (на 1000 пакетов они не доходил).
При этом статистика ошибок на интерфейсе gre-туннеля (tun20), при отсутствии потерь иногда увеличивалась иногда нет. Так же при при наличии потерь, ошибки на интерфейсе могли быть, могли не быть

Убрал полностью шифрование gre-тоннеля на час (оставил тоннель без ipsec), за час ошибок не было (может совпадение).

Убрал полностью шифрование gre-тоннеля на час (оставил тоннель без ipsec), за час ошибок не было (может совпадение).

IPSEC внутри туннеля или снаружи - всмысле шифруется весь протокол GRE или только определенные данные внутри?

Чтобы исключить совпадение, верни IPSEC и сними за какое-то время pcap-дамп(tcpdump-ом например) с полным содержимым UDP-пакетов на обоих концах.

Есть мнение, что чексумма таки бьётся, особенно если шифруется весь GRE траффик. А для IPSEC-а это чрезвычайно болезненная ситуация.

Шифруется весь трафик идущий между двумя wan-адресами (на них gre-туннель и сформирован).
Сейчас попробую снять трафик.
Правильно я понял, что снять трафик нужно с включенным ipsec-ом?

Снял шифрованный трафик. Сразу думал посчитаю количество, но не тут то было. Может я не так понял?
Вот как я делал: tcpdump -i eth2 -nv host 212.248.Y.Y and host 81.3.X.X > /home/tcpdump-212.248.Y.Y
Тоже самое на втором шлюзе (время синхронизируется из интернета)
Ждал пока будет ошибка. Остановил дамп. Посчитал количество пакетов по времени. Вот что вышло(привожу первые 20 пакетов)

На первом шлюзе
329 17:13:00
344 17:13:01
270 17:13:02
237 17:13:03
770 17:13:04
470 17:13:05
453 17:13:06
386 17:13:07
272 17:13:08
477 17:13:09
191 17:13:10
300 17:13:11
229 17:13:12
180 17:13:13
269 17:13:14
227 17:13:15
216 17:13:16
277 17:13:17
192 17:13:18
200 17:13:19
236 17:13:20

На втором шлюзе:
329 17:13:00
346 17:13:01
269 17:13:02
234 17:13:03
547 17:13:04
469 17:13:05
451 17:13:06
384 17:13:07
276 17:13:08
338 17:13:09
191 17:13:10
279 17:13:11
230 17:13:12
179 17:13:13
268 17:13:14
226 17:13:15
221 17:13:16
271 17:13:17
195 17:13:18
200 17:13:19
234 17:13:20

Похоже за единицу времени нельзя посчитать(задержки всегда будет при передаче)

Задержки будут, но gre-туннель - туннель без состояния. Если запретить пускать по нему траффик, кроме тестового - можно подождать несколько секунд после передачи финального тестового пакета - и тогда уже остановить tcpdump.

На заметку: можно поднять 2 gre-туннеля(опция key должна быть задана вручную в таком случае ЕМНИП), если хождение траффика в первом останавливать нежелательно.

Другое дело - как их различать, при условии что они оба будут выглядеть как шифрованный трафик...

Ну и да, мы тут углубились в дебри, я как-то забыл спросить очевидно: версия ядра и дистрибутив.

OS - Debian squeeze
ядро - 2.6.32-5-686.

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