Гранч-DSL. Vlan (окончание)

Новости.

Вот и приблизилась третья годовщина Екатеринбургской домашней сети "NetWay" (МП "Урал"), в создании которой мне случилось участвовать. Не знаю, сколько еще продюжит эта фирма - за последние полтора месяца интернет у меня дома работал меньше недели. То лежит шлюз, то сегмент, то часть сегмента. :-(. Судя по всему, придется искать другого провайдера.

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

Бесплатное подключение "чужих" абонентов без всяких условий, вообще говоря, запрещенный прием, который имеет смысл использовать только имея приличный запас по цене, и уровню сервиса. Кстати, район, где было сфотографировано объявление, еще год назад был безраздельной вотчиной МП "Урал"...

Но хватит и грустном. Интересной ссылочкой поделился Tavrid. Такой простенький экранчик... Переданный по лазерному лучу.

Оказывается, лазерная связь имеет довольно таки старую и славную историю. В уже несколько позабытой стране СССР первые атмосферные линии были созданы в 60-х годах. В Москве была пущена телефонная линия протяженностью более 5 км, а в Тбилиси - телевизионная, от студийного комплекса до передатчика (длиной 3,5 км).

В первых устройствах АЛС использовался гелий-неоновый лазер с длиной волны излучения 0,63 мкм и мощностью 40мВт, и амплитудная модуляция на базе эффекта Поккельса. Фотоприемником служил фотоумножитель.

Такой вот родственник современным оптолинкам отыскался...

Что бы не уходить далеко от оптотемы, в описание промышленно изготавливаемых устройств лазерной связи Белимов Дмитрий добавил таблицу сравнения устройств - уже в удобном html.

Интереснейшее письмо под заголовком "Как мы меняли Гранчи".

Год наша сеть выходила в инет через канал на Granch'ах 1205. Сопротивления у транзита было замечательное, 580 Ом, но они с трудом вставали при этом на 250к. И вот пришло время сделать плановый апгрейд.

Сеть домашняя - денег мало. Тут как раз Гранч выпустил новую модель SBNI 14 DSL. Скорость до мегабита, полный дуплекс (у старых был полудуплекс), длинная линия не должна мешать. Старые завод уценил на 35% и поменял на новые. (Есть все таки свои прелести, когда производитель под боком. Такая уценка - просто подарок. Прим. Nag).

Первое впечатление - дрова сырые, альфа версия, не иначе. Для установки нужно патчить исходники ядра и компилировать с поддержкой SBNI 14 DSL. Причем патч корректно работает только для версии Linux 2.2.18 и 2.4.17. В противном случае надо править самостоятельно.

Ну да ладно, все это решаем, патчим 2.2.19, компилируем. Фонтан эмоций вызывает то, что для поднятия интерфейса (теперь Гранч в системе обзывается ethX) нужно прописывать в автозагрузке загрузку модуля sbni14e, и уже после этого специальной утилитой указывать параметры работы.

Попытка сделать процесс более удобным, и копание в исходниках драйвера привело к обнаружению еще нескольких скоростных режимов до 1533 кбит! Максимальный режим тут же был запущен и канал поднялся на 1,5 мбит.

Теперь о совсем печальном: на скорости 1,5 мбит гранчи держались максимум 5 минут, после чего вызвали кернел паник и намертво вешали рутеры. На скорости 1мбит держались чуть дольше, до 40 минут. Общение со службой поддержки вызвало мягко говоря удивление. Один фрагмент разговора: рутеры вешаются, кернел паник - А с какими параметрами, с ними это постоянно....

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

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

Добавление несколько дней спустя...

... мегабит держат нормально, т.е. линух 2.2 валится раз в сутки, а 2.4 держится устойчиво. Такое вот достижение.

18.02.2002
Kir

Комментарии, как говорится, излишни. Решение явно для тех, кто не боится трудностей. Зато на 30% дешевле, чем made in china.

Не все vlan одинаково полезны. Окончание.

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

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

Транки умеют делать как коммутаторы с поддержкой 802.1q, так и их более простые собратья. Но это совершенно разные транки, не имеющие между собой ничего общего. Скажем, для описанного в предыдущих обзорах Surecom EP-716X транкинг - это объединение портов в группу, для увеличения скорости передачи данных между двумя коммутаторами (или коммутатором и многопортовой сетевой картой). Такая линия с точки зрения пользователя выглядит как один более скоростной порт.

Получается передача со скоростью 200, 300, 400... до 800 Мбит, соответственно, при объединении 2,3,4...8 портов. Хотя обычно, далее 400 Мбит фантазия разработчиков не идет. Решение жестко завязано на производителя, и вероятность совместной работы в таком режиме Surecom и Compex очень мала (хотя, чем черт не шутит).

В понимании другого "окопа", например Cisco, через транковый порт проходит несколько vlan (с тегами 802.1q или корпоративными аналогами). Служит этот порт (обычно единственный в физическом плане), опять таки, для связи коммутаторов между собой, или коммутатора с сервером.

И самое страшное. Эти два типа транков могут присутствовать одновременно. Т.е. на сгруппированных в транк портах может быть сконфигурирован транк нескольких vlan. Это не сильно заметно в Cisco, которая применяет связь через gigabit'ные порты, но встречается на менее "упертом" оборудовании.

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

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

Пока вся сеть состоит только из одного такого устройства, все прекрасно. Имеет смысл даже представить большой коммутатор в виде нескольких более маленьких. А если нужно маршрутизировать разные сети через сервер - в него можно установить несколько реальных (физических) сетевых карт, соединить их реальными кабелями с реальными портами, прописать нужные Vlan... И получить изолированные "виртуальные" сети.

Такое "экстравагантное" решение даже имеет вполне осмысленную экономику - мощное управляемое устройство намного удобнее, чем несколько более слабых. И пользователей в группы можно помещать, не вставая с удобного стула... Но это все, увы, годится только для относительно небольших "офисных" локалок.

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

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

Реальное применение - сплошь и рядом. Представим, что к единственному коммутатору подключен шлюз в интернет. АДСЛ, оптоволоконный конвертер, просто магистральный маршрутизатор сети провайдера. Вот и практическое использование такого решения.

Логика работы при этом относительно не простая, и часто зависит от производителя. Все исходящие кадры (2 сетевого уровня по модели OSI) форвардятся на единственный серверный порт, и оттуда уходят в шлюз. Хотя есть варианты устройств, которые пересылают кадры с неизвестным destination address (DA) на все порты (ответ при этом не будет получен при "нормальных" настройках программного обеспечения устройств на остальных портах).

Кадры от шлюза поступают на серверный порт, который распоряжается ими как обычный неуправляемы коммутатор. Широковещательные отправляет всем, при известном DA - только адресату.

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

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

Happy end? Да не тут-то было... Важным становится дизайн сети. Если она сделана как "дерево" из коммутаторов, поддерживающих port based vlan, то система хоть и с оговорками, но будет работать. Даже картинка "от Surecom'a" есть:

Однако, если "серверные" порты коммутаторов будут связаны через обычный неуправляемый коммутатор, или хаб - дело табак. Система рушится. Пользователи начинают работать друг с другом напрямую. То же самое произойдет при неправильной настройке сервера (шлюза).

Тем не менее, решение есть - а дискуссию в разрезе "так ли оно" или "стоит ли оно того" надеюсь скоро увидеть на форуме. :-)

Анонс

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

Главной темой следующего выпуска станут примеры реальных прокладок сетей в Днепропетровске, Украина. Ну и новостной блок - содержание которого во многом зависит от ваших писем...