У этой проблемы есть и продолжение! Если сделать в лоб то как вы описали - переписать флэшку с биосом с другого устройства - то происходит изменение идентификатора железки и в последствии слетают все лицензии которые были на этой АСА и при попытке их повторной установки железка по пол часа думает после чего даёт сбой. Поэтому мы пошли дальше и компилируем содержимое флэшек из заведомо рабочей и оригинальной АСА, дабы сохранить оригинальные идентификаторы и не наступать потом на эти грабли.
В целом я с Вами полностью согласен, но это не про UniFi.
Я потратил много времени на курение форумов различных вендоров для того, что бы понять, какое железо 100% сможет решить мои задачи. Т.е. это была аналитическая работа по выбору оборудования. Это и был мой капекс. С тех пор я просто знаю, что нужно ставить заказчикам, если им нужен хороший Wi-Fi не тратя времени на аналитику.
Первый купленный UniFi был настроен за 20 минут и с тех пор к конфигу больше никто не прикасался, даже при добавлении новых точек. Ubiquiti предлагает бесплатный софтовый контроллер для своих точек, фактически нужно конфигурить только его. Дальше достаточно воткнуть новую точку в нужный Vlan и она сама автоматически конфигурится контроллером. Всё работает полностью автоматически, а контроллер на котором поднято три SSID и HotSpot как я уже сказал конфигурится за 20 минут.
Так что с опексом всё отлично!
Более того, та же Cisco конфигурится гораздо дольше, но и умеет конечно тоже на порядок больше. При этом капекс у неё какой-то запредельный и для SOHO\SMB зачастую просто неподъёмный.
1) Статья которую вы приводите написана в марте 2011 года.
2) Я связывался с автором этой статьи где-то год назад, он лично подтвердил мне, что роуминг работает без проблем.
3) Я в сети находил несколько человек, описывающих реально работающие сети, где Wi-Fi IP-фоны живут под оборудованием UniFi, с бесшовным роумингом, разумеется.
4) Если глубоко покурить форумы UniFi то можно понять что роуминг у них работает и они его активно развивают.
5) Мы делали модернизацию беспроводной сети и основная причина была как раз в том, что нам нужно было обеспечить работу Wi-Fi IP-фонов как раз в бесшовном режиме, а они как вы понимаете весьма критичны к задержкам. У нас всё отлично работает уже год как, Переход между этажами (т.е. с точки на точку) при активном разговоре проходит без проблем, так что могу сам лично с уверенностью подтвердить, что бесшовный роуминг на UniFi — это факт.
Я вам озвучил про генераторов тонов не для того, что это крайне важная функция и нужно обязательно доработать, а для того, что бы понять что ещё даёт Microtest\Fluke за свои 500$.
Нужна эта функция бывает редко, особенно при хорошей маркировке кабелей и нормально документированной инфраструктуре, но вот когда разбираешься в чужой…
Но если добавление такого функционала не сильно повлияет на стоимость, то это конечно интересно.
У того же Microtest\Fluke Microscaner (по ссылке очень наглядная демка) есть кнопка mode и несколько режимов работы:
wiremap — даёт расклад по жилам
lengt — определяет длину кабеля
office — определение номера линка по специальным адапетерам
signal tone — генератор тонов
На счёт определения длины кабеля, я щаз помучал его в результате как я понял работает он так:
на том конце ничего нет — пишет OPEN, замеряет длину, причём может указать длину по каждой паре
на том конце инжектор (обратная сторона) — он не может замерить длину
на том конце коммутатор, порт 100Мбит — может замерить длину только по парам 4-5 и 7-8, причём ишет SHORT, т.е. коммутатор судя по всему закорачивает эти пары
на том конце коммутатор, порт 1Гбит — он не может замерить длину
на том конце ПК, порт 1Гбит — мерит длину по парам 4-5 и 7-8, но пишет под 400м на кабеле длиной 3м
на том конце ПК, порт 100Мбит — показывает по всем параш SHORT, мерит тоже по всем, но по парам 1-2 и 3-6 завыщает значение раза в полтора, а по парам 4-5 и 7-8 показывает честно.
как-то так.
Отсюда можно сделать вывод, что вам стоит лишь чуток доработать — при обнаружении активки на 100Мбит просто мерить по парам 4-5 и 7-8. С Гигабитными портами видимо никак.
вот тут и вот тут есть видео про генератор тонов.
Совместно с щупом позволяет найти нужный провод на той стороне, например в лотке или в стойке среди кипы других.
У Microtest\Fluke он может генерировать сигнал на любую отдельно взятую пару, т.е. можно найти даже конкретную пару в расшитой гребёнке с помощью того же щупа.
1) по сравнению с функционалом Microtest\Fluke:
— я так понял не умеет мерить длину кабеля при подключенном инжекторе (ответная часть) или активном оборудовании (?)
— нету генератора тонов для каждой пары
2) Но если откровенно 90% потребностей при саппорте LAN\СКС ваш девайс покрывает. Светодиодные моргатели стоят до 1000р., Microtest\Fluke порядка 500$. Если толкать ваш девайс с ценой до 3000р. (примерно 100$), то он будет выглядеть более привлекательно и вполне конкурентоспособно.
3) Размеры уменьшить было бы хорошо. В офисе для большой сети держать под рукой и так пойдёт, а вот на выезд с собой брать лучше что-то более компактное. Имхо можно размер экрана и шрифта уменьшить.
Да не было там storm-control — это точно!
Перечитайте мой ответ внимательно.
BPDU-то может и приходили, проблема в другом — проц 2950 из-за огромного кол-ва броадкастов просто не успевал их все обрабатывать, а у процесса STP тем не менее таймер-то тикал, и он приходил к выводу что BPDU вообще не приходят — вот вам и сработка по LoopGuard.
Хотя это лишь моё предположение, но других объяснений я тогда не видел, и сейчас не вижу.
P.S. Этот процесс сопровождался высокой загрузкой проца, что также было зафиксировано.
1. На доступе RSTP, в ядре MSTP. Какой именно коммутатор на тот момент был ROOT для данного vlan я точно не помню, вполне возможно, что как раз коммутатор с MSTP. Но TC там были точно, ибо я их лично снимал снифером с этой сетки, ну и со всеми вытекающими.
Кстати — ТЫЦ, см. раздел «New BPDU Format». Механизм другой, просто сокращено кол-во ситуаций, при которых выставляется флаг TC, но Topology Change никто не отменял.
2. В том же вилане находился и management интерфейс 2950, соответственно он пытался переварить весь этот шторм, проц там слабый и он моментально загружался, пропуская и\или не обрабатывая приходящие пакеты BPDU в том числе. Он не по шторму ложил порт, а по LoopGuard, так как не получал BPDU длительное время (статья начиналась строчкой из лога 2950).
Loop Guard – переводит порт в Inconsistent state, если порт перестал получать BPDU, изолируя таким образом проблемный участок сети от участия в построении STP. Применяется к конкретному порту командой spanning-tree loopguard enable. Используется глобально командой spanning-tree loopguard default. Невозможно использовать одновременно с RootGuard.
В данном случае была использована глобальная команда.
3. По комменту ниже — клался аплинк до распределения. И он(аплинк) там был один.
Вы предлагаете стартовать проект сетевого глоссария прямо тут в комментах, или просто порассуждать в рамках данной дискуссии?
Как я уже сказал маска она и в Африке маска. А вы можете как-то разделить термины для маски указывающей размерность сети на интерфейсе и маски указываемой в настройках динамических протоколов маршрутизации?
P.S. А заодно ещё и той маски, которая используется в ACL, она ведь тоже не является МАСКОЙ ПОДСЕТИ через который проходит фильтруемый трафик?
;)
Я прекрасно представляю, на что указывает МАСКА в команде network в OSPF и EIGRP.
Распространённым мифом, про который он упомнил не страдал и не страдаю.
Маска — она и в Африке маска и указывает именно на маску, очевидно же! )))))
Это всё понятно и известно.
Но в рамках поста про CCNA мы всё же говорим именно о cisco-вской реализации этих протоколов.
А в ней к сожалению RIPv2 не позволяет указывать маску в команде network и приходится лепить костыли.
Повторюсь, я не очень удачно назвал это отсутствием поддержки VLSM, но некоторое ограничение в работе тем не менее присутствует.
Заработает, так как в команде network указана сеть 10.0.0.1 и маска 0.0.0.0, которая объявляет все биты этой сети значимыми, а на интерфейсе у нас ровно то же занчение — 10.0.0.1. Т.е. OSPF вот только на этом интерфейсе и заработает (ну при условии, что нет других команд network).
Но ведь 0.0.0.0 — это и есть МАСКА, которая указывает нам какие биты считать значимыми, а какие нет.
А ну да… к маске ПОДСЕТИ это точно не имеет никакого отношения! Это другая МАСКА. Конечно, согласен. Не учёл слово «подсети», получилось, что «инверсная маска после «network» не имеет ни малейшего отношения к маске», что и вызвало непонимание.
Да, если это суммаризация сетей, у нас может быть сеть класса B (172.0.0.0), а маска /8. Т.е. маска отличается от классовой, но речь не идёт про VLSM, так как это суперсеть, а не подсеть.
В прочем это уже скорее тавтология ))))
В итоге можно привычно указать адрес и инверсную маску.
Увы, нельзя. Ip classless не помогает.
Вы, кстати, в курсе, что и в RIP, и в EIGRP, и в OSPF инверсная маска после «network» не имеет ни малейшего отношения к маске подсети? ;)
1) Я по прежнему настаиваю на том, что в RIP указать маску нельзя, ни прямую ни инверсную.
2) Ну в том же OSPF она только обратная и используется и указывает именно на МАСКУ. Не понял, что вы имели ввиду?
У этой проблемы есть и продолжение!
Если сделать в лоб то как вы описали - переписать флэшку с биосом с другого устройства - то происходит изменение идентификатора железки и в последствии слетают все лицензии которые были на этой АСА и при попытке их повторной установки железка по пол часа думает после чего даёт сбой. Поэтому мы пошли дальше и компилируем содержимое флэшек из заведомо рабочей и оригинальной АСА, дабы сохранить оригинальные идентификаторы и не наступать потом на эти грабли.
Так что если что обращайтесь, поможем - https://ciscoremont.ru/
;)
Почитайте про технологию Cisco CleanAir. Это конечно чисто маркетинговое название, но за ним тем не менее скрывается много реальных фич.
Я потратил много времени на курение форумов различных вендоров для того, что бы понять, какое железо 100% сможет решить мои задачи. Т.е. это была аналитическая работа по выбору оборудования. Это и был мой капекс. С тех пор я просто знаю, что нужно ставить заказчикам, если им нужен хороший Wi-Fi не тратя времени на аналитику.
Первый купленный UniFi был настроен за 20 минут и с тех пор к конфигу больше никто не прикасался, даже при добавлении новых точек. Ubiquiti предлагает бесплатный софтовый контроллер для своих точек, фактически нужно конфигурить только его. Дальше достаточно воткнуть новую точку в нужный Vlan и она сама автоматически конфигурится контроллером. Всё работает полностью автоматически, а контроллер на котором поднято три SSID и HotSpot как я уже сказал конфигурится за 20 минут.
Так что с опексом всё отлично!
Более того, та же Cisco конфигурится гораздо дольше, но и умеет конечно тоже на порядок больше. При этом капекс у неё какой-то запредельный и для SOHO\SMB зачастую просто неподъёмный.
1) Статья которую вы приводите написана в марте 2011 года.
2) Я связывался с автором этой статьи где-то год назад, он лично подтвердил мне, что роуминг работает без проблем.
3) Я в сети находил несколько человек, описывающих реально работающие сети, где Wi-Fi IP-фоны живут под оборудованием UniFi, с бесшовным роумингом, разумеется.
4) Если глубоко покурить форумы UniFi то можно понять что роуминг у них работает и они его активно развивают.
5) Мы делали модернизацию беспроводной сети и основная причина была как раз в том, что нам нужно было обеспечить работу Wi-Fi IP-фонов как раз в бесшовном режиме, а они как вы понимаете весьма критичны к задержкам. У нас всё отлично работает уже год как, Переход между этажами (т.е. с точки на точку) при активном разговоре проходит без проблем, так что могу сам лично с уверенностью подтвердить, что бесшовный роуминг на UniFi — это факт.
Вы мерите только OPEN, а он умеет мерить SHORT — я проверил, просто закоротил два контакта — мерит очень точно.
Нужна эта функция бывает редко, особенно при хорошей маркировке кабелей и нормально документированной инфраструктуре, но вот когда разбираешься в чужой…
Но если добавление такого функционала не сильно повлияет на стоимость, то это конечно интересно.
У того же Microtest\Fluke Microscaner (по ссылке очень наглядная демка) есть кнопка mode и несколько режимов работы:
wiremap — даёт расклад по жилам
lengt — определяет длину кабеля
office — определение номера линка по специальным адапетерам
signal tone — генератор тонов
На счёт определения длины кабеля, я щаз помучал его в результате как я понял работает он так:
на том конце ничего нет — пишет OPEN, замеряет длину, причём может указать длину по каждой паре
на том конце инжектор (обратная сторона) — он не может замерить длину
на том конце коммутатор, порт 100Мбит — может замерить длину только по парам 4-5 и 7-8, причём ишет SHORT, т.е. коммутатор судя по всему закорачивает эти пары
на том конце коммутатор, порт 1Гбит — он не может замерить длину
на том конце ПК, порт 1Гбит — мерит длину по парам 4-5 и 7-8, но пишет под 400м на кабеле длиной 3м
на том конце ПК, порт 100Мбит — показывает по всем параш SHORT, мерит тоже по всем, но по парам 1-2 и 3-6 завыщает значение раза в полтора, а по парам 4-5 и 7-8 показывает честно.
как-то так.
Отсюда можно сделать вывод, что вам стоит лишь чуток доработать — при обнаружении активки на 100Мбит просто мерить по парам 4-5 и 7-8. С Гигабитными портами видимо никак.
Совместно с щупом позволяет найти нужный провод на той стороне, например в лотке или в стойке среди кипы других.
У Microtest\Fluke он может генерировать сигнал на любую отдельно взятую пару, т.е. можно найти даже конкретную пару в расшитой гребёнке с помощью того же щупа.
— я так понял не умеет мерить длину кабеля при подключенном инжекторе (ответная часть) или активном оборудовании (?)
— нету генератора тонов для каждой пары
2) Но если откровенно 90% потребностей при саппорте LAN\СКС ваш девайс покрывает. Светодиодные моргатели стоят до 1000р., Microtest\Fluke порядка 500$. Если толкать ваш девайс с ценой до 3000р. (примерно 100$), то он будет выглядеть более привлекательно и вполне конкурентоспособно.
3) Размеры уменьшить было бы хорошо. В офисе для большой сети держать под рукой и так пойдёт, а вот на выезд с собой брать лучше что-то более компактное. Имхо можно размер экрана и шрифта уменьшить.
Я думаю многие админы\телекомщики с удовольствием закупились бы подобным девайсом.
Не думали о маленьком стартапе на этой почве?
Отлиный перевод для «ZILLION».
Да, и большое спасибо за ваши переводы!
Согласен. ))))
Перечитайте мой ответ внимательно.
BPDU-то может и приходили, проблема в другом — проц 2950 из-за огромного кол-ва броадкастов просто не успевал их все обрабатывать, а у процесса STP тем не менее таймер-то тикал, и он приходил к выводу что BPDU вообще не приходят — вот вам и сработка по LoopGuard.
Хотя это лишь моё предположение, но других объяснений я тогда не видел, и сейчас не вижу.
P.S. Этот процесс сопровождался высокой загрузкой проца, что также было зафиксировано.
Кстати — ТЫЦ, см. раздел «New BPDU Format». Механизм другой, просто сокращено кол-во ситуаций, при которых выставляется флаг TC, но Topology Change никто не отменял.
2. В том же вилане находился и management интерфейс 2950, соответственно он пытался переварить весь этот шторм, проц там слабый и он моментально загружался, пропуская и\или не обрабатывая приходящие пакеты BPDU в том числе. Он не по шторму ложил порт, а по LoopGuard, так как не получал BPDU длительное время (статья начиналась строчкой из лога 2950).
В данном случае была использована глобальная команда.
3. По комменту ниже — клался аплинк до распределения. И он(аплинк) там был один.
P.S. я когда-то описывал подобную проблему — ТЫЦ, можете почитать для ознакомления.
Как я уже сказал маска она и в Африке маска. А вы можете как-то разделить термины для маски указывающей размерность сети на интерфейсе и маски указываемой в настройках динамических протоколов маршрутизации?
P.S. А заодно ещё и той маски, которая используется в ACL, она ведь тоже не является МАСКОЙ ПОДСЕТИ через который проходит фильтруемый трафик?
;)
Распространённым мифом, про который он упомнил не страдал и не страдаю.
Маска — она и в Африке маска и указывает именно на маску, очевидно же! )))))
Но в рамках поста про CCNA мы всё же говорим именно о cisco-вской реализации этих протоколов.
А в ней к сожалению RIPv2 не позволяет указывать маску в команде network и приходится лепить костыли.
Повторюсь, я не очень удачно назвал это отсутствием поддержки VLSM, но некоторое ограничение в работе тем не менее присутствует.
Заработает, так как в команде network указана сеть 10.0.0.1 и маска 0.0.0.0, которая объявляет все биты этой сети значимыми, а на интерфейсе у нас ровно то же занчение — 10.0.0.1. Т.е. OSPF вот только на этом интерфейсе и заработает (ну при условии, что нет других команд network).
Но ведь 0.0.0.0 — это и есть МАСКА, которая указывает нам какие биты считать значимыми, а какие нет.
А ну да… к маске ПОДСЕТИ это точно не имеет никакого отношения! Это другая МАСКА. Конечно, согласен. Не учёл слово «подсети», получилось, что «инверсная маска после «network» не имеет ни малейшего отношения к маске», что и вызвало непонимание.
Да, если это суммаризация сетей, у нас может быть сеть класса B (172.0.0.0), а маска /8. Т.е. маска отличается от классовой, но речь не идёт про VLSM, так как это суперсеть, а не подсеть.
В прочем это уже скорее тавтология ))))
Увы, нельзя. Ip classless не помогает.
1) Я по прежнему настаиваю на том, что в RIP указать маску нельзя, ни прямую ни инверсную.
2) Ну в том же OSPF она только обратная и используется и указывает именно на МАСКУ. Не понял, что вы имели ввиду?
)))))))