Jose,
JUNOS RR can have multiple cluster-ids. So do this:
1/ R3 cluster-id 1.1.1.1 to serve R1+R6,
2/ R3 cluster-id 2.2.2.2 to serve R2+R5,
3/ R4 cluster-id 1.1.1.1 to serve R1+R6,
4/ R4 cluster-id 2.2.2.2 to serve R2+R5
-- and I think you'll meet the requirement of "RR unique cluster-id
redundancy".
Rgds
Alex
----- Original Message -----
From: "Jose Bejarano" <[email protected]>
To: <[email protected]>
Sent: Sunday, October 31, 2010 12:21 PM
Subject: [j-nsp] RR unique-cluster-id redundancy
Sorry, issue should say "RR unique-cluster-id redundancy"
Hi,
Topology
RR 1.1.1.1
|----R1----------------R3-------------R5-------|
| | | | |
| | | | |
|-----R2---------------R4-------------R6-------|
RR 2.2.2.2
R3 Route-Reflector Cluster-id 1.1.1.1
R4 Route-Reflector Cluster-id 2.2.2.2
R3 1.1.1.1 BGP group client: R1+R6
R3 BGP group no-client: R2+R5
R4 2.2.2.2 client: R2+R5
R4 BGP group no-client: R1+R6
R1+R2+R5+R6 BGP group ibgp: R3+R4
iBGP full-meshed R3-R4
How to build redundandy in this scenario ?
Goal is to build RR redundancy using unique-cluster-id, RR R3 and R4
should have clients but R1,R2,R5,R6 may not be clients of different RR.
Feedabck and configuration examples are wellcome...
Cheers,
--
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
