Task 5.1 BGP

What in this task tells us to use RR feature? Is it just to save in on peerings or does it have an actual function in this task?

Comments


  • I believe it is for full propogation of prefixes

    R4:

    Restriction: Do not enable iBGP peering between R3 and R6

    R4 will propagate AS200 learned prefixes to R3 and R6

    R3 is a RR client of R4 so R4 can reflect routes learned from BB1 via R6

    R6 is a RR client of R4 so R4 can reflect routes learned from BB3 via R3

    R1:

    Restriction: Do not enable BGP on SW1 or SW4 but ensure that they can reach all BGP routes by using the default route advertised via OSPF by R1.

    I would surmise then that all BGP prefixes have to be on R1, so it would be an ideal candidate to be a RR.  So all devices would ideally peer with R1 accept for SW1 and SW4 whom should not run BGP.

    R5 is a RR client of R1 so R1 can reflect routes learned from BB2 via SW2 and R2 routes.

    R2 is a RR client of R1 so R1 can reflect routes learned from BB2 via SW2 and R5 routes.

    Just my guess from first glance.

    HTH

  • Thanks Dennis,

    I read through the instructions too sloppy, got tired at end of session. It is clear to me now why R4 must be a RR. It also makes sense to make R1 a RR even though we could also have configured a full mesh.

  • Yes, the R1 scenario seems to be open to interpretation.  Full Mesh seems to be viable alternative.  I am studying BGP/MPLS test for CCIP, so BGP is fresh in my mind.

  • I read through the instructions too sloppy, got tired at end of session. It is clear to me now why R4 must be a RR. It also makes sense to make R1 a RR even though we could also have configured a full mesh.

    Thats true, full mesh is also an option for this task but to same good time, configuring RR is a better option.

Sign In or Register to comment.