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

Бюджетный FullView на софтовых роутерах Оптимизация трафика в интренет при 2-х аплинках

Доброго времени суток.

Есть 2 провайдера и 2 border'a (FreeBSD). Каждому провайдеру по BGP анонсируем по половнке AS, от провайдеров получаем соответственно 2 дефолтных роута.

С помощью PBR часть абонентов отправляем на border1, а другую часть на border2.

Исходящий трафик в таком случае получается неоптимальный: с border1 до ya.ru, например, пинги 2-3 см, с border2 - 6-7 мс.

В связи с этим хотим реализовать вот такую схемку:

shema.jpg

С каждого border'a отдавать по BGP целую AS, и принимать на каждый FullView. После чего "склеить" префиксы, например меньше \18 (чтоб в 20К записей уложиться), и отдавать их на L3 (Dlink DGS-3610), который будет выбирать более оптимальный исходящий маршрут для исходящего трафика.

При такой схеме есть некоторые вопросы:

1. рассмотрим такую ситуацию:

абонент 10.1.1.1, находящийся за натом 1.1.1.1 (pf), вышел по оптимальному маршруту через em0 border1 до ya.ru. Сам же ya.ru определелил, что ответить будет оптимальней через другой канал, соотвественно пакет вернётся на em0 border2. В одной из тем нашли, что для решения проблемы можно просто соединить 2 бордера между собой напрямую. Делаем на border2 редирект всё что к 1.1.1.1 отправлять на border1, т.к. border2 про этот нат ничего не знает.

Попадёт ли такой пакет, пришедший на em2 border1 с em2 border2, в правильный state, и сработает ли нат для 10.1.1.1 ?

Или же придёться ставить свитч выше обоих бордеров (хотя при таком раскладе придётся занимать лишние куски полосы от бордеров до свитча) ??

2. как лучше сделать: "кастрировать" FullView до 20к записей на самих бордерах и чем их склеивать для отправки на L3 или лучше будет принимать уже на самом L3 только префиксы меньше \18 что бы получилось до 20к записей ?

Edited by MaLblsH

Share this post


Link to post
Share on other sites

Я делал примерно такое на цисках, только BGP на L3-свитч не отдавал.

Прописал 2 дефолта на 3560, он примерно поровну раскидывал, бордеры между собой сами разбирались.

NAT у меня не было, но не вижу препятствий, главное чтобы пакет NAT'ился по выходу...

Share this post


Link to post
Share on other sites
Я делал примерно такое на цисках, только BGP на L3-свитч не отдавал.

Прописал 2 дефолта на 3560, он примерно поровну раскидывал, бордеры между собой сами разбирались.

NAT у меня не было, но не вижу препятствий, главное чтобы пакет NAT'ился по выходу...

Т.е. с 3560 пакеты уходили на один из бордеров независимо от оптимальности маршрута ? Нам бы до попадания пакета на бордер выбрать для него оптимальный маршрут.

А на счёт НАТ'та я не уверен что пакет, вышедший с border1 em0, и вернувшийся через border2 на em2 попадёт в нужный state.

Share this post


Link to post
Share on other sites
Я делал примерно такое на цисках, только BGP на L3-свитч не отдавал.

Прописал 2 дефолта на 3560, он примерно поровну раскидывал, бордеры между собой сами разбирались.

NAT у меня не было, но не вижу препятствий, главное чтобы пакет NAT'ился по выходу...

Т.е. с 3560 пакеты уходили на один из бордеров независимо от оптимальности маршрута ? Нам бы до попадания пакета на бордер выбрать для него оптимальный маршрут.

Пакеты уходили на 2 бордера примерно поровну, поскольку было 2 дефолта.

Если бордеры и каналы не нагружены более 60%, то неважно. Чисто статистически половина трафика перейдёт на другой бордер, ещё до NAT'a.

Оптимальный маршрут выбрать в такой маленькой таблице сложно. Могу только сказать, что более половины исходящего идёт на сети, выданные в последние лет 5...

Так что можно тупо раскидать статиком, 80.0.0.0/4 на один бордер, остальное на другой. :)

А на счёт НАТ'та я не уверен что пакет, вышедший с border1 em0, и вернувшийся через border2 на em2 попадёт в нужный state.
Почитайте про применение спутникового интернета.

Там как раз ответы возвращаются через другой интерфейс (со спутника).

Share this post


Link to post
Share on other sites

Просто спрошу: а зачем на бордерах NAT? Секьюрити?

Я бы отдавал с бордеров по OSPF дефолт в L3. Было бы 2 дефолта на коммутаторе - дальше играйте как хотите.

 

Share this post


Link to post
Share on other sites

