Дизайн сети предприятия

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

это мы с вами сейчас и обсудим. Если мы говорим про обычную кампусную сеть, сеть предприятия, там, где обычные юзеры сидят, её удобно строить с помощью блочной структуры, когда вся сеть разделяется на отдельные блоки. Все эти блоки похожи друг на друга, как братья-близнецы. Если у вас сеть построена по блочной структуре, то добавление нового блока в эту сеть происходит очень легко. Вы просто берёте и фактически копируете то, что у вас уже есть. Вот пример. Давайте попробую рисовалку использовать, как раз достал планшет. У нас есть сеть предприятия, у нас есть свичи уровня доступа, access-свичи, в них подключаются конечные юзеры. Обычный пользователь подключается к сети с помощью обычного порта свича. Вы ему даёте патчкорд, он втыкает в свой ноутбук и подключается к свичу. Обычные пользователи не нагружают свой порт. Если мы говорим про сеть предприятия, типичный пользователь, который в предприятии работает,

он не запускает торренты, не запускает приложения, которые будут передавать много трафика, не запускает подключения к сторидж-сетям, где требуется гонять много данных. Обычный юзер подключается к сети, скорее всего, на 100-мегабитном либо на гигабитном порту. И этот порт используется редко. Да, он может запустить что-то интенсивное, использующее сеть, например, условно 1С. И да, эта 1С может начать много трафика сосать с какого-нибудь дальнего сервера. Но она немножко прососала и перестала. И потом снова работал пользователь, нажал кнопку «сохраниться», снова насосала, перестала. Если используется передача файлов, то это всегда будет именно файловая передача, не блочная, а именно файловая. Когда передаётся большой файл, он немножко передаётся, а потом не передаётся. Немножко снова передаётся, немножко снова не передаётся. Такие порты на свичах доступа загружены не сильно. И когда они загружены, они загружены сильно в течение небольшого времени.

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

Внутри блока можно много access-свичей добавлять. Главное, чтобы у вас портов на distribution хватило для того, чтобы это всё физически подключить в сеть. Но и distribution можно соединять по схеме каждый с каждым между собой, можно их соединять через какое-то центральное ядро. Вот здесь на картинке показана схема с ядром сети, где у нас есть ядро. Core-свичи. Это свичи дорогие, быстрые и достаточно глупые, потому что они нужны только для того, чтобы соединить distribution-блоки между собой. Здесь у нас один distribution-блок, здесь другой distribution-блок, здесь третий distribution-блок. Эти блоки между собой неудобно соединять по схеме каждый с каждым. Поэтому они подключаются к ядру сети, а ядро сети уже подключается к другим блокам. Эта схема позволяет с использованием блочной структуры реализовать подключение нового здания, например, очень просто. Если у вас комплекс зданий раскидан по территории, в каждое здание мы ставим два distribution,

сколько надо access-свичей, и все линки между зданиями мы проводим в какое-то центральное место, где стоит пара core-свичей. Не в любой сети core нужен, ядро нужно только для того, чтобы сэкономить линки на distribution. Если у нас distribution-свичей всего 4 штуки, потому что у нас два distribution-блока, два здания между собой надо соединить, нет никакого смысла добавлять core-свичи. Добавление нового свича в разрыв, в путь трафика между двумя узлами, никоим образом не ускоряет работу. Оно всегда только замедляет её. Для distribution и core не используется в современном мире L2. Если мы говорим про хоть сколько-то современную сеть, это всегда L3. Distribution-свичи у вас всегда L3. Здесь L2 может ещё бегать. У вас здесь всякие VLAN-ы, транки и прочая L2-логика. А всё, что выше, — это уже везде всегда будет только IP.

IPv4 или IPv6 и тут какой-нибудь OSPF или что-то ещё. Старые сети, если говорить про совсем старые сети, они могли быть L2. У вас в пределах всей кампусной сети вполне мог быть один огромный Ethernet-домен, в котором вы делали VLAN-ы. И предполагалось, что в этом случае на core у вас тоже транки дотягиваются. И дальше вы гоняете огромный Spanning Tree или MST, или что-то там. Это уже давно не модно так делать. И проблемы, которые возникают в таких сетях, реально тяжело траблшутятся. Поэтому, если у вас есть возможность не работать с L2, не работать с огромным коммутируемым Ethernet-ом, не делайте этого. Так делать плохо. Используйте IP, потому что IP легко траблшутить, IP легко администрировать, IP легко масштабировать. Проблемы в IP существенно меньше по своей области, которую они будут затрагивать.

