[vlad11]

Если Вы не умеете читать RFC и стандарты - это ваши проблемы.

Самый первый звоночек, если у ISP один маршрутизатор и скорость выше 600-800Мб не поднимается, даже несмотря на выключения шейперов и другие шаманства.

 

P.S. Лобанов давно в черном списке, его бред не читаю :)

[applx]

RFC в студию...

если микротик то то там все и так ясно, вы не Сааб? ;) Хотя даже от него такого не ожидал бы

Изменено 25 сентября, 2016 пользователем applx

[[anp/hsw]]

Если Вы не умеете читать RFC и стандарты - это ваши проблемы.

Похоже, это вы не умеете читать. Процитируйте тот кусок, который вас навел на такие мысли.

[vlad11]

' timestamp='1474812524' post='1326419']

Если Вы не умеете читать RFC и стандарты - это ваши проблемы.

Похоже, это вы не умеете читать. Процитируйте тот кусок, который вас навел на такие мысли.

 

Т.е. вы не читали о работе TCP|IP, как регулируется скорости потоков и роль icmp на маршрутизаторах? :)

 

P.S. Подсказка:

 

...

А это комплексная проблема из минимум четырех факторов - MTU, MTU Path Discovery, RFC1918, RFC 1323 aka TCP windows scale.

...

[[anp/hsw]]

Т.е. вы не читали о работе TCP|IP, как регулируется скорости потоков и роль icmp на маршрутизаторах? :)

Я-то как раз читал, по этому и спрашиваю, откуда у вас такая ересь в голове появилась.

Я специально указал про возможный вариант с "icmp need to frag", чтобы не возникло никаких поводов для разночтений. Да и то, тут будет играть роль всего лишь наличие маршрута (и всего лишь в одну сторону, для доставки ICMP-пакета от транзитного роутера к вам), а не принадлежность адресов.

 

P.S. Подсказка:

PMTU я специально описал отдельно, а tcp window scaling тут вообще никаким боком не при делах. Не стройте из себя эксперта :)

Вобщем, требую пруфов!

[Butch3r]

Если Вы не умеете читать RFC и стандарты - это ваши проблемы.

Самый первый звоночек, если у ISP один маршрутизатор и скорость выше 600-800Мб не поднимается, даже несмотря на выключения шейперов и другие шаманства.

 

P.S. Лобанов давно в черном списке, его бред не читаю :)

А звонок для кого? Т.е. это означает, что проблема у аплинка (например кТТК, у которого уже почти все маршруты идут через серые IP) или для его абонента этого же ТТК?

 

После первого упоминания на форуме про вред серых IP на маршрутизаторах, которые также работают и с белыми я проводил тесты.

Бордер - Роутер А - L3 свич 1 - L3 свич 2 - L3 свич 3 - Роутер Б - абонент за ним. Скорость скачивания/закачивания по FTP / iperf не показали никакой разницы. Т.е. на свичах были серые IP, на роутерах белые IP. У абонента также был белый IP. Я менял адреса на серые на роутере Б на серый, переводил все свичи на белые IP. Чередовал. Разницы 0.

[applx]

Cоветую почитать про BGP FREE CORE и с чем его едят. Там как раз используют серые адреса в ядре и белые на бордерах. Таким образом работают не малое количество ISP Европы и США.

 

А писать такую хрень как вы стыдно должно быть. Прошу обьесниты почему у меня между двумя ЦОД 10Г в полке по ночам (репликацыя ВМок) и адреса серые?

[zi_rus]

P.S. Подсказка:

 

Рыба моя, ты сам не понимаешь что в тех RFC написано

 

PS я тоже в школьные годы думал сеть на адресах класса А будет быстрее работать чем на классе С

 

PPS

 

Несколько способов доказательства теорем:

 

* Доказательство посpедством эмоциональной жестикуляции

Хоpошо для учителей и докладчиков на семинаpах. Главное - не ставить

pядом ничего хpупкого.

 

* Доказательство с помощью нагpомождения неудобочитаемых записей

Тут важно задействовать как минимум четыpе алфавита - латинский,

гpеческий, цеpковнославянский и pуническую запись, не считая

символов, пpидуманных самостоятельно.

 

* Доказательство по умолчанию

"Подходящие пpимеpы из жизни читатель без тpуда найдет сам"

"Остальные 253 случая аналогичны"

 

* Доказательство посpедством взаимного цитиpования

"Как вы понимаете, теоpема 5, данная в источнике А, следует из теоpемы 3,

выведенной в источнике Б как логическое следствие пункта 6.2 источника В,

котоpый, в чем нетpудно убедиться, является частным случаем теоpемы 5,

данной в источнике А - не пpавда ли, тpивиально?!"

 

* Доказательство путем запутывания

Излагается длинная последовательность истинных и/или бессмысленных

посылок, pеальная связь между котоpыми - только на уpовне синтаксиса.

 

* Доказательство посpедством выдачи желаемого за действительное

Оpатоp цитиpует известную из литеpатуpы теоpему, пpоизвольно pасшиpяя

область ее пpименения, пеpевиpая под свои нужды или вообще вывоpачивая

суть наизнанку.

 

* Доказательство с помощью заемного автоpитета

"Hеужто двенадцать кpупнейших пpавительств миpа могут заблуждаться?!"

 

* Доказательство чеpез благоговение пеpед автоpитетом

"Я ехал в лифте с Пифагоpом, и своими ушами слышал, как тот сказал,

что квадpат гипотенузы pавен сумме квадpатов катетов!"

 

* Доказательство демонстpацией сопpичастности к тайнам высших сфеp

"Мне Пифагоp в частной пеpеписке пpизнался, что квадpат гипотенузы

pавен сумме квадpатов катетов"

 

* Доказательство путем пеpевода стpелок на совсем дpугую пpоблему

"Пpежде чем доказывать, что квадpат гипотенузы pавен сумме квадpатов

катетов, давайте посчитаем, действительно ли у тpеугольника тpи стоpоны".

 

* Доказательство путем отсылки к тpуднодоступным источникам

Автоp пpиводит элементаpный вывод из теоpемы, "доказательство котоpой

каждый может отыскать в дайджесте Мотологической Ассоциации Внутpенней

Монголии за 889 год (pукопись на папиpусе, тиpаж 2 экз.)".

 

* Доказательство путем апелляции к накопленному опыту

"Hо наш тезис пока никем не был опpовеpгнут!"

 

* Доказательство путем обpащения к космогонии (т.н. "космогонево")

"Правда существует независимо от того, верите вы в нее или нет!"

Едва ли не самый популяpный аpгумент в пользу существования Бога

 

* Доказательство путем бомбаpдиpовки диагpаммами и данными

Бывает неплохо в паpе с "доказательством по умолчанию"

 

* Доказательство посpедством оскорбления конкурентов

Очень помогает набpать "с нуля" политический вес

 

* Доказательство на основании фальшивых цитат

В главе источника, на котоpую ссылается автоp, нет ничего даже

отдаленно напоминающего цитиpуемый текст

 

* Доказательство посpедством ссылки на гpядущие публикации

Автоp гаpантиpует, что опубликует подтвеpждающие теоpию данные

в ближайшее вpемя - ну, скажем, сpазу же после дождичка в четвеpг.

 

* Доказательство посpедством возбуждения интуиции слушателя

Если вы хотите использовать этот метод, тест Роpшаха обеспечит

наилучший демонстpационный матеpиал

 

* Доказательство путем пеpехода на личности

"Как?! И вам все еще непонятно?!!"

 

 

[straus]

Так, если кому интересно.

Проблемы касательно 0 и 255 в конце адреса имели (и до сих пор имеют) место быть. Причин несколько. В старых версиях одной из веток юниксов широковещательным считался адрес 0, а не 255, со всеми вытекающими. Потом было поправлено. Кроме того, после перехода на бесклассовую адресацию с маской в большом количестве софта налепили ошибок, которые касались игнорирования маски в некоторых случаях.

[Sacrament]

Видимо из серии как ускорить интернет обмотав патчкорд другим патчкордом и продувка проводов))

[zhenya`]

.0 и .255 нельзя поставить на консольных терминальниках Moxa ) при любой маске.. у них расчеты идут как будто сеть всегда /24

[EDA_SPB]

Я знаю железку (КТВ усилитель), где нельзя ip и сети 192.168.0.X

 

Такое бывает, когда устройство имеет внутреннюю сеть IP для взаимодействия между модулями.

[stas_k]

Такое бывает, когда устройство имеет внутреннюю сеть IP для взаимодействия между модулями.

надо им подсказать чтобы использовали в следующих релизах 1.0.0.0/1

 

типа по фэншую хорошо. счастье приносит и удачу в делах.

[Wingman]

' timestamp='1474691137' post='1326189']

Грубо говоря, по такой трассе скорость будет медленнее набираться.

Трафик вообще ничего не знает об адресах на стыках, он форвардится неизменно (исключая случаи с DF) всеми машрутизаторами по цепочке независимо от того, какие у них адреса.

 

Открывайте спецификацию TCP/IP и вдумчиво изучайте механизм регулирования скорости TCP пакетов.

Не забываем про роль icmp пакетов на маршрутизаторах.

 

P.S. МФ ловко выкрутился, для снижения скорости транзита вставлять серые IP. Да и нечем им играться с размерами окна (другой способ регулировать ускорение траффика).

 

 

И он где-то в isp работает?

[SUrov_IBM]

' timestamp='1474812524' post='1326419']

Если Вы не умеете читать RFC и стандарты - это ваши проблемы.

Похоже, это вы не умеете читать. Процитируйте тот кусок, который вас навел на такие мысли.

 

Т.е. вы не читали о работе TCP|IP, как регулируется скорости потоков и роль icmp на маршрутизаторах? :)

 

P.S. Подсказка:

 

...

А это комплексная проблема из минимум четырех факторов - MTU, MTU Path Discovery, RFC1918, RFC 1323 aka TCP windows scale.

...

Vlad11, доброго Вам времени суток.

 

 

Не буду разводить димагогию, поскольку область телекоммуникации - моё хобби и возможно я ошибаюсь.

Но как мне видеться - в IPv4 нет никакой разницы между «приватными» (пример 192.x.x.x/24) и «публичными»

(пример 193.x.x.x/8) адресами.

 

Главное это связанность (маршрутизация). При этом под связанностью подразумевается прохождение IP пакета

от адреса источника (A), до адреса получателя (B), а не гарантированный (пример ICMP) ответ всех

промежуточных узлов (переходов) в цепочке.

 

Да, отсутствие ICMP мешает работе механизма PMTU и средствам диагностики неисправности, но никоим образом,

не должно влиять на скорость обмена по IP!

 

Косвенно, скорость обмена по IP может «проседать» из-за предельно низкого (заданного в «ручную») значения TCP MSS

(обосновано высокой нагрузкой на CPU маршрутизатора) - следствие заранее неизвестного значение MTU в «пути следования».

Но это, скорее относится к неверному построению (дизайну) схемы канала передачи данных.

 

Ведь «публичные» хосты сети Интернет, доступные через глобальную маршрутизацию, так же могут игнорировать ICMP (PMTU),

как и «приватные» (не маршрутизирующиеся в глобальной схеме).

Изменено 27 сентября, 2016 пользователем SUrov_IBM

[Butch3r]

' timestamp='1474812524' post='1326419']

Если Вы не умеете читать RFC и стандарты - это ваши проблемы.

Похоже, это вы не умеете читать. Процитируйте тот кусок, который вас навел на такие мысли.

 

Т.е. вы не читали о работе TCP|IP, как регулируется скорости потоков и роль icmp на маршрутизаторах? :)

 

P.S. Подсказка:

 

...

А это комплексная проблема из минимум четырех факторов - MTU, MTU Path Discovery, RFC1918, RFC 1323 aka TCP windows scale.

...

Vlad11, доброго Вам времени суток.

 

 

Не буду разводить димагогию, поскольку область телекоммуникации - моё хобби и возможно я ошибаюсь.

Но как мне видеться - в IPv4 нет никакой разницы между «приватными» (пример 192.x.x.x/24) и «публичными»

(пример 193.x.x.x/8) адресами.

 

Главное это связанность (маршрутизация). При этом под связанностью подразумевается прохождение IP пакета

от адреса источника (A), до адреса получателя (B), а не гарантированный (пример ICMP) ответ всех

промежуточных узлов (переходов) в цепочке.

 

Да, отсутствие ICMP мешает работе механизма PMTU и средствам диагностики неисправности, но никоим образом,

не должно влиять на скорость обмена по IP!

 

Косвенно, скорость обмена по IP может «проседать» из-за предельно низкого (заданного в «ручную») значения TCP MSS

(обосновано высокой нагрузкой на CPU маршрутизатора) - следствие заранее неизвестного значение MTU в «пути следования».

Но это, скорее относится к неверному построению (дизайну) схемы канала передачи данных.

 

Ведь «публичные» хосты сети Интернет, доступные через глобальную маршрутизацию, так же могут игнорировать ICMP (PMTU),

как и «приватные» (не маршрутизирующиеся в глобальной схеме).

Да тут в соседней теме пишут что он тупо троллит

[Saab95]

Проблема серый IP на маршрутизаторах в том, что если трейс запускать от устройства или абонента этой сети, то он покажет весь путь без звездочек, а вот ответный трейс со стороны интернета не сможет определить серые адреса, что может создавать проблемы при поиске неисправностей. Обычно у крупных провайдеров все сводится по L2 в центр и вопросы такой маршрутизации не возникают, т.к. используются белые адреса в малом количестве. Но если сеть большая, то маршрутизаторы работают по серым адресам и извне они не доступны. Скрыть все это очень легко на микротике, подменяя TTL правилом, тогда они ни от абонентов, ни извне, показываться не будут.

[[anp/hsw]]

подменяя TTL правилом

что создаст еще больше проблем при поиске неисправностей.

[MrNv]

у нас в NAT используется один из адресов оканчивающийся на .0 с ним lg.ttk.ru не работает :(

[Dim-Soft]

подменяя TTL правилом

IMHO а если насильно присваивать ttl = 64 всем пакетам, то для пользователей это будет "самый быстрый интернет" - до любого хоста 1 хоп :)