Ну если просто делить пользователей поровну - это у нас и так уже сделано.

Вот реальный пример:

игровые сервера Близарда на порядок быстрее работают через один аплинк, яндекс через другой.

Пришлось руками с помощью pbr'ok заруливать на нужный аплинк.

Постоянно ждать жалоб пользователей и городить pbr пока все сервера так не раскидаем ??? Не хотелось бы.

Я бы отдавал с бордеров по OSPF дефолт в L3. Было бы 2 дефолта на коммутаторе - дальше играйте как хотите.
А в опять же оптимальность, если мы будет на L3 отдавать только дефолты ??? Опять же маршруты будут не оптимальны.

Share this post


Link to post
Share on other sites

скажите честно, какой смысл тут в двух бордерах? отказоустойчивость? но циска-то у вас всеравно одна :)

почему бы два аплинка не свести в один бордер, который уже сам разберется с парой full view?

 

думаю до гигабита это вполне нормальным вариантом будет.

 

ну или в крайнем случае - пусть бордеры обменивают по своим em2 маршрутами, таким образом выбирая оптимальный.

в таких случаях подойдет статическое равномерное распределение по бордерам на циске, правда нат придется делать на бордерах (если он у вас есть)

 

Share this post


Link to post
Share on other sites

нат и бордюр разнести на разные железки.

Share this post


Link to post
Share on other sites
С каждого border'a отдавать по BGP целую AS, и принимать на каждый FullView. После чего "склеить" префиксы, например меньше \18 (чтоб в 20К записей уложиться), и отдавать их на L3 (Dlink DGS-3610), который будет выбирать более оптимальный исходящий маршрут для исходящего трафика.

Я бы в таком случае сделал бы redistribute to ospf на бордерах, и отдавал бы агрегированные префиксы на Dlink.

 

При такой схеме есть некоторые вопросы:

1. рассмотрим такую ситуацию:

абонент 10.1.1.1, находящийся за натом 1.1.1.1 (pf), вышел по оптимальному маршруту через em0 border1 до ya.ru. Сам же ya.ru определелил, что ответить будет оптимальней через другой канал, соотвественно пакет вернётся на em0 border2. В одной из тем нашли, что для решения проблемы можно просто соединить 2 бордера между собой напрямую. Делаем на border2 редирект всё что к 1.1.1.1 отправлять на border1, т.к. border2 про этот нат ничего не знает.

Попадёт ли такой пакет, пришедший на em2 border1 с em2 border2, в правильный state, и сработает ли нат для 10.1.1.1 ?

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

и обратных пакетов на каждом из отрезков.

 

 

 

скажите честно, какой смысл тут в двух бордерах? отказоустойчивость? но циска-то у вас всеравно одна :)

почему бы два аплинка не свести в один бордер, который уже сам разберется с парой full view?

А натить-то чем тогда будете ? Там не циска, там dlink.

Share this post


Link to post
Share on other sites
Я бы в таком случае сделал бы redistribute to ospf на бордерах, и отдавал бы агрегированные префиксы на Dlink.
А чем OSPF будет лучше BGP на Dlink, при BGP 20к записей, а OSPF всего 4к ?
Если правильно настроите - то попадет и сработает. Можно даже напрямую два бордера не соединять, а форвардить пакет сквозь Dlink. Нарисуйте на своей схеме стрелочками прохождение прямых

и обратных пакетов на каждом из отрезков.

Вот картинка:

shema2.jpg

 

Зелёными стрелками указан прямой путь, синими - обратный.

Сейчас правила для ната такие:

nat pass on em0 from <LAN> to any -> NET/24

Что бы заработала обратка через em2, нужно прописать его к em0 так:

nat pass on { em0, em2 } from <LAN> to any -> NET/24

или достаточно будет оставить как есть ?

Share this post


Link to post
Share on other sites
А чем OSPF будет лучше BGP на Dlink, при BGP 20к записей, а OSPF всего 4к ?

Прошу прощения, не посмотрел в спецификацию. OSPF меньше жрет, проще настраивается, и более совместим. Я вообще сомневаюсь насчет 20k записей в BGP при 12K ipv4 и 6k ipv6 адресов в таблицах маршрутизации...

 

Что бы заработала обратка через em2, нужно прописать его к em0 так:

nat pass on { em0, em2 } from <LAN> to any -> NET/24

или достаточно будет оставить как есть ?

Достаточно взять выделенный ip, прописать для него отдельные правила nat чтобы в него попадали и прямые и обратные пакеты, и оттестировать пока не заработает. Я же не вижу, что у вас там

кроме этого накручено, а телепаты у нас в отпуске.

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