1-interface-based.md

Interface-based

Это наиболее простой способ классифицировать пакеты в лоб. Всё, что насыпалось в указанный интерфейс, помечается определённым классом.

В большинстве случае такой гранулярности не хватает. Поэтому Interface-based классификация не сказать, что часто встречается в чистом виде.

Практика по Interface-based классификации

Схема та же:

Настройка политик QoS в оборудовании большинства вендоров делится на этапы.

1. Сначала определяется классификатор:

   class-map match-all TRISOLARANS_INTERFACE_CM
   match input-interface Ethernet0/2
   

   Всё, что приходит на интерфейс Ethernet0/2.

2. Далее создаётся политика, где связываются классификатор и необходимое действие.

   policy-map TRISOLARANS_REMARK
   class TRISOLARANS_INTERFACE_CM
   set ip dscp cs7
   

   Если пакет удовлетворяет классификатору TRISOLARANS_INTERFACE_CM, записать в поле DSCP значение CS7.

3. И последним шагом применить политику на интерфейс:

   interface Ethernet0/2
   service-policy input TRISOLARANS_REMARK
   

   Здесь немного избыточен классификатор, который проверят что пакет пришёл на интерфейс e0/2, куда мы потом и применяем политику. Можно было бы написать match any:

   class-map match-all TRISOLARANS_INTERFACE_CM
   match any
   

   Однако политика на самом деле может быть применена на vlanif или на выходной интерфейс, поэтому можно.

{% hint style="warning" %} Здесь я забегаю вперёд, используя непонятные CS7, а далее EF, AF. Ниже можно прочитать про эти аббревиатуры и принятые договорённости. Пока же достаточно знать, что это разные классы с разным уровнем сервиса. {% endhint %}

Пускаем обычный пинг на 172.16.2.2 (Trisolaran2) с Trisolaran1:

И в дампе между Linkmeup_R1 и Linkmeup_R2 увидим следующее:

pcapng

Файл конфигурации Interface-Based классификации