Policy-based Routing (PBR), как основное назначение (Часть 1). Дипс роут
Routes. The Beginning / Хабр
Окей. Проект создан и мы вошли в рабочую папку. Сразу набросимся на роуты:
rake routes
эта команда вам выдаст две строчки стандартных роутов./:controller/:action/:id /:controller/:action/:id.:format
Это значит, что любой урл сейчас будет парситься по этим двум правилам. :controller — это Контроллер =). Это компонент MVC, который чаще всего выступает как посредник между Представлением (HTML) и Моделью (база данных, скажем). Дальше будет яснее, но скорее всего вы итак знаете, что это такое. :action — это вызываемый метод контроллера. У контроллера обычно много методов. :id — если я вно не указывать запрет на создание id, то по умолчанию любая модель (таблица БД) создается с полем id. Поэтому любой элемент модели имеет id. И когда вы хотите удалить/редактировать/что угодно делать с каким-то конкретным элементом модели вы обязаны передать в контроллер этот самый id.
Окей. Давайте мы создадим новостной журнал. Для этого нам нужны: — Таблица news в нашей базе данных (Модель). В БД мы будем хранить заголовок статьи (title), автора статьи (author) и собственно саму статью (article) — Набор методов для работы с БД (Контроллер) — HTML формы для ввода, редактирования, чтения новостей (Представление) Мы можем создавать все это по отдельности. Но сейчас мы упростим себе задачу и используем функцию scaffold для генерации пачки готовых файлов.
./script/generate scaffold Magazine title:string author:string article:text
Мы только что создали все выше перечисленное (а также Helpers, о которых как-нибудь в другой раз). Также команда scaffold сама создала необходимые роуты. Еще раз наберите команду rake routes и вывалится кипа новых роутов
magazines GET /magazines {:controller=>"magazines", :action=>"index"} formatted_magazines GET /magazines.:format {:controller=>"magazines", :action=>"index"} POST /magazines {:controller=>"magazines", :action=>"create"} POST /magazines.:format {:controller=>"magazines", :action=>"create"} new_magazine GET /magazines/new {:controller=>"magazines", :action=>"new"} formatted_new_magazine GET /magazines/new.:format {:controller=>"magazines", :action=>"new"} edit_magazine GET /magazines/:id/edit {:controller=>"magazines", :action=>"edit"} formatted_edit_magazine GET /magazines/:id/edit.:format {:controller=>"magazines", :action=>"edit"} magazine GET /magazines/:id {:controller=>"magazines", :action=>"show"} formatted_magazine GET /magazines/:id.:format {:controller=>"magazines", :action=>"show"} PUT /magazines/:id {:controller=>"magazines", :action=>"update"} PUT /magazines/:id.:format {:controller=>"magazines", :action=>"update"} DELETE /magazines/:id {:controller=>"magazines", :action=>"destroy"} DELETE /magazines/:id.:format {:controller=>"magazines", :action=>"destroy"} Теперь мы запустим сервер и поиграемся с журналом. Но сперва мы создадим нашу базу данных и запустим миграции.Наш журнал теперь доступен по адресу localhost:3000/magazines Создайте пару новых статей.
Вернемся к таблице роутов выше. Первый столбец — это именные роуты. Они очень удобны. Есть несколько вариантов сейчас сделать ссылку на создание новой статьи. Откройте файл app/views/magazines/index.html.erb — это представление для метода index в контроллере magazines_controller. В самом низу давайте допишем немного кода.
<hr> <%= link_to 'Новая статья', :action => 'new' %><br /> <%= link_to 'Новая статья', '/magazines/new' %><br /> <%= link_to 'Новая статья', new_magazine_path %><br /> <%= link_to 'Новая статья', new_magazine_url %><br />
Самым правильным будет использование последних двух методов. Разница в том, что url возвращает полную ссылку (http://localhost:3000/magazines/new), а path только путь (/magazines/new). Почему лучше пользоваться именными роутами? Именной роут это переменная, изменив которую вы меняете все ссылки, которые пользуются этим роутом. Писать пути от руки вобще не рекомендуется, если приспичило, то лучше написать :action => 'new' (зачастую именных роутов на все случаи жизне не хватает, поэтому этот вариант очень распространен).
Второй столбец таблицы — это метод запроса. Одна и таже ссылка, но с разным методом ведет на разные методы контроллера. К примеру, в том же app/views/magazines/index.html.erb:<%= link_to 'Show', magazine %> <%= link_to 'Destroy', magazine, :method => :delete %> В первой ссылке исполняется дефолтный GET запрос (можно не указывать в ссылке :method=>:get), а во второй отправляется метод :delete. А ссылка magazine остается в обоих случаях одинаковая.
Третий столюбец — это собственно ссылки, которые мы получим в HTML. Последний столбец — это соответствие ссылок контроллеру и методу. Как уже выше писалось, любую ссылку можно представить в виде пары :controller, :action (ну и иногда :method).
<%= link_to 'Ссылка на другой контроллер из контроллера magazines', :controller => 'blogs', :action=>'show', :id=>'1', :method=>'GET' %> Так мы получим ссылку на блог с индексом 1. (Тут метод :get можно было и не указывать) <%= link_to 'Ссылка на родной метод контроллера', :action => 'show', :id => '1' %> Ссылка на статью с индексом 1. Контроллер и HTTP метод в данном случае указывать не надо, так как GET исполняется по умолчанию, а контроллер, если не указан, выполняется тот же.
Тепрь откройте файл config/routes.rb (можете удалить весь закомментированный текст)
map.resources :magazines map.connect ':controller/:action/:id' map.connect ':controller/:action/:id.:format'
Первую строчку вставила команда scaffold. Эта строчка и добавила нам пачку роутов, которую мы наблюдали выше.
Если вы сейчас наберете просто localhost:3000 вы попадете на приветственную страницу. Давайте это исправим.
map.root :controller => 'magazines'
Теперь из папки public удалите index.html и зайдя на localhost:3000 вы попадете напрямую куда надо =). Кроме того если вы просмотрите все роуты занова (rake routes), то увидите новый именной роут root. И в меню сможете сделать ссылку на «Главную» вида:
<%= link_to 'Главная', root %>
И вы всегда без ущерба ссылкам сможете изменить домашнюю страницу, скажем, на ваш магазин map.root :controller => 'shop'
Собственно создав root вы создали первый именной роут своими руками. Давайте создадим именной роут «localhost:3000/zhurnal». Не хотим мы буржуйский 'magazines', хотим 'zhurnal'!map.zhurnal '/klevi_zhurnal/:id', :controller => 'magazines', :id => nil
Итак, мы создали именной роут zhurnal, урл которого будет выглядеть как localhost:3000/klevi_zhurnal, а контент он будет получать от контроллера magazines. Если мы попробуем прочесть статью теперь вроде localhost:3000/klevi_zhurnal/1 — то мы обламаемся. Внесем в наш роут немного изменений:
map.zhurnal '/klevi_zhurnal/:action/:id', :controller => 'magazines', :action => 'index', :id => nil
Что все это значит: — урл вида /klevi_zhurnal/ будет отработан :controller => 'magazines', :action => 'index', :id => 'nil' — то есть мы получим индексовую страницу (index.html.erb) — /klevi_zhurnal/1 выплюнет ошибку, что action '1' не существует (посмотрите на последовательность передачи аргумента в роуте) — /klevi_zhurnal/show скажет, что ID не указано — /klevi_zhurnal/show/1 — выдаст вам статью с ID=1 (если она конечно существует) — /klevi_zhurnal/edit/1 — выдаст форму редактирования этой статьи
Правда теперь несколько тяжелее выглядят сами ссылки: Вместо <%= link_to 'Все статьи', magazines_path %> будет <%= link_to 'Все статьи', zhurnal_path %> Вместо <%= link_to 'Статья номер 1', magazine_path('1') %> будет <%= link_to 'Статья номер 1', zhurnal_path(:action=>'show', :id=>'1') %>
Обратите внимание на то, что для лучшего понимания роутов введена система множественного/единственного числа: показать все статьи magazines_path, показать отдельную статью: magazine_path. Чорт — не самое правильное слово вообще выбрал =). Если бы у нас все называлось Article: index => articles_path, show => article_path(:id)
Теперь давайте создадим новый метод. Откройте app/controllers/magazines_controller.rb Добавьте туда метод
def random offset = rand(Magazine.count :all) @magazine = Magazine.find(:first, :offset => offset) render :action => 'show' end
Этот метод просто возвращает рандомно статью. Давайте попробуем его вызвать: localhost:3000/magazines/random Получаем ошибку — требует от нас ID. Почему? Потому что стандартный роут продразумевает роут вида :controller/:action/:id. Давайте попробуем вызвать роут по правилам: localhost:3000/magazines/random/1230492 Записи с таким ID не существует — но все работает! Так как мы в нашем методе не используем ID вообще — то для нас и не принципиально какую ерунду мы там напишем. Давайте теперь все же попробуем сделать корректный роут вида localhost:3000/magazines/random/ Для этого существует опция :collection => { :action => :HTTP_method } Наш :action это :random, метод — :get получаем
map.resources :magazines, :collection => { :random => :get }
теперь все работает! =)
На этом вводная часть заканчивается. Дальше нас ждут более изощренные методы извращения ). Но не сегодня. Спасибо, за потраченное на чтение статьи время ).
API для желающихСкринкасты Райана Бейтса
habr.com
Легендарная американская дорога Route 66: ary
Route 66 на карте. Сейчас дорога выглядит уже не так - ее вообще нельзя целиком проехать от начала до конца. Но по некоторым участкам этого легендарного шоссе в штатах Аризона и Калифорния нам все же удалось покататься.
1.
2.
Почти любой городок на Дороге 66 создает ощущение, что несколько десятков лет назад здесь просто перестало идти время. Ну или оно идет, но в каком-то своем неспешном темпе. И это совсем не значит, что городки заброшены - нет, они живут, просто немножко застряли где-то в 50-х или 60-х годах.
3.
Вообще, то что произошло с городками на Route 66, очень наглядно показано в пиксаровском мультике "Тачки". Там как раз идет речь об одном из таких городков - как из-за строительства новой трассы он оказался всеми забытым. Обязательно посмотрите мульт, если еще не видели! Ну или хотя бы вот этот отрывок:
Многие придорожные магазинчики тоже превратились в музеи. В любом из них можно найти коллекцию старинных дорожных знаков, ржавых автомобильных номеров и конечно самих машин.
4.
Вот, например, такой автопарк. Давно переехавшим поближе к цивилизации хозяевам эти ржавые автомобильчики уже совершенно ни к чему.
5.
А это коллекция старинных заправочных станций.
6.
Просто жилой дом. Мания собирать всякий хлам не обошла и его хозяев.
7.
8.
Нечто стилизованное под городок Дикого Запада, а потом, кажется, все равно заброшенное.
9.
И ни души...
10.
На шоссе есть и много настоящих заброшек.
11.
Вот, например, такой ресторан.
12.
Ничего удивительного в том, что он разорился. На этом участке дороги за несколько часов пути мы встретили всего пару машин.
13.
Вид изнутри. Еще недавно, наверное, был открыт.
14.
Отдельная история - это дорожные указатели. "Указывать" на Route 66 чаще всего просто не на что, поэтому годится любой повод сообщить путнику о чем-нибудь, что ждет его на пути (а киоск через четверть мили конечно же не работал).
15.
Въезд в индейскую резервацию, тоже закрытый.
16.
Но самое интересное - это серии указателей, на которых скучающий путник может прочитать составленную фразу.
17.
Знаете, что это такое? Я настолько заинтересовалась этим вопросом, пока искала на него ответ, что решила написать отдельный пост и раскрыть тему поподробнее. АПД: готово, читать здесь
18.
А вот эти же знаки в одном из придорожных магазинов-музейчиков."Big MistakeMany MakeRely On HornInstead of Brake"
19.
Вот такая она, Дорога № 66.
20.
Самое стремное здесь - это когда садится солнце. Сразу наступает кромешная тьма, а до цивилизации еще ехать и ехать. Главное, не остаться здесь вдруг без бензина.
21.
Наконец-то один из отелей оказался работающим. Ура!
22.
If you ever plan to motor west, Travel my way take, the highway that's the best.Get your kicks on Route sixty-six.
Well it winds from Chicago to LAOver two-thousand miles all the way. Get your kicks on Route sixty-six.(с) Bobby Troup, 1946
ary.livejournal.com
Policy-based Routing (PBR), как основное назначение (Часть 1) / Хабр
Что такое Policy-based Routing (PBR) Policy-based routing (PBR) перевод данного словосочетания несет смысл такого характера, как маршрутизация на основе определенных политик (правил, условий), которые являются относительно гибкими и устанавливаются Администратором. Другими словами это технология предоставляет условия гибкой маршрутизации (если смотреть на технологию с первоочередной ее задачи), по источнику или назначению пакета.Где применяется Применение данной технологии очень часто используется для организации избыточности в небольших офисах, при нескольких каналах связи с «вешним миром», «гуглится» примерно таким запросом (PBR 2 ISP). Ну, или другими аналогичными. Если вы «погуглите» то для избыточности нужно будет помимо PBR еще такие штуки как Tracking, SLA, на них я сильно внимание не буду заострять, как сейчас так и в дальнейшей части статьи.Кратко про SLA и tracking — это две технологии, точнее связка двух технологий (в нашем случае), которые генерируют различного рода icmp трафик (при заданных условиях), это я про SLA, и выполняют мониторинг данного генератора, а это про tracking.
Так же PBR находит применение в настройках динамических протоколах маршрутизации (к примеру BGP; OSPF;EIGRP)для фильтрации и redistributions (перенаправления) роутов ну и мелочей типа изменение метрики маршрутов и т.п., и в статической маршрутизации (раскроется ниже), В построение механизмов улучшение качества сервисов (QoS). Возможно, что-то забыл, уж не обессудьте. В дальнейшем, в статье, я не буду раскрывать тему применения PBR в BGP, QoS, OSPF. Основы конструкции Собственно карта выглядит таким образом:Route-map namemap permit 5 match int fa0/0set ip default next-hop 10.10.10.1
Разберем по порядку: Первая строка (route-map namemap [permit | deny] [sequence-number]) содержит непосредственно команду которая открывает нашу карту (route -map), далее идет имя карты (namemap), для дальнейшего применение к политике этой карты затем идет permit (так как мы хотим, что бы трафик при выполнении условии описанных ниже выполнял действие). Т.е. идет перенаправление пакетов на шлюз 10.10.10.1. Вместо параметра permit может выступать параметр deny, но он не так часто применяется. В большей степени он применяется только при redistributions (перенаправления), в динамических протоколах маршрутизации, а если быть точнее, наоборот, при deny не производить redistributions (перенаправления). Для нижеуказанного условия карты, последним параметром идет sequence-number он у нас 5 т.е. порядковый номер карты, он удобен для логического представления карт с одним и тем же именем. Так же для удобства администрирования карты (удаления в частности).
Вторая строка (match interface fa0/0), содержит условие, для какого трафика применять нашу карту. В нашем случае, у нас будет применяться весь трафик проходящий через интерфейс маршрутизатора fastethernet0/0. Тут можно по различным критериям делать выборку, как правило, все рисуют карту по access-lists (листам доступа) т.е. рисуют access-list с параметрами для каких сетей применять карту. Примеры access-lists с легким комментарием представлены ниже.access-list 101 permit ip 192.168.0.0 0.0.0.255 any ### этот access-list примененный к route-maps будет выбирать трафик сети 192.168.0.0/24 до любого назначения. А при применении такого access-lists access-list 101 deny ip 192.168.0.0 0.0.0.255 host 192.168.2.44 access-list 101 deny ip 192.168.0.0 0.0.0.255 192.168.1.0 0.0.0.31 access-list 101 permit ip 192.168.0.0 0.0.0.255 any ### в первой строчке не будет перенаправлять трафик до хоста 192.168.2.44 ### по второй строке так же не будет перенаправлять на сеть 192.168.1.0/27 ### ну и по третьей строке будет применять для всего остального трафика, сети 192.168.0.0/24.
Так же добавить хочется что параметр match повторяющийся, т.е. выборку можно делать по нескольким критериям. К примеру метим по access-lists, и параллельно по размеру пакета match length min max, где min max это диапазон размера пакета от и до). И еще маленькое дополнение к этому параметру он не является обязательным. Другими словами если не делать выборку по критериям, то карта будет применяться ко всем пакетам, проходящим через интерфейс на который мы применим нашу карту маршрутизации.
Переходя к следующему параметру, скажу, что если вы выполните подкоманду set ? то помощь, вам покажет много значений, в основном эти значения направлены на опять же динамические протоколы маршрутизации. На данный момент я решил их не касаться (я планирую написать статьи про динамическую маршрутизацию, там и вернемся к ним). А перейдем сразу к set ip
Мы взяли в пример set ip default next-hop 10.10.10.1 Тут мы опять же рассмотрим ключевое слово default, оно означает, что если не будет роутов в глобальной таблице маршрутизации информации о сети назначения пакета, то будет отрабатывать наша карта и пакет будет отправлен на следующий шаг в данном случае 10.10.10.1. Можно написать явный set ip next-hop 10.10.10.1 и тогда пакет в не зависимости от глобальной таблицы будет перенаправлен на наш next-hop, т.е. пакет попавший в критерий что он пришел на интерфейс fa0/0, отправится на 10.10.10.1 и он уже будет решать что с этим пакетом делать.
Далее рассматривая параметр set ip, можно задать следующий шагом(next-hop) как определенный ip адрес, для последующей маршрутизации, так непосредственно интерфейс. К примеру set ip next-hop interface Dialer1), это удобно когда у вас, к примеру не статический адрес на next-hop-е, а динамический и вы не можете явно прописать адрес 3-го уровня, ну или если вы забыли какой ip адрес у вас на интерфейсе и вам лень посмотреть. Как было подмечено ниже в комментариях, не стоит указывать интерфейсы, на которых прописана сеть с большим количеством хостов в сети, другими словами использовать стоит при point to point сети (с префиксов 30 ).Другие параметры set ip, используются для изменения параметров ip пакета. Установка маркирования приоритета пакета в QoS(set ip precedence 3), или сброса параметра пакета don’t fragments (set ip df 0), что позволит установить размер пакета, какой нужен маршрутизаторам для дальнейшей передачи по каналам связи. Остается мелочь повесить route-map на интерфейс через который приходят пакеты нуждающиеся в перенаправлении пакетов в отличие от дефолтного маршрута глобальной таблицы маршрутизации. И получится такой листинг Route-map namemap permit 5 match int fa0/0 set ip default next-hop 10.10.10.1
interface FastEthernet0/0 encapsulation dot1Q 20 ip address 192.168.0.1 255.255.255.0 ip policy route-map namemap
Прошу заметить, что данная конфигурация не совсем правильная в нашем случае, хотя рабочая. Тут сами подумайте, чем она не корректна, и какие условия нужно изменить.
Послесловие: В этой части я попытался раскрыть азы PBR и как он работает с пакетами. Если у меня это получилось не внятно, прошу указать на ошибки. Буду очень признателен. В части 2 я опишу еще несколько моментов касающихся PBR, и приведу примеры построения маршрутизации, для конкретных случаев.
UPD вот собственно и попытка продолжения часть 2
Материал для статьи брался из головы, так что литературу указать не смогу, разве что www.
P.S статья эта была в песочнице, мне кто-то дал приглашение на хабр, но так как я был в офлайне долгое время приглашение утратило силу свою. хочу сказать спасибо товарищу который дал инвайт. сейчас я по приглашению smartov, мы с ним знакомы по другому ресурсу в сети. Ему так же благодарность за приглашение.
Posted by Mario
habr.com
Разница между Route Distinguisher и Route Target / Песочница / Хабр
Когда-то, начиная изучать MPLS и реализуемые на его основе сервисы, я уперся в два понятия — Route Target и Route Distinguisher. Информация по этим понятиям была в основном на английском языке (спасибо родителям за то что заставляли меня учить английский), на русском был или машинный перевод или общая информация, которая порождала больше вопросов, чем давала ответов.В статье буду использовать выводы с оборудования Juniper, так как испытываю большую симпатию к оборудованию данного производителя, нежели к Cisco, Huawei или Broсade. Статья написана полностью мной и не является переводом, дампы трафика и выводы с оборудования взяты с собранного в GNS3 стенда (для эмуляции использовал; vSRX, Cisco IOS-XR (vXR) и IOS).
Для того что бы перейти к пониманию назначения Route Target и Route Distinguisher, надо понять, что такое VRF, так как часть сетевых инженеров полностью не понимают принцип работы VRF (для некоторых даже открытием является то, что VRF используется и без MPLS).
Итак VRF — это не маршрутизатор в маршрутизаторе, а всего лишь изоляция таблицы маршрутизации одного клиента от другого и от основной таблицы маршрутизации роутера — это надо твердо усвоить (маршрутизатор в маршрутизаторе — это например logical systems в JunOS). По сути можно провести аналогию с VLAN — между различными VLAN пакеты напрямую не передаются (между VLAN пакеты должны идти через маршрутизируемый интерфейс), так же и два VRF, живущих на одном маршрутизаторе не могут общаться друг с другом без перераспределения маршрутов, так как их таблицы маршрутизации не имеют маршрутов к друг другу. Теперь мы можем перейти к основной теме статьи. Начнем с Route Destingisher (дословно различитель маршрутов). Route Distinguisher представляет из себя 64-битную последовательность вида type (2 байта):administrator(2 или 4 байта):value(4 или 2 байта). Поле type указывает в каком формате будут следующие два поля, значения которых указаны ниже:
Что бы понять назначение RD, разберем топологию ниже:
К PE-маршрутизатору подключены два клиента, но есть проблема — оба клиента имеют одно и то же приватное адресное пространство — 10.0.0.0/24. Предположим что между CE1 и PE запущен OSPF, а между CE2 и PE — RIP. На PE нам необходимо сделать перераспределение маршрутов из IGP протоколов в BGP, что бы передать маршруты клиентов на другие PE-маршрутизаторы. Для BGP это один и тот же префикс 10.0.0.0/24, поэтому перераспределен и анонсирован соседям по BGP будет только один лучший маршрут. Но нам то надо анонсировать оба маршрута. Вот тут нам на помощь приходит Route Distinguisher. Его единственной, но очень важной задачей является сделать заведомо не уникальный префикс уникальным. Получается это с помощью добавления 64-битного Route Distinguisher к искомому префиксу:
К примеру, имея два одинаковых префикса 192.168.1.0/24 и Route Distinguisher 100:10 и 100:20, получаем уникальные VPNv4 unicast префиксы, длинной 96 бит.
bgp.l3vpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 100:10:192.168.1.0/24 *[BGP/170] 00:46:53, localpref 100, from 10.3.3.3 AS path: I > to 10.0.0.1 via ge-0/0/1.0, Push 17, Push 17(top) 100:20:192.168.1.0/24 *[BGP/170] 00:46:53, localpref 100, from 10.3.3.3 AS path: I > to 10.0.0.1 via ge-0/0/1.0, Push 16, Push 17(top) Теперь эти префиксы можно передать другим PE маршрутизаторам. Но один из моих коллег задал вот такой вопрос: как PE маршрутизатор выделяет IPv4 префикс из полученного VPNv4 префикса, если не знает значение Route Distinguisher. Тут все просто, рассмотрим BGP Update message. Для начала посмотрим, как передается обычный IPv4 префикс:
Как видно из BGP анонса, в теле сообщения в поле NLRI и находится префикс. С помощью расширения MP-BGP, данный протокол может обеспечивать обмен префиксами различных address family идентифицируя их различными значениями AFI/SAFI. Рассмотрим Update message, в котором будет содержаться VPNv4 префикс:
Так как маршрутизатор знает длину Route Distinguisher (она фиксирована и равна 64 битам) и начало VPNv4 префикса, то ему не составляет труда отбросить значение первых 64-х бит и поместить в таблицу маршрутизации клиента только IPv4 префикс:
red.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.0/24 *[Direct/0] 00:48:11 > via ge-0/0/2.0 192.168.0.1/32 *[Local/0] 00:48:13 Local via ge-0/0/2.0 192.168.0.100/32 *[Direct/0] 00:48:37 > via lo0.1 192.168.1.0/24 *[BGP/170] 00:46:53, localpref 100, from 10.3.3.3 AS path: I > to 10.0.0.1 via ge-0/0/1.0, Push 17, Push 17(top) Думаю, что с Route Distinguisher мы разобрались, поэтому перейдем к обсуждению Route Target.Для понимания назначения Route Target надо понять, что такое l3vpn. К примеру клиент хочет объединить свои географически разнесенные сайты в одну сеть с помощью сети провайдера. Применение например GRE или IPSec-тоннелей в данном случае не возможно (физически возможно — но как администрировать такую кучу тоннелей?). Так как GRE или IPSec создают тоннель типа точка-точка, то чтобы соединить например 5 сайтов клиента нам надо связать каждый сайт с каждым (full mesh топология), то есть создать вручную n(n-1)/2, то есть 5(5-1)/2=10 тоннелей. А если сайтов будет 10 или 20?? l3vpn использует механизм автоматического поиска PE маршрутизаторов, к которым подключены сайты клиента (сконфигурированы соответствующие VRF), для автоматического создания между ними LSP -тоннелей. Когда у провайдера всего один клиент, то проблем с распределением анонсов нет, так как все маршруты должны быть приняты всеми PE-маршрутизаторами. Но в реальности клиентов много, а значит между PE маршрутизаторами передается много различной маршрутной информации различных клиентов. Но PE-маршрутизаторам не нужны все маршруты, а только маршруты клиентов, которые непосредственно подключены к этому PE-маршрутизатору. Получается, что надо как-то маркировать префиксы различных клиентов, которые будут передаваться по BGP между PE-маршрутизаторами и использовать эту маркировку для фильтрации маршрутной информации на PE-маршрутизаторах. Тут нам на помощь приходит BGP, а точнее атрибут community. Community бывают двух видов стандартные и расширенные. Route Target как раз таки и является частным случаем расширенного community, имеет длину 64 бита и формат type:administrator:assigned-number (например target:65501:100):
Ниже показан вывод марштутов, анонсируемых по протоколу BGP, к которым прикреплены расширенные community:
root@PE2> show route advertising-protocol bgp 10.1.1.1 detail blue.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) * 192.168.1.0/24 (1 entry, 1 announced) BGP group internal-vpn type Internal Route Distinguisher: 100:20 VPN Label: 16 Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [100] I Communities: target:1:2 red.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) * 192.168.1.0/24 (1 entry, 1 announced) BGP group internal-vpn type Internal Route Distinguisher: 100:10 VPN Label: 17 Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [100] I Communities: target:2:2 Route Target делятся на два значения import и export. Первое предназначено для фильтрации префиксов PE маршрутизатором на приеме. Принятые префиксы в последствии будут установлены в таблицу маршрутизации соответствующего VRF ( как RT import может быть указано более одного значения, в случае его отсутствия ни одни из маршрутов не будет принят и установлен в таблицу маршрутизации). Что бы можно было на приеме произвести фильтрацию на основании community, надо, чтобы это community кто то добавил к анонсу. Для этого и используется Route Target export, значение которого будет добавлено как расширенное community к BGP анонсу (в случае отсутствия в конфигурации VRF данного занчения ни один из маршрутов данного VRF не будет передан на другие PE маршрутизаторы).root@PE2> show configuration routing-instances blue { instance-type vrf; interface ge-0/0/0.0; route-distinguisher 100:20; vrf-target { import target:2:1; export target:1:2; } vrf-table-label; protocols { ospf { export bgp-to-vpn; area 0.0.0.2 { interface ge-0/0/0.0; } } } } Теперь, понимая различи между этими понятиями расставим все точки над i. Рассмотрим схему:
На схеме два PE маршрутизатора, между которыми установлена BGP сессия с address family vpnv4 unicast. На первом PE1 маршрутизаторе два VRF: red и blue, на PE2 три VRF: red, blue и black. Как видно, все сайты имеют одинаковое адресное пространство, но так как у нас сконфигурированы уникальные для данной сети RD, все префиксы становятся уникальными. Теперь надо понять, какие маршруты принимают и отдают PE маршрутизаторы.
PE1 имеет два VRF, согласно RT import, он должен принимать все BGP анонсы с расширенными community 2:10 и 2:11, а так же отправлять BGP анонсы с расширенными community 1:10 и 1:11 согласно RT export. Маршруты с расширенными community, не соответствующие сконфигурированным RT-import, маршрутизатор просто отбрасывает. Маршруты с RT import 2:10 маршрутизатор помещает в таблицу маршрутизации клиента red, а с RT 2:11 — в таблицу маршрутизации клиента blue. Оправляя маршруты клиента red, маршрутизатор «навешивает» на анонс расширенное community 1:10, и соответственно для анонсов клиента blue — 1:11.
PE2 имеет три VRF, и согласно RT import он принимает BGP анонсы с расширенными community 1:10, 1:11 и 10:10, и отправляет BGP анонсы с расширенными community 2:10, 2:11 и 20:30.
Так как на PE1 не сконфигурирован VRF black, то маршруты данного клиента ему не нужны, а значит, получая маршрут с расширенными community 20:30, PE1 их просто отбрасывает на основании того, что указанное в анонсе расширенное community не задано для данного маршрутизатора.
Бывает случаи, когда необходимо принимать маршруты со всеми расширенными community (например interAS-option B). При настройке маршрутизатора необходимо разрешить принимать все анонсы, так как это не дефолтное поведение маршрутизатора. Если маршрутизатор сконфигурирован как route-reflector, то он принимает и отдает все анонсы в не зависимости от расширенных community. Кроме того сам PE маршрутизатор может ограничить получаемые анонсы от других PE маршрутизаторов или роут-рефлекторов, тем самым уменьшая количество сигнальной информации. Но это уже тема другой статьи.
Спасибо за внимание! Надеюсь, я смог донести данную до читателя разницу между двумя этими с виду идентичными, но абсолютно разными по назначению понятиями.
habr.com
как сделать route -f? как сделать route -f? для чего это и с чем его едят? )
C:\Users\Ivan>route /?Обработка таблиц сетевых маршрутов.
ROUTE [-f] [-p] [-4|-6] command [destination] [MASK netmask] [gateway] [METRIC metric] [IF interface]
-f Очистка таблиц маршрутов от записей всех шлюзов. При указании одной из команд таблицы очищаются до выполнения команды.
-p При использовании с командой ADD задает сохранение маршрута при перезагрузке системы. По умолчанию маршруты не сохраняются при перезагрузке. Пропускается для остальных команд, изменяющих соответствующие постоянные маршруты. Этот параметр не поддерживается в Windows 95.
-4 Обязательное использование протокола IPv4.
-6 Обязательное использование протокола IPv6.
command Одна из следующих команд: PRINT Печать маршрута ADD Добавление маршрута DELETE Удаление маршрута CHANGE Изменение существующего маршрута destination Адресуемый узел. MASK Указывает, что следующий параметр интерпретируется как маска сети. netmask Значение маски подсети для записи данного маршрута. Если этот параметр не задан, по умолчанию используется значение 255.255.255.255. gateway Шлюз. interface Номер интерфейса для указанного маршрута. METRIC Определение метрики, т. е. цены для адресуемого узла.
Поиск всех символических имен узлов проводится в файле сетевой базы данных NETWORKS. Поиск символических имен шлюзов проводится в файле базы данных имен узлов HOSTS.
Для команд PRINT и DELETE можно указать узел и шлюз с помощью подстановочных знаков или опустить параметр "шлюз".
Если адресуемый узел содержит подстановочные знаки * или ?, он используется в качестве шаблона, и печатаются только соответствующие ему маршруты. Знак '*' соответствует любой строке, а '?' - одному знаку. Примеры: 157.*.1, 157.*, 127.*, *224*.
Соответствие шаблону поддерживает только команда PRINT. Диагностические сообщения: Недопустимое значение MASK вызывает ошибку, если (УЗЕЛ МАСКА) != УЗЕЛ. Например> route ADD 157.0.0.0 MASK 155.0.0.0 157.55.80.1 IF 1 Добавление маршрута завершится ошибкой, поскольку указан недопустимый параметр маски. (Узел & Маска) != Узел.
Примеры:
> route PRINT > route PRINT -4 > route PRINT -6 > route PRINT 157* ...Печать только узлов, начинающихся со 157
> route ADD 157.0.0.0 MASK 255.0.0.0 157.55.80.1 METRIC 3 IF 2 узел^ ^маска ^шлюз метрика^ ^ интерфейс^ Если IF не задан, то производится попытка найти лучший интерфейс для указанного шлюза. > route ADD 3ffe::/32 3ffe::1
> route CHANGE 157.0.0.0 MASK 255.0.0.0 157.55.80.5 METRIC 2 IF 2
Параметр CHANGE используется только для изменения шлюза или метрики.
> route DELETE 157.0.0.0 > route DELETE 3ffe::/32
C:\Users\Ivan>
otvet.mail.ru
