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

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

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

 

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

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

 

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

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


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

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

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

 

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


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

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

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

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

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


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

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

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


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

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

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

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


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

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

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

 

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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)

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

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


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

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

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

 

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


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

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

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

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

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

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


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

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

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

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


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

Join the conversation

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

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

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

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

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

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

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