Про виртуальные сети (часть 17).BGP в виртуальных сетях

Сегодня мы обсудим Border Gateway Protocol (BGP). Как понятно из названия это протокол граничных (или пограничных, кому как нравится) маршрутизаторов, т.е. маршрутизаторов которые стоят на границах сетей и обеспечивают общение этих самых сетей между собой. Является основным протоколом маршрутизации в интернете. Ну и как следствие, является достаточно сложным в настройке, но зато и предоставляет много возможностей.

Учитывая востребованность и распространенность этого протокола информации о нем в интернете читать, не перечитать. Однако у подавляющего большинства источников есть один общий недостаток, они или очень задвинуты в теорию и описание протокола, либо предлагаются конкретные конфиги, для конкретных сетей без особого разбора, что же это было. Я постараюсь, по мере возможности все-таки найти золотую середину, попытавшись с одной стороны объяснить, что же все-таки происходит при той или иной настройке, но и не вдаваясь особо в теорию, чтобы не усыпить читателя.

Поехали.

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

Physic_topology

Во-первых, я избавился от центрального коммутатора и соединил маршрутизаторы напрямую. Во-вторых, я изменил используемую в своих статьях платформу.  До этого все маршрутизаторы были на платформе 3640 и версией IOS 12.4. При написании данной статьи я заменил маршрутизаторы ISP_1, ISP_2, ISP_3 и ISP_4 на платформу 7200 и версию IOS 15.1, которая больше подходит в качестве Provider Edge (PE) маршрутизаторов (на платформе 3640 многие фишки BGP просто не реализованы). Ну и наконец я добавил резервные каналы и Branch маршрутизаторы для клиентов, чтобы продемонстрировать настройки iBGP, взаимодействие IGP с BGP и на какие моменты следует при этом обращать внимание.

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

BGP_Logic

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

Положим, что из сети клиентов в общую сеть должно анонсироваться по одному адресу с каждого маршрутизатора (в нашем примере это будут loopback интерфейсы). Сеть провайдера (хотя в нашем примере правильнее говорить о нескольких провайдерах, поскольку на каждом маршрутизаторе будет настроена своя AS) полностью должна управлять BGP.

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

ISP_1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
ISP_1(config)#ip vrf Client
ISP_1(config-vrf)#rd 1:100
ISP_1(config-vrf)#ip vrf Provider
ISP_1(config-vrf)#rd 1:1

С созданием виртуальных маршрутизаторов все должно быть понятно, а вот что такое rd? Router Distinguisher (здесь трудности перевода, не знаю как это дословно по-русски) уникальный идентификатор таблицы обновлений BGP виртуального маршрутизатора. Он состоит из двух частей: первая может быть номером автономной системы BGP или IP-адресом (router-id), вторая часть просто число, собственно и придающее уникальность идентификатору. Зачем же он нужен? До сих пор, настраивая протоколы IGP, прекрасно обходились без него. Дело в том, что а отличие от IGP протоколов на всем железном маршрутизаторе может быть только один BGP процесс. Поэтому, чтобы можно было определить чьи полученные анонсы, и вводится этот самый RD.

Далее создаем аналогичным образом создаем виртуальные маршрутизаторы на ISP_2, ISP_3 и ISP_4. Назначаем им интерфейсы и присваиваем этим интерфейсам адреса.

ISP_1(config-vrf)#int gi0/0
ISP_1(config-if)#description to ISP_2
ISP_1(config-if)#ip vrf forwarding Provider
ISP_1(config-if)#ip address 10.0.10.1 255.255.255.252
ISP_1(config-vrf)#int gi1/0
ISP_1(config-if)#description to ISP_3
ISP_1(config-if)#ip vrf forwarding Provider
ISP_1(config-if)#ip address 10.10.0.1 255.255.255.252
ISP_1(config-vrf)#int se2/0
ISP_1(config-if)#description to Client_2
ISP_1(config-if)#ip vrf forwarding Client
ISP_1(config-if)#ip unn Lo0
ISP_1(config-vrf)#int Lo0
ISP_1(config-if)#ip address 192.168.51.1 255.255.255.255

 

Здесь я опять воспользовался loopback интерфейсами для присвоения адресов последовательным интерфейсам. С одной стороны это позволяет экономить адреса на соединениях между маршрутизаторами, с другой стороны подобный подход требует и дополнительной настройки BGP. К который мы теперь и приступим.

Включаем BGP процесс:

ISP_1 (config)#router bgp 1

И тут же получаем:

%BGP-4-NORTRID: BGP could not pick a router-id. Please configure manually.

Понятным английским языком написано: не могу выбрать router-id, сконфигурируйте вручную. Почему появилась это сообщение понятно – после конфигурирования виртуальных маршрутизаторов у нас не осталось ни одного сконфигурированного интерфейса в железном маршрутизаторе. А если читатель помнит, в качестве router-id выбирается IP-адрес сконфигурированного активного интерфейса. Лучше всего если это loopback интерфейс. В то же время процесс динамической маршрутизации не может быть запущен без назначенного router-id. Усиленно рекомендую этот момент запомнить, так как если вы конфигурируете удаленно, а не через консоль, вы этого сообщения не получите, и можете потом долго искать причину, по которой маршрутизатор не устанавливает соседства с прописанными соседями.

Ну раз просят, прописываем router-id:

ISP_1 (config-router)#bgp router-id 192.168.50.1

На этом конфигурация BGP  для реального маршрутизатора заканчивается, принимаемся за виртуальные:

ISP_1(config-router)#address-family ipv4 vrf Client
ISP_1(config-router-af)#bgp router-id 192.168.51.1
ISP_1(config-router-af)#neighbor 192.168.53.2 remote-as 200
ISP_1(config-router-af)#neighbor 192.168.53.2 ebgp-multihop
ISP_1(config-router-af)#neighbor 192.168.53.2 update-source Loopback0
ISP_1(config-router-af)#neighbor 192.168.53.2 activate
ISP_1(config-router-af)#network 192.168.51.1 mask 255.255.255.255

Итак, что мы тут наконфигурили: мы задали вручную router-id (хотя это было и не обязательно), прописали соседа 192.168.53.2 (это Client_2), сказали, что сосед не подключен непосредственно, и приказали активироваться(в той версии IOS на которой я собирал стенд эта команда вводилась автоматически после добавления соседа, но может так не везде?). Затем указали подсеть 192.168.51.1/32 для анонса.

Здесь следует обратить внимание на два момента. Первый – это то, что eBGP требует, чтобы соседние пиры были соединены непосредственно (находились в одной подсети), однако это автоматически запрещает последовательным интерфейсам заимствовать адреса у других интерфейсов. Видимо это была одна из причин, по которой добавили ключевое слово  ebgp-multihop. С его помощью мы указываем маршрутизатору, что сосед все-таки не подсоединен непосредственно. После ключевого слова ebgp-multihop также можно указать количество hop’ов, которое допускается между соседями. По-умолчанию – 255. Второй момент в том, что IP-адрес у интерфейса не «родной». Поэтому указываем процессу BGP что  update-source Loopback0. (Во всех примерах в интернете указание update-source делается с обеих сторон, однако для установления соседства можно указать только с одной стороны)

Теперь сеть Provider:

ISP_1(config-router)#address-family ipv4 vrf Provider
ISP_1(config-router-af)#neighbor 10.0.10.2 remote-as 2
ISP_1(config-router-af)#neighbor 10.0.10.2 activate
ISP_1(config-router-af)#neighbor 10.10.0.2 remote-as 3
ISP_1(config-router-af)#neighbor 10.10.0.2 activate
ISP_1(config-router-af)#network 10.0.10.0 mask 255.255.255.252
ISP_1(config-router-af)#network 10.10.0.0 mask 255.255.255.252

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

