On Wed, 30 May 2001, Jeff Mcadams wrote:
You might be better off letting your next hop handle the aggregation. Aggregates never worked the way I (personally) thought they should on the Arcs. I was always of the idea that combining network aggregation with IP pool definitions was a bad idea. I always thought they should have defined IP pools, and then handled aggregation of routes in a seperate control area, but, 3Com has a history of not listening to me,
Actually they do: anunu2> list ip pool IP ADDRESS POOLS Name Address Size InUse State Route Unused Priority Status pool01 64.65.75.176/A 192 41 PUBLIC MULTI_AGGR 0 1 ACTIVE anunu2> list ip agg IP Aggregate Routes PoolName Aggregate Route Size Type pool01 64.65.75.176/28 16 MULTI_AGGR pool01 64.65.75.192/26 64 MULTI_AGGR pool01 64.65.76.0/26 64 MULTI_AGGR pool01 64.65.76.64/27 32 MULTI_AGGR pool01 64.65.76.96/28 16 MULTI_AGGR Notice the MULTI_AGGR in the listing for pool01? The neat thing with this is you just define the pool starting address as you normally would and it figures out the aggregates. The zero'th address in each aggregate doesn't present a problem as the box answers/arps for the entire range anyway. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.