xcme Опубликовано 17 января, 2011 · Жалоба Приветствую. У некоторых абонентов наблюдаем картину вроде этой: 12.01.2011 0:02:17 10.38.158.3 add 00:1E:68:05:31:F8 Port 04 12.01.2011 0:02:16 10.38.158.3 add 00:1E:68:05:E7:3B Port 04 12.01.2011 0:02:15 10.38.158.3 add 00:1E:68:05:B7:AB Port 04 12.01.2011 0:02:14 10.38.158.3 add 00:1E:68:05:38:8C Port 04 12.01.2011 0:02:13 10.38.158.3 add 00:1E:68:05:BA:35 Port 04 12.01.2011 0:02:12 10.38.158.3 add 00:1E:68:05:0B:C4 Port 04 12.01.2011 0:02:11 10.38.158.3 add 00:1E:68:05:BC:5C Port 04 Свич регистрирует новые маки на абонентском порту, где первые 4 байта совпадают с маком абонента, а два последние произвольно меняются. Проблема проявляется нерегулярно, т.е. дня 4 на порту обнаруживается только верный мак, затем сутки/двое маки множатся, потом опять тишина. К абонентам отправляется техник, который переустанавливает драйвера, лечит комп от вирусов (их, кстати, не обнаружил) и т.д., но через несколько дней все начинается снова. На порту одного абонента вагон ошибок Fragment, на порту другого ошибок нет вообще. Интересуют причины подобного поведения, какой софт флудит или глюк сетевухи или еще что, может кто сталкивался? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
itl2044 Опубликовано 17 января, 2011 · Жалоба Приветствую. У некоторых абонентов наблюдаем картину вроде этой: 12.01.2011 0:02:17 10.38.158.3 add 00:1E:68:05:31:F8 Port 04 12.01.2011 0:02:16 10.38.158.3 add 00:1E:68:05:E7:3B Port 04 12.01.2011 0:02:15 10.38.158.3 add 00:1E:68:05:B7:AB Port 04 12.01.2011 0:02:14 10.38.158.3 add 00:1E:68:05:38:8C Port 04 12.01.2011 0:02:13 10.38.158.3 add 00:1E:68:05:BA:35 Port 04 12.01.2011 0:02:12 10.38.158.3 add 00:1E:68:05:0B:C4 Port 04 12.01.2011 0:02:11 10.38.158.3 add 00:1E:68:05:BC:5C Port 04 Свич регистрирует новые маки на абонентском порту, где первые 4 байта совпадают с маком абонента, а два последние произвольно меняются. Проблема проявляется нерегулярно, т.е. дня 4 на порту обнаруживается только верный мак, затем сутки/двое маки множатся, потом опять тишина. К абонентам отправляется техник, который переустанавливает драйвера, лечит комп от вирусов (их, кстати, не обнаружил) и т.д., но через несколько дней все начинается снова. На порту одного абонента вагон ошибок Fragment, на порту другого ошибок нет вообще. Интересуют причины подобного поведения, какой софт флудит или глюк сетевухи или еще что, может кто сталкивался? Поменять сетевую карту у абонента - она подгорелая. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xDream Опубликовано 17 января, 2011 (изменено) · Жалоба Да... и еще из-за плохо обжатого кабеля такое видел... Изменено 17 января, 2011 пользователем xDream Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Diman Опубликовано 17 января, 2011 · Жалоба или где-то витуха идет параллельно силовой проводке и очень близко, и перевод порта на 10М не спасает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Negator Опубликовано 17 января, 2011 · Жалоба Угу ищите проблему с кабелем для начала поппробуйте просто переобжать Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vIv Опубликовано 17 января, 2011 · Жалоба Или абонент играет в игры с активным сниффером типа http://www.oxid.it/cain.html Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kirill_pulim Опубликовано 17 января, 2011 · Жалоба Приветствую. У некоторых абонентов наблюдаем картину вроде этой: 12.01.2011 0:02:17 10.38.158.3 add 00:1E:68:05:31:F8 Port 04 12.01.2011 0:02:16 10.38.158.3 add 00:1E:68:05:E7:3B Port 04 12.01.2011 0:02:15 10.38.158.3 add 00:1E:68:05:B7:AB Port 04 12.01.2011 0:02:14 10.38.158.3 add 00:1E:68:05:38:8C Port 04 12.01.2011 0:02:13 10.38.158.3 add 00:1E:68:05:BA:35 Port 04 12.01.2011 0:02:12 10.38.158.3 add 00:1E:68:05:0B:C4 Port 04 12.01.2011 0:02:11 10.38.158.3 add 00:1E:68:05:BC:5C Port 04 Свич регистрирует новые маки на абонентском порту, где первые 4 байта совпадают с маком абонента, а два последние произвольно меняются. Проблема проявляется нерегулярно, т.е. дня 4 на порту обнаруживается только верный мак, затем сутки/двое маки множатся, потом опять тишина. К абонентам отправляется техник, который переустанавливает драйвера, лечит комп от вирусов (их, кстати, не обнаружил) и т.д., но через несколько дней все начинается снова. На порту одного абонента вагон ошибок Fragment, на порту другого ошибок нет вообще. Интересуют причины подобного поведения, какой софт флудит или глюк сетевухи или еще что, может кто сталкивался? сетевая ASUS --- за последнее время штук пять клиетты отнесли обратно в оди магазин (постоянно меняет маки) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 19 января, 2011 · Жалоба Мнения разделились. :) Абоненты вроде не из тех, что каином могут баловаться и еще смущает что куча маков может быть на порту, где не регистрируются ошибки. Или они и не обязаны регистрироваться в каждом случае?:) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martin74 Опубликовано 19 января, 2011 · Жалоба Два дня назад арендатор в офисе начал жаловаться на неработу сети. Из неожиданностей - на сетку из 3-х компов на порту свича светилось 46-70 маков ;) Ошибок не было. Вылечили тем, что переделали розетку - заново кабель забили в плинт. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 19 января, 2011 · Жалоба Вылечили тем, что переделали розетку - заново кабель забили в плинт.У нас в городе продавалась(?) партия бракованных розеток RJ45, там заводской брак: после того как держатель для жил вставили не до конца, припаяли - на заводе не давали ему остыть и дожимали до упора.В итоге олово успевшее остыть сверху, не успевало остыть у основания, и получалась шляпка на палочке. Через некоторое время оно окислялось и контакт "мистически-непредсказуемо" пропадал. На глаз видно не сразу, зазор там меньше мм, да и саму плату снимать нужно. Для синей и коричневой пары всё было нормально :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 19 января, 2011 (изменено) · Жалоба Замечено 2 вида "левых" маков на адресах. 1. Как описано в посте у топикастера - меняется 4 последних байта. 2. Когда мак адреса являют из себя помойку (т.е. содержат откровенный мусор) 1-ый вариант бывает связан со следующими вариантами: а) Вирусы - (да-да, как не печально но - это наиболее частая причина - похоже стали распространятся звери которые стали таким образом пытаться видимо снифирить трафик сети путем перевода коммутаторов в режим хабов. Особенно часто встречается у тех клиентов, у кого стоит "условно бесплатный" антивирь вроде "Аваста", не в обиду будет сказано.) б) возможно глюк сетевых плат - это на 100% не подтверждалось - но замена сетевок или установка "родных" драйверов помогает иногда в особо странных случаях. 2-ой вариант как правило связан с плохим качеством линии или проблемами с железом, т.е., как правило, на интерфейсе есть куча ошибок, решается путем устранения проблем с кабелем, розетками, скрутками, джеками и т.п., ОДНАКО, были отмечены случаи и связанные с проблемами сетевок - а именно также как и в случае б) - неродные дрова или просто сбои - решалось заменой сетевки или установкой родных дров. З.Ы. Вот и всё. Конечно стоит напомнить что у "уважающего себя" оператора должно стоять управляемое оборудование и ограничено число маков на порту абонента или приняты какие-то дополнительные меры по защите сети от подобных проблем. Изменено 19 января, 2011 пользователем sdy_moscow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дегтярев Илья Опубликовано 20 января, 2011 · Жалоба Про битые пакеты. Нормальный управляемый свитч вначале проверяет контрольную сумму заголовка, потом только принимает решение и если появился новый мак заносит его в fdb. Однако есть мега-управляемый поделия. Например у нас стояли Телесины 80 и 85 серий. У обоих мак изучается до проверки контрольной суммы. Итого у первых свитчей на порту кривых маков заметить нельзя, во втором их дофига и из-за ограничения на количество у абонента периодически блокируется основной мак. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alteron Опубликовано 20 января, 2011 · Жалоба А свитчей типа DES-1005 или 1008 там нет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 20 января, 2011 (изменено) · Жалоба 1. Как описано в посте у топикастера - меняется 4 последних байта.В смысле 2 байта? Наверное в нашем случае надо попробовать заменить сетевую, т.к. компьютер абонента на вирусы уже проверялся. Конечно стоит напомнить что у "уважающего себя" оператора должно стоять управляемое оборудование и ограничено число маков на порту абонента или приняты какие-то дополнительные меры по защите сети от подобных проблем.Это понятно, заблокировать можно всегда, но тот сегмент небольшой, никто не страдает больше :) Интереснее понять причину проблемы. Вот например и такой глюк бывает попадается: http://forum.vbios.com/showtopic.php?tid/3.../post/last/m/1/ но он менее критичен. А свитчей типа DES-1005 или 1008 там нет?На доступе? Нет, там 3200-28 везде. А у абонентов не должно быть. Изменено 20 января, 2011 пользователем xcme Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...