Печаль 
. Опять страницы, видео со второго-третьего раза, непонятная задумчивость браузера там, где её не должно быть. У меня одного так?
Добавлено спустя 18 минут 36 секунд
-
# 14 мая 2015 20:30 Редактировалось budgerigar, 2 раз(а).
-
Senior MemberофлайнSenior Member
12712
21 год на сайте
пользователь #560212712# 14 мая 2015 21:17 Редактировалось Daimos, 1 раз.PING mtis.by (91.149.157.142): 64 data bytes
72 bytes from 91.149.157.142: seq=0 ttl=57 Time=3.427 ms72 bytes from 91.149.157.142: seq=1 ttl=57 Time=3.026 ms
72 bytes from 91.149.157.142: seq=2 ttl=57 Time=12.376 ms
72 bytes from 91.149.157.142: seq=3 ttl=57 Time=3.379 ms
72 bytes from 91.149.157.142: seq=4 ttl=57 Time=2.111 ms
72 bytes from 91.149.157.142: seq=5 ttl=57 Time=3.257 ms
72 bytes from 91.149.157.142: seq=6 ttl=57 Time=3.777 ms
72 bytes from 91.149.157.142: seq=7 ttl=57 Time=2.944 ms
72 bytes from 91.149.157.142: seq=8 ttl=57 Time=3.004 ms
72 bytes from 91.149.157.142: seq=9 ttl=57 Time=3.093 ms
72 bytes from 91.149.157.142: seq=10 ttl=57 Time=2.947 ms
72 bytes from 91.149.157.142: seq=11 ttl=57 Time=3.101 ms
72 bytes from 91.149.157.142: seq=12 ttl=57 Time=3.264 ms
72 bytes from 91.149.157.142: seq=13 ttl=57 Time=1.657 ms
72 bytes from 91.149.157.142: seq=15 ttl=57 Time=3.067 ms
72 bytes from 91.149.157.142: seq=16 ttl=57 Time=3.614 ms
72 bytes from 91.149.157.142: seq=17 ttl=57 Time=2.865 ms
72 bytes from 91.149.157.142: seq=19 ttl=57 Time=3.592 ms
72 bytes from 91.149.157.142: seq=21 ttl=57 Time=2.623 ms
72 bytes from 91.149.157.142: seq=22 ttl=57 Time=3.099 ms
72 bytes from 91.149.157.142: seq=23 ttl=57 Time=2.553 ms
72 bytes from 91.149.157.142: seq=24 ttl=57 Time=2.013 ms
72 bytes from 91.149.157.142: seq=25 ttl=57 Time=3.485 ms
72 bytes from 91.149.157.142: seq=26 ttl=57 Time=11.142 ms
72 bytes from 91.149.157.142: seq=27 ttl=57 Time=2.661 ms
72 bytes from 91.149.157.142: seq=28 ttl=57 Time=3.007 ms
72 bytes from 91.149.157.142: seq=29 ttl=57 Time=1.762 ms
72 bytes from 91.149.157.142: seq=30 ttl=57 Time=2.661 ms
72 bytes from 91.149.157.142: seq=31 ttl=57 Time=2.046 ms
72 bytes from 91.149.157.142: seq=32 ttl=57 Time=3.029 ms
72 bytes from 91.149.157.142: seq=33 ttl=57 Time=3.278 ms
72 bytes from 91.149.157.142: seq=34 ttl=57 Time=3.205 ms
72 bytes from 91.149.157.142: seq=35 ttl=57 Time=3.022 ms
72 bytes from 91.149.157.142: seq=36 ttl=57 Time=3.485 ms
72 bytes from 91.149.157.142: seq=37 ttl=57 Time=3.170 ms
72 bytes from 91.149.157.142: seq=38 ttl=57 Time=1.604 ms
72 bytes from 91.149.157.142: seq=39 ttl=57 Time=3.073 ms
72 bytes from 91.149.157.142: seq=40 ttl=57 Time=3.009 ms
72 bytes from 91.149.157.142: seq=41 ttl=57 Time=5.903 ms
72 bytes from 91.149.157.142: seq=42 ttl=57 Time=2.061 ms
72 bytes from 91.149.157.142: seq=43 ttl=57 Time=2.878 ms
72 bytes from 91.149.157.142: seq=44 ttl=57 Time=2.398 ms
72 bytes from 91.149.157.142: seq=45 ttl=57 Time=2.809 ms
72 bytes from 91.149.157.142: seq=46 ttl=57 Time=3.030 ms
72 bytes from 91.149.157.142: seq=47 ttl=57 Time=2.314 ms
72 bytes from 91.149.157.142: seq=48 ttl=57 Time=3.197 ms
72 bytes from 91.149.157.142: seq=49 ttl=57 Time=3.048 ms
72 bytes from 91.149.157.142: seq=50 ttl=57 Time=2.919 ms
72 bytes from 91.149.157.142: seq=51 ttl=57 Time=2.542 ms
72 bytes from 91.149.157.142: seq=52 ttl=57 Time=2.910 ms
72 bytes from 91.149.157.142: seq=53 ttl=57 Time=3.290 ms
72 bytes from 91.149.157.142: seq=55 ttl=57 Time=4.909 ms
72 bytes from 91.149.157.142: seq=56 ttl=57 Time=3.393 ms
72 bytes from 91.149.157.142: seq=57 ttl=57 Time=2.522 ms
72 bytes from 91.149.157.142: seq=58 ttl=57 Time=2.116 ms
72 bytes from 91.149.157.142: seq=59 ttl=57 Time=3.009 ms
72 bytes from 91.149.157.142: seq=60 ttl=57 Time=2.981 ms
72 bytes from 91.149.157.142: seq=62 ttl=57 Time=2.995 ms
72 bytes from 91.149.157.142: seq=63 ttl=57 Time=3.415 ms
72 bytes from 91.149.157.142: seq=64 ttl=57 Time=2.941 ms
72 bytes from 91.149.157.142: seq=65 ttl=57 Time=2.946 ms
72 bytes from 91.149.157.142: seq=66 ttl=57 Time=2.844 ms
72 bytes from 91.149.157.142: seq=67 ttl=57 Time=29.998 ms
72 bytes from 91.149.157.142: seq=68 ttl=57 Time=1.993 ms
72 bytes from 91.149.157.142: seq=69 ttl=57 Time=1.646 ms
72 bytes from 91.149.157.142: seq=70 ttl=57 Time=3.082 ms
72 bytes from 91.149.157.142: seq=71 ttl=57 Time=2.710 ms
72 bytes from 91.149.157.142: seq=73 ttl=57 Time=3.044 ms
72 bytes from 91.149.157.142: seq=74 ttl=57 Time=4.254 ms
72 bytes from 91.149.157.142: seq=75 ttl=57 Time=15.185 ms
72 bytes from 91.149.157.142: seq=76 ttl=57 Time=2.829 ms
72 bytes from 91.149.157.142: seq=77 ttl=57 Time=1.713 ms
72 bytes from 91.149.157.142: seq=78 ttl=57 Time=11.039 ms
72 bytes from 91.149.157.142: seq=79 ttl=57 Time=3.019 ms
72 bytes from 91.149.157.142: seq=80 ttl=57 Time=3.583 ms
72 bytes from 91.149.157.142: seq=81 ttl=57 Time=5.603 ms
72 bytes from 91.149.157.142: seq=82 ttl=57 Time=3.335 ms
72 bytes from 91.149.157.142: seq=83 ttl=57 Time=3.423 ms
72 bytes from 91.149.157.142: seq=84 ttl=57 Time=3.185 ms
--- mtis.by data statistics ---
85 Packets transmitted, 79 Packets received, 7% Packet loss
round-trip min/avg/max = 1.604/3.815/29.998 ms
Как-то так у меня.
На потерю ICMP пакетов я бы сильно внимания не обращал - это не приоритетный траффик.
[Паяльник & Отвертка TEAM] -
# 15 мая 2015 02:28
Daimos:
PING mtis.by (91.149.157.142): 64 data bytes
--- mtis.by data statistics ---
85 Packets transmitted, 79 Packets received, 7% Packet loss
round-trip min/avg/max = 1.604/3.815/29.998 ms
Как-то так у меня.
На потерю ICMP пакетов я бы сильно внимания не обращал - это не приоритетный траффик.
Т.е. узлы определяют наличие ICMP пакетов и если плохо с пропускной способностью не передают их?
Старая отмазка про приоритет ICMP на оконечном узле, при теперешних мощностях. А что с промежуточными узлами? Они ICMP-траффик, как и всё остальное не могут терять?
Забавно. А как же всё тогда проверяется на наличие проблем? Когда администратору не лень статистику посмотреть? Или можно (проще всего) настроить всё через ж**у так, чтобы не дать клиенту видеть ситуацию на обратном пути?
Или всё-таки это признак перегрузки узла (сервера)?
Жаль, что traceroute не запустили, пожалели коллег. ICMP-трассировка узлов для динамических IP по-прежнему отключена. Помнится, когда она была открыта, очень хорошо были видны перегруженные узлы МТИСа и Белтелекома(?).А это ведь не один "mtis.by" так звонился. Такая же картина и google, и прочими. Может они (конечные узлы) все были перегружены?
Картина чуть попозже:
-
Senior MemberофлайнSenior Member
12712
21 год на сайте
пользователь #560212712# 15 мая 2015 10:29budgerigar:
Т.е. узлы определяют наличие ICMP пакетов и если плохо с пропускной способностью не передают их?
Старая отмазка про приоритет ICMP на оконечном узле, при теперешних мощностях. А что с промежуточными узлами? Они ICMP-траффик, как и всё остальное не могут терять?Сеть интернет изначально разрабатывалась как сеть с потерями пакетов. Поэтому TCP\IP использует подтверждение приема пакетов и повторную посылку потерянных и качество передачи данных от этого не пострадает - только немного скорость уменьшиться.
Забавно. А как же всё тогда проверяется на наличие проблем? Когда администратору не лень статистику посмотреть? Или можно (проще всего) настроить всё через ж**у так, чтобы не дать клиенту видеть ситуацию на обратном пути?
Или всё-таки это признак перегрузки узла (сервера)?
Жаль, что traceroute не запустили, пожалели коллег. ICMP-трассировка узлов для динамических IP по-прежнему отключена. Помнится, когда она была открыта, очень хорошо были видны перегруженные узлы МТИСа и Белтелекома(?).
А это ведь не один "mtis.by" так звонился. Такая же картина и google, и прочими. Может они (конечные узлы) все были перегружены?Да без понятия как у них что и как у них там диагностируется - я в МТИС не работаю, я сисадмин в немелкой софтверной конторе.
У нас диагностируется сбором статистика по SNMP и по протоколу NetFlow.[Паяльник & Отвертка TEAM] -
# 16 мая 2015 13:49
Daimos:
budgerigar:
Т.е. узлы определяют наличие ICMP пакетов и если плохо с пропускной способностью не передают их?
Старая отмазка про приоритет ICMP на оконечном узле, при теперешних мощностях. А что с промежуточными узлами? Они ICMP-траффик, как и всё остальное не могут терять?Сеть интернет изначально разрабатывалась как сеть с потерями пакетов. Поэтому TCP\IP использует подтверждение приема пакетов и повторную посылку потерянных и качество передачи данных от этого не пострадает - только немного скорость уменьшиться.
Не хочется спорить
. Проблема в том, что разрабатывалась когда-то.
TCP надёжен до определенной степени. Потерялся пакет из очереди после повторной передачи - редкое событие, но оно бывает - разрыв TCP-соединения. Потерялся пакет в очереди на установку соединения, канала TCP ещё нет - итог - нельзя посмотреть видео или страницу открыть.
Daimos:
Забавно. А как же всё тогда проверяется на наличие проблем? Когда администратору не лень статистику посмотреть? Или можно (проще всего) настроить всё через ж**у так, чтобы не дать клиенту видеть ситуацию на обратном пути?
Или всё-таки это признак перегрузки узла (сервера)?
Жаль, что traceroute не запустили, пожалели коллег. ICMP-трассировка узлов для динамических IP по-прежнему отключена. Помнится, когда она была открыта, очень хорошо были видны перегруженные узлы МТИСа и Белтелекома(?).
А это ведь не один "mtis.by" так звонился. Такая же картина и google, и прочими. Может они (конечные узлы) все были перегружены?Да без понятия как у них что и как у них там диагностируется - я в МТИС не работаю, я сисадмин в немелкой софтверной конторе.
У нас диагностируется сбором статистика по SNMP и по протоколу NetFlow.Сколько раз можно об одном и том же писать.
У вас - администраторов - есть инструменты управления, известные в своей узкой среде - и они достаточно хорошие.
Но скажите, как мне, простому смертному, по SNMP v3 зайти по защищенному каналу и посмотреть статистику нагрузки маршрутизатора(ов)? Может вы поделитесь своими паролями? Лицензионным ПО, которое стоит денег (немалых для обычного смертного)?Я не понимаю, почему почему закрыли ICMP для промежуточных узлов.
Обратный маршрут пользователю не виден?
Ну и что? Есть же узел который отвечает за прямой маршрут. Если за ним все подряд узлы начинают терять ICMP, то о чём это говорит? Мне говорит, что связанные с ним узлы обратного маршрута (пусть они даже не видны), не обеспечивают качество.Daimos, не принимайте близко с сердцу.
Просто ребята МТИСе(?), закрыли ICMP для промежуточных узлов и опять расслабились, а ваши слова выглядят так, как будто у них есть оправдание. -
Senior MemberофлайнSenior Member
12712
21 год на сайте
пользователь #560212712# 16 мая 2015 14:03budgerigar, а зачем простому смертному смотреть нагрузку на маршрутизаторе? Это ему либо ничего не скажет, либо является служебной информацией, не подлежащей разглашению ( чтобы не знали конкуренты например)
ПО есть и бесплатное - и его масса - например Zabbix.
Почему закрыт ICMP - могу только гадать, что у них было на уме. Возможно есть косяки с его активацией и прохождением по узлам.
Что мешает вам купить за смешные деньги статический IP и пользоваться им без абонплаты? Для статики ICMP не отключен.
На форуме вам тут никто не ответит - они не читают ветку или просто игнорят сообщения тут. Надо писать им заказные письма - хотя все равно могут отбрехаться - ICMP не входит в перечень услуг как-бы.[Паяльник & Отвертка TEAM] -
# 16 мая 2015 17:24
Daimos:
Почему закрыт ICMP - могу только гадать, что у них было на уме. Возможно есть косяки с его активацией и прохождением по узлам.
Быстро ответили в этот раз. А что же вы промолчали тогда?
http://forum.onliner.by/viewtopic.php?t=5093969&p=65498272#p65498272
budgerigar:
У-у. BELARUSIANCLOUDTECHNOLOGIES (BeCloud datacom network phase 1) заработал
заглючил.
http://tech.onliner.by/2014/07/31/becloud-3/Добавлено спустя 11 минут 16 секундИнтересно, какие ещё будут неведомые сюрпризы?
Как вы думаете? Наверное я сам придумал эти названия для узлов? Ссылка1, Ссылка2.
Столько времени уже прошло, а там всё ещё "BeCloud datacom network phase 1".
Трассировка маршрута к google.com [173.194.113.9]
с максимальным числом прыжков 30:1 *
2 2 ms 2 ms 2 ms 172.16.0.20
3 3 ms 3 ms 2 ms 93.125.87.1
4 4 ms * * 185.32.224.201
5 29 ms 29 ms 29 ms de-cix20.net.google.com [80.81.193.108]
6 29 ms 29 ms 30 ms 209.85.251.150
7 30 ms 29 ms 31 ms 209.85.242.185
8 29 ms 29 ms 30 ms fra02s19-in-f9.1e100.net [173.194.113.9]Трассировка завершена.
05.08.2014 2:15:19,38
╤хЁтхЁ: google-public-dns-a.google.com
Address: 8.8.8.8╚ь : google.com
Addresses: 2a00:1450:4001:808::1001
173.194.113.8
173.194.113.4
173.194.113.2
173.194.113.14
173.194.113.3
173.194.113.9
173.194.113.6
173.194.113.1
173.194.113.7
173.194.113.5
173.194.113.005.08.2014 2:15:19,55
Трассировка маршрута к google.com [173.194.113.9]
с максимальным числом прыжков 30:
0 *
1 *
2 172.16.0.20
3 93.125.87.1
4 185.32.224.201
5 de-cix20.net.google.com [80.81.193.108]
6 209.85.251.150
7 209.85.242.185
8 fra02s19-in-f9.1e100.net [173.194.113.9]Подсчет статистики за: 200 сек. ...
Исходный узел Маршрутный узел
Прыжок RTT Утер./Отпр. % Утер./Отпр. % Адрес
0 *
0/ 100 = 0% |
1 *
0/ 100 = 0% |
2 3мс 0/ 100 = 0% 0/ 100 = 0% 172.16.0.20
0/ 100 = 0% |
3 --- 100/ 100 =100% 100/ 100 =100% 93.125.87.1
0/ 100 = 0% |
4 3мс 0/ 100 = 0% 0/ 100 = 0% 185.32.224.201
0/ 100 = 0% |
5 30мс 0/ 100 = 0% 0/ 100 = 0% de-cix20.net.google.com [80.81.193.108]
0/ 100 = 0% |
6 36мс 0/ 100 = 0% 0/ 100 = 0% 209.85.251.150
1/ 100 = 1% |
7 --- 100/ 100 =100% 99/ 100 = 99% 209.85.242.185
0/ 100 = 0% |
8 30мс 1/ 100 = 1% 0/ 100 = 0% fra02s19-in-f9.1e100.net [173.194.113.9]Трассировка завершена.
05.08.2014 2:19:44,86Трассировка маршрута к google.com [46.61.155.251]
с максимальным числом прыжков 30:1 *
2 2 ms 2 ms 3 ms 172.16.0.20
3 3 ms 2 ms 2 ms 93.125.87.1
4 3 ms 3 ms * 185.32.224.201
5 14 ms 14 ms 13 ms 188.254.79.149
6 14 ms 16 ms 13 ms 95.167.95.34
7 16 ms 13 ms 14 ms 46.61.155.251Трассировка завершена.
05.08.2014 16:19:01,37
╤хЁтхЁ: google-public-dns-a.google.com
Address: 8.8.8.8╚ь : google.com
Addresses: 2607:f8b0:4006:809::1005
46.61.155.29
46.61.155.30
46.61.155.25
46.61.155.49
46.61.155.59
46.61.155.40
46.61.155.55
46.61.155.34
46.61.155.39
46.61.155.50
46.61.155.20
46.61.155.54
46.61.155.45
46.61.155.44
46.61.155.35
46.61.155.2405.08.2014 16:19:01,55
Трассировка маршрута к google.com [46.61.155.251]
с максимальным числом прыжков 30:
0 *
1 *
2 172.16.0.20
3 93.125.87.1
4 * * *
Подсчет статистики за: 75 сек. ...
Исходный узел Маршрутный узел
Прыжок RTT Утер./Отпр. % Утер./Отпр. % Адрес
0 *
0/ 100 = 0% |
1 1мс 0/ 100 = 0% 0/ 100 = 0% 192.168.0.1
100/ 100 =100% |
2 --- 100/ 100 =100% 0/ 100 = 0% 172.16.0.20
0/ 100 = 0% |
3 --- 100/ 100 =100% 0/ 100 = 0% 93.125.87.1Трассировка завершена.
05.08.2014 16:21:01,8708.08.2014 14:59:50,82Трассировка маршрута к google.com [173.194.116.195]
с максимальным числом прыжков 30:1 2 ms 1 ms 3 ms *
2 2 ms 2 ms 2 ms 172.16.0.20
3 * * * Превышен интервал ожидания для запроса.
4 * * * Превышен интервал ожидания для запроса.
5 * * * Превышен интервал ожидания для запроса.
6 * * * Превышен интервал ожидания для запроса.
7 * * * Превышен интервал ожидания для запроса.
8 * * * Превышен интервал ожидания для запроса.
9 * * * Превышен интервал ожидания для запроса.
10 29 ms 30 ms 29 ms 173.194.116.195Трассировка завершена.
08.08.2014 15:01:30,54
╤хЁтхЁ: google-public-dns-a.google.com
Address: 8.8.8.8╚ь : google.com
Addresses: 2a00:1450:4001:80f::1009
173.194.113.73
173.194.113.78
173.194.113.72
173.194.113.68
173.194.113.66
173.194.113.64
173.194.113.67
173.194.113.65
173.194.113.69
173.194.113.70
173.194.113.7108.08.2014 15:01:30,80
Трассировка маршрута к google.com [173.194.116.195]
с максимальным числом прыжков 30:
0 *
1 *
2 172.16.0.20
3 * * *
Подсчет статистики за: 50 сек. ...
Исходный узел Маршрутный узел
Прыжок RTT Утер./Отпр. % Утер./Отпр. % Адрес
0 *
0/ 100 = 0% |
1 1мс 0/ 100 = 0% 0/ 100 = 0% *
100/ 100 =100% |
2 --- 100/ 100 =100% 0/ 100 = 0% 172.16.0.20Трассировка завершена.
08.08.2014 15:02:52,38Когда работала трассировка, то недолгое время, когда она была включена, когда переключали траффик на с узлов Белтелекома(Белпака) на BeCloud, было видно, что сразу после узлов "BeCloud datacom network phase 1" потери, так же как и на Белтелекоме(Белпаке).
Daimos:
На форуме вам тут никто не ответит - они не читают ветку или просто игнорят сообщения тут. Надо писать им заказные письма - хотя все равно могут отбрехаться - ICMP не входит в перечень услуг как-бы
Читают. С трассировкой был момент, не работало вообще, сделали нормально (см. "Как это ловилось 1" ).
Затем его хитро поправили, по-моему после упоминания в этой ветке BeCloud, - причём конечный узел виден (см. "Через три дня" )
.
Daimos:
ICMP не входит в перечень услуг как-бы
Daimos:
budgerigar, а зачем простому смертному смотреть нагрузку на маршрутизаторе? Это ему либо ничего не скажет, либо является служебной информацией, не подлежащей разглашению ( чтобы не знали конкуренты например)
Daimos:
Что мешает вам купить за смешные деньги статический IP и пользоваться им без абонплаты? Для статики ICMP не отключен.
Деньги плачены, всего лишь сервиса нормального хочу (см. "Как это ловилось 1" и "Через три дня" ).Daimos, простите, пожалуйста, что так с цитатами. Не принимайте близко с сердцу. Без вас скучно будет.
-
Senior MemberофлайнSenior Member
12712
21 год на сайте
пользователь #560212712# 16 мая 2015 18:02budgerigar, это форум - есть время почитать-ответить - могу ответить. Тем более не собираюсь оправдываться за левую контору для меня.
Что мне ответить было про биКлауд? Ни к нему, ни ко МТИСу я отношения не имею, разглагольствовать о том чего куда - не вижу особого смысла, и так забот хватает.Ну если найдете в договоре в любого провайдера ICMP - поржем вместе и я съем свою шляпу.
Ну может кто-то и прочитал - только могли прочитать на своем форуме например.Вот сейчас выглядит вот так трассировка, если вам интересно.
traceroute to 8.8.8.8 (8.8.8.
, 64 hops max, 52 byte packets
1 192.168.13.1 (192.168.13.1) 6.176 ms 0.571 ms 6.541 ms
2 * * *
3 172.16.3.7 (172.16.3.7) 11.548 ms 11.224 ms 15.740 ms
4 isp.belpak.by (86.57.252.137) 11.608 ms 11.855 ms 18.411 ms
5 ie2.net.belpak.by (93.85.80.137) 13.971 ms 16.361 ms 14.386 ms
6 * * *
7 * * *
8 216.239.48.3 (216.239.48.3) 112.062 ms
216.239.47.249 (216.239.47.249) 90.941 ms
216.239.47.251 (216.239.47.251) 36.064 ms
9 72.14.234.165 (72.14.234.165) 41.896 ms
216.239.46.177 (216.239.46.177) 38.724 ms
72.14.238.207 (72.14.238.207) 39.298 ms
10 google-public-dns-a.google.com (8.8.8. 37.659 ms 39.470 ms 37.981 msЕсли я для Вас тут роль клоуна изображаю или шута - то увольте, лучше в цирк сходить.
[Паяльник & Отвертка TEAM] -
# 16 мая 2015 20:39
Вечер субботы, статический адрес МТИС
Добавлено спустя 6 секундТрассировка маршрута к google-public-dns-a.google.com [8.8.8.8]
с максимальным числом прыжков 30:1 2 ms 1 ms 1 ms MTISGATE [192.168.27.20]
2 49 ms 2 ms 2 ms 172.16.0.5
3 83 ms 2 ms 5 ms 172.16.3.7
4 84 ms 3 ms 2 ms isp.belpak.by [86.57.252.137]
5 8 ms 5 ms 6 ms ie2.net.belpak.by [93.85.80.137]
6 * * * Превышен интервал ожидания для запроса.
7 * * * Превышен интервал ожидания для запроса.
8 32 ms * 94 ms 216.239.48.3
9 30 ms 30 ms 30 ms 209.85.241.121
10 113 ms 31 ms 29 ms google-public-dns-a.google.com [8.8.8.8]Добавлено спустя 1 минута 14 секундпо wifi
Добавлено спустя 46 секундбез отключения остальных пользователей
-
# 16 мая 2015 22:08
Daimos, спасибо за адреса промежуточных узлов.
ping 86.57.252.137Обмен пакетами с 86.57.252.137 по с 32 байтами данных:
Ответ от 86.57.252.137: число байт=32 время=5мс TTL=252
Превышен интервал ожидания для запроса.
Ответ от 86.57.252.137: число байт=32 время=6мс TTL=252
Ответ от 86.57.252.137: число байт=32 время=3мс TTL=252Статистика Ping для 86.57.252.137:
Пакетов: отправлено = 4, получено = 3, потеряно = 1
(25% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 3мсек, Максимальное = 6 мсек, Среднее = 4 мсекtracert 86.57.252.137
Трассировка маршрута к isp.belpak.by [86.57.252.137]
с максимальным числом прыжков 30:1 3 ms 2 ms 1 ms *
2 5 ms 2 ms 2 ms 172.16.0.20
3 * * * Превышен интервал ожидания для запроса.
4 3 ms 4 ms 3 ms isp.belpak.by [86.57.252.137]Трассировка завершена.
tracert 93.85.80.137
Трассировка маршрута к ie2.net.belpak.by [93.85.80.137]
с максимальным числом прыжков 30:1 1 ms 1 ms 1 ms *
2 4 ms 4 ms 2 ms 172.16.0.20
3 * * * Превышен интервал ожидания для запроса.
4 * * * Превышен интервал ожидания для запроса.
5 11 ms 11 ms 13 ms ie2.net.belpak.by [93.85.80.137]Трассировка завершена.
tracert 216.239.48.3
Трассировка маршрута к 216.239.48.3 с максимальным числом прыжков 30
1 9 ms 3 ms 4 ms *
2 3 ms 2 ms 2 ms 172.16.0.20
3 * * * Превышен интервал ожидания для запроса.
4 * * * Превышен интервал ожидания для запроса.
5 * * * Превышен интервал ожидания для запроса.
6 * * * Превышен интервал ожидания для запроса.
7 * * * Превышен интервал ожидания для запроса.
8 31 ms 28 ms 29 ms 216.239.48.3Трассировка завершена.
Это удивительно, но узлы Белпака трассируются. Похоже на то, что "умелец" написал/настроил фильтр ICMP, который отбрасывает все приходящие ICMP-пакеты к абоненту с динамическим адресом, кроме ICMP-пакета от конечного узла. Думаю так решение задачи оказалось проще, иначе бы пришлось целую актуальную таблицу адресов всё время поддерживать, чтобы скрыть адреса части узлов.
-
-
Urban rollerофлайнUrban roller
34351
21 год на сайте
пользователь #841234351Я не люблю спорт - я люблю экстрим! Я не люблю ЗОЖ - я люблю адреналин! -
# 17 мая 2015 13:04
Zloy Zhuk:
чет сегодня турбоночи нет?
Zloy Zhuk, не знаю. Не всегда, но ночью спать хочется, а не заниматься очередным тестированием сети. Надо было результат сохранить, а то ребята с Белпак-МТИС будут отрицать наличие проблем. У них действительно их может не быть, поскольку у меня интернет через другой сегмент сети BeCloud-МТИС.
У вас статический или динамический ip?lobank:
Daimos:
lobank:
Нет, конечно! Не у тебя одного!
Перестаньте писать про то, что когда-то было. Человек спрашивает про текущую ситуацию.
Еще раз повторю, для неумеющих ВНИМАТЕЛЬНО читать: "еще пара человек в соседнем подъездеждут окончания контракта". Так что узнать "как дела с мтис?" - никаких проблем! ВСЕ ПО ПРЕЖНЕМУ!
Кстати, budgerigar обрати внимание Daimos параллельно тоже держит подключение по адсл. На нем дети мультики у него смотрят! (не буду ставить смайлик - он думает, что смайлы НАД НИМ смеются?!).
Понимаете, Daimos, рассматривает меня как обычного пользователя-незнайку. Не всем дано стать системным администратором, я им тоже не являюсь. Но кое-какие базовые вещи мне понятны и доступны, например, http://www.gossamer-threads.com/lists/cisco/nsp/26987, там люди объясняют как сделать список для блокировки ICMP-ответов от внутренних маршрутизаторов сети.
С другой стороны, если бы Daimos, не публиковал результаты traceroute с узлами МТИС и не объяснял некоторые другие вещи, не базовые, было бы скучно. Кроме того, думаю, он боится, что ребята из МТИС, разломают действующую систему маршрутизации, и тогда всем будет несладко. Кстати, когда её ломали в прошлом году, было неприятно.
Я бы посоветовал подумать ему (Daimos и прочим) о BeCloud, потому что эту вещь кто-то упорно продвигает (http://tech.onliner.by/2015/05/07/becloud-5/) и творятся вещи, которые не только я считаю неправильными, но и другие http://www.gossamer-threads.com/lists/cisco/nsp/26987 (ветке уже 10 лет как), вместе с признаками перегрузки (?) оборудования (например, http://habrahabr.ru/post/111990), которые наблюдал я, как пользователь.
Также советую почитать http://tech.onliner.by/2015/05/07/becloud-4.Я не против(!) BeCloud, как такового. Но так резать сервисы при таком качестве маршрутизации это слишком.
Добавлено спустя 1 час 26 минут 41 секундаПосмотрел соседей, http://forum.onliner.by/viewtopic.php?t=1736876&p=79227391#p79227391, вчера оказывается не у одного меня сюрприз где-то полчаса был. На "mtis.by", вчера в районе 10 часов, 50% потерь по ping c маршрутизатора.
Добавлено спустя 1 минута 8 секундне считая страниц, которые не открывались с первого раза.
-
Senior MemberофлайнSenior Member
12712
21 год на сайте
пользователь #560212712# 17 мая 2015 17:13 Редактировалось Daimos, 1 раз.budgerigar, не сразу понял куда вы клоните с биклаудом - теперь понятно. Дело в том, что трепыхаться по этому поводу бесполезно - будем мы думать над этим или нет - фильтрация трафика уже неизбежность близкого будущего.
И я уверен, что скрытие IP адресов и топологии сети в МТИС сделано не для сокрытия, что он ходит через какие-то левые узлы, на которых наш траффик фильтруется или анализируется - так как сделать ответвление всего траффика "налево" для анализа - вообще незаметная для пользователя вещь, а фильтрация промежуточная вообще красиво делается - Cisco маршрутизатор при приходе icmp пакета может его отправить дальше и при этом не изменять TTL у него - то есть вы узла в середине вообще не заметите.Добавлено спустя 2 минуты 37 секундВот пример трейса с работы с одного провайдера
Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:наши - первые три девайса
1 1 ms <1 ms 1 ms core [192.168.0.207]
2 <1 ms <1 ms <1 ms router [10.17.23.2]
3 <1 ms <1 ms <1 ms btkgw [10.17.24.2]4 2 ms 4 ms 2 ms mm-49-244-209-82.adsl.mgts.by [82.209.244.49]
5 2 ms 3 ms 4 ms aggr1.mgts.by [86.57.200.33]
6 5 ms 4 ms 2 ms core3.net.belpak.by [93.85.80.161]
7 2 ms 4 ms 3 ms core1.net.belpak.by [93.85.80.45]
8 6 ms 4 ms 4 ms ie1.net.belpak.by [93.85.80.38]
9 2 ms 2 ms 2 ms 100ge.core.belpak.by [93.85.80.238]
10 26 ms 26 ms 29 ms 72.14.242.189
11 28 ms 28 ms 28 ms 216.239.47.249
12 29 ms 31 ms 30 ms 209.85.246.191
13 29 ms 28 ms 29 ms google-public-dns-a.google.com [8.8.8.8]Добавлено спустя 3 минуты 20 секундВот трейс через другого провайдера
Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:1 <1 ms <1 ms <1 ms core [192.168.0.207
2 <1 ms <1 ms <1 ms router [10.17.23.2]
а вот тут у нас есть маршрутизатор, которого не видно никому
3 1 ms <1 ms 1 ms bras8-lo1.telecom.by [93.125.5.8]
4 58 ms 3 ms 1 ms c6509-vss-vl184.telecom.by [93.125.5.169]
5 2 ms 1 ms 1 ms 178.124.168.37
6 2 ms 7 ms 7 ms core1.net.belpak.by [93.85.80.145]
7 * * * Request timed out.
8 * * * Request timed out.
9 26 ms 26 ms 26 ms 216.239.47.249
10 29 ms 27 ms 27 ms 209.85.246.197
11 27 ms 26 ms 26 ms google-public-dns-a.google.com [8.8.8.8][Паяльник & Отвертка TEAM] -
Senior MemberофлайнSenior Member
3470
18 лет на сайте
пользователь #427193470# 17 мая 2015 17:21 Редактировалось BAHbKA, 1 раз.Да ребята, глубоко вы полезли, прям теория заговора.
Можно просто зеркалировать трафик целеком и полностью и смотреть, что творится. И вы ни как не определите трассировками следят за вами или нет.Почитайте про систему СОРМ. Эта система есть практически у всех операторов, а у кого нет значит есть у вышестоящего провайдера.
Master xPON -
Senior MemberофлайнSenior Member
12712
21 год на сайте
пользователь #560212712# 17 мая 2015 17:24budgerigar:
Кроме того, думаю, он боится, что ребята из МТИС, разломают действующую систему маршрутизации, и тогда всем будет несладко. Кстати, когда её ломали в прошлом году, было неприятно.
Не - я не боюсь что они что-то там сломают - у меня есть запасной вариант ADSL на паузе и телефон с 3g, плюс еще один Ethernet провайдер уже смонтировал оборудование почти все - если что переключусь на него - на МТИСе уже год прошел с моего подключения и я могу свалить без штрафа с него
Добавлено спустя 11 минут 58 секундBAHbKA, СОРМ не позволяет фильтровать, что показывать пользователю - только смотреть куда он ходит и что делает. А вот биклауд это якобы сможет делать.
[Паяльник & Отвертка TEAM] -
Senior MemberофлайнSenior Member
3470
18 лет на сайте
пользователь #427193470# 17 мая 2015 17:45Фильтрация ни как не отражается в трассировке. Маршрутизатор режет по спискам и всё.
Master xPON -
# 17 мая 2015 18:00
Daimos:
budgerigar, не сразу понял куда вы клоните с биклаудом - теперь понятно. Дело в том, что трепыхаться по этому поводу бесполезно - будем мы думать над этим или нет - фильтрация трафика уже неизбежность близкого будущего.
Daimos, если вы посмотрели мои трассировки и ссылки внимательно - это уже неизбежная реальность. Вой кстати был неслабый, когда переключили часть пользователей белорусского сегмента на российский в прошлом году.
Daimos:
И я уверен, что скрытие IP адресов и топологии сети в МТИС сделано не для сокрытия, что он ходит через какие-то левые узлы, на которых наш траффик фильтруется или анализируется - так как сделать ответвление всего траффика "налево" для анализа - вообще незаметная для пользователя вещь, а фильтрация промежуточная вообще красиво делается - Cisco маршрутизатор при приходе icmp пакета может его отправить дальше и при этом не изменять TTL у него - то есть вы узла в середине вообще не заметите.
Добавлено спустя 2 минуты 37 секундВот пример трейса с работы с одного провайдера
Фильтровать можно всё, что угодно. Отслеживать тоже. Не пускать. Это бизнес, причём ему уже много-много лет. Также паранойя, которая стоит денег, причём чем она больше, тем дороже.
Мне на этот бизнес пока в принципе наплевать, вам судя по вашим словам тоже. Хотя кто знает, как это повернётся к нам в будущем?Добавлено спустя 42 минуты 52 секундыBAHbKA,
Откуда ссылка?
Мне больше нравятся надписи, PowerEdge R520 слева, DVD-ROM справа.
-
Senior MemberофлайнSenior Member
12712
21 год на сайте
пользователь #560212712# 17 мая 2015 19:05budgerigar:
Daimos, если вы посмотрели мои трассировки и ссылки внимательно - это уже неизбежная реальность. Вой кстати был неслабый, когда переключили часть пользователей белорусского сегмента на российский в прошлом году.
Ниче не понял про какое-то переключение - у БТК практически всегда было два канала - и на Россию он был шире в несколько раз европейского направления.
Чем в будущем обернется - понятно. Вы что-то хотите предложить? Спасибо - откажусь сразу.
budgerigar:
Мне больше нравятся надписи, PowerEdge R520 слева, DVD-ROM справа.
странный сервачок для нынешних времен - толку от DVD ноль, если в серваке есть iLo/IPMI.
[Паяльник & Отвертка TEAM] -
# 17 мая 2015 19:14 Редактировалось sin-ka, 1 раз.
budgerigar, Зря Вы катите бочки в сторону биклауда. Биклауд не режет клиентам icmp - это раз. Второе - он может и контролирует загрузку внешних пулов, в отличие от белтелекома. Данный момент оговорен в договоре с клиентами, чего нет у бтк. Что касается вчера вечера - снова шалил ЦОД бтк, уже который раз за последнее время. Устоявшаяся версия-оправдание - ддос....Хоть ты "график предстоящих ддосов" запрашивай..
P.S. что касается закрытого у вас icmp - проверьте, закрыт ли icmp по udpДобавлено спустя 2 минуты 24 секундыDaimos:
странный сервачок для нынешних времен - толку от DVD ноль, если в серваке есть iLo/IPMI.
Что закупил ниитзи десятки месяцев назад - то и использует. Главное, не знать стоимость этого "решения" для клиентов и требования, предъявляемые к их реализации - становится очень печально.
