Cisco IOS-XE: OSPF stuck in INIT - LLS TLV
I would like to take you guys to through the situation where you face the issue of getting OSPF stuck in INIT state. In this article I will describes how to troubleshoot the %ASA-4-409003: Received invalid packet: Bad LLS TLV length from 1.1.1.1, Open Shortest Path First (OSPF) error message.
Error Message Description
On newer version of IOS-XE you will observe OSPF adjacency stuck in INIT state because of LLS existing in OSPF packets. On ASA you will not see a neighbor at all but you will have following error messages as shown below:
OSPF: Send hello to 224.0.0.5 area 0 on outside from 20.20.0.2%ASA-4-409003: Received invalid packet: Bad LLS TLV length from X.X.X.X, outside
OSPF: Send hello to 224.0.0.5 area 0 on outside from 20.20.0.2%ASA-4-409003: Received invalid packet: Bad LLS TLV length from X.X.X.X, outside
Fig 1.1- OSPF INIT state
|
When you take packet capture on ASA you will see that the hello packet sent by (IOS-XE platform) will have an unknown TLV value which ASA will not able to understand due to which the adjacency will be stuck in INIT state.On IOS-XE you will as follows:
RouteXP_R1#show ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
20.20.0.2 1 INIT/DROTHER 00:00:39 20.20.0.2
Solution
Workaround is to apply ip ospf lls disable under OSPF interface configuration.
!
interface GigabitEthernet0/1/0
ip ospf lls disable
!
RouteXP_R1#show ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
20.20.0.2 1 FULL/DR 00:00:37 20.20.0.2
LLS allows for the extension of OSPF packets to provide additional bit space. The additional bit space enables greater information per packet exchange between OSPF neighbors.
This functionality is used, for example, by the OSPF Nonstop Forwarding (NSF) Awareness feature that allows customer premises equipment (CPE) routers that are NSF-aware to help NSF-capable routers perform nonstop forwarding of packets.
This type of behavior change is expected on 16.x releases only. To be more specific, new LLS TLV was added to ISO-XE from 16.5.1. It was done as part of OSPF SR TE unnumbered support and because of this the neighbor device ignores / rejects OSPF hello with the new LLS TLV.