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

Метки статьи: ‘Cisco Systems’

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

Продолжим обустройство нашей AS5350 и VoIP сети 🙂

Задача

Автоматизация управления VoIP dialpeer’ами на Cisco AS5350.

Решение

Протокол snmp уже используется для отображения картины загрузки потоков (OID: 1.3.6.1.4.1.9.10.19.1.1.9.1.3.номер_слота.номер_порта), то было принято решение управлять по этому же протоколу. Воспользовавшись гуглом и  SNMP Object Navigator, были найдены нужные OID’ы:

Для работы с AS5350 по протоколу snmp воспользуемся утилитами snmpwalk и snmpset из пакета net-snmp.

Получить все диалпиры:

# snmpwalk -v1 -c RO-community -O n 192.168.68.3 .1.3.6.1.2.1.10.21.1.2.1.1.5

.1.3.6.1.2.1.10.21.1.2.1.1.5.11.244 = STRING: «(0072)?84990088048»
.1.3.6.1.2.1.10.21.1.2.1.1.5.12.243 = STRING: «84950003211»
.1.3.6.1.2.1.10.21.1.2.1.1.5.13.195 = STRING: «(0072)?84950003220»

….

.1.3.6.1.2.1.10.21.1.2.1.1.5.246.196 = STRING: «0003217»

Например, нас интересует номер 84950003211, поэтому разберем строку вывода для этого номера поподробнее:

.1.3.6.1.2.1.10.21.1.2.1.1.5.12.243 = STRING: «84950003211», где 12 — номер дилапира на Cisco, 243 — индекс интерфейса по snmp (ifIndex)

Далее, для выключения диалпира нам нужно на него передать команду shutdown, что можно сделать по протоколу snmp при помощи OID 1.3.6.1.2.1.2.2.1.7.ifIndex:

# snmpset -v1 -c WR-community 192.168.68.3 1.3.6.1.2.1.2.2.1.7.243 i 2

.1.3.6.1.2.1.2.2.1.7.243 = INTEGER: down(2)

для его включения:

# snmpset -v1 -c WR-community 192.168.68.3 1.3.6.1.2.1.2.2.1.7.243 i 1

.1.3.6.1.2.1.2.2.1.7.243 = INTEGER: up(1)

Принципиально наша задача решена. Как и на чем ее накодить — оставляем выбор за вами.

 

Перечислю несколько полезных OID’ов ([rw] — OID используется и для чтения и для записи):

  • 1.3.6.1.2.1.10.21.1.2.1.1.4.DialpeerNumber.ifIndex — destination pattern
  • 1.3.6.1.2.1.10.21.1.2.1.1.5.DialpeerNumber.ifIndex — answer address
  • 1.3.6.1.2.1.2.2.1.7.ifIndex [rw] — Состояние интерфейса

1:up
2:down

  • 1.3.6.1.4.1.9.9.63.1.2.4.1.5.ifIndex [rw] — huntstop

1:true

2:false

  • 1.3.6.1.4.1.9.9.63.1.2.4.1.4.ifIndex [rw] — preference
  • 1.3.6.1.4.1.9.9.63.1.2.4.1.2.ifIndex [rw] — max-conn
  • 1.3.6.1.4.1.9.9.63.1.2.3.1.4.ifIndex [rw] — session target
  • 1.3.6.1.4.1.9.9.63.1.2.3.1.1.ifIndex [rw] — session protocol

1:other
2:cisco
3:sdp
4:sip
5:multicast

  • 1.3.6.1.4.1.9.9.63.1.2.3.1.6.ifIndex [rw] — fax rate

1:none
2:voiceRate
3:fax2400
4:fax4800
5:fax7200
6:fax9600
7:fax14400
8:fax12000

  • 1.3.6.1.4.1.9.9.63.1.2.3.1.5.ifIndex [rw] — codec

1:g729r8000
2:g729Ar8000
3:g726r16000
4:g726r24000
5:g726r32000
6:g711ulawr64000
7:g711Alawr64000
8:g728r16000
9:g723r6300
10:g723r5300
11:gsmr13200
12:g729Br8000
13:g729ABr8000
14:g723Ar6300
15:g723Ar5300
16:g729IETFr8000
17:gsmeEr12200
18:clearChannel
19:g726r40000
20:llcc
21:gsmAmrNb

Если используется voice-class codec для задания группы кодеков, то OID вернет первый кодек из группы.

 

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

Автор:  Панфилов Алексей (lehis (at) subnets.ru)

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

Топология

В качестве бордера c7206-npe-g1, на него принимаю 2 фул от ISP1 и ISP2.
Один из клиентов , со своей AS ходит через меня анонсами в обоих аплинков…
Каналы на аплинков разной толщины :

  • ISP1 — 200 мб/с
  • ISP2 — 155 мб/с

Описание поставленной задачи

Клиент подписал договор со следующими условиями:

  • при нормальной работе обоих аплинков клиент работает только через ISP1
  • при падении ISP1 клиент работает через ISP2

При этом чтобы клиент не ел полосу у ISP2 я решил его туда не анонсировать пока не упадет ISP1 …

Решение

router bgp OurAS
~skip~
neighbor Peering_IP_Customer remote-as CustomerAS
neighbor Peering_IP_Customer update-source GigabitEthernet0/3
neighbor Peering_IP_Customer fall-over
neighbor Peering_IP_ISP2 remote-as ISP2AS
neighbor Peering_IP_ISP2 update-source POS1/0
neighbor Peering_IP_ISP1 remote-as ISP2AS
neighbor Peering_IP_ISP1 update-source GigabitEthernet0/2
neighbor Peering_IP_ISP1 fall-over
!
address-family ipv4
~skip~

описываем пир с абонентом

neighbor Peering_IP_Customer activate
neighbor Peering_IP_Customer default-originate
neighbor Peering_IP_Customer prefix-list Customer_in in
neighbor Peering_IP_Customer prefix-list Customer_out out

описываем пир с ISP2, юзаем Advertise Condition Т.е. пока есть маршрут полученный через ISP1 сети 217.150.32.0/19 не анонсировать сеть абонента

neighbor Peering_IP_ISP2 activate
neighbor  Peering_IP_ISP2 advertise-map Cus2ISP2 non-exist-map NON-EXIST

при этом в любом случае анонсировать свои сети

neighbor Peering_IP_ISP2 route-map ISP2-in in
neighbor Peering_IP_ISP2 route-map ISP2-out out

описываем пир с ISP1


neighbor Peering_IP_ISP1 activate
neighbor Peering_IP_ISP1 route-map ISP1-in in
neighbor Peering_IP_ISP1 route-map ISP1-out out
~skip~
exit-address-family
!

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

!
route-map ISP1-out deny 5
match ip address prefix-list lan
!
route-map ISP1-out permit 10
match ip address prefix-list ourAS.all
!
route-map ISP1-out permit 20
match ip address prefix-list CustomerAS
!

тоже самое на второго апстрима

route-map ISP2-out deny 5
match ip address prefix-list lan
!
route-map ISP2-out permit 10
match ip address prefix-list ourAS.all CustomerAS
!

роутмап для определения есть ли анонс интересующей нас сети через первый апстрим

route-map NON-EXIST permit 10
match ip address prefix-list ISP1-in-net
match as-path 1
!

собственно роутмап анонса клиента

route-map Cus2ISP2 deny 5
match ip address prefix-list lan
!
route-map Cus2ISP2 permit 10
match ip address prefix-list CustomerAS
!

префикс листы

ip prefix-list ourAS.all seq 5 permit our_net1/21 le 24
ip prefix-list ourAS.all seq 10 permit our_net2/21 le 24
!
ip prefix-list CustomerAS seq 5 permit customer_net/22
!

собственно сеть которую мониторим

ip prefix-list ISP1-in-net seq 5 permit 217.150.32.0/19
!

так как на этом роутере у нас используются дополнительные демоны динамической маршрутизации (eigrp + ospf), в случае ошибки эти сети !не будут анонсированы нашим апстримам и абоненту

