Автор Тема: Управление на VLAN-ни  (Прочетена 7419 пъти)

mystical

  • Напреднали
  • *****
  • Публикации: 326
  • Distribution: Debian, FreeBSD
  • Window Manager: XFCE
    • Профил
    • WWW
Управление на VLAN-ни
« -: Jul 20, 2013, 23:44 »
Имам Cisco 2950, на който за момента са дигнати няколко VLAN-а:
Цитат
Port      Name            Status         Vlan       Duplex  Speed Type
Fa0/1                        connected    10         a-full  a-100 10/100BaseTX
Fa0/2                        notconnect   11          auto   auto 10/100BaseTX

Gi0/1                        connected    trunk      a-full a-1000 10/100/1000BaseTX

На линукса също са вдигнати съответните VLAN-ни:
Цитат
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP qlen 1000
    link/ether 1c:6f:65:ac:3c:56 brd ff:ff:ff:ff:ff:ff
    inet 10.111.2.1/24 scope global eth0
    inet 10.111.1.1/24 scope global eth0

3: vlan10@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP
    link/ether 1c:6f:65:ac:3c:56 brd ff:ff:ff:ff:ff:ff
4: vlan11@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 1c:6f:65:ac:3c:56 brd ff:ff:ff:ff:ff:ff

eth0 е свързан към Gi0/1 на cisco-то. За момента експериментирам с две мрежи 10.111.1.1/24 и 10.111.2.1/24
Идеята ми е vlan-ните, да не са обвързани с кокретни мрежи. Във всеки VLAN да има IP адреси от различни мрежи (10.111.1.1/24 и 10.111.2.1/24). Защо? Едва ли има интернет доставчик, който се съобразява с VLAN-ните, за да даде съответното IP-пи на клиентите си, от съответния VLAN и порт, ако изобщо знае какви VLAN-ни са дигнати.
Предполага се, че ще има и tc (шейпър):
iptables -t mangle -A FORWARD -s 10.111.1.0/24 -j IPMARK --addr=src --and-mask=0xffff --or-mask=0x10000
iptables -t mangle -A FORWARD -s 10.111.2.0/24 -j IPMARK --addr=src --and-mask=0xffff --or-mask=0x10000
tc qdisc add dev eth1 root handle 1: htb
tc filter add dev eth1 parent 1:0 protocol ip prio 1 fw ...

Въпроса ми е как мога да събера много VLAN-ни на едно място, без да омажа нещата, за да пусна рутиране?
Ако успея с това начинание си мисля и за статични arp таблици.

Пробвах да направя bridge, между двата в-лан-а и нещата се омазаха:
Цитат
04:31:36: %SPANTREE-2-BLOCK_PVID_PEER: Blocking GigabitEthernet0/1 on VLAN0010. Inconsistent peer vlan.                    
04:31:36: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking GigabitEthernet0/1 on VLAN0011. Inconsistent local vlan.
« Последна редакция: Jul 20, 2013, 23:55 от mystical »
Активен

Ако не можеш да градиш, поне не руши!

edmon

  • Гост
Re: Управление на VLAN-ни
« Отговор #1 -: Jul 21, 2013, 00:03 »
Не, че съм го правил но предполагам само, че ако с ДХЦП  раздадеш на съответните влан-и адреси от съответните мрежи и нещата ще се опростят от самосебе си ! :)
Активен

sudo

  • Напреднали
  • *****
  • Публикации: 73
    • Профил
Re: Управление на VLAN-ни
« Отговор #2 -: Jul 21, 2013, 12:22 »
За какво са ви VLAN-и ако няма да се съобразявате с тях??? Има си Default Vlan 1.
Постановката на Линукса също не ви е правилна.
За бриджа пък въобще да не говорим, не знаете за какво е, но го ползвате ...
Това което всъщност ви трябва е inter-vlan routing (router on a stick).
Активен

mystical

  • Напреднали
  • *****
  • Публикации: 326
  • Distribution: Debian, FreeBSD
  • Window Manager: XFCE
    • Профил
    • WWW
Re: Управление на VLAN-ни
« Отговор #3 -: Jul 21, 2013, 13:11 »
Ще се опитам да обесня идеята с два примера:

1
Cisco 2950-24 портов без вдигнати vlan-ни, който е свързан към eth0 на линукс рутер. На eth0 са вдигнати две мрежи 10.111.1.1/24 и 10.111.2.1/24. Всичко работи, но има една голяма LAN мрежа, в която циркулира всичко - Broadcast, arp заявки от всеки до всеки, всичко каквото се сетите и всеки прави каквото си иска. Включително ако на някой му изтече интернета сканира за IP и MAC, сменя си IP-то и MAC-а и продължава да има интернет.
Много грозна картина!
2
Cisco 2950-24 портов с вдигнати vlan-ни, който е свързан към eth0 на линукс рутер. На линукския рутер също са вдигнати две мрежи 10.111.1.1/24 и 10.111.2.1/24.
Идеята е за всеки порт - отделен vlan, който идва до рутера. В рутера vlan-ните да не се смесват, но и да не са обвързани с конкретна мрежа. Всеки vlan да комуникира с един общ интерфейс, но да не може да комуникира с останалите vlan-ни, без да мине през общия интерфейс. По този начи го изброените недостатъци се свеждат до отделен порт - vlan.

inter-vlan routing (router on a stick) не е проблем да се направи, ако всеки vlan се обвърже с конкретна мрежа или част от мрежа. Това е неприемлив вариант.
Активен

Ако не можеш да градиш, поне не руши!

balaban

  • Гост
Re: Управление на VLAN-ни
« Отговор #4 -: Jul 21, 2013, 19:31 »
Add-ваш VLAN-ите на eth0, например eth0.10, eth0.11 и т.н., вкарваш ги в бридж например br0 и после с ebtables (не iptables) даваш политиката по дефаулт на br0 да е DROP за FORWARD! По този начин няма да loop-неш VLAN-ите помежду им, защото ако направиш това ще стане грозна картинка. След това вече на br0 интерфейса си вдигай каквито искаш адреси, така ще бъдат достъпни от всеки VLAN.
Активен

sudo

  • Напреднали
  • *****
  • Публикации: 73
    • Профил
Re: Управление на VLAN-ни
« Отговор #5 -: Jul 21, 2013, 20:16 »
Перфектно !!! и "... Всичко работи, но има една голяма LAN мрежа, в която циркулира всичко - Broadcast, arp заявки от всеки до всеки, всичко каквото се сетите и всеки прави каквото си иска. Включително ако на някой му изтече интернета сканира за IP и MAC, сменя си IP-то и MAC-а и продължава да има интернет..."  Опааа, забравих, ние ще филтрираме по MAC, чудесно докато сме аз, Грую и брат му. А като станат 500 клиента ???
Айде по-сериозно, а?
Активен

balaban

  • Гост
Re: Управление на VLAN-ни
« Отговор #6 -: Jul 21, 2013, 20:53 »
Перфектно !!! и "... Всичко работи, но има една голяма LAN мрежа, в която циркулира всичко - Broadcast, arp заявки от всеки до всеки, всичко каквото се сетите и всеки прави каквото си иска. Включително ако на някой му изтече интернета сканира за IP и MAC, сменя си IP-то и MAC-а и продължава да има интернет..."  Опааа, забравих, ние ще филтрираме по MAC, чудесно докато сме аз, Грую и брат му. А като станат 500 клиента ???
Айде по-сериозно, а?

А ти да си видял някъде да съм писал че това е най-интелигентното решение? Човека има конкретен въпрос и му давам конкретен отговор. Айде сега ако можеш обясни как по-точно ще мине Layer2 трафика през въпросния bridge със зададена DROP политика?
Активен

sudo

  • Напреднали
  • *****
  • Публикации: 73
    • Профил
