On 13/Mar/18 13:04, adamv0...@netconsultings.com wrote:
> Keeping RR1s separate from RR2s is all about memory efficiency, That memory saving could now be entering the real of "extreme", but hey, your network :-)... > > The same rationale is behind having sessions between RRs as non-client > sessions. > - In combination with separate RR1 and RR2 infrastructures each RR (RR1/RR2) > in the network learns only one path for any single homed prefix. > - If I’d have RR1s and RR2s all mixed in a full-mesh then each RR would get 2 > paths > That is double the amount of state I’d need to keep on every RR in comparison > with separate RR1 and RR2 infrastructures. The actual routes the RR's would exchange with one another in a shared Cluster-ID scenario would be the routes they originate. Provided you are a network that does not de-aggregate, you're looking at just whatever allocations you obtain from your favorite RIR. Not about to break the memory bank (pun intended, hehe) compared to the state of the global Internet routing table. > If sessions between RRs are configured as client sessions AND Don't know why you'd do that. Inter-/intra-RR sessions should not be clients, IMHO. But like I said, your network... Mark. _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
