[j-nsp] Summarize Global Table
Chris Morrow
morrowc at ops-netman.net
Wed Oct 26 09:21:55 EDT 2011
On 10/26/2011 12:10 AM, Shane Amante wrote:
> With respect to S-VA, it appears you would need to play games with
> carrying either a default route or less specifics (aggregates) with
> NO_EXPORT, etc. around your network and having the potential to
> accidentally leak them beyond your network. However, what's more
> concerning is clearly some prefixes (more specifics) are going to be
> responsible for carrying *a lot* of traffic, (think: popular CDN's,
> portals, etc.), which you want to ensure are optimally routed. The
in any case that you remove some of 'all the data' the routing table,
more stretch for some prefixes is introduced, right? So this isn't
particularly unexpected.
> problem is, AFAICT, S-VA makes you identify _and_ maintain those
> 'popular prefixes' on your own to ensure that you optimally route
> them. In theory, one might use Netflow to periodically determine and
sure, same for all instances of the 'remove some routing data' solutions.
> adjust the list of "popular prefixes", but what happens when you
> experience a sudden influx of traffic? How fast are you going to be
> able to react?
the real trick, as you highlight, is to figure out a method to identify
and maintain and TE (properly) prefixes which are hot at some point in time.
One argument is that sloshing some traffic on less optimal paths which
are not overloaded isn't really bad, it may even be less costly to
upgrade the links than to run around upgrading fib/rib/cpus on aging
hardware, right?
-chris
More information about the juniper-nsp
mailing list