Поднимаем упрощенную провайдерскую сеть дома

  • Tutorial
Изначально эта статья была дневником по лабораторной работе, которую я придумал сам для себя. Постепенно мне начало казаться, что данная информация может быть полезна кому-то еще. Поэтому я постарался преобразовать заметку в более-менее приличный вид, добавить описание некоторых команд и технологий.

В статье рассматривается построение простейшей сети с несколькими провайдерами и клиентами, в частности, такие технологии, как NAT, OSPF, BGP, MPLS VPN. Многое, естественно, будет не учтено. Например в статье почти нет описания проблем безопасности, т.к. на эту тему можно говорить бесконечно, а текст и так получается довольно объемным. QoS тоже оставлен в стороне, т.к. в лабораторных условиях его особо не проверишь.

По поводу целевой аудитории. Совсем новичкам в сетях статья, боюсь, будет непонятна. Людям, обладающим знаниями хотя бы на уровне CCNP – неинтересна. Поэтому я примерно ориентируюсь на сертификацию CCNA R&S.

Лабораторная построена на эмуляторе Cisco IOU. По поводу его установки и использования написано уже много чего, так что повторяться не буду.

Используются образы i86bi_linux-adventerprisek9-ms.152-4.M1 и i86bi_linux_l2-ipbasek9-ms.jan24-2013-B

Определимся с топологией и IP-адресацией.

После некоторых раздумий я решил сделать такую схему:

Теперь осталось придумать легенду:

  1. AS1234 – крупный провайдер ISP1. Владеет сетью 50.0.0.0/16.
  2. AS67 – провайдер ISP2. Владеет сетью 100.0.0.0/16. Нужен для внесения дополнительной сложности в топологию.
  3. AS812 – клиент Customer1. Владеет блоком PI-адресов IPv4 175.0.0.0/24, но внутри своей сети использует исключительно IPv6.
  4. AS65000 – клиент Customer2. Получает от провайдера блок адресов 50.0.109.0/24. Внутри сети использует приватные адреса из подсети 192.168.109.0/24. AS65000 — приватная.
  5. AS1114 – клиент Customer3. Владеет блоком PI-адресов 150.0.0.0/24. Их же и использует для внутренних нод.

Для простоты на p2p линках между маршрутизаторами в разных AS будем использовать адреса вида 200.0.xy.0/24, где x,y – номера маршрутизаторов, x>y.

p2p линки внутри провайдеров также будут иметь маску /24 (понятно, что это расточительство, но так будет значительно проще настраивать маршрутизацию) и вид 50.0.xy.0 (100.0.xy.0 для AS67), где x,y – номера маршрутизаторов, x>y.

Первоначальная настройка


Базовая конфигурация

Для начала зальем на все маршрутизаторы примерно одинаковую конфигурацию (пример для R2):
enable 
configure terminal 

Включаем aaa и настраиваем возможность заходить на маршрутизатор удаленно с локальными реквизитами:
aaa new-model 
aaa authentication login default local 
username cisco privilege 15 secret cisco 
no ip domain-lookup 

Прописываем все необходимое для ssh v1.99 и разрешаем только его в параметрах линии:
ip domain-name isp1.com 
hostname R2 
crypto key generate rsa modulus 2048 
line console 0 
exec-timeout 0 
line vty 0 4 
transport input ssh 
exec-timeout 0 

На каждом маршрутизаторе создадим несколько loopback'ов. lo0 для протоколов маршрутизации, остальные для имитации клиентских подключений, чтобы RIB не выглядела слишком маленькой. Понятно, что если провайдер владеет подсетью 50.0.0.0/16, он не имеет никакого права анонсировать, например, подсеть 2.0.0.0/24, но для наглядности мы сделаем допущение, что такая ситуация возможна:
interface loopback 0 
ip address 2.2.2.2 255.255.255.255 
interface loopback 1 
ip address 2.0.0.2 255.255.255.0 
interface loopback 2 
ip address 2.0.1.2 255.255.255.0 
interface loopback 3 
ip address 2.0.2.2 255.255.255.0 
interface loopback 4 
ip address 2.0.3.2 255.255.255.0 

Присвоим адреса и отключим CDP на тех интерфейсах, которые смотрят не на соседний по AS маршрутизатор:
interface ethernet 0/0 
ip address 200.0.62.2 255.255.255.0 
no cdp enable 
no shutdown 
interface ethernet 0/1 
ip address 50.0.32.2 255.255.255.0 
no shutdown 
interface ethernet 0/2 
ip address 200.0.72.2 255.255.255.0 
no cdp enable 
no shutdown 
interface ethernet 0/3 
ip address 50.0.52.2 255.255.255.0 
no shutdown 

end 
write 

Теперь необходимо настроить наших клиентов.

HSRP, Stateful NAT

Начнем с AS65000. Из нее подсеть 192.168.109.0/24 будет транслироваться в блок адресов 50.0.109.0/24, выданный провайдером. При этом автономная система подключена к одному ISP через два маршрутизатора, поэтому для обеспечения избыточности на них необходимо будет настроить HSRP. В связи с этим при использовании обычного NAT может возникнуть проблема ассиметричного роутинга:

  1. Приватный адрес транслируется в публичный на одном из маршрутизаторов.
  2. Ответ приходит на второй маршрутизатор.
  3. У второго маршрутизатора правило трансляции для данного пакета отсутствует, так что он просто отбросит пакет.
  4. Для решения данной проблемы официальный сайт Cisco предлагает использовать Stateful NAT.


Для начала настроим HSRP (конфиг на R10).

У больших компаний редко бывает всего один VLAN, так что все настройки будем делать на сабинтерфейсе для 109 VLAN'а:

Создаем HSRP группу:
R10(config)#interface ethernet 0/1.109
R10(config-subif)#encapsulation dot1Q 109 
R10(config-subif)#ip address 192.168.109.10 255.255.255.0 
R10(config-subif)#standby 109 ip 192.168.109.109
R10(config-subif)#standby 109 preempt
R10(config-subif)#standby 109 name SNAT 

