Cisco BPDU Filter and BPDU Guard simultaneously.

Решил зафиксировать незначительную заметку относительно одновременного использования функций BPDU Filter и BPDU Guard на коммутаторах, в частности на Catalyst 3750 с версией c3750-advipservicesk9-mz.122-46.SE. Мне не удалось нагуглить достоверной информации по этому поводу, разве только этот пост, который оказался не что неверным, а скорее неполным.

Итак:

  • Если включить функции BPDU Filter и BPDU Guard одновременно используя команды на интерфейсах, приоритет будет отдан функции BPDU Filter.
    SW1#sh run int fa1/0/5
    Building configuration...
    
    Current configuration : 100 bytes
    !
    interface FastEthernet1/0/5
     spanning-tree bpdufilter enable
     spanning-tree bpduguard enable
    end
    
    SW1#
    
  • Если включить функции BPDU Filter и BPDU Guard одновременно используя команды глобальные команды, приоритет будет отдан функции BPDU Guard.
    SW1#sh run | i spanning-tree portfast
    spanning-tree portfast default
    spanning-tree portfast bpduguard default
    spanning-tree portfast bpdufilter default
    SW1#
    

Вполне допускаю, что все зависит от модели коммутатора и от версии ПО. Эксперименты с другими моделями проводить не стал.

MTU in Cisco Catalyst.

Сегодня достаточно подорбно разбирал вопрос MTU в Cisco IOS. Проверял при помощи больших ICMP пакетов и современных коммутаторов Huawei, так как Cisco Catalyst 3950/2960/3550/3560/3750 имеют у SVI интерфейсов максимум MTU 1500.

Немного неудобно было то, что в Cisco IOS CLI команда ping с ключем размера пакета описывает полный размер IP пакета (включая заголовок IP (20 bytes) + заголовок ICMP (8 bytes) + ICMP Payload), тогда как в Huawei VRP этот ключ описывает лишь размер ICMP Payload без учета заголовков IP и ICMP.

Еще одно глобальное неудобство состояло в том, что если на Catalyst настроить SPAN, то в нем нельзя увидеть входящие фреймы в том случае если они больше настроенного на Catalyst MTU.

Выводы

  1. Команда “system mtu …” описывает максимальный IP MTU пакета (т.е. с учетом IP заголовка и далее), который может быть передан через коммутатор в случае если используется access или trunk порты. И при этом неважно тегированный или нетегированный фрейм.
  2. Если используется dot1q-tunnel, то логика работы меняется, а именно:
    1. Если фрейм нетегированный, то коммутатор пропускает пакет с IP MTU равным сконфигурированному “system mtu …“.
    2. Если же фрейм тегирован, то коммутатор может пропустить фреймы с IP MTU меньшим сконфигурированного “system mtu …” на 4 байта. Казалось бы, что добавляется только один Dot1Q тэг размеров в 2 байта, но, вероятно, из-за логики работы, необходимо увеличивать “system mtu …” на 4 байта. Если предполагается множественная QinQ вложенность, тогда, скорее всего, нужно учитывать +2 байта для каждого доплнительного вложения.

Admin area