ospf database size - affects that underlying transport mtu might have
Scott Weeks
surfer at mauigateway.com
Mon Nov 27 22:51:48 UTC 2017
--- 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
More information about the NANOG
mailing list