ospf database size - affects that underlying transport mtu might have

Tue Nov 28 00:47:00 UTC 2017

Em 22 de nov de 2017 3:53 PM, "Aaron Gould" <aaron1 at gvtc.com> escreveu:

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

Anyone ever experienced anything strange with underlying transport network
mtu possibly causing ospf neighbor adjacency to be broken ?

Yes, the neighbor state will loop between init/Exchange and it will never
become Full.
As others said, you need to test the MTU size without fragmentation and
adjust in your L3 interface (ping with DF-bit).

I'm

 asking if
the underlying 3rd party transport layer 2 network has a smaller mtu than
the endpoint ospf ip interface have, could this cause those ospf neighbors
to not fully establish ?

IMHO, Your transport network must support your Full 1500 bytes MTU. No one
want to deal with fragmentation. They need to activate jumbo frames to sell
L2 circuits.

.and I'm also asking this if the single ospf area
has grown large enough to cause some sort of initial database packet to be
larger than that underlying 3rd party mtu is providing

Its normal to have a LSADB bigger than MTU could support, and with correct
MTU this is not a problem.

Regards,

Rafael