Re: traceroute

Marek Moskal <moskit@irc.p-l> wrote:
>>>> A taka telia/tpsa nie powinna tego wycinac? Czy moze byłoby to zbyt
>>>> 'meczace' dla routerow?
>> Jeżeli ma klientów końcowych, to oczywiście. W tranzycie sensu nie ma.
> W pewnej mierze ma - nawet w przypadku tranzytu operator powinien MBSZ
> wycinac na brzegu pakiety z niewlasciwymi adresami zrodlowymi, np. z sieci
> prywatnych

I nie można by było dostać icmp z prywatnego linku /30 ;)

> czy tez z wlasnej sieci operatora (!). Taka odrobina higieny.

Jestem w stanie sobie wyobrazić taką awarię, że od operatora do tego
samego operatora idzie przez innego.

I naprawdę by wystarczyło filtrowanie klientów źródłowych od klientów
końcowych.

> PS: dla kompletnosci dyskusji - mechanizm do tego sluzacy na "duzych"
> routerach nazywa sie "unicast Reverse Path Forwarding check" (uRPF) i jego
> dwie podstawowe odmiany to tryb "strict" (dla laczy do klientow koncowych,
> weryfikacja czy adres zrodlowy ma w tablicy routingu trase wskazujaca na
> interfejs z ktorego taki pakiet przyszedl)

I uRPF strict będzie szybszy niż ACL? Czy tylko wygodniejszy w konfiguracji?

> albo "loose" (dla ruchu
> tranzytowego lub pochodzacego od klientow typu multi-home, weryfikacja czy
> trasa do adresu zrodlowego w ogole jest w tablicu routingu).

He he, zrobili w końcu; pamiętam, jak wprowadzili uRPF i popsuli multihoming.

> Pozwala to "wyczyscic" to, co sie wpuszcza do wlasnego szkieletu.

Pod warunkiem, że nikt śmieci nie ogłasza -- czyli marne zabezpieczenie. ;p
Ile to już razy widziałem ogłaszane rfc1918.

p.

-- 
Beware of he who would deny you access to information, for in his
heart he dreams himself your master.   -- Commissioner Pravin Lal
http://nerdquiz.sgh.waw.pl/  -- polska wersja quizu dla nerdów ;)