технология QinQ

[zvukovik]

Так теорию почитайте. L2 уровень - передача кадров Ethernet. Передаются согласно MAC-адресам и таблицам (т.н. CAM-table) в коммутаторах, а размерчики ограничены. Поэтому для упрощения жизни на L2 придумали qinq, но кадр всё равно надо распаковывать со всеми вытекающими. Поэтому умные дядьки подумали и придумали коммутаторы L3 уровня, где собственно заканчивается широковещательный домен, и идёт оперирование ip пакетами.

Edited January 7, 2016 by zvukovik

[myst]

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

[GrandPr1de]

А если чуть более развернуто? Если с примером, то вообще замечательно было бы. :)

Не ну всё зависит от дизайна сети.

Вот у меня есть пачка старых цисок, собирают линки - терминируют вланы. У меня влан на юзера делается, абонента идентифицирую по опции 82 (с какой именно циски прилетел запрос и по номеру влана).

Мне нет нужды тянуть весь л2 в центр.

Для тех кто использует такие вещи как accel-ppp + ipoe (q-in-q) - нужно тянуть весь л2 до тазика с акцелем, у меня такой нужды нет совершенно.

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

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

 

Ну лично я это так вижу. Может кто добавит ещё чего-то, или поправит меня.

[tehmeh]

Ну это классический L3-connected. Сами с такой схемы уходим на L2-connected, ибо плюшек больше.

[GrandPr1de]

Ну это классический L3-connected. Сами с такой схемы уходим на L2-connected, ибо плюшек больше.

 

и каких же плюшек больше?

[tehmeh]

Ну это классический L3-connected. Сами с такой схемы уходим на L2-connected, ибо плюшек больше.

 

и каких же плюшек больше?

 

Все зависит от подхода, конечно.

 

Например, адреса на одной железке. Можно делать динамический пул, как у больших ребят, экономить публичные адреса, снижать потребность в NAT. На l3-connected надо как-то будет объяснять DHCP, что вот если опция с этой железки, то им надо вот с этих диапазонов любой адрес выдавать. Не гибко. Или например, b2b-клиент переехал из офиса в офис и надо ему, чтобы адресация сохранилась прежней, а у вас он стал приземляться на другой железке, с другими адресами. Надо как-то думать, как перевести.

 

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

 

Авторизовать можно по паре S-TAG, C-TAG, опция 82 заполняется на BRAS, но это на любителя. Снимается всякий функционал вида dhcp snooping с доступа или relay с агрегации, смотря где вы ее добавляете.

 

Минусов тоже хватает, как и везде.

[GrandPr1de]

как я упоминал выше влан на юзера без proxy-arp, абоны просто не видят друг друга :)

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

 

а где нету влан на юзера - максимальная сегментация трафика различными изоляциями портов и прочего

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

 

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

[tehmeh]

А вот "свой гейт" в виде чего реализован? Это loopback интерфейс, на который unnumbered on SVI приземляются пользовательские VLAN? Обычно просто на таких loopback перечисляются несколько сетей через secondary, и абоненты из разных ip-подсетей могут прекрасно общаться друг с другом, так как connected маршруты.

 

Не хочу холивор устраивать на тему l2/l3, просто мы для себя нашли такую схему более применимой. Тем более у нас VLAN на коммутатор, решили переходить на VLAN на абонента, а уж раз такое дело, то совместили это с переездом на BRAS.

 

Не вижу ничего страшного с b2b на брасе. Для L2 мы даем VLAN или QinQ через сеть, это понятно, тут брас не при чем. Для L3VPN очень хорошо вписывается со своим отдельным VRF-ом. А интернетик просто дать - так вообще милое дело, и локалку можно порезать под тариф, чтобы больше заносили. К плюсу такого подхода отмечу - что это централизованное и автоматизированное средство управления услугами. А так попробуй вспомни, когда этот самый выделенный канал надо потушить. Или проблемы разряда: как на нем ограничить скорость, посчитать трафик и так далее.

Edited January 8, 2016 by tehmeh

[GrandPr1de]

А вот "свой гейт" в виде чего реализован? Это loopback интерфейс, на который unnumbered on SVI приземляются пользовательские VLAN? Обычно просто на таких loopback перечисляются несколько сетей через secondary, и абоненты из разных ip-подсетей могут прекрасно общаться друг с другом, так как connected маршруты.

ну это банальным acl можно закрыть, делов то темболее как я говорил, циски у меня старые, вешаешь \22 на лупбек и хватает за глаза

[tehmeh]

А меня еще критикуют за то, что я proxy-arp везде отключаю : )

[man781]

можно долго спорить про плюсы и минусы L2 конектед против L3 конектед.

Что было уже ни раз.

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

Причем, не стоит сейчас уводить спор о нужности или ненужности или срочноcти внедрения ipv6.

 

Т.о. в схеме ipoe + vlan на юзера + приземлениe L2 на брасе - в случае необходимости дать всем юзерам ipv6 - от промежуточных узлов (доступ-агрегация-ядро) дополнительно не понадобится никаких извратов от слово вообще (по определению L2).

 

Все что нужно - обновить ПО и подкрутить конфиг на брасе (ну и разумеется подержка дуал стэка на другом конце - CPE клиента - но это вне зависимости от L2 или L3 коннектед)

Разве не так?

 

Извраты понадобятся на брасе и биллинге

а в случае если до сих пор юзается pppoe - внедрение dual stack проще пареной репы :)

 

Справедливости ради - на данный момент не чувствуем потребности и спроса в ipv6 от слова вообще (раздаем юзерам белые ипв4 - в августе спокойно взяли очередные 4 096 адресов)

И .... это....не юзаем пока ipoe (слишком много переделывать - а зачем если все работает :) - но планируем

[Ivan_83]

У FreeBSD есть скрипт для использования qinq в Netgraph-node.

На русском: www.netlab.linkpc.net/wiki/ru:software:freebsd:ng_vlan

[Diman_xxxx]

в захлеб:-) окружение ребует убрать мобилу

Прлдалжайте:-)