Re: Управление на VLAN-ни
« Отговор #7 -: Jul 21, 2013, 21:53 »
Айде сега ако можеш обясни как по-точно ще мине Layer2 трафика през въпросния bridge със зададена DROP политика?

Още по-чудесно: сходни arp-ове, сходни broadcast-и само че този път в два сегмента. Проблеми ^2 :)
Активен

balaban

  • Гост
Re: Управление на VLAN-ни
« Отговор #8 -: Jul 21, 2013, 22:11 »
Айде сега ако можеш обясни как по-точно ще мине Layer2 трафика през въпросния bridge със зададена DROP политика?

Още по-чудесно: сходни arp-ове, сходни broadcast-и само че този път в два сегмента. Проблеми ^2 :)

Първо се изказваш неподготвен, второ не ми отговори на въпроса, и трето какво разбираш под "сходни"?
Активен

sudo

  • Напреднали
  • *****
  • Публикации: 73
    • Профил
Re: Управление на VLAN-ни
« Отговор #9 -: Jul 21, 2013, 23:45 »
... второ не ми отговори на въпроса, и трето какво разбираш под "сходни"?

Когато срежеш на две една тръба пълна с боклуци ...  имаш вече ДВЕ тръби пълни с боклуци.

Айде стига толкова вече, че ми се спи.

MOD: Момчета, няма ли да е по-добре да обсъдите каквото имате на лично, вместо да спамите темата. Коментара се отнася и за двама ви. Защо трябва да се закачате публично, след като за всички ще е по-добре да се разберете с ЛС и темата да съдържа само полезна информация. Толкова ли е трудно? Благодаря за разбирането.

МОД веднага те послушвам и пълня темата със знания. Въпрос към знаещите: Какво ще стане ако взема аз като клиент на VLAN 11 да си сложа съществуващо IP от VLAN 10 и напукам една злобна ARP с destination FF:FF:FF:FF:FF:FF ???

Легнах си вече (човече спи)
« Последна редакция: Jul 22, 2013, 00:35 от sudo »
Активен

netgraph

  • Напреднали
  • *****
  • Публикации: 34
  • Distribution: *BSD, Fedora, RHEL
  • Window Manager: Fluxbox, Mate
    • Профил
Re: Управление на VLAN-ни
« Отговор #10 -: Jul 22, 2013, 02:58 »
Ще се опитам да обесня идеята с два примера:

1
Cisco 2950-24 портов без вдигнати vlan-ни, който е свързан към eth0 на линукс рутер. На eth0 са вдигнати две мрежи 10.111.1.1/24 и 10.111.2.1/24. Всичко работи, но има една голяма LAN мрежа, в която циркулира всичко - Broadcast, arp заявки от всеки до всеки, всичко каквото се сетите и всеки прави каквото си иска. Включително ако на някой му изтече интернета сканира за IP и MAC, сменя си IP-то и MAC-а и продължава да има интернет.
Много грозна картина!
2
Cisco 2950-24 портов с вдигнати vlan-ни, който е свързан към eth0 на линукс рутер. На линукския рутер също са вдигнати две мрежи 10.111.1.1/24 и 10.111.2.1/24.
Идеята е за всеки порт - отделен vlan, който идва до рутера. В рутера vlan-ните да не се смесват, но и да не са обвързани с конкретна мрежа. Всеки vlan да комуникира с един общ интерфейс, но да не може да комуникира с останалите vlan-ни, без да мине през общия интерфейс. По този начи го изброените недостатъци се свеждат до отделен порт - vlan.

