без использования свитча

Anton при задании обоих адресов статикой на одном интерфейсе у провайдера что-то ломается?

а хвост провайдера один, Серёж )

я вчера говорил провайдера в езер1. езер1 и езер2 в бридж. Езер2 соеденить кабелем с езер3. На езер3 поднять второй адрес

я вчера говорил провайдера в езер1. езер1 и езер2 в бридж. Езер2 соеденить кабелем с езер3. На езер3 поднять второй адрес

в принципе да,

на бридже один адрес, на эзер3 второй

я что то не понимаю. ну заведи ты два устройства через комутатор. в чем проблем? Ну раз провайдер готов выдавать два адреса значит он и готов завести два МАСа на порту к тебе. Или как? Или я туплю после трудового дня или ты что то недоописал в требованиях.

Да, всё верно - об этом я вчера ведь уже говорил.

Anton при задании обоих адресов статикой на одном интерфейсе у провайдера что-то ломается?

Только первый назначенный работает. Со второго даже шлюз не отвечает.

Только первый назначенный работает. Со второго даже шлюз не отвечает.

ага, понятно.

я вчера говорил провайдера в езер1. езер1 и езер2 в бридж. Езер2 соеденить кабелем с езер3. На езер3 поднять второй адрес

MAC будет только один - моста.

MAC будет только один - моста.

не, ты немножко не понял. ether1+2 в бридж. на него dhcp-client или адрес статикой. ether2-ether3 линк медью. на eth3 второй адрес.

ether1 к прову

Sergiy, помнишь, я тогда говорил, что эта задача похожа на твою, но на л2? Можешь считать подсказкой. ?

блин, за день вы написали 300 месаг. причем 96 из них был срачег с Антоном. имейте совесть. АНтон, давай завязывай провоцировать. ПРОЕХАЛИ. нам еще шоу "Пусть говорят" не хватало

Вы еще посчитайте, сколько навалил в чате антон, и какой от него процент полезных мессаг. Говно из него прет и преобладает.

/stat@combot

combot.org/chat/-1001062683398

Sergiy, помнишь, я тогда говорил, что эта задача похожа на твою, но на л2? Можешь считать подсказкой. ?

какую именно? моих задачек тут нет. Я только репостил задачи от тренеров ?

Да я уже забыл, в чём её суть была. Последнюю же.

о пинге между роутерами с маскарадингами?

не, ты немножко не понял. ether1+2 в бридж. на него dhcp-client или адрес статикой. ether2-ether3 линк медью. на eth3 второй адрес.

Хороший вариант. Возможно, он даже частично решит проблему, уберёт одну из преград в реализации. Но немного усложним - у нас железка с одним портом.

не, адреса ставили "подставные", оно шло к второму роутеру(метароутер), там получало роутмарки и правильный адрес. Обычный ДСТНАТ с подставными адресами. Как тут и предлагали. метароутер что бы был ВХОДЯЩИЙ трафик, который и можно уже сДСТНатить ?. Вот такой вот костыль.

Вот эта.

И всё же - Слейв может быть ДХЦП-клиентом?

Нет.

точно?

А если бы и мог - это бы не помогло.

почему?

Я мог бы дать ещё подсказок, но это очень упростит задачу...

у Бриджа АДМИН-МАС может отличаться от МАСа физики

почему?

Потому что даже при ручном назначении адресов работает только тот, который назначен первым. Вне зависимости от того, в каком порядке ты их назначал.

Предположим следующее: Шлюз - 1.1.1.1 Первый адрес - 1.1.1.2 мак 11:11:11:11:11:11 Второй адрес - 1.1.1.3 мак 22:22:22:22:22:22

ну тут задача о том как задать два МАСа на одном физическом интерфейсе

у Бриджа АДМИН-МАС может отличаться от МАСа физики

Естественно. Но сам мост имеет только один MAC на все дырки, куда он включен. В этом и суть моста как такового. admin-mac (MAC address; Default: ) Static MAC address of the bridge (takes effect if auto-mac=no)

ну я думал слейв мог быть клиентом. оказалось нет

Ещё одна небольшая подсказка - знаний только RouterOS недостаточно для решения этой задачи.

ты шо МАС FFFFF... назначил? ?

Не, я параноик и использую случайно сгенерированные locally administered MAC.

Хм, смотрю на скрин и вижу, что это поле неизменяемое. Всё верно? Если так - то жаль, я люблю генерить рандомные MAC. Вот так, например: #! /usr/bin/env perl # vim: ts=4:sw=4 use strict; use warnings; my $i; my @m; my $b0; for ($i = 0; $i < 5; $i++) { @m[$i] = rand(256); } $b0 = int(rand(256)) & ~1 | 1 << 1; printf "%02x:%02x:%02x:%02x:%02x:%02x\n", $b0, @m;

Даже скрипт сюда скидывал.

Так как решил задачку на одном порту с двумя маками и без другого железа/метароутера?

Ну, пусть @erazel ещё подумает. Интересно же. Но ответ будет в любом случае, конечно же. Либо вместе к нему придём, либо уже расскажу, когда идеи закончатся.

расказывай. на меня надежды мало.я начисто забыл теорию сетей

Ээх...

Ключевое тут - ARP Inspection у провайдера. Пока с этой функцией не разберёшься - все поползновения бесполезны, и вот почему...

Работает это так: коммутатор провайдера отвечает на запросы, но сам имеет статическую таблицу MAC. Когда коммутатор получает запрос от известного адреса - он копирует запись в FDB.

Следовательно, в рамках одной железки стандартным способом эту задачу решить невозможно, т.к. когда негровтык послал ARP-запрос на адрес шлюза от своего первого IP - он получит ответ, запишет его в свою таблицу, и со второго адреса уже не будет спрашивать. А следовательно, коммутатор провайдера для второго адреса не обновит свою FDB, и не будет знать, куда же отправлять трафик.

Статик арп-запись на микроте для адреса шлюза?

от известного адреса єто как? IP- адреса?

Статик арп-запись на микроте для адреса шлюза?

Говорю же - ARP Inspection.

Не, я к тому, как решать

от известного адреса єто как? IP- адреса?

Ага, src-ip - 1.1.1.3, src-mac - 22:22:22:22:22:22, arp who was 1.1.1.1

Так вот пока не будет сделан такой запрос - в FDB коммутатора провайдера не появится эта запись. Он просто будет считать, что порт пуст, на нём нет устройств.

ну даже если комутатор выучит оба твоих МАС, всеравно как ты два МАС на одном интерфейсе поднимешь?

Коммутатор провайдера не выучит оба MAC потому, что после того, как RouterOS выучит MAC первого с сосбственного первого IP, второй запрос никогда не будет послан.

Так вот пока не будет сделан такой запрос - в FDB коммутатора провайдера не появится эта запись. Он просто будет считать, что порт пуст, на нём нет устройств.

А запроса такового не будет, пока будет статическая арп-запись в микроте для адреса шлюза, нет?

Даже если будет динамическая. Запрос будет только один - шлюз ведь один.

Sergiy, ты там живой? Как себя чувствуешь после этого извращения?

Тут уже осталось только реализацию запилить.

никак. в голове просто картина не укладывается ?

пиши давай уже что ты конкретно сделал ?

В общем, первая задача - нам нужно получить 2 мака на одной дырке. Просто их назначить невозможно. Задачу с натом "хуй знает куда" я не просто так привёл в пример. Нам тоже это понадобится, но на л2, а не л3.

Предположим следующее: Шлюз - 1.1.1.1 Первый адрес - 1.1.1.2 мак 11:11:11:11:11:11 Второй адрес - 1.1.1.3 мак 22:22:22:22:22:22

Вернёмся сюда.

дальше

Делаем мост, в который пихаем дырку, куда включен кабель от провайдера (это нужно для л2 нат).

И на уровне бридж фаервола остальное ?

Не всё, но почти.

Делаем dstnat и srcnat соответственно для 1.1.1.3 11:11:11:11:11.

Но у нас остаётся последняя проблема - обновление FDB на коммутаторе провайдера. Делаем 2 дефолтных шлюза - первый pref-src 1.1.1.2, второй - pref-src 1.1.1.3 с distance больше, чем для первого и check-gateway=arp.

ERROR: S client not available

ну тут задача о том как задать два МАСа на одном физическом интерфейсе

Я выше предлагал вррп из 1 девайса поднять

Не помогло бы.

? Будет на одном физическом интерфейсе 2 мака и 2 адреса

А ARP-таблица на негровтыке - одна.

А шлюз у обоих из одной подсетки?

Да, естественно. Я это в оригинальном описании задачи писал.

А шлюз у обоих из одной подсетки?

Он просто один.

А ARP-таблица на негровтыке - одна.

Ну и чем это мешает?

Ну а если у нас эти 2 интерфейса в разных врф висят - каждый будет ходить со своим срц_ип

Ну и чем это мешает?

Я же написал - негровтык отправит со своего первого ип-адреса арп запрос на шлюз и добавит его мак в арп-таблицу.

После этого негровтык уже будет знать мак-адрес шлюза, и от своего второго ип запрос не пошлёт. Шлюз, соответственно, не обновит свою FDB.

А,ясно

Но у нас остаётся последняя проблема - обновление FDB на коммутаторе провайдера. Делаем 2 дефолтных шлюза - первый pref-src 1.1.1.2, второй - pref-src 1.1.1.3 с distance больше, чем для первого и check-gateway=arp.

И поэтому нужен вот этот костыль. Ну, хитро, согласен

@erazel, ну что - сейчас уже понятна аналогия с dstnat на несуществующие адреса?

Мне кажется такая схема чревата отвалами по мере устаревания арп- таблицы с той или другой стороны

А VRF - вариант, может попробую, когда делать нечего будет.

Мне кажется такая схема чревата отвалами по мере устаревания арп- таблицы с той или другой стороны

check-gateway раз в минуту, ЕМНИП, а обычно время жизни ARP на коммутаторах провайдеров - 5-10 минут.

Вот схема Сергея с задействованием трёх портов мне что-то больше нравится.

Или даже два и коммутатор

check-gateway раз в минуту, ЕМНИП, а обычно время жизни ARP на коммутаторах провайдеров - 5-10 минут.

Ты тут зависишь от параметров, которые неизвестны и неподвластны

Вот схема Сергея с задействованием трёх портов мне что-то больше нравится.

Там костылей с арпом не надо

"обычно" - хорошо, но не всегда :)

Вот схема Сергея с задействованием трёх портов мне что-то больше нравится.

Ну, в условии задачи изначально было сказано - железка одна. А дополнительные железки никак бы не добавили вторую ARP-таблицу на RouterOS, так что от check-gateway=arp никуда не деться.

check-gateway раз в минуту, ЕМНИП, а обычно время жизни ARP на коммутаторах провайдеров - 5-10 минут.

check-gateway every 10 seconds

Там костылей с арпом не надо

Надо.

Ну, в условии задачи изначально было сказано - железка одна. А дополнительные железки никак бы не добавили вторую ARP-таблицу на RouterOS, так что от check-gateway=arp никуда не деться.

Врф и два интерфейса.

При использовании VRF сколько будет ARP-таблиц?

Костылять такое из-за отсутствия возможности поставить перед тиком четырехпортовый свитч

Да не поможет он.

При использовании VRF сколько будет ARP-таблиц?

Одна. Только маки на двух интерфейсах будут разные и шлюз нормально отработает

check-gateway every 10 seconds

Точно. Тем более.

Одна. Только маки на двух интерфейсах будут разные и шлюз нормально отработает

Не отработает. Я же писал - ARP Inspection на коммутаторе провайдера.