greyshadow

В том примерно районе еще и промтелеком кажись обитает.

Повторюсь - балансировать можно в LACP-е по MAC-ам, по IP-ам, а самые продвинутые по IP+port, смотрите, что умеют ваши коммутаторы! например juniper ex-3200 по MAC-ам, по IP-ам; а cisco cat6500 + sup32 или sup720 - по MAC-ам, по IP-ам, по IP+port, zyxel GS4012F по MAC-ам, по IP-ам; а zyxel MES-3524 - только по MAC-ам...

Если мас-ов мало - надо свичи, которые балансить по ip-ам умеют, свичи попроще по мас-ам балансят и вы нормальной балансировки можете не увидеть вовсе.

а какой характер трафика? мас-ов там много бегает?

Теория говорит, что получиться, практика - критерий истины Встречал вифи-шки, которые например не пропускали STP, а другие пропускали....

Не факт - это может быть куча трассировщиков. в случайные 0.07 секунды 21 трейс с разных сторон света? согласитесь маловероятно

Ну так вот вам и ответ - пакеты "бродят" по кольцу между вами и провом пока ttl не истечет, если у вас за 0.07 секунды 21 пакет "умер", примерно столько же по теории вероятностей "умерло" на стороне прова (уже 42 пакета) и как минимум каждый пакет 15 раз туда-сюда слетал, итого 42*15/0.07 примерно 9000 пакетов в секунду (расчет очень грубый) но какраз это и есть те "лишние" пакеты на вход и исход , у вас 13k - 3.7k=9.3k погрешность моих расчетов примерно 4% - отличный результат, вот вам и обьяснение

В пакеттрейсере bgp-а была обкорнанная до состояния неваримости... Или уже что-то поменялось??

Неубиваемых систем небывает! Есть в той или иной степени дуракоустойчивые - но у них свои недостатки

tcpdump -i vlan20 'proto ICMP'

OTRS или ищите по словосочетанию trouble ticket. GLPI тоже можно в этом направлении поковырять.

Вам удаленно или с выездом на место??

Голое шасси или в нем что-то торчит?

Насмешили.... а как вы двусторонний канал ИСКЛЮЧИТЕЛЬНО на приеме организуете???

Посмотреть tcpdump -e чего он выпуливает в интерфейс, и выпуливает ли вообще...

У хуавея что-то такое было - комбайн на грабли похожий, 5 или 6 антенн... вафля, свич, 3G и что-то там еще и все в "одном корпусе".... Кажись вот это: http://www.insotel.ru/model.php?id=7942

Если он пропустит фреймы 1522 байта размером - может.

Если чей-то подход к решению прблемы отличен от вашего - это еще не означает, что он неправильный... Так что привет танкистам

Кто-то умудряется выдавать IP-ы НЕ из радиуса...

Есть небольшая разница, если вы IP-ы выдаете из пула указанного как набор IP-ов в файлике на серваке - то разные процессы-серваки совершенно спокойно выдают один и тот же IP разным абонентам.... Если IP-ами заведует RADIUS - то да, побарабану один там сервер или нет.

Еще vega собирает заявки по частному сектору на подключение (вроде как оптикой).

Не слышал об ограничении в 64 инт. Вообще хотелось бы слушать один интерфейс, что бы не передергивать пппое-сервер. Ваяете сходу 200+ интерфейсов на серваке, и неважно что эти vlan-ы пока еще пустые, по мере необходимости поднимаете нужное кол-во vlan-ов с уже зарезервированными номерами. Наверно так и буду делать. Думал может красивое решение есть) Есть - cisco asr 9000 например или SmartEdge какой-нибудь... Но там ценник всю красоту портит

А зачем его передергивать то??? Ну слушает он 100 вланов, появляется 101. Как без передергивания? Обновление ядра тоже приводит к передергиванию, причем в отличии от сервиса - всей системы.... И как будете с этим жить? Купите специализированный BRAS и будет вам счастье!

Не слышал об ограничении в 64 инт. Вообще хотелось бы слушать один интерфейс, что бы не передергивать пппое-сервер. Ваяете сходу 200+ интерфейсов на серваке, и неважно что эти vlan-ы пока еще пустые, по мере необходимости поднимаете нужное кол-во vlan-ов с уже зарезервированными номерами.

Еще раз повторюсь - смотрите в сторону QinQ и возможности прослущки pppoe сервером фреймов с QinQ тегами. Как вариант - пропатчите сервак сами... ну для этого правда придется в исходниках так некисло покивиряться.