crash99 Posted June 7, 2019 · Report post Добрый день. Прошу совета, как правильно и эффективно реализовать задачу. Исходные данные (схема во вложении): 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 траффика, и как это скажется на произодительности. Кто как видит решение, может я чего-то упускаю из виду. Спасибо! Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
TheUser Posted June 7, 2019 · Report post Стукнуть по башке тому, кто накручивает acl на интерфейса в сторону пиринг партнёров. Как на счёт выноса пиринга и своей сети в отдельный vrf? Из него в глобальный сделать дефолтный маршрут. Из глобального в него - маршрут на /18. Но лучше все-таки стукнуть. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vurd Posted June 7, 2019 · Report post А чем обоснован acl? Там так много клиентского трафика с /24, что стоит его ограничивать? Когда появляются слова pbr, vrf обычно стоит задуматься "а надо ли оно", ибо решая глупую хотелку вы в разы усложняете схему. По факту может быть куда проще перенести стык с дц с бордера на ядро, там всего один префикс, если уж так надо запретить клиенту ходить прямым маршутом. А может быть и не надо, стык пиринга то дешевле поди, чем транзит в isp(1,2,x). Еще вариант вообще не отдавать сеть дц на клиента или докинуть препендов туда - пускай ломится через других аплинков, вы же ему не дефолт сгружаете, значит там у него есть альтернативные пути. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
crash99 Posted June 8, 2019 · Report post 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, потому что пока все решения выходят так себе :( Спасибо за ответ. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
