+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Запрос функции MPLS: Управление VRF

Запрос функции MPLS: Управление VRF, RouterOS

Eising

Guest

27.11.2009 14:37:00

Привет! У меня есть предложение по новой функции: хочу предложить концепцию management VRF. Management VRF позволяет использовать отдельную таблицу маршрутизации для управления. Доступ по SSH, WinBox, Telnet и прочим разрешен только в пределах этой VRF. В среде провайдера это обеспечивает безопасность основной таблицы маршрутизации, поскольку именно она содержит интернет-маршруты, и через неё проходит интернет-трафик клиентов. Management VRF станет таблицей маршрутизации, через которую будет осуществляться весь доступ к роутеру. Telnet, SSH, WinBox, SNMP и т.д. будут прослушивать адреса только в пределах VRF, а также удалённая логирование, NTP и т.д. Я вижу это реализованным в RouterOS примерно так: Разрешить /ip service иметь ключевое слово routing-table. Таким образом, я смогу делать следующее: /ip service set ssh routing-table=management. Тогда SSH будет привязываться к интерфейсам в пределах management VRF. По умолчанию будет "main", чтобы это работало без поддержки MPLS. Разрешить указание глобальной опции @routingtable, чтобы можно было делать следующее: /system logging target add name="my.nms.station" target=remote remote=192.168.255.13:514@management или опцию routing-table здесь тоже. Я видел это реализованным на маршрутизаторах Cisco ASR-1000, и я считаю, что это правильный способ обезопасить MPLS-сети, содержащие клиентские маршруты в глобальной таблице. Надеюсь, вы реализуете эту функцию. Если у вас возникнут вопросы, с удовольствием всё поясню.

padmaramya Guest	#2 0 11.05.2010 12:26:00 Не могли бы вы, пожалуйста, подробно объяснить мне это управление VRF с графическим представлением?

borec420 Guest	#3 0 19.06.2012 11:13:00 Была бы очень полезная функция. Есть ли какие-то продвижения по этому вопросу? @mikrotik: Кто-нибудь думает о реализации этой функции в RouterOS?

LukasSVK Guest	#4 0 01.07.2012 01:44:00 +1, очень полезно и не только в MPLS. Сейчас управление/сервисы не поддерживаются.

Zorro

Guest

17.05.2016 03:19:00

VRF не идеален и рассчитан на относительно простые, компактные настройки. Если тебе нужно что-то более гибкое, удобное в управлении и изящное, что со временем не вырастет в огромного монстра с точки зрения размера и потребления ресурсов — PBR может быть для тебя другим вариантом. В любом случае, VRF выполняет свою работу. Возможно, и с MPLS в будущих версиях ROS — да, вполне вероятно.

doneware

Guest

17.05.2016 20:04:00

Может, это только мне так кажется, но я думаю, что протоколы маршрутизации не менее важны, чем само управление. Поэтому мой подход – использовать глобальную таблицу маршрутизации (GRT) для решения обеих задач. Все остальное (пользовательский трафик, VRF-ы [если они есть]) может оставаться изолированным, так как я не хочу, чтобы пользователи имели доступ к сетевым элементам. Идея управления VRF-ами возникла из-за того, что изначально устройства не могли иметь изолированные таблицы маршрутизации. Тогда все (пользовательский трафик, трафик управления, трафик данных) находилось в одном экземпляре маршрутизации. Затем появилась виртуализация таблиц маршрутизации в начале 2000-х, и все поспешили спрятать там доступ для управления. Более элегантным решением было бы поместить все остальное в изолированные экземпляры, даже интернет-трафик. Но это было сложно, если вообще возможно, в большой сети, состоящей из многих устройств (десятки-сотни). Я предполагаю, что вы будете использовать MPLS в сети, иначе VRF-ы не так уж и веселы. В этом случае вам все равно придется скрывать топологию от всех. И эта информация о маршрутизации (IGP, iBGP, LDP) всегда будет находиться в GRT. И если вы сосредоточены на безопасности, вам, возможно, не захочется размещать там что-либо, связанное с пользователями, что делает ее лучшим местом для размещения трафика управления. Я не говорю, что управление с поддержкой VRF - это плохо, на самом деле вам понадобится гораздо больше, каждый отдельный инструмент/команда, которые вы используете для связи/тестирования/чего угодно, должны поддерживать VRF. Но есть более одного способа это сделать. Как всегда.

EDIT: Если речь идет только о "почти идеальном" контроле доступа, вы можете добиться этого, используя цепочку входящего трафика брандмауэра IP для управления входящим трафиком. Тем не менее, это будет немного сложнее.

ZeroByte

Guest

17.05.2016 20:54:00

Интересный подход. Я тоже об этом думал, но как-то не хотел лезть с глобальной BGP-таблицей в VRF… но если подумать, если в ядрах/слоях распределения сети только твоя собственная топология, и PE-маршрутизаторы используют LSPs для достижения пограничных маршрутизаторов, то большинство устройств даже не будут иметь глобальную таблицу маршрутизации, так что в этом смысле это имеет гораздо больше смысла… хмммм… (шестеренки крутятся) Но да, инструменты и сервисы на хосте определенно должны быть VRF-aware. Отсутствие возможности поместить pppoe-сервер в VRF, например, затормозило многих людей в разработке сетевых схем…

nz_monkey

Guest

18.05.2016 09:10:00

+1 Вот почему у нас до сих пор Cisco ASR в сети! Нам нужно уметь запускать L2TP-сервер в VRF, ориентированном на наших оптовых провайдеров (по соображениям безопасности), а когда пользователи подключаются к нашему L2TP-концентратору, нам нужны RADIUS VSA для размещения этих соединений в другой VRF.

Zorro

Guest

18.05.2016 23:13:00

VRF изначально больше походил на простое/прямое решение для небольших сетей/компаний, а не на серебряную пулю, панацею :=) И да, эволюция MPLS/VPLS тоже мне кажется более логичной и весомой. Ну и весь этот "ad-hoc" функционал, типа HWMPLUS/802.11s, BATMAN v3/4/5, cjdns и несколько менее популярных вариантов. Что касается "запаковывания"/изгибания глобальной таблицы маршрутизации (то ли через VRF, то ли через что-то еще из популярных) — к сожалению, большинство маршрутизаторов все еще не хватает необходимого аппаратного обеспечения для этого (и CCR не идеально масштабируется, пока). А что касается безопасности конечных точек — использование серверов RADIUS/Diameter в качестве основы (для аутентификации и проверки 1/2/3-факторной аутентификации против d-db) вполне обычно и имеет смысл, но L2TP для этого — немного перебор и, в общем, 802.1x-2010 вполне достаточно.

nicktc Guest	#10 0 14.04.2016 16:55:00 +1 (и, есть какие-нибудь обходные пути?)

nz_monkey Guest	#11 0 15.04.2016 11:54:00 По местной легенде, эта функция будет доступна в RouterOS v7.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры