Slide 35 of 41
Notes:
- Peer groups are both a configuration shorthand, AND a performance optimization.
- Typically, you will have many IBGP neighbors with exactly the same configuration, except for the peering address. What you can do is define a peer-group, in much the same way as you define a neighbor. You then add the normal BGP configuration commands to that peer-group. Finally, you apply that peer-group to one or more neighbors.
- On this slide I’ve defined a peer-group called internal. I’ve configured a number of BGP features for the BGP peer group: a text “description” of the group; the remote-as (same as local AS as this is IBGP); set the update-source to be the loopback so my peering will survive individual link failures; configured the sending of communities; locked down the BGP version to version 4.; and applied a password.
- Locking the BGP version to version 4 prevents the unpleasant consequences of someone (the new engineer!) mistakenly configuring version 3 on one of the peers. BGP version 3 is not a classless protocol, so the consequences of bringing up a session with version 3 can be quite unpleasant!
- Passwords are often overlooked as a way to prevent mistakes. You can apply a password, which causes TCP to use an MD5 authentication on the session. If someone is new, don’t give them the password until they know what they are doing :-)
