Mailing List Archive: NCS540 - Interface up, not passing traffic

NCS540 - Interface up, not passing traffic

Dec 4, 2020, 5:47 AM

Post #1 of 9 (1159 views)

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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: NCS540 - Interface up, not passing traffic [ In reply to ]

jason at lixfeld

Dec 4, 2020, 5:53 AM

Post #2 of 9 (1159 views)

Permalink

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@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@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: NCS540 - Interface up, not passing traffic [ In reply to ]

eric at atlantech

Dec 4, 2020, 6:07 AM

Post #3 of 9 (1159 views)

Permalink

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@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@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@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: NCS540 - Interface up, not passing traffic [ In reply to ]

shawn at rmrf

Dec 4, 2020, 6:36 AM

Post #4 of 9 (1159 views)

Permalink

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@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@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@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@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@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: NCS540 - Interface up, not passing traffic [ In reply to ]

eric at atlantech

Dec 4, 2020, 7:09 AM

Post #5 of 9 (1159 views)

Permalink

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@puck.nether.net on behalf of shawn@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@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@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@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@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@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@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: NCS540 - Interface up, not passing traffic [ In reply to ]

gert at greenie

Dec 4, 2020, 8:24 AM

Post #6 of 9 (1159 views)

Permalink

Hi,

On Fri, Dec 04, 2020 at 03:09:33PM +0000, Eric Van Tol wrote:
> 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.

Try enabling LLDP or CDP and see if you can see anything.

Try looking on the "show int ten... accounting" counters to see if
either side receives what the other side claims to be sending.

The link might be good, but the IP layer might be confused... or
one side might be sending ok, but not receiving anything.

Counters good.

gert

--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de

Re: NCS540 - Interface up, not passing traffic [ In reply to ]

eric at atlantech

Dec 4, 2020, 8:39 AM

Post #7 of 9 (1159 views)

Permalink

Also great suggestions, but to no avail. 0 packets input on either side. :(

I might be stuck with having to reboot one or both of these devices if the SFP re-insertion doesn't resolve it.

evt

?On 12/4/20, 11:24 AM, "Gert Doering" <gert@greenie.muc.de> wrote:

Hi,

On Fri, Dec 04, 2020 at 03:09:33PM +0000, Eric Van Tol wrote:
> 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.

Try enabling LLDP or CDP and see if you can see anything.

Try looking on the "show int ten... accounting" counters to see if
either side receives what the other side claims to be sending.

The link might be good, but the IP layer might be confused... or
one side might be sending ok, but not receiving anything.

Counters good.

gert

--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: NCS540 - Interface up, not passing traffic [ In reply to ]

gurbo at golas

Dec 4, 2020, 9:55 AM

Post #8 of 9 (1159 views)

Permalink

Hello,

If possible, replace SFP transceiver or try to use monitor-session on interface for capture traffic.
By my opinion your IOS XR version isn't good and "raw", try to upgrade. At the end this year expected 7.3.x, but I'm waitin 7.4.x....

Guess this command was viewed and nothing interesting founded.
RP/0/RP0/CPU0:xxx#show controllers tenGigE 0/0/0/20 all

May be some intresting information you can find here:
RP/0/RP0/CPU0:xxx#run
[node0_RP0_CPU0:~]$ls -la /var/log

On Fri, 4 Dec 2020 16:39:38 +0000
Eric Van Tol <eric@atlantech.net> wrote:

> Also great suggestions, but to no avail. 0 packets input on either side. :(
>
> I might be stuck with having to reboot one or both of these devices if the SFP re-insertion doesn't resolve it.
>
> evt
>
> ?On 12/4/20, 11:24 AM, "Gert Doering" <gert@greenie.muc.de> wrote:
>
> Hi,
>
> On Fri, Dec 04, 2020 at 03:09:33PM +0000, Eric Van Tol wrote:
> > 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.
>
> Try enabling LLDP or CDP and see if you can see anything.
>
> Try looking on the "show int ten... accounting" counters to see if
> either side receives what the other side claims to be sending.
>
> The link might be good, but the IP layer might be confused... or
> one side might be sending ok, but not receiving anything.
>
> Counters good.
>
> gert
>
> --
> "If was one thing all people took for granted, was conviction that if you
> feed honest figures into a computer, honest figures come out. Never doubted
> it myself till I met a computer with a sense of humor."
> Robert A. Heinlein, The Moon is a Harsh Mistress
>
> Gert Doering - Munich, Germany gert@greenie.muc.de
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

--
Alexandr Gurbo <gurbo@golas.ru>
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: NCS540 - Interface up, not passing traffic [ In reply to ]

eric at atlantech

Dec 9, 2020, 11:08 AM

Post #9 of 9 (1141 views)

Permalink

To all, thanks for the suggestions. This issue turned out to be the SFP. Re-seating it fixed the issue. I'll have to look into a possible upgrade if I can find that any SFP-related bugs are resolved in any releases higher than 7.1.1.

evt

?On 12/4/20, 12:56 PM, "Alexandr Gurbo" <gurbo@golas.ru> wrote:

EXTERNAL - Do not click links or open attachments from an unverified source/sender.

Hello,

If possible, replace SFP transceiver or try to use monitor-session on interface for capture traffic.
By my opinion your IOS XR version isn't good and "raw", try to upgrade. At the end this year expected 7.3.x, but I'm waitin 7.4.x....

Guess this command was viewed and nothing interesting founded.
RP/0/RP0/CPU0:xxx#show controllers tenGigE 0/0/0/20 all

May be some intresting information you can find here:
RP/0/RP0/CPU0:xxx#run
[node0_RP0_CPU0:~]$ls -la /var/log

On Fri, 4 Dec 2020 16:39:38 +0000
Eric Van Tol <eric@atlantech.net> wrote:

> Also great suggestions, but to no avail. 0 packets input on either side. :(
>
> I might be stuck with having to reboot one or both of these devices if the SFP re-insertion doesn't resolve it.
>
> evt
>
> On 12/4/20, 11:24 AM, "Gert Doering" <gert@greenie.muc.de> wrote:
>
> Hi,
>
> On Fri, Dec 04, 2020 at 03:09:33PM +0000, Eric Van Tol wrote:
> > 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.
>
> Try enabling LLDP or CDP and see if you can see anything.
>
> Try looking on the "show int ten... accounting" counters to see if
> either side receives what the other side claims to be sending.
>
> The link might be good, but the IP layer might be confused... or
> one side might be sending ok, but not receiving anything.
>
> Counters good.
>
> gert
>
> --
> "If was one thing all people took for granted, was conviction that if you
> feed honest figures into a computer, honest figures come out. Never doubted
> it myself till I met a computer with a sense of humor."
> Robert A. Heinlein, The Moon is a Harsh Mistress
>
> Gert Doering - Munich, Germany gert@greenie.muc.de
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

--
Alexandr Gurbo <gurbo@golas.ru>

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Mailing List Archive

Mailing List Archive

Attached Files: