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

[Randy]

Hi,
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.
./Randy



________________________________
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




-Aaron




_______________________________________________

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

https://puck.nether.net/mailman/listinfo/cisco-nsp

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