BGP: BGP and your ISP


The first term is multihoming. This is a BGP configuration where multiple connections to the internet exist. This allows for load balancing as well as redundancy – you don’t want to have internet connectivity cut off if one path goes down. Single points of failure are never good, but can be positively crippling with BGP.

From the ISP’s point of view, there are three ways to handle sending routes to the BGP AS:

  • Send default routes only into the AS. (Low resource usage – uses the least memory of these three options.)
  • Send default routes and selected more-specific routes into the AS.
  • Send all routes into the AS. (High resource usage – uses the most memory of these three options.)

If the ISP sends only default routes into the AS, the non-BGP speakers in the AS will naturally use the path with the best metric to reach external destinations. With the other two choices, BGP will generally use the AS_PATH value to decide how routers in the AS should reach external destinations. The ISP has to walk a line between having more-specific routing tables and overtaxing router resources.


If memory and CPU are a concern, you should consider receiving only a default route from the ISPs. Receiving only default routes causes the least stress on your router resources.

You can opt for a combination of default and more-specific routes, but in the real world, you’ve usually got a router that can handle the load of specific routes or a router that can only handle default routes.

IGP < > BGP Redistribution

Don’t ever do this unless you know what your doing! At times, it may be necessary for you to place IGP routes into the BGP routing table. There are three ways to do this:

  1. the network command
  2. redistribution of static routes
  3. redistribution of dynamically learned IGP routes

*The network command is generally your best bet.

Private AS Numbers

BGP allows you quite a bit of range when it comes to selecting an AS number:

R1(config)#router bgp ?
<1-65535> Autonomous system number

Just as there are private IP addresses, there are private AS numbers. The AS numbers 64512 – 65535 are considered “private” AS numbers and just as private IP addresses should not be advertised to external networks, neither should private AS numbers. Public or private, you can’t assign AS number zero with BGP, just as you couldn’t with EIGRP.

BGP: Prefix Lists

Prefix Lists

Prefix Lists are used to fine tune BGP and decide what routes are to be advertised or NOT advertised. They are also extremely fast, efficient and easier to use than ACLs, although they follow almost the same logic. They also use sequence numbers, so making changes to certain lines is nice and easy.

When we take our classic BGP topology:


We know that by default R2 and R3 will not receive the loopback on R4, this is because of BGPs Split Horizon rule… yadda yadda… We need a full mesh or our good friend next hop self.

We can get round this simply by using the next hop self command on R4.. yadda yadda been here before several times! Starting to sink in!

How about if R4 has the following networks on top of the loopback:

…and we want to use a prefix list to stop both R2 and R3 from receiving these routes, but to still receive the route to

We need to configure a prefix list on R1

Prefix List Operation

  • First, if a route is expressly permitted, it’s used; if it’s denied, it’s not used.
  • Implicit Deny is still applicable at the bottom of the prefix list
  • Explicit Deny doesnt override the Implicit Deny – MAKE NOTE!

Configuration for Prefix List

1. Create Prefix List

R1(config)#ip prefix-list NO_172_16_1_TO_3 deny
R1(config)#ip prefix-list NO_172_16_1_TO_3 deny
R1(config)#ip prefix-list NO_172_16_1_TO_3 deny
R1(config)#ip prefix-list NO_172_16_1_TO_3 permit le 32 (PERMIT EVERYTHING ELSE WITH A MASK LOWER THAN 32 BITS)

2. Apply Prefix List to neighbor statements (To R2 and R3)

R1(config)#router bgp 100
R1(config-router)#neighbor R2 IP ADDRESS prefix-list NO_172_16_1_TO_3 out
R1(config-router)#neighbor R3 IP ADDRESS prefix-list NO_172_16_1_TO_3 out

Verification Commands (Example from Chris Bryant Study Guide)

R1#show ip prefix-list
ip prefix-list NO16THROUGH19: 5 entries
seq 5 deny
seq 10 deny
seq 15 deny
seq 20 deny
seq 25 permit le 32

Example of editing a prefix list

R1(config)#ip prefix-list NO16THROUGH19 ?
deny Specify packets to reject
description Prefix-list specific descriptin
permit Specify packets to forward
seq sequence number of an entry
R1(config)#ip prefix-list NO16THROUGH19 seq 2 permit

BGP: More Route Reflectors!

When we encounter a situation whereby an eBGP peer exists and the iGP peers within the single AS are not able to advertise networks to neighbours, we can get round this in a few different ways. (This is defined by BGP split horizon)

1. Use dynamic or static routing to get a route to the eBGP router in the relevant iBGP routers IP routing table, or configure next-hop-self on the router performing the eBGP peer.

Configuration recap for next hop self:

R3(config)#router bgp 1235
R3(config-router)#neighbor next-hop-self
R3#clear ip bgp * soft

The result is a next-hop address that the iBGP router can reach, so the BGP route is now valid and best.

2. Setup a full mesh in the AS. Not a good idea… see previous post

3. Configure a Route Reflector – In a hub and spoke style topology, the successful candidate to become the route reflector is the hub router. The spoke routers will be known as route reflector clients and will require NO configuration. The configuration for the RR is performed on the hub router:

R1(config)#router bgp 1235
R1(config-router)#neighbor route-reflector-client
00:34:00: %BGP-5-ADJCHANGE: neighbor Down RR client config change
R1(config-router)#neighbor route-reflector-client
00:34:12: %BGP-5-ADJCHANGE: neighbor Down RR client config change
00:34:27: %BGP-5-ADJCHANGE: neighbor Up
00:34:38: %BGP-5-ADJCHANGE: neighbor Up

Configuring a BGP peer as a route reflector client will bring down the peer connection. As you can see from the timestamps, they were only down for 25 to 30 seconds, but it’s an important point to remember. Especially on production networks…

Route reflectors serve two major purposes:

  1. They reduce the number of TCP connections needed in an iBGP deployment.
  2. Just as importantly, route reflectors allow us to get around the rule of BGP Split Horizon – because unlike other protocols you studied in the CCNA, you can’t turn BGP Split Horizon off at the interface level.

To verify that a router is seen as a route reflector client, run show ip bgp neighbor x.x.x.x. This is an excellent command for overall BGP troubleshooting.

Clusters And The Originator-ID Attribute

BGP Clusters are a combination of route reflectors and clients that are sharing information. There can be more than one route reflector in a cluster. When deciding on the routers that will be the route reflectors in a cluster, you should consider both the peering relationships in place (and the ones that would need to be added to make the route reflector work) and the impact on router resources that being an RR creates.

Make sure the routers that will serve as the route reflectors in your network possess the resources to get the job done.

If BGP Split Horizon is intended to stop routing loops, why is Split Horizon not an issue with clusters? Because the Originator-ID identifies the router that originated the path. This attribute is set by the route reflector and effectively eliminates the chance of a routing loop. If the router that originated the route receives the route in an update, the update will be discarded.

Where Do Route Reflectors Send Routes?

Route reflectors have three possible types of peers – clients, non-clients, and eBGP peers. How a route reflector handles the update depends on the device that sent the update:

  1. Updates from RR clients are sent to all client and non-client peers.
  2. Updates from eBGP peers are sent to all client and non-client peers.
  3. Updates from nonclient peers are sent to all clients in the cluster.




BGP: Route Reflectors

Route Reflectors

BGP route reflectors are the exception to the BGP Split Horizon rule. A router configured as a BGP route reflector can take a route learned from one iBGP peer and advertise it to another iBGP peer. The iBGP peers that will be sending routes to the route reflector are referred to as clients. When one client sends a route to the route reflector, the RR does just that – it reflects the route to the other clients.

To the clients, this is a totally transparent process. The clients don’t even know they are clients, and they require no additional configuration.

All clients must peer with the RR. Clients will not have a peer relationship with other clients. This allows us to have BGP work with a partial mesh rather than a full mesh.

Rather than implementing and configuring a full mesh, we can use a hub and spoke topology with our hub acting as the RR and the spokes as clients. This will be a massive reduction in overall BGP TCP connections.

A BGP speaker that has a peer relationship to an RR does not have to be a client; these speakers are called nonclients. Non-clients do have to have a TCP connection to every other router in the AS.

Route Reflectors lab and configuration to follow…

BGP: Route Aggregation Options and BGP Synchronization


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

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 Down User reset
09:18:36: %BGP-5-ADJCHANGE: neighbor Down User reset
09:18:36: %BGP-5-ADJCHANGE: neighbor 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
R1(config-router)#no synchronization

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.

BGP: Changing the Weight & Intro to Route Aggregation


If you’re in an all- Cisco environment, it makes sense to change the weight of a route to make it the preferred route, since that is the first criteria checked.

The default weight is 0, so we’ll use the neighbor command to set the weight for all routes learned for a specific network with a custom weight value.

Since the weight attribute is Cisco proprietary, so in a multi-vendor environment we’d change the local pref to get a similar result.

*This change to a route’s weight is locally significant only

Route Aggregation

The Atomic Aggregate Attribute

When BGP paths are aggregated, this well-known attribute indicates the router that performed the aggregation. This attribute gives notice to downstream routers that more-specific BGP routing information was lost at the point of aggregation. Aggregation = Summarization

The Aggregator Attribute

This optional attribute gives the BGP Router ID and AS number of the router that performed the aggregation. The aggregator attribute will also include a list of all the AS numbers that these aggregated routes passed through.

BGP: Third Party Next Hop

This is extremely rare, however worth mentioning. If we have an iBGP setup between routers R1 and R2 (AS100) and an eBGP peer between R1 and R3 (AS200) WHEN ALL CONNECTED ON THE SAME SUBNET!!! A BGP speaker is allowed to advertise the IP address of an internal peer as the next-hop address IF the external peer receiving the route has a subnet in common with the internal peer.

So if R1 is the hub and R2 and R3 the spokes, R1 will have a next hop ip address of R3 to reach R3s loopback interface, not a next hop of R2. This is because R1 and R3 share the same subnet.

I presume this is rare as most eBGP peers like this are not done on a shared broadcast segment. This built-in feature is designed to bring about the most accurate routing possible which is correct in this rare scenario.