При липса на свързаност или прекъсване на услуга:

  • Информация за статус на порта up/down и откога е с този статус.
  • Информация за последно отпадане/прекъсване и колко пъти се е случило това откакто се наблюдава проблем с услугата.
  • Откога се наблюдава проблем с услугата и дали е обвързан с часовете с пиково натоварване.
  • Предоставяне на log от Router / Switch / Server машината на която се терминира връзката с Telepoint заедно с Timestamps с коректен час (GMT)
  • Проверка на приемни оптични нива, DOM статистики на физически интерфейс, CRC статистики на броячите на порта.
  • Информация за настройки на Speed/Duplex settings – 10/100/1000, Auto Negotiation on/off
  • При работа с оптичен интерфейс е нужно да се предостави информация за използвания модул.
  • За проверка на физически проблем с връзката може да помолите Telepoint да проверят за повреден кабел, конектор, оптични нива и други.

При проблем засягащ загуба на пакети, ниски скорости от/до интернет:

  • Предоставяне на резултат от traceroute с посочени source/destination IP адреси до проблемната дестинация.
    Резултатите трябва да се предоставят без resolve, за да се виждат IP адресите през различнит hop-ове.
    • Windows: tracert google.com
    • Linux: traceroute google.com
    • Под Linux базирани системи може да използвате MTR за тези тестове.

    Забележка: Повечето Core рутери през които преминава Вашият трафик не приоритизират отговорите на ICMP протокола който се използва при ping тест. Поради тази причина, а и поради други фактори, може да наблюдавате загуби във Вашите тестове на междинни hop-ове. Това е напълно нормално и не е причина за проблема който наблюдавате. Вашите тестове могат да покажат проблем на мрежово ниво ако имат загуби до крайното destination IP. Ако това е така се налага проверка на връзката Ви. Моля направете тестове и до други дестинации както международни така и такива базирани в България като приложите тестовете.


    Командата на Windows е tracert последвана от destination IP / Domain Name. На linux e traceroute. Логиката в резултатите е същата, независимо дали сме на Linux или Windows. Може да използваме или Domain Name или IP. DNS ще си го преведе след това.


    Първата цифра ни е HOP number, тя ни показва на кой HOP сме по пътя на връзката. Най- важното нещо тук е да видим трите цифри след това. Те ни показват RTT(round trip time), което означава колко време е нужно на пакета да стигне дестинацията и да се върне до нашето устройство. Мерната единица е ms(милисекунди). Колоните са три защото tracerоute изпраща общо 3 съобщения за по-добра последователност. Последната колона след трите цифри ни е IP адреса и domain name на устройството на дадения HOP. По средата на теста можем да видим Request time out, но не винаги, това е повод за проблем. Някои устройства просто блокират пакети от tracerout или ping(windows - ICMP / Linux - UDP). Времената в RTT колоните са важното нещо което трябва да гледаме при този тест. Ако установим повишена латенция в първите няколко HOPS, това означава,че може да имаме проблем на локално LAN ниво. Ако установим повишаване на ниво от даден HOP и продължи с постоянно повишаване, това може да индикира за проблем от точката където е започнало повишаването.


    В дадения случай 11 ни е последния HOP, по default tracert е 30 HOPS максимум. Ако искаме да повишим default HOPS може да използваме параметъра -h последван от броя на HOPS.


  • Друг способ който може да използваме е MTR. Той комбинира traceroute и ping.


  • По-подробен е от Traceroute и ни показва и процента от загубите на пакети по различните HOPS. MTR е наличен в Windows, Mac OS и Linux. За да изтеглите MTR в Windows, можете да изтеглите Windows версия WINMTR. За да инсталирате MTR на Mac OS, можете да използвате Homebrew или Macports. Според специфичната дистрибуция на Linux може да се инсталира със следните команди: apt-get install mtr или yum install mtr (RHEL, Fedora)

  • Проверка и информация за броячи на грешки на интерфейс (CRC), както и откога се забелязва натрупване на грешки, претоварване на порт. Повреден UTP кабел може да е причина за този порт да работи на 100Mbps, а да се очаква да е 1Gbps.
  • Проверка за скорост на интерфейс 10/100/1000.
  • Предоставяне на Bandwidth тест като по възможност използвайте публичен Iperf Server или изтеглете голям по обем файл (Linux distro) При необходимост можете да се свържете с nocTelepoint и ние ще Ви предоставим Iperf Server в нашата мрежа за тестови цели. При Mikrotik Router можем да предоставим Btest server.

    Iperf е client-server bandwith test tool между два хоста. Може да се ползва и на Windows и на Linux, обикновенно само през CLI. От едната страна имаме сървър който "слуша" по default на порт 5201. За да стартираме сървъра използваме командата: iperf3 -s. Ако искаме да сменим порта на който сървъра "слуша" може да използваме параметъра -p. От другата страна клиента трябва да използва следната команда за да осъществи връзка към сървъра и теста да започен: iperf3 -c /IP на сървъра/ След няколко секунди (10 по default) ще видим резултатите. Ако искаме да увеличим времето за тест използваме параметъра -tIperf е client-server bandwith test tool между два хоста. Може да се ползва и на Windows и на Linux, обикновенно само през CLI. От едната страна имаме сървър който "слуша" по default на порт 5201. За да стартираме сървъра използваме командата: iperf3 -s. Ако искаме да сменим порта на който сървъра "слуша" може да използваме параметъра -p. От другата страна клиента трябва да използва следната команда за да осъществи връзка към сървъра и теста да започен: iperf3 -c /IP на сървъра/ След няколко секунди (10 по default) ще видим резултатите. Ако искаме да увеличим времето за тест използваме параметъра -t


При проблем засягащ връзката от/до един сървър от топологията:

  • Предоставяне на топологията от гледна точна на сървъра Пример: Server <> Switch <> Router <> Telepoint Gateway
  • Предоставяне на тестове от проблемен сървър както и повторни резултати от сървър с който не се наблюдава проблем.

При липса на интернет, но успешен PING до Gateway IP адрес:

  • Проверка и информация за активираните IP адреси на Router / Server машината, спрямо предоставената мрежа както и default gateway (0.0.0.0/0) конфигурацията. При тези симптоми най-честата причина е липса или неправилно зададен default gateway.