[j-nsp] RR unique-cluster-id redundancy

[Alex]

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" <Jose.Bejarano at gmx.net>
To: <juniper-nsp at puck.nether.net>
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 juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp