zeleniy

На FreeBSD: http://www.freebsd.org/doc/handbook/network-aggregation.html ifconfig_lagg0="laggproto lacp laggport igb0 laggport igb1" ifconfig_lagg1="laggproto lacp laggport em0 laggport em1" На свитче: configure terminal lacp system-priority 4096 aggregateport load-balance src-dst-ip interface range GigabitEthernet 0/15-16 no shutdown description AGG-2G-LINK lacp port-priority 4096 port-group 2 mode passive flowcontrol off medium-type copper exit interface AggregatePort 2 no shutdown description AGG-2G-LINK flowcontrol off switchport mode trunk switchport trunk allowed vlan all exit Тоесть - 802.3ad а что говорит свитч на: show interfaces AggregatePort 2

конфиг свитча выложите, может у вас наcтроено незнаю как во freebsd , но в линуксе есть: 1. balance-rr (Этот режим используется по-умолчанию, если в настройках не указано другое. balance-rr обеспечивает балансировку нагрузки и отказоустойчивость. В данном режиме пакеты отправляются "по кругу" от первого интерфейса к последнему и сначала. Если выходит из строя один из интерфейсов, пакеты отправляются на остальные оставшиеся) 2. active-backup 3. balance-xor 4. broadcast 5. 802.3ad то что нужно вам 6. balance-tlb 7. balance-alb

ну прилепите график сюда что ли с внешнего интерфейса, что бы визуально было видно что упирается. Как по мне так link aggregation это грех, купите сетевую 10гбит они не такие дорогие

да с абилсом видел на форуме, только исходники куда то делись

Кто нибудь пробовал прикрутить этот модуль в качестве NAS в stargazer, очень хотелось бы его видеть. У меня сейчас (правда не в stg): zeleniy@router:~$ /usr/local/ISG/bin/ISG.pl show_count Approved sessions count: 1575 Unapproved sessions count: 34 Штука реально работает в продакшен, нагрузка на сервер меньше, чем при использовании HTB.

дайте конфигурацию на Dell PowerEdge R200

А почему не срабатывает шифт 3? ситуация один в один, ни та ни та комбинация не срабатывает, ни через гипертерминал ни через putty

было такое, в конфиге может быть настроено disable_password_recovery, или еще может зависеть от прошивки. Везите в Длинк

Добрый вечер, ищем 1-2 волокна под выкуп или в аренду в г. Алушта, точка А - ул. Чатырдагская 1а, точка Б - рабочий (профессорский) уголок. Рассмотрим все ближайшие муфты или кросы

вот если бы вы его еще модулем 10 гиговым укомплектовали....естественно с повышением цены=)

нет, это невозможно, такая технология/ Возможно передумают и дадут операторам со спутника забирать. Если не ошибаюсь висят на 31 градусе

если не ошибаюсь это это комбо-порты, т.е. или оптика или медь

конечно!!!, эти же дебилы для провайдеров ничего не дают, ни тюнеров, ни камов многоканальных. Хотим видеть плату с CI+ слотом. А в универсальном услуге им подавай канальчики. Ладно если бы альтернатива была на спутнике, так нету киноточки, винтажа, эскулап и прочего отстоя, который даже за бесплатно смотреть не возможно

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

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

резерв до выяснения, что в комплекте? уши есть? резерв снят

Юзера получают адреса по DHCP, никаких статических привязок. Все работало до поры до времени пока не начали наблюдать странности с попаданиями валидных маков в блок, т.е. мак сервер знает и дает по нему ип, но свич его не разрешает, а блокирует. Вторая проблема - связка в таблице есть, трафик бегает но почему-то с громадными дропами. При этих проблемах потерь на линках магистраль/абоненты нет Переключение режима работы адрес_биндинга в АЦЛ результата не дало. Все проблемы лечатся выключением адрес_биндинга. Прошивки вплоть от 1,52 до 1,80. Причем есть попадаются свичи где прошивки/конфиг идентичны но на одном блочит/дропает трафик, а на другом все окей. у меня юзеры тоже ip получают по DHCP, просто на свитче статическая таблица, ее содержимое меняется когда меняется в биллинге мак адрес и ip адрес клиента

У абонентов стоят роутеры 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 и все нормально работает неделями (проверено)

незнаю как это работает у ТС, но у меня работает в таком виде на разных свитчах 3526,3528,3028,3200-10,3200-18,3200-26-с1,3552 уже года 3 где-то show address_binding ip_mac allshow address_binding blocked all В студию. Ну то что он работал год - это как бы еще не показатель. Может он у Вас год не перегружался - т.е. свич с мущинским аптаймом, и Вы просто не попадали в такую ситуацию.Просто если такое горе наблюдается, то порверять надо все тотально. Как то слабо верится в то, что это аппаратная проблема. Я правильно понимаю - у вас после перезагрузки абонентов не блочит, а возникают именно потери до них? show error ports 1-24 что нибудь интересное говорит? бывало такое пару раз на 3526 при подключении нового клиента (в то время как все остальные нормально работали), решалось перепрошивкой на последнюю версию. Поверьте я подставлял свой ноут на линуксе вместо абонентского, прописывал себе его мак, поставил на пинг - есть пинг, ушел курить прихожу пинга нет - чудесно, включаем мультискатовый канал в влц - работает и не рассыпается, переключаем канал на другой- работает (это я к тому, что если кто скажет что мультик из буфера показывает), а пинга так и нет, спустя несколько минут пинг заработал снова. Загрузка процессора в этот момент 20%. В safeguard engine не уходит

show address_binding ip_mac allshow 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

сначала попробую туда поставить такой же свитч, а тот разберу и проверю кондеры, просто делали уже все кроме замены свитча, есть такие же 3200-26 из той же партии, но в другом районе и сегменте сети, так эл-во не отключали и все ок работает

забивается оператором по snmp Второй вопрос:Насколько я понимаю, если у Вас "оператор" (биллинг) ходит snmp-ём на свич и приводит состояние привязок ip-mac-port в соответствие с "действительностью" и не сохраняет конфиг после этого, то после ребута свича он просыпается с чистым "мозгом" (т.е. без этих привязок), но с четкими указаниями на то, что если придет незнакомец - блочить. Что он похоже и делает. Вы как то специально отрабатываете подобную ситуацию? нет, в скрипте после операций с ipmb идет save, у меня немного не такая ситуация как у ТС, у меня потери до клиента если включен ipmb Чудесно, т.е. правильно ли я понимаю, что Ваш свичь поднимаясь из холодного ребута имеет в конфиге все привязки ipmb?Тогда следующий вопрос - После загрузки свича Вы видите "валидных" абонентов как "блокированных"? нет не вижу, т.к. они после включения получают по dhcp адреса и в fdb они dynamic forward. Повторю еще раз, свитч работал в таком режиме более года, проблемы начались после многократных отключений электроэнергии в этом районе

забивается оператором по snmp Второй вопрос:Насколько я понимаю, если у Вас "оператор" (биллинг) ходит snmp-ём на свич и приводит состояние привязок ip-mac-port в соответствие с "действительностью" и не сохраняет конфиг после этого, то после ребута свича он просыпается с чистым "мозгом" (т.е. без этих привязок), но с четкими указаниями на то, что если придет незнакомец - блочить. Что он похоже и делает. Вы как то специально отрабатываете подобную ситуацию? нет, в скрипте после операций с ipmb идет save, у меня немного не такая ситуация как у ТС, у меня потери до клиента если включен ipmb

извиняюсь, искал спойлер не нашел, подскажите исправлю