Jump to content
Калькуляторы

Анонсирование injected-routes внутри AS

Опасное колдунство. Как-то один из наших аплинков решил пошаманить таким образом с нашими префиксами (в целях некой оптимизации прохождения трафика), а наша ас-ка из нескольких регионов анонсировалась, без внутренней связности между бордерами, поэтому был прописан allow as-in. И когда нам прилетели наши же префиксы, побитые на более мелкие, было очень неприятно.

да, наверное некоторая опасность есть, поэтому я рекомендовал бы в таком route-map добавить "set community no-export" при инжектировании (если это возможно)

 

но само реешение мне понравилось, креативненько

Share this post


Link to post
Share on other sites

лупбэк правильно (а не интерфейс нейбора) заматчен префикс листом?

 

Интерфейс, апдейты по ним проставлены

у вас iBGP пиринг не по лупбэкам? матчить надо именно лупбэк (source а не next-hop).

Share this post


Link to post
Share on other sites

Усе,

особенности route-reflectot - из-за того что next-hop приходит от источника, где есть сеть

чистый next-hop self на reflector-client не применяется

но если отдавать роут мап с префиксом и set ip next hop -атрибут меняется, все проходит, пингуется и трассируется

 

Ядро

show ip cef exact-route x.x.x.x 208.91.60.94

x.x.x.x -> 208.91.60.94 => IP adj out of VlanX, addr 172.20.20.2

 

Прозрачный роутер

x.x.x.x -> 208.91.60.94 => IP adj out of FastEthernet0/0.Y, addr 172.30.30.2

 

border

x.x.x.x -> 208.91.60.94 => IP adj out of GigabitEthernet0/3.Z, addr uplink

Share this post


Link to post
Share on other sites

hatter@atom:~$ traceroute 208.91.60.94

traceroute to 208.91.60.94 (208.91.60.94), 30 hops max, 60 byte packets

1 name (x.x.x.x) 0.457 ms 0.425 ms 0.491 ms

2 172.20.20.2 (172.20.20.2) 1.817 ms 2.219 ms 2.520 ms

3 172.30.30.2 (172.30.30.2) 7.193 ms 7.437 ms 10.246 ms

4 uplink (addr) 15.045 ms 15.254 ms 16.066 ms

5 addr (addr) 10.673 ms 11.220 ms 12.027 ms

6 addr (addr) 12.579 ms 10.453 ms 9.582 ms

7 6-1-5.bear1.Russia2.Level3.net (213.242.122.141) 29.363 ms 29.409 ms 29.661 ms

8 ae-1-60.edge3.Washington4.Level3.net (4.69.149.18) 142.146 ms 141.237 ms ae-2-70.edge3.Washington4.Level3.net (4.69.149.82) 142.593 ms

9 ae-1-60.edge3.Washington4.Level3.net (4.69.149.18) 141.803 ms 141.282 ms ae-2-70.edge3.Washington4.Level3.net (4.69.149.82) 142.544 ms

10 NETWORK-STR.edge3.Washington4.Level3.net (4.53.116.90) 141.126 ms 141.247 ms 140.817 ms

11 * * *

12 * * *

13 * * *

14 * * *

15 * * *

16 *^C

hatter@atom:~$ ping 208.91.60.94

PING 208.91.60.94 (208.91.60.94) 56(84) bytes of data.

64 bytes from 208.91.60.94: icmp_seq=1 ttl=246 time=137 ms

64 bytes from 208.91.60.94: icmp_seq=2 ttl=246 time=136 ms

64 bytes from 208.91.60.94: icmp_seq=3 ttl=246 time=137 ms

^C

--- 208.91.60.94 ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 2002ms

rtt min/avg/max/mdev = 136.963/137.060/137.159/0.434 ms

Share this post


Link to post
Share on other sites

Почему не хотите пойти по протоптанной дорожке и поставить какой-нибудь dpi (например, sce)?

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

Отталкиваясь от этого, я считаю, весьма оправданным поиск альтернативных решений.

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

Тазик с кваггой, прикрученный по ebgp - самый простой и легко масштабируемый вариант (тазиков можно поставить много, на каждый - отруливать часть списка, фильтруется только исходящий трафик, если тазик поломался - всё идёт мимо), когда только вводили эту обязательную фильтрацию - в Йоте мы сделали именно так. Сейчас есть и коммерческие решения, принцип отруливания трафика - аналогичный.

 

По поводу того, кто именно из аплинков нам подгадил в побивкой префиксов - уже и не припомню, давно дело было. Вроде бы Глобалнет, но может и ошибаюсь. В любом случае, случай был единичным, а allow-as-in после этого поубирали на бордерах (перешли на рекурсивные дефолты, для того что бы абоненты одного региона могли достучаться до абонентов другого).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this