Innokentiy
независимо от оборудования\
Roman
а динамическая отдача DNS в в6 - это тот еще головняк)
RA с DNS option справиться вполне, просто мне нужно отдать клиенту не системные DNS одному
Innokentiy
а что, винда уже научилась в DNS через RA?
Ẏoxi
> мечты о красивых коротких link-local адресах
но зачем, холмс? IPv6-адреса запоминают только наркоманы и DNS-сервера, и тем и другим не составит сложности запомнить рандомный адрес
Например, семантическая нумерация. Я нумерую последние 2 байта IPv4 по схеме: 172.16.{номер роутера},{номер устройства}.
Очень удобно. Днс не нужен.
Innokentiy
Например, семантическая нумерация. Я нумерую последние 2 байта IPv4 по схеме: 172.16.{номер роутера},{номер устройства}.
Очень удобно. Днс не нужен.
а если не наркоманить, то можно именовать устройства, а не нумеровать
Ẏoxi
Я просто в v6 не шарю, заранее извиняюсь за невежество.
Roman
> мечты о красивых коротких link-local адресах
но зачем, холмс? IPv6-адреса запоминают только наркоманы и DNS-сервера, и тем и другим не составит сложности запомнить рандомный адрес
Например gateway вида FE80::1 выглядит удобнее, чем FE80:123e:asda:1231
Innokentiy
Например gateway вида FE80::1 выглядит удобнее, чем FE80:123e:asda:1231
человек вообще не должен взаимодействовать с использованием IPv6-адресов
Innokentiy
а компьютеру абсолютно все равноЮ сколько нулей в 128-битном адресе
Roman
человек вообще не должен взаимодействовать с использованием IPv6-адресов
Нет, я пока не так плох, чтобы у меня дома была динамическая маршрутизация
Roman
Чтобы только руками маршруты не создавать
Innokentiy
зачем? слаак же
Roman
Затем, что иногда, слишком часто, мне не хватает просто одного default route
Roman
А вообще IPv6 в MT что-то выглядит менее любимым, нежели IPv4
Innokentiy
и неудивительно
Roman
Но DHCPv6 сервер нужно бы привести в порядок, а то даже для базовых опций, необходимость их кодирования в Hex это не дело
Roman
А нет можно не чинить, RIPE Atlas умеет только в SLAAC пока 😔
Anonymous
Вопрос вот есть у меня VRRP для каждого Влана , а теперь вопрос куда вешать DHCP-relay на VRRP интерфейс и его айпи в качестве источника , или на физический интерфейс и указывать IP который на interface влан висит?
Evgeniy
На интерфейс влана смотрящий на клиента
Evgeniy
В одном броудкаст сегменте с клиентами
Evgeniy
Тот интерфейс к которому приходит dhcp discover от клиентов тот и является релеем
Roman
Я на VRRP интерфейсе размещал бы, он тоже находится в одном сегменте с клиентами.
Roman
Там на _физическом_ интерфейсе будет фильтр на канальном уровне, для виртуального MAC адреса вашего VRRP интерфейса
Anonymous
Ладно попробуем и так и сяк
Evgeniy
Если у вас вррп прикидывается для клиентов значит на него
Anonymous
/interface vrrp add interface=VLAN200 name=VLAN200VRRP priority=120 version=2 vrid=20 Я не знаю как это корректно трактовать . кто на кого вешается
Volodymyr
/interface vrrp add interface=VLAN200 name=VLAN200VRRP priority=120 version=2 vrid=20 Я не знаю как это корректно трактовать . кто на кого вешается
Вот лучше наоборот. вррп вешать на физику, а влан на вррп.
Anonymous
там даже уже и не физика там бридж
Innokentiy
чем лучше?
Innokentiy
тем, что кадры вррп соответствующего влана будут бегать с меткой
Innokentiy
это очень нестандартный вендорозависимый ход
Volodymyr
тем, что кадры вррп соответствующего влана будут бегать с меткой
А внутри влана будет бегать мультикаст вррп.
Innokentiy
А внутри влана будет бегать мультикаст вррп.
не будет. если мы вешаем вррп на физику, вррп будет бегать в одном экземпляре и без метки
Volodymyr
не будет. если мы вешаем вррп на физику, вррп будет бегать в одном экземпляре и без метки
Так я ж о чем и говорю. А у автора вррп на влане.
Innokentiy
то есть как и предполагается по стандарту
Anonymous
бегает вррп с метками за каждый влан
Anonymous
час еще раз посомтрю
😷Драничек
Господа, а кто имел опыт использования mANT LTE 5o? Сильно выручает в условиях плохого LTE?
Anonymous
оно и проектируется под зоопарк
Volodymyr
то есть как и предполагается по стандарту
вррп на микротике резервирует роутер, т.е. в нашем случае физический интерфейс. И должно падать(переползать на слейв) все, что на этом интерфейсе есть подчиненного. В том числе и вланы.
Anonymous
Innokentiy
> вррп на микротике
вот тут-то собака и порылась, потому что в стандарте вррп резервирует мак-адрес в пределах широковещательного домена
Innokentiy
если сочетать микротик и условную циску, то циска сможет просочетаться по вррп с микротиком по вашей схеме только по native vlan. а во всех остальных она будет считать себя мастером
Roman
вррп на микротике резервирует роутер, т.е. в нашем случае физический интерфейс. И должно падать(переползать на слейв) все, что на этом интерфейсе есть подчиненного. В том числе и вланы.
Это в случае, если у нас для всех Vlan одинаковый Master, а если нет?
Innokentiy
если микротик, в свою очередь, посчитает себя мега-мастером за весь роутер, у вас в почти всех вланах будет конфликт
Volodymyr
если микротик, в свою очередь, посчитает себя мега-мастером за весь роутер, у вас в почти всех вланах будет конфликт
С циской микротик так дружить нельзя. По крайней мере ,пока на микротике не будет "взрослый" вррп.
Innokentiy
возможно ли сделать так технически для сети только из микротиков? да, возможно
разумно ли делать так? нет, оно не будет работать в гетерогенной среде вообще, а в моновендорной даст вендорлок, который снять можно только разобрав все интерфейсы
Innokentiy
на микротике нормальный вррп, который прекрасно работает, если вррп вешать на влан-интерфейс
Anonymous
тэк значит правильно копаем траншею
Innokentiy
с поправкой на геморройность трекинга доступности внешнего мира, который в циске/хуевее/джунипере/етц нативный, а в мт делается через одно место и скриптами
Innokentiy
(да, я знаю, что раньше мт не позволял вррп вешать на вланы. сейчас, однако, вполне позволяет)
Anonymous
трэкинг надо будет у Инокентия посмотреть для цицски и попробывать изобрести аналог на МТ
Volodymyr
на микротике нормальный вррп, который прекрасно работает, если вррп вешать на влан-интерфейс
Я свой аргумент сказал - лишний мультикаст на каждый влан. Если влан один - лучше(дешевле) вешать на влан. Если планируется балансировка - только на влан. Если ни то ни другое, то "дешевле" наоборот.
Anonymous
Я правда для своей схемы не нахожу применения трекингу
Roman
С циской микротик так дружить нельзя. По крайней мере ,пока на микротике не будет "взрослый" вррп.
В случае с физическими интерфейсами, на них будут IP адреса тогда в любом же случае у МТ?
Anonymous
часть вланов на один физический шлюз час на другой
Volodymyr
В случае с физическими интерфейсами, на них будут IP адреса тогда в любом же случае у МТ?
Так это будет без влана.
Innokentiy
> лишний мультикаст на каждый влан
не столько "лишний" в одном случае, сколько "экономия на нестандартном поведении" в другом
Roman
А с Vlan, адреса он возьмёт с Vlan что-ли?
Roman
Я не понял, MT умеет запускать VRRP instance на интерфейсе на котором не инициализирован IP протокол?
Innokentiy
нет. обязательно должен быть ip-адрес
Pasha
а в unicast-peer не научили еще?
Volodymyr
> лишний мультикаст на каждый влан
не столько "лишний" в одном случае, сколько "экономия на нестандартном поведении" в другом
в "одном случае" - категорически с Вами согласен.
Roman
Если там будет IP адрес, тогда на Cisco sub-interface для native vlan без тега, без проблем позволит спарить нам MT и Cisco, правда не знаю, зачем.
Innokentiy
не позволит
Roman
MT не будет тегировать VRRP пакеты, если он запущен на физическом интерфейсе
Roman
Cisco не будет тегировать VRRP пакеты, для группы запущенной на sub-interface где мы не тегируем кадры.
Innokentiy
это правда
Anonymous
Innokentiy
но она не будет интерпретировать пакеты vrrp, полученные на одном субинтерфейсе, как относящиеся к экземпляру вррп на другом субинтерфейсе
Roman
Ах вот вы о чём