nanog mailing list archives
RE: ospf database size - affects that underlying transport mtu might have
From: "Scott Weeks" <surfer () mauigateway com>
Date: Mon, 27 Nov 2017 14:51:48 -0800
--- nanog () nanog org wrote: From: Richard Vander Reyden via NANOG <nanog () 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
Current thread:
- ospf database size - affects that underlying transport mtu might have Aaron Gould (Nov 22)
- Re: ospf database size - affects that underlying transport mtu might have Jay Hennigan (Nov 22)
- RE: ospf database size - affects that underlying transport mtu might have Richard Vander Reyden via NANOG (Nov 27)
- Re: ospf database size - affects that underlying transport mtu might have Rafael Ganascim (Nov 27)
- <Possible follow-ups>
- RE: ospf database size - affects that underlying transport mtu might have Scott Weeks (Nov 27)