Сконфигурируем ACL и NAT pool для Stateful NAT точно так же, как и для обычного (длина маски 25, а не 24, т.к. решено было оставить половину подсети для других нужд, здесь не рассматриваемых):
R10(config)#ip access-list standard SNAT_INSIDE
R10(config-std-nacl)#permit 192.168.109.0 0.0.0.255 
R10(config)#ip nat pool SNAT_OUTSIDE 50.0.109.1 50.0.109.126 prefix-length 25 

Настроим непосредственно Stateful NAT:
R10(config)#ip nat stateful id 109 
R10(config-ipnat-snat)#redundancy SNAT 
R10(config-ipnat-snat-red)#protocol udp
R10(config-ipnat-snat-red)#mapping-id 109 
R10(config)#ip nat inside source list SNAT_INSIDE pool SNAT_OUTSIDE mapping-id 109 overload

И включим его на интерфейсах:
R10(config)#interface ethernet 0/0
R10(config-if)#ip nat outside

R10(config)#interface ethernet 0/1.109
R10(config-subif)#ip nat inside

На eth 0/2 применим для того, чтобы в случае, если пакет придет на R10, а R5 не будет доступен, адрес все-таки транслировался и доходил до места назначения:
R10(config)#interface ethernet 0/2
R10(config-if)#ip nat outside

Можно сделать по другому – применить не ip nat outside на eth0/2 маршрутизатора R10, а ip nat inside на eth0/1 маршрутизатора R9. Результат будет абсолютно одинаковым, главное – понимать, зачем это делается и как работает.

На R9 конфигурация аналогичная.

Конфигурация SW13 не приводится ввиду ее простоты. Интерфейсы, смотрящие на маршрутизаторы сделаем транками с инкапсуляцией в 109 VLAN. Также настроим интерфейс в 109 VLAN'e для проверки нашего решения.

После этого можно для теста поднять маршрутизацию на роутерах R3, R4, R5, R9 и R10 таким образом, чтобы пинг пошел по данному пути:


SW13#ping 3.3.3.3 
Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/6 ms 

R9#sh ip nat translations 
Pro Inside global      Inside local       Outside local      Outside global 
icmp 50.0.109.4:35     192.168.109.13:35  3.3.3.3:35         3.3.3.3:35 
--- 50.0.109.4         192.168.109.13     ---                --- 

R10#sh ip nat translations 
Pro Inside global      Inside local       Outside local      Outside global 
icmp 50.0.109.4:35     192.168.109.13:35  3.3.3.3:35         3.3.3.3:35 
--- 50.0.109.4         192.168.109.13     ---                --- 

Как мы видим, информация синхронизировалась между двумя HSRP маршрутизаторами, и при ассиметричном роутинге пинг прошел обратно через тот маршрутизатор, который не осуществлял прямую трансляцию адреса.

IPv6, NAT-PT

Теперь обратимся к AS812. Напомним, что местные инженеры активно внедряют инновации, поэтому вся внутренняя сеть построена на протоколе IPv6. Тем не менее провайдер, к которому подключена данная компания даже не слышал про существование IPv6, поэтому придется использовать на пограничном маршрутизаторе NAT-PT (Protocol Translation).

Данная технология, как это понятно из названия, позволяет осуществлять трансляцию из одного сетевого протокола в другой, и, соответственно, общаться хостам, поддерживающим только IPv6 или только IPv4, друг с другом.


Если мы попробуем сделать это без трансляции, то получим примерно такое сообщение:
SW12#ping 200.0.86.6
% Unrecognized host or address, or protocol not running. 

Определимся с адресацией: предположим, что используется одна большая подсеть 2001:0:0:812::/64

Тогда адрес интерфейса eth0/1 на R8 будет 2001:0:0:812::8/64.

Включаем маршрутизацию пакетов IPv6:
R8(config)#ipv6 unicast-routing 

Задаем IPv6 адрес:
R8(config)#interface ethernet 0/1 
R8(config-if)#ipv6 address 2001:0:0:812::8/64

Включаем NAT на интерфейсах:
R8(config)#interface range eth 0/0-2 
R8(config-if-range)#ipv6 nat

Создаем пул IPv4, в который будут транслироваться наши внутренние IPv6 адреса:
R8(config)#ipv6 nat v6v4 pool 6TO4 175.0.0.1 175.0.0.254 prefix-length 24 

ACL, содержащий префикс, при вводе которого перед IPv4 адресом, мы сообщим маршрутизатору, что нам необходима трансляция:
R8(config)#ipv6 access-list v6LIST 
R8(config-ipv6-acl)#permit ipv6 any 4::/96 

Применяем этот ACL:
R8(config)#ipv6 nat prefix 4::/96 v4-mapped v6LIST

И, собственно, включаем NAT-PT:
R8(config)#ipv6 nat v6v4 source list v6LIST pool 6TO4 overload

Обратите внимание, что длина префикса составляет 96 бит. Если учесть, что суммарная длина IPv6 адреса 128 бит, получаем в остатке 32 бита, что равно длине IPv4 адреса.

Проверяем. Временно создадим на R6 и на R8 необходимые маршруты и попробуем пропинговать R6 с коммутатора SW12:
SW12#ping 4::200.0.86.6 
Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 4::C800:5606, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/3 ms 

