EDA_SPB

Хороший вопрос, я уже и не помню как он появился. Скорее всего, менеджер прислал. Вот недавно упало письмо в почту от cdata, есть еще какая-то облачная платформа.

У c-data же есть NMS, там все мышкой. Бесплатно.

Пока мы не узнаем необходимые параметры канала - говорить об технических решениях рановато. Может там телеметрией надо обмениваться раз в сутки. Или 100500 hd потоков. Замечу, что отклонения планируются не только по горизонтали, но и по вертикали.

Не совсем так, pLTE - это частная лте сеть. Вы решаете вопрос с частотами, покупаете БС и ядро сети, ставите, настраиваете и используете ресурсы как вам надо. Сейчас это более чем реально, технически не так сложно, как можно подумать. Если надо будет, рекомендую обратиться к Bandit. Но в вашем конкретном случае это решение вряд ли поможет. Вам нужна точка-точка, а pLTE - это когда надо собрать трафик с множества терминалов на какой-нибудь территории.

Сейчас нет калькулятора под рукой, но, кажется, маловато. Насколько помню, зона френеля в 5 ггц будет метров 16. Плюс вода... Вам какая скорость канала нужна? Доступность?

Я думаю, тут странно обсуждать микротики и им подобное. На 20 км по воде какая высота подвеса нужна? Реально ли ее обеспечить на корабле/лодке, даже не беря в расчет подвижность объекта?

А вообще есть тут в треде пользователи Гидры? Как сам биллинг? Мое знакомство с ним закончилось на версии 4.0, 6.0 должна быть сильно лучше. Как тех. поддержка? Читаю контракт, оплата ТП по часам, что смущает. Это всегда невыгодно для клиента. Но, с другой стороны, не вижу в какой другой форме можно было бы формализировать отношения.

@alexs200, Вы без эмоции еще раз прочитайте контракт с Латера на поставку Гидра-4. Какие у вас есть права, что вообще за продукт вы купили, в каком составе. Повторюсь, очень большая вероятность, что по контракту обновления версий, патчи и т.д. бесплатно. Такой пункт был в типовом контракте у Латера. Т.к. Гидра-4 не обновляется до Гидра-6 (там другая архитектура), то заплатить за внедрение по второму разу, скорее всего, придется. Что касается диска, посмотрел один договор Латеры - там говорится, что заказчик имеет право сделать резервную копию на случай утери/порчи оригинала. Но нет пункта об повторном предоставлении дистрибутивов. Вообще Гидра не про самостоятельную эксплуатацию. Такое решение подразумевает внедрение и поддержку. Возможно, Гидра не совсем целесообразна при 1к пользователей, требования к железу у нее приличные. Думаю, самый оптимальный путь - договориться о внедрении 6ой версии с минимальным участием Латеры для экономии ваших денег. Кстати, внутри Гидры Oracle... На территории РФ не получить официально лицензию, насколько мне известно.

@alexs200 , приветствую. Читайте контракт, как я понимаю, у вас он на неэксклюзивное право использования ПО? Очень часто там есть пункт, что исполнитель обязуется предоставлять обновления и новые версии. У Латеры точно был до 2016г. Я извиняюсь, откуда у вас цена 400к? Это на 1к пользователей запрос от Латера?

Привет всем, откопали древность - старые ону cdata, определяется как model 400w в веб интрефейсе модуля pon или как onu4few в nms от cdata. Установили штук 30, начались с ними проблемы - время от времени перегружается pon модуль (в них еще есть отдельный управляющий проц, с ним все ок). Логи молчат. Перед перезагрузкой pon модуль выдает радостно в консоль: Not register reset system! Помогает перезагрузка по питанию и (вроде бы, не уверен) перетыкание оптического кабеля на стороне онушки. Проблема воспроизводится даже на коротком патчкорде. Никто такое не встречал? Нет ли в природе прошивки для этой ону, у нас должна быть древняя (Software v2.1.10, Firmware 6.15.1.14), долго лежали на складе.

Привет всем. Есть древняя 6500 с древним ios 12.2. Обновить ее никак нельзя. Рядом стоит не менее древняя 4924 с такой же версией ios. На обеих железках есть SVI c helper. Далее интересное. Есть сервер, который генерирет dhcp запросы как в сторону 6500, так и в сторону 4924. Так вот 6500 почему-то заполняет arp таблицу SVI c helper при получении DHCPACK. Т.е., судя по всему, берет CIADDR, CHADDR прямо из dhcp пакета и заполняет arp этими данными. 4924 в этом не замечена. Для меня это проблема, т.к. на сервере, который генерирует dhcp запросы, стоит специальное ПО. Это ПО прячет все полученные от DHCP сервера IP за один мак. Который, естественно, не совпадает с маком в DHCPACK. Получается, что arp таблица на 6500 заполняется маками из DHCPACK. Если arp таблицу почистить вручную, то 6500 сделает нормальный arp запрос, получит мак и все проработает до следующей коммуникации с dhcp сервером. Всякие dhcp snooping отключены на 6500. Можно ли отучить 6500 от такого поведения?

Да, они же стандартно поддерживают режим AP. До 30 юзеров работает нормально. Потом на прошивке 3.5.6 начинаются ребуты у нас.

Китайские TBS никто не использовал?

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

Есть такое.