[s.lobanov]

1 час назад, Ivan_83 сказал:

А с чего ты взял что Л3 сам по себе панацея?

Я тебе и в л3 могу влить так что буферов не хватит, разницы никакой нет.

Он намекает на то что у софтроутеров условно бесконечный буфер (с помещением пакета в RAM). Типа в каждый подъезд по софтроутеру ставить. Кстати, у того же микротика и нет ничего софтроутерного типа 24FE/GE+2/4GE. А вот на свитчах CRS от шлакотика интересно бы узнать размер буфер.

[Ivan_83]

4 часа назад, s.lobanov сказал:

Он намекает на то что у софтроутеров условно бесконечный буфер (с помещением пакета в RAM).

Мы же понимаем что в начале оно попадает в буфер чипа сетевухи, даже у интелов есть счётчики дропов.

[s.lobanov]

@Ivan_83 

Так проблема-то не в rx-буфере, а в tx и если повесить шейпер с большим latency/буфером, то tx буфер будет сначала в ram и тут пофиг на аппаратные ограничения

[NiTr0]

ну в общем да, на софтроутерах (особенно - хилых мыльничках с куриными мозгами на каком-то мипсе/арме 1ггц) дропы будут не на выход, а на вход :)

[vurd]

Предлагаю перестать обсуждать микротик и удалить связанное с ним в этом треде. Ибо вопрос на самом деле серъезный, а будет спущен во флейм.

[s.lobanov]

@vurd 

У микротика есть свитчи серии CRS https://wiki.mikrotik.com/wiki/Manual:CRS3xx_series_switches#Models 

На точно таком же чипе Marvell 98DX3236 построены свитчи Eltex http://eltexalatau.kz/upload/iblock/04a/mes_2324p_2348p_datasheet_4.0.6_en.pdf , в даташите Eltex есть размер буфера 12Mb (12 Мбит судя по всему)

 

Розничная цена микротика намного интереснее чем Eltex. Так что если нужны чисто вланы без всяких там мультикастов, селектив QinQ и т.п. то почему бы и не взять свитч mikrotik?

[Butch3r]

2 часа назад, vurd сказал:

Предлагаю перестать обсуждать микротик и удалить связанное с ним в этом треде. Ибо вопрос на самом деле серъезный, а будет спущен во флейм.

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

 

В 17.01.2019 в 11:55, darkagent сказал:

из многолетней практики и бесконечных "экспериментов" на живом трафике.

А вы не пробовали хотябы чуточку из этого на 3630? Просто там как я понимаю платформа софта совершенно другая, может тут они смогли сделать нормальную работу с буфером?

[orlik]

2 hours ago, Butch3r said:

мы ищем свич с большим буфером

 

В целом на доступ никто не производит свичи с большим буфером , ибо это дорого. 

Не знаю было уже или нет , но вот тут  есть табличка с чипами и размерами буферов . также указаны модели коммутаторов.

 

P.S. не флейма ради , а зачем вам большой буфер и насколько большой вам нужен чтобы решить ваши проблемы ? 

[darkagent]

4 часа назад, Butch3r сказал:

А вы не пробовали хотябы чуточку из этого на 3630? Просто там как я понимаю платформа софта совершенно другая, может тут они смогли сделать нормальную работу с буфером?

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

[NiTr0]

5 часов назад, s.lobanov сказал:

Так что если нужны чисто вланы без всяких там мультикастов, селектив QinQ и т.п.

ну как тупой агрегатор без излишеств типа stp, lacp и т.п. - вполне пойдет, вебсмарт как вебсмарт.

[Justas]

В 17.01.2019 в 23:24, NiTr0 сказал:

низкая скорость одиночных tcp потоков (затыкается ютуб, спидтест показывает 20-30 мбит вместо положенных 100 и т.п.), дропы пингов (порядка нескольких %), "непрохождение" пингов по несколько десятков килобайт, и прочие прелести.

 

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

Изменено 20 января, 2019 пользователем Justas

[s.lobanov]

@Justas потому что сервера шлют на скорости 10G на протяжении tcp-окна, а втолкнуть это надо в порт 1G. Вы ещё учтите что за одним портом куча абонов

 

А свободная ёмкость в вашем cacti/zabbix/etc это среднее за X секунд, а не мгновенное значение

[disappointed]

1 час назад, Justas сказал:

 

Каким образом свитч агрегации при наличии свободной ёмкости матрицы коммутации согласно паспортной спецификации перестает надлежащим образом выполнять свою функцию?

 

Также как конверторы с SFP 1G в медную cотку с малым буфером.

Микробёрсты длиной в сотни милисекунд приводят к потерям.

Свитчей я таких не встречал.

[NiTr0]

1 час назад, Justas сказал:

