Хабр Курсы для админов
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 37
ИМХО проблема высосана из пальца. Во-первых, можно подобрать реально случайный диапазон, благо в 10ой сети их много. Во-вторых, для внутренней подсети можно взять какие-нибудь зарезервированные адреса. В-третьих, можно использовать DHCP для внутренней подсети и менять адресацию одной командой.
можно использовать DHCP для внутренней подсети и менять адресацию одной командой
Ожидал такого решения походу чтения этой статьи(самое простое - заготовить два диапазона, и если первый используется на внешней сети, то отключать его), пока не наткнулся на упоминание устройств умеющих только статический IP4. В этом случае смена выдаваемых DHCP адресов проблему полностью не решает.
Или умеющих не только статический, но по неким причинам требующим именно статического для цели использования. Даже не "прибитого" к устройству на DHCP сервере, а именно статического.
Так-то иначе можно и по DHCP постоянный адрес устройству выдавать.
Другое дело, что автор, используя VRF, обошелся без упоминания MPLS :)
Ибо самое интересное начинается в случае, если совпадающая адресация оказывается не в разных физических сетях. До некоторого количества совпадающих сетей это разруливается за счёт VLAN'ов и управляемых коммутаторов, конечно.
Другое дело, что автор, используя VRF, обошелся без упоминания MPLS :)
Мне нравится эта шутка )
Совпадающая адресация в пределах одной embedded network - это нечто запредельно странное, как и MPLS.
Что бы абсолютно точно не было никогда никакого совпадения без VRF и MPLS достаточно было бы "позаимствовать" честную белую сеть, про которую вы точно знаете что она никогда вам не пригодится, зарегестрированную за условным Зимбабве и туда же смаршрутизированную
Вероятность что вы захотите установить прямой коннект с каким-то пользователем "Зимбабве-телеком" исчезающе мала
Это если совсем лень адресацию менять каждый раз.
Второй варинат - more specific
Я очень сомневаюсь что автору на самом деле нужно /24 в его стойке,
/28 где то из bogon если не хочется брать реальник,
из середины диапазона, что бы меньше вероятность сопадения со шлюзом была
Зависит от кейса использования.
У автора указано, что речь идёт о комплекте устройств, которые перевозятся с места на место для организации мероприятий. Подключение к Инету обеспечивает принимающая площадка
Чем каждый раз на новом месте перенастраивать кучу оборудования (включая связи его друг с другом), действительно, проще и быстрее перенастроить внешнюю сеть на маршрутизаторе.
Еще может случиться интеграция всяких legacy сетей, например технологических, которые строились независимо друг от друга, но в какой-то момент понадобилось получить к ним централизованный доступ. Мотаться по региону перенастраивать, например, приборы учёта, ради этой цели вряд ли целесообразно.
Если сеть планируются с нуля изначально - то да, подобная проблема может возникнуть только у оператора связи или ЦОДа. Но вот там одной лишь технологии VRF маловато будет, какой-нибудь MPLS и/или VXLAN понадобятся.
Во всех перечисленных вами случаях нет никаких конфликтов в пределах одной embedded network.
Может возникнуть, если привезённо оборудование будет с той же адресацией, что и на месте подключения.
Или если в разных сетях одна и та же адресация, а доступ надо в обе иметь.
Не совсем наверное верно это называть embedded network, но проблема конфликта адресов возможна.
На месте подключения находится местная же сеть, которая не является embedded network
Или если в разных сетях одна и та же адресация, а доступ надо в обе иметь.
А я писал про конфликты внутри сети.
На месте подключения находится местная же сеть, которая не является embedded network
Так и я говорю, что это не факт, что стоит говорить про embedded network. Да и автор статьи писал, что он "слегка" дал термину собственное определение.
А я писал про конфликты внутри сети.
А я - пожалуй, про то, что говоря о VRF в статье, не стоило сводить всё к вопросу embedded networks и задуматься над кейсами, где может возникнуть ситуация использования одинаково IP-адресации и связанных с этим потенциальных конфликтов.
ИМХО проблема высосана из пальца
Не совсем так. Представьте, что вы разрабатываете комплекс «под ключ» (например, маленькую производственную линию) и вашим устройствам от внешней сети нужен только интернет (условно, для проверки лицензии и передачи телеметрии). При этом вы не хотите даже знать, какие там адреса подсетей у клиента на объекте и какой там интернет-провайдер, и тем более, нечаянно с ними пересечься. При таких вводных приведённое в статье решение будет максимально беспроблемным.
благо в 10ой сети их много
Нельзя заранее быть уверенным, что админ условного завода не забрал себе всю 10.0.0.0/8 под локальную сеть.
Ещё проще - возить 2 роутера, и гипотетической ситуации когда совпали ip, второй роутер ставить перед первым
Нельзя заранее быть уверенным, что админ условного завода не забрал себе всю 10.0.0.0/8 под локальную сеть.
Конечно нет но вам вся и не нужна - главное что бы шлюз был доступен
Можно использовать 169.254.0.0/16 для внутренней адресации
Чтобы в стойке были доступны устройства при конфликте IP снаружи достаточно прибить арпы на управляемом коммутаторе.
На коммутаторе нет арпов :(
Даже на самых простых управляемых есть таблица ARP. Этого достаточно, чтобы устройства в сегменте точно знали на каком порту каждый IP адрес.
И зачем коммутатору знать на каком порту сидит ip?
Коммутатору незачем знать, где какой ip адрес, т.к. это L2 устройство. Вы путаете с mac address table
Да, подзабыл уже малость. Спасибо что поправили, CAM-таблица. В которой мы прибиваем маки к портам. Сути не меняет. Работает железно в любой сети с идентичным IP адресами.
Нет... это вам никак не поможет в данной ситуации
У меня так год стойка работала. С преднастроенными IP, биндом маков на портах коммутатора и мне было похрен на внешнюю адресацию ЗА пределами свитча. Единственное условие - уникальный IP шлюза во внешней сети. Видеосервер на него-таки должен был выходить.
Чудом она работала. Возможно, конфликтов адресов на самом деле не было, потому и работала. Возможно, конфликты были, но она работала потому что ближайшее оборудование успевало отвечать первее. Возможно, оборудование просто общалось широковещательными пакетами, которым пофигу на конфликты адресов. А возможно, что в сети был умный DHCP-сервер, который учитывал адреса вашего оборудования при раздаче своих.
"Простой" управляемый коммутатор знает про ARP только на management интерфейсе (физическом или виртуальном, смотрящем в управляемую сеть).
На всех остальных интерфейсах он интересуется только MAC-адресами. Ему вообще плавать, работает поверх Ethernet IP или какой-нибудь (кто еще помнит?) IPX, или еще что-то.
L3 свитч уже да, что-то знает, но это гибрид свитча и роутера.
На коммутаторе нет арпов :(
Погуглил устройство - это не управляемый коммутатор, это L3 коммутатор. "Немножко" разные вещи.
Ещё бы понять в каком режиме ARP у вас там настроен, по умолчанию даже L3 коммутаторы не имеют к нему никакого отношения, но вроде как раз у цисок есть странно-костыльные опции работы с этим протоколом.
Использовать Link-Local адресов (LLA) для встроенной сети вполне возможно и даже приемлимо, если все устройства находятся в общем канальном сегменте. Даже если есть несколько соединенных маршрутизатором сегментов, то построить общую сеть на LLA все же можно (даже без динамической маршрутизации), но это порождает множество проблем или, как минимум, неудобств. Следует так же учитывать необязательное использование EUI-64 (а часть устройств может генерировать интерфейсную часть адреса случайным образом), возможное использование одиного и того же LLA на разных интерфейсах одного и того же маршрутизатора (LLA должен быть уникальным только в пределах одного сегмента), и прочие проблемы, осложняющие настройку и отладку.
Для изолированных сетей (включая встраиваемые сети) дизайнерами IPv6 был разработан специальный тип адресов - ULA (Unique Local Address). Это если вы желаете чтобы устройства из внутренней сети не могли коммуницировать наружу. А если необходим доступ, то нет никаких проблем с назначением внутренним устройствам глобальных адресов (GUA). Что с ULA, что с GUA, DHCPv6 сервер не обязателен, адреса можно раздать через IA_PD в RS/RA (а так же адреса серверов DNS), но если неоходимо передать устройствам специфическую информацию (сервер NTP, etc.) то DHCP сервер необходим.
Мыслите вы правильно и в верном направлении, но, как мне кажется, не вполне эффективно пытаетесь использовать стек IPv6.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Не выбирайте странные подсети, пользуйтесь VRF