Валентин

Пробовал кучу разных тудушек для личного использования, так ничего и не выбрал. Потом остановился и задумался на счёт методологии. Таск менеджеры - это всего лишь автоматизированная система. Чтобы что-то автоматизировать, нужен сам базовый процесс. Поэтому я взял обычный бумажный ежедневник (На самом деле тетрадь со сменным блоком), и стал его вести в разрезе дела на день, на неделю, заметки по ходу встреч, используя методологию bullet notes. Теперь это уже стало возможно автоматизировать, но Опыт показал, что заметки, написанные от руки, усваиваются лучше. А для информации, которую нужно сохранить для себя на будущее, я выбрал обсидиан+Gitnotes, но это решение уже типа персональной вики.

Не изобретайте велосипед, а погуглите маркёры для подмены/вставки рекламы (scte-35, scte-104) и вообще про технологию dynamic ad insertion.

Ни разу не сталкивался с ТЗ по 19 (ЕСПД), но постоянно работаю с ТЗ по 34 (АС). Тем, кто говорит, что ГОСТ это про бюрократию, рекомендую в ограниченные сроки создать автоматизированную систему с нуля хотя бы масштаба одного города, в которой будут работать хотя бы человек 20, поработать с инфобезом по ней. Сразу станет понятно, для чего ГОСТ 34 нужен, и ПМИ для чего, и проект на систему.

По-нормальному только BGP со своим блоком адресов/ASN или внешний хостинг. Лайфхаки:
1) два разных домена к разным адресам, например eth0.example.com и lte0.example.com. Навряд ли в случае обрыва ВОЛС на lte пойдёт куча удаленных клиентов.
2) внешний сервер со статическим адресом, пара туннелей до него с вашего расположения, маршрутизация трафика через сервер (если трафик к сайту небольшой).
3) v6 для внешних сервисов
4) Если количество пользователей ограничено, можно завести отдельный DNS сервер с низким TTL, пользователям прописать у себя этот DNS.

BGP, CEF, vPC/VSS, Nexus

Это несложно, тем более VSS уже вообще дохнет. Идите работать в большой город в оператора, там поработаете с этим на практике.

Другой вопрос вообще о перспективности работы сетевым инженером.

Датаграмма - набор байт. Что вы в нем закодируете - ваше усмотрение. Но как бы для того, чтобы json стал набором байт и был распознан, надо ещё определить кодировку, а чтобы он корректно прочитался, надо обеспечить сохранение порядка пакетов и корректную разбивку по пакетам большой порции данных. И как правило от UDP ждут быстрой обработки, а нагружая содержимое датаграммы jsonом (который, кстати, при определенных условиях может долго парсится), теряется смысл.
Самое простое кодировать значения байтами и битами.

Никаких. Если бы блокировали, по ipv6 он был бы доступен

Вопрос - есть ли у кого-то опыт взаимодействия с MSK-IX - можно ли кому писать/звонить, если ты не провайдер? Или только через своего провайдера?

Даже оператор не может повлиять.

У М9 нет проблем (это же просто ЦОД, ну или роуте-сервер), Проблемы на межопнрпторском стыке.

Самый примитивный сислог - netcat, запущенный на определенном порту и пишущий весь вывод в файл. А просмотр - на это в консоли полно инструментов. А вы тут докеры, отдельный софт...

IP адреса компьютеров, серверов, телефонов, принтеров, видеокамер

Решения типа IPAM. В зависимости от объема данных и количества пользователей разные продукты (от экселя до промышленных Network Resource Inventory).
Для серверов - решения типа CMDB.
Единого инструмента не будет, так как у всех своя особенность. Ну и надо плясать от ваших потребностей, для ведения IP плана на небольших проектах у меня отлично работает excel с выгрузкой в confluence.

Минимальное значение фрейма для обычного Ethernet равно 64 байта. Это известная вещь. Но вокруг этого образовалось множество легенд и домыслов.

Такой размер фрейма идет еще с Ethernet I, это было сделано для корректной работы алгоритма CSMA/CD. Напомню, в общей среде передачи для устранения коллизий (это когда одновременно несколько устройств будут передавать по одному и тому же проводнику одновременно сигнал) в Ethernet для каждого устройства отводится свой слот времени на передачу. То есть одно устройство должно отправить, а другое - принять, за определенный тайм-слот (да, это механизм Time Division Multiplexing). На это у нас влияет физика в виде ограничения на скорость распространения света. Примем следующую формулу:

2*L = C * t
t = S/Bandwidht
L = C * (S/Bandwidth)/2,

L - максимальная длина среды (провода)
t - время на прохождение сигнала
S - размер кадра
C - скорость распространения сигнала в среде (скорость света умноженная на коэффициент задержки сигнала в среде)

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

