Что делать если одна AS и несколько сетей в разных городах

[linx]

Сегодня Ростелеком обрадовал - запустил BGP. В итоге: 2 города, 2 разных провайдера, одна AS. Отдается default,full-view. В ripe изменения: добавил объекты route, export, import.

Конфиги quagga (номера AS и IP вымышленные, только для примера):

Код: Выделить всё

gw ~ # cat /etc/quagga/bgpd.conf
hostname AS123456
password zebra
enable password zebra
log file /var/log/bgpd.log
router bgp 123456
bgp router-id 81.26.168.226
bgp log-neighbor-changes
no synchronization
network 48.151.0.0/22
neighbor 81.26.168.225 remote-as 31233
neighbor 81.26.168.225 description UPLINK_MEGAFON

gw1 ~ # cat /etc/quagga/bgpd.conf
hostname AS123456
password zebra
enable password zebra
log file /var/log/bgpd.log
router bgp 123456
bgp router-id 173.45.248.98
bgp log-neighbor-changes
no synchronization
network 48.151.4.0/23
neighbor 173.45.248.97 remote-as 45975
neighbor 173.45.248.97 description UPLINK_ROSTELEKOM


Всем спасибо за советы и помощь

[root]

Конфиги quagga

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

[linx]

Я не дипломированный специалист, тока учусь. BGP -знаком ток по книге с отсюда, дополнил конфиги до такого вида, по статье. Немного не понимаю что соответствует этим цифрам _65[0-9][0-9][0-9]_ Мне кажется их нужно набирать исходя из используемых в AS IP адресов

в документации вроде:
Unique alpha-numeric name that identifies the regular expression access list. List names can be up to 255 characters in length and contain the following characters: A-Z, a-z, 0-9, _, and -. Use the show ip as-path-access-list to display the names of all defined as-path access lists.

Код: Выделить всё

hostname AS123456
password zebra
enable password zebra
log file /var/log/bgpd.log
router bgp 123456
bgp router-id 173.45.248.98
bgp log-neighbor-changes
no synchronization
network 48.151.4.0/23
neighbor 173.45.248.97 remote-as 45975
neighbor 178.45.248.97 next-hop-self
neighbor 178.45.248.97 route-map ROSTELEKOM_IN in
neighbor 178.45.248.97 route-map ROSTELEKOM_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 48.151.4.0/23 le 32
ip prefix-list upstream-out seq 10 permit 48.151.4.0/23
!
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 ROSTELEKOM_IN deny 100
match as-path 1
!
route-map ROSTELEKOM_IN deny 110
match ip address prefix-list bogons
!
route-map ROSTELEKOM_IN deny 115
match ip address prefix-list default
!
route-map ROSTELEKOM_IN deny 120
match ip address prefix-list our-CIDR-blocks
!
route-map ROSTELEKOM_IN permit 200
set local-preference 100
!
route-map ROSTELEKOM_OUT permit 100
match ip address prefix-list upstream-out
!
route-map ROSTELEKOM_OUT deny 200


[root]

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

Немного не понимаю что соответствует этим цифрам _65[0-9][0-9][0-9]_

это шаблон as-path для номеров "серых" (privаt) атономок, которые не маршрутизируются в Инете.
есть "серые" подсети, есть и "серые" ASки.

Мне кажется их нужно набирать исходя из используемых в AS IP адресов

их нужно набирать если не хочешь чтобы тебе кто то всучил "левый" маршрут, по которому твой роутер начнет радостно сливать трафик.

в документации вроде

почитай про Regular Expressions и Using Regular Expressions in BGP

ip prefix-list bogons seq 15 permit 0.0.0.0/8 le 32

это отфильтрует маршрут default gateway, сам решай нуна тебе его фильтровать или нет

neighbor 178.45.248.97 next-hop-self

это можно удалить, т.к. эта команда относится к iBGP пиру, а в твоем случае это eBGP пир

лучше добавь:

Код: Выделить всё

neighbor 178.45.248.97 soft-reconfiguration inbound

так же:

Код: Выделить всё

bgp router-id 81.26.168.226

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

[simpl3x]

Добрый день,
в развитие темы, занимаемся подобным вопросом, хотим разделить /22 на /24 и анонсировать их из разных населенных пунктов.
с объектами в ripe вроде как понятно.
теоретическая часть вопроса понятна, каждый бордер будет вещать свою /24 сетку.
вопрос в том, стоит ли поднимать между бордерами тунель и iBGP. вопрос родился из ответа на другом ресурсе:

Есть одно НО, скажем фильтры по RIPE, когда подобная "нарезанная" сеть будет отфильтрована, из-за несоотвествия RIPE-объекта и анонсируемого блока. Проще делать туннель и строить iBGP, после чего анонсировать все сети с обеих машин.

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

[root]

в RIPE создаются все объекты route подо все анонсируемые сети и не важно агрегированный это префикс или more specific префикс.
например есть префикс /23 и его разбили на два /24, соответственно в RIPE должны быть три объекта route /23,/24,/24

вопрос в том, стоит ли поднимать между бордерами тунель и iBGP. вопрос родился из ответа на другом ресурсе:

стоит поднимать iBGP сессию в случае если между бордерами прямой провод, а не туннель, пригодится для резервирования канала.
В этом случае каждому апстриму анонсируется два префикса:
/23 - агрегированный префикс
/24 - префикс за который отвечает данный бордер
Таким образом при наличии iBGP сессии, правильной настройке и падении канала к апстриму на одном из бордеров трафик к нему (подсети /24 за ним) польётся через другой бордер.
Если туннель между бордерами строится через Инет, то он бессмысленен, т.к. связность нарушится при падении канала у одного из бордеров.

что можно добиться таким решением?

ничего, читай выше

можно ли анонсировать подобным образом сети меньше чем /24?

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

[simpl3x]

спасибо.

[Dgoni_sp]

В продолжение темы наверное многие с этим ещё столкнутся.
За весь период подключили 3 города, для каждого выделелялась сеть /24 объявлялась с одним и тем же номером AS.
При подключении нового города, например последнего делал:
1. Создавал объект route для новой сети, тем самым привязывал её к AS
2. В объекте aut-num своей ASN добавлял поля import и export, указывая что от ASN (новый пров) буду принимать то-то, а отдавать такому-то ASN (новый пров) такую-то ASN (свою).
Всё работает.
Но вот пришло письмо, цитирую

Dear Colleagues,

Six months ago you received your first allocation from the RIPE NCC. Always half a year later we review the registry if we can raise their Assignment Window (AW).

http://www.ripe.net/info/faq/db/aw.html

These are the criterias to receive an AW:

# The LIR's understanding of RIPE NCC assignment policies and procedures
# Whether request documentation presented to the RIPE NCC is completed correctly
# Whether the LIR demonstrates good judgment when evaluating address space requests
# If the LIR's past assignments have been registered correctly in the RIPE Database


Unfortunately, we noticed that you have not fully registered the below assignment that was approved by the RIPE NCC on 20110325 in the RIPE Database:

Netname Approved In DB %
------------------------------------------------------------------------------
RISONE-SPB-NET 768 0 00% => NCC#2011023200


- Is this approval still needed?

If yes, then please register the /3,/24 assignment to network RISONE-SPB-NET in the RIPE Database.

To register the assignment you can use the web updates:
https://apps.db.ripe.net/webupdates/select-type.html

1- Select the 'inetnum' object in the box under "Object Type"
2- fill in all the necessary fields.
3- Add the clear text password for your maintainer GV65889-MNT
4- Submit the object


- If you have made any other assignment please let us know.


After this issue will be solved we can review the raise of your AW.


We look forward to your reply.

Best Regards,

[Dgoni_sp]

Как я понял, (перевод немного корявый но суть вроде ясна)

Дорогие Коллеги,

Шесть месяцев назад Вы получили свое первое выделение от RIPE NCC. Всегда половину года спустя мы рассматриваем реестр, если мы можем повысить их Окно Присвоения (AW).

http://www.ripe.net/info/faq/db/aw.html

Они - criterias, чтобы получить AW:

# Понимание LIR политик присвоения RIPE NCC и процедур
# Завершена ли документация запроса, представленная RIPE NCC, правильно
# Демонстрирует ли LIR хорошее суждение при оценке запросов адресного пространства
# Если прошлые присвоения LIR были зарегистрированы правильно в RIPE Базе данных


К сожалению, мы заметили, что Вы не полностью зарегистрировались ниже присвоения, которое было одобрено RIPE NCC по заявке 20110325 в RIPE Базе данных:

Netname, Одобренный В БД %
------------------------------------------------------------------------------
RISONE-SPB-NET 768 0 00% => NCC#2011023200

- Это одобрение все еще необходимо?

Если да, то, пожалуйста, зарегистрируйте/3,/24 присвоение, чтобы объединить RISONE-SPB-NET в сеть в RIPE Базе данных.

Чтобы зарегистрировать присвоение, Вы можете использовать веб-обновления:
https://apps.db.ripe.net/webupdates/select-type.html

1-Выборов 'inetnum' возражают в поле под "Объектным Типом"
2-заполняют все необходимые поля.
3-Добавляют пароль в виде открытого текста для Вашего обслуживающего GV65889-MNT
4-Представляют объект

- Если Вы заставили присвоение по возможности сообщить нам.

После того, как эта проблема будет решена, мы можем рассмотреть повышение Вашего AW.
Мы с нетерпением ждем Вашего ответа.
Наилучшие пожелания,

[Dgoni_sp]

Теперь понимаю, что 6 месяцев назад, когда RIPE нам выделил сеть 31.22.8.0 - 31.22.15.255 (2044 IP) она находилась в состоянии ALLOCATED PA.
Цитирую

We have allocated the following prefix of IPv4 address space
to your registry ru.risone:

31.22.8.0/21

inetnum: 31.22.8.0 - 31.22.15.255
netname: RU-RISONE-20110325
descr: Closed Joint-Stock Company "Rigional Internet Networks"
country: RU
org: ORG-CJCI1-RIPE
admin-c: GV3867-RIPE
tech-c: GV3867-RIPE
status: ALLOCATED PA
mnt-by: RIPE-NCC-HM-MNT
mnt-lower: GV65889-MNT
mnt-routes: GV65889-MNT
notify: e.goley@risone.ru
changed: hostmaster@ripe.net 20110325
source: RIPE

Потом наш менеджер в RIPE отписался

The RIPE NCC has approved the assignment of a /23,/24 range of
768 addresses to the network RISONE-SPB-NET.

** What you must do now ***

1. Make an assignment from the address space allocated to ru.risone
2. Register the assignment in the RIPE Database:

https://www.db.ripe.net/webupdates

- use RISONE-SPB-NET as the netname for your inetnum object(s)
- do not add the date to the changed line. The Database will add
the date for you
- do not exceed 768 IPs in the range
- Note: the approval can be split over several IP ranges

http://www.ripe.net/info/faq/rs/main.html#5


If you ever change the netname from RISONE-SPB-NET to something else,
you must inform <hostmaster@ripe.net>. Just reply to this
message with details of the change.


Kind regards,

Т.е нам разрешают использовать только диапазон 31.22.8.0 - 31.22.10.255