Давным давно, в то время пока я пускал слюни в уютной детской кроватке, устройству для того, чтобы отправить данные надо было убедиться в том, что в данный конкретный момент времени никто не вещает на общем сегменте сети. За то, может ли устройство вести передачу отвечал протокол CSMA/CD – Carrier Sense Multiple Access with Collision Detect, а сами устройства оперировали в режиме half-duplex, т.е. могли либо вещать, либо слушать несущую в каждый конкретный момент времени. Более того, если одно устройство создавало фрейм с ошибкой все остальные устройство получали этот фрейм. Весь скоп устройств в такой сети назывался Collision Domain.
К счастью времена концентраторов (hub) канули в Лету, домен коллизий уменьшился до порта коммутатора и устройства, непосредственно присоединенного к этому порту. Устройства получили возможность работать в full-duplex, т.е. получать и передавать данные одновременно, а ошибки в фреймах теперь фильтруются непосредственно на ASIC, к которому подключен порт(ы) и не распространяются на всю сеть. Ты хороший пакет, у тебя годный CRC? Значит мы повторим тебя на исходящем порту (store-and-forward метод – пакеты приходят на входящий порт, поступают на хранения для инспекции и только затем перенаправляются на исходящий). Идиллия? Идиллия!
Layer 2 коммутаторы
Весь процесс коммутации на втором уровне полностью основан на MAC адресах, а значит коммутатору жизненно необходимо получить информацию не только о тех устройствах, которые подключены непосредственно к его портам, но и заучить информацию о устройствах, находящихся за другими коммутаторами. Следствием этого безудержного желания становится факт того, что коммутаторы изучают Source MAC полученного фрейма и создают запись, в которой фигурирует порт, на который пришел фрейм, MAC и VLAN. Такая запись заносится в CAM таблицу.
Как не трудно догадаться помимо Source MAC имеет место еще и Destination MAC – адрес того устройства, которому фрейм должен быть доставлен. Коммутатор заглядывает в список записей, в надежде найти за каким портом и в каком VLAN находится получатель фрейма и в том случае если такой записи не существует, то коммутатор рассылает фрейм на все порты за исключением того, с которого этот фрейм пришел. Этот процесс носит название unknown unicast flooding.
Multilayer коммутаторы
Или MLS (Multilayer Switch). Часто их называют “layer 3 коммутаторы”, что меня несколько коробит, так как зачастую такие железки умеют еще и заниматься обработкой пакетов на основе информации четвертого уровня.
Предпосылкой к появлению MLS стало желание заниматься не только коммутацией, но и маршрутизацией на скорости интерфейса. Конфигурации, в которых маршрутизаций между VLAN занимаются маршрутизаторы таким похвастаться не могли. Существует два типа MLS и, не смотря на то, что только второе поколение поддерживается в операционных система Cisco IOS, NX-OS etc на экзамене CCNP Switch вам не мешает знать еще и о первом.
- Route caching – первое поколение, включающее в себя Route Processor (RP) и Switching Engine (SE). RP заносит в кэш информацию, на основании адреса получателя первого пакета, а SE, затем, занимается коммутацией подобных пакетов на основании кэша. Это техника так же носит названия demand-based switching, flow-based switching.
- Topology-based – второе поколение MLS, использующее специальное аппаратное обеспечение. Информация из всей таблицы маршрутизации помещается в единую базу данных и маршрутизация происходит на основе поиска в такой базе данных наиболее длинного префикса. Cisco называет такой тип маршрутизации CEF (Cisco Express Forwarding), а область аппаратурного обеспечения, содержащая актуальную таблицу маршрутизации – FIB (Forward Information Base).
Процесс коммутации/маршрутизации в MLS
Пакет забирается с одной из входящих очередей и происходит исследование L2 и L3 адресов получателей. Решение о том куда направить пакет происходит на основании CAM и FIB таблиц. Решение о том как отправить пакет (и отправлять ли вообще) принимается на основании ACL и QOS политик. Стоит отметить, что поиск по CAM, FIB, QOS, ACL происходит одновременно.
- CAM или Layer 2 forwarding table. В этой таблице MAC адрес получателя используется в качестве индекса. В том случае если фрейм содержит пакет, который надо маршрутизировать, то в качестве Destination MAC будет фигурировать адрес L3 порта коммутатора.
- FIB или Layer 3 forwarding table. В этой таблице IP адрес получателя используется в качестве индекса. Результатом поиска могут стать несколько записей из которых выбирается наиболее длинный префикс. Результирующая запись содержит IP адрес next hop устройства, его MAC адрес, исходящий порт коммутатора и VLAN.
- ACL – (опционально) списки контроля доступа, которые компилируются в специальную память – TCAM, на основании ACL принимается решение маршрутизировать пакет или нет.
- QOS – (опционально) классификация, маркировка и применение к пакету политик. QOS правила так же размещаются в TCAM.
- Packet Rewrite – на этом этапе происходит изменение Destination MAC L3 порта коммутатора на Destination MAC L3 next hop устройства, TTL уменьшается на единицу. Из-за подмены Source&Destination MAC так же происходит перезапись контрольной суммы фрейма, а из-за изменения TTL – контрольной суммы пакета.
Стоит держать в голове информацию о том, что некоторые типы пакетов не могут быть обработаны с помощью технологии CEF. Их обработкой занимается процессор маршрутизатора, а процесс этот носит название process switching. К таким типам пакетов относятся:
- ARP запросы и ответы.
- Пакеты, которые требуют от MLS проявить какую-либо реацию (TTL expired, MTU exceeded, fragmentation needed).
- Broadcast, которые необходимо транслировать в unicast (ip helper-address при DHCP запросах).
- Обновления протоколов маршрутизации.
- CDP пакеты.
- Пакеты, которые необходимо зашифровать.
- Пакеты, которые необходимо транслировать с помощью NAT/PAT.
- Пакеты, попадающие под действия правила ACL с ключем log.
Посмотреть информацию о данных, расположенных в FIB таблицы можно с помощью команды:
MLS# show ip cef [prefix/mask | vlan | interface | ... ] [detail]
например:
CoreSwitchA#sh ip cef 172.16.20.0 255.255.255.0 longer-prefixes Prefix Next Hop Interface 172.16.20.254/32 receive Vlan20 172.16.20.0/32 receive Vlan20 172.16.20.255/32 receive Vlan20 172.16.20.121/32 attached Vlan20 172.16.20.56/32 attached Vlan20 172.16.20.11/32 attached Vlan20 172.16.20.15/32 attached Vlan20 172.16.20.55/32 attached Vlan20 172.16.20.12/32 attached Vlan20 ...