Well, if the router CAN run BGP, the feed from Cymru is only about 84
prefixes - not a lot of memory tied up there, is there?
If the router isn't capable of BGP, someone earlier today was kind
enough to post a script that they use to find changes to one of the
BOGON lists and suggested an Expect script to automatically update their
router. Probably a little advanced for most leaf sites, but for someone
who's responsible for a larger network -- doesn't seem that bad.
James Laszko
Pipeline Communications, Inc.
james@pcipros.com
Well, if the router CAN run BGP, the feed from Cymru is only about 84
prefixes - not a lot of memory tied up there, is there?
I am *not* talking about the leaf - rather the core. I am curious what
resources are needed to manage 200K BGP peers other than 200K IP
addresses. Is there an IOS limit on the number of BGP peers? Memory?
-Hank
Well, if the router CAN run BGP, the feed from Cymru is only about 84
prefixes - not a lot of memory tied up there, is there?
my point was that not all managed routers, the majority actually, can't
and don't run BGP. their code doesn't even support bgp...
If the router isn't capable of BGP, someone earlier today was kind
enough to post a script that they use to find changes to one of the
BOGON lists and suggested an Expect script to automatically update their
router. Probably a little advanced for most leaf sites, but for someone
who's responsible for a larger network -- doesn't seem that bad.
and that 'auto update' has to have customer approval for each change. When
you deal with 70,000 customer routers making this approval happen is next
to impossible. As an example, how many do you think are/were upgraded for
the lsat 'cisco all platform' (just to pick on one low-end platform
vendor popular in this space) protocols bug? Not very many ... not nearly
enough.
If you are trying to fix this problem you'll have much better luck chasing
down the customers and having them raise this up to their provider.
I can't comment on that, but it strikes me that it might be a fairly
non-optimal solution, for the simple reason that we're talking about a
small, low-delta, highly-distributed feed where session state is going
to eat most of your CPU and memory, but any *one* session is unlikely to
really need much except keepalives. And, of course, no need to actually
route anything.
Sounds like an excellent thing to throw commodity (OK, probably rackmount,
but still) PC hardware at (potentially in clusters, I haven't looked into
what the memory/CPU load of sessions boil down to on recent versions of
BGP-capable software that runs on such).