Конкретные расчеты приводить не буду, но для 10М Ethernet дистанция получается 5,12 км, а для 100М - 512 м, для 1000М - 51,2 м. Это при 64 байтах. Уменьшаем размер фрейма - получаем расстояние в 2 раза меньше (уменьшаем же по степеням двойки).

Умные люди подумали, что для 1000Base-T максимальное теоретическое расстояние в 51 метр слишком мало и сделали рекомендацию - минимальный размер кадра для 1000Base-T увеличить до 512 байт. При этом расстояние получилось около 409,6 м.

Все это был вольный пересказ ответа на стек-овер-флоу .

Теперь как это было реализовано. Формат кадра для 10/100М Ethernet представляет следующий вид:



Pad-добиваем нулями до минимального размера кадра. Делается это на MAC-уровне (читай, на L2, привет, модель OSI).

А для 1000Base-T уже добавляем еще и поле Carier Extension. Причем из интересного, в отличие от Pad Field, оно уже забивается не нулями, а специальной последовательностью символов, генерирующихся на PHY уровне (опять привет, модель OSI).

А для 1000Base-T уже добавляем еще и поле Carier Extension. Причем из интересного, в отличие от Pad Field, оно уже забивается не нулями, а специальной последовательностью символов, генерирующихся на PHY уровне (опять привет, модель OSI).



Такой минимальный размер кадра в 512 байт верен только для режима half-duplex Gigabit Ethernet с включенным CSMA/CD. При full-duplex он не добавляется. Иначе было бы невозможно строить линии на сотни километров через DWDM или даже спутник. Но минимум в 64 байта все же остается. Мне кажется, это не стали убирать из-за того, что куда уж меньше (64 байта - 14 байт на заголовки - 2 на FCS, а дальше уже внутренние заголовки надо вычитать…). Можете поэксперементировать хоть даже на виртуалках между виртуальными интерфейсами - фрейм добивается нулями. Подробнее со структурой посмотрите здесь.

Кроме того, значения значения в поле Type/Length согласно IANA должна быть представлена максимальная длина фрейма 0x0000-0x05DC (пусть этим сейчас никто и не пользуется, сейчас в большинстве случаев здесь будет 0x8000 - IPv4, ну или что-то другое с VLANами, если снимать дамп с транкового порта). Собственно, это причина, почему на коммутаторах максимальное значение L2 MTU равно 1500 байт.

Пытливый читатель спросит, зачем использовать full-duplex в 1000Base-T, ведь там всегда сигнал передается в одну сторону по своим двум парам, в обратную - по другим. Ответ - для того, чтобы использовать гигабитные хабы. Когда вы используете хаб, уже по двум своим парам могут побежать пакетики от двух хостов. Другой вопрос, что в природе таких, наверно, не существовало.

Если вы задумаете, зачем сейчас об этом думать, то есть и другие современные технологии с множественным доступом к одной среде. Например, всем известный wifi. И там также работает алгоритм CSMA/CD (только его вариация - CSMA/CA, там посылается отдельный типы фреймов RTS/CTS. Но, как говорится, это уже совсем другая история, о которой в деталях можно почитать по ссылке.

Это что, вопрос из дампов CCNA? Подумайте, с какого IP адреса на какой должны идти пакеты и под какое правило маршрутизации они попадают. Подсказка: что-то не так на R2 со статическим маршрутом.

В расчёте не указаны график работы людей: 7x24, 8x5. 6 FTE для 24x7 не пришей кобыле хвост, комплектовка смены делается из расчета 5 ш/е на одного постоянно работающего инженера.

Считаем, что при вашем уровне SLA недоступность должна быть 36 часов в месяц. Это первый KPI. Заводим требование - максимальное время разовой аварии, например, 4 часа. Итого, в месяц не больше 9 аварий, то есть не больше двух аварий в неделю. Если заниматься только этим, это покроет 5 описанных ш/е.

Все задачи на дежурную смену классифицируем: критичная, некритичная, обычная, для каждой делаем режим и нормативные сроки обработки (для критичной мы уже поставили). Доля обработанных задач в срок задач - второй KPI.

Добавляем профилактические работы, своевременность их проведения - третий KPI.

Я могу ещё много накрутить, но в итоге у вас получится формула KPI, которую вы будете оптимизировать.

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

Вай-Фай на таких объектах становится частью производственного процесса, поэтому нужно стабильное радиопокрытие. Нужно профессиональное радиоизмерение и политики доступа к радиосети.
P. S. Сталкивался с самодеятельным колхозом, в результате которого останавливалась отгрузка товара.