>> Zde si dovolim nesouhlasit, vystupni interface smerem VEN je >> adresovany, i kdyz jsou to adresy pouze pro routing > > Aha, tak to jsem v tvym popisu videl vic, nez jsi tam ty vedome vlozil. > > Pak tedy slo o napad muj, coz muzu vnimat jako pozitivni zjisteni, na > druhou stranu mi v takovem pripade bohuzel neprislusi napad > prohlasovat za inovativni, uzasny a zajimavy ... ;-) > > Ja tam vidim urcitou hypotetickou sanci na reseni systemove obecne, > pritom bez prekladu, proxy i nutnosti specificky konfigurovat > jednotlivy aplikace. > > Ale asi se nevydam tu cestu prozkoumat, protoze i kdyby se ukazalo, ze > to reseni je opravdu funkcni, je to natolik nestandardni konfigurace, > ze se proste na kriticky infrastrukturni stroj nehodi. > > Dan > Zde si opet dovolim castecne nesouhlasit. Z pohledu routingu se jedna o standardni routing (co na tom ze interface je virtualni, to je ve finale i VLAN interface :-D). Z pohledu systemoveho ovsem souhlasim, je to takovej "ohejbak na rohliky", nicmene funguje to. Jak podotykas Dane, pro kriticky infrastrukturni stroj je to hodne nestandardni berlicka, nicmene stale se pohybujeme v nativnich vecech pouzitych "nativnim" zpusobem, tudiz ani update by to nemely rozhodit. Imho ale z hlediska sitare/routare je to klasicka "chuze okolo blokace", kterych na BGP exterior routerech jsi stejne nucen delat X. Jinak poznamka pro zadavatele .... doporucuji urychlene kompilovat jadro s optionem ROUTE_TABLES= >1, stejne casem dopadnete na policy routing (jeste jsem nepotkal bgp peering s multiple uplink ktery by to nepotreboval), takze doporucuji to udelat jeste v okamziku kdy to jde. Ale predpokladam ze zadavatel vzhledem ke sve profesi to zna i lip nez ja, ktery si s tim momentalne lamu hlavu za provozu u jednoho kseftu. Vilem
-- S pozdravem Vilem Kebrt email: vilem.ke...@gmail.com -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l