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
> - 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
> 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...
cisco-nsp mailing list firstname.lastname@example.org
archive at http://puck.nether.net/pipermail/cisco-nsp/