Mystray

Но ведь не будет же, в случае hsts/https сайтов. И опять же: сам по себе браузер не открывается, большая часть ресурсов работает по https, а простые юзеры (по личным наблюдениям), достаточно экспрессивно реагируют на сложные последовательности действий вроде "после подключения вай-фай открыть браузер и в нем какой-то сайт (не гугл/яндекс!), чтоб попасть на заглушку", и идут на такое только в случае отсутствия альтернативы в виде 3g/lte.

Или не отредиректит, если пользователь зайдет на ресурс с https/hsts или приложением, а получит, в лучшем случае, ругань на сертификат...

"момент обновления" будет после request system reboot. До того момента все должно работать (не уверен, будут ли проходить коммиты - не пробовал)

Как выше и сказали - роут-мапы на исход не пускают ничего кроме /21. Добавьте что-то вроде ip prefix-list AAA-NET seq 10 permit aaa.aaa.aaa.0/21 ge 32

Extreme X620 - 10x10G портов - не то, что надо?

Juniper vQFX или Virtual ExtremeXOS не подойдут? Более-менее Switch-alike софтины. Или HP VSR1000, хотя что там насчет Opt82 на вланах не подскажу.

Если статистика собрана правильно и полная (с разных сторон, максимально близко к маршруту игровых пакетов), и все равно "там ничего нет" - тогда о каком шейпинге UDP протокола можно говорить, если "там ничего нет"? UDP ходит? ходит. Задержек нет? нет. Значит с UDP проблем нет, а есть проблема с игрой. Или вы ссчитаете, что кто-то волшебным образом находит UDP-пакет сгенеренный mtr-ом, пропускает его по высокому приоритету, а UDP-пакет, сгенеренный игрой, специально берет и перекладывает в длинный ящик, чтоб насолить клиентам? Вообще, при общении с айтишной братией - крайне советую всегда выкладывать цифры. Это как бумажки при бюрократии: чем больше бумаги - тем чище жопа. Только тут чем больше цифирь, тем выше шанс, что в этих цифирях найдется что-то не то. Нет, это не icmp. Я уже говорил: откройте wireshark во время игры и найдите там хоть один icmp-пакет. А в чем сложность? Есть проблема с продуктом? Если есть - покажите им видосики, мучайте сапорт, выходите на их разрабов, сетевиков, пусть они, знакомые и со своей инфраструктурой, и с реализацией сетевой части игры, собирают дампы и разбираются. Те же близзарды в свое время очень активно сотрудничали, и с операторами, и с игроками по проблемам с сетью. Прийти на форум ISP с такими "проблемами" же получается? Сомневаюсь. Крайне редко ручной тюнинг дает столько пользы, сколько наносит вреда из-за отличий от того умолчания, которое предполагается непутевыми разрабами и тестерами.

MTR (или, что более наглядно, pingplotter) в режиме UDP/TCP (смотря что в игре используется) натравленный на игровой (не логин) сервер и порт в моменты проблемы - было? Не видно. Был только крик о том, что "ВСТРОЕННЫЙ ПИНГ ИДЕТ ПО ICMP И НИЧЕГО НЕ ПОКАЗЫВАЕТ", хотя, как может убедиться любой, в большинстве игр ICMP нет, зато есть хитрые алгоритмы высчитывания делеев, джиттеров и прочих попугаев. Обращения в отделы техподдержки игр были? Что они отвечают? Какие средства диагностики предлагают? Был случай, когда "геймер" тоже несколько раз менял комплектующие и каждый раз ругался на продавцов, которые брак впаривают. А оказалось, что после каждой замены винда ставилась с одного и того же зверьсиди, а драйвера - с такого же пацанского пака, со всеми вытекающими тормозами/вылетами/зоопарком живности. Ничего такого не наблюдается? Какие-нибудь гей-оптимизаторы, клинеры, твикеры, улучшайзеры и подборки драйверов - много чего подобного "опытные геймеры" ставят на автомате.

rancid изначально был под cisco заточен. на сколько он будет корректно работать с d-link & mikrotik ? там на каждое семейство свои скрипты, а в конфиг-файле прописывается соответствие. Как скрипт напишите/возьмете готовый/поправите - настолько корректно и будет.

