CCNP Route "Full Scale" Лаба: Фильтруем

Прошу прощения за картинку, коллеги...

В прошлый раз я коснулся весьма сложной темы в рамках CCNP Route. Да и в рамках реальной жизни тоже. В качестве одного из вариантов решения возникающих проблемы я использовал route-map при редистрибуции. Сказать, что это очень сильный инструмент - ничего не сказать. Этот инструмент позволяет творить с трафиком много интересного, в том числе и осуществлять фильтрацию на основе тех или иных вводных. Именно фильтрацией сегодня и займемся. Но ни одними route-map'ами един мир Cisco. Попробуем разобраться в том, как можно фильтровать маршруты и другими способами.

Все посты по CCNP  Route лабе здесь. 

Во время подготовки к CCNP Route, я снова плотно подсел на "технику" MindMap. Например, каждую CLI команду, которую я применяю во время подготовки к экзамену я выношу на отдельную схему. Покажу её в будущих постах. Тема фильтрации довольно мутная, поэтому и её я решил сделать немного понятнее и нагляднее с помощью небольшой диаграммы.

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

Первый способ я применял как раз таки в прошлом посте. Можно сослаться на route-map или же добавить в другой протокол внешние (external), внутренние (internal) или NSSA (nssa-external) маршруты. Понятное дело, что речь идет только про OSPF. Все это мы рассмотрим чуть дальше.

Второй способ, как я уже упомянул, я называю локальным. Здесь у каждого протокола свои особенности. В RIP, скажем, нельзя применять route-map при редистрибуции, а вот в OSPF можно дополнительно фильтровать Type3 и Type5 LSA на ABR и ASBR соответственно.

Route-map, как я уже упомянул, очень мощный инструмент. Сам этот роутмап постоит из двух частей - match и set. В первой части мы указываем, по какому параметру мы определяем интересный трафик. Это может быть тег, интерфейс,  ACL, префикс лист и многое другое. Во второй части, делаем какие-либо операции с этим трафиком. Устанавливаем метрику, тип метрики, тег, вес и все прочее такое.

Ниже не полный список всех опций.

После краткого экскурса в теорию пора пофильтровать на лабе.

Фильтрация при редистрибуции

Обратим наш взор на OSPF. Здесь в NSSA области располагается наш инфраструктурный сервер. Само собой, мы хотим чтобы до него имел доступ каждый роутер в сети. Допустим, OSPF сеть обсуживает какие-то важные структуры и мы не хотим "светить" её остальной сети. 

В этом случае, мы можем применить механизм фильтрования на основе областей OSPF.  Настраиваем на B5-E2-O1 и E4-O2 так.

router eigrp 90
 redistribute ospf 110 match external 2 metric 1000 200 255 1 1500

Таким образом в EIGRP уйдут только внешние маршруты с типом два, а именно суммарный 192.168.0.0/21. Проверяем на Е7. Видно, что теперь у нас только один маршрут из OSPF сети.

 

Но, стоит помнить о GRE туннеле, который терминируется на О9. Его мы настроим в следующем посте. Но это значит, что про этот адрес тоже должны знать, ну как минимум в RIP домене. Так что такой способ фильтрации "с плеча" нам не подходит.

Настроим фильтр на B5-E2-O1 и E4-O2 таким образом, чтобы он пропускал только внешние маршруты на 192.168.0.0/21 и анонсировал в EIGRP адрес на loopback'e O9 (10.0.10.9/32). Не стоит забывать и про тег, который мы навешиваем на маршруты OSPF попадающие в EIGRP. Так мы избавляемся от проблем при редистрибуции. Навешивали мы его простым роутмапом ниже.

route-map TAG_EIGRP_TO_OSPF permit 10
 set tag 400

Придется немного изменить его, но пойдем поэтапно. 

1. Определяем те подсети, которые мы хотим пропустить в остальную часть сети. 192.168.0.0/21 и 10.0.10.9/32. Я сделаю это с помощью extended ACL.

ip access-list extended GREandSRV
 permit ip 192.168.0.0 0.0.0.234 any
 permit ip host 10.0.10.9 any

2. Пишем новый route-map. Пропускаем только префиксы из предыдущего ACL, а все что идет с тегом 400 отбрасываем. Как вы помните, здесь мы страхуем себя от колец и прочих неприятностей. Трафик на входе в OSPF домен "красится" определенным тегом и отбрасывается при попытке протиснутся обратно в EIGRP.

route-map FROM_OSPF_TO_EIGRP permit 10
 match ip address GREandSRV
!
route-map FROM_OSPF_TO_EIGRP deny 20
 match tag 400

3. Добавляем ключ route-map при редисрибуции в EIGRP.

router eigrp 90
 redistribute ospf 110 metric 1000 200 255 1 1500 route-map FROM_OSPF_TO_EIGRP

Теперь E7 знает только про нужные маршруты.

Фильтрация с помощью distribute-list

В distance-vector протоколах нет никаких там границ зон и прочей "чепухи", поэтому фильтровать маршруты можно прям на любых устройствах.

Как вы помните, R3 и R4 соединены одной общей сетью. Оба эти устройства сообщают об этой сети двум своим "хабам" в  RIP домене - R1 и R2.

