How design rr-group for addition redundancy!

In a large sp mpls-based L3-vpn network,there is rr-group,for dedicated vpnv4 routes.

but there is a single point of failure.

For example,there are 4 PEs,and two vpns(VPN-a  VPN-b),located on every PEs,

of course,there are two RRs(not in forwarding path),RR-a and RR-b server to VPN-a and VPN-b,respectively.

Here is configuration: 

PEs:

ip vrf A

   rd 1:1

  route-target 1:1 both

ip vrf B

   rd 2:2

  route-target 2:2 both

 

rotuer bgp 1

no bgp default ipv4-unicast

no bgp default route-target filter

neighbour RR-a remote-as 1

neighbour RR-a update-source loopback0

neighbour RR-b remote-as 1

neighbour RR-b update-source loopback0

address-family vpnv4 unicast

      neighbour RR-a active

      neighbour RR-a send-community ext

      neighbour RR-b active

      neighbour RR-b send-community ext

 

RR1:

ip extcommunity-list standard VPN-a

    permit rt 1:1

router bgp 1

     no bgp default ipv4-unicast

     neighbour all-pes remote-as 1

     neighbour all-pes uodate-source loopback0

   address-family vpnv4 unicast

    neighbour all-pes active

   neighbour all-pes send-community ext

   rr-group VPN-a

 

RR2:

ip extcommunity-list standard VPN-b

permit rt 2:2

router bgp 1

no bgp default ipv4-unicast

neighbour all-pes remote-as 1

neighbour all-pes uodate-source loopback0

address-family vpnv4 unicast

neighbour all-pes active

neighbour all-pes send-community ext

rr-group VPN-b

 

what i wondered is the relationship between RR1 and RR2,

if there should have a ibgp or not ?

if have,the ibgp is common or is RRC each other?

whatever solution,there seems to be a single point of failure, (for example :the failure of RR-a)

how should i do to fix it ?

Comments

  • The route reflectors need to be fully meshed if there are multiple RRs. You usually divide RRs in clusters depending on geography. Maybe West coast is one cluster, East coast another etc. RRs run regular iBGP session to each other, they should not be clients of each other.

    The clients have two sessions, one to each RR. You could setup the clients to peer to RRs in different clusters as well but it depends on the topology. If it is impossible to reach RR in other cluster without passing through RR in your cluster then it makes no sense to use that setup.

     

  • Here is a very good link describing this feature:

     

    http://wiki.nil.com/BGP_route_reflectors

     

    HTH

Sign In or Register to comment.