ip prefix-list lan seq 5 permit 0.0.0.0/0
ip prefix-list lan seq 10 permit 10.0.0.0/8 le 32
ip prefix-list lan seq 15 permit 172.16.0.0/12 le 32
ip prefix-list lan seq 20 permit 192.168.0.0/16 le 32
!

as-path лист для фильтра номера автономки ISP1

ip as-path access-list 1 permit ^AS_ISP1_NUM$
!

Результат

При такой настройке получаем:

  1. наши сети анонсятся через обоих апстримов
  2. абонент анонсится
    • при нормальной работе ISP1 только через него
    • при падении ISP1 идет анонс через ISP2

При этом вы могли заметить что на ISP2 прописано анонсить route-map ISP2-out в данный роут-мап входит и подсеть абонента.
Но она не будет анонсироваться пока не выполниться условие advertise-map Cus2ISP2 non-exist-map NON-EXIST, что нам и требовалось.
З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Green

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

Назрел вопрос о реконфигурации AS5350, являющейся пограничным VoIP-шлюзом для существующей скромной (до 100 пиров) VoIP-сети.

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

Задачи

  1. Прием входящего трафика на свою номерную емкость через потоки Е1 от разных операторов.
  2. Пропуск исходящего трафика на Е1 разных операторов (например, в зависимости от ценовой политики).
  3. Формирование АОНа на основе префикса, подставленного перед набираемым номером, присланным из IP сети.
  4. Блокировка исходящих звонков с АОНами, не прописанными на AS5350.
  5. Блокировка входящих звонков на номера, не прописанные на AS5350.

Немного теории

Звонок, с точки зрения AS5350, состоит из двух частей (legs) — voip и pots. Если при поступлении звонка на AS5350 не находятся диалпиры, под которые могут попасть voip и pots части звонка, то будут использоваться системные диалпиры, отображаемые под номером ноль. Ниже приведены две схемы порядка прохождения звонков:

Входящий звонок из Е1

Входящий звонок из Е1

Исходящий звонок на Е1

Посмотреть распределение активных leg-ов по диалпирам можно командой:

show voice call status

CallID     CID  ccVdb      Port             DSP/Ch  Called #   Codec    Dial-peers
0x2B       12F1 0x6640CB84 3/0:D.30         1/3:1  *0007536    14400     66/2
0x32       1256 0x6640CB84 3/1:D.31         1/3:4  *0000579536 g711alaw  0/3

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

Настройка

pots-диалпир для входящего трафика из потоков Е1:

dial-peer voice 7 pots
description INBOUND-CALLS-VIA-E1
huntstop                                             //Нашли подходящий диалпир и останавливаем "охоту" на остальных :)
preference 10
incoming called-number .T        //Благодаря этой строке (.Т – любые набираемые номера) этот
//диалпир выбирается в качестве наиболее подходящего для входящего звонка из Е1
direct-inward-dial
no register e164

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

pots-диалпир для пропуска исходящего МГ/МН трафика (начинающегося с 8-ки: 8.Т) в поток Е1 (3/1) первого провайдера:

dial-peer voice 2 pots
description OUTBOUND-MGMN-CALL-VIA-E1-1
huntstop
destination-pattern 8.T
progress_ind setup enable 3
progress_ind progress enable 8
direct-inward-dial
port 3/1:D
no register e164

pots-диалпир для пропуска оставшегося исходящего трафика в поток Е1 (3/0) второго провайдера:

dial-peer voice 3 pots

description OUTBOUND-REMAINING-CALLS-VIA-E1-0
huntstop
preference 8
destination-pattern .T
progress_ind setup enable 3
progress_ind progress enable 8
direct-inward-dial
port 3/0:D
no register e164

Замечание:

Преференс этого диалпира должен быть больше, чем pots-диалпира 1001 (описание которого будет дано ниже), иначе входящие со стороны Е1 звонки будут пытаться выйти через Е1 3/0 (и получим мы isdn-switching, который в данном случае никому не нужен).

Тааакс… с pots-leg’ами разобрались, продолжим с voip-leg’ами.

voip-диалпир для «приема» входящего из IP-сети номера с префиксом 009901 перед набранным номером:

dial-peer voice 94 voip
description inbound_peer_4_380-00-01
translation-profile incoming CUT-PREFIX
codec g711alaw
incoming called-number 009901.T

Создадим профиль преобразования АОНа и набираемого номера:

voice translation-profile CUT-PREFIX
translate calling 121
translate called 120

Создадим правило преобразования набираемого (called) номера – «отрежем» лидирующий префикс 009901:

voice translation-rule 120
rule 8 /^009901\(.*\)/ /\1/ type any unknown

Создадим правило преобразования АОНа — заменим любой присланный АОН на нужный нам 380-00-01:

voice translation-rule 121
rule 12 /^.*/ /3800001/

Пример типичного voip-диалпира:

dial-peer voice 78 voip
description TYPICAL-VOIP-PEER
max-conn 2
answer-address 84953800000     // answer-address служит для выбора диалпира в качестве наиболее
// подходящего на основе АОНа звонка, пришедшего из IP-сети.
//В данном случае у нас АОН будет 89453800000
destination-pattern 3800000       // destination-pattern служит для выбора диалпира в качестве
//наиболее подходящего на основе набранного номера звонка, пришедшего из Е1.
session protocol sipv2
session target ipv4:192.168.68.6
dtmf-relay rtp-nte
codec g711alaw
no vad

Все, что нужно мы разрешили-описали, осталась блокировка «левых» звонков, т.е. тех звонков, что не подходят ни под один dial-peer описанные выше, для чего создадим voip-диалпир:

dial-peer voice 1001 voip
description BAD-AON-AND-CALLED-NUM
call-block translation-profile incoming BLOCK    //блокируем звонок из IP сети
huntstop
preference 7
destination-pattern .T
codec g711alaw
session target ipv4:10.10.10.10

По итогу отправляем входящий звонок из Е1 на адрес 10.10.10.10, который маршрутизируется в никуда.
М.б. кто-то предложит лучшее решение ? С удовольствием послушаем.

Маршрутизируем адрес в «/dev/null»:

ip route 10.10.10.10 255.255.255.255 Null0

Создадим профиль и правило трансляции для блокировки «левых» АОНов:

voice translation-profile BLOCK
translate calling 42
!
voice translation-rule 42
rule 1 reject /^.*/

Для понимания, как и какие диалпиры участвуют в «выборах» при звонке и кто из них «победил» вам поможет команда:

debug voice dialpeer all

Будьте аккуратны – ее вывод может быть очень объемным !

В «отслеживании» звонков в/из IP-сети вам поможет команда:

debug ccsip calls

В трассировке звонка через ISDN вам поможет команда:

debug isdn q931

Увидеть логирование отработки правил трансляции номеров вам поможет команда:

debug voice translation

Замечание:

не забывайте давать команду:

terminal monitor

для того, чтобы вывод дебага отображался у вас в консоли (если вы сидите на циске через telnet), иначе он будет тихо складироваться в буфер логов AS5350 и все 🙂

Выражаю благодарность за помощь в написании статьи Сергею Бабичеву ( ака zaikini )

Ссылки

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/guide/ftgwrepg.html

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

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

Столкнулся сегодня с задачей создания vlan с номером из диапазона с 1006  по 4094 включительно (extended-range vlan).
Все делается как обычно:


Switch(config)# vlan 1070
Switch(config-vlan)# name EXT_VLAN
Switch(config-vlan)# end

Но есть нюанс: VTP свитча у вас должен быть в режиме transparent, иначе (например, в режиме server) при выходе из режима конфигурирования влана свитч не создаст влан и будет сообщать об ошибке:

% Failed to create VLANs 1070
Failed due to unknown reason.
%Failed to commit extended VLAN(s) changes.
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 2, среднее: 4,00 из 5)
Загрузка...
Отправить на почту Отправить на почту

