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

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

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

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

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

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