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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.