[anp/hsw]

Значит они платили столько. Сомневаюсь, что UPS им бесплатно все возит. Если бы ты хоть раз оформлял RMA на устройства ubiquiti, то не задавал бы такой вопрос. Скорее всего, платил UBNT, также как и за доставку. Я прекрасно знаю, и знаком с историями, как ДНС растаможивает видеокарты и процессоры по 4 евро за кило. Но тут не моя печаль - таможенное оформление происходило брокером от UPS, и кроме нескольких вопросов от меня он ничего не хотел, в том числе финансово. Хотя я прекрасно знаю, насколько они все любят деньги за каждый чих брать, но видимо все было оплачено UBNT. Бесплатно же они не работают.

Знатно у вас подгорело! Сомневаюсь, конечно, что они с UPS по розничным ценам работают, но ничто не мешало им отправить обычной почтой, груз-то немалый. Как они там документы оформляли - хз, но никаких пошлин с меня не брали, все уже было растаможено по получении. А их и не ввозят. Вы попробуйте у дистрибьютеров их заказать - ответят сертификация в процессе, дату поставки вам назовут.

Так это все выполнено. Вы можете ввести хоть с луны железку, если она уже сертифицирована. У нас при ввозе сертифицировалась EU-версия (отдельной RU- версии не делают). Везет какой-нибудь wmd фуру железок из латвии. Они сертифицированы. Где тут вы усмотрели серый или черный ввоз?

Видимо он и платит, т.к. у сломаного железа на экспорте цена 0, и я ничего не платил. При импорте также не платил, таможню прошло нормально (доставка UPS, если что, оформление брокером как возврат из ремонта). И каким образом он перестал быть сертифицированым? У железок одна и та же модель, та же NSM5-EU - что для России, что для Латвии. Там только для US-версии условия особые. Забавно. Я хотя бы отправлял в ubiquiti дохлое железо на замену в не очень маленьком обьеме, и назад оно мне также приходило успешно. А что вы? Ах, в газетах прочитали, и теперь фантазируете? Мои возражения исключительно о том, что вы уже сказали (=написали). Возразить на еще не сказаные ваши фразы я не могу, т.к. не знаю их содержания :)

Выкидываете вместе с VLAN, например? Как с ним быть? Сейчас на каждый уровень модели OSI нужно разное количество ресурсов. Вы же предлагаете убрать L2, и запихать его функционал спомощью костылей в L3. Какую задачу это решит?

Вы не дописали до конца? Зачем тогда опубликовали пост? Допишите и публикуйте. Раз сообщение дописано, значит ваша мысль в ней закончена. Для "потом" идите откройте отдельную тему, и там пишите. А "тут" все подчиняется правилам общения на форуме, и не вам их менять.

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

Т.е теперь еще нужен CPU, который будет обрабатывать RA? А вот тут по-подробнее: если переложить модель VRRP на вашу, то получается, что с двух портов будет приходить одинаковый префикс, так? Какой из них будет главным? Т.е. при замене свича на свич с другим количеством портов, адресные пространства будут смещаться? Отлично, вы выдумали еще одну проблему на пустом месте! Ваш свич собрался коммутировать только в одну сторону? Как быть с ситуацией, когда сетей больше одной, и одну из них надо нарезать "в другую сторону"? А что если статически резать я не хочу, а хочу отдать в один из портов сеть "как есть"? И таких "если" - довольно много. Такими вещами в ASIC уже не заставите заниматься, ему нужна помощь CPU. Итого мы приходим к тому, что ваш свич будет в несколько раз дороже обычного. С этим можно жить, если вы сможете пояснить, какие преимущества он будет нести?

Вы плохо представляете, какие вычислительные ресурсы требуются, чтобы хотя бы на 100 мегабитах такое запустить. Весь мировой интернет не сконцентрирован в коммутаторе. А значит он еще и сам будет решать, к какому из аплинков пускать трафик? Не иначе как ospf или bgp там будет?

И сразу перестают работать протоколы типа LACP, VRRP о прочего, завязаные на том, что у двух хостов может быть один и тот же IP-адрес, или распределяющие потоки согласно MAC-адреса а не IP. Вы же не будете делать "специальный IOT коммутатор"? Стандарт - он для всех. Как-то надо будет реализовывать подобные фичи, чтобы быть совместимыми в другими коммутаторами. Опять же - сколько там IPv6-адресов-то? Даже в современных коммутаторах все мак адреса (всего 6 байт!) не влезают в коммутационную матрицу, и приходится считать от них хэш бит так на 12-14, и по нему работать. Как вам больше нравится? Килобитные скорости, или адресные коллизии на каждом втором пакете?