inter-vlan routing (router on a stick) не е проблем да се направи, ако всеки vlan се обвърже с конкретна мрежа или част от мрежа. Това е неприемлив вариант.
Здравей,
Едно от решенията на проблема ти се нарича proxy arp. Има много документация за това из интернет, няма да пресъздавам обяснения на български тук.
На кратко идеята:
Вдига се IP адрес X на N интерфейси (примерно в/у VLAN интерфейсите, които ти разделят мрежата) и се пуска proxy arp на същите интерфейси. След това
чрез добавяне на статични пътища до използваните адреси по интерфейсите се постига свързаност м/у рутера и клиентите. Идеята на proxy arp е, че ако клиент
от сегмент 1 търси клиент от сегмент 2, който е в същия subnet, то рутера ще се представи за търсения клиент (чрез ARP отговор) пред търсещия от сегмент 1 и ще започне
да получава пакетите за него и да ги рутира към него в сегмент 2 (естествено ip_forwarding трябва да е пуснат). По този начин дори можеш да ограничиш скоростта м/у клиенти от един и същи IP subnet, които са в различни сегменти (VLAN-и).

Ще ти дам една примерна конфигурация, която изпълнява това, което се опитваш да постигнеш ако съм те разбрал правилно.
Можеш много лесно да постигнеш конфигурацията по точка 2.
Ето един пример с мрежа 10.246.243.0/24 и VLAN 20 и 30:
Рутер:
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/conf/eth0.20/proxy_arp
echo 1 > /proc/sys/net/ipv4/conf/eth0.30/proxy_arp

# Вдигаме адреса на рутера и на двата VLAN-а
ip addr add 10.246.243.1/32 dev eth0.20
ip addr add 10.246.243.1/32 dev eth0.30

# Добавяме пътища до два клиента - единия във VLAN 20 (.2), другия в 30 (.3)
ip route add 10.246.243.2/32 dev eth0.20 src 10.246.243.1
ip route add 10.246.243.3/32 dev eth0.30 src 10.246.243.1

След това можеш да пробваш от 10.246.243.2 зад VLAN 20 да достигнеш 10.246.243.3
във VLAN 30 и в ARP таблицата на клиентите ще забележиш, че .2 вижда .3 с MAC адрес рутера и същото
за .3 към .2. Това е добре да го комбинираш със статичнa  ARP таблица.
За scale-ване, в момента в мрежа с 15000 клиента и ~ 2000 VLAN-a, подобна схема работи перфектно като в един
broadcast domain има не повече от 10 човека.
Не си защитен с/у крадене на интернет в отделните сегменти, но обикновено лесно се хваща крадеца ако е проблем.
Ако в един сегмент някой си сложи адрес на клиент от друг сегмент, то той няма да постигне нищо, единствения проблем
ще е, че хората от засегнатия сегмент няма да виждат въпросния адрес (тъй като вероятно крадеца ще отговаря с ARP отговори първи), което пак е доста лесно да се провери.
Надявам се това да ти помогне  [_]3

Поздрави
« Последна редакция: Jul 22, 2013, 03:08 от GytOS »
Активен

__asm__("jmp .");

balaban

  • Гост
Re: Управление на VLAN-ни
« Отговор #11 -: Jul 22, 2013, 07:59 »
Цитат
Когато срежеш на две една тръба пълна с боклуци ...  имаш вече ДВЕ тръби пълни с боклуци.

Ти си един страхотен млад човек, но пишеш доста странни и несвързани неща. Ти тези "две тръби" (VLAN 10,11) така или иначе вече ги имаш. Какво значи в случая една тръба да я срежеш на две? Как ще разрешеш нещо на две което вече си е на две?

Цитат
Въпрос към знаещите: Какво ще стане ако взема аз като клиент на VLAN 11 да си сложа съществуващо IP от VLAN 10 и напукам една злобна ARP с destination FF:FF:FF:FF:FF:FF ???

Пак не се разбира какво имаш предвид. В случая с бриджа всички клиенти са в един или повече subnet-и, което означава че клиент от VLAN10 може да има адрес 192.168.1.22, а клиент от VLAN11 адрес 192.168.1.252. Какъв е смисъла от това което пишеш? Правиш ли разлика между Layer2 и Layer3 трафик?

Ако mystical е наясно с Cisco IOS там мможе да направи допълнителни настройки за по-голяма сигурност.
« Последна редакция: Jul 22, 2013, 08:03 от balaban »
Активен

sudo

  • Напреднали
  • *****
  • Публикации: 73
    • Профил
Re: Управление на VLAN-ни
« Отговор #12 -: Jul 22, 2013, 11:41 »
Такааа, ето доста изход + конфигурации щото ми писна от въпроси "това разбираш ли?" "онова разбираш ли?" "отговори ми на въпроса..."

1. рутер ОС Линукс Ubuntu 13.04
root@ubuntu:~# ifconfig
br1       Link encap:Ethernet  HWaddr 00:23:54:9c:69:89 
          inet addr:10.240.12.6  Bcast:0.0.0.0  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4074 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1110 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:218930 (218.9 KB)  TX bytes:93157 (93.1 KB)

eth6      Link encap:Ethernet  HWaddr 00:23:54:9c:69:89 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5626 errors:0 dropped:31 overruns:0 frame:0
          TX packets:2461 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:986405 (986.4 KB)  TX bytes:365796 (365.7 KB)

eth6.1010 Link encap:Ethernet  HWaddr 00:23:54:9c:69:89 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1345 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1636 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:390407 (390.4 KB)  TX bytes:150117 (150.1 KB)

eth6.1030 Link encap:Ethernet  HWaddr 00:23:54:9c:69:89 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3471 errors:0 dropped:0 overruns:0 frame:0
          TX packets:409 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:200086 (200.0 KB)  TX bytes:111951 (111.9 KB)

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1194 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1194 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:117512 (117.5 KB)  TX bytes:117512 (117.5 KB)

root@ubuntu:~# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: DROP

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
root@ubuntu:~# arping -I br1 -b 10.240.12.2
ARPING 10.240.12.2 from 10.240.12.6 br1
Unicast reply from 10.240.12.2 [18:03:73:6F:4B:F1]  0.769ms
Unicast reply from 10.240.12.2 [00:E0:18:55:4B:FC]  1.785ms
Unicast reply from 10.240.12.2 [00:E0:18:55:4B:FC]  0.671ms
Unicast reply from 10.240.12.2 [18:03:73:6F:4B:F1]  0.704ms
Unicast reply from 10.240.12.2 [18:03:73:6F:4B:F1]  0.756ms
Unicast reply from 10.240.12.2 [00:E0:18:55:4B:FC]  1.733ms
Unicast reply from 10.240.12.2 [18:03:73:6F:4B:F1]  0.737ms
Unicast reply from 10.240.12.2 [00:E0:18:55:4B:FC]  1.720ms
Unicast reply from 10.240.12.2 [00:E0:18:55:4B:FC]  0.657ms
Unicast reply from 10.240.12.2 [18:03:73:6F:4B:F1]  0.740ms
Unicast reply from 10.240.12.2 [18:03:73:6F:4B:F1]  0.749ms
Unicast reply from 10.240.12.2 [00:E0:18:55:4B:FC]  1.730ms
Unicast reply from 10.240.12.2 [00:E0:18:55:4B:FC]  0.666ms
Unicast reply from 10.240.12.2 [18:03:73:6F:4B:F1]  0.697ms
Unicast reply from 10.240.12.2 [00:E0:18:55:4B:FC]  0.668ms
Unicast reply from 10.240.12.2 [18:03:73:6F:4B:F1]  0.749ms
^CSent 8 probes (8 broadcast(s))
Received 16 response(s)
root@ubuntu:~# ssh 10.240.12.2
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
e8:73:5a:3e:36:db:a2:67:0e:06:5c:c2:4b:6c:a1:9c.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending RSA key in /root/.ssh/known_hosts:11
  remove with: ssh-keygen -f "/root/.ssh/known_hosts" -R 10.240.12.2
RSA host key for 10.240.12.2 has changed and you have requested strict checking.
Host key verification failed.
root@ubuntu:~#

