- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- OSPF to Cisco FULL/DR but CP not sending routes LS...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OSPF to Cisco FULL/DR but CP not sending routes LSU TooLow/LSAck TooLow
Hi
I cant see these anywhere in RFC or documentation - anyone know what they mean?
I know the description from sk95968
LSU TooLow Neighbor state is too low to accept this packet type
LSAck TooLow Neighbor state is too low to accept this packet type
But how to fix?
I have seen it once before in 2022 where the peer was a nexus and it was resolved with “Layer-3 peer router” command on nexus switch under VPC to solve the problem.
I guess this will be the linux/red-hat part of OS?
Thanks
Ian
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ok fixed it - they were using area1 which I assumed was connected to area0 on the provider side, but its not. So we changed to area 0 both sides, and although neighborshps were up, and we learned routes from Cisco we now see our routes routes learned by Cisco too.
We also saw messages that link to sk102369 in routed_messages when debug was running - but there is no ipv6 on the interface.
So now I have seen two strange tickets for
LSU TooLow Neighbor state is too low to accept this packet type and;
LSAck TooLow Neighbor state is too low to accept this packet type
I can only assume its the system trying to tell you something isn't right but not having a better way to do it in the code.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is the peer set for point-to-point network type?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
good call - will check - thanks!
we have policy allowing traffic and no zebug drops - I just checked the resolution notes on my last ticket so will get full packet capture also;
"The Nexus was sending ttl-exceeded icmp packets back to the checkpoint in response to the checkpoint DD ospf packets (which have a ttl of 1). traceroute to the nexus peers showed two hops (despite being in same vlan). The issue was resolved by the customer configuring 'layer-3 peer router' on the nexus under vpc."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Also looks like the Cisco sends LLS TLV type 32768 in the Hello packet - I don't think we know what that is. I saw this;
ASA won't become full with ISR 4400 router - Cisco Community
And a colleague found a cpug post about policy blocking it - I didn't think we were but checking this SK I will make sure and feedback;
sk39960 - How to allow Dynamic Routing protocols traffic (OSPF, BGP, PIM, RIP, IGRP) through Check P...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ok fixed it - they were using area1 which I assumed was connected to area0 on the provider side, but its not. So we changed to area 0 both sides, and although neighborshps were up, and we learned routes from Cisco we now see our routes routes learned by Cisco too.
We also saw messages that link to sk102369 in routed_messages when debug was running - but there is no ipv6 on the interface.
So now I have seen two strange tickets for
LSU TooLow Neighbor state is too low to accept this packet type and;
LSAck TooLow Neighbor state is too low to accept this packet type
I can only assume its the system trying to tell you something isn't right but not having a better way to do it in the code.
