добро пожаловать в open-source и вообще в *nix-way. Вам никто ничего не должен. Сделали что-то хорошее - радуйтесь, а не возмущайтесь. Возьмите, да напишите сами патч и отправьте пулл-реквест.
в ARPANET не было аналогов LAN. host-to-host всегда общались через IMP и не было никаких таких разделений на то что два хоста могут пообщаться друг с другом минуя IMP, просто узнав адрес друг-друга.
но с другой стороны IMP - это не просто роутер, как в текущем понимании. Т.к. логика слоя tcp работала именно на IMP. Ну вот фаргментация пакетов, подтверждения доставки, сборка пакетов обратно и гарантия очередности доставки.
Я бы сказал, что IMP больше похож на самом деле на брокер очередей, чем на роутер. Host-IMP - это скорее API к IMP. А host-host - это прям очередь.
ну не совсем ) что роутеры, что свитчи в итоге создают какую-то таблицу форвардинга (FIB) в которой хранят записи, что делать в зависимости от destination. И в принципе этот самый FIB одинаково сложный, что у роутеров, что у современных multilayer-свитчей - dest может быть как просто dst-mac, так и dst-ip или что-от еще суровее, так и "что делать" может быть просто "выплюнь в порт" или сложно "поменяй метку, перепиши dst"/"уложи в vni, отправь к другому vtep".
Вот только у свитчей бывает всего один тип интерфейсов - ethernet. Или ATM. Или infiniband. Или... Но не бывает свитча eth + FR. А роутер - бывает. Вот и основная разница.
Есть еще нюансики, конечно: посмотрите мой ответ ниже - https://habr.com/ru/articles/840116/comments/#comment_27237592
в современном мире функции роутеров и свитчей пересекаются. Большинство свитчей умеют маршрутизировать - если например на свитче создано несколько vlan-ов и каждому из них сконфигурирована своя подсеть с ip-адресом на виртуальном свитча, то свитч прекрасно будет маршрутизировать пакеты из одной подсети в другую и соответственно на выходе тегировать нужным vlan. Также многие свитчи L3+ умеют использовать протоколы маршрутизации как igp (ospf, eigp, isis), так и egp (bgp).
В свою очередь, современные роутеры могут коммутировать на основе данных из L2 - можно собрать из портов коммутируемую группу (у разных вендоров называется по-разному - bridge-group, brdige-domain и т.п.) и они будут работать как свитч.
Факторов разницы несколько:
порты на свитче одной и той-же технологии (ethernet, infiniband, ...), а на роутере могут одновременно быть совершенно разные порты - eth, atm, древний frame-relay, набор модемов 3g/4g/5g, какой-нить жуткий ds3/e3 и прочая экзотика; это ключевой момент из-за которого в принципе и появились роутеры;
портовая емкость - у свитчей как правило больше, впрочем бывают и роутеры с большим количеством портов;
стоимость портов на свитчах как правило в разы меньше; отсюда и портовая емкость;
функционал роутеров как правило гораздо шире. Протоколы маршрутизации умеют и свитчи запускать, mpls и evpn - тоже, а вот, допустим, быть vpn-клиентом и сервером или иметь развесистый иерархический QoS с парой сотен тысяч классов на одном интерфейсе - свитч так не умеет;
исходя из прошлого пункта - у роутеров гораздо сложнее и software и firmware (я имею в виду, то что исполняется на CPU и микропрограммы/архитектура ASICов);
а появились роутеры достаточно просто. Вот были несколько разных видов локальных сетей (lan - это сеть с одним видом технологии передачи данных и соответственно, как-то локализованная с точки зрения физики в которой хосты могут достигать друг-друга обращась по адресу привязанному непосредственно к интерфейсу (mac как-правило)) - token-ring такой, token-ring-сякой, eth, модемные пулы всякие. И если в lan-е или двух одинаковых lan-ах как-то можно общение наладить, то если есть сетка thin-TR, а в соседнем здании thick-TR и еще модемный пул рядом стоит - это беда. И нужно устройство, которое имеет набор интерфейсов с разной технологией, а более того идея как передавать данные между сетями с разной технологей. Нужна абстракция, с адресами непривязанными к железу и методы связывания абстрактных адресов с физическими. Вот отсюда и появился IP - это та самая абстракция и ARP или NDP и методы инкапсуляции данных как связь абстракции с реальностью. Ну и устройство с разными интерфейсами и работающее на основе именно адресов внутри этой абстракции (см. пункт первый в описании про роутеры) - роутер. Всё предельно просто и вытекает логично из необходимостей. Там еще много было всего связанного с отказоустойчивостью, потерями, надежностью и т.д и всё разрабатывалось одновременно, поэтому не просто ip, а сразу tcp/ip, но именно роутеры появились из-за IP.
нет. это вообще не нужно. это не имеет никакого отношения к технической стороне, это коммерческая организация.
Лучше скажите, чем роутер от свитча отличается? Принимая во внимание соверменные multi-layer свитчи, которые и ipv4/ipv6 маршрутизировать умеют и vxlan и evpn и даже bgp )) А начать стоит именно с этого - зачем появились роутеры.
да нет, все работает так. только предпосылки совершенно неправильно поданы. Или вообще не поданы. Зачем нужно разделение на роутеры и свитчи сказано два предложения и совершенно не раскрывающих проблематики и зачем оно в принципе нужно. в ARPANET были IMP которые суть роутеры и адресация сложнее чем в IP, но вот почему-то пришли не только к IP, но и к tcp/ip и вообще этим пресловутым 7 уровням - зачем, почему, откуда - никакой информации. Туповато.
даже интересно стало, с чего бы это сбой в канале должен приводить к повторной передаче аж 5-10% данных за час? 30mbps, если мне не изменяет память, это примерно 3мегабайта в секунду полезных данных, то есть чуть больше 10 гигабайт в час. Значит потеряется 1 гигабайт, то есть 10 гигабит с заголовками, ну предположим, что это 625 мегасимволов при модуляции 16 бит на символ (это довольно сильно). Соотвественно в 100mbps канале с модуляцией 16bps в секунду сериализутся примерно 6,2 мегасимвола. Допустим, что среда передачи - оптоволокно с коэффициентом преломления примерно 1,6 и свет в нем имеет скорость 187500км/сек. Таким оборазом в канале будет передаваться примерно 33 символа на километр. Чтобы при единичной проблеме потерялись сразу 625 мегасимволов - они должны сериализоваться в канал и не десеарилизоваться из него, то есть потеряться при распространении, то есть полностью влезть в канал связи... 625*10^6 / 33 = 18 миллионов километров канала. Автор несет несусветную ху... рму.
ну вы изобрели очередной велосипед, чем славен Яндекс. Дальше нормальная СБ вас попросит расширить на бастионе поддержку протоколов с ssh до rdp/vnc, включить запись экранов, сделать модерируемую сессию админов с красной кнопкой у ИБ "отключить его нафиг", прикрутить к сессии DLP... И все это перерастет наконец-то в нормальный PAM (Privileged Access Management) коих на рынке - десятки.
так домашняя хранилка или лаба? начнем с того, что минус за кликбейтный заголовок.
Дальше минусы кончились, но были бы - за несоотвествие темы содержимому; за много воды ни о чем; за затертые темы "я тут не смог сделать нормальный nas"; отдельный минус за слово сторадж (поясню, английское storage произносится как сторейдж)
так-то ipv6 teredo нельзя назвать "доступ за NAT", т.к. адрес вам выдается глобальный, маршрутизируемый в инторнетах и считай, что сервер выставлен голым задом в инторнет. Префикс 2001::/16 входит в блок 2000::/3, который и есть Global unicast. Просто teredo - это такой специальный способ выставить голый зад из приватного ipv4 в публичный ipv6.
два момента... 1) нафига вы пишите статью, суть которой - ссылка на 7и минутное видео? Читая статью на хабре я не хочу смотреть видео, я хочу именно читать.
2) суть всей домашней виртуализации - это найти железо. если ты намыл где-то сервант с 128Gb Ram и 32cpuCores, то всё остальное - это мелочи недостойные упоминания
если постоянно общаешься с драконами, то сам становишься драконом. Вот и тут типичный сотрудник HR проецирует свои взгляды но область в которой не разбирается. Поверьте, HR-проблемы (к слову, описаны довольно точно) лишь 10-20% от всех проблем тим-лида. Основные проблемы которые решает тим-лид - это взаимодействие команды с внешним миром и внутренние бурления в команде. И обе они - пропасть.
чем "отечественный РП" отличается от нормального PM - рассказано в этой статье. single point of contact? не, не слышали. Project scope definition - вы офанарели, я тут документацию не пишу, а контролирую! Еще попросите к боссам сходить, когда в проект пихают всякое, но без денег, сроков и людей... Составление плана проекта, нарисовать диграмму Ганта - да вы смеетесь, вы, что сами безрукие?! Предпроектные активности типа поиска ресурсов и оценки целесообразности - я должен за начальников работу работать?
самое прикольное в том, что не mininet ни k8s-netsim не позволят эмулировать действительные проблемы, их достаточно лишь для изучения каких-то минимальных начальных основ. Например, основные беды openFlow случаются в тот момент, когда сильно кастомный доработанный openVswitch, dpdk и свой контроллер - и ну никак ты их не разместишь на одном хосте, даже если вычислительных ресурсов хоста хватает. Или те же "сетевые топологии в k8s" - это не сеть про сеть, а про упоротый фланнель или сервис-меш )
у наших решений есть две проблемы - 1) отсутствие стандартизации вместо с велосипедостроением - в итоге cisco с juniper прекрасно строят ipsec, а вот S-Terra с VipNet - нет, хотя ГОСТ, который впрочем описывает только алгоритм... 2) все наши решения - это linux на x86, ну или в последнее время на arm. Ну то есть шифрование на процессоре общего назначения, который при этом еще и роутит и линукс на себе запущает... никаких гарантий времени шифрования/дешифрования, чтоб можно было выстроить простую и логичную обработку трафика
эммм... мне казалось, что поезд должен ездить. Иначе это урок жесточайшего хардкодинга и детям с первых уроков надо говорить, что так делать нельзя.
добро пожаловать в open-source и вообще в *nix-way. Вам никто ничего не должен. Сделали что-то хорошее - радуйтесь, а не возмущайтесь. Возьмите, да напишите сами патч и отправьте пулл-реквест.
Привет! начните с этого:
https://linkmeup.ru/sdsm/
там целый цикл статей, найдите начало - 0ю часть - и прямо вот с неё.
в ARPANET не было аналогов LAN. host-to-host всегда общались через IMP и не было никаких таких разделений на то что два хоста могут пообщаться друг с другом минуя IMP, просто узнав адрес друг-друга.
но с другой стороны IMP - это не просто роутер, как в текущем понимании. Т.к. логика слоя tcp работала именно на IMP. Ну вот фаргментация пакетов, подтверждения доставки, сборка пакетов обратно и гарантия очередности доставки.
Я бы сказал, что IMP больше похож на самом деле на брокер очередей, чем на роутер. Host-IMP - это скорее API к IMP. А host-host - это прям очередь.
вот описание IMP:
https://walden-family.com/impcode/BBN1822_Jan1976.pdf
ну не совсем ) что роутеры, что свитчи в итоге создают какую-то таблицу форвардинга (FIB) в которой хранят записи, что делать в зависимости от destination. И в принципе этот самый FIB одинаково сложный, что у роутеров, что у современных multilayer-свитчей - dest может быть как просто dst-mac, так и dst-ip или что-от еще суровее, так и "что делать" может быть просто "выплюнь в порт" или сложно "поменяй метку, перепиши dst"/"уложи в vni, отправь к другому vtep".
Вот только у свитчей бывает всего один тип интерфейсов - ethernet. Или ATM. Или infiniband. Или... Но не бывает свитча eth + FR. А роутер - бывает. Вот и основная разница.
Есть еще нюансики, конечно: посмотрите мой ответ ниже - https://habr.com/ru/articles/840116/comments/#comment_27237592
в современном мире функции роутеров и свитчей пересекаются. Большинство свитчей умеют маршрутизировать - если например на свитче создано несколько vlan-ов и каждому из них сконфигурирована своя подсеть с ip-адресом на виртуальном свитча, то свитч прекрасно будет маршрутизировать пакеты из одной подсети в другую и соответственно на выходе тегировать нужным vlan. Также многие свитчи L3+ умеют использовать протоколы маршрутизации как igp (ospf, eigp, isis), так и egp (bgp).
В свою очередь, современные роутеры могут коммутировать на основе данных из L2 - можно собрать из портов коммутируемую группу (у разных вендоров называется по-разному - bridge-group, brdige-domain и т.п.) и они будут работать как свитч.
Факторов разницы несколько:
порты на свитче одной и той-же технологии (ethernet, infiniband, ...), а на роутере могут одновременно быть совершенно разные порты - eth, atm, древний frame-relay, набор модемов 3g/4g/5g, какой-нить жуткий ds3/e3 и прочая экзотика; это ключевой момент из-за которого в принципе и появились роутеры;
портовая емкость - у свитчей как правило больше, впрочем бывают и роутеры с большим количеством портов;
стоимость портов на свитчах как правило в разы меньше; отсюда и портовая емкость;
функционал роутеров как правило гораздо шире. Протоколы маршрутизации умеют и свитчи запускать, mpls и evpn - тоже, а вот, допустим, быть vpn-клиентом и сервером или иметь развесистый иерархический QoS с парой сотен тысяч классов на одном интерфейсе - свитч так не умеет;
исходя из прошлого пункта - у роутеров гораздо сложнее и software и firmware (я имею в виду, то что исполняется на CPU и микропрограммы/архитектура ASICов);
а появились роутеры достаточно просто. Вот были несколько разных видов локальных сетей (lan - это сеть с одним видом технологии передачи данных и соответственно, как-то локализованная с точки зрения физики в которой хосты могут достигать друг-друга обращась по адресу привязанному непосредственно к интерфейсу (mac как-правило)) - token-ring такой, token-ring-сякой, eth, модемные пулы всякие. И если в lan-е или двух одинаковых lan-ах как-то можно общение наладить, то если есть сетка thin-TR, а в соседнем здании thick-TR и еще модемный пул рядом стоит - это беда. И нужно устройство, которое имеет набор интерфейсов с разной технологией, а более того идея как передавать данные между сетями с разной технологей. Нужна абстракция, с адресами непривязанными к железу и методы связывания абстрактных адресов с физическими. Вот отсюда и появился IP - это та самая абстракция и ARP или NDP и методы инкапсуляции данных как связь абстракции с реальностью. Ну и устройство с разными интерфейсами и работающее на основе именно адресов внутри этой абстракции (см. пункт первый в описании про роутеры) - роутер. Всё предельно просто и вытекает логично из необходимостей. Там еще много было всего связанного с отказоустойчивостью, потерями, надежностью и т.д и всё разрабатывалось одновременно, поэтому не просто ip, а сразу tcp/ip, но именно роутеры появились из-за IP.
так а что же свитч L3? с ним как быть?
нет. это вообще не нужно. это не имеет никакого отношения к технической стороне, это коммерческая организация.
Лучше скажите, чем роутер от свитча отличается? Принимая во внимание соверменные multi-layer свитчи, которые и ipv4/ipv6 маршрутизировать умеют и vxlan и evpn и даже bgp )) А начать стоит именно с этого - зачем появились роутеры.
да нет, все работает так. только предпосылки совершенно неправильно поданы. Или вообще не поданы. Зачем нужно разделение на роутеры и свитчи сказано два предложения и совершенно не раскрывающих проблематики и зачем оно в принципе нужно. в ARPANET были IMP которые суть роутеры и адресация сложнее чем в IP, но вот почему-то пришли не только к IP, но и к tcp/ip и вообще этим пресловутым 7 уровням - зачем, почему, откуда - никакой информации. Туповато.
даже интересно стало, с чего бы это сбой в канале должен приводить к повторной передаче аж 5-10% данных за час? 30mbps, если мне не изменяет память, это примерно 3мегабайта в секунду полезных данных, то есть чуть больше 10 гигабайт в час. Значит потеряется 1 гигабайт, то есть 10 гигабит с заголовками, ну предположим, что это 625 мегасимволов при модуляции 16 бит на символ (это довольно сильно). Соотвественно в 100mbps канале с модуляцией 16bps в секунду сериализутся примерно 6,2 мегасимвола. Допустим, что среда передачи - оптоволокно с коэффициентом преломления примерно 1,6 и свет в нем имеет скорость 187500км/сек. Таким оборазом в канале будет передаваться примерно 33 символа на километр. Чтобы при единичной проблеме потерялись сразу 625 мегасимволов - они должны сериализоваться в канал и не десеарилизоваться из него, то есть потеряться при распространении, то есть полностью влезть в канал связи... 625*10^6 / 33 = 18 миллионов километров канала. Автор несет несусветную ху... рму.
ну вы изобрели очередной велосипед, чем славен Яндекс. Дальше нормальная СБ вас попросит расширить на бастионе поддержку протоколов с ssh до rdp/vnc, включить запись экранов, сделать модерируемую сессию админов с красной кнопкой у ИБ "отключить его нафиг", прикрутить к сессии DLP... И все это перерастет наконец-то в нормальный PAM (Privileged Access Management) коих на рынке - десятки.
так домашняя хранилка или лаба? начнем с того, что минус за кликбейтный заголовок.
Дальше минусы кончились, но были бы - за несоотвествие темы содержимому; за много воды ни о чем; за затертые темы "я тут не смог сделать нормальный nas"; отдельный минус за слово сторадж (поясню, английское storage произносится как сторейдж)
ну если без свитча, то зачем морочиться ethernet-ом? Две карточки infiniband на озоне стоят ~12тыр, кабель еще 3. Будет 40g )
так-то ipv6 teredo нельзя назвать "доступ за NAT", т.к. адрес вам выдается глобальный, маршрутизируемый в инторнетах и считай, что сервер выставлен голым задом в инторнет. Префикс 2001::/16 входит в блок 2000::/3, который и есть Global unicast. Просто teredo - это такой специальный способ выставить голый зад из приватного ipv4 в публичный ipv6.
два момента... 1) нафига вы пишите статью, суть которой - ссылка на 7и минутное видео? Читая статью на хабре я не хочу смотреть видео, я хочу именно читать.
2) суть всей домашней виртуализации - это найти железо. если ты намыл где-то сервант с 128Gb Ram и 32cpuCores, то всё остальное - это мелочи недостойные упоминания
если постоянно общаешься с драконами, то сам становишься драконом. Вот и тут типичный сотрудник HR проецирует свои взгляды но область в которой не разбирается. Поверьте, HR-проблемы (к слову, описаны довольно точно) лишь 10-20% от всех проблем тим-лида. Основные проблемы которые решает тим-лид - это взаимодействие команды с внешним миром и внутренние бурления в команде. И обе они - пропасть.
чем "отечественный РП" отличается от нормального PM - рассказано в этой статье. single point of contact? не, не слышали. Project scope definition - вы офанарели, я тут документацию не пишу, а контролирую! Еще попросите к боссам сходить, когда в проект пихают всякое, но без денег, сроков и людей... Составление плана проекта, нарисовать диграмму Ганта - да вы смеетесь, вы, что сами безрукие?! Предпроектные активности типа поиска ресурсов и оценки целесообразности - я должен за начальников работу работать?
самое прикольное в том, что не mininet ни k8s-netsim не позволят эмулировать действительные проблемы, их достаточно лишь для изучения каких-то минимальных начальных основ. Например, основные беды openFlow случаются в тот момент, когда сильно кастомный доработанный openVswitch, dpdk и свой контроллер - и ну никак ты их не разместишь на одном хосте, даже если вычислительных ресурсов хоста хватает. Или те же "сетевые топологии в k8s" - это не сеть про сеть, а про упоротый фланнель или сервис-меш )
божечки... вы б лучше рассказали как подружить инфраструктуру и затертый богами agile
у наших решений есть две проблемы - 1) отсутствие стандартизации вместо с велосипедостроением - в итоге cisco с juniper прекрасно строят ipsec, а вот S-Terra с VipNet - нет, хотя ГОСТ, который впрочем описывает только алгоритм... 2) все наши решения - это linux на x86, ну или в последнее время на arm. Ну то есть шифрование на процессоре общего назначения, который при этом еще и роутит и линукс на себе запущает... никаких гарантий времени шифрования/дешифрования, чтоб можно было выстроить простую и логичную обработку трафика