System mtu routing 1500 cisco что это
Maximum Transmission Unit (MTU). Мифы и рифы
Maximum transmission unit (MTU) это максимальный объём данных, который может быть передан протоколом за одну итерацию. К примеру, Ethernet MTU равняется 1500, что означает, что максимальный объём данных, переносимый Ethernet фреймом не может превышать 1500 байт (без учёта Ethernet заголовка и FCS — Рис. 1).
Рис. 1
Давайте пробежимся с MTU по уровням OSI:
Layer 2.
Ethernet MTU является частным случаем Hardware MTU. Определение Hardware MTU вытекает из общего определения:
Hardware MTU — это максимальный размер пакета, который может быть передан интерфейсом за одну итерацию (по крайней мере значение указано в спецификациях устройства – по факту некоторые чипсеты поддерживают передачу больших размеров пакетов, чем заявлено). Поэтому если взглянуть на рисунок 1 в отрыве от Ethernet, то получим следующее: 
Рис. 2
Замечание: Однако и тут не обойтись без оговорки. Как вы видите, HW MTU (Ethernet MTU в частности) не включает заголовок L2 в себя. Однако это справедливо для IOS и IOS XE, но для IOS XR и JunOS заголовок L2 включен в размер HW MTU – Рис. 3. Эта особенность может привезти к проблемам при установке OSPF neighborship между платформами под управлением IOS(XE) и IOS XR (OSPF требует совпадения MTU в Hello пакетах). Поэтому, при конфигурации MTU для Ethernet интерфейсов, на стороне IOS XR MTU должно быть на 14 байт больше (12 байт src mac+dst mac и 2 байт EtherType). К примеру, MTU в 1500 в Cisco IOS эквивалентно MTU в 1514 для IOS XR.
Рис. 3
Конфигурация и проверка.
Для того что бы изменить MTU на маршрутизаторах под управлением Cisco IOS используется команда интерфейс уровня:
Layer3.
IP MTU определяет максимальный размер пакета с IP заголовком, который может быть передан на данном интерфейсе не прибегая к фрагментации. Зависимость между IP MTU и HW MTU описывается следующей формулой:
IP MTU ≤ HW MTU
Соответственно, когда на интерфейс попадает пакет, превосходящий установленное IP MTU, пакет либо подвергается фрагментации, либо, в случае установленного флага DF (DO NOT Fragment) в IP заголовке, дискардится, а устройство может сгенерировать ICMP сообщение Fragmentation Needed, используемое в механизме path MTU discovery (о нём позже), и отправить его назад отправителю исходного пакета.
Конфигурация и проверка.
Для изменения IP MTU на маршрутизаторах под управлением Cisco IOS используется команда интерфейс уровня:
Вот те раз. Команда ip mtu не видна в show run. Да тут есть интересный нюанс – если ip mtu совпадает с hw mtu, то в выводе show run будет отображаться только hw mtu. Если значения разные то отображаются оба.
Layer 4.
TCP Maximum Segment Size (MSS) определяет максимальный размер TCP сегмента (без TCP заголовка!), который может быть использован (отправлен/принят) в ходе TCP сессии. Анонс (именно анонс, не хендшейк) размеров TCP MSS происходит во время установки TCP сессии – принимающая сторона анонсирует стороне отправляющей какой размер TCP сегмент она может принять. Соответственно размер TCP MSS может различаться в рамках одной TCP сессии в зависимости от направления.
Рис. 4
Сторона, производящая анонс, высчитывает значение TCP MSS для себя по следующей формуле:
TCM MSS = (IP MTU – [IPHDR + TCPHDR])
Конфигурация.
Тут у нас возможны два сценария – маршрутизатор является транзитным или участником TCP сессии.
1) Транзитное устройство:
Для предотвращения дропа пакетов промежуточным устройством в случае наличия линка с малым MTU, маршрутизатор будет прослушивать TCP SYN пакеты и подменять значения MSS анонсируемые конечным устройством. Что приведет к отправке пакетов меньшей величины конечным устройством и вуаля – проблема с дропами на линке с малым MTU упреждена.
2) Терминирующее устройство:
Здесь всё просто – маршрутизатор является участником TCP сессии и мы можем установить принудительно, размер MSS который он будет анонсировать.
Кажется всё? Нет, не всё. Вспоминаем про MPLS. Вспоминаем… Закончили вспоминать, переходим к рассмотрению.
Layer 2,5. MPLS.
Рис. 5
MPLS MTU определяет максимальный размер маркированного (кто знает как лучше переводиться Labeled прошу подсказать в комментах) IP пакета. В случае, если размер маркированного пакета превышает MPLS MTU, то пакет либо фрагментируется, либо, при наличии установленного в IP заголовка флага с DF bit, дропается (пока логика как и при превышении IP MTU), с возможной отправкой ICMP сообщения Fragmentation Needed.
Замечание: Вот тут дела обстоят немного по другому, по сравнению c IP MTU. В MPLS сети промежуточный узел может и не иметь маршрута к отправителю пакета, поэтому вместо того что бы слать ICMP сообщение отправителю напрямую, оно инкапсулируется с тем же стеком меток (label stack), что и исходный пакет, и отправляется по его же пути следования. Достигая Egress LSR (конечного MPLS маршрутизатора для данного LSP – за ним уже IP сеть без меток), который знает ip маршруты к узлу отправителя, ICMP сообщение Fragmentation Needed «разворачивается» им, инкапсулируется необходимыми заголовками и отправляется назад в MPLS сеть к отправителю оригинального пакета. Поведение аналогично с TTL Expired, да и в целом скорее относиться к теме MPLS, а не MTU. Поэтому кто не знаком с процессом — www.google.kg/?gws_rd=ssl#q=mpls+ttl+expired
Что здесь ещё интересного? MPLS MTU может быть больше HW MTU (поэтому на Рис. 3 HW MTU частично обозначено пунктиром). При этом IOS выдаст варнинг, но в большинстве случаев будет работать (зависит от чипсета интерфейса) и успешно пропускать по крайней мере baby-giant фреймы. А в иной раз можно получить дроп пакетов, повреждение данных, и сто лет без урожая.
Конфигурация и проверка.
Замечание: MPLS MTU отображается в running конфиге, также как и IP MTU — только в случае, если значение отличается от HW MTU. Но, в отличие от IP MTU, любое изменение HW MTU меняет значение MPLS MTU до значения HW MTU (IP MTU это действие не меняет).
MTU на коммутаторах Cisco.
На заметку администратору.
1) Для того, что бы найти минимальный MTU (забавное сочетание) на сети можно использовать расширенную команду ping, причём как c конечных станций/серверов так и с оборудования Cisco. Пропингуем с маршрутизатора R01 маршрутизатор R02 с выставленным df-bit, c начальным размером пакета в 1000 байт, конечным 1500 байт, и шагом 100 байт. Кол-во повторений 2.
Как видите, проходит только 6 ICMP пакетов размером 1000, 1100, 1200, 1300 байт
Начиная с 1400 байт и выше пакеты не проходят. Следовательно, минимальное MTU между двумя точками — 1300 и 1400, что можно уточнить ещё за несколько циклов, ужимая диапазон и умешьшая шаг.
На этом всё. Есть ещё в закромах старый драфт статьи по размерам фреймов и их эволюции, где описаны понятия Jumbo Frame, Baby-Giant Frame, встречающиеся в этой статье. Если посчитаете нужным, могу доработать и выложить и её.
IP MTU и туннели IPSec и GRE
Вопросы с IP фрагментированием
Хотя фрагментация пакета выполняется достаточно быстро, обратная сборка исходного пакета требует значительных ресурсов: затрат памяти, вопросы быстродействия.
В случае потери одного из фрагментов вся датаграмма должна быть передана заново.
Фрагметы очень тяжело обрабатывать на брендмауэрах (с 4-го по 7 уровень), при неправильной последовательности они будут забракованы.
TCP MSS и избегание дефрагментации
Таким образом TCP MSS позволяет избежать фрагментации на уровне двух участников сессии TCP. Но TCP MSS не может обработать тот случай, когда по пути между хостами есть меньший MTU.
PMTUD
PMTUD поддерживается только TCP, UDP и другие протоколы не поддерживают PMTUD.
Хост отсылает нефрагментированный пакет с установленным DF bit. Если маршрутизатор пытается отдать пакет на link, с меньшей MTU чем этот пакет, маршрутизатор дропнет этот пакет и возвратит сообщение ICMP «Destination Unreachable», с кодом «fragmentation needed and DF set» (type 3, code 4). Когда Хост-источник получает эту информацию, он понижает MSS и затем пересылает TCP сегмент заново.
Где актуально использование PMTUD
Вообще Path MTU Discovery (RFC 1191) осуществляется всеми клиентами включая Windows 2000/2003/XP/7/8.
Для нормальной работы PMTUD необходимо, чтобы пропускался протокол ICMP, в частности должны пропускаться сообщения ICMP «unreachable» и «time-exceeded».
Для проверки можно использовать утилиту mturoute.exe. Утилита отрабатывает аналогично PMTUD и возвращает значение MTU, которое необходимо использовать на данном хосте.
Текущее значение MTU можно увидеть через команды:
Windows 7, Windows Vista: netsh interface ipv4 show subinterfaces
Windows XP: netsh interface ip show interface
Значения MTU для локальной машины можно поменять и вручную (хотя и не рекомендуется)
Adjusting IP MTU, TCP MSS, and PMTUD on Windows and Sun Systems
Также можно использовать утилиту Set MTU, поставляемой с Cisco Systems VPN Client.
Что такое туннель
Туннель состоит из основных компонентов:
— Passenger protocol
— Carrier protocol. Протокол, осуществляющий инкапсуляцию:
GRE
IP in IP tunnels
— Transport protocol. Протокол отвечающий за маршрутизацию encapsulated protocol. В нашем случае это IP.
На приведенном рисунке IP у нас выступает как transport protocol и как passenger protocol.
Инкапсуляция трафика дает следующие преимущества:
Рекомендации построения туннельных интерфейсов
Общий конфиг для туннельного интефейса DMVPN + IPSec будет выглядеть:
interface Tunnel200
description ### DMVPN TUNNEL HUB
ip address 10.5.0.1 255.255.255.0
no ip redirects
ip mtu 1400
tunnel path-mtu-discovery
ip nbar protocol-discovery
ip hold-time eigrp 1 35
no ip next-hop-self eigrp 1
ip flow ingress
ip flow egress
ip nhrp authentication baurus
ip nhrp map multicast dynamic
ip nhrp network-id 200
ip tcp adjust-mss 1360
no ip split-horizon eigrp 1
delay 100000
tunnel source 87.237.40.107
tunnel mode gre multipoint
tunnel key 123
tunnel protection ipsec profile DMVPN
Настройка и проверка значения максимального блока передачи данных на платформах Cisco Nexus
Параметры загрузки
Об этом переводе
Этот документ был переведен Cisco с помощью машинного перевода, при ограниченном участии переводчика, чтобы сделать материалы и ресурсы поддержки доступными пользователям на их родном языке. Обратите внимание: даже лучший машинный перевод не может быть настолько точным и правильным, как перевод, выполненный профессиональным переводчиком. Компания Cisco Systems, Inc. не несет ответственности за точность этих переводов и рекомендует обращаться к английской версии документа (ссылка предоставлена) для уточнения.
Содержание
Введение
В этом документе описывается настройка и проверка максимального блока передачи данных (MTU) на коммутаторах Cisco Nexus.
Предварительные условия
Требования
Для этого документа отсутствуют особые требования.
Используемые компоненты
Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.
Настройка
Конфигурации MTU уровня 3
Все порты уровня 3 настраиваются индивидуально независимо от платформы.
Настройка MTU на коммутируемом виртуальном интерфейсе (SVI)
Настройте MTU на порте уровня 3
Конфигурации MTU уровня 2
MTU уровня 2 настраивается с использованием политики качества обслуживания (QoS) сети или путем настройки самого порта (на коммутаторах, поддерживающих настройку MTU на отдельных портах). Только Nexus 7000, 9000, и определенные 3000 моделей поддерживает для каждого порта MTU.
Настройка MTU для политики качества обслуживания сети
Nexus 3000: Включает коммутаторы серий Nexus 3048, 3064, 3132Q, 3132Q-X, 3132Q-XL, 3172 и 3500
Nexus 5000: Все коммутаторы серии Nexus 5000 и 5500
Nexus 6000: Все коммутаторы серии Nexus 6000
Чтобы настроить более высокое значение MTU на этих коммутаторах, создайте политику network-qos или измените существующую политику, чтобы задать более высокое значение MTU. Эта конфигурация применима ко всем портам. Она охватывает все порты Cisco Fabric Extender (FEX), подключенные к коммутатору. Настройка MTU на отдельных портах.
Настройка MTU на отдельных портах
Nexus 3000: Включает коммутаторы серии Nexus 3132Q-V, 3164, 31108, 31128PQ, 3200 и 36180YC-R
Neuxs 7000: Все коммутаторы серии Nexus 7000 и 7700
Nexus 9000: Все коммутаторы серии Nexus 9200 (включает 92xxx), 9300 коммутаторов Серии (включает 93xxx), и коммутаторы серии 9500
Для настройки MTU на для каждого порта основание, эта конфигурация необходима:
Настройка Nexus 2000
Примечание. Значение MTU для Nexus 2000 задается путем настройки кадров крупного размера на родительском коммутаторе. Для родительских коммутаторов, которые поддерживают кадры крупного размера для отдельных портов, следует настроить канал порта матрицы (FPC) FEX. Если для родительского коммутатора требуется политика качества обслуживания сети, в этом случае кадр крупного размера задается с использованием конфигурации политики качества обслуживания сети родительского коммутатора. Эти изменения в обоих случаях автоматически передаются в FEX.
Настройка FPC на отдельных портах (настраивается на родительском коммутаторе Nexus)
Примечание. Nexus 7000 не позволяет задать MTU FEX с использованием FPC в версии 6.2 и более поздних версий. Вместо этого необходимо создать пользовательскую политику качества обслуживания в соответствии со следующей конфигурацией.
Nexus 7000 / Конфигурация Кадра большого размера FEX (только применяется к версии 6.2 и позже),
Примечание. Измените текущий используемый шаблон. Чтобы найти текущий используемый шаблон, выполните команду show policy-map system type network-qos.
Настройка политики качества обслуживания сети (настраивается на родительском коммутаторе Nexus)
Проверка
Воспользуйтесь данным разделом для проверки правильности функционирования вашей конфигурации.
MTU уровня 3
Проверьте MTU уровня 3 на всех платформах Nexus с помощью команды show interface eth x/y, как показано в этом примере:
Проверьте MTU SVI с помощью команды show interface vlan, как показано в следующем примере вывода:
MTU уровня 2
В этом разделе описывается процедура проверки MTU уровня 2 для отдельных платформ. Команды выполняются с родительского коммутатора.
Проверьте MTU на коммутаторах то QoS сети использования
Проверьте MTU на коммутаторах та поддержка для каждого порта MTU
Примечание. Если Nexus 3000 в коде идет раньше, чем 7.0(3) I2(2a), необходимо проверить значение MTU с помощью команды ethernet show queueing interface x/x. Коммутаторы Nexus 3000, которые выполняют 7.0 (3) I2 (2a) и позже показывают максимальный размер передаваемого блока данных на для каждого порта основание.
Nexus 2000
Примечание. Если MTU FEX изменяется, значение MTU FEX увеличивается до более высокого предварительно определенного значения, которое не точно совпадает с заданным значением. Родительское устройство принудительно применяет настроенное значение MTU в канале порта матрицы (FPC) FEX.
Для FEX, связанного с Nexus 5000, 6000, и 7000:
Для FEX, связанного с Nexus 9000:
Устранение неполадок
Этот раздел обеспечивает информацию, которую вы можете использовать для того, чтобы устранить неисправность в вашей конфигурации.
Примечание.Перед использованием команд debug обратитесь к документу Важные сведения о командах отладки.
Иногда необходимо проверять изменения в программном обеспечении. Для этого проверьте диспетчер портов Ethernet (ethpm), чтобы убедиться в том, что изменения передаются программно на все платформы:
Кроме того, в модулях M1, M2, F1 и F2 можно проверить передачу изменений аппаратным способом:
Можно также просмотреть конфигурацию QoS на сетевой карте:
Влияние
Если обе стороны VPC не совпадают с MTU, несогласованный MTU через ссылку мог бы оказать влияние на маршрутизируемые интерфейсы с маршрутизацией смежностей и вызовет несоответствие типа 1 с VPC. Следует настраивать конфигурацию с осторожностью.
Дополнительные сведения о параметрах непротиворечивости VPC и Несоответствиях Типа 1 как MTU могут быть найдены в описании команды show vpc consistency-parameters.
MTU Behavior on Cisco IOS XR and Cisco IOS Routers
Available Languages
Download Options
Contents
Introduction
This document describes maximum transmission unit ( MTU) behaviors on Cisco IOS ® XR routers and compares those behaviors to Cisco IOS routers. It also discusses MTUs on routed Layer 3 (L3) interfaces and Layer 2 VPN (L2VPN) L2 interfaces that use both the Ethernet Virtual Connection (EVC) and non-EVC models. This document also describes important changes to how Ethernet interface driver MTU and maximum receive unit (MRU) are automatically configured in Release 5.1.1 and later.
Background Information
In computer networking, the MTU of a communications protocol of a layer defines the size, in bytes, of the largest protocol data unit that the layer is allowed to transmit over one interface. One MTU parameter is associated with each interface, layer, and protocol.
MTU characteristics in Cisco IOS XR software are:
The remainder of this document illustrates MTU characteristics, compares Cisco IOS and Cisco IOS XR software behavior, and gives examples for these types of interfaces:
Configure
Note: Use the Command Lookup Tool (registered customers only) in order to obtain more information on the commands used in this section.
Note: The Output Interpreter Tool (registered customers only) supports certain show commands. Use the Output Interpreter Tool in order to view an analysis of show command output.
Comparison of Cisco IOS and Cisco IOS XR Software
This section compares Cisco IOS and Cisco IOS XR software behavior with reference to MTU characteristics.
In Cisco IOS software, the mtu command and the corresponding show commands do not include the L2 header. Use the mtu command in order to configure the L2 payload to the maximum size for the L3 packets, including the L3 header.
This is different from Cisco IOS XR software, where the mtu command includes the L2 header (14 bytes for Ethernet or 4 bytes for PPP/HDLC).
If a Cisco IOS router is configured with mtu x and is connected to a Cisco IOS XR router, then the corresponding interface on the Cisco IOS XR router should be configured with mtu x+14 for Ethernet interfaces, or mtu x+4 for serial interfaces.
Cisco IOS and Cisco IOS XR software have the same meaning for the ipv4 mtu, ipv6 mtu and mpls mtu commands; they must be configured with the same values.
As a result, this is the configuration in Cisco IOS software on an Ethernet interface:
The corresponding configuration on the Cisco IOS XR software neighbor is:
Routed L3 Interfaces
The MTU values must be the same on all devices connected to an L2 network. Otherwise, these symptoms might be reported:
Default MTU
This section analyzes the default MTU of a routed interface when the mtu command is not configured:
In this example, the default L2 interface MTU is 1514 bytes and includes 14 bytes of Ethernet header. The 14 bytes are accounted by 6 bytes of destination MAC address, 6 bytes of source MAC address, and 2 bytes of type or length. This does not include the preamble, frame delimiter, 4 bytes of frame check sequence (FCS), and inter-frame gap. For a PPP or HDLC frame, 4 bytes of the L2 header are accounted for; so the default interface MTU is 1504 bytes.
The L3 child protocols inherit their MTU from the payload of the parent MTU. When you subtract 14 bytes of an L2 header from an L2 MTU of 1514 bytes, you have an L2 payload of 1500 bytes. This becomes the MTU for L3 protocols. IPv4, IPv6, MPLS, and Connectionless Network Service (CLNS) inherit this1500 byte MTU. As a result, a Cisco IOS XR Ethernet interface, by default, can transport a 1500 byte L3 packet which is the same as the defauIt on a Cisco IOS Ethernet interface.
Non-Default MTU
This section shows how to configure an mpls mtu of 1508 in order to send an IPv4 packet of 1500 bytes with two MPLS tags of 4 bytes each, on top of the packet:
Although the mpls mtu 1508 command is committed, it is not applied, because MPLS still has an MTU of 1500 bytes in the show command. This is because L3 child protocols cannot have an MTU larger than the payload of their parent L2 interface.
In order to allow two labels on top of a 1500 byte IP packet, you must:
This configuration lets you send IPv4 and IPv6 packets of 1500 bytes and MPLS packets of 1508 bytes (a 1500 byte packet with two tags on the top).
Routed L3 Sub-Interfaces
These characteristics apply to routed L3 sub-interfaces.
A routed sub-interface MTU inherits the MTU of its parent main interface; add 4 bytes for each VLAN tag configured on the sub-interface. Thus, there are 4 bytes for a dot1q sub-interface and 8 bytes for a IEEE 802.1Q tunneling (QinQ) sub-interface.
As a result, L3 packets of the same size can be forwarded both on the main interface and the sub-interface.
The mtu command can be configured under the sub-interface, but it is applied only if it is lower or equal to the MTU that is inherited from the main interface.
This is an example where the MTU of the main interface is 2000 bytes:
In the show commands, the MTU of the sub-interface is 2004; add 4 bytes to the MTU of the main interface because there is one dot1q tag configured under the sub-interface.
The mtu command can be configured under the sub-interface, but the configured MTU is applied only if it is lower or equal to the MTU that is inherited from the main interface (4 bytes larger than the MTU of the main interface).
When the MTU of the sub-interface that is larger than the inherited MTU, it is not applied, as shown here:
Thus, you can use only the mtu command in order to lower the MTU value inherited from the main interface.
Similarly, you can also use the MTU commands of L3 protocols (IPv4, IPv6, MPLS) in order to lower the value of the L3 MTU inherited from the sub-interface L2 payload. The L3 protocol MTU does not take effect when it is configured to a value that does not fit in the payload of the L2 MTU.
L2VPN L2 Interface
The MTU for an L2VPN is important because Label Distribution Protocol (LDP) does not bring a pseudowire (PW) up when the MTUs on the attachment circuits at each side of a PW are not the same.
Here is a show command that illustrates that an L2VPN PW stays down when there is an MTU mismatch:
In this example, note that the MPLS L2VPN provider edges (PEs) at each side must signal the same MTU value in order to bring the PW up.
The MTU signaled by MPLS LDP does not include the L2 overhead. This is different from the XR interface config and show commands that include the L2 overhead. The MTU on the sub-interface is 2018 bytes (as inherited from the main interface of 2014 bytes), but LDP signaled an MTU of 2000 bytes. As a result, it subtracts 18 bytes (14 bytes of Ethernet header + 4 bytes of 1 dot1q tag) from the L2 header.
It is important to understand how each device computes the MTU values of the attachment circuits in order to fix MTU mismatches. This depends upon parameters such as vendor, platform, software version, and configuration.
EVC (ASR9000)
The Cisco ASR 9000 Series Aggregation Services Router uses the EVC infrastructure model, which allows flexible VLAN matching on L2VPN L2 interfaces and sub-interfaces.
The EVC L2VPN L2 interfaces have these characteristics:
When there is an mtu command under the sub-interface, it takes effect only if it is lower than the computed MTU. The rewrite command does not influence the MTU of the sub-interface.
Here is an example:
In this example, the MTU in the main interface is 2014 bytes; add 8 bytes because there are two tags configured under the sub-interface.
If you configure mtu 2026 bytes under the sub-interface, it is not applied because it is larger than the MTU of the sub-interface inherited from the main interface (2022). As a result, you can configure only a sub-interface MTU lower than 2022 bytes.
Based on this sub-interface MTU, compute the MTU of the MPLS LDP payload that is signaled to the neighbor, and make sure that it is identical to the one computed by the remote L2VPN PE. This is where the rewrite command comes into play.
In order to compute the MTU of the MPLS LDP payload, take the MTU of the sub-interface, then:
This is the same example with the QinQ configuration on gig 0/1/0/3.201:
This is the computation for the MTU of the MPLS LDP payload:
Ensure that the remote side advertises an MPLS LDP payload of 2000 bytes. Otherwise, adjust the local or remote attachment circuit (AC) MTU size so they match.
Specific Ethernet Flow Point (EFP) Encapsulation Commands
These encapsulations count as matching zero tags, so they do not increase the sub-interface MTU:
These encapsulation modifiers do not affect the number of tags required in order to compute the sub-interface MTU:
encapsulation [dot1q|dot1ad] priority-tagged counts as matching a single tag.
The ‘any’ keyword used as the innermost tag match does not increase the sub-interface MTU.
The ranges of VLAN-IDs increment the sub-interface MTU:
The encapsulation MTU overhead of an EFP that is a disjunctive match is treated as the MTU of its highest element.
Non EVC (XR 12000 and CRS)
Routers like the Cisco XR 12000 Series router and the Carrier Routing System (CRS) use the traditional configuration for the VLAN matching on sub-interfaces. These characteristics apply to L2VPN L2 interfaces on CRS and on XR 12000 routers that do not follow the EVC model:
Here are several examples that illustrate these characteristics.
This example shows how a non-EVC sub-interface is configured:
The non-EVC platforms use the dot1q vlan or dot1ad vlan commands instead of the encapsulation and rewrite commands of the EVC platforms (ASR9000).
If you do not configure an MTU explicitly on the main or sub-interface, then a 1500 byte L3 packet can be received by default:
The sub-interface MTU is computed from the main interface MTU (1514); add 4 bytes for each dot1q tag. Because there is one tag configured on the sub-interface with the dot1q vlan 201 command, add 4 bytes to 1514 for an MTU of 1518 bytes.
The corresponding payload MTU in MPLS LDP is 1500 bytes, since the 14 bytes of Ethernet header are not counted and the one dot1q tag is popped automatically by the non-EVC platform when it goes over the PW:
If you increase the MTU of the main interface to 2014 bytes, the MTU of the sub-interface is increased accordingly:
So, in order to compute the MPLS LDP MTU, subtract 14 bytes of Ethernet header, and add 4 bytes for each tag configured under the sub-interface.
Automatic Ethernet Interface Driver MTU and MRU Configuration
On Ethernet interfaces the interface driver is configured with an MTU and MRU that is based on the interface MTU configuration.
The configured MTU and MRU on the Ethernet interface driver can be seen with the show controller all command.
In releases earlier than Cisco IOS XR Release 5.1.1, the MTU and MRU on the Ethernet interface driver were automatically configured based on the Cisco IOS XR MTU configuration on the interface.
The MTU/MRU configured on the Ethernet driver was simply based on the configured MTU + 12 bytes for the addition of 2 Ethernet Tags and the CRC field. The 12 bytes were added to the Ethernet driver MTU/MRU regardless of if there were any VLAN tags configured on the sub-interfaces.
An example with all Cisco IOS XR versions earlier than Cisco IOS XR Release 5.1.1 and a default MTU of 1514 on an ASR 9000 interface is shown here:
In Cisco IOS XR Release 5.1.1 and later, the MTU and MRU that is used on the Ethernet interface driver has changed and is now based on the number of VLAN tags that are configured on any of the sub-interfaces.
If no VLAN tags are configured on any sub-interfaces, the driver MTU/MRU equals the configured MTU on interface + 4 CRC bytes, for example 1514 + 4 = 1518 bytes.
If one VLAN is configured on any sub-interfaces, the driver MTU/MRU equals the configured MTU + 8 bytes (1 tag + CRC), for example 1514 + 8 = 1522 bytes.
If two VLAN tags are configured on any sub-interfaces, the driver MTU/MRU equals the configured MTU + 12 bytes (2 tags + CRC), for example 1514 + 12 = 1526 bytes
If QinQ with the any keyword is configured for the second-do1q tag the driver MTU/MRU equals the configured MTU + 8 bytes (1 tag + CRC), for example 1514 + 8 = 1522 bytes.
These examples display the behavior in Cisco IOS XR Release 5.1.1 and later on an ASR 9000:
In most situations this behavior change in Release 5.1.1 and later should not require any changes to the configuration of the MTU on the interface.
This behavior change can cause problems in the case of a sub-interface configured with a single VLAN tag, but receives packets with two VLAN tags. In that situation the packets received can exceed the MRU on the Ethernet interface driver. In order to eliminate that condition, the interface MTU can either be increased by 4 bytes or the sub-interface configured with two VLAN tags.
The automatic Ethernet interface driver MTU and MRU configuration in Release 5.1.1 behavior is the same for a CRS and ASR 9000 routers. But a CRS router that runs Release 5.1.1 does not include the 4 byte CRC in the MTU and MRU value displayed in the show controller output. The behavior of how it is reported is not the same between CRS and ASR9000.
The way the MTU and MRU is displayed in the show controller output on the ASR 9000 will change in the future so that the 4 bytes of CRC will not be included in the MTU/MRU value displayed. This future change can be tracked with Cisco bug ID CSCuo93379. 
Convert the Configuration When You Upgrade from a Release Earlier than Release 5.1.1 to Release 5.1.1 or Later
If there was a main interface without any sub-interface and without any mtu command in a release earlier than Release 5.1. 1 :
And this interface transports dot1q or QinQ frames, then the MTU should be manually configured to «mtu 1522» in Release 5.1.1 and later:
This configuration allows QinQ frames to be transported as in the earlier releases. The MTU value could be configured to 1518 if only dot1q and not QinQ are to be transported.
If there were sub-interfaces configured for dot1q or QinQ, but with the «any» keyword and no QinQ sub-interfaces with 2 explicit tags was configured in a release earlier than Release 5.1.1:
This configuration in Release 5.1.1 and later will only allow to transport frames with one tag so the MTU should also be increased manually by 4 bytes if QinQ frames are to be transported:
If a QinQ sub-interface with 2 explicit tags (that do not use the «any» keyword) is configured, there is no need to modify the MTU configuration when you upgrade to Release 5.1.1 and later:
If there is no L2 transport sub-interface but only L3 routed interfaces, it is expected that the MTU configuration would match at both sides and there would not be frames larger than the MTU that is transported. There is no need to update the MTU configuration when you upgrade to Release 5.1.1 and later.
Similarly, when a non-default MTU was configured in a release earlier than Release 5.1.1 and no sub-interface was configured and dot1q or QinQ frames have to be transported, then the configured MTU value should be increased by 8 bytes when you upgrade to Release 5.1.1 or later.
Release earlier than Release 5.1.1:
The MTU should be manually increased by 8 bytes when you upgrade to Release 5.1.1 and later:
The configured MTU value should also be increased by 4 bytes if there is a dot1q sub-interface and no QinQ sub-interface or a QinQ sub-interface with the any keyword for the second-dot1q tag.
Release earlier than Release 5.1.1:
Release 5.1.1 and later:
If a QinQ sub-interface with 2 explicit tags (that do not use the «any» keyword) is configured, there is no need to modify the MTU configuration when you upgrade to Release 5.1.1 and later.
If there is no L2 transport sub-interface, but only L3 routed interfaces, it is expected that the MTU configuration would match at both sides and there would not be frames larger than the MTU that is transported. There is no need to update the MTU configuration when you upgrade to Release 5.1.1 and later.