Про виртуальные сети (часть 20). Ограничиваем таблицу маршрутизации VRF (часть 1)

Всем привет. Сегодня мы рассмотрим один из моментов, связанный с безопасностью виртуальных сетей, а именно как ограничить ресурсы маршрутизатора, предоставляемые клиенту. Ведь маршрутизатор один и его ресурсы не безграничны. А клиенту может понадобиться очень большая таблица маршрутизации. А может и попасться очень зловредный клиент (или просто неграмотный) и его сеть будет просто очень страшно флудить обновлениями маршрутов, фактически осуществляя DoS атаку.  Что же делать?

Ну, во-первых, можно вообще не предоставлять клиенту виртуальный маршрутизатор и ограничится L2 туннелем. В этом случае вся нагрузка по маршрутизации ложится на оборудование клиента и в задачу провайдера входит только передача пакетов из точки А в точку Б. Это подходит в том случае если клиенту нужно только объединение его частных сетей, а провайдеру вообще не нужно париться: порезал скорость и спи спокойно. Но очень часто этого будет недостаточно и виртуальный маршрутизатор все-таки придется предоставлять.

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

В-третьих, мы можем просто сказать виртуальному маршрутизатору: можешь записать в свою таблицу N маршрутов и все. Остальные побоку. В этом случае мы можем настраивать динамическую маршрутизацию и полностью забыть про этот виртуальный маршрутизатор? Почти, но не совсем. Рассмотрим этот способ поподробнее.

За основу возьмем сеть из предыдущей статьи.  Уберем все лишнее и настроим маршрутизацию между Yug, Vostok, Sever и Zapad с использованием BGP. Объединение подсетей клиента осуществляется с использованием GRE туннеля, маршрутизация OSPF. Схемa логической топологии приведена ниже.

L2VPN_Logic

Конечно, я не стал рисовать десятки или даже сотни клиентов. В этом нет необходимости.

Итак, идем на маршрутизатор Zapad, заходим в режим конфигурации виртуального маршрутизатора и пишем:

Zapad(config-vrf)#maximum routes 10 90 reinstall 90

Что же это значит? Это значит, что мы разрешаем инсталлировать в таблицу маршрутизации не более 10 маршрутов (следует помнить, что в это количество включены любые маршруты, в том числе и непосредственно подключенные сети) и просим сообщить о достижении 90-процентного порога заполнения таблицы маршрутизации. Reinstall 90 сообщает маршрутизатору о том, что после того, как было достигнуто максимальное количество маршрутов, новые маршруты можно добавлять не раньше, чем заполнение таблицы маршрутизации снизится до 90%.

Очень много букафф. Проверим, как это работает. Самый простой способ добавлять маршруты – добавлять loopback интерфейсы на маршрутизаторе клиента. Поскольку в конфигурации OSPF указано network 0.0.0.0 255.255.255.255, все новые подсети сразу будут анонсироваться соседям.

Смотрим таблицу маршрутизации при исходной конфигурации:

Zapad(config-vrf)#do sh ip route vrf Zapadd

10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C        10.0.0.1/32 is directly connected, Loopback0
C        10.1.10.0/30 is directly connected, Ethernet1/0
L        10.1.10.1/32 is directly connected, Ethernet1/0
O        10.2.10.0/30 [110/1010] via 172.16.0.1, 00:00:25, Tunnel0
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.16.0.0/30 is directly connected, Tunnel0
L        172.16.0.2/32 is directly connected, Tunnel0
192.168.10.0/32 is subnetted, 1 subnets
O        192.168.10.1 [110/11] via 10.1.10.2, 00:00:46, Ethernet1/0
192.168.20.0/32 is subnetted, 1 subnets
O        192.168.20.1 [110/1011] via 172.16.0.1, 00:00:46, Tunnel0

Мы видим, что 8 маршрутов уже присутствует. Поскольку мы установили лимит в 10 маршрутов, достичь его не составит труда. Идем на маршрутизатор D_Zapad и там добавляем loopback интерфейсы.

D_Zapad(config-if)#int lo1
D_Zapad(config-if)#ip addr 10.111.1.1 255.255.255.255
D_Zapad(config-if)#int lo2
D_Zapad(config-if)#ip addr 10.111.1.2 255.255.255.255

И очень скоро получаем на маршрутизаторе Zapad предупреждение:

*Feb 19 22:20:11.839: %IPRT-3-ROUTELIMITWARNING: IP routing table limit warning – Zapadd

Все правильно. Лимит мы еще не превысили. Превысили только указанный 90%-й порог, о чем и получили предупреждение. Идем дальше.

D_Zapad(config-if)#int lo3
D_Zapad(config-if)#ip addr 10.111.1.3 255.255.255.255

И теперь уже получаем не предупреждение, а сухую констатацию факта – лимит превышен.

*Feb 19 22:23:24.303: %IPRT-3-ROUTELIMITEXCEEDED: IP routing table limit exceeded — Zapadd

Проверяем таблицу маршрутизации виртуального маршрутизатора Zapadd:

Zapad#sh ip route vrf Zapadd

10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C        10.0.0.1/32 is directly connected, Loopback0
C        10.1.10.0/30 is directly connected, Ethernet1/0
L        10.1.10.1/32 is directly connected, Ethernet1/0
O        10.2.10.0/30 [110/1010] via 172.16.0.1, 00:09:46, Tunnel0
O        10.111.1.1/32 [110/11] via 10.1.10.2, 00:05:37, Ethernet1/0
O        10.111.1.2/32 [110/11] via 10.1.10.2, 00:04:42, Ethernet1/0
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.16.0.0/30 is directly connected, Tunnel0
L        172.16.0.2/32 is directly connected, Tunnel0
192.168.10.0/32 is subnetted, 1 subnets
O        192.168.10.1 [110/11] via 10.1.10.2, 00:15:14, Ethernet1/0
192.168.20.0/32 is subnetted, 1 subnets
O        192.168.20.1 [110/1011] via 172.16.0.1, 00:15:14, Tunnel0

Как мы видим, подсети 10.111.1.3/32 нет. Она не вписалась в лимит. Цель достигнута. Количество маршрутов ограничено, и теперь маршрутизатор, принимая решение о передаче пакета, не будет отвлекаться на маршруты сверх лимита. Но так ли уж все хорошо получилось? Давайте глянем непосредственно на OSPF процесс:

Zapad#sh ip ospf 2 rib topology
OSPF local RIB
Codes: * — Best, > — Installed in global RIB

*   10.0.0.1/32, Intra, cost 1, area 0, Connected
via 10.0.0.1, Loopback0
*   10.1.10.0/30, Intra, cost 10, area 0, Connected
via 10.1.10.1, Ethernet1/0
*>  10.2.10.0/30, Intra, cost 1010, area 0
via 172.16.0.1, Tunnel0
*>  10.111.1.1/32, Intra, cost 11, area 0
via 10.1.10.2, Ethernet1/0
*>  10.111.1.2/32, Intra, cost 11, area 0
via 10.1.10.2, Ethernet1/0
*   10.111.1.3/32, Intra, cost 11, area 0
via 10.1.10.2, Ethernet1/0
*   172.16.0.0/30, Intra, cost 1000, area 0, Connected
via 172.16.0.2, Tunnel0
*>  192.168.10.1/32, Intra, cost 11, area 0
via 10.1.10.2, Ethernet1/0
*>  192.168.20.1/32, Intra, cost 1011, area 0
via 172.16.0.1, Tunnel0

И что мы видим? 10.111.1.3/32 собственной персоной. Это говорит о том, что несмотря на то, что мы ограничили количество маршрутов, включаемых в таблицу маршрутизации, OSPF процесс по-прежнему продолжает принимать и обрабатывать LSA пакеты, на что тратит некоторую часть производительности всего маршрутизатора.

Вообще говоря, мы не можем запретить OSPF процессу принимать обновления: динамическая маршрутизация просто теряет смысл в этом случае. Не можем и ограничить хранимую OSPF топологию. Единственное, что возможно – ограничить количество принимаемых LSA пакетов в единицу времени.

Zapad(config)#router ospf 2 vrf Zapadd
Zapad(config-router)#max-lsa 10 80

По умолчанию временной интервал равен 5 минут. Т.е. в течении 5 минут будет принято и обработано не более 10 объявлений.

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

Это все, что касается ограничений применяемых к таблице маршрутизации, но не все, что качается защиты vrf от слишком большого количества маршрутов. Продолжение следует…

Аверьянов Кирилл
network-lab.ru

Как обычно, полные конфиги:
D_Vostok
D_Zapad
Sever
Vostok
Yug
Zapad


Комментарии:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Hide me
Получать регулярно свежие материалы, лабораторные и вебинары
Email Имя
Show me