Двата хоста с IP 10.240.12.2 са Убунту и Дебиан съответно във VLAN1010 u VLAN1030. Горните резултати са постигнати единствено и само с програмно осигуряване инсталирано от официалните хранилища на Дебиан и Убунту. Всичко това колега показва че онова което сте написали работи, само че е ГРОЗНО и не решава проблема с краденето на Интернет, а и както е видно и много други проблеми създава.

ПП Не ми пишете на ЛС къде греша :)
Активен

mystical

  • Напреднали
  • *****
  • Публикации: 326
  • Distribution: Debian, FreeBSD
  • Window Manager: XFCE
    • Профил
    • WWW
Re: Управление на VLAN-ни
« Отговор #13 -: Jul 22, 2013, 23:08 »
Благодаря на всички, които взеха участие за решаване на проблема! Специални благодарности на GytOS!

Като се има в предвит и че някой друг може да се сблъска с подобен проблем, ще опиша под формата на copy-paste, реализацията на задачата от първия ми пост. Като следвам идеята на GytOS.

Основни настройки на Cisco 2950:

en

conf t
interface FastEthernet0/1
 switchport access vlan 10
 switchport mode access
 switchport block unicast
 switchport port-security maximum 16
 switchport port-security
 switchport port-security aging time 240
 switchport port-security violation restrict
 switchport port-security aging type inactivity
 no cdp enable
 spanning-tree bpduguard enable
 ip dhcp snooping limit rate 50
end      

conf t
interface FastEthernet0/2
 switchport access vlan 11
 switchport mode access
 switchport block unicast
 switchport port-security maximum 16
 switchport port-security
 switchport port-security aging time 240
 switchport port-security violation restrict
 switchport port-security aging type inactivity
 no cdp enable
 spanning-tree bpduguard enable
 ip dhcp snooping limit rate 50
end  

conf t
interface GigabitEthernet0/1
 switchport trunk native vlan 2                                                                             
 switchport trunk allowed vlan 10-33                                                                        
 switchport mode trunk                                                                                      
 switchport nonegotiate
end

show interfaces g0/1 trunk

copy running-config startup-config

Линукс:

apt-get update
apt-get install vlan

echo 1 > /proc/sys/net/ipv4/ip_forward

ip link add link eth0 name vlan10 type vlan id 10
ip link set dev vlan10 up
ip address add 10.111.1.1/32 dev vlan10
ip address add 10.111.2.1/32 dev vlan10
echo 1 > /proc/sys/net/ipv4/conf/vlan10/proxy_arp

ip link add link eth0 name vlan11 type vlan id 11
ip link set dev vlan11 up
ip address add 10.111.1.1/32 dev vlan11
ip address add 10.111.2.1/32 dev vlan11
echo 1 > /proc/sys/net/ipv4/conf/vlan11/proxy_arp


ip route add 10.111.2.2/32 dev vlan10 src 10.111.2.1

root@debian:/home/mystical# ping 10.111.2.2
PING 10.111.2.2 (10.111.2.2) 56(84) bytes of data.
64 bytes from 10.111.2.2: icmp_req=1 ttl=64 time=0.148 ms
64 bytes from 10.111.2.2: icmp_req=2 ttl=64 time=0.154 ms
64 bytes from 10.111.2.2: icmp_req=3 ttl=64 time=0.142 ms
64 bytes from 10.111.2.2: icmp_req=4 ttl=64 time=0.145 ms
^C
--- 10.111.2.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.142/0.147/0.154/0.009 ms

ip route add 10.111.2.3/32 dev vlan11 src 10.111.2.1

root@debian:/home/mystical# ping 10.111.2.3
PING 10.111.2.3 (10.111.2.3) 56(84) bytes of data.
64 bytes from 10.111.2.3: icmp_req=1 ttl=128 time=0.162 ms
64 bytes from 10.111.2.3: icmp_req=2 ttl=128 time=0.156 ms
64 bytes from 10.111.2.3: icmp_req=3 ttl=128 time=0.161 ms
64 bytes from 10.111.2.3: icmp_req=4 ttl=128 time=0.156 ms
^C
--- 10.111.2.3 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2998ms
rtt min/avg/max/mdev = 0.156/0.158/0.162/0.015 ms

tc
eth1 - интерфей свързан към интернет
eth0 - интерфей свързан към вътрешната мрежа

iptables -t mangle -A FORWARD -d 10.111.2.0/24 -j IPMARK --addr=dst --and-mask=0xffff --or-mask=0x10000
iptables -t mangle -A FORWARD -s 10.111.2.0/24 -j IPMARK --addr=src --and-mask=0xffff --or-mask=0x10000

tc qdisc add dev vlan11 root handle 1: htb
tc filter add dev vlan11 parent 1:0 protocol ip prio 1 fw

#Отнася се за IP 10.111.2.3 Download
tc class add dev vlan11 parent 1: classid 1:0203 htb rate 4Mbit

tc qdisc add dev eth1 root handle 1: htb
tc filter add dev eth1 parent 1:0 protocol ip prio 1 fw

#Отнася се за IP 10.111.2.3 Upload
tc class add dev eth1 parent 1: classid 1:0203 htb rate 4Mbit

Никога не съм реализирал нещо подобно и малко се притеснявам, дали ще има допълнителен товар върху машината от индивидуалното маршрутизиране за всяко IP.
Повече се притеснява, че за всеки vlan интерфейс трябва да се вдигне tc qdisc и tc filter за да се ограничи скороста за сваляне. Има ли допълнителен товар от това нещо и евентуално колко?
Активен

Ако не можеш да градиш, поне не руши!

netgraph

  • Напреднали
  • *****
  • Публикации: 34
  • Distribution: *BSD, Fedora, RHEL
  • Window Manager: Fluxbox, Mate
    • Профил
Re: Управление на VLAN-ни
« Отговор #14 -: Jul 23, 2013, 03:35 »
<snip>
Никога не съм реализирал нещо подобно и малко се притеснявам, дали ще има допълнителен товар върху машината от индивидуалното маршрутизиране за всяко IP.
Повече се притеснява, че за всеки vlan интерфейс трябва да се вдигне tc qdisc и tc filter за да се ограничи скороста за сваляне. Има ли допълнителен товар от това нещо и евентуално колко?
Здравей отново,
Радвам се, че си успял да си решиш проблема и си споделил подробно как за останалите. Относно въпросите ти - да, има допълнително натоварване разбира се.
Рутирането на индивидуални адреси няма да ти е проблем, а ограниченията и правилата ще ти натоварят най - много машината. Всичко е относително и зависи от
конфигурацията на филтрите, правилата, мрежовите настройки и естествено способностите на хардуера. Вероятно си стигнал до http://lartc.org/howto/ -
това е един от най - изчерпателните ресурси за Линукс по тези теми  :)
Наблюдавай си натоварването както и броячите за различни грешки, закъснения на пакети в час пик и т.н.


Активен

__asm__("jmp .");

Подобни теми
Заглавие Започната от Отговора Прегледи Последна публикация
VLAN
Настройка на програми
laskov 5 4054 Последна публикация Mar 11, 2006, 11:56
от july
Vlan, trunk и untagged vlan
Настройка на хардуер
Explisit 2 4621 Последна публикация Feb 12, 2008, 02:37
от Explisit
vlan
Хардуерни и софтуерни проблеми
flipz 1 3698 Последна публикация Jul 08, 2009, 10:08
от wfw
Въпрос за vlan
Идеи и мнения
buserg 23 7714 Последна публикация Apr 07, 2012, 09:53
от kissow
Конфигуриране на Asterisk със Мтел VLan
Настройка на програми
modo86 20 12356 Последна публикация Nov 02, 2016, 23:15
от embak