Routing

When I  have two RRs in the same cluster,what should be  the realtion  between them?I use 2 RRs for redundancy

two RRs has normal IBGP neigbhor session now

my questions is :

1:they need to peer as non-clients,right?

2:if I set 2 RRs as RR client with each other,is it fine?

Hi Robert.

This is fine if you receive ibgp routes from r3 and r4. They need to be rr clients if both ebgp sessions need to propagate those prefixes. If are not clients, will propagate ebgp routes anyway.

r1,r2,r3,r4 are ibgp relation,outside this ,there is another router(ebgp) connect to r1 and r2 ,

I wanna know whch relation should be between r1(RR) and r2(RR)

Hi Robert.

This is fine if you receive ibgp routes from r3 and r4. They need to be rr clients if both ebgp sessions need to propagate those prefixes. If are not clients, will propagate ebgp routes anyway.

----I am a little confused here

it seems client or non-client,it doesn't matter

can u descibe it in detail

   Have to remember that bgp is not like other routing protocols. It blocks the prefix advertisement, depending on if the peer is a ibgp, or ebgp connection.

   Anything you learn from a ebgp peer (on other AS) will be propagated to all peers, ebgp and ibgp.

  Anything you learn from a ibgp (in your same AS) will be blocked, not propagated to other ibgp peers

  RR clients, override the ibgp block rule.

  This is why under BGP you need a full mesh ibgp relationshipg, from all ibgp peers to all ibgp peers. But this could be hard to configure and maintain on large deployments. You have to configure n*(n-1) peer relationships.

  So, if you learn something from R3/R4, will not be propapagated to any ibgp peers, unless you configure some RR clients. Even if you hace some upstream routers, that connect to the outside world through ebgp, then will need to configure these as RR clients. But only, if you propagate prefix from R3/R4. If not, R1/R2 will not propagate nothing to the eR routers, look, under the following topology, if you propagate from R3/R4, eR1 and eR2 need to be RR clients. If not, onlye R3 and R4 should be RR clients.

R1 and R2 should be clients only if they learn prefix from R3 and R4.

AS 11111

                                       R1                                          R2

-----              ebgp          |                                               |

AS 22222                      |                                                |

                                      eR1                                        eR2

                  ibgp              |                                                |

                                        |                                                |

                           RR      R1      -----------------------       R2

                 ibgp               |              \                       /           |

                                        |                                                |

                                       R3                                           R4

AS 11111 R1 R2 ----- ebgp | | AS 22222 | | eR1 eR2 ibgp | | | | RR R1 ----------------------- R2 ibgp | \ / | | | R3 R4

hi,Alex

I think u misunderstaood me

in your topo

r3 r4 are RR client of r1 and r2  which means r1 and r2 are RR server

r3 and r4 need to advertise to outside

my question is :

relation between r1 and r2

1:"normal ibgp neighbor"  or "r1 is client of r2/r2 is client of r1"

pls remember both of them are RR server for r3/r4

2:as I know,RR is used in ibgp,no matter what EBGP

The two route reflectors (R1 and R2) should have a normal iBGP neighborship (non-client).  They do not need to "reflect" internal routes from clients.  Since all clients of this cluster should have bgp sessions to both. They must be fully meshed with any other route reflectors in the AS.

Ben

What i means.

R1 to R2 RR clients, ibgp..

R3/R4 RR clients, ibgp.

eR1/eR2 RR clients, ibgp.

Why, because what you learn from R3 and R4 have to be propagated to eR1/eR2 via an ibgp peer.

What you learn from eR1/eR2 via ibgp have to be propagated to R3/R4.

If you lost your eR1 ebgp peer, then have to propagate R3 prefix from R1 to R2, and from R2 to eR2.

Every time you need to propagate a prefix from a ibgp peer to other ibgp peer, you need a RR relation with the second peer.

As Bob saids, if your R3/R4 peer with both RR, then the R1/R2 peering dont need to be RR client. Because you dont need to  propagate ibgp learned prefix to other ibgp peer. R1/R2 will learn this directly from R3/R4.

  The rule is always, if learn form ibgp, and need to propagate to other ibgp peer, second peer have to be a rr client.

