[ad_min_XP]

Добрый день. Пытаюсь понять как организовать достаточно устойчивую сеть. Великих знаний не имею, изучаю всё по ходу появления проблем.

 

Имеется два здания территориально разнесённые, в каждое здание спускаются по одному провайдеру, а между зданиями арендованный L2 канал. С провайдерами подняты BGP, принимаем FV, и анонсится одна сеть /24, между зданиями по L2 поднят iBGP.

 

Пока что сервера и клиенты располагаются в здании 2 поэтому border-2 является ещё и шлюзом анонсируемой подсети. Сеть такая однобокая получилась потому что сначала был заведён провайдер в здание 2 и BGP сессия была только с ним, а потом для отказоустойчивости был заведён провайдер в здание 1.

 

В дальнейшем планируется размещение оборудования и в здании 1, но я не совсем понял как растянуть одну сеть /24 на два здания, это ведь надо и там шлюз делать? Или делать vlan между зданиями для нашей подсети, но как тогда зарезервировать шлюз? VRRP? Но скорее всего растягивать сеть не придётся т.к. в планах арендовать ещё одну подсеть /24, но остаётся вопрос как зарезервировать роутеры.

 

Ещё вопрос в том правильно ли терминировать провайдеров и L2 канал на бордерах или надо заводить их в коммутаторы, а бордеры подключать к ним а-ля router-on-stick? С моей точки зрения коммутатор в случае каких-то проблем с сетью типа DDoS или кривых рук роутеры лягут раньше чем коммутаторы тем самым связь между зданиями останется через L2 канал.

В общем пните в нужном направлении, может есть какой бест практис по этому поводу.

[jffulcrum]

1 час назад, ad_min_XP сказал:

Ещё вопрос в том правильно ли терминировать провайдеров и L2 канал на бордерах или надо заводить их в коммутаторы, а бордеры подключать к ним а-ля router-on-stick? С моей точки зрения коммутатор в случае каких-то проблем с сетью типа DDoS или кривых рук роутеры лягут раньше чем коммутаторы тем самым связь между зданиями останется через L2 канал.

С требованиями безопасности стоит определиться, и потянут ли их коммутаторы, да и роутеры. Возможно, в схему придется внести какие-то МСЭ. Публичные сервер в любом случае напрямую в Интернет выставлять не очень хорошо, там просится DMZ с NAT 1:1 или решения типа HA Proxy/nginx

 

Связь между зданиями у вас останется на коммутаторах лишь в случае плоской сети. Иначе это линк должен быть между маршрутизаторами 'route nat' в вашей схеме. 

 

По резервированию шлюза по умолчанию решения зависят от того, нужно только HA, или нужно и LB. Для VVRP достаточно имеющегося линка L2. Но если вы и так сделали iBGP, можно в и Ip Anycast пойти: Building a BGP Anycast Lab « ipSpace.net blog

 

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

 

[ad_min_XP]

30 минут назад, jffulcrum сказал:

Публичные сервер в любом случае напрямую в Интернет выставлять не очень хорошо, там просится DMZ с NAT 1:1 или решения типа HA Proxy/nginx

Публичные сервера в основном хотят публичные IP сервера напрямую, это что вроде VDS. Сервера которым надо NAT 1:1 сидят за роутером route nat.

 

30 минут назад, jffulcrum сказал:

Связь между зданиями у вас останется на коммутаторах лишь в случае плоской сети. Иначе это линк должен быть между маршрутизаторами 'route nat' в вашей схеме. 

Коммутаторы в моём понимании были нужны для того чтобы на бордерах поднять сессии BGP перекрёстно от двух провайдеров и не терять свзязанность между зданиями в случае сбоя бордера или каких либо работ на нём.

 

30 минут назад, jffulcrum сказал:

По резервированию шлюза по умолчанию решения зависят от того, нужно только HA, или нужно и LB. Для VVRP достаточно имеющегося линка L2. Но если вы и так сделали iBGP, можно в и Ip Anycast пойти: Building a BGP Anycast Lab « ipSpace.net blog

Интересно, тему изучу.

 

30 минут назад, jffulcrum сказал:

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

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

Edited November 28 by ad_min_XP

[Saab95]

В 28.11.2024 в 18:11, ad_min_XP сказал:

не совсем понял как растянуть одну сеть /24 на два здания, это ведь надо и там шлюз делать?

