Перейти к содержимому
Калькуляторы

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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, потому что пока все решения выходят так себе :(

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.