[c-nsp] ospf database size - affects that underlying transport mtu might have

Randy randy_94108 at yahoo.com
Thu Nov 23 18:39:15 EST 2017

Yes. If neighbor adjacency gets hosed at Exchange-Start, MTU is more than likely; the culprit.
Ip ospf mtu-ignore can be used to confirm. IMO, bad to have this in place in a production-env; special-cases notwithstanding.

From: Aaron Gould <aaron1 at gvtc.com>
To: cisco-nsp at puck.nether.net 
Sent: Wednesday, November 22, 2017 9:52 AM
Subject: [c-nsp] ospf database size - affects that underlying transport mtu might have

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 ?  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 ? .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



cisco-nsp mailing list  cisco-nsp at puck.nether.net


archive at http://puck.nether.net/pipermail/cisco-nsp/

More information about the cisco-nsp mailing list