-
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!lub
lin.pl!uw.edu.pl!newsgate.cistron.nl!newsgate.news.xs4all.nl!194.109.133.84.MIS
MATCH!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!feeder.news-service.co
m!postnews.google.com!q12g2000yqi.googlegroups.com!not-for-mail
From: nastach <...@p...pl>
Newsgroups: pl.internet.polip
Subject: Re: Polityka bezpieczeństwa PWR PLIX vs niezawodność i wygoda.
Date: Wed, 19 Jan 2011 14:17:52 -0800 (PST)
Organization: http://groups.google.com
Lines: 67
Message-ID: <1...@q...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.206.214.216
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
X-Trace: posting.google.com 1295475473 24587 127.0.0.1 (19 Jan 2011 22:17:53 GMT)
X-Complaints-To: g...@g...com
NNTP-Posting-Date: Wed, 19 Jan 2011 22:17:53 +0000 (UTC)
Complaints-To: g...@g...com
Injection-Info: q12g2000yqi.googlegroups.com; posting-host=87.206.214.216;
posting-account=usQRJQoAAACjvlOzyqI0F3TnX11u_k8n
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-US)
AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.231
Safari/534.10,gzip(gfe)
Xref: news-archive.icm.edu.pl pl.internet.polip:93744
[ ukryj nagłówki ]> "Widać nasza strata :-((" - to nie tak :-)
> Rozwój Internetu - czyli i PLIX'a! - jest w interesie każdego z nas,
> 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
> - 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 :->
> Skorzystamy z Twojego pomysłu i zaproponujemy innym uczestnikom
> podobne rozwiązania. Będziemy pierwsi na rynku wprowadzający takie
> rozwiązanie!
> Co było potrzebne: cztery pary zezwoleń dostępne na jednym porcie:
> - IP1 - MAC1
> - IP2 - MAC2
> - IP3 - MAC1
> - IP3 - MAC2
> Można to też rozwiązać inaczej - nie analizujmy teraz tego czy
> potrzeba tyle IP czy MAC'ów - odpowiadam bezpośrednio na poprzedni
> post.
> Serio(!) spodziewałem się lepszego kontaktu - chociaż dziękuję za
> podjęcie dyskusji tutaj. Podejście typu "bo regulamin" jest przypisane
> raczej dużym, nie elastycznym firmą - monopolistą.
Drogi przyszły/niedoszły kliencie.
Ale jak tu o merytoryczną dyskusją skoro upieracie się że wasze
rozwiązanie jest git i innego nie ma,
a IX'y się mylą bo chcą wyciągać kasę od klientów za kolejne porty.
Zrozum proszę że N mac-address'ów na jednym porcie to potencjalne
zagrożenie dla IX'a i innych uczestników.
Historia wiele razy pokazala, ze kazdy robi bledy. Nie mozemy sobie
pozwolic, aby jeden z uczestnikow poprzez swoja pomylke spowodowal
problem u innych.
Dla nas wyjście z tej sytuacje jest jedno, musimy stworzyć takie
zasady aby zapewnić bezpieczeństwo wszystkim uczestnikom co wiąże
się z nałożeniem pewnych restrykcji oraz ograniczeniom, które nie są
czasami zrozumiałe i wygodne dla nich.
Oczywiście możemy wpuszczać do sieci CDP/EDP/BPDU pozwalać każdemu na
N adresów IP oraz mac, nie filtorwać tego rozgłaszają
ale chyba nie tego od nas klienci oczekują prawda ?
P.S.
Ale najłatwiej krzyczeć: "Po pierwsze PLIX zły niechcieć dać mi 3
adresów ip, po drugie PLIX zły niechcieć mi puszczać 4 mac-addresów,
po trzecie PLIX na porcie 1G nie pozwala puszczać 2G"
Hmm może Kota by zatrudnić do reklamy z takim hasłem ;-))
Pozdrawiam
Następne wpisy z tego wątku
- 19.01.11 22:49 Grzegorz Janoszka
- 19.01.11 22:57 f...@o...pl
- 19.01.11 23:04 Bartosz Waszak
- 19.01.11 23:05 nastach
- 19.01.11 23:07 f...@o...pl
- 19.01.11 23:08 f...@o...pl
- 19.01.11 23:14 obeer
- 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
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 <=