Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

MediaOne dns problems



[I'm sorry this is so long, I just wanted to get these thoughts down
in one place]

[Ron Peterson: Tue, Apr 10, 2001 at 12:47:28PM -0400]
> 
> On 10 Apr 2001, Derek Atkins wrote:
> 

> > Actually, that's not true.  Unless they have a good "plan" in place,
> > they may need to re-subnet the town as more users come online.
> > Remember that your whole town is NOT on one subnet.  Generally you are
> > subnetted by fiber node, which can handle several neighborhoods.  As
> > the neighborhoods get saturated with users, they need to partition the
> > space, hense a renumbering.
> 
> Umm, of course.  Excuse me while I backpedal and eat crow...
> 

well, I'd argue that dhcp makes a great deal of sense for a cable
provider, but not primarily for this often cited reason.

The argument makes the presumption that there should be one route to a
segment.. so let's say I'm on a a segment that is a /22 (1023
addresses) that gets too busy and so needs to be split into 2
different segments - logically let's say 2 /23's (2 sets of 511). DHCP
makes that easy enough to have happen. People renumber, and then the
segments are physically broken apart and interfaces added to the
headends and routes adjusted.

However, lets rewind the clock.. instead of having one /22.. why not
32 /27's (each with 31 usable addresses) that are all routed to the
same segment.. when that grows too busy some of those /27's can be
physically moved to a new segment and the route adjusted without
anybody renumbering or any other changes being made at the
desktop. You've essentially pre-partitioned the software but not the
hardware (the hardware is damn pricey... you don't buy very far
ahead of need)..

There are some downsides, but most of them aren't a big deal in this
context:

aggregation: the AT&T routers now carry more local routes. somewhere
between 16 and 32 times as many from my example. But let's not forget
that these segment splits actually do represent physical geography and
pretty quickly those routes can be aggregated back into /22's and
similar sized things that are announced throughout the greater AT&T
network, and eventually into bgp.. so the route size is only
multiplied in the scope of the routers that are the stubs for these
routes.. so we don't multiply all the AT&T routes by 32, we
effectively add just (at max) a couple hundred routes to each edge
router, but they still advertise the old number of routes to their
peers after all the splits are taken into account (maybe a hop or
two).. so we add 0 routes to the real interior routers.. given that
the core BGP route table size is running ~100K announcements right
now, this is just noise for any decent BGP/OSPF implementation and
hardware and has absolutely no impact on any kind of Wide Area
scenario.

overhead: Each subnet costs you one broadcast address that you can't
use as a host address. (historically it also costs you a network
address, but that hasn't been technically true for a long time but to
avoid problems with some old implementations a lot of people don't use
the all 0 host address. I do use it - ymmv.) so having 32 /27's instead
of 1 /22 costs you 31 potential hosts in the same addressspace, or about
3%. This does indeed suck, but 3% seems payable to me.

restricting broadcast domains: If there is a lot of chatter between
hosts that are both located on the same physical segment, but under the
new scheme are in different blocks, the new scheme forces the router
to get involved.. this is slower and more costly for
everybody. Nothing I know about residential service tells me this is a
serious possibility though. The only locality I'd see is with
Home-Networking, and a /27 (or similar) should be able to hold that
without a problem.

.....

alright, I said all that in defense of static-ips-as-reasonable but at
the top I also said I think DHCP makes a lot of sense for a cable
provider primarily because of other reasons.. for the sake of
completeness those reasons are:

  * configuration. Given the massive number of end users, they will
    over time break their own static configurations. DHCP provides a
    lot less knobs. No pieces of paper to keep track of when you re-OS
    your machine. I honestly believe simplicity of user configuration
    and maintenance issues are the primary reason.

  * security. AT&T doesn't do this, but they should: packets on their
    network could be cross referenced against their current DHCP lease
    to make sure that the MAC address matches. mismatches can be
    flagged as potential spoofing attacks. You can do this
    on a sampling basis (and asynchronously to boot) so the load really
    isn't overwhelming. 

  * perceived anonymity. This will be hard for the BLU crew to
    believe, but there's a huge contingent of cable modem users who
    are genuinely annoyed that they *don't* get a new IP each time
    they renew their lease. Their case is that when browsing across
    sessions and sites your IP can be used to correlate the
    sessions.. of course the fact that at&T provides a consistent (at
    least most of the time) reverse lookup for your IP even in the
    case of a rare renumber isn't one of their favorite features
    either. I don't have a lot of sympathy for this argument myself,
    but it's popular in some circles.

  * arin renumbering. There is a legitimate case in my mind for
    renumbering, and dhcp certainly makes that easier. The issue isn't
    when a local segment gets too busy (the topic of the top half of
    this too long missive.), but related to the fact that address
    space is a scarce resource. Most providers can't get enough
    address space to hold all of their customers for 3 years out. In
    order to conserve addresses ARIN won't give them substantially
    more than what they need in the close-future. At some point, if the
    business prospers, they will need another allocation.. after a
    couple iterations of this process they have a handful of global
    allocations that aren't contiguous.. because it's in the
    Internet's best interest that global routes are aggregatable (and
    therefore contiguous) ARIN will let them trade in the handful of
    smalls for a single larger one.. but that involves
    renumbering. You generally get 6 months to make the transition.

....

and one final thought: for those of you arguing that there isn't
enough competition and features aren't as good as they should be for
the price you pay, please think back all the way to 1993 or 1994 when
you could easily pay 5 grand a month for a T1 that didn't include any
very expensive hardware.. I'm still amazed at all the bandwidth I get
to my home for $29.95 a month (not including some very cheap
hardware). The pace at which this is moving is astounding.


-P
-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org