Ubinoob

To akurat póki co nie przeszkadza. Kilkanaście ms więcej i tyle. Nie powinno się zatkać w szczycie dziś. Problem mają też niektórzy inni operatorzy np. z transmisją do de-cixa: Multimedia, Netia, S-NET itp.

Podeślij im na traceroute@ml.ovh.net wraz ze swoim adresem IP.

W takim razie pochwal się operatorem/AS'em + trasą

Operatorzy którzy są dostępni w PLIX, TPIX, THINX lub mają bezpośrednie styki z OVH mają dobry routing (czyli większość). Jak któryś z operatorów wydziwia w postaci prependu, localprefa lub innymi sposobami steruje ruchem to owszem, może lecieć przez RBX, no ale tutaj to nie bardzo wina OVH. W większości przypadków jest ok

Obecnie pojawiło się coś takiego: https://www.ovh.pl/serwery_dedykowane/fs/173fs6.xml pod storage.

News bez żadnego poparcia. Zero konkretów, nawet nie wiadomo jaki jest wektor ataku.

Pod gry to jednak i7 jest lepszym rozwiązaniem. Nie umniejszając oczywiście xeonowi, ale tutaj liczy się bardziej wydajność pojedynczego rdzenia, która w przypadku i7 jest wyższa.

Zobacz też http://datahouse.pl (umowa).

Taką sytuację obserwuję od ponad roku. Kilkukrotnie to zgłaszałem, bo zwyczajnie myślałem że to jakiś błąd, ale że nie doskwierało mi to tak bardzo to nie dążyłem do uzyskania sensownej odpowiedzi. Na dedykach oczywiście wszystko działa. Jeśli chodzi o stałą filtrację to uruchamia ona jedynie firewall-network i tilerę, więc filtrację dla niewielkiej ilości ataków. Natomiast nie w tym rzecz, bo gdy atak zostanie wykryty, załącza się arbor/armor (niezależnie od stałej filtracji) i można się pożegnać z UDP.

Dziś miałem tą przyjemność (albo i nie) dowiedzieć się czegoś ciekawego o konfiguracji VAC, co jest dosyć ważne dla potencjalnych kupujących a nie ma nigdzie o tym wzmianki. Wszystkie usługi współdzielone (w tym oczywiście vps, pci, inne usługi cloud itd.) posiadają taką konfiguracje VAC'a że UDP jest w zasadzie całkowicie odcinane BEZ FILTROWANIA! Wyjątkiem są serwery dedykowane. Odpowiedzi od OVH na zgłoszenie problemu ciągłego odcinania UDP w przypadku każdego rodzaju ataku: Po moich zastrzeżeniach dotyczących dostępności tej informacji przed zakupem, dostałem odpowiedź że moja sugestia została przekazana do działu marketingu. Prawdę mówiąc we wszystkich usługach, czy to public cloud, czy dedykach widnieje ładne "Anty-DDoS Pro", gdzie możemy wyczytać o filtracji UDP a jednak nie do końca tak jest. Nie trzymam na tym serwerze żadnych gier czy innych głupot, ale np. OpenVPN na UDP działa znacznie wydajniej, a w momencie ataku można zapomnieć o UDP. Jeśli więc komuś zależy na postawieniu czegokolwiek co wymaga UDP to wszelkiego rodzaju instancje chmurowe, vpsy itp. w OVH to słaby pomysł (chyba że liczymy się z niedostępnością w momencie załączenia VAC).

Pod warunkiem oczywiście że Twój operator w nich uczestniczy i nie ma podniesionego localprefa, czy nie prependuje się w IX'ach za bardzo.

A może zwyczajnie nie ścigają się na te mocno overbookowane cyferki, które przeciętnemu Kowalskiemu nie są potrzebne? Jeżeli komuś to nie przeszkadza to od siebie powiem tyle, że w zasadzie nie ma na co u nich narzekać. Oczywiście wiele zależy od lokalizacji. Jeśli chodzi o brzeg to obecnie globala wypychają za pomocą COGENT'a i TATA, jest PLIX, TPIX, EPIX, DECIX, jest tranzyt do TPNET. Oprócz drobnych potknięć w postaci ostatnio przytykającego się TPIX'a jest ok. W szkielecie też bardzo niskie czasy. Koniec OT.