Если где-то что-то пойдёт не так, у вас отвалится какой-нибудь маленький кусок сети. Не может быть такого, что если у вас где-то что-то в сети начинает козлить, то ложится вся сеть целиком. Со Spanning Tree такое может произойти. Поэтому никакого L2. Актуальная рекомендация, которую Cisco предлагает рассматривать в качестве best practice, заключается в том, чтобы даже до свичей доступа доводить L3. Чтобы пользователи втыкались в свич, и этот свич являлся шлюзом по умолчанию. Дальше у вас вообще вся сеть будет уже L3. Я рекомендую вам, если такая возможность есть, использовать этот дизайн. Но он, естественно, предполагает, что у вас access-свичи должны быть достаточно умные. И они, как правило, дороже, чем чистые L2. Поэтому, если деньги есть, овчинка стоит выделки. Используйте L3-свичи. Если денег нет, и свичи уже куплены, и никто вам не даст их поменять, тогда делать нечего. Ешьте, что дают.

Дальше. Что касается пользователей. Пользователи подключаются к своим access-свичам. Access-свичи включаются в distribution. Distribution, если есть, подключаются к ядру. И дальше у нас возникает вопрос: а что дальше? Юзеры воткнулись в сеть. Да, юзеры между собой могут пересылать трафик. Но юзерам между собой не очень интересно пересылать трафик. Юзеры хотят либо в интернет ходить, либо к каким-то сервисам доступ получать. И для того, чтобы выйти в интернет, используется так называемый edge-блок. Этот edge-блок — это роутеры, которые подключаются либо к интернету, либо терминируют на себе какие-то VPN-подключения, либо что-то ещё. Это какие-то специальные устройства, которые надо куда-то подключить. Вот куда их надо подключать. Если мы говорим про это как единый блок, мы можем сказать, это такой же блок, как и этот distribution-блок, как и этот distribution-блок, как и этот distribution-блок. Мы можем этот блок точно так же, как и эти блоки, подключить.

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

Но мы сейчас туда лезть не будем. Для нас это просто отдельный блок, который надо подключить к нашей сети. Таких блоков вы можете наплодить сколько угодно. Вы ограничены только ёмкостью ваших core-свичей. Как правило, когда у вас выделяется отдельный edge-блок, то да, у вас ядро уже есть. Если ядра у вас нет, то можно будет все эти блоки соединять по схеме каждый с каждым. У вас есть здесь пара distribution-свичей, здесь пара distribution-свичей, здесь пара distribution-свичей, здесь пара роутеров. И вы их просто по схеме каждый с каждым подключаете. Понятное дело, что это потребует огромного количества линков между этими устройствами. Но если этих блоков 2, 3, 4, это всё ещё оправдано. Если этих блоков становится штук 10, то соединять их по схеме каждый с каждым уже просто математически становится невыгодно. И стоимость портов, которые вы занимаете для взаимодействия по схеме каждый с каждым, начинает превышать разумные пределы. Distribution-свичи довольно дорогие,

и стоимость порта у них тоже довольно велика. Поэтому для экономии портов, для экономии денег на этих портах, вы можете выделить отдельно два свича для уровня ядра. И трафик пропускать уже между ними. Внутри каждого блока или между блоками мы будем запускать какой-то протокол динамической маршрутизации. И для каждой задачи мы будем подбирать протокол маршрутизации, который будет правильным для этой задачи. Внутри кампусной сети, там, где у нас обычные юзеры сидят, удобно использовать протоколы OSPF или EIGRP. Они для этого хорошо предназначены, у них для этого есть инструменты. Они нормально работают на сетях такого масштаба. Какой у вас может быть масштаб кампусной сети? Тысяча пользователей, 10 тысяч пользователей. Кампусная сеть на 10 тысяч пользователей — это университет. Представьте себе какую-нибудь сеть МГУ.

