[=Dmitry=]

Про DIR-300 и Flow control

http://forum.dlink.ru/viewtopic.php?f=3&t=161948

Ждем...

 

На клиентской Винде можно попробовать отключить Flow control ("Управление потоком") в настройках сетевушки.

У некоторых мыльниц, так же присутствует данная опция.

Это конечно костыль, но позволяет частично/временно решить проблему..., а дальше либо мы дождемся исправлений от Д-Линк, и будем отлавливать "негодяев" по одному на месте, с "добровольно-принудительной" перепрошивкой, либо менять коммутаторы.

[No_name]

Brainiac, все у длинка лечится перепрошивкой) в данном случае тоже

...

На тот момент не лечилось, а интернет нужен был "вчера".

Изменено 8 сентября, 2013 пользователем Brainiac

[Andrei]

Andrei, почему у вас в таблице 00:60:fd:8a:43:8e два раза в разных виланах?

А как определить - чей это мак? Тупо бегать по свичам и искать по портам? Есть более изящное решение?

 

stp включил только чтобы включился LBD:

Скажите, у вас так часто петли на магистральных портах образуются? Если нет - то нафига их детектировать пытаться?

С петлями не сталкивался, но решил подстраховаться.

 

И вот, недавно тоже, в один прекрасный момент, жалуются абоненты в одном из сегментов, что компы то получают адреса, то нет,

то работает сеть, то не работает. Странно, знаю этот сегмент всегда без проблем работал, в итоге после всех манипуляций,

оказался зависший роутер длинк-300 у одного из клиентов.

Чем он там срал в сегмент, разбираться не стали, просто его перегрузили и все заработало.

В проблемном сегменте точно знаю, что есть парочка клиентов с дир-300. Может и больше.

Порты, в которые они включены, я выключал на коммутаторах в конечных домах, но картину это не меняло. Возможно я не все такие роутеры знаю.

[srg555]

А как определить - чей это мак? Тупо бегать по свичам и искать по портам? Есть более изящное решение?

 

Вести учёт абонент<->порт коммутатора, хотя как мотивировать монтёров использовать верные порты это отдельный вопрос. Если такие данные есть, то искать по логам радиуса/bras'а/прочего этот мак-адрес и сопоставлять с абонентом.

Одинаковые мак-адреса могут быть следстием установки альтернативных прошивок без смены мака на заводской после перепрошивки

[EShirokiy]

Andrei, show arp на 3100 и по ID IP вычислить?

[Ivan_83]

На клиентской Винде можно попробовать отключить Flow control ("Управление потоком") в настройках сетевушки.

Можно попробовать отключить их на порту коммутатора и порезать ацл.

[mcdemon]

Brainiac, с абонентским оборудованием длинк (роутеры) вечно проблемы, например dir-615 k2 из коробки вообще не работает =)

можно поподробнее? а то мы на днях кокраз 100штук заказали таких со дня на день придут, до этого брали только дир300, щас решили брать 615.

[EShirokiy]

mcdemon, http://otservice.ru/wp-content/uploads/wpsc/product_images/63898.jpg вот такие из коробки не работают, надо обязательно обновляться на последнюю прошивку, на фтп длинка лежит

[mcdemon]

я понял какие) именно к2 ревизию мы заказали

меня интересует что значит не работают)

[Andrei]

А как определить - чей это мак? Тупо бегать по свичам и искать по портам? Есть более изящное решение?

 

Вести учёт абонент<->порт коммутатора, хотя как мотивировать монтёров использовать верные порты это отдельный вопрос.

Мы не используем привязку mac-port. Авторизация по pptp

 

Andrei, show arp на 3100 и по ID IP вычислить?

DGS-3100_Mira52# sh arp

Command:  show arp

 arpentry             Display the current contents of the Switch's ARP table.
 arp_spoofing_prevention show ARP spoofing prevention
DGS-3100_Mira52# sh arpe

ARP timeout: 300 Seconds

Interface      IP Address       MAC Address        Type
-------------  ---------------  -----------------  ---------------
managment      192.168.254.1    00:02:1b:fd:2c:d1  dynamic

Total Entries: 1

DGS-3100_Mira52# sh arp_s

Arp Spoofing Prevention is not set

Не вижу, что это дает.

По sh fdb конечно можно побегать по свичам и вычислить, но я спросил про более изящный метод.

[pppoetest]

Вообще самое адекватное из абонентских устройств - это роутеры фирмы Tp-link, конкретно модели WR741ND, WR841ND процент брака стремится к нулю, работают хорошо

Мультикаст по вайфаю не пережевывает, заикается.

[NiTr0]

С петлями не сталкивался, но решил подстраховаться.

А не думали, что луп детект гасит ваши свичи доступа?

[Andrei]

С петлями не сталкивался, но решил подстраховаться.

А не думали, что луп детект гасит ваши свичи доступа?

во-первых, я включил stp и lbd ПОСЛЕ появления проблемы. так что причина отвала свичей доступа не в этом. и отваливались только свичи, которые находились в клиентском влане (повторюсь - у Planet-WGSD-1020 просто нет управляющего влана).

во-вторых, я так думаю, что он гасил бы линки до свичей доступа в случае образования на этих свичах петель. не могут же петли может образоваться сразу на 4-5 свичах доступа? а отвалы свичей доступа были не под одному, а пачками - по 4-5 за раз.

 

update. проблема была в субботу после обеда. в вск и пн все работает стабильно. я даже костыль в виде "clear fdb all" на 3100 отключил. но причину понять надо.

[No_name]

я понял какие) именно к2 ревизию мы заказали

меня интересует что значит не работают)

Если мне память не изменяет, они не сохраняли конфиг при перезагрузке.

Изменено 9 сентября, 2013 пользователем Brainiac

[Traskalata]

Brainiac, все у длинка лечится перепрошивкой) в данном случае тоже

Вообще самое адекватное из абонентских устройств - это роутеры фирмы Tp-link, конкретно модели WR741ND, WR841ND процент брака стремится к нулю, работают хорошо

Я их ставлю абонентам. Действительно стабильно работают.

[EShirokiy]

я понял какие) именно к2 ревизию мы заказали

меня интересует что значит не работают)

Там DHCP отваливался, фавля не хотела работать, настройки слетали и т.д. Вообще очень странно почему такой продукт на рынок выпустили, кажется, его даже не тестировали

[taf_321]

DIR-ы это нечто хтоничное в своей глючности. Всеми силами избавляемся от них в своей сети.

[Andrei]

Заметил, что отвалы pptp-сессий в таком сегменте происходят только у тех абонентов, у кого стоят роутеры нижней ценовой категории, типа tplink 740, 741, 841.

Cнифером послушал что происходит перед тем, как роутер рвет pptp-сессию: роутер шлет NAS-у (cisco) пакет протокола pptp "[TCP Previous segment not captured] Call-Clear-Request", перед этим периодически проскакивали пакеты "[TCP Retransmission] Echo-Request". И потом, не дожидаясь разрыва сессии, начинает заново ломиться с именем и паролем с попытками установить pptp-соединение.

 

Потерь от центра до клиентского свича практически нет:

 

ping -i0.2 -s 1500 192.168.10.243

...

--- 192.168.10.243 ping statistics ---

4341 packets transmitted, 4337 received, 0% packet loss, time 872752ms

rtt min/avg/max/mdev = 4.579/4.791/81.124/1.302 ms

[moonfire]

 

Andrei, show arp на 3100 и по ID IP вычислить?

DGS-3100_Mira52# sh arp

Command:  show arp

 arpentry             Display the current contents of the Switch's ARP table.
 arp_spoofing_prevention show ARP spoofing prevention
DGS-3100_Mira52# sh arpe

ARP timeout: 300 Seconds

Interface      IP Address       MAC Address        Type
-------------  ---------------  -----------------  ---------------
managment      192.168.254.1    00:02:1b:fd:2c:d1  dynamic

Total Entries: 1

DGS-3100_Mira52# sh arp_s

Arp Spoofing Prevention is not set

Не вижу, что это дает.

По sh fdb конечно можно побегать по свичам и вычислить, но я спросил про более изящный метод.

 

sh arp нужно делать на точке терминации вланов(маршрутизаторе). Тоесть скорее всего на 192.168.254.1

По проблеме. Может в пользовательском влане кто-то балует и, например, арпспуфит Planet. Влан то общий.

[Andrei]

 

По проблеме. Может в пользовательском влане кто-то балует и, например, арпспуфит Planet. Влан то общий.

А делать-то что кроме как пытаться вычислить и сделать а-та-та?

 

Послушал снифером трафик в сегменте и вот что увидел:

192.168.10.1 - это линух-сервер, который указан в настройках у клиента в качестве основного шлюза и dns-сервера

192.168.11.80 - клиент

9.500935 192.168.11.80 -> Broadcast ARP Who has 192.168.11.4? Tell 192.168.11.80

9.500949 192.168.11.80 -> Broadcast ARP Who has 192.168.10.197? Tell 192.168.11.80

10.306229 192.168.11.80 -> Broadcast ARP Who has 192.168.10.56? Tell 192.168.11.80

10.306696 192.168.11.80 -> Broadcast ARP Who has 192.168.10.56? Tell 192.168.11.80

10.500922 192.168.11.80 -> Broadcast ARP Who has 192.168.10.1? Tell 192.168.11.80

