Linux-Bulgaria.ORG
навигация

 

начало

пощенски списък

архив на групата

семинари ...

документи

как да ...

 

 

Предишно писмо Следващо писмо Предишно по тема Следващо по тема По Дата По тема (thread)

Re: [Lug-bg] Mind-boggling: dynamic multipoint vpn под Линукс.


  • Subject: Re: [Lug-bg] Mind-boggling: dynamic multipoint vpn под Линукс.
  • From: Nikolaj <lorddoskias@xxxxxxxxx>
  • Date: Mon, 30 Jul 2007 19:00:22 +0300

Anton Glinkov wrote:
> Колко товари една openvpn сесия, която е само отворена и не се ползва 
> според теб? full-mesh и СТП-то се прави, за да се постигне, това което 
> се търси - ако някой линк и/или точка умре - автоматично да се прерутира 
> Layer 2 свързъността, според настройките (cost priority). Човекът е 
> писал - иска мултипойнт VPN решение под линукс. Ти говориш за 
> маршрутизатори и техните протоколи, а аз говоря за най-обикновен линукс 
> :). А ако се чудиш какво става с arp заявката и изцяло с ethernet 
> broadcast-ите - зависи изцяло от това дали иска Layer-2 или Layer-3 
> свързаност м/у точките. Ако си запознат със СТП протокола, ще знаеш, че 
> всички портове, които не се ползват (т.е имат детектнат loop), се 
> блокират изцяло и през тях минават само 802.1d пакети. Не виждам какво 
> общо имат arp-заявките тук. Ако реши може да си бриджне и вътрешни мрежи 
> в този 'общ бридж' и всичко пак ще си работи абсолютно без проблеми. Ако 
> човекът има нужда от помощ - да ми драсне едно писмо - ще помогна с 
> каквото мога. Не ми се спори повече. Приятна вечер.
> 
> Danail Petrov wrote:
>> Здрасти,
>>
>> Anton Glinkov wrote:
>>> Danail Petrov wrote:
>>>  
>>>> Anton Glinkov wrote:
>>>>    
>>>>> openvpn - всяка точка с всяка друга + spanning tree. Играчка ще е за 
>>>>> изграждане, но не е нещо сложно.
>>>>>         
>>>> Нещо не схванах, какво общо има Layer3 VPN-а с layer2 протокол за 
>>>> loop detection/prevention spanning tree?
>>>>     
>>> Вдига bridge интерфейс и се настройват по 7 openvpn Layer 2 тунела 
>>> (tap) до останалите. Всички тези 'тапи' се вкарват в bridge-а. Това се 
>>> прави и на 8те сървъра. Настройва се spanning tree на всяка машина 
>>> (приоритети, pathcost и от сорта). Вдигат се IP-та на br0 интерфейсите 
>>> (10.0.0.1, 2, 3... примерно), който благодарение на spanning tree-то 
>>> винаги имат видимост помежду си ако някоя точка падне. И вече в 
>>> зависимост от това каква свързаност се иска м/у точките се настройва 
>>> рутиране или допълнителен Layer 2 bridging.
>>>
>>> Ако пак не си схванал.. не мога да го обясня по-добре.. sorry :)
>>>
>>>   
>> тоест тук говорим за някакво супер нерентабилно и ненужно товарене на 
>> машината (помисли колко ISAKMP сесий трябва да имаш между всички машини 
>> [2^8-2], и ако пуснеш layer2-то в тези сесий то какво ще се случва при 
>> всеки нов arp request в мрежата?) Не разбирам кому е нужно да се прави 
>> full mesh топология, и защо им трябва на маршрутизаторите да разбират от 
>> STP? Нали затова са маршрутизатори, и хората са им измислили 
>> маршрутизиращи протоколи? Какво ще правиш с това STP в тази ситуация, 
>> къде по-точно ще бъде полезно то? И какво значи че "като bridge-неш два 
>> лан сегмента през wan-а, то те щели да се виждат благодарение на STP?"
>>
>> Николай, бъди по-конкретен с условията и нещата които си намислил. Кажи 
>> с какво разполагаш и каква е крайната цел вместо всички тук да умуваме 
>> за това :)
> 

Гледам, че се е заформила дискусия по въпроса, за което се радвам. Ами в 
интерес на истината нямам конкретно задание, но просто един човек ми 
постави подобен въпрос. Най-близкото инфо до това което каза той беше на 
  цицко някаква ала-баница: Има 1 хъб, на който върви NHRP сървър, и 
всеки spoke се регва като клиент на NHRP сървъра, и когато машина зад 
някой от  spoke-овете иска да достъпи ресурс до, намиращ се зад някой 
друг spoke, се праща запитване към NHRP сървъра, той отговоря  и така се 
изгражда spoke-spoke тунел. Но и в този вариант ако ти падне NHRP 
сървъра пак увисва цялата работа.
_______________________________________________
Lug-bg mailing list
Lug-bg@xxxxxxxxxxxxxxxxxx
http://linux-bulgaria.org/mailman/listinfo/lug-bg



 

наши приятели

 

линукс за българи
http://linux-bg.org

FSA-BG
http://fsa-bg.org

OpenFest
http://openfest.org

FreeBSD BG
http://bg-freebsd.org

KDE-BG
http://kde.fsa-bg.org/

Gnome-BG
http://gnome.cult.bg/

проект OpenFMI
http://openfmi.net

NetField Forum
http://netField.ludost.net/forum/

 

 

Linux-Bulgaria.ORG

Mailing list messages are © Copyright their authors.