not to make this too cisco specific, but...
the number of entries in the forwarding cache on the
sse is generally more than the number of routes in
the bgp rib (because of the way the cache handles
more-specifics of over-lapping aggregates). so in
addition to the raw number of routes in the rib, the
efficiency (and scope) of aggregation are also
important data points
now a question. what does an sse do when its cache
fills? it used to(*) bring down the whole sse, which
doesn't really make much sense given that it's a
cache and therefore it's normal operation for it to
be incomplete. anyone know an answer to that one?
/jws
(*) -- "used to" implies that it happened before,
which it did. but that was largely due to the
ineffeciency of the data structures, and the problem
was solved such that 2 years (and counting) was added
to its life
BTW, really all data incorporated from BGP protocl for
3 - 8 core routings do not need more than 32MB RAM; the fact CISCO
need more than 32MB ram for core routing is due to inefficient data
structures... Exactly it's because they (I think) have solved some
other task (not minimize memory, but CPU and development time).
What is really 100K routes?
100K * (
8 bytes - address + maska
4 - pointer to interface
4 - pointer to ASPATH (ASPATHES are really shared by many
different routes; You have not 1000,000 different AS
PATHES at all)
8 - accounting
8 - some other,
) - it's about 32 bytes in this example.
Of cource, it's not true - really we can expect about 64 bytes/route.
64 bytes * 100K = 6 Mb RAM. I can propose it's nessesary 128bytes - it'll be
12MB RAM.
But anyway, if somebody designes specially INTERNET CORE router,
he can hold any core routing tables in 16 MB RAM, not more. There is
a lot of different ways to minimise memory usage.
We are far from the theoretical memory leak; the more serious problem
may be efficiensy etc..., but there is CISCO FUTIONS and other ideas
to hold CPU usage in acceptable range.
I am shure we'll be the witnesses of the such events as it have been last
year when CISCO's engeneers have fixed serious BGP problem in 1 or 2
nights. Through this way (to solve hardware problems by software)
have it's limits.
In cisco.external.nanog you write:
not to make this too cisco specific, but...
the number of entries in the forwarding cache on the
sse is generally more than the number of routes in
the bgp rib (because of the way the cache handles
more-specifics of over-lapping aggregates). so in
addition to the raw number of routes in the rib, the
efficiency (and scope) of aggregation are also
important data points
now a question. what does an sse do when its cache
fills? it used to(*) bring down the whole sse, which
doesn't really make much sense given that it's a
cache and therefore it's normal operation for it to
be incomplete. anyone know an answer to that one?
SSE memory usage is monitored and if it falls below a particular
threshold, the ager will become more aggressive in aging entries..
--ravi