[nsp] RAM for two unique views?

Pete Templin petelists at templin.org
Tue Mar 9 14:20:43 EST 2004


My idea was concocted around statically routed customers, so my thought 
was to group cheap upstreams on one or more core boxes and expen$ive 
upstreams on separate core boxes.  I'd then build an alternate VRF on 
the agg routers, with a higher weight towards the cheap upstreams.  I'm 
not sure I could do much with route servers, but one never knows.

Stephen J. Wilcox wrote:

> variation on a theme.. can you achieve the same (similar) result with route 
> servers where you ebgp-mhop the customer a different table based on service 
> class.. anyone doing any split level service like this ?
> 
> Steve
> 
> On Tue, 9 Mar 2004, Pete Templin wrote:
> 
> 
>>List,
>>
>>If (and this is all hypothetical, just in case the PHB comes up with the 
>>  idea) I were to put a full BGP view in the default IPv4 routing table 
>>AND a full BGP view in a VRF routing table, what's the minimum likely 
>>RAM that would be safe?  In other words, are there any economies of 
>>duplication that would aid the memory usage, or am I looking at 
>>384-512MB of memory (i.e. NPE-400, NPE-G1, RSP16) needed to accomplish this?
>>
>>(For the curious, I'm looking at options for two unique routing tables, 
>>one with good & fast but expensive bandwidth, the other with cheap YMMV 
>>bandwidth.  The idea is to be able to reprovision the customer(s) 
>>between the two blends without rehoming them into a different 
>>aggregation router, and/or having to procure a separate agg router, etc. 
>>  I'm not thrilled about the concept, but I figure I'd better have my 
>>ducks in a row before I get caught off-guard.)
>>
>>pt
>>_______________________________________________
>>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>https://puck.nether.net/mailman/listinfo/cisco-nsp
>>archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
> 
> 
> 


More information about the cisco-nsp mailing list