[pppoetest]

Это да, неверно сформулировал вопрос.

[rdc]

Или как выше говорили - паковать всё в q-in-q и гнать на брас

Совершенно верно.

 

Трафик будет бегать до терминации.

Ну и пусть себе бегает, какая разница…

[Saab95]

Опция 82 это жутко устаревший костыль на сетях с не управляемым, или криво управляемым оборудованием. В данный момент можно рассматривать только схему влан на клиента с автоматической раздачей адресов внутри этого влана. При чем выдавать адреса на основе IPoE с арендой 5 минут. Если абонент выключил свое оборудование, то его адрес можно освободить и выдать другому клиенту.

 

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

[viver]

А туннель через туннель? Не узнаю вас...

[White_Alex]

Опция 82 это жутко устаревший костыль на сетях с не управляемым, или криво управляемым оборудованием.

ну вот, пришел поручик.....

В данный момент можно рассматривать только схему влан на клиента с автоматической раздачей адресов внутри этого влана. При чем выдавать адреса на основе IPoE с арендой 5 минут. Если абонент выключил свое оборудование, то его адрес можно освободить и выдать другому клиенту.

ну круто чо, vlan на абонента, одни и те же адреса по разным абонентам...

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

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

 

 

прошу прощения камрады, не удержался от реакции на тупой толстый троллинг

[pppoetest]

тупой толстый троллинг

Самое страшное, что оно это всерьёз.

[alks]

Опция 82 это жутко устаревший костыль на сетях с не управляемым, или криво управляемым оборудованием. В данный момент можно рассматривать только схему влан на клиента с автоматической раздачей адресов внутри этого влана. При чем выдавать адреса на основе IPoE с арендой 5 минут. Если абонент выключил свое оборудование, то его адрес можно освободить и выдать другому клиенту.

 

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

аренда адреса в 5 минут это здорово конечно а как скажите идентифицировать сессию на брасе? по DHCP? и каждые 5 минут ее дропать и создавать новую? вы вообще в курсе что 90% клиентов дома стоит вафля как cpe.

 

влан на абонента это значит где-то надо делать q-in-q, терминировать и гнать локальный траф обратно, попутно невнятные схемы выдачи IP и как делать авторизацию? если я хочу авторизацию без радиуса, скажем на базе sce, ну и т.д.

 

вообщем честно говоря на мой взгляд это самая громоздкая cо множеством надстроек и с избыточным трафиком схема ipoe

[vurd]

тупой толстый троллинг

Самое страшное, что оно это всерьёз.

 

Да вы что. Прогресс то идёт, уже в центре нарисовали циску, а не стопку микротиков. Это было неизбежно. Взят очень важный рубеж в осознании Saab-ом реальности, а не "примерно так бы оно могло работать".

[GrandPr1de]

Опция 82 это жутко устаревший костыль на сетях с не управляемым, или криво управляемым оборудованием.

хочу увидеть как тупой свич навешивает опцию 82.....

[Diman_xxxx]

Короче пришел сааб, и перевел любопытный топик на тролинг самого себя. Печально.

[darkagent]

и перевел любопытный топик на тролинг самого себя

этому явлению даже название есть...

[Diman_xxxx]

В моем "мозге" почему-то всплывает вот эта картина, тот что слева, только наверно (возможно) добровольно :)

[Ivan_83]

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

Тоже мне проблема.

Никто никуда не охиреет, для софтины типа релея это вообще не проблема.

[GrandPr1de]

Тоже мне проблема.Никто никуда не охиреет, для софтины типа релея это вообще не проблема.

для релея не проблема, а слушать 4к и больше интерфейсов самим дхцп сервером - чего-то не очень хочется.

[rdc]

какая ему разница, он железный, не треснет

[dIMbI4]

У меня жужжат три варианта на доступе в разных колхозах-

1. простые дот1ку свичи с идентичным конфигом, опшн вешаем повланово на порту агрегации, идет на л3 района, дальше брас

2. простые дот1ку свичи с идентичным конфигом, каждый пакуем в куинку на агрегации, тянем до браса.

3. Доступ с опшн82 и всякими плюшками, влан на дом, агрегация тупой транспорт, идем на л3 района, брас.

Везде динамик реалки, дшсп лиз тайм 10-15 минут. Абонент вырубил комп/ сменил девайс, получи другой ип.

Все варианты рабочие, безпроблемные. Работают вкучу.

Л3 на выбор, 4948 тот еще чугунный паравоз, тянет все что тянется. Дальше ступенька 4948-10ге, потом 4900м. Можно обратить внимание на экстрим.

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

Брас- вот тут простой выбор. Нужен нат- альтернатив я не вижу кроме эриксона. Не надо ната - безусловно asr.

Бордер очень хороший у вас есть на 76й.

Не гонитесь за железом - все в одном, все равно придется разносить на специализированные железяки по мере роста.

[SyJet]

Зачем ему в ядрее вообще что-то из коммутаторов, если есть 76хх? Вот чего я не пойму

[creed]

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

DES-3526 ставятся поступательно. На вторичке сейчас их много, по доступным ценам, софт отточен за года, ремонтировать можем своими силами - чего еще можно желать?

DGS-3100-24TG, C3550 постепенно меняются на DGS-3120-24SC. C3550 сами по себе уже мрут от старости без посторонней помощи, 3100-24TG в целом рабочий аппарат, но не нравится (полуфабрикат - моё сугобо имхо)

Стремимся унифицировать, DGS-3120-24SC используем как всеядную агрегацию (100mbit/1000mbit SFP) для обратной совместимости с домами, где по каким-то причинам всё еще сотка и чаще всего неуправляемый доступ.

Замена доступа на 3526 в бюджет (1 млн.р.) не включена - это уже повседневка, а вот агрегация, ядро, брас и прочее - еще как!, ибо единовременные вложения.

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

 

(клиент) <---> (DES-3526) <----> (DGS-3120-24SC) <-----> (WS-C4948-S)

 

4948 сейчас используется как основной шлюз для всех юзеров (ip интерфейсы на vlan'ax), там же делается блокировка путём созданием static arp entry.

Это не спасает от подстановки чужого ip с mac'ом, поэтому ищу более совершенные методы авторизации и контроля доступа.

За 4948 стоит комбинация из двух PC-бриджей для шейпинга, PC-NAT. Комбинация вполне рабочая, хоть и на пределе. Специально не раскрывал много подробностей, вынесу в отдельный топик.

На C7604 больше ничего вешать не хотим, она неплохо справляется в качестве бордера c двумя Full View и CPU Usage 50%.

Солидарен с dIMbI4, чуть позже докупим для неё WS-X6704-10GE и для спокойного сна еще один PWR-2700-AC/4.

Изменено 22 апреля, 2015 пользователем creed

[Saab95]

ну круто чо, vlan на абонента, одни и те же адреса по разным абонентам...

 

IPoE, никаких потерь адресов нет.

 

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

 

Нет, но откуда пошла эта схема? От привязки к маку.

 

аренда адреса в 5 минут это здорово конечно а как скажите идентифицировать сессию на брасе? по DHCP? и каждые 5 минут ее дропать и создавать новую? вы вообще в курсе что 90% клиентов дома стоит вафля как cpe.

 

Зачем дропать? При продлении аренды сессия не дропается.

 

влан на абонента это значит где-то надо делать q-in-q, терминировать и гнать локальный траф обратно, попутно невнятные схемы выдачи IP и как делать авторизацию? если я хочу авторизацию без радиуса, скажем на базе sce, ну и т.д.

 

Не надо никаких q-in-q, это прошлый век. Все коммутирующее оборудование подключается к маршрутизаторам, которые и переводят трафик на L3, далее по сети все идет в центр. Авторизация делается по IP в центре.

 

вообщем честно говоря на мой взгляд это самая громоздкая cо множеством надстроек и с избыточным трафиком схема ipoe

 

Самая удобная схема, не нужны никакие STP, L2 кольца и прочая гадость.

 

для релея не проблема, а слушать 4к и больше интерфейсов самим дхцп сервером - чего-то не очень хочется.

 

Скоро вообще коммутаторы снимут с производства и будут продаваться только маршрутизаторы.

[darkagent]

бобер, выдыхай...

[White_Alex]

Скоро вообще коммутаторы снимут с производства и будут продаваться только микротики.

fixed, не благодарите :-)

[micho]

Скоро вообще коммутаторы снимут с производства и будут продаваться только маршрутизаторы.

Кто-то начитался сказок про SDN?

[creed]

У клиента к примеру такие статик настройки 10.208.3.164/255.255.0.0 gw 10.208.0.1

На доме установлен управляемый доступ, 3526 в моём случае. Агрегация - 3120-24SC

Требуется запретить абону подставлять чужие ip.

При этом не ограничивать его использованием только одного ip, если у него их несколько.

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

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

 

Я бы в этой ситуации постепенно перевёл бы сеть на схему vlan-per-customer.

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

 

Чем конктретно вариант vlan-per-customer предпочтительнее, какие преимущества это принесет?

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

-Отсутствие привязок по макам? Пока не совсем понимаю, как именно привязать конкретный ip к конкретному QinQ, особенно без opt.82

-Секьюрность?

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

По-идее должно избавить клиента от внутри-свичевого флуда и спуфинга, man-in-middle, и т.п.

Количество маков на порту вроде как можно итак ограничить с помощью port-security.

Однако эту кучу вланов нужно будет где-то терминировать. На агрегации (в моем случае на DGS-3120-24SC)? Не пускать же напрямую в ядро.

Без сегментирования клиенты все равно окажутся в одном L2 бродкасте, только бродкаст этот будет множится еще и в каждый отдельный QinQ, верно?

Как с мультикастом быть? Что с затерминированными вланами делать дальше?

 

3) каким образом осуществлять блокировку?

сегментируйте, настраивайте Traffic Segmentation, loopdetect и т.д.

Мы железобетонно прибиваем IP к порту с помощью ACL автоматически из биллинга. Это исключает *издинг инета. Могу поделиться - пишите личкой.

VLAN per customer хорошо, но боюсь абонентам надо будет перенастраиваться.

 

Буду очень признателен за примеры конфигурации. Не понятно почему понадобится перенастраивать абонентов.

Насколько я понял, vlan-per-customer не применяете. Как сегментируете?

До ACL уже кое-как додумался, и по-идее, даже если у клиентов по несколько ip, правил должно получиться не так уж и много.

Как быть со сменой мака при смене сетевушки? Хранить в БД связку mac-ip-свич-порт, следить за trap'ами от mac-notification и при совпадении порта сбрасывать привязку автоматически?

Если мыслить логически, влан(порт?) со шлюзом должен быть доступен из каждого клиентского. Как и страница с сообщением о блокировке, личный кабинет и прочее.

Реализуемо через traffic segmentation, правильно понимаю?

 

Открыты вопросы по практической релизации:

 

1) vlan-per-customer, терминирование клиентских вланов и всё, что с этим связано.

 

2) Сегментирование /16, так чтобы при этом все продолжало работать со старыми настройками, но не сыпался бродкаст со всего /16 домена

 

3) Можно ли обойтись без прослушавания тысяч вланов на dhcpd, если не будет использоваться opt.82? Например, используя dhcp relay

 

4) Каким образом авторизовывать на порту только разрешенные ip? Желательно без привязок по MAC, чтобы при смене оборудования у клиента всё заработало автоматически.

 

 

Помогите собрать воедино.

Изменено 22 апреля, 2015 пользователем creed

[NiTr0]

Нет, но откуда пошла эта схема? От привязки к маку.

С какой такой радости? Причем опция 82 к привязке к маку? :)

 

Кто-то начитался сказок про SDN?

Нет, кто-то напаривает микротики, будучи продаваном ;)

[Saab95]

1) vlan-per-customer, терминирование клиентских вланов и всё, что с этим связано.

 

Терминируете на районных маршрутизаторах.

 

2) Сегментирование /16, так чтобы при этом все продолжало работать со старыми настройками, но не сыпался бродкаст со всего /16 домена

 

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

 

3) Можно ли обойтись без прослушавания тысяч вланов на dhcpd, если не будет использоваться opt.82? Например, используя dhcp relay

 

Нет.

 

4) Каким образом авторизовывать на порту только разрешенные ip? Желательно без привязок по MAC, чтобы при смене оборудования у клиента всё заработало автоматически.

 

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