ah,I see

thanks very much

r3/r4 have connections to r1/r2 and are RR client of them,so r1 peer r2 as normal ibgp neighbor is sufficent,right?

btw: if I set r1 peer r2 as RR client and r2 peer r1 as RR client,what will happen?

Right.

If you mutually rr client r1 and r2, will have a backup path for the peering from r3 and r4 to r1 and r2. Example, from r3 to r2 through r1, and from r4 to r1 through r2. If you lost the direct peer r3-r2, r4-r2, r1 will not propagate to r2 what learns from r3, and r1 will not propagate to r2 what learns from r4.

cool.Alex

if I mutually rr client r1 and r2,it will not work as I expect,right?

If you lost the direct peer r3-r2, r4-r2, r1 will not propagate to r2 what learns from r3, and r1 will not propagate to r2 what learns from r4.

-------------so r3 can't talk to r4

-------------the reason why r1 will not propagate to r2 is ? r2 and r3 are client of r1,r1 should propagate to r2 which he learns from r3

would u like to explain a little more on this?

You have always to think on the ibgp rule. If you learn a prefix from a ibgp peer, will not propagate to other ibgp peer.

This is why you need RR if there is two hops between to ibgp routers. Second router will not propagate ibgp prefix to other ibgp peers, unless these are RR clients. RR break the ibgp rules, and allow to propagate ibgp learned prefix to rr clients ibgp peers.

  So R3 - R1 - R2

    R1 should be RR server and R2 client if want to receive R3 prefixes.

    R1 should be RR server and R3 client if want to receive R2 prefixes.

r3  RR client

r1 RR server

r2 non-client

r1 will propgate r3's route to non-client r2 ,this is a rule in RR definition

I always want to know

1:if r1 and r2 are normal ibgp neigbhor ,it is fine?

2:if I set r1 and r2 are RR client of each other,what will happen
?

You swap the rule.

r3  RR client

r1 RR server

r2 non-client

r1 will propgate r3's route to non-client r2 ,this is a rule in RR definition   ----> Wrong.

    R1 will propagate R2 prefix to R3 because R3 is the RR client.

    If not you dont have control on to which ibgp peers do you propagate what prefix. Not all peers need to receive ibgp prefix.

   R1 and R2 are always normal ibgp peers.

   If both are RR clients, both will propagate to each other the ibgp prefix they learn from other ibgp peers.

   R3    - -    R1    - -     R2   -  -     R4

   R1 / R2 RR servers and clients.

   R3 - is R1 rr client.

   R4 - is R2 rr client.

   R1 will send all ibgp prefixes to R2 because R2 is a rr client.

   R2 will send all ibgp prefixes to R1 because R1 is a rr client.

   This way, R3 will learn the R4 prefixes because under R1 this is configured as RR client.

   R4 will learn R3 prefixes because under R2 this is configured as RR client.

have u done test on this?

I have done many test on this

r1 RR server

r3  RR client

r4 non-client

r1 will advertise route of r3 to r4

jucao@r3# run show route advertising-protocol bgp 192.168.99.3    

inet.0: 70 destinations, 70 routes (70 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 1.1.1.1/32              10.80.230.1                  100        I

jucao@r1# set protocols bgp group iBGP-jfw030 cluster 1.1.1.1

jucao@r40> show route 1.1.1.1    

inet.0: 58 destinations, 58 routes (58 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.1.1.1/32         *[BGP/170] 00:00:02, localpref 100, from 192.168.99.3
                      AS path: I
                    > to 10.80.215.1 via reth1.0

  Hi Robert, im sorry very busy last days.

  I think there is someting wrong in your configuration.

  If i understand your topology from your show commands.

  This looks like your R1 address is 192.168.99.3. R1 R2 and R3 are under the same lan network.

  R3 route to 1.1.1.1/32, have a next hop, this is not a self generated route. This is a ibgp route, so if you propagate this to R1, 192.168.99.3, then R3 is configured as RR Server with the Cluster command under the R3 configuration. So this is not only a RR client, this is a RR server.

  R1 receive the route from a ibgp neighbor. Unless you configure R4 as no-client-reflect, this is a RR client. So will propagate this prefix to R4.

  I believe you have a cluster command under your R3 configuration, and you miss the no-client-reflect configuration for R4 under R1.

  You have to fully understand how the junos configuration works.

  RR server, this is the ibgp router that you configure with the cluster id command.

  RR client. This is every ibgp peer of the RR server.

  RR non client. This is every ibgp peer you configure with the no-client-reflect option under the RR server configuration.

  So, for default every ibgp peer is a RR client under the RR server.

  Look to the following example.

  R1  --- .1    12.12.12.0/24     .2   ---  R2   ---- .2   23.23.23.0/24    .3  --- R3   --- .3     34.34.34.0/24   --- R4.

  R1 - R2   ibgp

  R2 - R3   ibgp

  R3 RR server, cluster 3.3.3.3

     Under R3, R2 no-client-reflect.

     R4 ibgp.

  R4 - R3    ibgp.

  Under this configuration :

      R2 will receive R1 prefixes. (ibgp)

      R3 will not receive R1 prefixes. (R2 is not RR server).

      R3 will receive R4 and R3 prefixes. (ibgp)

      R2 will not receive R4 prefiexes. (Under R3 is no-client-reflect).

      R4 will receive R3 and R2 prefixes (RR client)

  Attached you could find all configurations and shows. For sure works this way.

Attachment(s)

BGP RR example.txt   22 KB 1 version

hello,Alex

thanks very much for your reply

but I found this in the jncis book

BTW: in my topology,R3 is client, R1 is RR server,

Also in my opinion,we need to configure ibgp peer as Client instead of automatically consider it as CLIEN in RR

hope section below can explain something to u

Operational Theory
Now that we’ve touched on the basics of what a route reflection network is and the terms used
to describe it, let’s discuss how routes are propagated. In addition, we’ll touch on some design
issues related to route reflection.
Figure 5.8 shows the Zinfandel, Chablis, and Cabernet routers in a route reflection cluster. The
Zinfandel router is the route reflector for the cluster, assigned an identifier of 1.1.1.1, while Cha-blis and Cabernet are the clients. Each of the clients forms an IBGP peering session with just the
RR and not with each other. This reduction in peering sessions pays large dividends as the net-work size grows and greatly reduces the number of overall peering sessions in the AS. The route
reflector forwards active BGP routes based on how they were received using the following rules:
From an EBGP peer When an RR receives an active BGP route from an EBGP peer, it forwards
the route to all clients in its cluster as well as to all other IBGP nonclient peers. The Cluster List
and Originator attributes are added only to routes advertised to clients within the cluster.
IBGP Scaling Methods 355
From an IBGP client peer When an RR receives an active BGP route from an IBGP peer that
belongs to its cluster, it forwards the route to all other clients in its cluster as well as all other
IBGP nonclient peers. These IBGP advertisements contain the Originator ID attribute and a
modified Cluster List. The route reflector also advertises the route to all of its EBGP peers with-out adding the route reflection attributes.
From an IBGP nonclient peer When an RR receives an active BGP route from an IBGP peer
that is not within a cluster, it forwards the route to all clients in its cluster with the appropriate
attributes attached. The route reflector also advertises the routes to its EBGP peers without the
route reflection attributes

  Hi Robert.

  Be carefull with the Juniper documentation, some times its vage, and may take you to this confusion.

  What you will not find in the jncis book :

   Questions :

   1.-  Do i have to configure the cluster command under RR Clients ?.

   2.- What is a rr client inside cluster ?.

   3.- What is a ibgp peer not inside first cluster ?.

   4.-  Could a RR reflector belong to several clusters ?.

   5.- How do i configure a single cluster for all ibgp peers.

   6.- What is a no rr client ibgp peer.

   Answers :

   1.- No. Dont configure the cluster command under normal(client or non rr client) ibgp peers. This command is used to configure this router as RR server.

   2.- This is every peer under a bgp group with the cluster command.

           set protocols bgp group RR-Cluster-1 cluster 1.1.1.1

           set protocols bgp grup RR-Cluster-1 neighbor 10.10.10.1

           set protocols bgp grup RR-Cluster-1 neighbor 10.10.10.2

           set protocols bgp grup RR-Cluster-1 neighbor 10.10.10.3

           set protocols bgp grup RR-Cluster-1 neighbor 10.10.10.4

   3.- This is every ibgp peer not inside same bgp group.

           set protocols bgp grup RR-Cluster-2 neighbor 11.11.10.1

           set protocols bgp grup RR-Cluster-2 neighbor 11.11.10.2

           set protocols bgp grup RR-Cluster-2 neighbor 11.11.10.3

           set protocols bgp grup RR-Cluster-2 neighbor 11.11.10.4

    4.- Of course

           set protocols bgp group RR-Cluster-2 cluster 2.2.2.2

    5.- Easy, this will be a third cluster for every other bgp group.

           set protocols bgp cluster 3.3.3.3

    6.- set protocols bgp group No-client neighbor 12.12.12.12 no-client-reflect.

             or even

         set protocols bgp group RR-Cluster-1 neighbor 12.12.12.12 no-client-reflect

ok,Alex

thanks for your reply

I told u everything I configured, and I hope u can do a same test on junos

R3-----R1-----R4

I set clusterid in R1 under a group

          set protocols bgp group RR-Cluster-1 cluster 1.1.1.1

then I configure R3 as R1's client

           set protocols bgp grup RR-Cluster-1 neighbor 10.10.10.1

R1 peer with R4 as normal ibgp session

so ,now ,R3 is RR client,R4 is non-client,right?

I advertise route in R3,and R1 reflect this route to R4

hahaha

I did find there are some **bleep**ty thing in juniper book

ha

ha

pls remember R1 peer R4 in a different group

  Right, this will work that way. Think that you only have two ibgp peers, will reflect each other, so will not see any different behaviour to configure R4 in the same cluster.

 R1 will reflect R3 prefixes to R4, and R4 prefixes to R3. But R3 is a RR client and R4 not. This would be a strange behaviour. The answer, R4 is outside the RR cluster. So prefix from inside cluster are reflected outside cluster, and from outside to inside.

  If you add a R5, R6 routers, outside cluster, will reflect R3 routes to every ibgp peer outside cluster. But will not reflect R4, R5, R6 prefixes between them, because they are not in a RR cluster.

 Look, the following changes to my configuration. Will reflect routes inside cluster and outside cluster.

delete routing-instance RI3 protocols bgp cluster

delete routing-instances RI3 protocols bgp group RI2 no-client-reflect

set routing-instances RI3 protocols bgp group RI4 cluster 3.3.3.3

admin@MX> show route advertising-protocol bgp 34.34.34.3

RI4.inet.0: 45 destinations, 46 routes (41 active, 4 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.4.1.0/24             Self                         100        I
* 10.4.2.0/24             Self                         100        I
* 10.4.3.0/24             Self                         100        I
* 10.4.4.0/24             Self                         100        I
* 34.34.34.0/24           Self                         100        I
* 172.19.100.0/24         Self                         100        I
* 172.19.101.0/24         Self                         100        I
* 172.19.102.0/24         Self                         100        I
* 172.19.103.0/24         Self                         100        I
* 192.168.112.0/24        Self                         100        I
* 192.168.113.0/24        Self                         100        I
* 192.168.114.0/24        Self                         100        I
* 192.168.115.0/24        Self                         100        I

admin@MX> show route advertising-protocol bgp 23.23.23.2

RI3.inet.0: 55 destinations, 59 routes (55 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.3.1.0/24             Self                         100        I
* 10.3.2.0/24             Self                         100        I
* 10.3.3.0/24             Self                         100        I
* 10.3.4.0/24             Self                         100        I
* 10.4.1.0/24             34.34.34.4                   100        I
* 10.4.2.0/24             34.34.34.4                   100        I
* 10.4.3.0/24             34.34.34.4                   100        I
* 10.4.4.0/24             34.34.34.4                   100        I
* 23.23.23.0/24           Self                         100        I
* 34.34.34.0/24           Self                         100        I
* 172.18.100.0/24         Self                         100        I
* 172.18.101.0/24         Self                         100        I
* 172.18.102.0/24         Self                         100        I
* 172.18.103.0/24         Self                         100        I
* 172.19.100.0/24         34.34.34.4                   100        I
* 172.19.101.0/24         34.34.34.4                   100        I
* 172.19.102.0/24         34.34.34.4                   100        I
* 172.19.103.0/24         34.34.34.4                   100        I
* 192.168.108.0/24        Self                         100        I
* 192.168.109.0/24        Self                         100        I
* 192.168.110.0/24        Self                         100        I
* 192.168.111.0/24        Self                         100        I
* 192.168.114.0/24        34.34.34.4                   100        I
* 192.168.115.0/24        34.34.34.4                   100        I

admin@MX> show route advertising-protocol bgp 12.12.12.1

RI2.inet.0: 69 destinations, 73 routes (69 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.2.1.0/24             Self                         100        I
* 10.2.2.0/24             Self                         100        I
* 10.2.3.0/24             Self                         100        I
* 10.2.4.0/24             Self                         100        I
* 12.12.12.0/24           Self                         100        I
* 23.23.23.0/24           Self                         100        I
* 172.17.100.0/24         Self                         100        I
* 172.17.101.0/24         Self                         100        I
* 172.17.102.0/24         Self                         100        I
* 172.17.103.0/24         Self                         100        I
* 192.168.104.0/24        Self                         100        I
* 192.168.105.0/24        Self                         100        I
* 192.168.106.0/24        Self                         100        I
* 192.168.107.0/24        Self                         100        I

admin@MX> show route advertising-protocol bgp 23.23.23.3

RI2.inet.0: 69 destinations, 87 routes (69 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.2.1.0/24             Self                         100        I
* 10.2.2.0/24             Self                         100        I
* 10.2.3.0/24             Self                         100        I
* 10.2.4.0/24             Self                         100        I
* 12.12.12.0/24           Self                         100        I
* 23.23.23.0/24           Self                         100        I
* 172.17.100.0/24         Self                         100        I
* 172.17.101.0/24         Self                         100        I
* 172.17.102.0/24         Self                         100        I
* 172.17.103.0/24         Self                         100        I
* 192.168.104.0/24        Self                         100        I
* 192.168.105.0/24        Self                         100        I
* 192.168.106.0/24        Self                         100        I
* 192.168.107.0/24        Self                         100        I

admin@MX> show route advertising-protocol bgp 34.34.34.4

RI3.inet.0: 55 destinations, 59 routes (55 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.2.1.0/24             23.23.23.2                   100        I
* 10.2.2.0/24             23.23.23.2                   100        I
* 10.2.3.0/24             23.23.23.2                   100        I
* 10.2.4.0/24             23.23.23.2                   100        I
* 10.3.1.0/24             Self                         100        I
* 10.3.2.0/24             Self                         100        I
* 10.3.3.0/24             Self                         100        I
* 10.3.4.0/24             Self                         100        I
* 12.12.12.0/24           23.23.23.2                   100        I
* 23.23.23.0/24           Self                         100        I
* 34.34.34.0/24           Self                         100        I
* 172.17.100.0/24         23.23.23.2                   100        I
* 172.17.101.0/24         23.23.23.2                   100        I
* 172.17.102.0/24         23.23.23.2                   100        I
* 172.17.103.0/24         23.23.23.2                   100        I
* 172.18.100.0/24         Self                         100        I
* 172.18.101.0/24         Self                         100        I
* 172.18.102.0/24         Self                         100        I
* 172.18.103.0/24         Self                         100        I
* 192.168.104.0/24        23.23.23.2                   100        I
* 192.168.105.0/24        23.23.23.2                   100        I
* 192.168.106.0/24        23.23.23.2                   100        I
* 192.168.107.0/24        23.23.23.2                   100        I
* 192.168.108.0/24        Self                         100        I
* 192.168.109.0/24        Self                         100        I
* 192.168.110.0/24        Self                         100        I
* 192.168.111.0/24        Self                         100        I

kudos!

yes,Alex,that  is what I want to say

RR will reflect prefix from client to non-client

from non-client to client only

Ok. This could as complex as you want.

thanks very much,Alex

I understand this now

besides this ,I learn a useful command from u : no-client-reflect

to disable reflect prefix to other ibgp,