|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Date: Tue, 31 Jan 2012 11:27:52 +0100 From: Fredy Kuenzler <kuenzler@init7.net> To: nanog@nanog.org In-Reply-To: <CADb+6TB=qjkwqu6nWso5z+_t485wSUPGRLPz=06xwYcnRb3z1Q@mail.gmail.com> Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org Am 31.01.2012 04:06, schrieb Joel Maslak: > There are several ways to handle this is, if you have at least two > /24s of space. > > Let's say you just have two /24s, both part of the same /23. > > [...] Sad to see that deaggregation is still propagated to handle this issue. As a matter of fact deaggregation pollutes the global BGP table with more than 40% of rubbish, mainly caused by this silly type of traffic engineering. See the weekly routing table report or the CIDR report: > Analysis Summary > ---------------- > > BGP routing table entries examined: 394446 > Prefixes after maximum aggregation: 169250 > Deaggregation factor: 2.33 > Unique aggregates announced to Internet: 191523 There are many smarter ways to manage unbalanced links. See my slides presented on various occations (page 31 to 48) which describes the disadvantages and collateral damage of deaggregation: http://www.swinog.ch/meetings/swinog23/p/03_BGP-traffic-engineering-considerations-v0.2.pdf HTH, -- Fredy Künzler Init7 / AS13030
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |