[weedman]

Здравствуйте. После чтения сообщений на этом форуме, у меня мложилось мнение, что радио на L3 должно стабильнее работать, чем на L2, потому что пакет не будет передаваться через всю L2 цепочку, а только через последний L3 сегмент (где оно и потерялось).

На форуме Микротик пишут, что в случае с L2, пакет также будет отправляться только через потерявший его сегмент, на то он и hardware retry=7 (кажется 7).

 

где правда?

[[anp/hsw]]

L3 и L2 это все еще один и тот же пакет.

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

На L2 в случае обычного коммутатора никто не принимает. В случае радио (любого) есть алгоритмы ack с подтверждением приема пакета удаленной стороной. И тут уже радио принимает решение, передавать повторно или нет.

В общем случае, лучше такой пакет на L2 не передавать повторно, т.к. только хост-источник реально знает, нужен ли будет этот пакет клиенту к тому моменту, как будет повтор его передачи (в случае с UDP играми и телефоней - обычно нет, в случае с TCP - без разницы).

[weedman]

9 часов назад, [anp/hsw] сказал:

L3 и L2 это все еще один и тот же пакет.

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

На L2 в случае обычного коммутатора никто не принимает. В случае радио (любого) есть алгоритмы ack с подтверждением приема пакета удаленной стороной. И тут уже радио принимает решение, передавать повторно или нет.

В общем случае, лучше такой пакет на L2 не передавать повторно, т.к. только хост-источник реально знает, нужен ли будет этот пакет клиенту к тому моменту, как будет повтор его передачи (в случае с UDP играми и телефоней - обычно нет, в случае с TCP - без разницы).

В общем без разницы. А сааб говорил иначе.

[Saab95]

Цитата

В общем без разницы. А сааб говорил иначе.

Цитата

В общем случае, лучше такой пакет на L2 не передавать повторно, т.к. только хост-источник реально знает, нужен ли будет этот пакет клиенту к тому моменту, как будет повтор его передачи (в случае с UDP играми и телефоней - обычно нет, в случае с TCP - без разницы).

Немного тут не так. Если представить 3 устройства в цепочке по радиоканалам и L2, то пакет может пройти через устройство 1 и устройство 2, а на устройстве 3 потеряться. Потеряться он может по любой причине.

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

 

Но я писал что увеличивается скорость в радио, если уйти от L2 и передавать L3 трафик, например на мостах. Тут же ясно - меньше мусора, меньше мак адресов - снижается нагрузка на процессор, меньше мелких пакетов, которые занимают ресурсы канала. Если посмотреть торчем порой трафик, который там по L2 ходит - то там очень много не нужного. Если сеть крупная, и в центр стягиваются данные со многих сегментов сети по L2 - то там мусора будет уже больше, еще бывают штормы трафика, когда какой-то клиент в радио отвалился от БС, а на его мак адрес льется входящий трафик - он разлетается по всей сети, ведь в таблицах коммутации этот мак адрес пропадает. И когда по L2 в одном сегменте много устройств (даже вланы тут не помогут), это приводит к проблемам.

 

Учитывая то, что поиск проблем в L3 сети проще, чем в L2, да и вообще многих проблем не возникает, то при наличии оборудования (тот же микротик везде на сети) перевод все на L3 не потребует и дополнительных трат.

[[anp/hsw]]

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

Если представить 3 устройства в цепочке по радиоканалам и L2, то пакет может пройти через устройство 1 и устройство 2, а на устройстве 3 потеряться. Потеряться он может по любой причине.

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

Да хоть запредставляйтесь. К тому моменту, как вы пакет повторно отправите, клиенту он скорее всего не будет нужен, т.к. на L3 от хоста-источника уже пойдет другой пакет. Это может сработать, если повторная передача состоялась очень быстро (ACK timeout небольшой, соответствующий дистанции 50-100м), но если задержка для обнаружения пакета будет большая, то возникнет "packet reordering" - когда более новый пакет приходит раньше более старого. Это очень плохо влияет на большинство протоколов.

6 часов назад, Saab95 сказал:

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

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

[Saab95]

Цитата

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

Интернет работает на L3.

 

