That would be me. :-P It wasn't FCS errors though, it was 'jabber' errors received on the far end:
> On two CCR1036s, connected to a outside circuit using 1310nm 1000base-LX > modules, > we see ~2% packet-loss on traffic we send out. Inbound traffic is fine. > > The provider claims to be seeing 'jabber' errors from us on their > Alcatel-Lucent Ethernet > platform, which sits behind an Infinera DTN transport loop. They connected a > JDSU > test set, and could not replicate the problem; either with their JDSU facing > them > while emulating us, or facing us while emulating them. We also cannot > replicate > the issue when connecting those routers to other circuits/equipment. A > multitude > of different SFP optics were tried, from multiple vendors (MT included, also > Finisar, MemoryDealers, Dell, and FiberStore); no difference was seen. > > The really strange thing is that another CCR1036 works just fine on this > circuit. > We base-lined all of the CCRs involved on ROS v6.25 with RouterBoot v3.21, > although we did try other versions as well, including ROS v6.28; no > difference was > seen. > > The only difference that really stands out is the serial numbers, with the > single > CCR1036 that works fine having a much lower SN: > > CCR1036 that works: 42A2xxxxxxxx > CCR1036 that doesn't: 5AA6xxxxxxxx > CCR1036 that doesn't: 529Cxxxxxxxx IIRC, the Infinera had no complaints. MT support returned this: ''' nothing major has been changed on this CCR unit during it's manufacturing cycle regarding the SFP interfaces. Either way after a talk with our engineers it was agreed that RMA would be required for these two newer units to figure out what is different in them from that older one. In order to fix it the SFP interface problem. Please return them to your supplier for warranty service. ''' I don't think we ever actually RMA-ed the unit, and we ended up de-commissioning the circuit shortly afterwards, and didn't pursue the issue. --Eric -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Nathan Anderson Sent: Monday, January 30, 2017 2:01 PM To: [email protected]; 'Adam Moffett' Subject: Re: [Telrad] Ethernet RX FCS errors from BreezeWay? re-deployed; ugh -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Nathan Anderson Sent: Monday, January 30, 2017 1:56 PM To: [email protected]; 'Adam Moffett' Subject: Re: [Telrad] Ethernet RX FCS errors from BreezeWay? One thing that occurs to me: We've never explicitly heard about MT making unannounced changes and revisions to the 1036 hardware, but they have been known to do that kind of thing to other RBs in the past, and we actually have seen differing behavior and performance on the 1036 *SFP* ports between different CCRs purchased at different times, running the exact same OS and RouterBOOT versions. (I don't have all of the details, since this was a problem that my co-worker largely chased down, so I'll have to ask him, but as a real-world example, we had 2 1036s connected to 2 separate circuits provided by the same upstream provider where one of them was taking errors on the SFP interface, and we thought it was 100% the provider's problem on that circuit since we swapped the CCR once and it didn't fix it. I think we also tried replacing the SFP module to no avail. But the replacement CCR was of a similar manufacturing batch as the one that got swapped out [serial #s and MAC addresses were very close], so on a whim, we found another CCR to replace it with -- an OLDER one -- that matched more closely the serial of the CCR that was connected to the other circuit that was working fine, and when we swapped that router out a second time with that older CCR, the problem disappeared. Note that we had plenty of other 1036s from that same "bad" batch connected to other fiber paths tha t showed no symptoms, and we have re-reployed the 1036s we tried on this particular circuit to other locations and they are also working fine. It was a weird combination of THAT circuit from THAT provider connected to THAT generation of 1036.) The 1036 currently connected to our BreezeWay is a new-ish one with a MAC bearing OUI 4C:5E:0C. The OUI of the 1036s that had problems with their SFP connected to a specific circuit was D4:CA:6D. The OUI of the 1036s whose SFP interface worked fine with that particular provider and circuit was the original MikroTik 00:0C:42 -- so presumably some of the first 1036s to come off of the assembly line. I don't think we have any of those 00:0C:42 1036s sitting out of service right now, so I can't try swapping with one of those. But it would be interesting to know what the MAC OUIs are of 1036s that others on this list are successfully using hooked up to a BreezeWay. -- Nathan -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Nathan Anderson Sent: Monday, January 30, 2017 1:29 PM To: 'Adam Moffett'; [email protected] Subject: Re: [Telrad] Ethernet RX FCS errors from BreezeWay? Interesting; thanks. Ours is also on OS 6.32.3, RB firmware 3.21 (which appears to be the version bundled with 6.32.3). Same BreezeWay firmware version. We just upgraded the BW to this release recently, and I wondered if it might be related, but then I looked at past logs and saw that this was also happening with firmware 00729. So that wasn't it. -- Nathan -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Adam Moffett Sent: Monday, January 30, 2017 4:18 AM To: [email protected] Subject: Re: [Telrad] Ethernet RX FCS errors from BreezeWay? We also have the Breezeway connected to a CCR 1036. I'm not seeing FCS errors. Breezeway port 9 connected to CCR ether4. The CCR ethernet port is all at default settings. Breezeway SW version 0606.02151 RouterOS 6.32.3 ------ Original Message ------ From: "Nathan Anderson" <[email protected]> To: "[email protected]" <[email protected]> Sent: 1/30/2017 2:37:27 AM Subject: [Telrad] Ethernet RX FCS errors from BreezeWay? >We have recently noticed a new problem: we have an access port on our >BreezeWay (in this case, so happens it's the BW's port 10, but may not >be relevant) that is plugged into a MikroTik CCR 1036. The MikroTik is >reporting that it is sporadically seeing FCS errors on frames received >from the BreezeWay. I have replaced the ethernet cable and also tried >moving to a different ethernet port on the CCR. Neither has made a >difference. > >I'm wondering if there is any way I can see any ethernet stats or >diagnostic information from the BreezeWay's perspective. In my poking >around, so far I have come up empty. > >I'm not necessarily convinced at this point that this is the >BreezeWay's fault, mind you. I'm just wondering if anybody else has >seen something similar, and how to best go about chasing this problem >down. My perception is that the CCRs in particular have had a troubled >history when it comes to its copper gig ports...search for "Ubiquiti >AirFiber MikroTik CCR" if you want some fun afternoon light reading. > >Thanks, > >-- >Nathan Anderson >First Step Internet, LLC >[email protected] > >_______________________________________________ >Telrad mailing list >[email protected] >http://lists.wispa.org/mailman/listinfo/telrad > _______________________________________________ Telrad mailing list [email protected] http://lists.wispa.org/mailman/listinfo/telrad _______________________________________________ Telrad mailing list [email protected] http://lists.wispa.org/mailman/listinfo/telrad _______________________________________________ Telrad mailing list [email protected] http://lists.wispa.org/mailman/listinfo/telrad _______________________________________________ Telrad mailing list [email protected] http://lists.wispa.org/mailman/listinfo/telrad _______________________________________________ Telrad mailing list [email protected] http://lists.wispa.org/mailman/listinfo/telrad
