IVB

Лучше. Но для этого с "той" стороны должен быть соответствующим образом настроенный Микротик. У меня же там АСУС. Этот режим не завёлся. Поэтому пользуемся тем, что есть.

Отбой. Я тормоз 😞 Нужно было режим подключения к АСУСу по ВайФай выставить station pseudobridge.

Здравствуйте. Нужно реализовать простую схему. Есть роутер АСУС, который подключен к провайдеру и раздаёт интернет для нескольких локальных устройств (два смарта и ноут). На ноуте кривой Wi-Fi адаптер. Поэтому хочу подключить ноут через Микротик: ноут подключаю к Микротику витой парой, а Микротик подключается к АСУСу по Вай-Фай. На Микротике сбриджевал порты Вай-Фай и Эзернет. У АСУСа, Микротика и ноута - статические IP в одной локальной подсети. Микротик к АСУСу подключается. Если ноут подключен к АСУСу по Вай-Фай - Микротик с ноута доступен. Если положить на ноуте Вай-Фай и поднять Эзернет - Микротик доступен. С Микротика пингуются и ноут, и АСУС. Но с ноута пингуется только Микротик. АСУС не пингуется. Где-то я что-то пропустил в настройках. Подскажите, пожалуйста, где я прокололся.

Нет, с возвратом проблем не было. Но вот клиент несколько месяцев не платит. И даже объясняет, почему (уехал на заработки - не пользуется, вернётся - будет пользоваться дальше). И кто его знает - может, действительно уехал, а, может, на конкурента переключился. Вот и хочется найти какое-то решение, чтобы наше оборудование, которое пока не используется в нашей сети, не использовалось в сети конкурента.

ОНУ находится у клиента на ответственном хранении, и по расторжении договора клиент обязан ОНУ вернуть. Но, думаю, большинство провайдеров допускают ситуации, когда клиент не расторгает договор - но и не пользуется услугами и не платит за них достаточно длительный период.

Здравствуйте. Интересует такой вопрос. Существуют ли какие-либо способы предотвратить использование ОНУ другим провайдером? Вот, допустим, пришёл к нашему клиенту другой провайдер и предложил пакет на 5 копеек дешевле. И нашу же ОНУ нашим кабелем подключил к своей сети. Есть ли какая-то возможность сделать так, чтобы ОНУ работали только в нашей сети, а в другой (без дополнительных усилий со стороны того провайдера) не работали? ОЛТы у нас используются P3310B и P3310C. ОНУшки - зоопарк: Pon E107-CF нонейм Gpon Alcatel-Lucent I-010G NGpon E105 Foxgate 1001WZ несколько разных моделей BDCOM... Понимаю, что вопрос достаточно глупый, но вдруг у кого-то есть положительный опыт...

большое спасибо за помощь! всё очень просто - когда знаешь, как :)

Здравствуйте. Настраиваю "выносной" сервер доступа на Микротике. В user manager прописаны МАС-адреса из локальной сети, которые могут получать IP по DHCP. Там же прописаны ограничения скорости. Устройства с прописанными МАС-адресами получают IP по DHCP и доступ за пределы сети. Если МАС отсутствует - адрес не выдаётся, доступа нет. Но если вручную на устройстве из локальной сети прописать IP из пула, из которого выдаются адреса - устройство получает доступ за пределы локалки вне зависимости от его МАС адреса. Как эту лазейку правильно заблокировать? Спасибо.

Здравствуйте. На "железных" железках никогда не сталкивался с ситуацией, чтобы интерфейсы "перенумеровывались". А вот сейчас проверяю определённые идеи на виртуалке с РоутерОС - и столкнулся с тем, что у меня в определённый момент "поехали" интерфейсы: порядок интерфейсов в конфиге виртуалки перестал соответствовать порядку интерфейсов "внутри" МикроТика. Т.е. первый интерфейс в виртуалке стал ether2, 2-й - ether3, ..., последний - ether1 (сначала такой чехарды не было). Хочу "прибить" названия интерфейсов к их МАС-адресам. Пробовал set [ find orig-mac-address=XX:XX:XX:XX:XX:XX ] name=myname и set [ find mac-address=XX:XX:XX:XX:XX:XX ] name=myname МикроТик всё равно "переиначивает" эти команды в set [ find default-name=etherX ] Но вот эти X в etherX уже один раз "съехали", и нет никакой гарантии, что они не съедут ещё раз :( Есть какая-то возможность "закрепить" названия интерфейсов, привязав их не к "etherX", а к чему-то более постоянному? Или это особенность реализации RouterOS X86 и остаётся только смириться? (и ни для чего, кроме как для тестов, её не использовать)

Всё понятно, спасибо. Слишком давно разбирался с PPPoE и успел подзабыть реализацию :( Приношу извинения за глупый вопрос.

Есть два БРАСа - "железный" (SE100) и Акцель. SE100 работает давно, Акцель только начинаем внедрять. Почему-то на запросы на получение адреса по протоколу PPPoE отвечает только Акцель. Сложилось впечатление, что SE100 "видит" ответ Акцеля на запрос, и сам даже к Радиусу уже не обращается. Можно ли (если да - то как), сделать так, чтобы к Радиусу для обработки PPPoE запроса обращались оба БРАСа? В случае с IPoE к Радиусу обращаются оба БРАСа, и Радиус определяет, какой из БРАСов должен авторизовать клиента. Такого же поведения хочется добиться и для PPPoE.

# tc filter show dev ipoe0 filter parent 1: protocol ip pref 90 fw filter parent 1: protocol ip pref 90 fw handle 0x30 classid 1: # tc filter show dev ipoe1 filter parent 1: protocol ip pref 90 fw filter parent 1: protocol ip pref 90 fw handle 0x30 classid 1:

Да, этот вариант мне в голову не пришёл. Спасибо за хорошую идею.

-l - это именно data, а не управление (проверено экспериментально) а управление - это -A (тоже проверено) не могу ручаться за реализации всех протоколов (т.к. они выполняются разными демонами), но демон bgpd умеет биндиться не к 0.0.0.0 (к сожалению, он умеет либо к 0.0.0.0, либо к одному конкретному адресу) так что по поводу сорцов - их действительно не мешало бы "допилить", чтобы можно было указывать несколько параметров -A и -l

Это почти то, что нужно. Почти - потому что параметр -l может быть только один (если задать больше одного - игнорируются все, кроме последнего). А мне ведь нужно, чтобы bgpd с разными пирами общался (с разных адресов, естественно), в т.ч. и с bird. Спасибо за информацию - но, похоже, моя хотелка нереализуема.