Oh well, I am more into blocking certain ASNs and insert a default route
into the network. I took some of the top de-aggregation networks from
the CIDR-reports, that I am not interested in, and generated some
negative list.
Input:
https://github.com/ipcjk/asnbuilder/blob/master/customASN.txt
Output:
https://github.com/ipcjk/asnbuilder/blob/master/saveTheFIB.txt
This saves around 90k IP4 routes and 13k IP6 routes, nothing fancy
there. This can be fine-tuned to bare minimum, enriched with *-flow or
telemetry data and aligned with downstream customers.
So instead of our current positive tracking (which ASN accumulates
what-bytes), we could apply negative tracking (which ASN is not peer, is
not having traffic, ..) and add this to our saveTheFIB as-path. If the
netflow collector sees traffic to a ASN, put the routes back into the
system.
Long-term I am thinking about the SLX9640 as a replacement for our edge
MLXE-4s. Also I often jealously look at the CER-RT-X FIB and cry ;)
Jörg
On 29 Jan 2019, at 11:30, Fredy Kuenzler wrote:
Am 29.01.19 um 10:59 schrieb Jörg Kost:
Meanwhile, BGP4 aggregation is our new buddy... #LifeBeyond750k.
Would be interested to know your aggregate / filter criteria,
anything fancy that we all can use? Have you already installed some
filter for the tragedy of the IPv6 routing table?
Regarding the aggregation aka #LifeBeyond750k I presented some concept
ideas at SwiNOG 33. See the presentation (May 2018) here.
http://www.swinog.ch/wp-content/uploads/2018/07/Fredy_Kuenzler_life_beyond_750k_init7.pdf
We made further tests since and we are also addressing the IPv6
aggregation with priority these days and should be able to come up
with
configuration examples shortly.
_______________________________________________
foundry-nsp mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/foundry-nsp
