When I enable the above using: enable ip SEND_HOST_UNREACH_FOR_POOL I notice that my rip built routing tables on my router start to degrade. What I mean is this. I have rip configured on all my hiperarc's and on my backbone router. Without the above enabled all seems to work as expected. With it enabled some clients connect fine, others can connect but can't do anything past the hyperarc. When I investigate I find that some users that don't work do have entries in the table, others don't. I thought enabling that might reduce the size of my routing table further and increase the speed at which disconnected IP's are dropped from the table. It just seems to muck up the waters. Is this just a convergence issue with rip? What is the true function of this feature if not for this purpose? Any input at all. Maybe there is some other function for this? -- Lewis Bergman Texas Communications 4309 Maple St. Abilene, TX 79602-8044 325-691-3301 800-299-6962
I found this if you haven't already read it: http://totalservice.utstar.com/TCSDOCS/4.2/10039431/102_arc4.htm I personally don't like rip and we converted our entire network basically to OSPF a long time ago. As far as reducing the size of your routing table do you setup your IP Pools as aggregate or non_aggregate? As far as RIP "degrading" I would guess it's probably a convergence issue. Something like the following possibly: User drops their connection to your hiperarc causing their interface to go into a down state. With the above command enabled the hiperarc would send a host unreachable message back out (assuming the IP in question is part of your IP pool). If I remember correctly RIP has a 30 second convergence time. Is it possible that the problems you are seeing are taking place within a 30-60 second time interval? Have you been able to sit and watch users for a longer period of time and verified if they were still having routing issues? What code are you running on the hiperarc? You say some users don't show up in the routing table of the arc at all when they are connected? So you aren't able to ping them directly from the arc? In my opinion the send host unreach for pool command shouldn't have anything really to do with that. Todd ----- Original Message ----- From: "Lewis Bergman" <lbergman@wtxs.net> To: "Discussion relating to the 3Com/US Robotics Total Control modem systems." <usr-tc@mailman.xmission.com> Sent: Thursday, October 21, 2004 8:57 AM Subject: [USR-TC] Send ICMP Host Unreachable for Pool: DISABLED
When I enable the above using: enable ip SEND_HOST_UNREACH_FOR_POOL I notice that my rip built routing tables on my router start to degrade. What I mean is this.
I have rip configured on all my hiperarc's and on my backbone router. Without the above enabled all seems to work as expected. With it enabled some clients connect fine, others can connect but can't do anything past the hyperarc. When I investigate I find that some users that don't work do have entries in the table, others don't.
I thought enabling that might reduce the size of my routing table further and increase the speed at which disconnected IP's are dropped from the table. It just seems to muck up the waters. Is this just a convergence issue with rip? What is the true function of this feature if not for this purpose?
Any input at all. Maybe there is some other function for this? -- Lewis Bergman Texas Communications 4309 Maple St. Abilene, TX 79602-8044 325-691-3301 800-299-6962
_______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc
Todd Bertolozzi wrote:
I found this if you haven't already read it:
http://totalservice.utstar.com/TCSDOCS/4.2/10039431/102_arc4.htm
I personally don't like rip and we converted our entire network basically to OSPF a long time ago.
As far as reducing the size of your routing table do you setup your IP Pools as aggregate or non_aggregate?
As far as RIP "degrading" I would guess it's probably a convergence issue. Something like the following possibly:
User drops their connection to your hiperarc causing their interface to go into a down state. With the above command enabled the hiperarc would send a host unreachable message back out (assuming the IP in question is part of your IP pool). If I remember correctly RIP has a 30 second convergence time. Is it possible that the problems you are seeing are taking place within a 30-60 second time interval? Have you been able to sit and watch users for a longer period of time and verified if they were still having routing issues?
What code are you running on the hiperarc? You say some users don't show up in the routing table of the arc at all when they are connected? So you aren't able to ping them directly from the arc? In my opinion the send host unreach for pool command shouldn't have anything really to do with that.
Todd ----- Original Message ----- From: "Lewis Bergman" <lbergman@wtxs.net> To: "Discussion relating to the 3Com/US Robotics Total Control modem systems." <usr-tc@mailman.xmission.com> Sent: Thursday, October 21, 2004 8:57 AM Subject: [USR-TC] Send ICMP Host Unreachable for Pool: DISABLED
When I enable the above using: enable ip SEND_HOST_UNREACH_FOR_POOL I notice that my rip built routing tables on my router start to degrade. What I mean is this.
I have rip configured on all my hiperarc's and on my backbone router. Without the above enabled all seems to work as expected. With it enabled some clients connect fine, others can connect but can't do anything past the hyperarc. When I investigate I find that some users that don't work do have entries in the table, others don't.
I thought enabling that might reduce the size of my routing table further and increase the speed at which disconnected IP's are dropped from the table. It just seems to muck up the waters. Is this just a convergence issue with rip? What is the true function of this feature if not for this purpose?
Any input at all. Maybe there is some other function for this? RIP is noisy but when I first set this up a couple of years ago someone said the OSPF with the HiperArc didn't prove reliable. Maybe time to re-evalute and make a switch to OSPF.
On a slightly differnt topic, more of a network deal. Do you use a /30 or a /31 (.252 or .254) between your hiperArc and your backbone router? -- Lewis Bergman Texas Communications 4309 Maple St. Abilene, TX 79602-8044 325-691-3301 800-299-6962
Todd Bertolozzi wrote:
As far as reducing the size of your routing table do you setup your IP Pools as aggregate or non_aggregate? I checked and they are all non_aggregate. Thanks for the tip. Maybe one of these years when my kids grow up I'll step through every single command and finally learn what this thing can do.
-- Lewis Bergman Texas Communications 4309 Maple St. Abilene, TX 79602-8044 325-691-3301 800-299-6962
Any ideas on why it won't let me set the ip pools to aggregate? HiPer>> set ip pooL 1 rOUTE aggREGATE CLI - Request SET IP POOL failed on field ROUTE CLI - Request failed with error: BAD_VALUE on value: 1 -- Lewis Bergman Texas Communications 4309 Maple St. Abilene, TX 79602-8044 325-691-3301 800-299-6962
I believe you need to disable the pools / make sure no 1 is on them before you can change them.... If all else fails delete them and set them up again with the route_aggregate command Todd ----- Original Message ----- From: "Lewis Bergman" <lbergman@wtxs.net> To: "Discussion relating to the 3Com/US Robotics Total Control modem systems." <usr-tc@mailman.xmission.com> Sent: Friday, October 22, 2004 2:38 PM Subject: Re: [USR-TC] Send ICMP Host Unreachable for Pool: DISABLED
Any ideas on why it won't let me set the ip pools to aggregate?
HiPer>> set ip pooL 1 rOUTE aggREGATE CLI - Request SET IP POOL failed on field ROUTE CLI - Request failed with error: BAD_VALUE on value: 1
-- Lewis Bergman Texas Communications 4309 Maple St. Abilene, TX 79602-8044 325-691-3301 800-299-6962
_______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc
participants (2)
-
Lewis Bergman -
Todd Bertolozzi