|
Thread Index [isp-bgp] Re: Will I be killed for not aggregating?
The biggest reason cited in all the arguments I've ever heard is because of
router memory space. Each advertised prefix takes up a certain amount of
memory. Each provider I have is currently advertising between 125,000 and
135,000 routes to us. Every time you de-aggregate a shorter prefix you
increase the amount of memory required in my routers. Now, in the case that
started this particular thread, it's not that huge of a deal, going from 1
to 2 routes. However, there are companies who take entire /16's and
advertise them as 256 /24s. If 1 prefix takes up 2k of memory, then 256 of
them takes up 6144k. Suddenly it becomes more of an issue. So the BCP is to
aggregate as much as possible.
Thanks,
Adam Debus
Network Engineer, ReachONE Internet
adam@...
----- Original Message -----
From: "Serge Paquin" <isp-bgp@...p.ca>
To: <isp-bgp@isp-bgp.com>
Sent: Tuesday, February 17, 2004 6:41 PM
Subject: [isp-bgp] Re: Will I be killed for not aggregating?
Hello,
May I ask from an academic standpoint why advertising more specific
routes is a problem and why there is no good reason to ever do it? I figure
one reason is obviously the global route table size. But maybe I'm missing
something. I'm going multi-homed since I've started a small Hosting
facility in my city. No way I can get a /19 from ARIN so I got an AS and am
advertising a /24 from my upstream onto another provider.
This is not a money issue since I would have happily paid for the IP
space from ARIN but I would never qualify for that much IP space.
Is what Rick is asking about doing a totally different issue? Now that
I'm getting into the BGP world I want to ensure I don't step on any toes :)
Serge.
----- Original Message -----
From: "Rick Kunkel" <kunkel@...>
To: <isp-bgp@isp-bgp.com>
Sent: Tuesday, February 17, 2004 9:06 PM
Subject: [isp-bgp] Re: Will I be killed for not aggregating?
> On Tue, 17 Feb 2004, Arnold Nipper wrote:
> > >>
> > >>>Provided you have a good reason for deagg'ing your CIDR's, I think it
is OK.
> > >>>Traffic engineering would be one of them. However, do find out if
your providers
> > >>>will let your do meds or communities as both of these can sometimes
achieve
> > >>>the same effect (in the traffic engineering context) w/o the need to
deagg.
> > >>>
> > >>
> > >>IMHO there is *never* a good reason for de-aggregation. Why do you
want
> > >>to bother others for you poor network design?
> > >
> > >
> > >
> > > I had a feeling I might get scolded...hence my original subject line.
:)
> > >
> > > Again, ideally, I'd love it if we had a better connection between
NOCS,
> > > but since that's currently cost prohibitive, our options (I think) are
> > > limited to either not using BGP (but we're currently multi-homed, with
> > > four providers), or do this deaggregation bit. Would it be safe to
say
> > > that, given those options, you'd go for the "no BGP" one?
> > >
> >
> > I would have either set up two networks. One at each location. Or do
> > multihoming to the same provider(s) and have more specific announced to
> > them with no-export set (this was what Haesu already proposed).
> >
> > Everyone who injects more specifics thinks s/he has a good reason to do
> > so. But as stated before there is none. Having too little money is the
> > worst one.
>
> I'm a major proponent of keeping things tidy. The available budget is
> obviously something that the employer has the last word on. In my
> defense, it should be noted that, for the most part, I inherited the
> administration of the current network, and am trying my best to fix it
> where needed. Given the unalterable history of the way that this network
> _was_ set up, I'm trying to find ways to develop it into a network that
> adheres more strictly to the way that networks _should_ be constructed,
> and hence, one that you would probably approve more highly of.
>
> That being said, concerning your statement about the two networks: Is
> asking for two /20's instead of a /19 something that ARIN is likely to do?
> Or am I misunderstanding you?
>
> Sincerest thanks for your input,
>
> Rick Kunkel
>
>
>
>
> To unsubscribe via postal mail, please contact us at:
> Jupitermedia Corp.
> Attn: Discussion List Management
> 475 Park Avenue South
> New York, NY 10016
>
> Please include the email address which you have been contacted with.
>
> ------------------------ANNOUNCEMENT---------------------------------
> ---------------------------------------------------------------------
> ** ISPCON Spring 2004 ** Washington DC Hilton & Towers **
> ** The industry's ISP and WISP event ** www.ispcon.com **
> ** 10 years experience illuminating the market's future **
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
>
>
To unsubscribe via postal mail, please contact us at:
Jupitermedia Corp.
Attn: Discussion List Management
475 Park Avenue South
New York, NY 10016
Please include the email address which you have been contacted with.
To unsubscribe via postal mail, please contact us at:
Jupitermedia Corp.
Attn: Discussion List Management
475 Park Avenue South
New York, NY 10016
Please include the email address which you have been contacted with.
Thread Index |
|
