Subject: (usr-tc) Changing IP Pool

From: "Michael J. Hartwick" <[email-masked]>
Date: Wed, 30 May 2001 18:10:24 +0000

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                      [email-masked]
Hartwick Communications Consulting                      (519) 396-7719
Kincardine, ON, CA                             http://www.hartwick.com
----------------------------------------------------------------------

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 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.

---

From: Terry Kennedy <[email-masked]>
Date: Wed, 30 May 2001 18:16:58 +0000

you have to delete the pool I think in this case because
a pool called pool1 exists.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Michael J. Hartwick
Sent: Wednesday, May 30, 2001 9:06 AM
To: [email-masked]
Subject: (usr-tc) Changing IP Pool

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

.64/26	size 64
.128/26	size 64
.192/28 size 64

Any suggestions?

Michael

-

-

---

From: Jeff Mcadams <[email-masked]>
Date: Wed, 30 May 2001 18:29:42 +0000

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.

-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Mike Andrews <[email-masked]>
Date: Wed, 30 May 2001 18:41:57 +0000

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 * [email-masked] * [email-masked] * 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.)

-

---

From: Steve Johnson <[email-masked]>
Date: Wed, 30 May 2001 18:49:10 +0000

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

-- 
Steve Johnson - [email-masked]      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/

-

---

From: Jeff Mcadams <[email-masked]>
Date: Wed, 30 May 2001 18:53:09 +0000

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: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Jeff Mcadams <[email-masked]>
Date: Wed, 30 May 2001 18:56:54 +0000

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.

-

---

From: "Michael J. Hartwick" <[email-masked]>
Date: Wed, 30 May 2001 19:08:24 +0000

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

-

---

From: Jeff Mcadams <[email-masked]>
Date: Wed, 30 May 2001 19:31:30 +0000

Also sprach Michael J. Hartwick
>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: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Mike Andrews <[email-masked]>
Date: Wed, 30 May 2001 23:11:46 +0000

> 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.

> 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...

-

---

From: Jeff Mcadams <[email-masked]>
Date: Thu, 31 May 2001 01:14:35 +0000

Also sprach Mike Andrews
>> 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 ;)

>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: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: "Michael J. Hartwick" <[email-masked]>
Date: Thu, 31 May 2001 06:28:27 +0000

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

-

---

From: Jeff Mcadams <[email-masked]>
Date: Thu, 31 May 2001 14:39:40 +0000

>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: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Antonio Querubin <[email-masked]>
Date: Sat, 02 Jun 2001 00:34:46 +0000

> 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.

-

---

From: Jeff Mcadams <[email-masked]>
Date: Sat, 02 Jun 2001 04:41:29 +0000

Also sprach Antonio Querubin
>> 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,

>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: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Ved <[email-masked]>
Date: Sat, 02 Jun 2001 14:22:00 +0000

Yes it was added in 5.x code onwards

V
----- Original Message -----
From: "Jeff Mcadams" <[email-masked]>
To: <[email-masked]>
Sent: Friday, June 01, 2001 9:35 PM
Subject: Re: (usr-tc) Changing IP Pool

-

---

From: Jeff Mcadams <[email-masked]>
Date: Sat, 02 Jun 2001 16:33:12 +0000

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.

-