Eugene Berdnikov пишет:
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 с обеих сторон.
Сорри, всем отбой..... все оказалось проще...... серв не при чем, нашел
уже в сети урода - надо еще кого-нибудь
к нему заслать посмотреть как он так умудрился сделать. смысл в том что
малая часть broadcast трафика уходящего в его порт разворачивается и
топает назад портя ARP таблицы свитчей. Вот и получалась лотерея - если
чей-то бродкаст возвращался - свитчи разворачивали таблицы и его трафик
шел в тот порт пока он очередным пакетом не поворачивал на себя, странно
только что проблема не локализовалась в одном VLAN и проявлялась в
других..... по идее за пределы VLAN в котором она возникла она не должна
была выходить. В общем-то конечно ethernet технология задница.....
Кстати в принципе можно и автоматическую диагностику подобных вещей
делать, может кто знает реализацию?
Или такого еще не реализовывали? Теоретически если регулярно опрашивать
свитчи по SNMP и следить за изменениями
таблиц соответствия MAC адресов и портов - вполне можно сразу находить
направление с которого идет эта фигня.
Олег.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
