Jump to content

Автоматичен филтър на vlans вдигнати върху bridge интерфейс


Recommended Posts

Пача се намира на следния линк: https://patchwork.ozlabs.org/patch/388795/

 

Някой да е пробвал нещо подобно?

Какви точно филтри ще има между vlans и дали ще работи стабилно?

 

Целта ми е да дигна IP върху bridge интерфейса и това IP да се използва от клиентите, които са пръснати по vlans като гейт по-подразбиране. По този начин се надявам да спестя системни ресурси (машината да се товари по-малко).

 

Установих, че пача се прилага за ядро:

 

 

~/linux/linux-3.16.7-ckt7$ patch -p1 < 3-3-bridge-Automatically-filter-vlans-configured-on-top-of-bridge.patch
patching file net/bridge/br_device.c
Hunk #1 succeeded at 302 (offset -5 lines).
Hunk #2 succeeded at 371 (offset -5 lines).
Hunk #3 succeeded at 402 (offset -5 lines).
patching file net/bridge/br_private.h
Hunk #2 succeeded at 662 (offset -2 lines).
Hunk #3 succeeded at 766 (offset -8 lines).

 

В по-долни версии на linux дава грешка.

 

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

Адрес на коментара
Сподели в други сайтове

  • Администратор

От влани едва ли ще ти се товари машината,по скоро от правилата !

Зашо не ползваш суича за целта ?

Use since

OpenBSD 3.x

FreeBSD 4.x

Centos 5.x Debian 3.x Ubuntu 7.x

Аз съм фен на OpenWRT.

 

Горчивината от лошото качество остава дълго след като е преминало удоволствието от ниската цена.

_____________________________

___|____|____|____|____|____|__

_|____|____|____|____|____|____

___|____|_ Удряй _|____|____|__

_|____|___ главата ___|____|____

___|____|_ си тук!! |____|____|__

_|____|____|____|____|____|____

___|____|____|____|____|____|__

Адрес на коментара
Сподели в други сайтове

 

Целта ми е да дигна IP върху bridge интерфейса и това IP да се използва от клиентите, които са пръснати по vlans като гейт по-подразбиране. По този начин се надявам да спестя системни ресурси (машината да се товари по-малко).

 

 

Това можеш да го направиш без допълнителни пачове.

Ако е лесно, не е интересно :)

Адрес на коментара
Сподели в други сайтове

  • Администратор

Може питащия да е любител на кърнел 2,4

но там и вуду магии ще трябват.

Харесай поста ^^^
acer.gif htc.gifsigpic4024_2.gif

Форумът е за взаимопомощ а не за свършване на чужда работа


ɹɐǝɥ uɐɔ noʎ ǝɹoɯ ǝɥʇ 'ǝɯoɔǝq noʎ ɹǝʇǝınb ǝɥʇ

Адрес на коментара
Сподели в други сайтове

Това можеш да го направиш без допълнителни пачове.

 

Доста се обезмисля идеята от прозрачни vlan-ни (поне тази, за която масово се използват от българските интернет доставчици - сегментиране на мрежата). Трябва да има минимален филтър между тях. ebtables като решение не ми се струва много удачно.

Адрес на коментара
Сподели в други сайтове

  • Администратор

На теб ти трябва между портовете да не се виждат ли?

Харесай поста ^^^
acer.gif htc.gifsigpic4024_2.gif

Форумът е за взаимопомощ а не за свършване на чужда работа


ɹɐǝɥ uɐɔ noʎ ǝɹoɯ ǝɥʇ 'ǝɯoɔǝq noʎ ɹǝʇǝınb ǝɥʇ

Адрес на коментара
Сподели в други сайтове

Да.

Сегментиране на мрежата, всеки порт на суича да е в отделен vlan, през trun порт да идват директно гейта. До тука няма проблеми, но когато дойдат в гейта трябва за всяка мрежа да се дига по едно ИП на всеки vlan, за да се използва от клиентите. Ако са вдигнати върху bridge интерфейс и има минимален филтър между vlan-ните, тогава ще има ИП само на bridge интерфейса, което ще се вижда от клиентите от всички vlan-ни, но в същото време ще има и сегментиране на мрежата.

Незнам какви филтри ще създаде този пач между vlan-ните и как ще се държат. Не искам да използвам ebtables, по разбираеми причини (ще се пишат много, много правила, киоте ще гълтат много, много ресурси).

Адрес на коментара
Сподели в други сайтове

от 5 години ползвам точно такова сегментиране. какви са тези драми с филтри и прочие?

Клиента се заключва във влан-а си и това е. вижда себе си и гейта и нищо друго. всякаква

комуникация с друг клиент в мрежата става през сървъра. пон, лан или вирелесс все си е

така така и работи.

Адрес на коментара
Сподели в други сайтове

L2 комутатор с port isolation няма ли да ти е по-удобен?

Пример всички users са ти във vlan 2, vlan 1 ти е за към гейта - там си го разтагваш (след комутатора пак ще виждат един гейт).

Редактирано от Networker

“...ние, можещите водени от незнаещите, вършим невъзможното за кефа на неблагодарните. И сме направили толкова много, с толкова малко, за толкова дълго време, че сме се квалифицирали да правим всичко от нищо...”, Константин Йозеф Иречек, 13.12.1881 г.

Адрес на коментара
Сподели в други сайтове

и като си премести клиента компютъра от вход А ет. 4 във вход Б ет. 6 как

ще разбереш каде е? Или на лан идеологията.. важното е да работи ;)

Адрес на коментара
Сподели в други сайтове

Доста се обезмисля идеята от прозрачни vlan-ни (поне тази, за която масово се използват от българските интернет доставчици - сегментиране на мрежата). Трябва да има минимален филтър между тях. ebtables като решение не ми се струва много удачно.

 

 

А какъв е смисъла на междинния филтър? Искаш клиентите да не се виждат по между си?

Ако е лесно, не е интересно :)

Адрес на коментара
Сподели в други сайтове

Ако само иска да не му се виждат клиентите, няма значение на кой порт на switch-а ще е (те всички са с еднакъв таг към users) стига да има isolation.
Ако има нужда да знае кой се е местил, да, при него по-скоро, до колкото разбирам трябва да са много VLAN-и на един порт (интерфейс).

“...ние, можещите водени от незнаещите, вършим невъзможното за кефа на неблагодарните. И сме направили толкова много, с толкова малко, за толкова дълго време, че сме се квалифицирали да правим всичко от нищо...”, Константин Йозеф Иречек, 13.12.1881 г.

Адрес на коментара
Сподели в други сайтове

от 5 години ползвам точно такова сегментиране. какви са тези драми с филтри и прочие?

 

Как го правиш това сегментиране, през bridge интерфейс с untagged vlans или с по един IP адрес за всяка мрежа на всеки vlan?

 

Направих някои тестове:

insmod /lib/modules/`uname -r`/kernel/net/802/stp.ko

insmod /lib/modules/`uname -r`/kernel/net/802/garp.ko

insmod /lib/modules/`uname -r`/kernel/net/bridge/bridge.ko

insmod /lib/modules/`uname -r`/kernel/net/8021q/8021q.ko

echo 1 > /proc/sys/net/bridge/bridge-nf-filter-vlan-tagged

echo 1 > /proc/sys/net/bridge/bridge-nf-filter-pppoe-tagged

 

brctl addbr br0

brctl addif br0 eth0

ip link set dev br0 up

ip link set dev eth0 up

ip address add 192.168.2.1/24 dev br0

 

vconfig add br0 11

ip link set dev br0.11 up

echo 1 > /proc/sys/net/ipv4/conf/br0.11/proxy_arp

 

Няма проблеми да се untag-ват vlan-ни върху bridge интерфейс, не се залупват.

Но това не ми върши никаква работа, понеже br0 не разпознава untag-натия трафик от интерфейс br0.11

 

Пример:

на br0.11 имам хост с IP: 192.168.2.11

когато добавя IP: 192.168.2.1/24 на br0 не вижда 192.168.2.11, понеже не разпознава untag-натия трафик от br0.11

ако добавя 192.168.2.1/24 на br0.11 няма проблеми

 

Целта е да няма IP на всеки vlan.

 

Тук се опитват да направят нещо подобно, но по различен начин http://permalink.gmane.org/gmane.linux.network/311944, може би това е идеята на горния пач.

Редактирано от mysticall
Адрес на коментара
Сподели в други сайтове

Ти по този начин не бриджваш VLAN-ите, а вдигаш VLAN-и на бридж интерфейса.. 

 

vconfig add eth0 11

ip link set dev eth0.11 up

vconfig add eth0 12

ip link set dev eth0.12 up

brctl addif br0 eth0.11 eth0.12

ip add a 192.168.2.1/24 dev br0

 

Създавам прозрачни VLAN-и и се обезмисля идеята на VLAN-ите.

 

Трябва да има и друго решение на проблема.

Редактирано от mysticall
Адрес на коментара
Сподели в други сайтове

Създайте нов акаунт или се впишете, за да коментирате

За да коментирате, трябва да имате регистрация

Създайте акаунт

Присъединете се към нашата общност. Регистрацията става бързо!

Регистрация на нов акаунт

Вход

Имате акаунт? Впишете се оттук.

Вписване
  • Потребители разглеждащи страницата   0 потребители

    • No registered users viewing this page.
×
×
  • Създай нов...

Important Information

By using this site, you agree to our Terms of Use.