16.1R4.7 пострадал на разных платформах (olive, mx80), железки с 14.1 и 13 не зацепило, видимо дело конкретно в 16 версии. До нас долетело по такой цепочке: "28917 174 12956 262206 262206 262197 262197 262197 262197 262197 262197 262197 ...", на bgplay это веселье запислось.

Сегодня прилетел из мира такой вот апдейт: BGP routing table entry for 186.177.130.0/24 Paths: (1 available, best #1, table Default-IP-Routing-Table) ... 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 Last update: Tue Jun 20 09:15:55 2017 Квагги на бордерах молча прожевали и передали дальше, но вот судя по количеству отвалившихся сессий, то ли квагги апдейт сломали, то ли джуны не могут такое проглотить, все джуны в сети повываливались с такой руганью: Jun 20 09:26:34 rr2 rpd[4367]: %DAEMON-3: BGP ERROR: Insufficient data for the packet Jun 20 09:26:34 rr2 rpd[4367]: %DAEMON-4: bgp_read_v4_update:12184: NOTIFICATION sent to 10.0.0.1 (Internal AS 64515): code 3 (Update Message Error) subcode 1 (invalid attribute list) Jun 20 09:26:34 rr2 rpd[4367]: %DAEMON-3: Received malformed update from 10.0.0.1 (Internal AS 64515) Jun 20 09:26:34 rr2 rpd[4367]: %DAEMON-3: Family inet-unicast, prefix 186.177.130.0/24 Jun 20 09:26:34 rr2 rpd[4367]: %DAEMON-3: Malformed Attribute AS_PATH(2) flag 0x40 length 3298. Jun 20 09:26:34 rr2 rpd[4367]: %DAEMON-4-RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 10.0.0.1 (Internal AS 64515) changed state from Established to Idle (event RecvUpdate) (instance master) Некоторая часть клиентских сессий тоже, хотя не уверен, что у клиентов именно джуны. Кто-то еще столкнулся? Как такое возможно предотвратить?

Джуны - не Экстримы, один раз железку зарегал и качай до посинения, пока не ЕОЛнется, разве нет?

Для меня как раз отличаются, я вообще не вижу проблем в задержках/потерях, если они не влияют на транзитный трафик. А ваша формулировка такова, все набежавшие сюда по ссылкам с ютуба пользователи сразу ассоциируют такого рода потери с проблемами у оператора. Если там какой-нибудь л3 свич, то это вообще практически норма. Тем более, что таки не видно проблем на конечном хосте ни с джиттером ни с потерями. Хотя та же телия и балуется аггрегацией с балансировкой по L3+L4 с интересными эффектами вроде "с адреса .2 все отлично, а с адреса .4 75% потерь" и это вполне может быть наш случай.

В каком месте бред? Потеря не постоянна, конечно. Потому мы можем говорить только о статистически значимых количествах измерений от нескольких сотен запросов. А до второго хопа пакет долетает через астрал, минуя первый хоп (на котором как раз потери) что ли? Как, по-вашему, можно иметь 100% ответов от второго хопа, если до него даже не могут дойти 100% запросов? На что второй хоп сгенерирует ответ, если запрос уже потерялся раньше? Вот так выглядят настоящие 4-5% потерь транзитного трафика в одну сторону на линке между 2 и 3 хопом, и, естественно, до всех последующих хопов потери сохраняются, потому что тоже проходят через этот битый линк и тоже теряются.

Вы что-то не то говорите, совсем. Нет у него потерь ни на брасе, ни на телии. Если бы потери действительно были 5% на брасе - то и на всех последующих узлах тоже были бы видны не менее 5% потерь потому как отправленный на 5-7-100 хоп пакет точно так же потерялся бы на брасе и не дошел до 5-7-100 хопа, и точно так же записался в потери. Но нет, ответов нет только на конкретном хопе, а за ним - все чистенько, а значит - до следующего хопа долетают ВСЕ 100% отправленных пакетов. Что исключает потери транзитного трафика этих хопом. То же самое с телиевским хопом. Они просто не обязаны отвечать TTL Exceeded (или port unreachable или echo reply) на каждый пакет.