[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