10.500945 192.168.10.1 -> 192.168.11.80 ARP 192.168.10.1 is at 00:0d:61:90:1b:d1

10.500967 192.168.11.80 -> Broadcast ARP Who has 192.168.11.4? Tell 192.168.11.80

10.500980 192.168.11.80 -> Broadcast ARP Who has 192.168.10.197? Tell 192.168.11.80

11.000952 192.168.11.80 -> Broadcast ARP Who has 192.168.10.56? Tell 192.168.11.80

11.001054 192.168.11.80 -> Broadcast ARP Who has 192.168.10.56? Tell 192.168.11.80

12.001062 192.168.11.80 -> Broadcast ARP Who has 192.168.10.56? Tell 192.168.11.80

вирусня у клиента?

[Andrei]

Интересно, что появилось несколько клиентов, у которых с некоторых пор не поднимается pptp. Причем связь до них есть, снифером видно от них бродкасты:

  0.000000 192.168.11.96 -> Broadcast    ARP Who has 192.168.11.1?  Tell 192.168.11.96
 0.000043 192.168.11.1 -> 192.168.11.96 ARP 192.168.11.1 is at 00:0d:61:90:1b:d1
 0.000248 192.168.11.96 -> Broadcast    ARP Who has 192.168.11.1?  Tell 192.168.11.96
 0.000261 192.168.11.1 -> 192.168.11.96 ARP 192.168.11.1 is at 00:0d:61:90:1b:d1
 0.949408 192.168.11.96 -> Broadcast    ARP Who has 192.168.11.1?  Tell 192.168.11.96
 0.949432 192.168.11.1 -> 192.168.11.96 ARP 192.168.11.1 is at 00:0d:61:90:1b:d1
 0.949510 192.168.11.96 -> Broadcast    ARP Who has 192.168.11.1?  Tell 192.168.11.96
 0.949515 192.168.11.1 -> 192.168.11.96 ARP 192.168.11.1 is at 00:0d:61:90:1b:d1

192.168.11.1 - сервер

192.168.11.96 - клиент

Если от клиента пинговать сервер - все замечательно пингуется, но при попытке установить pptp-соединение до этого же сервера пишет "Порт открыт" и потом ошибка Windows 7 номер 868. При этом во время попытки установить соединение на сервере снифером не видно никаких попыток это сделать со стороны клиента.

Иногда помогает штатное "Восстановление системы" с откатом последних виндовых обновлений.

Кто-то с таким сталкивался? В чем причина?

[Andrei]

Update: похоже этому подвержены только Windows 7 (домашние, максимальные - не важно), с роутерами и WinXP такой проблемы нет.

[Andrei]

Ну неужели никто не сталкивался. Вот вчера опять такой клиент позвонил. Переставил Win7, вечер поработал, всё было ОК, на утро - опять не работает подключение pptp. Слушаю снифером видно только бродкаст трафик типа вот такого:

 14.304322 192.168.11.96 -> 192.168.11.255 NBNS Registration NB ?????-??<20>
14.305093 192.168.11.96 -> 192.168.11.255 NBNS Registration NB ?????-??<20>
14.382321 192.168.11.96 -> 192.168.11.255 NBNS Name query NB ISATAP<00>
14.383016 192.168.11.96 -> 192.168.11.255 NBNS Name query NB ISATAP<00>
14.507049 192.168.11.96 -> Broadcast    ARP Who has 192.168.11.1?  Tell 192.168.11.96
14.507063 192.168.11.1 -> 192.168.11.96 ARP 192.168.11.1 is at 00:0d:61:90:1b:d1
15.068695 192.168.11.96 -> 192.168.11.255 NBNS Registration NB ?????-??<20>
15.069485 192.168.11.96 -> 192.168.11.255 NBNS Registration NB ?????-??<20>

и никаких попыток отресолвить имя vpn-сервера и поднять pptp.

За вечер винда успела поставить втихаря 3 обновления, откатили их через "Все программы" - "Стандартные" - "Служебные" - "Восстановление системы". Не помогло.

Попросил клиента попинговать наш сервер, пинг говорит не "Превышен интервал ожидания", а "Заданный узел не доступен", при этом на сервере я пингов снифером тоже не вижу, хотя порт на коммутаторе в UP, счетчики пакетов увеличиваются, якобы все ОК.

Клиент тут же берет нетбук, подключает кабель к нему - все работает замечательно. Т.е. дело не в нашей сетке, а в каких-то глюках Win7.

Коллеги, кто сталкивался - подскажите в какую сторону копать?

[No_name]

Переставил Win7...

Вы уверены что лицензия, а может сборка какая кривожопая?

На ХР такое сплошь и рядом было, всякие "звери" и прочяя мутотень.