Article View: pl.internet.polip
Article #93753Re: Polityka bezpieczeństwa PWR PLIX vs niezawodność i wygoda.
From: obeer
Date: Fri, 21 Jan 2011 18:57
Date: Fri, 21 Jan 2011 18:57
58 lines
4499 bytes
4499 bytes
On Jan 21, 6:12 pm, "Zboj" <zboj_...@mnc.dot.pl> wrote: > > Przykro mi to czytać, jeżeli nie wiesz co mogą zrobić 2 mac-addressy w > > sieci L2 wpięte na jednym porcie, to zastanawiam się co robisz w swoim > biznesie. > > Zastanów się może lepiej, jak dobrze uzasadnić Twoje zastrzeżenie. Pomijam > edukację mojej ciemnej osoby. Chodzi raczej o techniczne uzasadnienie Twojej > tezy, którego ciągle skąpisz. Uważam, że nie przeczytałeś dokładnie tego co napisałem. przypomina mi się cytat z filmu "Job": "Drogi chłopcze, rozmowa ze mną nie ma sensu, ponieważ jestem kompletnie głucha". I tak samo uważam w tym przypadku. Jesteś głuchy na argumenty innych. Chcesz sobie robić urynanet w swojej sieci, to sobie rób. Wypracowałeś best practices na swoim sprzęcie - wyobraź sobie, że inni również. Ja nie przekonuję Ciebie do tego, że świadczysz złą usługę, bo nie spełnia moich oczekiwań. Nie wiem czy jesteś świadom tego, że mechanizmy wykrywania pętli gdy po drugiej stronie jest sprzęt innego vendora i skonfigurowany przez kogoś innego nie zawsze działają? Jeżeli Twój switch (powiedzmy Cisco) wysyła do innego switcha ramkę BPDU i czeka aż ona wróci i na tej podstawie stwierdza czy jest pętla czy nie, to ktoś do kogo jesteś wpięty może filtrować BPDU (Cisco z włączonym BPDU Filter) i je dropować, a i tak pętle zrobi spinając u siebie 2 porty. Co w takim przypadku? Twój super switch po prostu ją przepuści. Logika switcha PLIXowego jest prosta: ten sam mac pojawia się na 2 portach, znaczy pętla, znaczy coś z tym zrób (co - w zależności od konfiguracji). Zapewniam Cię, że mamy dużo filtrów na Layer2 w PLIXie (ACLki na MACki, loop-detection, rate-limity na broadcasty, multicasty, dropujemy wszystkie ramki inne niż IP i IPv6, wpuszczamy tylko konkretne EtherTypy i inne cuda robimy jeszcze) na każdym porcie klienckim, a mimo tego trzymamy się naszej zasady. Jak na razie zasada się sprawdza, bo nawet w przypadku gdy switch eFUZJI/KIKE/KIXa, które to KIKE również reprezentujesz jako Członek Komisji Rewizyjnej, robił niejednokrotnie pętle w PLIXie, to klienci PLIXowi tego nie odczuwali. I właśnie wszystkim chodzi o to, aby to było zachowane. Myślę, że dyskusja odeszła już zupełnie od tego o co pytał Sławek Lipowski. Ustaliliśmy stanowisko PLIXa, wysłuchaliśmy komentarzy. Proponuję zamknąć ten temat. Sylwester ps. RSTP nie służy do wykrywania pętli. ps.2. Stormy to z reguły są efektem pętli a nie służą do ich wykrywania, ale może w tym szaleństwie jest metoda ;-P
Technical Details
Message-ID:
<980d8a84-389e-441a-9cc5-ba55de323bdd@v12g2000vbx.googlegroups.com>Path:
mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!lublin.pl!uw.edu.pl!newsgate.cistron.nl!newsgate.news.xs4all.nl!news2.euro.net!feeder.news-service.com!postnews.google.com!v12g2000vbx.googlegroups.com!not-for-mailReferences:
<ih4abu$25q$1@inews.gazeta.pl> <9f3ad206-ad8e-463d-b704-b11b26962c7d@l24g2000vby.googlegroups.com> <ih6qkc$6rf$1@news2.ipartners.pl> <ih6ulr$p1e$1@news.onet.pl> <760ff2e9-6410-4cfe-9876-740eeb74a418@i18g2000yqn.googlegroups.com> <eacea4c9-eb17-42fc-81f8-395b931fd7ef@o14g2000yqe.googlegroups.com> <91ba10c2-38cd-4705-8717-b9e2a3946c6c@m13g2000yqb.googlegroups.com> <ih7qsa$77h$1@news.tiberium.net.pl> <ih9svo$1oi9$1@news2.ipartners.pl> <2343167c-98d1-45d1-80df-b8d9b5b7940e@t23g2000vby.googlegroups.com> <ihceqf$31ku$1@news2.ipartners.pl>Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!lublin.pl!uw.edu.pl!newsgate.cistron.nl!newsgate.news.xs4all.nl!news2.euro.net!feeder.news-service.com!postnews.google.com!v12g2000vbx.googlegroups.com!not-for-mail From: obeer <sylwester.biernacki@gmail.com> Newsgroups: pl.internet.polip Subject: Re: Polityka bezpieczeństwa PWR PLIX vs niezawodność i wygoda. Date: Fri, 21 Jan 2011 10:57:25 -0800 (PST) Organization: http://groups.google.com Lines: 71 Message-ID: <980d8a84-389e-441a-9cc5-ba55de323bdd@v12g2000vbx.googlegroups.com> References: <ih4abu$25q$1@inews.gazeta.pl> <9f3ad206-ad8e-463d-b704-b11b26962c7d@l24g2000vby.googlegroups.com> <ih6qkc$6rf$1@news2.ipartners.pl> <ih6ulr$p1e$1@news.onet.pl> <760ff2e9-6410-4cfe-9876-740eeb74a418@i18g2000yqn.googlegroups.com> <eacea4c9-eb17-42fc-81f8-395b931fd7ef@o14g2000yqe.googlegroups.com> <91ba10c2-38cd-4705-8717-b9e2a3946c6c@m13g2000yqb.googlegroups.com> <ih7qsa$77h$1@news.tiberium.net.pl> <ih9svo$1oi9$1@news2.ipartners.pl> <2343167c-98d1-45d1-80df-b8d9b5b7940e@t23g2000vby.googlegroups.com> <ihceqf$31ku$1@news2.ipartners.pl> NNTP-Posting-Host: 193.22.169.237 Mime-Version: 1.0 X-Trace: posting.google.com 1295636245 8344 127.0.0.1 (21 Jan 2011 18:57:25 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 21 Jan 2011 18:57:25 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: v12g2000vbx.googlegroups.com; posting-host=193.22.169.237; posting-account=vSccbgoAAACF54J3--3jB0Yu2dOVqDjG User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-us) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4,gzip(gfe) Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit