Коллеги, наткнулись на странные грабли. Дано: FreeBSD 4.9-RC или 4.8-p13, в ядре - pseudo-device gre. squid 2.5-неважно-какой. Проблема: при нагрузке (в среднем - 1.5-2 млн запросов в сутки) начинаем терять пакеты, вплоть до полного их нехождения. после arp -d -a маки появляются, nmbclusters много, но, в лучшем случае, проходит 1 пакет из нескольких сотен. Понятное дело, спасает reboot, ifconfig up/down не лечит. Подозрение на реализацию gre в FreeBSD начиная с 4.8. Вопросы: 1) кто-нибудь на такие грабли натыкался ? 2) есть ли workaround ? 3) а на чем вы делает interception proxy на FreeBSD ? С уважением, Дмитрий -- Dmitry A.Deineka DAD1-UANIC DD518-RIPE http://www.itl.net.ua =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Wed, 15 Oct 2003, Dmitry A.Deineka wrote:
Коллеги,
наткнулись на странные грабли.
Дано: FreeBSD 4.9-RC или 4.8-p13, в ядре - pseudo-device gre. squid 2.5-неважно-какой.
Проблема: при нагрузке (в среднем - 1.5-2 млн запросов в сутки) начинаем терять пакеты, вплоть до полного их нехождения. после arp -d -a маки появляются, nmbclusters много, но, в лучшем случае, проходит 1 пакет из нескольких сотен. Понятное дело, спасает reboot, ifconfig up/down не лечит.
Подозрение на реализацию gre в FreeBSD начиная с 4.8.
Вопросы: 1) кто-нибудь на такие грабли натыкался ? 2) есть ли workaround ? 3) а на чем вы делает interception proxy на FreeBSD ?
Добавлю еще один эпизод ... Тазик обслуживает сотню vlans, до сотни gif и gre вперемешку, до полутора сотен tun. FreeBSD 4-STABLE. С течением времени (а иногда и даже сразу после перезагрузки) два-три gre и/или gif перестают работать. Выражается это в том, что при живой опорной сети и поднятом туннеле внутри туннеля я вижу tcpdump'ом только мелкие udp-пакеты. Просто down/up не лечит. Если пересадить умерший туннель на другой (свободный) номер того же типа - все работает. Т.е. такое впечатление, что струтктуры ядра, которые реализуют gre, в какой-то момент по каким-то причинам перестают быть вменяемыми. Нащупаный workaround - ifconfig down, ifconfig delete, ifconfig deletetunnel, ifconfig destroy, ifconfig create и отконфигурить заново. При этом естественно идет по линии гинекологии нумерация интерфейсов в snmp. Лечение было простым. Так как грабли начались именно с включением в конфигурацию gre и для решаемых этим тазиком задач в общем-то было все равно - gre или gif, то все gre поменял на gif. Грабли кончились. Позже я решил еще раз проверить - благо был повод. На другом тазике, работающем с несколько большими потоками данных, поднял всего два gre. Максимальное время жизни во вменяемом состоянии - часа три. Заменил gre на gif - живет уже пару месяцев. Вывод (IMHO) - чего-то они с gre начудили, причем весьма основательно. Я принял решение до появления серьезных оснований воздержаться от употребления gre для туннелирования с участием FreeBSD. . -- WBR, Sergey Saley SA-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Wed, Oct 15, 2003 at 05:48:02PM +0300, Sergey Saley wrote:
Коллеги,
наткнулись на странные грабли.
Дано: FreeBSD 4.9-RC или 4.8-p13, в ядре - pseudo-device gre. squid 2.5-неважно-какой.
Проблема: при нагрузке (в среднем - 1.5-2 млн запросов в сутки) начинаем терять пакеты, вплоть до полного их нехождения. после arp -d -a маки появляются, nmbclusters много, но, в лучшем случае, проходит 1 пакет из нескольких сотен. Понятное дело, спасает reboot, ifconfig up/down не лечит.
Подозрение на реализацию gre в FreeBSD начиная с 4.8.
Вопросы: 1) кто-нибудь на такие грабли натыкался ? 2) есть ли workaround ? 3) а на чем вы делает interception proxy на FreeBSD ?
Добавлю еще один эпизод ...
Тазик обслуживает сотню vlans, до сотни gif и gre вперемешку, до полутора сотен tun. FreeBSD 4-STABLE. С течением времени (а иногда и даже сразу после перезагрузки) два-три gre и/или gif перестают работать. Выражается это в том, что при живой опорной сети и поднятом туннеле внутри туннеля я вижу tcpdump'ом только мелкие udp-пакеты. Просто down/up не лечит. Если пересадить умерший туннель на другой (свободный) номер того же типа - все работает. Т.е. такое впечатление, что струтктуры ядра, которые реализуют gre, в какой-то момент по каким-то причинам перестают быть вменяемыми.
Нащупаный workaround - ifconfig down, ifconfig delete, ifconfig deletetunnel, ifconfig destroy, ifconfig create и отконфигурить заново. При этом естественно идет по линии гинекологии нумерация интерфейсов в snmp.
я gre практически не использую... а по поводу gif - он очень не любит изменение маршрута до того конца туннеля. сразу падает с очень похожими на твой симптомами. причем количество gif'ов не влияют на повышение падучести. наблюдал это и на машине с одним туннелем и с десятками. мой workaround: ifconfig delete ifconfig deletetunnel ifconfig tunnel .... ifconfig inet .... так работает и snmp не гробит.
Лечение было простым. Так как грабли начались именно с включением в конфигурацию gre и для решаемых этим тазиком задач в общем-то было все равно - gre или gif, то все gre поменял на gif. Грабли кончились.
Позже я решил еще раз проверить - благо был повод. На другом тазике, работающем с несколько большими потоками данных, поднял всего два gre. Максимальное время жизни во вменяемом состоянии - часа три. Заменил gre на gif - живет уже пару месяцев.
Вывод (IMHO) - чего-то они с gre начудили, причем весьма основательно. Я принял решение до появления серьезных оснований воздержаться от употребления gre для туннелирования с участием FreeBSD.
-- Maxim Mazurok (MMP2-RIPE) =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
participants (3)
-
Dmitry A.Deineka -
Maxim Mazurok -
Sergey Saley