Eugene Berdnikov пишет:
Сорри, всем отбой..... все оказалось проще...... серв не при чем, нашел уже в сети урода - надо еще кого-нибудь к нему заслать посмотреть как он так умудрился сделать. смысл в том что малая часть broadcast трафика уходящего в его порт разворачивается и топает назад портя ARP таблицы свитчей. Вот и получалась лотерея - если чей-то бродкаст возвращался - свитчи разворачивали таблицы и его трафик шел в тот порт пока он очередным пакетом не поворачивал на себя, странно только что проблема не локализовалась в одном VLAN и проявлялась в других..... по идее за пределы VLAN в котором она возникла она не должна была выходить. В общем-то конечно ethernet технология задница.....On Tue, Mar 04, 2008 at 04:23:10PM +0300, Oleg Frolkov wrote:Параллельно на рабочей машине цепляюсь ssh к роутеру, запускаю screen и tcpdump -ni eth0Пакеты ПЕРЕСТАЮТ теряться..... первым предположением было что из-за включения promisc режима на интерфейсе, но простой детач screen-а (tcpdump остается работать) и пакеты начинают опять теряться.....Промиск можно поставить принудительно через /sbin/ip или ifconfig.на другом 1Gbit), так что боюсь проблемасофтверная и пока не вижу решения, запустил вот workaround-ом tcpdump и он хлещет кушая ресурсы процовкак на роутере так и на рабочем компе.Возможно, поломан arp. Сравните tcpdump arp or icmp с обеих сторон.
Кстати в принципе можно и автоматическую диагностику подобных вещей делать, может кто знает реализацию? Или такого еще не реализовывали? Теоретически если регулярно опрашивать свитчи по SNMP и следить за изменениями таблиц соответствия MAC адресов и портов - вполне можно сразу находить направление с которого идет эта фигня.
Олег.