Как мы видим, технология работает. Для того, чтобы выделенная подсеть 175.0.0.0/24 не пропадала зря (все-таки крайне глупо покупать PI-адреса и использовать их только для динамического NAT'a) можно было бы сконфигурировать статические трансляции v6v4 и v4v6, чтобы, например, внутренний сервер имеющий адрес IPv6 был доступен из внешней сети по IPv4 адресу. Тем не менее этого мы делать не будем.

Больше, в данный момент, у клиентов настраивать особо нечего, так что можно перейти к настройке маршрутизации.

OSPF, настройка маршрутизации внутри автономной системы


Начнем с IGP, в частности с протокола OSPF. EIGRP рассматривать не будем, т.к. на таких небольших сетях принципиальных отличий в конфигурации немного.

В сети провайдера ISP1 все роутеры кроме R1 соединены по принципу “каждый с каждым”. Так как R1 подключен только одним линком, имеет смысл вынести его в отдельную totally stubby area (т.е. отдавать R1 только маршрут по умолчанию на R3).

Приведем пример настройки OSPF на R3:
R3(config)#router ospf 1234 
R3(config-router)#router-id 3.3.3.3

По умолчанию запретим всем интерфейсам участвовать в OSPF процессе, а затем включим только нужные (конкретно на R3 данные команды не имеют абсолютно никакого смысла, т.к. все его интерфейсы будут задействованы):
R3(config-router)#passive-interface default 
R3(config-router)#no passive interface e0/1
R3(config-router)#no passive interface e0/2
R3(config-router)#no passive interface e0/3
R3(config-router)#no passive interface e0/4

Следующая команда дает возможность при изменении карты сети запускать процесс SPF только частично, для отдельной ветви дерева, что в больших сетях может несколько уменьшить время сходимости топологии:
R3(config-router)#ispf 

Добавляем сеть в тупиковый регион и конфигурируем сам регион:
R3(config-router)#network 50.0.31.0 0.0.0.255 area 1234
R3(config-router)#area 1234 stub no-summary

Добавляем подсети из магистрального региона:
R3(config-router)#network 50.0.32.0 0.0.0.255 area 0 
R3(config-router)#network 50.0.43.0 0.0.0.255 area 0 
R3(config-router)#network 50.0.53.0 0.0.0.255 area 0 

Можно, конечно, анонсировать и так:
R3(config-router)#network 50.0.0.0 0.0.255.255 area 0 

но:

  • Есть шанс случайно захватить лишнюю подсеть;
  • При удалении одной из суммаризованных подсетей могут возникнуть проблемы;
  • Это в принципе дает меньше контроля над ситуацией и повышает риск ошибки.

Также можно объявлять принадлежность подсети к процессу ospf непосредственно на интерфейсе (и это единственный путь в IPv6), но используемый мной способ банально быстрее (на мой взгляд), да и нагляднее, когда вся конфигурация, связанная с определенным протоколом хранится в одном месте.

Сети с loopback'ов добавим командой redistribute connected. Делать это надо аккуратно, потому что всегда есть риск объявить что-то, что объявлять бы не хотелось. Поэтому воспользуемся route-map'ом, чтобы установить четкие ограничения:
R3(config)#ip access-list standard REDISTRIBUTE_CONNECTED 
R3(config-std-nacl)#permit host 3.3.3.3 
R3(config-std-nacl)#permit 3.0.0.3 0.0.0.255 
R3(config-std-nacl)#permit 3.0.1.3 0.0.0.255 
R3(config-std-nacl)#permit 3.0.2.3 0.0.0.255 
R3(config-std-nacl)#permit 3.0.3.3 0.0.0.255 
 
R3(config)#route-map REDISTRIBUTE_CONNECTED 
R3(config-route-map)#match ip address REDISTRIBUTE_CONNECTED 

R3(config-router)#redistribute connected route-map REDISTRIBUTE_CONNECTED subnets 

Вообще route-map – крайне гибкая и удобная технология, которая позволяет творить с подсетями практически все что угодно: суммаризовать, вешать различные теги, метки, менять всевозможные параметры, пути следования пакетов, etc. В секции про настройку BGP я затрону route-map'ы чуть более детально.

Остановимся подробнее на том, чем еще выделяется команда redistribute:
R5(config)#do sh ip route 
-----------------------------------------------------------------
      3.0.0.0/8 is variably subnetted, 5 subnets, 2 masks 
O E2     3.0.0.0/24 [110/20] via 50.0.53.3, 00:19:17, Ethernet0/0 
O E2     3.0.1.0/24 [110/20] via 50.0.53.3, 00:19:07, Ethernet0/0 
O E2     3.0.2.0/24 [110/20] via 50.0.53.3, 00:19:07, Ethernet0/0 
O E2     3.0.3.0/24 [110/20] via 50.0.53.3, 00:19:07, Ethernet0/0 
O E2     3.3.3.3/32 [110/20] via 50.0.53.3, 00:19:37, Ethernet0/0 
-----------------------------------------------------------------
O        50.0.32.0/24 [110/20] via 50.0.53.3, 00:21:43, Ethernet0/0 
O        50.0.43.0/24 [110/20] via 50.0.53.3, 00:21:43, Ethernet0/0 

Если мы внимательно посмотрим на таблицу маршрутизации, то увидим, что подсети, созданные командой redistribute connected помечены, как внешние для этой AS маршруты, в отличие от тех, которые добавлены командой network. Соответственно R3 становится ASBR (Autonomous System Boundary Router), хотя по факту им не является.

Также при типе маршрута E2 (а данная метка ставится по умолчанию) метрика не будет пересчитываться, как это обычно происходит в процессе SPF (то есть при увеличении длины пути до подсети стоимость линков учитываться не будет).

Избежать этого можно так:
R3(config-router)#redistribute connected route-map REDISTRIBUTE_CONNECTED subnets metric-type 1

Вернемся к R1. После конфигурации area 1234 как totally stubby в таблице маршрутизации мы увидим только один маршрут, пришедший по OSPF. Как и ожидалось – это default gateway:
R1(config-router)#do sh ip route 
--------------------------------------------------------------
Gateway of last resort is 50.0.31.3 to network 0.0.0.0 

O*IA  0.0.0.0/0 [110/11] via 50.0.31.3, 00:00:00, Ethernet0/1 
-------------------------------------------------------------

Все остальные маршрутизаторы в лабораторной настраиваются примерно одинаково, так что нет смысла заострять на них внимание.

BGP, настройка маршрутизации между автономными системами


Недавно на собеседовании в одном крупном и известном интеграторе мне задали вопрос: “Зачем вообще нужны IGP, когда у нас есть iBGP?”. Ответ про ужасную скорость сходимости протокола по сравнению с IGP, необходимость топологии full-mesh (или Route Reflector), повышенные требования к ресурсам каждого маршрутизатора в топологии их не удовлетворил.

Только выйдя из переговорной я вспомнил, что BGP не будет помещать в RIB маршруты, для которых next-hop недоступен.

Соответственно, без IGP с внутренних маршрутизаторов мы не сможем достучаться до next-hop (который, как правило, является адресом eBGP пира, не присоединенного непосредственно) и маршрутизации у нас не получится. Думаю, что от меня хотели услышать именно это. К слову, должность мне все-таки предложили, но это уже совсем другая история.

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

Для того, чтобы достучаться до соседнего loopback для eBGP пиров нам бы потребовались следующие действия:

  1. Static route на loopback соседа;
  2. redistribute static в OSPF (можно обойтись без этого, если на всех iBGP пирах делать команду next-hop self, но мне как-то не очень нравится так делать);
  3. Команда neighbor n.n.n.n ebgp-multihop 2 для того, чтобы увеличить ttl служебных BGP пакетов (по умолчанию равен 1);
  4. Команда neighbor n.n.n.n update-source lo0.

Чтобы сократить конфигурацию будем использовать:

  • loopback адреса для коммуникации между iBGP пирами (это действительно имеет смысл, т.к. даже при падении одного из линков TCP-сессия останется живой благодаря избыточным соединениям);
  • адреса на физических интерфейсах для eBGP пиров
.
Настроим BGP в автономной системе 1234.

Для начала небольшой чек-лист:

  1. prefix-list, фильтрующий приватные сети;
  2. prefix-list, фильтрующий p2p-линки;
  3. prefix-list, фильтрующий адреса на lo0;
  4. prefix-list, фильтрующий адреса, анонсируемые соседней AS;
  5. route-map для соседа;
  6. route-map для анонса connected сетей (если вдруг мы не захотим анонсировать их командой network);
  7. непосредственно конфигурация BGP;

Атрибут community использовать не будем. В данном случае сеть небольшая, пиринговых войн не предвидится, DDOS получить неоткуда, поэтому путаницы от community, на мой взгляд, будет больше, чем пользы.

Зачем вообще мы делаем фильтрацию? Затем, что если клиент неадекватен и вдруг решит анонсировать все, что ему захочется (в нашем случае AS65000 попробует поступить именно так), провайдер ОБЯЗАН пресечь данные действия со своей стороны.

Пойдем по списку. Для примера будем настраивать R4:

1) Т.к. это всего лишь лабораторная, будем фильтровать не все сети, а только 3 самых известных (существует еще куча зарезервированных под разные нужды префиксов, например 127.0.0.0/8):
R4(config)#ip prefix-list PRIVATE_IP permit 10.0.0.0/8 le 32 
R4(config)#ip prefix-list PRIVATE_IP permit 172.16.0.0/12 le 32 
R4(config)#ip prefix-list PRIVATE_IP permit 192.168.0.0/16 le 32

2) p2p линки между маршрутизаторами внутри автономной системы, на мой взгляд, информация, которую незачем оглашать, так что лучше оставим ее внутри AS:
R4(config)#ip prefix-list P2P permit 50.0.31.0/24 le 32
R4(config)#ip prefix-list P2P permit 50.0.32.0/24 le 32 
R4(config)#ip prefix-list P2P permit 50.0.43.0/24 le 32
R4(config)#ip prefix-list P2P permit 50.0.52.0/24 le 32
R4(config)#ip prefix-list P2P permit 50.0.53.0/24 le 32
R4(config)#ip prefix-list P2P permit 50.0.54.0/24 le 32

3) Наши lo0 адреса также не должны маршрутизироваться, т.к. таким образом мы можем навредить реальному хосту 1.1.1.1, или, например, сделать недоступным DNS-сервер google с адресом 8.8.8.8 (на самом деле не можем, уже давно все провайдеры фильтруют сети с маской /25 и больше).
R4(config)#ip prefix-list LOOPBACK permit 1.1.1.1/32
R4(config)#ip prefix-list LOOPBACK permit 2.2.2.2/32
R4(config)#ip prefix-list LOOPBACK permit 3.3.3.3/32
R4(config)#ip prefix-list LOOPBACK permit 4.4.4.4/32
R4(config)#ip prefix-list LOOPBACK permit 5.5.5.5/32

4) Наша соседняя AS65000 транзитной не является, следовательно не может анонсировать ничего, кроме выданной ей подсети 50.0.109.0/24. Проконтролируем это:
R4(config)#ip prefix-list ADVERTISED permit 50.0.109.0/24 le 32

На этом закончим с фильтрацией. Я никогда (на момент написания этой части статьи) не работал в ISP, но у меня есть очень сильное подозрение, что у них в BGP фильтруется в несколько раз больше маршрутов, и цели для этого могут быть самыми разными.

5) Пришло время настроить route-map. Так как в префикс листах мы писали “permit”, сейчас мы будем писать “deny”.

Фильтрация исходящего трафика:
R4(config)#route-map AS65000_OUT deny 10
R4(config-route-map)#match ip address prefix-list LOOPBACK 
R4(config-route-map)#match ip address prefix-list P2P 
R4(config-route-map)#match ip address prefix-list PRIVATE_IP

R4(config)#route-map AS65000_OUT permit 20

Фильтрация входящего трафика:
R4(config)#route-map AS65000_IN
R4(config-route-map)#match ip address prefix-list ADVERTISED

R4(config)#route-map AS65000_IN deny 20

6) На R4 будем добавлять connected сети 4.0.0.0/24 – 4.0.3.0/24 суммаризованными в одну подсеть 4.0.0.0/22. Сделать это можно несколькими способами, покажем один из них:
R4(config)#ip access-list standard REDISTRIBUTE_CONNECTED 
R4(config-std-nacl)#permit 4.0.0.0 0.0.3.255 

R4(config)#route-map REDISTRIBUTE_CONNECTED 
R4(config-route-map)#match ip address REDISTRIBUTE_CONNECTED 

R4(config-route-map)#router bgp 1234 
R4(config-router)#redistribute connected route-map REDISTRIBUTE_CONNECTED

На этом этапе мы получаем такой вывод #sh ip bgp:
R4(config-router)#do sh ip bgp
-------------------------------------------------------------------
     Network          Next Hop            Metric LocPrf Weight Path 
 *>  4.0.0.0/24       0.0.0.0                  0         32768 ? 
 *>  4.0.1.0/24       0.0.0.0                  0         32768 ? 
 *>  4.0.2.0/24       0.0.0.0                  0         32768 ? 
 *>  4.0.3.0/24       0.0.0.0                  0         32768 ? 

Теперь делаем
R4(config-router)#aggregate-address 4.0.0.0 255.255.252.0 summary-only 

и видим следующий вывод:
R4(config-router)#do sh ip bgp 
-------------------------------------------------------------------
     Network          Next Hop            Metric LocPrf Weight Path 
 s>  4.0.0.0/24       0.0.0.0                  0         32768 ? 
 *>  4.0.0.0/22       0.0.0.0                            32768 i 
 s>  4.0.1.0/24       0.0.0.0                  0         32768 ? 
 s>  4.0.2.0/24       0.0.0.0                  0         32768 ? 
 s>  4.0.3.0/24       0.0.0.0                  0         32768 ? 

Все маршруты, кроме суммарного, помечены буквой “s” — suppressed, что значит подавленные. Анонсироваться они не будут. Если бы мы по каким то причинам ввели команду aggregate-address без ключевого слова summary-only, то анонсировались бы и суммаризованная подсеть, и каждая из /24 по отдельности.

7) Пришло время непосредственной настройки процесса BGP, установления соседских отношений и конфигурации прочих параметров, описывающих общий характер работы протокола:
R4(config)#router bgp 1234 
R4(config-router)#bgp router-id 4.4.4.4 

R4(config-router)#neighbor 3.3.3.3 remote-as 1234 
R4(config-router)#neighbor 3.3.3.3 update-source lo0 

R4(config-router)#neighbor 5.5.5.5 remote-as 1234 
R4(config-router)#neighbor 5.5.5.5 update-source lo0 

R4(config-router)#neighbor 200.0.94.9 remote-as 65000

Применим ранее сконфигурированные route-map на соседа:
R4(config-router)#neighbor 200.0.94.9 route-map AS65000_IN in 
R4(config-router)#neighbor 200.0.94.9 route-map AS65000_OUT out 


Теперь настало время настроить R3.

Пропустим все пункты про фильтрацию, т.к. у R3 нет eBGP пиров. Вместо этого сконфигурируем R3 как Route Reflector. Дело в том, что iBGP пиры при получении маршрута не отправляют его дальше. Таким образом у нас обязательно должна быть full-mesh топология, чтобы, например, R4 мог получить маршруты с R2.

Посмотрев на нашу топологию можно заметить, что до full-mesh она немного не дотягивает. Поэтому придется использовать Route Reflector, чтобы все iBGP пиры выучили все iBGP маршруты.

Так как соседей у нас целых 3, имеет смысл конфигурировать их с помощью peer-group:
R3(config-router)#neighbor LOCAL peer-group 
R3(config-router)#neighbor LOCAL remote-as 1234 

R3(config-router)#neighbor 2.2.2.2 peer-group LOCAL 
R3(config-router)#neighbor 4.4.4.4 peer-group LOCAL 
R3(config-router)#neighbor 5.5.5.5 peer-group LOCAL 

R3(config-router)#neighbor LOCAL update-source lo0 

Настроим номер группы для Route Reflector (следует уделять этому особое внимание, если кластеров планируется сделать несколько):
R3(config-router)#bgp cluster-id 1 

И сделаем всех наших соседей клиентами:
R3(config-router)#neighbor LOCAL route-reflector-client 

Обратите внимание, что на самих клиентах настраивать ничего не нужно, достаточно указать RR-соседа как обычный iBGP пир.

Также покажем на R3 второй способ суммаризации подсетей.

Создаем суммарный маршрут на null 0 (напомним, что если маршрута нет в RIB, BGP не будет анонсировать его):
R3(config)#ip route 3.0.0.0 255.255.252.0 null 0 

И просто добавляем его в BGP:
R3(config-router)#network 3.0.0.0 mask 255.255.252.0 

Как мы видим, суммаризованная сеть присутствует в таблице BGP и анонсируется. Также мы уже получили от R4 его суммаризованную сеть 4.0.0.0/22:
R3(config-router)#do sh ip bgp 
------------------------------------------------------------------- 
     Network          Next Hop            Metric LocPrf Weight Path 
 *>  3.0.0.0/22       0.0.0.0                  0         32768 i 
 *>i 4.0.0.0/22       4.4.4.4                  0    100      0 i 

Какой способ суммаризации лучше – судить не мне, но тот, который мы применяли на R4 однозначно гибче в настройке, поэтому я предпочитаю использовать именно его.

Как мы помним R1 соединен только с R3 и не использует BGP, так что на R3 нам надо анонсировать и сеть 50.0.254.0/24 с R1, чтобы она тоже была доступна. Сделаем это самым простым образом:
R3(config-router)#network 50.0.254.0 mask 255.255.255.0

Казалось бы все должно пройти отлично, маршрут анонсируется, но посмотрим на R4:
R4(config-router)#do sh ip bgp 
     Network          Next Hop            Metric LocPrf Weight Path 
-------------------------------------------------------------------
 r>i 50.0.254.0/24    50.0.31.1               20    100      0 i 
-------------------------------------------------------------------

Мы поймали RIB-failure. На самом деле абсолютно ничего страшного не случилось. Есть несколько причин по которым может появиться RIB-failure. В данном случае это произошло потому, что в RIB на R4 уже есть маршрут с лучшей AD (полученный через OSPF) до данного префикса. Будет ли этот маршрут анонсироваться в другие AS? Ответ – да, будет, волноваться не о чем.

Например на R9 (если предположить, что BGP там уже настроен):
R9(config)#do sh ip bgp 
---------------------------------------------------------------------
     Network          Next Hop            Metric LocPrf Weight Path 
 *>  3.0.0.0/22       200.0.94.4                             0 1234 i 
 *>  4.0.0.0/22       200.0.94.4               0             0 1234 i 
 *>  50.0.109.0/24    0.0.0.0                  0         32768 i 
 *>  50.0.254.0/24    200.0.94.4                             0 1234 i 
---------------------------------------------------------------------

Кстати говоря, раз уж получилось так, что BGP на R9 уже работает, попробуем чисто ради интереса проанонсировать серую подсеть 192.168.109.0/24 и посмотреть, отработает ли фильтрация на R4:
R4#debug ip bgp 200.0.94.9 updates 

R9(config-router)#network 192.168.109.0 mask 255.255.255.0 

R4# 
*Nov 28 22:13:31.004: BGP(0): 200.0.94.9 rcvd UPDATE w/ attr: nexthop 200.0.94.9, origin i, metric 0, merged path 65000, AS_PATH 
*Nov 28 22:13:31.004: BGP(0): 200.0.94.9 rcvd 192.168.109.0/24 -- DENIED due to: route-map; 

Как мы видим, R4 попытался получить обновление, но route-map отработал как надо.

К слову, на R9 и R10 ничего фильтровать не будем, переложим эти заботы на провайдера. Предположим, что местные инженеры не обладают достаточной квалификацией (на самом деле мне просто лень, к тому же я обещал, что AS65000 особой адекватностью отличаться не будет).

На R5 и R2 добавим еще одну необходимую нам команду в стандартную конфигурацию BGP:
R5(config-router)#neighbor 200.0.115.11 remove-private-as

Таким образом мы уберем из анонса приватную AS. Посмотрим, как теперь будет выглядеть путь к подсети 50.0.109.0/24 (префикс из приватной AS 65000) для маршрутизатора R11:
R11(config-router)#do sh ip bgp 
---------------------------------------------------------------------
    Network          Next Hop            Metric LocPrf Weight Path 
 *>  3.0.0.0/22       200.0.115.5                            0 1234 i 
 *>  4.0.0.0/22       200.0.115.5                            0 1234 i 
 *>  5.0.0.0/24       200.0.115.5              0             0 1234 i 
 *>  5.0.1.0/24       200.0.115.5              0             0 1234 i 
 *>  5.0.2.0/24       200.0.115.5              0             0 1234 i 
 *>  5.0.3.0/24       200.0.115.5              0             0 1234 i 
 *>  50.0.109.0/24    200.0.115.5                            0 1234 i 
 *>  50.0.254.0/24    200.0.115.5                            0 1234 i 
---------------------------------------------------------------------

В столбце path для интересующего нас префикса указана только одна AS – 1234, следовательно наша задумка удалась, и приватная AS65000 не отображается.

Кстати говоря, фильтрация на R11 просто жизненно необходима. Дело в том, что AS1114 подключена сразу к двум ISP, но транзитной не является (судя по вики такие AS называются многоинтерфейсными). Поэтому, если вдруг какой-то трафик, не относящийся к этой AS пройдет через нее, плохо будет всем:

  • провайдерам, т.к. каналы скорее всего имеют не очень большую пропускную способность, следовательно часть пакетов будет теряться;
  • компании владеющей AS, т.к. ее аплинки будут забиты чужим, абсолютно неинтересным ей трафиком.

Как делать фильтрацию на R11 показывать не буду, концептуально этот процесс не отличается от уже описанного. Скажу только, что там будет присутствовать такая команда:
R11(config)#ip prefix-list OUTBOUND permit 150.0.0.0/24 le 32 

Немного по поводу того, почему везде используются префикс-листы, а не ACL:

  • Одним префикс-листом мы можем отфильтровать сразу все подсети данной сети (например команда чуть выше фильтрует не только /24 маску, но и всевозможные /25, /26, etc...);
  • Я смутно помню, как читал статью, где рассказывалось, что у prefix-list древовидная структура в отличие от ACL, соответственно маршрутизатору требуется несколько меньше ресурсов для лукапа (возможно неправда, полагаюсь на память, статью найти не могу).

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

При полностью настроенной маршрутизации sh ip bgp на R8 выглядит так:
sh ip bgp
R8(config-router)#do sh ip bgp 
------------------------------------------------------------------------ 
     Network          Next Hop            Metric LocPrf Weight Path 
 *   2.0.0.0/24       200.0.87.7                             0 67 1234 i 
 *>                   200.0.86.6                             0 67 1234 i 
 *   2.0.1.0/24       200.0.87.7                             0 67 1234 i 
 *>                   200.0.86.6                             0 67 1234 i 
 *   2.0.2.0/24       200.0.87.7                             0 67 1234 i 
 *>                   200.0.86.6                             0 67 1234 i 
 *   2.0.3.0/24       200.0.87.7                             0 67 1234 i 
 *>                   200.0.86.6                             0 67 1234 i 
 *   3.0.0.0/22       200.0.87.7                             0 67 1234 i 
 *>                   200.0.86.6                             0 67 1234 i 
 *   4.0.0.0/22       200.0.87.7                             0 67 1234 i 
 *>                   200.0.86.6                             0 67 1234 i 
 *   5.0.0.0/24       200.0.87.7                             0 67 1234 i 
 *>                   200.0.86.6                             0 67 1234 i 
 *   5.0.1.0/24       200.0.87.7                             0 67 1234 i 
 *>                   200.0.86.6                             0 67 1234 i 
 *   5.0.2.0/24       200.0.87.7                             0 67 1234 i 
 *>                   200.0.86.6                             0 67 1234 i 
 *   5.0.3.0/24       200.0.87.7                             0 67 1234 i 
 *>                   200.0.86.6                             0 67 1234 i 
 *   6.0.0.0/24       200.0.87.7                             0 67 i 
 *>                   200.0.86.6               0             0 67 i 
 *   6.0.1.0/24       200.0.87.7                             0 67 i 
 *>                   200.0.86.6               0             0 67 i 
 *   6.0.2.0/24       200.0.87.7                             0 67 i 
 *>                   200.0.86.6               0             0 67 i 
 *   6.0.3.0/24       200.0.87.7                             0 67 i 
 *>                   200.0.86.6               0             0 67 i 
 *   7.0.0.0/24       200.0.87.7               0             0 67 i 
 *>                   200.0.86.6                             0 67 i 
 *   7.0.1.0/24       200.0.87.7               0             0 67 i 
 *>                   200.0.86.6                             0 67 i 
 *   7.0.2.0/24       200.0.87.7               0             0 67 i 
 *>                   200.0.86.6                             0 67 i 
 *   7.0.3.0/24       200.0.87.7               0             0 67 i 
 *>                   200.0.86.6                             0 67 i 
 *   50.0.109.0/24    200.0.87.7                             0 67 1234 i 
 *>                   200.0.86.6                             0 67 1234 i 
 *   50.0.254.0/24    200.0.87.7                             0 67 1234 i 
 *>                   200.0.86.6                             0 67 1234 i 
 *   100.0.0.0/16     200.0.87.7               0             0 67 i 
 *>                   200.0.86.6                             0 67 i 
 *   150.0.0.0/24     200.0.87.7                             0 67 1114 i 
 *>                   200.0.86.6                             0 67 1114 i 
 *>  175.0.0.0/24     0.0.0.0                  0         32768 i 


