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

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

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

 

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

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

network.png

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

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

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

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

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

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

network1.png

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

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

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

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

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


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

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

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


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

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

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

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

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

а обратно:

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

или

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

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

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

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


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

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

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

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

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

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

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

а обратно:

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

или

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

 

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

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

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

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

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

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

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


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

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

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

 

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

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

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

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

 

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

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

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


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

Join the conversation

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

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

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

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

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

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

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