ISP`s IT Аутсорсинг
Быстрый переход: Главная блога Главная сайта Форум
Если Вы чего то недопоняли или не нашли - задайте
вопрос на нашем форуме и мы попробуем Вам помочь.
Subnets.ru Регистрация IP и Автономных систем mega-net.ru

Архивные статьи в категории ‘Протоколы маршрутизации’

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

Введние в статичскую маршрутизацию

Статический маршруты используются по ряду причин и чаще всего, когда не существует динамического маршрута к определенному месту назначения или когда включение динамического протокола маршрутизации не выполнимо. По умолчанию статические маршруты имеют административную дистанцию равную 1, что дает им преимущество над маршрутами изученными из динамических протоколов маршрутизации. Что такое административная дистанция и как она влияет на выбор маршрута, читайте в статье “Административная Дистанция”, опубликованной ранее на CicsoLab.RU.

Когда вы увеличиваете административную дистанцию в значение большем чем значение динамического протокола маршрутизации, статический маршрут будет работать только в случае, когда пропадет динамическая маршрутизация. Например, маршруты изученные из динамического протокола IGRP имеют административную дистанцию по умолчанию 100. Для того, чтобы конфигурировать статический маршрут, который будет перекрыт IGRP маршрутом, укажите административную дистанцию больше 100. Такой вид статической маршрутизации называется “плавающей”. Такой маршрут инсталлируется в таблицу маршрутизации только, когда более предпочтительный маршрут исчезнет оттуда. Например,

ip route 172.31.10.0 255.255.255.0 10.10.10.2 101

Обратите внимание, что административная дистанция 255, рассматривается как недостижимая и статический маршрут с административной дистанцией 255 никогда не будет введен в таблицу маршрутизации.

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

ip route 0.0.0.0 0.0.0.0 Ethernet0

В такой конфигурации маршрутизатор выполняет ARP запросы на интерфейсе Ethernet0 для каждого узла, который попадает в маршрут по умолчанию, потому что маршрутизатор рассматривает все эти узлы как напрямую подсоединенные к этому интерфейсу.

Такой вид маршрута по умолчанию, особенное если он используется большим количеством пакетов ко многим разным сетям может привести к большой нагрузке на CPU и огромному ARP кэшу и даже к исчерпании свободной памяти на этот самый кэш.

Указание числового следующего хопа (next hop) для маршрута, предотвратит выполнение ARP запросов на каждый адрес. Однако, если интерфейс за которым лежит next hop упадет, а числовое значение следующего хопа достижимо через рекурсивный маршрут, вы должный указать и IP адрес следующего хопа и интерфейс через который данный next hop может быть найден. Например,

ip route 0.0.0.0 0.0.0.0 Serial 3/3 192.168.20.1

Проблема

Теперь рассмотрим небольшой проблемный сценарий. В данной сетевой диаграмме, существует два статических маршрута к одному и тому же месту назначения (172.31.10.0/24). Один маршрут является “плавающим” маршрутом. Это резервный путь к целевой сети. Проблема в данном сценарии в том, что плавающий маршрут никогда не инсталлируется не таблицу маршрутизации, когда основной канал падает.

Рис.1

Рис.1

R1 имеет маршрут по умолчанию который указывает на маршрутизатор сервис провайдера (ISP) для доступа в Интернет. R1 также имеет два канала к R2. T1 это основной канал, а 56К это резервный канал. На R1 настроен статический маршрут в сторону сети 172.31.10.0/24, который указывает на IP адрес интерфейса Serial0 маршрутизатора R2 (10.10.10.2) в качестве следующего хопа. R1 также имеет плавающий маршрут для сети 172.31.10.0/24 который указывает на IP адрес интерфейса Serial1 роутера R2 (192.168.20.2). Административная дистанция для такого плавающего статического маршрута установлена в значение 250. Задача, сделать так, чтобы пакеты ходили по 56К каналу в обоих направлениях только в случае падения основного канала.

Конфигурация R1
hostname R1
!
ip subnet-zero
!
interface Serial3/0
description ISP Link
ip address 192.168.10.1 255.255.255.252
clockrate 64000
!
interface Serial3/2
description Primary Link to R2
ip address 10.10.10.1 255.255.255.252
!
interface Serial3/3
description Backup Link to R2
ip address 192.168.20.1 255.255.255.252
clockrate 64000
!
ip classless
#Это маршрут по умолчнию на ISP router
ip route 0.0.0.0 0.0.0.0 Serial3/0
!
#Это основной маршрут к LAN.
ip route 172.31.10.0 255.255.255.0 10.10.10.2
!
#Это плавающий маршрут к LAN.
ip route 172.31.10.0 255.255.255.0 192.168.20.2 250

Таблица маршрутизации на R1 выглядит следующим образом:

R1#show ip route
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
10.0.0.0/30 is subnetted, 1 subnets
C 10.10.10.0 is directly connected, Serial3/2
192.168.10.0/30 is subnetted, 1 subnets
C 192.168.10.0 is directly connected, Serial3/0
192.168.20.0/30 is subnetted, 1 subnets
C 192.168.20.0 is directly connected, Serial3/3
#Основной статический маршруи к LAN через канал T1.
172.31.0.0/24 is subnetted, 1 subnets
S 172.31.10.0 [1/0] via 10.10.10.2
#Статический маршрут по умолчнию в Internet.
S* 0.0.0.0/0 is directly connected, Serial3/0

Конфигурация R2

hostname R2
ip subnet-zero
!
interface Ethernet0
description Local LAN
ip address 172.31.10.2 255.255.255.0
!
interface Serial0
description Primary Link to R1
ip address 10.10.10.2 255.255.255.252
clockrate 56000
!
interface Serial1
description Backup Link to R1
ip address 192.168.20.2 255.255.255.252
!
ip classless
!
#Это основной маршрут по умолчнию.
ip route 0.0.0.0 0.0.0.0 10.10.10.1
#Это плавающий маршрут по умолчнию, используется если канал T1 неисправен.
ip route 0.0.0.0 0.0.0.0 192.168.20.1 250

R2 имеет маршрут по умолчанию инсталлированный через 10.10.10.1, и когда вы используете команду traceroute от R2 к ISP, пакеты ходят по каналу T1.

R2#show ip route
Gateway of last resort is 10.10.10.1 to network 0.0.0.0
172.31.0.0/24 is subnetted, 1 subnets
C 172.31.10.0 is directly connected, Ethernet0
192.168.20.0/30 is subnetted, 1 subnets
C 192.168.20.0 is directly connected, Serial1
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.10.10.0/30 is directly connected, Serial0
#Это основной маршрут по умолчнию.
S* 0.0.0.0/0 [1/0] via 10.10.10.1

R2#traceroute 192.168.10.2
.
Type escape sequence to abort.
Tracing the route to 192.168.10.2
.
1 10.10.10.1 16 msec 20 msec 16 msec
2 192.168.10.2 32 msec * 32 msec

R2 посылает ICMP пакеты к Internet хосту 192.168.30.1 с адресом отправителя 172.31.10.2.

R2#ping 192.168.30.1 source 172.31.10.2
Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/32 ms

Если мы опускаем интерфейс Serial3/2 на R1, то мы ожидаем, что R1 инсталирует плавающий статический маршрут к сети 172.31.10.0, а R2 инсталирует плавающий статический маршрут для 0.0.0.0 через 192.168.20.1. И по идее трафик будет ходить по 56К каналу.

Выполним указанный тест и посмотрим так ли это на самом деле:

R1#show ip interface brief
Interface IP-Address OK? Method Status Protocol
Serial3/0 192.168.10.1 YES manual up up
Serial3/2 10.10.10.1 YES manual up up
Serial3/3 192.168.20.1 YES manual up up

R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int s3/2
R1(config-if)#shut
R1(config-if)#end
2d21h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3/2, changed state to down
2d21h: %LINK-5-CHANGED: Interface Serial3/2, changed state to administratively down

R1#show ip interface brief
Interface IP-Address OK? Method Status Protocol
Serial3/0 192.168.10.1 YES manual up& up
Serial3/2 10.10.10.1 YES manual administratively down down
Serial3/3 192.168.20.1 YES manual up up

Взглянем на таблицы маршрутизации обоих роутеров.

R1#show ip route
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
192.168.10.0/30 is subnetted, 1 subnets
C 192.168.10.0 is directly connected, Serial3/0
192.168.20.0/30 is subnetted, 1 subnets
C 192.168.20.0 is directly connected, Serial3/3
#Статический маршрут через канал T1 остался в таблице маршрутизации.
#Это не то, что мы ожидали увидеть, когда выключали Serial 3/2
172.31.0.0/24 is subnetted, 1 subnets
S 172.31.10.0 [1/0] via 10.10.10.2
#Маршрут по умолчнию в Интерент.
S* 0.0.0.0/0 is directly connected, Serial3/0

На маршрутизаторе R2 все правильно.

R2#show ip route
Gateway of last resort is 192.168.20.1 to network 0.0.0.0
172.31.0.0/24 is subnetted, 1 subnets
C 172.31.10.0 is directly connected, Ethernet0
192.168.20.0/30 is subnetted, 1 subnets
C 192.168.20.0 is directly connected, Serial1
S* 0.0.0.0/0 [250/0] via 192.168.20.1

Однако теперь более не возможно пинговать внешний хост 192.168.20.1, поскольку R1 пытается послать ICMP ответы через Serial3/2 который выключен.

R2#ping 192.168.30.1 source 172.31.10.2
Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

Итак плавающий статический маршрут не был инсталлирован на R1 и основной маршрут все еще находиться в таблице маршрутизации R1, даже хотя интерфейс Serial3/2 лежит.

Причина этого поведения в том, что статические маршруты являются рекурсивными по природе. У вас всегда статический маршрут будет храниться в таблице маршрутизации до тех пор пока у вас есть маршрут на следующий хоп. В данном случае, R1 думает, что он может получить 10.10.10.2 через 192.168.10.2, потому, что 192.168.10.2 это следующий хоп для 0.0.0.0 0.0.0.0. Маршрут на следующий хоп может быть более специфичным, менее специфичным или маршрутом по умолчанию. В этом сценарии вы думает, что поскольку линк упал, вы не должный иметь маршрута для 10.10.10.2, но если вы посмотрите на таблицу маршрутизации R1, вы увидите, что существует статический маршрут по умолчанию, указывающий на ISP роутер. Поэтому R1 думает, что он может достичь next hop (10.10.10.2) для сети 172.31.10.0/24, через свой маршрут по умолчанию и статический маршрут 172.31.10.0/24 через 10.10.10.2 остается в таблице маршрутизации, тем самым предотвращаю инсталляцию плавающего маршрута.

Для того, чтобы предотвратить данную проблему вы должны указать интерфейс через который может быть найден следующий хоп. Тогда плавающий маршрут будет инсталлироваться только в случае, когда IP адрес next-hop будет достижим через указный интерфейс. Решение, заключается в удалении старого статического маршрута к сети 172.31.10.0 и добавлении нового, но на этот раз указываем интерфейс, через который достижим IP адрес следующего хопа. Это позволит инсталлировать плавающий маршрут, когда упадет интерфейс Serial3/2.

R1(config)#no ip route 172.31.10.0 255.255.255.0 10.10.10.2
R1(config)#no ip route 172.31.10.0 255.255.255.0 192.168.20.2 250
R1(config)#ip route 172.31.10.0 255.255.255.0 Serial3/2 10.10.10.2
R1(config)#ip route 172.31.10.0 255.255.255.0 Serial3/3 192.168.20.2 250

Статический маршрут к сети 172.31.10.0 через 10.10.10.2 будет находиться в таблице маршрутизации только, если 10.10.10.2 будет виден через интерфейс Serial3/2. Если данное условие не выполняется, статический маршрут через 10.10.10.2 удаляется их таблицы и взамен инсталлируется плавающий маршрут через Serial 3/3 и следующий хоп 192.168.20.2.

По материалам: cisco.com

Оригинал статьи тут

Ссылки:

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 4, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту

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

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

Выбираем наилучший путь

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

Чем меньше численное значение административной дистанции, тем более надежен протокол. Например, если роутер принимает маршрут к определенной сети и через OSPF и через IGRP, маршрутизатор выберет протокол IGRP, поскольку IGRP более надежен. Это значит, что маршрутизатор добавит в свою роутинговую таблицу маршрут от протокола IGRP.

Если вдруг, вы потеряли источник IGRP информации (например, выключили питание на нем), роутер будет использовать информацию поставляемую протоколом OSPF, до тех пор пока источник IGRP маршрутов не возобновит свою работу.

Таблица значений административной дистанции

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

Connected interface 0
Static route 1
Enhanced Interior Gateway Routing Protocol (EIGRP) summary route 5
External Border Gateway Protocol (BGP) 20
Internal EIGRP 90
IGRP 100
OSPF 110
Intermediate System-to-Intermediate System (IS-IS) 115
Routing Information Protocol (RIP) 120
Exterior Gateway Protocol (EGP) 140
On Demand Routing (ODR) 160
External EIGRP 170
Internal BGP 200
Unknown 255

Если административная дистанция равна 255, роутер не доверяет источнику маршрута и никогда не инсталлирует такой маршрут в таблицу маршрутизации.

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

ip route 10.0.0.0 255.0.0.0 Dialer 1 250

Здесь административная дистанция для маршурута 10.0.0.0/8 установлена в значение 250.

Таблица маршрутизации может выглядеть следующий образом

R1#show ip route

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 1 subnets
C 172.16.1.0 is directly connected, Ethernet0
R 10.0.0.0/8 [120/1] via 172.16.1.200, 00:00:16, Ethernet0
C 192.168.1.0/24 is directly connected, Loopback0

Если интерфейс Ethernet0 упадет, то в таблицу маршрутизации инсталлируется плавающий статический маршрут и весь трафик предназначенный для сети 10.0.0.0/8 будет маршрутизироваться через интерфейс Dialer 1 и по резервному каналу.

R1#show ip route
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.1.0 is directly connected, Ethernet0
S 10.0.0.0/8 is directly connected, Dialer1
C 192.168.1.0/24 is directly connected, Loopback0

Как только Ethernet интерфейс подниматься обратно, то в таблицу сразу же инсталлируется маршрут от динамического протокола RIP и трафик снова пойдет через Ethernet 0.

По материалам: cisco.com

Оригинал статьи тут

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 4, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту

object mntner, object as-set, object aut-num, object route
object inetnum, object person, object domain, object role

Раз вы добрались до конфигурации протокола BGP значит «общения» с базой данных (далее просто «БД«) RIPE вам не избежать.

Многие спрашивают: «А что такое as-set ?» или «Как узнать какой AS принадлежит маршрут

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

Итак, вы прошли процесс получения статуса LIR, собственного блока IP-адресов и номера автономной системы (ASNum).

Справка:

Локальный Интернет-реестр (LIR – Local Internet Registry) – термин, используемый для описания членов RIPE NCC.

Их называют локальными Интернет-реестрами (LIR) потому что они несут ответственность за распределение адресного пространства и регистрацию адресного пространства на локальном уровне.Локальные Интернет-реестры также утверждают общеобязательные политики и процедуры на локальном уровне. Организации, которые становятся локальными Интернет-реестрами — это в основном Интернет-провайдеры (ISP), которые выделяют и назначают адресное пространство своим клиентам, телекоммуникационные организации и коммерческие предприятия наряду с академическими учреждениями. Академические учреждения – это организации, которым требуются большие блоки адресного пространства, которые не могут быть получены у вышестоящего провайдера.

Что же делать дальше ? Бесконечное кол-во документации на сайте RIPE и молчащий google… а разбираться нужно. Попробую своими словами описать, то как разбирался/делал я сам.

ALLOCATION vs ASSIGNMENT

Для начала разберем два понятия:

  1. ALLOCATION — выделенное провайдеру адресное пространство. Оно закреплено за ним в БД
  2. ASSIGNMENT — текущее, одобренное RIPE, используемое провайдером адресное пространство так же описанное в БД

С первым вроде все понятно, RIPE выделил вам какой-то блок для дальнейшего использования, а вот со вторым не все так просто.

После того как RIPE сделал ALLOCATION какого либо блока вам необходимо согласовать с ними сколько и под какие нужды вы будете использовать адресное пространство. Вам придется заполнять форму в которой расписывать ADDRESS PLAN, что бы перевести часть адресного пространства из статуса ALLOCATED в статус ASSIGNED. Статус ASSIGNED будет означать, что RIPE одобрил вам использование адресного пространства под описанные вами нужды.

Советы по заполнению ADDRESS PLAN:

  1. не указывайте сети под конечного пользователя более чем /30, т.к. иначе RIPE напишет вам, сеть более чем /30 считается как End User`s infrastructure и заставит ваших пользователей так же заполнять форму на выделение адресного пространства.
  2. можно просить как минимум /24 под P2P (сети /30), в которые будут входить ваши каналы
  3. так же две сети /24 можно попросить под активное оборудование: маршрутизаторы, сервера, voip железки и прочее, главное не переборщите.
  4. RIPE очень любит когда пишут про NAT (адресное пространство ipv4 стремительно заканчивается), не разочаровывайте их, просите, опять таки не менее /24, под NAT сервера.
  5. В кач-ве оборудования пишите все: сервера, циски (даже Catalyst), VoIP шлюзы, железные firewall`ы вообще все что можно :), все для чего можно доказать необходимость внешнего адреса (если спросят ;))

Вы заполнили ADDRESS PLAN и отправили его в RIPE… ждем ответа… варианта два:

  1. их удовлетворит ваш запрос и они выставят статус ASSIGNED PA на сети которые они одобрили
  2. скажут что именно их не устраивает и вам придется бодаться с ними далее.

Зачем все это ? Можете ли вы использовать адресное пространство в статусе ALLOCATED ?

Использовать то вы его сможете, но если у вас кончится адресное пространство и вы заходите получить ещё блок адресов, то RIPE откажет вам, сославшись на то, что вы в текущий момент не используете свой первый ALLOCATED блок адресов. Посмотреть как RIPE видит текущее ваше использование выделенного вам адресного пространства можно с помощью утилиты Web Asused, указав свой Regid (например: ru.myisp) вам на email (указанный в lirportal) придет письмо содержащие отчет об использовании вами вашего адресного пространства.

Объекты в БД

БД состоит из многих объектов, мы рассмотрим некоторые из них. Для примера возьмем хорошего магистрального провайдера: Транстелеком.

Объект person [описание полей объекта]

Это описание человека. Пример:

person:          Yaroslav V Kapsalov
address:         JSC TransTeleCom
address:         7, Dolgorukovskaya st.
address:         127006 Moscow Russia
e-mail:          y.kapsalov@transtk.ru
phone:           +7 495 7846670
nic-hdl:         YARK-RIPE
source:          RIPE # Filtered

Объект person используется для указание административных (admin-c) и технических (tech-c) контактов где необходимо указать NIC-HDL, это уникальный инеднтификатор присваемый объекту person в БД. В данном примере nic-hdl это YARK-RIPE.

Видео пример создания объекта: смотреть

Видео пример проверки объекта: смотреть

Объект role [описание полей объекта]

Похож на объект «person«, но предназначен для описания не только контактного лица, но и роли, которое оно выполняет. Кроме того, объект «role» позволяет объединить несколько персон, выполняющих общую функцию (например отдел тех. поддержки, системных администраторов и т.д.). Для задания административных и технических контактов рекомендуется по возможности применять именно объект «role«. Пример:

role:            TTC NOC
address:         Company TransTeleCom Network Operation Center
address:         7, Dolgorukovskaya st.
address:         127006 Moscow Russia
remarks:         phone:          +7 095 7846677
phone:           +7 495 7846677
remarks:         phone:          +7 095 7846670
phone:           +7 495 7846670
remarks:         fax-no:         +7 095 7846671
fax-no:          +7 495 7846671
............[skiped]....................
mnt-by:          TRANSTELECOM-MNT
source:          RIPE # Filtered
............[skiped]....................

Одноименные поля, заполняются так же, как и в объекте «person«. Обратите внимание, что в отличие от объекта «person» поле «e-mail» здесь является обязательным.

В поле «role» указывается название службы, к которой относится объект.

В полях «admin-c» и «tech-c» указываются nic-handle персон, отвечающих за административные и за технические вопросы. Таких полей может быть несколько.

Объект inetnum [описание полей объекта]

Этот объект описывает ASSIGNMENT блок (блоки, подсети) адресов. Пример:

inetnum:         217.150.32.0 - 217.150.32.255
netname:         TTK-OFFICE-NET
descr:           Transtelecom Office Network
descr:           Moscow, Russia
country:         RU
admin-c:         KTTK-RIPE
tech-c:          KTTK-RIPE
status:          ASSIGNED PA
remarks:         INFRA-AW
mnt-by:          TRANSTELECOM-MNT
source:          RIPE # Filtered

Статус (status)- атрибут объектов inetnum , которые содержат информацию о выделении и назначении пространства IP-адресов (более подробная информация находится в документе ripe-387). В следующей таблицы приведена расшифровка значений статусов блоков IP-адресов.

Статус Пояснение
ALLOCATED PA Данное адресное пространство выделено локальному реестру (LIR), и никакие назначения (assignments) и суб-выделения (sub-allocation) , сделанные в этом пространстве , не являются портабельными (portable) при перемещении (конечного пользователя , которому назначены адреса из этого пространства) к другому провайдеру.
ALLOCATED PI Данное адресное пространство было выделено локальному или региональному реестру , и все назначения , сделанные в нем , портабельны. Назначения (после перемещения к другому провайдеру ) могут быть сохранены так долго , пока выполняются критерии первоначального назначения. Никакие суб-выделения не могут быть сделаны в данном адресном пространстве.
ASSIGNED PA Данное адресное пространство было назначено конечному пользователю для использования с услугами , предоставляемыми соответствующим локальным реестром. Оно не может быть сохранено при отказе от услуг , предоставляемых локальным реестром.
ASSIGNED PI Данное адресное пространство было назначено конечному пользователю и оно может быть сохранено так долго , пока выполняются критерии первоначального назначения
EARLY

REGISTRATION

Адресное пространство с данным статусом используется администрацией базы данных RIPE при перемещении пре-RIR регистраций из базы данных ARIN. Это значение может быть изменено пользователями базы данных (RIPE) (кроме значения ALLOCATED PA) . Объекты с подобным статусом могут создавать только администраторы базы данных RIPE.
NOT-SET Это значение показывает , что соответствующие адресные пространства (точнее , соответствующие объекты типа Inetnum) были зарегистрированы до того , как атрибут «статус» стал обязательным для объектов типа Inetnum. Соответствующий объект не был обновлен с тех пор. Объекты с таким значением статуса не создаются. Данное значение статуса может быть изменено пользователями базы данных.
SUB-ALLOCATED PA Данное адресное пространство было выделено локальным реестром нижестоящему сетевому оператору , который будет (сам) назначать адреса (конечным пользователям) из данного пространства. Все назначения из данного пространства являются PA. Они не могут быть сохранены при смене услуги на другую , предоставляемую другим провайдером.
ALLOCATED UNSPECIFIED Данное адресное пространство выдлено локальному или региональному реестру. Назначения (assignments) могут быть PI и PA . Этот статус предназначен для адресных пространств , выделенных согласно устаревшим на данный момент документам , когда существовали одновременно назначения (assignments) обоих типов. Присваивания данного статуса новым выделенным адресным пространствам избегают. Суб-выделения адресных пространств в данном типе адресного пространства не могут быть совершены.
LIR-PARTITIONED PA Данный статус позволяет локальным реестрам документировать распределение и делегировать управление выделенным пространством внутри своих организаций. Адресное пространство с данным статусом не считается используемым. Когда адреса из такого пространства используются , должен быть зарегистрирован более конкретный объект типа Inetnum для этих адресов.
0 Данный статус не является статусом , официально утвержденным RIPE NCC, значение 0 («нуль») всего лишь отмечает , что статус данного блока адресов неизвестен , это значение используется только данной релизацией базы данных географической привязки


Объект route[описание полей объекта]

Этот объект указывает на то, какой автономной системе принадлежит сеть. Пример:

route:           217.150.32.0/19
descr:           RU-TRANS-TELECOM-20010213
origin:          AS20485
mnt-by:          TRANSTELECOM-MNT
source:          RIPE # Filtered

Из этого следует, что сеть 217.150.32.0/19 оглашается автономной системой с номером 20485. Ключом route объекта являются одновременно два поля: route и origin . В поле route указывается диапазон адресов, за маршрутизацию которых в Интернет будет отвечать автономная система, номер которой указан в поле origin .

Объект aut-num[описание полей объекта]

Этот объект описывает автономную систему. Пример:

aut-num:         AS20485
as-name:         TRANSTELECOM
descr:           JSC Company TransTeleCom
descr:           Moscow, Russia
............[skiped]....................

В нем описывают не только кому принадлежит данный номер, административные и технические контакты,
но и описание пиров (peer) данной автономной системы и комьюнити (communities) которые можно
использовать.
Пиры:
…………[skiped]………………..
import: from AS174 action pref=120; accept AS174:AS-COGENT;
import: from AS786 action pref=120; accept AS-JANETPLUS;
import: from AS1290 action pref=120; accept AS-PSINETUK;
import: from AS2110 action pref=120; accept AS-IEUNET;
import: from AS2119 action pref=120; accept AS-TELENOR;
import: from AS2529 action pref=120; accept AS-DEMON;

…………[skiped]………………..

Показывает импорт маршрутов для автономной системы Транстелекома (AS20485), префиксы каких
автономных систем принимаются от указанных пиров. Может быть указано как и одиночная AS так и as-set.

…………[skiped]………………..

export: to AS174 announce AS-TTK;
export: to AS786 announce AS-TTK;
export: to AS1290 announce AS-TTK;
export: to AS2110 announce AS-TTK;
export: to AS2119 announce AS-TTK;
export: to AS2529 announce AS-TTK;

…………[skiped]………………..

Показывает какие маршруты оглашаются автономной системой Транстелекома (AS20485) своим пирам.
Так же может быть указана одна AS или as-set (в данном примере используется именно as-set)

Комъюнити:
…………[skiped]………………..
remarks: +==============================================================+
remarks: | BGP COMMUNITIES |
remarks: +—————————————————————
remarks: | Communities for prefix classification |
remarks: +—————————————————————
remarks: | All inbound prefixes are marked with BGP communities |
remarks: | which describe their source and geographical region. |
remarks: | The format for the second component of community |
remarks: | (number after 20485:) is set at five digits. |
remarks: | This format is 20485:SNNRR where the fields are: |
remarks: | |
remarks: | S — source of the prefix: |
remarks: | |
remarks: | 1 — Customer |
remarks: | 2 — Upstream |
remarks: | 3 — International peer |
remarks: | 4 — Russian peer |
remarks: | |
remarks: | NN — Upstream, peer or customer number: |
remarks: | |
remarks: | Customers: |
remarks: | 11 — BGP with Internal Internet Access |
remarks: | 13 — BGP with Partial Internet Access |
remarks: | 17 — BGP with Global Internet Access |
remarks: | Static routes from CTTC allocations: 20485:61RR|
remarks: | Upstreams: |
remarks: | 01 — Cable&Wireless (AS1273) |
remarks: | 02 — Telia (AS1299) |
remarks: | 03 — NTT (AS2914) |
remarks: | 05 — PCCW (AS3491) |
remarks: | 07 — UUNET (AS702) |
remarks: | International peers: |
remarks: | 01 — SONG (AS3246) |
remarks: | 03 — GOOGLE (AS15169) |
remarks: | 04 — LINX |
remarks: | 05 — RETN (AS9002, International peers) |
…………[skiped]………………..

Описывает как используются/использовать комъюнити с данной автономной системой.

Комъюнити может выставляться на все маршруты или только на некоторые. Комъюнити состоит из
ASNUM:COMMNUM — номер автономной системы родителя данного комъюнити : 20485:20100
По комъюнити можно понять откуда пришел маршрут и использовать их в своих фильтрах (route-map). Так же с их помощью можно «просить» автономную систему соседа сделать что либо с оглашаемыми вашей AS маршрутами (префиксами).

…………[skiped]………………..
remarks: +—————————————————————+
remarks: | Communities for prefix control |
remarks: +—————————————————————+
remarks: | !!!ATENTION!!! |
remarks: | The using of this communities may cause connectivity |
remarks: | problems and you must clearly understand what you |
remarks: | are doing. TransTeleCom does not bear any responsibility |
remarks: | if there will be such troubles. |
remarks: +—————————————————————+
remarks: | There are two predetermined eBGP session types which |
remarks: | customers may use: |
remarks: | 1 — Global Internet Access. CTTC announce |
remarks: | customer’s prefixes to all customers, |
remarks: | upstreams and peers. |
remarks: | BGP communities are available. |
remarks: | |
remarks: | 2 — Access to customers and Russian peers. |
…………[skiped]………………..
remarks: | — To prepand or deny prefix use 20485:5DNNA, where: |
remarks: | |
remarks: | D — destination of the prepend or deny action: |
remarks: | 2 — Upstreams |
remarks: | 3 — International peers |
remarks: | 4 — Russian peers |
remarks: | 9 — Upstreams and Peers |
…………[skiped]………………..
remarks: | A — action: |
remarks: | |
remarks: | 0 — don’t announce prefix |
remarks: | 1 — announce with one prepend |
remarks: | 2 — announce with two times prepend |
remarks: | 3 — announce with three times prepend |
…………[skiped]………………..

Составив комьюнити, исходя из описания, и, огласив его вместе с исходящим от вас маршрутом(ами), автономная система пира (в данном примере AS20485) выполнит те или иные действия: выполнит prepend (препенд — когда в as-path подставляется N раз ваш номер AS, что увеличивает as-path и соответственно ухудшает маршрут) или вовсе «запретит» (не будет анонсировать своим соседям) этот маршрут (префикс).
Это может позволит вам балансировать входящий трафик на ваших внешних каналах.

Объект as-set[описание полей объекта]

Этот объект описывает (включает в себя) несколько автономных систем или других as-set.

Данный объект используется для настройки входящих BGP фильтров, используются или префиксы или as-path. Пример:

as-set:          AS-TTK
descr:           Customers with TransTeleCom Global Access
members:         AS20485
members:         AS-CTTC
members:         AS-KTTK
members:         AS-SETTC
members:         AS-SIBTTK
members:         AS-STTK
members:         AS-SUTTK
members:         AS-TTKNN
members:         AS-TTKNN-IZHEVSK
members:         AS-UMN
members:         AS-UMN-TMN
members:         AS-VTT
members:         AS-ZSTTK-SET
members:         AS33989
............[skiped]....................
mnt-by:          TRANSTELECOM-MNT
source:          RIPE # Filtered

Внутри объекта as-set member`ом может быть как и одна AS (например AS33989) так и другие as-set`ы (например AS-CTTC). Воспользовавшись утилитой на нашем сайте вы сможете построить фильтры по as-set (внимание ! Объект as-set должен существовать в БД RIPE).

В данном примере имя as-set`а — AS-TTK.

