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

Бюджетный 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к записей ?

Изменено пользователем MaLblsH

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


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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

 

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


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

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

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

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

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

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

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

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


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

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

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

 

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

 

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

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

 

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


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

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

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


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

С каждого 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.

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


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

Я бы в таком случае сделал бы 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

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

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


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

А чем 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 чтобы в него попадали и прямые и обратные пакеты, и оттестировать пока не заработает. Я же не вижу, что у вас там

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

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


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

Join the conversation

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

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

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

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

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

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

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