Задача номер один. Мы хотим, чтобы R1 не балансировал трафик до R3 и R4, а посылал его только в сторону R3. Причем, по каким-то таинственным причинам, мы не будем тюнить метрику. Сейчас задача простая - R1 не должен знать о том, что за R4 находится сеть 10.20.34.0/32. 

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

Сделаем так, что бы R4 не рассказывал про сеть 10.20.34.0/30 R1. Создаем простой ACL, в котором фильтруем подсеть 10.20.34.0/30 и разрешаем все остальное. Далее, навешиваем это на интерфейс в сторону R1 в исходящем направлении.

access-list 1 deny   10.20.34.0 /30
access-list 1 permit any

router rip
 distribute-list 1 out Ethernet0/0

Далее, надо чуточку подождать, RIP штука небыстрая...

Теперь же попробуем применить направление in. Для этого взглянем, скажем, на E6. Он подключен двумя линками к EIGRP сети. Один из них serial, так что весь трафик "валит" через более приоритетный ethernet интерфейс. Например, трафик на 10.0.20.4/32.

Попробуем немного сбалансировать картину. Что если менеджмент трафик пустить в простаивающий на данный момент Serial1/0. Трафика там не много, как раз разгрузим Ethernet0/0. Весь менеджмент трафик представляет из себя трафик на адреса /32 (ну почти...).

На этот раз воспользуемся префикс-листом ниже. Первой строчкой запрещаем все адреса (0.0.0.0/0) с префиксами, которые больше или равны 32. По факту - только /32. Вторая строчка разрешает все префиксы от 0 до 32.

ip prefix-list ThirtyTwo seq 5 deny 0.0.0.0/0 ge 32
ip prefix-list ThirtyTwo seq 10 permit 0.0.0.0/0 le 32

Применяем 

router eigrp 90
 distribute-list prefix ThirtyTwo in Ethernet0/0

Т.е. мы просто игнорируем все /32 подсети через интерфейс Eth0/0. После этого весь такой трафик пойдет через оставшийся сериальный интерфейс. Ну кроме 10.0.30.5/32, тот вообще доступен через Ethernet0/1.

Фильтрация между областями

В OSPF также работает команда distribute-list, но работает только в направлении in. По сути, она просто не дает добавить определенные маршруты в таблицу маршрутизации. Причем в LSDB эти маршруты видны будут. Все это мы уже рассматривали.

Сейчас займемся фильтрацией LSA Type 3 и LSA Type 5.

Вот в этой части OSPF сети мы видим, что подсеть на O6 (10.16.0.0/16) будет доступна через два ABRa - О3 и О4.

Так, но не совсем. У нас же ещё и виртуальный линк настроен, поэтому LSA приходит ещё и напрямую от O6, но не суть. Скажем, мы не хотим, чтобы LSA Type 3 про 10.16.0.0/16 проходила через O4 в нулевую область. На О4 так же есть и вторая область, в ней мы ничего фильтровать не хотим.

Тут для меня всегда был не очень очевидный момент с направлениями IN и OUT.

Сейчас мы хотим отфильтровать LSA которые идут в сторону area0, значит конфигурировать будем её. IN означает, что мы будем фильтровать маршруты, которые уходят в эту область. A OUT - маршруты, которые приходят из этой области.

Например, команда
area 0 filter-list prefix 10.16_BLOCKING in
отфильтрует отсылку LSA в нулевую область но будет слать её в четвертую.

area 1 filter-list prefix 10.16_BLOCKING out
отфильтрует LSA на подходе, в таком случае ни area0, ни area 2 её не получат.

В любом случае, сначала создаем префикс лист.

O4(config)#ip prefix-list 10.16_BLOCKING seq 5 deny 10.16.0.0/16
O4(config)#ip prefix-list 10.16_BLOCKING seq 10 permit 0.0.0.0/0 le 32

Навешываем его в filter-list на направление in в area0.

O4(config)#router ospf 110
O4(config-router)#area 0 filter-list prefix 10.16_BLOCKING in

После чего в нулевой области LSA должен пропасть, а во второй нет. Но вторая область настроена как stub no-summary. Переконфигурируем её на обычную тупиковую.

O4(config)#router ospf 110
O4(config-router)#no area 2 stub
*Oct  4 18:44:29.906: %OSPF-5-ADJCHG: Process 110, Nbr 10.0.10.7 on Ethernet0/2 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
O4(config-router)#area 2 stub 

Проверяем и убеждаемся в том, что в нулевой области LSA нет.

А в четвертой есть

При использовании area 1 filter-list prefix 10.16_BLOCKING out, как я и говорил, LSA будет отсутствовать во всех областях.

Ура, я наконец-то покончил с большой темой по Advanced IGP. В следующем посте коротенько про VRF Lite и GRE Tunneling.

5. Advanced IGP routing  (IPv4)
- Configure authentication (plain-text, MD5)
- Configure Summarization
- Metris
- Load balancing (equal, unequal)
- Routing loops
- Advanced redistribution with filtering 

- VRF Lite
- GRE Tunneling

P.S.:
Для тех, кто дочитал до конца этот пост и читал недавний про смену работы. Работу я все же сменил. Пока все отлично, для меня приоткрылись двери "сесурити" и балансировщиков нагрузки. Будем грызть! Думаю, через некоторое время постараюсь написать пост про новую работу.

Спасибо за внимание.