Данные схемы сетей нарисованы от балды, и изображают абстрактную проводную сеть в частном секторе.
Итак. В наносах серии М5 - версии прошивки 5.3 и выше имеется функция Spanning Tree.
В двух словах, нужна она для автоматического резервирования каналов. Как она работает, описано здесь: http://ru.wikipedia.org/wiki/Spanning_Tree_Protocol
Я расскажу, как я её применил для резервирования на наших сетях.
Изначально, в одной точке стоял "Нанос1" и туда закидывался траффик. От этой точки проводная локалка в частном секторе и росла. Через пару лет, она приобрела довольно дикий вид, ввиду того, что спрогнозировать появление новых абонов было никак нельзя, и кабель тянули куда попало, по мере появления новых заявок.
В результате, мы получили проблему, в том, что на пути кабеля к самому последнему потребителю имеется сотня хабов, которые каждый день отключали по самым разным причинам. То электрики одну улицу отключат, то авария на подстанции, то хозяин дома, где установлен хаб, электричество отключает, то розетки меняет, причём сегодня один, завтра другой, послезавтра третий. А потом всё заново. То есть, чем больше хабов на пути кабеля, тем реже у потребителя работает инет. Обрывы происходили каждый день. Вот тогда мы и задумались о резервировании. Аккумулятор на каждый хаб не поставишь, да и менять аккумуляторы каждые два года тоже не охота.
И тут мне пришло в голову, что я видел в свежей прошивке Наноса опцию "Spanning Tree Protocol".
На самом дальнем конце локалки мы поставили ещё один "Нанос2" и подцепили его к той же AP(Нанос0), что и "Нанос1". На всех трёх включили Spanning Tree. РИС.1
Весь траф сразу пошёл через "Нанос2", а на "Наносе1" график упал на ноль. При разрыве локалки в любой точке, траф автоматически распределялся между обоими наносами. В данном случае, я больше всего боялся кольца из-за кривизны прошивки (оборудование ведь дешёвое, да и мало кому придёт в голову использовать эту функцию). Но всё заработало, как в аптеке !
Так как на точке-многоточке вряд ли получится реализовать более 40 мбит на один нанос, (а он до обрыва работает именно один, так как у второго автоматически отключается LAN-порт), то мне в голову сразу пришла схема на РИС.2, которую мы реализуем, когда понадобится увеличивать пропускную способность канала.
Хотя по уму, если частотная обстановка на базе и видимость позволяет, то лучше реализовать схему, показанную на РИС.3 При таком включении резервируется не только обрыв в любом месте локалки, но и падение одного из каналов.
Итак. В наносах серии М5 - версии прошивки 5.3 и выше имеется функция Spanning Tree.
В двух словах, нужна она для автоматического резервирования каналов. Как она работает, описано здесь: http://ru.wikipedia.org/wiki/Spanning_Tree_Protocol
Я расскажу, как я её применил для резервирования на наших сетях.
Изначально, в одной точке стоял "Нанос1" и туда закидывался траффик. От этой точки проводная локалка в частном секторе и росла. Через пару лет, она приобрела довольно дикий вид, ввиду того, что спрогнозировать появление новых абонов было никак нельзя, и кабель тянули куда попало, по мере появления новых заявок.
В результате, мы получили проблему, в том, что на пути кабеля к самому последнему потребителю имеется сотня хабов, которые каждый день отключали по самым разным причинам. То электрики одну улицу отключат, то авария на подстанции, то хозяин дома, где установлен хаб, электричество отключает, то розетки меняет, причём сегодня один, завтра другой, послезавтра третий. А потом всё заново. То есть, чем больше хабов на пути кабеля, тем реже у потребителя работает инет. Обрывы происходили каждый день. Вот тогда мы и задумались о резервировании. Аккумулятор на каждый хаб не поставишь, да и менять аккумуляторы каждые два года тоже не охота.
И тут мне пришло в голову, что я видел в свежей прошивке Наноса опцию "Spanning Tree Protocol".
На самом дальнем конце локалки мы поставили ещё один "Нанос2" и подцепили его к той же AP(Нанос0), что и "Нанос1". На всех трёх включили Spanning Tree. РИС.1
Весь траф сразу пошёл через "Нанос2", а на "Наносе1" график упал на ноль. При разрыве локалки в любой точке, траф автоматически распределялся между обоими наносами. В данном случае, я больше всего боялся кольца из-за кривизны прошивки (оборудование ведь дешёвое, да и мало кому придёт в голову использовать эту функцию). Но всё заработало, как в аптеке !
Так как на точке-многоточке вряд ли получится реализовать более 40 мбит на один нанос, (а он до обрыва работает именно один, так как у второго автоматически отключается LAN-порт), то мне в голову сразу пришла схема на РИС.2, которую мы реализуем, когда понадобится увеличивать пропускную способность канала.
Хотя по уму, если частотная обстановка на базе и видимость позволяет, то лучше реализовать схему, показанную на РИС.3 При таком включении резервируется не только обрыв в любом месте локалки, но и падение одного из каналов.
Вложения
Комментарий