obeer <s...@g...com> writes:

> Proponuję zamknąć ten temat.

Pomyliło ci się z jakimś forum.

MJ

do góry

Użytkownik "Pawel Sikora" <n...@n...pl> napisał w wiadomości
news:ihcpdk$tpm$1@mx1.internetia.pl...
> "Zboj" <z...@m...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

do góry

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

do góry

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

do góry

> 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

do góry

Dnia 24.01.2011 Zboj <z...@m...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 sie 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!

do góry

On Jan 25, 12:38 am, Andrzej 'The Undefined' Dopierała <undef...@pld-
linux.org> wrote:
> Dnia 24.01.2011 Zboj <z...@m...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 sie 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

do góry

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<z...@m...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 sie 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

do góry

Andrzej 'The Undefined' Dopierała wrote:
> Dnia 24.01.2011 Zboj <z...@m...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 sie 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

do góry

> 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

do góry