🚀 go-pugleaf

http://www.ams-ix.net/config-guide/

4.1. Physical L2 Topology
The AMS-IX rules dictate that only one MAC address is allowed behind a
port. This means that you have to be extremely careful when connecting
a device that can act as a L2 device. In general, we do not recommend
using L2 devices between a member's router and the AMS-IX switch,
except when used as a media converter.

The reason for allowing only one MAC address that we want no
additional L2 network behind the AMS-IX ports. Extended L2 networks
are not under the control of the AMS-IX, but instabilities in a L2
network behind the AMS-IX switches can and typically do have a
negative impact on the whole exchange. Forwarding loops and spanning
tree topology changes are
good examples of this. By enforcing the one-MAC-address-per-port rule,
we effectively prevent forwarding loops and STP traffic from
intermediate L2 devices.

In short, an intermediate L2 device may only bridge frames from the
member's router to the AMS-IX port (so we see only one MAC address)
and should otherwise be completely invisible. No connected device
should bridge frames from other devices onto the AMS-IX, or talk STP
on its AMS-IX interface.


[ciach]

Jeśli dobrze przeczytasz co jest napisane powyżej, oraz co Ci
odpowiadaliśmy, to zauważysz jedną prostą rzecz:

do PLIXa wchodzisz jedną rurką gdzie jest jeden mac-address wpuszczony
- gdzie to jest wpięte po Twojej stronie to nas nie interesuje.
W szczególności zapinasz to w switcha w port accessowy z dwoma innymi
accessowymi portami w tym samym vlanie.
W obrębie switcha twoje maszyny z VRRP/CARP będą rozmawiać ze sobą, a
do PLIXa będzie wpuszczany tylko ruch z maca i ip wirtualnego (ale
przecież właśnie o to chodzi, nieprawdaż?).

Co do samej sesji BGP masz rację, będzie musiało się BGP położyć i
podnieść na drugiej maszynie, ale z tego co pamiętam to w OBSD dało
się coś z tym zrobić, żeby nie trwało to 3x KEEPALIVE.

Sylwester
PLIX

On 18 Sty, 16:07, Sławek Lipowski <sla...@lipowski.org> wrote:
> Witam,
>
> Na początku postaram się przedstawić ogólny zarys problemu, później
> przejdę do konkretów. No to lecimy...
>
> Dawno dawno temu klient miał ruter na Debianie z Quagga. Dowolna jego
> awaria to był pad Internetu. Jakakolwiek prace przy nim musiała być
> planowana na godziny nocne, ponieważ wiązały się z pewnym lub
> ewentualnym padem dostępu do Internetu.
>
> Problem skończył się, gdy maszyna ta została zastąpiona przez dwie
> maszyny z Quaggą. Do każdego dostawcy są przynajmniej dwie sesje z dwóch
> różnych IP stykowych, jest iBGP między maszynami, jako next hop na
> wszystkich sesjiach BGP do danego dostawcy rozgłaszany jest IP różny od
> tych, z których zestawiane są sesje, i to IP migruje między maszynami
> dzięki VRRP (keepalived). Do tego momentu wszystko jest cacy. Można
> serwisować maszynę wyłączając ją całkowicie, zestaw jest odporny na pad
> jednej z maszyn.
>
> Kilka dni temu pojawił się wątek podpięcia tego układu do PLIXa i
> spotkaliśmy się ze ścianą. Podobnie jak u wszystkich dostawców,
> poprosiliśmy o trzy IPki z klasy stykowej, możliwość spięcia sesji BGP z
> dwóch z nich i rozgłoszenia trzeciego jako next hop. W odpowiedzi
> dowiedzieliśmy się, że pojedynczy port w PLIX to ze względów
> bezpieczeństwa jedno IP i jeden adres MAC.
>
> Stały i pojedynczy adres MAC generuje problem chociażby z VRRP w
> keepalived (brak vmac). Ponadto trzeba by było migrować między maszynami
> nie tylko IP i MAC, ale także i sesje BGP. Zależy nam, żeby przełączenie
> się maszyn nie powodowało zrywania wszystkich sesji BGP z PLIXem.
>
> Z AC-Xem spięliśmy się w ten sposób bez problemu. PLIX zaproponował
> zakupienie 3 portów, żeby mieć 3 adresy IP...
>
> Macie jakieś pomysły, jak to rozwiązać bez generowania nieuzasadnionych
> kosztów? Chcielibyśmy zachować możliwość położenia jednej (dowolnej) z
> maszyn bez degradacji ruchu.
>
> --
> Sławomir Lipowskihttp://lipowski.org

Sądząc po informacji od Sylwestra rozwiązaniem może być dołączenie do
jakiegoś dużego partnera - może do nowego punktu wymiany TPSA? - jak
nie teraz to za 6mc.
Pozdrawiam
Rafał Jackiewicz

On 18 Sty, 19:01, "free...@o2.pl" <free...@o2.pl> wrote:
> On 18 Sty, 16:07, Sławek Lipowski <sla...@lipowski.org> wrote:
>
>
>
>
>
>
>
>
>
> > Witam,
>
> > Na początku postaram się przedstawić ogólny zarys problemu, później
> > przejdę do konkretów. No to lecimy...
>
> > Dawno dawno temu klient miał ruter na Debianie z Quagga. Dowolna jego
> > awaria to był pad Internetu. Jakakolwiek prace przy nim musiała być
> > planowana na godziny nocne, ponieważ wiązały się z pewnym lub
> > ewentualnym padem dostępu do Internetu.
>
> > Problem skończył się, gdy maszyna ta została zastąpiona przez dwie
> > maszyny z Quaggą. Do każdego dostawcy są przynajmniej dwie sesje z dwóch
> > różnych IP stykowych, jest iBGP między maszynami, jako next hop na
> > wszystkich sesjiach BGP do danego dostawcy rozgłaszany jest IP różny od
> > tych, z których zestawiane są sesje, i to IP migruje między maszynami
> > dzięki VRRP (keepalived). Do tego momentu wszystko jest cacy. Można
> > serwisować maszynę wyłączając ją całkowicie, zestaw jest odporny na pad
> > jednej z maszyn.
>
> > Kilka dni temu pojawił się wątek podpięcia tego układu do PLIXa i
> > spotkaliśmy się ze ścianą. Podobnie jak u wszystkich dostawców,
> > poprosiliśmy o trzy IPki z klasy stykowej, możliwość spięcia sesji BGP z
> > dwóch z nich i rozgłoszenia trzeciego jako next hop. W odpowiedzi
> > dowiedzieliśmy się, że pojedynczy port w PLIX to ze względów
> > bezpieczeństwa jedno IP i jeden adres MAC.
>
> > Stały i pojedynczy adres MAC generuje problem chociażby z VRRP w
> > keepalived (brak vmac). Ponadto trzeba by było migrować między maszynami
> > nie tylko IP i MAC, ale także i sesje BGP. Zależy nam, żeby przełączenie
> > się maszyn nie powodowało zrywania wszystkich sesji BGP z PLIXem.
>
> > Z AC-Xem spięliśmy się w ten sposób bez problemu. PLIX zaproponował
> > zakupienie 3 portów, żeby mieć 3 adresy IP...
>
> > Macie jakieś pomysły, jak to rozwiązać bez generowania nieuzasadnionych
> > kosztów? Chcielibyśmy zachować możliwość położenia jednej (dowolnej) z
> > maszyn bez degradacji ruchu.
>
> > --
> > Sławomir Lipowskihttp://lipowski.org
>
> Sądząc po informacji od Sylwestra rozwiązaniem może być dołączenie do
> jakiegoś dużego partnera - może do nowego punktu wymiany TPSA? - jak
> nie teraz to za 6mc.
> Pozdrawiam
> Rafał Jackiewicz

Wydaje mi się że w TPIX sprawa będzie wyglądała tak samo, ale
mogę się mylić ;-)) Robercie ?
Tak czy inaczej PLIX nie jest jedynym punktem wymiany ruchu w naszym
kraju więc można przebierać.

Pozdrawiam

On 18 Sty, 19:17, nastach <n...@plix.pl> wrote:
> On 18 Sty, 19:01, "free...@o2.pl" <free...@o2.pl> wrote:
>
>
>
>
>
>
>
>
>
> > On 18 Sty, 16:07, Sławek Lipowski <sla...@lipowski.org> wrote:
>
> > > Witam,
>
> > > Na początku postaram się przedstawić ogólny zarys problemu, później
> > > przejdę do konkretów. No to lecimy...
>
> > > Dawno dawno temu klient miał ruter na Debianie z Quagga. Dowolna jego
> > > awaria to był pad Internetu. Jakakolwiek prace przy nim musiała być
> > > planowana na godziny nocne, ponieważ wiązały się z pewnym lub
> > > ewentualnym padem dostępu do Internetu.
>
> > > Problem skończył się, gdy maszyna ta została zastąpiona przez dwie
> > > maszyny z Quaggą. Do każdego dostawcy są przynajmniej dwie sesje z dwóch
> > > różnych IP stykowych, jest iBGP między maszynami, jako next hop na
> > > wszystkich sesjiach BGP do danego dostawcy rozgłaszany jest IP różny od
> > > tych, z których zestawiane są sesje, i to IP migruje między maszynami
> > > dzięki VRRP (keepalived). Do tego momentu wszystko jest cacy. Można
> > > serwisować maszynę wyłączając ją całkowicie, zestaw jest odporny na pad
> > > jednej z maszyn.
>
> > > Kilka dni temu pojawił się wątek podpięcia tego układu do PLIXa i
> > > spotkaliśmy się ze ścianą. Podobnie jak u wszystkich dostawców,
> > > poprosiliśmy o trzy IPki z klasy stykowej, możliwość spięcia sesji BGP z
> > > dwóch z nich i rozgłoszenia trzeciego jako next hop. W odpowiedzi
> > > dowiedzieliśmy się, że pojedynczy port w PLIX to ze względów
> > > bezpieczeństwa jedno IP i jeden adres MAC.
>
> > > Stały i pojedynczy adres MAC generuje problem chociażby z VRRP w
> > > keepalived (brak vmac). Ponadto trzeba by było migrować między maszynami
> > > nie tylko IP i MAC, ale także i sesje BGP. Zależy nam, żeby przełączenie
> > > się maszyn nie powodowało zrywania wszystkich sesji BGP z PLIXem.
>
> > > Z AC-Xem spięliśmy się w ten sposób bez problemu. PLIX zaproponował
> > > zakupienie 3 portów, żeby mieć 3 adresy IP...
>
> > > Macie jakieś pomysły, jak to rozwiązać bez generowania nieuzasadnionych
> > > kosztów? Chcielibyśmy zachować możliwość położenia jednej (dowolnej) z
> > > maszyn bez degradacji ruchu.
>
> > > --
> > > Sławomir Lipowskihttp://lipowski.org
>
> > Sądząc po informacji od Sylwestra rozwiązaniem może być dołączenie do
> > jakiegoś dużego partnera - może do nowego punktu wymiany TPSA? - jak
> > nie teraz to za 6mc.
> > Pozdrawiam
> > Rafał Jackiewicz
>
> Wydaje mi się że w TPIX sprawa będzie wyglądała tak samo, ale
> mogę się mylić ;-)) Robercie ?
> Tak czy inaczej PLIX nie jest jedynym punktem wymiany ruchu w naszym
> kraju więc można przebierać.
>
> Pozdrawiam

Polecam:

http://www.tp.pl/b/binaries/PL/358503/_Oferta_TPIX_367107190.pdf

"W ramach jednego Kanału VLAN do Open peering dopuszczany jest jeden
adres MAC
(jedno Urządzenie Operatora). Ramki wysyłane w ramach jednego Kanału
VLAN do Open
peering powinny mieć ten sam adres źródłowy MAC. Dopuszczalne są
oddzielne adresy
MAC dla urządzeń obsługujących protokoły IPv4 oraz IPv6 po uzgodnieniu
z TP. "

obeer pisze:
> ... OBSD ...

OpenBSD jest w zasadzie jednowątkowe, jądro MP czy bez MP będzie mięć tą samą wydajność
( w moich testach kernel Single Procesor i Multi Procesor wypadły identycznie ).
Jeśli użyć OpenBSD do routowania/firewallowania pakietów tarci się
kilkukrotnie na wydajności w porównaniu do linuxa na wieloprocesorowej maszynie.

Testowany pod OpenBSD nat pomiędzy vlanami na jednym interfejsie fizycznym:
Quad-Core AMD Opteron™ Processor 2384
Max 300000 pkts/s jeśli jeden stan na firewallu
Max 138910 pkts/s jeśli milion stanów na firewallu

Podejrzewam, że dla czytelników tej grupy takie osiągnięcie to "żenada" ;) .

-- 
  Pozdrawiam
    Marek Grzybowski

On Jan 19, 10:06 am, Wolodyj <tombo-ma...@o2.pl> wrote:
> obeer pisze:
>
> > ... OBSD ...
>
> OpenBSD jest w zasadzie jednowątkowe, jądro MP czy bez MP będzie mięć tą samą wydajność
> ( w moich testach kernel Single Procesor i Multi Procesor wypadły identycznie ).
> Jeśli użyć OpenBSD do routowania/firewallowania pakietów tarci się
> kilkukrotnie na wydajności w porównaniu do linuxa na wieloprocesorowej maszynie.
>
> Testowany pod OpenBSD nat pomiędzy vlanami na jednym interfejsie fizycznym:
> Quad-Core AMD Opteron(tm) Processor 2384
> Max 300000 pkts/s jeśli jeden stan na firewallu
> Max 138910 pkts/s jeśli milion stanów na firewallu
>
> Podejrzewam, że dla czytelników tej grupy takie osiągnięcie to "żenada" ;) .

Skoro chcesz na routerze robić firewalling, to np. Cisco w wielu
przypadkach zacznie obrabiać ruch procesorem i jego wydajność spadnie
n razy.

Ja dla przykładu przerzucałem pomiędzy vlanami na jednym interfejsie
fizycznym na pIII 600MHz 5 lat temu 600Mbps ruchu pomiędzy powstającym
wtedy PLIXem a WIXem.

I kolejny przykład - nie wiem czy nadal aktualny, ale jak pracowałem w
jednej dużej kablówce lat temu 6 to wszystkie NATy były na OBSD i
kilkanaście tysięcy ludzi za nimi stało.
Nie wiem, czy to temat na tę listę, więc proponuję z tematami "ja mam
większego" przejść na alt.binaries.locomotives ;-)

Na koniec moje przemyślenie: 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.

Sylwester

Wszystko to fajnie brzmi, jak styk jest lokalny po różnych włóknach. Jeśli 
jednak peer jest z innego miasta (a tak jest w tym przypadku) i dochodzi 
jedną trasą, to rozszywanie na osobne fizyczne porty w W-wie jest psu na 
budę i nic nie poprawia w stabilności. Wręcz przeciwnie - wymaga kolokacji 
switcha w W-wie, czyli dodatkowego punktu awarii. Tylko tak transmisja z 
kraju trafiająca do W-wy, może zostać rozszyta na kilka portów.

W opisie nie chodzi o to na czym jest to zrobione. Tylko o to, by w ramach i 
tak jednej fizycznej transmisji mieć redundancję 2 routerów BGP.

Podobnie działają PLIXowe routery .99 i .100. Są słownie: dwa i oba dostępne 
z punktu widzenia uczestnika węzła via słownie: jeden port właśnie po to, by 
awaria lub serwis jednego z nich, nie kładły wszystkiego.

To, o czym pisze Sławek, to nic więcej, tylko wariant tego samego 
rozwiązania, ale od strony uczestnika węzła. Można dyskustować o 
implementacji, itd. Ale ja też mając od lat 2 routery BGP - mam zapięte 2 
komplety sesji BGP do tych dostawców nadrzędnych, z którymi taką redundancję 
uznałem za wskazaną.

A odniesieniom do AMSIX'a można przeciwstawić inne zapisy z innych IXów. 
Tylko co to zmieni w tej dyskusji?

Pozdrawiam,

-- 
---
Zboj (Piotr Marciniak)
   zboj \at/ mnc.pl 

On 19-01-11 14:57, Zboj wrote:
> Podobnie działają PLIXowe routery .99 i .100. Są słownie: dwa i oba dostępne 
> z punktu widzenia uczestnika węzła via słownie: jeden port właśnie po to, by 
> awaria lub serwis jednego z nich, nie kładły wszystkiego.

AFAIK są to dwie różne maszyny na dwóch różnych fizycznych portach.

> To, o czym pisze Sławek, to nic więcej, tylko wariant tego samego 
> rozwiązania, ale od strony uczestnika węzła. Można dyskustować o 
> implementacji, itd. Ale ja też mając od lat 2 routery BGP - mam zapięte 2 
> komplety sesji BGP do tych dostawców nadrzędnych, z którymi taką redundancję 
> uznałem za wskazaną.

Nieprawda.

> A odniesieniom do AMSIX'a można przeciwstawić inne zapisy z innych IXów. 
> Tylko co to zmieni w tej dyskusji?

To pokaż te zapisy z innych IXów. Ja nie znam żadnego IX, a należę do
ponad 20, gdzie by dopuszczali takie zabawy w wirtualne IP.

-- 
Grzegorz Janoszka

W dniu 11-01-18 16:07, Sławek Lipowski pisze:
> Witam,
> 
> Na początku postaram się przedstawić ogólny zarys problemu, później
> przejdę do konkretów. No to lecimy...
> 
> Dawno dawno temu klient miał ruter na Debianie z Quagga. Dowolna jego
> awaria to był pad Internetu. Jakakolwiek prace przy nim musiała być
> planowana na godziny nocne, ponieważ wiązały się z pewnym lub
> ewentualnym padem dostępu do Internetu.
> 
> Problem skończył się, gdy maszyna ta została zastąpiona przez dwie
> maszyny z Quaggą. Do każdego dostawcy są przynajmniej dwie sesje z dwóch
> różnych IP stykowych, jest iBGP między maszynami, jako next hop na
> wszystkich sesjiach BGP do danego dostawcy rozgłaszany jest IP różny od
> tych, z których zestawiane są sesje, i to IP migruje między maszynami
> dzięki VRRP (keepalived). Do tego momentu wszystko jest cacy. Można
> serwisować maszynę wyłączając ją całkowicie, zestaw jest odporny na pad
> jednej z maszyn.
> 
> Kilka dni temu pojawił się wątek podpięcia tego układu do PLIXa i
> spotkaliśmy się ze ścianą. Podobnie jak u wszystkich dostawców,
> poprosiliśmy o trzy IPki z klasy stykowej, możliwość spięcia sesji BGP z
> dwóch z nich i rozgłoszenia trzeciego jako next hop. W odpowiedzi
> dowiedzieliśmy się, że pojedynczy port w PLIX to ze względów
> bezpieczeństwa jedno IP i jeden adres MAC.
> 
> Stały i pojedynczy adres MAC generuje problem chociażby z VRRP w
> keepalived (brak vmac). Ponadto trzeba by było migrować między maszynami
> nie tylko IP i MAC, ale także i sesje BGP. Zależy nam, żeby przełączenie
> się maszyn nie powodowało zrywania wszystkich sesji BGP z PLIXem.
> 
> Z AC-Xem spięliśmy się w ten sposób bez problemu. PLIX zaproponował
> zakupienie 3 portów, żeby mieć 3 adresy IP...
> 
> Macie jakieś pomysły, jak to rozwiązać bez generowania nieuzasadnionych
> kosztów? Chcielibyśmy zachować możliwość położenia jednej (dowolnej) z
> maszyn bez degradacji ruchu.
> 

Może nie wniosę dużo do wątku, ale jakiś czas temu ostro testowałem
Vyatte pod BGP właśnie.
Ona pozwalała na to, żeby obie maszynki po vrrp gadały po adresach
prywatnych a virtual IP miały rzeczywisty i tak samo mac...

A Vyatta to nic innego jak linux i quagga, prawda ? :)


Pozdrawiam

>> Podobnie działają PLIXowe routery .99 i .100. Są słownie: dwa i oba 
>> dostępne
>> z punktu widzenia uczestnika węzła via słownie: jeden port właśnie po to, 
>> by
>> awaria lub serwis jednego z nich, nie kładły wszystkiego.
>
> AFAIK są to dwie różne maszyny na dwóch różnych fizycznych portach.

Od strony uczestnika PLIX'a? Żartujesz? Nie doczytałeś? Jak kupuję 1 port w 
PLIX, to cokolwiek jest dalej w sieci Sylwka, ja oba jego routery widzę 
przez 1 port, który wykupiłem. Wiesz - w tym kontekście każdy z nas mając 
dwa swoje routery, też przecież ma je wpięte do jakichś dwóch gniazdek.

>> To, o czym pisze Sławek, to nic więcej, tylko wariant tego samego
>> rozwiązania, ale od strony uczestnika węzła. Można dyskustować o
>> implementacji, itd. Ale ja też mając od lat 2 routery BGP - mam zapięte 2
>> komplety sesji BGP do tych dostawców nadrzędnych, z którymi taką 
>> redundancję
>> uznałem za wskazaną.
>
> Nieprawda.

Wypowiadasz się o mojej konfiguracji? Ciekawe. Adminujesz u mnie, bo nie 
kojarzę? Troszkę się rozpędziłeś.

>> A odniesieniom do AMSIX'a można przeciwstawić inne zapisy z innych IXów.
>> Tylko co to zmieni w tej dyskusji?
>
> To pokaż te zapisy z innych IXów. Ja nie znam żadnego IX, a należę do
> ponad 20, gdzie by dopuszczali takie zabawy w wirtualne IP.

Jeśli zmuszę się do ich przejrzenia i znajdę - to coś to zmieni w polityce 
PLIX'a? Albo nie wiem - spotka mnie z tego powodu jakaś gratyfikacja?

-- 
---
Zboj (Piotr Marciniak)
   zboj \at/ mnc.pl 

On 19 Sty, 16:06, Grzegorz Janoszka <Grzeg...@nie-lubie-
spamu.Janoszka.pl> wrote:
> On 19-01-11 14:57, Zboj wrote:
>
> > Podobnie działają PLIXowe routery .99 i .100. Są słownie: dwa i oba dostępne
> > z punktu widzenia uczestnika węzła via słownie: jeden port właśnie po to, by
> > awaria lub serwis jednego z nich, nie kładły wszystkiego.
>
> AFAIK są to dwie różne maszyny na dwóch różnych fizycznych portach.
>
> > To, o czym pisze Sławek, to nic więcej, tylko wariant tego samego
> > rozwiązania, ale od strony uczestnika węzła. Można dyskustować o
> > implementacji, itd. Ale ja też mając od lat 2 routery BGP - mam zapięte 2
> > komplety sesji BGP do tych dostawców nadrzędnych, z którymi taką redundancję
> > uznałem za wskazaną.
>
> Nieprawda.
>
> > A odniesieniom do AMSIX'a można przeciwstawić inne zapisy z innych IXów.
> > Tylko co to zmieni w tej dyskusji?
>
> To pokaż te zapisy z innych IXów. Ja nie znam żadnego IX, a należę do
> ponad 20, gdzie by dopuszczali takie zabawy w wirtualne IP.
>
> --
> Grzegorz Janoszka

Otóż Piotr Marciniak idealnie podsumował sytuację - taki jest stan
faktyczny. Celne podsumowanie.

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łą). 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).

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 wpiête 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".
PLIX miał być rodzajem "głównego" łącza. Taki był plan, ponieważ to
jest PLIX! Niestety, tak nie może być. 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ę.

Pozdrawiam
Rafał Jackiewicz

On 19 Sty, 21:34, "free...@o2.pl" <free...@o2.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 wpiête 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

On 19 Sty, 21:52, nastach <n...@plix.pl> wrote:
> On 19 Sty, 21:34, "free...@o2.pl" <free...@o2.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 wpiête 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,
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ą.

Pozdrawiam
Rafał

> "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

On 19-01-11 21:34, freebsd@o2.pl wrote:
> 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łą). 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).

Oczywiście. 20 lub 200 firm hurtowni dostarcza jabłka zielone, żółte i
czerwone. A gdzie przychylenie się do potrzeb partnerów w interesach? A
gdzie wolny rynek? Ja chcę niebieskie jabłka! Albo choć czarne!
20 czy 200 ISP dostarcza protokół IP. A czemu nie przychylą się i nie
dostarczą IPX albo DECnet? Ja tak chcę!

> Nie rozumiem postawy "gdzie to jest wpiête 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".
> PLIX miał być rodzajem "głównego" łącza. Taki był plan, ponieważ to
> jest PLIX! Niestety, tak nie może być. 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 :-)))

No tak, pomyliłeś raczej usługi. Punkt wymiany ruchu nie może być
"głównym łączem". No to teraz doceń ten wolny rynek, zalej go powodzią
pomysłów, rozpoznaj potrzeby klientów i udziel wsparcia specjalistów.
Sieci będą walić drzwiami i oknami, żeby się podłączyć do tego nowego
wspaniałego IX, który będzie tak interaktywny z klientami, że nawet TPSA
się przyłączy.

Żaden szanujący się punkt wymiany ruchu na świecie nie bawi się w jakiś
wirtualne adresy szalejące między quaggami. Jak TPSA podchodzi poważnie
do swojej usługi i będzie chciała wyjść poza horyzont "Stasiu i Jasiu
zrobili osiedlówkę na pececie z linuksem", to też ustali jasne i
konkretne zasady i będziesz miał kolejny powód do marudzenia.

-- 
Grzegorz Janoszka

On 19 Sty, 23:49, Grzegorz Janoszka <Grzeg...@nie-lubie-
spamu.Janoszka.pl> wrote:
> On 19-01-11 21:34, free...@o2.pl wrote:
>
> > 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łą). 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).
>
> Oczywiście. 20 lub 200 firm hurtowni dostarcza jabłka zielone, żółte i
> czerwone. A gdzie przychylenie się do potrzeb partnerów w interesach? A
> gdzie wolny rynek? Ja chcę niebieskie jabłka! Albo choć czarne!
> 20 czy 200 ISP dostarcza protokół IP. A czemu nie przychylą się i nie
> dostarczą IPX albo DECnet? Ja tak chcę!
>
> > Nie rozumiem postawy "gdzie to jest wpiête 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".
> > PLIX miał być rodzajem "głównego" łącza. Taki był plan, ponieważ to
> > jest PLIX! Niestety, tak nie może być. 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 :-)))
>
> No tak, pomyliłeś raczej usługi. Punkt wymiany ruchu nie może być
> "głównym łączem". No to teraz doceń ten wolny rynek, zalej go powodzią
> pomysłów, rozpoznaj potrzeby klientów i udziel wsparcia specjalistów.
> Sieci będą walić drzwiami i oknami, żeby się podłączyć do tego nowego
> wspaniałego IX, który będzie tak interaktywny z klientami, że nawet TPSA
> się przyłączy.
>
> Żaden szanujący się punkt wymiany ruchu na świecie nie bawi się w jakiś
> wirtualne adresy szalejące między quaggami. Jak TPSA podchodzi poważnie
> do swojej usługi i będzie chciała wyjść poza horyzont "Stasiu i Jasiu
> zrobili osiedlówkę na pececie z linuksem", to też ustali jasne i
> konkretne zasady i będziesz miał kolejny powód do marudzenia.
>
> --
> Grzegorz Janoszka

Dziwi mnie ten napastliwy ton. Chcesz jabłka niebieskie - spytaj się
chińczyków - załatwią :-)
Kiedyś nie było punktów wymiany - co to musiał być za szalony pomysł
dla dużych ISP! Teraz są.
Tak pracuję głównie na otwartym oprogramowaniu - dla mnie to nie jest
powód do wstydu. Tak, zajmuje się nieraz małymi klientami - z
nadzieją, że nadal będziemy współpracować jak będą więksi. Nie mam
kompleksów związanych z tym.

Pozdrawiam
Rafał Jackiewicz

W dniu 2011-01-19 22:24, freebsd@o2.pl pisze:
> "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ą.

Sam pomysł VRRP na styku z BGP jest wg mnie dziwnym wynalazkiem.
Czemu nie 2 komplety sesji BGP z kazdym z routerow uniknie sie zbednych 
announce/withdrawn z BGP i braku dostepnosci na czas renegocjacji sesji ?

Ten schemat moznaby powtorzych na kazdym z laczy, a poza tym rownie 
dobrze backup moze dzialac na zasadzie ze lacza A jest na routerze A, 
lacze B na routerze B i trzymac na kazdym z nich taki komplet ktory 
zapeniw odpowiedni komplet sciezek i jednoczesnie wydajnosc na wypadek 
padu routera. To w czasach 95% chyba nie jest zbytnio trudne :P

Pozdrawiam

-- 
Bartosz Waszak <waszi@tiberium.co.il>
nic-hdl: BW1026-RIPE

On 19 Sty, 23:57, "free...@o2.pl" <free...@o2.pl> wrote:
> Dziwi mnie ten napastliwy ton. Chcesz jabłka niebieskie - spytaj się
> chińczyków - załatwią :-)
> Kiedyś nie było punktów wymiany - co to musiał być za szalony pomysł
> dla dużych ISP! Teraz są.
> Tak pracuję głównie na otwartym oprogramowaniu - dla mnie to nie jest
> powód do wstydu. Tak, zajmuje się nieraz małymi klientami - z
> nadzieją, że nadal będziemy współpracować jak będą więksi. Nie mam
> kompleksów związanych z tym.
Ale czy ktoś mówi że open source jest złe, RS'y w IX'ach głównie się
opierają
na BIRD, OpenBGPD czy Quagga. Każdy klient jest tak samo istotny ten
co robi
20Gbps ruchu i ten co robi 10Mbps, ważne żeby zrozumiał pewne zasady.
Najgorzej jak ten co robi 10Mbps ma większe wymagania niż ten co co
robi
20Gbps ...
Czasami może lepiej przemyśleć swoją postawę niż krytykować
innych ;-))

On 19 Sty, 23:17, nastach <n...@plix.pl> wrote:
> > "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

Nie krzyczę. Czytam uważnie posty starając się zrozumieć wszelkie
racje. Nigdzie nie napisałem, że się ktoś myli. Jak rozumiem
koresponduję z pracownikami PLIXa - i to jest wspaniałe: bezpośredni
dostęp do osób technicznych.
Staram się przedstawić problem - oczekując merytorycznej dyskusji.
"Drogi przyszły/niedoszły kliencie." - sam jestem "techniczny",
rozumiem i doceniam dowcip :-) Jednak wydźwięk korespondencji można by
troszkę stonować. Chcemy kupić jeden port. 1000zł. Mało? Dużo? Zapewne
zależy dla kogo. Ja chciał bym dostawać 1000zł więcej na mój business.
Nie dopuścił bym do lekceważenia klienta - nawet jeśli go prv. nie
specjalnie lubię. Nastach - pracujesz w firmie i zapewne fajnie by
było gdyby się ona rozwijała? Do tego trzeba oprócz podejścia
"technicznego" i zapewne dużej wiedzy informatycznej dodać odrobinę
marketingu :-)
Pozdrawiam
Rafał

On 20 Sty, 00:05, nastach <n...@plix.pl> wrote:
> On 19 Sty, 23:57, "free...@o2.pl" <free...@o2.pl> wrote:> Dziwi mnie ten napastliwy ton. Chcesz jabłka niebieskie - spytaj się
> > chińczyków - załatwią :-)
> > Kiedyś nie było punktów wymiany - co to musiał być za szalony pomysł
> > dla dużych ISP! Teraz są.
> > Tak pracuję głównie na otwartym oprogramowaniu - dla mnie to nie jest
> > powód do wstydu. Tak, zajmuje się nieraz małymi klientami - z
> > nadzieją, że nadal będziemy współpracować jak będą więksi. Nie mam
> > kompleksów związanych z tym.
>
> Ale czy ktoś mówi że open source jest złe, RS'y w IX'ach głównie się
> opierają
> na BIRD, OpenBGPD czy Quagga. Każdy klient jest tak samo istotny ten
> co robi
> 20Gbps ruchu i ten co robi 10Mbps, ważne żeby zrozumiał pewne zasady.
> Najgorzej jak ten co robi 10Mbps ma większe wymagania niż ten co co
> robi
> 20Gbps ...
> Czasami może lepiej przemyśleć swoją postawę niż krytykować
> innych ;-))
Ok, wezmę to pod uwagę :-)
Rafał

On 19 Sty, 22:24, "free...@o2.pl" <free...@o2.pl> wrote:
> On 19 Sty, 21:52, nastach <n...@plix.pl> wrote:
>
>
>
>
>
> > On 19 Sty, 21:34, "free...@o2.pl" <free...@o2.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 wpiête 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

On 20 Sty, 00:14, obeer <sylwester.bierna...@gmail.com> wrote:
> On 19 Sty, 22:24, "free...@o2.pl" <free...@o2.pl> wrote:
>
>
>
>
>
> > On 19 Sty, 21:52, nastach <n...@plix.pl> wrote:
>
> > > On 19 Sty, 21:34, "free...@o2.pl" <free...@o2.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 wpiête 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

Kurcze - bardzo dziękuję za konkretną odpowiedź. To jest wystarczające
dla mnie. Już powoli traciłem nadzieję na merytoryczną dyskusję.
Pozdrawiam serdecznie
Rafał Jackiewicz

On 20 Sty, 00:07, "free...@o2.pl" <free...@o2.pl> wrote:
> On 19 Sty, 23:17, nastach <n...@plix.pl> wrote:
>
>
>
>
>
> > > "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
>
> Nie krzyczę. Czytam uważnie posty starając się zrozumieć wszelkie
> racje. Nigdzie nie napisałem, że się ktoś myli. Jak rozumiem
> koresponduję z pracownikami PLIXa - i to jest wspaniałe: bezpośredni
> dostęp do osób technicznych.
> Staram się przedstawić problem - oczekując merytorycznej dyskusji.
> "Drogi przyszły/niedoszły kliencie." - sam jestem "techniczny",
> rozumiem i doceniam dowcip :-) Jednak wydźwięk korespondencji można by
> troszkę stonować. Chcemy kupić jeden port. 1000zł. Mało? Dużo? Zapewne
> zależy dla kogo. Ja chciał bym dostawać 1000zł więcej na mój business.


Drogi Rafale (jeśli mogę po imieniu oczywiście)

   Nie traktuj postów nastacha obrazliwie, nastach pisze o ogólnych
problemach ludzkości z uwzględnieniem polskich realiów. W wielu
wypadkach klienci korzystający z 100-200Mbps wymiany w PLIXie mają
wymagania dużo wyższe mi ż operatorzy wpięci 10Gbps. Szanujemy
wszystkich klientów i tak samo pomagamy takim co maja 100Mbps jak i
40Gbps. To nasze zadanie - pomagać wszystkim ucestnikom PLIXa, którzy
tego potrzebują.

Zapytaj naszych klientów jak to działa, a najlepiej zostań nawet
testowo i się przekonaj sam.
Jestem przekonany, że nie będziesz zawiedziony :)

Co do dyskusji merytorycznej, uważam, że jest ona potrzebna, dzięki
temu możemy rozwijać PLIXa, ale zawsze musimy mieć na względzie fakt,
że to naprawdę kawał polskiego internetu i nie możemy sobie lekceważyć
kwestii bezpieczeństwa całego węzła. I tak jak wspomniałem w
poprzednim poście, przychylamy się do wielu pomysłów, o ile nie
uderzają one w całego PLIXa

Sylwester

Dnia 18.01.2011 Sławek Lipowski <slawek@lipowski.org> napisał/a:
> Dawno dawno temu klient miał ruter na Debianie z Quagga. Dowolna jego 
> awaria to był pad Internetu. Jakakolwiek prace przy nim musiała być 
> planowana na godziny nocne, ponieważ wiązały się z pewnym lub 
> ewentualnym padem dostępu do Internetu.
>
> Problem skończył się, gdy maszyna ta została zastąpiona przez dwie 
> maszyny z Quaggą. Do każdego dostawcy są przynajmniej dwie sesje z dwóch 
> różnych IP stykowych, jest iBGP między maszynami, jako next hop na 
> wszystkich sesjiach BGP do danego dostawcy rozgłaszany jest IP różny od 
> tych, z których zestawiane są sesje, i to IP migruje między maszynami 
> dzięki VRRP (keepalived). Do tego momentu wszystko jest cacy. Można 
> serwisować maszynę wyłączając ją całkowicie, zestaw jest odporny na pad 
> jednej z maszyn.
>
> Kilka dni temu pojawił się wątek podpięcia tego układu do PLIXa i 
> spotkaliśmy się ze ścianą. Podobnie jak u wszystkich dostawców, 
> poprosiliśmy o trzy IPki z klasy stykowej, możliwość spięcia sesji BGP z 
> dwóch z nich i rozgłoszenia trzeciego jako next hop. W odpowiedzi 
> dowiedzieliśmy się, że pojedynczy port w PLIX to ze względów 
> bezpieczeństwa jedno IP i jeden adres MAC.
Ja to powiem tak.

Jestem w podobnej sytuacji. 2 routery na linuksie, z quagga. Co prawda inna
dystrybucja, ale to znaczenia nie ma. Kilka lacz, w tym 2 IX-y.

Przez dlugi czas zastanawialem sie czy nie zaprzac do tego wszystkiego vrrp.
Ale doszedlem do wniosku ze pomysl jest bez sensu.

Bo przeciez:
- moje routerki nie padaja. Zbyt czesto.
- lacza ktore mam nie padaja. Zbyt czesto.

Jak lacze padnie - na drugim routerze musze zapewnic dzialanie calej sieci. Jak
nie zapewnie - jest zonk.  Jak router padnie - jak wyzej. Przy czym pad lacza
zdarza sie czesciej niz pad routera. Jak router pada - to go wymieniam by nie
padal. A prace serwisowe poprzedzam ip neigh XXX shutdown ;)

W ten sam sposob zakladam ze plix, jako kolejne moje lacze moze pasc. I
nieplanowany pad plixa zdarzy sie czesciej niz nieplanowany pad mojego routera.
Wiec - zabawy w vrrp u mnie na styku do plixa maja sredni sens.


A teraz spojrzmy z drugiej strony. Chlopaki z PLIX-a staraja sie utrzymac
dzialanie PLIX-a. Dopuszczanie do tego by klient zaczal im siac kilkoma macami
- moze doprowadzic do tego ze zrobi jakas brzydka petelke - ergo plix
przestanie dzialac. I dla mnie, jako zadowolonego klienta plixa, ktorym
otrzymuje obecnie jakies 35% ruchu bardziej liczy sie to ze ten ruch bedzie
"prawie zawsze" niz to ze plix bedzie miec jednego klienta wiecej ktory
podwyzszy moj download na plixie o 1%.


> Z AC-Xem spięliśmy się w ten sposób bez problemu. PLIX zaproponował 
> zakupienie 3 portów, żeby mieć 3 adresy IP...
acx w l3? czy l2? Jezeli l3 - ma zasieg lokalny przeciez. Wiec potencjalny
problem by dotyczyl tylko Twojego wezla.

> Macie jakieś pomysły, jak to rozwiązać bez generowania nieuzasadnionych 
> kosztów? Chcielibyśmy zachować możliwość położenia jednej (dowolnej) z 
> maszyn bez degradacji ruchu.
moze wsadzic osobny router w plixie? jakas puszke 1U zdolna uciagnac ruch jaki
macie do plixa - a miedzy nim a Twoimi dwoma routerami bawic sie w ulepszanie
bgp? :)

-- 
Andrzej 'The Undefined' Dopierała
HomePage: http://andrzej.dopierala.name/
Reprezentuję siebie i wyrażam tylko moje zdanie!

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

> Czemu nie 2 komplety sesji BGP z kazdym z routerow uniknie sie zbednych 
> announce/withdrawn z BGP i braku dostepnosci na czas renegocjacji sesji ?

W wariancie PLIXowym - 1 IP/MAC na port, gdy masz dysył z kraju, a nie 
kabelkologię w PLIX DC, to co proponujesz też jest nie do zrobienia - chyba 
że kolokując dod. switcha w PLIX DC, ale czemu to bez sensu - już opisałem. 
Mimo wygłoszonej tutaj deklaracji o otwartości - PLIX ma swoje maniery i 
priorytety. Czasem nawet nie maskowane regulaminem, a zwykłym - nie, bo nie.

Ale merytorycznie - niezależnie od oceny rozwiązania z VRRP - wariant 2 
sesji BGP na porcie do 1 odbiorcy, który spełniłby i Twoją propozycję i 
pewnie w jakimś sensie oczekiwania Rafała, wymagałby akceptacji 2 IP i 2 MAC 
na porcie. Trudno mi sobie wytłumaczyć, czym 2 pary mac-ip naruszają 
bezpieczeństwo względem 1 pary. Szczególnie, że w akceptowanej przez PLIX'a 
wersji, można wsadzić do PLIX DC switcha, zapiąć 2 pary portów i i tak zbić 
to później na 1 switchu wysyłając jakąś transmisją poza W-wę. W praktyce - 
dosył do W-wy i tak pozostanie 1, a transmisje zmiksują się w 1 transmisji, 
a później w 1 serwerowni odbiorcy. Dokłądnie tak samo, jak w 1 podsieci są 
obydwa routery PLIXowe. Takie 2 pary są więc bardzo dalekie od dramatycznej 
retoryki Sylwka o wpuszczaniu wszystkiego i braku filtrów na cokolwiek. No 
ale dramatyzm oświadczenia, zaklinanie się na bezpieczeństwo i eskalacja 
potencjalnych problemów, pozwalają na uduszenie przeciwnika i jego 
argumentacji. Kompletnie rpzy tym nie próbując wyjaśnić, co dokładnie np. 2 
pary ip-mac na porcie mogą nabroić, że należy ich tak kategorycznie zakazać. 
Wedle mojej skromnej wiedzy "nie popartej sesjami z 20 IXami" - ryzyko jest 
dokładnie takie samo, jak przy 1 parze ip-mac. Oczywiście pod warunkiem 
zachowania dokładnie takiej samej konfiguracji bezpieczeńśtwa w zakresie 
innych filtrów.

I poważnie. Zamiast demagogii, że to może wywalić "kawał polskiego 
Internetu", chciałbym przeczytać - w jaki sposób.

Pozdrawiam,

-- 
---
Zboj (Piotr Marciniak)
   zboj \at/ mnc.pl 

Dnia Wed, 19 Jan 2011 15:20:47 -0800, freebsd@o2.pl napisał(a):
/../
> Kurcze - bardzo dziękuję za konkretną odpowiedź. To jest wystarczające
> dla mnie. Już powoli traciłem nadzieję na merytoryczną dyskusję.
> Pozdrawiam serdecznie
> Rafał Jackiewicz

Profesjonalnie to cytaty tnij.