Объект domain[описание полей объекта]

Этот объект отвечает за DNS сервера. Благодаря ему можно указать DNS сервера отвечающие за обратный резолв (PTR записи) для вашего блока адресов. Пример:

domain:          32.150.217.in-addr.arpa
descr:           Reverse delegation for TRANS-TELECOM-NET
remarks:         INFRA AW
admin-c:         KTTK-RIPE
tech-c:          KTTK-RIPE
zone-c:          KTTK-RIPE
nserver:         dns-prim.transtk.ru
nserver:         dns-sec.transtk.ru
nserver:         ns.transtelecom.net
nserver:         ns1.transtelecom.net
mnt-by:          TRANSTELECOM-MNT
source:          RIPE # Filtered

Это необходимо если вы хотите, чтобы на команду nslookup ВАШ-IP-АДРЕС, вы и остальной мир, получали имя.

Пример: nslookup 217.150.32.1
1.32.150.217.in-addr.arpa name = ttk-eth1.transtk.ru.

Объект mntner[описание полей объекта]

Произносится как maintainer.

Этот объект необходим для защиты объектов в БД, основным признаком которого является схема аутентификации. При использовании ссылки на mntner в каком-либо объекте БД (включая сам mntner) объект считается защищенным от несанкционированного изменения/удаления, при этом степень защищенности определяется схемой аутентификации. Им как бы подписывают другие объекты, как сертификатом, подтверждая подлинность данных. В отличие от других объектов, объект mntner имеет пароль и для того, чтобы изменить другие объекты, в которых есть ссылка на mntner (при их создании/редктировании было добавлено поле «mnt-by«), вам необходимо знать его. Кем «подписан» можно видеть по полю mnt-by. Пример:

mntner:          TRANSTELECOM-MNT
descr:           JSC TransTeleCom Maintainer
admin-c:         KTTK-RIPE
tech-c:          KTTK-RIPE
auth:            MD5-PW $1$dkAwA6S5$tP8KkASb5xG7atyTYxpDo/
mnt-by:          TRANSTELECOM-MNT
referral-by:     RIPE-DBM-MNT
source:          RIPE # Filtered

Строка auth и содержит зашифрованный пароль. Пароль криптуется как и в ОС FreeBSD (/etc/master.passwd), поэтому при создании объекта mntner свой пароль можно скопировать из файла /etc/master.passwd лиюо воспользоваться утилитой Crypted password generation на сайте RIPE.

Видео пример создания объекта: смотреть

Обязательно защищайте свои объекты с помощью mntner (поле«mnt-by«). Посмотрите видео пример как это сделать: смотреть

Надеюсь, что хоть немного стало понятней, т.к. по себе знаю, что с нуля врубаться в это дело сложновато.

Так что дальше ?

Если у вас уже есть номер атономной системы и свой блок адресов, то пора внести в БД недостающие части. Вносить изменения в можно двумя способами:

  1. отправить письмо с полным описанием объекта на email auto-dbm@ripe.net. В ответ вам придет письмо или «SUCCESS: changes» или «FAILED: changes» с описанием ошибок которые вы допустили.
  2. воспользоваться online утилитой Webupdates

