-
Path: news-archive.icm.edu.pl!news.gazeta.pl!not-for-mail
From: Sławek Lipowski <s...@l...org>
Newsgroups: pl.internet.polip
Subject: Re: Polityka bezpieczeństwa PWR PLIX vs niezawodność i wygoda.
Date: Thu, 20 Jan 2011 10:35:47 +0100
Organization: "Portal Gazeta.pl -> http://www.gazeta.pl"
Lines: 158
Message-ID: <ih8vlj$a8t$1@inews.gazeta.pl>
References: <ih4abu$25q$1@inews.gazeta.pl>
NNTP-Posting-Host: gargamel.bpcentrum.net
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: inews.gazeta.pl 1295516147 10525 193.142.113.195 (20 Jan 2011 09:35:47 GMT)
X-Complaints-To: u...@a...pl
NNTP-Posting-Date: Thu, 20 Jan 2011 09:35:47 +0000 (UTC)
X-User: s.lipowski
In-Reply-To: <ih4abu$25q$1@inews.gazeta.pl>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226
Icedove/3.0.11
Xref: news-archive.icm.edu.pl pl.internet.polip:93756
[ ukryj nagłówki ]Witam,
Dzięki za duży odzew. Trochę się tego nazbierało, żeby nie mnożyć postów
postaram się odpisać w jednym, tak skrótowo, jak się da.
<Odnośnie tego, co pisze Sylwester (jeśli mogę po imieniu oczywiście :))>
-> Przyjmuję do wiadomości, jak jest w AMS-IX. Sprawdziłem, jak jest w PLIX:
http://www.plix.pl/pl/help/faq
http://www.plix.pl/download/configuration_pl.pdf
"Uczestnicy podłączani są do węzła przy pomocy portów Ethernet o
przepustowości 1Gbps lub 10Gbps. Każdemu portowi uczestnika przydzielany
jest na stałe jeden lub więcej adresów IP z puli adresowej PLIX
195.182.218.0/23."
Czy możemy zatem otrzymać trzy adresy IP na jednym porcie (i wykorzystać
je we wspomniany wcześniej sposób) zakładając, że cały ruch będzie
przychodził z takim samym, pojedynczym adresem MAC? Ewentualnie jeśli
nie ma takie możliwości, to może warto zmienić tę informację? ;)
"umowa na dostęp do PLIX zabranie rozgłaszania więcej niż jednego adresu
MAC na jednym porcie."
Tego faktycznie wcześniej nie zauważyłem, mój błąd. Mam w związku z tym
pytanie na przyszłość. Jak wygląda u Was procedura migracji na inny MAC?
W AMS-IX możliwe jest przypisanie dwóch adresów MAC do portu.
-> VRRP w Linuksie (keepalived) nie ma zaimplementowanego wirtualnego
MAC adresu. Można oczywiście rzeźbić i osiągnąć taki efekt, ale wyznaję
zasadę, że najprostsze działające i spełniające wszystkie założone cele
rozwiązanie byłoby najlepsze. Ponadto z wirtualnym MAC w VRRP i CARP
jest też taki problem, że ich liczba jest ograniczona. W dużym IXe może
stanowić to realny problem.
-> Potrzebujemy rozwiązanie, które podtrzyma przynajmniej jedną sesję do
PLIXa, takie jest założenie.
-> "Wydaje mi się, że jeśli ktoś ma 600Mbps
ruchu do PLIXa (czyli ok. 1,5Gbps całego swojego ruchu), to stać go
już na coś mocniejszego niż pecet z linuxem/bsd"
Ruter na linuksie nie musi oznaczać "peceta". Nie wspomnę już o tym, że
zarówno PLIX, jak i wspomniany AMS-IX nie działają na "czymś lepszym",
tylko na linuksie/bsd, prawda?
<Nastach>
-> Nie forsuje swojego rozwiązania, nie twierdzę, że jest najlepsze, nie
staram się wymusić niczego na PLIXie, po prostu pytam o propozycje
możliwych rozwiązań zakładając, że zarówno stanowisko PLIXa, jak i
wymagania klienta się nie zmienią.
<Sylwester & Nastach>
-> Co w kwestii bezpieczeństwa zmienia to, czy na poście przepuścicie
jeden MAC, czy tez dwa? Pytam z Ciekawości.
<Rafal>
-> Co do wymagań z perspektywy klienta, to mam wrażenie, że tak to tylko
u nas no i może w Erze. ;)
<Bartosz Waszak>
-> "Sam pomysł VRRP na styku z BGP jest wg mnie dziwnym wynalazkiem."
VRRP w tym rozwiązaniu nie przełącza IP, z których spinane są sesje.
VRRP przełącza adres, który jest rozgłaszany jako next hop.
-> "Czemu nie 2 komplety sesji BGP z kazdym z routerow uniknie sie
zbednych announce/withdrawn z BGP i braku dostepnosci na czas
renegocjacji sesji ?"
Nie wiem, czy dobrze rozumiem, co masz na myśli, ale dokładnie tak mamy.
Na każdej z maszyn mamy komplet sesji BGP do każdego operatora. Do PLIXa
w prosty sposób na jednym porcie się nie da spiąć sesji z obu maszyn, bo
jeden MAC per port.
-> "To w czasach 95% chyba nie jest zbytnio trudne :P "
Nie jest, ale klient tego nie chce. Trzeba by to stale kontrolować,
ponadto klient wymaga stałych opłat za łącza. Klient jest przede
wszystkim dostawcą treści, ma dużo usług wystawionych na cały świat.
Jakiś niemiły gest ze strony konkurencji mógłby podbijać koszta.
<Grzegorz Janoszka>
-> "Punkt wymiany ruchu nie może być
"głównym łączem"."
Oczywiście w przypadku ISP nie może być. Tylko że mowa o dostawcy
treści, który celuje w polskiego odbiorcę i który realizuje teraz ruch
głównie w dwóch kierunkach: polskie IXy (poprzez AC-X, pośrednio przez
PLIX i KIX) oraz TP. Myślę, że to wyjaśnia, co Rafał miał na myśli.
Jeśli miał na myśli coś innego, to mnie za chwilę zapewne poprawi. :)
-> "Żaden szanujący się punkt wymiany ruchu na świecie nie bawi się w
jakiś wirtualne adresy szalejące między quaggami"
Co rozumiesz przez nie pozwala? To, że zezwala na jedno IP i jeden MAC
nie znaczy, że nie może stać za tym dowolne rozwiązanie (w tym quagga z
"szalejącymi", cokolwiek masz na myśli, adresami IP). Sylwester pisał o
tym wcześniej. Ponadto we wspomnianym rozwiązaniu VRRP nie przełącza
IPków, z których quaggi spinają sesje BGP.
-> "Stasiu i Jasiu zrobili osiedlówkę"
Pudło, tak jak mówiłem, nie osiedlówka, a dostawca treści.
<Komuch>
Z tego co zdążyłem doczytać, to vyatta także nie ma wirtualnego MAC
adresu na VRRP i ludzie starają się to obchodzić tak samo, jak w każdym
innym linuksie.
<Andrzej 'The Undefined' Dopierała>
-> "Przez dlugi czas zastanawialem sie czy nie zaprzac do tego
wszystkiego vrrp.
Ale doszedlem do wniosku ze pomysl jest bez sensu."
W tym wypadku takie, a nie inne rozwiązanie wynikło bezpośrednio z
wymagań klienta, przyjętej przez niego polityki i różnych zaszłości
związanych z istniejącymi już rozwiązaniami. Rozwiązanie się sprawdza.
-> "acx w l3? czy l2? Jezeli l3 - ma zasieg lokalny przeciez. Wiec
potencjalny
problem by dotyczyl tylko Twojego wezla."
Oczywiście, że w L2. Wszystkie usługi ATMANa mamy zresztą tak podpięte.
Pozostaje pochwalić AC-X za swobodę, jaką dają klientowi i za to, że to
ogarniają jakoś mimo braku ograniczeń.
<Zboj>
Generalnie się zgadza. Powód dla którego utrzymywane są po stronie
klienta dwie maszyny z pełnym kompletem tras jest ogólnie taki sam, jak
ten, dla którego PLIX ma dwa RSy. Nawet działa to na podobnej zasadzie. :)
<Ogólnie>
Generalnie to dyskusja, chyba nieco niepotrzebnie, zeszła na sferę
polityczną, podczas gdy nie stawiałem sobie za cel reformowanie PLIXa, a
jedynie rozwiązanie danego problemu technicznego.
Aktualnie rodzi mi się już w głowie koncepcja wyrzeźbienia pewnego
rozwiązania, które zadowoli klienta i spełni wymogi PLIXa, zobaczymy co
z tego wyjdzie.
Jeśli pominąłem coś istotnego, to proszę zwrócić mi uwagę. :)
Pozdrawiam,
--
Sławomir Lipowski
http://lipowski.org
Następne wpisy z tego wątku
- 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
- 21.01.11 20:07 Pawel Sikora
- 21.01.11 22:52 Przemysław Gubernat
- 21.01.11 23:40 Łukasz Bromirski
- 22.01.11 21:31 Michal Jankowski
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 <=