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

Internet и peering на ASR9000

Добрый день.

 

Прошу совета, как правильно и эффективно реализовать задачу.

 

Исходные данные (схема во вложении):

Cisco ASR9000, имеет BGP линки до:

- ISP-1 (принимаем full view, анонсируем x.x.x.x/18, y.y.y.y/24)

- ISP-2 (принимаем full view, анонсируем x.x.x.x/18, y.y.y.y/24)

- DC (принимаем сеть  z.z.z.z/24, анонсируем сеть x.x.x.x/18). У DC на интерфейсе стоит access-list разрешать траффик только между z.z.z.z и x.x.x.x

- Client (принимаем y.y.y.y/24, анонсируем full view) 

Все это крутится в одном дефолтном vrf. Проблема в том, что траффик client-а с сети y.y.y.y на z.z.z.z идёт через пиринг до DC, и на интерфейсе DC дропается аксесс листом. Задача что бы трафик от y.y.y.y до z.z.z.z проходил через ISP. 

 

Как я это видел изначально:

1.Создаем 2 VRF - Peering и Internet. 

2.В vrf peering помещаем линк до DC. В vrf INTERNET помещаем линки до ISP-1, ISP-2, Client. Внутренние сети (x.x.x.x) остаются в vrf default.

3.В vrf Peering делаем import/export из/в глобальную таблицу маршрутизации. Так мы достигаем доступности между z.z.z.z и x.x.x.x через peering стык.

4.в vrf Internet делаем import/export из/в глобальную таблицу маршрутизации. Так мы достигаем доступность между x.x.x.x и y.y.y.y, y.y.y.y и z.z.z.z  через ISP.

 

Но, я не учел загрузку по cef увеличивается в два раза, т.к. full view появляется в vrf deafult и vrf Internet. fv всего 700к маршрутов, а fib линейной карты 1m, поэтому она ругается и висит.

На данный момент я вижу решение это pbr c проверкой доступности на интерфейс в сторону  клиента  - if src y.y.y.y and dest z.z.z.z then next-hop isp-1 or isp 2. Но мне это решение не кажется красивым и не знаю насколько ASR отрабтает PBR на 2Gbps траффика, и как это скажется на произодительности. 

 

Кто как видит решение, может я чего-то упускаю из виду. 

 

Спасибо!

 

scheme1.png

Share this post


Link to post
Share on other sites

Стукнуть по башке тому, кто накручивает acl на интерфейса в сторону пиринг партнёров. 

Как на счёт выноса пиринга и своей сети в отдельный vrf? Из него в глобальный сделать дефолтный маршрут. Из глобального в него - маршрут на /18.

Но лучше все-таки стукнуть. 

Share this post


Link to post
Share on other sites

А чем обоснован acl?

Там так много клиентского трафика с /24, что стоит его ограничивать?

Когда появляются слова pbr, vrf обычно стоит задуматься "а надо ли оно", ибо решая глупую хотелку вы в разы усложняете схему.

По факту может быть куда проще перенести стык с дц с бордера на ядро, там всего один префикс, если уж так надо запретить клиенту ходить прямым маршутом. А может быть и не надо, стык пиринга то дешевле поди, чем транзит в isp(1,2,x).

 

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

Share this post


Link to post
Share on other sites
17 hours ago, TheUser said:

Стукнуть по башке тому, кто накручивает acl на интерфейса в сторону пиринг партнёров. 

Как на счёт выноса пиринга и своей сети в отдельный vrf? Из него в глобальный сделать дефолтный маршрут. Из глобального в него - маршрут на /18.

Но лучше все-таки стукнуть. 

Я бы с удовольствием стукнул :), но таковы требования бузопасности, это не совсем DC просто. 

Не совсем понял с дефолтным маршрутом, т.е. я импортирую дефолтный маршрут из глобала в vrf? Но тогда весь исходит уйдет в одного провайдера и все плбшки от фулвью пропадут. Или как-то можно траффик отправить в глобал, что бы он потом ушел по лучшему маршруту в глобале?

 

14 hours ago, vurd said:

А чем обоснован acl?

Там так много клиентского трафика с /24, что стоит его ограничивать?

Когда появляются слова pbr, vrf обычно стоит задуматься "а надо ли оно", ибо решая глупую хотелку вы в разы усложняете схему.

ACL обоснован сооброжениями безопасности как нам сказали. Попробуем побороться с этим, но хотелось бы иметь решение, если всё же не получится снять acl. Траффика в этом пиринге очень мало.
 

Quote

По факту может быть куда проще перенести стык с дц с бордера на ядро, там всего один префикс, если уж так надо запретить клиенту ходить прямым маршутом. А может быть и не надо, стык пиринга то дешевле поди, чем транзит в isp(1,2,x).


Вынос на ядро к сожалению архитектурно не возможен, т.к. наши публичные сети по сути присутствуют только на BG и CGNAT, которые стыкуются напрямую. 
 

Quote

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

Пока так и делаем, но если отвалится второй провайдер клиента, то будут жалобы о недоступности сетей DC.

Будем уламывать о снятии ACL, потому что пока все решения выходят так себе :(

Спасибо за ответ.

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