-
Path: news-archive.icm.edu.pl!news.icm.edu.pl!uw.edu.pl!newsgate.cistron.nl!newsgate.
news.xs4all.nl!194.109.133.84.MISMATCH!newsfeed.xs4all.nl!newsfeed5.news.xs4all
.nl!xs4all!feeder.news-service.com!postnews.google.com!k22g2000yqh.googlegroups
.com!not-for-mail
From: obeer <s...@g...com>
Newsgroups: pl.internet.polip
Subject: Re: Polityka bezpieczeństwa PWR PLIX vs niezawodność i wygoda.
Date: Wed, 19 Jan 2011 15:14:31 -0800 (PST)
Organization: http://groups.google.com
Lines: 225
Message-ID: <6...@k...googlegroups.com>
References: <ih4abu$25q$1@inews.gazeta.pl>
<9...@l...googlegroups.com>
<ih6qkc$6rf$1@news2.ipartners.pl> <ih6ulr$p1e$1@news.onet.pl>
<7...@i...googlegroups.com>
<e...@o...googlegroups.com>
<9...@m...googlegroups.com>
NNTP-Posting-Host: 87.207.180.21
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Trace: posting.google.com 1295478871 14916 127.0.0.1 (19 Jan 2011 23:14:31 GMT)
X-Complaints-To: g...@g...com
NNTP-Posting-Date: Wed, 19 Jan 2011 23:14:31 +0000 (UTC)
Complaints-To: g...@g...com
Injection-Info: k22g2000yqh.googlegroups.com; posting-host=87.207.180.21;
posting-account=vSccbgoAAACF54J3--3jB0Yu2dOVqDjG
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (iPad; U; CPU OS 4_2_1 like Mac OS X; pl-pl)
AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8C148
Safari/6533.18.5,gzip(gfe)
Xref: news-archive.icm.edu.pl pl.internet.polip:93752
[ ukryj nagłówki ]On 19 Sty, 22:24, "f...@o...pl" <f...@o...pl> wrote:
> On 19 Sty, 21:52, nastach <n...@p...pl> wrote:
>
>
>
>
>
> > On 19 Sty, 21:34, "f...@o...pl" <f...@o...pl> wrote:
>
> > > On 19 Sty, 16:06, Grzegorz Janoszka <Grzeg...@nie-lubie-
>
> > > 20 lub 200 punktów wymiany stosuje ustalone przez siebie zasady? - to
> > > są tylko zapisy danej firmy - to nie jest bezwzględne prawo! W
> > > dokumentacji przywołanego tu AMSIX nie ma wzmianki o tym, iż nie
> > > przychylą się do potrzeb partnerów w interesach (to taką relację
> > > klient-sprzedawca uznaję za najbardziej dojrzałą).
>
> > Nie chodzi tu o zapisy w umowach tylko o dobre praktyki, które się
> > sprawdzają i zostały wypracowane przez IX'y. Jest to spowodowane
> > tylko tym żeby zapewnić bezpieczeństwo innym uczestnikom. Szkoda
> > jak by jeden uczestnik mógł spowodować awarię u innych uczestników
> > IX'a.
> > Uwierz mi czym większy IX tym mniej elastyczny.
>
> > > Mamy wolny rynek, a
> > > ja wierzę, że to potrzeby klienta wpływają na jego kształt. Wierzę, w
> > > moc konkurencji - dlatego jestem ciekawy stanowiska nowego gracza,
> > > jakim jest TPIX (lub innych punktów wymiany).
>
> > Polecam link, który wcześniej wklejałem.
>
> > > Właśnie elastyczność, szybkość reakcji i podążanie za potrzebami rynku
> > > decydują o rozwoju firm. Mi jako płatnikowi zależy na jak najlepszej
> > > jakości usług. Chcę uzyskać maksymalną niezawodność. Nie chcę jednak
> > > strzelać z armaty do muchy - chciał bym zastosować jak najprostsze
> > > rozwiązanie, gdyż takie działają najlepiej. Problem został opisany w
> > > tym celu, by bardziej doświadczeni administratorzy mogli pomóc -
> > > odpowiedzi trudno jednak uznać mi za wsparcie ze strony usługodawcy.
> > > Zupełnie inaczej firma (dla której pracuję) została potraktowana przez
> > > ATMAN'a.
> > > Nie rozumiem postawy "gdzie to jest wpiete po Twojej stronie to nas
> > > nie interesuje". Gdzie tu interakcja z klientem? Przecież, można
> > > nawiązać lepsze relacje z klientem - nawet bez realizacji jego
> > > "zachcianek".
>
> > Oczywiście że jest ale nie można spełniać wszystkich zachcianek
> > "Bo ja jestem super klient mam dostać co chcę bo się nie wepnę".
> > Dla nas jest ważniejsze bezpieczeństwo i niezawodność niż podpinanie
> > za wszelką cenę klientów.
>
> > > PLIX miał być rodzajem "głównego" łącza. Taki był plan, ponieważ to
> > > jest PLIX! Niestety, tak nie może być.
>
> > Widać nasza strata :-((
>
> > > Spodziewałem się powodzi
> > > pomysłów, rozpoznania potrzeb klienta, wsparcia specjalistów. No cóż,
> > > należy się z tym pogodzić i podpiąć teraz tak jak dają. Takie
> > > życie :-)))
> > > Co do TPIX - wygląda na to, że jesteśmy atrakcyjnym klientem dla TP.
> > > Nie kontaktowaliśmy się jeszcze w sprawie TPIX'a, ale jeśli nikt się
> > > nie wypowie w tej sprawie tutaj to spróbuję uzyskać odpowiedzi na moje
> > > pytania i je tutaj zamieszczę.
>
> > TPIX ma taką samą umowę dla wszystkich uczestników, jak widać w ich
> > dokumencie jeden mac-address na porcie.
>
> > Pozdrawiam
>
> "Widać nasza strata :-((" - to nie tak :-)
> Rozwój Internetu - czyli i PLIX'a! - jest w interesie każdego z nas,
Cieszę się, że tak nas postrzegasz :)
> oraz firm dla których pracujemy. Do tego dążymy. Tak zarabiamy.
> Nie widzę tylko merytorycznego stwierdzenia, np.:
> - nie mamy możliwości technicznych, nasz sprzęt tego nie wspiera, ale
> kliencie pracujemy nad tym, może tak kiedyś się da
Bo prawda jest taka, ze technicznie da się to zrobić po naszej
stronie.
Nie raz i nie dwa już o tym myśleliśmy i nawet chcieliśmy poluzować
nasze założenia, jednak za każdym razem przychodziły nam na pamięć
sytuacje gdy nasi klienci powodowali "drobne" awarie.
Jedna z nich na przykład spowodowała, że niektóre portale na
kilkanaście minut zniknęły z tablicy światowego bgp.
Weź pod uwagę jedną rzecz: jesteśmy profesjonalnym ixem i tego
profesjonalnego podejścia od nas wymagają uczestnicy korzystający z
dostępu do PLIXa.
Ostatnią rzeczą jaka przychodzi nam do głowy jest robić na złość
firmom, które łożą na nasze utrzymanie.
Wiele pomysłów naszych klientów wdrazamy, chociaż czasem nie są do
końca po naszej myśli, np. Porty 100Mbps + colo switcha 1u w cenie
500pln, mimo, że od samego początku twierdziliśmy, że minimalny port
do podpiecia się w PLIXie to gigabit.
Niemniej dla nas i naszych uczestników najważniejsze jest żeby PLIX/
Internet działał i tutaj musimy być tym złym policjantem, który na
niektóre rzeczy pozwolić nie może dla bezpieczeństwa "społeczeństwa"
czyli w naszym wypadku uczestników PLIXa.
> - lub: kliencie {szanowny :) } mylisz się, tak się nie robi, jesteś w
> błędzie, to jest do niczego, ponieważ... (tu mi się podobał pierwszy
> post Sylwestra: merytorycznie stwierdził, że dane rozwiązanie może
> zrywać sesję BGP)
> - kliencie, zróbmy tak: ty osiągniesz swoje cele jeśli zrobisz to i
> to, kupisz to i tamo, my zrobimy też coś, by łatwiej Ci było osiągnąć
> dany cel
> - inaczej: kliencie, super pomysł! masz port na rok za darmo :->
W większości przypadków pomagamy uczestnikom PLIXa jak tylko możemy.
Z drugiej strony oczekujemy, że będą dostosowywać swoje myślenie i
działanie nie tylko do tego jak im jest wygodniej, a jak bezpieczniej
i pewniej będzie dla wszystkich.
Ja ie mam nic przeciwko vrrp/carpom, jak już pisałem, sam wielokrotnie
takie rozwiązania implementowalem u wielu naszych uczestników, to
naprawdę da się zrobić w sposób taki, aby było jak najmniej bolesne
dla operatora.
Oczywiście inne duże IXy są dla nas wzorem, gdyż one mają często dużo
więcej problemów z którymi sobie radzą a do nas to nie trafia,
niemniej z ciekawostek mogę napisać, ze kilka lat temu zanim udało nam
się uporządkować publiczny vlan PLIXowy, urządzenia pewnego producenta
z Tajwanu, po wpieciu portem accessowym do PLIXa wieszały się
fizycznie i bez hard resetu nie wstawały.
Piszę to po to, by pokazać, że pozornie proste i nie szkodzące nikomu
pakie mogą oddziaływać na innych w tym samym vlanie w różny sposób.
Generalnie zasada jest taka: mamy ponad 100Gbps ruchu. Jeśli ktoś
swoim działaniem spowoduje, że ten ruch w PLIXie przestanie lecieć, to
wszyscy będą mieć problemy.
My wybieramy mniejsze zło. Nawet jeśli miało to być kosztem rezygnacji
jednego klienta z usługi. Nam zależy na tym, by wszyscy mieli stabilną
usługę.
Możemy odpytać każdego z ponad 160 uczestników PLIXa, czy się zgadzają
na takie rozwiązanie jakiego się domaga Sławek. Jeśli nie będzie
obiekcji, to wdrożymy to od jutra.
Mam nadzieje, ze przybliżyłem istotę problemu.
Ps. Przeczytajcie dokładnie regulamin TPIXa. Tajemnicą poliszynela
jest, że tworzył go w dużej mierze nasz były już pracownik. Zobaczcie
jakie są tam zapisy odnośnie ilości maców na porcie etc. Zerknijcie
też na czas reakcji na awarie i porownajcie to z tym co na co dzień
oferujemy w PLIXie. Może wtedy zrozumiecie, czemu jesteśmy tacy
"staroświeccy" w podejściu dotyczącym bezpieczeństwa wszystkich w
PLIXie.
Sylwester
Następne wpisy z tego wątku
- 19.01.11 23:20 f...@o...pl
- 19.01.11 23:29 obeer
- 19.01.11 23:44 Andrzej 'The Undefined' Dopierała
- 20.01.11 09:35 Sławek Lipowski
- 20.01.11 17:56 Zboj
- 20.01.11 19:16 Smok Eustachy
- 20.01.11 20:20 f...@o...pl
- 21.01.11 11:44 Tomasz Śląski
- 21.01.11 12:17 Ziolko
- 21.01.11 12:40 Verox
- 21.01.11 13:10 Maciej Bebenek (news.onet.pl)
- 21.01.11 14:20 Zboj
- 21.01.11 14:55 obeer
- 21.01.11 17:12 Zboj
- 21.01.11 18:57 obeer
Najnowsze wątki z tej grupy
- Jest tutaj kto? Halo, Darius Expert?
- Czy to konieczne? ATMAN - 30.06.2019 - Wyłączenie news.atman.pl
- pl.internet.polip - is DEAD?
- ovh
- INEA
- Prośba o traceroute z Vectry
- BGP - wszyscy wkładają głowę w piasek.
- http://pl
- Re: Czemu jest wylaczany serwer w3cache.icm.edu.pl ?
- Taaaka integracaj na rynku, a tu nikt, nic..
- Alternatywna sieć dla internetu kiedyś w Polsce
- ooerator gsm + stały ip z revdns
- Dostęp do ip nostrady
- narzędzia do weryfikacji poprawności bazy WHOIS
- T-mobile bawi się w MITM....
Najnowsze wątki
- 2024-12-23 Riga => Specjalista ds. public relations <=
- 2024-12-23 Łódź => Specjalista ds. Sprzedaży <=
- 2024-12-23 Kraków => International Freight Forwarder <=
- 2024-12-23 Co nalezy do Cinkciarza, a co do Conotoxia ?
- 2024-12-23 Poznań => Key Account Manager <=
- 2024-12-23 Warszawa => Presales / Inżynier Wsparcia Technicznego IT <=
- 2024-12-23 Rzeszów => Spedytor Międzynarodowy <=
- 2024-12-23 Warszawa => Infrastructure Automation Engineer <=
- 2024-12-23 Białystok => Analityk w dziale Trade Development (doświadczenie z Po
- 2024-12-23 Warszawa => Site Reliability Engineer (SRE) <=
- 2024-12-23 Warszawa => DevOps Engineer <=
- 2024-12-23 Warszawa => Senior Account Manager <=
- 2024-12-23 Katowice => Regionalny Kierownik Sprzedaży (OZE) <=
- 2024-12-23 Katowice => Administrator IT - Wirtualizacja i Konteneryzacja <=
- 2024-12-23 Mińsk Mazowiecki => Spedytor Międzynarodowy <=