ospf database size - affects that underlying transport mtu might have

[surfer at mauigateway.com (Scott Weeks)]

--- nanog at nanog.org wrote:
From: Richard Vander Reyden via NANOG <nanog at nanog.org>

> This is a *single area* ospf environment, that has been 
> stable for years. But now suddenly is having issues with 
> new ospf neightbor adjacencies , which are riding a 3rd 
> party transport network 

>> I have seen this in the lab before, was related to the 
>> size of the LSA. 
---------------------------------------------------


Wouldn't this show in some SNMP OID that can be 
monitored?  If nothing else, fragmentation (see 
below).  Also, how big was the LSA?  It should 
be able to be pretty big.  According to:

https://supportforums.cisco.com/t5/service-providers-documents/ospf-and-mtu/ta-p/3118885

"RFC 2328 (OSPF version 2 specification) says...If 
necessary, the length of OSPF packets can be up to 
65,535 bytes (including the IP header).  The OSPF 
packet types that are likely to be large (Database
Description Packets, Link State Request, Link State 
Update, and Link State Acknowledgment packets) can 
usually be split into several separate protocol 
packets, without loss of functionality.  This is 
recommended; IP fragmentation should be avoided 
whenever possible."

scott