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

Метки статьи: ‘bgp’

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

Ссылка на новость: http://uinc.ru/news/sn22174.html

Попытки решить проблемы с нехваткой IPv4 адресов поставили Всемирную Сеть перед новой значительной проблемой — переполнением глобальной таблицы BGP-маршрутов. В настоящее время глобальная таблица маршрутов BGP на некоторых системах преодолела отметку в 512 тысяч записей, что начало приводить к разнообразным локальным проблемам со связностью. Ожидается, что своего пика проблема достигнет на следующей неделе, когда с переполнением столкнётся большинство провайдеров. Суть проблемы в том, что в процессе оптимизации пространства IPv4-адресов, провайдерам стали выделяться небольшие подсети, что привело к росту размера глобальной таблицы маршрутов BGP. При этом во многих устаревших, но ещё находящихся в эксплуатации, маршрутизаторах Cisco и некоторых других производителей для BGP-таблицы глобальных маршрутов IPv4 по умолчанию установлено ограничение в 512K элементов, что обусловлено размером TCAM-памяти, в которой размещается таблица маршрутов. Например, проблеме подвержены серии Cisco 7600, Cisco ASR 9000 с картами Trident, Cisco ASR 1000 с 4GB ОЗУ, Cisco Catalyst 6500. В зависимости от используемого маршрутизатора переполнение таблицы может привести к разным эффектам, от краха маршрутизатора до выпадания маршрутов и других проблем со связностью. В основном пострадают операторы связи, вынужденные использовать устаревшее оборудование. Крупные провайдеры уже перешли на современные модели маршрутизаторов, которые избавлены от упомянутых ограничений. Проблема также не повлияет на стабильность глобальной системы маршрутизации и будет ограничена только локальными проблемами со связностью у операторов, использующих устаревшие маршрутизаторы. Проблема уже привела к простою в работе таких компаний, как eBay, Comcast, Time-Warner, LastPass, Liquid Web. Так как TCAM-память разделена для таблиц IPv4 и IPv6, одним из решений является выделение дополнительной памяти для таблицы IPv4 за счёт урезания размера таблицы IPv6, но данная манипуляция («mls cef maximum-routes ip 1000») требует перезагрузки маршрутизатора. В настоящее время размер таблицы для IPv6 составляет менее 20 тысяч записей. 

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (Еще не голосовали)
Loading...Loading...
Отправить на почту Отправить на почту

В продолжении предыдущей статьи Juniper и Policy-based routing ( PBR ) появилась задача когда необходимо чтобы маршруты из таблицы inet.2 (mBGP) попадали не только в нее, но и в таблицу inet.0 (eBGP).

Расскажу и покажу как это сделали мы.

Дано

  • MX80 (JUNOS 10.4R1.9)
  • апстрим с двумя BGP сессиями eBGP и mBGP

Задача

Импортировать маршруты принимаемые в сессии mBGP (роутинг таблица inet.2) в таблицу сессии eBGP (таблица inet.0).

Реализация

Состояние ДО изменений:

Для примера возьмем маршрут до подсети 11.11.11.192/28.
Посмотрим текущий маршрут до этой подсети:

juniper-MX80> show route terse 11.11.11.192
inet.2: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 11.11.11.192/28  B 170        100            >20.20.20.209   65500 I

Видим что данный маршрут находится только в таблице inet.2, это то мы и будем «исправлять».

Приступим. Как и в случае с PBR нам поможет механизм rib-groups.
Создадим rib группы:

routing-options {
    rib-groups {
        bgp-multicast-rg {
            export-rib inet.2;
            import-rib [ inet.2 inet.0 ];
        }
        bgp-unicast-rg {
            export-rib inet.0;
            import-rib inet.0;
        }
    }
}

Мы создали две rib группы: одну для unicast, другую для multicast. В rib группе multicast в import-rib мы указали, что принимаемые маршруты нужно импортировать и в таблицу inet.0.

Теперь опишем эти rib группы в protocols bgp:

protocols {
    bgp {
        family inet {
            unicast {
                rib-group bgp-unicast-rg;
            }
            multicast {
                rib-group bgp-multicast-rg;
            }
        }
    }
}

Ну и сами BGP пиры, один eBGP, другой mBGP:

protocols {
    bgp {
        log-updown;
        local-as 65000;
        group ebgp {
            type external;
            no-advertise-peer-as;
            neighbor 10.10.10.229 {
                description eBGP_peer;
                import bgp-import;
                family inet {
                    unicast;
                }
                export bgp-export;
                peer-as 65500;
            }
        }
        group mbgp {
            type external;
            no-advertise-peer-as;
            neighbor 20.20.20.209 {
                description mBGP_peer;
                import bgp-mcast-import;
                family inet {
                    multicast;
                }
                export bgp-mcast-export;
                peer-as 65500;
            }
        }
    }
}

После commit`а смотрим появился ли маршрут в таблице inet.0:

juniper-MX80> show route terse 11.11.11.192

inet.0: 51 destinations, 51 routes (44 active, 0 holddown, 7 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 11.11.11.192/28  B 170        100            >20.20.20.209   65500 I

inet.2: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 11.11.11.192/28  B 170        100            >20.20.20.209   65500 I

А вот теперь мы видим что наш маршрут присутствует в двух таблицах, что нам и было надо.

Ссылки

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

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

 

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

Сегодня ночью обнаружилось, что один из апстрим каналов начал играть в «ванька-встанька».

BGP сессия падала, поднималась, снова падала, снова поднималась и так до бесконечности.

В логах BGP читалось:

Sep  9 00:26:59.219845 RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer XX.XX.XX.141 (External AS XXXX) changed state from Established to Idle (event RecvUpdate)
Sep  9 00:27:03.460183 bgp_read_v4_update:8189: NOTIFICATION sent to XX.XX.XX.141 (External AS XXXX): code 3 (Update Message Error) subcode 11 (AS path attribute problem)
Sep  9 00:27:39.219859 RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer XX.XX.XX.141 (External AS XXXX) changed state from OpenConfirm to Established (event RecvKeepAlive)

В messages:

Sep  9 00:27:33  rpd[1153]: XX.XX.XX.141 (External AS XXXX) Received BAD update for family inet-unicast(1), prefix 212.118.142.0/24

Полез разбираться, читаем:
BGP Notification Message Error Codes and Error Subcodes

Table 142: BGP Notification Message Error Codes  

Error
Code
Value
Code Name Description
1 Message Header
Error
A problem was detected either
with the contents or length of the BGP header. The Error Subcode
provides more details on the nature of the problem.
2 Open
Message Error
A problem was
found in the body of an Open message. The Error Subtype field
describes the problem in more detail. Note that authentication failures
or inability to agree on a parameter such as hold time are included
here.
3 Update Message
Error
A problem was found in the body
of an Update message. Again, the Error Subtype provides
more information. Many of the problems that fall under this code are
related to issues detected in the routing data or path attributes sent
in the Update message, so these messages provide feedback about
such problems to the device sending the erroneous data.
4 Hold
Timer Expired
A message was
not received before the hold time expired.
See
the description of the Keepalive message for details on this timer
.
5 Finite State
Machine Error
The BGP finite state machine
refers to the mechanism by which the BGP software on a peer moves from
one operating state to another based on events (
see
the TCP finite state machine description for some background on this
concept
). If an event occurs that is unexpected
for the state the peer is currently in, it will generate this error.
6 Cease Used when a
BGP device wants to break the connection to a peer for a reason not
related to any of the error conditions described by the other codes.

Table 143: BGP Notification Message Error Subcodes  

Error
Type
Error
Subcode Value
Subcode
Name
Description
Message
Header Error (Error Code 1)
1 Connection Not
Synchronized
The expected value in the Marker
field was not found, indicating that the connection has become unsynchronized.
See
the description of the Marker field
.
2 Bad
Message Length
The message
was less than 19 bytes, greater than 4096 bytes, or not consistent with
what was expected for the message type.
3 Bad Message
Type
The Type field of the
message contains an invalid value.
Open
Message Error (Error Code 2)
1 Unsupported
Version Number
The device
does not “speak” the version number its peer is trying to
use.
2 Bad Peer AS The router doesn’t recognize
the peer’s autonomous system number or is not willing to communicate
with it.
3 Bad
BGP Identifier
The BGP Identifier
field is invalid.
4 Unsupported
Optional Parameter
The Open message contains
an optional parameter that the recipient of the message doesn’t understand.
5 Authentication
Failure
The data in
the Authentication Information optional parameter could not be
authenticated.
6 Unacceptable
Hold Time
The router refuses to open a
session because the proposed hold time its peer specified in its Open
message is unacceptable.
Update
Message Error (Error Code 3)
1 Malformed
Attribute List
The overall
structure of the message’s
path
attributes
is incorrect, or an attribute
has appeared twice.
2 Unrecognized
Well-Known Attribute
One of the mandatory well-known
attributes was not recognized.
3 Missing
Well-Known Attribute
One of the
mandatory well-known attributes was not specified.
4 Attribute Flags
Error
An attribute has a flag set to
a value that conflicts with the attribute’s type code.
5 Attribute
Length Error
The length
of an attribute is incorrect.
6 Invalid Origin
Attribute
The Origin attribute has
an undefined value.
7 AS
Routing Loop
A routing loop
was detected.
8 Invalid Next_Hop
Attribute
The Next_Hop attribute
is invalid.
9 Optional
Attribute Error
An error was
detected in an optional attribute.
10 Invalid Network
Field
The Network Layer Reachability
Information
field is incorrect.
11 Malformed
AS_Path
The AS_Path
attribute is incorrect.

Такс… приехали…

При помощи своего апстрима удалось выяснить что действительно мне и многим другим другим поднасрал Saudi Telecom и анонсируемый им префикс 212.118.142.0/24.
О чем свидетельствуют мои логи, рассказ апстрима о проблемах и у других его клиентов, а так же:  Saudi Telecom sending route with invalid attributes 212.118.142.0/24:

anyone else getting a route for 212.118.142.0/24 with invalid
attributes? Seems this is (again) causing problems with some (older)
routers/software.

Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
6-Resolve tree 2
AS path: 6453 39386 25019 I Unrecognized Attributes: 39
bytes
AS path: Attr flags e0 code 80: 00 00 fd 88 40 01 01 02
40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40 05 04
00 00 00 64
Accepted Multipath

-Jonas

Ответ:

Exactly the same here.

Sep 8 20:24:04 BBD-RC02 rpd[1334]: Received BAD update from
94.228.128.57 (External AS 41887), aspath_attr():3472
PA4_TYPE_ATTRSET(128) => 1 times IGNORED, family inet-unicast(1), prefix
212.118.142.0/24

Bye,
Raymond.

Смотрим инфу в RIPE:

% Information related to '212.118.140.0/22AS25019'
route: 212.118.140.0/22
descr: Saudi Arabia backbone and local registry address space / STC
remarks: for any Abuse or Spamming Please send an e-mail to abuse@saudi.net.sa
origin: AS25019
mnt-by: saudinet-stc
source: RIPE # Filtered

% Information related to '212.118.140.0/22AS39891'
route: 212.118.140.0/22
descr: Saudi Arabia backbone and local registry address space / STC
origin: AS39891
mnt-by: saudinet-stc
source: RIPE # Filtered

О как, за двумя ASками данный префикс числится. Красавцы, чего тут сказать.

Отфильтровав этот префикс к чертям собачьим, BGP сессия сразу же перестала падать. Вечером та же участь постигла и другого апстрима.

Т.к. к вечеру я уже реально задолбался, то взял отфильтровал нафиг по as-path обе аски  AS39891 и AS25019. Пусть саудовский телеком идет лесом и уже научится пользоваться BGP фильтрами.

Вот так один «олень» может доставить гемороя многим во всем мире.

З.Ы. Junos:

    JUNOS Base OS Software Suite [9.4R1.8]
    JUNOS Kernel Software Suite [9.4R1.8]

Пролеме точно подвержены Junos`ы версии 9.4 и ниже, update JunOS`а ждет меня и не только меня :)



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

Используем BIRD (Internet Routing Daemon) для создания «пограничного» маршрутизатора.

Итак, у нас появилась собственная автономная система и блок /23 PI адресов. Возник вопрос, что использовать для анонсирования своей AS и блока адресов, какое железо?
Клиенты использующие сеть для доступа к Интернет потребляют трафик порядка 300-400Мб/с. Ценник на «железный» роутер для таких задач будет от 400К рублей, поэтому было принято решение — используем opensource и имеющийся в наличии сервер HP Proliant DL140 G3 с двумя 2-х ядерными процессорами и 2Гб оперативной памяти. Используемая ОС — CentOS 5, а в качестве демона маршрутизации был выбран, после некторых тестов и сравнений, — BIRD. На используемом сервере установлена версия 1.2.4 (процесс установки описан здесь).

Описание схемы сети.

Смотрим рисунок. Сеть подключается через наш «пограничный» маршрутизатор к двум провайдерам, один из них AS65002 — основной, второй AS65001 — резервный, со вторым очень дружественные взаимоотношения и он по доброте душевной бесплатно транзитит наш трафик на точку обмена трафиком и обратно, таким образом, мы немного (а иногда и 50%) экономим на оплате трафика основному провайдеру. Наша AS — AS6500 и полученный префикс — zzz.zzz.zzz.0/23. Внутри нашей AS работает протокол OSPF (выбран исходя из того, что роутеры на базе opensource в сети будут появляться чаще, чем роутеры Cisco).  От обоих провайдеров мы получаем full-view. Дополнительно, второй провайдер (AS65001) «красит» маршруты с точки обмена трафиком с помощью community — 65001:1400. Для того, чтобы избежать ошибок с получением маршрута по умолчанию от провайдеров, мы сами его с пограничного маршрутизатора объявляем внутрь сети (тем самым, кстати гарантируем, что трафик на несуществующие префиксы не будет уходить дальше нашего роутера).  Стыковая  сеть с провайдером AS65002 — y.y.y.0/30, стыковая сеть с провайдером AS65001 — x.x.x.0/30. Внутри сети между роутерами используется сеть z.z.z.0/28.

Подготовка к созданию конфигурации BIRD, коротко о BIRD.

С документацией по использованию BIRD можно ознакомиться здесь. Самое основное в понимании работы с BIRD — это представление о таблицах маршрутизации и протоколах, которые работают с этими таблицами. BIRD поддерживает работу протоколов BGPv4, RIPv2, OSPFv2, OSPFv3 и виртуального протокола Pipe  для обмена маршрутами между различными таблицами маршрутизации. Для всех протоколов реализована работа с IPv6.  Между таблицей маршрутзации и протоколом устанавливаются два фильтра export и import, которые могут принимать, блокировать или изменять получаемую и передаваемую информацию из таблицы в протокол и обратно. Export — направление от таблицы к протоколу, import — в обратную сторону. Когда маршрут передается из протокола в таблицу, его стоимость пересчитывается и об этом оповещаются все протоколы, которые используют данную таблицу, после чего каждый протокол формирует update и рассылает сообщение согласно своему механизму оповещения об изменении маршрута.  По-умолчанию в BIRD существует таблица master, которая может использоваться всеми протоколами, если иное в конфигурации протокола не было указано. Кроме указанных выше протоколов, есть еще псевдопротокол kernel, отчечающий за синхронизацию между таблицами маршрутизации BIRD и ядра системы, протокол static — отвечающий за статическую маршрутизацию, протокол direct — создающий маршруты в BIRD на основе настроек сетевых интерфейсов полученных из ядра, и протокол device, отслеживающий состояниме интерфефсов в системе (up/down).

Составим список протоколов и их названий, которые мы будем использовать:
  • bgpAS65002 (в BIRD для работы с bgp соседом необходмо запустить отдельную «ветку» протокола) — для работы с основным провайдером;
  • bgpAS65001 — для работы с резервным провайдером;
  • ospfAS65000 — для обеспечения маршрутизации внутри сети;
  • static1 — понадобится для объявления маршрута по-умолчанию;
  • static2 — используем для объявления нашего «большого» префикса;
  • kernel — понадобится для передачи маршрутов из BIRD в систему;
  • direct и device — их назначение описано выше.

Т.к. конфигурация сети у нас довольно простая, будем использовать только одну таблицу маршрутизации — master.

Для составления конфигурационного файла, лучше все взаимосвязи сначала отразим на схеме:

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

Файл конфигурации BIRD.

/*

* This is an example configuration file.

*/

#Задаем формат времени для логирования
timeformat base     iso long;
timeformat log      iso long;
timeformat protocol iso long;
timeformat route    iso long;

#Указываем путь к лог-файлу
log «/var/log/bird.log» all;
log stderr all;

##### Начнем описание наших протоколов, некоторые описания взяты из дефолтного конфига

# The direct protocol automatically generates device routes to

# all network interfaces. Can exist in as many instances as you wish

# if you want to populate multiple routing tables with device routes.
protocol direct {

interface «eth*», «*»; # Restrict network interfaces it works with

}

# This pseudo-protocol watches all interface up/down events.
protocol device {

scan time 10; # Scan interfaces every 10 seconds

}

# This pseudo-protocol performs synchronization between BIRD’s routing

# tables and the kernel. If your kernel supports multiple routing tables

# (as Linux 2.2.x does), you can run multiple instances of the kernel

# protocol and synchronize different kernel tables with different BIRD tables.
protocol kernel {
persist off; # Don’t remove routes on bird shutdown
scan time 20; # Scan kernel routing table every 20 seconds
import none; # Default is import all
export all; # Default is export none
}

#Статический маршрут, необходимый для добавления маршрута по-умолчанию в таблицу master
protocol static static1 {

route 0.0.0.0/0 via «lo»;

}

#Статический маршрут для добавления нашего префикса в таблицу
protocol static static2 {

preference 253;

route zzz.zzz.zzz.0/23 via «lo»;

}
###Конфигурация протокола OSPF:

#Как мы описывали выше, мы должны объявить нашим ospf соседям маршрут по-умолчанию и маршруты типа directly, а в таблицу master должны передать маршруты полученные от ospf соседей, кроме дефолта

#для этого используем соответствующие фильтры:
filter import_OSPF {

if ( source = RTS_OSPF && net != 0.0.0.0/0 ) then {

print «net accepted:», net;

accept;

}

reject;

}

filter export_OSPF {
#Передаем маршруты connected
if ( source = RTS_DEVICE ) then {

print «net accepted:», net;

ospf_metric2 = 20;

accept;

}
#Передаем маршрут по умолчанию, т.к. он у нас «завернут» на интефрейс loopback, то необходимо использовать конструкцию RTS_STATIC_DEVICE, а не RTS_STATIC
if ( source = RTS_STATIC_DEVICE && net = 0.0.0.0/0 ) then {

print «net accepted:», net;

ospf_metric2 = 5;

accept;

}

reject;

}

#Конфигурация протокола OSPF
protocol ospf ospfAS65000 {

router id 87.244.8.18;

export filter export_OSPF;

import filter import_OSPF;

area 0.0.0.0 {

interface «eth1.4» {

hello 10;

retransmit 5;

cost 10;

transmit delay 1;

dead count 4;

wait 40;

type broadcast;

priority 0;

};

};

}
###

###Настройка BGP

#Задаем функцию, с помощью которой мы будем блокировать сети RFC1918, дефолт, префиксы короче /24, префиксы /32, /0 и /7, если они вдруг «прилетят» от bgp соседей
function avoid_nonexist()
#Описываем префикс-лист, по которому будет происходить проверка маршрутов
prefix set nonexist;

{

nonexist = [ 169.254.0.0/16+, 172.16.0.0/12+, 192.168.0.0/16+, 10.0.0.0/8+, 224.0.0.0/4+, 240.0.0.0/4+, 0.0.0.0/32-, 0.0.0.0/0{25,32}, 0.0.0.0/0{0,7} ];

if net ~ nonexist then return false;

return true;

}
#Задаем функцию, с помощью которой будем фильтровать маршруты из нашей AS
function pref_from_myasset()

prefix set pref_from_65000;

{

pref_from_65000 = [ zzz.zzz.zzz.0/23  ];

if net ~ pref_from_65000 then return true;

return false;

}

###Основной провайдер

##Отфильтровываем маршруты и устанавливаем local preference
filter prov65002in {

if avoid_nonexist() then

{

bgp_local_pref = 340; #устанавливаем local preference
accept;

}

reject;

}

filter prov65002out {

if pref_from_myasset() then

{

bgp_community = -empty-; #не отправляем никаких коммьюнити
bgp_path.prepend(65000); #добавляем prepend
accept;

}

reject;

}


protocol bgp bgpAS65002 {

table master;

router id yyy.yyy.yyy.2;

description «AS65002»;

local as 65000;

neighbor yyy.yyy.yyy.1 as 65002;

hold time 240;

startup hold time 240;

connect retry time 120;

keepalive time 80;

start delay time 5;

error wait time 60, 300;

error forget time 300;

next hop self;

path metric 1;

default bgp_med 0;

source address yyy.yyy.yyy.2;

export filter prov65002in;

import filter prov65002out;

}
###

###Резервный провайдер

##Отфильтровываем маршруты, устанавливаем local preference для маршрутов помеченных community на стороне второго провайдера
filter prov65001in {

if (65001,1400) ~ bgp_community then

{

bgp_local_pref = 400; # local preference для маршрутов отмеченных community 65001:400

accept;

}

bgp_local_pref = 330; #local preference для остальных маршрутов
if avoid_nonexist() then accept;

}


filter prov65002out {

if pref_from_myasset() then

{

bgp_community = -empty-;

accept;

}

reject;

}

protocol bgp bgpAS65001 {

table master;

router id xxx.xxx.xxx.2;

description «AS65001»;

local as 65000;

neighbor xxx.xxx.xxx.1 as 65001;

hold time 240;

startup hold time 240;

connect retry time 120;

keepalive time 80;

start delay time 5;

error wait time 60, 300;

error forget time 300;

next hop self;

path metric 1;

default bgp_med 0;

source address xxx.xxx.xxx.2;

export filter prov65002out;

import filter prov65002in;

}
###

/*

* The End

*/

Для проверки работы фильтров, состояния протоколов, маршрутов и т.п. в BIRD есть свой CLI:

# /usr/local/sbin/birdc

BIRD 1.2.4 ready.

bird> >?

configure [soft] [«<file>»]                    Reload configuration

debug …                                      Control protocol debugging via BIRD logs

disable <protocol> | «<pattern>» | all         Disable protocol

down                                           Shut the daemon down

dump …                                       Dump debugging information

echo [all | off | <mask>] [<buffer-size>]      Configure echoing of log messages

enable <protocol> | «<pattern>» | all          Enable protocol

exit                                           Exit the client

help                                           Description of the help system

mrtdump …                                    Control protocol debugging via MRTdump files

quit                                           Quit the client

reload <protocol> | «<pattern>» | all          Reload protocol

restart <protocol> | «<pattern>» | all         Restart protocol

restrict                                       Restrict current CLI session to safe commands

show …                                       Show status information

На этом пока все, буду рад, если эта статья кому-то пожет в работе))

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

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

Топология

В качестве бордера 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)
Loading...Loading...
Отправить на почту Отправить на почту