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

Прошу совета по редизайну сети на управляемом оборудовании

Здравствуйте.

 

Ситуация: досталась в администрирование городская сеть на управляемом оборудовании.

С точки зрения строительства физической топологии вроде все сделано нормально: есть уровень додступа

(L2 свичи в домах), узлы агрегации (L2\L3 свичи) к которым "звездой" (оптикой через медиаконвертеры)

подлючены свичи доступа, магистраль ("кольцо") между узлами аггрегации которая подключена к "ядру" сети

если это можно так назвать.

 

Да, с точки зрения правильности физической топологии, не все так гладко и правильно: "звезда" на агрегации хуже

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

Ситуация стандартна: уровень доступа и дистрибьюции построен, переделывать его никто денег не даст.

 

Что стоит: везде стоит Allied Telesyn.

На уровне доступа L2 свичи AT-8524

http://www.alliedtelesis.com/media/datashe...0-family_ds.pdf

 

На дистрибьюции L2\L3 свичи AT-8824 (и небольшое количество AT-8948)

http://www.alliedtelesis.com/media/datashe...0_family_ds.pdf

http://www.alliedtelesis.com/media/datasheets/8948_ds.pdf

 

На ядре сети L2\L3 свитч AT-9924T

http://www.alliedtelesis.com/media/datashe...0_family_ds.pdf

 

Даже беглый взгляд на даташиты показывает, что ничего такого, что требуется от уровня доступа

в нормальной операторской сети Ethernet (не говоря уже об MetroEthernet) свичи доступа не имеют.

Нет ни DCHP Option82, ни 802.1x, ни L2\L3 ACL, ни QoS (есть CoS для маркировки траффика, но на самих

свичах какие-либо инструменты по обработке маркировок, выделении полос и т.п. не присутствуют).

MAC Security есть, но настраивается только с локальной консоли, удаленно ничего не поменяешь.

Про GVRP, Q-in-Q (или MAC-in-MAC) на которых частично основаны некоторые функции в MetroEthernet, разговора

вообще нет, даже на уровне дистрибьюции. АТ-8948 умеют Q-in-Q, но их на сети 10% от количества узлов

агрегации.

 

Теперь собственно, логика. Существует условно назовем "старый", "текущий" и "новый" дизайны.

Старый и текущий - это первоначальный разработанный интегратором(?), текущий - это уже какие-то переделки,

устраняющие баги старого дазайна и добавляющие новые :) Вопрос почему под старый дизайн было так все

спроектировано, как зовут интегратора и откуда у него растут руки не актуален - есть проблемы, их надо решать.

Помощи от того интегратора нет никакой (ну в общем, ситуация не нова). Довольно лирики, теперь факты.

 

СТАРЫЙ ДИЗАЙН: на уровне доступа стоят АТ-8524. По одному на многоэтажку. Не хватает одного - есть

возможность сделать стек из 2-3 устройств. В пределах одного свича АТ-8524 клиенты друг друга не видят

благодаря вендорской реализации технологии называемой у АТ MultipleVLAN. В данном варианте траффик

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

траффик через уровень доступа не гоняет. От уровня доступа все собирается оптикой (звездой) через

медиаконвертеры в медные порты на АТ-8824. На AT-8824 нарезаны VLAN-на-дом, которые изолируют броадкасты.

Тоже в целом неплохо. На АТ-8824 настроены L3 программные фильтры, которые не пускают трафик между вланами.

Каждый AT-8824 работает как PPPoE BRAS, на котором клиенты (физ.лица) и терминируются. При соединении клиент

получает серый адрес 10.Х.Х.Х\32 через который получает доступ к внутренней локалке, Инету и другим сервисам.

При соединении на PPPoE интерфейсы АТ-8824 подвешивает другой L3 программный фильтр, который управляет доступом

конкретного юзера к локалке и сервисам. Билинговая система изменяет содержание данного фильтра в зависимости от

состоянии подписки клиента. Таким образом, на каждом узле агрегации стоит свой BRAS, которые по магистрали соединены

