J
Или дроплет старше 2015 года?)
Serhii
floating ip)))
J
Обсуждаем как работают плавающие адреса в digitalocean)
J
https://docs.digitalocean.com/glossary/anchor-ip/
Вот же чо пишут.
Serhii
Что бы сделать так же в опенстеке иметь и пуб адрес + прикрутить floating
J
Ааааа
J
Этот адрес напрямую на виртуалку не попадает.
Все, я понял.
Serhii
там port-forwarding скорее всего
Serhii
Не, это ты про плавающий говорил.
А я щас говорю про anchor ip.
А оно что не одно и тоже🤷♂️?
J
А оно что не одно и тоже🤷♂️?
Нет)
Anchor ip это вспомогательный айпишник, через который роутится трафик между плавающим адресом и "обычным"
J
А не
Serhii
Хочу сделать так чтобы floating IP можна было прикрутить к виртуалки которая имеет публичный адрес, но хотя я уже понял
нужно просто выделить под floating другую сеть после чего маршруты не будут перекрывать друг друга и трафик будет поступать на ип А и на ип Б, а если нужно пустить исходящий через флоатиг изменить роут на виртуалке
J
https://docs.digitalocean.com/products/networking/reserved-ips/how-to/find-anchor-ips/#get-a-droplets-anchor-ip
J
Что да?)
Я про то что сначала думал что anchor ip настраивается на инстансе, потом подумал что нет, что это прост интерфейс роутера и инстансу дается до него on-link маршрут. А потом читнул чо они пишут и все-таки этот адрес должен быть у инстанса, выходит что так.
J
Да я понятия не имею чо там.
Мне просто интересно как там сделано.
Mikhail
О, у дижитал оушн тангстен?
Serhii
Операция «Тангстен» (англ. tungsten — вольфрам) — атака палубной авиации королевского военно-морского флота Великобритании на немецкий линкор «Тирпиц», осуществлённая 3 апреля 1944 года в ходе Второй мировой войны. Основной целью операции было уничтожение или вывод из строя линкора, находившегося на базе в Норвегии, прежде чем он вновь войдёт в строй после ремонта.
Serhii
Что такое тангстен)?
Mikhail
Ну уже открытая😀
J
Дык и как рабоатет механизм плавающих адресов?
Зачем они выдумали anchor ip?)
Mikhail
Ладно, я спать, чет устал за сегодня. Видимо магнитная буря догнала меня.
Илья | 😶☮️🐸
Максим из джунипера, приходи @tungstenfabric_ru
Serhii
Лоооол мой мозг поплыл я спать
Serhii
всем спасибо
Serhii
😅
J
https://docs.digitalocean.com/products/networking/reserved-ips/how-to/enable-old/
Так. Ну вот они его добавляют. Но как же оно будет работать если у виртуалки default gw прописан через другой интерфейс? Непонимат)
J
6.xx?
J
А.
Anchor ip вместе с публичным адресом на одном интерфейсе висит. И получается что anchor ip gateway и default gateway эт один и тот же порт.
J
J
Я тебя не понял вообще, поэтому переспросил)
6.xx это версия чего?)
J
Хамство?
Artemy
Не «спрашиваю» а «троллю»
J
Ой, ладно, я разобрался как у DO работает, вроде. Ну и славно)
J
Я тебя не понимаю)
Я не ту версию документации открыл у DO?
Надо актуальную искать?)
J
Ребята, такой вопрос. (Не знаю стыдный или нет)
Мне нужно чтобы к некой подсети внутри сети раздавался on-link маршрут, аналогично тому как раздаются маршруты ко всем подсетям внутри сети или как отдается маршрут к metadata proxy.
То есть, чтобы был указан не некстхоп, а интерфейс через который подсеть доступна. Но при это необходимо чтобы нейтрон ни в коем случае из этой подсети не пытался взять адреса ни для каких нужд. Ни для dhcp ни для fip gateway ни для чего. Потому что в этой подсети интерфейсы внешних по отношению к опенстеку устройств.
Пока придумал прописывать несуществующий service_type, типа network:biba. Но нет уверенности разумно ли это. Может есть способ красивше и правильнее?
J
В какой части нужно больше деталей?
Stanley
Ребята, такой вопрос. (Не знаю стыдный или нет)
Мне нужно чтобы к некой подсети внутри сети раздавался on-link маршрут, аналогично тому как раздаются маршруты ко всем подсетям внутри сети или как отдается маршрут к metadata proxy.
То есть, чтобы был указан не некстхоп, а интерфейс через который подсеть доступна. Но при это необходимо чтобы нейтрон ни в коем случае из этой подсети не пытался взять адреса ни для каких нужд. Ни для dhcp ни для fip gateway ни для чего. Потому что в этой подсети интерфейсы внешних по отношению к опенстеку устройств.
Пока придумал прописывать несуществующий service_type, типа network:biba. Но нет уверенности разумно ли это. Может есть способ красивше и правильнее?
А можно тоже самое, но без подсказок по решению? То есть - что нужно получить?
J
Ну это в винде так называется.
directly connected, иначе говоря.
J
А можно тоже самое, но без подсказок по решению? То есть - что нужно получить?
Нужно чтобы инстансы получали по dhcp маршрут вида
a.a.a.a/b via dev ensX
При этом чтобы у самих инстансов на интерфейсах адресов из сети назначения не было.
Stanley
Нужно чтобы инстансы получали по dhcp маршрут вида
a.a.a.a/b via dev ensX
При этом чтобы у самих инстансов на интерфейсах адресов из сети назначения не было.
То есть, переписать metadata agent? Почему бы и нет
J
Вопрос не как такой маршрут раздавать, а как исключить выделение адресов нейтроном из этой подсети на любые нужды.
J
Нейтрон и так это делает.
Если у тебя в одной сети много подсетей, то такие маршруты будут отдаваться ко всем подсетям. Потому что они все в одном бродкаст домене.
Там в конфиг dnsmasq прописывается 121 опция без некстхопа просто. И dhcp клиент сам понимает что сеть назначения доступна через интерфейс на котором он опцию получил.
Илья | 😶☮️🐸
Нейтрон и так это делает.
Если у тебя в одной сети много подсетей, то такие маршруты будут отдаваться ко всем подсетям. Потому что они все в одном бродкаст домене.
Там в конфиг dnsmasq прописывается 121 опция без некстхопа просто. И dhcp клиент сам понимает что сеть назначения доступна через интерфейс на котором он опцию получил.
Это поведение как-то можно изменить ?
Илья | 😶☮️🐸
А если их 20-30-50 ? Затея выглядит странной отдавать по каждой маршрут
J
Ну когда подсетей немного, наверное
20-30-50 внутри одного бродкаст домена?
Эт вопрос будет уже к дизайну сети.
Возможно, если ты используешь subnet pools, то отдаваться будет один маршрут, агрегированный.
Stanley
Нейтрон и так это делает.
Если у тебя в одной сети много подсетей, то такие маршруты будут отдаваться ко всем подсетям. Потому что они все в одном бродкаст домене.
Там в конфиг dnsmasq прописывается 121 опция без некстхопа просто. И dhcp клиент сам понимает что сеть назначения доступна через интерфейс на котором он опцию получил.
Так я и говорю, нужно metadata агента переписать. Пусть через dnsmasq что угодно отдает.
Stanley
Чтобы штатно - хз. Очень сомневаюсь.
J
Так я и говорю, нужно metadata агента переписать. Пусть через dnsmasq что угодно отдает.
Зачем переписывать?
У меня простой вопрос. Как сделать сервисную подсеть чтобы из неё нейтрон не брал адреса?
Stanley
Сделать сеть в нейтроне, чтобы нейтрон про нее не знал. Уж даже не знаю. :)
J
Решение есть.
Внутри уже существующей сети создаю service subnet.
service type у неё заведомо несуществующий, gateway=none, dhcp выключен.
Все нормально, nova из неё никогда не возьмет адреса, нейтрон тоже не будет брать, потому что там явно указан service_type, которого нет.
Это нужно только чтобы адрес этой подсети попадал в 121 опцию и хосты в других подсетях внутри сети знали что для них эта сеть достижима по l2.
Это всё работает и всё хорошо.
Просто, может есть более изящное решение?
J
А чо это даст?)
J
А не, нифига, я ошибся)
Похоже, если нет активных портов в подсети, нейтрон к ней маршрут отдавать не будет.
J
У меня новый вопрос.
Можно ли создать какой-то порт-заглушку чтобы статус у него был ACTIVE?
То есть чтоб порт прост овисел в базе нейтрона, занимал адрес и был ACTIVE, а не DOWN.
J
Почему?
J
Или я пьяный, например, взял и снес все проекты. Тоже ведь возможно?
J
Зачем высасывать из пальца какие-то ситуации?
J
Для того чтобы заставить нейтрон раздавать маршрут к подсети в которой этот порт)
J
Вот я и спрашиваю можно ли не биндить никуда и сделать все равно active?
J
А чо проще по-твоему, роутер, для которого будут создаваться реальные неймспейсы, интерфейсы и маршруты или запись о порте в базе?
J
Так то конечно можно роутер.
J
Да хоспаде.
Доступны они будут.
В этой подсети, маршрут к которой я хочу раздавать физические устройства есть.
J
Какой записи нет?
Будет ovs работать как обычный свитч.
J
Есть виртуалка в external сети.
В этой же external сети (в том же влане) есть устройства на которых настроена другая ip сеть.
По l2 связность между виртуалками и устройствами есть.
Но они должны знать что могут общаться напрямую. Для этого виртуалкам надо сказать что вот такая-то сеть у вас доступна через вот этот интерфейс.
И тогда всё чудесно будет работать. Вируталка будет слать arp запрос со своего адреса, устройства будут отвечать со своего. И будут они общаться, хотя ip сети у них настроены разные.
J
На какое-то время нужно такую схему организовать, ничо не сделаешь.
Den
А поделить сетку нельзя? Что бы нейтрон в одной половинке только адреса выдавал?
J
А поделить сетку нельзя? Что бы нейтрон в одной половинке только адреса выдавал?
Имеешь ввиду, всех в одну сеть запихнуть?
Не получится, потому что в external сети не получится найти достаточное количество адресов.
Den
Я имею ввиду, что допустим у нас экстернал сеть /24. Нейтрона говорим, что бы он аллокейшин адресов по dhcp ,делал с 128 до 254. Т.е. первые адреса он не будет выдавать и из будут использовать внешние. Ну и без гейтвеая эту сеть. И да, экстернал - это условно. Просто физ.нет.
J
Нет, побольше чуть.
Ну а роутер на палочке делать или вируталкам давать интерфейсы во вторую сеть тож не очень хочется.
J
Я имею ввиду, что допустим у нас экстернал сеть /24. Нейтрона говорим, что бы он аллокейшин адресов по dhcp ,делал с 128 до 254. Т.е. первые адреса он не будет выдавать и из будут использовать внешние. Ну и без гейтвеая эту сеть. И да, экстернал - это условно. Просто физ.нет.
Так можно сделать когда заранее планируешь.
А тут ситуация такая что адресов не хватит для того чтобы поделить сеть пополам)
J
Ага. Тогда это будет не просто роутер на палочке, а кусок говна на палочке)
Den
J
т.е. адреса вперемешку?
Не, просто почти все адреса в сети заняты виртуалками и поэтому взять столько сколько нужно для внешних устройств уже не получится.
J
А почему разъебанный?