Comments 36
И через trunk порт можно пропустить только primary vlan т.е. по сути технология живет на отдельно взятом коммутаторе.эм… trunk порт и pvlan не связные вещи как бы… А касательно вашей фразы, то всё наоборот: trunk порт не может быть объявлен promiscuous портом.
спасибо! оговорился, исправил.
Всё не то.
Главное, что хочет индустрия: возможности устройствам, находящимся в одной сети (L3 network) иметь возможность работать посредством только L3, то есть чтобы они не видели L2 трафик друг друга, но могли обращаться по IP.
Я не видел промышленных систем, которые могли бы делать такое.
Главное, что хочет индустрия: возможности устройствам, находящимся в одной сети (L3 network) иметь возможность работать посредством только L3, то есть чтобы они не видели L2 трафик друг друга, но могли обращаться по IP.
Я не видел промышленных систем, которые могли бы делать такое.
ну такое не возможно. по крайней мере по существующей модели osi. И если и будет возможно, то только в не близком будущем.
У меня есть пара идей как это сделать — маршрутизатор должен отвечать на who has своим MAC'ом на все активные IP в его сетевом сегменте и дальше работать с пакетом как при обычной маршрутизации. В этом случае private vlan позволит изолировать клиентов на L2, а L3 будет обрабатываться машрутизатором, даже в одном сетевом сегменте.
PS У меня начинается когнитивный диссонанс из-за ников.
PS У меня начинается когнитивный диссонанс из-за ников.
Щас amario еще и аватарку такую же поставит ;)
Я вот случайно увидел этот комментарий и вспомнил, что именно такое делает accel-ppp в схеме с ipoe на QinQ. Там каждый пользователь в отдельном VLAN-е, навешивается ip unnumbered и proxyarp.
а чем Вам не хватает возможностей PVLAN? isolated — и вперед…
Не хватает.
очень емкий и информативный ответ
Как узлам между друг другом по L3 ходить?
написать маршрут через gateway
С какой стати узел будет отправлять трафик соседу по сети на шлюз?
Сколько я с людьми, которые про PVLAN'ы не говорил, практически никто из них не понимает, чем «сосед по сети» отличается от «другой сети в том же канальном сегменте». Проблема не сетями, проблема в изоляции клиентов одной сети. По спекам они должны на L2 взаимодействовать, а нам этого не хочется. В этом и есть главная драма.
Сколько я с людьми, которые про PVLAN'ы не говорил, практически никто из них не понимает, чем «сосед по сети» отличается от «другой сети в том же канальном сегменте». Проблема не сетями, проблема в изоляции клиентов одной сети. По спекам они должны на L2 взаимодействовать, а нам этого не хочется. В этом и есть главная драма.
если напишете маршрут к своей подсети с большей маской через шлюз (например, для подсети с /24 два маршрута с /25) — трафик будет ходить через шлюз.
Чушь говорите. Direct connected networks отправляются локально.
Вот про эту проблему я и говорил — как начнёшь с человеком говорить, выясняется, что он основ IP-машрутизации не знает.
Вот про эту проблему я и говорил — как начнёшь с человеком говорить, выясняется, что он основ IP-машрутизации не знает.
локальная таблица маршрутизации ничем не хуже любой другой. если маршрут будет с большей маской — он выиграет у directly-connected.
И, amarao, полегче, Вы не в колхозе лекции по квантовой физике читаете.
И, amarao, полегче, Вы не в колхозе лекции по квантовой физике читаете.
Упс. Спасибо. Я был не прав, узкий машрут выигрывает даже если он directly connected.
Ок, теперь говорю более развёрнуто.
Мы не можем принудить клиентские машины ходить на шлюз вместо arp-запроса к соседу без прописывания ему пачки таблиц маршрутизации. А власти над клиентскими машинами мы не имеем.
Далее: я не знаю (это интересно, так что я проверю это завтра), будет ли маршрутизатор маршрутизировать трафик в ту же сеть, из которой принял пакет (не физический интерфейс, а именно сеть).
Хотя идея внезапно стала интересной…
Ок, теперь говорю более развёрнуто.
Мы не можем принудить клиентские машины ходить на шлюз вместо arp-запроса к соседу без прописывания ему пачки таблиц маршрутизации. А власти над клиентскими машинами мы не имеем.
Далее: я не знаю (это интересно, так что я проверю это завтра), будет ли маршрутизатор маршрутизировать трафик в ту же сеть, из которой принял пакет (не физический интерфейс, а именно сеть).
Хотя идея внезапно стала интересной…
начну с конца: кошка — да, будет. на антициске тут недавно даже жалоба на это в форуме. За остальные не поручусь. Только icmp redirect отключить для спокойствия.
про клиентские машины — понял, тут пока в голову ничего не приходит.
Рад, что пришли к конценсусу.
про клиентские машины — понял, тут пока в голову ничего не приходит.
Рад, что пришли к конценсусу.
А власти над клиентскими машинами мы не имеем.
А по dhcp, роуты кинуть на тачки есть возможность?
А по dhcp, роуты кинуть на тачки есть возможность?
Можно даже элегантнее — 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.»
«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.»
Влан на юзера? Одна L3 сеть нужной ширины на лупбеке + ip-unnumbered + proxy arp, если хостам надо общаться между собой?
Навроде вот этого www.opennet.ru/base/cisco/catalyst_ip_unnumber.txt.html
Навроде вот этого www.opennet.ru/base/cisco/catalyst_ip_unnumber.txt.html
Не знаю что у вас за индустрия, и на какие промышленные системы вы смотрели, но подобный функционал у нас реализован с помощью ip unnumbered на Cisco.
www.opennet.ru/base/cisco/catalyst_ip_unnumber.txt.html
www.opennet.ru/base/cisco/catalyst_ip_unnumber.txt.html
ну вот этот самый момент как заставить роутер одним маком для всего сетевого сегмента.
а так pvlan практически та самая схема.
ps сам путаюсь с никами, но так уж получилось, я сам забил свой ник на хабре но потом оказалось что инфайт перестал жить :). при следущей регистрации уже нельзя было выбрать ник. в любом случае он не сильно отличался от amario т.е. mario но уже было бы намного просче в различии.
а так pvlan практически та самая схема.
ps сам путаюсь с никами, но так уж получилось, я сам забил свой ник на хабре но потом оказалось что инфайт перестал жить :). при следущей регистрации уже нельзя было выбрать ник. в любом случае он не сильно отличался от amario т.е. mario но уже было бы намного просче в различии.
Блин, статья интересная, но из-за бесконечных «ться» читать невозможно. Я не граммар-нацци, но это реально бесит.
И через trunk порт нельзя нельзя пропустить pvlan. т.е. по сути технология живет на отдельно взятом коммутаторе. Для ознакомления — www.cisco.com/en/US/tech/tk389/tk814/technologies_configuration_example09186a008017acad.shtml#multiple_switch
Sign up to leave a comment.
Немного о private vlan