Настраиваем BGP используя quagga на FreeBSD

Опубликовано admin в Чт, 09/07/2009 - 22:19
Статья взята с subnets.ru (_http://subnets.ru/blog/?p=19).

Настраиваем BGP используя quagga на FreeBSD (_http://subnets.ru/blog/?tag=freebsd).

В статье описан способ поднять протокол динамической маршрутизации BGPv4 (EBGP) для минимального взаимодействия двух AS.

Протокол BGP сложный механизм состоящий из многих параметров. В одной статье сложно учесть и объяснить все.
Статья будет пригодна тем, кто только начал сталкиваться с этим протоколом и не использовал quagga.

Основные понятия:

AS – Autonomous system – группа маршрутизаторов (шлюзов) из одной административной области, взаимодействующих с другими автономными системами посредством внешнего протокола маршрутизации. При наличии собственного номера AS и блока адресов позволяет использовать два и более каналов в сеть Интернет одновременно, с распределением нагрузки между ними.

EGP – Exterior Gateway Protocol, протокол внешнего шлюза. (например: BGPv4, IS-IS);

IGP – Interior gateway protocol, протокол внутреннего шлюза (например: RIP, EIGRP, OSPF);

EBGP – External BGP, взаимодействие протокола BGP с другими (чужими) автономными системами;

IBGP – Internal BGP, взаимодействие протокола BGP внутри своей автономной системы;

peer – Сосед по протоколу динамической маршрутизации;

as-path – “Путь” из номеров AS (автономных систем) до сети назначения;

Номера AS 64512 – 65535 выделены для частного использования (”серые” номера AS);

Тестовый стенд: компьютер Intel P4, 4Gb памяти, и два сетевых интерфейса em0, em1

Начнем:

cd /usr/ports/net/quagga/
make install clean

После установки нам необходимо настроить два демона:

  1. zebra
  2. bgpd

Переходим в директорию /usr/local/etc/quagga

Файл: zebra.conf

hostname zebra
password 123
enable password 123
log file /usr/local/etc/quagga/zebra.log
!
interface em0
ip address 10.1.1.1/24
!
interface em1
ip address 2.2.2.2/30
!
interface lo0
!
ip route 10.0.0.0/8 Null0 254
ip route 172.16.0.0/12 Null0 254
ip route 192.168.0.0/16 Null0 254
ip route 64.17.0.0/21 Null0 254
ip route 64.17.0.0/22 10.1.1.2
ip route 64.17.4.0/22 10.1.1.3
!
ip forwarding
!
!
line vty
exec-timeout 0 0
!

Пройдемся по конфигу zebra.conf

em0 - интерфейс смотрящий в сторону локальной сети
em1- интерфейс смотрящий в сторону провайдера
маршруты 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 отправлены в Null0, иными словами все пакеты которые будут приходить от данных сетей будут отбрасываться, т.к. это “серые” сети которые не маршрутизируются в сети Интернет.
64.17.0.0/21 – это выделенный нам, организацией RIPE (_http://ripe.net), блок внешних адресов.
Т.к. для того, что бы протокол BGP мог анонсировать (объявлять) эту подсеть провайдеру он сам должен знать где находится данная сеть. Для того, чтобы в последствии избежать ситуаций когда из-за проблем внутри локальной сети, например недоступность gateway на который (которые) будут маршрутизироваться подсети или сеть 64.17.0.0/21 при использовании внутренних протоколов динамической маршрутизации (RIP, OSPF, EIGRP), BGP перестанет анонсировать наш блок внешних адресов, для этого мы также отправляем маршрут этой сети в Null0. Таким образом мы заставим BGP всегда знать маршрут в эту сеть.
Теперь возмем блок 64.17.0.0/21 и поделим его на две подсети 64.17.0.0/22, 64.17.4.0/22 и “отмаршрутизируем” их внутрь сети на два других сервера 10.1.1.2, 10.1.1.3 где они будут использоваться под клиентов или другое оборудование, где могут быть ещё разбиты на более мелкие подсети.

Вы возможно подумали о том: “как же это будет работать раз /21 отправлена в Null0 ?”
Это будет работать по тому, что в таблице маршрутизации роутера будет три маршрута, два из которых более точные (/22), поэтому наш маршрутизатор будет пользоваться ими для продвижения пакетов приходящие от нашего блока.

Файл bgpd.conf:

hostname AS100
password 123
enable password 123
log file /usr/local/etc/quagga/bgpd.log
!
router bgp 100
bgp router-id 2.2.2.2
bgp log-neighbor-changes
no synchronization
network 64.17.0.0/21
neighbor 2.2.2.1 remote-as 200
neighbor 2.2.2.1 description MY-PROVIDER
neighbor 2.2.2.1 next-hop-self
neighbor 2.2.2.1 route-map MY-PROVIDER-in in
neighbor 2.2.2.1 route-map MY-PROVIDER-out out
!
ip prefix-list bogons description bogus nets
ip prefix-list bogons seq 15 permit 0.0.0.0/8 le 32
ip prefix-list bogons seq 20 permit 127.0.0.0/8 le 32
ip prefix-list bogons seq 30 permit 10.0.0.0/8 le 32
ip prefix-list bogons seq 35 permit 172.16.0.0/12 le 32
ip prefix-list bogons seq 40 permit 192.168.0.0/16 le 32
ip prefix-list bogons seq 45 permit 169.254.0.0/16 le 32
ip prefix-list bogons seq 50 permit 224.0.0.0/4 le 32
ip prefix-list bogons seq 55 permit 240.0.0.0/4 le 32
ip prefix-list default description default route
ip prefix-list default seq 10 permit 0.0.0.0/0
ip prefix-list our-CIDR-blocks seq 5 permit 64.17.0.0/21 le 32
ip prefix-list upstream-out seq 10 permit 64.17.0.0/21
!
ip as-path access-list 1 permit _6451[2-9]_
ip as-path access-list 1 permit _645[2-9][0-9]_
ip as-path access-list 1 permit _64[6-9][0-9][0-9]_
ip as-path access-list 1 permit _65[0-9][0-9][0-9]_
!
route-map MY-PROVIDER-in deny 100
match as-path 1
!
route-map MY-PROVIDER-in deny 110
match ip address prefix-list bogons
!
route-map MY-PROVIDER-in deny 115
match ip address prefix-list default
!
route-map MY-PROVIDER-in deny 120
match ip address prefix-list our-CIDR-blocks
!
route-map MY-PROVIDER-in permit 200
set local-preference 100
!
route-map MY-PROVIDER-out permit 100
match ip address prefix-list upstream-out
!
route-map MY-PROVIDER-out deny 200
!
line vty
!

Пройдемся по конфигу bgpd.conf

AS100 – Autonomous system, наш номер автономной системы так же выданный нам организацией RIPE (_http://ripe.net)
AS200 – автономная система нашего провайдера
no synchronization – не ждать подтверждения маршрута от протоколов внутреннего шлюза (IGP)
network 64.17.0.0/21 – указываем сеть для анонсирования
командами neighbor мы описываем своего “соседа” (peer`а), указываем номер его AS, его IP-адрес, указываем маршрутные карты на вход и на выход, neighbor 2.2.2.1 next-hop-self – говорит о том, что для всех оглашаемых маршрутов next-hop будет выставлен на нас (в as-path будет содержаться номер нашей AS)
ip prefix-list bogons – описывает те сети маршруты в которые мы не хотим получать от своего “соседа”
ip as-path access-list 1 – описывает “серые” номера AS которые не маршрутизируются в сети Интернет и предоставлены для внутреннего использования, где бы они не встречались в as-path

route-map MY-PROVIDER-in – маршрутная карта которая применяется при передаче соседом маршрутов в нашу AS100

в deny 100 – запрещаем принимать маршруты в as-path которых содержатся “серые” AS, перечисленные в ip as-path access-list 1
в deny 110 – запрещаем принимать маршруты в которых содержатся сети перечисленные в ip prefix-list bogons
в deny 115 – запрещаем принимать default gateway
в deny 120 – запрещаем принимать маршрут в принадлежащие нам сети (наш блок адресов (prefix-list our-CIDR-blocks)) (на всякий случай ;) )
в permit 200 – и последние правило которое разрешит все остальные маршруты и выставит на них local-preference 100

route-map MY-PROVIDER-out – маршрутная карта которая применяется при оглашении маршрутов от нашей AS100 к AS200 автономной системы нашего провайдера (prefix-list upstream-out).

в permit 100 – разрешаем свой блок /21

Принцип работы маршрутных карт (route-map) прост, то что разрешает access-list является совпадением, а дальше применяется действие указанное в маршрутной карте: permit или deny.
Последним действием которое не указано, но подразумевается это deny. Тот же самый принцип что и в access-list. Если совпадений не будет, то маршрут будет запрещен.

Рекомендуется присваивать “говорящие” названия для маршрутных карт (route-map) для дальнейшего удобства, когда конфиг будет разрастаться.

Ну вот мы и сделали необходимый минимум.
Пишем в /etc/rc.conf:

quagga_enable=”YES”
quagga_daemons=”zebra bgpd”
quagga_flags=”-d -A 127.0.0.1″

Стартуем:

/usr/local/etc/rc.d/quagga start

либо

/usr/local/sbin/zebra -f /usr/local/etc/quagga/zebra.conf -d -A 127.0.0.1
/usr/local/sbin/bgpd -f /usr/local/etc/quagga/bgpd.conf -d -A 127.0.0.1

Все то что описано в конфиге, можно настроить и через консоль, после запуска демона.
Для того, чтобы настроить и управлять демоном zebra, после его запуска, устанавливаем telnet соединение на порт 2601 localhost (127.0.0.1:2601).
Демон bgpd работает на порту 2605 localhost (127.0.0.1:2605).

Проверяем, что все работает:
telnet 127.0.0.1 2605
вводим пароль 123 и переходим в enable режим опять таки вводя пароль 123
смотрим информацию по соседу, где нас интересует строка состояния:
sh ip bgp neighbors 2.2.2.1
..................
BGP state = Established, up for 09w6d19h
.....................

даем команду sh ip bgp и смотрим получаем ли мы маршруты от соседа

AS100# sh ip bgp
BGP table version is 0, local router ID is 89.111.159.22
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 3.0.0.0 2.2.2.1 100 0 200 310 600 701 703 80 i
*> 4.0.0.0 2.2.2.1 100 0 200 310 3356 i
*> 4.0.0.0/9 2.2.2.1 100 0 200 310 3356 i
*> 4.23.112.0/24 2.2.2.1 100 0 200 310 174 21889 i
*> 4.23.113.0/24 2.2.2.1 100 0 200 310 174 21889 i
*> 4.23.114.0/24 2.2.2.1 100 0 200 310 174 21889 i
*> 4.36.116.0/23 2.2.2.1 100 0 200 310 174 21889 i
*> 4.36.116.0/24 2.2.2.1 100 0 200 310 174 21889 i
*> 4.36.117.0/24 2.2.2.1 100 0 200 310 174 21889 i
*> 4.36.118.0/24 2.2.2.1 100 0 200 310 174 21889 i

………………

Мы видим, что маршруты от соседа к нам приходят.

Теперь посмотрим, что мы огласили своему соседу:

sh ip bgp neighbors 2.2.2.1
BGP table version is 0, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 64.17.0.0/21 2.2.2.2 0 32768 i

Total number of prefixes 1

Мы должны видеть наш блок адресов 64.17.0.0/21 и next-hop наш IP-адрес, если это так то все в порядке, наш маршрут соседу отправлен.

З.Ы.

Данная статья не претендует на гипер HOW-TO, но м.б. поможет кому нить, а так же, возможно, будет дописываться.

При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Мы продолжим тему настройки и понимания протокола BGP в других статьях, предполагается:

  1. настройка BGP на оборудовании от Cisco Systems (_http://subnets.ru/blog/?tag=cisco-systems)
  2. настройка протокола BGP на оборудовании от Juniper (_http://subnets.ru/blog/?tag=juniper)
  3. как получить номер AS и собственный блок адресов ?
  4. что и как делать в БД RIPE после получения AS и блока адресов ? (_http://subnets.ru/blog/?p=24)
  5. как управлять внешними каналами (трафик) ?
  6. транзитные AS

Ссылки:

Сгенерировать полный конфиг для cisco, построить фильтры по as-set (_http://subnets.ru/blog/?p=24) , создать access-list / prefix-list можно с помощью: Online BGP tools (_http://subnets.ru/wrapper.php?p=4) Т.к. quagga имеет cisco like интерфейс конфиги почти один в один.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Похожие статьи:

  • Настройка протокола BGP на оборудовании Cisco Systems (_http://subnets.ru/blog/?p=28)
  • Redistribute static route into OSPF / Редистрибуция статических маршрутов в OSPF (_http://subnets.ru/blog/?p=595)
  • Cisco и Policy-based routing ( PBR ) (_http://subnets.ru/blog/?p=479)
  • Настройка протокола BGP на оборудовании Juniper (_http://subnets.ru/blog/?p=29)
  • Настройка Vlan на Foundry BigIRON 4000 (_http://subnets.ru/blog/?p=721)
( categories: )