Бесклассовая маршрутизация в IPv4

Продолжаем разговор по курсу ICND1. И у нас следующая тема на повестке дня — это по-прежнему маршрутизация в протоколе IP. Предыдущее занятие было посвящено классовой маршрутизации, тот механизм маршрутизации, который в IP был предложен изначально. У нас есть пакеты. Эти пакеты перекладываются между отправителем и получателем каждый раз на транзитных узлах куда-то в сторону получателя. И все эти транзитные узлы, маршрутизаторы, они оперируют IP-адресом получателя, который в каждом пакете есть, он неизменный. И каждый транзитный узел смотрит на IP-шник получателя, смотрит на то, где этот IP-шник получателя будет находиться. При этом у нас появляется такое явление, как запись в таблице маршрутизации. И по этой самой таблице ищется та сеть, которая включает в себя IP-адрес получателя. При этом в таблице по факту присутствуют только IP-адреса самих сетей. И у каждого адреса сети есть левая часть,

которая будет называться Network ID, и правая часть, как у любого IP-адреса, у адреса сети тоже она есть. Но у адреса самой сети правая часть будет вся нулевая. Граница между левой и правой частью в классовой маршрутизации у нас проходит ровно в одном из трёх мест. Либо между первым и вторым октетом, если это адрес класса A, либо между вторым и третьим октетом, если это адрес класса B, либо между третьим и четвёртым октетом, если это адрес класса C. Сети бывают трёх размеров — безумным сетям. Адреса класса C принадлежат большим сетям. Всё просто. Но очень скоро, когда это всё пошло в продакшн, стало понятно, что три класса сетей и три размера сетей, большой, гигантский, безумный — это очень неудобно. И для того, чтобы адаптироваться к потребностям заказчиков, авторы протокола IP сказали, нам нужно будет предложить больше размеров сетей,

чтобы у нас была не градация большой, гигантский, безумный, а градация совсем маленький, чуть побольше, средний, нормальный, большой, гигантский, супергигантский, безумный. Не три размера на выбор давать, все из которых неудобны, а как-то более динамически подстраиваться под хотелки конечных пользователей. И от классовой маршрутизации, от определения того, где проходит граница между network ID и host ID в конкретном адресе по первым битам, отказались. Эта идеология была красивая, но она не прижилась. И из-за того, что адреса достаточно компактные, 32-битовые, получилось, что держать сети трёх разных размеров неудобно. Неудобно в том числе и потому, что это порождает катастрофически неэффективное расходование IP-адресов. И с 1985 года, точнее даже с 1984, буквально через три года

после того, как IP пошёл в продакшн, был предложен механизм, который отказывается от определения того, где проходят границы между левой и правой частью по первым битам IP-шника, и определение того, где проходит граница, становится каким-то другим. Давайте мы посмотрим на то, как это будет происходить. Бесклассовая маршрутизация и адресация появляется практически сразу после того, как IP пошёл в массы. В 1981 году IP у нас стандартизируется, в 1984 году появляется новый стандарт, который описывает механизм, который называется сабнетинг. Сабнетинг — это механизм, когда мы берём классовую сетку, делим её на части. При этом внутри самой этой сети, которую мы порежем на части, мы можем использовать адреса, у которых левая и правая часть уже имеют границу не в одном из трёх предсказуемых мест, а в практически произвольном месте.

Но при этом сабнетинг от всего остального будет отличаться тем, что вы внутри своей сети можете делать всё, что хотите. А наружу вы никому не говорите про то, что вы что-то там сделали. Давайте я попробую порисовать немножко и проиллюстрирую то, что я имею в виду. Выглядит это примерно так. У нас есть какие-то сети. Это, допустим, одна классовая сеть, это другая классовая сеть, это третья классовая сеть. Все эти сети соединяются между собой во всемирное взаимодействие, в сеть интернет. У нас каждая из этих сетей может быть классовая. Какие-то из этих сетей будут класса A, какие-то — класса B и C. Но если мы берём и получаем у глобального какого-то регистратора или регионального регистратора какую-то сеть, мы пошли, мы заплатили за неё денег, мы получили её в своё пользование.

И у всех остальных должно появиться понимание, что ваша сеть находится вот тут. И в таблице маршрутизации всех магистральных роутеров ваша сеть должна будет присутствовать. При этом вы можете взять и свою сеть поделить на части. И вы можете сказать, давайте мы разделим нашу большую сеть на 8 кусочков поменьше. Потому что что такое сеть? Это просто набор IP-адресов, у которых левая часть одинаковая, правая пробегает все возможные значения. И вы говорите, окей, мы получили какую-то пачку адресов, мы делим эту большую пачку на несколько подпачек. И в каждой подпачке у нас левая часть одинаковая, правая пробегает все возможные значения. Мы взяли одну пачку адресов, разделили на несколько. Каждая маленькая подпачка, которая получилась, это маленькая подпачка. Она в свою очередь получается какая-то независимая пачка, потому что у неё работает правило, что левая часть одинаковая, правая пробегает всевозможные значения, но при этом мы можем внутри своей сети эти пачки использовать как захотим.

Мы можем их раскладывать по отдельным каналам, делать с ними всё что угодно, но при этом снаружи мы про это никому ничего не рассказываем. Мы говорим всё равно, что это у нас единая монолитная классовая сеть, которую мы можем использовать как хотим, но она вся находится в одном и том же месте, поэтому все магистральные провайдеры всё равно думают, что ваша сеть классовая. Эта штука появилась в 1984 году, и она появляется как расширение для классовой модели интернета. Интернет всё ещё классовый, в интернете у нас по-прежнему все друг на друга смотрят, и все друг к другу подмигивают и говорят, да-да, мы понимаем, что у тебя всё ещё классовая сеть, хотя на самом деле уже начинают все использовать именно бесклассовую адресацию, с этим механизмом сабнетинга, когда одну большую пачку адресов вы делите на несколько. Эта штука позволяет намного более экономно расходовать IP-адреса, потому что если у вас есть, например, какая-то сеть, у вас здесь пользователи сидят, и здесь пользователи сидят. Здесь, допустим, 128 пользователей, ну, 100 пользователей,

и здесь 100 пользователей. И наружу вы смотрите в весь остальной мир через какой-то роутер. Если делать по науке, по тому, как это изначально протокол IP предусматривал, то вы сюда должны были сеть класса C купить, сюда должны были сеть класса C купить, и у вас получалось необходимо использовать две сети класса C, потому что сети бывают только трёх размеров в классовой адресации. Большой, гигантский, безумный. Сюда мы должны использовать сети большого размера, самый маленький из трёх вариантов, который предлагала индустрия. В случае с сабнетингом вы можете сказать, нам не нужно покупать две сети класса C. Нам можно купить одну сеть класса C, разбить её на две части, потому что в сети класса C у нас 256 адресов. Мы её делим пополам. Получается две пачки по 128 узлов. И нам вполне достаточно будет половинку сети класса C для того, чтобы использовать всё это дело как следует. Но да, наружу мы говорим, что у нас по-прежнему одна монолитная сеть класса C, а внутри сети уже используем две половинки независимо и обособленно.

Эта штука позволяет существенно более экономно расходовать адреса, у нас расход классовых сетей снизился, но это было только полумерой, потому что в таблицах маршрутизации магистральных роутеров в интернете всё равно про все сети необходимо было знать. Сколько этих сетей, там, 2 миллиона штук в адресном пространстве класса C, вот до 2 миллионов адресов вам в таблице маршрутизации магистральных роутеров нужно было запоминать. А, как уже говорилось, это практически недоступные на тот момент объёмы, которые просто невозможно было реализовать технологически. Поэтому, да, предприятия, которые вынуждены были покупать в изначальном классовом мире IP-сети, они сказали, круто, что вы придумали сабнетинг, мы теперь более экономно можем расходовать адреса, мы теперь можем платить меньше денег за эти сети. И наши проблемы решены. Но провайдеры стали жаловаться, что теперь входной порог стал ниже, поэтому компании, которые покупают адреса, их становится всё больше и больше.

На каждую компанию нужно отдельную классовую сеть в таблице маршрутизации каждого роутера иметь. Поэтому провайдеры запили и сказали, вы что, ребят, у нас таким образом места не хватает вообще никак в таблицах маршрутизации, давайте что-то делать. И в 92-м году RFC 1338 описывает механизм, который на тот момент уже фактически был готов к внедрению. Механизм называется супернетинг. Смысл заключается в том, что если у вас есть несколько классовых сетей, одна классовая сеть, вторая классовая сеть, третья классовая сеть, которые идут прямо по порядку, вы можете взять эти классовые сети, рассматривать как одну монолитную сеть, которая когда-то была разделена на несколько частей. Каждый из этих кусочков — классовый. Но мы можем сказать, что если в каждом из этих кусочков адреса идут по порядку, и мы берём несколько классовых сетей, которые тоже все идут по порядку, то в такой ситуации получится, что в совокупном пуле адресов

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

ARIN — США и Канада, латинская Америка — LACNIC, Африка — AfriNIC и Азия-Пасифик — APNIC. Пять региональных регистраторов, они получают пачки адресов, и эти пачки адресов обычно все идут по порядку. То получается, что мы можем взять и сказать, что если мы берём пачку адресов, которые идут по порядку, в которой много классовых сетей, они тоже все идут по порядку, то мы можем сказать, что есть у нас набор классовых сетей, которые в принципе складываются в одну большую суперсеть, и все эти адреса принадлежат одному региональному регистратору, допустим, AfriNIC. И дальше внутри Африки они уже раздаются. Но маршрут до всего континента Африки, до всего региона Африки, скорее всего, есть один какой-то, который более выгодный, или там два более выгодных. И дальше остальные маршруты будут менее выгодны. Поэтому мы можем сказать, давайте мы все эти мелкие сетки схлопнем в одну большую суперсеть, на неё поставим отдельный маршрут,

и дальше уже мы не будем знать отдельно про мелкие сетки. Вместо там тысячи мелких сетей у нас будет одна большая сеть. И таким образом объём таблиц маршрутизации будет сокращён. Как эта штука будет работать? Началось всё, как уже было сказано, с механизма сабнетинга. Он заключался в том, что у нас есть какая-то классовая сеть, и дальше мы её делим на части, но при этом не говорим ничего своему провайдеру. С точки зрения провайдера и с точки зрения всего остального мира мы всё ещё используем классовую сеть, а внутри нашей сети мы её делим на части и получаем много, но более мелких кусочков сетей. Штука называется сабнетинг. Для того, чтобы это работало, нам нужна родительская классовая сеть. И мы зафиксировали какие-то биты, которые относятся к Network ID. Допустим, нам дали сеть класса A. Мы фиксируем 8 бит Network ID родительской сети. Дальше. Мы хотим эту сеть разрезать на несколько кусков. В IP мы это делаем путём так называемого заимствования битов от Host ID.

В любом случае мы не можем лезть в биты Network ID, они у нас фиксированы, и изменять их мы не имеем права. А все адреса, которые принадлежат этой родительской сети, у них все биты Host ID пробегают все возможные значения. И мы можем сказать, давайте мы отберём те адреса, у которых некоторые первые биты Host ID будут какие-то конкретные. И фактически мы скажем, что если у нас есть большая классовая сеть, у неё есть зафиксированные биты Network ID, и есть биты Host ID, которые пробегают все возможные значения. От 0, 0, 0, 0, 0, 0, 0, 0 и так далее. От 0, 0, 0 до 1, 1, 1, 1, 1, 1, 1, 1 и так далее, 1, 1, 1, 1. Давайте зафиксируем все адреса, которые у нас есть в этой родительской сети, которые начинаются на битовую четвёрку 0. И у нас получится пачка адресов, у которой первые 8 бит такие же, как у Network ID родительской сети,

потом следующие 4 бита тоже нули, они тоже все одинаковые, потому что мы их отобрали таким образом. А все остальные биты, которые здесь есть, они пробегают все возможные значения. Мы в эту пачку адресов отобрали только такие IP-шники, но все такие IP-шники, у которых первые 4 бита host ID были нулевые. Что получается? Мы в эту пачку отобрали все адреса, у которых первые 12 бит будут зафиксированы и будут одинаковые, а все остальные пробегают все возможные значения. Таким образом, фактически, мы сделали новую сеть или новую подсеть, у которой эта часть одинаковая, а эта часть пробегает все возможные значения. Мы взяли 4 битика под адрес подсети, добавили их к зафиксированным битикам Network ID и получили 12-битный новый адрес сети, новый Network ID. А правая часть у нас сократилась по размеру, но она всё равно пробегает все возможные значения. Точно так же мы фиксируем отдельно все адреса,

у которых первые биты будут не 0, 0, 0, 0, а 0, 0, 0, 1, потом 0, 0, 1, 0, потом 0, 0, 1, 1 и так далее. Вместо одной безумного размера сети класса A мы сделали 16 подсетей, у которых в каждой подсети левые 12 бит зафиксированы, а правые 20 пробегают все возможные значения. По факту мы для каждого конкретного адреса сместили границу между левой и правой частью из того места, где она была в классовой сети, вправо на 4 бита. Как раз те самые 4 бита, которые были заимствованы под subnet ID. Такая штука. Это и называется subnetting. Для того, чтобы по внешнему виду IP-шника можно было в классовом мире определить, где проходит граница между левой и правой частью,

мы смотрели на начало IP-адреса. И говорили, если у нас адрес класса A, то граница проходит между первым и вторым октетом. Если адрес класса B, то между вторым и третьим. Для адреса класса C — между третьим и четвёртым. В бесклассовом мире, где у нас появляется возможность сдвигать границу между левой и правой частью адреса вправо на произвольное количество битов, у нас появляется вопрос, А каким образом теперь мы будем определять, где проходит эта самая граница. И в бесклассовом мире появляется такая концепция, которая называется маска сети. Это всего лишь указание, где у конкретного данного нам адреса проходят границы между левой и правой частью. Это механизм, с помощью которого мы вместо того, чтобы смотреть на первые биты адреса, будем определять размер Network ID. RFC 950, тот, который про сабнетинг рассказывал, он описывает эту самую маску сети как 32-битное значение, 32-битное число,

состоящее из ноликов и единичек. И все адреса, которые принадлежат к одной и той же сети, все должны иметь одинаковые биты Network ID. И RFC 950 говорил: давайте мы сделаем такое 32-битное число, которое будет записываться рядом с IP-адресом, которое тоже 32-битное число. И в этой самой маске у нас биты будут выставляться в единичку, если в соответствующем бите IP-адреса битик является частью Network ID, и нолик в маске будет записан в конкретном бите, если в оригинальном IP-адресе этот же бит является частью Host ID. По сути, у нас есть какой-то IP-адрес. Раньше мы смотрели на первые биты, и для адреса класса C у нас там были биты 1, 1, 0, что у нас там? 0, 0, 0, 0, 0. Вот такое число. 192, дальше 168, это у нас 1, 0, 1, 0.

Это 160. 1, 0, 0, 0. Вот так. Это второй октет. Дальше 0, 0, 0, 0, 0, 0, 0, 0. Третий октет 0, 0, 0, 0, 0, 0, 0, 1. Планировать наперёд — не моя сильная сторона. Вот такой адрес: 192.168.0.1. Это в битовом виде я просто записал. И если мы хотим сказать, что у нас граница между левой и правой частью проходит не в том виде, где она должна была проходить в классовом мире, между третьим и четвёртым октетом, а смещена вправо, раз уж у меня здесь нарисована линия, то смещена вправо как раз на 4 бита. То для того, чтобы это сделать, я могу воспользоваться маской, которая будет состоять из таких битов, ноликов и единичек, которые будут как раз определяться тем, относится ли определённый бит к Network ID у оригинального IP-шника или нет. Она будет состоять: 1, 1, 1, 1, 1, 1, 1, 1. 8 единиц тут, 1, 1, 1, 1, 1, 1, 1, 1. 8 единиц здесь, 1, 1, 1, 1, 1, 1, 1, 1.

Ещё 8 единиц здесь, потому что все эти биты принадлежат к Network ID. И плюс ещё здесь у нас тоже 4 битка единицы. А все остальные биты относятся к Host ID, поэтому они будут выставлены в ноль. Эта маска состоит из ноликов и единиц, и нолики и единицы записываются в маску именно так, что если бит IP-шника относится к Network ID, то маска в указанном бите будет единицей. Если у этого бита в IP-шнике это будет Host ID, то он выставляется в ноль. Таким образом, получается, что маска состоит из некоторого количества единиц, а потом все остальные биты будут нулевые, потому что у нас граница между левой и правой частью у оригинального IP-шника проходит где-то в конкретном месте. Всё, что слева, — это будут единицы, всё, что справа, — это будут нолики. И это 32-битное значение записывается в той же форме, что и IP-шник. В нашем случае это будет маска 255.255.255, и вот это число 240.

Такая штука. Это оригинальный RFC 950, который вот такое предлагал. Если вдруг вы готовы к тому, чтобы услышать немножко наркомании, я вам могу про эту наркоманию немножко рассказать. Но если вдруг вы не знали то, что я вам сейчас рассказывал, и вы чувствовали, что для вас это что-то новое, то скажите мне, я тогда наркоманию рассказывать не буду. Вроде никто не жалуется, поэтому расскажу про наркоманию. RFC 950 на самом деле рассказывал, что могут быть маски разрывные. И этот механизм, что конкретный битик будет выставляться в единичку или в нолик, в зависимости от того, является ли некий бит IP-шника Network ID или Host ID, он предполагал, что в принципе может быть такая ситуация, что у вас биты Network ID и Host ID могут идти в разрыве. Они в любом случае руководствуются тем же самым правилом, что Network ID — это всё, что зафиксировано,

а Host ID — это пробегает всевозможные значения. Но предполагалось, что кому-то может захотеться сделать сетки, у которых Network ID — например, первый и третий октет, а второй и четвёртый октет пробегают всевозможные значения. И в этом случае вы могли сделать маску типа 255.0.255.0. И дальше с этим можно было как-то жить. Это реальная была наркомания. На тот момент, когда в 1984 году это всё предлагалось, кому-то показалась здравой идеей это сделать. И RFC 950 — это до сих пор действующий RFC. Гипотетически это должно поддерживаться и сегодня. Но уже в 1985 году стало понятно, что эта наркомания никому не пригодилась. И по факту все следующие RFC, которые сегодня поддерживаются, они уже не предполагают такую наркоманию. Они не предполагают, что у вас маска может содержать единички-нолики вперемешку. Актуальное состояние по состоянию на 2019 год:

у вас биты сначала в маске идут все единицы, а потом, начиная с определённого момента, как раз того самого момента, где в оригинальном IP-шнике закончился Network ID и начинается Host ID, у вас дальше все биты маски идут нулевые. Далее. В начале 90-х появляется RFC 1860, который говорит, что маску в таком формате записывать как-то неудобно. Когда мы записываем IP-шник и рядом с ним записываем ещё 255.255 и что-то там. Просто потому, что в нормальной человеческой маске столько бит энтропии нет, чтобы тратить на неё столько, условно говоря, чернил ручки, если мы пишем эту маску ручкой на бумаге, или ресурсов клавиатуры. На самом деле масок не может быть слишком много. IP-адресов их 4 миллиарда, а масок не 4 миллиарда, их сильно меньше,

потому что масок может быть на самом деле всего 33 штуки. То место, где проходят границы между левой и правой частью, оно может быть либо между первым и вторым октетом, между вторым и третьим октетом, между третьим и четвёртым октетом, и ещё оно может смещаться вправо. По факту у нас есть 32-битный IP-адрес, у него граница между левой и правой частью может идти вот здесь, вот здесь, вот здесь, вот здесь, вот здесь. Она всё равно будет идти между битами. У нас битов самих 32 штуки, плюс ещё два пограничных значения — не между битами, а по краям маски целиком. Вот здесь гипотетически может проходить граница Network ID, вот здесь. Получается у нас 32 бита — это 33 возможных положения той самой границы между Network ID и Host ID. Поэтому нет смысла на такое маленькое количество энтропии указывать так много информации, вот это 255.255.255.255. Намного проще просто сказать: маска состоит из какого-то количества единиц, а потом все остальные будут нули.

Она всё равно имеет ровно такой вид. И RFC 1860 как раз и говорит: не надо писать много-много 255.255 и так далее. Напишите просто слэш и дальше сколько в маске единиц. Сколько бит оригинального IP-шника относится к Network ID. У нас есть адрес класса A, который изначально был куплен, сеть класса A, кто-то, допустим, представим себе, подумал, что он будет запускать спутники, вот он купил себе сеть класса A, у этой сети все первые 8 бит зафиксированы, а оставшиеся пробегают все возможные значения. Тогда это будет сеть с маской слэш 8 после того, как будет использована бесклассовая адресация. Если у нас есть наша привычная 255.255.255.0 маска, то это будет маска, у которой зафиксированы первые 24 бита в единицу, оставшиеся в нуле, это будет слэш 24. Это абсолютно одна и та же сущность,

просто записанная в двух разных форматах. Старый формат — это так называемая десятичная маска, вот эта 255.255.255.0, которая состоит из 24 единиц и дальше 8 нулей. И, в кавычках, новая запись — это так называемая префиксная запись, когда мы пишем слэш 24. Это одно и то же по смыслу явление. Вот пример. У нас есть IP-шник 10.0.0.1, и мы хотим сказать, что этот адрес у нас получился бесклассовый, и получился он в результате того, что мы взяли сеть, в которой он находился, классовую, и заимствовали под адрес подсети некоторое количество бит. Мы переместили границу между левой и правой частью немножко вправо. Оригинальный адрес у нас имел вид 00001010 00000000 01000000 01. Первый битик у него был нулевой, следовательно, это адрес класса A. Следовательно, у него граница между левой и правой частью в классовом мире проходила ровно в одном месте —

между первым и вторым октетами. Если мы в бесклассовом мире говорим, что хотим указать, что мы делим большую сеть, классовую десятку, на много мелких подсетей, мы хотим сместить границу вправо, и мы заимствуем некоторое количество бит под адрес подсети. У нас есть некоторое количество бит родительской сети, 8 бит, и мы смещаем границу вправо на 20 бит. У нас получается 8 бит зафиксированных. Дальше мы смещаем границу вправо на 20 бит. Здесь 20, здесь 8. И у нас получается 2 в 20 степени сетей из одной большой восьмёрки, в каждой из которых у нас 2 в 4 степени, на самом деле минус 2, адреса будут присутствовать. Получается: 4 бита под Host ID, 20 бит под Subnet ID, 8 бит от Network ID родительской сетки. По внешнему виду оригинального класса IP-шника было понятно, где проходят границы между левой и правой частью.

Но если теперь мы хотим сказать, что у нас есть IP-шник 10.0.0.1, но мы говорим, что этот IP-шник бесклассовый, нам нужно указать, где у этого IP-шника проходят границы между левой и правой частью. И мы можем сказать в этой новой парадигме, где проходит граница, одним из двух способов. Либо мы пишем IP-шник и дальше указываем, что у этого IP-шника левые 28 бит относятся к новому Network ID, Network ID плюс Subnet ID точнее. Или мы можем сказать, что у этого IP-шника первые 28 бит относятся к Network ID, а всё остальное — под Host ID. IP-шник плюс маска в одном или в другом формате. Маска без указания IP-шника сама по себе смысла никакого не имеет. Она нужна для того, чтобы указать, где в конкретном IP-шнике проходят границы между левой и правой частью. Это не самостоятельная сущность, а дополнительный костыль к IP-адресу, без самого IP-адреса смысла не имеющий. Ещё раз подчеркну, что конкретно в этом случае у нас две формы записи маски абсолютно равнозначны.

Что в одном, что в другом случае по факту они обозначают ровно одно явление. Что у нас есть адрес 10.0.0.1, у которого рядышком с ним в одной канальной среде находятся все IP-шники, у которых левые 28 бит вот такие. А все остальные биты, эти 4 бита, пробегают все возможные значения. И у нас получается, что 2 в четвёртой степени — 16 минус 2 — это 14 адресов может быть в такой сети. И все эти 14 адресов могут быть использованы только в том же самом канале, в котором сидит узел 10.0.0.1. Как уже было сказано, маска может быть не любой. Маска может состоять из начального некоторого количества единиц, а потом это должны быть все остальные нули. Не может быть такого, что у нас в маске единички-нолики будут путаться и чередоваться. Как следствие, сначала идёт некоторое количество единиц, потом идёт некоторое количество нулей, и получается, что граница между единичками и нулями в маске может проходить в очень ограниченном количестве мест.

Если мы работаем с десятичной маской, 255 и чего-то там, то эта маска будет иметь довольно предсказуемый вид. Во-первых, сначала будут идти некоторые октеты, которые содержат целиком все единицы. Это октет 255. Он может быть, либо его вообще может не быть, либо может быть один, либо может быть их два, либо может быть их три, либо может быть четыре. Если у нас четыре октета по восемь битов, То есть все биты будут относиться к network ID. Это такой специальный особый случай. Если записать их вот так: slash 0, slash 8, slash 16, slash 24, slash 32. Вот это пять возможных вариантов сетей, которые будут состоять только из октетов 255 сначала и 0 в конце. Соответственно, у сети slash 0 вообще ни одного октета нет 255. Все октеты 0. У сети slash 8 один октет 255, остальные 0.

Slash 16 — два 255, два 0. 24-я — три 255, один 0. И 32-я — это все четыре октета 255. Вот эти пять особых случаев, они довольно простые. Их можно запомнить, а можно даже не запоминать, а просто понять логику и при необходимости посчитать. Здесь ничего особенного нет. Что касается сценария, когда у нас граница между левой и правой частью проходит не по октету, а внутри какого-то октета. Не между первым и вторым, не между вторым и третьим октетами, а часть какого-то октета относится к левой части адреса, а часть какого-то октета относится к правой части адреса. В этом случае у нас всё равно сначала будут идти какие-то 255 октеты, возможно, будет один или два, или вообще ни одного не будет. Все остальные октеты, соответственно, кроме одного вот этого проблемного, будут нулевые. Они состоят целиком из нулей. И один октет будет какой-то кривой. У него будут сначала единички, а потом нолики.

И для того, чтобы быстро преобразовывать десятичный формат записи в префиксный и наоборот, я вам рекомендую воспользоваться вот такой шпаргалкой, которая нарисована на слайде. Эту шпаргалку вы можете воспроизвести на экзамене. Ещё раз подчеркну, вы не можете приносить шпаргалки с собой на экзамен, но никто вам не мешает на экзамене нарисовать эту шпаргалку. И рисуется она элементарно, и вам не нужно будет запоминать какие-то все возможные значения префиксных масок, все возможные значения десятичных масок. Задач на экзамене на это будет довольно много. Я думаю, что их будет там штук пять, наверное. И если вы будете прямо по-честному вычислять, какая маска чему соответствует, вы потратите много времени. А эту шпаргалку вы можете реально нарисовать за пару минут, и тем самым фактически все задачи, которые будут содержать в себе игры с маской, она будет решать просто на ура за единицы секунд. Поэтому рекомендую понять, про что здесь говорится, и рекомендую воспроизвести её на экзамене.

Так вот, эта шпаргалка, которая здесь нарисована, она позволяет понять, как будет устроена маска, если у нас граница между левой и правой частью проходит по какому-то октету. Она будет как раз указывать, что будет происходить с этим проблемным октетом, как он себя будет вести. Если у нас есть какой-то, в кавычках, проблемный октет, у которого первый битик единичка, а все остальные биты нулевые, это значит, что маска сначала содержит некоторое количество 255-х октетов, потом октет, состоящий из единицы и семи нулей, то есть это в десятичном виде будет число 128, а потом все остальные октеты будут нулевые, сколько бы их там ни было. Если этот кривой октет, 128, будет стоять в первой позиции, то есть это будет сетка 128.0.0.0, то это будет сеть слэш-1. Если этот октет будет стоять во второй позиции, то есть первый октет будет 255, второй — 128, третий — нулевой, четвёртый — нулевой, то это будет слэш-9 сетка. Аналогично в третьей позиции он будет слэш-17,

в четвёртой слэш-25. Вы можете, соответственно, таким образом сказать, что если вам нарисовали какую-то сетку, например, 255.255.128.0, вы просто смотрите: вижу знакомый октет 128, нахожу его вот здесь. Смотрю, что он находится в третьей позиции, первый октет, второй октет, третий октет, четвёртый октет. Значит, я вижу, октет 128 находится в третьей позиции, соответственно, это сетка слэш-17. Пересечение третьего столбца и кривого октета 128. Аналогично, если у вас будет 1, 1 и дальше 6 нулей, это будет десятичное число 192, и это будет соответствовать сетям слэш-2, слэш-10, слэш-18, слэш-26. Как вы понимаете, 3 единицы, 4 единицы, 5 единиц, 6 единиц и 7 единиц, они абсолютно точно так же будут устроены. 224, 240, 248, 252, 254. Нулевой и 255 октеты,

они будут состоять целиком из нулей или единиц, и, соответственно, они будут соответствовать вот этим сетям, по сути. Поэтому да, слэш-1, слэш-2, слэш-3, слэш-4, слэш-5, слэш-6, слэш-7. Пишем их вот так в столбик. Дальше 8 не пишем. 9, 10, 11, 12, 13, 14, 15, 16 опять кратно 8 — не пишем, 17, 18 и так далее. До 23. С 25 по 31. Вот так в четыре колонки выписываем семь чисел в каждую колонку. И нужное количество единиц. Одна единица — семь нулей, две единицы — шесть нулей, три единицы — пять нулей, четыре единицы — четыре нуля. Вот эти числа вам надо преобразовать из двоичной системы в десятичную. Вы научитесь это делать очень быстро, буквально сегодня. И, соответственно, на экзамене вы должны будете воспроизвести подобную структуру. Она реально легко воспроизводится. Ещё раз подчеркну, как она рисуется.