Как мы видим, R8 держит на себе два местных full view (был бы настоящий интернет — был бы настоящий full view).

Проверяя связность я был несколько удивлен этим:
SW12#ping 4::3.0.0.3          
Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 4::300:3, timeout is 2 seconds: 
!.!.! 
Success rate is 60 percent (3/5), round-trip min/avg/max = 1/2/4 ms 

Описание и решение здесь.

Я пошел на крайние меры и выключил CEF на R8 (никогда так не делайте). Ситуация исправилась:
SW12#ping 4::3.0.0.3 
Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 4::300:3, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/3 ms 


MPLS VPN


Про MPLS будет сказано не так много, как хотелось бы. Мы просто настроим его и попробуем запустить L2 и L3 VPN. Для этих целей задействуем ранее остававшийся в стороне маршрутизатор R15.

Для начала базовые (самые базовые, только чтобы заработало) настройки MPLS на маршрутизаторах (в AS67 у нас нет P (Provider) устройств, только PE (Provider Edge), чего вполне достаточно для демонстрации VPN). Конфигурацию покажу только на одной стороне (R7 и R11), на другой все то же самое:

Включаем MPLS на интерфесах, на которых работает OSPF:
R7(config)#router ospf 67 
R7(config-router)#mpls ldp autoconfig 

R7(config)#mpls ldp router-id loopback 0 

Настраиваем диапазон используемых меток:
R7(config)#mpls label range 700 799 

Включаем MPLS глобально:
R7(config)#mpls ip 

Тут про MPLS VPN написано лучше, чем у меня, но я все-таки повторю процесс настройки.

Через AS67 мы пробросим L2VPN R11 R15

Для начала надо сконфигурировать VLAN для проброса на R11 и R15:
R11(config)#bridge irb
R11(config)#bridge 100 protocol ieee 
R11(config)#bridge 100 bridge ip 
R11(config)#bridge 100 route ip 

R11(config)#int bvi 100 
R11(config-if)#ip address 192.168.100.11 255.255.255.0

R11(config)#int eth0/2.100 
R11(config-subif)#encapsulation dot1Q 100
R11(config-subif)#bridge-group 100 

R11(config)#int eth 0/1.100    
R11(config-subif)#encapsulation dot1Q 100 
R11(config-subif)#bridge-group 100 

А теперь ввести всего несколько команд на PE:
R7(config)#int eth 0/3.100 
R7(config-subif)#encapsulation dot1Q 100 
R7(config-subif)#xconnect 6.6.6.6 100 encapsulation mpls 
R7(config-subif)#mpls ip

Все, L2 связность между VLAN 100 за R11 и R15 поднята. Проверим:
SW14#ping 192.168.100.15 
Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 192.168.100.15, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/8 ms 

Через AS1234 мы пробросим L3VPN R11 R15

Настройки, в целом, несколько сложнее чем для L2 VPN, но, по большому счету, ничего особого в них нет:

Настраиваем L3VPN только на PE и CE (Customer Edge) маршрутизаторах (трогать P не требуется).

Для проверки маршрутизации создадим приватную подсеть 10.0.150.0/24 на R11 и сеть 10.0.151.0/24 на R15. Наша задача – получить рабочий пинг с Loopback 150 на R11 до Loopback 151 на R15.

Во-первых, необходимо настроить стык PE-CE:

Использовать будем подсеть 10.0.0.0/24 (сконфигурируем на сабинтерфейсах, т.к. в дальнейшем мы привяжем их к VRF, и после этого, если поднимать на физике, понадобится более глобально перенастраивать BGP и переносить соседа в данный VRF).

На CE все просто:
R11(config)#router ospf 150 
R11(config-router)#network 10.0.0.5 0.0.0.255 area 0 
R11(config-router)#network 10.0.150.0 0.0.0.255 area 0 

А на PE нам потребуется создавать отдельный клиентский VRF (виртуальная сущность, имитирующая отдельный маршрутизатор с собственной таблицей маршрутизации, интерфейсами, etc...):
R5(config)#ip vrf AS1114 
R5(config-vrf)#rd 1234:1 
R5(config-vrf)#route-target export 1234:1 
R5(config-vrf)#route-target import 1234:1 

Также есть необходимость подкрутить BGP:
R5(config-router)#address-family vpnv4 
R5(config-router-af)#neighbor 2.2.2.2 activate 
R5(config-router-af)#neighbor 2.2.2.2 send-community both 
R5(config-router-af)#exit-address-family 

Теперь на PE создадим процесс OSPF в клиентском VRF:
R5(config)#router ospf 150 vrf AS1114 

увидим это:
*Nov 29 13:29:51.725: %OSPF-4-NORTRID: OSPF process 150 failed to allocate unique router-id and cannot start 

и присвоим процессу router-id:
R5(config-router)#router-id 10.0.0.5

Добавляем необходимую нам сеть:
R5(config-router)#network 10.0.0.0 0.0.0.255 area 0 

и связываем BGP с OSPF:
R5(config)#router bgp 1234                     
R5(config-router)#address-family ipv4 vrf AS1114 
R5(config-router-af)#redistribute ospf 150 
R5(config-router-af)#exit-address-family 

R5(config)#router ospf 150 vrf AS1114 
R5(config-router)#redistribute bgp 1234 subnets 

Привязываем интерфейс к VRF:
R5(config-subif)#ip vrf forwarding AS1114 

И видим, что надо пересоздать ip-адрес на интерфейсе:
% Interface Ethernet0/2.10 IPv4 disabled and address(es) removed due to enabling VRF AS1114 

