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
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 ?
Yes. Easy to check with a ping sweeping a range of sizes and DF set.
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
Not likely. How many routers and are things relatively stable in terms of routes changing?
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.
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 ?
You can check this with a ping of your mtu size set with the df bit set
.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
If you have a large amount of routers in your area the LSA size will grow, we saw a problem in testing when we injected 2000 prefixes into the area and the OSPF neighbour would not come up. On a cisco router you can set 'buffers huge' as a work around.
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.