SRv6 to MPLS Interworking and Path MTU Failure
An operator is migrating a 180-node IP/MPLS backbone to SRv6. The core runs IS-IS Level-2 and SRv6 with uSID; 48 legacy PEs still use LDP and MPLS VPNv4. The backbone has 9,000 L3VPN instances and 2,400 IPv4 BGP sessions. Core interfaces use 9,000-byte MTU; customer access ports are 1,500 bytes. During a pilot, HTTP and SSH sessions from a legacy MPLS site to an SRv6 site hang after the TCP handshake, while 1,400-byte pings succeed and 1,500-byte pings fail. The SRv6 PE uses H.Encaps.BE for VPN traffic, and ICMPv6 Packet Too Big messages from the core are being filtered by an access-list on the legacy PE. The project team proposes raising the access MTU to 1,600 and disabling IPv6 ICMP on all PEs. Evaluate the proposal.
1. Explain the packet-size failure and assess the proposed fix of raising access MTU to 1,600 bytes and disabling ICMPv6 on all PEs.
Read the worked answer
The handshake succeeds because small TCP control packets fit; the first full-size data segment does not. SRv6 H.Encaps.BE adds an outer IPv6 header of 40 bytes, and an SRH can add 8 bytes plus 16 bytes per segment. A 1,500-byte customer packet becomes at least 1,540 bytes on the core-facing link. If the SRv6 PE does not fragment and the access cannot carry the larger frame, the packet is dropped. Because ICMPv6 Packet Too Big is filtered on the legacy PE, PMTUD cannot learn the reduced path MTU, so sessions hang. Raising access MTU to 1,600 is unsafe unless every access switch, host, and provider path supports it; most customer ports remain 1,500. Disabling ICMPv6 breaks PMTUD and IPv6 neighbor functions and should be rejected. The correct direction is to enable ICMPv6 PTB on the core-to-access path, apply TCP MSS clamping on the PE for affected VPNs, and account for the SRv6 header in interface and tunnel MTU design. Use ping -s with DF and tracert to confirm the exact failure size, and check display ipv6 interface MTU values.
2. Design the SRv6-to-MPLS interworking and MTU plan for the 48 legacy PEs, including where encapsulation and fragmentation are handled.
Read the worked answer
Keep the 48 legacy PEs on MPLS and introduce SRv6-MPLS interworking at a small number of border PEs that support both encapsulations rather than forcing an overnight upgrade. Advertise VPNv4 routes between the domains through route reflectors, with consistent route targets and labels. At the interworking PE, traffic from an SRv6 PE is decapsulated and forwarded into MPLS with the VPN label; the reverse direction encapsulates into SRv6. Do not stack SRv6 and MPLS headers end to end. For MTU, the interworking PE must be the controlled fragmentation/clamping point: set the SRv6 tunnel MTU to account for the outer IPv6 header, clamp TCP MSS to 1,360–1,400 for 1,500-byte access, and allow ICMPv6 PTB. Legacy PE access ports stay at 1,500; core MTU 9,000 is fine. Migrate region by region, starting with low-risk VPNs, and verify with display bgp vpnv4, display segment-routing ipv6 locator, and end-to-end large-packet tests.