R5(config-subif)#ip add 10.0.0.5 255.255.255.0 

Теперь то же самое на другой паре PE-CE. Единственное отличие – на R15 нет BGP, так что мы можем не создавать сабинтерфейсы для разных VRF, а делать все в одном физическом. В текущей конфигурации это будет работать.

Когда все будет готово, можем посмотреть RIB на R15:
R15(config)#do sh ip route ospf 
-----------------------------------------------------------------------
O E2     10.0.150.11/32 [110/11] via 200.0.152.2, 00:02:26, Ethernet0/0 
O E2  200.0.115.0/24 [110/1] via 200.0.152.2, 00:02:26, Ethernet0/0 
-----------------------------------------------------------------------

Мы видим, что маршруты через L3 VPN поднялись и доступны:
R15(config)#do ping 10.0.150.11 source 10.0.151.15 
Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 10.0.150.11, timeout is 2 seconds: 
Packet sent with a source address of 10.0.151.15 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/5 ms 

Loopback адрес на R11 пингуется с R15 (и наоборот), значит цель достигнута.

Кстати говоря, шифровать трафик здесь необходимо. Я попробовал зайти telnet'ом с R11 на R15 и с помощью Wireshark на линке R2 R5 легко нашел пару логин/пароль и все введенные конфигурационные команды.

Конфигурация BGP на R5 в данный момент выглядит таким образом:
sh run | sec bgp
R5(config-subif)#do sh run | sec bgp 
router bgp 1234 
 bgp router-id 5.5.5.5 
 bgp log-neighbor-changes 
 neighbor 2.2.2.2 remote-as 1234 
 neighbor 2.2.2.2 update-source Loopback0 
 neighbor 3.3.3.3 remote-as 1234 
 neighbor 3.3.3.3 update-source Loopback0 
 neighbor 4.4.4.4 remote-as 1234 
 neighbor 4.4.4.4 update-source Loopback0 
 neighbor 200.0.65.6 remote-as 67 
 neighbor 200.0.75.7 remote-as 67 
 neighbor 200.0.105.10 remote-as 65000 
 neighbor 200.0.115.11 remote-as 1114 
 ! 
 address-family ipv4 
  network 5.0.0.0 mask 255.255.255.0 
  network 5.0.1.0 mask 255.255.255.0 
  network 5.0.2.0 mask 255.255.255.0 
  network 5.0.3.0 mask 255.255.255.0 
  neighbor 2.2.2.2 activate 
  neighbor 3.3.3.3 activate 
  neighbor 4.4.4.4 activate 
  neighbor 200.0.65.6 activate 
  neighbor 200.0.65.6 remove-private-as 
  neighbor 200.0.75.7 activate 
  neighbor 200.0.75.7 remove-private-as 
  neighbor 200.0.105.10 activate 
  neighbor 200.0.105.10 route-map AS65000_IN in 
  neighbor 200.0.105.10 route-map AS65000_OUT out 
  neighbor 200.0.115.11 activate 
  neighbor 200.0.115.11 remove-private-as 
  neighbor 200.0.115.11 route-map AS1114_IN in 
  neighbor 200.0.115.11 route-map AS1114_OUT out 
 exit-address-family 
 ! 
 address-family vpnv4 
  neighbor 2.2.2.2 activate 
  neighbor 2.2.2.2 send-community both 
 exit-address-family 
 ! 
 address-family ipv4 vrf AS1114 
  redistribute ospf 150 
 exit-address-family 


На этом закончим с MPLS и со статьей в целом.

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 11

    +4
    Хороший пример и неплохой cookbook.
      0
      Надо изворачиваться до конца:) Добавляй в одной as is-is, проключай opt a-b-c стыки, для вида включи vrf-lite, vpls попробуй.
      Ну и что уж, зачем останавливаться только на транспорте? Опорную симулировать довольно тяжело, а вот доступ с брасами, агрегаторами и домовыми свичами — в самый раз. Не зря же в iou коммутаторы поддерживаются?)
      А дальше надо дать кому-нибудь эту лабу, чтоб внести какой-нибудь хитрый redistribute, и тренироваться в troubleshootingе)
        +2
        Спасибо за статью.
        Замечу, что SNAT уже не поддерживается, и в реальных условиях словили багу, когда SNAT+HSRP приводил к ребуту маршрутизатора.
        TAC порекомендовал переводить на NAT HA, но и с ним получили много веселого — переполнение очереди на интерфейсе с последующим отваливанием прохождения любого трафика через него и спонтанные crash, поправят, если повезет, в апреле 2015.
        Так что я бы не рекомендовал использовать nat+hsrp+bgp на одном устройстве… Как минимум натить надо где-то еще.
          0
          redistribute static в OSPF (можно обойтись без этого, если на всех iBGP пирах делать команду next-hop self, но мне как-то не очень нравится так делать);


          А почему, собственно? Если делать для iBGP next-hop self — вроде можно и без IGP? Или есть какие-то соображения, почему оно плохо?
            0
            IGP повышает скорость сходимости, BGP довольно неповоротливый протокол
              0
              Чисто теоретически обойтись без IGP, наверное, и получится, но для топологии больше, чем в 2 устройства — удовольствие очень и очень сомнительное (опять же — как минимум, если делать соседство на loopback'ах — все-таки придется писать статические маршруты, а тогда не использовать IGP нет смысла вообще).

              Почему оно плохо — особых соображений нет, и многие так и делают, но изначально команда создавалась все-таки не для этих целей. Тут, скорее, моя личная позиция, которая может быть и ошибочной.
                0
                cyruslab.net/2012/05/20/bgp-full-mesh-bgp-without-igp/ Вот, кстати, про то, как сделать iBGP без IGP.
                0
                Опубликуйте, пожалуйста, лабораторную где-нибудь. Буду безмерно благораден.
                  0
                  Постараюсь на выходных залить куда-нибудь, но стоит иметь в виду, что это не GNS3, и я смогу скинуть только образ с виртуалкой, на которой все это поднято (весит прилично).
                    +1
                    Будет достаточно, если экспортируете при помощи Manage -> Export Labs
                  0
                  Multicast-а в ней не хватает.

                  Only users with full accounts can post comments. Log in, please.