Рассмотрим пример настройки протокола BGP на оборудовании Cisco Systems.

В основном принципе настройка на Cisco ничем не отличается от настройки BGP на FreeBSD используя Quagga.

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

схема BGP

AS100 — наш номер ASки

5.5.0.0/20 — анонсируемый нами префикс (наш блок адресов)

AS200 — наш апстрим, который отдает нам full-view (полную таблицу маршрутов)

AS300 — наш privat peer (приватный пир), который отдает нам маршруты в свою AS и своего клиента AS400.

С чего начать ?

С настройки интерфейсов конечно.

GigabitEthernet3/0 — AS200
GigabitEthernet3/1 — AS300

Зайдите на router телнетом и перейдите в enable режим.

cisco# conf t
cisco(config)# interface GigabitEthernet3/0
cisco(config-if)# ip address 1.1.1.2 255.255.255.252
cisco(config-if)# interface GigabitEthernet3/1
cisco(config-if)# ip address 2.2.2.10 255.255.255.252
cisco(config-if)# exit

Добавим маршруты, сначала отправим туда, откуда не возвращаются :), маршруты в «серые сети»:


cisco(config)# ip route 10.0.0.0 255.0.0.0 Null0 254
cisco(config)# ip route 172.16.0.0 255.240.0.0 Null0 254
cisco(config)# ip route 192.168.0.0 255.255.0.0 Null0 254

Затем добавим маршрут на свой полный блок:


cisco(config)# ip route 5.5.0.0 255.255.240.0 Null0 254

Протокол BGP не будет анонсировать префикс, пока сам не узнает маршрут до него.
Именно для этого мы и создали этот маршрут, который будет присутствовать в таблице маршрутизации всегда.
Вы можете пророутить внутрь своей сети как полный блок (тогда маршрут в Null0 (нуль ноль) можно и не добавлять) так и его, побитые на подсети, части.  Например подсети по /21:

cisco(config)# ip route 5.5.0.0 255.255.248.0 10.0.0.2
cisco(config)# ip route 5.5.0.0 255.255.248.0 10.0.0.3

Где:

  • 10.0.0.2
  • 10.0.0.3

маршрутизаторы внутри сети. Ессно, что они должны быть доступны с маршрутизатора BGP.

Роутер всегда отправляет пакеты по маршруту с лучшим совпадением по маске, именно поэтому маршрут в Null0 и два маршрута, которые мы сделали выше, будут прекрасно сосуществовать и пакеты будут идти на хосты 10.0.0.2 и 10.0.0.3, т.к. у них более точное совпадение по маске.

Приступим к созданию необходимых route-map. Сначала начнем со всего «серого» (адресов и номеров AS).

Создадим необходимые prefix-list и as-path access-list.

Маршрут в default:
cisco(config)# ip prefix-list bogons description bogus nets
cisco(config)# ip prefix-list bogons seq 15 permit 0.0.0.0/8 le 32

Затем остальное:
cisco(config)# ip prefix-list bogons seq 20 permit 127.0.0.0/8 le 32
cisco(config)# ip prefix-list bogons seq 25 permit 192.0.2.0/24 le 32
cisco(config)# ip prefix-list bogons seq 30 permit 10.0.0.0/8 le 32
cisco(config)# ip prefix-list bogons seq 35 permit 172.16.0.0/12 le 32
cisco(config)# ip prefix-list bogons seq 40 permit 192.168.0.0/16 le 32
cisco(config)# ip prefix-list bogons seq 45 permit 169.254.0.0/16 le 32
cisco(config)# ip prefix-list bogons seq 50 permit 192.42.172.0/24 le 32
cisco(config)# ip prefix-list bogons seq 55 permit 198.18.0.0/15 le 32
cisco(config)# ip prefix-list bogons seq 60 permit 192.88.99.0/24 le 32
cisco(config)# ip prefix-list bogons seq 65 permit 224.0.0.0/4 le 32
cisco(config)# ip prefix-list bogons seq 70 permit 240.0.0.0/4 le 32

