Ah, great suggestion, but it's not the 889 days thing (uptime is only 17 weeks). That said, this does remind me again that the ASRs are sometimes finicky about interfaces going down and require the occasional reboot to fix. The only reason I'm shying away from the ASR as the problem is because lots of interfaces on the ASR went down due to customers connected to it losing power at the same time and this is the only interface that hasn't come back up. Possibly poor reasoning on my part because I should know by now that the most important interface on the router is the one most likely to have a problem and not work because that's how this miserable world works.
I guess I'm hoping someone can point me to internal counters on either device that might show how far the packet is getting as it traverses the fabric. I just don't know enough about the hardware counters to know what to look at. -evt On 12/4/20, 8:53 AM, "Jason Lixfeld" <[email protected]> wrote: EXTERNAL - Do not click links or open attachments from an unverified source/sender. Maybe it’s not the NCS? If your ASR920 was unaffected by the power event, and it’s been up for 889 days, is it possible you’re seeing this? https://www.mail-archive.com/[email protected]/msg66833.html > On Dec 4, 2020, at 8:47 AM, Eric Van Tol <[email protected]> wrote: > > Hi again, > We have an NCS540 (IOS-XE 7.1.1) where an unexpected reboot occurred the other night, which also highlighted my inability to log in via direct console in an earlier thread. I have this router connected directly to an ASR920-24 via 10G port, both using the same optics, 10G-LR. Between the two, running IPv4 and IPv6, IS-IS and LDP. As mentioned, we had an unexpected reload due to power issues at the site on Wednesday and once the NCS rebooted, the link between the two routers came up, but is not passing traffic anymore. There are other interfaces on the NCS that are working just fine with the same original config and no config changes happened upon reload to affect things. > > I am unable to ping between them on either side of the connection, no incoming packets, no ARP resolution. I’ve tried shut/no shut, reconfiguration and finally, removing the entire interface config and just setting them both up as routed interfaces to simplify everything, as they were previously set up as trunk interfaces. No ACLs are on either side, no immediately visible errors on either side and no other interfaces are experiencing this behavior. Again, the physical link is up and DOM shows fine RX levels on either side. I’d like to avoid rebooting the entire router, but maybe that’s my only option. Are there any debugging options, logs or platform counters I can look at to see a bit deeper under the hood, so to speak, to try and narrow down why this link that is up is not able to pass traffic? Interface configs below, but are just dead simple (changing to mask to /30 doesn’t do anything, either): > > NCS: > interface TenGigE0/0/0/23 > ipv4 address x.x.x.64 255.255.255.254 > > ASR: > interface TenGigabitEthernet0/0/24 > ip address x.x.x.65 255.255.255.254 > end > > Bug Search tool doesn’t show anything that I can see that describes this behavior. Any suggestions besides re-seating the SFP, which I’ve already put in a request internally to have completed? > > -evt > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
