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

Посоветуйте по архитектуре сети хочу внедрить linux ISG...

Здравствуйте коллеги!

 

Прошу вашего совета по дизайну сети.

На данный момент архитектура такая - клиентские вланы терминируются на коммутаторах агрегации, коммутаторы объединены единой EXCHANGE сеткой, в сетке бегает OSPF, так что все маршруты на клиентские сетки прописываются автоматом. Дефолт отдается с бордера.

network.png

А хочется внедрить проект linux ISG, чтобы разгрузить бордер от дурацкого занятия типа шейпинга клиентских сеток, и прочего. Но - делать это нужно постепенно, ясное дело, а не перестраивая все разом.

Вот и возник вопрос - как бы это сделать, чтобы:

1. Не перелопачивать структуру сети.

2. Не прописывать статик маршруты руками.

3. В дальнейшем иметь возможность масштабирования.

Пришла в голову только такая идея:

network1.png

На linux-isg сервере в ospf даем redistribute kernel, соответственно, все маршрутизируется само. На коммутаторах агрегации делаем дефолт роут на ISG сервер.

НО - в данном случае нет возможности масштабирования/резервирования, то есть нельзя тупо поставить рядом другой ISG-серв и дать части коммутаторов дефолт на него, ибо как пойдет обратный маршрут? Я лично не понимаю.

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

Посоветуйте, у кого какие идеи есть...

Share this post


Link to post
Share on other sites

Дефолт на свитчах пишите статиком. Тогда просто по мере перенастройки районов меняете на свитче дефолт с бордера на lISG.

Share this post


Link to post
Share on other sites
Дефолт на свитчах пишите статиком. Тогда просто по мере перенастройки районов меняете на свитче дефолт с бордера на lISG.
Это конечно все хорошо, но.

А что с маршрутами на бордере? Тоже статиком каждую сеть на ISG прописывать?

А локальный трафик между свитчами агрегации как пойдет? С исг-клиента:

клиент1-агрегация-исг-агрегация-клиент2

а обратно:

другой клиент-агрегация-агрегация-клиент1

или

другой клиент-агрегация-бордер-агрегация-клиент1

Имеем несимметричный неконтролируемый канал.

То то и оно, что не хочется статиков, по возможности...

Share this post


Link to post
Share on other sites
Дефолт на свитчах пишите статиком. Тогда просто по мере перенастройки районов меняете на свитче дефолт с бордера на lISG.
Это конечно все хорошо, но.

А что с маршрутами на бордере? Тоже статиком каждую сеть на ISG прописывать?

Отдавать по RIP-у бордеру маршруты на подключенных клиентов.

По OSPF не отдавайте - засрется всё. Только клиентов бордеру через RIP (в quagga + lISG это выглядит как redistribute kernel, но нужно патчить кваггу - в ридми есть написано).

А локальный трафик между свитчами агрегации как пойдет? С исг-клиента:

клиент1-агрегация-исг-агрегация-клиент2

а обратно:

другой клиент-агрегация-агрегация-клиент1

или

другой клиент-агрегация-бордер-агрегация-клиент1

Имеем несимметричный неконтролируемый канал.

То то и оно, что не хочется статиков, по возможности...

А почему это локальный трафик должен бегать через ISG/бордер?

Клиент -> Аггрегация (надеюсь, понятно, что L3?) -> Соседний свитч аггрегации (соответственно маршруту, полученному по OSPF) -> Другой клиент.

Локалка будет бегать по маршрутам, полученным по OSPF, все остальное (т.е инет :)) - в дефолт, т.е в ISG.

Share this post


Link to post
Share on other sites
Дефолт на свитчах пишите статиком. Тогда просто по мере перенастройки районов меняете на свитче дефолт с бордера на lISG.
Это конечно все хорошо, но.

А что с маршрутами на бордере? Тоже статиком каждую сеть на ISG прописывать?

Отдавать по RIP-у бордеру маршруты на подключенных клиентов.

По OSPF не отдавайте - засрется всё. Только клиентов бордеру через RIP (в quagga + lISG это выглядит как redistribute kernel, но нужно патчить кваггу - в ридми есть написано).

Хм, кстати да, возможность отдавать маршруты подключеных клиентов с ISG я как-то не учёл, интересный вариант...

А почему не отдавать через OSPF? Не совсем понял значение термина "засрется" :)

Share this post


Link to post
Share on other sites
НО - в данном случае нет возможности масштабирования/резервирования, то есть нельзя тупо поставить рядом другой ISG-серв
с этим проблема будет однозначно как не крути

разве что раздавать серый и натить - и то не всё сладко

Есть конечно вариант использовать ISG сервер как L3 свитч, и терминировать пользовательские вланы на нем... Это конечно даст больший контроль над сеткой, но производительность такого решения вызывает сомения...
а в чём проблема ?

сами думаем внедрять именно так но прикрутить к ISG свой DHCPD relay + свой DHCPD сервер с базой и наними всякими финтами + аналог IP unnumbered - но всё равно будут наверное проблемы с равномерной утилизацией белых адресов....

Отдавать по RIP-у бордеру маршруты на подключенных клиентов
а как вы себе это представляете? то есть заанонсировать только адреса клиентов которые подключены?
Edited by Lynx10

Share this post


Link to post
Share on other sites
Хм, кстати да, возможность отдавать маршруты подключеных клиентов с ISG я как-то не учёл, интересный вариант...

А почему не отдавать через OSPF? Не совсем понял значение термина "засрется" :)

При изменении одного маршрута у OSPF перестраивается вся зона. Оверхед слишком большой.

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

Потому RIP - чем проще, тем лучше.

 

НО - в данном случае нет возможности масштабирования/резервирования, то есть нельзя тупо поставить рядом другой ISG-серв
с этим проблема будет однозначно как не крути

разве что раздавать серый и натить - и то не всё сладко

Есть одна идейка, с Олегом (Умник) обговаривали, но увы - дальше теории не дошло.
Отдавать по RIP-у бордеру маршруты на подключенных клиентов
а как вы себе это представляете? то есть заанонсировать только адреса клиентов которые подключены?

Отдавать бордеру.

А бордер анонсирует по BGP/OSPF всю подсеть.

Кроме того, на бордере полезно иметь blackhole на всю подсеть - перекроется более точными маршрутами (т.е. клиентами), а пакеты на "мёртвые" адреса не будут уходить в дефолт.

Share this post


Link to post
Share on other sites

Вообще вопрос внедрения интересный

то есть у нас л3 клиент пришёл на LISG со своим адресом (откуда пришёл через л3 коммутаторы по л2 - не играет роли - так как в конце концов он будет л3 клиент) - есть варианты

 

1 У клиента серый (нет разницы руками забит или ДХЦП) - и таких как он много и все тупо натятся к белому - это не проблема - маршрутизации динамической как таковой не требуется статика с бордера - масштабированность можна сказать нормальная

2 У клиента белый руками забит (из большой подсети - которая промаршрутизирована статикой или динамикой с бордера на LISG) - клиент имеет дефалт куда то (или Л3 коммутатор или прямо на LISG) - масштабировать проблемно!

2а У клиента белый по ДХЦП (из большой подсети - которая промаршрутизирована статикой или динамикой с бордера на LISG) - - масштабировать более мение (если дефалт на LISG - то можна рядом поставить +1 LISG ) - плохая утилизация белых адресов!

3 У клиента серый но натится 1 в 1 вариант похож на 2а

 

4 мы пробуем (затерминировать кучу вланов) перехватить ДХЦП на LISG - отдать клиенту белый, далее по принципу аннамберед - с костыльным добавлением маршрутов в таблицу на LISG - и соответственно дальше динамически маршрут с LISG на бордер - масштабируемость и утилизация должны быть нормальные

Edited by Lynx10

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