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 Lipowski
http://lipowski.org

do góry

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

do góry

On 18 Sty, 16:07, Sławek Lipowski <s...@l...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

do góry

On 18 Sty, 19:01, "f...@o...pl" <f...@o...pl> wrote:
> On 18 Sty, 16:07, Sławek Lipowski <s...@l...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

do góry

On 18 Sty, 19:17, nastach <n...@p...pl> wrote:
> On 18 Sty, 19:01, "f...@o...pl" <f...@o...pl> wrote:
>
>
>
>
>
>
>
>
>
> > On 18 Sty, 16:07, Sławek Lipowski <s...@l...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_3
67107190.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. "

do góry

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

--
Pozdrawiam
Marek Grzybowski

do góry

On Jan 19, 10:06 am, Wolodyj <t...@o...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

do góry

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

do góry

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

do góry

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

do góry