То есть для нормальной работы L2 нужно:

1. Разбить все каналы на вланы.

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

 

- на коммутаторах это легко делается, но на радио оборудовании любые фильтра это затраты ресурсов процессора.

 

Но тут появляется вопрос - не всегда можно зафильтровать все по самой специфике сети, да и сами коммутаторы будут перегружены фильтрами, особенно первые в цепочках. А говорим мы про радио - и тут по каналу пойдут и лишние запросы ARP, и некий мусорный трафик мелкими пакетами - все это займет лишнее время канала (пакетная нагрузка). Использование L3 окажется выгоднее.

 

Цитата

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

Я не говорю про потерю пакета. Вероятность потерять пакет, передавая его 3 раза по цепочке маршрутизаторов ниже, чем передавать его по 3-м L2 радио каналам.

 

В случае L3 можно сделать нормальную буферизацию, увеличив объем буфера, использовать тот же PCQ - ведь классификаторы в виде IP адресов уже можно использовать. На L2 кроме как объем буфера увеличить - больше нет способов повысить отказоустойчивость.

[[anp/hsw]]

В 10.04.2023 в 03:18, Saab95 сказал:

Но тут появляется вопрос - не всегда можно зафильтровать все по самой специфике сети, да и сами коммутаторы будут перегружены фильтрами, особенно первые в цепочках. А говорим мы про радио - и тут по каналу пойдут и лишние запросы ARP, и некий мусорный трафик мелкими пакетами - все это займет лишнее время канала (пакетная нагрузка). Использование L3 окажется выгоднее.

Тогда вам L3 тоже фильтровать надо. Даже лишние ARP запросы никуда не денутся, если вы их специально отфильтруете.

Обращение к неизвестному адресу на L3 точно также порождает ARP пакет на конечном интерфейсе, где хост будет искать этот адрес.

В 10.04.2023 в 03:18, Saab95 сказал:

Вероятность потерять пакет, передавая его 3 раза по цепочке маршрутизаторов ниже, чем передавать его по 3-м L2 радио каналам.

Передавая пакет на L3 вы должны сложить вероятность потери на L2 с вероятностью потерять на L3 (которая тоже будет от нагрузки CPU зависеть, итд). Учитывая, что вы не можете передать пакет L3 без участия L2 ethernet (если мы не берем частные случаи типа IPoATM и прочей не-ethernet экзотики), то вероятности нужно именно сложить, а не заменить одну на другую, как вы пишете.

В 10.04.2023 в 03:18, Saab95 сказал:

В случае L3 можно сделать нормальную буферизацию, увеличив объем буфера, использовать тот же PCQ - ведь классификаторы в виде IP адресов уже можно использовать.

Еще более осложнив жизнь игрунам и IP-телефонистам?

[Saab95]

Цитата

Обращение к неизвестному адресу на L3 точно также порождает ARP пакет на конечном интерфейсе, где хост будет искать этот адрес.

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

 

Цитата

Учитывая, что вы не можете передать пакет L3 без участия L2 ethernet

Радио оборудование в любом случае передает данные программно, будь то L2 или L3. И по накладным расходам передать L3 проще, т.к. таблица мак адресов состоит всего из 3-х устройств, никаких других хостов в сегменте нет.

 

Цитата

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

Это было бы верно, если передавался L3 трафик поверх L2 и сравнивалось все это с простой передачей данных по L2, без использования IP заголовков и пакетов.

А так в описываемом случае передачи по L2 данные тоже передаются по L3, только без использования ретрансляции на промежуточных узлах.

 

Цитата

Еще более осложнив жизнь игрунам и IP-телефонистам?

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

[[anp/hsw]]

В 24.04.2023 в 03:24, Saab95 сказал:

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

Вы не сможете передать трафик на L3 до того, как узнаете, кому его нужно передать на L2. За это отвечает ARP. В L3 цепочке каждый промежуточный роутер сгенерирует свой ARP запрос до следующего роутера, чтобы передать единичный пакет.

В 24.04.2023 в 03:24, Saab95 сказал:

И по накладным расходам передать L3 проще, т.к. таблица мак адресов состоит всего из 3-х устройств, никаких других хостов в сегменте нет.

В случае радио, мак таблица вообще никакого значения не имеет, т.к. это broadcast среда. Хоть там 1000 маков, хоть один, пакет будет выпушен в радиоинтерфейс одинаковым образом.

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

В 24.04.2023 в 03:24, Saab95 сказал:

только без использования ретрансляции на промежуточных узлах

Ваш микротик только на L3 умеет повторно передавать данные? Радио вообще-то фиолетово, hwtxretry/swtxretry применяются к необработаноми пакету в радиосреде.

В 24.04.2023 в 03:24, Saab95 сказал:

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

Причина задержки - потеряный пакет. К тому моменту, как пакет был передан повторно, что в игре, что в телефонии, клиенту он уже не нужен. Телефония будет квакать и заикаться, игра будет лагать.

[weedman]

Мой вывод - L2 и L3 не принципиально, главное чтобы широковещательного трафика не было много.

[npokypop]

Мы сейчас и уже как 7 лет, используем схему vlan на сектор, и тянем этот vlan прямо в ядро через все базухи, просто через бриджи. Проблем пока не наблюдали. Есть мысли переходить на L3 только из-за плюшек OSPF и резервирования\балансировки каналов. Но это уже в мыслях года 3 как и руки не доходят.

[Saab95]

Цитата

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

Если в радио идет много таких вланов - то в радиотракте будет обрабатываться большое количество мак адресов все равно.

 

Цитата

Мы сейчас и уже как 7 лет, используем схему vlan на сектор, и тянем этот vlan прямо в ядро через все базухи, просто через бриджи. Проблем пока не наблюдали.

Когда еще был PPPoE то на БС упаковывали трафик абонентов в EoIP туннель и подавали в центр. L2 заканчивался на БС и далее по всей сети шел только L3.

Абоненты, которые работали с IP адресами, получали их от БС или от роутера, к которому эта БС подключена.

 

Если проблем нет то сеть маленькая. Когда только начинали уже при установке 30 базовой станции поняли что на L2 собирать все в центр неудобно и перевели все на L3 (в радио было PPPoE). В пике было более 5000 базовых станций, установленных в большом количестве городов, поселков и деревень. При чем подключение большей части таких БС было через интернет посредством туннеля, и каждая БС подключалась сразу к десятку серверов доступа для резервирования и распределения нагрузки.

 

Если бы были ограничены только L2, то не смогли бы установить столько БС - ведь невозможно везде сделать свои L2 каналы или арендовать их. Поэтому на своей сети при первом удобном случае нужно уходить с L2, ведь если у вас L2 - вы ограничены в развитии сети.

[npokypop]

@Saab95 Можете развернуто пояснить на примерах вот это: "При чем подключение большей части таких БС было через интернет посредством туннеля, и каждая БС подключалась сразу к десятку серверов доступа для резервирования и распределения нагрузки. "

 

[fractal]

6 часов назад, npokypop сказал:

@Saab95 Можете развернуто пояснить на примерах вот это: "При чем подключение большей части таких БС было через интернет посредством туннеля, и каждая БС подключалась сразу к десятку серверов доступа для резервирования и распределения нагрузки. "

 

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

[Saab95]

Цитата

Можете развернуто пояснить на примерах вот это: "При чем подключение большей части таких БС было через интернет посредством туннеля, и каждая БС подключалась сразу к десятку серверов доступа для резервирования и распределения нагрузки. "

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

 

Каждая БС подключалась по L2TP туннелям к каждому маршрутизатору, через OSPF обменивались маршрутами. По сути все пакеты абонентов распараллеливались по разным туннелям, тем самым распределялась нагрузка между центральными маршрутизаторами. В точке подключения заказывался 1-2 канала от местных провайдеров (интернет) и не требовалось строить свои каналы что бы подключить БС. Абонентам выдавались свои внутренние серые и белые адреса.

 

При этом настройки везде были идентичными, от монтажника лишь требовалось установить оборудование на крыше, подключить канал провайдера и все - обычно провайдер выдавал адреса автоматом, БС через DHCP получала адрес и оказывалась подключена к сети.