Аналогичным образом настраиваем остальные маршрутизаторы ISP и проверяем что у нас получилось.

Сначала проверяем, как установилось соединение с соседями

ISP_1#sh ip bgp vpnv4 vrf Client summary
BGP router identifier 192.168.51.1, local AS number 1
BGP table version is 64, main routing table version 64
3 network entries using 480 bytes of memory
3 path entries using 168 bytes of memory
10/6 BGP path/bestpath attribute entries using 1360 bytes of memory
6 BGP AS-PATH entries using 144 bytes of memory
1 BGP extended community entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 2176 total bytes of memory
BGP activity 23/16 prefixes, 51/40 paths, scan interval 60 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.53.2    4          200    1284    1411     64     0    0  21:17:31        2

 

ISP_1#sh ip bgp vpnv4 vrf Provider summary
BGP router identifier 192.168.50.1, local AS number 1
BGP table version is 64, main routing table version 64
4 network entries using 640 bytes of memory
8 path entries using 448 bytes of memory
10/6 BGP path/bestpath attribute entries using 1360 bytes of memory
6 BGP AS-PATH entries using 144 bytes of memory
1 BGP extended community entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 2616 total bytes of memory
BGP activity 23/16 prefixes, 51/40 paths, scan interval 60 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.10.2       4            2    1444    1446     64     0   0   21:23:30        3
10.10.0.2       4            3     688     689     64     0   0   10:15:48        3

Я выделил время в столбце Up/Down, именно его наличие в данном выводе указывает, что соединение установлено. Если там указано что-то другое, значит соединения нет. При использовании ключевого слова neighbor будет показан более подробный вывод о соседях, и там следует искать слово established. Если оно есть, значит соединение установлено. Всякие там active и тем более idle не подходят.

ISP_1#sh ip bgp vpnv4 vrf Provider
BGP table version is 64, local router ID is 192.168.50.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf Provider)
*  10.0.10.0/30     10.0.10.2                0             0 2 i
*>                  0.0.0.0                  0         32768 i
*> 10.0.20.0/30     10.10.0.2                0             0 3 i
*                   10.0.10.2                              0 2 4 3 i
*  10.10.0.0/30     10.10.0.2                0             0 3 i
*>                  0.0.0.0                  0         32768 i
*  10.20.0.0/30     10.10.0.2                              0 3 4 2 i
*>                  10.0.10.2                0             0 2 i

В этом выводе мы видим, какие сети были проанонсированы соседними маршрутизаторами. Последний столбец – список автономных систем, через которые эта подсеть доступна. Видно, что каждая подсеть может быть достигнута по 2-м маршрутам, что и логично, поскольку каждую объявляет два маршрутизатора. Ну и естественно лучшие маршруты (в BGP критерий по умолчанию – это количество AS по дороге, но можно настраивать при необходимости и другие: метрику, вес и router-id соседей), включаются в таблицу маршрутизации.

ISP_1#sh ip route vrf Provider
Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C        10.0.10.0/30 is directly connected, GigabitEthernet0/0
L        10.0.10.1/32 is directly connected, GigabitEthernet0/0
B        10.0.20.0/30 [20/0] via 10.10.0.2, 10:26:01
C        10.10.0.0/30 is directly connected, GigabitEthernet1/0
L        10.10.0.1/32 is directly connected, GigabitEthernet1/0
B        10.20.0.0/30 [20/0] via 10.0.10.2, 21:32:33

 Все подсети виртуальной сети Provider на месте. На этом настройку виртуальной сети Provider можно считать законченной.

Теперь перейдем к сетям клиентов. Начнем с Client_2, раз уж он непосредственно присоединен к ISP_1 и настройку виртуального маршрутизатора Client я производил как раз для него. Сразу отмечу что настройка виртуального маршрутизатора Client на ISP_3 отличается только анонсируемым адресом loopback интерфейса. То же касается и настроек на ISP_2 и ISP_4, отличаются только анонсируемые адреса и номер удаленной AS.

Для начала настроим маршрутизацию с ISP:

Client_2#conf t
Client_2(config)#router bgp 200
Client_2(config-router)#neighbor 192.168.51.1 remote-as 1
Client_2(config-router)#neighbor 192.168.51.1 ebgp-multihop 255
Client_2(config-router)#neighbor 192.168.51.1 update-source Loopback0
Client_2(config-router)#neighbor 192.168.51.3 remote-as 3
Client_2(config-router)#neighbor 192.168.51.3 ebgp-multihop 2
Client_2(config-router)#neighbor 192.168.51.3 update-source Loopback0
Client_2(config-router)#network 192.168.53.2 mask 255.255.255.255

Теперь нам нужно каким-то образом вставить анонсирование маршрута к интерфейсу loopback маршрутизатора Client_2_Branch. В сети Client_2 мы сделаем это с использованием редистрибьюции из EIGRP. Однако EIGRP передает информацию обо всей адресации в сети, а нам нужно анонсировать только одну. Поэтому сначала настраиваем route-map который будет описывать, что мы хотим передать в BGP.

Client_2(config)#access-list 20 permit 192.168.59.1
Client_2(config)#route-map Red_EIGRP permit 10
Client_2(config-route-map)#match ip address 20

И, собственно, редистрибьюция:

Client_2(config)#router bgp 200
Client_2(config-router)#redistribute eigrp 200 route-map Red_EIGRP

Посмотрим, что получилось.

Client_2#sh ip bgp summ
BGP router identifier 192.168.53.2, local AS number 200
BGP table version is 6, main routing table version 6
3 network entries using 351 bytes of memory
3 path entries using 156 bytes of memory
4/3 BGP path/bestpath attribute entries using 496 bytes of memory
2 BGP AS-PATH entries using 48 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1051 total bytes of memory
BGP activity 13/10 prefixes, 13/10 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.51.1    4     1    1593    1460        6    0    0 23:54:33        1
192.168.51.3    4     3    1600    1468        6    0    0 23:54:33        1
Client_2#sh ip bgp
BGP table version is 6, local router ID is 192.168.53.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
r> 192.168.51.1/32  192.168.51.1             0             0 1 i
r> 192.168.51.3/32  192.168.51.3             0             0 3 i
*> 192.168.59.1/32  192.168.57.254      156160         32768 ?

Как видим все в порядке. RIB_failure обозначат, что такой маршрут не может быть вставлен в таблицу маршрутизации, так как он там уже есть. В нашем случае эти маршруты уже объявлены вручную.

Теперь переходим к сети Client_1. Здесь для анонсирования loopback маршрутизатора Client_1_Branch я воспользуюсь iBGP.

Client_1#conf t
Client_1(config)#router bgp 100
Client_1(config-router)#neighbor 192.168.20.1 remote-as 100
Client_1(config-router)#neighbor 192.168.20.1 update-source Loopback0
Client_1(config-router)#neighbor 192.168.51.2 remote-as 2
Client_1(config-router)#neighbor 192.168.51.2 ebgp-multihop 255
Client_1(config-router)#neighbor 192.168.51.2 update-source Loopback0
Client_1(config-router)#neighbor 192.168.51.4 remote-as 4
Client_1(config-router)#neighbor 192.168.51.4 ebgp-multihop 255
Client_1(config-router)#neighbor 192.168.51.4 update-source Loopback0
Client_1(config-router)#network 192.168.53.1 mask 255.255.255.255

Теперь с Client_1_Branch. Здесь вообще все просто.

Client_1_Branch#conf t
Client_1_Branch(config)#router bgp 100
Client_1_Branch(config-router)#neighbor 192.168.53.1 remote-as 100
Client_1_Branch(config-router)#neighbor 192.168.53.1 update-source Loopback0
Client_1_Branch(config-router)#network 192.168.20.1 mask 255.255.255.255

