Може би иска всичките отдалечени точки да са в един мрежови сегмент? (поради някаква причина, не обсъждаме каква:) ) Поздрави Цветин
Danail Petrov <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 31.07.2007 02:35 Please respond to Linux Users Group - Bulgaria <lug-bg@linux-bulgaria.org> To Linux Users Group - Bulgaria <lug-bg@linux-bulgaria.org> 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@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg
_______________________________________________ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg
