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

[Tsvetin.Vasilev@xxxxxxxxx]

Може би иска всичките
отдалечени точки да са в един мрежови сегмент?
(поради някаква причина, не обсъждаме каква:)
)
Поздрави
Цветин

Danail Petrov <danail.petrov@xxxxxxxxxxx>
Sent by: lug-bg-bounces@xxxxxxxxxxxxxxxxxx

31.07.2007 02:35

Please respond to
Linux Users Group - Bulgaria <lug-bg@xxxxxxxxxxxxxxxxxx>

To	Linux Users Group - Bulgaria <lug-bg@xxxxxxxxxxxxxxxxxx>
cc
Subject	Re: [Lug-bg] Mind-boggling: dynamic multipoint vpn под Линукс.

Добре де, аз нещо не разбирам.
Кой ще бъде root bridge-a, и как си 
представяш цялата тази мрежа изградена
логически ? Имаме 7 
рутера....защо трябва да ползваме ethernet технология
измислена за loop 
prevention, след като хората са измислили маршрутизиращи
протоколи? (да 
не следиш Blog-a на Делиян? :))))

Немога да проумея необходимоста от STP ...

Поздрави!

Anton Glinkov wrote:
> Danail Petrov wrote:
>   
>> Здрасти,
>> ти как реши че на човека му трябва
layer2 свързаност?
>>     
> никъде не съм го рещил. Казах, че при
този сценарий е плюс и 
> _ако_му_е_нужна_, може да я използва.
> Как по-просто да обясня, че нещото, което
предлагам е да се създаде 
> full-mesh система от ethernet тунели, която ще
се контролира от STP. Т.е 
> има един общ ethernet сегмент, в който се
намират всичките му линукс 
> машини. Свързъността м/у тях е гарантирана
от fullmesh-a и STP-то. Т.е 
> по всяко едно време (ако изключим пълно
умиране на дадена точка, тогава 
> само тя изчезва) те се виждат. Като иска
Layer 3, просто ще си добави по 
> 7 статични routes (не мисля, че има нужда
от динамични протоколи освен 
> ако няма ) на всяка една от 8те машини
и проблемът му с рутирането (ако 
> изобщо може да се нарече проблем) е решен.
>   
>> Anton Glinkov wrote:
>>     
>>> Колко товари една openvpn сесия, която
е само отворена и не се ползва 
>>> според теб?
>>>       
>> Какво значи да е отворена и да не се
ползва? Я си представи един вирус в 
>> локалната мрежа, който плюе яко към
ff:ff:ff:ff:ff:ff или по-лошият 
>> вариянт, ако тунелният ти интерфейс
работи като Proxy-arp? А сега си 
>> представи всичкият този трафик кодиран
в ESP пакети (и ако кажем се 
>> ползва aes/3des + sha) целия този трафик
ще се процесва софтуерно от 
>> CPU-то на машината, и ще даде 100% load (и
това е само един от няколкото 
>> проблеми за които се сещам)
>>     
> 'отворена и да не се ползва' означава,
тунелът да е изграден и работещ, 
> но по него да минават само bridge-STP-related
ethernet фреймове. Ако 
> реши да настрои звезда - всяка машина
ще има по един работещ и по 6 
> 'спящи' тунела готови да 'потекат' в момента
в който стане нещо с 
> работещия, а центърът на звездата - 7
работещи. Другият вариант е да се 
> изравни натоварването и всяка точка
да има по 2 работещи и 5 'спящи', но 
> тогава ще има безсмислено завъртане
на трафик. При настройка на bridge 
> priority, port priority и path cost, лесно можеш да си
играеш и разменяш 
> топологиите on-the-fly, и да намериш  най-удачната
за случая, без да се 
> притесняваш, че системата ще рухне (освен
ако не задаваш неразумни 
> стойности на горните 2, разбира се :))
> За броадкастите и Layer 2 - виж по-горе. А
proxy_arp се спира лесно :)
>   
>>>  full-mesh и СТП-то се прави, за да
се постигне, това което се търси - 
>>> ако някой линк и/или точка умре -
автоматично да се прерутира
>>>       
>> "рутирането" и STP-то са две съвсем
различни неща. Това което говориш за 
>> прерутирането се извършва чрез рутиращи
протоколи (BGP,OSPF,ISIS,RIP), 
>> или иначе казано, когато говорим за
routing говорим за layer3. А там, 
>> STP _няма_ :)
>>     
> пропуснал съм кавичките на 'прерутира'
- моя грешка :)
>   
>>>  
>>> Layer 2 свързъността, според настройките
(cost priority). Човекът е 
>>> писал - иска мултипойнт VPN решение
под линукс. 
>>>       
>> Аз пак питам, къде е казал че иска layer2
VPN?
>>     
> Аз пак казвам - никой не го кара -> виж
най-горе. Layer 2 е връзката 
> само м/у линуските. После може да се включи
Layer 3 рутиране.
>   
>>> Ти говориш за маршрутизатори и техните
протоколи, а аз говоря за 
>>> най-обикновен линукс :). 
>>>       
>> Как стигна до това заключение? :)
>>     
> Това казвам - идеята ми е проблемът да
се реши без маршрутизиращи 
> протоколи, което според мен е елегантно
и, при добра настройка, почти 
> ненатоварващо хардуера. (криптирането
няма как да се избегне)
>   
>>> А ако се чудиш какво става с arp заявката
и изцяло с ethernet 
>>> broadcast-ите 
>>>       
>> Изобщо не се чудя дори :)
>>     
>>> зависи изцяло от това дали иска
Layer-2 или Layer-3   
>>>       
>> питам аз ... ;-)
>>     
> виж по-горе.. :)
>   
>>> свързаност м/у точките. Ако си запознат
със СТП протокола, ще знаеш, 
>>> че всички портове, които не се ползват
(т.е имат детектнат loop),
>>>       
>> Сигурно съм наясно малко повече от
теб за работата на STP (дано не 
>> прозвучи захапливо, наистина нямам
намерение да се заяждам)
>>     
> не можеш да бъдеш сигурен ;-)
>   
>>> се блокират изцяло и през тях минават
само 802.1d пакети. Не виждам 
>>> какво общо имат arp-заявките тук.
>>>       
>> Сигурно вече си разбрал, описах го
по-горе.
>>     
> даже и да направи Layer 2 VPN, което пак казвам,
и _подчертавам_, че не 
> е задължително - има си ebtables за контриране
на broadcast бури и 
> всякакви други 'лоши' фреймове.
>   
>>> Ако реши може да си бриджне и вътрешни
мрежи в този 'общ бридж' и 
>>> всичко пак ще си работи абсолютно
без проблеми. Ако човекът има нужда 
>>> от помощ - да ми драсне едно писмо
- ще помогна с каквото мога. Не ми 
>>> се спори повече. Приятна вечер.
>>>   
>>>       
>> Приятелю, не ме разбирай погрешно.
Аз съм последният човек в тази листа, 
>> който иска да породи конфликт. Просто
ми е странна твоята идея!!!Аз също 
>> съм тук за да помагам с каквото мога!!!
>>     
> Продължавам да си мисля, че не схващаш
напълно, каква ми е идеята и 
> затова гледам да бъда минимално остър
:) Извинявам се, ако съм те 
> засегнал с нещо. От алкохола е :)
>
>   

-- 
Danail Petrov
Senior Network Administrator
Evolink, Sofia
+359(2)9691650
www.evolink.com
icq uin 989677

[attachment "smime.p7s" deleted by Tsvetin Vasilev/BG/CCHBC]
_______________________________________________
Lug-bg mailing list
Lug-bg@xxxxxxxxxxxxxxxxxx
http://linux-bulgaria.org/mailman/listinfo/lug-bg

---

LEGAL DISCLAIMER:This e-mail contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, or print this e-mail.

_______________________________________________
Lug-bg mailing list
Lug-bg@xxxxxxxxxxxxxxxxxx
http://linux-bulgaria.org/mailman/listinfo/lug-bg