Если не бросилось в глаза, подсказываю: я не воспользовался ключевым словом ebgp-multihop. А все из-за того, что iBGP(internal) в отличие он eBGP(external) не требует, чтобы пиры были соединены непосредственно.

Проверяем, естественно, установлено ли соседство, и какие маршруты проанонсировались. Все должно быть в порядке. Если нет, сверяемся с готовым конфигом.

Ну и вот, наконец, мы подобрались к кульминации нашего повествования. Необходимо настроить передачу трафика между виртуальными маршрутизаторами так, чтобы все всех видели и могли передавать друг другу информацию. Делается это очень просто. Не нужно никаких route-map или дополнительных интерфейсов. Достаточно всего-то передать маршруты проанонсированные BGP с одного виртуального маршрутизатора на другой в пределах железного маршрутизатора. В самом начале статьи для каждого виртуального маршрутизатора я задал значение RD. И теперь, ссылаясь на него, возможно передавать таблицы между виртуальными маршрутизаторами.

ISP_1(config)#ip vrf Client
ISP_1(config-vrf)#route-target export 1:100
ISP_1(config-vrf)#route-target import 1:1
ISP_1(config-vrf)#ip vrf Provider
ISP_1(config-vrf)#route-target export 1:1
ISP_1(config-vrf)#route-target import 1:100

Вот, собственно и все. Проверяем, что у нас получилось.

ISP_1#sh ip bgp vpnv4 vrf Client
BGP table version is 80, local router ID is 192.168.51.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:100 (default for vrf Client) VRF Router ID 192.168.51.1
*> 10.0.10.0/30     0.0.0.0                  0         32768 i
*> 10.0.20.0/30     10.10.0.2                0             0 3 i
*> 10.10.0.0/30     0.0.0.0                  0         32768 i
*> 10.20.0.0/30     10.0.10.2                0             0 2 i
*> 192.168.51.1/32  0.0.0.0                  0         32768 i
*> 192.168.51.3/32  192.168.53.2                           0 200 3 i
*> 192.168.59.1/32  192.168.53.2        156160             0 200 ?
ISP_1#sh ip bgp vpnv4 vrf Provider
BGP table version is 80, local router ID is 192.168.50.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf Provider)
*  10.0.10.0/30     10.0.10.2                0             0 2 i
*>                  0.0.0.0                  0         32768 i
*> 10.0.20.0/30     10.10.0.2                0             0 3 i
*                   10.0.10.2                              0 2 4 3 i
*  10.10.0.0/30     10.10.0.2                0             0 3 i
*>                  0.0.0.0                  0         32768 i
*  10.20.0.0/30     10.10.0.2                              0 3 4 2 i
*>                  10.0.10.2                0             0 2 i
*> 192.168.51.1/32  0.0.0.0                  0         32768 i
*> 192.168.51.3/32  192.168.53.2                           0 200 3 i
*> 192.168.59.1/32  192.168.53.2        156160             0 200 ?

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

Аналогичным образом настраиваем маршрутизацию и на других ISP и проверяем. Идем на маршрутизатор Client_1_Branch и проверяем таблицу маршрутизации:

Client_1_Banch#sh ip bgp
BGP table version is 70, local router ID is 192.168.20.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*>i10.0.10.0/30     192.168.51.2             0    100      0 2 i
*>i10.0.20.0/30     192.168.51.4             0    100      0 4 3 i
*>i10.10.0.0/30     192.168.51.2             0    100      0 2 1 i
*>i10.20.0.0/30     192.168.51.2             0    100      0 2 i
r>i192.168.18.0     192.168.53.1             0    100      0 ?
r>i192.168.19.0     192.168.53.1             0    100      0 ?
*> 192.168.20.1/32  0.0.0.0                  0         32768 i
*>i192.168.51.1/32  192.168.51.2             0    100      0 2 1 i
*>i192.168.51.3/32  192.168.51.4             0    100      0 4 3 i
r>i192.168.51.4/32  192.168.51.4             0    100      0 4 i
r>i192.168.53.1/32  192.168.53.1             0    100      0 ?
*>i192.168.59.1/32  192.168.51.2             0    100      0 2 1 200 ?

 

