amario Feb 28 2011 at 18:12

Немного о private vlan

2 min

57K

Network technologies*

Comments 36

Alukardd Feb 28 2011 at 18:48

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

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

amario Feb 28 2011 at 18:59

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

amarao Mar 1 2011 at 14:16

Всё не то.

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

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

amario Mar 1 2011 at 14:32

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

amarao Mar 1 2011 at 14:37

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

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

dohlik Jun 1 2011 at 14:59

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

Obramko Aug 4 2014 at 13:24

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

Obramko Aug 4 2014 at 13:31

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

IlyaPodkopaev Apr 22 2011 at 12:04

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

amarao Apr 22 2011 at 14:50

Не хватает.

IlyaPodkopaev Apr 22 2011 at 15:43

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

amarao Apr 22 2011 at 17:13

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

IlyaPodkopaev Apr 22 2011 at 17:15

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

amarao Apr 22 2011 at 17:31

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

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

IlyaPodkopaev Apr 22 2011 at 17:39

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

amarao Apr 22 2011 at 20:34

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

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

IlyaPodkopaev Apr 22 2011 at 21:13

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

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

amarao Apr 22 2011 at 22:18

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

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

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

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

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

IlyaPodkopaev Apr 22 2011 at 22:22

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

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

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

amarao Apr 22 2011 at 22:36

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

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

amario Apr 23 2011 at 11:26

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

amarao Apr 24 2011 at 14:26

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

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

mongolio Jun 1 2011 at 14: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 Aug 9 2012 at 10:46

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

vvh1te Jun 30 2011 at 13:22

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

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

apcsb Aug 12 2012 at 19:02

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

amario Aug 13 2012 at 00:49

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

apcsb Aug 13 2012 at 01:36

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

amario Aug 13 2012 at 10:12

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

amario Mar 1 2011 at 15:10

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

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

make_luv Jun 1 2011 at 14:50

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

amario Jun 1 2011 at 14:59

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

make_luv Jun 1 2011 at 15:01

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

mongolio Jun 1 2011 at 15:26

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

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

fortyseven Oct 28 2011 at 01:23

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

amario Aug 13 2012 at 01:03

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