https://ia801601.us.archive.org/16/items/linkmeup-V047/linkmeup-V047.mp3 https://ia601601.us.archive.org/6/items/linkmeup-V043/linkmeup-V043.mp3

спасибо, эти ссылки работают

труба = youtube

)

спасибо

Ребята го на биринг IT! Регистрация уже открыта :) https://beering.ru/est?type=2

https://habrahabr.ru/post/326566/

https://habrahabr.ru/post/326566/

Норм! Спасибо тебе Клиппер за линк! :)

я досих пор не звонил

так хитрожопость с приоритетами, повалит интернет

в комментах есть альтернативное слово "злоупортебление"

учитывая, что интернет в немалой степени держится на доверии, то склонен согласиться с предыдущим оратором

если это примет хоть какие-то ощутимые масштабы - начнется борьба с такими хитропопыми

Это что получается, весь клиентский трафик на портах динамической маршрутизации будет приоритетным?

https://habrahabr.ru/post/326566/

Это что получается, весь клиентский трафик на портах динамической маршрутизации будет приоритетным?

Нет же. Роутер различает трафик направленный к нему и транзитный, транзитный, в свою очередь, будет обрабатываться в зависимости от значения IP precedence (если настроено). Вот в этом комментарии все написано https://habrahabr.ru/post/326566/#comment_10174580

Это что получается, весь клиентский трафик на портах динамической маршрутизации будет приоритетным?

нет конечно, ты просто читаешь забр же, там часто такая хуйня

Нет же. Роутер различает трафик направленный к нему и транзитный, транзитный, в свою очередь, будет обрабатываться в зависимости от значения IP precedence (если настроено). Вот в этом комментарии все написано https://habrahabr.ru/post/326566/#comment_10174580

Спасибо

Т.к товарищ, писавший статью на хабр не удосужился показать заголовки IP пакетов, а сразу перешел к поспешным выводам, я снял дамп трафика во время установления соединения и разговора. UDP port 520 я не увидел, по всей видимости приложение использует порты от 520 и выше для подключения к серверам (см. ниже картинку call control). Так же видна "гениальная" задумка разрабов телеграма - выставить CS6 IP precedence во всех исходящих пакетах. На входящих - как положено стоит CS0, что радует, т.к провайдеры режут таких ушлых.

Но автор ведь старался, поймал момент когда 520й порт выберется...

Но автор ведь старался, поймал момент когда 520й порт выберется...

А потом получается ситуация "один неправильно сказал 10 человек неправильно услышали" и понеслась: "Шок!!!1111 Телеграм поломает интернеты!!!11"

Т.к товарищ, писавший статью на хабр не удосужился показать заголовки IP пакетов, а сразу перешел к поспешным выводам, я снял дамп трафика во время установления соединения и разговора. UDP port 520 я не увидел, по всей видимости приложение использует порты от 520 и выше для подключения к серверам (см. ниже картинку call control). Так же видна "гениальная" задумка разрабов телеграма - выставить CS6 IP precedence во всех исходящих пакетах. На входящих - как положено стоит CS0, что радует, т.к провайдеры режут таких ушлых.

там если что в @ru_voip сидит товарищ, который это все писал

можете зайти и спросить напрямую, чо гадать то

я про голос для телеграма, не про пост на хабре

можете зайти и спросить напрямую, чо гадать то

Протокол писал?

да

https://github.com/grishka/libtgvoip

собственно можно и самим посмотреть

товарищи профессионалы, подскажите где я не прав

no ip access-list standard PM-int ip access-list standard PM-int permit 10.0.0.0 255.0.0.0 permit 172.16.0.0 255.240.0.0 permit 192.168.0.0 255.255.0.0 sh ip access-lists PM-int Standard IP access list PM-int 10 permit 0.0.0.0, wildcard bits 255.0.0.0 20 permit 0.0.0.0, wildcard bits 255.240.0.0 30 permit 0.0.0.0, wildcard bits 255.255.0.0

ISR1921 155-3.M5

wildcard bits

ох твою ж мать

У acl wildcard mask

извиняюсь

спать надо больше)

большое, ага

спасибо

Быват :)

Т.к товарищ, писавший статью на хабр не удосужился показать заголовки IP пакетов, а сразу перешел к поспешным выводам, я снял дамп трафика во время установления соединения и разговора. UDP port 520 я не увидел, по всей видимости приложение использует порты от 520 и выше для подключения к серверам (см. ниже картинку call control). Так же видна "гениальная" задумка разрабов телеграма - выставить CS6 IP precedence во всех исходящих пакетах. На входящих - как положено стоит CS0, что радует, т.к провайдеры режут таких ушлых.

Я идею понял. Только вот прикол: все пакеты от физических клиентов на входе в сеть провайдера получают сброс dscp. Сервера телеграма идуд от апстримов. Входящий трафик от них тоже проходит сброс по dscp...

По крайне мере в ТТК)

Т.к товарищ, писавший статью на хабр не удосужился показать заголовки IP пакетов, а сразу перешел к поспешным выводам, я снял дамп трафика во время установления соединения и разговора. UDP port 520 я не увидел, по всей видимости приложение использует порты от 520 и выше для подключения к серверам (см. ниже картинку call control). Так же видна "гениальная" задумка разрабов телеграма - выставить CS6 IP precedence во всех исходящих пакетах. На входящих - как положено стоит CS0, что радует, т.к провайдеры режут таких ушлых.

вот этот кусок https://github.com/grishka/libtgvoip/blob/public/VoIPController.cpp#L324

Я идею понял. Только вот прикол: все пакеты от физических клиентов на входе в сеть провайдера получают сброс dscp. Сервера телеграма идуд от апстримов. Входящий трафик от них тоже проходит сброс по dscp...

в надежде что у кого-то приоретизация всё же есть

вообще какой-то очень небольшой плюс может быть. распространенная практика давать гарантированный bandwidth роутинг протоколам (+мониторить отдельный класс проще), поэтому если вдруг (упаси боже!) у isp в сети rip и они матчат с помощью "permit udp any any eq rip", то этот сигнальный трафик телеграма действительно может получить гарантию.

маловероятно, но после того, что я вижу на работе - я ничему не удивляюсь

маловероятно, но после того, что я вижу на работе - я ничему не удивляюсь

Люблю такие истории)) может покаст сделать на тему файлов и антибестпрактисов?

скорее всего все эти истории - confidential :)

вообще какой-то очень небольшой плюс может быть. распространенная практика давать гарантированный bandwidth роутинг протоколам (+мониторить отдельный класс проще), поэтому если вдруг (упаси боже!) у isp в сети rip и они матчат с помощью "permit udp any any eq rip", то этот сигнальный трафик телеграма действительно может получить гарантию.

> permit ip any any eq rip а что в заголовке ip может идентифицировать его как рип?

> permit ip any any eq rip а что в заголовке ip может идентифицировать его как рип?

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

> permit ip any any eq rip а что в заголовке ip может идентифицировать его как рип?

sed 's/ip/udp/g'

порт это уже не ip заголовок

а простите, очепятка конечно.

fixed

просто это правило, имхо, какой-то изврат, если оно реально у кого-то присутствует

оао "изврат-телеком"

просто это правило, имхо, какой-то изврат, если оно реально у кого-то присутствует

Тут половина чата может рассказать такие истории...

изврат потому что рип, или изврат матчить рип траффик?

изврат, матчить по номеру порта обычно, матчат как раз по DSCP т.к. железки их автоматом маркируют

ты тогда не можешь различать свой контрол траффик в класс мепе

класс мепе?

я его и так не различу, вот тут же как раз пишут, что телеграм иногда работает на RIP портах

я не совсем понимаю, что ты хочешь сказать

кстати, это из-за дефолтного декодирования ваершарком на основе номера порта автор решил что там RIP

я не совсем понимаю, что ты хочешь сказать

я хочу сказать, если уж матчить rip, то матчить на основе dscp - тру вей матчить на основе номера порта - не тру вей

ERROR: S client not available

делают ли разбивку на разные протоколы для cs6 в реальном мире - да делают с целью различить. понятно, что не все протоколы можно матчить на основе ip protocol num, и тогда в ход идут порты, мультикаст адреса и все такое

я тебя не заставляю матчить внутри cs6. но так делают, и понятно с какой целью

А ничего что весь трафик для которого это актуально - link-local?

А ничего что весь трафик для которого это актуально - link-local?

тунели

А ничего что весь трафик для которого это актуально - link-local?

хотя по большей части да

А ничего что весь трафик для которого это актуально - link-local?

ну не весь. бгп первым приходит в голову. а что это меняет? ты ведь хочешь иметь гарантированный bw на линке

я тебя не заставляю матчить внутри cs6. но так делают, и понятно с какой целью

у нас заматчено на основе как раз cs6 для eigrp хотя я щас задумался, а нужно ли это впринципе

А на бгп тоже dscp ставится?

не помню с головы. а ты не хочешь про бгп позаботиться? :)

Я видел случаи когда бгп трафик откидывался

А на бгп тоже dscp ставится?

чёто как то нет https://www.cloudshark.org/captures/94c0c9095eff

Забивался обычным вебом

у нас заматчено на основе как раз cs6 для eigrp хотя я щас задумался, а нужно ли это впринципе

типа cs6 AND ip prot num 88?

а вот тут - да https://www.cloudshark.org/captures/751c2ce5276b

Видимо вопрос имплементации

типа cs6 AND ip prot num 88?

просто cs6

Видимо вопрос имплементации

ага

просто cs6

ну так, у тебя ведь не только eigrp будет (наверное). почти весь контрол плейн будет cs6. как будешь знать, что твоей гарантии не хватает для _eigrp_

ну так, у тебя ведь не только eigrp будет (наверное). почти весь контрол плейн будет cs6. как будешь знать, что твоей гарантии не хватает для _eigrp_

да, вопщем тут есть место для подумать... хотя у нас ничего кроме eigrp не бегает особо

блин щас посмотрел, обычная ссш сессия тоже cs6 маркируется вот это прикол

:)

Менеджмент

Должен быть даже выше чем контрол по логике

в cisco IOS по-умолчанию включена приоритезация control-plane трафика т.н SPD http://www.anticisco.ru/blogs/2012/06/%D1%82%D0%BE-%D1%87%D0%B5%D0%B3%D0%BE-%D0%B2%D1%8B-%D0%BC%D0%BE%D0%B3%D0%BB%D0%B8-%D0%BD%D0%B5-%D0%B7%D0%BD%D0%B0%D1%82%D1%8C-%D0%BE-%D0%B2%D1%85%D0%BE%D0%B4%D0%BD%D1%8B%D1%85-%D0%BE%D1%87%D0%B5/ Правда, работает в input направлении.

да и только предназначенный для роутера (контрол-плейн)

Только то что пантится

йеп

чёт не вижу таких команд нигде старьё походу судя по иосам вот тут http://www.cisco.com/c/en/us/about/security-center/selective-packet-discard.html

spd еще жив если что :) кейс не так давно был

пом вот это более актуальная штука http://www.cisco.com/c/en/us/about/security-center/copp-best-practices.html

spd еще жив если что :) кейс не так давно был

насколько я понимаю, если проц не загружен, то дропаться ничего не должно?

https://geektimes.ru/post/288034/