On 20 Sty, 20:16, Smok Eustachy <smok.eusta...@wurg.pl> wrote:
> Dnia Wed, 19 Jan 2011 15:20:47 -0800, free...@o2.pl napisał(a):
> /../
>
> > Kurcze - bardzo dziękuję za konkretną odpowiedź. To jest wystarczające
> > dla mnie. Już powoli traciłem nadzieję na merytoryczną dyskusję.
> > Pozdrawiam serdecznie
> > Rafał Jackiewicz
>
> Profesjonalnie to cytaty tnij.

Zgłoś zażalenie do Gogola.
Rafał

nastach wrote:

> Najgorzej jak ten co robi 10Mbps ma większe wymagania niż ten co co
> robi 20Gbps ...

Ale to jest pewna prawidłowość zwana Pareto - 20% klientów generuje 80% 
problemów.
;-)

-- 
Ślązak 

W dniu 2011-01-21 12:44, Tomasz Śląski pisze:
> nastach wrote:
>
>> Najgorzej jak ten co robi 10Mbps ma większe wymagania niż ten co co
>> robi 20Gbps ...
>
> Ale to jest pewna prawidłowość zwana Pareto - 20% klientów generuje 80%
> problemów.
> ;-)
>
ale za to 20% klientów generuje 80% zysku

to w sumie sie wyrównuje ;-)

On Fri, 21 Jan 2011 13:17:39 +0100, Ziolko napisał:
> W dniu 2011-01-21 12:44, Tomasz Śląski pisze:
>> nastach wrote:
>>
>>> Najgorzej jak ten co robi 10Mbps ma większe wymagania niż ten co co
>>> robi 20Gbps ...
>>
>> Ale to jest pewna prawidłowość zwana Pareto - 20% klientów generuje 80%
>> problemów.
>> ;-)
>>
> ale za to 20% klientów generuje 80% zysku
>
> to w sumie sie wyrównuje ;-)

Tyle że to nie Ci sami ;-)
Generalnie, cytując klasyka: "klient w krawacie jest mniej awanturującym się"


-- 
#begin 755 signature.exe
[tomek <at> sikornik <dot> net]                             vy 73! de SP9UOB
Proud to be 100 percent microsoft free.                            op. Tomek

W dniu 2011-01-21 13:17, Ziolko pisze:

>> Ale to jest pewna prawidłowość zwana Pareto - 20% klientów generuje 80%
>> problemów.
>> ;-)
>>
> ale za to 20% klientów generuje 80% zysku
>
> to w sumie sie wyrównuje ;-)

Oba zbiory są rozłączne.

> I poważnie. Zamiast demagogii, że to może wywalić "kawał polskiego 
> Internetu", chciałbym przeczytać - w jaki sposób.

I jak to zazwyczaj bywa - postawienie konkretnego pytania zwyczajowo zamyka 
dyskusje demagogów.


-- 
---
Zboj (Piotr Marciniak)
   zboj \at/ mnc.pl 

On Jan 20, 6:56 pm, "Zboj" <zboj_...@mnc.dot.pl> wrote:

> Mimo wyg oszonej tutaj deklaracji o otwarto ci - PLIX ma swoje maniery i
> priorytety. Czasem nawet nie maskowane regulaminem, a zwyk ym - nie, bo nie.

Bardzo lubię takie wypowiedzi - to tak jak w PiSie - rzucasz tekst,
sam tylko wiedząc o co w nim chodzi.
Pewnie też masz swoją prawdę i ona jest najTwojsza :P


> Ale merytorycznie - niezale nie od oceny rozwi zania z VRRP - wariant 2
> sesji BGP na porcie do 1 odbiorcy, kt ry spe ni by i Twoj propozycj i
> pewnie w jakim sensie oczekiwania Rafa a, wymaga by akceptacji 2 IP i 2 MAC
> na porcie. Trudno mi sobie wyt umaczy , czym 2 pary mac-ip naruszaj
> bezpiecze stwo wzgl dem 1 pary.

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.
Nigdy nie zdarzyło Ci się, żeby klienci mając na końcu switcha
zapinali sobie dwa kabelki jeden w drugi i robili pętle?

http://www.mnc.pl/aktualnosci/regulamin/
§ 5, pkt. 9
Administrator zablokuje publiczne IP w przypadku wystąpienia
zagrożenia sieci związanego z przyznanym publicznym IP, w
szczególności w przypadku: a. udokumentowanych prób włamań na
komputery w sieci MNC lub w Internecie lub podobnej działalności, np.
skanowania sieci i innych działań mogących stanowić przygotowanie do
włamania;
odnotowania rozpowszechniania z danego IP sprzecznej z prawem treści,
w tym spamu, nielegalnego oprogramowania, itp;
udostępniania w oparciu o przyznane IP zasobów innych komputerów i
urządzeń sieci MNC, które nie posiadają własnych adresów publicznych;
stwierdzenia braku zabezpieczeń komputera, o których mowa w pkt. 4;
odnotowania uporczywych prób włamań z Internetu na przyznany
Abonentowi adres publiczny;
odnotowania faktu blokady klas adresowych sieci MNC na serwerach
wewnętrznych w oparciu o działania danego Abonenta w sieci;
innych działań naruszających bezpieczeństwo Abonentów, sieci lub normy
prawne.
W podanych wyżej sytuacjach, Administrator może odmówić odblokowania
lub powtórnego przyznania publicznego IP danemu Abonentowi.


> Takie 2 pary s wi c bardzo dalekie od dramatycznej
> retoryki Sylwka o wpuszczaniu wszystkiego i braku filtr w na cokolwiek. No
> ale dramatyzm o wiadczenia, zaklinanie si na bezpiecze stwo i eskalacja
> potencjalnych problem w, pozwalaj na uduszenie przeciwnika i jego
> argumentacji.

Piotrze, ty chyba żyjesz w innym świecie niż reszta ludzi. Uważasz, że
wszyscy chcą robić Ci na złość?
Rozumiem, że chcesz na siłę pokazać, że ktoś Ci broni takiego
rozwiązania jakiego byś sobie życzył?

to ja też pozwolę sobie pomarzyć:
W .pl można przekroczyć prędkość o 10km/h, w .se tylko o 1km/h i za to
oberwać mandat.
Co za paskudni Szwedzi, że tak chcą karać. Ja bym chciał, żeby dało
się podróżować autostradami bez limitu.



Kompletnie rpzy tym nie pr buj c wyja ni , co dok adnie np. 2
> pary ip-mac na porcie mog nabroi , e nale y ich tak kategorycznie zakaza .
> Wedle mojej skromnej wiedzy "nie popartej sesjami z 20 IXami" - ryzyko jest
> dok adnie takie samo, jak przy 1 parze ip-mac. Oczywi cie pod warunkiem
> zachowania dok adnie takiej samej konfiguracji bezpiecze twa w zakresie
> innych filtr w.

A wg nas ryzyko jest dużo wyższe, przy 1 macu możemy je praktycznie
wykluczyć.
Jeśli klient wepnie się 2 portami i będzie miał po 1 różnym
macaddressie na każdym, to w przypadku wykrycia pętli switch zablokuje
jego port lub zdropuje ruch z danego portu.
W przypadku gdy mamy 2 macaddressy na jednym porcie, wykrycie pętli i
zablokowanie ruchu z niego jest dużo trudniejsze.

Masz rację co do jednego: robimy to dla naszej wygody i upieramy się,
że nasze rozwiązanie jest bezpieczne.
Mamy do tego prawo, tak samo jak Ty do krytykowania tego podejścia.

I nie raz zmieniamy nasze podejście do różnych spraw, aby być bardziej
użyteczni dla naszych uczestników.
Pewnie i to podejście się kiedyś zmieni (tylko krowa nie zmienia
zdania), ale na razie ze względów technicznych i przyjętej polityki
bezpieczeństwa stosujemy się do tego co krytykujesz.

Zastanów się, proszę, czy gdybyś był na naszym miejscu, to byś tak
łatwo i beztrosko pozwalał wszystkim na robienie czego sobie chcą.
Pewnie może i kiedyś tak było u Ciebie, u nas kiedyś również. Jednakże
życie nauczyło nas tego, że musimy dbać o dobro naszych uczestników, a
większość operatorów chce takiej polityki ze względu na swoje
bezpieczeństwo.


Sylwester

>> Mimo wyg oszonej tutaj deklaracji o otwarto ci - PLIX ma swoje maniery i
>> priorytety. Czasem nawet nie maskowane regulaminem, a zwyk ym - nie, bo 
>> nie.

>Bardzo lubię takie wypowiedzi - to tak jak w PiSie - rzucasz tekst,
sam tylko wiedząc o co w nim chodzi.
>Pewnie też masz swoją prawdę i ona jest najTwojsza :P

Nawzajem... Przy czym w tym wypadku dokładnie obaj wiemy, o czym piszę. + 
jakichś 150 operatorów. Ale to OT w tym wątku.

> 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.

