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

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

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

Ссылка на новость: 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 тысяч записей. 

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

Используем 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)
Загрузка...
Отправить на почту Отправить на почту

Топология

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

Задача

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

Иными словами нужно что бы эти три пира «жили» в своей таблице маршрутизации и не имели отношения к основной таблице маршрутизации.
Каждая таблица будет «жить» по своим законам и трафик будет ходить по своим маршрутам.

Имеем

  • Juniper M10i
  • JUNOS 10.1R1.8

Решение

Решить эту задачу нам поможет  routing-instances.

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

Читаем доку: Configuring Routing Instances

Первый возникающий вопрос это какого типа routing-instances нам нужен ? Смотрим описание:

  • forwarding—Provide support for filter-based forwarding, where interfaces are not associated with instances. All interfaces belong to the default instance. Other instances are used for populating RPD learned routes. See Configuring Filter-Based Forwarding.
  • l2vpn—Provide support for Layer 2 VPNs. For more detailed information about configuring VPNs, see the JUNOS VPNs Configuration Guide.
  • layer2-control—(MX Series routers only) Provide support for RSTP or MSTP in customer edge interfaces of a VPLS routing instance. For more detailed information about configuring RSTP and MSTP, see the JUNOS MX Series Ethernet Services Routers Layer 2 Configuration Guide
  • no-forwarding—This is the default routing instance. Do not create a corresponding forwarding instance.
  • virtual-router—Similar to a VPN routing and forwarding instance type, but used for non-VPN-related applications. There are no VRF import, VRF export, VRF target, or route distinguisher requirements for this instance type.
  • virtual-switch—(MX Series routers only) Provide support for Layer 2 bridging. Use this routing instances type to isolate a LAN segment with its Spanning Tree Protocol (STP) instance and separates its VLAN identifier space. For more detailed information about configuring a virtual switch, see the JUNOS MX Series Ethernet Services Routers Layer 2 Configuration Guide and the JUNOS MX Series Ethernet Services Routers Solutions Guide.
  • vpls—Virtual private local-area network (LAN) service. Use this routing instance type for point-to-multipoint LAN implementations between a set of sites in a VPN. For more information about configuring VPLS, see the JUNOS VPNs Configuration Guide.
  • vrf—VPN routing and forwarding instance. Provides support for Layer 3 VPNs, where interface routes for each instance go into the corresponding forwarding table only. For more information about configuring VPNs, see the JUNOS VPNs Configuration Guide.

To configure a routing instance type, include the instance-type statement:

routing-instances {
     routing-instance-name {
           interface interface-name;
           instance-type (forwarding | l2vpn | layer2-control | no-forwarding | virtual-router | virtual-switch | vpls | vrf);
     }
}

Если вы общались с железом от Cisco, то первое что вам бросится в глаза, так это знакомое слово VRF (либо вы уже слышали/настраивали VRF-lite).

В моем случае мне походит тип virtual-router, т.к. VPN`а у меня нет, а все что мне нужно это создать вторую, отдельную от основной, таблицу маршрутизации, которая будет действовать только в пределах данного роутера.

Приступим

Исходные данные для нашего VRF:
VRF апстрим #1:

  • подключен к физическому интерфейсу: ge-0/0/1.0
  • ASN: 100
  • IP-адрес: 1.1.1.1/30

VRF апстрим #2:

  • подключен к физическому интерфейсу: ge-0/0/2.0
  • ASN: 200
  • IP-адрес: 2.2.2.1/30

VRF клиент #1:

  • подключен к физическому интерфейсу: ge-0/1/0.0
  • ASN: 300
  • IP-адрес: 3.3.3.2/30

Назовем наш VRF именем test, а наш номер AS будет 400.

Обращаю ваше внимание так это на то, что конфигурацию протокола BGP у основного роутера мы не трогаем, т.е. никаких изменений туда вносить не надо.
Подмечу, что конфигурацию самих физических интерфейсов и policy-statement (роут мапов) для пиров в нашем VRF нужно производить в режиме конфигурирования основного роутера, а не в routing-instances test.

Заходим в режим конфигурирования:

root@juniper> configure

Затем перейдем в уровень routing-instances:

root@juniper# edit routing-instances

После чего нам нужно задать имя нашего routing-instance (допустим test) и задать в нем остальные настройки, в том числе настройки протокола BGP.

[edit routing-instances]
root@juniper#
set test description «test routing table»

Зададим тип  routing-instance:

[edit routing-instances]
root@juniper#
set test instance-type virtual-router

Затем укажем какие интерфейсы роутера помещать в данный instance (в моем случае это будет три интерфейса, т.к. три пира и каждый в своем интерфейсе, это могут быть как целиком физические интерфейсы, так и вланы):

[edit routing-instances]
root@juniper#
set test  interface ge-0/0/1.0
root@juniper# set test  interface ge-0/0/2.0
root@juniper# set test  interface ge-0/1/0.0

Дальнейшая настройка routing-instance ничем не отличается от настройки основного роутера. Те же секции, те же команды. Не буду далее описывать каждую команду и покажу что мы должны получить на выходе по нашему routing-instance test:
[edit]
root@juniper#
show routing-instances test

test {
    description "test routing table";
    instance-type virtual-router;
    interface ge-0/0/1.0;
    interface ge-0/0/2.0;
    interface ge-0/1/0.0;
    routing-options {
        router-id 1.1.1.2;
        autonomous-system 400;
    }

    protocols {
        bgp {
            path-selection always-compare-med;
            traceoptions {
                file bgp_vrf.log size 1m files 10;
            }
            log-updown;
            remove-private;
            local-as 400;
            group upstreams {
                type external;
                no-advertise-peer-as;
                neighbor 1.1.1.1 {
                    description VRF_Upstream_1;
                    import vrf-upstream-1-in;
                    export vrf-customer;
                    remove-private;
                    peer-as 100;
                }
                neighbor 2.2.2.1 {
                    description VRF_Upstream_2;
                    import vrf-upstream-2-in;
                    export vrf-customer;
                    peer-as 200;
                }
            }
            group customers {
                neighbor 3.3.3.2 {
                    description VRF_client_1;
                    import vrf-client-in;
                    export vrf-client-out;
                    peer-as 300;
                }
            }
        }
    }
}

Собственно на этом конфигурация VRF и закончена. Как видно из конфига мы настроили BGP протокол внутри VRF`а где апстримов поместили в группу upstreams, а нашего клиента в группу customers.

Теперь остается настроить сами физические интерфейсы и создать полиси-мапы (vrf-upstream-1-in, vrf-customer, vrf-upstream-2-in, vrf-customer, vrf-client-in, vrf-client-out).

Напоминаю, что это делается в режиме «глобального» конфигурирования роутера, а не в routing-instance test.

Что мы должны увидеть после коммита данного конфига ?

По команде:

[edit]
root@juniper#
run show bgp summary

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

Так же можно посмотреть что там с маршрутами в нашей routing-instance test:

[edit]
root@juniper#
run show route table test.inet.0

Несколько заметок, например запустив пинг до нашего VRF клиента командой:

[edit]
root@juniper#
run ping 3.3.3.2

не удивляйтесь что пинга нет, даже при наличии линка на физическом интерфейсе и не торопитесь с выводами, что физика не работает или с той стороны не настроен IP-адрес, просто вы забыли о том, что вы выполняете эту команду из основного роутера, а ведь физический интерфейс в сторону VRF-клиента принадлежит routing-instance test и основной роутер действительно не знает маршрут в эту подсеть.

Меняем команду на:

[edit]
root@juniper#
run ping 3.3.3.2 routing-instance test
и вот он наш пинг:

PING 3.3.3.2 (3.3.3.2): 56 data bytes
64 bytes from 3.3.3.2: icmp_seq=0 ttl=255 time=0.660 ms
64 bytes from 3.3.3.2: icmp_seq=1 ttl=255 time=0.647 ms
^C
--- 3.3.3.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.647/0.653/0.660/0.007 ms

т.е. мы явно сказали роутеру какой instance использовать для отправки пакетов до хоста 3.3.3.2.

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

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

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

Думаю многим из вас знаком сайт http://www.robtex.com на котором много полезных вещей и одна из них это графическое отображение связей заданной AS.

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

Но есть вещи которых нет в графическом отображении  www.robtex.com. Например он не показывает даунстримов (клиентов) для заданной AS. Соответственно нет инфы, которая нужна админу транзитного оператора, который настраивает фильтры под клиентов. Инфа бы помогла увидеть «кольца» в маршрутизации его клиентов через другие связанные с ним AS.

Так же что-то непонятное творится с кешированием. Много раз замечал на AS`ках, которых обслуживаю, что инфа на www.robtex.com не соответствует текущей ситуации иногда даже через месяц после изменений. Т.е. ты что-то поменял, но измений не видно… и долго не видно.

На просторах «тырнета» была обнаружена либа «JavaScript Graph Library» -> Dracula Graph Library, которая отображает связности между объектами.

Dracula Graph Library работает на векторной библиотеке Raphaël, разработанной  Дмитрием  Барановским.

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

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

Итак, готовы вам представить первую версию собственного скрипта отображающий инфу по AS в графическом виде —>  «Построение графа связанности AS по ее номеру«.

Где можно указать номер AS, а так же:

  • тип выводимой информации: апстримы/даунстримы
  • выбрать глубину рекурсии

Вся информация берется из БД RIPE, которая доступна в выводе информации по номеру AS: http://www.db.ripe.net/whois?ASXXXXX (где XXXXX номер AS).

Пример вывода скрипта по нашей AS:

AS graph example

AS graph example

  • Красные стрелочки -> Апстримы
  • Зеленые стрелочки -> Даунстримы

Как вы понимаете автономка автономке рознь, т.е. кол-во апстримов и даунстримов у крупного оператора может быть большим, поэтому во избежание зависания вашего браузера выставлен лимит по кол-ву отображаемых на экране объектов, в 200 шт.

RIPE ессно не в восторге если каждый раз при выводе обращаться к их БД и они могут заблочить IP, если он будет обращаться к их БД очень часто.

Посему кеш у нашей тулзы тоже есть, но он не такой «жестокий» и составляет не более 3-х суток.

Не всегда расположение объектов на странице вывода является оптимальным, для этого в конце страницы есть кнопка «перерисовать», либо вы сами можете  таскать любой объект (круг с номером AS) на экране и расставить их так, как нравится вам.

Информация заносимая админами в описание их AS в БД RIPE может различаться, т.к. способов написания import/export несколько. Мы постарались учесть самые распространенные из них, но мы предполагаем, что вы, уважаемые посетители, можете найти AS, картинка по которой может отображаться не совсем правильно. Если это так, то просим Вас сообщить нам о такой через форму «обратной связи» у нас на сайте.

И опережая вопросы: ДА, мы думали над тем, что бы брать информацию не из БД RIPE, а непосредственно из таблицы маршрутизации (full-view) BGP роутеров. Возможно, мы сделаем это в следующих версиях скрипта когда руки дойдут 🙂

По мере использования, получения отзывов и предложений наша тулза может изменяться.

Надеемся, что эта тулза поможет не только нам, поэтому и решили разместить её на нашем сайте в свободном доступе 🙂

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

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