Client_1_Banch#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

192.168.59.0/32 is subnetted, 1 subnets
B       192.168.59.1 [200/0] via 192.168.51.2, 00:01:43
192.168.20.0/32 is subnetted, 1 subnets
C       192.168.20.1 is directly connected, Loopback0
10.0.0.0/30 is subnetted, 4 subnets
B       10.10.0.0 [200/0] via 192.168.51.2, 00:01:43
B       10.0.10.0 [200/0] via 192.168.51.2, 00:01:43
B       10.20.0.0 [200/0] via 192.168.51.2, 00:01:43
B       10.0.20.0 [200/0] via 192.168.51.2, 00:01:43
192.168.53.0/32 is subnetted, 1 subnets
S       192.168.53.1 [1/0] via 192.168.19.1
192.168.51.0/32 is subnetted, 4 subnets
B       192.168.51.3 [200/0] via 192.168.51.2, 00:01:44
D EX    192.168.51.2 [170/2172416] via 192.168.19.1, 1d00h, FastEthernet0/0
B       192.168.51.1 [200/0] via 192.168.51.2, 00:01:46
D EX    192.168.51.4 [170/2172416] via 192.168.19.1, 1d00h, FastEthernet0/0
C    192.168.19.0/24 is directly connected, FastEthernet0/0
D    192.168.18.0/24 [90/30720] via 192.168.19.1, 1d00h, FastEthernet0/0

Пробуем пинговать:

Client_1_Banch#ping 192.168.59.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.59.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Да что ж это такое? Ведь мы все настроили, и в таблице маршрутизации маршрут есть.

Client_1_Banch#sh ip route 192.168.59.1
Routing entry for 192.168.59.1/32
Known via "bgp 100", distance 200, metric 0
Tag 2, type internal
Last update from 192.168.51.2 00:05:22 ago
Routing Descriptor Blocks:
* 192.168.51.2, from 192.168.53.1, 00:05:22 ago
Route metric is 0, traffic share count is 1
AS Hops 3
Route tag 2

Здесь нужно вспомнить две вещи. Во-первых основной принцип маршрутизации, гласящий, что маршрутизатор принимает решение о передаче пакета исходя только из своей таблицы маршрутизации. Следствием является то, что если существует маршрут из пункта А в пункт Б, то из этого не следует, что есть маршрут из Б в А. И во-вторых, в сети Client_2 мы настраивали редистрибьюцию из EIGRP в BGP,а вот обратно не делали.

Вообще говоря редистрибьюция из EGP в IGP дело опасное. Представьте, что на ваш скромненький маршрутизатор, где-нибудь в удаленном офисе свалилась вся таблица маршрутизации интернета. Представили? Да только ее передача туда завалит всю работу. Не говоря уже о том, чтобы этот SOHO маршрутизатор ее обработал.

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

Client_2_Branch(config)#ip route 0.0.0.0 0.0.0.0 192.168.57.1

Ну и проверяем, конечно же:

Client_1_Banch#ping 192.168.59.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.59.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/56/68 ms

Вот и сказке конец, а кто слушал – молодец!

Аверьянов Кирилл
network-lab.ru

Полные конфиги маршрутизаторов.

Client_1
Client_1_Banch
Client_2
Client_2_Branch
ISP_1
ISP_2
ISP_3
ISP_4

 


Комментарии:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Hide me
Получать регулярно свежие материалы, лабораторные и вебинары
Email Имя
Show me