00:00:00 Агрегирование Начало 00:01:15 Отличие STP 00:03:15 Ограничение оборудования на подключение Агрегированного канал 00:06:50 ПРотоколы агрегирования 00:09:37 EtherChannel CIsco 00:19:50 PAgP 00:21:40 LACP IEEE 802.3ad 00:27:00 NIC teaming , LAG
Уважаемые зрители! Если видео лекции/практики оказалось полезным, поддержите ролик лайком и комментарием, это поможет ознакомить с ним большую аудиторию. Спасибо. Анонсы, обсуждения, вопросы тут: t.me/nir_net Для желающих поддержать канал boosty.to/nir_net
Спасибо за видео! Как всегда круто) Вопрос. если мы соединяем 3 коммутатора между собой кольцом (петлей) , то сначала мы должный настроить агрегацию (LACP), а потом на логических каналах настроить STP чтобы не было петли? И есть ли необходимость в STP протоколе, если мы можем с помощью LASP добиться некой отказоустойчивости, пусть не такой надежной как через STP?
Вы собираетесь между всеми тремя кинуть по 2 или более линка и собрать по агрегированному каналу между всеми? Если на коммутаторах включён STP он будет работать с агрегированными каналами как с обычными портами и кого-то заблокирует.
Хотелось бы пояснения за стек. Вы, условно, объединяете L3 между собой кабелем. Это считается кабель для стекирования или для передачи данных (резервный канал) и не будет-ли там петель? (Как я понял, на л3 петель уже не может быть) хотелось бы просвещения в этом :)
на сервере 4 порта 10G хотим файловый сервер на него закинуть, ну может пока что контроллер домена, а коммутаторы пока ток 1G, ядра сети вроде пока нет чётко выраженного.(я не сетевик, запрягли и занимаюсь самообучением). Имеет смысл в коммутатор подключать через 4 порта этот сервер чтобы всё работало хотя бы на 1Gx4? или пинать начальство на нормальный коммутатор с 10Gx48 портами? имеет ли смысл подключать файловый сервер с 10G на 40G, на сервере установлен hyper-V core, там можно создать виртуальный коммутатор на 4х физических подключениях switch Embedded Teaming (SET). коммутатор простой d-Link на 48 портов 1g(DGS-1510-52XMP), есть слоты под 10G но пустые, без разъемов. ну и половина организации всё ещё на 100мб/с, компов штук 500. планируется всех в AD засунуть а потом рабочие столы на сервере хранить. текущий файловый сервер на 775 сокете через 1Gb работает, вроде пока хватает
1. Да сервер можно сразу включить агрегиррованными линками 4х1G. Чуть сложнее, но возможно улучшит пропускную для арм, тут важно выбрать правильные параметры хеширования линка. 2. Перевод серверов на 10 или 40g обычно истрия про ЦОД. В вашем случае 10g стоит рассматривать, если вы утилизируете на линке агрегированные 4g и если в инфраструктуре найдутся коммуитаторы с портами 10g, купить сетевую карту серверу не проблема. 3. Менять не менять коммутаторы. Это зависит от ваших целей, а вы еще не знаете что и как у вас нагружено. Выход один: настраивать как есть а потом собирать статистику, и вот если в рабочие пики все будет забито, то думать: докупать ли модули в коммутаторы или просить новые с аплинками 10g.
@@Networkisreachable понял, спасибо, начальник так же говорит, сначала делайте, потом когда потребность возникнет, закупим, а закупать и разбираться куда воткнуть это не дело)))
Есть ли коммутаторы и технологии, позволяющие выбирать порт для отправки кадра в агрегированном канале на основании мгновенной текущей занятости портов? Собственно, это первое, что приходит на ум, когда начинаешь вникать в агрегирование. То есть, положим, ASIC получает кадр на передачу и отправляет его в тот порт, который не занят передачей в данный момент. EtherChannel выглядит откровенным костылем на этом фоне- он никогда не даст реальной 100% утилизации суммарной пропускной способности физических линий.
Других альтернатив нет по сути, только стекирование (если вы две железки объединяете). Важнее трафик разложить так, чтоб сесии шли каждая по своему линку, иначе кадры могут "обгонять" впереди идущие и на выходе будет непоследовательная цепочка пакетов ,что приведет к низкой производительности конкретной сессии и хоста. Да агрегирование это очень условная технология по размазке трафика, это всегда и нужно держать в уме. Но есть железки которые вплоть до TCP порта используют в хешировании (а не только мас и ip) и трафик раскладывается успешно.
Спасибо за очередную классную лекцию !
00:00:00 Агрегирование Начало
00:01:15 Отличие STP
00:03:15 Ограничение оборудования на подключение Агрегированного канал
00:06:50 ПРотоколы агрегирования
00:09:37 EtherChannel CIsco
00:19:50 PAgP
00:21:40 LACP IEEE 802.3ad
00:27:00 NIC teaming , LAG
Отличные понятные объяснения, без воды!👍
Я так попал с LACP -)... Этому спикеру +5 баллов в карму, ибо он озвучил самый большой гемор с аргегированием каналов.
Уважаемые зрители! Если видео лекции/практики оказалось полезным,
поддержите ролик лайком и комментарием, это поможет ознакомить
с ним большую аудиторию. Спасибо.
Анонсы, обсуждения, вопросы тут: t.me/nir_net
Для желающих поддержать канал boosty.to/nir_net
Спасибо! Отличное объяснение.
Спасибо за ваши уроки
Спасибо за видео
В коммутаторах 3Com лет 20 назад я встречал, что агрегирование линков (каналов) называлось Trunk, а HP видимо от них и "заразилось" после покупки 3COM
Возможно, аналогично и у d-link, huawei, H3C
Спасибо за видео! Как всегда круто) Вопрос. если мы соединяем 3 коммутатора между собой кольцом (петлей) , то сначала мы должный настроить агрегацию (LACP), а потом на логических каналах настроить STP чтобы не было петли? И есть ли необходимость в STP протоколе, если мы можем с помощью LASP добиться некой отказоустойчивости, пусть не такой надежной как через STP?
Вы собираетесь между всеми тремя кинуть по 2 или более линка и собрать по агрегированному каналу между всеми? Если на коммутаторах включён STP он будет работать с агрегированными каналами как с обычными портами и кого-то заблокирует.
Хотелось бы пояснения за стек. Вы, условно, объединяете L3 между собой кабелем. Это считается кабель для стекирования или для передачи данных (резервный канал) и не будет-ли там петель? (Как я понял, на л3 петель уже не может быть) хотелось бы просвещения в этом :)
В данной теме речь о стеке не идет, тут обычная агрегация двух и более линков. Петель в таком линке нет, он представляет собой одно целое.
На слайде 40:05 порты одинаковые, а должны быть, по логике, разные и из них собираться порт-ченел :)
Да, там досадная ошибка на слайде.
на сервере 4 порта 10G хотим файловый сервер на него закинуть, ну может пока что контроллер домена, а коммутаторы пока ток 1G, ядра сети вроде пока нет чётко выраженного.(я не сетевик, запрягли и занимаюсь самообучением). Имеет смысл в коммутатор подключать через 4 порта этот сервер чтобы всё работало хотя бы на 1Gx4? или пинать начальство на нормальный коммутатор с 10Gx48 портами? имеет ли смысл подключать файловый сервер с 10G на 40G, на сервере установлен hyper-V core, там можно создать виртуальный коммутатор на 4х физических подключениях switch Embedded Teaming (SET). коммутатор простой d-Link на 48 портов 1g(DGS-1510-52XMP), есть слоты под 10G но пустые, без разъемов. ну и половина организации всё ещё на 100мб/с, компов штук 500. планируется всех в AD засунуть а потом рабочие столы на сервере хранить. текущий файловый сервер на 775 сокете через 1Gb работает, вроде пока хватает
1. Да сервер можно сразу включить агрегиррованными линками 4х1G. Чуть сложнее, но возможно улучшит пропускную для арм, тут важно выбрать правильные параметры хеширования линка. 2. Перевод серверов на 10 или 40g обычно истрия про ЦОД. В вашем случае 10g стоит рассматривать, если вы утилизируете на линке агрегированные 4g и если в инфраструктуре найдутся коммуитаторы с портами 10g, купить сетевую карту серверу не проблема. 3. Менять не менять коммутаторы. Это зависит от ваших целей, а вы еще не знаете что и как у вас нагружено. Выход один: настраивать как есть а потом собирать статистику, и вот если в рабочие пики все будет забито, то думать: докупать ли модули в коммутаторы или просить новые с аплинками 10g.
@@Networkisreachable понял, спасибо, начальник так же говорит, сначала делайте, потом когда потребность возникнет, закупим, а закупать и разбираться куда воткнуть это не дело)))
Есть ли коммутаторы и технологии, позволяющие выбирать порт для отправки кадра в агрегированном канале на основании мгновенной текущей занятости портов? Собственно, это первое, что приходит на ум, когда начинаешь вникать в агрегирование. То есть, положим, ASIC получает кадр на передачу и отправляет его в тот порт, который не занят передачей в данный момент. EtherChannel выглядит откровенным костылем на этом фоне- он никогда не даст реальной 100% утилизации суммарной пропускной способности физических линий.
Других альтернатив нет по сути, только стекирование (если вы две железки объединяете).
Важнее трафик разложить так, чтоб сесии шли каждая по своему линку, иначе кадры могут "обгонять" впереди идущие и на выходе будет непоследовательная цепочка пакетов ,что приведет к низкой производительности конкретной сессии и хоста.
Да агрегирование это очень условная технология по размазке трафика, это всегда и нужно держать в уме. Но есть железки которые вплоть до TCP порта используют в хешировании (а не только мас и ip) и трафик раскладывается успешно.
так и не показал конфигурацию
Можно посмотреть тут ua-cam.com/video/plmHOO21Rqc/v-deo.htmlsi=r--KJCHxYTVFEcj9
+Plus
+