Перейти к содержимому
Калькуляторы

SNR-CPE поддержка, опыт эксплуатации, регрессии, результаты тестирования, общие вопросы

1) допустимый диапазон питающих напряжений 5-14В постоянки. Ток БП должен держать не меньше ампера

2) ну сдох бывает, брак,если железка новая заменят без проблем, БП нынче не торт ;(

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

При обновлении с 5.0.19 на 5.2.13 в настройках WiFi пропал сканер эфира. Это какой-то баг, или специально убрали? (фича мегаудобная, позволяющая саппорту оперативно проверить радиообстановку у клиента, при жалобах "интернет на ноутбуке тормозит")

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сканер не доступен только в режиме автовыбора канала, проверьте не выбран ли у вас автовыбор

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сканер не доступен только в режиме автовыбора канала, проверьте не выбран ли у вас автовыбор

 

И это не верно. Нет никакого смысла скрывать сканер даже если стоит авто. Надо убрать привязку.

 

(фича мегаудобная, позволяющая саппорту оперативно проверить радиообстановку у клиента, при жалобах "интернет на ноутбуке тормозит")

 

Увы но результаты сканирование зачастую не говорят ни о чём т.к. в результатах только 802.11 устройства, тогда как очень часто проблема деградации скорости в совсем других устройствах так же работающих в 2.4ГГц которые сканер не увидит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Увы но результаты сканирование зачастую не говорят ни о чём т.к. в результатах только 802.11 устройства, тогда как очень часто проблема деградации скорости в совсем других устройствах так же работающих в 2.4ГГц которые сканер не увидит.

По опыту эксплуатации >1000 устройств, самая главная причина деградации скорости это когда один канал обсели несколько десятков AP-шек. Встроенный сканер просто глотком воздуха оказался, помогая саппорту оперативно разрулить ситуацию без необходимости выезда на адрес сотрудника.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да да. Поставьте рядом 2 АП, разнесите по каналам ну пусть 1 и 6. Запустите на одной iperf в 16 потоков, затем параллельно на другой. Убедитесь что всё сдохло почти до уровня GPRS. Теперь проделайте тоже самое выставив один и тот же канал. Вы будете сильно удивлены результату. =)

 

Самая главная причина деградации скорости в 2.4 это его сверхзагаженность. Потому повторюсь, дуалбэнд и только дуалбэнд для таких инсталляций.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день.

Пробую поднять L2TP Server для доступа в Lan из Wan.

System Platform - MT7620 2T2R 2.4GHz, 100FDX

Firmware Version - 5.0.19.RU.09022017

 

Services - L2TP Server - Включен по умолчанию, плюс Allow debug.

Пароль test - test.

 

System Log:

Feb 13 02:49:12 vpn-server: One or more users need be configured. Stop.
Feb 13 02:49:12 kernel: ASSOC Assign 11n HT STA - AID=1 14:bb:6e:7c:e0:a5
Feb 13 02:49:12 kernel: ASSOC - Update AP OperaionMode=2 , fAnyStationIsLegacy=0, fAnyStation20Only=1, fAnyStationNonGF=1
Feb 13 02:49:12 udhcpd[28929]: sending ACK to 192.168.1.151
Feb 13 02:49:13 udhcpd[28929]: sending ACK to 192.168.1.202
Feb 13 02:49:14 udhcpd[28929]: sending ACK to 192.168.1.236
Feb 13 02:49:16 kernel: br0: port 1(eth2.1) entered forwarding state
Feb 13 02:49:17 kernel: br0: port 2(ra0) entered forwarding state
Feb 13 02:50:29 iptables: Add netfiler rules
Feb 13 02:50:29 iptables: Allow established/related in input
Feb 13 02:50:29 iptables: Service limit set
Feb 13 02:50:29 iptables: DHCP server allow
Feb 13 02:50:29 iptables: Dnsproxy allow to connect
Feb 13 02:50:29 iptables: Add vpnfilter rules for L2TP
Feb 13 02:50:29 iptables: Remote managment web limit
Feb 13 02:50:29 iptables: Remote managment ssh limit
Feb 13 02:50:29 iptables: Remote managment telnet limit
Feb 13 02:50:29 iptables: Allow rate limited ping from all interfaces.
Feb 13 02:50:29 iptables: Set forward rules
Feb 13 02:50:29 iptables: Add forward chain for vpnserver
Feb 13 02:50:29 iptables: Allow forward from LAN to any
Feb 13 02:50:29 iptables: Add SNAT from 192.168.1.1/255.255.255.0 to 185.0.0.0 at eth2.2.
Feb 13 02:50:29 iptables: Allow established/related in forward
Feb 13 02:50:30 vpn-server: Start l2tp vpn server
Feb 13 02:50:35 xl2tpd[29354]: Using l2tp kernel support.
Feb 13 02:50:35 xl2tpd[29356]: xl2tpd version xl2tpd-1.3.8 started on Wive-NG-MT PID:29356
Feb 13 02:52:04 dropbear[29361]: Child connection from 192.168.1.151:53213
Feb 13 02:52:12 dropbear[29361]: Password auth succeeded for 'Admin' from 192.168.1.151:53213
Feb 13 02:53:06 kernel: ESW: Link Status Changed - Port2 Link Down
Feb 13 02:53:50 dropbear[29361]: Exit (Admin): Error reading: Connection timed out
Feb 13 02:56:50 kernel: ESW: Link Status Changed - Port2 Link Up
Feb 13 02:56:50 udhcpd[28929]: sending ACK to 192.168.1.151
Feb 13 02:57:16 iptables: Add netfiler rules
Feb 13 02:57:16 iptables: Allow established/related in input
Feb 13 02:57:16 iptables: Service limit set
Feb 13 02:57:16 iptables: DHCP server allow
Feb 13 02:57:16 iptables: Dnsproxy allow to connect
Feb 13 02:57:16 iptables: Add vpnfilter rules for L2TP
Feb 13 02:57:16 iptables: Remote managment web limit
Feb 13 02:57:16 iptables: Remote managment ssh limit
Feb 13 02:57:16 iptables: Remote managment telnet limit
Feb 13 02:57:17 iptables: Allow rate limited ping from all interfaces.
Feb 13 02:57:17 iptables: Set forward rules
Feb 13 02:57:17 iptables: Add forward chain for vpnserver
Feb 13 02:57:17 iptables: Allow forward from LAN to any
Feb 13 02:57:17 iptables: Add SNAT from 192.168.1.1/255.255.255.0 to 185.0.0.0 at eth2.2.
Feb 13 02:57:17 iptables: Allow established/related in forward
Feb 13 02:57:17 vpn-server: Stop l2tp vpn server
Feb 13 02:57:17 xl2tpd[29356]: death_handler: Fatal signal 15 received
Feb 13 02:57:18 vpn-server: Start l2tp vpn server
Feb 13 02:57:23 xl2tpd[29532]: Using l2tp kernel support.
Feb 13 02:57:23 xl2tpd[29532]: xl2tpd version xl2tpd-1.3.8 started on Wive-NG-MT PID:29532

 

[Wive-NG-MT@/]# netstat -au
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
udp        0      0 0.0.0.0:domain          0.0.0.0:*
udp        0      0 0.0.0.0:bootps          0.0.0.0:*
udp        0      0 0.0.0.0:l2f             0.0.0.0:*
udp        0      0 :::domain               :::*
[Wive-NG-MT@/]# iptables -L -n -v
Chain INPUT (policy DROP 176 packets, 17105 bytes)
pkts bytes target     prot opt in     out     source               destination
   0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
2154  166K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
 445 33600 servicelimit  all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
 708  484K l2tpsrvfwd  all  --  *      *       0.0.0.0/0            0.0.0.0/0
 348 20056 ACCEPT     all  --  br0    *       192.168.1.0/24       0.0.0.0/0
 360  464K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT 3915 packets, 777K bytes)
pkts bytes target     prot opt in     out     source               destination

Chain l2tpsrvfwd (1 references)
pkts bytes target     prot opt in     out     source               destination

Chain servicelimit (1 references)
pkts bytes target     prot opt in     out     source               destination
   1   334 ACCEPT     udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:67
 127  7389 ACCEPT     udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
   0     0 ACCEPT     tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:53
   4  1648 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:500
   0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 500,1701,4500
   0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport sports 500,1701,4500
   0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 #conn src/32 > 16 reject-with icmp-port-unreachable
 136  7072 ACCEPT     tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:80
   0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:22 #conn src/32 > 4 reject-with icmp-port-unreachable
   1    52 ACCEPT     tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:22
   0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:23 #conn src/32 > 4 reject-with icmp-port-unreachable
   0     0 ACCEPT     tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:23
   0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8 limit: avg 10/sec burst 5
   0     0 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
   0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmp !type 8

 

