We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is Why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • [geot exclude_region="No Trial" ] Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career![/geot]
  • Full Access to our 541 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

 

288 New Members signed up the last 30 days!

 
satisfaction-guaranteed

100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!


Notable Replies

  1. Great explanation. Peer groups saves a lot of time and headache. Thanks

    Ammar,
    CCIE R&S - in progress

  2. Hi Rene,

    I think that in configuration there is missing a static route to each of the peer's loopback addresses.

    George

  3. Hi George,

    That's right, this example only shows a "before" and "after" of using peer groups. You will need static routes to reach the loopback addresses of the remote peers.

    Rene

  4. Hi Aswin,

    The functionality remains the same but behind the scenes, something is different. Imagine you have 100 BGP neighbors...they all have the same configuration. Without peer groups, the router will have to generate an update for each neighbor, one-by-one.

    With peer groups, the update is generated only once for the peer group. For each neighbor, we only have to replicate the update..that's it. That saves some CPU cycles on the router.

    I have to say that most routers also support BGP Dynamic Update Peer-Groups. This means that routers will automatically try to replicate packets "behind the scenes" for each neighbor, even when you are not using peer groups. Peer groups are still useful since they simplify your configuration.

    Rene

  5. Hi,

    I have a problem in R1 he doesn't create any neighbor relationship:

    These are the logs:

    *Jul  9 17:58:35.187: BGP: ses global 3.3.3.3 (0x655EF9CC:0) act Reset (Active open failed).
    *Jul  9 17:58:35.199: BGP: 3.3.3.3 active went from Active to Idle
    *Jul  9 17:58:35.199: BGP: nbr global 3.3.3.3 Active open failed - open timer running
    *Jul  9 17:58:35.203: BGP: nbr global 3.3.3.3 Active open failed - open timer running

    Example for R3 but it's the same for R2 and R4:

    router bgp 1
     bgp log-neighbor-changes
     neighbor R2_R3_R4 peer-group
     neighbor R2_R3_R4 ebgp-multihop 2
     neighbor R2_R3_R4 update-source Loopback0
     neighbor 2.2.2.2 remote-as 2
     neighbor 2.2.2.2 peer-group R2_R3_R4
     neighbor 3.3.3.3 remote-as 3
     neighbor 3.3.3.3 peer-group R2_R3_R4
     neighbor 4.4.4.4 remote-as 4
     neighbor 4.4.4.4 peer-group R2_R3_R4

Continue the discussion forum.networklessons.com

2 more replies

Participants