Sławek Lipowski <s...@l...org> wrote:
>> To przed położeniem sesji (jak już bardzo chcesz) zrób tak aby tym
>> łączem nic nie chciało iść, wtedy położenie będzie niezauważalne.
> Wyobraźmy sobie sytuację, że przerzucamy priorytetowy i czuły ruch
> między dwoma firmami. Obie firmy mają łącza od 2 tych samych dostawców.
> Obie mają BGP ustawione tak, że ruch domyślnie idzie przez dostawcę 1.
> Niestety jedna z firm ma od dostawcy 2 łącze o małej przepustowości. Jak
> teraz druga firma ma bezboleśnie położyć sesję BGP z dostawcą 1?
> Poza tym zakładasz bardzo piękny scenariusz, w którym przy 2 łączach do
> bezstratnego obsłużenia całego ruchu wystarczy przepływność jednego z
> nich...

E... tego... to źle ustawione. Drugie (i trzecie) łącze powinno być
w stanie obsłużyć cały ruch przy założeniu padnięcie drugiego (czasem
nawet dwóch pozostałych) łącz. Inaczej to takie... słabe zabezpieczenie
i wszyscy powinni być przygotowani na degradację ruchu.

p.

--
Beware of he who would deny you access to information, for in his
heart he dreams himself your master. -- Commissioner Pravin Lal

do góry

On 2009-07-04, Piotr KUCHARSKI <c...@s...waw.pl> wrote:
> Sławek Lipowski <s...@l...org> wrote:
>>> To przed położeniem sesji (jak już bardzo chcesz) zrób tak aby tym
>>> łączem nic nie chciało iść, wtedy położenie będzie niezauważalne.
>> Wyobraźmy sobie sytuację, że przerzucamy priorytetowy i czuły ruch
>> między dwoma firmami. Obie firmy mają łącza od 2 tych samych dostawców.
>> Obie mają BGP ustawione tak, że ruch domyślnie idzie przez dostawcę 1.
>> Niestety jedna z firm ma od dostawcy 2 łącze o małej przepustowości. Jak
>> teraz druga firma ma bezboleśnie położyć sesję BGP z dostawcą 1?
>> Poza tym zakładasz bardzo piękny scenariusz, w którym przy 2 łączach do
>> bezstratnego obsłużenia całego ruchu wystarczy przepływność jednego z
>> nich...
>
> E... tego... to źle ustawione. Drugie (i trzecie) łącze powinno być
> w stanie obsłużyć cały ruch przy założeniu padnięcie drugiego (czasem
> nawet dwóch pozostałych) łącz. Inaczej to takie... słabe zabezpieczenie
> i wszyscy powinni być przygotowani na degradację ruchu.

Bo to nie jest redundancja tylko agregacja ;)

--
Pozdrawiam,
Marek Marczykowski | gg:2873965
marmarek at staszic waw pl | xmpp:marmarek at staszic waw pl

do góry

Lukasz Trabinski pisze:
> Sławek Lipowski <s...@l...org> wrote:
>
>> Poza tym zakładasz bardzo piękny scenariusz, w którym przy 2 łączach do
>> bezstratnego obsłużenia całego ruchu wystarczy przepływność jednego z
>> nich...
>
> To jest normalny scenariusz.
>

Norma to jest pojęcie względne. Dla mnie normalną sytuacją jest to, że
kierownictwo oszczędza na łączu i nie pozwoli płacić 2x więcej za nie
tylko po to, żeby jedno mogło obsłużyć cały ruch. Zamiast tego zwraca
uwagę, że mamy duży procent mniej krytycznego ruchu, który w razie czego
może być nieco zdegradowany. A jak następuje awaria łącza, to to samo
kierownictwo naciska, żeby jak najszybciej coś z tym zrobić, bo są
straty wynikające ze zdegradowania tego mniej priorytetowego ruchu...

--
Sławek Lipowski

do góry

Piotr KUCHARSKI pisze:
> Sławek Lipowski <s...@l...org> wrote:
>>> To przed położeniem sesji (jak już bardzo chcesz) zrób tak aby tym
>>> łączem nic nie chciało iść, wtedy położenie będzie niezauważalne.
>> Wyobraźmy sobie sytuację, że przerzucamy priorytetowy i czuły ruch
>> między dwoma firmami. Obie firmy mają łącza od 2 tych samych dostawców.
>> Obie mają BGP ustawione tak, że ruch domyślnie idzie przez dostawcę 1.
>> Niestety jedna z firm ma od dostawcy 2 łącze o małej przepustowości. Jak
>> teraz druga firma ma bezboleśnie położyć sesję BGP z dostawcą 1?
>> Poza tym zakładasz bardzo piękny scenariusz, w którym przy 2 łączach do
>> bezstratnego obsłużenia całego ruchu wystarczy przepływność jednego z
>> nich...
>
> E... tego... to źle ustawione. Drugie (i trzecie) łącze powinno być
> w stanie obsłużyć cały ruch przy założeniu padnięcie drugiego (czasem
> nawet dwóch pozostałych) łącz. Inaczej to takie... słabe zabezpieczenie
> i wszyscy powinni być przygotowani na degradację ruchu.
>
> p.
>

Niestety przy tego typu współpracy (dwie firmy, dwa zarządy, wspólne
interesy) nie na wszystko ma się wpływ.

--
Sławek Lipowski

do góry

Sławek Lipowski <s...@l...org> wrote:

> Norma to jest pojęcie względne. Dla mnie normalną sytuacją jest to, że
> kierownictwo oszczędza na łączu i nie pozwoli płacić 2x więcej za nie
> tylko po to, żeby jedno mogło obsłużyć cały ruch. Zamiast tego zwraca
> uwagę, że mamy duży procent mniej krytycznego ruchu, który w razie czego
> może być nieco zdegradowany. A jak następuje awaria łącza, to to samo
> kierownictwo naciska, żeby jak najszybciej coś z tym zrobić, bo są
> straty wynikające ze zdegradowania tego mniej priorytetowego ruchu...

Kierownictwo słyszało np. o 95 percentylu i takim sposobie płacenia za
ruch na backupowym łaczu? Z drugiej strony, albo oszczędności, albo
niezawodność w każdej sytuacji.

--
ŁT

do góry

Lukasz Trabinski pisze:
> Sławek Lipowski <s...@l...org> wrote:
>
>> Norma to jest pojęcie względne. Dla mnie normalną sytuacją jest to, że
>> kierownictwo oszczędza na łączu i nie pozwoli płacić 2x więcej za nie
>> tylko po to, żeby jedno mogło obsłużyć cały ruch. Zamiast tego zwraca
>> uwagę, że mamy duży procent mniej krytycznego ruchu, który w razie czego
>> może być nieco zdegradowany. A jak następuje awaria łącza, to to samo
>> kierownictwo naciska, żeby jak najszybciej coś z tym zrobić, bo są
>> straty wynikające ze zdegradowania tego mniej priorytetowego ruchu...
>
> Kierownictwo słyszało np. o 95 percentylu i takim sposobie płacenia za
> ruch na backupowym łaczu?

Słyszało i uznało, że nie chce co chwile pilnować i kalkulować kosztów.
Zmartwiło się też tym, że niezaprzyjaźniona firma mogłaby podbijać
koszty generując ruch na tym łączu.

> Z drugiej strony, albo oszczędności, albo
> niezawodność w każdej sytuacji.
>

Dokładnie jest tak ja mówisz. Krytyczny ruch mamy zabezpieczony, ten
mniej... To już zależy. Ale to już kwestia kalkulacji ryzyka...

--
Sławomir Lipowski

do góry