На вашем месте я бы сначала пользовался 2-ым способом, т.к. там есть подсказки при создании объектов.

Сначала создадим объект person. Заходим на Webupdates, в разделе «Create a new object» выбираем объект person и жмем «Add object». Заполняем все необходимые поля и жмем «Submit update» и читаем создался ли объект или проишошла какая либо ошибка. Если какие либо поля вызывают сомнения то жмем «?» и читаем описание-подсказку. Поле «nic-hdl» можно выставить в AUTO-1, тогда БД сама сгенерит имя для этого объекта.

Теперь создадим mntner. Опять идем в «ADD» на Webupdates и выбираем объект mntner.

В поле «mntner:» пишем MNTYOUR-PROVIDER-NAME или YOUR-PROVIDER-NAMEMNT.
В поле «admin-c:» пишем nic-hdl (которые мы получили после создания объекта person.) — это будет использоваться для административных контактов.
В поле «auth:» пишем MD5-PW ВАШ-ПАРОЛЬ-В-MD5
В поле «referral-by:» пишем RIPE-DBM-MNT

После создания объекта mntner можно вернуться к объекту person, но уже редактируя, т.е. раздел «Modify or delete an existing object» — вводим свой nic-hdl. В радактировании добавляем поле «mnt-by» (воспользовавшись формой «Add New Field» внизу страницы), в нем указываем имя которое мы писали создавая объект mntner, например MNTYOUR-PROVIDER-NAME, но теперь необходимо добавить поле «password» в котором ввести некриптованый пароль, дабы подтвердить владение объектом mntner. «Подписав» объект person своим объектом mntner вы избегаете того, что кто либо изменит ваш объект person без вашего ведома, т.к. теперь для любого изменения этого обекта будет требоваться пароль mntner`а.

Далее необходимо создать объект inetnum.

В поле «inetnum:» вписываем сеть которую мы согласовали с RIPE когда писали Address Plan. Например: 217.150.32.0 — 217.150.32.255

В поле «netname:» вписываем название для своей сети так же указанную в Address Plan.

В поле «status:» пишем ASSIGNED PA

Что писать в поле «mnt-by:» вы уже знаете 😉

Все остальные объекты создаются/редактируются по тому же принципу.

Создайте объекты route, domain, as-set.

В объекте domain добавте столько полей «nserver:» сколько вам необходимо. В них нужно указать DNS имена ваших DNS серверов которые будут отвечать за reverse delegation (обратный просмотр(резолв)) ваших адресов. В «zone-c:» указываем nic-hdl человека который в вашей организации будет отвечать за зоны обраного просмотра.

В объекте as-set добавте поле «members:». Если ваша AS пока не транзитная, то напишите в нем ASНОМЕР_ВАШЕЙ_AS, поле «as-set:» является именем вашего будущего as-set`а. Обычно имя выглядит как AS-PROVIDER_NAME, например AS-TTK.

Создать его нужно для того, что если вас спросят «По какому объекту строить фильтры ?», то вам необходимо говорить что это as-set и его имя. Это для Вашего же удобства.

Важно: если вы отредактировали свой as-set (добавили/удалили что-то), то вам необходимо сообщить об этом вашим peer`ам (соседям), т.к. не у всех есть автоматический апдейт фильтров.

Отредактируйте (если это необходимо) свой объект aut-num например добавив поле(я) «remarks:» или «descr:» с более подробным описанием своей сети или юр.лица которому она принадлежит, а так же, возможно, обновив свой «import:» или «export:» лист.

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

Помним, что полное описание полей объекта можно получить выполнив в БД с ключем -v и именем объекта который нас интересует: пример.

Поля, отмеченные как [mandatory] являются обязательными для заполнения, должны обязательно присутствовать в заявке.

Поля, отмеченные как [single] могут присутствовать в заявке только в единственном экземпляре.

Поля, отмеченные как [multiple] могут присутствовать в нескольких экземплярах (например для указания нескольких телефонных номеров).

Поле «changed» должно содержать адрес электронной почты человека, который отправляет данную заявку (или вносит изменения) и дату внесения изменений в формате ГГГГММДД.

Поле «source» должно содержать значение «RIPE».

Поле «mnt-by» применяется для выбора способа авторизации дальнейших изменений в создаваемом объекте (см. объект «mntner«).

Удаление из БД делается точно так же как и создание. Единственное отличие, то что в конце добавляется поле «delete:» в котором вы и указываете причину удаления этого объекта.

Для удобства использования WebUpdates, дабы не вводить пароль от объекта mntner, можно использовать авторизацию до проведения необходимых изменений: смотреть

Пока это все что я хотел вам поведать, комментарии/замечания приветствуются.

Полезные ссылки:

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

З.Ы.Ы. Мы можем оказать вам содействие в получении статуса LIR, номера автономной системы и собственного блока адресов для Вашей организации на возмездной основе.

mntner object, as-set object, aut-num object, route object
inetnum object, person object, domain object, role object

Автор: Николаев Дмитрий (virus (at) subnets.ru)
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 21, среднее: 4,57 из 5)
Загрузка...
Отправить на почту Отправить на почту

Настраиваем BGP используя quagga на 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, блок внешних адресов.
Т.к. для того, что бы протокол 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
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 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
*> 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 advertised-routes
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
  2. настройка протокола BGP на оборудовании от Juniper
  3. как получить номер AS и собственный блок адресов ?
  4. что и как делать в БД RIPE после получения AS и блока адресов ?
  5. как управлять внешними каналами (трафик) ?
  6. транзитные AS

Ссылки:

Сгенерировать полный конфиг для cisco, построить фильтры по as-set , создать access-list / prefix-list можно с помощью: Online BGP tools Т.к. quagga имеет cisco like интерфейс конфиги почти один в один.

Автор: Николаев Дмитрий (virus (at) subnets.ru)
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 3, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту