Изцяло загубихте връзката с главната постановка. Когато градиш ethernet
енкапсулации ( openvpn tap) е жизнено важно да разделиш установката си
на 2 - virtual media : the holy TAP и пакетирането, което ще е обвързано
с тази медия. Прелестно е да се гради multimesh топология, но не трябва
да се забравя, че работата на такава мрежа е свързана с главоблъсканица
относно least cost path и weighted ratio. Когато Глинков спомена
spanning tree беше прав, но "цъжтящото дърво" хич не е "протокол"(просто
не са измислили по-готино име за STP), а problem solving methodology,
която е напълно приложима в конкретния случай. Идеята за общ, дори и
контролиран от STP ethernet segment е смехотворна заради чистия
overhead, който поемат активните и чакащите канали под форма на
broadcast и election traffic. Винаги е хубаво да си задавате един
въпрос, когато се опитвате да изградите state-of-the-art мрежа - 'аз
обичам ли да губя съня си, заради паднала точка и/или election loop?'.
Просто е хубаво да стъпиш на 2 солидни основи : контролирано рутиране и
достъпна медия.
Щом не искаш да разчиташ на една единствена машина, просто изброй като
remote peers(remote директивата на openvpn) всичките си хостове, на
които настрой client-to-client и единно адресиране(дори и през dhcpd за
consistency). Всеки път когато имаш счупен тунел(което в никакъв случай
не е еквивалентно на дефектирал сървър), клиентите ти ще се вържат към
следващия от редицата, но ще запазиш правото си да задаваш
приоритети(според начина, по който редиш хостовте в отделните конфиг
файлове) и ще преодолееш проблема с централизираното реконектване(няма
да ти се наложи да навържеш всичките си клиенти към "следващия" сървър,
ако един от тях спре временно да вижда настоящия crosspoint). Сега
остава да им push-неш генерални рутирания ( целия събнет се стига през
tunX/tapX ) и proxy_arp, като те ще са валидни през целия път на
пакетирането заради hopping line of sight. Така виртуалната ти мрежа ще
еволюира спрямо свързаността ОТ всеки peer, а не ДО всеки peer.
И като за след вечеря : защо по дяволите автоматично се спряхме на tap
interface-ing, а не на по-малко проблематичния и бърз tun? Явно
прекалено много пъти сме чували, че "мрежата" се състой от 2 неща -
shares and printers :) Ако искаш tier-effective netbios over
heterogenous networks - деплойни си WINS, мама ти(към лирическия герой),
а не бриджвай до посиняване на очните дъна.
Nikolaj wrote:
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
[email protected]
http://linux-bulgaria.org/mailman/listinfo/lug-bg
_______________________________________________
Lug-bg mailing list
[email protected]
http://linux-bulgaria.org/mailman/listinfo/lug-bg
