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

Анонсирование разразненных роутов наверх

Всем доброго времени.

 

Задался разрешением следующей задачи. По условию мы имеем некий граничный роутер, принимающий на борт два фулл вью. Под ним среди прочего обитает сервер доступа на базе Linux, который раздает интернет при помощи туннелей (PPTP, PPPoE). Основная масса абонентов имеет серый айпи и бегает сквозь НАТ. С другой стороны имеется группа абонентов, имеющих реальные(белые) айпи-адреса. На данный момент все выглядит просто и прозрачно - на граничнике указан статик роут в виде блока в стороны сервера с туннелями. Но ресурса одной железки в виде рутера скоро будет не хватать. Придется балансировать нагрузку между железками (2-3-4). При этом в ходе балансировки любой из абонентов со своим реальником можем появится на любой из раздающих железок. А значит нужно делать динамическую адресацию.

На первый взгляд, видится все так. Между граничником и железками раздачи установлены OSPF или iBGP сессии, по которым производится redistribute local без агрегации. То бишь граничник будет получать десятки-сотни-тысячи роутов /32. Насколько сильно это нагрузит граничник? К слову - на месте граничника стоит не легкая железка Cisco 7606-S.

 

Какие еще видятся варианты решения этой нелегкой задачи?

Share this post


Link to post
Share on other sites

В Вашей схеме отсутствует классическая, хрестоматийная компонента. Ядро. Именно ядро должно собирать "динамику" от BRAS-ов.

Это не задача для "бордера". И он с ней рано или поздно справлятся перестанет. Хотя конечно 10-20К маршрутов для роутера, который держит 2 фулвью - это не проблема.

 

Share this post


Link to post
Share on other sites
В Вашей схеме отсутствует классическая, хрестоматийная компонента. Ядро. Именно ядро должно собирать "динамику" от BRAS-ов.

Это не задача для "бордера". И он с ней рано или поздно справлятся перестанет. Хотя конечно 10-20К маршрутов для роутера, который держит 2 фулвью - это не проблема.

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

Share this post


Link to post
Share on other sites

Если жалко бордер, или нет желания грузить его лишними маршрутами, то вставьте между брасами и бордером L3 свич, пусть на нем все агрегируется, а с бордера так и останется смотрящий в сторону свича статик.

Share this post


Link to post
Share on other sites

Именно об этом я и говорю.

L3 свич сможет и динамику от BRAS-ов собирать. OSPF или RIP (как например у меня)

Share this post


Link to post
Share on other sites
Именно об этом я и говорю.

L3 свич сможет и динамику от BRAS-ов собирать. OSPF или RIP (как например у меня)

 

Это мысль. Спасибо. А какие железки L3 используете? Имеющийся под рукой 3627 от ДЛинка умеет не более 12к префиксов. Не то чтобы мало, но интересно у кого еще что есть :)

Share this post


Link to post
Share on other sites

3560/3750 с ip-services-k9 ios'ом на борту для начала будет придостаточно. использовать для этих целей 36xx от длинка крайне не советую, ибо намучаетесь.

cisco естественно...

между бордером и l3-свитчем (будем называть его теперь ядром) можно организовать тот же ospf с пониженными таймерами, и проводить суммаризацию сеток по возможным маскам. особой нагрузки на бордер это не даст, но зато избавит от вбивания статиков.

Edited by darkagent

Share this post


Link to post
Share on other sites

3750 - не ставьте.

Я на эти грабли настумал.

Всего 8К маршрутов.

Из них динамических 2 или 3 в зависимости от профиля.

Аналогичный HP - тоже 8.

Да все одноклассники скорее всего 8.

Мы разорились на Cat 6506.

Share this post


Link to post
Share on other sites

cat3550-12T, routing template:

   
  number of unicast mac addresses:   6K
  number of igmp groups:             6K
  number of qos aces:                1K
  number of security aces:           1K
  number of unicast routes:          24K
  number of multicast routes:        6K

 

cat ME3750, также routing:

  number of unicast mac addresses:                  3K
  number of IPv4 IGMP groups + multicast routes:    1K
  number of IPv4 unicast routes:                    11K
  number of directly-connected IPv4 hosts:        3K
  number of indirect IPv4 routes:                 8K
  number of IPv4 policy based routing aces:         0.5K
  number of IPv4/MAC qos aces:                      0.25K
  number of IPv4/MAC security aces:                 1K

 

Кстати может опытные цисководы подскажут про отсутствие в 3550 деления unicast routes на directly-connected IPv4 hosts и indirect IPv4 routes.

Означает ли это что любой из типов может занять эти самые 24К? (В таком раскладе правда упремся в unicast mac addresses)

Edited by dsk

Share this post


Link to post
Share on other sites
3750 - не ставьте.

Я на эти грабли настумал.

Всего 8К маршрутов.

Из них динамических 2 или 3 в зависимости от профиля.

Аналогичный HP - тоже 8.

Да все одноклассники скорее всего 8.

Мы разорились на Cat 6506.

тогда еще вариант с 4500 серией:

http://www.cisco.com/en/US/prod/collateral...Data_Sheet.html

IP v4 Routing Entries : 128000 для всех SVE, и 256k у SVE 6-E

но это считай уже полноценное ядро.

 

Share this post


Link to post
Share on other sites
3560/3750 с ip-services-k9 ios'ом на борту для начала будет придостаточно. использовать для этих целей 36xx от длинка крайне не советую, ибо намучаетесь.

cisco естественно...

между бордером и l3-свитчем (будем называть его теперь ядром) можно организовать тот же ospf с пониженными таймерами, и проводить суммаризацию сеток по возможным маскам. особой нагрузки на бордер это не даст, но зато избавит от вбивания статиков.

А можно поподробнее об известных в данном смысле проблемах для 36хх? Я, конечно, в курсе багов и приколов любой оборудки ДЛинк, но в другой ипостасии используются 36хх с OSPF как роутеры - вроде бы ничего пока не заметил массового. Было дело в более старой прошивке - глючил OSPF - но уже вроде бы пофиксили.

Share this post


Link to post
Share on other sites

да дело даже не столько в багах, сколько в запутанности. проблемы начнутся уже с самого начала - когда вам потребуется альтернатива ацесс-листам для фильтрации in/out. на длинках этого нет, там только пакетными фильтрами резать, количество которых сильно ограничено. дальше веселей - как только встанет вопрос о суммаризации адресов. а если захочется таймеры подкрутить, или path-cost'ами поиграться...

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

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