по L3. В магистрали работает OSPF, которая локальный трафик замыкает через нужные BRASы, а внешний (Инет, центральные

сервера контента) выносит на ядро сети, где на чистом L3 все роутится или в инет или на какие-то сервера.

 

В сетке бегало 1,5 десятка VLANов для шибко важных юр.лиц (банки и т.п.). Настроено одно общее STP (благо что физическая

топология у всех VLAN одинаковая). Все нормально, "юрики" довольны, включают свои сетки с сотнями компов прямо как есть,

без роутеров, без шифрования и т.п. и получают свою локалку в чистом виде, как привыкли.

 

В целом вроде все грамотно, оптимизация магистралей, BRAS на узел и все такое. Хорошо? Хорошо да не очень...

Эксплуатация показала, что BRASы из AT-8824 никакие... Фильтры, управляющие доступом к локалке и услугам, программные

и грузят проц на 100% даже при локальном трафике в 50-70 мбит\с в сумме. PPPoE держит плохо, где-то в районе тех

же самых 50-70мбит\с на все соединения в сумме. Сначала все это было не сильно заметно, но как нагрузка начала расти,

то проблемы вылезли. В итоге имелись: низкая скорость на PPPoE соединениях и загрузка гигабитных линков на 5-7%

(из за того что железка быстрее обработать и выдать трафик в магистраль не может, причем как выяснилось в переписке

с вендором, транзитный трафик тоже попадает под анализ, даже если на транзитные порты никаким образом фильтры

не подвешены, неумно - спору нет, почему так - непонятно). Все это привело к тому, что при 100% загрузке проца АТ-8824

теряли всякие важные пакеты (STP BPDU, OSPF LSA), а то и вообще вставали колом, да так, что удаленно свич переставал

на все реагировать, требовалась перезагрузка по питанию.

 

Пареллельно вылезла один раз проблема с дублирующимся MACом. Два клиента (работающие по арендованным VLANам)

каким-то образом оказались 2 одинаковых МАКа (то ли наши меньшие братья-китайцы уже штампуют сетевушки с одинаковыми МАКами,

то ли какой-то умник нашел дрова где это можно руками поменять). Результат один - и на свиче доступа и на дистрибьюции

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

Нашли случайно - отключили один порт на VLAN-е - точка другого клиента заработала нормально. И только потом снифая траффик

поочередно на обеих точках увидели реально одинаковые МАКи на Realtek. Итого: неделя поисков, случайный результат и нет гарантии

что это не повторится вновь. Учитывая что клиентов хотящих именно VLAN все больше и больше, и все больше и больше компов, а каждый

VLAN проходит через всю сеть-кольцо и "размазан" по трем десяткам узлов агрегации, то само по себе понятие какой-то диагностики на L2

в таком варианте отсутвтвует (по крайне мере никакого софта вендор не порекомендовал).

 

 

ТЕКУЩИЙ ДИЗАЙН: после длительных переговоров с вендором результатом которых стало заключение о том, что интегратор который все это

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

Вендором был предложен вариант заменить (дополнительно установить) на каждый узел агрегации нормальный BRAS. Нормальный BRAS из линейки на текущий момент это AT-AR770S с заявленой пропускной способностью в нужном нам режиме (PPPoE+L3 программные фильтры)

на уровне 1гигабита\с. В принципе нормально. Но сапгрейдить 30 узлов добавив на них по устройству в районе $1500-2000 за каждое это

в сумме $45-60к. Немало. Поэтому после долгой переписки с девелоперами и дизайнерами вендора был разработал новый дизайн с центральной

фермой из 2 BRAS на AT-AR770S на которых бы терминировались все физ.лица. Сделали. Схема на уровне кабелей конечно осталась как есть.

На уровне доступа физ.лиц изолировали через MultipleVLAN, на уровне агрегации убрали VLAN-на-дом и сделали один общий VLAN на узел агрегации, в который подключались свичи доступа. Общий VLAN на узел по технологии PrivateVLAN тоже передает трафик только с\на аплинки

(оптическая магистраль). Убрали с AT-8824 все IPFilter и PPPoE BRAS. VLANы с узлов агрегации прокинули транками на 2xAT-AR770S (примерно поровну на каждый BRAS). После долгих переделок софта под такой дизайн (не все там было гладко, и не на все функционала хватало), вся эта конструкция взлетела. Таким образом, в сетке оказалось уже под 50 VLAN (часть клиентских, часть районных с узлов агрегации). Все нормально, клиенты авторизуются через PPPoE, фильтры есть только на 2 AT-AR770, все достаточно шустро анализируется, ACLится и маршутизируется как внутри одного BRAS, так и между ними и наружу. Утилизация магистральных соединений подскочила в 10 раз, клиенты физики говорят в локалке стало работать веселее. Хорошо? Хорошо, но не очень...

 

Некоторое время назад из системы SNMP мониторинга стали пропадать свичи доступа (они находятся там же, где и абоненты физ лица, отдельного ManagementVLAN к сожалению пока нет, но будем делать, хотя и при старом дизайне все было также). Возможно идет подмена IP со стороны абонентов, или спуф ARPов, но результатт в том, что свичи в мониторинге то потухнут, то погаснут. В общем, ситуация неприятная. Плюс к этому, соединения PPPoE стали рваться по таймаутам (LQR Echo Timeout) и вообще, как то все стало нестабильно.

 

Еще вылезла проблема с клиентскими VLAN: у одного клиента с тремя десятками точек на этом VLANе пропал доступ к 5 точкам. Клиент "правильный", на всех точка стоят кошки, кучи маков в VLANе нет, только равное количеству точек. На уровнях доступа МАКи на портах есть, но сниф броадкаст траффка показал что в сети ежесекундно бегают ARP и спрашивают МАКи одних и тех же IP, которые и не работают. Иногда точки начинают работать, пропускают с потерями траффик, фрагментированые пакеты проходят через раз. Налицо какая нестабильность на L2, поймать её в данном варианте организации сети просто физически невозможно. Прошла неделя, клиент нервничает. Проблема стоит на месте.

 

 

Теперь собственно, НОВЫЙ ДИЗАЙН...

 

Хотелось попросить совета. Исходные данные таковы, что уровень доступа никто перестраивать не будет, оборудование такое какое есть. Дистрибьюция тоже. Надо что-то с этим всем такое сделать, чтобы все работало. Под все подразумевается:

- простой способ доступа к сети для физ.лиц (как сейчас - PPPoE, логин\пароль, больше ничего не надо);

- управление доступом к локалке (без шейпирования, просто вкл\выкл);

- возможность иметь в сетке VLANы для клиентов без которых они жить не могут;

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

- (опционально) сетка серая 10.0.0.0\8, кому нужен реальник - НАТим снаружи в серый адрес. В принципе, можно подумать роутинг

и выдавать на PPPoE реальник\32, но что делать с теми клиентами которым нужен к примеру блок 4,8,16 и т.д.? Или только VLAN и саб-интерфейс на кошке которая раздает инет спасет?

 

Понятно, что сейчас модно строить MetroEthernet с его Q-in-Q (MAC-in-MAC), псевдоканалами для более правильной орзанизации VLAN для юр.лиц, GVRP для VLAN-на-клиента для физ.лиц (или 802.1+Radius), Q-in-Q Selective для VLAN-на-сервис и т.д. Вроде как для всего этого в линейке AT что-то где-то кусками есть, но никто купить это не даст. Равно как что-то другое другого вендора. Самая затратная часть (доступ, агрегация) построена и приходится работать с тем что есть. Есть вариант, купить какое-то дополнительное железо на ядро сети. Но опять же вопрос в том, сколько это будет стоить.

 

Благодарю за внимание всех тех, кто осилил это пост:)

 

Вопрос один: конечно текущая сетка уже далеко не пионер-нет, но и назвать её сетью Ethernеt операторского класса язык тоже не поворачивается по изложенным причинам. Все когда то начинали с чего-то, и не все везде строят сразу MetroEthernet на Nortel, Juniper или чем то подобном.

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

 

Из перечитанного на этом форуме (с грустью еще раз вспомнив о том как правильно делаются операторские MetroEthernet сети, вспомнив недобрым словом "интегратора" который делал эту сеть), для себя приметил только вариант с возвратом к схеме разбивки каждого узла агрегации по схеме VLAN на дом, убирании PPPoE, выдачи по DHCP адресов для работы в локалке, выдачи маршрута по умолчанию для обмена трафиком между домами-районами. Но встает проблема управления доступом к локалке: можно конечно выкл\вкл абонентский порт по SNMP или Telnet, но есть клиенты которые работают по тарифам только Инет, локалка им не нужна и платить за неё они не будут. А давать её бесплатно не хотелось бы.

Авторизацию делать на L3 BRAS, на каких нибудь PPTP или других VPN, но почитал тут в соседней ветке про подмену ARP и собирание паролей на "псевдо" L3 концентраторе и как-то не сильно заманчиво получается... В общем, выслушаю мнения предложения. Хочется для начала просто прикинуть варианты. Чем больше - тем лучше, будет из чего выбрать. Хотя, насчет больше я не уверен - пространства для маневра очень мало.

 

Второй вариант - ставить на каждый узел агрегации свой BRAS на AT-AR770S. Из минусов кроме "дорого" вылезает невозможность делать в сетке VLANы, которые бы выходили за пределы BRAS и проходили через всю сеть. AT-AR770S это роутер с оптическими аплинками, которые являются L3 интерфейсами eth0 и eth1. Добавить эти порты в VLAN железка не дает. Клиенты (юрики) которые используют VLAN и откажутся от L3 транспорта есть, и таких 90%. Как вариант - установка BRAS другого вендора, которые позволяют это делать, но это уже потребует переделки билинга под новый набор управляющих команд для изменения фильтров доступа.

 

Заранее большое спасибо за ответы.

Edited by Sergey_Taurus

Share this post


Link to post
Share on other sites

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

Это не у вас сейчас телевидение внедряют? Вы в мск?

Share this post


Link to post
Share on other sites
интересная история. тут голову поломать конечно есть над чем.
Вот и ломаю, уже не первый год. Одной головы уже просто мало,

поэтому и обратился сюда. Людей здесь много, опыта тоже.

Может что и придумаем сообща.

 

Это не у вас сейчас телевидение внедряют? Вы в мск?
Нет.
Edited by Sergey_Taurus

Share this post


Link to post
Share on other sites
есть клиенты которые работают по тарифам только Инет, локалка им не нужна и платить за неё они не будут. А давать её бесплатно не хотелось бы.

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

Share this post


Link to post
Share on other sites
есть клиенты которые работают по тарифам только Инет, локалка им не нужна и платить за неё они не будут. А давать её бесплатно не хотелось бы.
не знаю как у Вас, а у меня нет таких клиентов, которым жаль переплатить насчастные 50 рублей, мне кажется, что проблема надумана, и если даже найдётся десяток таких клиентов, проще их не подключать, чем городить огород, который выйдет дороже и сложнее.

Спору нет. Реально у нас разница между такими тарифами около $5. Теоретически можно убедить сэйлов что эти тарифы нам не нужны и как-то уговорить существующих абонентов платить чуть больше, параллельно расписав сколько всего есть в локалке вкусного.

 

Разговор на самом деле о другом моменте. В варианте VLAN-на-дом: статические серые адреса (без DHCP, т.к. нужна именно серая статика на абонента), статический маршрут на 10.0.0.0\8 через VLAN-интерфейс на AT-8824, авторизация на L3 BRAS или на L2 BRAS (допустим там же, на узле АТ-8824) при которой в туннельное соединение пойдет только Инет (потому что ничего более скоростного AT-8824 пережевать через PPPoE не смогут). Можно поковырять HWFilter, который по заявлению вендора работает на скорости проводов, прикрутить его в VLAN-интерфейсам, как-то переписать билинг чтобы он эти "железные" фильтры изменял. Но, появляются 2 момента:

1) Появляется дополнительные настройки, которые делаются на компе абонента (физика): статические адреса на карточке, статические маршруты. 80% юзеров в этом ничего не понимают и повторить смогут только если суппорт будет из "за руку водить" по окошкам с картинками. Если маршрута не будет - траф польется через PPPoE и завалит железку. Т.е. система усложняется, что не есть хорошо. В случае с L3 BRAS - клиент просто на нём не сможет авторизоваться пока правильно все не пропишет. Сложно все это и непонятно для юзера.

2) Статика (да и динамика) IP без какой-либо защиты от дублирующихся адресов в сегменте, рано или поздно выйдет боком: будет поток звонков что "я забыл какой у меня IP", или "кто-то использует мой адрес и у меня не работает локалка", а также куча народу которая догадается подвесить себе на карточку IP всего сегмента и подвесит весь сегмент. Поиск таких проблем (в виду невозможности их устранения на уровне доступа ни MAC Security ни MAC-IP привязкой - в железе ничего этого нет) будет занимать лювиную долю рабочего времени.

 

Да, есть всякие штуки типа DHCP со списком какому МАКу какой адрес выдать, но как тут еще говорилось не надо юзеров "привязывать" к МАКу, да практически узнать у домохозяйки какой МАК у её нового ноута - невозможно. Поэтому система должна быть максимально простой: логин\пароль, туннельное соединение настраиваемое мастером в виндовс.

Edited by Sergey_Taurus

Share this post


Link to post
Share on other sites

"Нормальный BRAS из линейки на текущий момент это AT-AR770S с заявленой пропускной способностью в нужном нам режиме (PPPoE+L3 программные фильтры)

на уровне 1гигабита\с. В принципе нормально. Но сапгрейдить 30 узлов добавив на них по устройству в районе $1500-2000 за каждое это

в сумме $45-60к."

 

А здесь никакой опечатки нет?... ПППое терминатор на 1Гб за $2000???

Share this post


Link to post
Share on other sites

а сколько у вас сейчас абонентская база, сколько ожидаете через год, два? численность населения в городе и сколько % покрыто сетью?

Share this post


Link to post
Share on other sites

Сколько коммутаторов каждого типа в сети? Какой STP протокол используется? Какой диаметр сети по самому длиному пути?

Share this post


Link to post
Share on other sites

так как в личку мне писать нельзя, то вы уж не обесутьте

(с грустью еще раз вспомнив о том как правильно делаются операторские MetroEthernet сети
дайте сцылку где пишут про это и технологии безопасности о которых вы сами говорили и которых вам нехватает на доступе?

форум это конечно хорошо но знания хочется получать не с чьих то слов и домыслов а из систематизированой литературы...

Share this post


Link to post
Share on other sites

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

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

кому локалка не нужна, давать влан без л3 (наверно, можно 1шт. на весь узел агрегации)

вланы с домов протащить также в ядро до браса(ов), где слушать пппое для интернету.

30 узлов агрегации х 30 свичей доступа(грубо) = 900 вланов, < 4096, можно обойтись без q-in-q

и обязательно управление в отдельный влан!

Edited by ugluck

Share this post


Link to post
Share on other sites

Да походу влан до дома это выходе. И еще вместо PPPoE поднять PPTP с сохранением логина/пароля для выхода во внешку. Ну а кому локалка не нужна пусть и остается а PPPoE.

p.s.

Allied Telesyn... да уж научались в свое время с ними.... Незавидую.. С каждым новым софтом решались одни проблемы, но появлялись другие.

Share this post


Link to post
Share on other sites
"Нормальный BRAS из линейки на текущий момент это AT-AR770S с заявленой пропускной способностью в нужном нам режиме (PPPoE+L3 программные фильтры) на уровне 1гигабита\с. В принципе нормально. Но сапгрейдить 30 узлов добавив на них по устройству в районе $1500-2000 за каждое это

в сумме $45-60к."

 

А здесь никакой опечатки нет?... ПППое терминатор на 1Гб за $2000???

Наблюдал максимум в 400 мбит\с (сумма вх+исх) при 40% нагрузки на CPU. Т.е. в целом думаю для полной нагрузки гигабит можно ожидать, т.к. зависимость по нагрузке практически линейная.

 

 

а сколько у вас сейчас абонентская база, сколько ожидаете через год, два? численность населения в городе и сколько % покрыто сетью?
Не совсем понятно насколько это связано с описанными техническими проблемами. Хорошо, допустим (примерные цифры) что база 2000, онлайн в ЧНН 1000, прирост 500\год, город не миллионник даже близко.

 

Сколько коммутаторов каждого типа в сети? Какой STP протокол используется? Какой диаметр сети по самому длиному пути?
В сети порядка 20 узлов агрегации. Каждый узел агрегации собирает около 20 свичей доступа. Используется RSTP. В нормальном режиме кольцо делится на 2 половинки по 10 узлов в каждой. Или я не так понял понятие "диаметр"?

 

дайте сцылку где пишут про это и технологии безопасности о которых вы сами говорили и которых вам нехватает на доступе?

форум это конечно хорошо но знания хочется получать не с чьих то слов и домыслов а из систематизированой литературы...

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

 

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

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

Вытащить домовые вланы на BRAS не проблема - сейчас так и сделано. Без разницы, будет ли через PPPoE гнаться локалка или только Интернет, в итоге уже сейчас какие-то непонятности на L2 (частые обрывы и т.п.) Так что видится пока только такой вариант: VLAN на дом, далее между вланами роутинг на L3. Для Интернета - PPPoE на агрегации (несколько мегабит интернета с фильтрацией на выходе из сети АТ-8824 потянут).

 

Идея с блэкхолами на агрегации для тех кто не оплатил локалку хорошая.

 

Главные вопросы:

1) Локалка дается по статике. Допустим юзеру настроили эту статику, все нормально, все работает. Оплата за локалку кончилась. IP юзера заблэкхолился на агрегации. Туда же в блэкхол вынесены все неиспользуемые адреса. Что мешает юзеру как-то у соседа узнать адрес на котором все работает и поставить его себе? На свичах доступа никакой защиты, привязки MAC-IP нет. Конечно, поиск кулхацкера суживается до одного свича, но это может быть достаточно долго и трудоемко (в свичах и нормальной ARP таблицы тоже нет...)

2) Для локалки раздали статику, прописали маршруты. Для Интернета - на агрегации слушаем PPPoE. Юзер сбросил сетевые настройки, забыл настроить маршрут - весь траф полился в PPPoE по дефолтному маршруту. Железка вс вероятностью 90% либо загрузилась по полной на обработке PPPoE потока в десятки мегабит локалки или вообще упала (причины описаны в первом посте). Другой вариант: локалка на статике заблэкхолилась, юзер специально убрал маршрут, весь траф полился в PPPoE где на другом конце его поймал такой же умник. В итоге: локалка у обоих работает, через PPPoE. Как с этим быть? С фильтрами на агрегации особо не разгуляешься - они программные, грузят проц сильно. Есть еще аппаратные фильтры, но их функциональности по беглым прикидкам не хватит (хотя надо посмотреть подробнее).

 

Share this post


Link to post
Share on other sites
...

Главные вопросы:

1) Локалка дается по статике. Допустим юзеру настроили эту статику, все нормально, все работает. Оплата за локалку кончилась. IP юзера заблэкхолился на агрегации. Туда же в блэкхол вынесены все неиспользуемые адреса. Что мешает юзеру как-то у соседа узнать адрес на котором все работает и поставить его себе? На свичах доступа никакой защиты, привязки MAC-IP нет. Конечно, поиск кулхацкера суживается до одного свича, но это может быть достаточно долго и трудоемко (в свичах и нормальной ARP таблицы тоже нет...)

2) Для локалки раздали статику, прописали маршруты. Для Интернета - на агрегации слушаем PPPoE. Юзер сбросил сетевые настройки, забыл настроить маршрут - весь траф полился в PPPoE по дефолтному маршруту. Железка вс вероятностью 90% либо загрузилась по полной на обработке PPPoE потока в десятки мегабит локалки или вообще упала (причины описаны в первом посте). Другой вариант: локалка на статике заблэкхолилась, юзер специально убрал маршрут, весь траф полился в PPPoE где на другом конце его поймал такой же умник. В итоге: локалка у обоих работает, через PPPoE. Как с этим быть? С фильтрами на агрегации особо не разгуляешься - они программные, грузят проц сильно. Есть еще аппаратные фильтры, но их функциональности по беглым прикидкам не хватит (хотя надо посмотреть подробнее).

1. убыток от того, что кульхацкер поюзает локалку, невелик. выпалить гада можно по жалобе соседа, простым арпом/пингом с последовательным отключением портов свича доступа. процедура минут на десять, с перекурами. после выпаливания кульхацкеры беруцца на карандаш и при рецидивах высаживаются в отдельный влан без санкций, но под мониторингом, где продолжают хачить друг друга. кто в этом серпентарии окажется круче всех (напр., по мртг) - получает джоб-оффер:)

2. PPPoE - зарезана скорость или считается трафик. если 2 юзера гоняют траф между собой через брас, то ИМХО ничего страшного. скорость-то зарезана на уровне интерфейса PPP :)

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

да, лучше 2, причом в каждом влане по интерфейсу от каждого, кто раньше встанет - того и тапки. в этой схеме и ситуация с локалкой через брас сможет случится лишь 50%случаев, когда оба кульхацкера на одном брасе окажуцца. а пппое принудительно рвать раз в 12(24) часов.

Share this post


Link to post
Share on other sites

пример.

в локалку выдайте 192.168.0.0/24

пппое выдайте 192.168.1.0/24

и не маршрутизируйте эти сети между собой.

все. локалка через пппое не будет работать. и брас напрягаться не будет

 

суть ясна?

Share this post


Link to post
Share on other sites
1. убыток от того, что кульхацкер поюзает локалку, невелик. выпалить гада можно по жалобе соседа, простым арпом/пингом с последовательным отключением портов свича доступа. процедура минут на десять, с перекурами. после выпаливания кульхацкеры беруцца на карандаш и при рецидивах высаживаются в отдельный влан без санкций, но под мониторингом, где продолжают хачить друг друга. кто в этом серпентарии окажется круче всех (напр., по мртг) - получает джоб-оффер:)
Спору нет, убыток невелик, но проблем для тех юзеров кто честно платит абонентку может быть много.

Как я уже говорил, на свичах доступа (да и на дистрибьюции) ARP таблиц нет. Пинговать можно того IP, и то с результатом вида "есть\нет".

Так что поиск кулхацкера будет очень сложным делом.

 

2. PPPoE - зарезана скорость или считается трафик. если 2 юзера гоняют траф между собой через брас, то ИМХО ничего страшного. скорость-то зарезана на уровне интерфейса PPP :)

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

да, лучше 2, причом в каждом влане по интерфейсу от каждого, кто раньше встанет - того и тапки. в этой схеме и ситуация с локалкой через брас сможет случится лишь 50%случаев, когда оба кульхацкера на одном брасе окажуцца. а пппое принудительно рвать раз в 12(24) часов.

Как я писал, так и хотели сделать: на ядро сети поставили два BRAS, прокинули к ним на транках PPPoE. В итоге - после месяца-двух нормальной работы (через PPPoE шла и локалка и Инет) вылезли какие-то глюки на всех вланах по маленьку.

 

в локалку выдайте 192.168.0.0/24

пппое выдайте 192.168.1.0/24

и не маршрутизируйте эти сети между собой.

все. локалка через пппое не будет работать. и брас напрягаться не будет

Вот это интересный вариант. На самом деле примерно так (со смещением) все и выдается, просто есть проблемы в фильтрации пакетов: использованные ранее L3 программные фильтры сильно грузят проц, а аппаратные хоть и не грузят, но сильно громоздкие и к динамическим изменениям менее приспособлены.

 

PS: Только что проверил, и блэкхола на агрегации тоже нет, только на АТ-8948\АТ-9924... Засада.

 

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
Sign in to follow this