3.7a Describe, Implement and Troubleshoot Peer Relationships
3.7a(i) Peer-group, template
Peer Group
- BGP peer groups reduce CPU utilization and simplify BGP syntax.
- The routing table is checked only once and the updates are replicated to all peer group members instead of doing it individually for each peer.
- You can group BGP neighbors that share the same outbound policies.
- The policies are applied to the group rather than individual peers.
- The outbound update policy must be identical between the peers but the inbound update policy can be customized for any member of a peer group.
Example:
router bgp 100
neighbor IBGP peer-group
neighbor IBGP remote-as 100
neighbor IBGP update-source Loopback0
neighbor 1.1.1.1 peer-group IBGP
neighbor 2.2.2.2 peer-group IBGP
neighbor 3.3.3.3 peer-group IBGP
Without the peer group the AS number and source interface would have been specified individually for each peer.
Template
- An optimization of BGP peer groups.
- Uses the concept of inheritance to apply policies.
- Two types of peer templates: peer session templates and peer policy templates.
- Peer session templates are used to group and apply general BGP session establishment configuration.
- Peer policy templates are used to group and apply NLRI advertisement policies.
- A peer template can directly or indirectly inherit the configuration from another peer template.
- A directly inherited template will overwrite any indirectly inherited statements that are duplicated in the directly inherited template.
- A BGP neighbor can directly inherit only one session template and indirectly inherit up to seven additional session templates.
Example (peer session template):
-- WITHOUT INHERITANCE --
router bgp 100
template peer-session IBGP
remote-as 100
update-source Loopback0
exit-peer-session
!
neighbor 1.1.1.1 inherit peer-session IBGP
neighbor 2.2.2.2 inherit peer-session IBGP
neighbor 3.3.3.3 inherit peer-session IBGP
-- WITH INHERITANCE --
router bgp 100
template IBGP
remote-as 100
inherit peer-session UPDATE-SOURCE
exit-peer-session
!
template UPDATE-SOURCE
update-source Loopback0
exit-peer-session
!
neighbor 1.1.1.1 inherit peer-session IBGP
neihgbor 2.2.2.2 inherit peer-session IBGP
neighbor 3.3.3.3 inherit peer-session IBGP
Example (peer policy template):
ip prefix-list DENY-PRIVATE-IP seq 10 deny 10.0.0.0/8
ip prefix-list DENY-PRIVATE-IP seq 20 deny 172.16.0.0/12
ip prefix-list DENY-PRIVATE-IP seq 30 deny 192.168.0.0/16
ip prefix-list DENY-PRIVATE-IP seq 40 permit 0.0.0.0/0 le 32
!
router bgp 100
template peer-policy IBGP-POLICY
inherit peer-policy FILTER-PRIVATE 10
inherit peer-policy NEXT-HOP-SELF 20
exit-peer-policy
!
template peer-policy FILTER-PRIVATE
prefix-list DENY-PRIVATE-IP out
exit-peer-policy
!
template peer-policy NEXT-HOP-SELF
next-hop-self
exit-peer-policy
!
neighbor 1.1.1.1 inherit peer-policy IBGP-POLICY
neighbor 2.2.2.2 inherit peer-policy IBGP-POLICY
neighbor 3.3.3.3 inherit peer-policy IBGP-POLICY
Inherited peer policy templates are configured with sequence numbers like route-maps.
3.7a(ii) Active, Passive
- BGP is essentially a standard TCP based protocol, which means that it is client and server based.
- Normally, the role of client and server are negotiated dynamically during BGP session establishment (lower BGP RID becomes the server).
- The neighbor x.x.x.x transport connection mode {active | passive} command can be used to manually set the client (active) and server (passive) roles.
Example:
R1#
router bgp 100
neighbor 150.1.2.2 remote-as 100
neighbor 150.1.2.2 update-source Loopback0
R2#
router bgp 100
neighbor 150.1.1.1 remote-as 100
neighbor 150.1.1.1 update-source Loopback0
By default, R1 becomes the server (TCP port 179) because of the lower BGP RID 150.1.1.1.
R1#show ip bgp neighbors | inc BGP neighbor|Local host|Foreign host
BGP neighbor is 150.1.2.2, remote AS 100, internal link
Local host: 150.1.1.1, Local port: 179
Foreign host: 150.1.2.2, Foreign port: 46662
Let's explicitly specify R1 as the client (active).
R1#
router bgp 100
neighbor 150.1.2.2 transport connection-mode active
As expected, R1 now operates as the client.
R1#show ip bgp neighbors | inc BGP neighbor|Local host|Foreign host
BGP neighbor is 150.1.2.2, remote AS 100, internal link
Local host: 150.1.1.1, Local port: 64038
Foreign host: 150.1.2.2, Foreign port: 179
3.7a(iii) States, timers
States
Idle: BGP is initializing its resources (refuses incoming BGP session requests).
- Verify that the peers have correct IP address and AS number configuration (BGP does not accept connections from unknown BGP peers).
- Make sure that the routers can reach each other using the configured IP addresses and TCP port 179.
Connect: BGP is waiting for the transport protocol connection to be completed. If successful, the state transitions to OpenSent (the OPEN message is sent). If unsuccessful, the state transitions to Active. If BGP peers get stuck in the Connect state, it is usually because of a configuration error.
- Check inbound and outbound TCP connectivity on port 179 (and random TCP port greater than1023).
- Verify IP addresses and AS numbers.
Active: BGP is unable to establish a successful TCP connection with its neighbor. A neighbor state that is oscillating between Connect and Active typically indicates a problem with the TCP transport connection.
OpenSent: The BGP peer waits for an OPEN message from its peer. After an OPEN message has been received, it is checked for validity. At this time, all fields in the OPEN message are checked against the local BGP configuration. In case of errors, an error NOTIFICATION is sent and the state goes back to Idle. If no errors, BGP starts sending KEEPALIVE messages.
OpenConfirm: The local router is waiting for the receipt of a KEEPALIVE message from its peer. Upon receipt of a KEEPALIVE message, the BGP session transitions to the Established state.
Established: BGP peers reach the Established state after they have successfully exchanged OPEN and KEEPALIVE messages. After the peers reach the Established state, they begin to send UPDATE messages containing routing information and KEEPALIVE messages to verify the TCP Connection state. If an error is encountered at any time while a peer is in the Established state, the local peer sends a NOTIFICATION message with the reason for the error and transitions back to the Idle state.
BGP Timers
KEEPALIVE: BGP session "refresh" timer that signals the router's presence to its BGP peers. 60 seconds by default.
HOLD-TIME: BGP session "validity" timer that tells the router how long to wait for a KEEPALIVE (or UPDATE) message from its peer. 180 seconds (3x KEEPALIVE) by default. If the HOLDDOWN timer expires, the neighbor is declared dead and the routes from this neighbor are flushed.
For all neighbors.
router bgp 100
timers bgp 60 180
Per neighbor.
router bgp 100
neighbor 1.1.1.1 timers 60 180
The timer values are exchanged during the BGP peer establishment and negotiated to the lower values.
ADVERTISEMENT TIMER: A minimum delay between updates sent to a neighbor. Introduced to maintain a stable routing table. By default, 30 seconds for eBGP peers and 0 seconds for iBGP peers.
router bgp 100
neighbor 6.6.6.6 advertisement-interval 30
SCAN TIMER: Designed to go over the BGP prefix-tables every 60 seconds (default) and validate if an IGP route to the next-hop is reachable.
router bgp 100
bgp scan-time 60
NEXT-HOP TRACKING (NHT): An event-driven system to provide faster convergence (optimization over the BGP scan timer). NHT monitors the RIB for next-hop related changes for both iBGP and eBGP prefixes and reports such events to the BGP process.
The delay interval between full routing table walks should match the tuning parameters for the IGP. The default delay interval is 5 seconds, which is an optimal value for a fast-tuned IGP. Aggressively dampening unstable IGP peering sessions is recommended to mitigate possible impact to BGP.
router bgp 100
bgp nexthop trigger enable
bgp nexthop trigger delay 5
UPDATE-DELAY: The maximum initial delay before a BGP speaker sends its first update. 120 seconds by default.
router bgp 100
bgp update-delay 120
AGGREGATE-TIMER: Controls how often routes will be aggregated. Even if using aggregate-address … summary-only, more specific routes will be advertised and later withdrawn when the timer kicks in.
The range is from 6 to 60 or else 0. The default is 30. A value of 0 disables timer-based aggregation and starts aggregation immediately.
router bgp 100
bgp aggregate-timer 30
3.7a(iv) Dynamic Neighbors
The BGP dynamic neighbor feature allows BGP peering to a group of remote neighbors that are defined by a range of IP addresses (each range is a subnet) instead of individually configuring each neighbor.
Example: The BGP dynamic neighbor feature is extremely useful in a hub-and-spoke topology. On the hub, BGP dynamic neighbors allows BGP peering based on the peer group without having to use any individual neighbor statements to specify who those neighbors actually are. The neighbors are learned dynamically. Normal BGP configuration (static neighbor statements) is required on the spokes. Still, the overeall BGP configuration is simplified drastically. BGP dynamic neighbors are an efficient way to support hundreds or even thousands of BGP sessions with minimal configuration.
router bgp 100
neighbor HUB-AND-SPOKE peer-group
neighbor HUB-AND-SPOKE remote-as 100
bgp listen range 192.168.0.0/16 peer-group HUB-AND-SPOKE
bgp listen limit 200
Optional Commands:
- bgp listen limit <max-num> sets a limit (maximum number) of BGP dynamic neighbors.
- neighbor HUB-AND-SPOKE remote-as 100 alternate-as <as-num1> ... <as-num5> identifies up to five alternate AS numbers for listen range neighbors.
Router# show ip bgp summary
BGP router identifier 192.168.3.1, local AS number 100
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
*192.168.3.3 4 100 3 3 1 0 0 00:00:37 0
*192.168.3.2 4 100 6 6 1 0 0 00:04:36 0
* Dynamically created based on a listen range command
Dynamically created neighbors: 2/(200 max), Subnet ranges: 1
BGP peergroup HUB-AND-SPOKE listen range group members:
192.168.0.0/16
No comments:
Post a Comment