Dosazitelnost BGP routeru

[Vilem Kebrt]

>> 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.kebrt na gmail.com