Во-первых - это значит отказаться от поддержки всего существующего парка устройств, которые его поддерживают. Поддержка многих устройств уже давно закончилась, как пример - всякие ЧПУ станки, системы автоматизации, итд. Во-вторых - это задержки. ipv6 заголовок несколько сложнее ethernet, и сил для его обработки требуется побольше. Разбор ethernet кадров вылизан годами, а кто будет тестировать и оптимизировать обработку ipv6? Для всяких систем особой важности это критичный фактор. В-третьих - за чей счет банкет? IP-блоки, чтобы построить свой чип для ethernet-коммутатора можно чуть ли не в свободном доступе найти. Кто будет разрабатывать IPV6-only свич, если большинству заказчиков он не нужен?

Затем, что кроме ipv6, есть еще много протоколов, работающих по L2. Хоть они и менее распространены, это совсем не означает, что на них можно положить болт.

Вот сейчас бред был. Зайди в любую ethernet-сеть крупного оператора, и посмотри, сколько там broadcast и multicast трафика тебе неподредственно не предназначеного. А еще мультикаст маршрутизируется (хотя это и довольно редкий случай, DVMRP уже забыт), для этого есть mrouted. Если ты не знал, то маршрут до одной и той же сети может быть более, чем на одном интерфейсе. И это нормально. Зацепиться на raw socket - много ума не надо. Только правильный ли это путь при наличии всех инструментов в сетевом стеке?

Это все полная херня, в том числе то что написано на сайте UBNT. И об этом тоже говорится в той скандальной статье. Это шикарно! Сам производитель обьявил кого-то дистрибьютером, а вы отнекиваетесь и убеждены в обратном.

Нечего там смотреть, будет также, как в FC-6s - внешне он примерно похож, а внутренее - плохое литье, совсем грубо обработаные поверхности, регулировочные винты ничего не регулируют, ну и конечно, контейнер с ним работать не будет. Я даже видел в продаже китайский контейнер для сбора осколков. Как он работает? Его нужно открыть, рукой поместить туда осколок, закрыть :)

Это уже просверлил кто-то. Такого винта там не может быть - используются шестигранники. В моем CT-30, который близко лежит, тоже отверстия нет.

Он явно не первой свежести :) Сдается мне, что это чехол от CT-10A. У меня такие где-то есть, и синий и зеленый. Чехлы для CT-30 шли сразу большие, т.к. контейнер продавался отдельной опцией, но конструктивно для него было все реализовано.

Один из kit-а к сваркам, другой - индивидуальный выпуск. Посмотрел свою складскую табличку - все ct30, которые покупались китом с аппаратом, имеют 5-6 значный серийник без нуля в начале. CT-30 и CT-10A, покупавшиеся отдельно, имеют серийник с ноликом в начале. Они все из металла, на правом просто версия "без резинки", поди и софт-тача на нем тоже нет?

Не удивительно, ведь там заявлено железо 802.11а - а значит 5ггц. Тут бы хорошо, если 2.4 заработает, а то может придется и 900мгц искать железки.

Это исключительно проблема криворукости настройщика. Достаточно добавить роут для мультикаста по самой широкой маске в нужный интерфейс, чтобы rp_filter его пропустил. Собственно, это и будет вашим "добавлением исключения".

Добавились наработки по Zyxel PMG5318-B20A, Nateks FG-GPON-ONT-1GE, Egde-Core ECB2110-1G1

Там сейчас только "витуха до центрального узла в аренду". Был бы VLAN - другое дело. Целевая аудитория в "ПМ в ареду" - это юрики, и не самые нищебродские. Что будет, когда вместо них будет тысяча физиков? Если содержать вторую техподдержку, то тут и до полноценного оператора не далеко. А если без нее, то даже не знаю, как это провернуть в таком массштабе...

Мне интересно, что там будет с временем реакции на аварию (у кого-то оно и час, у кого-то и 48 часов) и с пограничными ситуациями, когда все друг на друга будут стрелки переводить например, при наличии потерь пакетов, а абонент будет сидеть без связи. Что будет, если начать тестировать их сопли в щитках каким-нибудь fluke, и он покажет несоответствие 5 категории? перекладывать будут? Решение интересное, но не законченое. Им бы следовало сдавать не кабельную инфраструктуру, а VLAN до абонента, тогда пограничных ситуаций намного меньше, и при адекватной цене операторы смогли бы с ними работать.

В логах точек доступа можно посмотреть, когда к ним подключались/отключались. И увязать это миграцией клиента. Вполне может оказаться, что в этот момент клиент никуда не переключался.

И там тоже есть ack'и, правда реализованые на более высоком уровне. Иначе бы ваш поток никогда не прекращался даже после отключения клиента. Сначала нужно ответить, что именно не устраивает в обычной миграции MAC-адреса в FDB путем получения пакета с другого порта.