DES-3200-XX и блокировка абонентов с IP-MAC-Port Binding после выключения света

[Гайджин 574]

нет не вижу, т.к. они после включения получают по dhcp адреса и в fdb они dynamic forward.

show address_binding ip_mac all

show address_binding blocked all

В студию.

Повторю еще раз, свитч работал в таком режиме более года, проблемы начались после многократных отключений электроэнергии в этом районе

Ну то что он работал год - это как бы еще не показатель. Может он у Вас год не перегружался - т.е. свич с мущинским аптаймом, и Вы просто не попадали в такую ситуацию.

Просто если такое горе наблюдается, то порверять надо все тотально. Как то слабо верится в то, что это аппаратная проблема.

Я правильно понимаю - у вас после перезагрузки абонентов не блочит, а возникают именно потери до них?

show error ports 1-24 что нибудь интересное говорит?

[zeleniy 7]

 

нет не вижу, т.к. они после включения получают по dhcp адреса и в fdb они dynamic forward.

show address_binding ip_mac all

show address_binding blocked all

В студию.

>>Повторю еще раз, свитч работал в таком режиме более года, проблемы начались после многократных отключений электроэнергии в этом районе

Ну то что он работал год - это как бы еще не показатель. Может он у Вас год не перегружался - т.е. свич с мущинским аптаймом, и Вы просто не попадали в такую ситуацию.

Просто если такое горе наблюдается, то порверять надо все тотально. Как то слабо верится в то, что это аппаратная проблема.

Я правильно понимаю - у вас после перезагрузки абонентов не блочит, а возникают именно потери до них?

show error ports 1-24 что нибудь интересное говорит?

 

Command: show address_binding ip_mac all

M(Mode) - D:DHCP, S:Static ACL - A:Active I:Inactive

IP Address                              MAC Address       M  ACL Ports
--------------------------------------- ----------------- -- -- ---------------
172.17.1.28                             00-1F-16-CB-69-E5 S  A  9
172.17.1.68                             00-00-F0-79-F4-A8 S  A  12
172.17.1.146                            1C-6F-65-A9-53-FB S  A  7
172.17.1.149                            90-E6-BA-6E-05-08 S  A  3
172.17.1.170                            14-DA-E9-DE-5E-49 S  A  4
172.17.1.190                            00-25-22-91-C9-38 S  A  5
172.17.2.10                             00-22-15-D0-A6-9D S  A  8
172.17.2.27                             3C-97-0E-20-52-01 S  A  13
172.17.2.33                             BC-AE-C5-C7-A2-FB S  A  10
172.17.2.50                             AC-F1-DF-2A-1C-C7 S  A  16
172.17.2.138                            00-30-18-A1-2D-19 S  A  6

Total Entries : 11

Command: show address_binding blocked all

 VID  VLAN Name                        MAC Address       Port Type
 ---- -------------------------------- ----------------- ---- ---------------

Total Entries : 0

Command: show error ports 1-24
 Port Number : 1
                 RX Frames                                  TX Frames
                 ----------                                 ----------
 CRC Error       0                    Excessive Deferral    0
 Undersize       0                    CRC Error             0
 Oversize        0                    Late Collision        0
 Fragment        0                    Excessive Collision   0
 Jabber          0                    Single Collision      0
 Drop Pkts       -                    Collision             0

Изменено 2013-03-26 12:50:28 пользователем zeleniy

[alex_o 1 194]

ТС по поводу ИМПБ.

Это функционал длинк по "настойчивой просьбе" 3-х очень крупных росиянских операторов в свое время привязал к дхцп-снупингу. И как по мне, замечательно сделал! И сегодня это именно в серии 3200 работает почти идеально.

Вы, насколько я понял, не желаете использовать этот механизм в том виде, как предлагает длинк, а юзаете его частитчно, обвязав костылями. Дело хозяйское. Очевидно, для решения возникшей траблы надо дописать очередной костыль. Или же все-таки начать юзать функционал ИМПБ так, как это предлагает вендор.

Удачи!

[zeleniy 7]

ТС по поводу ИМПБ.

Это функционал длинк по "настойчивой просьбе" 3-х очень крупных росиянских операторов в свое время привязал к дхцп-снупингу. И как по мне, замечательно сделал! И сегодня это именно в серии 3200 работает почти идеально.

Вы, насколько я понял, не желаете использовать этот механизм в том виде, как предлагает длинк, а юзаете его частитчно, обвязав костылями. Дело хозяйское. Очевидно, для решения возникшей траблы надо дописать очередной костыль. Или же все-таки начать юзать функционал ИМПБ так, как это предлагает вендор.

Удачи!

незнаю как это работает у ТС, но у меня работает в таком виде на разных свитчах 3526,3528,3028,3200-10,3200-18,3200-26-с1,3552 уже года 3 где-то

 

 

нет не вижу, т.к. они после включения получают по dhcp адреса и в fdb они dynamic forward.

show address_binding ip_mac all

show address_binding blocked all

В студию.

>Повторю еще раз, свитч работал в таком режиме более года, проблемы начались после многократных отключений электроэнергии в этом районе

Ну то что он работал год - это как бы еще не показатель. Может он у Вас год не перегружался - т.е. свич с мущинским аптаймом, и Вы просто не попадали в такую ситуацию.

Просто если такое горе наблюдается, то порверять надо все тотально. Как то слабо верится в то, что это аппаратная проблема.

Я правильно понимаю - у вас после перезагрузки абонентов не блочит, а возникают именно потери до них?

show error ports 1-24 что нибудь интересное говорит?

 

бывало такое пару раз на 3526 при подключении нового клиента (в то время как все остальные нормально работали), решалось перепрошивкой на последнюю версию.

Поверьте я подставлял свой ноут на линуксе вместо абонентского, прописывал себе его мак, поставил на пинг - есть пинг, ушел курить прихожу пинга нет - чудесно, включаем мультискатовый канал в влц - работает и не рассыпается, переключаем канал на другой- работает (это я к тому, что если кто скажет что мультик из буфера показывает), а пинга так и нет, спустя несколько минут пинг заработал снова. Загрузка процессора в этот момент 20%. В safeguard engine не уходит

[Гайджин 574]

Мы похоже на разных языках говорим - я еще раз прошу, опишите суть вашей проблемы (не на примерах, а четкими словами) - у вас линк до клиента дропать пакеты начниет частично, или же время от времени полностью пропадает юникастовая связность с клиентом?

 

p.s. за фразу "это я к тому, что если кто скажет что мультик из буфера показывает" - отдельное спасибо.

[zeleniy 7]

Мы похоже на разных языках говорим - я еще раз прошу, опишите суть вашей проблемы (не на примерах, а четкими словами) - у вас линк до клиента дропать пакеты начниет частично, или же время от времени полностью пропадает юникастовая связность с клиентом?

 

p.s. за фразу "это я к тому, что если кто скажет что мультик из буфера показывает" - отдельное спасибо.

У абонентов стоят роутеры dir-300 rev b 6 и tp-link wr-741nd, это разные люди, они подключены разными кабелями к одному свитчу 3200-26 rev b1, я пингую их со шлюза, и наблюдаю потери время от времени (т.е. на какой то интервал времени пропадает связь, не пингуется), может их не быть минут 20, а могут появляться с интервалом в 5 минут. В логах ничего ни про safeguard engine, ни про unauthentificated ip-mac-port-binding, загрузка процессора 20%. Все это наблюдается при включенном ipmb с правилами на портах, выключаем ipmb и все нормально работает неделями (проверено)

[Kitikonti 61]

Если я правильно понял то нас тут трое неудачников

Поведаю пожалуй свою беду

Свичи 3200-28f ревизия В1 (про С1 пока не говорим)

Конфиг адрес_биндинга таков:

 

config address_binding ip_mac ports 1-24 state enable allow_zeroip enable forward_dhcppkt enable
config address_binding ip_mac ports 1-28 mode arp stop_learning_threshold 0
config address_binding dhcp_snoop max_entry ports 1-28 limit 5
config address_binding dhcp_snoop max_entry ports 1-28 limit no_limit ipv6
enable address_binding dhcp_snoop
enable address_binding trap_log
disable address_binding dhcp_snoop ipv6

Юзера получают адреса по DHCP, никаких статических привязок.

Все работало до поры до времени пока не начали наблюдать странности с попаданиями валидных маков в блок, т.е. мак сервер знает и дает по нему ип, но свич его не разрешает, а блокирует.

Вторая проблема - связка в таблице есть, трафик бегает но почему-то с громадными дропами.

При этих проблемах потерь на линках магистраль/абоненты нет

Переключение режима работы адрес_биндинга в АЦЛ результата не дало. Все проблемы лечатся выключением адрес_биндинга.

Прошивки вплоть от 1,52 до 1,80. Причем есть попадаются свичи где прошивки/конфиг идентичны но на одном блочит/дропает трафик, а на другом все окей.

[zeleniy 7]

Если я правильно понял то нас тут трое неудачников

Поведаю пожалуй свою беду

Свичи 3200-28f ревизия В1 (про С1 пока не говорим)

Конфиг адрес_биндинга таков:

 

config address_binding ip_mac ports 1-24 state enable allow_zeroip enable forward_dhcppkt enable

config address_binding ip_mac ports 1-28 mode arp stop_learning_threshold 0

config address_binding dhcp_snoop max_entry ports 1-28 limit 5

