amario28 фев 2011 в 15:12

Немного о private vlan

2 мин

62K

Сетевые технологии *

Комментарии 36

Alukardd 28 фев 2011 в 15:48

И через trunk порт можно пропустить только primary vlan т.е. по сути технология живет на отдельно взятом коммутаторе.

эм… trunk порт и pvlan не связные вещи как бы… А касательно вашей фразы, то всё наоборот: trunk порт не может быть объявлен promiscuous портом.

amario 28 фев 2011 в 15:59

спасибо! оговорился, исправил.

amarao 1 мар 2011 в 11:16

Всё не то.

Главное, что хочет индустрия: возможности устройствам, находящимся в одной сети (L3 network) иметь возможность работать посредством только L3, то есть чтобы они не видели L2 трафик друг друга, но могли обращаться по IP.

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

amario 1 мар 2011 в 11:32

ну такое не возможно. по крайней мере по существующей модели osi. И если и будет возможно, то только в не близком будущем.

amarao 1 мар 2011 в 11:37

У меня есть пара идей как это сделать — маршрутизатор должен отвечать на who has своим MAC'ом на все активные IP в его сетевом сегменте и дальше работать с пакетом как при обычной маршрутизации. В этом случае private vlan позволит изолировать клиентов на L2, а L3 будет обрабатываться машрутизатором, даже в одном сетевом сегменте.

PS У меня начинается когнитивный диссонанс из-за ников.

dohlik 1 июн 2011 в 10:59

Щас amario еще и аватарку такую же поставит ;)

Obramko 4 авг 2014 в 09:24

Я вот случайно увидел этот комментарий и вспомнил, что именно такое делает accel-ppp в схеме с ipoe на QinQ. Там каждый пользователь в отдельном VLAN-е, навешивается ip unnumbered и proxyarp.

Obramko 4 авг 2014 в 09:31

И опять же случайно нашёл: похоже, такая же схема реализовывается в Extreme Summit с помощью PVLAN + configure iparp add proxy. Есть в Concepts Guide.

IlyaPodkopaev 22 апр 2011 в 08:04

а чем Вам не хватает возможностей PVLAN? isolated — и вперед…

amarao 22 апр 2011 в 10:50

Не хватает.

IlyaPodkopaev 22 апр 2011 в 11:43

очень емкий и информативный ответ

amarao 22 апр 2011 в 13:13

Как узлам между друг другом по L3 ходить?

IlyaPodkopaev 22 апр 2011 в 13:15

написать маршрут через gateway

amarao 22 апр 2011 в 13:31

С какой стати узел будет отправлять трафик соседу по сети на шлюз?

Сколько я с людьми, которые про PVLAN'ы не говорил, практически никто из них не понимает, чем «сосед по сети» отличается от «другой сети в том же канальном сегменте». Проблема не сетями, проблема в изоляции клиентов одной сети. По спекам они должны на L2 взаимодействовать, а нам этого не хочется. В этом и есть главная драма.

IlyaPodkopaev 22 апр 2011 в 13:39

если напишете маршрут к своей подсети с большей маской через шлюз (например, для подсети с /24 два маршрута с /25) — трафик будет ходить через шлюз.

amarao 22 апр 2011 в 16:34

Чушь говорите. Direct connected networks отправляются локально.

Вот про эту проблему я и говорил — как начнёшь с человеком говорить, выясняется, что он основ IP-машрутизации не знает.

IlyaPodkopaev 22 апр 2011 в 17:13

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

И, amarao, полегче, Вы не в колхозе лекции по квантовой физике читаете.

amarao 22 апр 2011 в 18:18

Упс. Спасибо. Я был не прав, узкий машрут выигрывает даже если он directly connected.

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

Мы не можем принудить клиентские машины ходить на шлюз вместо arp-запроса к соседу без прописывания ему пачки таблиц маршрутизации. А власти над клиентскими машинами мы не имеем.

Далее: я не знаю (это интересно, так что я проверю это завтра), будет ли маршрутизатор маршрутизировать трафик в ту же сеть, из которой принял пакет (не физический интерфейс, а именно сеть).

Хотя идея внезапно стала интересной…

IlyaPodkopaev 22 апр 2011 в 18:22

начну с конца: кошка — да, будет. на антициске тут недавно даже жалоба на это в форуме. За остальные не поручусь. Только icmp redirect отключить для спокойствия.

про клиентские машины — понял, тут пока в голову ничего не приходит.

Рад, что пришли к конценсусу.

amarao 22 апр 2011 в 18:36

Спасибо большое, я пишу пока идею в трекер, я буду над ней сильно думать.

Потому что это вполне себе решение для EVG (IEEE 802.1Qbg), позволяющее избавить машины от чуждого им трафика полностью и окончательно.

amario 23 апр 2011 в 07:26

А власти над клиентскими машинами мы не имеем.
А по dhcp, роуты кинуть на тачки есть возможность?

amarao 24 апр 2011 в 10:26

Нет, статика.

Да и «власть» я имел в виду другого плана — клиенты вольны делать в своих машинах что угодно, пока это не направлено на помехи окружающим.

mongolio 1 июн 2011 в 10:26

Можно даже элегантнее — local proxy arp:
«The local proxy ARP feature allows the Multilayer Switching Feature Card (MSFC) to respond to ARP requests for IP addresses within a subnet where normally no routing is required. With the local proxy ARP feature enabled, the MSFC responds to all ARP requests for IP addresses within the subnet and forwards all traffic between hosts in the subnet.»

casperrr 9 авг 2012 в 06:46

Влан на юзера? Одна L3 сеть нужной ширины на лупбеке + ip-unnumbered + proxy arp, если хостам надо общаться между собой?
Навроде вот этого www.opennet.ru/base/cisco/catalyst_ip_unnumber.txt.html

vvh1te 30 июн 2011 в 09:22

Не знаю что у вас за индустрия, и на какие промышленные системы вы смотрели, но подобный функционал у нас реализован с помощью ip unnumbered на Cisco.

www.opennet.ru/base/cisco/catalyst_ip_unnumber.txt.html

apcsb 12 авг 2012 в 15:02

Я правильно понял, что это решение требует отдельный VLAN на каждого пользователя?

amario 12 авг 2012 в 20:49

Да. Ибо, 3-ий уровень. Ну… или каждому клиенту по порту на маршрутизаторе (не l3 коммутатор).

apcsb 12 авг 2012 в 21:36

Так неинтересно :) А уж поддерживать это дело вообще напряг, если не использовать какие-нибудь средства автоматизации.
Local Proxy ARP выглядит интереснее.

amario 13 авг 2012 в 06:12

Это решение используется у операторов, а у них практикуется автоматизация на unix-like системах, в частности фряху любят.

amario 1 мар 2011 в 12:10

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

ps сам путаюсь с никами, но так уж получилось, я сам забил свой ник на хабре но потом оказалось что инфайт перестал жить :). при следущей регистрации уже нельзя было выбрать ник. в любом случае он не сильно отличался от amario т.е. mario но уже было бы намного просче в различии.

make_luv 1 июн 2011 в 10:50

Блин, статья интересная, но из-за бесконечных «ться» читать невозможно. Я не граммар-нацци, но это реально бесит.

amario 1 июн 2011 в 10:59

Исправил. Извините, но с русским у меня действительно не сильно хорошо.

make_luv 1 июн 2011 в 11:01

Спасибо, теперь с удовольствием прочту)

mongolio 1 июн 2011 в 11:26

И через trunk порт нельзя нельзя пропустить pvlan. т.е. по сути технология живет на отдельно взятом коммутаторе.

Для ознакомления — www.cisco.com/en/US/tech/tk389/tk814/technologies_configuration_example09186a008017acad.shtml#multiple_switch

fortyseven 27 окт 2011 в 21:23

В JunOS можно размазать на несколько коммутаторов начиная с 10.4

amario 12 авг 2012 в 21:03

Убрал… Это утверждение родилось у меня в связи с тем, что оборудование Allied telesis, не умеет через транк работать. А я с этой технологией как раз, больше, на их оборудовании работал.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий