Init State After an MTU Change on a Point-to-Point Core Link
Two 7750 SR routers, R1 (SR-12) and R2 (SR-7), are connected by a 10G point-to-point core link. Both interfaces run IS-IS level 2 only, with default hello timers (10/30) and default hello padding. After a transport team changed the MTU on R1's interface from 9212 to 1600 to match a new Ethernet circuit, the adjacency dropped. It now sits in 'Init' on R2, while R1 shows the neighbor as 'Down'. R2 still reports MTU 9212. Authentication is not configured, and both routers show the correct ISO interface in show router isis interface. The link is the only path between two aggregation domains, and production traffic is down. The transport provider cannot raise the MTU on the new circuit, so R1 must stay at 1600. The design requires IS-IS level 2 to remain up.
1. Explain what the 'Init' state on R2 proves about the hello exchange, and why the MTU asymmetry produces one-way adjacency state rather than keeping both routers Down.
Read the worked answer
'Init' means R2 has received a valid IIH from R1 and found its own system ID in R1's neighbor list, but R1 has not received a usable IIH from R2. The direction that works is R1 to R2: R1's hello is padded to its 1600-byte interface MTU and therefore fits R2's 9212-byte MTU. The direction that fails is R2 to R1: R2 pads its hello to 9212 bytes, which exceeds R1's 1600-byte interface MTU, so R1 drops the frame. IS-IS hello padding expands the PDU to the interface MTU, so an MTU mismatch becomes a hello-size mismatch. If R2's hello were smaller than 1600 bytes, R1 could process it; padding makes the mismatch fatal. This also explains why R2 is not Down: it sees a neighbor, but the neighbor does not see it. The state is asymmetric because only one side is receiving a usable hello. The fix must make the hello sizes interoperable, either by aligning MTUs or by removing padding on both sides; merely checking that the adjacency exists on one side is misleading.
2. List the SR OS checks and configuration changes you would use to restore the adjacency. State whether disabling hello padding is an acceptable permanent fix here.
Read the worked answer
First confirm the mismatch: on both routers run show port <port-id> detail | match MTU and show router isis interface "<intf>" detail. The IS-IS interface output shows hello padding and the interface MTU; show router isis adjacency detail shows the state and the neighbor's system ID. On R2, change the port MTU to 1600 with configure port <port-id> ethernet mtu 1600, then re-enable the port and IS-IS interface as required by the release. Changing MTU can reset the interface, so do it in a maintenance window even though the link is already down. If the hardware or transport cannot support 1600 at the port level, disable hello padding under the IS-IS interface on both routers (configure router isis 0 interface "<intf>" hello-padding false, or the equivalent no hello-padding in that context) and verify the adjacency reaches Up. However, disabling padding is not a full fix: R2 can still send an LSP larger than 1600 bytes that R1 will drop. Therefore the permanent solution is to align interface MTU, or to constrain LSP size and accept the operational risk. After the change, clear the adjacency and confirm both routers show Up and install the expected routes.
3. A colleague suggests changing only R2's IS-IS hello padding and leaving R2's port MTU at 9212. What remaining risk would you document, and how would you verify it?
Read the worked answer
The remaining risk is LSP MTU, not hello MTU. With padding removed, R2's hellos become small enough for R1, so the adjacency should come Up. But R2's interface still accepts and may emit frames up to 9212 bytes. If an LSP, CSNP, or PSNP exceeds 1600 bytes, R1 will drop it. The LSDB can then remain incomplete or flooding can stall, which is harder to diagnose than a down adjacency because the neighbor stays Up. Verify by examining show router isis interface "<intf>" detail for the actual interface MTU, and show router isis database detail for LSP sizes. Generate or inspect the largest LSPs in the level; if any approach 1600 bytes, the design is unsafe. Also check show router isis statistics for dropped PDUs or retransmissions. The documented position should be: padding removal restores hellos, but MTU alignment is required for reliable flooding. If the provider cannot raise the circuit MTU, set R2's port MTU to 1600 and keep padding enabled, which removes both the hello and LSP size mismatch.