We know that we can aggregate/summarise multiple network statements that are sequential/contigious into a single advertisement. This is how it is done using BGP..
Within the BGP AS/process, we will inject the aggregated route using the ‘aggregate-address’ command:
router bgp 100
aggregate-address 22.214.171.124 252.0.0.0.0
The router sees the aggregate and places it into its BGP table. Note that by default, the more-specific routes are not removed from the BGP table. With our IGP protocols, the specific networks disappeared from the routing table, NOT with BGP.
To suppress the advertisement of the more-specific routes, use the summary-only option with the aggregate-address command. (on the end of the command)
To further extend this command… If you also use the as-set option, the path advertised for this route will be an AS_PATH that was traveled by all of the more-specific paths being aggregated. Cisco recommends that you do not use this option when a great number of paths are being aggregated, since the aggregate may be removed, updated, and replaced as AS-path reachability changes.
Why aggregate routes in the first place? For the same reason we did so with other protocols – route aggregation lessens the load on router resources by making the routing tables smaller while still being complete and accurate.
Resetting and Clearing The BGP Peer Connections
Sometimes you’ll find it necessary to reset the TCP session between BGP speakers. Not all changes require this. For example, the route aggregation we just performed required no such reset. There is a “hard reset” and a “soft reset”. The clear ip bgp* command performs a hard reset where the TCP session itself is reset:
R1#clear ip bgp *
09:18:36: %BGP-5-ADJCHANGE: neighbor 10.1.1.5 Down User reset
09:18:36: %BGP-5-ADJCHANGE: neighbor 126.96.36.199 Down User reset
09:18:36: %BGP-5-ADJCHANGE: neighbor 188.8.131.52 Down User reset
With this command, the BGP sessions themselves are reset and the neighbor adjacencies are lost. The adjacencies you see here came back within 20 – 40 seconds, but BGP reachability was lost during that time.
To clear the sessions without resetting the sessions, use the soft option, as shown here;
R1#clear ip bgp * soft
Internal BGP: Synchronization, Full Meshes, and Route Reflectors
Rules and Guidelines when working with iBGP:
- iBGP neighbors do not have to be directly connected. The connection between iBGP routers is on TCP port 179.
- It’s common practice to use a remote router’s loopback address in the neighbor statement, rather than the closest physical address. This allows us to keep our BGP adjacencies in situations where losing the physical address would result in losing that adjacency.
- iBGP routers do not send updates to every single neighbor. The only way an iBGP router will advertise a route to its neighbors is if the route was created by the transmitting router via the network command, by static route redistribution, IGP route redistribution, or if the advertised route is a connected route in the first place. (KEY POINT!!!)
*This means that when a iBGP speaker learns about a route from an iBGP peer, the only kind of BGP router that route can then be advertised to is an eBGP router. iBGP routers do not advertise routes received from one iBGP neighbor to other iBGP neighbors.
The only way round this is to have a full mesh in each AS, which is not realistic on the internet! BGP has a solution to this dilemma.
The BGP Rule Of Synchronisation
The BGP rule of synchronization only matters when an AS is going to serve as a transit area, and if there are non-BGP speakers in the transit area.
The BGP Rule Of Synchronization states that a transit AS will not advertise a route until every router in the transit AS has the route in its IGP routing table.
BGP Synchronization’s major benefit is that packets that can’t possibly reach the desired remote network will not even be sent, reducing both the amount of unnecessary traffic and the unnecessary strain on router resources.
BGP Synchronization is turned off in many deployments, though, and as of IOS version 12.2(8) it’s turned off by default. There are three scenarios under which it’s safe to turn synchronization off:
1. If all the routers in the AS are running BGP.
2. If a full mesh exists in the AS.
3. If the AS is not a transit AS to begin with.
To do so, simply run the BGP command no synchronization.
R1(config)#router bgp 100
The Problem With BGP Full Mesh Deployments
BGP Split Horizon is much different that what we are used to with routing in the CCNA.
BGP Split Horizon states that one iBGP peer can’t learn about a path from one iBGP peer and then advertise it to another iBGP peer.
Therefore, we would need a logical full mesh among all iBGP speakers in an autonomous system.
Reasons against a Full Mesh with BGP:
- Any full-mesh deployment of BGP is going to have a large cost on the router’s resources (memory, CPU).
- A full mesh is going to require a large number of TCP connections, and the more routers you have, the more connections you’ll need.
- A full mesh setup will use a lot of bandwidth.
- Time consuming to setup and admin overhead is a nightmare.