IP адреса можно выдавать поштучно, не используя маску подсети. Поэтому там где надо, там такой адрес и используете.

 

На серверах обычно есть 2 сетевых интерфейса, 1 подключаете к БГП 1, второй подключаете к БГП 2. На каждом интерфейсе устанавливаете один и тот же IP адрес и один и тот же шлюз, метрику устанавливаете на одном выше, на другом ниже. Теперь на сервере будет всегда один и тот же адрес, даже если любой из БГП серверов отключится.

 

Еще можно OSPF настроить.

[TheUser]

12 часов назад, Saab95 сказал:

IP адреса можно выдавать поштучно, не используя маску подсети. Поэтому там где надо, там такой адрес и используете.

 

На серверах обычно есть 2 сетевых интерфейса, 1 подключаете к БГП 1, второй подключаете к БГП 2. На каждом интерфейсе устанавливаете один и тот же IP адрес и один и тот же шлюз, метрику устанавливаете на одном выше, на другом ниже. Теперь на сервере будет всегда один и тот же адрес, даже если любой из БГП серверов отключится.

 

Еще можно OSPF настроить.

 

Какое же говно у Вас в голове.

 

Цитата

Имеется два здания территориально разнесённые, в каждое здание спускаются по одному провайдеру, а между зданиями арендованный L2 канал.

L2 канал зависит от инфраструктуры одного из аплинков? Есть вероятность, что одновременно упадет и аплинк, и канал?

[ad_min_XP]

13 часов назад, Saab95 сказал:

На серверах обычно есть 2 сетевых интерфейса, 1 подключаете к БГП 1, второй подключаете к БГП 2

Извините, но решение на мой взгляд несколько сомнительное

 

1 час назад, TheUser сказал:

L2 канал зависит от инфраструктуры одного из аплинков? Есть вероятность, что одновременно упадет и аплинк, и канал?

Нет, канал организован через сторонние организации и чисто физически расходится с аплинками.

 

В будущем может возникнуть организовывать L2 домен между зданиями для нужд каких-то сервисов и как вариант мы можем канал нарезать на vlan, QinQ через него пролазит. В связи с этим я больше склоняюсь к терминированию канала на каких-то коммутаторах чтобы vlan было удобно спускать до серверов не трогая бордеры. Но остаётся вопрос с расположением бордеров.

Edited November 30 by ad_min_XP

[jffulcrum]

3 часа назад, ad_min_XP сказал:

Извините, но решение на мой взгляд несколько сомнительное

M-LAG тоже, в принципе, вариант резервирования шлюза. Но это уровень коммутаторов.

[ad_min_XP]

27 минут назад, jffulcrum сказал:

M-LAG тоже, в принципе, вариант резервирования шлюза. Но это уровень коммутаторов

На M-LAG планы были только когда поставим по два коммутатора top-of-rack

[Saab95]

9 часов назад, ad_min_XP сказал:

Извините, но решение на мой взгляд несколько сомнительное

Чем же оно сомнительное? В этом случае связь пропадет только при отказе сразу двух маршрутизаторов БГП.

 

Если подключите сервер одним портом в коммутатор, и уже на коммутаторе реализуете резервирование, то при отказе коммутатора связь пропадет.

 

Все критичные сервера всегда подключают в 2 независимых роутера / коммутатора. Т.к. тут вероятность отказа коммутатора / роутера выше, чем вероятность отказа сервера или вышестоящего роутера.

[ad_min_XP]

1 час назад, Saab95 сказал:

Чем же оно сомнительное? В этом случае связь пропадет только при отказе сразу двух маршрутизаторов БГП.

 

Если подключите сервер одним портом в коммутатор, и уже на коммутаторе реализуете резервирование, то при отказе коммутатора связь пропадет.

 

Все критичные сервера всегда подключают в 2 независимых роутера / коммутатора. Т.к. тут вероятность отказа коммутатора / роутера выше, чем вероятность отказа сервера или вышестоящего роутера.

Я сомнительным назвал способ с настройкой одинакового адреса на портах и разной метрики. Я знаком с m-lag с использованием двух коммутаторов для резервирования. И в целом вопрос не в резервировани путей до серверов.

[Morty]

2 часа назад, Saab95 сказал:

Чем же оно сомнительное? В этом случае связь пропадет только при отказе сразу двух маршрутизаторов БГП.

А ещё пусть каждый хостер в каждый vps контейнер засунет bgp, чтобы у каждого клиента был bgp для резервирования... 

Edited November 30 by Morty

[Saab95]

21 час назад, ad_min_XP сказал:

Я сомнительным назвал способ с настройкой одинакового адреса на портах и разной метрики.

Если смотреть на сеть глазами администратора L3 сети, то никаких проблем и даже странностей с этим нет, т.к. IP адрес, один и тот же, можно хоть в 100 местах сети повесить поштучно (с маской /32) и он везде будет работать.

 

В 28.11.2024 в 18:11, ad_min_XP сказал:

В дальнейшем планируется размещение оборудования и в здании 1, но я не совсем понял как растянуть одну сеть /24 на два здания, это ведь надо и там шлюз делать? Или делать vlan между зданиями для нашей подсети, но как тогда зарезервировать шлюз? VRRP? Но скорее всего растягивать сеть не придётся т.к. в планах арендовать ещё одну подсеть /24, но остаётся вопрос как зарезервировать роутеры.

У вас же как раз и был вопрос в резервировании роутеров. И как раз сделав 2 параллельные ветки на коммутаторах от них, или на одних коммутаторах, но с разными вланами, можно зарезервировать подключениями серверов 2-мя патчкордами.

 

То есть в одном здании ставите БГП + коммутатор, во втором здании так же БГП + коммутатор. Коммутаторы соединяете между собой напрямую, и БГП соединяете с собой напрямую, минуя коммутаторы - что бы была возможность между ними прямой передачи данных, вдруг пакет не на тот маршрутизатор придет - так его по линии между ними сразу и перекинут.

 

При такой схеме можно уже дальше расставлять коммутаторы по зданию для связи с помещениями, прокидывая вланы от каждого БГП и иметь в любой точке сети прямую с ними связь.

 

21 час назад, Morty сказал:

А ещё пусть каждый хостер в каждый vps контейнер засунет bgp, чтобы у каждого клиента был bgp для резервирования... 

Сервера на базе windows умеют OSPF, а уж сервера на базе линукс подобных систем и подавно. Можно вообще про слово шлюз забыть как устаревшую технологию.

 

В 28.11.2024 в 18:11, ad_min_XP сказал:

В общем пните в нужном направлении, может есть какой бест практис по этому поводу.

Тут надо смотреть что за сервера, если это виндовс с их AD, где нужна прямая связь - схема одна, если это просто сервера, работающие по IP и им не нужна централизованная выдача адресов и параметров, то другая схема.

 

Если ставите имеющееся оборудования (роутеры, коммутаторы), или планируете закупать новые. Если новые - то какая скорость портов нужна, какие интерфейсы на серверах. Ведь можно до серверов вообще оптоволокно проложить, и подключить сразу в центр сети здания, что бы не думать про ограничение длины в 100 метров витой пары.

[Умник]

В 01.12.2024 в 01:13, Morty сказал:

А ещё пусть каждый хостер в каждый vps контейнер засунет bgp, чтобы у каждого клиента был bgp для резервирования... 

Конечно на каждый контейнер/виртуальную машину не нужно, но схема вполне рабочая и нередко применяемая.

Вот: https://blog.ipspace.net/2016/02/running-bgp-on-servers/. Еще комментарии почитайте.

[ad_min_XP]

Так ли необходимо растягивать BGP на уровень серверов? Вопрос использования адресов одной подсети в двух зданиях не самый главный. Меня интересует как правильно оконечить аплинков, канал между зданиями и расположение бордеров. Есть какие-то устоявшиеся схемы или каждый делает то что ближе и понятнее ему?

[jffulcrum]

Делают на что хватает денег. Бюджет обычно определяет уровень решений.

[ad_min_XP]

Чтож, в целом понял. Раскуриваю мануалы и бюджет. Пока остановлюсь на варианте с коммутаторами.

[Saab95]

28 минут назад, ad_min_XP сказал:

Раскуриваю мануалы и бюджет.

Определитесь с кабелями до оборудования. Сейчас медные кабели дорогие. Вариант протянуть оптику, купить сетевой адаптер с оптическими портами - обойдется дешевле, чем протягивать 100 метров медной витой пары.

[ad_min_XP]

36 минут назад, Saab95 сказал:

Определитесь с кабелями до оборудования.

О каких кабелях речь идёт? Между зданиями канал арендован, внутри зданий медь, тянуть оптику от коммутаторов до серверов смысла не имеет.