Вы рисуете сначала вот эту лесенку. Одна единица, две единицы, три единицы, четыре единицы, пять единиц, шесть единиц, семь единиц. Дальше всё здесь заполняете единицами, всё тут заполняете, соответственно, нулями. Дальше преобразовываете все эти числа из двоичной в десятичную. Вы научитесь это делать очень быстро, и здесь фактически несложная операция сложения получается. 128, 192, 224, 240, 248, 252, 254. Преобразовать из двоичной системы счисления в десятичную просто. Эти числа хорошо знакомы, во-первых, во-вторых, они вам ещё много раз понадобятся, так что вы это сделаете легко. И дальше рисуете. Один, два, три, четыре, пять, шесть, семь. Девять, десять, одиннадцать, двенадцать, тринадцать, четырнадцать, пятнадцать. Семнадцать, восемнадцать и так далее. После чего, если вам дают в качестве задания преобразовать маску из одного формата в другой, у вас никаких сложностей с этим уже возникать не будет. Дают маску, допустим, слэш-21 и просят написать её десятичное значение,

никаких проблем. Это, соответственно, кривой октет в третьем столбце, значит, 255.255.248.0. Дают вам одиннадцатую маску — не проблема. Второй столбец, значит, 255.224.0.0. И в прямую сторону, и в обратную вы можете уже с масками работать без особых проблем. Почему я вам рекомендую сделать это на экзамене? Именно потому, что это экономит время, очень сильно экономит время. Так, что касается процедуры разделения на подсети и агрегации, обратная процедура, я, в принципе, уже про это всё рассказал. У нас есть какая-то сеть. В изначальном оригинальном сабнетинге по RFC 950 предполагалось, что сеть будет классовая. Но здесь классовую сеть я нарисовать не смог, она бы не поместилась на экране, поэтому я в качестве примера взял сетку, которая уже была разрезана на части. У нас была классовая сеть 192.168.1.0.

Это была классовая сеть класса C, поэтому у неё левые 24 бита были зафиксированы, правые пробегали все возможные значения. Вот это вот 0 — это был хост ID. Мы её взяли и разрезали на части, и получили некоторое количество 29-х сеток. Просто для того, чтобы сэкономить место на слайде, я взял один из этих кусочков, 192.168.1.0/29, и предложил его разрезать пополам. Что такое взять и разрезать пополам сеть? Мы под словом «сеть» понимаем набор всех IP-адресов, у которых левые некоторые биты одинаковые, а правые пробегают всевозможные значения. Что такое сеть 192.168.1.0 по 29-й маске? Это такая сеть, у которой IP-адреса содержат левые 29 битов, именно такие же, как у 192.168.1.0, а правые, соответственно, пробегают все возможные значения. 192.168.1.0, вот он выписан в качестве эталона, вот набор единичек и ноликов.

Вот это число, это то число, которое мы привыкли называть адресом 192.168.1.0. Компьютер работает именно с числами. И вот это число в 32-битной записи как раз соответствует записи 192.168.1.0. Левые 29 бит мы фиксируем, мы говорим: всё, вот это Network ID. И у всех адресов, которые будут находиться в этой сети, левые 29 бит будут точно такие же. И мы их выписываем. Мы выписываем все адреса, у которых левые 29 бит такие же, а правые пробегают всевозможные значения. 000 — это, понятно, адрес самой сети. Дальше прибавляем единичку — 001. Прибавляем ещё единичку — 010, 011, 100, 101, 110, 111. В трёх битах хост-айди мы записали все возможные значения. Их два в третьей степени, восемь штук. И вот они пробежали все возможные значения от трёх нулей до трёх единиц. Дальше мы говорим: окей, вот у нас есть такая пачка адресов, у которой левые 29 бит зафиксированы,

а правые пробегают все возможные значения. Мы можем эту пачку из восьми адресов разделить на две подпачки. Соответственно, в каждой подпачке у нас будет меньшее количество адресов, в частности, если мы пополам делим — четыре. И левую пачку мы отбираем таким образом, чтобы у неё все первые 30 бит были одинаковые. 29 первых бит у неё и так одинаковые, просто по определению. Исходное условие было, что они одинаковые. А, соответственно, 30-й бит может представлять собой либо нолик, либо единичку. Вот мы отбираем в левую пачку те адреса, у которых первый битик хост-айди нулевой. А в правую пачку все адреса, у которых 30-й бит будет, соответственно, единичка. Естественно, таких адресов будет одинаковое количество. И получается, что у нас есть две подпачки одинакового размера, у которых левые 30 бит будут одинаковые. Вот они. А правые оставшиеся два бита пробегают все возможные значения.

Это просто по условию так. Мы отобрали все адреса, у которых левый бит хост-айди зафиксирован, но все остальные биты действительно пробегают вообще все возможные значения. Не может быть такого, что какие-то ещё адреса останутся нераспределённые по нашим пачкам, потому что, ещё раз подчеркну, по условию мы их так отбирали. И в этом случае мы можем сказать, что у нас из родительской сети 192.168.1.0 по 29-й маске получилось две сети. Первая сеть, у неё IP-адрес тот же самый, 192.168.1.0, он никуда не делся, самый маленький IP-адрес сохранился, но уже по 30-й маске. И вторая сеть, у неё уже IP-адрес будет другой. Левые 30 бит у неё будут другие. Они будут на единичку больше. И, соответственно, если взять и преобразовать полученный адрес в десятичный вид, то он будет записываться как 192.168.1.4, но тоже по 30-й маске. То есть это указание, что левые 30 бит относятся к Network ID.

А правые у этой сети пробегают все возможные значения. Мы взяли большую сеть, порезали её пополам. В каждой половинке адресов ровно в два раза меньше, чем было в оригинальной сети, но самих сетей у нас получилось в два раза больше, чем оригинальная сеть. То есть две. Вот эта процедура называется сабнетинг. Точно так же можно делить на 4 части, на 8 частей, на 16 частей. Просто вы откусываете от хост-айди не один битик, а 2, 3, 4. Можно, естественно, порезать только на количество сетей, кратное двойке. Если вам вдруг нужно сеть разделить, допустим, на 3 части, то с помощью этого алгоритма сделать это ровно-ровно не получится. Вы должны будете разделить на количество частей, которое кратно двойке. Если вам нужно какое-то меньшее количество частей, вы говорите: окей, значит, мы делим на количество сетей, кратное двойке, какие-то из получившихся подсетей задействуем, а все остальные складываем в долгий ящик, вдруг потом когда-нибудь пригодятся. Если вам нужно на 3 части разрезать большую сеть, вы режете её на 4 части, 3 кусочка задействуете,

4-й кусочек просто откладываете в сторону. и храните про запас. Есть ещё обратная операция, которая называется агрегация. Это то, что провайдерам было интересно. Когда вы берёте несколько сетей, у которых у всех старшие биты Network ID совпадают, а оставшиеся биты Network ID пробегают все возможные значения, именно все возможные значения. Фактически это можно будет заметить как то, что вы взяли какую-то сетку и порезали её на части. У вас всегда получаются кусочки, которые просто по определению — у них старшие биты какие-то совпадают, а все остальные будут пробегать все возможные значения. Если вы взяли несколько кусочков сетей, посмотрели на них внимательно и увидели, что они могли бы быть порезаны из какой-то одной большой сети, то вы можете эти кусочки склеить обратно в большую сеть. Этот процесс называется агрегация.

Не любые сети можно склеить, агрегировать в какую-то одну большую сеть. Только те кусочки сетей, которые изначально были порезаны из какой-то одной большей сети. Здесь пример, что четыре сети с маской /31 можно агрегировать в одну /29. Ещё раз подчеркну, не любые четыре сети склеиваются, а только те, которые могли быть изначально порезаны на части из большой сети. В нашем случае мы можем сказать, что у нас есть сеть 192.168.1.0/31. Все возможные значения. И мы внимательно смотрим на сами IP-шники и говорим: здесь у нас и здесь, соответственно, левые 31 бит одинаковые. Соответственно, 31 — это 29 и ещё 2. И здесь тоже 31 бит

одинаковые, но 29 одинаковые ещё и со всеми остальными кусочками, а эти кусочки, эта часть Network ID, она уже с другими кусочками будет отличаться. Здесь тоже у нас получается Network ID, левые 29 бит одинаковые со всеми остальными кусочками, а эти два битика Network ID в пределах своей пачки одинаковые, но с другими кусочками отличаются. Абсолютно аналогично: здесь тоже у нас свой отдельный кусочек, а эти все биты опять же одинаковые. И у нас возникает предположение, что, возможно, мы можем сказать, что эти биты у нас у всех IP-шников одинаковые, а эти биты пробегают вообще все возможные значения. И в этой ситуации мы можем сказать, что эти четыре сети по /31 маске фактически изначально были получены путём разрезания большой сети с /29 маской. 192.168.1.0 /29 на четыре кусочка. И если мы это замечаем,

мы можем сказать: давайте расценивать эти сети не как четыре маленьких сетки по /31 маске, а одну большую сетку по /29 маске. Эта операция полностью обратная по смыслу сабнеттингу. Сабнеттинг — мы берём сетку и делим на части, агрегация — мы берём несколько кусочков оригинальной сети и склеиваем их обратно в оригинальную сеть. Единственное, чем это описание плохо, это то, что не всегда у вас действительно есть какая-то сеть, которая резалась изначально на части. Может быть такое, что у вас, например, есть четыре классовые сети. 192.168.16.0, 192.168.17.0, 192.168.18.0 и аналогично 19.0. Эти сети на части ни из чего не резались, но у них опять же абсолютно аналогично левые 22 бита будут одинаковые,

а оставшиеся биты, они пробегают все возможные значения. Там их целых четыре варианта. Будет 0-0, 0-1, 1-0, 1-1. И естественно, что Host ID в каждой сети тоже пробегает все возможные значения. В этом случае мы можем сказать, что именно эти классовые сети складываются или агрегируются в одну большую сеть по /22 маске. 192.168.16.0/22. Подчеркну, что это мы взяли 4 классовые сети и склеили их в одну большую суперсеть. По сути мы могли бы сказать, что это аналогичная процедура, если бы мы взяли сеть 192.168.16.0 по /22 маске и разрезали бы на 4 части. Но ключевой момент заключается вот в чём. Процедура сабнеттинга изначально развилась из идеи, что мы берём классовую сеть и режем её на одинаковые кусочки. Изначально сабнеттинг не предполагал,

