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

Снова про отказоустойчивость

Не было проблем - купила баба порося.... В общем появился в ядре второй роутер, типа для отказоустойчивости. 

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

Теперь OSPF, и надо скрость резать на портах на уровне доступа, и анонсится /27 подсеть на каждом access свитче. Ну и DHCP + relay. 

Проблема -  полудинамические адреса у юзеров и перерасход IP адресов, т.к. /27 много а /28 мало. 

Есть ли способ анонсить в OSPF адреса из общего пула, например скажем /22, и не все подряд, а только те, которые фактически используются в данный момент.

 

 

Забыл сказать - свичи на уровне доступа умеют Wire Speed OSPF, то есть все летает нормально...

Share this post


Link to post
Share on other sites

На микротике можно раздавать один адрес на влан, например вы IP-Address указываете 10.10.10.1, а Network = 10.10.10.123 - адрес абонента. Тогда перерасхода адресов нет. Все это прекрасно анонсируется через OSPF.

Share this post


Link to post
Share on other sites

Можно поподробнее об этом? ума не приложу, как динамические адреса проанонсировать на нашем оборудовании

Share this post


Link to post
Share on other sites

Микротик при выдачи адреса по DHCP умеет выполнять скрипт, и то же самое при окончании аренды. Вот с этой помощью и навешиваете нужный белый IP адрес на интерфейс, что бы абонент смог данные передавать после получения белого адреса. По OSPF это все само проанонсируется между обоими микротиками. Но у вас DHCP relay, какие-то коммутаторы - с такой связкой нормально работать не будет. Настраивайте коммутаторы как тупой транспорт с упаковкой во влан, а в центре всем управляйте. И скорость надо не на влане резать, а по IP адресу абонента.

Share this post


Link to post
Share on other sites

Свичи на уровне доступа умеют OSPF, но не умеют туннели типа EOIP, а значит виланы должны терминироваться на этих свичах, т.е никаких больше абонентских виланов в ядре.

Соответственно скрипт DHCP сервера должен добавлять белые адреса на свич доступа, чтобы проанонсить в OSPF. Так?

Share this post


Link to post
Share on other sites

Нет. На свичах вы не сделаете ничего. И то направление, в сторону которого двигаетесь - перенос всего на свичи - тупиковое.

 

Надо на каждом коммутаторе настроить упаковку абонентского порта во влан, все эти вланы пригнать в центр и там терминировать. Если вы хотите уйти от L2 в центре, что правильно, тогда в промежуточных точках на сети установите микротики и запакуйте эти вланы в EoIP туннели или MPLS, и уже это тяните в центр, где на этих интерфейсах и терминируйте абонентов. Есть коммутаторы с поддержкой EoMPLS, на сегодняшний день стоят порядка 140-160 тыс., есть микротик CCR1009, который стоит во много раз дешевле и может сделать все то же на скорости 4-6 гигабит (роутинг + MPLS) и их реально поставить на промежуточных точках сети, и уже по 10Г портам все стянуть в центр.

 

Далее для резервирования - все абонентские вланы заводите копией на 2 сервера доступа, на каждый вешаете DHCP сервер. Абонент создаст запрос на выделение адреса и тот сервер, который ему ответит - с тем абонент и будет работать. Если один сервер грохнется, все абоненты с обрывами сессий перейдут на оставшийся. Другой способ это деление всех абонентских интерфейсов пополам и отключение половины, далее проверкой пингом или иными способами мониторится соседний сервер доступа, при его недоступности включаются отключенные абонентские интерфейсы. Естественно, время аренды IP адреса устанавливается минимальным - 5 минут. Тогда при отвале одного сервера абоненты в течении 5 минут восстановят свою работу.

Share this post


Link to post
Share on other sites

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

У нас в ядре стоят пара CCR1072, в агрегации -  пара CRS317 16S+,  а в доступе  ZYXEL 4600, тоже с 10GBit/s потрами, и это только первая стойка, по плану их будет 8 шт...

В случае падения одного свича отвалятся 28 абонентов, в принципе терпимо. А если упадет CRS317, то это уже почти 400 абонентов. Нужно обеспечить резервирование и на этом уровне. Но CRS317 на таких скоростях - это только L2.

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

Share this post


Link to post
Share on other sites

MPLS то вам зачем? Дотяните вланы до агрегации, а там зароутите их до ядра. Хотите резервирования, какой-нить VRRP+Routing вам в помощь. Не надо никакие скрипты и прочей лабуды, чем проще схема- тем она надежней. А вообще, для ваших скоростей, я бы не юзал софт роутер.

Share this post


Link to post
Share on other sites

Про скрипты это я написал если совсем никакие новомодные технологии не использовать.

 

18 часов назад, maxkst сказал:

У нас в ядре стоят пара CCR1072

Это лишнее, 1072 не нужен на роутинге или шейперах, т.к. его производительность чрезмерно высокая, гораздо эффективнее (и по цене тоже) использовать 1036.

 

18 часов назад, maxkst сказал:

А если упадет CRS317, то это уже почти 400 абонентов. Нужно обеспечить резервирование и на этом уровне.

И часто падает? У нас для агрегации больших скоплений абонентов используются CCR1009 или CCR1016 (модель с большим количеством оптических портов). Эти промежуточные роутеры ни разу не падали сами по себе, если только с питанием что-то случилось. Если устройство сломается - поехать и заменить на другое дело 30 минут. Но если хочется вообще все зарезервировать - ничего не мешает поставить делители на оптику и поставить параллельно второй роутер.

 

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

 

18 часов назад, maxkst сказал:

Поэтому абон. виланы на них терминировать - не вариант.

Сделайте MPLS в центре. Тогда никаких вланов не надо - работайте сразу с L2 интерфейсами внутри MPLS, там и управлять удобнее.

 

Кроме всего, если абоненты физики, то там не нужна прямо такая прозрачная схема резервирования. Если что-то грохнется, то даже 5-10 минут без интернета, часто, остается не замеченной, даже в техподдержку начинают звонить уже после получаса отсутствия связи или больше.

Share this post


Link to post
Share on other sites
11 часов назад, VolanD666 сказал:

Дотяните вланы до агрегации

Если в агрегации две железки, и нужно обеспечить отказоустойчивость на этом уровне, то вланы тянуть до обоих девайсов? 

 

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

И часто падает?

Вообще не падает, пока сами что-то не уроним. Я вообще не сторонник этой гонки за отказоустойчивостью, это хотелки босса. Достаточно BGP на бордере и OSPF в ядре.

 

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

производительность чрезмерно высокая

У нас тут все чрезмерно высокое, 10G only везде, кроме абонентского порта, он 1G, поэтому CCR1009 и CCR1016 - не вариант.

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

Сделайте MPLS в центре. Тогда никаких вланов не надо - работайте сразу с L2 интерфейсами внутри MPLS, там и управлять удобнее.

Работаю сейчас над этим, но похоже что CRS317 в агрегации загнется, он поддерживает Hardware Offload для физических портов, на VPLS я этого не увидел, первый тест показал 20% CPU LOAD при каких то 300MBit/s

Share this post


Link to post
Share on other sites

И еще, у меня в целом не очень хорошее впечатление от MPLS на тиках, сталкивался много раз с явлением,

когда после перестроения OSPF сети VPLS туннели не поднимались, лечилось путем disable-enable соответствующего LDP interface,

а все что лечится таким образом - явно лажа...

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

На словах все так просто и представляется

Share this post


Link to post
Share on other sites
В 3/14/2018 в 21:21, VolanD666 сказал:

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

Насколько я понимаю, резервирование шлюза VRRP работает более-менее адекватно на LAN интерфейсах в схеме WAN-NAT-LAN (не наш вариант).

В ином случае нужно два VRRP и на WAN и на LAN стороне, и  я не знаю, как поведет себя мастер роутер в случае отвала LAN, у которого все впорядке с WAN. 

Share this post


Link to post
Share on other sites
В 3/12/2018 в 12:08, Saab95 сказал:

Микротик при выдачи адреса по DHCP умеет выполнять скрипт

Можно взглянуть на этот скрипт? Просто интересно, как единый DHCP сервер знает, на какой VLAN какой адрес кинуть,

а так же нет ли "бесхозных" адресов, которые по какой-либо причине своевременно не удалились, не приходится ли это как-то отдельно мониторить и подчищать?

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

Share this post


Link to post
Share on other sites

Если вы используете технологию влан на абонента, то на каждый такой влан вешается свой DHCP сервер, и ему уже не надо ничего знать про влан, т.к. он на этом влане висит. Соответственно в настройках DHCP вставляете команду на установку IP на этот интерфейс при начале аренды, и удаление по окончании. Вот и все дела. Если все вланы заведены на один микротик, допустим 1000 вланов, то будет и 1000 DHCP серверов.

 

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

 

Поэтому кратко есть 2 схемы:

 

1. Тянуть все в центр (во вланах или в L2 over L3 туннелях), и там заводить на один или несколько маршрутизаторов, каким-то образом разделяя пользователей на каждый.

2. Терминировать пользователей на удаленных маршрутизаторах и в центре резервировать только каналы связи до них.

 

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

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

 

В любом случае L3 каналы гибче L2, и в большой сети тянуть L2 в центр в чистом виде по L2 не эффективно и сложно резервируется. Все крупные операторы тянут абонентские каналы в центр через MPLS.

 

Share this post


Link to post
Share on other sites
7 часов назад, Saab95 сказал:

Все крупные операторы тянут абонентские каналы в центр через MPLS.

MPLS в чистом виде или с VPLS туннелями поверх OSPF?

Share this post


Link to post
Share on other sites
В 21.03.2018 в 09:27, Saab95 сказал:

то отключится только 100 абонентов.

А если сломается ядро?

Share this post


Link to post
Share on other sites
22 часа назад, maxkst сказал:

MPLS в чистом виде или с VPLS туннелями поверх OSPF?

Разными способами. Естественно, если это оборудование типа цисок/коммутаторов, то в чистом виде. На микротике часто туннелями делают.

 

5 часов назад, myth сказал:

А если сломается ядро?

А оно не сломается. Вопрос же резервирования. Ядро легче резервировать, если не надо терминировать абонентские подключения.

 

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

Share this post


Link to post
Share on other sites

Ядерный свитч сломался. Куда оптика приходит. Что дальше?

Share this post


Link to post
Share on other sites
3 минуты назад, myth сказал:

Ядерный свитч сломался. Куда оптика приходит. Что дальше?

Ага все каналы в один коммутатор, который нафиг тут не сдался=)

 

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

Share this post


Link to post
Share on other sites

 

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

- Nat -

Какой может быть нат, если мы про перерасход айпи адресов говорим. Только белые адреса.

 

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

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

Кольцо L3? Поверх него звезда L2? с двума роутерами Core в центре? И кто из них будет gateway ? 

 

5 часов назад, myth сказал:

Что мешает с L2 сделать так же?

У вас STP работает?

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