The resolution is close. It was the port on the RB951 that fed the SXT that was fried, along with the aforementioned power supply for the SXT. The SXT and the cable tested OK (still don't understand why the SXT's wireless link showed as dead).
The 951 ports were full, and I didn't have any spare 951s in stock, so I did some handwaving to route the SXT traffic through an attached hEX that had spare ports. Thanks for the help. > On Jan 19, 2018, at 4:10 AM, Scott Reed <[email protected]> wrote: > > The port on the SXT got fried with the power supply. Whatever happened is > causing it to echo the other MAC address. > > > On 1/18/2018 11:10 PM, Grand Avenue Broadband wrote: >> More accurately, "I'm my own neighbor." This one has me buffaloed. >> >> MikroTik neighbor protocol claims that the "neighbor" of port 3 is… port 3. >> This is not just awkward, but it really p*s off OSPF. >> >> >> >> Physically, port 3 is attached to a single cable that runs up a mast to an >> SXT 5 lite configured as a "layer 2 bridge" to another location. I run >> cable test and MikroTik claims the cable is fine. >> >> I went out to the site today (90 min one-way) and discovered the power >> supply for the SXT was fried (plus the mast cable had popped out of the POE >> injector at some point). I replaced it, and the neighbor table properly >> reported the presence of the SXT. Hooray! >> >> I was able to talk to the SXT via ROMON while I was onsite. It had >> established a good wireless connection to its partner SXT, but I still >> couldn't get actual routes established through it, and couldn't figure out >> why. The wireless link stayed up solid except for two occasions on which I >> rebooted the local SXT, once to upgrade the OS to match everybody else, and >> once for some reason I don't recall. This is the log from the far end. >> >> >> >> After some time unable to find an obvious routing issue (using the same >> configuration that has been working there for two years) I ran out of time >> and made the return trip. When I got back to the office and logged in >> remotely to continue the debug, I found that the neighbor table had reverted >> back to its old tricks, reporting the port's own MAC address as its own >> neighbor. Furthermore, the SXT at the far end reports the wireless link >> went dead right about the time I was halfway home, which I bet is when the >> neighbor folly reintroduced itself. Talk about a case of mechanic-itis. >> >> Has anybody seen anything like this before? Does anybody have any ideas? >> > > -- > Scott Reed > SBRConsulting, LLC > WISPA Vendor Member > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://mail.butchevans.com/pipermail/mikrotik/attachments/20180119/44373c9d/attachment.html > > <http://mail.butchevans.com/pipermail/mikrotik/attachments/20180119/44373c9d/attachment.html>> > _______________________________________________ > Mikrotik mailing list > [email protected] <mailto:[email protected]> > http://mail.butchevans.com/mailman/listinfo/mikrotik > <http://mail.butchevans.com/mailman/listinfo/mikrotik> > > Visit http://blog.butchevans.com/ <http://blog.butchevans.com/> for tutorials > related to Mikrotik RouterOS -- Grand Avenue Broadband -- Wireless Internet Service Circle City to Wickenburg and surrounding areas http://grandavebb.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.butchevans.com/pipermail/mikrotik/attachments/20180130/7d4b75b3/attachment.html> _______________________________________________ Mikrotik mailing list [email protected] http://mail.butchevans.com/mailman/listinfo/mikrotik Visit http://blog.butchevans.com/ for tutorials related to Mikrotik RouterOS
