----- Original Message -----
From: "X-BOX/B.P." <bpollinger@x-box.com>
To: <ntisp@iea-software.com>
Sent: Tuesday, December 07, 1999 10:28 AM
Subject: Re: [NTISP] IP delegation...
> After all reading I think the only solution is subnetting all Your users
or
> using DHCP or not beeing able to control IP-usage of a particular user at
> all. First important question is if You are routing Your users or bridging
> Your users? If You are routing them You MUST assign subnets (and this is
> what I'd prefer..). If You want to avoid the additional work, simply use
> assigned pools and OSPF and write a small script for a website where a
user
> could purchase a bigger netmask to be assigned more ip's (standard give
him
> a mask of 255.255.255.255, You know...). Thus, if he wants more IP's he
goes
> to Your site and purchases an amount of say 16 IP's. The script changes
the
> radius,Tacacs or whatever database and assignes the user the new netmask.
> That's all...its quite easy to do..
>
>
> Regards
>
> Bernd Pollinger
> -------------------------------------------
> X-BOX Online Service GmbH
> Berlin, germany
> http://www.x-box.com
> -------------------------------------------
> "Keyboard Error: Press F1 to continue!" ;-)
>
>
> ----- Original Message -----
> From: Gabriel Sponsler <gabe@montereybay.com>
> To: <ntisp@iea-software.com>
> Sent: Friday, December 03, 1999 8:39 PM
> Subject: Re: [NTISP] IP delegation...
>
>
> | Bob:
> | I am sorry I got your feathers ruffled. Perhaps the inquiry was a
bit
> | incomplete.
> | The reason that we have the constraint is because of the unusual
> | circumstance with our upstream provider. They control the class B, and
> have
> | allocated us only two class C blocks as of now, so as you surely know
> 254.0
> | subnet is appropriate for our circumstance.
> | I was hoping for a resolution aside from subnetting our customers to
> | meet their individual IP needs for a couple of reasons. 1) As you can
tell
> | from the above paragraph we are temporarily constrained by the quantity
of
> | IPs we can use. 2) Our sales team have sold odd amounts of IP to our
> | customers, and once again I am trying to be efficient by not assigning a
> /28
> | to someone who only needs 6 IP addresses.
> | I am somewhat resigned to subnet to each customer accordingly, but
> then
> | again that's why I posted to the news group for alternative suggestions.
> |
> | Thanks,
> | Gabe
> | ----- Original Message -----
> | From: Bob's Lists <bob.lists@raha.com>
> | To: <ntisp@iea-software.com>
> | Sent: Friday, December 03, 1999 11:19 AM
> | Subject: RE: [NTISP] IP delegation...
> |
> |
> | > Pardon my ignorance on this issue, but in starting to sell DSL our
> company
> | > has run into a problem delegating IP addresses to customers. Due to
the
> | > configuration constraints of the Cisco router (3810) we are using, we
> have
> | > assigned a subnet mask for our end users of 255.255.254.0 thus
allowing
> | all
> | > of the users access to all of the addresses in the assigned class C.
> | >
> | > My question is: What would be the best way to avoid customers to just
> grab
> | > unused IPs for their workstations? The only way I could do it now is
> | > assign all the untaken IP to a Nt workstation, but that is cumbersome
> and
> | > quite annoying.
> | >
> | > -----------------------
> | >
> | > The only suggestion I can offer, is to get a network admin who knows
> what
> | > they're doing.
> | >
> | > First of all, 255.255.254.0 is not a class C, it is 2 class C's (or 1
> /23,
> | > and they're now known). Using that mask, and if, indeed, your upstream
> has
> | > allocated you a class C, I'm surprised they haven't nailed you yet for
> | some
> | > 'unusual traffic' on your link...
> | >
> | > Next, you should be allocating customers only what they need. If they
> need
> | 1
> | > address, give them a /30 (with the gateway on your router, leaving 1
IP
> at
> | > the customer end. Similarly for customers requiring more addresses,
> assign
> | > them appropriately sized subnets.
> | >
> | > What configuration restraints?
> | >
> | > Whoever set it up being incapable is the only restraint I see here.
> | >
> | > Regards
> | >
> | > Bob
> | >
> | >
> | > For more information about this list (including removal) go to:
> | > http://www.iea-software.com/support/maillists/liststart
> |
> |
> |
> | For more information about this list (including removal) go to:
> | http://www.iea-software.com/support/maillists/liststart
>
>
>
> For more information about this list (including removal) go to:
> http://www.iea-software.com/support/maillists/liststart
For more information about this list (including removal) go to:
http://www.iea-software.com/support/maillists/liststart