seagull Опубликовано 24 февраля, 2011 · Жалоба Здравствуйте коллеги! Прошу вашего совета по дизайну сети. На данный момент архитектура такая - клиентские вланы терминируются на коммутаторах агрегации, коммутаторы объединены единой EXCHANGE сеткой, в сетке бегает OSPF, так что все маршруты на клиентские сетки прописываются автоматом. Дефолт отдается с бордера. А хочется внедрить проект linux ISG, чтобы разгрузить бордер от дурацкого занятия типа шейпинга клиентских сеток, и прочего. Но - делать это нужно постепенно, ясное дело, а не перестраивая все разом. Вот и возник вопрос - как бы это сделать, чтобы: 1. Не перелопачивать структуру сети. 2. Не прописывать статик маршруты руками. 3. В дальнейшем иметь возможность масштабирования. Пришла в голову только такая идея: На linux-isg сервере в ospf даем redistribute kernel, соответственно, все маршрутизируется само. На коммутаторах агрегации делаем дефолт роут на ISG сервер. НО - в данном случае нет возможности масштабирования/резервирования, то есть нельзя тупо поставить рядом другой ISG-серв и дать части коммутаторов дефолт на него, ибо как пойдет обратный маршрут? Я лично не понимаю. Есть конечно вариант использовать ISG сервер как L3 свитч, и терминировать пользовательские вланы на нем... Это конечно даст больший контроль над сеткой, но производительность такого решения вызывает сомения... Посоветуйте, у кого какие идеи есть... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 24 февраля, 2011 · Жалоба Дефолт на свитчах пишите статиком. Тогда просто по мере перенастройки районов меняете на свитче дефолт с бордера на lISG. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
seagull Опубликовано 24 февраля, 2011 · Жалоба Дефолт на свитчах пишите статиком. Тогда просто по мере перенастройки районов меняете на свитче дефолт с бордера на lISG.Это конечно все хорошо, но.А что с маршрутами на бордере? Тоже статиком каждую сеть на ISG прописывать? А локальный трафик между свитчами агрегации как пойдет? С исг-клиента: клиент1-агрегация-исг-агрегация-клиент2 а обратно: другой клиент-агрегация-агрегация-клиент1 или другой клиент-агрегация-бордер-агрегация-клиент1 Имеем несимметричный неконтролируемый канал. То то и оно, что не хочется статиков, по возможности... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 24 февраля, 2011 · Жалоба Дефолт на свитчах пишите статиком. Тогда просто по мере перенастройки районов меняете на свитче дефолт с бордера на lISG.Это конечно все хорошо, но.А что с маршрутами на бордере? Тоже статиком каждую сеть на ISG прописывать? Отдавать по RIP-у бордеру маршруты на подключенных клиентов.По OSPF не отдавайте - засрется всё. Только клиентов бордеру через RIP (в quagga + lISG это выглядит как redistribute kernel, но нужно патчить кваггу - в ридми есть написано). А локальный трафик между свитчами агрегации как пойдет? С исг-клиента:клиент1-агрегация-исг-агрегация-клиент2 а обратно: другой клиент-агрегация-агрегация-клиент1 или другой клиент-агрегация-бордер-агрегация-клиент1 Имеем несимметричный неконтролируемый канал. То то и оно, что не хочется статиков, по возможности... А почему это локальный трафик должен бегать через ISG/бордер?Клиент -> Аггрегация (надеюсь, понятно, что L3?) -> Соседний свитч аггрегации (соответственно маршруту, полученному по OSPF) -> Другой клиент. Локалка будет бегать по маршрутам, полученным по OSPF, все остальное (т.е инет :)) - в дефолт, т.е в ISG. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
seagull Опубликовано 24 февраля, 2011 · Жалоба Дефолт на свитчах пишите статиком. Тогда просто по мере перенастройки районов меняете на свитче дефолт с бордера на lISG.Это конечно все хорошо, но.А что с маршрутами на бордере? Тоже статиком каждую сеть на ISG прописывать? Отдавать по RIP-у бордеру маршруты на подключенных клиентов.По OSPF не отдавайте - засрется всё. Только клиентов бордеру через RIP (в quagga + lISG это выглядит как redistribute kernel, но нужно патчить кваггу - в ридми есть написано). Хм, кстати да, возможность отдавать маршруты подключеных клиентов с ISG я как-то не учёл, интересный вариант... А почему не отдавать через OSPF? Не совсем понял значение термина "засрется" :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Lynx10 Опубликовано 25 февраля, 2011 (изменено) · Жалоба НО - в данном случае нет возможности масштабирования/резервирования, то есть нельзя тупо поставить рядом другой ISG-сервс этим проблема будет однозначно как не крути разве что раздавать серый и натить - и то не всё сладко Есть конечно вариант использовать ISG сервер как L3 свитч, и терминировать пользовательские вланы на нем... Это конечно даст больший контроль над сеткой, но производительность такого решения вызывает сомения...а в чём проблема ? сами думаем внедрять именно так но прикрутить к ISG свой DHCPD relay + свой DHCPD сервер с базой и наними всякими финтами + аналог IP unnumbered - но всё равно будут наверное проблемы с равномерной утилизацией белых адресов.... Отдавать по RIP-у бордеру маршруты на подключенных клиентова как вы себе это представляете? то есть заанонсировать только адреса клиентов которые подключены? Изменено 25 февраля, 2011 пользователем Lynx10 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 25 февраля, 2011 · Жалоба Хм, кстати да, возможность отдавать маршруты подключеных клиентов с ISG я как-то не учёл, интересный вариант...А почему не отдавать через OSPF? Не совсем понял значение термина "засрется" :) При изменении одного маршрута у OSPF перестраивается вся зона. Оверхед слишком большой.Кроме того, свитчи имеют обыкновение от большого кол-ва маршрутов загибаться. Потому RIP - чем проще, тем лучше. НО - в данном случае нет возможности масштабирования/резервирования, то есть нельзя тупо поставить рядом другой ISG-сервс этим проблема будет однозначно как не крути разве что раздавать серый и натить - и то не всё сладко Есть одна идейка, с Олегом (Умник) обговаривали, но увы - дальше теории не дошло. Отдавать по RIP-у бордеру маршруты на подключенных клиентова как вы себе это представляете? то есть заанонсировать только адреса клиентов которые подключены? Отдавать бордеру.А бордер анонсирует по BGP/OSPF всю подсеть. Кроме того, на бордере полезно иметь blackhole на всю подсеть - перекроется более точными маршрутами (т.е. клиентами), а пакеты на "мёртвые" адреса не будут уходить в дефолт. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Lynx10 Опубликовано 25 февраля, 2011 (изменено) · Жалоба Вообще вопрос внедрения интересный то есть у нас л3 клиент пришёл на LISG со своим адресом (откуда пришёл через л3 коммутаторы по л2 - не играет роли - так как в конце концов он будет л3 клиент) - есть варианты 1 У клиента серый (нет разницы руками забит или ДХЦП) - и таких как он много и все тупо натятся к белому - это не проблема - маршрутизации динамической как таковой не требуется статика с бордера - масштабированность можна сказать нормальная 2 У клиента белый руками забит (из большой подсети - которая промаршрутизирована статикой или динамикой с бордера на LISG) - клиент имеет дефалт куда то (или Л3 коммутатор или прямо на LISG) - масштабировать проблемно! 2а У клиента белый по ДХЦП (из большой подсети - которая промаршрутизирована статикой или динамикой с бордера на LISG) - - масштабировать более мение (если дефалт на LISG - то можна рядом поставить +1 LISG ) - плохая утилизация белых адресов! 3 У клиента серый но натится 1 в 1 вариант похож на 2а 4 мы пробуем (затерминировать кучу вланов) перехватить ДХЦП на LISG - отдать клиенту белый, далее по принципу аннамберед - с костыльным добавлением маршрутов в таблицу на LISG - и соответственно дальше динамически маршрут с LISG на бордер - масштабируемость и утилизация должны быть нормальные Изменено 25 февраля, 2011 пользователем Lynx10 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...