Skocz do zawartości

Polecane posty

Od 10-15 minut nie działa mi główna strona globalnetwork oraz moje serwery. Prawdopodobnie coś na łączu bo po plixie idzie. Ktoś coś wie?

 

EDIT: Bankowo coś padło na łączach bo nie tylko GlobalNetwork nie działa u mnie, Castpol również.

Edytowano przez Biszkopcik (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Wygląda na to że tepsa im padła,

aczkolwiek u mnie działa ok (tpix), lecz nie leci przez telie jak z lg.tpnet.pl

Edytowano przez Gość (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Bez przesady... na pewno ogarną, nie trzeba nikomu truc o prawie 1 w nocy

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość Kamikadze

Od siebie nie mam dostępu po TP przykładowo hitme <-> global idzie bez problemu.

 

edit:

 

Może znowu coś z operatorami kombinują :)

Edytowano przez Kamikadze (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Chyba coś na styku do HE poleciało z tepsą. Nadal wytępuje ten problem?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Witam,

 

Tak jak napisał Miłosz jest problem na styku HE z TPNET. Problem został zgłoszony - czekamy na jakieś informacje zwrotne.

 

 

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Witam,

 

Tak jak napisał Miłosz jest problem na styku HE z TPNET. Problem został zgłoszony - czekamy na jakieś informacje zwrotne.

 

 

no dobrze - fajnie że zajmujecie się problemem......jedno pytanie: gdzie i komu to zgłaszaliście? Tepsie?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Do HE, bo to ich styki z Telią i TP

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

no leży

Śledzenie trasy do globalnetwork.pl [195.177.216.7]
z maksymalną liczbą 30 przeskoków:

  1     3 ms     3 ms     2 ms  livebox.home [192.168.1.1]
  2   183 ms    22 ms    21 ms  war-bg1.neo.tpnet.pl [83.1.4.11]
  3    93 ms    54 ms    76 ms  war-r2.tpnet.pl [80.50.157.41]
  4    36 ms     *        *     hbg-b1-link.telia.net [213.248.89.93]
  5    36 ms    37 ms     *     hbg-bb4-link.telia.net [213.155.135.86]
  6    37 ms    37 ms    37 ms  war-b1-link.telia.net [80.91.251.34]
  7     *        *        *     Upłynął limit czasu żądania.
  8     *        *        *     Upłynął limit czasu żądania.
  9     *        *        *     Upłynął limit czasu żądania.
 10     *        *        *     Upłynął limit czasu żądania.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość Kamikadze

Gdańsk

traceroute to m1.serwerstatus.pl (91.236.55.100), 30 hops max, 60 byte packets 1  vps16.hitme.net.pl (188.116.2.26)  0.101 ms  0.017 ms  0.017 ms 2  gw-v0-ln.gdacto-3.v4.nephax.net (91.203.132.1)  0.257 ms  0.362 ms  0.341 ms 3  nephax-ci-gw.task.gda.pl (153.19.102.117)  2.450 ms  2.359 ms  2.364 ms 4  globalnetwork.thinx.pl (212.91.0.155)  5.239 ms  5.283 ms  5.141 ms 5  91.236.54.42.client.blcluster.net (91.236.54.42)  5.746 ms  5.726 ms  5.738 ms 6  m1.serwerstatus.pl (91.236.55.100)  5.757 ms  5.662 ms  5.879 ms

Poznań

traceroute to m1.serwerstatus.pl (91.236.55.100), 30 hops max, 60 byte packets 1  192.168.1.75 (192.168.1.75)  0.043 ms  0.011 ms  0.008 ms 2  10.11.11.5 (10.11.11.5)  0.481 ms  0.504 ms  0.586 ms 3  blue-leaf.plix.pl (195.182.218.148)  8.264 ms  8.331 ms  8.392 ms 4  91.236.54.42.client.blcluster.net (91.236.54.42)  9.002 ms  8.971 ms  9.153 ms 5  m1.serwerstatus.pl (91.236.55.100)  9.133 ms  9.157 ms  9.121 ms

Tuchola

traceroute to m1.serwerstatus.pl (91.236.55.100), 30 hops max, 60 byte packets 1  gw-v11-core (91.237.69.1)  0.587 ms * * 2  globalnetwork.thinx.pl (212.91.0.155)  14.117 ms  13.977 ms  13.726 ms 3  91.236.54.42.client.blcluster.net (91.236.54.42)  14.569 ms  14.255 ms  14.088 ms 4  m1.serwerstatus.pl (91.236.55.100)  13.908 ms  13.808 ms  13.711 ms

Francja

traceroute to m1.serwerstatus.pl (91.236.55.100), 30 hops max, 60 byte packets 1  201.ip-176-31-185.eu (176.31.185.201)  0.047 ms  0.012 ms  0.011 ms 2  rbx-g1-a9.fr.eu (178.33.100.37)  0.817 ms  2.328 ms  2.296 ms 3  * * * 4  var-1-6k.pl.eu (91.121.131.244)  27.968 ms * * 5  war-cx1.tpix.pl (195.149.232.5)  27.930 ms  28.000 ms  27.971 ms 6  globalnetwork.thinx.pl (212.91.0.155)  28.299 ms  28.276 ms  28.220 ms 7  91.236.54.42.client.blcluster.net (91.236.54.42)  28.610 ms  29.052 ms  29.018 ms 8  m1.serwerstatus.pl (91.236.55.100)  30.380 ms  29.977 ms  30.154 ms

TP


1 1 ms 1 ms 1 ms 10.0.0.1
2 20 ms 20 ms 19 ms war-bg3.neo.tpnet.pl [83.1.4.60]
3 19 ms 18 ms 18 ms war-r2.tpnet.pl [80.50.146.1]
4 36 ms 34 ms 99 ms hbg-b1-link.telia.net [213.248.89.93]
5 39 ms 37 ms 34 ms hbg-bb1-link.telia.net [80.91.246.6]
6 49 ms 49 ms 54 ms war-b1-link.telia.net [213.155.131.91]
7 * * * Upłynął limit czasu żądania.
8 * * * Upłynął limit czasu żądania.
9 * * * Upłynął limit czasu żądania.
10 *

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Nie padł, nie leży. Jest znowu jakiś problem na styku HE - Telia/Oryndż

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Czy działa wam strona globalnetwork? Bo wydaje mi się że ich usługi znowu padły, ale nie jestem pewien czy to przypadkiem nie jest znów problem na łączach TPNET dlatego pytam.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Nie wiem co tam u nich się dzieje, ale z całym szacunkiem dla nich to już jest co najmniej irytujące. Od dłuższego czasu nagminnie pojawiają się awarie i nie ma ani żadnych informacji ani tym bardziej żadnego kontaktu. Dostałem dziś na maila informację że około godziny 24 w nocy (z 7 na 8 listopada) będą kilkuminutowe przerwy techniczne. Chyba trochę się wydłużyły...

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Monitoruję jeden z ich serwerów - ten z klientami byłego Glowa.netu, bo swego czasu glowanet właśnie monitorowałem - i odnotowałem przerwę w dostępności pomiędzy godz. 23:44 a 13:04.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Szanowni Państwo,

 

poniżej zamieszczamy informację wyjaśniającą przyczyny dzisiejszej awarii:

 

Jak informowaliśmy Państwa wcześniej nasza firma od kilku miesięcy posiada sprzętową ochronę przed atakami DDoS oraz inspekcję ruchu IPS/IDS. Konfiguracja tego rozwiązania wydawała nam się w kilku scenariuszach bardzo dobra. Firewalle, które posiadamy, były skonfigurowane w trybie transparentnym aby zapewnić iż podczas ewentualnej awarii urządzenia ruch będzie przekazywany dalej poprawnie. Po kilku miesiącach pracy firewalli zebraliśmy informacje zwrotne od klientów dotyczące występujących niedogodności. Głównym problemem były problemy z ARP’ami na maszynach wirtualnych. Dlatego zdecydowaliśmy o odpięciu ochrony od produkcyjnej sieci i przetestowaniu nowego rozwiązania w labie. Odpięcie systemu ochrony nastąpiło około 2 tygodnie temu co niestety spowodowało powrót ataków na systemy klientów. W laboratorium przygotowaliśmy nowe rozwiązanie wraz z nową konfiguracja oraz dokonaliśmy wszelkich koniecznych testów. Konfiguracja wymagała od nas wykorzystania VRF na routerach BGP wraz z technologią MPLS. Coraz częstsze ataki na naszą infrastrukturę spowodowały szybsze wdrożenie nowej konfiguracji, która nastąpiła wczoraj w nocy. Niestety po zaaplikowaniu konfiguracji, zestawieniu wszystkich sieci do operatorów zaczęły przepełniać się tablice MLS i RIB co powodowało obciążenie sprzętu na poziomie 99%. Problemem okazała się błędna informacja w dokumentacji Cisco, która mówiła iż dane urządzenia są w stanie obsłużyć daną liczbę wpisów i labelowania tras MPLS’owych, problem w tym iż Cisco na swoich urządzeniach mimo że ma możliwość obsługiwania większej ilości wpisów domyślnie obcina to do ustalonych wartości. Dokumentacja niestety nie miała informacji jak te wartości zmienić. Po konsultacji z inżynierami Cisco udało nam się opanować sytuację z tablicami RIB i MLS. Po tej sytuacji napotkaliśmy kolejny problem, w którym ruch z VRF (BGP OUTSIDE DO OPERATORÓW) na sztywno był wysyłany tylko jednym operatorem. Objawiało się to w taki sposób: Ruch z TPSA przychodził na linku od jednego operatora a ruch powrotny wysyłany był drugim operatorem, który nie miał styku z TPSA.

 

W momencie określenia problemu jako krytyczny i skomplikowany podjęliśmy decyzję o rollbacku konfiguracji, ale cały czas występował problem z wydajnością tablic MLS, RIB oraz problemy z ARP. Dlatego podjęta została decyzja o docelowym rozwiązaniu problemu. Nad rozwiązaniem problemu pracowało 3 certyfikowanych inżynierów Cisco Routing i Security. Na chwilę obecną rozwiązaliśmy wszystkie problemy, które mieliśmy przed pracą firewalli w trybie transparentnym oraz ochraniamy klientów przed dalszymi atakami DDoS wraz z dalszą poprawną pracą systemu inspekcji IPS/IDS.

 

Za wszelkie niedogodności serdecznie przepraszamy.

Edytowano przez globalnetwork.pl (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Witam,

 

Globalnetwork.pl nie padł i nie zamierza:) jesteśmy w trakcie dużych zmian. Podzieliliśmy usługi na dwie marki. Obecni nasi klienci zostali poinformowani o zmianach m.in o tym że usługi hostingowe hostowane są z Amazon AWS. Wkrótce więcej ciekawych zmian.

 

Zespół CLOUDBITLY.COM (dawne Globalnetwork.pl)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Bądź aktywny! Zaloguj się lub utwórz konto

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto

Zarejestruj nowe konto, to proste!

Zarejestruj nowe konto

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się


×