Теперь «серые» номера AS`ок:
cisco(config)# ip as-path access-list 1 permit _6451[2-9]_
cisco(config)# ip as-path access-list 1 permit _645[2-9][0-9]_
cisco(config)# ip as-path access-list 1 permit _64[6-9][0-9][0-9]_
cisco(config)# ip as-path access-list 1 permit _65[0-9][0-9][0-9]_

Создадим маршрутную карту на IN для AS200 (нашего апстрима).
Запрещаем маршруты с «серыми» номерами AS в as-path, то что матчит (разрешает (permit)) наш as-path access-list, то запрещает наша следующая маршрутная карта:

cisco(config)# route-map map-AS200-in deny 100
cisco(config-route-map)# description — filter private ASs
cisco(config-route-map)# match as-path 1
cisco(config-route-map)# exit

Теперь по маршруту по умолчанию и «серым» сетям, логика действия как и в пред. случае, запрещаем то что permit в prefix-list bogons:

cisco(config)# route-map map-AS200-in deny 110
cisco(config-route-map)# description — — filter bogons
cisco(config-route-map)# match ip address prefix-list bogons
cisco(config-route-map)# exit

Ну и последнее, т.к. мы хотим принимать от AS200 full-view (т.е. полную таблицу), то:

  • разрешаем все остальные маршруты
  • выставляем local-preference по умолчанию внутри своей AS

cisco(config)# route-map map-AS200-in permit 200
cisco(config-route-map)# description — permit any else, set default loc-pref
cisco(config-route-map)# set local-preference 100
cisco(config-route-map)# exit

Создадим маршрутную карту на OUT для AS200 (нашего апстрима). Эта маршрутная карта нужна нам для того, чтобы наша AS анонсировала только свой префикс. Если маршрутной карты на OUT не будет, то ваша AS будет анонсировать всем своим соседям все известные ей маршруты и вы, сами того не желая, дадите возможность прогонять через вас трафик.
Но прежде создадим префикс лист со своим префиксом:

cisco(config)# ip prefix-list own-prefixes permit 5.5.0.0/20

Вот теперь вернемся к маршрутке на OUT:

cisco(config)# route-map map-AS200-out permit 100
cisco(config-route-map)# description — permit our prefixes
cisco(config-route-map)# match ip address prefix-list own-prefixes
cisco(config-route-map)# exit

Т.к. в конце маршрутки по умолчанию идет неявный deny, то все остальные префиксы (маршруты) будут запрещены.

Настало время приступить к маршрутным картам для нашего private peer`а.
Т.к. от него мы собираемся получать только маршруты принадлежащие ему (AS300) и его клиенту (AS400), то будет проще, разрешим только необходимые префиксы, а все остальное запретим:

cisco(config)# ip prefix-list peer-prefixes permit 11.11.0.0/21
cisco(config)# ip prefix-list peer-prefixes permit 12.12.0.0/21

Теперь можно создать маршрутную карту на IN, в которой разрешим необходимые префиксы и поднимем loc-pref, на данные префиксы, чтобы маршруты полученные от этого пира имели приоритет над маршрутами к этим префиксам полученными от других апстримов/пиров:

cisco(config)# route-map map-AS300-in permit 100
cisco(config-route-map)# description — — permit peer prefix
cisco(config-route-map)# match ip address prefix-list peer-prefixes
cisco(config-route-map)# set local-preference 200
cisco(config-route-map)# exit

Ну и тут не обойдется без маршрутной карты на OUT:

cisco(config)# route-map map-AS300-out permit 100
cisco(config-route-map)# description — permit our prefixes
cisco(config-route-map)# match ip address prefix-list own-prefixes
cisco(config-route-map)# exit

Зачем мы создали две маршрутные карты на OUT с разными названиями, но с одинаковым содержимым ?
Ответ прост. Если, в последствии, нам нужно будет, например добавить community к своему маршруту или оглашать свой блок меньшими подсетями, то все равно придется делать разные маршрутные карты, вот поэтому сделаем это сразу, чтобы потом не изменять конфигурацию bgp, а просто подправить маршрутную карту.

Закончим подготовку перед настройкой BGP:

cisco(config)# ip classless
cisco(config)# ip routing
cisco(config)# ip subnet-zero

Подготовку мы сделали, теперь можно переходить непосредственно к настройке и запуску BGP.

cisco(config)# router bgp 100
cisco(config-router)# no synchronization
cisco(config-router)# bgp log-neighbor-changes
cisco(config-router)# bgp deterministic-med

Объявим наш префикс:
cisco(config-router)# network 5.5.0.0 mask 255.255.240.0

Пропишем наего апстрима AS200:
cisco(config-router)# neighbor 1.1.1.1 remote-as 200
cisco(config-router)# neighbor 1.1.1.1 description AS200-upstream
cisco(config-router)# neighbor 1.1.1.1 send-community
cisco(config-router)# neighbor 1.1.1.1 version 4
cisco(config-router)# neighbor 1.1.1.1 soft-reconfiguration inbound
cisco(config-router)# neighbor 1.1.1.1 route-map map-AS200-in in
cisco(config-router)# neighbor 1.1.1.1 route-map map-AS200-out out

Пропишем нашего private peer`а:
cisco(config-router)# neighbor 2.2.2.9 remote-as 300
cisco(config-router)# neighbor 2.2.2.9 description AS300-private-peer
cisco(config-router)# neighbor 2.2.2.9 send-community
cisco(config-router)# neighbor 2.2.2.9 version 4
cisco(config-router)# neighbor 2.2.2.9 soft-reconfiguration inbound
cisco(config-router)# neighbor 2.2.2.9 route-map map-AS300-in in
cisco(config-router)# neighbor 2.2.2.9 route-map map-AS300-out out

Заканчиваем:
cisco(config-router)# distance bgp 180 200 200
cisco(config-router)# no auto-summary
cisco(config-router)# exit
cisco(config)# exit
cisco# wri

После запуска посмотрите, что все настроенные BGP сессии поднялись. Команда:
cisco# show ip bgp summary

Так же стоит взгянуть что именно мы огласили нашему апстриму:
cisco# show ip bgp neighbors 1.1.1.1 advertised-routes

И нашему private peer`у:
cisco# show ip bgp neighbors 2.2.2.9 advertised-routes

Можно взглянуть и что мы от них получили:
cisco# show ip bgp neighbors 1.1.1.1 received-routes
cisco# show ip bgp neighbors 2.2.2.9 received-routes

После того как вы убедились, что все соответствует задуманному можно расслабиться и выпить пива 🙂


Заметка:
После каждого изменения route-map, в процессе работы, чтобы изменения вступили в силу необходимо оборвать (clear`нуть) BGP сессию с сосседом. Для того чтобы этого не делать и существует команда soft-reconfiguration inbound при настройке neighbor. Она заставляет роутер хранить маршруты полученные от соседа не только после обработки вашими route-map, но и до этого.
Тем самым вы не обрываете сессию с соседом, а роутер просто берет сохраненные у себя маршруты, которые пришли от соседа и сохранены в первозданном виде ДО обработки вашими route-map и снова прогоняет их через уже измененную route-map.
Например вы изменили route-map map-AS200-in, значит нуна клирнуть сессию с соседом IP-адрес 1.1.1.1.
cisco# clear ip bgp 1.1.1.1 soft in


Заметка:
Если вы хотите принимать от BGP соседа маршруты не более определенной маски, то необходимо создать prefix-list с указанием le или ge:

  • eq — Matches the exact prefix length
  • ge — Matches a prefix length that is equal to or greater than the configured prefix length
  • le — Matches a prefix length that is equal to or less than the configured prefix length

Например: принимать все маршруты с любым префиксом, но не более /24:
cisco(config)# ip prefix-list prefix-range seq 5 permit 0.0.0.0/0 le 24
cisco(config)# route-map peer-in permit 200
cisco(config-route-map)# match ip address prefix-list prefix-range


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

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

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