>Nigdy nie zdarzyło Ci się, żeby klienci mając na końcu switcha
zapinali sobie dwa kabelki jeden w drugi i robili pętle?

Widziałem sytuacje, w których następiło zwarcie TX z RX w uszkodzonym 
switchu, czy kompie 1 usera. Myślisz, że filtry 1 MAC'a cokolwiek pomogły? A 
pętle opisane przez Ciebie po prostu downują mi port do usera w switchu 
accessowym kompletnie z pominięciem limitów mac/port. Tyle, że w mojej 
lokalnej małej sieci mogę wykorzystać np. rstp, stormy i wykrywanie pętli. 
Możliwości zależą od sprzętu i softu. Oraz oczywiście od polityki styków z 
innymi operatorami. Masz inną perspektywę na pewno. Choć jeśli zapinam np. 
odbiorcę biznesowego z jego siecią, routerami itd, to w pewnym sensie mam 
podobne do PLIXowych problemy - bo są to dla mnie obce sieci.

> http://www.mnc.pl/aktualnosci/regulamin/

Mój stary regulamin dla userów domowych znam. Co to wnosi do naszej 
dyskusji? Że mogę odłączyć abusera? Każdy może. Niezależnie od filtrów.

> Piotrze, ty chyba żyjesz w innym świecie niż reszta ludzi. Uważasz, że
wszyscy chcą robić Ci na złość?
>Rozumiem, że chcesz na siłę pokazać, że ktoś Ci broni takiego
rozwiązania jakiego byś sobie życzył?

Na pewno ja sobie życzę? Przecież zapotrzebowanie zgłosiła do PLIX'a firma 
Rafała, nie moja. Ja się tylko włączyłem w wątek.

> A wg nas ryzyko jest dużo wyższe, przy 1 macu możemy je praktycznie
wykluczyć.

Ja właśnie proszę o opisanie tej różnicy. Zamiast mi tu klarować ad 
personam, że jestem niedouczonym tłukiem - napisz dokładnie proszę dlaczego 
w Twojej opinii wzrasta ryzyko tak dramatycznie.

>Jeśli klient wepnie się 2 portami i będzie miał po 1 różnym
macaddressie na każdym, to w przypadku wykrycia pętli switch zablokuje
jego port lub zdropuje ruch z danego portu.
>W przypadku gdy mamy 2 macaddressy na jednym porcie, wykrycie pętli i
zablokowanie ruchu z niego jest dużo trudniejsze.

Dlaczego? Przecież jest sporo mechanizmów wykrywania pętli. I sporo z nich 
nie potrzebuje mac'a. A i w niektórych przypadkach masz pętle, ale żadnego 
maca - np. w/w problem zwarcia TX i RX.

>Masz rację co do jednego: robimy to dla naszej wygody i upieramy się,
że nasze rozwiązanie jest bezpieczne.

Ponowię - dlaczego?

>Mamy do tego prawo, tak samo jak Ty do krytykowania tego podejścia.

Tego prawa zdajesz się odmawiać.

Dziękuję za odzew, ale na prawdę ciekaw jestem tej dziury w security 
powodowanej przez 2 pary IP-MAC zamiast 1 MAC'a. Zgadzam się zdecydowanie, 
że brak mi doświadczenia i rozmachu PLIX'a, więc chętnie spróbuję zrozumieć 
to, na co się powołujesz. Zupełnie poważnie.

Pozdrawiam,

Piotr 

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

"Zboj" <zboj_at_@mnc.dot.pl> napisał w wiadomości 
news:ihceqf$31ku$1@news2.ipartners.pl...
> Dziękuję za odzew, ale na prawdę ciekaw jestem tej dziury w security 
> powodowanej przez 2 pary IP-MAC zamiast 1 MAC'a.

pary IP-MAC powiadasz ...
To wy uzywacie tuneli GRE zeby sie tranzytowac? A moze NAT-a :)))

> Piotr

P/ 

W dniu 2011-01-20 18:56, Zboj pisze:
>> Czemu nie 2 komplety sesji BGP z kazdym z routerow uniknie sie zbednych 
>> announce/withdrawn z BGP i braku dostepnosci na czas renegocjacji sesji ?
> 
[..]
> 
> I poważnie. Zamiast demagogii, że to może wywalić "kawał polskiego 
> Internetu", chciałbym przeczytać - w jaki sposób.

Co by daleko nie sięgać... rozgłoszenie spanning tree i nie do końca dobra
konfiguracja portu.

-- 
[WRC] Biały Scenic 2000 1,9 dTI
CB: Intek M-490 ML 145

+-=-=-=-=-=-=-=- Przemysław Gubernat -=-=-=-=-=-=-=-=-=-=-=-+
| _API Internet_ A. Stolarczyk i P. Gubernat Spółka Jawna   |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+

On 2011-01-21 19:57, obeer wrote:

> Uważam, że nie przeczytałeś dokładnie tego co napisałem.

Tak z boku tej dyskusji - na najbliższym PLNOGu zainteresowane IXy będą 
mogły przez 1:15h opowiadać w dowolony sposób o swoich osiągnięciach,
budowie, czemu tak a nie inaczej. Pierwszego i drugiego dnia. Duuużo
czasu na udowadnianie czemu X jest lepsze od Y jeśli na to się
zdecydujecie.

Tak jak pisał Andrzej i o czym wie Sylwek - zapraszamy do zgłaszania
się w ramach procesu CfP żeby opowiedzieć, która wersja podejścia jest
bardziej odporna na atak Turbodymomena lub Nieoczekiwane Podłożenie
Bułeczki.

-- 
"There's no sense in being precise when |               Łukasz Bromirski
  you don't know what you're talking     |      jid:lbromirski@jabber.org
  about."               John von Neumann |    http://lukasz.bromirski.net

obeer <sylwester.biernacki@gmail.com> writes:

> Proponuję zamknąć ten temat.

Pomyliło ci się z jakimś forum.

  MJ

Użytkownik "Pawel Sikora" <niewazne@niewazne.pl> napisał w wiadomości 
news:ihcpdk$tpm$1@mx1.internetia.pl...
> "Zboj" <zboj_at_@mnc.dot.pl> napisał w wiadomoœci 
> news:ihceqf$31ku$1@news2.ipartners.pl...
>> Dziękuję za odzew, ale na prawdę ciekaw jestem tej dziury w security 
>> powodowanej przez 2 pary IP-MAC zamiast 1 MAC'a.
>
> pary IP-MAC powiadasz ...
> To wy uzywacie tuneli GRE zeby sie tranzytowac? A moze NAT-a :)))

To nie do mnie pytanie. Nie ja stawiam tezę: "1 port, 1 MAC, 1 IP są 
bezpieczne, cokolwiek więcej - nie". Ja tylko prosiłem o jej rozwinięcie.

Piotr 

Znowu dużo słów o tym, co wspaniale robicie. OK. Jestem pod wrażeniem.

Nadal brak mi wyjaśnienia z Twojej strony - w jaki sposób 2 MACi per port są 
krytyczniejsze od 1. Napisałeś:

>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).

W tym wariancie Twój switch zachowa się dokładnie tak samo przy 2 MAC'ach.

Narysujmy schemat: 2 routery BGP PLIX --- switch PLIX --- switch klienta ---  
2 routery BGP klienta.

Dla mnie to symetryczny układ. Przy czym od strony portu PLIX'a będzie dużo 
MACów i takie same potencjalnie problemy, jakie opisałeś. Ze strony klienta 
zaś są np. wyłącznie 2 routery. Mechanizm, który opisałeś wyżej zadziała 
równie prawidłowo dla 2 MACów, jak i dla 1. Czego nie rozumiem ja lub Ty?

Pomińmy już resztę opisów. Wyjaśnij tylko sedno tematu - a więc w czym 
przeszkadzają Ci 2 MACi?


-- 
---
Zboj (Piotr Marciniak)
   zboj \at/ mnc.pl 

>>> Czemu nie 2 komplety sesji BGP z kazdym z routerow uniknie sie zbednych
>>> announce/withdrawn z BGP i braku dostepnosci na czas renegocjacji sesji 
>>> ?
>>
> [..]
>>
>> I poważnie. Zamiast demagogii, że to może wywalić "kawał polskiego
>> Internetu", chciałbym przeczytać - w jaki sposób.
>
> Co by daleko nie sięgać... rozgłoszenie spanning tree i nie do końca dobra
> konfiguracja portu.

Czy na pewno podany przez Ciebie problem STP dotyczy 2 MACów na porcie? 
Widzę stadko problemów tego typu, ale nie kojarzę ich z ilością MACów typu 1 
lub 2.

Pozdrawiam,


-- 
---
Zboj (Piotr Marciniak)
   zboj \at/ mnc.pl 

> 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.

