Make sure it's not broadcast ospf, I believe that's the default. If one side flaps it goes away til the other side either reboots or ospf disables/enables
On Jul 5, 2017 11:25 PM, "George Skorup" <[email protected]> wrote: > No, not the L2 MTU. The L3 (IP) MTUs must match on the router interfaces > speaking OSPF. > > I have zero experience with SIAE gear, but being a licensed radio, I > imagine it has an integrated ethernet switch. I've seen a fair number of > switches go stupid. If you can run 1500 byte pings across the link with no > loss, then I'd assume both L2 and L3 should work as expected. However, that > doesn't mean something isn't screwing with multicast, which OSPF obviously > needs. > > On 7/5/2017 10:15 PM, Jason McKemie wrote: > > I checked, all MTUs on these links are the same. The L2 MTU, however, is > not. Does this have any effect? > > On Wed, Jul 5, 2017 at 10:12 PM, Jason McKemie < > [email protected]> wrote: > >> No errors or packet loss. Strangely, it seems to be preferring the >> Rocket M5 backhaul over the SIAE 11GHz link. The MTU on both ends of the >> link has remained at default on these. I'll double check, but unless it >> changed itself it should be the same. >> >> On Wed, Jul 5, 2017 at 8:13 PM, George Skorup <[email protected]> >> wrote: >> >>> Errors or packet loss? Something rate limiting multicast? Has someone >>> recently changed MTUs? I don't know if RouterOS will even log OSPF MTU >>> mismatches. Never tried it. If the IP/L3 MTUs don't match, then OSPF is not >>> gonna have a good time. OSPF relies on IP since there is no native >>> fragmentation in the protocol. >>> >>> As far as NTP and/or accurate time, I haven't experienced any issues >>> with that in regards to OSPF. I discovered a router where the NTP process >>> appeared to have crashed and the clock was off by like 10 minutes. OSPF was >>> humming along with two neighbors for months and a third for hours because >>> the adjacent router was rebooted. >>> >>> On 7/5/2017 7:20 PM, Darin Steffl wrote: >>> >>> I also recommend only using bug fix release for mikrotik. Also make sure >>> you have clocks synced to an ntp source on every mikrotik router and that >>> it's accurate. >>> >>> On Wed, Jul 5, 2017 at 7:09 PM Jason McKemie < >>> [email protected]> wrote: >>> >>>> Thanks. I'll try 6.38.7 tonight. >>>> >>>> There haven't been many changes to the network, and every is pingable. >>>> I did add one static route for a Baicells eNB a week or two ago, but the >>>> problem cropped up more recently. I'll have to look into that a bit more. >>>> >>>> On Wed, Jul 5, 2017 at 6:59 PM, Chris Wright <[email protected]> >>>> wrote: >>>> >>>>> I recommend sticking to the Bugfix releases (currently 6.38.7). >>>>> >>>>> >>>>> >>>>> Did anything happen recently that could possibly have provoked the >>>>> disappearance like a VLAN or other L2/L3 change? Are the neighbors >>>>> pingable >>>>> on their backbone IPs? >>>>> >>>>> >>>>> >>>>> Chris Wright >>>>> >>>>> Network Administrator >>>>> >>>>> >>>>> >>>>> *From:* Af [mailto:[email protected]] *On Behalf Of *Jason McKemie >>>>> *Sent:* Wednesday, July 05, 2017 4:53 PM >>>>> *To:* [email protected] >>>>> *Subject:* [AFMUG] Mikrotik OSPF >>>>> >>>>> >>>>> >>>>> Has anyone seen issues with Mikrotik OSPF neighbors just disappearing >>>>> for no apparent reason? All of my links are ok, but I OSPF just isn't >>>>> picking anything up on one of them. I might try upgrading both of the >>>>> Mikrotiks involved, this feels like a bug. I have 6.38.5 on one end and >>>>> 6.38 on the other, both CCR's. >>>>> >>>> >>>> -- >>> Darin Steffl >>> Minnesota WiFi >>> www.mnwifi.com >>> 507-634-WiFi >>> <http://www.facebook.com/minnesotawifi> Like us on Facebook >>> <http://www.facebook.com/minnesotawifi> >>> >>> >>> >> > >
