[c-nsp] NCS540 - Interface up, not passing traffic
Eric Van Tol
eric at atlantech.net
Fri Dec 4 10:09:33 EST 2020
Yeah, I've also had weird experiences with the ASR, but the difference here is that the port is up on both sides, and consistently comes up when the interface is shut/no shut, whereas in every instance we've had such weirdness, the port would not come up at all on the ASR. Definitely not ruling it out, it's just different behavior than I've seen before. Regardless, I'll keep the ASR in mind as a possible source of the problem.
evt
On 12/4/20, 9:38 AM, "cisco-nsp on behalf of Shawn L" <cisco-nsp-bounces at puck.nether.net on behalf of shawn at rmrf.us> wrote:
EXTERNAL - Do not click links or open attachments from an unverified source/sender.
I'll second that one -- check the ASR920. I've seen instances where I
needed to physically remove the SFP, wait a minute, replace it, wait a
couple of minutes and then things came back up.
On the power front, we had a 920 (12SZ) at a remote location that had
several brown-outs, and then lost power. The 920 had one psu plugged into
a UPS, and the other directly into the wall. When the power came back on we
couldn't see it remotely. When we got on-site, everything looked fine, all
the lights were on, link lights, etc. But the far end still said the link
was down. When we consoled in, errors were scrolling across the screen.
Rebooted and everything came up.
I guess where I'm going with this is that the 920 can be weird. Don't
discount that it could be the one having the issue. I really like the 920
platform. Now if was only stable......
Shawn
On Fri, Dec 4, 2020 at 9:09 AM Eric Van Tol <eric at atlantech.net> wrote:
> 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" <jason at lixfeld.ca> 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/cisco-nsp@puck.nether.net/msg66833.html
>
> > On Dec 4, 2020, at 8:47 AM, Eric Van Tol <eric at atlantech.net> 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 cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
_______________________________________________
cisco-nsp mailing list cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp
mailing list