@Czoobek: OVH ma PNI z UPC i szczerze mówiąc pierwszy raz słyszę o takim problemie z tak niską przepustowością. Sprawdź tutaj: http://rbx.proof.ovh.net/ jeśli wynik jest ok to proponuje dokonanie kilku pomiarów iperfem. Może coś nie tak na routerze/switchu do którego jesteś podpięty lub na samej maszynie.

ONLINE nie ma w żadnym IX'ie w Polsce, więc średnio można porównywać w tej kwestii. Wiadomo że tutaj OVH będzie lepsze.

To, że cache "po drodze" może się różnie zachowywać. Weź też pod uwagę, że systemu DNS nie obsługuje jeden serwer i nie na każdym ta konfiguracja jest już odświeżona. Podany przez Ciebie objaw jest jak najbardziej normalny. Gratulacje natomiast należą się Tobie, za ignorancję tego co powiedzieli bardziej doświadczeni. Zadajesz pytanie, a potem odrzucasz z automatu odpowiedzi...

Pełno opów ma obecnie na sztywno poustawiane różne localprefy na sesjach z OVH i wielu wciąż leci przez zagranicę. Często nawet ciężko jest OVH to zmienić (no chyba że zgasić sesję). Faktycznie warto zgłaszać na peering@ovh.net, ale trzeba się liczyć z tym, że to może potrwać (tak jak sprawa z preferencją vectry).

VAC w PL został uruchomiony produkcyjnie i teraz ruch nie jest już filtrowany przez SBG. Jak ktoś może to fajnie by było zobaczyć jak wygląda trasa przy filtrowaniu automatycznym (podczas ataku). Z góry dzięki.

Przetestowałem to u siebie i szczerze mówiąc ciekawy jest tylko problem z potokami, bo faktycznie przykład z whoami nic nie loguje (jak użyjemy np. touch to plik się tworzy). Natomiast odpaliłem sobie regułkę: /etc IN_MODIFY,IN_CREATE,IN_DELETE /bin/sh /root/testincron (tylko i wyłącznie ta jedyna reguła) i skrypt z Twoją zawartością się bez problemu uruchomił. #!/bin/sh date +"%m/%d/%Y %H:%M:%S $HOSTNAME" >> /root/log.txt Jeśli nie "date" to spróbuj użyć zwykłe "touch /root/test" czy przynajmniej skrypt startuje.

Ale plik jest? Zobacz z ciekawości (jeśli jest pusty plik): /etc/ IN_MODIFY,IN_CREATE,IN_DELETE /usr/bin/whoami >> /tmp/test.log 2>&1

I nadal nie ma nic w /tmp/test.log?

Sprawdź czy on uruchamia to faktycznie na roocie (w przeciwnym wypadku nie uda mu się dostać do katalogu): /etc IN_MODIFY,IN_CREATE,IN_DELETE /usr/bin/whoami >> /tmp/test.log Jeśli faktycznie na roocie, to spróbuj w swoim skrypcie zmienić: /bin/date +"%m/%d/%Y %H:%M:%S $HOSTNAME" >> /root/log.txt Ewentualnie można spróbować zobaczyć o jest w $PATH i próbować je ustawić.

Spróbuj zrobić z tego jeden wpis i ręcznie wskazać interpreter. /etc IN_MODIFY,IN_CREATE,IN_DELETE /usr/bin/logger "Sciezka: $@/$# Zdarzenie:$%" && /bin/sh /root/skrypt

Skrypt w czym? Jesteś pewien że incron ma dostęp do tego katalogu i odpowiedni chmod?

VAC w Polsce jest aktywny, ale atakowane IP nie są jeszcze do niego routowane (pewnie konfigurują). Podejrzewam, że będą blokami je dodawać i obserwować co się dzieje. Dodawanie reguł "Firewall Network" nie ma nic wspólnego z nową technologią (arbor > armor), bo akurat one są obsługiwane przez CISCO ASR9001, które tutaj też istnieje.

Już od dawna jest wyłączone.