что вы можете эти кусочки резать потом повторно. Потом уже отдельно появилась идея, что такое делать можно, а изначально так делать было нельзя. Соответственно, если вы делаете процедуру, обратную сабнеттингу, классическому чистому сабнеттингу, то у вас не может получиться ничего крупнее, чем классовая сеть. А агрегация как раз заключается в том, что мы берём именно классовые сетки, которые есть в интернете, и складываем их во что-то более крупное, чем классовые. Или кусочки классовых сетей склеиваем в какую-то ещё другую суперсеть для того, чтобы избавиться от большого количества сетей в таблице маршрутизации. Что касается повторного разделения сети на кусочки. Если мы взяли классовую сеть и разделили её на подсети, то оригинальный RFC 950 предполагал только одно деление. Соответственно, у вас все кусочки получались одинаковые, и достаточно было только в одном месте угадать, какого размера эти кусочки

могли бы получаться, чтобы все остальные кусочки вы бы тоже понимали, какого размера они могут быть. Например, вы внутри своей сети говорили: у вас есть адрес 10.0.0.1/28. И это автоматом означало, что все адреса, которые будут начинаться на десятку, у них у всех будет маска /28, потому что эта классовая сеть-десятка была разрезана на /28 куски. Следовательно, если вы видите IP-шник 10.1.1.1, вы сразу могли сказать, что у этого IP-шника его обладатель имеет маску /28. Делалось это в расчёте на то, что вам когда-нибудь пригодилось бы понимание того, какая маска будет у получателя. В итоге не пригодилось. На самом деле знать, какая маска будет у получателя, не нужно. Но оригинальная идея была такая, что если мы понимали, что у нас маска вот такая и что мы в оригинале

были в такой классовой сети, то все узлы в этой классовой сети будут с такой же маской, как у нас. Потом от этой идеи отказались, и родился механизм, который называется VLSM. Variable Length Subnet Mask. Маска переменной длины. Смысл заключается в том, что вы, порезав один раз сетку на кусочки, можете использовать один какой-то кусочек или несколько кусочков для того, чтобы порезать их на более мелкие кусочки. У нас есть большая какая-то сеть, мы её режем пополам, потом одну половинку, например, ещё режем пополам, половинку ещё режем пополам. Дальше две мелкие половинки ещё режем пополам. Такие вещи можно будет делать. У вас в итоге получится, что сети внутри большой классовой сети могут быть произвольного размера. И если у вас есть IP-шник 10.0.0.1 по маске /28, то в другом месте этой сети 10.1.1.1 может быть вполне с маской /24. Это допустимо, это разрешено, и никаких проблем по факту не вызывало.

Но изначальная идея была, что все маски должны быть одинаковые. И поэтому, например, в тех же самых цисках вы можете увидеть в некоторых ситуациях до сих пор, что циска вам будет писать, что у нас есть сеть, и эта сеть либо вообще маску не указывает. Просто написано, что у нас есть сетка 192.168.1.0, и вообще маску не пишут. Тогда эта маска предполагается такая же, как классовая, то есть /24. Либо может быть написано, что у нас есть классовая сеть 192.168.1.0, и она написана subnetted, и показано, что subnetted на /25 кусочки. Напишет 192.168.1.0 is subnetted. И, допустим, где-то рядышком написано /25. И показано 192.168.1.0 и 192.168.1.128.

Показываются два IP-шника, но не нарисованы маски, потому что маски у всех кусочков будут одинаковые. Или будет написано 192.168.1.0 is variably subnetted. Маска у всех разная, и в этом случае размер маски пишется не в общей какой-то графе, а показано: здесь /25, здесь /26 и так далее. Напротив каждого IP-шника будет написана уже маска. Именно механизм VLSM сегодня используется абсолютно везде. Никто не заставляет вас использовать везде одинаковую маску, если вы взяли какую-то классовую сеть и порезали её на части. Никаких классовых сетей уже сегодня нет. VLSM — это про разрезание на куски большой классовой сети. И есть ещё механизм CIDR, который используется провайдерами. Это указание на то, что в интернете никаких классовых маршрутов тоже уже не осталось. Classless Inter-Domain Routing — это про то, что вы берёте любые сети и объединяете их по своему усмотрению в таблице маршрутизации до каких угодно сетей. Вы можете взять классовые сети и объединить их во что-то большее,

включая и бесклассовые сети, которые получатся. Вы можете сказать, что у нас есть сеть 8.0.0.0/8, 9.0.0.0/8, 10.0.0.0/8 и 11.0.0.0/8. И все они по /8 маскам. Мы взяли четыре классовые сетки и схлопнули их в одну большую суперсеть. 8.0.0.0, 9.0.0.0, 10.0.0.0, 11.0.0.0 — они все схлопываются в 8.0.0.0 по /6 маске. Этой /6 маски в классовом мире быть не могло в принципе, потому что в классовом мире в принципе не было масок. Но даже тогда, когда появился механизм разделения сети на подсети, просто обычный сабнеттинг, границу между левой и правой частью мы могли смещать только вправо.

И самая крупная сеть, которую мы могли резать на части, это была сеть класса A. CIDR отказался от практики, что мы берём обязательно классовую сеть и дальше делим её на части. Он сказал, что можно делать как смещение границы между левой и правой частью вправо, так и влево. Причём это делать можно абсолютно по своему усмотрению, ни на кого не оглядываясь, ни с кем не советуясь и в том числе не обращая внимания на классовость. VLSM — это про предприятие. Берём классовую сетку, например, и делим её на части. CIDR — это про провайдинг, что берём любые сети, включая, например, классовые, и объединяем их в какие-то большие куски сетей. RFC 950, который предлагал делить сети на подсети, причём на все сети одинакового размера, он рекомендовал, если вы делите сеть на подсети, не использовать две из получившихся подсетей, два из получившихся кусков. Первый кусок, который он не рекомендовал использовать, —

это самый первый, потому что IP-адрес этой самой первой сети совпадал бы с IP-адресом оригинальной сети. И были бы какие-нибудь узлы, которые могли бы гипотетически использовать в таблице маршрутизации адреса самих сетей как основной идентификатор без указания маски. И тогда такие узлы могли бы спутать классовую сеть, которую вы изначально нарезали на части, и самый первый её кусок, который получился при разрезании сети на подсети. Поэтому, чтобы не совпадали IP-адреса самих сетей в таблице маршрутизации и из-за этого не вышел бы конфуз, RFC 950 говорил, что не стоит брать первый кусочек. Равным образом он не рекомендовал брать самую последнюю по счёту сеть из-за того, что там было пересечение по широковещательным адресам, и гипотетически можно было бы устроить петлю маршрутизации, если бы вы отправили пакет на такой directed broadcast. Он бы в таблицах разных роутеров

мог маршрутизироваться по разным строчкам, и мог гипотетически зависнуть в петле маршрутизации на роутерах, если бы некоторые из этих роутеров не поддерживали бы полноценно механизм разделения сети на подсети. Уже RFC 1878, Тот самый, который определил префиксную запись, эту рекомендацию указал как устаревшую на тот момент. Уже в начале 90-х это стало неактуально, потому что все роутеры на тот момент по факту поддерживали бесклассовую маршрутизацию. Поэтому если вы точно знаете, что все ваши роутеры выпущены после 92-го года, эту рекомендацию вы можете смело игнорировать. Почему я вам про это рассказываю, какую-то некрофилию поднял из глубин древности? Дело в том, что на старых роутерах цисковских, с IOS, например, 12-м, у них в конфигурации есть строчка IP subnet 0 или no IP subnet 0. Это как раз про это.

Можно ли брать первую по счёту сетку или последнюю по счёту сетку, или нельзя. Точнее, Cisco разрешает последнюю брать без проблем, но первую она не позволяет иногда использовать. Если вы пытаетесь повесить на интерфейс IP-шник, и у этого IP-шника вычисляется IP-адрес сети, и он совпадает с IP-шником классовой сети, в этой ситуации Cisco просто будет ругаться, говорит: ты попросил меня не давать тебе использовать первый кусочек из тех подсетей, которые получаются. Я тебе сообщаю, что я тебе не дам это сделать, потому что ты меня просил тебя предупреждать. Если вы режете сеть на кусочки, вы можете гипотетически порезать сеть на кусочки любого размера. Но есть нюанс. Мы договорились, что в абсолютно любой сети у нас два адреса используются как служебные. Адрес самой сети, и его нельзя назначать хостам, и адрес широковещательный. Его тоже нельзя назначать хостам, потому что он фактически принадлежит вообще всем.

Но есть такие сети, где эти два служебных адреса не очень сильно нужны. Например, в ситуации, когда у вас есть, допустим, представим себе, что у нас есть сетка /24. В этой сети у нас два в восьмой степени минус два адреса хостов. Это 254 хоста можно будет адресовать. Плюс два адреса служебных. Два адреса — это у нас сам адрес сети и бродкаст. Если мы возьмём и разрежем её пополам, у нас получается два в седьмой степени адресов в каждой сети. Это у нас 126 хостов плюс два служебных адреса. Аналогично режем на части. /26, /27 у нас будет получаться. Два в шестой степени — это 62 плюс два адреса. И два в пятой степени — это 30 плюс два. /25, /26, /27, /28, /29 —

это два в четвёртой степени. Возможных адресов хоста — это 14 плюс два служебных. И два в третьей степени — 6 плюс два служебных. И /30 маска — это два во второй степени адресов, потому что 30 бит под Network ID оставляют нам два бита под Host ID. И в два бита Host ID мы можем вписать четыре разных значения. Получается, два адреса мы можем назначить на хосты и два адреса плюс у нас служебных. В итоге получается какая-то странная ситуация. У нас есть канал, в котором мы можем назначить два адреса — левый и правый. Если вдруг какой-то трафик будет посылаться на соседа в этом канале, то это фактически канал Point-to-Point. Получается, что мы, если захотим что-либо отправить в этот интерфейс, мы в любом случае можем указать адрес того единственного соседа, который в этом канале находится. Нам нет необходимости использовать Broadcast в этом канале.

В любом случае любой трафик, который уйдёт, дойдёт только до одного получателя. Поэтому, если у вас есть среда, в которой ровно два участника, по стандарту IP предполагается, что вы должны использовать /30 маски, и там половина всех адресов у вас будет отходить под служебные нужды. Вы фактически резервируете за этим каналом четыре адреса, но два из них использовать можете, а два из них использовать не можете. Для того чтобы более эффективно расходовать IP-адреса, появился RFC 3021, который сказал: именно в ситуации, когда у вас Point-to-Point link, вы можете использовать /31 маски. В такой сети у вас будет всего два адреса, и оба эти адреса можно назначить хостам. Адрес самой сети и адрес широковещательный не выделяются как специальные отдельные сущности, потому что они в Point-to-Point канале не нужны. Эта штука позволяет более эффективно расходовать IP-адреса, но она не поддерживается абсолютно всеми устройствами.

Cisco, например, её поддерживает. Некоторые другие операционные системы, некоторые другие сетевые устройства её могут не поддерживать. Классический такой пример, что не поддерживает эти самые /31 маски, — это MikroTik. Также, как в случае с классовой маршрутизацией, мы уже разбирали сценарий вида: есть компьютер, у него есть два интерфейса, на этих интерфейсах есть IP-шники, и возникает вопрос, куда, в какой интерфейс отправлять некий пакет. Представим себе, что у нас есть компьютер, у него есть пакет, у этого пакета есть известный адрес получателя 10.0.2.2. И возникает вопрос, куда будем отправлять этот пакет, и, кстати, с каким IP-шником источника по умолчанию этот пакет будет отправляться, если не сказано иное. Если у нас есть какое-то приложение, например, мы запускаем ping, и мы говорим:

мы хотим попингать вот этого товарища, и мы хотим попингать его с указанием адреса источника, например, 10.0.1.1. В этом случае тот адрес, который мы заказали, он и будет использоваться в качестве адреса источника. При этом с какого интерфейса будет отправлен такой пакет, вообще роли никакой не играет. Либо приложение заказало IP-шник, либо не заказало. Вот оно заказало адрес получателя, и возникает вопрос, куда конкретно отправлять пакет с таким адресом получателя. Ещё раз подчеркну, адрес источника здесь вообще никакой роли не играет. Мы его можем указывать или можем не указывать. Логика будет примерно та же самая, что в случае с классовой маршрутизацией. Мы смотрим на свой IP-шник на одном интерфейсе. 10.0.1.1. И маска у него /24. Следовательно, мы берём первые 24 бита от IP-шника 10.0.1.1. Здесь легко. 10.0.1. Более строго — мы находим адрес сети, к которой принадлежит наш интерфейс, наш IP-шник 10.0.1.1.

По /24 маске это будет адрес 10.0.1.0/24. Дальше мы смотрим. Если мы возьмём такую же маску и приложим её к IP-шнику получателя, получится ли у нас такой же адрес сети или не получится? 10.0.2.2. Мы берём эти 24 бита, прикладываем сюда и смотрим, что у нас получается. Получается 10.0.2.0/24. Это адрес сети. И если мы взяли свою /24 маску и приложили её к IP-шнику получателя, результат не совпал. 10.0.1.0 у нас, 10.0.2.0 у него. Ещё раз подчеркну, мы не знаем, какая у него по факту маска. Мы свою маску к нему приложили и смотрим, совпало или не совпало. Поэтому мы не можем отправить этот пакет в первый интерфейс так, чтобы он напрямую дошёл до получателя. Но может быть у нас есть другой интерфейс, 10.0.2.1, там наш собственный IP-шник с /24 маской. Берём /24 маску,

уже эту, прикладываем к своему IP-шнику 10.0.2.1, получается 10.0.2, первые 24 бита, или если IP-шник записывать целиком — адрес сети 10.0.2.0/24. Дальше. Берём эту же /24 маску, не ту, которая по факту у этого узла есть на самом деле — /24 или какая-то другая. Мы берём именно ту маску, которая висит на нашем интерфейсе. Она может быть гипотетически не /24, а /25, к примеру. Значит, будем /25 брать. Берём эту маску и прикладываем её к IP-шнику получателя, /24. И получаем адрес сети 10.0.2.0/24. Результат совпал. Раз и два. У нас одинаковый получился, поэтому мы можем сказать, что на интерфейсе 2 у нас находится IP-шник, у которого левые биты Network ID такие же, как у адреса получателя. Следовательно, они с получателем находятся в одной IP-сети, в одном канале, и трафик можно направить напрямую на получателя, и он дойдёт до него.

Если мы с получателем не находимся в одном канале, мы перебрали все свои интерфейсы, обнаружили, что совпадения нигде нету, то мы должны будем послать такой пакет на какой-то транзитный роутер, который дальше переложит этот пакет в сторону получателя. По той же аналогии: он получит пакет от нас, примет его, увидит, что внутри что-то, что ему не предназначено, и дальше этот пакет будет пытаться отправить в сторону сети получателя, так же, как это делали мы. Здесь логика будет следующая. Мы опять же должны будем знать про все сети в мире, кто где сидит. Во все сети, в которых у нас нет прямого интерфейса, нужно будет маршруты запомнить. И у нас будет табличка, в которой мы будем это делать. У нас есть сетка 10.0.3.0 с /24 маской, 10.0.4.224 с /28 маской, про которые мы откуда-то знаем. Вот они. Раз, два. И мы знаем, что 10.0.3.0 с /24 маской находится здесь, 10.0.4.0, 4.224 по 28 маске

находится за интерфейсом номер 2. И дальше мы говорим, окей, у нас есть айпишник получателя 10.0.3.224. Куда мы такой пакет будем девать? В какой интерфейс надо его послать? То ли в сторону первого интерфейса, то ли в сторону второго интерфейса, и заодно канальный адрес роутера, если вдруг эти интерфейсы будут иметь возможность отправлять трафик больше, чем одному соседу. Соответственно, делаем примерно то же самое, что мы только что делали, только мы уже перебираем не те сетки, которые у нас на интерфейсах висят, а те сетки, которые у нас есть в таблице. Берём эту сеть 10.0.3.0 по 24 маске. Берём эту маску, прикладываем к этому айпишнику и смотрим, в какой сети находится этот айпишник. 10.0.3.0. Слэш 24. У нас есть совпадение. В классовом мире мы бы на этом остановились, сказали, первое совпадение есть. В классовом мире два разных совпадения быть в принципе не может, потому что каждая классовая сеть

в принципе не пересекается с другими классовыми сетями. Но в бесклассовом мире у нас может быть пересечение, поэтому мы этот маршрут помечаем как возможно подходящий и проверяем все остальные маршруты тоже. В бесклассовом мире мы должны проверить все маршруты в таблице маршрутизации, а потом среди них выбрать наиболее подходящий. Поэтому первый маршрут мы нашли, он хороший, он подходит. Проверяем второй. 10.0.4.224.0 по 28 маске. Соответственно, здесь результаты мы стираем. Берём 28 маску, которая у нас есть в таблице маршрутизации, вот эту, прикладываем её к айпишнику 28 и проверяем, что у нас получилось. Это будет 10.0.3, пардон, да, 3. И дальше 224. Здесь надо в двоичное представление всё дело переводить. 224 десятичное. Это у нас 128 плюс 64, 192 плюс 32,

как раз 224. 0, 0, 0, 0, 0. Двоичное. Это вот такое число. Соответственно, если у нас маска 28, то левые 4 бита из этого относятся к Network ID, а правые 4 бита относятся к Host ID. И получается, что 10.0.3 и ещё 1.1.1.0 двоичное, это адрес самой, точнее, это Network ID. И если мы возьмём и зафиксируем, так, пардон, здесь четвёрка, точнее, здесь тройка. 1.1.1.0 — это Network ID. Если мы всё остальное обнулим, то у нас то же самое получится. Это 224. То есть адрес 10.0.3.224 по 28 маске — это уже адрес самой сети. И есть ли у нас совпадение 10.0.3.224 здесь, 10.0.4.224

в таблице маршрутизации? У нас совпадения нету, поэтому мы говорим, такой маршрут не может быть использован для доставки трафика до IP-шника 10.0.3.224. И получается, что из одного варианта, как можно доставить трафик до удалённой сети, нам надо выбрать один наилучший. Сделать это не очень сложно, он один всего и есть. Поэтому мы говорим, трафик должен пойти на интерфейс номер один. И здесь видно на рисунке, что оно действительно похоже на правду, что 10.0.3.0 по 24 маске действительно там и находится. Мы посылаем это на первый интерфейс. И заодно здесь, если приложение не специфицировало, какой IP-шник источника оно хочет использовать на этом компьютере, то берётся IP-шник, который является основным IP-адресом на интерфейсе, с которого отправляется пакет. В классовом мире тоже самое было. В нашем случае, если мы не указываем явно, с каким адресом источника пингаем соседа, то выбирается этот IP-шник. Если бы вдруг пакет ушёл

через этот интерфейс, и, опять же, приложение не специфицировало, с каким IP-шником пингать, то выбрался бы этот IP-шник в качестве адреса источника. В классовом мире вы могли пометить звёздочкой одну классовую сеть, сделав её так называемой сетью по умолчанию. Всё, что не попало явно под явно указанные маршруты, всё отправлялось по тому же маршруту, как и эта отмеченная звёздочкой сеть. В бесклассовой маршрутизации вы не можете отметить сеть как сеть по умолчанию, но зато вы можете сделать маршрут на суперсеть 0.0.0.0, к которой принадлежат вообще все IP-шники. Это сеть, у которой 0 битов относится к Network ID, а соответственно все биты Host ID пробегают вообще все возможные значения, и получается, что абсолютно любой IP-шник в такую сеть входит. Поэтому, если вдруг у вас есть желание обработать какие-то маршруты

неявным образом, то можно использовать такой маршрут на суперсеть 0.0.0.0. В итоге получается, что у нас может быть такая ситуация, что есть некоторый набор маршрутов в таблице маршрутизации, которые потенциально могут быть использованы для доставки трафика в удалённую сеть. Среди них может быть как раз этот самый маршрут до сети 0.0.0.0, у которого первые 0 бит совпадают с IP-шником назначения, а оставшиеся биты не совпадают, но этого никто и не требует. И может быть такое, что у нас есть несколько явно указанных сетей, которые одновременно можно использовать для доставки трафика. Мы говорим, такой маршрут можно использовать, такой маршрут можно использовать. Может быть нормальная ситуация, когда у нас есть несколько маршрутов в таблице маршрутизации, и они все подходят. Вот пример. У нас есть 112, 168, 145 — айпишник получателя. И несколько маршрутов в таблице маршрутизации. 112, 168, 100, 0 по 24-й маске — подходит. Вот у нас 112, 168, 100, 0.

112, 168, 0, 0 по 16-й маске — тоже подходит. И 0, 0, 0, 0, 0 первых бит — тоже подходят. Действительно, этот айпишник подходит под 3 маршрута. И возникает вопрос, если эти маршруты гипотетически указывают в разном направлении, то есть эта сетка доступна слева, эта сетка доступна справа, эта сеть доступна сбоку, какой конкретно маршрут выбрать? Они все смотрят в разные направления. Одна сеть сюда показывает, другая туда, третья сюда. В какую сторону направлять пакет? И в IP-мире маршрутизаторы руководствуются правилом наибольшей специфичности, или так называемый most-specific route. Если мы нашли несколько маршрутов, и они все подходят, мы выбираем такой маршрут, у которого Network ID получился самый большой. Наибольшее количество бит гарантированно требуется для совпадения. Соответственно, в случае 192.168.100.0 по 24-й маске Network ID занимает 24 бита.

192.168.0.0 по 16-й маске — Network ID занимает 16 бит. И 0.0.0.0 по 0-й маске — Network ID занимает 0 бит. Здесь 24, здесь 16, здесь 0. Выбираем тот, у которого совпадение самое большое. Совпадение самое большое — значит, сеть самая маленькая. Мы можем сказать, что из всего числового пространства, все IP-адреса, которые есть, начиная с 0.0.0.0 по 255.255.255.255. Что такое сеть по 0-й маске? Это вообще вся числовая ось. Отсюда и досюда. Понятно, что это наименее специфичный маршрут из всех, который можно представить. Он включает в себя вообще всё, поэтому, естественно, его приоритет должен быть минимальный. Поэтому, если у вас есть хотя бы какой-то другой маршрут, который имеет Network ID хотя бы какого-то размера, отличного от нуля, то, естественно, маршрут по умолчанию, 0.0.0.0, ему проиграет.

Что такое сеть по 16-й маске? Это какой-то диапазон адресов, начиная со 192.168.0.0 по 192.168.255.255. Это какой-то числовой отрезочек, который является, естественно, частью большого отрезка 0.0.0.0. И что такое 192.168.100.0 по 24-й маске? Это часть этого отрезка 192.168.0.0 по 16-й маске. Он вот такой. Начиная со 192.168.100.0 по 192.168.100.255. Это часть большего отрезка. Получается, больший отрезок закрывает большее количество адресов и он менее специфичный. А маленький отрезочек, который у нас на этой числовой прямой получился, который является частью большего отрезка, он получается наиболее специфичный. Да. Наибольшая специфичность здесь вполне интуитивно понятный термин.

По крайней мере, обычно это проблем не вызывает. И соответственно, предполагается, что чем более специфичный маршрут мы выделяем, чем более узкий участок на числовой оси выделяем, тем более приоритетное это указание будет по сравнению со всеми остальными. Достаточно логичная концепция. Также, как и в случае с классовой маршрутизацией, в бесклассовом мире у каждого узла должна быть таблица маршрутизации. И уже нельзя ничего выделить звёздочкой, поэтому у нас появляется необходимость для взаимодействия с какими-то сетями либо явно их указывать, либо делать маршрут на суперсеть 0.0.0.0. На самом деле, когда вы указываете, например, в Windows или в любой другой операционной системе маршрут по умолчанию, это как раз фактически в таблице маршрутизации задаёт маршрут на эту самую суперсеть. Маршрут по умолчанию — это 0.0.0.0 по нулевой маске. Он и есть. Давайте разберём пример с самым обычным хостом.

У него есть свой собственный IP-шник. 10.0.3.2. Давайте представим, что по 24-й маске, если не указано иное, везде будем считать 24-ю маску. И соответственно, 10.0.3.0/24 — это сетка у нас connected, она напрямую подключена. Здесь, в этом канале живут все IP-шники, начинающиеся на 10.0.3. И оно живёт в интерфейсе Ethernet 0. Вот этот интерфейс. Он один-единственный, всё просто. И заодно указано, что сеть 0.0.0.0 по нулевой маске, то есть все адреса вообще в мире, естественно, за исключением более конкретного кусочка 10.0.3.0 по 24-й маске, будет жить за этим же интерфейсом Ethernet 0, но конкретно за хостом 10.0.3.1. Смотрите, какая штука. Мы здесь не указываем интерфейс, мы указываем IP-шник соседа. И этот IP-шник соседа — возникает вопрос, а где его взять? Очень просто. Мы снова запускаем запрос к таблице маршрутизации. Если нам надо, например, узнать, куда отправить пакет на адрес,

к примеру, 8.8.8.8. У нас возникает вопрос, вот два маршрута в таблице. Можно ли по этому отправить такой пакет? Да, можно, он подходит. Можно ли по этому маршруту отправить пакет на адрес 8.8.8.8? Нет, нельзя, он не подходит. Но дальше возникает вопрос: окей, мы нашли самый выгодный маршрут, и у него указано вместо интерфейса, куда отправлять трафик, какой-то непонятный IP-шник. Куда этот IP-шник-то, что с ним делать дальше? И ответ очень простой. Мы вычёркиваем тот маршрут, который у нас получился самый выгодный. И из числа всех оставшихся задаём вопрос, а до этого next hop, IP-шника next hop, куда надо трафик послать, чтобы стало хорошо? И это называется рекурсивный запрос к таблице маршрутизации. Соответственно, мы из числа всех остальных маршрутов находим самый выгодный маршрут до этого IP-шника next hop. Задаём вопрос и находим, что самый выгодный способ доставить трафик до 10.0.3.0,

В частности, до 10.0.3.1 — это направить пакет на интерфейс Ethernet 0/0. Таким нехитрым образом мы нашли одновременно и интерфейс, куда отправить трафик до 8.8.8.8. Это интерфейс Ethernet 0/0. И заодно мы нашли, кому конкретно отправить трафик за этим интерфейсом, учитывая, что здесь у нас Ethernet-интерфейс. В этом Ethernet может быть много разных участников. И мы выбрали именно того самого, кому имеет смысл отправлять трафик до всех остальных сетей в мире. Оно будет идти на роутер. А дальше этот роутер уже будет разбираться, куда доставить трафик. Мы про него проговорим сейчас отдельно. Давайте другой роутер посмотрим пока, который чуть менее сложный. У него три маршрута в таблице маршрутизации. Одна Connected-сетка 10.0.0.0 по 24-й маске. В ней пользователи сидят. Одна Connected-сетка 10.0.1.0 по 30-й маске. Вот она.

По 30-й маске, значит, у неё только два узла. Вот этот и вот этот. Довольно просто всё. Connected-сетки указаны: одна за одним интерфейсом, другая за другим. И указано, что все сети в мире доступны за интерфейсом 10.0.1.2. Как добраться из интерфейса до next-hop 10.0.1.2? Как до него добраться? Вычёркиваем этот маршрут и задаём вопрос. До 10.0.1.2 — либо сюда, либо сюда. Здесь не подходит, здесь подходит. Следовательно, трафик до всех сетей в мире, кроме явно указанных, отправляется на интерфейс Ethernet-1, соседу, у которого IP-шник 10.0.1.2. Опять же, рекурсивный запрос нам помог. И наконец, самый сложный случай здесь — это вот этот маршрутизатор. У него есть некоторое количество Connected от интерфейсов. 10.0.1.0 — здесь. 10.0.2.0 — здесь. 10.0.3.0 — здесь. 192.168.0.0 по 29-й маске — тут.

Все Connected-сетки мы его описали. Но есть ещё все сети в мире — 0.0.0.0 по нулевой маске, которые доступны через 192.168.0.1. Как узнать, где этот товарищ сидит? Вычёркиваем этот маршрут и задаём вопрос. Среди всех оставшихся, как лучше всего добраться до 192.168.0.1? Через такую сеть — 192.168.0.0 по 29-й маске. Доступна за интерфейсом Ethernet-0/0. Но есть нюанс, который заключается в том, что если мы будем направлять трафик до вообще всех сетей в мире, кроме Connected, на этот самый маршрут по умолчанию, то мы потеряем трафик до 10.0.0.2. Если этот товарищ хочет связаться с вот этим узлом, он направит трафик на свой роутер, а дальше роутер должен сказать: мы не направляем это всё по маршруту по умолчанию в интернет. Мы должны именно до 10.0.0.0 трафик направлять в обход. И у нас появляется сетка 10.0.0.0 по 24-й маске, которая доступна через 10.0.1.1.

А где эта штука? Как её найти? Опять же, вычёркиваем и находим. 10.0.1.1. Вот он, самый выгодный маршрут. Вот это тоже есть в принципе, но этот более вкусный. Поэтому трафик направляется на интерфейс Ethernet-3 на IP-шник 10.0.1.1. Эта концепция в бесклассовом мире именно та, которой мы пользуемся сегодня в 100% случаев. На любом узле, который умеет пользоваться протоколом IP, будь то сотовый телефон, будь то компьютер, будь то принтер, будь то маршрутизатор, у них у всех есть таблица маршрутизации. Иногда она может быть вырождена, иногда вы не можете посмотреть её в виде таблицы. Иногда всё, что вам доступно, это возможность задать только IP-шник с маской и шлюз. По факту IP-шник с маской порождают у вас Connected-сетку, а шлюз порождает у вас запись 0.0.0.0. Вы можете не видеть это как таблицу, но она всё равно там в ядре где-то есть. Чаще всего, если мы работаем с сетевым железом, всё-таки вы можете посмотреть эту самую таблицу,

и она будет иметь какой-то вот такой вид. Чаще всего. С ней мы можем работать. Замечу ещё, что в IPv4 изначально предполагалось, что пакеты, которые приходят на роутер, в принципе, гипотетически могут выходить через несколько интерфейсов одновременно. Мы с таким режимом работать не будем. Мы всегда исходим из того, что пакет входит через один интерфейс и выходит через один интерфейс тоже. Иногда есть подлые люди, которые спрашивают, в чём разница между маршрутизацией IP и коммутацией Ethernet. Вроде бы, говорят эти самые подлые люди, в IP у нас через один интерфейс вошло и через один вышло. И в Ethernet тоже, чаще всего, если у нас всё хорошо настроено, тоже через один интерфейс вошло, через один интерфейс вышло. И эти подлые люди говорят: а как так получается, в чём тогда разница? Но подлые люди на самом деле не учитывают тот факт, что коммутация в Ethernet — это разбрасывание кадра на все интерфейсы,

кроме некоторых в сценарии. Если мы знаем, где сидит получатель, некоторыми интерфейсами становятся все, кроме одного, того самого, за которым с нашей точки зрения сидит получатель. А в IP мы штатно рассматриваем только сценарий, когда мы знаем, где сидит получатель, где мы будем видеть его сеть. Если вдруг в таблице маршрутизации нет вообще никакого маршрута, куда девать пакет, то такой пакет отбрасывается штатно в современном мире. В принципе, вы можете написать какое-то специальное правило, если вдруг мы хотим, мы можем сделать какой-то обработчик вида: нормальные пакеты обрабатываем по таблице маршрутизации, а некоторые обрабатываем как-то ещё. На курсе Route у нас будет такой специальный случай, когда мы будем отталкиваться не от destination-based роутинга, а от правил по обработке трафика с помощью политик.

Тем не менее, нормальное явление в современном IP — это то, что у вас всегда в таблице маршрутизации есть указание, куда девать трафик до определённых сетей. И эта таблица маршрутизации всегда даёт вам ровно одно направление, куда девать пакет. Поэтому пакет входит через один интерфейс и выходит через один интерфейс. Или отбрасывается, потому что вы не знаете, куда его девать. Это не всегда предполагалось таким образом, что будет работать. Изначально, когда военные заказывали разработку протокола IP, они предполагали, что может быть ситуация вида: пакет вошёл через один интерфейс и вышел через много разных интерфейсов. И действительно, такой режим в IP есть. Это называется мультикаст. Когда у вас есть несколько роутеров в цепочке, раз, два, три роутера, и они как-то между собой в такую древовидную структуру разделены. И у вас приходит пакет, он входит через один интерфейс и выходит через два. И на этот роутер он тоже выходит через два.

У вас начинается такое ветвление. Мы не будем рассматривать мультикаст вообще нигде и никогда, если мы говорим про маршрутизируемый мультикаст. Потому что маршрутизируемый мультикаст — это тема большая, сложная, а главное — в классическом предприятии абсолютно ненужная. Тем не менее, такая штука существует. От всего мультикаста, который в принципе бывает, мы будем рассматривать только один маленький кусочек, так называемый немаршрутизируемый мультикаст. Это мультикаст, который работает в пределах канала, то есть он не проходит через роутеры, но зато вы можете отправить такой пакет самостоятельно в интерфейс. Например, у вас есть роутер, и он говорит: я хочу отправить пакет на мультикаст-адрес 224.0.0.2. И такой пакет дойдёт до всех узлов в пределах канала. Вы можете этот свитч взять и заменить на хаб или на толстый жёлтый коаксиал. Фактически получится, что у нас в толстом жёлтом коаксиале находятся четыре участника. И кадр, который несёт в себе такой мультикастовый пакет, дойдёт до всех потребителей.

И дальше все потребители скажут, интересно им это или нет. Если они вдруг запустили какой-то специальный софт, который велел им слушать адрес 224.0.0.2, то они это прочитают. Допустим, два роутера взяли и прочитали такой кадр, содержащий такой мультикастовый IP-пакет. А третий узел не запустил на себе такой софт, который велел ему читать 224.0.0.2, и проигнорировал его. Этот режим мультикаста мы с вами рассматривать будем. Сразу вы можете задать вопрос. Первый: почему 224.0.0.2? Вообще говоря, 224.0.0.2 — это адрес, который относится к классу D. Такие адреса начинаются на три битовые единицы. Когда я вам рассказывал про классы сетей A, B и C, я сказал, что класс D зарезервированный, трогать его нельзя. Но на самом деле, когда мультикаст появился — он появился не сразу — для него потребовалось выделить адресное пространство. И весь диапазон класса D,

это 224.0.0.0 по третьей маске, его разделили на две части. Диапазон класса D — 224.0.0.0/4, и 240.0.0.0/4 — это был класс E. 240.0.0.0/4. Это класс E. Класс E до сих пор зарезервирован, трогать его нельзя, а класс D отдали под мультикаст. Ещё интересный момент заключается в том, что, как я уже сказал, изначально мультикаста в том виде, в котором мы его знаем сегодня, в IP не было, он появился позже. И когда его разрабатывали, его разрабатывали изначально как отдельный протокол. Потому что уж очень концепция обработки мультикаста не похожа на концепцию обработки юникастового трафика по таблице маршрутизации. Там всё другое. И изначально этот протокол называли IPv5. Поэтому у вас может быть вопрос: есть IPv4, есть IPv6, а промежуточное где — IPv5? Так вот, IPv5 — это как раз мультикаст.

Его просто потом решили, что недостойно оно того, чтобы использовать его как отдельный протокол, потому что многие концепции обработки трафика всё-таки очень сильно похожи для IPv4 и для этого самого потенциального IPv5. Поэтому по факту ему решили не выдавать новый номер. Его внедрили в IPv4, просто дали ему отдельное адресное пространство, чтобы не путать взаимодействие юникастовое и мультикастовое. Но номер версии 5 так и остался за мультикастом по факту. 224.0.0.0/24. Вот у меня написано здесь. Это как раз немаршрутизируемый мультикаст. Адреса, начинающиеся на 224.0.0, это 224.0.0.1, 224.0.0.2, 224.0.0.102 и так далее. Это всё адреса, которые распространяются только в пределах канала, и некоторые из этих адресов нам будет нужно знать. Из того, что прямо стоит знать:

224.0.0.1. Это адрес «вообще все». Вообще все, кто поддерживает мультикаст. Более строго — потому что могут быть узлы, которые мультикаст не поддерживают. Вы можете взять, например, попинговать этот IP-шник, и у вас гипотетически может быть такое, что все узлы, которые поддерживают мультикаст, на ваш пинг будут отвечать. Я привёл пример. У меня есть некая машинка под управлением Ubuntu, и я запустил пинг до адреса 224.0.0.1. Видно, что пинги пингуются, но пингуется, правда, только один узел — 192.168.1.20. Все остальные не пингуются. Действительно, большая часть узлов на самом деле на такой мультикастовый пинг не отвечает. Это специальное особое условие, которое говорит, что если просто кто-то пытается кого-то непонятно пинговать, он всё-таки должен указывать, кого он именно хочет пинговать. 224.0.0.1 — это адрес «вообще все».

Это очень широко накрываемая аудитория, поэтому многие узлы не хотят, чтобы их так широко пинговали. Из того, что ещё вам может пригодиться: 224.0.0.2 — это все роутеры. Например, вы на циске запускаете процесс маршрутизации, и она начинает слушать адрес 224.0.0.2 — все роутеры. 224.0.0.5 и 0.6 — это будет OSPF. Если вы запускаете процесс OSPF, динамической маршрутизации, то ваш роутер будет слушать один или даже оба эти адреса, в зависимости от того, в каком режиме он будет работать. 224.0.0.9 — это RIP, 224.0.0.10 — EIGRP. Это мы всё в курсе CCNP уже будем с вами смотреть. Главное, чтобы вы понимали, что мультикаст, который на 224.0.0 начинается, это всё немаршрутизируемый мультикаст. Он не проходит через роутеры, но он работает в пределах канала. Это всё, что я хотел рассказать

про бесклассовую маршрутизацию. На всякий случай резюмируя: всё, что мы сегодня делаем, работает именно в парадигме бесклассовой маршрутизации. Никаких классовых адресов сегодня нет. Вы не можете получить сегодня классовую сеть в принципе. Вы можете получить сеть, эквивалентную по размеру, бесклассовой сети. Но обязательно всегда, когда вы будете сегодня использовать какие-то IP-шники, рядом с ними нужно указывать маску, где конкретно у вашего IP-шника проходят границы между левой и правой частью. Абсолютно 100% софта сегодня поддерживает бесклассовую и только бесклассовую маршрутизацию. Но в некоторых случаях следы классовой маршрутизации, несмотря на то, что с 92-го года она полностью искоренена, первые попытки её искоренить начались через 3 года после того, как IP пошёл в продакшн в далёком 84-м году. Сколько получается? 35 лет назад. В очень-очень-очень далёком прошлом всё это начали искоренять, но сегодня, в 2019 году,

следы классовой маршрутизации всё ещё кое-где вылезают. Например, если вы в операционной системе Windows пытаетесь установить VPN-подключение, и вам протокол согласования виртуального канала выдаёт IP-шник, он вам не выдаёт маску. И автоматически Windows предполагает, что если маску не выдают, то нужно использовать маску классовую. И, соответственно, вам выдают адрес 192.168.1.0, вы говорите, ага, это адрес в классовом мире был бы адресом класса C. Поэтому я поставлю классовую маску слэш 24. Или, например, вы получаете IP-шник 10.0.0.1. Ваш Windows говорит, окей, мы построили VPN-туннель, мы в нём получили IP-шник 10.0.0.1. Какую маску мы поставим? Правильно. Аналогичную классовой. 255.0.0.0. Слэш восьмую. Кое-где такие рудименты вылезают. Так же, как иногда рождаются люди, у которых есть кусочек хвостика. Вроде хвостик им не сильно нужен, и, в принципе, его можно смело отрезать,

но всё равно оно рождается такое. И то же самое в современном мире с классовыми рудиментами. Тоже иногда с ними приходится сталкиваться. Это не что-то абсолютно несуществующее, и вы должны понимать, как это когда-то давным-давно работало. Но по факту в 99,99% случаев вы с классовыми штуками не столкнётесь никогда. Но понимать, откуда всё берётся, всё-таки нужно. Давайте к следующей теме. Эту тему пора закапывать. Продолжение следует...