config address_binding dhcp_snoop max_entry ports 1-28 limit no_limit ipv6

enable address_binding dhcp_snoop

enable address_binding trap_log

disable address_binding dhcp_snoop ipv6

Юзера получают адреса по DHCP, никаких статических привязок.

Все работало до поры до времени пока не начали наблюдать странности с попаданиями валидных маков в блок, т.е. мак сервер знает и дает по нему ип, но свич его не разрешает, а блокирует.

Вторая проблема - связка в таблице есть, трафик бегает но почему-то с громадными дропами.

При этих проблемах потерь на линках магистраль/абоненты нет

Переключение режима работы адрес_биндинга в АЦЛ результата не дало. Все проблемы лечатся выключением адрес_биндинга.

Прошивки вплоть от 1,52 до 1,80. Причем есть попадаются свичи где прошивки/конфиг идентичны но на одном блочит/дропает трафик, а на другом все окей.

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

[chip_shpak 1]

Если я правильно понял то нас тут трое неудачников

Поведаю пожалуй свою беду

Свичи 3200-28f ревизия В1 (про С1 пока не говорим)

Конфиг адрес_биндинга таков:

 

config address_binding ip_mac ports 1-24 state enable allow_zeroip enable forward_dhcppkt enable

config address_binding ip_mac ports 1-28 mode arp stop_learning_threshold 0

config address_binding dhcp_snoop max_entry ports 1-28 limit 5

config address_binding dhcp_snoop max_entry ports 1-28 limit no_limit ipv6

enable address_binding dhcp_snoop

enable address_binding trap_log

disable address_binding dhcp_snoop ipv6

Юзера получают адреса по DHCP, никаких статических привязок.

Все работало до поры до времени пока не начали наблюдать странности с попаданиями валидных маков в блок, т.е. мак сервер знает и дает по нему ип, но свич его не разрешает, а блокирует.

Вторая проблема - связка в таблице есть, трафик бегает но почему-то с громадными дропами.

При этих проблемах потерь на линках магистраль/абоненты нет

Переключение режима работы адрес_биндинга в АЦЛ результата не дало. Все проблемы лечатся выключением адрес_биндинга.

Прошивки вплоть от 1,52 до 1,80. Причем есть попадаются свичи где прошивки/конфиг идентичны но на одном блочит/дропает трафик, а на другом все окей.

 

Еше замечено что при включеном dhcp-snoop на windows 7 x64 и сетевая realtek особено с чипом 8102e после окончания лиза дроп пакета когда отклячаем dhcp_snoop все работает ок. Может тоже кто то сталкивался 

Изменено 2013-03-27 07:51:38 пользователем chip_shpak

[zeleniy 7]

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

[chip_shpak 1]

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

 

интересно чем закончилось а то тоже неблюдаем такую проблему с дропами на абонентов на некоторых комутаторах

[zeleniy 7]

 

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

 

интересно чем закончилось а то тоже неблюдаем такую проблему с дропами на абонентов на некоторых комутаторах

разобрал, емкости целые, прошил новой прошивкой, 1.82 В008 , сделал ресет, поменял некоторые свитчи местами и все ок, я так думаю что все таки проблема в питании, другой свитч С1, в этом месте нормально пашет

Изменено 2013-04-05 08:18:49 пользователем zeleniy

[Ksail 15]

Firmware Version    1.51.B008  - никаких глюков

[_ivan_ 25]

ТС по поводу ИМПБ.

Это функционал длинк по "настойчивой просьбе" 3-х очень крупных росиянских операторов в свое время привязал к дхцп-снупингу. И как по мне, замечательно сделал! И сегодня это именно в серии 3200 работает почти идеально.

Вы, насколько я понял, не желаете использовать этот механизм в том виде, как предлагает длинк, а юзаете его частитчно, обвязав костылями. Дело хозяйское. Очевидно, для решения возникшей траблы надо дописать очередной костыль. Или же все-таки начать юзать функционал ИМПБ так, как это предлагает вендор.

Удачи!

и как правильно использовать данный механизм?

[dUrant 0]

Странно юзаем около сотни тазиков, с разными прошивками. Таких багов не наблюдали. Слежу за темой

[slimq 2]

Хотя схема авторизации другая и ipmb не используем. Но по симптомам была идентичная проблема. На портах абонов стоит port security  и после грозы один из портов после перезагрузки заносил в свою таблицу мак адреса с 3-х других портов. У клиента выглядело аналогично вашему примеру. Посмотрите может и у вас на каком-то порту после перезагрузки эти маки висят. Нам помогло административное выключение порта.

[axl72 12]

Возможно вам надо включить на абонентских портах loopback detection? дохлый порт зачастую отражает исходящие arp-пакеты. или оборудование клиента образует петлю.