bqd

Коллеги, вы осознаете, что мы вынуждены своими руками строить газенвангены? И я тоже вынужден под страхом даже не штрафов, (штрафы там копеечные пока), а административного давления от своего начальства, на которое давит их начальство, на которое давит администрация, которая не в теме и вникать не будет (мы не оператор связи), но ведь туда приходят официальные письма из РКН и надо исполнять. Не исполнишь - найдем того кто исполнит и пойдешь нахер. Да, я ни разу не дартанян. Такое же малодушное ссыкло. Тем не менее, как мне кажется, - это тот редкий случай когда перфекционизм не очень уместен понимаю, что трудно, но надо себя заставлять Нам приказали настроить БГП и НСДИ - мы настроили и отчитались. Все. Не работает - так и чудесно. Лучше чтоб никогда не заработало. Проявлять излишнее рвение - приближать всеобщую жопу А то получается газенвагены построили, а евреи не дохнут. Не порядок, надо на форуме спросить Васю, у него дохнут как положено Уж простите за аналогию про заполнение XML-ей опытом делиться полезно. Ведь от нас требуется корректное заполнение А корректную работу БГП и НСДИ пока не требуют. Требуют только чтоб было хоть как то настроено.

Спасибо! Очень интересная тема. И действительно самое сложное в этой схеме - договориться с аплинками пытаюсь уговорить двух ISP но пока безуспешно оба начинали с того, что не взлетит, потом что может и взлетит но низэнько. В общем неготиэйшн продолжается.... Есть у кого нибудь история успеха чтоб еще аргументов докинуть? И вот такой еще момент: пугают что если отказаться от ASN, RIPE отберет PI Это правда?

хуа S5735-L или S5735-S если нужен второй БП

Вы изменения внесли, значит приказ выполнили. Зачем вам чтоб оно работало? любите с пятницы записываться и веревку свою приносить

использую dokuwiki, но оно малость (лет на 10) уже устарело сейчас с нуля смотрел бы в сторону MkDocs (потому что модный маркдаун) в связке с self-hosted ReadTheDocs

да тоже думаю по первому варианту будет меньше всего влиять а например если в кронтаб прописать что-то типа */30 * * * * root /usr/bin/dig axfr @194.85.254.37 > /dev/null то вообще влиять не будет и кстати у меня axfr работает хотя никаких ip я никуда еще не сообщал

очень даже типичен андерлей для небольших евпн фабрик стандартно по ospf унамберд строится но на физических интерфейсах конечно. не представяю зачем это надо на svi делать в цод

unknown unicast возникает когда dst-mac нет в FDB (CAM) возможно камеры молчат и запись в CAM протухает поток этой беды можно ограничить если внести статическую запись мак адресов камер в конфиг свича как то так mac-address-table static 0011.2233.4455 vlan 100 interface ethernet 1/2

Весело тут у вас Собственно неудивительно - обычная реакция на агрессивную некомпетентность Автор, не обижайся, тут все когда такими были в той или иной степени. Это нормально, что чуваки по разные стороны ямы на кривой Данинга-Крюгера кидают друг в друга какашками Теперь попробую ответить на вопрос 1. Вопрос не по адресу. Провайдеры не имеют отношения к реализации TCP, его congestion алгоритмам и тюнингом сетевых настроек клиентской ОС 2. Для TCP потока существует простая такая формула: throuthput = TCPWindowSize / RTT Понятно, что если ты хочешь разогнать поток до 100M при rtt 50ms то тебе нужно окно 100 000 000 * 0.050 / 8 = 625К Я не знаю какое максимальное окно задано по умолчанию в Windows. Там наверное есть ключи реестра для этого. Вот только эти ключи ничего не дадут так как iperf под windows собирается с использованием cygwin C последним iperf3 идет cygwin.dll версии 2.5.1 в котором максимальный TCPWindowSize выставлено в 278,775 Таким образом на потоке с RTT 50мс разогнаться дальше 44M никак не получится. 278,775 / 0.05 * 8 = 44 604 000 b/s В принципе если поставить последний cygwin отдельно от iperf то эта проблема решается. Но винда действительно плохо подходит под задачу. Кстать легко проверить как ключ -m отработал на клиенте. Просто поймай TCP SYN пакет на сервере WireShark-ом 3. Алгоритмы TCP Congestion чуствительны к потерям трафика. В легаси алгоритмах на каждый ретрансмит окно сжималось вдвое. Сейчас лучше, но не радикально. Понятно, что если у тебя единственный поток то он один за всех и будет коллапсировать в ответ на каждый битый бит. А 20 потоков не заметят потери (кратковременной) бойца и канал получится утилизировать максимально. Так же совершенно очевидно, что вероятность потери пакета прямопропорциональна расстоянию (ну и количеству хопов конечно). А то что пинги не показывают потерь не значит, что их нет. Просто пинги, во первых, короче (у меня в Linux 84 байта о умолчанию), а во вторых - их пренебрежимо мало. сравни тест пингами и iperf-ом с точки зрения утилизации полосы: 1 vs 8333 пакет/с 84*8 vs 100000000 бит/с 4. Требовать от провайдеров работы однопоточного приложения в 2020 году ну настолько нелепо, что даже как то дико. Что это за задача такая - передавать файл в один поток несколько дней? Кому вообще нужны файлы? Почему его нужно передавать обязательно в один поток? Выглядит как будто Вы неспособны решить элементарную задачу - задеплоить приложение или сервис по передаче информации из точки А в точку Б по существующим каналам связи и поэтому решили взбодрить весь телеком. Может Вы троль?

А что так можно было? Я просто гуглил ZTP, а там для SRX все сложно и грустно значит поиграю в autoinstall мне как раз нужно подобное генератор конфигов автоматизировал, а дальше копипаста. некрасиво если получится отпишу конечно вопрос сходу: конфиг в каком формате задается? скобочки {} или set-ы?

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

очевидно, что 15М не получить на физическом порту в 10м я бы ставил 1Г просто потому, что таким образом убирается лишняя сущность half-duplex а дальше настраивать firewall policer-ы на нужную скорость и вешать на нужные интерфейсы

Про микротики тоже ничего не знаю, но извините пройти мимо не смог. Для OSPF на p2p линках адрес не обязателен. Можно использовать unnumbered. В OSPF оно было всегда, но в последнее время стало очень популярно в дизайне фабрик. Настолько удобно, что парни из cumulus пошли дальше и придумали bgp unnumbered (технически адрес некст-хопа есть, но это линк-локал ipv6)

сам клиент из одной своей точки в другую или оператора попросить ну или, если мы про интернет, добавляется вариант с облачным iperf з.ы. зачем делать quote на соседнее сообщение?

в этом ипрелесть UDP - сервер на стороне клиента не нужен И входящий поток нужно не генерить, а мерить. счетчики интерфейса считывать любым удобным способом. я для этого в observium/librenms смотрю на входящий порт в режиме realtime Либо в графане через заббикс если нужно промерить поток в конкретном QoS классе, благо iperf умеет в ToS