So I went an put Procurves in at both sites, its so far completely stable, no CRCs or FCS errors. Im attributing this to mikrotiks historic negotiation issues.
I wish everybody would just use whatever it is HP uses, Ive had negotiation issues with various vendors and environments over the years with the exception of HP gear, it always seems to just work On Wed, Jul 19, 2017 at 8:31 PM, Steve Jones <[email protected]> wrote: > Id rather wait a little for a hello than have reconvergence across the > network any day. Granted that attitude comes from a long time ago on a > tranzeo based layer 2 network where they implemented rstp but got greedy > and adjusted timers, those were awful days, just awful. > I have a support ticket with saf going, i chose mikrotik because of the > features at the cost, i knew going into it mikrotik is a little bugomatic > factory. This only becam an issue after pulling the hp switches between the > radios and router when i took the layer 2 component off the distribution > network. > Lower cost routers come with an increased toolset of bandaids and fukitol > > On Jul 19, 2017 7:06 PM, "Chris Wright" <[email protected]> wrote: > >> This right here. There is still a much bigger underlying problem, and >> putting OSPF on the bridge is only a palliative fix. >> >> >> >> Chris Wright >> >> Network Administrator >> >> >> >> *From:* Af [mailto:[email protected]] *On Behalf Of *Adam Moffett >> *Sent:* Wednesday, July 19, 2017 3:57 PM >> *To:* [email protected] >> *Subject:* Re: [AFMUG] flapping ethernet port ospf workaround >> >> >> >> OSPF didn't lose the neighbor, but you still want to fix the ethernet >> issue. >> >> >> >> One thing that could be an issue is if you want OSPF to fail over to a >> secondary path. If the interface goes down, then the router knows >> instantly that something is wrong and convergence can start right away. If >> the path is down while the interface stays up, then the router has to wait >> for hello packets to time out before it's aware of the issue. >> >> >> >> The default dead timer is 40 seconds, so the "it's down but I don't know >> yet" condition has to last at least that long before the router takes >> action. >> >> >> >> >> >> ------ Original Message ------ >> >> From: "Steve Jones" <[email protected]> >> >> To: "[email protected]" <[email protected]> >> >> Sent: 7/19/2017 3:03:11 PM >> >> Subject: Re: [AFMUG] flapping ethernet port ospf workaround >> >> >> >> if this doesn't harm anything, I'm thinking I may make this the standard, >> its flapped 24 times since I put it in, not a single ospf drop >> >> >> >> On Wed, Jul 19, 2017 at 1:54 PM, Chris Wright <[email protected]> >> wrote: >> >> I’ve had to run OSPF on a bridge in a pinch, and so long as you don’t >> make any live changes to the bridge (adding/removing interfaces), the >> Mikrotik won’t mind. Just remember to set your static OSPF interfaces (if >> you have any) accordingly. Same goes for MPLS – LDP Interfaces if you’re >> using it. If you’re thinking it’ll be like this for longer than a week, >> leave yourself plenty of documentation to backtrack properly. Nothing like >> coming back to it three months later and trying to remember what you did! >> >> >> >> Chris Wright >> >> Network Administrator >> >> >> >> *From:* Af [mailto:[email protected]] *On Behalf Of *Steve Jones >> *Sent:* Wednesday, July 19, 2017 9:21 AM >> *To:* [email protected] >> *Subject:* [AFMUG] flapping ethernet port ospf workaround >> >> >> >> So ive been dealing with the SAFs and the mikrotiks being uppity with one >> another. >> >> SAF has a gigabit port, but it only offers the option to lock it to 100, >> not gigabit. >> >> so I have the mikrotiks set, just not the otherside, the port still flaps >> on both radios >> >> >> >> what was happening is everytime it flaps, the interface dropped in ospf >> and went neighbor down, rerouting traffic then coming back up >> >> >> >> what I did was made a bridge, added that port to it, and put the ospf ip >> on the bridge itself, this allows the port to flap without the ospf >> interface going down until we work throught the issue with SAF >> >> >> >> I'm wondering if this is causing some other harm having it on the bridge, >> rather than the physical port >> >> >> >>
