MTU в IP/MPLS L2VPN

MTU Problem @ DevOps Reaction

Тема MTU/MRU у меня никогда не заходила. Как и некоторые другие темы. Сколько я не читаю и не пытаюсь понять, мало что меняется. Со знакомством c MPLS L2VPN проблема вышла на новый уровень. Попробуем составить краткий конспектик по Alcatel-подходу к MTU. Подозреваю, что он схож с PWE3.

Все посты про MPLS VPN можно посмотреть по тегу MPLS или в обобщающем посте.

MTU в IP/MPLS VPN можно задать много где:

1. На порту в сторону клиента (UNI - User-Network Interface). Тут в целом все просто. Размер MTU должен быть выставлен в соответсвтии с той технологией, которая используется для доступа. Вернее с типом энкапсуляции. dot1q - 1518 байт (1500 - полезная нагрузка, 14 - заголовок Ethernet, 8 байт - VLAN Tag), чистый Ethernet - 1514 байт и т.д.

2. На порту в сторону backbone-сети (NNI - Network-Network Interface). Тут есть смысл ставить как можно большее значение, а лучше максимальное. Через порт в сторону ядра будут идти разные сервисы с разными значениями MTU, лучше чтобы в порт пролезло любое значение. Тут может быть классический косяк с какой-нибудь старой железкой на каком-нибудь арендованном канале, которая не может больше 1518 байт. В таком случае можно уменьшить MTU на всех SDP, которые идут через этот линк, до приемлемого значения. Таким образом, трафик пролезет через узкое место, а MTU на портах останутся в прежнем значении. Ведь эти же порты могут использоваться для SDP в другие стороны.

3. LSP-Path MTU. По дефолту LSP-Path MTU равен MTU на порту в сторону ядра минус L2 overhead. Однако при использовании RSVP-TE можно включить процесс в котором устройства договорятся об используемом MTU (MTU negotiation, одним словом).

4. SDP-Path MTU. Максимальный размер кадра, который передается в SDP. В одном SDP может быть много сервисов. Значение должно быть больше MTU, который прописан на сервисе. Оно и логично. Часто генерится автоматически в соответствии с тем, какой тип туннелирования используется для SDP. 

RSVP-TE с MTU Negotiation - LSP-Path минус 8 байт на транспортную и pseudowire-метку.

RSVP-TE без MTU Negotiation - NNI MTU минус размер заголовка и минус 8 байт на метки.

LDP - аналогично NNI MTU минус размер заголовка и минус 8 байт на метки.

GRE - NNI MTU минус 20 байт на ещё один заголовок IP минус 4 байта на psewdowire-метку минус 4 байта на сам GRE заголовок.

LDPoRSVP -  NNI MTU минус размер заголовка минус 8 байт на метки и минус ещё 4 байта на туннельную метку.

Если SDP использует FRR технологию защиты с bypass tunnel, то MTU уменьшается ещё на 4 байта для дополнительной метки.

5. Service MTU. Это размер кадра для клиентского трафика после того как он попал в фабрику устройства (VPN Payload). Обычно VLAN-tag (а то и два) снимаются на SAP, а по pseudowire трафик идет без дополнительных тегов. Это, кстати, дает возможность принять трафик в 300 влане, например, а отдать в 400. Service MTU должно быть равно размеру пользовательского кадра без учета VLAN тэгов и MPLS меток.

Так же MTU присутстствует, но не конфигурируется:

VC-MTU. VC-MTU равно Service MTU за вычетом 14 байт (на Ethernet заголовок). Это значение сигнализируется при установке pseudowire с помощью T-LDP. Значение это определяет максимальную полезную нагрузку клиентского трафика без учета заголовков.

Вся фишка, конечно же, в отношении этих значений.

1. Трафик должен пролезть в SDP

NNI MTU минус ENCAPSULATION должно быть больше или равно SDP-Path MTU.

2. Сервис должен пролезть в SDP

SDP-Path MTU больше или равен Service MTU

3. Трафик сервиса должен вылезти из порта в сторону абонент.

UNI MTU минус ENCAPSUlATION должно быть больше или равно Service MTU.