Как не пробовал настроить клиента на Windows, по дебагу чисто, как будто даже нет попыток подключится.

Подскажите пожалуйста куда копать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

   0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 500,1701,4500
   0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport sports 500,1701,4500

 

А их и нет (попыток), счётчики пустые. Т.е. ниодого пакета на 1701 порт не пришло в принципе. Так что выясняйте у провайдеров посередине кто дропает udp на 1701 порт (читай блокирует l2tp) ну или винда ваша и не пытается соедениться...

 

 

P.S. И в 100й раз. Перед тем как писать всегда обновляйте ПО до текущей актуальной версии. С софтом даже месячной давности никто разбираться не будет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ну или винда ваша и не пытается соедениться...

Так и есть.

Имея другие, зашифрованные IPSec, L2TP подключения на компьютере, ни в какую не подключится к серверу на роутере.

Попробовал с соседнего компьютера, с такой же Windows 7, и всё заработало без танцев с бубном.

Решение оказалось на поверхности, отключаем проверку подлинности ЦС при подключении -

"ProhibitIpSec"=dword:00000001

"AllowL2TPWeakCrypto"=dword:00000001

Спасибо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день.

Установили роутер абоненту, увидели интересную картину на графиках доступности устройства.

graph_image.png

На канале проблем нет, потери пакетов тоже.

Как кажется, такая картина может быть вызвана -

# allow ratelimit ping request

iptables -A servicelimit -p icmp --icmp-type echo-request -m limit --limit 10/s -j ACCEPT

iptables -A servicelimit -p icmp --icmp-type echo-request -j DROP

Если так, то какой лимит выставить?

П.С. Мониторинг Cacti - Advanced Ping.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну да в лимит влетаете видимо. Я не очень понимаю в чём тайный смысл постоянно дрючить клиента icmp echo. Увеличивайте интервал опроса пингом устройства.

 

Я не в курсе как именно Cacti - Advanced Ping реализует опрос. Сериями через интервал или равномерно и постоянно по таймеру тикают. Но интервал для icmp echo должен быть больше десятой доли секунды (при опросе). По дефолту у ping (у самой обычной консольной команды) интервал 1 icmp echo в секунду т.е. лимит достаточно высок что бы не вносить проблем.

 

Как там у какти ХЗ.

 

Я бы (если бы стояла цель мониторить доступность) вообще бы слал бы раз в минуту или даже больше серию из 10тка пакетов большого размера с интервалом в 1s.

 

Надо понимать какая цель ставиться. Если проверить доступность устройства то это хотя бы один ответ пинга можно считать устройство уже доступно. Кстати тоже не факт. Запросто может колом всё встать, но ядро будет усиленно отвечать пингами, или наоборот канал будет забит пользовательскими данными которые аппаратно нащёлкал блок PPE, а ответы на icmp echo банально будут постоянно висеть в софт очереди и умирать не долетая до вопрошающего. Т.е. такой опрос почти ни о чём не говорит.

 

Если стоит цель тестировать трассу, то наверное имеет смысл мониторить потери до вашей конечной точки ответственности (домовой свитч) и только по необходимости (если проблемы до домового коммутатора нет, а у юзверя есть, при этом линк в норме и ошибок на портах коммутатора не наблюдается, взрывной рост которых зачастую гораздо более информативен чем пинание CPE).

 

ИМХО не очень хорошая идея создавать шум в сторону пользователя icmp-echo. Эти данные почти ничего не дают относительно тех данных которые можно снять с порта коммутатора.

 

Но это всё вопросы уже из другой темы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ИМХО не очень хорошая идея создавать шум в сторону пользователя icmp-echo. Эти данные почти ничего не дают относительно тех данных которые можно снять с порта коммутатора.

В текущий момент цель отслеживание качества линка, там на пути радимост, скоро поставим на объект свою активку и не будем "теранить" роутер.

Попробую, временно, поиграться со значением --limit.

Без fs save - ребут роутера спасёт от возможных ошибок?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В текущий момент цель отслеживание качества линка, там на пути радимост, скоро поставим на объект свою активку и не будем "теранить" роутер.

 

А... Вот оно что.

 

Попробую, временно, поиграться со значением --limit.

 

Да добавьте тогда правило что бы с адреса пинговалки отвечал без лимита перед лимит правилом. Ну раз один фиг решение временное.

 

iptables -A servicelimit -s адрес_пинговалки -p icmp --icmp-type echo-request -j ACCEPT

 

Без fs save - ребут роутера спасёт от возможных ошибок?

 

Не очень понял от каких ошибок спасёт? =) Для экспериментов можете менять правила на лету и применять их по service iptables restart или вообще непосредственно руками через iptables крутить.

 

Изменения не будут сохраняться пока fs save не скажете, т.е. после ребута rwfs будет снова загружена с флэша, где если не сказать fs save, будет версия до правок. Т.е. ваших изменений не будет.

 

Однако будьте аккуратны. Совсем не сложно правя логику инита поставить устройво раком вплоть до необходимости подключения консоли для восстановления.

 

Что бы избежать таких казусов в части работы с iptables сделаны хуки https://sourceforge.net/p/wive-ng/wive-ng-mt/ci/master/tree/README Т.е. возможность исполнения пользовательских скриптов с вызовом из опредёленных мест и даже если в них будет ошибка то это не приведёт к остановке загрузки и в крайнем случае для восстановления работы достаточно будет нажать резет. Ну и плюс это решает проблему когда я правлю что-то в скриптовой логике, а потом вам приходиться уже в другом месте что-то править.

 

P.S. Для проверки лимит ли виноват или что-то ещё достаточно вообще просто сказать iptables -I servicelimit -p icmp --icmp-type echo-request -j ACCEPT Т.е. добавить разрешающее правило без всяких лимитов в самое начало таблицы servicelimit.

 

PP.S. Кроме лимита на уровне нетфильтра, ядро само лимитирует icmp, настройки меняются через sysctl (сделать постоянными можно добавив опции в /etc/sysctl.conf). Текущие настройки лимита для icmp в ядре:

net.ipv4.icmp_ratelimit = 1000
net.ipv4.icmp_ratemask = 6168

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

цель отслеживание качества линка

 

Вот тут кстати может быть ещё одна засада. В радио сейчас модно стало использовать TxOP. Т.е. на уровне драйвера классифицируют трафик и исходя из этого крутят модуляции, параметры tx retry и т.д. per packet. В итоге icmp зачастую, как и для ManagmentFrames бегают на самых низких доступных модуляциях. Т.е. то что icmp бегает и бегает без потерь никак не говорит, что линк работает нормально и что потерь на том же UDP/TCP не будет, или что оно вообще как-то будет ходить. ;)

 

Но это опять таки уже вопрос совсем другой темы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не очень понял от каких ошибок спасёт? =)

Как говорится, ковыряние в удалённом фаерволе - к дальней дороге.

А тут ещё момент, что жезезка за 15 км от меня.

 

Вот тут кстати может быть ещё одна засада.

С радио там всё нормально, всё снимается по SNMP, тут задача простая как "бревно".

На составном канале, местами не подконтрольном, мониторить наличие связи.

 

П.С. Спасибо за помощь, разобрался, кстати ровно 20 пакетов в секунду - действительно всё удобно.

Забываем, что это "сохо роутер", общаемся просто с Lin машиной.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

П.С. Спасибо за помощь, разобрался, кстати ровно 20 пакетов в секунду - действительно всё удобно.

Забываем, что это "сохо роутер", общаемся просто с Lin машиной.

 

Могу по дефолту увеличить в софте тогда лимит. 10 или 20 для решения задачи защиты от зафлуживания разницы нет. Т.е. можно несколько увеличить дефолт. Наверное так и сделаю.

 

Забываем, что это "сохо роутер", общаемся просто с Lin машиной.

 

Ну собсно да, именно так и есть, маленький Linux ноги у которого ооооооооочень давно выросли из uClinux (правда от него в чистом виде ничего не осталось). И инит скриптовый тоже не спроста тяну в то время как даже на больших системах во всю шизофрения со всякими systemd. Как бы задача дать чловеку с мозгом свободу делать, что он захочет при этом оставить web в максимально лаконичном виде что бы и блондинка могла настроить.

 

P.S. Увеличил дефолт до 25/s (36кбит флуда 1500байт пакетами не страшно). C 5.3.7 будет в сборках.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Как говорится, ковыряние в удалённом фаерволе - к дальней дороге.

А тут ещё момент, что жезезка за 15 км от меня.

 

Ну эт да =)

 

С радио там всё нормально, всё снимается по SNMP, тут задача простая как "бревно".

 

