[shvlad1]

Добрый день.

Есть клиент, потребляющий FullView (интернет в Global table).

Ему хочется льготный доступ к DATAIX в отдельном вилане. Для этого поднимаю отдельную BGP сессию и в ней отдаю ему префиксы, получаемые с DATAIX.

Естественно, его анонсы одинаковы в рамках новой сессии и сессии c FV и изменение LP для префиксов, получаемых внутри двух разных сессий не разносит исходящий на клиента трафик, т.е. весь исходящий идет либо по новому, либо по старому вилану.

Как поступить, чтобы трафик от DATAIX шел по новому вилану, а остальной - по старому?

Пока в голову приходит создание нового VRF и экспорт маршрутов от DATAIX внутрь данного VRF. Все это дело на цисках (7600).

Правильным путем иду, товарищи? Косяков с реализацией route leaking не должно быть?

Вырезать префиксы DATAIX из FV/поднимать новый стык с DATAIX не предлагать.

[Wingman]

mpls l3vpn? Или, например, разрулить комьюнитями со стороны клиента (так у вас раньше работало =) )?

[shvlad1]

L3vpn не подходит - стык с датаих один и он в гт. Перемычки на роутере между двумя интерфейсами, один из которых в гт, другой в нужном врф , делать не хочу. Можно с помощью med разруливать , но хочется, чтобы это было прозрачно для клиента.

[ugluck]

vrf - это и есть, в некотором роде, L3VPN. я бы высадил стык с DATA-IXом в vrf, с последующим ликом в основную таблицу, т.к. лик роутов от DATA-IX в данный vrf не решит задачу направления трафика от DATA-IX клиенту.

если пакет от data-ix приходит в GRT - нет причин у цыски пихать его в vrf, т.к. в GRT уже есть маршрут от клиента. а вот если пакет приходит в vrf, в котором есть отдельный клиентский стык - пакет будет направлен клиенту по данному маршруту. префиксы от клиентов, всасываемые ликом из grt должны иметь в данном vfrе меньший локалпреф. также применение vrfов помогает против клиентских морспецов на ix-ах.

[shvlad1]

Пока придумал след. схему:

1. Не анонсируем датааиксу в гт префиксы клиента, вырезаем из анонсов клиенту префиксы датааикса

Таким образом решаем проблему входящего от клиента трафика

2. Новый линк помещаем в отдельный врф, настраиваем ликинг из гт в этот врф префиксов датааикса.

Таким образом решаем проблему исходящего трафика.

 

Выйдет?

[ugluck]

новый линк с кем?

пакет от data-ix должен попасть на вашем бордере в vrf, в котором есть маршрут к клиенту через новый/отдельный vlan. как он туда попадет?

[shvlad1]

С клиентом - новый вилан который

[ugluck]

1. Не анонсируем датааиксу в гт префиксы клиента

как data-ix получит префиксы клиента?

[shvlad1]

Получит префиксы от новой сессии.

Старые отдавать не буду

[ugluck]

хех. новая сессия с киентом - в vrf, data-ix - в grt?

если так, то в grt у вас уже есть префиксы клиента, полученные из старого стыка и отфильтрованные в сторону data-ix. отдать в bgp можно лишь префиксы, установленные в таблицу маршрутов (видимые по команде sho ip rout). откуда у вас в grt возьмутся маршруты к клиенту через vrf и как пойдёт трафик к клиенту от вашего аплинка?

вот пара ссылок, там разбирается проблема морспецификов, но решение применимо и для вашей задачи:

http://net-geek.org/dbg/2008/09/overcoming-peer-fraud.html

http://gul-tech.livejournal.com/3790.html

[dazgluk]

В отдельной сессии отдаете ему префиксы DATAIX, получаете его исходящий.

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

А на ваш стык с DataIX придется городить PBR, и по метке (в тупом случае по dst ip) отдавать клиенту входящий траф.

Костыли конечно редкостные, но боюсь по человечески ввашу схему не сделать

[shvlad1]

хех. новая сессия с киентом - в vrf, data-ix - в grt?

если так, то в grt у вас уже есть префиксы клиента, полученные из старого стыка и отфильтрованные в сторону data-ix. отдать в bgp можно лишь префиксы, установленные в таблицу маршрутов (видимые по команде sho ip rout). откуда у вас в grt возьмутся маршруты к клиенту через vrf и как пойдёт трафик к клиенту от вашего аплинка?

вот пара ссылок, там разбирается проблема морспецификов, но решение применимо и для вашей задачи:

http://net-geek.org/dbg/2008/09/overcoming-peer-fraud.html

http://gul-tech.livejournal.com/3790.html

 

Подниму-ка вопрос, снова стал актуальным.

Прочитал ваши ссылки, проблема в том, что апстрим и клиент находятся на разных роутерах в MPLS -сети, а одно из ограничений этой схемы:

•IPv4 prefixes imported into a VRF using this feature cannot be imported into a VPNv4 VRF.

Но аплинк согласился поднять вторую сессию. Можно ли в этом случае что-нибудь придумать?

Напомню, клиент анонсируется одинаково по двум линкам.