Транзитные пакеты
Last updated
Last updated
Пусть мы имеем дело со стандартным Ethernet/IP-пакетом. Узел — IP-маршрутизатор. Пакет следует транзитом из L3-порта А в L3-порт Б.
Оптический сигнал приходит в порт. Здесь он преобразуется в электрические импульсы.
Импульсы попадают на PIC, где восстанавливает из них поток битов. Поток битов модуль Ethernet разбивает на отдельные Ethernet-кадры. В этом ему помогает преамбула, которая тут же за ненадобностью отбрасывается. По ходу дела Ethernet вычисляет контрольную сумму кадра. А потом сравнивает с хвостовым заголовком FCS. Если совпало, пакет без FCS передаётся дальше. Если нет — тут же отбрасывается, а счётчик ошибок на интерфейсе увеличивается на 1. Здесь же на PIC вычисляется статистика трафика: количество, объём, скорость с разбивкой на Unicast, Broadcast, Multicast.
Далее этот Ethernet кадр ещё со всем заголовками отправляется на FE.
FE извлекает из заголовка, обращается в CAM и ищет, есть ли там такая запись. Она находится и CAM сообщает адрес в RAM. Поскольку Ethernet терминируется на маршрутизаторе, данный DMAC — это MAC-адрес самого узла. Поэтому запись в RAM сообщает, что порт назначения — сам этот маршрутизатор и нужно передать Payload модулю IP (об этом говорит анализ поля EtherType в заголовке).
Далее FE отделяет заголовок IP от нагрузки (Payload). Нагрузка будет томиться в буфере, а заголовок разорвут и растащут по полям для анализа. Какие же данные из заголовка понадобятся?
Адрес назначения (IP в нашем случае, но может быть MAC, MPLS-метка итд.)
Приоритет (DSCP, IEEE802.1p, EXP итд.)
Значение TTL.
Возможно понадобятся и другие поля, такие как адрес источника, информация о вложенных данных (протокол, порт, приложение).
Далее, пока пакет греется во внутричиповом буфере, происходит обработка изученных данных.
Проверка по ACL — можно ли вообще передавать этот трафик.
Ingress FE здесь обращается к TCAM с просьбой найти маршрут, соответствующий данному IP-адресу. Тот находит и передаёт адрес ячейки в RAM.
FE от RAM получает Egress FE, выходной интерфейс и NextHop.
В большинстве случаев Ingress FE выясняет на этом шаге MAC-адрес Next-Hop'а из таблицы соседей (Adjacenies Tables).
Если адрес назначения локальный то или парсится следующий заголовок (как это и было выше с Ethernet), или принимаются какие-то меры аппаратные (BFD, например) или пакет передаётся на CPU (BGP, OSFP итд.)
Преобразование приоритета из заголовков пакета во внутреннюю CoS-метку, в соответствии с которой пакет будет обрабатываться в пределах данного узла. Может навешиваться приоритет обработки в очередях и приоритет отбрасывания пакета.
Всё это станет метаданными и будет помещено во временный заголовок, сопровождающий пакет до Egress FE:
Egress FE
Выходной интерфейс
Приоритет
TTL
Next Hop (MAC-адрес)
Egress FE нужен для того, чтобы доставить пакет до нужного чипа коммутации; выходной интерфейс — чтобы сообщить ему, куда пакет передать; приоритет — говорит, как с трафиком поступать в пределах устройства и, возможно, что записать в заголовок пакета (DSCP); TTL — тоже понадобится для того, чтобы потом его вписать в заголовок; а Next Hop MAC позволит затем определить, что писать в поле DMAC Ethernet-заголовка.
Данный метазаголовок приклеивается обратно к пакету перед помещением его во входную очередь. К этому моменту уже создано нужное количество копий пакета и они направляются к нужным Egress FE.
В зависимости от реализации далее входная очередь может запрашивать разрешение у выходной на передачу пакета, ожидать явное подтверждение или вовсе передавать безусловно.
Непосредственно перед передачей на общую шину, пакет разрезается чипом SerDes на ячейки.
Далее ячейки попадают на общую шину. Оттуда на плату коммутации, если она есть. Если чипов коммутации не много (2-4), то фабрики могут быть встроены в интерфейсные карты. Если больше, то это или отдельностоящиме платы или составная часть управляющих. Для нас всё это не принципиально — важно знать, что ячейки передаются через эти фабрики.
С общей шины ячейки приходят на чип SerDes выходной платы, где благодаря их номерам они обратно собираются в пакет.
Пакет помещается в выходную очередь. Выходная очередь служит защитой FE от чрезмерного потока трафика (Back Pressure). Очередь позволяет отбрасываться пакеты контролируемо и прогнозируемо. Как раз в ней будет иметь значение приоритет CoS, указанный в метазаголовке. Чем ниже приоритет, тем выше вероятность отбрасывания при перегрузках. Таким образом на чип коммутации никогда не придёт больше трафика, чем он способен обработать. Здесь уже вступают в дело механизмы QoS: обработка пакетов в очередях, предотвращение перегрузок, управление перегрузками, шейпинг. Возвращаясь к VOQ (Virtual Output Queue), можно заметить, что данная очередь часто совмещается с очередями на интерфейсы: чтобы в порт 10 Гб/с не пытаться просунуть 13. Однако интерфейсные очереди могут быть выполнены и на отдельных чипах ближе к интерфейсам или даже на PIC.
После выходной очереди пакет с метазаголовком попадает на Egress FE.
Далее пакет попадает на чип PIC, где вычисляется контрольная сумма, которая записывается в FCS, добавляются преамбула и IFG, и вычисляется статистика отправленных пакетов.
Ну и потом, наконец, пакет отправляется в свой последний путь, реинкарнировав снова в импульс.
Уменьшение TTL на 1 и проверка, не равен ли он 0. Если равен — то запрос на CPU для генерации .
Приняните решение о назначении пакета на основе .
Тут же FE узнаёт необходима ли репликация пакетов и в какие порты (BUM-трафик в случае, например сценариев L2VPN), считает хэш для определения в какой из интерфейсов или послать этот пакет.
Здесь теперь разбирается метазаголовок и Egress FE готовит уже окончательный вид настоящих заголовков: Заполняет поля приоритета, записывает правильный TTL, передаёт пакет уровню Ethernet, где формируется полностью новый заголовок с данного устройства, а из временного заголовка (однако, если MAC не был разрезолвлен на Ingress FE, это происходит здесь). Здесь же может выполняться полисинг, настроенный на выходном интерфейсе (ограничение скорости, например).