Ну я не грю что ненормально. Но вот такие подвыверты могут сильно осложнить мониторинг на основе icmp echo. Т.к. по пингам например будет всё ОК. А по факту...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Подскажите если можно, vpn не получается поднять между CPE-MD1 и CPE-W4N-MT. Нужно заставить W4N ходить в инет через MD1. Прошивка на обоих последняя на текущий момент от 28.04. ppp0 в кач-ве основного шлюза постоянно отваливается, и в VPN Client состояние из Online переходит в Connecting.. Логи в текстовике приложил.

vpn.txt

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

С роутами беда. Пропишите статик роут до VPN сервера через DGW по WAN который выдаётся через DHCP затем настраивайте туннель. Иначе у вас сейчас поднимается туннель и в него перекидывается DGW после чего всё умирает. Он просто незнает куда слать и откда принимать пакеты. Для большинтсва случаев оно само всё что надо добавляет, но... Глядя в лог ничего другого в голову не приходит навскидку.

 

Может где-то подсети пересекаются. Или клиент и сервер в одной подсети но при этом должны ходить один фиг через DGW. Такие случае прошивка сама не в силах задетектить. Тут ИИ нужен. =)

 

P.S. Для проверки догадки можно убрать галку DGW в настройках клиента, если обрывы прекратятся то копаем в эту сторону дальше.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Давайте уже в профильный раздел с описанием схемы тестирования, описанием устройств, со скринами рожи и т.д. А то разговоры про обычный порошок и другие роутеры не дадут нужного результата как ни крути.

post-104634-056398700 1495182184_thumb.png

post-104634-048069000 1495182172_thumb.png

 

post-104634-052543300 1495183744_thumb.png

post-104634-056866600 1495182178_thumb.png

post-104634-079726900 1495183579_thumb.png

 

6309266034.png

 

Тот же ноут, но роутер другой (Кинетик гига 3)

6309276607.png

 

post-104634-000937800 1495183210_thumb.png

 

на md1 сеть wifi Wive-NG-MT,на другом OfficeUN.

Изменено пользователем DinarD

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Роутер SNR-CPE-W4N

Версия ПО 4.3.14.RU.17052016

Платформа MT7620 2T2R 2.4GHz, 100FDX

Настроен в режиме роутера. Реквизиты статикой(один IP), в остальном настройки роутера не изменялись.

Сеть из себя представляет: роутер SNR-CPE-W4N, включен wifi (максимум 3 девайса). В LAN порт роутера включен 8-ми портовый dlink (должен быть неуправляемый). В dlink стянуты парочка ПК и принтер.

-------

Проблема:

Каждые 5 минут пропадает связь из LAN до внешней сети. Пингплоттер (ПК по кабелю в LAN) показывает отсутствие потерь до LAN-интерфейса (192.168.1.1) и наличие потерь до всех внешних IP.

Пинги из LAN. Скрины пингплоттера:

https://vk.com/photo74628755_456239271

https://vk.com/photo74628755_456239272

Потерь из внешних сетей до WAN-интерфейса нет. Отсюда делаю вывод, что какая-то проблема на роутере с перекладкой трафика из LAN в WAN, возможно, что-то с NAT. В логах в момент проблемы чисто. Снять дампы трафика за роутером(с WAN) проблематично, т.к. оператор связи не расторопный.

 

Может кто-то сталкивался с проблемой, что можете посоветовать?

Вопрос на опережение: при обновлении прошивки конфиг слетит(планирую обновиться удалённо)?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

думаю что однозначно обновляться, резетить и конфигурить заново руками, потом повторно снимать лог. И тут же вроде видно что потери на экстриме. Что трэйс до других узлов говорит?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Второй хоп 91.229.235.193 - это AS57003 91.229.234.0/23 PortalTeleNet LLC - там и включен роутер. Потери не на экстриме, а в том провайдере, к которому подключен. Иначе говоря сразу за WAN-интерфейсом роутера.

Трейс до других хостов аналогичен, потери за роутером.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Второй хоп 91.229.235.193 - это AS57003 91.229.234.0/23 PortalTeleNet LLC - там и включен роутер. Потери не на экстриме, а в том провайдере, к которому подключен. Иначе говоря сразу за WAN-интерфейсом роутера.

Трейс до других хостов аналогичен, потери за роутером.

 

Ну дык и разбирайтесь с тем что выше WAN роутера. Шнурки и т.д... Может длинк прёт и т.д. С чего вывод что проблема в роутере?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.