RE: [pacnog] Splitting up prefix advertisements

["Alo Anesi" <Alo.Anesi@bluesky.as>]

Hi Philip,
 
Don't worry, I promise not to let my AS gain more than 10 ranking points on the CIDR-report. =)
 
The thing is, we did the usual method of assigning network gear at the high end of the range and customer addresses at the low end of the range. But that now means that the first 7 /24's of our /20 are customer IP's and, of course, they are the ones using most of the bandwidth.
 
If I chop it up at the /21 margin, the top half should be doing relatively minimal traffic since it contains network gear, servers, etc.
 
My current plan is to go with the /21 with the "fat" half announced to the primary provider and the other half to the secondary. Of course, the aggregate will be announced at both ends. However, I'll probably look into the actual peerings that my upstreams have to get a clearer picture of the situation.
 
By the way, looking glass and the cidr-report are awesome tools for this kind of project. Also, I would be completely lost with all of this had it not been for the Routing workshop in the last two PACNOGs, so I will be singing your praises for quite some time.
 
Cheers,
Alo
 
P.s.
I'm probably a slow learner, because it took me two PACNOG workshops to "get" BGP, hehe. But I'm hitting the ground running now.

________________________________

From: Philip Smith [mailto:pfs@cisco.com]
Sent: Sun 7/16/2006 3:23 PM
To: Alo Anesi
Cc: pacnog@pacnog.org
Subject: Re: [pacnog] Splitting up prefix advertisements



Hi Alo,

Alo Anesi said the following on 14/7/06 20:00:
>
> So from everything we discusses at the previous PACNOGs, it seems splitting
> up prefix advertisements is the best (only?) way to split inbound traffic
> when dealing with two different upstreams.

It's pretty much the only way unfortunately. No BGP implementer has
support for the no-peer community (RFC3765); that would have helped with
hiding local traffic engineering requirements of providers.

> My question is, can I go as far as splitting at the /22 boundary for my /20?
> I could split at the /21 boundary, but with the way we've been allocating
> customer addresses 90% of my usage occurs in the first half of my /20.

Well, you could subdivide all the way down to a /32 if you really wanted
to, but I really wouldn't bet anything on reachability of those
specifics if you do that. It is really important to always announce your
aggregate, even if you subdivide the block for traffic engineering purposes.

The other thing that very few people think about is how they do the
address assignments within their own backbone. If 90% of the traffic
comes into 5% of the address space, I'd encourage people to consider
renumbering to make the load balancing easier. Dynamic assignment pools
are easy to renumber, so if you need to move internal address space
usage around to help with load balancing, that's one possible target (I
did that years ago in my operational days).

> I realize the CIDR folks may frown on de-aggregation, but I need some way
> to load balance two links of different sizes from 2 different upstreams.

As one of the "CIDR folks", I frown on unnecessary deaggregation. I
reckon that 35% of the address space announced is simply people
announcing their address blocks split unnecessarily into /24s -
basically what I call leaking their internal BGP prefixes to the public
Internet. Internal BGP is only meant to be visible inside an Autonomous
System - external BGP has a different purpose, and that's where all SPs
need to be prudent. So careful deaggregation to assist with traffic
engineering is just one of those facts of life - but Alo, please don't
take your /20 and spray it out to the world as 16 /24s with random
AS-PATH prepends to do your load balancing. There are many better ways,
e.g. as per the PacNOG workshop materials from the last meeting.

philip
--