06-29-2024 07:43 AM
Hello
So I have DSL 40/5 Service and for the past 2 years I have had no issues. As of this past 3 weeks I have these insane lag spikes. It could stay normal for 30 minutes or 5 hours, then it happens. My 30ms goes to 2000-3000 ms. It either will not go back down, or will after a while. I have removed every device except the ISRC1111 and the PC plugged into it, same thing. Currently my DSL Modem is in Bridge mode and ISR is doing PPPoE.
To test it, I eliminated everything Cisco and simply used my DSL Modem in PPPoE and 2 days went by 0 issues and my continuous ping stayed 30-60 ms. With that said, when using my ISR C1111 as PPPoE and the lag starts, if I reboot the ISR it all goes back to normal...for 30 mins maybe or several hours.
I really do not know how to troubleshoot this, especially when all in same exact config has been fine. Also, even doing the traceroute and ping ON the ISR, same madness.
What all would be needed from me to help in helping me figure it out?
Solved! Go to Solution.
07-04-2024 11:43 AM
Hits: 25561608 Misses: 37922
In-to-out drops: 2058 Out-to-in drops: 1046
these two count is showing the NAT is exhausted or you config timeout not correct
MHM
07-04-2024 11:55 AM
With that said, I can’t find which thread it was, but one of my more recent ones, we had me set my timeouts lower…. Not sure if same timeouts… it would be in my running-config I posted. As far as cables, yes I did I have all new Cat 8 (just cause) cables . Nice good quality
07-04-2024 12:18 PM
get it,
make timeout to it default value
cisco not recommend to change the timeout except in some case
MHM
07-04-2024 12:46 PM
I recall you having an issue with NAT using all available translation for PAT. As I recall, this is the reason the tcp and udp timeout was lowered for NAT translations.
07-04-2024 01:47 PM
Yeah I believe I initiated it but I remember there was one concern of me being “attacked” and then my internet timing out at random. I’ll have to go back and really read why we lowered it for what specific. But you are right. I am wondering, did I change existing timeouts or did we put them in place which made new timeouts? Like, would a default setting even show up in the running-config if it was set to default? I’ll have to go and see which ones and how to change them to default
07-04-2024 11:49 AM
The show process cpu doesn't seem to me to be a problem. Also show ip traffic seems ok.
Have you tried replacing all patch cables in the communication path?
07-04-2024 03:27 PM
Seems I can not find what the “default” values were. Are these correct?;
ip nat translation tcp-timeout 500
ip nat translation udp-timeout 30
ip nat translation dns-timeout 30
ip nat translation icmp-timeout 30
ip nat translation finrst-timeout 30
ip nat translation syn-timeout 30
ip nat translation max-entries 1000
07-04-2024 03:37 PM
07-06-2024 11:40 AM
Would this 2000-3000 ms Ping, and time-outs cause any CRC or FEC Errors to build up as well by any chance [while it is pinging out]
07-06-2024 12:12 PM
you see CRC or FEC? if you see these error then it cable issue
MHM
07-06-2024 02:53 PM - edited 07-06-2024 03:06 PM
I am trying to find out where the CRC's are.
ISP ---[Copper vDSL]---C4000 Router (Bridge Mode)----CAT 8 75'------Cisco ISR1111
I can not say I am seeing CRC on the ISR logs, but from my ISP side I am getting maybe 10-20 every few hours. So I am wondering are the CRC's from ISP to DSL Router, or DSL Router to ISR C1111.
Also, I work for the ISP and so what I did was unplug everything at home except DSL Router to ISR and still had CRC's.. So I "eliminated" INSIDE CRMC.. Just need to determine which segment.
07-06-2024 03:08 PM
Can you share the output of show interface Gi0/0/0 ?
07-06-2024 04:29 PM
I assume this would suggest DSL Router to ISR is "clean" also suggesting my CRC's are ISP top DSL Router?
Also, I made these changes... But did not see 'udp-timeout' on the link given earlier so I made it 60?;
ip nat translation tcp-timeout 86400
ip nat translation udp-timeout 60
ip nat translation syn-timeout 60
ip nat translation dns-timeout 60
ip nat translation icmp-timeout 60
ip nat translation max-entries 200000
GigabitEthernet0/0/0 is up, line protocol is up
Hardware is C1111-2x1GE, address is 00ea.bded.c480 (bia 00ea.bded.c480)
Description: WAN
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not supported
Full Duplex, 1000Mbps, link type is auto, media type is RJ45
output flow-control is off, input flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:02, output hang never
Last clearing of "show interface" counters never
Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 1143000 bits/sec, 242 packets/sec
5 minute output rate 1274000 bits/sec, 273 packets/sec
86802657 packets input, 86630420180 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 180450 multicast, 0 pause input
66890459 packets output, 13493769995 bytes, 0 underruns
Output 2 broadcasts (0 IP multicasts)
0 output errors, 0 collisions, 1 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
07-07-2024 09:31 AM
How and on what device are you seeng CRC? If it's on the C4000 router, then I assume the CRC's are related to the VDSL interface which are normal given the nature of the technology used.
Looking at the show interface gi0/0/0 from you ISR, I can say that the segment between the ISR and your C4000 Router is OK.
07-07-2024 09:53 AM
I never know what is widely n own information or just company specific, but as a tech I can do something called a POLL DSLAM which checks the DSLAM, customer or every customer stats. If I monitor my line, it naturally just shows ISP to C4000 CRC so yeah I assume it is just that segment. I am happy to see 0/0/0 shows good. I made those timeout adjustments based on the website defaults, saw no udp timeout so did it 60.. hopefully this clears things up.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide