Subnets.ru

**AxelMAN** » 20 июл 2010, 20:07

Всем привет. Я здесь новенький, но почитав ветки форума понял, что это то что мне нужно

Попытаюсь обьяснить то, с чем у меня несколько дней назад возникли полные непонимания.
Мы конечный ISP, имеем свою индивидуальную AS и диапазон IP-адресов /21.
BGP крутится на Cisco Catalyst 3750G. Имеем 3 внешних пира.

До меня BGP както уже було настроено с нашими пирами, но наблюдалась такая проблема, что трафик, котрый должен был бы сливаться нам через канал City-IX, почему-то, в большинстве, сливался через канал UA-IX. Когда я уже влез в проблему детальнее, я посмотрел, что и на Украину и на город мы анонсируем одни и те же префиксы (/22).
Одним словом анонсировали пирам так:

После этого я решил немного изменить префикс-листы анонсов 3-му пиру, и теперь туда начали анонсировать: 4 подсети с префиксом /23. Помогло. Трафик полился через City-Ix.

Тут же ж решил, возомнив себя гуру BGP, поменять все префиксы, анонсируемые нашим пирам. Поменял по принципу most-prefered:

На каналах World UA-IX как-бы ничего не поменялось, разве что на UA-IX по Cacti стали заметны какие-то резкие обрывы, и потом опять подьемы трафика (так как бы оно раздуплялось там, и бросало всьо через City-IX) - но в прицнипе загрузка канала UA-IX упала, а City-IX возросла, чего и требовалось добиться.

Теперь то, чего я не понимаю... Начал пользоваться looking glas'ом, и вот что заметил. На LG нашего ISP, что дает нам World, вижу маршрут с префиксом /21 (на нем стоит local preference 100), который мы анонсируем ему на прямую, и 2 маршрута с префиксами /22 (local preference = 95), которые он получил через несколько автономных систем от AS, которой мы и анонсировали /22. Сделав traceroute отсюда же, вижу что пакеты идут через UA-IX, тоесть через most-prefered маршрут /22 (несмотря на то что тудою путь длиннее). Опять же повторюсь, что по графикам загрузки наших каналов я бы не сказал, что что-то поменялось, трафик и дальше льется и через World и UA-IX канал. Но тогда не понимаю... по логике, роутер, когда получает пакет, смотрит на его destination address, смотрит в таблицу маршрутизации и выбирает оттуда сеть, у которой по маске больше match, тоесть /22, и до атрибута local preference дело то и не доходит.... он шлет туда... ИЛИ ЖЕ Я ОШИБАЮСЬ, и local preference имеет место тут быть (тогда почему traceroute идет через /22....

)

Помогите пожалуста прояснить мне вот эту ситуацию.
И еще, может ли как-то обьяснить как именно правильно анонсировать маршруты, дли примера как в этой ситуации, для того чтобы идеология точек обмена трафика правильно работала и экономила деньги компании (МОЖЕТ Я ЧЕГО НЕ ТАК СДЕЛАЛ).

Иииеще... Подскажите где можна почитать что-нибудь про суть организации и работы точек обмена трафиком, как они соединяються с интернетом, и с другими (большими и меньшими) точками обмена трафика, чтобы я в конце концов понял как там гуляют маршруты...
Извините, что так много... Не умею по другому

Заранее СПАСИБО !!!

**root** » 21 июл 2010, 19:33

AxelMAN писал(а):Помогите пожалуста прояснить мне вот эту ситуацию.

будет всегда выбираться маршрут more specific, bgp best path selection алгоритм даже не запустится
на всякий случай вот он:
http://subnets.ru/wrapper.php?p=7#xtocid2375328

Summary of the BGP Path Selection Process

BGP всегда выбирает один из маршрутов - как наилучший. Когда маршрут выбран, BGP помещает его в свою таблицу маршрутизации, и передает его своим neighbor'ам. Для выбора наилучшего маршрута BGP использует следующие критерии:

1. Если путь, указанный в поле next-hop, недоступен, этот update убивается.
2. Лучшим считается путь с наибольшим значением weight;
3. Если weight путей одинаковы, то выбирается путь с наибольшим lpref;
4. Если weight и lpref одинаковы, то выбирается путь, который появился в таблице маршрутов BGP на данном роутере. (подразумевается, что это будет самый наикратчайший путь);
5. Если нет путей, которые "родились" на данном роутере, то выбирается путь с AS_path минимальной длины;
6. Если все пути имеют одинаковую длину (одинаковое количество hop'ов, следовательно), выбирается путь с "lowest origin type". Считается, что IGP < EGP < Incomplete.;
7. Если Origin attr. code одинаковы для всех путей, выбирается путь с наименьшим MED attr.;
8. Если и MED одинаковы для всех возможных путей, предпочтительным считается external path перед internal path;
9. Если опять все пути одинаковы, то prefer the path through the closest IGP neighbor;
10. Выбирается путь с наименьшим IP адресом из тех, которые указываются by the BGP router ID.

не путай выбор лучшего пути при поступлении маршрута от соседа (в BGP update сообщении) когда запускается алгоритм bgp best path selection и алгоритмом выбором маршрута, из уже сформированной таблицы маршрутов, по которому будет передаваться трафик (more specific и Административная дистанция)

more specific`ом конечно можно играть, но это не совсем "честно" и многие это осуждают и ругаются когда такое встречают
ты попробуй все же убрать more specific и разрулить входящий трафик по каналам с помощью as-path prepend, выставляя его разным на разных каналах
т.е. в твоем случае как то так наверно:
1 - World : 2 препенда
2 - UA-IX : 1 препенд
3 - City-IX : нет препендов
т.е. при анонсах себя в World и UA-IX добавляй препенды (в as-path свою ASку требуемое кол-во раз), таким образом ты ухудшишь этот маршрут через этот канал
получится что пиры будут видеть тебя так:
AS100 - Твой ISP
AS65000 - Ты
AS200 - пир в UA-IX
AS300 - пир в City-IX
AS500 - какая нить ASка далеко в инете

AS100:

65000 65000 65000

AS200:

65000 65000

AS300:

65000

AS500:

XXX XXX 100 65000 65000 65000

таким образом самый короткий путь к тебе это по каналу City-IX, те пиры кто видит этот маршрут, будут сливать тебе трафик именно этим маршрутом (ессно если админ удаленной AS не делал спец. настроек для твоей AS, т.е. не завышал тот же local-prefence на тебя по другому каналу)

AxelMAN писал(а):Сделав traceroute отсюда же, вижу что пакеты идут через UA-IX, тоесть через most-prefered маршрут /22 (несмотря на то что тудою путь длиннее).

радуйся, значит ты получаешь и транзитный трафик к себе через своего прова, но в канал UA-IX
а он, я думаю, скорее всего дешевле по оплате чем канал от прова
получается что твой пров не учел подобной ситуации и просто тупо теряет свои деньги
настроить грамотно транзитную AS не просто, как и учесть все возможные ситуации, но все приходит с опытом

думаю что когда нить пров осознает свою ошибку и исправит её, а тебе тогда нужно будет быть готовым к тому, что на канале ты <--> пров возрастет входящий трафик

AxelMAN писал(а):Подскажите где можна почитать что-нибудь про суть организации и работы точек обмена трафиком, как они соединяються с интернетом, и с другими (большими и меньшими) точками обмена трафика, чтобы я в конце концов понял как там гуляют маршруты...

хмм... книжку по BGP, там обычно и картинки есть
Описание BGP протокола ( BGPv4 ) :: перевод на русский
Принципы маршрутизации в Internet. Самое полное описание протокола BGP 4
а так все просто, каждый роутер анонсит друг другу свои best маршруты, которые видит сам и так далее, от роутера к роутеру

AxelMAN писал(а):Извините, что так много... Не умею по другому

да ничего, наоборот чем подробнее объясняют тем лучше

AxelMAN писал(а):Заранее СПАСИБО !!!

нзчт

**AxelMAN** » 20 окт 2010, 13:49

Снова привет. Извините за долгое пропадание...
Немного разобрался в работе наших провайдеров, и понял что препенды мне тут не сильно помогут... и так как я настраивал, наверное будет наилучшим вариантом.
Дело вот оно в чем. Тот провайдер, что наливвает нам UA-IX также входит в состав City-IX. Итак, на UA-IX мы анонсируем две сети по /22, а на City-IX - четыре сети по /23. City-IX тоже анонсирует нашему UA-IX-провайдеру маршуты по /23. В итоге последний, как я понял из looking glass, имеет 2 таблицы маршрутизации: UA-IX-таблицу (o_exchange.inet.0), в которой находятся анонсируемые нами сети по /22, и интернет-таблицу (inet.0), в котрой видны и наши сети по /22 и сети по /23, которые пришли из City-IX (сети из этой таблицы в интернет не анонсируются). Соответственно most-prefered маршрут для "City-IX"трафика направленного в нашу AS выбирается через City-IX, тоесть как нужно. Если же я проанонсирую в City-IX и UA-IX маршруты с одинаковыми масками, то выберется маршрут через UA-IX канал, потому что на него стоит local preference 200, а на City-IX - 108. Вот такая у них политика...

Все было ничего, пока не появилась новая задача/проблема.
Взяли еще 1 канал в World (получаем тоже дефолт), и теперь нужно зделать своего рода резервирование. Детали:

1. Условно назву пулы наших IP-адресов:

2. Повторюсь, что теперь имеем 4 внешних пира:

3. Пирам анонсируем:

Задача стоит в разгрузке части внешнего канала в мир на другой канал. Для этого хотим, чтобы:

Придумал следующее решение:
1. Создаю ACL'и которые разрешают мои пулы:

Код: Выделить всё: ip access-list extended ISP-POOL1-OUT permit ip 100.100.100.0 0.0.1.255 any ip access-list extended ISP-POOL2-OUT permit ip 200.200.200.0 0.0.7.255 any

2. Создаю роут-мап, который будет матчить мои пулы, и назначать им дефолтовый гейтвей:

Код: Выделить всё: route-map ISP-POOLS-OUT permit 10 match ip address ISP-POOL1-OUT set ip default next-hop World-1-IP World-2-IP route-map ISP-POOLS-OUT permit 20 match ip address ISP-POOL2-OUT set ip default next-hop World-2-IP World-1-IP

3. Вешаю роут-мап на влан, по которому мой Border (напомню, что это Cisco Catalyst 3750G) соединен с BRAS'ом.

Код: Выделить всё: interface vlan 100 ip policy route-map ISP-POOLS-OUT

И получаю в логе ошибку:

%PLATFORM_PBR-3-UNSUPPORTED_RMAP: Route-map ISP-POOLS-OUT not supported for Policy-Based Routing

Нагуглил вот-что:

Error Message: PLATFORM_PBR-3-UNSUPPORTED_RMAP: Route-map [chars] not supported for Policy-Based Routing
Explanation: This message means that the route-map attached to an interface for policy routing contains an action that is not supported on this platform. This is a hardware limitation. [chars] is the route-map.
Recommended Action: Reconfigure the route-map to use permit entries and set ip next-hop actions only.

Тоесть получается, что каталиста не может присваивать дефолтовый гейтвей индивидуально каждому пакету, что матичться в раут-мапе (что я думаю смог-бы сделать полноценный роутер). Вариант с set ip next-hop меня не удовлетворяет, поскольку в таком случае будут игнорироваться маршуты, полученные из UA-IX и City-IX.

Подскажите пожалуйста, можна ли как-то по другому реализовать решение этой проблемы? Еще раз спасибо!!!
P.S.1 Забыл добавить, что интересует именно PBR из внутри нашей AS в мир, так как вход в AS регулирую путем анонсирования половины маршрутов в один канал, а другой половины - во второй.
P.S.2 Схему описанную выше хотел хотел еще зарезервировать от "black hole" через IP SLA, но пока и первая половина моей задумки не работает ((

**root** » 22 окт 2010, 09:24

1. Пора бы уже отказываться от игр в more specific, это тока добавляет тебе же гемороя
2. В City-IX и у твоих World апстримов есть какие либо community по управлению трафиком ?
3. Попробуй засетить на свои маршруты, которые ты анонсишь в City-IX, комъюнити no-export
Border Gateway Protocol (BGP)

Community Attribute

The community attribute provides a way of grouping destinations, called communities, to which routing decisions (such as acceptance, preference, and redistribution) can be applied. Route maps are used to set the community attribute. Predefined community attributes are listed here:

•no-export—Do not advertise this route to EBGP peers.
•no-advertise—Do not advertise this route to any peer.

многие маршрутизаторы его слушают по умолчанию и тем самым ты запретишь распространение своих четырех /23

BGP Case Studies, IP Routing

Community Attribute

The community attribute is a transitive, optional attribute in the range of 0 to 4,294,967,200. The community attribute is a way to group destinations in a certain community and apply routing decisions according to those communities. The routing decisions are accept, prefer, and redistribute, among others.

You can use route maps to set the community attributes. The route map set command has this syntax:
set community community-number [additive] [well-known-community]
A few predefined, well known communities for use in this command are:

no-export—Do not advertise to eBGP peers. Keep this route within an AS.
no-advertise—Do not advertise this route to any peer, internal or external.
internet—Advertise this route to the Internet community. Any router belongs to this community.
local-as—Use in confederation scenarios to prevent the transmit of packets outside the local AS.

Here are two examples of route maps that set the community:
Код: Выделить всё
route-map communitymap match ip address 1 set community no-advertise

4.

AxelMAN писал(а):что каталиста не может

какой IOS ? Ты смотрел что твоя версия IOS поддерживает PBR ? Смотри в Cisco Feature Navigator
Потому что не исключено, что у тя будет написано след.:

Policy-based routing based on packet length, IP precedence and TOS, set interface, set default next hop, or set default interface are not supported. Policy maps with no valid set actions or with set action set to Don't Fragment are not supported.

5.

AxelMAN писал(а):Подскажите пожалуйста, можна ли как-то по другому реализовать решение этой проблемы? Еще раз спасибо!!!

Да кроме PBR`а ничего в голову и не приходит.
покажи вывод команды:

Код: Выделить всё: show sdm prefer

Understanding and Configuring Switching Database Manager on Catalyst 3750 Series Switches

**AxelMAN** » 22 окт 2010, 11:51

root писал(а):1. Пора бы уже отказываться от игр в more specific, это тока добавляет тебе же гемороя
2. В City-IX и у твоих World апстримов есть какие либо community по управлению трафиком ?
3. Попробуй засетить на свои маршруты, которые ты анонсишь в City-IX, комъюнити no-export

Ну наверное ставить коммюнити no-export на City-IX для того, чтобы он не анонсировал их нашему UA-IX'овскому провайдеру не правильно, поскольку последний тоже является участником City-IX. Как он тогда получит нужные маршруты??? Тем более, говорил с организатором City-IX, который сказал что не анонсирует никому "левому" наши сети.
Или же я не правильно Вас понял?

root писал(а):какой IOS ? Ты смотрел что твоя версия IOS поддерживает PBR ? Смотри в Cisco Feature Navigator

Конечно что смотрел:

Код: Выделить всё: BORDER#show version Cisco IOS Software, C3750 Software (C3750-IPSERVICESK9-M), Version 12.2(46)SE, RELEASE SOFTWARE (fc2) Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 21-Aug-08 15:43 by nachen Image text-base: 0x00003000, data-base: 0x01880000 ROM: Bootstrap program is C3750 boot loader BOOTLDR: C3750 Boot Loader (C3750-HBOOT-M) Version 12.1(14r)EA1a, RELEASE SOFTWARE (fc1) System image file is "flash:c3750-ipservicesk9-mz.122-46.SE.bin"

PBR поддерживает. А как бы мы иначе BGP там крутили..? Там без раут-мапов, префикс-листов.... никуда... Соответственно и SDM поставили routing, иначе бы маршруты не поместились бы в память.

Код: Выделить всё: BORDER#show sdm prefer The current template is "desktop routing" template. The selected template optimizes the resources in the switch to support this level of features for 8 routed interfaces and 1024 VLANs. number of unicast mac addresses: 3K number of IPv4 IGMP groups + multicast routes: 1K number of IPv4 unicast routes: 11K number of directly-connected IPv4 hosts: 3K number of indirect IPv4 routes: 8K number of IPv4 policy based routing aces: 0.5K number of IPv4/MAC qos aces: 0.5K number of IPv4/MAC security aces: 1K

Заодно посмотрел еще утилизацю TCAM памяти на каталисте:

Код: Выделить всё: BORDER#show platform tcam utilization CAM Utilization for ASIC# 0 Max Used Masks/Values Masks/values Unicast mac addresses: 400/3200 171/1278 IPv4 IGMP groups + multicast routes: 144/1152 6/26 IPv4 unicast directly-connected routes: 400/3200 171/1278 IPv4 unicast indirectly-connected routes: 1040/8320 646/5054 IPv4 policy based routing aces: 384/512 1/2 IPv4 qos aces: 768/768 328/328 IPv4 security aces: 1024/1024 500/500

Как видно под PBR выделенно 512 enties. И места еще хватает. Если бы проблема была бы в памяти, то роут-мап как минимум вешался бы, а проблемы начинались бы при переполнении... Но сечас ничего подобного нету.
Посмотел документацию к своему IOS'у (http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_46_se/configuration/guide/swuncli.html#wp1072184) . Єтот точно не поддерживает то что я прописывал в роут-мапе

:

Unsupported Route Map Commands:
match route-type for policy-based routing (PBR)
set as-path {tag | prepend as-path-string}
set automatic-tag
set dampening half-life reuse suppress max-suppress-time
set default interface interface-id [interface-id.....]
set interface interface-id [interface-id.....]
set ip default next-hop ip-address [ip-address.....]
set ip destination ip-address mask
set ip next-hop verify-availability
set ip precedence value
set ip qos-group
set metric-type internal
set origin
set metric-type internal
set tag tag-value

В самом последнем IOS'e к каталисте 12.2(55)SE тоже самое :cry:

**root** » 22 окт 2010, 14:48

AxelMAN писал(а):Или же я не правильно Вас понял?

или я тебя, хотя не знаю как ещё понять:

AxelMAN писал(а):Тот провайдер, что наливвает нам UA-IX также входит в состав City-IX.

а раз так, то ответ на вопрос:

AxelMAN писал(а):Как он тогда получит нужные маршруты???

очень прост, из UA-IX и узнает, т.к. туда ты тоже анонсишь свои подсети

AxelMAN писал(а):Тем более, говорил с организатором City-IX, который сказал что не анонсирует никому "левому" наши сети.

эммм... а что вообще понимается под "левыми" ?
я про "левость" не говорил, ессно они анонсят твои маршруты тока пирам, те что входят в City-IX.
no-export не позволит роутерам далее распрострянять твой маршрут, тот что они получили через City-IX
таким образом твой пров который входит и туда и туда, не будет распространять далее (своим пирам) твои more specific маршруты, которые н получит через City-IX

AxelMAN писал(а):PBR поддерживает. А как бы мы иначе BGP там крутили..?

да легко !

Cisco IOS Software, C3560 Software (C3560-ADVIPSERVICESK9-M), Version 12.2(25)SED1, RELEASE SOFTWARE (fc1)
System image file is "flash:/c3560-advipservicesk9-mz.122-25.SED1.bin"

Код: Выделить всё: sh sdm prefer

The current template is "desktop default" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.

number of unicast mac addresses: 6K
number of IPv4 IGMP groups + multicast routes: 1K
number of IPv4 unicast routes: 8K
number of directly-connected IPv4 hosts: 6K
number of indirect IPv4 routes: 2K
number of IPv4 policy based routing aces: 0
number of IPv4/MAC qos aces: 512
number of IPv4/MAC security aces: 1K

Код: Выделить всё: sh ip bgp summary

BGP router identifier XX.XX.XX.210, local AS number YYYYY
BGP table version is 1025, main routing table version 1025
44 network entries using 4972 bytes of memory
85 path entries using 4420 bytes of memory
47/22 BGP path/bestpath attribute entries using 5076 bytes of memory
20 BGP AS-PATH entries using 496 bytes of memory
2 BGP community 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 15012 total bytes of memory
42 received paths for inbound soft reconfiguration
BGP activity 466/418 prefixes, 975/886 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
XX.XX.XX.XX 4 ZZZZZ 117606 123953 1025 0 0 9w3d 41

AxelMAN писал(а):Там без раут-мапов, префикс-листов.... никуда...

все это у меня и на desktop default есть

AxelMAN писал(а):иначе бы маршруты не поместились бы в память.

сморя сколько маршрутов нужно принять

full-view ессно не поместится

AxelMAN писал(а):точно не поддерживает то что я прописывал в роут-мапе

ну тогда типа опа
у меня есть c3750-ipservicesk9-mz.122-53.SE.bin, но там тоже облом:
http://www.cisco.com/en/US/docs/switche ... uncli.html

Unsupported Route Map Commands

match route-type for policy-based routing (PBR)
set as-path {tag | prepend as-path-string}
set automatic-tag
set dampening half-life reuse suppress max-suppress-time
set default interface interface-id [interface-id.....]
set interface interface-id [interface-id.....]
set ip default next-hop ip-address [ip-address.....]
set ip destination ip-address mask
set ip next-hop verify-availability
set ip precedence value
set ip qos-group
set metric-type internal
set origin
set metric-type internal

боюсь что set ip default next-hop нету в IOS`ах для 3750, а точнее не будет эта команда работать на catalyst`ах, видимо ограничение по железу
м.б. что нить с vrf подумать стоит, он может помочь создать несколько таблиц маршрутизации внутри одного роутера, в каталистах vrf есть

A Catalyst 3750 switch supports one global network and up to 26 VRFs.

Configuring IP Unicast Routing => Configuring VRFs

**AxelMAN** » 22 окт 2010, 15:26

root писал(а):очень прост, из UA-IX и узнает, т.к. туда ты тоже анонсишь свои подсети

Ну это я понимаю, просто тогда трафик, который мог-бы лится через канал с City-IX польется через UA-IX-канал.
Короче тут както все так запутно, что я очумеваю ))

root писал(а):я про "левость" не говорил, ессно они анонсят твои маршруты тока пирам, те что входят в City-IX.
no-export не позволит роутерам далее распрострянять твой маршрут, тот что они получили через City-IX
таким образом твой пров который входит и туда и туда, не будет распространять далее (своим пирам) твои more specific маршруты, которые н получит через City-IX

А он и не анонсирует мои most-specific в мир. Ладно, проехали... Попробую сам разобраться ))

root писал(а):боюсь что set ip default next-hop нету в IOS`ах для 3750, а точнее не будет эта команда работать на catalyst`ах, видимо ограничение по железу
м.б. что нить с vrf подумать стоит, он может помочь создать несколько таблиц маршрутизации внутри одного роутера, в каталистах vrf есть

Мда, я тоже думаю, что это апаратное ограничение, поскольку каталиста больше комутатор чем маршрутизатор... Вот и все...
Меня посещала уже такая идея с vrf'ами... В принципе наш BGP сейчас тоже в vrf крутится.
Но я думал, чтобы сделать еще пару vrf, и в одну заганять первый дефолтовый маршрут, а в другую - второй дефолтовый маршрут. Но все уж больно сложно, как для моего уровня, потому что тогда не знаю куда девать таблицы City-IX'a и UA-IX'a, плюс это нужно еще и мои 2 пула заганять как-то в те отдельные vrf'ы...

**root** » 29 окт 2010, 08:22

AxelMAN писал(а):Короче тут както все так запутно, что я очумеваю ))

ну BGP никогда не был простым протоколом, а сложные вещи всегда сложны
что бы легче было осознавать, надо схему нарисовать, со всеми связями, глядя на нее легче понять что к чему.
пол дела за тебя может сделать наш as graph

AxelMAN писал(а):Мда, я тоже думаю, что это апаратное ограничение, поскольку каталиста больше комутатор чем маршрутизатор... Вот и все...

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

AxelMAN писал(а):В принципе наш BGP сейчас тоже в vrf крутится.

хм... мне не совсем понятно зачем, ну да лана

AxelMAN писал(а):делать еще пару vrf, и в одну заганять первый дефолтовый маршрут, а в другую - второй дефолтовый маршрут

ну да, типа того

AxelMAN писал(а):потому что тогда не знаю куда девать таблицы City-IX'a и UA-IX'a

как это куда, туда же в vrf, в соответствии с твоей задачей
а 2-х апстримов в "мир" с разными префами, что бы трафик распределился как ты хочешь

AxelMAN писал(а):Но все уж больно сложно, как для моего уровня

"галаза боятся, а руки делают"

никто ж не рождается с врожденными знаниями и опытом

AxelMAN писал(а):плюс это нужно еще и мои 2 пула заганять как-то в те отдельные vrf'ы...

ну ведь в vrf можно включать интерфейсы, в vrf можно имортить маршруты
просто нуна доку по vrf`у внимательно почтитать

Subnets.ru

Правильная настройка BGP при работе с точками обмена трафика

Правильная настройка BGP при работе с точками обмена трафика

Re: Правильная настройка BGP при работе с точками обмена тра

Re: Правильная настройка BGP при работе с точками обмена тра

Re: Правильная настройка BGP при работе с точками обмена тра

Re: Правильная настройка BGP при работе с точками обмена тра

Re: Правильная настройка BGP при работе с точками обмена тра

Re: Правильная настройка BGP при работе с точками обмена тра

Re: Правильная настройка BGP при работе с точками обмена тра

Кто сейчас на конференции