По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Десятая часть тут.
Вы входите в комнату и кричите: «Игорь!» Ваш коллега Игорь оборачивается и начинает разговор о будущем IT-индустрии. Эта способность использовать один носитель (воздух, по которому движется ваш голос) для обращения к одному человеку, даже если многие другие люди используют этот же носитель для других разговоров в одно и то же время, в сетевой инженерии называется мультиплексированием. Более формально:
Мультиплексирование используется, чтобы позволить нескольким объектам, подключенным к сети, обмениваться данными через общую сеть.
Почему здесь используется слово объекты, а не хосты? Возвращаясь к примеру «разговор с Игорем", представьте себе, что единственный способ общения с Игорем — это общение с его ребенком-подростком, который только пишет (никогда не говорит). На самом деле Игорь-член семьи из нескольких сотен или нескольких тысяч человек, и все коммуникации для всей этой семьи должны проходить через этого одного подростка, и каждый человек в семье имеет несколько разговоров, идущих одновременно, иногда на разные темы с одним и тем же человеком. Бедный подросток должен писать очень быстро, и держать много информации в голове, например: "Игорь имеет четыре разговора с Леной", и должен держать информацию в каждом разговоре совершенно отдельно друг от друга. Это ближе к тому, как на самом деле работает сетевое мультиплексирование- рассмотрим:
К одной сети могут быть подключены миллионы (или миллиарды) хостов, и все они используют одну и ту же физическую сеть для связи друг с другом.
Каждый из этих хостов на самом деле содержит много приложений, возможно, несколько сотен, каждое из которых может связываться с любым из сотен приложений на любом другом хосте, подключенном к сети.
Каждое из этих приложений может фактически иметь несколько разговоров с любым другим приложением, запущенным на любом другом хосте в сети.
Если это начинает казаться сложным, то это потому, что так оно и есть. Вопрос, на который должен ответить эта лекция, заключается в следующем:
Как эффективно мультиплексировать хосты через компьютерную сеть?
Далее рассматриваются наиболее часто используемые решения в этом пространстве, а также некоторые интересные проблемы, связанные с этой основной проблемой, такие как multicast и anycast.
Адресация устройств и приложений
Компьютерные сети используют ряд иерархически расположенных адресов для решения этих проблем. Рисунок 1 иллюстрирует это. На рисунке 1 показаны четыре уровня адресации:
На уровне физического канала существуют адреса интерфейсов, которые позволяют двум устройствам обращаться к конкретному устройству индивидуально.
На уровне хоста существуют адреса хостов, которые позволяют двум хостам напрямую обращаться к конкретному хосту.
На уровне процесса существуют номера портов, которые в сочетании с адресом хоста позволяют двум процессам обращаться к конкретному процессу на конкретном устройстве.
На уровне диалога (разговора) набор порта источника, порта назначения, адреса источника и адреса назначения может быть объединен, чтобы однозначно идентифицировать конкретный разговор или поток.
Эта схема и объяснение кажутся очень простыми. В реальной жизни все гораздо запутаннее. В наиболее широко развернутой схеме адресации - интернет-протоколе IP отсутствуют адреса уровня хоста. Вместо этого существуют логические и физические адреса на основе каждого интерфейса.
Идентификаторы (адреса) мультиплексирования и мультиплексирование иерархически расположены друг над другом в сети.
Однако есть некоторые ситуации, в которых вы хотите отправить трафик более чем на один хост одновременно. Для этих ситуаций существуют multicast и anycast. Эти два специальных вида адресации будут рассмотрены в следующих лекциях.
О физических каналах, Broadcasts, и Failure Domains
Простая модель, показанная на рисунке 1, становится более сложной, если принять во внимание концепцию широковещательных доменов и физического подключения. Некоторые типы мультимедиа (в частности, Ethernet) разработаны таким образом, что каждое устройство, подключенное к одной и той же физической линии связи, получает каждый пакет, передаваемый на физический носитель—хосты просто игнорируют пакеты, не адресованные одному из адресов, связанных с физическим интерфейсом, подключенным к физическому проводу. В современных сетях, однако, физическая проводка Ethernet редко позволяет каждому устройству принимать пакеты любого другого устройства. Вместо этого в центре сети есть коммутатор, который блокирует передачу пакетов, не предназначенных для конкретного устройства, по физическому проводу, подключенному к этому хосту.
В этих протоколах, однако, есть явные адреса, отведенные для пакетов, которые должны передаваться каждому хосту, который обычно получал бы каждый пакет, если бы не было коммутатора, или что каждый хост должен был получать и обрабатывать (обычно это некоторая форма версия адреса все 1 или все 0). Это называется трансляцией (broadcasts). Любое устройство, которое будет принимать и обрабатывать широковещательную рассылку, отправленную устройством, называется частью широковещательной рассылки устройства. Концепция широковещательного домена традиционно тесно связана с областью сбоев, поскольку сбои в сети, влияющие на одно устройство в широковещательном домене, часто влияют на каждое устройство в широковещательном домене.
Не удивляйтесь, если вы найдете все это довольно запутанным, потому что на самом деле это довольно запутанно. Основные понятия широковещания и широковещательных доменов все еще существуют и по-прежнему важны для понимания функционирования сети, но значение этого термина может измениться или даже не применяться в некоторых ситуациях. Будьте осторожны при рассмотрении любой ситуации, чтобы убедиться, что вы действительно понимаете, как, где и, что такие широковещательные домены действительно существуют, и как конкретные технологии влияют на отношения между физической связью, адресацией и широковещательными доменами.
Основная цель TCP состоит в том, чтобы обеспечить транспортировать данные поверх IP. Как протокол более высокого уровня, он полагается на возможности адресации и мультиплексирования IPv6 для передачи информации на правильный хост назначения. По этой причине TCP не требует схемы адресации.
Управление потоком
TCP использует метод скользящего окна для управления потоком информации по каждому соединению между двумя хостами. Рисунок 1 демонстрирует это. На рисунке 1 предположим, что начальный размер окна установлен равным 20. Затем последовательность событий:
В момент времени t1 отправитель передает 10 пакетов или октетов данных (в случае TCP это 10 октетов данных).
В момент времени t2 получатель подтверждает эти 10 октетов, и для окна установлено значение 30. Это означает, что отправителю теперь разрешено отправлять еще до 30 октетов данных перед ожиданием следующего подтверждения; другими словами, отправитель может отправить до 40 октетов, прежде чем он должен будет дождаться подтверждения для отправки дополнительных данных.
В момент времени t3 отправитель отправляет еще 5 октетов данных, номера 11–15.
В момент времени t4 приемник подтверждает получение октетов через 15, и окно устанавливается на 40 октетов.
В момент времени t5 отправитель отправляет около 20 октетов данных, пронумерованных 16–35.
В момент времени t6 получатель подтверждает 35, и окно устанавливается на 50.
Следует отметить несколько важных моментов, касающихся этой техники:
Когда получатель подтверждает получение определенного фрагмента данных, он неявно также подтверждает получение всего, что было до этого фрагмента данных.
Если приемник не отправляет подтверждение—к примеру , передатчик отправляет 16-35 в момент времени t5, а приемник не отправляет подтверждение—отправитель будет ждать некоторое время и считать, что данные никогда не поступали, поэтому он будет повторно отправлять данные.
Если получатель подтверждает некоторые данные, переданные отправителем, но не все, отправитель предполагает, что некоторые данные отсутствуют, и ретранслирует с точки, которую подтвердил получатель. Например, если отправитель передал 16-35 в момент времени t6, а получатель подтвердил 30, отправитель должен повторно передать 30 и переслать.
Окно устанавливается как для отправителя, так и для получателя
Вместо использования номеров октетов TCP присваивает каждой передаче порядковый номер; когда приемник подтверждает определенный порядковый номер, передатчик предполагает, что приемник фактически получил все октеты информации вплоть порядкового номера передачи. Для TCP, таким образом, порядковый номер действует как своего рода “стенография” для набора октетов. Рисунок 2 демонстрирует это.
На рисунке 2:
В момент времени t1 отправитель объединяет октеты 1–10 и передает их, помечая их как порядковый номер 1.
В момент времени t2 получатель подтверждает порядковый номер 1, неявно подтверждая получение октетов 1–10.
В момент времени t3 отправитель связывает октеты 11–15 вместе и передает их, помечая их как порядковый номер 2.
В момент времени t4 получатель подтверждает порядковый номер 2, неявно подтверждая октеты, отправленные через 15.
В момент времени t5 предположим, что 10 октетов поместятся в один пакет; в этом случае отправитель отправит два пакета, один из которых содержит 16–25 с порядковым номером 3, а другой - октеты 26–35 с порядковым номером 4.
В момент времени t6 приемник подтверждает порядковый номер 4, неявно подтверждая все ранее переданные данные.
Что произойдет, если один пакет информации будет пропущен?
Что делать, если первый пакет из потока в 100 пакетов не получен? Используя систему, описанную на рисунке 2, получатель просто не подтвердит этот первый пакет информации, вынуждая отправителя повторно передать данные через некоторое время. Однако это неэффективно; каждый потерянный пакет информации требует полной повторной отправки из этого пакета. Реализации TCP используют два разных способа, чтобы получатель мог запросить один пакет.
Первый способ - тройное признание. Если получатель трижды подтверждает пакет, который предшествует последнему подтвержденному серийному номеру, отправитель предполагает, что получатель запрашивает повторную передачу пакета. Три повторных подтверждения используются для предотвращения неправильной доставки пакетов или отброшенных пакетов, вызывающих ложный запрос на повторную передачу.
Второй способ заключается в реализации выборочных подтверждений (SACK).15 SACK добавляет новое поле к подтверждению TCP, которое позволяет получателю подтвердить получение определенного набора серийных номеров, а не предполагать, что подтверждение одного серийного номера также подтверждает каждый более низкий серийный номер.
Как долго передатчик ждет перед повторной передачи?
Первый способ, которым отправитель может обнаружить потерянный пакет - это время ожидания повторной передачи (RTO), которое рассчитывается как функция времени приема-передачи (RTT или rtt). Rtt — это временной интервал между передачей пакета отправителем и получением подтверждения от получателя. RTT измеряет задержку в сети от передатчика до приемника, время обработки в приемнике и задержку в сети от приемника до передатчика. Обратите внимание, что rtt может варьироваться в зависимости от пути, по которому каждый пакет проходит через сеть, локальных условий в момент коммутации пакета и т. д.
RTO обычно рассчитывается как средневзвешенное значение, при котором более старые временные интервалы оказывают меньшее влияние, чем более поздние измеренные значения.
Альтернативным механизмом, используемым в большинстве реализаций TCP, является быстрая ретрансляция. При быстрой повторной передаче получатель добавляет единицу к ожидаемому порядковому номеру в любом подтверждении. Например, если отправитель передает последовательность 10, получатель подтверждает последовательность 11, даже если он еще не получил последовательность 11. В этом случае порядковый номер в подтверждении подтверждает получение данных и указывает, какой порядковый номер он ожидает от отправителя для передачи в следующий раз.
Если передатчик получает подтверждение с порядковым номером, который на единицу больше последнего подтвержденного порядкового номера три раза подряд, он будет считать, что следующие пакеты были отброшены.
Таким образом, существует два типа потери пакетов в TCP, когда реализован быстрый запуск. Первый-это стандартный тайм-аут, который возникает, когда отправитель передает пакет и не получает подтверждения до истечения срока действия RTO. Это называется отказом RTO. Второй называется быстрым сбоем ретрансляции. Эти два условия часто обрабатываются по-разному.
Как выбирается размер окна?
При выборе размера окна необходимо учитывать ряд различных факторов, но доминирующим фактором часто является получение максимально возможной производительности при одновременном предотвращении перегрузки канала. Фактически, контроль перегрузки TCP, вероятно, является основной формой контроля перегрузки, фактически применяемой в глобальном Интернете. Чтобы понять контроль перегрузки TCP, лучше всего начать с некоторых определений:
Окно приема (RWND): объем данных, которые приемник готов принять; это окно обычно устанавливается на основе размера буфера приемника или какого-либо другого ресурса, доступного в приемнике. Это размер окна, объявленный в заголовке TCP.
Окно перегрузки (CWND): объем данных, которые передатчик готов отправить до получения подтверждения. Это окно не объявляется в заголовке TCP; получатель не знает размер CWND.
Порог медленного запуска (SST): CWND, при котором отправитель считает соединение с максимальной скоростью передачи пакетов без возникновения перегрузки в сети. SST изначально устанавливается реализацией и изменяется в случае потери пакета в зависимости от используемого механизма предотвращения перегрузки.
Большинство реализаций TCP начинают сеансы с алгоритма медленного старта. 16 На этом этапе CWND начинается с 1, 2 или 10. Для каждого сегмента, для которого получено подтверждение, размер CWND увеличивается на 1. Учитывая, что такие подтверждения должны занимать ненамного больше времени, чем один rtt, медленный запуск должен привести к удвоению окна каждого rtt. Окно будет продолжать увеличиваться с этой скоростью до тех пор, пока либо пакет не будет потерян (приемник не сможет подтвердить пакет), CWND не достигнет RWND, либо CWND не достигнет SST. Как только любое из этих трех условий происходит, отправитель переходит в режим предотвращения перегрузки.
Примечание. Каким образом увеличение CWND на 1 для каждого полученного ACL удваивает окно для каждого rtt? Идея состоит в следующем: когда размер окна равен 1, вы должны получать один сегмент на каждый RTT. Когда вы увеличиваете размер окна до 2, вы должны получать 2 сегмента в каждом rtt; на 4, вы должны получить 4 и т. д. Поскольку получатель подтверждает каждый сегмент отдельно и увеличивает окно на 1 каждый раз, когда он подтверждает сегмент, он должен подтвердить 1 сегмент в первом rtt и установить окно на 2; 2 сегмента во втором rtt, добавляя 2 к окну, чтобы установить окно на 4; 4 сегмента в третьем RTT, добавив 4 к окну, чтобы установить размер окна равным 8 и т. д.
В режиме предотвращения перегрузки CWND увеличивается один раз за каждый rtt, что означает, что размер окна перестает расти экспоненциально, а вместо этого увеличивается линейно. CWND будет продолжать расти либо до тех пор, пока получатель не подтвердит получение пакета (TCP предполагает, что это означает, что пакет был потерян или отброшен), либо пока CWND не достигнет RWND. Существует два широко распространенных способа, которыми реализация TCP может реагировать на потерю пакета, называемых Tahoe и Reno.
Примечание. На самом деле существует множество различных вариаций Tahoe и Reno; здесь рассматриваются только самые базовые реализации. Также существует множество различных методов реагирования на потерю пакета, когда соединение находится в режиме предотвращения перегрузки.
Если реализация использует Tahoe, и потеря пакета обнаружена посредством быстрой повторной передачи, она установит SST на половину текущего CWND, установит CWND на исходное значение и снова начнет медленный запуск. Это означает, что отправитель снова будет передавать 1, 2 или 10 порядковых номеров, увеличивая CWND для каждого подтвержденного порядкового номера. Как и в начале процесса медленного запуска, это приводит к удвоению CWND каждого rtt. Как только CWND достигнет SST, TCP вернется в режим предотвращения перегрузки.
Если реализация использует Reno, и потеря пакета обнаружена посредством быстрой повторной передачи, она установит SST и CWND на половину текущего CWND и продолжит работу в режиме предотвращения перегрузки.
В любой реализации, если обнаруживается потеря пакета из-за того, что получатель не отправляет подтверждение в пределах RTO, CWND устанавливается на 1, и медленный запуск используется для увеличения скорости соединения.
Контроль ошибок
TCP предоставляет две формы обнаружения ошибок и управления ими:
Сам протокол, наряду с механизмом управления окнами, обеспечивает доставку данных в приложение по порядку и без какой-либо недостающей информации.
Контрольная сумма дополнения единицы, включенная в заголовок TCP, считается более слабой, чем Cyclic Redundancy Check (CRC) и многие другие формы обнаружения ошибок. Эта проверка ошибок служит дополнением, а не заменой, коррекции ошибок, обеспечиваемой протоколами ниже и выше в стеке.
Если получатель обнаруживает ошибку контрольной суммы, он может использовать любой из описанных здесь механизмов, чтобы запросить отправителя повторно передать данные—просто не подтверждая получение данных, запрашивая повторную передачу через SACK, активно не подтверждая получение данных через быструю повторную передачу или отправляя тройное подтверждение для конкретного сегмента, содержащего поврежденные данные.
Номера портов TCP
TCP не управляет каким-либо типом мультиплексирования напрямую; однако он предоставляет номера портов, которые приложения и протоколы выше TCP в стеке протоколов могут использовать для мультиплексирования. Хотя эти номера портов передаются в TCP, они обычно непрозрачны для TCP; TCP не придает никакого значения этим номерам портов, кроме использования их для отправки информации правильному приложению на принимающем узле.
Номера TCP-портов делятся на два широких класса: хорошо известные и эфемерные. Хорошо известные порты определяются как часть спецификации протокола верхнего уровня; эти порты являются портами «по умолчанию» для этих приложений. Например, службу, поддерживающую Simple Mail Transfer Protocol (SMTP), обычно можно найти, подключившись к узлу с использованием TCP на порт номер 25. Службу, поддерживающую Hypertext Transport Protocol (HTTP), обычно можно найти, подключившись к узлу с использованием TCP на порт 80. Эти службы не обязательно должны использовать эти номера портов; большинство серверов можно настроить на использование какого-либо номера порта, отличного от указанного в спецификации протокола. Например, веб-серверы, не предназначенные для общего (или общедоступного) использования, могут использовать какой-либо другой TCP-порт, например 8080.
Эфемерные порты значимы только для локального хоста и обычно назначаются из пула доступных номеров портов на локальном хосте. Эфемерные порты чаще всего используются в качестве исходных портов для TCP-соединений; например, хост, подключающийся к службе через порт 80 на сервере, будет использовать эфемерный порт в качестве исходного TCP-порта. До тех пор, пока любой конкретный хост использует данный эфемерный номер порта только один раз для любого TCP-соединения, каждый сеанс TCP в любой сети может быть однозначно идентифицирован через исходный адрес, исходный порт, адрес назначения, порт назначения и номер протокола, работающего поверх TCP.
Настройка сеанса TCP
TCP использует трехстороннее рукопожатие для установки сеанса:
Клиент отправляет синхронизацию (SYN) на сервер. Этот пакет является обычным TCP-пакетом, но с битом SYN, установленным в заголовке TCP, и указывает, что отправитель запрашивает сеанс для настройки с получателем. Этот пакет обычно отправляется на хорошо известный номер порта или на какой-то заранее установленный номер порта, который, как известно клиенту, будет прослушиваться сервером по определенному IP-адресу. Этот пакет включает в себя начальный порядковый номер клиента.
Сервер отправляет подтверждение для SYN, SYN-ACK. Этот пакет подтверждает порядковый номер, предоставленный клиентом, плюс один, и включает начальный порядковый номер сервера в качестве порядкового номера для этого пакета.
Клиент отправляет подтверждение (ACK), включающее начальный порядковый номер сервера плюс один.
Этот процесс используется для обеспечения двусторонней связи между клиентом и сервером перед началом передачи данных. Первоначальный порядковый номер, выбранный отправителем и получателем, в большинстве реализаций рандомизирован, чтобы не дать стороннему злоумышленнику угадать, какой порядковый номер будет использоваться, и захватить сеанс TCP на начальных этапах его формирования.
Многоуровневый коммутатор будет использовать информацию из таблиц, которые созданы (плоскость управления) для построения аппаратных таблиц. Он будет использовать таблицу маршрутизации для построения FIB (информационной базы пересылки) и таблицу ARP для построения таблицы смежности. Это самый быстрый способ переключения, потому что теперь у нас есть вся информация уровня 2 и 3, необходимая для пересылки аппаратных пакетов IP.
Давайте посмотрим на информационную таблицу о пересылке и таблицу смежности на некоторых маршрутизаторах.
Будем использовать ту же топологию, что и ранее. 3 роутера и R3 имеет интерфейс loopback0. Будем использовать статические маршруты для полного подключения:
R1(config)#ip route 3.3.3.0 255.255.255.0 192.168.23.3
R1(config)#ip route 192.168.23.0 255.255.255.0 192.168.12.2
R2(config)#ip route 3.3.3.0 255.255.255.0 192.168.23.3
R3(config)#ip route 192.168.12.0 255.255.255.0 192.168.23.2
Это статические маршруты, которые мы будем использовать. Теперь посмотрим на таблицу маршрутизации и FIB:
show ip cef показывает нам таблицу FIB. Вы можете видеть, что есть довольно много вещей в таблице FIB. Ниже даны разъяснения по некоторым из записей:
0.0.0.0/0 - это для интерфейса null0. Когда мы получим IP-пакеты, соответствующие этому правилу, то оно будет отброшено.
0.0.0.0 /32 - это для всех-нулевых передач. Забудьте об этом, так как мы больше не используем его.
3.3.3.0 /24 - это запись для интерфейса loopback0 R3. Обратите внимание, что следующий переход - это 192.168.12.2, а не 192.168.23.3, как в таблице маршрутизации!
192.168.12.0/24 - это наша непосредственно подключенная сеть.
192.168.12.0/32 зарезервировано для точного сетевого адреса.
192.168.12.1/32 - это IP-адрес на интерфейсе FastEthernet 0/0.
192.168.12.2/32 - это IP-адрес на интерфейсе FastEthernet 0/0 R2.
192.168.12.255/32 - это широковещательный адрес для сети 192.168.12.0/24.
224.0.0.0/4 - соответствует всему многоадресному трафику. Он будет удален, если поддержка многоадресной рассылки отключена глобально.
224.0.0.0/24 - соответствует всему многоадресному трафику, зарезервированному для трафика управления локальной сетью (например, OSPF, EIGRP).
255.255.255.255/32 - широковещательный адрес для подсети.
Давайте подробно рассмотрим запись для network 3.3.3.0/24:
Номер версии говорит нам, как часто эта запись CEF обновлялась с момента создания таблицы. Мы видим, что для достижения 3.3.3.0/24 нам нужно перейти к 192.168.23.3 и что требуется рекурсивный поиск. Следующий прыжок-192.168.12.2. Он также говорит, что это valid cached adjacency (допустимая кэшированная смежность). Существует целый ряд различных смежностей:
Null adjacency: используется для отправки пакетов в интерфейс null0.
Drop adjacency: это для пакетов, которые не могут быть переданы из-за ошибок инкапсуляции, маршрутов, которые не могут быть разрешены, или протоколов, которые не поддерживаются.
Discard adjacency: это относится к пакетам, которые должны быть отброшены из-за списка доступа или другой политики.
Punt adjacency: используется для пакетов, которые отправляются на плоскость управления для обработки.
Пакеты, которые не пересылаются CEF, обрабатываются процессором. Если у вас есть много таких пакетов, то вы можете увидеть проблемы с производительностью.
Вы можете видеть, сколько пакетов было обработано процессором:
Вы можете использовать команду show cef not-cef-switched, чтобы проверить это. Количество пакетов указано по причине:
No_adj: смежность не является полной..
No_encap: Информация об ARP является неполной.
Unsupp’ted: пакет имеет функции, которые не поддерживаются.
Redirect: Перенаправление ICMP.
Receive: Это пакеты, предназначенные для IP-адреса, настроенного на интерфейсе уровня 3, пакеты, предназначенные для нашего маршрутизатора.
Options: В заголовке пакета есть параметры IP-адреса.
Access: ошибка сравнения со списком доступа
Frag: ошибка фрагментации пакетов
Мы также можем взглянуть на таблицу смежности, в которой хранится информация уровня 2 для каждой записи:
Вы можете использовать команду show adjacency summary, чтобы быстро посмотреть, сколько у нас есть смежностей. Смежность - это отображение от уровня 2 до уровня 3 и происходит из таблицы ARP.
R1#show adjacency
Protocol Interface Address
IP FastEthernet0/0 192.168.12.2(9)
R1 имеет только один интерфейс, который подключен к R2. Вы можете увидеть запись для ip 192.168.12.2, который является интерфейсом FastEthernet 0/0 R2. Давайте увеличим масштаб этой записи:
Мы видим там запись для 192.168.12.2 и там написано:
CC011D800000CC001D8000000800
Что означает это число? Это MAC-адреса, которые нам нужны, и Ethertype ... давайте разберем поподробнее его:
CC011D800000 - это MAC-адрес интерфейса R2 FastEthernet0 / 0
CC001D800000 - это MAC-адрес интерфейса R1 FastEthernet0/0.
0800 - это Ethertype. 0x800 означает IPv4.
Благодаря таблицам FIB и смежности у нас есть вся информация уровня 2 и 3, которая нам требуется для перезаписи и пересылки пакетов. Имейте в виду, что перед фактической пересылкой пакета мы сначала должны переписать информацию заголовка:
Исходный MAC-адрес.
Конечный MAC-адрес.
Контрольная сумма кадров Ethernet.
TTL IP-пакета.
Контрольная сумма IP-пакетов.
Как только это будет сделано, мы сможем переслать пакет. Теперь у вас есть представление о том, что такое CEF и как обрабатываются пакеты.
Возникает вопрос, а в чем разница между маршрутизаторами и коммутаторами, поскольку многоуровневый коммутатор может маршрутизировать, а маршрутизатор может выполнять коммутацию.
Различие между устройствамистанвится все меньше, но коммутаторы обычно используют только Ethernet. Если вы покупаете Cisco Catalyst 3560 или 3750, то у вас будут только интерфейсы Ethernet. У них есть ASICs, поэтому коммутация кадров может выполняться со скоростью линии связи. С другой стороны, маршрутизаторы имеют другие интерфейсы, такие как последовательные каналы связи, беспроводные сети, и они могут быть модернизированы модулями для VPN, VoIP и т. д. Вы не сможете настроить такие вещи, как NAT/PAT на (маленьком) коммутаторе. Однако грань между ними становится все тоньше
Маршрутизаторы используются для маршрутизации, коммутаторы уровня 2-для коммутации, но многоуровневые коммутаторы могут выполнять комбинацию того и другого. Возможно, ваш коммутатор выполняет 80% коммутации и 20% маршрутизации или наоборот. TCAM можно "запрограммировать" на использование оптимальных ресурсов с помощью шаблонов SDM.
SDM (Switching Database Manager) используется на коммутаторах Cisco Catalyst для управления использованием памяти TCAM. Например, коммутатор, который используется только для коммутации, не требует никакой памяти для хранения информации о маршрутизации IPv4. С другой стороны, коммутатору, который используется только в качестве маршрутизатора, не потребуется много памяти для хранения MAC-адресов.
SDM предлагает ряд шаблонов, которые мы можем использовать на нашем коммутаторе, вот пример коммутатора Cisco Catalyst 3560:
Выше вы можете видеть, что текущий шаблон является "desktop default", и вы можете видеть, сколько памяти он резервирует для различных элементов. Вот пример других шаблонов:
Вот шаблоны SDM для коммутатора. Мы можем изменить шаблон с помощью команды sdm prefer:
Вы должны перезагрузить устройство прежде, чем он вступит в силу:
SW1#reload
Теперь давайте еще раз проверим шаблон:
По сравнению с шаблоном "desktop default" мы теперь имеем двойное хранилище для одноадресных MAC-адресов. Однако для маршрутов IPv4 ничего не зарезервировано.
Это хорошая идея, чтобы установить шаблон SDM, для того чтобы соответствовать необходимому использованию вашего коммутатора. Если вы делаете как коммутацию, так и маршрутизацию и не уверены в том, какой шаблон выбрать, то вы можете посмотреть на текущее использование TCAM, вот как это сделать:
На данном рисунке многое не отображено, но вы можете видеть, как заполняется TCAM в данный момент. Теперь вам есть что сравнить с шаблонами SDM.