По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
В небольших сетевых устройствах с одним сетевым процессом (ASIC или NPU) переместить пакет из входной очереди в выходную просто. Оба интерфейса ввода и вывода используют общий пул памяти пакетов, поэтому указатель на пакет может быть перемещен из одной очереди в другую. Для достижения большего количества портов и более крупных устройств - особенно устройств шасси - должна быть внутренняя шина или матрица, которая соединяет механизмы обработки входных и выходных пакетов. Одним из распространенных типов структуры, используемой для соединения механизмов обработки пакетов в сетевом устройстве, является структура матрицы; Рисунок ниже иллюстрирует это. Размер и структура полотна матрицы зависят от количества подключенных портов. Если в коммутаторе больше портов, чем возможно для подключения через одну матрицу кросс-панелей, то коммутатор будет использовать несколько структур кросс-панелей. Распространенной топологией для такого типа полотна является многоступенчатая закрытая структура, соединяющая входную и выходную полотна матрицы вместе. Вы можете думать об этом как о матрице из матриц. Для работы матрицы требуется чувство времени (или, скорее, фиксированный временной интервал) и планировщик. В каждый интервал времени один порт вывода (отправки) соединяется с одним портом ввода (приема), так что в течение этого периода времени отправитель может передать пакет, кадр или набор пакетов получателю. Планировщик "соединяет" правильные точки пересечения на матрице, чтобы передачи происходили в нужный период времени. Например: Line card 1 (LC1) хочет отправить пакет в LC3. LC3 хочет отправить пакет в LC5. В течение следующего временного цикла планировщик может подключить строку A к столбцу 1 ("установить" соединение в A3) и подключить строку C к столбцу 5 ("установить" соединение в C5), чтобы между этими парами был установлен канал связи. Пересечения и конфликты Что произойдет, если два передатчика захотят отправить пакет одному получателю? Например, если в течение одного периода времени и LC1, и LC2 хотят отправить пакет в LC9 через полотно перекрестной матрицы? Это называется конфликтом, и это ситуация, которую должен обрабатывать планировщик структуры. Какому из двух входных портов должно быть разрешено отправлять свой трафик на выходной порт? А где же тем временем должны находится очереди входящего трафика? Один из вариантов - хранить пакеты во входной очереди; коммутаторы, использующие эту технику, называются коммутаторами с очередью ввода (input-queued switches). Такие коммутаторы испытывают head-of-line (HOL). Блокировка HOL - это то, что происходит, когда пакет в начале линии, ожидающий пересылки через структуру, блокирует другие пакеты, стоящие в очереди за ним. Другой вариант - использовать в коммутаторе несколько виртуальных очередей вывода (virtual output queues- VOQ) для каждого порта ввода. VOQ дают матрице перекрестной сети несколько мест для хранения входящих пакетов, пока они ожидают доставки на свои выходные порты. Во многих конструкциях коммутаторов один VOQ существует на каждый выходной порт, для которого предназначен входной трафик. Следовательно, входной порт может иметь несколько пакетов в очереди в нескольких разных VOQ, предполагая, что несколько разных выходных портов. Каждый из этих VOQ может обслуживаться в течение одного тактового цикла. Это означает, что блокировка HOL устраняется, потому что несколько разных пакетов из одной входной очереди могут проходить через матрицу кроссбара одновременно. Для порта ввода существует не одна очередь, а несколько разных очередей. Даже с VOQ остается потенциальная возможность разногласий по структуре перекрестной сети. Наиболее распространенный пример - это когда два или более входящих пакета должны покинуть коммутатор через один и тот же выходной порт в одно и то же время, или, точнее, в одном тактовом цикле. Выходной порт может отправлять только один пакет за такт. Определение того, какая входная очередь будет доставлять трафик на выходной порт первой, - это алгоритм, определяемый производителем коммутатора для максимального использования аппаратного обеспечения. iSLIP-это один из алгоритмов планирования, используемых коммутаторами для решения этой проблемы. Обзор алгоритма iSLIP Алгоритм iSLIP разрешает конфликты межсетевых экранов, распределяя трафик таким образом, чтобы сетевое устройство достигало неблокирующей пропускной способности. Для понимания этого полезно внимательно изучить iSLIP в его простейшей форме, проанализировав, что происходит, когда алгоритм iSLIP выполняется один раз. Во время выполнения iSLIP происходят три важных события: Запрос. Все входные точки (вход) на перекрестной матрице с поставленным в очередь трафиком спрашивают свои выходные точки (выход), могут ли они отправить. Предоставление (грант). Каждая точка вывода, получившая запрос, должна определять, какая точка ввода будет разрешена для отправки. Если есть один запрос, то грант предоставляется без дальнейшего обсуждения. Однако при наличии нескольких запросов точка вывода должна определять, какая точка ввода может отправлять. Это делается через циклического перебора, где одному запросу предоставляется грант, последующему запросу предоставляется грант во время следующего выполнения iSLIP, и так далее по кругу. Когда было принято решение об этом конкретном выполнении iSLIP, каждая точка вывода отправляет свое сообщение о предоставлении, эффективно сигнализируя о разрешении на отправку, в соответствующую точку ввода. Принятие. Входная точка рассматривает сообщения о предоставлении гранта, полученные ею от выходных точек, выбирая грант циклическим способом. После выбора входной сигнал уведомляет выходной сигнал о том, что грант принят. Если и только, если выходная точка уведомлена о том, что грант был принят, выходная точка перейдет к следующему запросу. Если сообщение accept не получено, то точка вывода попытается обслужить предыдущий запрос во время следующего выполнения iSLIP. Понимание процессов запроса, предоставления и принятия дает нам представление о том, как пакеты могут быть доставлены одновременно через матрицу кроссбара без конфликтов. Однако, если вы поразмыслите над сложным набором входов, VOQ и выходов, вы можете понять, что один запуск iSLIP не планирует доставки столько пакетов, сколько могло бы быть после одного выполнения. Понимание процессов запроса, предоставления и принятия дает нам представление о том, как пакеты могут быть доставлены одновременно через матрицу кроссбара без конфликтов. Однако, если вы поразмыслите над сложным набором входов, VOQ и выходов, вы поймете, что один запуск iSLIP не планирует доставки столько пакетов, сколько могло бы быть после одного выполнения. Конечно, некоторые входы были предоставлены выходам, и некоторые пакеты могут быть переадресованы, но возможно, что некоторые выходы никогда не были согласованы с ожидающим входом. Другими словами, если вы ограничите iSLIP одним исполнением за такт, мы оставим доступную выходную полосу пропускания неиспользуемой. Поэтому обычной практикой является запуск iSLIP через несколько итераций. В результате количество совпадений ввода-вывода максимально. За один раз через матрицу кроссбара может быть отправлено больше пакетов. Сколько раз нужно запускать iSLIP, чтобы максимально увеличить количество пакетов, которые можно коммутировать через матрицу кроссбара за такт? Исследования показывают, что для шаблонов трафика, преобладающих в большинстве сетей, запуск iSLIP четыре раза лучше всего сопоставляет входные и выходные данные в матрице. Выполнение iSLIP более четырех раз не приводит к значительному увеличению количества совпадений. Другими словами, запуск iSLIP пять, шесть или десять раз в большинстве сетевых сред ничего не даст. Выход за рамки iSLIP Это обсуждение до сих пор предполагало, что движение, протекающее через матрицу, имеет одинаковое значение. Однако в современных центрах обработки данных одни классы трафика имеют приоритет над другими. Например, фреймы хранилища Fibre Channel over Ethernet (FCoE) должны проходить через матрицу без потерь, в то время как сеанс TCP, попадающий в класс QoS, этого не делает. Обрабатывает ли iSLIP трафик с разными приоритетами, отдавая одни запросы раньше других? Да, но в модифицированной форме алгоритма, который мы рассмотрели. Варианты iSLIP включают Приоритетный, Пороговый и Взвешенный iSLIP. Помимо iSLIP, который здесь используется просто как удобный пример управления конфликтами, поставщики будут писать свои собственные алгоритмы, соответствующие аппаратным возможностям своей собственной коммутационной матрицы. Например, в этом разделе рассматривается только матрица перекрестных линий с входящей очередью, но многие структуры перекрестных линий предлагают также организацию очереди вывода на выходной стороне матрицы.
img
Механизм передачи данных или информации между двумя связанными устройствами, соединенными по сети, называется режимом передачи. Режим передачи также называется режимом связи. Он указывает направление потока сигнала между двумя связанными устройствами. Шины и сети предназначены для обеспечения связи между отдельными устройствами, связанными по сети. Категории режимов транзакций Существует три категории режимов передачи: симплексный режим полудуплексный режим полнодуплексный режим Симплексный режим В этом типе режима передачи связь является однонаправленной, то есть данные могут передаваться только в одном направлении. Это означает, что вы не можете отправить сообщение обратно отправителю, как на улице с односторонним движением. Из этих двух устройств только одно может отправлять или передавать по каналу связи, а другое-только принимать данные. Пример: Симплексную дуплексную передачу можно увидеть между компьютером и клавиатурой. Телевизионное вещание, телевидение и пульт дистанционного управления также являются примерами симплексной дуплексной передачи. Другой пример симплексной передачи включает в себя акустическую систему. Диктор говорит в микрофон, и голос передается через усилитель, а затем на динамики. Преимущество Симплексного режима В этом режиме станция может использовать всю пропускную способность канала связи, поэтому одновременно может передаваться больше данных. Недостаток Симплексного режима В основном коммуникации требуют двустороннего обмена данными, но это однонаправленный обмен, поэтому здесь нет связи между устройствами. Полудуплексный Режим В полудуплексном режиме каждая станция может также передавать и принимать данные. Поток сообщений может идти в обоих направлениях, но не одновременно. Вся пропускная способность канала связи используется в одном направлении за один раз. В полудуплексном режиме отправитель отправляет данные и ожидает их подтверждения, а если есть какая-либо ошибка, то получатель может потребовать от него повторной передачи этих данных. Благодаря этому возможно обнаружение ошибок. Примером полудуплексного режима является рация. В рации с одной стороны говорят в микрофон устройства, а с другой-кто-то слушает. После паузы другой говорит, и первое лицо слушает. Пример: Это как однополосная дорога с двунаправленным движением. Пока машины едут в одном направлении, машины, идущие в другую сторону, должны ждать. Преимущество Полудуплексного режима В полудуплексном режиме вся пропускная способность канала берется на себя любым из двух устройств, передающих одновременно. Недостаток Полудуплексного режима Это вызывает задержку в отправке данных в нужное время, так как когда одно устройство отправляет данные, то другое должно ждать отправки данных. Полный Дуплексный Режим В полнодуплексном режиме связь является двунаправленной, то есть поток данных идет в обоих направлениях одновременно. С обоих концов прием и передача данных возможны одновременно. Полнодуплексный режим имеет два физически отдельных пути передачи, один из которых предназначен для движения трафика в одном направлении, а другой-для движения трафика в противоположном направлении. Это один из самых быстрых способов связи между устройствами. Пример: По телефонной линии два человека общаются друг с другом, оба могут говорить и слушать друг друга одновременно, это полнодуплексная передача. Другой пример - улица с двусторонним движением, движение по которой осуществляется одновременно в обоих направлениях. Преимущество Полнодуплексного режима Обе станции могут отправлять и получать данные одновременно, поэтому емкость канала может быть разделена. Недостаток Полнодуплексного режима Полоса пропускания канала связи делится на две части, если между устройствами нет выделенного пути.
img
Теперь мы можем продолжить поиск и устранение неисправностей. В большинстве случаев вы ожидаете увидеть определенную сеть в таблице маршрутизации, но ее там нет. Далее рассмотрим несколько сценариев неправильной (или полностью не рабочей) работы EIGRP и как исправить наиболее распространенные ошибки. Ниже перечислены часто встречающиеся ошибки: Первую часть статьи про траблшутинг EIGRP можно почитать здесь. Кто-то настроил distribute-list, чтобы информация о маршрутах фильтровалась. Было настроено автосуммирование или кто-то настроил суммирование вручную Split-horizon блокирует объявление маршрутной информации. Перераспределение было настроено, но информация из EIGRP не используется. Перераспределение было настроено, но никакие внешние маршруты EIGRP не отображаются. Case #1 Давайте начнем с простой топологии. OFF1 и OFF2 работают под управлением EIGRP, и каждый маршрутизатор имеет интерфейс обратной связи. Вот конфигурация обоих маршрутизаторов: OFF1(config)#router eigrp 12 OFF1(config-router)#no auto-summary OFF1(config-router)#network 1.1.1.0 0.0.0.255 OFF1(config-router)#network 192.168.12.0 0.0.0.255 OFF2(config)#router eigrp 12 OFF2(config-router)#no auto-summary OFF2(config-router)#network 2.2.2.0 0.0.0.255 OFF2(config-router)#network 192.168.12.0 0.0.0.255 Все работает нормально, пока через пару недель один из пользователей не пожаловался на то, что ему не удалось подключиться к сети 2.2.2.0 / 24 из-за OFF1. Посмотрите на таблицу маршрутизации на OFF1, и вот что вы видите: По какой-то причине нет сети 2.2.2.0 / 24 в таблице маршрутизации. Видно, что на OFF1 не настроен distribute lists. OFF2 содержит сеть 1.1.1.0 / 24 в своей таблице маршрутизации. Давайте выполним быструю отладку, чтобы увидеть, что происходит. Отладка показывает нам, что происходит. Прежде чем вы увидите это сообщение, придется немного подождать, или вы можете сбросить соседство EIGRP, чтобы ускорить процесс. Как видите, в сети 2.2.2.0 / 24 отказано из-за distribute list. Другой быстрый способ проверить это - использовать команду show ip protocol. В этом случае использование show run могло бы быстрее обнаружить distribute-list. Вот список доступа, доставляющий нам неприятности. OFF2(config)#router eigrp 12 OFF2(config-router)#no distribute-list 1 out Удалим distribute-list. Задача решена! Извлеченный урок: если команды network верны, проверьте, есть ли у вас distribute-list, который запрещает объявлять префиксы или устанавливать их в таблицу маршрутизации. Имейте в виду, distribute-list могут быть настроены как входящие или исходящие, как список доступа. Case #2 В следующем сценарии те же 2 маршрутизатора, но разные сети в loopback. Вот конфигурация: OFF1(config)#router eigrp 12 OFF1(config-router)#network 192.168.12.0 OFF1(config-router)#network 10.0.0.0 OFF2(config)#router eigrp 12 OFF2(config-router)#network 192.168.12.0 OFF2(config-router)#network 10.0.0.0 Как вы видите - это довольно базовая конфигурация. Глядя на таблицы маршрутизации, не видно сети 10.1.1.0 / 24 или 10.2.2.0 / 24. Видна запись для сети 10.0.0.0/8, указывающую на интерфейс null0. Эта запись отображается только при настройке суммирования и используется для предотвращения циклов маршрутизации. Давайте включим отладку и посмотрим, что мы можем найти. OFF2#clear ip eigrp 12 neighbors Этой командой мы сделаем сброс соседства EIGRP, чтобы ускорить процесс. Имейте в виду, что это, вероятно, не самое лучшее, что можно сделать в производственной сети, пока вы не узнаете, что не так, но это действительно помогает ускорить процесс. Вот наш ответ. Отладка говорит нам, что сеть 10.2.2.0 / 24 не следует объявлять, а сеть 10.0.0.0 / 8 нужно объявлять (это вкратце). Это может произойти по двум причинам: Суммирование было кем-то настроено Авто-суммирование включено для EIGRP. Как вы видите, авто-суммирование включено для EIGRP. В зависимости от версии IOS авто-суммирование включено или отключено по умолчанию. OFF1(config)#router eigrp 12 OFF1(config-router)#no auto-summary OFF2(config)#router eigrp 12 OFF2(config-router)#no auto-summary Отключение автоматического суммирования должно помочь. Ну что, наши сети появились в таблице маршрутизации. Извлеченный урок: если включена автоматическое суммирование EIGRP, вы можете столкнуться с нестабильными сетями. Case #3 Очередная проблема. В приведенном выше примере у нас есть 2 маршрутизатора, но разные сети. OFF1 содержит сеть 172.16.1.0 / 24 на интерфейсе обратной связи, а OFF2 содержит сеть 172.16.2.0 / 24 и 172.16.22.0 / 24 на своих интерфейсах обратной связи. Посмотрим конфигурацию EIGRP обоих маршрутизаторов: Как вы видите, что все сети объявляются. Обратите внимание, что в OFF1 включено автоматическое суммирование, а в OFF2 отключено автоматическое суммирование. Кто-то настроил суммирование на OFF2 и отправляет ее на OFF1. Суммирование создана для сети 172.16.0.0 / 16. Однако, если посмотреть на таблицу маршрутизации OFF1, она не появится. Мы видим запись для сети 172.16.0.0 / 16, но она указывает на интерфейс null0, а не на OFF2. Что здесь происходит? OFF2#clear ip eigrp 12 neighbors Давайте сделаем отладку на OFF2, чтобы увидеть, объявляется ли суммирование. Выполним команду clear ip eigrp neighbors, просто чтобы ускорить процесс. Глядя на отладку, видно, что OFF2 работает правильно. Он объявляет сводный маршрут 172.16.0.0 / 16 так, как должен. Это означает, что проблема должна быть в OFF1. Давайте проведем отладку OFF1. Мы можем видеть, что OFF1 получает сводный маршрут от OFF2, но решает не использовать его. Это хороший момент для проверки таблицы топологии EIGRP. Вы видите, что он имеет суммирование сети 172.16.0.0 / 16 от OFF2 в своей таблице топологии EIGRP, но OFF1 решает не использовать ее, потому что вход через интерфейс null0 является лучшим путем. OFF1(config)#router eigrp 12 OFF1(config-router)#no auto-summary Решение состоит в том, что нам нужно избавиться от записи null0 в таблице маршрутизации. Единственный способ сделать это - отключить автоматическое суммирование. Отключение автоматического суммирования удаляет запись null0, и теперь суммирование OFF2 установлено проблема решена! Извлеченный урок: автоматическое суммирование EIGRP создает запись через интерфейс null0, которая может помешать установке суммирования, которые вы получаете от соседних маршрутизаторов. Case #4 Есть еще одна проблема с суммированием, которую сейчас и разберем. Мы используем топологию, которую вы видите выше, и ниже конфигурация EIGRP обоих маршрутизаторов. Все сети объявлены, и автоматическое суммирование отключено на обоих маршрутизаторах. Суммирование было настроено на OFF2 и должно быть объявлено к OFF1. К сожалению, ничего не видно на OFF1. Давайте проверим OFF2, чтобы посмотреть, что не так. Когда дело доходит до устранения неполадок с сетью, вашими друзьями являются не Google или Яндекс, а команды Debug и show. Странно, это единственная сеть, которую OFF2 объявляет. Одно из золотых правил маршрутизации: вы не можете объявлять то, чего у вас нет. Очевидно, OFF2 знает только о сети 192.168.12.0 / 24. Вот это ошибка! Кто-то выполнил команду отключения на интерфейсах обратной связи. OFF2(config)#interface loopback 0 OFF2(config-if)#no shutdown OFF2(config)#interface loopback 1 OFF2(config-if)#no shutdown Включим интерфейсы. Теперь мы видим, что суммирование объявляется. Теперь мы видим суммирование в таблице маршрутизации OFF1- проблема решена! Извлеченный урок: вы не можете объявлять то, чего у вас нет в таблице маршрутизации. ВАЖНО. Последняя проблема может быть показаться простой, но есть важный момент, который вы не должны забывать: для объявления итогового маршрута в таблице маршрутизации объявляемого маршрутизатора должен быть указан хотя бы один префикс, попадающий в итоговый диапазон! Case #5 Давайте посмотрим на другую топологию. На рисунке выше у нас есть концентратор Frame Relay и соответствующая топология. Каждый из OFF1 и OFF2 имеет интерфейс обратной связи, который мы будем объявлять в EIGRP. Вот соответствующая конфигурация всех маршрутизаторов: CONC(config)#router eigrp 123 CONC(config-router)#no auto-summary CONC(config-router)#network 192.168.123.0 OFF1(config-if)#router eigrp 123 OFF1(config-router)#no auto-summary OFF1(config-router)#network 192.168.123.0 OFF1(config-router)#network 2.2.2.0 0.0.0.255 OFF2(config)#router eigrp 123 OFF2(config-router)#no auto-summary OFF2(config-router)#network 192.168.123.0 OFF2(config-router)#network 3.3.3.0 0.0.0.255 Видно, что все сети объявлены. Наш концентратор-маршрутизатор видит сети из двух OFF-маршрутизаторов. К сожалению, наши маршрутизаторы не видят ничего ... Похоже, что маршрутизатор-концентратор не объявляет сети, которые он изучает с помощью OFF-маршрутизаторов. Давайте включим отладку, чтобы увидеть, что происходит. CONC#clear ip eigrp 123 neighbors Сбросим соседство EIGRP, чтобы ускорить процесс. В отладке мы видим, что наш маршрутизатор-концентратор узнает о сети 2.2.2.0 / 24 и 3.3.3.0 / 24, но объявляет только сеть 192.168.123.0 / 24 для OFF-маршрутизаторов. Разделение горизонта не позволяет размещать объявление от одного маршрутизатора на другой. CONC(config)#interface serial 0/0 CONC(config-if)#no ip split-horizon eigrp 123 Давайте отключим разделение горизонта на последовательном интерфейсе маршрутизатора-концентратора. Теперь мы видим, что маршрутизатор-концентратор объявляет все сети. OFF-маршрутизаторы теперь могут узнавать о сетях друг друга, поскольку split horizon отключено. Это хорошо, но это еще не все. Извлеченный урок: RIP и EIGRP являются протоколами маршрутизации на расстоянии и используют split horizon. Split horizon предотвращает объявление префикса вне интерфейса, на котором мы его узнали. Хотя сети отображаются в таблицах маршрутизации мы не можем пропинговать от одного OFF-маршрутизатора к другому. Это не проблема EIGRP, но она связана с Frame Relay. Мы должны это исправить. Когда OFF1 отправляет IP-пакет на OFF2, IP-пакет выглядит следующим образом: Давайте пока подумаем, как роутер, и посмотрим, что здесь происходит. Сначала нам нужно проверить, знает ли OFF1, куда отправить 3.3.3.3: Существует запись для 3.3.3.3, а IP-адрес следующего перехода - 192.168.123.1 (маршрутизатор-концентратор). Можем ли мы достичь 192.168.123.1? Нет проблем, кажется, OFF1 может пересылать пакеты, предназначенные для сети 3.3.3.0/24. Давайте перейдем к маршрутизатору CONC. У маршрутизатора-концентратора нет проблем с отправкой трафика в сеть 3.3.3.0 / 24, поэтому на данный момент мы можем сделать вывод, что проблема должна быть в маршрутизаторе OFF2. Это IP-пакет, который получает маршрутизатор OFF2, и когда он отвечает, он создает новый IP-пакет, который выглядит следующим образом: Способен ли OFF2 достигать IP-адрес 192.168.123.2 Давайте узнаем! Теперь мы знаем проблему ... OFF2 не может достичь IP-адреса 192.168.123.2 Если мы посмотрим на таблицу маршрутизации OFF2, то увидим, что сеть 192.168.123.0 / 24 подключена напрямую. С точки зрения третьего уровня у нас нет никаких проблем. Пришло время перейти вниз по модели OSI и проверить уровень 2 ... или, может быть, между уровнем 2 и 3. Frame Relay использует Inverse ARP для привязки уровня 2 (DLCI) к уровню 3 (IP-адрес). Вы можете видеть, что нет сопоставления для IP-адреса 192.168.123.2. OFF2(config)#int s0/0 OFF2(config-if)#frame-relay map ip 192.168.123.2 301 Давайте frame-relay map сами. Теперь роутер OFF2 знает, как связаться с роутером OFF1 Наконец, маршрутизатор OFF1 может пропинговать интерфейс обратной связи маршрутизатора OFF2. Когда мы пытаемся пропинговать от маршрутизатора OFF2 к интерфейсу обратной связи маршрутизатора OFF1, у нас возникает та же проблема, поэтому мы также добавим туда оператор frame-relay map: OFF1(config)#int s0/0 OFF1(config-if)#frame-relay map ip 192.168.123.3 201 Теперь у нас есть extra frame-relay map на маршрутизаторе OFF1. И наш пинг проходит!
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59