Что бы абсолютно точно не было никогда никакого совпадения без VRF и MPLS достаточно было бы "позаимствовать" честную белую сеть, про которую вы точно знаете что она никогда вам не пригодится, зарегестрированную за условным Зимбабве и туда же смаршрутизированную
Вероятность что вы захотите установить прямой коннект с каким-то пользователем "Зимбабве-телеком" исчезающе мала
Это если совсем лень адресацию менять каждый раз.
Второй варинат - more specific Я очень сомневаюсь что автору на самом деле нужно /24 в его стойке, /28 где то из bogon если не хочется брать реальник, из середины диапазона, что бы меньше вероятность сопадения со шлюзом была
Не совсем CNI (в моем понимании) в первую очередь предназначен для того что бы реализовать связность и оверлейную сеть там, где физической сетью вы не управляете
В типичном случае у вас хостер/клауд провайдер выдал сервера/ВМки и каждой из них назначил адреса или несколько, и вы не можете просто взять и добавить маршрутов между ними, добавить свои сети со своими правилами маршрутизации - это может сделать только провайдер, так как доступа к своему сетевом железу он вам не дает.
В моем же сетапе я полностью контролировал как ноды кластера (в моем тестовом сетапе это были малинки), так и сетевую инфраструктуру - маршрутизаторы и свитчи (в моем сетапе эти обе роли играл страрый L3 свитч Catalyst 3560G, старый но не бесполезный)
В случае CNI - у вас пакет прежде чем покинуть ноду инкапсулируется в VXLAN ну или что-то другое (что-то что накодили авторы CNI), что бы внешние адреса были те, что выдал провайдер (а иначе пакет просто никуда не дойдет) "Внутренний мир" кластера, адресация - от провайдера скрыты. Это удобно тем что не требует взяимодействия с провайдером, но требует дополнительных ресурсов на инкапсуляцию/декапсуляцию каждого пакет. Откровенно сказать не таких уж больших ресурсов, но все же.
В случае "без CNI" нет нужды ничего инкапсулировать - вы, контролируя сеть, можете обеспечить доставку пакетов "как есть" без инкапсуляции (и это сильно проще, OSPF уже много лет "просто работает", как минимум в таких простых схемах)
Я разобрал лабу три года назад - так что прямо вот с конфигами в руках показать не могу
Но сути такая
- на conroller-manager задается (щас подсмотрел в хелп) что-то вроде
--allocate-node-cidrs --cluster-cidr - тут указывается сеть например 10.100.0.0/16
Из этой сети будет назначаться блок на каждую ноду --node-cidr-mask-size
По памяти мне казалось что это распределение иежду нодами я делал в ручном режиме. Но сейчас в Help говорит что нет
--pod-cidr string The CIDR to use for pod IP addresses, only used in standalone mode. In cluster mode, this is obtained from the master.
В результате POD после старта получает IP из диапазона --cluster-cidr Вроде был флаг --network-plugin=kubenet но сейчас судя по документации это поведение изменено, но сути это не меняет
В результате имеем - у ПОДа есть адрес, взятый из диапазона. Осталось дело за малым-обеспечить к нему маршрут "для всех"
В моем тестовом сетапе это решалось ospf и redistribute static/connected/kernel , но протокол маршрутизации может быть любой
Очевидно, что такая настройка нужна каждой ноде. Как только на ней поднимается ПОД то у ноды появляется маршрут, о котором она "рассказывает" через протокол динамической маршрутизации всем остальным, и под становится доступен по сети (в этом сетапе - не только другим подам, а всем кому будет передан маршрут, это удобно или нет в зависимости от того что хотите сделать)
Тут могут быть неточности, так как "живого" кластера под рукой у меня нет, и в ближайшее время восстанавливать его не планировал (ручная сборка с выпуском сертефикатов и настройкой всего с нуля - приличный гимморой)
Поднял старые записи, наверно был не прави и зависит от модуля
Для одного было вот так
GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX intel_iommu=on ixgbe.allow_unsupported_sfp=1"
[89774.886100] ixgbe 0000:07:00.0: failed to initialize because an unsupported SFP+ module type was detected.
[89774.886105] ixgbe 0000:07:00.0: Reload the driver after installing a supported module.
[89774.886869] ixgbe 0000:07:00.0: removed PHC on enp7s0f0
Зачем это провайдеру? Ради трех калек ? Услуга должна быть максимально стандартна, хотелки - за совсем другие деньги.
Я не делал сам, но часто в sfp onu можно поменять серийник и «притвориться» другой ону, той что от провайдера.
ПОН достаточно широкий набор технологий, и мои знания ограничены только вендором zte и GPON, авторизацию по серийнику как часто делают, так точно можно обойти.
Про другие типы авторизации и про то какие конкретно ону это позволяют, не знаю
Ps. Sfp onu от zte cdata или bdcom или других вендоров olt лично мне не попадалось. Ну правда я и не искал.
Конечно нет но вам вся и не нужна - главное что бы шлюз был доступен
Что бы абсолютно точно не было никогда никакого совпадения без VRF и MPLS достаточно было бы "позаимствовать" честную белую сеть, про которую вы точно знаете что она никогда вам не пригодится, зарегестрированную за условным Зимбабве и туда же смаршрутизированную
Вероятность что вы захотите установить прямой коннект с каким-то пользователем "Зимбабве-телеком" исчезающе мала
Это если совсем лень адресацию менять каждый раз.
Второй варинат - more specific
Я очень сомневаюсь что автору на самом деле нужно /24 в его стойке,
/28 где то из bogon если не хочется брать реальник,
из середины диапазона, что бы меньше вероятность сопадения со шлюзом была
Мне нравится эта шутка )
Я застал только PCI на 486
Примерно вот такие (только процессор от AMD был)
Как видете никакой экзотики
только ISA и PCI и так продолжалось (как минимум в моей местности) до AGP
Вы несомненно правы, CNI != overlay
Но тем не менее других CNI я не встречал, хотя скорее всего `--network-plugin=kubenet ` тоже по сути CNI
Не совсем
CNI (в моем понимании) в первую очередь предназначен для того что бы реализовать связность и оверлейную сеть там, где физической сетью вы не управляете
В типичном случае у вас хостер/клауд провайдер выдал сервера/ВМки и каждой из них назначил адреса или несколько, и вы не можете просто взять и добавить маршрутов между ними, добавить свои сети со своими правилами маршрутизации - это может сделать только провайдер, так как доступа к своему сетевом железу он вам не дает.
В моем же сетапе я полностью контролировал как ноды кластера (в моем тестовом сетапе это были малинки), так и сетевую инфраструктуру - маршрутизаторы и свитчи (в моем сетапе эти обе роли играл страрый L3 свитч Catalyst 3560G, старый но не бесполезный)
В случае CNI - у вас пакет прежде чем покинуть ноду инкапсулируется в VXLAN ну или что-то другое (что-то что накодили авторы CNI), что бы внешние адреса были те, что выдал провайдер (а иначе пакет просто никуда не дойдет) "Внутренний мир" кластера, адресация - от провайдера скрыты. Это удобно тем что не требует взяимодействия с провайдером, но требует дополнительных ресурсов на инкапсуляцию/декапсуляцию каждого пакет. Откровенно сказать не таких уж больших ресурсов, но все же.
В случае "без CNI" нет нужды ничего инкапсулировать - вы, контролируя сеть, можете обеспечить доставку пакетов "как есть" без инкапсуляции (и это сильно проще, OSPF уже много лет "просто работает", как минимум в таких простых схемах)
Я разобрал лабу три года назад - так что прямо вот с конфигами в руках показать не могу
Но сути такая
- на conroller-manager задается (щас подсмотрел в хелп) что-то вроде
--allocate-node-cidrs
--cluster-cidr - тут указывается сеть например 10.100.0.0/16
Из этой сети будет назначаться блок на каждую ноду
--node-cidr-mask-size
По памяти мне казалось что это распределение иежду нодами я делал в ручном режиме. Но сейчас в Help говорит что нет
--pod-cidr string The CIDR to use for pod IP addresses, only used in standalone mode. In cluster mode, this is obtained from the master.
В результате POD после старта получает IP из диапазона --cluster-cidr
Вроде был флаг --network-plugin=kubenet но сейчас судя по документации это поведение изменено, но сути это не меняет
В результате имеем - у ПОДа есть адрес, взятый из диапазона. Осталось дело за малым-обеспечить к нему маршрут "для всех"
В моем тестовом сетапе это решалось ospf и redistribute static/connected/kernel , но протокол маршрутизации может быть любой
Очевидно, что такая настройка нужна каждой ноде. Как только на ней поднимается ПОД то у ноды появляется маршрут, о котором она "рассказывает" через протокол динамической маршрутизации всем остальным, и под становится доступен по сети (в этом сетапе - не только другим подам, а всем кому будет передан маршрут, это удобно или нет в зависимости от того что хотите сделать)
Тут могут быть неточности, так как "живого" кластера под рукой у меня нет, и в ближайшее время восстанавливать его не планировал (ручная сборка с выпуском сертефикатов и настройкой всего с нуля - приличный гимморой)
Вот вам старая, но все еще лучшая, чем ту что мы комментируем, статья
https://habr.com/ru/articles/149447/
Там есть и про отключение меджленных режимов
Если совсем никак не избавится от таких клиентов - вешать их на другую точку, что б не тормозили всех
Всем хорош
Но это оверлей, лишние заголовки а автор хотел без них как я понимаю
Вообще то можно при сильном желании собрать кластер прям даже совсем без cni, и базово это будет работать.
Каждый кублет можно настроить выдавать адреса из своего пула, ну и маршруты прописать к ним, статика или динамика, по вкусу.
И это будет даже работать, в среде где вы контролируете сеть, те управляете маршрутизацией.
Но очень часто это не так, и тогда уже без оверлея в том или ином виде не обойтись
Я не хочу вас обидеть но это ошибка.
Чем выше скорость, тем лучше, так как эфир будет занят меньше времени.
Правильно как раз наоборот делать - отключать низкие скорости.
Высоко берете, еще не все dir-300 выкинули
Смешались в кучу кони, люди, qdisc , ppp0 и Bluetooth (разве он на 5ггц? А если нет то как мешает)
Статью писал чат бот с минимальными правками и ценность ее соответственно нулевая
https://ic-line.ua/wiki/2-cwdm-eto-prosto#osnovi
Просто оставлю это тут для интересующихся, хорошо про wdm
Поднял старые записи, наверно был не прави и зависит от модуля
Для одного было вот так
Для другого было вот так
Возможно второй даже заработал бы, но сервер в одном месте а OLT в другом и кроме того что он увиделся я ничего больше не проверял
В нескольких разных свитчах (EdgeCore) заработал без проблем, где то были проблемы с Native Vlan но извернуться можно
В микроте 2011 у меня дома уже больше года работает без проблем (но дя, греется)
PS
какой же ублюдочный редктор комментариев тут ( Что то сложнее пары слов написать неудобно.
Я пробовал несколько, нонеймы, не заработала ни одна
Насчет любой микротик - я б не был уверен, вроде в 4011 не работает, но это с чужих слов
Зачем это провайдеру? Ради трех калек ? Услуга должна быть максимально стандартна, хотелки - за совсем другие деньги.
Я не делал сам, но часто в sfp onu можно поменять серийник и «притвориться» другой ону, той что от провайдера.
ПОН достаточно широкий набор технологий, и мои знания ограничены только вендором zte и GPON, авторизацию по серийнику как часто делают, так точно можно обойти.
Про другие типы авторизации и про то какие конкретно ону это позволяют, не знаю
Ps. Sfp onu от zte cdata или bdcom или других вендоров olt лично мне не попадалось. Ну правда я и не искал.
Sfp onu отдельный гимморой как для провайдера так и для абонента, учитывая зоопарк технологий пон
Как обзор неплохо, но много моментов, особенно про совместимость модулей, не раскрыты, нужно продолжать;)
Просто в начале скрипта
set -eu${DEBUG:+x}
Если нужно запустить с деьагом - DEBUG=1 ./myscript.sh
С форума Нага