Каким образом свитч агрегации при наличии свободной ёмкости матрицы коммутации согласно паспортной спецификации перестает надлежащим образом выполнять свою функцию?

а причем матрица коммутации к тому факту, что в свич в какой-то момент времени вливается трафика больше, чем из него выливается? мгновенно ессно, в текущую миллисекунду, а не в среднем за несколько минут.

и этот трафик надо куда-то сложить - а складывать некуда, мозги куриные, потому - дропается. а congestion control при этом считает, что все, уперлись в полку, и надо снижать скорость. и снижает...

[Ivan_83]

1 час назад, NiTr0 сказал:

и этот трафик надо куда-то сложить - а складывать некуда, мозги куриные, потому - дропается. а congestion control при этом считает, что все, уперлись в полку, и надо снижать скорость. и снижает...

Там ещё свич должен FlowControl пакеты начать слать, с просьбой к отправляющему заткнутся на хх мс, надеюсь на аплинках и серверах нет желающих такое включать.

[NiTr0]

1 час назад, Ivan_83 сказал:

Там ещё свич должен FlowControl пакеты начать слать,

должен только если у него flow control включен. если  этой опции нет (а есть ли она к слову в некротиках?) - тут уж как повезет, может слать а может и не слать, если будет слать - будет весело :)

к слову, слать он при засирании буфера будет всем подключеным девайсам, кто пытается что-то отправить. независимо от объема трафика. буфер-то кончился :)

[Butch3r]

10 часов назад, orlik сказал:

 

В целом на доступ никто не производит свичи с большим буфером , ибо это дорого. 

Не знаю было уже или нет , но вот тут  есть табличка с чипами и размерами буферов . также указаны модели коммутаторов.

 

P.S. не флейма ради , а зачем вам большой буфер и насколько большой вам нужен чтобы решить ваши проблемы ? 

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

 

И у нас не совсем доступ - у нас 1г агрегация.

[darkagent]

17 часов назад, s.lobanov сказал:

У микротика есть свитчи серии CRS https://wiki.mikrotik.com/wiki/Manual:CRS3xx_series_switches#Models 

На точно таком же чипе Marvell 98DX3236 построены свитчи Eltex http://eltexalatau.kz/upload/iblock/04a/mes_2324p_2348p_datasheet_4.0.6_en.pdf , в даташите Eltex есть размер буфера 12Mb (12 Мбит судя по всему)

У того же snr-s2995g тот же чипсет под капотом. Чистый доступ и совсем малая агрегация, ни о какой нормальной агрегации и речи быть не может. Взяли на пробу snr-s2995g-12fx - удобен своими маленькими габаритами, и тем что умеет 100/1000 на оптическом порту, чтоб перехватить несколько частных домов или организаций мимоходом вполне годится. 

 

9 часов назад, Justas сказал:

на будущее хотелось понимать симптоматику

у GGC (гуглокэш) одно время в доках фигурировали требования к конкретным коммутаторам,  а точнее к тому что ставить не стоит. И были запуски "на том что есть" с последующей экстренной заменой "на то что надо", так вот, для GGC минималочкой ставится cisco 4948 (или аналог), у которого жирнющий пакетный буфер, а работа ggc через какие-нибудь 3750X больше похожа на изнасилование трупа лошади. И это при том что на старте утилизация портовой емкости GGC не превышает и 50% на каждый задействованный порт. Просто ты открываешь популярный ролик на ютубе, а он тебе травит прогруз на прогрузе даже на ссаном 360p. 

 

Чтоб не ощущать проблем никаких с микроберстами, сеть от поставщика контента до последней мили должна быть гомогенной, но такое не реально даже в теории. Любое перекладывание из большей емкости в меньшую чревато выплескиванием потока. Наглядно такое можно представить взяв бутылку, воронку, и кастрюлю воды... 

[Saab95]

В 19.01.2019 в 20:12, Ivan_83 сказал:

А с чего ты взял что Л3 сам по себе панацея?

Потому что сам интернет работает на L3. И нельзя сделать сеть больше определенного размера сегмента, на технологии L2.

 

Потому что на L2 нельзя сделать даже нормального резервирования, нельзя управлять потоками трафика, много чего нельзя.

 

В 19.01.2019 в 21:37, s.lobanov сказал:

у софтроутеров условно бесконечный буфер (с помещением пакета в RAM)

Правильно, если идет большой поток данных, то данные из буфера сетевого чипа помещаются в память, где спокойно ждут своей очереди. Ясно дело, такая фишка работает только на L3 доступе, если пытаться засунуть туда L2 - жди беды.

 

5 часов назад, darkagent сказал:

У того же snr-s2995g тот же чипсет под капотом.

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

 

