Варианты дизайна. Подключение к Интернет #1 

Networker Channel доброго времени суток. Есть пару вопросов. Как связаться лично?

самое суперское разъяснение... и чувствуется как вам хочется поделиться знаниями, пасиба!

практические настройки бюджетных сетей есть? в моем случаи это Длинк

Спасибо! Декабрь и январь как всегда очень насыщены. Так что, вот возвращаюсь. Идей много. Буду пытаться находить время, чтобы их реализовывать. Еще раз спасибо!

Круто! Спасибо!

Спасибо большое, очень много значат для меня такие комментарии.

Спасибо! Помогаю мои видео в жизни? Каждому "творцу" интересно знать, насколько успешно были применены знания в жизни. Напиши, пожалуйста, пару слов.

Хорошая тема. Я не планировал подробно освещать сетевую безопасность. Но, с точки зрения дизайна у меня есть несколько мыслей: как и где использовать, что умеет, для чего лучше использовать. В общем, ответы на наиболее часто задаваемые вопросы.

Спасибо большое!

Топологии колец: Korenix - корейская фирма, использует для построения избыточных путей протокол собственный поверх Ethernet: Super Ring или Rapid Super Ring или что-то подобное. Вот тут есть брошюра www.korenix.ru/pdf/korenix.pdf - думаю на русском. На самом деле Ethernet НЕ использует кольцо: его топология ВСЕГДА логическая шина. Т.е. защиту от колец и быстрое переключение маршрутов можно на суб-секундном уровне реализовывать на Rapid PVST+ от cisco или стандартизованных RSTP и MSTP. Кореникс говорит о времени переключении 20 мс или 5 мс на "крутых" железках. RSTP при правильной топологии может переключиться быстрее. Не вижу смысла углубляться в частные (propriatary) технологии, вместо того, чтобы изучить стандартизованные. Если только не нужно внедрение Korenix в конкретном проекте, среде (это все таки промышленные коммутаторы). У Cisco тоже есть промышленные коммутаторы )

Да, это к сожалению так. Думаю есть варианты сделать это в ближнем зарубежье. Но, сам я не прорабатывал этот вопрос. Спасибо большое за Ваш комментарий.

Спасибо. Это visio 2016

буду стараться делать новые ) спасибо!

Нет, такого курса нет, к сожалению. Но, может быть образовательные полезные материалы Вы найдете тут А также тут cscomarathon.ru/materials А также я советую вам поискать материалы по курсу CCNA, подписаться на форму коих много в каналах телеграмм

Вы очень правильные вопросы задаёте. Это говорит о том что и думаете в правильном направлении. Гостевой и игровой, в чем разница? Вай вай может быть хоть 1, хоть 10GB, но полезный трафик для гостей будет зависеть от ширины канала в Интернет. L3 коммутатор вряд-ли нужен в такой сети. Тогда вопрос разграничения частично отпадает, а частично переходит на маршрутизатор.

Спасибо! Гостевой в том смысле, что любые посетители (даже те, кто не играть пришел, а скажем смотреть турнир какой-нибудь) могли через точку доступа зайти в интернет по нужде (так делают например в кафе). Ну и получается им не нужна огромная полезная пропускная способность. А не будет ошибкой если я все таки использую L3 свич и разделю всё на VLANы? Просто мне почему-то рекомендовали вынести все сервера (даже те, на которых игроки должны играть) в отдельный VLAN, - по мне это странно, но тем не менее в таком случае нужно обеспечить быструю связь между VLANами игроков и VLAN серверов, а делается это правильнее через L3 свич все-таки как я понимаю. Хотя для меня это звучит как "выстрели себе в ногу". Может я ошибаюсь? UPD: Ну и плюс на L3 коммутаторе можно сразу запретить ходьбу из игровых подсетей в management

Да, можно использовать L3 коммутатор. В этом случае его преимущества очевидны.

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

А также, если платнируется использовать между ядром сети и распределением - L3, то использование HSRP/VRRP/GLBP вполне оправдано. Если у вас свернутое ядро (т.е. фунцкции ядра и распределения выполняются на одном устройстве), то тут тоже возможны варианты. Вопрос дизайна всегда выбирает админ исходя из конкретных вариантов их топологии )

Эрик, а что такое "видел общую"? Что имеется в виду: общий трафик в Интернет? Были бы доступны обе сети? Вы это можете сделать просмотрев мой следующий ролик о дизайне. В самом простом вариианте с InterVlan роутингом и списками доступа.

Добрый день. NAT на коммутаторах не поддерживается. Эта функция для маршрутизаторов и файерволов, тапи ASA, Firepower и др. На ASA и FP функциональность NAT гораздо шире, чем на маршрутизаторах.

Добрый день! NAT не делают на коммутаторах третьего уровня. Он должен делаться на маршрутизаторах или фаайерволах.

@@NetworkerChannel спасибо. Дошло.

сам себе неплохо ответил)

Всё дело в определении что вы называете тем или иным NAT.

Если над затрагивает пор в TCP or UDP, да безусловно этот нат работает 4 уровне.

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

И большое спасибо, за ваши труды, смотрю с большим интересом. Да ещё и спросить можно)! 😊

Добрый день, Егор! Вы имеете в виду при подключении с Автономной системой и использовании BGP?

Да. Но, чтобы ip были доступны в 2х разных цодах. К цодам подключены разные операторы.

К каждому ЦОДу оба оператора подключены, или к одному один, а к другому другой?

к одному один, а к другому другой. Т.к. этот случай чаще случается

Нет, это невозможно. LACP согласует состояние агрегированного канала с 2-х сторон. На 2-х соединенных коммутаторах. Другие протоколы умеют согласовывать агрегацию канала на нескольких (более 2х) соединенных коммутаторах, например на Cisco NEXUS это vPC - Virtual Port Channel, или это может делать функциональность VSS для Cisco Catalyst 45/65/68хх серий. А в случае подключения к 2-м операторам связи общего у них ничего нет, поэтому агрегировать каналы не получится.

С точки зрения балансировки трафика между операторами, можно использовать Policy Based Routing (PBR), так он называется у Cisco, у других вендоров есть похожие технологии. Но, я не очень рекомендую его использовать: грузит CPU (далеко не во всех устройствах PBR реализован на уровне микросхем ASIC шины данных), тяжело таублшутить ))

Спасибо большое !

Всегда пожалуйста)

Планировал, не знаю только что именно было бы полезно )

Была бы полезна практическая часть настройки различных вариантов дизайна в GNS3.

Ещё было бы полезно получить советы (некий tips & tricks) по работе с wireshark, для траблшутинга.

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

Сниферы в качестве траублшутинга - это уже уровень повыше, чем просто CCNA, мой канал ориентируется на людей начинающих. Хотя тематика снифера интересна сама по себе. Но, IMHO, чтобы работать со снифером, нужно куда глубже знать технологии, чем обычны CCNA, да и в той же модели OSI разбираться хорошо нужно. С этой точки зрения, я whireshark и не показывают. Спасибо за комментарий! Может "дорасту" и до снифера ))

Физически в один порт 2 кабеля не подключить, конечно. Делается это так: устанавливается коммутатор, или выделяются на коммутаторе 3 порта, 2 из них в провайдеров, один - в маршрутизатор. В сторону маршрутизатора настраивается транк, в котором передаются со стороны каждого провайдера вланы, например 100 и 200. На маршрутизаторе настраиваются суб-интерфейсы (например gi1.100 и gi 1.200), они логические, но функционально будут работать как физические.

Зачетный комментарий! Спасибо! Это верно. Исходящий трафик, порожденный маршрутизатором, не будет регламентироваться на исходящем интерфейсе с помощью акцесс листа на этом интерфейсе )) Но, трафик поражденный маршрутизатром будет всегда исходящим, т.е. out, однако акцесс лист нужно использовать в route map и регламентировать такой тип трафика через настройку в разделе маршрутизатора Control Plane. Отличный комментарий и ссылка в описании! спасибо!

Конечно не стоит! Это как правило разный тип трафика и зачем его смашивать. Просто настроить в другой влан. С точки срения управления и безопасности это плюс.

камеры сильно спамят широковещательным трафиком

это Microsoft Visio 2016, плюс собственные картинки + Cisco Visio Stensils. www.cisco.com/c/en/us/products/visio-stencil-listing.html

это был майкрософт визио, сейчас рисую все в PPT

ети и иже с ними Microsoft Vision 2016. Иконки дорисовывал местами сам

Конечно, от Vlan 1 нужно избавлятся.

@@NetworkerChannel спасибо!

Конечно, отзывы всегда лучше! И обратная связь, конечно!

Не все специалисты пренебрегают академическими знаниями. Особенно знаниями о модели OSI, а это самый базовый уровень. В тематике по дизайну никогда не бывает конкретики. Мы же не проект рассматриваем, а делимся знаниями. Кому-то они нужны, и эти люди понимают зачем. А кто-то выбирает иной путь. Как говориться, свое мнение имеют профессиональное право высказывать только эксперты. Спасибо за Ваш амбициозный комментарий. Он наверняка будет полезен и близок люди, разделяющим Вашу точку зрения.

Спасибо! Редко кто ставит плюсы за это видео, хотя оно и стоит этого. )))