[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Please help our simple bgp
- Subject: Please help our simple bgp
- From: kuenzler at init7.net (Fredy Kuenzler)
- Date: Tue, 31 Jan 2012 11:27:52 +0100
- In-reply-to: <CADb+6TB=qjkwqu6nWso5z+_t485wSUPGRLPz=06xwYcnRb3z1Q@mail.gmail.com>
- References: <CACwqZxjBp_R_b-r-9zdB+4xSO1mPmfaYhg8nuDwnt7g2i6RXTg@mail.gmail.com> <CADb+6TB=qjkwqu6nWso5z+_t485wSUPGRLPz=06xwYcnRb3z1Q@mail.gmail.com>
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