Эта сеть, в которой много зданий, они расположены достаточно компактно. Там тысячи и тысячи пользователей сидят. И внутри всего этого может работать протокол динамической маршрутизации. OSPF или EIGRP при правильной подготовке с такими масштабами справиться могут. Если у вас пользователей становится больше, то это уже просто перестаёт быть кампусной сетью, это перерастает во что-то другое. И там вам потребуется протокол динамической маршрутизации, который будет больше подходить для подобных задач. Представьте себе сеть какого-нибудь условного Газпрома, у которого много организаций, много зданий, распределённых даже по городу. И не говоря про то, что в разных регионах, в разных городах тоже есть здания. В такой ситуации вам лучше будет использовать протокол, который заточен под большое количество маршрутов, под стабильность, потому что если сеть Газпрому упадёт, это будет, наверное, неприятно. И для того, чтобы хорошо работать в сетях, в которых очень много пользователей,

нужно будет использовать протокол BGP. BGP может работать внутри сети предприятия. Он для этого может быть использован. Не сказать, чтобы он под это был заточен, но он нормально справляется с подобной задачей. Как правило, он будет не единственным протоколом. Он будет решать задачу перетаскивания маршрутов, а рядом с ним будет ещё другой протокол, классический IGP, который решает какую-нибудь ещё задачу. Мы с вами, когда про BGP будем говорить, разберём, в каких сценариях его можно будет использовать. Если у вас есть какой-то блок, который отвечает за центр обработки данных, то там тоже будет либо чистый OSPF работать, либо OSPF плюс BGP. EIGRP в ЦОД-ах экстремально редко используется. Это всё-таки экзотика. Если вы будете подключаться к интернету или поверх каких-то VPN-ов организовывать связи с другими своими офисами,

VPN-ы могут быть любыми, могут быть провайдерскими, могут быть через интернет, то вы захотите динамическую маршрутизацию тоже иметь. И для такого рода сценариев лучше использовать специальные отдельные протоколы. Не любой протокол будет для этого подходить. Для подключения к WAN-сетям или к VPN-ам лучше использовать протокол класса Distance Vector. Если у вас есть WAN-сети или VPN-ы, или что-то в этом духе, то эти сети могут работать нестабильно. У вас VPN может, допустим, подняться-упасть, подняться-упасть, подняться-упасть. Если у вас поверх этого работает OSPF, протокол класса Link State, его каждый раз на такое событие будет передёргивать. Он будет заново пересчитывать всю топологию. То с поднявшимся интерфейсом, то с упавшим, то с поднявшимся, то с упавшим. И ему будет очень тяжело с такой ситуацией бороться, потому что каждый раз ему потребуется много ресурсов для обработки такой ситуации.

Если мы используем Distance Vector, то там всё хорошо. Там просто прибежал новый маршрут, что у нас есть новая сетка, а потом маршрут упал, мы просто рассказываем, что такой сетки больше нет. Нагрузка на протокол динамической маршрутизации при изменении топологии будет существенно ниже для Distance Vector протоколов. И это как раз то, что требуется в WAN-сетях или в случаях с VPN. Это не означает, что вы не можете использовать OSPF для VPN. Но если у вас есть хорошо спроектированная сеть, лучше Link State протоколы в VPN не использовать. Мы должны будем знать разницу между различными протоколами, которые можно использовать, знать, где их хорошо использовать, где их плохо использовать, почему их в тех или иных местах нехорошо использовать, и знать плюсы и минусы тех или иных протоколов. Например, OSPF — это протокол класса Link State, классический протокол IGP, Interior Gateway Protocol, который работает внутри автономной системы.

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

Хотя Cisco, например, работает по умолчанию в 1583. Это означает, что если вы берёте Cisco и не Cisco, то с большой вероятностью OSPF есть и там, и там. Протокол, очевидно, сложный. Потому что каждый раз, когда происходят какие-то изменения, запускается много процессов пересчётов. И если у вас постоянно какие-то изменения происходят, то OSPF может 100% нагрузку положить на процессор. Это не то, чего вы хотите. Если у вас сеть работает нестабильно, OSPF в такой сети лучше не использовать. EIGRP, в свою очередь, протокол дистанс-векторный. Соответственно, протокол тоже IGP. При правильной подготовке тоже неплохо масштабируемый. Тоже очень быстрый, как и OSPF. Может работать с произвольной адресацией в том смысле, что если вдруг вы запускаете EIGRP на совершенно произвольной сети, EIGRP выживет. OSPF не выживет. На совершенно случайной сетке с тысячами маршрутов EIGRP выживет.

Может быть, не очень хорошо будет работать, но нормально. Но есть у него недостаток. EIGRP — протокол нестандартный. RFC по нему вышла, Cisco его опубликовала, но по факту его реализация только в FRR-роутинге. И она, скажем, неполноценная. Поэтому, если вы хотите подружить Cisco с чем-нибудь, то что-нибудь должно быть либо Cisco, и тогда вы можете использовать EIGRP, либо, если это не Cisco, EIGRP вам будет противопоказан. Вычислительно простой, в том смысле, что нагрузку на процессор EIGRP не даёт вовсе. У него, что бы ни происходило, ничего не может взять и заставить его задуматься о вечном надолго. Если говорить про другие протоколы, которые у нас в курсе будут, например, BGP. BGP тоже дистанс-векторный протокол. Его иногда называют path-вектор, потому что единица передачи информации у него не маршрут, а именно путь, по которому может пройти трафик. Но тем не менее ведёт себя он исключительно

как дистанс-векторный протокол, поэтому можно пренебречь специальным определением. Протокол BGP заточен под большие сети, под сети масштаба интернета. И поэтому его называют, соответственно, EGP-протоколом, потому что в интернете у нас будет множество автономных систем, передающих друг другу информацию. Поэтому мы никогда никому не доверяем. Если нам кто-то что-то присылает, мы 10 раз это перепроверим, перед тем как принять в таблицу маршрутизации, отправить дальше. В IGP мы всем доверяем, потому что если у нас есть несколько роутеров, которые настроены одними и теми же людьми, в одной и той же логике, соседняя железка не может нам прислать ничего плохого. Если мы проверили, что это действительно соседняя железка прислала, всё, мы безусловно доверяем тому, что прислал сосед. В BGP, даже если мы знаем, кто сосед, мы не доверяем по умолчанию всему тому, что присылается по соседству. Мы перепроверяем, проверяем по политикам и так далее.

За счёт этого BGP будет очень здорово масштабироваться. BGP действительно адаптирован под адресное пространство с миллионами префиксов. Он вполне может выжить в сети, в которой миллион, два миллиона маршрутов. При этом надо понимать, что в интернете сейчас маршрутов меньше. Сегодняшний интернет состоит примерно из 700 тысяч маршрутов, плюс-минус. Но если мы говорим, например, про провайдерские сети, там может быть большое количество маршрутов — не только тех, которые есть в интернете, но и маршрутов их пользователей. И соответственно, BGP всё равно под это дело заточен. Он нормально выживает, когда получает пачку маршрутов интернета, и в дополнение ещё пару сотен клиентов выгружают свои таблицы маршрутизации в провайдерский BGP. И да, BGP нормально выживает в таких условиях. BGP за счёт того, что он масштабируемый, за счёт того, что он никому ничего не доверяет, очень медленно работает по сравнению с OSPF, с EIGRP.

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

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

традиционно в курсе используется RIP, Routing Information Protocol, Distance Vector Protocol, очень старый, 69-го года. Он появился до того, как был придуман протокол IP. Это забавно на самом деле, но тем не менее, да, RIP — это протокол динамической маршрутизации, который сегодня воспринимается исключительно как протокол для IP, а придуман он был до IP, за 5 лет до этого. Соответственно, в 68-м году никакие задачи, которые для нас абсолютно естественны сегодня, тогда просто не существовали. Не было задачи обеспечить безопасность в сети, не было задачи обеспечить быстрое переключение между двумя маршрутами, если вдруг один маршрут дохнет, соответственно, быстро переключиться на второй. Не было задачи быстро вообще отреагировать на что-то. RIP хоть как-то сделает что-то, что он умеет, и уже хорошо. Поэтому в курсе RIP используется как образцово-показательный плохой протокол, хотя на самом деле сам протокол неплохой.

Он просто очень простой. За счёт того, что он очень простой, у него нет каких-то специальных особенных супервозможностей. И как следствие, когда мы его начинаем сравнивать с OSPF, который сложный, или с EIGRP, который быстрый, RIP по всем статьям будет проигрывать. RIP не масштабируется, потому что в 68–69-м году, когда он был придуман, никто не ставил задачу на роутере обслуживать миллионы маршрутов. Миллионов маршрутов не было. Протокола IP не было. Когда его через 5 лет только придумают, в качестве образцово-показательного дизайна сети интернета авторы протокола IP будут видеть то, что в каждой стране может быть пара сотен маршрутов. Стран — две сотни, и в каждой стране пара сотен маршрутов. И всего получается десятки тысяч маршрутов — это то, что авторы протокола закладывали. RIP даже под эти десятки тысяч заточен не был. Он под тысячу маршрутов ещё, может быть, и переживёт,

но не более того. RIP никоим образом не быстрый. Опять же, в 68–69-м году, когда он создавался, не было задачи быстро переключиться между двумя маршрутами, если один маршрут сдох. Если новая сеть стала известна, ещё туда-сюда можно сказать, что RIP в некоторых ситуациях отреагирует быстро. Но когда хороший маршрут уходит из таблицы, и вместо него остаётся похуже, RIP на это очень долго будет тупить. И соответственно, RIP — стандартный протокол, есть во многих железках. Из того, что можно будет вспомнить замечательного: например, RIP есть в Windows Server. Это не для того, чтобы вы Windows Server могли использовать в качестве маршрутизатора. RIP в Windows Server есть для того, чтобы вы могли протокол динамической маршрутизации довести до конечных хостов, чтобы у каждого конечного хоста была полная таблица маршрутизации, чтобы трафик до тех сетей, которых нет в таблице маршрутизации, хост просто не посылал.

И соответственно, когда-то давным-давно была гениальная идея, что можно динамическую маршрутизацию догонять до конечных хостов и тем самым хостам, например, сообщать, какой максимальный MTU может быть в сети до каждого конкретного префикса, какое количество хопов, какая там производительность и всякое такое. Но это не очень популярная идея, и сегодня она используется крайне редко, но тем не менее в своё время задумка такая была. Так, RIP очень простой и очень тупой. Из того, что можно будет встретить в реальной сети предприятия, достаточно интересным аспектом будет возможность агрегировать маршруты. Если у вас есть правильно задизайненная сеть, то в каждом блоке у вас будет использоваться своя отдельная сетка. Представьте себе, что это у нас, например, distribution block. 1 distribution block, 2 distribution block, а это, соответственно, ядро. Это core. Это distribution block 1.

Это distribution block 2. Это, например, два здания. В каждом здании мы используем свою отдельную сеть. Например, в верхнем блоке мы используем сеть 10.1.0.0 с маской /16. Во втором здании мы используем сеть, например, 10.3.0.0 с маской /16. И соответственно, внутри каждого блока мы дербаним эту сетку на подсети. Здесь у нас юзеры сидят в одной сети 10.1.1.0, здесь юзеры в другой сети 10.1.2.0, 10.1.3.0, 10.1.4.0. Мы берём эту сетку 10.1.0.0 с маской /16 и режем её на /24. И на пользовательских интерфейсах мы используем именно кусочки этой большой сети. Когда мы наружу будем анонсировать, что у нас есть какие-то сети, мы не будем отдельно маленькие кусочки с маской /24 анонсировать. Мы возьмём и склеим их в одну большую сетку 10.1.0.0 с маской /16, из которой на самом деле они все были порезаны. И поэтому наружу будет анонсироваться

не мелочь всякая, а одна большая сеть 10.1.0.0 с маской /16. И каждый блок будет анонсировать только одну свою большую сеть. Соответственно, ядро тоже будет суммировать все эти маршруты. Оно будет говорить, что у нас есть доступ во все эти сети — 10.1.0.0, 10.2.0.0, 10.3.0.0, 10.4.0.0 — с маской /16, они все есть. Если этих блоков мало, например 2, 3, 4, в принципе все эти маршруты можно отправить всем блокам. Но если этих блоков много, например представьте, что у вас 200 таких distribution-блоков, просто такие гигантские core-свитчи стоят, и к ним приходит много-много маршрутов — все эти блоки, все эти IP-сети можно схлопнуть до одного дефолтного маршрута. Ваш core-свитч посылает на distribution-свитч указание: вообще все IP-шники доступны через меня. Зачем это делается? Для того чтобы сократить количество записей в таблице маршрутизации, потому что чем меньше записей в таблице маршрутизации, тем меньше нагрузка на железке. Если

у вас есть distribution-блок, он будет знать про все свои сети внутри сети 10.1.0.0 с маской /16, и он будет знать, что всё остальное доступно через ядро. В ядре, в свою очередь, будет ограниченное количество маршрутов: 10.1.0.0/16, 10.2.0.0/16, 10.3.0.0/16, и возможно здесь где-то ещё будет доступ в интернет, и соответственно здесь будет приходить уже настоящий дефолт 0.0.0.0/0. Здесь где-нибудь сбоку может жить не distribution, а дата-центр, и соответственно он будет свои какие-то маршруты присылать. Опять же, ядро знает, где кто сидит, ядро получает эти агрегированные маршруты и трафик будет посылать по ним. Но в каждом distribution-блоке не надо знать на самом деле, что есть такой-то блок, есть второй, есть пятый, есть десятый — если всё равно весь трафик должен пройти через ядро. Поэтому такая схема, когда вы все маршруты схлопываете и агрегируете и тем самым

порождаете меньшее количество записей в таблице маршрутизации, она достаточно элегантная и очень хорошо масштабируется. Иногда агрегацию называют словом суммаризация — суть одна и та же. У нас есть несколько мелких сетей, которые были порезаны на части из одной крупной, и мы берём и агрегируем эти несколько сетей до одной большой. Слово «суммаризация» мне просто не очень нравится. Во-первых, она не очень красивая, какая-то не русская. Во-вторых, я стараюсь избегать использования этого слова, потому что в OSPF есть LSA тройка, который называется summarize, и для того чтобы не путать summarize LSA и суммарные маршруты, я соответственно стараюсь не использовать слово «суммаризация». Но иногда в литературе суммаризация — это как раз то же самое, что я называю агрегацией. Всякие more specific, которые у вас есть, они есть только в пределах своей области видимости, своего distribution блока. У нас здесь 10.100.16 маски. Порезано на /24: .1, /24: .2, /24: .3, /24 — они все

в пределах distribution блока видны. Наружу distribution блока мы показываем только совокупную, агрегированную сетку 10.100.16 с маской, из которой это всё было порезано. Так, это такой краткий рассказ про то, как можно дизайнить IP-сети в предприятии. У нас будет детальный рассказ про то, как можно вообще организовать связь между коммутаторами. Там все те же самые концепции будут использованы. Тоже будет рассказ про access switch, про distribution switch, про core switch на курсе по switching. Там разберём, например, концепцию, когда у вас нет core switch, нет ядра, и routing и distribution switch будет соединяться между собой напрямую. Это будет штука, называется collapsed core. Она уже не будет использовать тот факт, что у вас обязательно там бегает протокол IP. Если у вас есть collapsed core, он прекрасно будет жить что с IP,

что с Ethernet, то есть что L2 будет использовать, что L3. Поэтому весь этот блок переехал туда. Но тем не менее на всякий случай знайте, что если есть у вас такая полноценная сеть — полноценная в смысле большая-пребольшая — у вас она разбивается на distribution блоки, и блоки связываются между собой через ядро. Если у вас сеть не настолько большая, чтобы ставить отдельный core switch, то distribution между собой могут связываться по схеме «каждый с каждым», и тогда такая сеть будет называться collapsed core, когда у вас фактически core switch нет, а distribution трафик между собой гонит напрямую.