Заметки к CCNP Route: OSPF часть 4

Фильтрация маршрутов (route filtering) в OSPF

OSPF поддерживает несколько способов фильтрации маршрутов, однако в отличии от EIGRP где суммирование маршрутов, так же как и фильтрация может осуществлятсья в любой точке сети, OSPF позволяет делать это на ABR и ASBR.

OSPF использует различную логику для маршрутизации внутри области и между областями. Если внутри области все маршрутизаторы имеют полное видение топологии области на основе LSA 1 и 2 типов, запускают алгоритм SPF и находят все возможные пути для известных подсетей, реализуя таким образом логику действия link-state протоколов маршрутизации, то в маршрутизации между областями используется логика distance-vector протоколов маршрутизации. Поясню: внутри области SPF подсчитывает лучший путь до каждого ABR. А для выбора пути до сети, которая лежит в другой области, просто берется метрика до ABR и добавляется к той, которую он анонсирует.

Так же стоит держать в голове факт того, что OSPF не анонсирует маршруты. Вместо них анонсируются LSA. Так что любая фильтрация, которая вам может понадобится, должна каким-то образом воздейстовать на передачу LSA. Все маршрутизаторы области обязаны иметь представление о топологии, что является фундаментальным требованием SPF. Это позволяет избежать петель маршрутизации. Именно поэтому мы и не можем фильтровать LSA с маршрутной информацией в рамках одной области.

С LSA 3 и 5 типов дело обстоит лучше из-за использование дистанционно-векторной логики. Это и позволяет фильтровать LSA 3 и 5 типа на ABR.

Стэнд для сегодняшней статьи будет выглядеть следующим образом:

Фильтрация LSA 3 типа с использованием prefix-list

Посмотрим на схему, а точнее на ту часть где area 1 присоединяется к backbone области посредству R2 и R3. Допустим перед нами стоит задача анонсировать 172.16.4.0/24 подсеть через R3, а остальные сети через R2, фактически запрещая им распространять LSA третьего типа c информацией о каких-либо сетях в backbone область. Делается это элементарно:

Rx(config)#router ospf #_num
Rx(config-router)# area #_num filter-list prefix LIST_NAME [ in | out ]

В prefix-list подсети с утверждением deny будут отфильтрованы. Осталось разобраться с in и out.

Ключ in указывает на то, что надо фильтровать определенные подсети, которые распространяются в указанную область (в нашем случае backbone), а out из указанной области (area 1). Для чего это сделано? Представим, что R2 и R3 являются ABR для еще одной области и нам нужно реализовать ту же логику фильтрации. Вместо того, чтобы городить несколько отдельных команд для каждой области с ключом in, можно резать все на входе ключем out и это будет справедливо для всех областей.

Займемся практикой и заодно отфильтруем /30 подсети:

R2(config)#ip prefix-list OSPF-FILTER deny 172.16.4.0/24
R2(config)#ip prefix-list OSPF-FILTER deny 0.0.0.0/0 ge 30 le 30
R2(config)#ip prefix-list OSPF-FILTER permit 0.0.0.0/0 le 32
R2(config-router)#area 1 filter-list OSPF-FILTER out

R3(config)#ip prefix-list OSPF-FILTER deny 0.0.0.0/0 ge 30 le 30
R3(config)#ip prefix-list OSPF-FILTER deny 172.16.1.0/24
R3(config)#ip prefix-list OSPF-FILTER deny 172.16.2.0/24
R3(config)#ip prefix-list OSPF-FILTER deny 172.16.3.0/24
R3(config)#ip prefix-list OSPF-FILTER permit 0.0.0.0/0 le 32
R3(config-router)#area 0 filter-list prefix OSPF-FILTER in

И посмотрим на результат до и после со стороны R7:

R7#sh ip ospf database
--- опущено ---
                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
172.16.1.0      2.2.2.2         1451        0x80000006 0x002146
172.16.1.0      3.3.3.3         1554        0x80000006 0x000360
172.16.2.0      2.2.2.2         1451        0x80000006 0x001650
172.16.2.0      3.3.3.3         1554        0x80000006 0x00F76A
172.16.3.0      2.2.2.2         1451        0x80000006 0x000B5A
172.16.3.0      3.3.3.3         1556        0x80000006 0x00EC74
172.16.4.0      2.2.2.2         1453        0x80000006 0x00FF64
172.16.4.0      3.3.3.3         1556        0x80000006 0x00E17E
172.17.1.0      1.1.1.1         1139        0x80000007 0x004FE3
172.17.2.0      1.1.1.1         1139        0x80000007 0x0044ED
172.17.3.0      1.1.1.1         1139        0x80000007 0x009394
192.168.1.0     2.2.2.2         1711        0x80000007 0x00D6E6
192.168.1.0     3.3.3.3         1556        0x80000006 0x001F91
192.168.2.0     2.2.2.2         1453        0x80000006 0x003281
192.168.2.0     3.3.3.3         1556        0x80000006 0x00AF0A
192.168.101.0   1.1.1.1         1139        0x80000007 0x00C264
192.168.102.0   1.1.1.1         1139        0x80000007 0x00B76E

R7#sh ip ospf database
--- опущено ---
                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
172.16.1.0      2.2.2.2         128         0x80000007 0x001F47
172.16.2.0      2.2.2.2         128         0x80000007 0x001451
172.16.3.0      2.2.2.2         128         0x80000007 0x00095B
172.16.4.0      3.3.3.3         259         0x80000007 0x00DF7F
172.17.1.0      1.1.1.1         1840        0x80000007 0x004FE3
172.17.2.0      1.1.1.1         1843        0x80000007 0x0044ED
172.17.3.0      1.1.1.1         1843        0x80000007 0x009394
192.168.101.0   1.1.1.1         1843        0x80000007 0x00C264
192.168.102.0   1.1.1.1         1843        0x80000007 0x00B76E

Easy as that.

OSPF route filtering с помощью distribute lists

В некоторых случаях вам нужно отфильтровать маршрут, но из-за дизайна области сделать это немного затруднительно. К примеру вам нужно отфильтровать маршрут в области с 5 маршрутизаторами таким образом, чтобы 2 из них ничего про него не знали. С помощью prefix lists такого, понятное дело, сделать не выйдет.

Distribute lists позволяют фильтровать маршруты после того как отработал механизм SPF, но до того как они попадут в таблицу маршрутизации.

Если вы помните в EIGRP можно было использовать ключи in и out с distribute lists, однако в OSPF имеет смысл только ключ in. Команда distribute-list должна указывать на ACL, prefix list или на route map, под фильтрацию попадают только маршруты с утверждением deny.

Отфильтруем на R7 маршруты до 192.168.102.0/30 сети:

R7#sh ip route 192.168.0.0 255.255.0.0 longer-prefixes
--- опущено ---
     192.168.20.0/29 is subnetted, 1 subnets
C       192.168.20.0 is directly connected, FastEthernet0/0
     192.168.102.0/30 is subnetted, 1 subnets
O IA    192.168.102.0 [110/74] via 192.168.20.1, 00:50:13, FastEthernet0/0
     192.168.101.0/30 is subnetted, 1 subnets
O IA    192.168.101.0 [110/74] via 192.168.20.1, 00:50:13, FastEthernet0/0
R7#conf t
R7(config)#ip prefix-list DERFILTER deny 192.168.102.0/30
R7(config)#ip prefix-list DERFILTER permit 0.0.0.0/0 le 32
R7(config)#router ospf 1
R7(config-router)#distribute-list prefix DERFILTER in
R7(config-router)#do sh ip route 192.168.0.0 255.255.0.0 lo
--- опущено --- 
     192.168.20.0/29 is subnetted, 1 subnets
C       192.168.20.0 is directly connected, FastEthernet0/0
     192.168.101.0/30 is subnetted, 1 subnets
O IA    192.168.101.0 [110/74] via 192.168.20.1, 00:00:12, FastEthernet0/0

Маршруты по умолчанию

Маршруты по умолчанию используются в двух случаях:

  • Нужно направить пакеты от маршрутизаторов на удаленных площадках в ядро сети.
  • Нужно рассказать о ASBR, у которых есть доступ в интернеты.

Сделать это командами area range и summary-address 0.0.0.0/0 больше нельзя, не смотря на то, что говорят в старых учебниках и пособиях.

R1(config-router)#area 1 range 0.0.0.0 0.0.0.0
OSPF: Cannot add this range as 0.0.0.0/0 represents default

Вместо этого рекомендуется использовать default-information originate:

R7(config-router)#router ospf 1
R7(config-router)#default-information originate

R1#sh ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "ospf 1", distance 110, metric 1, candidate default path
  Tag 1, type extern 2, forward metric 10
  Last update from 192.168.20.4 on FastEthernet0/0, 00:00:07 ago
  Routing Descriptor Blocks:
  * 192.168.20.4, from 7.7.7.7, 00:00:07 ago, via FastEthernet0/0
      Route metric is 1, traffic share count is 1
      Route tag 1

Тупиковые области

Как вы понимаете R4, R5, R6 совершенно не нужно знать о том, какие сети вообще существуют за пределами их областей, так как в любом случае весь трафик, который будет выходить за пределы области пойдет через ABR.

     172.17.0.0/24 is subnetted, 3 subnets
O       172.17.1.0 [110/11] via 172.17.3.2, 05:26:43, FastEthernet0/0
C       172.17.3.0 is directly connected, FastEthernet0/0
O       172.17.2.0 [110/11] via 172.17.3.2, 05:26:43, FastEthernet0/0
     172.16.0.0/24 is subnetted, 4 subnets
O IA    172.16.4.0 [110/85] via 192.168.101.2, 04:56:06, Serial1/0
O IA    172.16.1.0 [110/85] via 192.168.101.2, 04:56:06, Serial1/0
O IA    172.16.2.0 [110/85] via 192.168.101.2, 04:56:06, Serial1/0
O IA    172.16.3.0 [110/85] via 192.168.101.2, 04:56:07, Serial1/0
     192.168.20.0/29 is subnetted, 1 subnets
O IA    192.168.20.0 [110/74] via 192.168.101.2, 05:26:45, Serial1/0
     192.168.102.0/30 is subnetted, 1 subnets
O       192.168.102.0 [110/74] via 172.17.3.2, 05:26:45, FastEthernet0/0
     192.168.101.0/30 is subnetted, 1 subnets
C       192.168.101.0 is directly connected, Serial1/0
O*E2 0.0.0.0/0 [110/1] via 192.168.101.2, 00:05:00, Serial1/0

Не будет ли более разумно отдавать им маршрут по умолчанию на ABR? Для этого и существует механизм тупиковых областей. ABR больше не отправляют LSA 3 и 5 типов внутрь такой области, а вместо них отдают маршрут по умолчанию. В итоге получим:

  • ABR создают маршрут по умолчанию используя тип 3 LSA, в который помещается сеть 0.0.0.0/0 и рассылает это сообщение маршрутизаторам в тупиковой области.
  • ABR не передает LSA 5 типа в тупиковую область.
  • ABR может не передавать LSA 3 в тупиковую область.
  • Метрика такого маршрута равна 1 по умолчанию. Такое поведение можно изменить с помощью команды area #_num default-cost cost.
  • Маршрутизаторы внутри тупиковой области не занимаются редистрибуцией маршрутов, полученных из других источников в OSPF так как это требует LSA 5 типа.
  • Все маршрутизаторы тупиковой области должны быть сконфигурированы как stub маршрутизаторы. В противном случае соседство не будет сформировано.

Тупиковые области бывают 4 типов:

Тип Анонс LSA типа 3 от ABR в тупиковую область Анонс LSA тип 5 от ABR в тупиковую область Редистрибуция из других источников
Stub Да Нет Нет
Totally Stubby Нет Нет Нет
NSSA Да Нет Да
Totaly NSSA Нет Нет Да

Totally Stubby и Totally NSSA являются проприетрными расширениями протокола OSPF и поддерживаются только на Cisco ABR.

В итоге:

  • Для всех типов тупиковых областей ABRы фильтруют LSA 5 типа.
  • Если это totally области ABRы так же фильтруют LSA 3 типа.
  • Если это не totally области ABRы передают LSA 3 типа как обычно.
  • NSSA области позволяют занимать редистрибуцией информации из внеших источник с помощью LSA 7 типа. ABR конвертирует LSA тип 7 в 5.

Настройка Stubby областей:

Действие Шаги
Stubby Настроить каждый маршрутизатор в области с помощью area #_num stub
Totally Stubby ABR: area #_num stub no-summary
Все остальные маршрутизаторы в области: area #_num stub
Метрика маршрута по умолчанию Значение по умолчанию равно 1. На ABR можно изменить это поведение командой area #_num default-metric metric

Настройка NSSA областей:

Действие Шаги
NSSA Настроить каждый маршрутизатор в области с помощью area #_num nssa
Totally NSSA ABR: area #_num nssa no-summary
Все остальные маршрутизаторы в области, включая ASBR: area #_num nssa
Метрика маршрута из внешнего источника Задается при редистрибуции командой redistribute object metric #_num