Hi, we have a Hiper box that we have been adding some DSP cards to. My problem is extending the IP pool to cover the extra ports. Currently there are 4 DSP's with 2 more to be added today. They are using PRI's, but I want to put 24 IP's per DSP into the ARC. I currently have 1 pool defined as: Name Address Size InUse State Route Status pool1 xxx.xxx.xx.112/C 96 24 PUBLIC NO_AGGREGATE ACTIVE I want to change it to start at .64 and have 144 addresses. I think the best way would be to define 3 pools: .64/26 size 64 .128/26 size 64 .192/28 size 64 I even tried to just change the start address and pool size and the thing complains.
set ip pool pool1 iniTIAL_POOL_ADDRESS xxx.xxx.xx.64/C size 144 CLI - Request SET IP POOL failed on field INITIAL_POOL_ADDRESS CLI - Request failed with error: BAD_VALUE on value: 0.0.0.8
Any suggestions? Michael ---------------------------------------------------------------------- Michael J. Hartwick, VE3SLQ hartwick@hartwick.com Hartwick Communications Consulting (519) 396-7719 Kincardine, ON, CA http://www.hartwick.com ---------------------------------------------------------------------- - 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.
you have to delete the pool I think in this case because a pool called pool1 exists. -----Original Message----- From: owner-usr-tc@lists.xmission.com [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Michael J. Hartwick Sent: Wednesday, May 30, 2001 9:06 AM To: usr-tc@lists.xmission.com Subject: (usr-tc) Changing IP Pool Hi, we have a Hiper box that we have been adding some DSP cards to. My problem is extending the IP pool to cover the extra ports. Currently there are 4 DSP's with 2 more to be added today. They are using PRI's, but I want to put 24 IP's per DSP into the ARC. I currently have 1 pool defined as: Name Address Size InUse State Route Status pool1 xxx.xxx.xx.112/C 96 24 PUBLIC NO_AGGREGATE ACTIVE I want to change it to start at .64 and have 144 addresses. I think the best way would be to define 3 pools: .64/26 size 64 .128/26 size 64 .192/28 size 64 I even tried to just change the start address and pool size and the thing complains.
set ip pool pool1 iniTIAL_POOL_ADDRESS xxx.xxx.xx.64/C size 144 CLI - Request SET IP POOL failed on field INITIAL_POOL_ADDRESS CLI - Request failed with error: BAD_VALUE on value: 0.0.0.8
Any suggestions? Michael ---------------------------------------------------------------------- Michael J. Hartwick, VE3SLQ hartwick@hartwick.com Hartwick Communications Consulting (519) 396-7719 Kincardine, ON, CA http://www.hartwick.com ---------------------------------------------------------------------- - 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.
Also sprach Terry Kennedy
you have to delete the pool I think in this case because a pool called pool1 exists.
Shouldn't *have* to since its a set command (changes an already existing entry) rather than an add command (add a new entry to a table), but there may be problems with modifying active entries in a table like that. I'm not sure...haven't mucked about with this in quite some time. I do know that there is no problem with just defining a new pool (add ip pool ....) for the rest of the IP addresses that aren't covered by the pool already in there. The Arc will handle having multiple pools without any trouble whatsoever. Default setting is to round-robin the usage of addresses, so the addresses will get used from both eventually, even without all lines being in use. Indeed, there are some benefits to splitting up the pools anyway...you can disable individual pools and move IP addresses around (as people log off and free up the addresses in the disabled pool) without disrupting your service and stuff like that.
-----Original Message----- From: owner-usr-tc@lists.xmission.com [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Michael J. Hartwick Sent: Wednesday, May 30, 2001 9:06 AM To: usr-tc@lists.xmission.com Subject: (usr-tc) Changing IP Pool
Hi, we have a Hiper box that we have been adding some DSP cards to. My problem is extending the IP pool to cover the extra ports. Currently there are 4 DSP's with 2 more to be added today. They are using PRI's, but I want to put 24 IP's per DSP into the ARC.
I currently have 1 pool defined as: Name Address Size InUse State Route Status pool1 xxx.xxx.xx.112/C 96 24 PUBLIC NO_AGGREGATE ACTIVE
I want to change it to start at .64 and have 144 addresses. I think the best way would be to define 3 pools:
.64/26 size 64 .128/26 size 64 .192/28 size 64
I even tried to just change the start address and pool size and the thing complains.
set ip pool pool1 iniTIAL_POOL_ADDRESS xxx.xxx.xx.64/C size 144 CLI - Request SET IP POOL failed on field INITIAL_POOL_ADDRESS CLI - Request failed with error: BAD_VALUE on value: 0.0.0.8
Any suggestions?
Michael
---------------------------------------------------------------------- Michael J. Hartwick, VE3SLQ hartwick@hartwick.com Hartwick Communications Consulting (519) 396-7719 Kincardine, ON, CA http://www.hartwick.com ----------------------------------------------------------------------
- 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.
-- 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.
Thanks for all of the replies, I just picked this one to reply to. :) On Wed, 30 May 2001 at 12:24 (-0400), Jeff Mcadams wrote: JM> Shouldn't *have* to since its a set command (changes an already existing JM> entry) rather than an add command (add a new entry to a table), but That was my hope as well, but that doesn't appear to be the case. It looks like I might need to create a new pool and then delete this one and create another to adjust it. JM> I do know that there is no problem with just defining a new pool (add ip JM> pool ....) for the rest of the IP addresses that aren't covered by the JM> pool already in there. The Arc will handle having multiple pools JM> without any trouble whatsoever. Default setting is to round-robin the JM> usage of addresses, so the addresses will get used from both eventually, JM> even without all lines being in use. JM> JM> Indeed, there are some benefits to splitting up the pools anyway...you JM> can disable individual pools and move IP addresses around (as people log JM> off and free up the addresses in the disabled pool) without disrupting JM> your service and stuff like that. The consensus seems to be go with multiple pools and be happy. :) It looks like I need to number into temporary address space, delete the current pool, then create the new ones. If I could get the aggregate to work the way I think it should I would be happy. I have version 4.1.59 on the ARC so am stuck with RIP. :( Thanks for the responses. I will be getting this thing the way I want sooner or later. Michael ---------------------------------------------------------------------- Michael J. Hartwick, VE3SLQ hartwick@hartwick.com Hartwick Communications Consulting (519) 396-7719 Kincardine, ON, CA http://www.hartwick.com ---------------------------------------------------------------------- - 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 Michael J. Hartwick
The consensus seems to be go with multiple pools and be happy. :) It looks like I need to number into temporary address space, delete the current pool, then create the new ones. If I could get the aggregate to work the way I think it should I would be happy.
You might be better off letting your next hop handle the aggregation. Aggregates never worked the way I (personally) thought they should on the Arcs. I was always of the idea that combining network aggregation with IP pool definitions was a bad idea. I always thought they should have defined IP pools, and then handled aggregation of routes in a seperate control area, but, 3Com has a history of not listening to me, so here we are. :)
I have version 4.1.59 on the ARC so am stuck with RIP. :(
My suggestion would be to go ahead and let the Arc advertise out everything as individual routes. Let your next hop (cisco?) pick up those rip routes (hint: passive-interface in IOS is your friend!) and redistribute them and/or aggregate them into the routing protocol of your choice, in the manner of your choosing. This is what I do. Despite being on new enough code to have OSPF on the Arcs, I've stuck with RIPv2, and let my next hop cisco redistribute into OSPF, aggregating in the process. With liberal use of passive-interface settings on the Cisco, I have very low CPU usage on the cisco boxes (including a 2500 in one city), as the cpu hit with RIP in IOS is keeping track of timers for re-broadcasting the routes. If you passive-interface all of your RIP interfaces on your cisco system, it doesn't have to keep track of all of those timers (on a per-route basis!) and as such will significantly lower your CPU usage. -- 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.
On Wed, 30 May 2001, Jeff Mcadams wrote:
You might be better off letting your next hop handle the aggregation. Aggregates never worked the way I (personally) thought they should on the Arcs. I was always of the idea that combining network aggregation with IP pool definitions was a bad idea. I always thought they should have defined IP pools, and then handled aggregation of routes in a seperate control area, but, 3Com has a history of not listening to me,
Actually they do: anunu2> list ip pool IP ADDRESS POOLS Name Address Size InUse State Route Unused Priority Status pool01 64.65.75.176/A 192 41 PUBLIC MULTI_AGGR 0 1 ACTIVE anunu2> list ip agg IP Aggregate Routes PoolName Aggregate Route Size Type pool01 64.65.75.176/28 16 MULTI_AGGR pool01 64.65.75.192/26 64 MULTI_AGGR pool01 64.65.76.0/26 64 MULTI_AGGR pool01 64.65.76.64/27 32 MULTI_AGGR pool01 64.65.76.96/28 16 MULTI_AGGR Notice the MULTI_AGGR in the listing for pool01? The neat thing with this is you just define the pool starting address as you normally would and it figures out the aggregates. The zero'th address in each aggregate doesn't present a problem as the box answers/arps for the entire range anyway. - 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 Antonio Querubin
On Wed, 30 May 2001, Jeff Mcadams wrote:
You might be better off letting your next hop handle the aggregation. Aggregates never worked the way I (personally) thought they should on the Arcs. I was always of the idea that combining network aggregation with IP pool definitions was a bad idea. I always thought they should have defined IP pools, and then handled aggregation of routes in a seperate control area, but, 3Com has a history of not listening to me,
Actually they do:
anunu2> list ip pool
IP ADDRESS POOLS Name Address Size InUse State Route Unused Priority Status pool01 64.65.75.176/A 192 41 PUBLIC MULTI_AGGR 0 1 ACTIVE anunu2> list ip agg
IP Aggregate Routes PoolName Aggregate Route Size Type pool01 64.65.75.176/28 16 MULTI_AGGR pool01 64.65.75.192/26 64 MULTI_AGGR pool01 64.65.76.0/26 64 MULTI_AGGR pool01 64.65.76.64/27 32 MULTI_AGGR pool01 64.65.76.96/28 16 MULTI_AGGR
Notice the MULTI_AGGR in the listing for pool01? The neat thing with this is you just define the pool starting address as you normally would and it figures out the aggregates. The zero'th address in each aggregate doesn't present a problem as the box answers/arps for the entire range anyway.
Hrmm...neat...added in 5.0.9 apparently. Mike, Curt, either of you guys know about this? I don't remember that ever being mentioned in the beta, or anytime after. Of course, the definition of the aggregates is still tied up with the pools...which is still pretty broken...but at least its not *as* broken this way. I'm not aware of any control of redistribution of routes between OSPF and RIP for example. Controlling aggregation of routes in the dial-up pools really prevents the Arcs from reaching their full potential (I've mentioned things along this line before). The Arc really has the potential to be a good, maybe even great, general purpose router system...of course, 3Com seems to be doing their best to destroy any value that the company has as a single unit, so I don't hold out much hope for the Arc ever being able to see its true potential. I just hope Krish, Mike Wronski, Tom Goodman and the rest of the good people at 3Com get out before the ship sinks. :/ Sorry...getting a bit off topic again. -- 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.
Yes it was added in 5.x code onwards V ----- Original Message ----- From: "Jeff Mcadams" <jeffm@iglou.com> To: <usr-tc@lists.xmission.com> Sent: Friday, June 01, 2001 9:35 PM Subject: Re: (usr-tc) Changing IP Pool
Also sprach Antonio Querubin
On Wed, 30 May 2001, Jeff Mcadams wrote:
You might be better off letting your next hop handle the aggregation. Aggregates never worked the way I (personally) thought they should on the Arcs. I was always of the idea that combining network aggregation with IP pool definitions was a bad idea. I always thought they should have defined IP pools, and then handled aggregation of routes in a seperate control area, but, 3Com has a history of not listening to me,
Actually they do:
anunu2> list ip pool
IP ADDRESS POOLS Name Address Size InUse State Route Unused Priority Status pool01 64.65.75.176/A 192 41 PUBLIC MULTI_AGGR 0 1 ACTIVE anunu2> list ip agg
IP Aggregate Routes PoolName Aggregate Route Size Type pool01 64.65.75.176/28 16 MULTI_AGGR pool01 64.65.75.192/26 64 MULTI_AGGR pool01 64.65.76.0/26 64 MULTI_AGGR pool01 64.65.76.64/27 32 MULTI_AGGR pool01 64.65.76.96/28 16 MULTI_AGGR
Notice the MULTI_AGGR in the listing for pool01? The neat thing with this is you just define the pool starting address as you normally would and it figures out the aggregates. The zero'th address in each aggregate doesn't present a problem as the box answers/arps for the entire range anyway.
Hrmm...neat...added in 5.0.9 apparently. Mike, Curt, either of you guys know about this? I don't remember that ever being mentioned in the beta, or anytime after.
Of course, the definition of the aggregates is still tied up with the pools...which is still pretty broken...but at least its not *as* broken this way.
I'm not aware of any control of redistribution of routes between OSPF and RIP for example.
Controlling aggregation of routes in the dial-up pools really prevents the Arcs from reaching their full potential (I've mentioned things along this line before). The Arc really has the potential to be a good, maybe even great, general purpose router system...of course, 3Com seems to be doing their best to destroy any value that the company has as a single unit, so I don't hold out much hope for the Arc ever being able to see its true potential.
I just hope Krish, Mike Wronski, Tom Goodman and the rest of the good people at 3Com get out before the ship sinks. :/
Sorry...getting a bit off topic again. -- 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.
Also sprach Ved
Yes it was added in 5.x code onwards
Did it ever get added in release notes for any release? I looked again in the 5.0.9 release notes and didn't find any mention of it in there...Haven't looked at 5.1.x release notes, but I doubt it would be in there since it wasn't a new feature for that release. -- 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.
1) Try starting at .65, .129, and .193, size 62. 2) Create a new pool with a different name instead of trying to modify the old one. Then delete the old one. (It's smart enough to know if the old one is in use; it just marks it "delete pending", and then once everyone's logged out, it'll go poof on its own) Mike Andrews * mandrews@dcr.net * mandrews@bit0.com * http://www.bit0.com VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet access for Frankfort, Lexington, Louisville and surrounding counties www.fark.com: If it's not news, it's Fark. (Or something like that.) On Wed, 30 May 2001, Michael J. Hartwick wrote:
Hi, we have a Hiper box that we have been adding some DSP cards to. My problem is extending the IP pool to cover the extra ports. Currently there are 4 DSP's with 2 more to be added today. They are using PRI's, but I want to put 24 IP's per DSP into the ARC.
I currently have 1 pool defined as: Name Address Size InUse State Route Status pool1 xxx.xxx.xx.112/C 96 24 PUBLIC NO_AGGREGATE ACTIVE
I want to change it to start at .64 and have 144 addresses. I think the best way would be to define 3 pools:
.64/26 size 64 .128/26 size 64 .192/28 size 64
I even tried to just change the start address and pool size and the thing complains.
set ip pool pool1 iniTIAL_POOL_ADDRESS xxx.xxx.xx.64/C size 144 CLI - Request SET IP POOL failed on field INITIAL_POOL_ADDRESS CLI - Request failed with error: BAD_VALUE on value: 0.0.0.8
Any suggestions?
Michael
---------------------------------------------------------------------- Michael J. Hartwick, VE3SLQ hartwick@hartwick.com Hartwick Communications Consulting (519) 396-7719 Kincardine, ON, CA http://www.hartwick.com ----------------------------------------------------------------------
- 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.
Just a side note, You can not delete a pool that is in use, and I believe you can not modify either. I find it nice to have 3 pools on each TC that way I can disable one and fill up the others if I need to do maint. on a pool. -Steve On Wed, May 30, 2001 at 12:37:47PM -0400, Mike Andrews wrote:
1) Try starting at .65, .129, and .193, size 62.
2) Create a new pool with a different name instead of trying to modify the old one. Then delete the old one. (It's smart enough to know if the old one is in use; it just marks it "delete pending", and then once everyone's logged out, it'll go poof on its own)
Mike Andrews * mandrews@dcr.net * mandrews@bit0.com * http://www.bit0.com VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet access for Frankfort, Lexington, Louisville and surrounding counties www.fark.com: If it's not news, it's Fark. (Or something like that.)
On Wed, 30 May 2001, Michael J. Hartwick wrote:
Hi, we have a Hiper box that we have been adding some DSP cards to. My problem is extending the IP pool to cover the extra ports. Currently there are 4 DSP's with 2 more to be added today. They are using PRI's, but I want to put 24 IP's per DSP into the ARC.
I currently have 1 pool defined as: Name Address Size InUse State Route Status pool1 xxx.xxx.xx.112/C 96 24 PUBLIC NO_AGGREGATE ACTIVE
I want to change it to start at .64 and have 144 addresses. I think the best way would be to define 3 pools:
.64/26 size 64 .128/26 size 64 .192/28 size 64
I even tried to just change the start address and pool size and the thing complains.
set ip pool pool1 iniTIAL_POOL_ADDRESS xxx.xxx.xx.64/C size 144 CLI - Request SET IP POOL failed on field INITIAL_POOL_ADDRESS CLI - Request failed with error: BAD_VALUE on value: 0.0.0.8
Any suggestions?
Michael
---------------------------------------------------------------------- Michael J. Hartwick, VE3SLQ hartwick@hartwick.com Hartwick Communications Consulting (519) 396-7719 Kincardine, ON, CA http://www.hartwick.com ----------------------------------------------------------------------
- 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.
-- Steve Johnson - linuxnut@sonic.net Sonic.net, Inc. System Administrator 300 B Street #100 707.522.1000 (Voice) Santa Rosa, CA 95404 707.547.2199 (Fax) http://www.sonic.net/ - 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 Steve Johnson
Just a side note, You can not delete a pool that is in use, and I believe you can not modify either. I find it nice to have 3 pools on each TC that way I can disable one and fill up the others if I need to do maint. on a pool.
And a clarification of that...you can use the delete command...but it will still show up in the list command until all the addresses are freed up (by people logging off), once the pool is freed up, it'll disappear. As I mentioned in other messages, I'm definitely with you on the using multiple pools thing...its really nice to be able to juggle them around a bit. I've never used anything beyond 5.0.9 (during the TCS 4.0 beta)...did they ever fix the DHCP support? In 5.1.x maybe? I haven't ever gotten a copy of later code to try it out. Using DHCP could be *really* cool as it would allow massive flexibility in IP addressing...that's assuming that the code was ever fixed to actually *work*. It was rather significantly broken in 5.0.9. -- 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.
Also sprach Mike Andrews
1) Try starting at .65, .129, and .193, size 62.
As long as he's not aggregating, he shouldn't have any trouble starting with the 0's address (especially since he's defining it as a /C, so they really wouldn't even be a 0's address for that ;)
2) Create a new pool with a different name instead of trying to modify the old one. Then delete the old one. (It's smart enough to know if the old one is in use; it just marks it "delete pending", and then once everyone's logged out, it'll go poof on its own)
Yeah...that's one way of doing it...though I'm not sure it'll let you create pools that overlap IP addresses, so it may have to be a multi-step process if he wants to end up with a single pool. I just say, heck with it...use multiple pools and be happy. :) -- 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.
On Wed, 30 May 2001, Jeff Mcadams wrote:
Also sprach Mike Andrews
1) Try starting at .65, .129, and .193, size 62.
As long as he's not aggregating, he shouldn't have any trouble starting with the 0's address (especially since he's defining it as a /C, so they really wouldn't even be a 0's address for that ;)
Yeah, I'm just being overly conservative there. :) And I aggregate, so I don't have a billion host routes in my ospf setup.
2) Create a new pool with a different name instead of trying to modify the old one. Then delete the old one. (It's smart enough to know if the old one is in use; it just marks it "delete pending", and then once everyone's logged out, it'll go poof on its own)
Yeah...that's one way of doing it...though I'm not sure it'll let you create pools that overlap IP addresses, so it may have to be a multi-step process if he wants to end up with a single pool.
It won't... so, yeah.
I just say, heck with it...use multiple pools and be happy. :)
I do that anyway, for efficiency's sake. A box with 9 PRI's on it has 3 pools of /25+/26+/27 instead of a /24... a full 15 PRI box would be /24+/26+/27. It helps make your case with ARIN easier when you go begging and pleading for another /20 or /19... Mike Andrews * mandrews@dcr.net * mandrews@bit0.com * http://www.bit0.com VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet access for Frankfort, Lexington, Louisville and surrounding counties www.fark.com: If it's not news, it's Fark. (Or something like that.) - 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 Mike Andrews
On Wed, 30 May 2001, Jeff Mcadams wrote:
As long as he's not aggregating, he shouldn't have any trouble starting with the 0's address (especially since he's defining it as a /C, so they really wouldn't even be a 0's address for that ;)
Yeah, I'm just being overly conservative there. :) And I aggregate, so I don't have a billion host routes in my ospf setup.
Yeah...I've got maybe a couple of hundred routes in my OSPF domain...certainly not a killer, but it'd be nice to lessen that a bit. As I think I mentioned, I *do* summarize on the redistribution from RIPv2 to OSPF that I do in the Ciscos...so we're doing about the same thing...just in different spots. :)
I do that anyway, for efficiency's sake. A box with 9 PRI's on it has 3 pools of /25+/26+/27 instead of a /24... a full 15 PRI box would be /24+/26+/27. It helps make your case with ARIN easier when you go begging and pleading for another /20 or /19...
Hah! I don't even do mine on bit boundaries. I've got some with pools of 4 addresses, pools of 7 addresses, weird stuff like that. I've pulled remnants from different blocks at different times to make up the number of IP addresses that I needed on one of my systems...the wonders of routing protocols figures it all out and everything is quite happy. Well...here...I'll just show you: HiPer>> list ip poOLS IP ADDRESS POOLS Name Address Size InUse State Route Unused Status dialup 204.255.236.232/C 23 11 PUBLIC NO_AGGREGATE 0 ACTIVE dialup2 204.255.236.200/C 23 14 PUBLIC NO_AGGREGATE 0 ACTIVE dialup3 204.255.236.223/C 9 5 PUBLIC NO_AGGREGATE 0 ACTIVE dialup4 204.255.230.241/C 14 8 PUBLIC NO_AGGREGATE 0 ACTIVE dialup5 204.255.230.195/C 46 46 PUBLIC NO_AGGREGATE 0 ACTIVE dialup6 204.255.230.149/C 23 6 PUBLIC NO_AGGREGATE 0 ACTIVE dialup7 204.255.230.172/C 23 6 PUBLIC NO_AGGREGATE 0 ACTIVE dialup8 204.252.74.17/C 46 17 PUBLIC NO_AGGREGATE 0 ACTIVE HiPer>> Wacko isn't it? :) This box grew from originally only having one PRI to having 8 on it currently, and is likely to grow some more. The wonders of running an ISP on a shoestring. :) Someday, I'll go back and clean it all up so there's not these little netblock droppings all over the place...*shrug*. In the meantime, it all just works and it did definitely help when we went to ARIN for more space...(got a /20, FWIW). -- 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.
On Wed, 30 May 2001 at 19:09 (-0400), Jeff Mcadams wrote: JM> IP ADDRESS POOLS JM> Name Address Size InUse State Route Unused Status JM> dialup 204.255.236.232/C 23 11 PUBLIC NO_AGGREGATE 0 ACTIVE JM> dialup2 204.255.236.200/C 23 14 PUBLIC NO_AGGREGATE 0 ACTIVE JM> dialup3 204.255.236.223/C 9 5 PUBLIC NO_AGGREGATE 0 ACTIVE JM> dialup4 204.255.230.241/C 14 8 PUBLIC NO_AGGREGATE 0 ACTIVE JM> dialup5 204.255.230.195/C 46 46 PUBLIC NO_AGGREGATE 0 ACTIVE JM> dialup6 204.255.230.149/C 23 6 PUBLIC NO_AGGREGATE 0 ACTIVE JM> dialup7 204.255.230.172/C 23 6 PUBLIC NO_AGGREGATE 0 ACTIVE JM> dialup8 204.252.74.17/C 46 17 PUBLIC NO_AGGREGATE 0 ACTIVE JM> HiPer>> JM> JM> Wacko isn't it? :) This box grew from originally only having one PRI JM> to having 8 on it currently, and is likely to grow some more. The JM> wonders of running an ISP on a shoestring. :) I have managed to get it to work by creating a couple of temp pools (I couldn't use contiguous IP space :() and then once the orignal pool was gone I created 3 new pools. pool1 216.191.63.65/26 63 3 PUBLIC NO_AGGREGATE ACTIVE pool2 216.191.63.129/26 63 6 PUBLIC NO_AGGREGATE ACTIVE pool3 216.191.63.193/28 15 2 PUBLIC NO_AGGREGATE ACTIVE And it appears to be working. It is getting to that time of night that customers are not hitting this box anymore (8 PRI's before it in the hunt group) so my changes should be done by morning. I am letting the TC speak RIPv2 to a Cisco that is redistributing into OSPF for the rest of the network. I have been trying to keep the allocations for the pool in the same block to minimize the routes needed and have it down to 3 once the Cisco is done aggregating. Thanks to everyone who responded to my question. Hmm...An unrelated question...Is there anyway to backup the software from the DSP and/or the ARC incase something goes wrong? We have acquired this box as part of an ISP we purchased and don't have much in the way of documentation (thanks to the PDF's online I have enough to get by), but I don't have any software to load back in should something get corrupted. Thanks, Michael ---------------------------------------------------------------------- Michael J. Hartwick, VE3SLQ hartwick@hartwick.com Hartwick Communications Consulting (519) 396-7719 Kincardine, ON, CA http://www.hartwick.com ---------------------------------------------------------------------- - 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 Michael J. Hartwick
Hmm...An unrelated question...Is there anyway to backup the software from the DSP and/or the ARC incase something goes wrong? We have acquired this box as part of an ISP we purchased and don't have much in the way of documentation (thanks to the PDF's online I have enough to get by), but I don't have any software to load back in should something get corrupted.
The only dead tree manuals you can get are printouts of the pdfs, FWIW. There's no way to backup the software off a DSP or Arc that I'm aware of. Sorry. -- 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.
participants (7)
-
Antonio Querubin -
Jeff Mcadams -
Michael J. Hartwick -
Mike Andrews -
Steve Johnson -
Terry Kennedy -
Ved