Согласитесь, что если бы у всех были циски, длинки и прочие вендоры, с полной поддержкой всех фич L3, то каким образом бы все настраивали? Разница в том, что на микротике все это можно сделать за вполне вменяемые деньги, а на циске и иже с ними - в 10 раз дороже. Ясно дело, экономически это не имеет смысла - не окупится.

[s.lobanov]

29 минут назад, Saab95 сказал:

Правильно, если идет большой поток данных, то данные из буфера сетевого чипа помещаются в память, где спокойно ждут своей очереди. Ясно дело, такая фишка работает только на L3 доступе, если пытаться засунуть туда L2 - жди беды.

Бред. Это никак не зависит от L2 или L3 доступа, это зависит от того, аппаратный буфер или аппаратный+программный. Можно сделать L2-доступ на софтроутерах и тем самым решить проблемы с буфером.

Если mikrotik crs будет работать в режиме свитча (в l3-режиме), то будет тоже самое что и на других свитчах. Если будет использоваться роутинг/свитчинг через его дохлый cpu, то он загнётся уже на нескольких абонентах.

 

Я ж не против софтроутеров на доступе, но софтроутеров 24FE/GE+2/4GE по цене L2/L3-свитчей просто нет

 

Какую конкретно модель вы предлагаете на доступ и какую на агрегацию?

[Saab95]

На доступ - CRS326-24G-2S+RM - только не надо говорить что он слаб по скорости - порядка 500 мегабит трафика он пропускает на все подключенные абонентские порты, больше просто не потребляют.

 

На агрегацию уже роутеры по типу CCR1016 с SFP портами.

 

 

[alibek]

50 минут назад, Saab95 сказал:

Потому что сам интернет работает на L3. И нельзя сделать сеть больше определенного размера сегмента, на технологии L2.

Глупости.

Абоненты — это не сеть, это транспорт. А транспорт правильнее работает на L2.

[Ivan_83]

50 минут назад, Saab95 сказал:

Потому что сам интернет работает на L3. И нельзя сделать сеть больше определенного размера сегмента, на технологии L2.

Речь ваще про другое.

 

50 минут назад, Saab95 сказал:

Потому что на L2 нельзя сделать даже нормального резервирования, нельзя управлять потоками трафика, много чего нельзя.

Ну это на мыкротыке видимо низя.

 

50 минут назад, Saab95 сказал:

если идет большой поток данных, то данные из буфера сетевого чипа помещаются в память, где спокойно ждут своей очереди. Ясно дело, такая фишка работает только на L3 доступе, если пытаться засунуть туда L2 - жди беды.

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

[Justas]

17 часов назад, NiTr0 сказал:

а причем матрица коммутации к тому факту, что в свич в какой-то момент времени вливается трафика больше, чем из него выливается? мгновенно ессно, в текущую миллисекунду, а не в среднем за несколько минут.

и этот трафик надо куда-то сложить - а складывать некуда, мозги куриные, потому - дропается. а congestion control при этом считает, что все, уперлись в полку, и надо снижать скорость. и снижает...

 

То есть, я всё правильно понял, что дело в неправильной архитектуре сети и большими буферами стараются "сгладить" косяки архитектуры? Ну, то есть, по хорошему нужно переводить порты коммутатора агрегации, смотрящие в ядро, с 10G на 40G, а порты, смотрящие на доступ, с 1G на 10G, но из-за экономии стараются вытянуть из 1/10G еще хоть что-то?

[Saab95]

3 часа назад, alibek сказал:

Глупости.

Абоненты — это не сеть, это транспорт. А транспорт правильнее работает на L2.

Ну и как вы себе это представляете, какие есть градации?

1. Офисная локалка на 20 компов - можно держать в одном сегменте.

2. Сеть малого провайдера - 100-200 компов можно держать в одном сегменте.

3. Сеть провайдера - тут уже идет разбивка на вланы, например влан на коммутатор.

4. Сеть крупного провайдера - влан на пользователя в пределах коммутатора, QinQ на транспорте для подачи в центр.

 

Дальше то что? Представьте 1000 коммутаторов на 48 портов - это уже 48 тысяч вланов. И все это идет в одном "физическом" порту. Как в этой куче искать проблемы, где теряется, где буфера не хватает? Именно по этой причине провайдеры переходят на гибридные схемы, где все в центр идет через MPLS, а на промежуточных узлах в него упаковывают абонентские L2 интерфейсы (вланы). Тогда в центре уже оперируют L2 абонентскими интерфейсами не зависимо от архитектуры сети.

 

Кто когда-то арендовывал вланы у крупных операторов знают, что у них постоянно возникают проблемы с блокировкой мультикаста или еще некого трафика, а потом, оказывается, где-то на сети меняли коммутатор и он стал источником этой проблемы. Ищут такие неполадки долго, гоняя монтажников и делая физические переключения. А вот арендовав порт MPLS у особо крупных, никогда никаких проблем не бывает.