(usr-tc) RIPv2 CPU Issue
I've been using RIPv2 to allow our Cisco to route to our TCs, but I just noticed recently that RIP is a CPU hog on the Cisco. It is consuming around 60 percent of the CPU. Is there anything that can be done to decrease the amount of RIP updates that the TCs send? Is OSPF less of a pig? Should I segement things so that I proxy arp the regular dialups and only RIP a subnet for the people I need to route a subnet to? Any thoughts appreciated. -- ----- G Douglas Davidson | CityNet, Inc. douglas@city-net.com | Pittsburgh, PA voice: 412.481.5406 | fax: 412.431.1315 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Also sprach G. Douglas Davidson
I've been using RIPv2 to allow our Cisco to route to our TCs, but I just noticed recently that RIP is a CPU hog on the Cisco. It is consuming around 60 percent of the CPU. Is there anything that can be done to decrease the amount of RIP updates that the TCs send? Is OSPF less of a pig? Should I segement things so that I proxy arp the regular dialups and only RIP a subnet for the people I need to route a subnet to?
Any thoughts appreciated.
passive-interface on the cisco is your friend! If you passive-interface all of your RIP interfaces on the cisco, then the cisco knows it doesn't have to keep track of many of the timers on each route that it has to keep track of if its not set for passive-interface. Each route has a timer associated with it so the router knows when it needs to rebroadcast the route back out again...by eliminating these timers with the passive-interface command, I dropped the cpu load on my 7507 from ~50% to ~15% The only thing you loose by putting passive-interface on everything on the cisco is the ability for the cisco to inform the Arcs about routes it has...but since the usual mode of deployment is for the Arcs to be default routed to the cisco...you really don't loose much of any functionality. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
I have an odd problem with my TC Hub (at least I think it's the TC's problem). Starting this afternoon suddenly all my ISDN customers can't connect while modems work just fine connecting to the same unit. One customer says he can connect to another ISP using his ISDN line but not to us (but he can connect via a modem). I'm a little clueless as where to look for the culprit, moreso since we haven't touched the unit in months. Any ideas what, where I should check? Oh, it's an older unit, pre-DSP....about 3 years old. Thanks, ---Marius - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Marius Kirschner <marius@agoron.com> said:
I have an odd problem with my TC Hub (at least I think it's the TC's problem). Starting this afternoon suddenly all my ISDN customers can't connect while modems work just fine connecting to the same unit. One customer says he can connect to another ISP using his ISDN line but not to us (but he can connect via a modem).
I'm a little clueless as where to look for the culprit, moreso since we haven't touched the unit in months. Any ideas what, where I should check? Oh, it's an older unit, pre-DSP....about 3 years old. Thanks,
---Marius
There used to be a problem with the piggy back board for ISDN having a memory leak and running out of memory then ceasing to function. (Several years ago). The symptoms are just as you described. I think we put a terminal on the console of the arc and saw "out of memory" messages that gave the clue. Solution at that time was two fold. You could re-boot either the arc or nmc and it would reset the memory and be good for a while. (In our case it was a couple of months). Later on we had some information about switching the isdn detection/hardware to a different card and that solved the problem completely. I think we switched it to the dsp card instead of the arc card. Its been a while. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Also sprach Marius Kirschner
I have an odd problem with my TC Hub (at least I think it's the TC's problem). Starting this afternoon suddenly all my ISDN customers can't connect while modems work just fine connecting to the same unit. One customer says he can connect to another ISP using his ISDN line but not to us (but he can connect via a modem).
I'm a little clueless as where to look for the culprit, moreso since we haven't touched the unit in months. Any ideas what, where I should check? Oh, it's an older unit, pre-DSP....about 3 years old. Thanks,
Can the customer connect if they set their ISDN equipment to use 56kbps channels rather than 64kbps? It could be that a telco has a circuit somewhere in there that is using robbed-bit signalling or something like that which is preventing 64kbps clear channel calls from going through correctly. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
When I telnet into our TC and do a "show all" is displays the following for the ISDN ports: I0 idle 0.0.0.0 Login/ IDLE 0 0 0 I1 idle 0.0.0.0 Login/ IDLE 0 0 0 I2 idle 0.0.0.0 Login/ IDLE 0 0 0 I3 idle 0.0.0.0 Login/ IDLE 0 0 0 I4 idle 0.0.0.0 Login/ IDLE 0 0 0 Can somebody please verify that this is what it should display when nobody is using the ports? Thanks, ---Marius
-----Original Message----- From: owner-usr-tc@lists.xmission.com [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams Sent: Thursday, November 09, 2000 9:28 PM To: usr-tc@lists.xmission.com Subject: Re: (usr-tc) Odd problem
Also sprach Marius Kirschner
I have an odd problem with my TC Hub (at least I think it's the TC's problem). Starting this afternoon suddenly all my ISDN customers can't connect while modems work just fine connecting to the same unit. One customer says he can connect to another ISP using his ISDN line but not to us (but he can connect via a modem).
I'm a little clueless as where to look for the culprit, moreso since we haven't touched the unit in months. Any ideas what, where I should check? Oh, it's an older unit, pre-DSP....about 3 years old. Thanks,
Can the customer connect if they set their ISDN equipment to use 56kbps channels rather than 64kbps? It could be that a telco has a circuit somewhere in there that is using robbed-bit signalling or something like that which is preventing 64kbps clear channel calls from going through correctly. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
participants (4)
-
G. Douglas Davidson -
Jeff Mcadams -
Marius Kirschner -
w8mfd＠dayton.net