heap Опубликовано 19 января, 2010 · Жалоба Всем доброго времени. Задался разрешением следующей задачи. По условию мы имеем некий граничный роутер, принимающий на борт два фулл вью. Под ним среди прочего обитает сервер доступа на базе Linux, который раздает интернет при помощи туннелей (PPTP, PPPoE). Основная масса абонентов имеет серый айпи и бегает сквозь НАТ. С другой стороны имеется группа абонентов, имеющих реальные(белые) айпи-адреса. На данный момент все выглядит просто и прозрачно - на граничнике указан статик роут в виде блока в стороны сервера с туннелями. Но ресурса одной железки в виде рутера скоро будет не хватать. Придется балансировать нагрузку между железками (2-3-4). При этом в ходе балансировки любой из абонентов со своим реальником можем появится на любой из раздающих железок. А значит нужно делать динамическую адресацию. На первый взгляд, видится все так. Между граничником и железками раздачи установлены OSPF или iBGP сессии, по которым производится redistribute local без агрегации. То бишь граничник будет получать десятки-сотни-тысячи роутов /32. Насколько сильно это нагрузит граничник? К слову - на месте граничника стоит не легкая железка Cisco 7606-S. Какие еще видятся варианты решения этой нелегкой задачи? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 19 января, 2010 · Жалоба В Вашей схеме отсутствует классическая, хрестоматийная компонента. Ядро. Именно ядро должно собирать "динамику" от BRAS-ов. Это не задача для "бордера". И он с ней рано или поздно справлятся перестанет. Хотя конечно 10-20К маршрутов для роутера, который держит 2 фулвью - это не проблема. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 19 января, 2010 · Жалоба В Вашей схеме отсутствует классическая, хрестоматийная компонента. Ядро. Именно ядро должно собирать "динамику" от BRAS-ов.Это не задача для "бордера". И он с ней рано или поздно справлятся перестанет. Хотя конечно 10-20К маршрутов для роутера, который держит 2 фулвью - это не проблема. Как бы на самом деле сейчас в промежуток вставить "ядро" - получится как зайцу пятая нога - с одной стороны должна лопатить немало трафика, а с другой граничник по большей части будет просто граничник - перекладывать трафло между аплинками и ядром. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsk Опубликовано 19 января, 2010 · Жалоба Если жалко бордер, или нет желания грузить его лишними маршрутами, то вставьте между брасами и бордером L3 свич, пусть на нем все агрегируется, а с бордера так и останется смотрящий в сторону свича статик. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 20 января, 2010 · Жалоба Именно об этом я и говорю. L3 свич сможет и динамику от BRAS-ов собирать. OSPF или RIP (как например у меня) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 20 января, 2010 · Жалоба Именно об этом я и говорю.L3 свич сможет и динамику от BRAS-ов собирать. OSPF или RIP (как например у меня) Это мысль. Спасибо. А какие железки L3 используете? Имеющийся под рукой 3627 от ДЛинка умеет не более 12к префиксов. Не то чтобы мало, но интересно у кого еще что есть :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 20 января, 2010 (изменено) · Жалоба 3560/3750 с ip-services-k9 ios'ом на борту для начала будет придостаточно. использовать для этих целей 36xx от длинка крайне не советую, ибо намучаетесь. cisco естественно... между бордером и l3-свитчем (будем называть его теперь ядром) можно организовать тот же ospf с пониженными таймерами, и проводить суммаризацию сеток по возможным маскам. особой нагрузки на бордер это не даст, но зато избавит от вбивания статиков. Изменено 20 января, 2010 пользователем darkagent Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 20 января, 2010 · Жалоба 3750 - не ставьте. Я на эти грабли настумал. Всего 8К маршрутов. Из них динамических 2 или 3 в зависимости от профиля. Аналогичный HP - тоже 8. Да все одноклассники скорее всего 8. Мы разорились на Cat 6506. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsk Опубликовано 20 января, 2010 (изменено) · Жалоба 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) Изменено 20 января, 2010 пользователем dsk Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 21 января, 2010 · Жалоба 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 но это считай уже полноценное ядро. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 21 января, 2010 · Жалоба 3560/3750 с ip-services-k9 ios'ом на борту для начала будет придостаточно. использовать для этих целей 36xx от длинка крайне не советую, ибо намучаетесь.cisco естественно... между бордером и l3-свитчем (будем называть его теперь ядром) можно организовать тот же ospf с пониженными таймерами, и проводить суммаризацию сеток по возможным маскам. особой нагрузки на бордер это не даст, но зато избавит от вбивания статиков. А можно поподробнее об известных в данном смысле проблемах для 36хх? Я, конечно, в курсе багов и приколов любой оборудки ДЛинк, но в другой ипостасии используются 36хх с OSPF как роутеры - вроде бы ничего пока не заметил массового. Было дело в более старой прошивке - глючил OSPF - но уже вроде бы пофиксили. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 21 января, 2010 · Жалоба да дело даже не столько в багах, сколько в запутанности. проблемы начнутся уже с самого начала - когда вам потребуется альтернатива ацесс-листам для фильтрации in/out. на длинках этого нет, там только пакетными фильтрами резать, количество которых сильно ограничено. дальше веселей - как только встанет вопрос о суммаризации адресов. а если захочется таймеры подкрутить, или path-cost'ами поиграться... ну и то что это процесс исключительно софтовый, а софт у длинка как многие уже знают, не самый стабильный - лучше эту переложить на более стабильное оборудование. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...