A co ma moja funkcja w komisji rewizyjnej (wiesz, to taki organ wewnętrznej 
kontroli finansowej) izby gospodarczej do konfiguracji przełącznika przez 
jednego z jej członków? Ty jesteś członkiem tej samej organizacji. I co to 
wnosi do tematu? Obaj odpowiadamy za konfigurację switcha w firmie trzeciej 
tylko dlatego, że jesteśmy w tej samej organizacji?

BTW - gdybym Ci nawet udowodnił, że nie piszesz prawdy w temacie 2 maców, bo 
masz takie sytuacje na portach w PLIXie, to co to zmieni? Uderzysz się w 
pierś i przeprosisz za ściemę lub ogłosisz zmianę polityki? Czy też 
wypowiesz obecne warunki swoim klientom, by móc dalej brnąć w tezę o 
zasadach? Ja wiem i rozumiem, że masz jakąś niechęć do KIX'a i pewnie główny 
problem w tym, że transmisja ma do Ciebie dotrzeć via styk z KIKE. Tylko czy 
profesjonalizm, na który się powołujesz, powinien wpływać na decyzję o 
sposobie spięcia z klientem w zależności od tego, kto go tranzytuje?


-- 
---
Zboj (Piotr Marciniak)
   zboj \at/ mnc.pl 

Dnia 24.01.2011 Zboj <zboj_at_@mnc.dot.pl> napisał/a:
> BTW - gdybym Ci nawet udowodni³, ¿e nie piszesz prawdy w temacie 2 maców, bo 
> masz takie sytuacje na portach w PLIXie, to co to zmieni? Uderzysz siê w 
heh...
[root@r1 ~]# /usr/sbin/arping 195.182.218.56             
ARPING 195.182.218.56
60 bytes from 00:30:88:12:05:9f (195.182.218.56): index=0 time=10.468 msec
60 bytes from 00:30:88:11:33:27 (195.182.218.56): index=1 time=10.939 msec
60 bytes from 00:30:88:12:05:9f (195.182.218.56): index=2 time=10.107 msec
60 bytes from 00:30:88:11:33:27 (195.182.218.56): index=3 time=10.712 msec
^C
--- 195.182.218.56 statistics ---
2 packets transmitted, 4 packets received, -100% unanswered

? :)

-- 
Andrzej 'The Undefined' Dopierała
HomePage: http://andrzej.dopierala.name/
Reprezentuję siebie i wyrażam tylko moje zdanie!

On Jan 25, 12:38 am, Andrzej 'The Undefined' Dopierała <undef...@pld-
linux.org> wrote:
> Dnia 24.01.2011 Zboj <zboj_...@mnc.dot.pl> napisał/a:> BTW - gdybym Ci nawet udowodni³, ¿e nie piszesz prawdy w temacie 2 maców, bo
> > masz takie sytuacje na portach w PLIXie, to co to zmieni? Uderzysz siê w
>
> heh...
> [root@r1 ~]# /usr/sbin/arping 195.182.218.56            
> ARPING 195.182.218.56
> 60 bytes from 00:30:88:12:05:9f (195.182.218.56): index=0 time=10.468 msec
> 60 bytes from 00:30:88:11:33:27 (195.182.218.56): index=1 time=10.939 msec
> 60 bytes from 00:30:88:12:05:9f (195.182.218.56): index=2 time=10.107 msec
> 60 bytes from 00:30:88:11:33:27 (195.182.218.56): index=3 time=10.712 msec
> ^C
> --- 195.182.218.56 statistics ---
> 2 packets transmitted, 4 packets received, -100% unanswered
>
> ? :)


To jest przykład naszego flexibility w podejściu do klienta ;-P
Leon używa Redbacka z nowym softem i ze starym softem.
Że nowy się sypie to tymczasowo ma wpuszczone dwa ipki i dwa maki, aż
się nie przełączy na docelowy.

Generalnie mamy więcej takich przypadków, które z zaszłości, z racji
tego, że byliśmy zbyt dobrzy i naiwni, kiedyś wyszły.
Od kilku miesięcy sprzątamy zaległości i nikomu nie pozwalamy już na
nowe szaleństwa.

Niedługo jeszcze wdrożymy ISO ;-)

Sylwester

W dniu 25.01.2011 01:20, obeer pisze:
> On Jan 25, 12:38 am, Andrzej 'The Undefined' Dopierała<undef...@pld-
> linux.org>  wrote:
>> Dnia 24.01.2011 Zboj<zboj_...@mnc.dot.pl>  napisał/a:>  BTW - gdybym Ci nawet udowodni³, ¿e nie piszesz prawdy w temacie 2 maców, bo
>>> masz takie sytuacje na portach w PLIXie, to co to zmieni? Uderzysz siê w
>>
>> heh...
>> [root@r1 ~]# /usr/sbin/arping 195.182.218.56
>> ARPING 195.182.218.56
>> 60 bytes from 00:30:88:12:05:9f (195.182.218.56): index=0 time=10.468 msec
>> 60 bytes from 00:30:88:11:33:27 (195.182.218.56): index=1 time=10.939 msec
>> 60 bytes from 00:30:88:12:05:9f (195.182.218.56): index=2 time=10.107 msec
>> 60 bytes from 00:30:88:11:33:27 (195.182.218.56): index=3 time=10.712 msec
>> ^C
>> --- 195.182.218.56 statistics ---
>> 2 packets transmitted, 4 packets received, -100% unanswered
>>
>> ? :)
>
>
> To jest przykład naszego flexibility w podejściu do klienta ;-P

W podejściu do wybranego klienta. No cóż. Życie, zawsze będą równi i 
równiejsi.

> Leon używa Redbacka z nowym softem i ze starym softem.
> Że nowy się sypie to tymczasowo ma wpuszczone dwa ipki i dwa maki, aż
> się nie przełączy na docelowy.

To może, zgodnie z tym co napisałeś w innym poście, należałoby "odpytać 
każdego z ponad 160 uczestników PLIXa, czy się zgadzają
na takie rozwiązanie"? Nie sądzę, żeby podobało się im, że inny 
uczestnik wystawia jedno IP jednocześnie na dwóch MAC adresach. Przecież 
to jest wbrew sztuce.

> Generalnie mamy więcej takich przypadków, które z zaszłości, z racji
> tego, że byliśmy zbyt dobrzy i naiwni, kiedyś wyszły.
> Od kilku miesięcy sprzątamy zaległości i nikomu nie pozwalamy już na
> nowe szaleństwa.

Ok, tylko IMHO pozwolenie uczestnikowi na wystawienie jednego IP 
jednocześnie na dwóch MAC adresach jest szaleństwem. Przypisanie dwóch 
MAC adresów do portu - nie.

> Niedługo jeszcze wdrożymy ISO ;-)
>
> Sylwester

Przyjmuję do wiadomości, że w obu sprawach (przytoczonego Leona i 
naszej) stanowisko PLIXa się nie zmieni. Troszkę to jednak irytujące.

-- 
Sławomir Lipowski
http://lipowski.org

Andrzej 'The Undefined' Dopierała wrote:
> Dnia 24.01.2011 Zboj <zboj_at_@mnc.dot.pl> napisał/a:
>> BTW - gdybym Ci nawet udowodni³, ¿e nie piszesz prawdy w temacie 2 maców, bo 
>> masz takie sytuacje na portach w PLIXie, to co to zmieni? Uderzysz siê w 
> heh...
> [root@r1 ~]# /usr/sbin/arping 195.182.218.56             
> ARPING 195.182.218.56
> 60 bytes from 00:30:88:12:05:9f (195.182.218.56): index=0 time=10.468 msec
> 60 bytes from 00:30:88:11:33:27 (195.182.218.56): index=1 time=10.939 msec
> 60 bytes from 00:30:88:12:05:9f (195.182.218.56): index=2 time=10.107 msec
> 60 bytes from 00:30:88:11:33:27 (195.182.218.56): index=3 time=10.712 msec
> ^C
> --- 195.182.218.56 statistics ---
> 2 packets transmitted, 4 packets received, -100% unanswered
> 
> ? :)

ups, to musiało być coś o czym ktoś zapomniał przy rozdzielaniu routerów.
Takie coś było na jednym z routerów:
  ip arp 195.182.218.56 00:0f:23:01:b7:43 alias

Już naprawione.

Marcin

> To jest przykład naszego flexibility w podejściu do klienta ;-P

taaaaaa. Pisałem Ci maila w tym temacie.

Rozumiem, że technicznie nie idziecie na rękę. Wkurzałoby mnie gdybym 
miał więcej pracy bo poszedłem na rękę a to wywołuje problem.

Popatrz jednak na elastyczność innych osób i innych procedur. W mojej 
ocenie są za sztywne i trwają zbyt długo.

Na niezawodność i wygodę składa się także podejście inne a nie tylko 
techniczne.





Icek