In this post, I am going to cover a set of BGP configuration scenarios that will provide you with a good understanding of how to configure Border Gateway Protocol on Cisco routers.
If you have a good understanding of BGP, BGP configuration is not at all difficult; however, it can get complicated when applying complex policies. This section will take you step-by-step through the configuration of iBGP and eBGP peerings from basic to more complex setups.
A BGP session between two routers is configured in two basic steps:
- Establish the BGP process and specify the local AS the router belongs to with the router bgp command.
- Declare a neighbor and its AS number with the neighbor remote-as command.
Advertisement
eBGP Peering (external BGP)
eBGP stands for external BGP. An eBGP peering occurs when both BGP peers are in different autonomous systems.
In the diagram above, R1 belongs to AS 65001 and R2 to AS 65002.
Here’s R1’s eBGP configuration.
R1# R1#config term Enter configuration commands, one per line. End with CNTL/Z. R1(config)# R1(config)#router bgp 65001 R1(config-router)#neighbor 10.1.0.2 remote-as 65002 R1(config-router)#end R1#
Here’s R2’s eBGP configuration.
R2# R2#config term Enter configuration commands, one per line. End with CNTL/Z. R2(config)#router bgp 65002 R2(config-router)#neighbor 10.1.0.1 remote-as 65001 R2(config-router)#end R2#
After you configure R2, you should see a message on each router’s screen saying that the BGP neighbor came up.
R1# *Sep 21 11:35:58.691: %BGP-5-ADJCHANGE: neighbor 10.1.0.2 Up R1# R2# *Sep 21 11:35:59.051: %BGP-5-ADJCHANGE: neighbor 10.1.0.1 Up R2#
On R1, verify the BGP neighbor status with the show ip bgp summary command and notice the remote AS number is 65002 as opposed to the local AS number of 65001.
R1#show ip bgp summary BGP router identifier 10.1.0.1, local AS number 65001 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.1.0.2 4 65002 16 17 1 0 0 00:11:51 0 R1#
On R2, also verify the BGP neighbor status with the same show ip bgp summary command. Make sure the remote AS is 65001.
R2#show ip bgp summary BGP router identifier 10.1.0.2, local AS number 65002 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.1.0.1 4 65001 17 17 1 0 0 00:12:14 0 R2#
Notice that on the very right, there aren’t prefixes sent to one another because you’re not advertising any networks. If you were to advertise networks, you’d see that field change from 0 to the number of prefixes exchanged.
Advertisement
iBGP Peering (internal BGP)
iBGP stands for internal BGP. An iBGP peering occurs when both BGP peers belong to the same autonomous system.
In the diagram above, both R1 and R2 belong to AS 65000.
Here’s R1’s iBGP configuration.
R1# R1#config term Enter configuration commands, one per line. End with CNTL/Z. R1(config)# R1(config)#router bgp 65000 R1(config-router)#neighbor 10.1.0.2 remote-as 65000 R1(config-router)#end R1#
Here’s R2’s iBGP configuration.
R2# R2#config term Enter configuration commands, one per line. End with CNTL/Z. R2(config)#router bgp 65000 R2(config-router)#neighbor 10.1.0.1 remote-as 65000 R2(config-router)#end R2#
After you configure R2, you should see a message on each router’s screen saying that the BGP neighbor came up.
R1# *Sep 21 12:05:26.996: %BGP-5-ADJCHANGE: neighbor 10.1.0.2 Up R1# R2# *Sep 21 12:05:27.448: %BGP-5-ADJCHANGE: neighbor 10.1.0.1 Up R2#
On R1, verify the BGP neighbor status with the show ip bgp summary command and notice the remote AS number of 65000 is the same as R1’s local AS number.
R1#show ip bgp summary BGP router identifier 10.1.0.1, local AS number 65000 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.1.0.2 4 65000 39 38 1 0 0 00:31:51 0 R1#
On R2, also verify the BGP neighbor status with the same show ip bgp summary command. Make sure the remote AS number is the same as R2’s local AS.
R2#show ip bgp summary BGP router identifier 10.1.0.2, local AS number 65000 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.1.0.1 4 65000 38 39 1 0 0 00:32:14 0 R2#
Likewise, notice that on the very right, there aren’t prefixes sent to one another because you’re not advertising any networks. If you were to advertise networks, you would see that field change from 0 to the number of prefixes exchanged.
Advertisement
BGP Authentication
BGP supports MD5 neighbor authentication. MD5 sends a message digest (also called a hash) that is created using the key and a message. The message digest is then sent instead of the key. The key itself is not sent to prevent it from being intercepted by an eavesdropper.
BGP neighbor authentication is configured on a router so that the router authenticates the source of each routing update packet it receives from its peers. This authentication is accomplished by configuring a shared authentication key (sometimes referred to as a password) on both BGP peers.
The sending router uses portions of the IP and TCP headers, TCP payload (including the BGP route advertisements), and the pre-configured shared secret to generate the MD5 hash. The MD5 hash is then stored in TCP option 19, which is defined specifically for this purpose. The receiving BGP neighbor uses the same algorithm and shared secret to compute its own version of the MD5 hash. It then compares its own version with the version that it received. If the MD5 hash values are not identical, the receiving BGP neighbor discards the packet. If the MD5 hash values are the same, the packet is accepted and processed by BGP.
Let’s add authentication to our internal BGP scenario with the password command under the BGP process.
R1# R1#config term Enter configuration commands, one per line. End with CNTL/Z. R1(config)#router bgp 65000 R1(config-router)#neighbor 10.1.0.2 password G00Dluck R1(config-router)#end R1# R2# R2#config term Enter configuration commands, one per line. End with CNTL/Z. R2(config)#router bgp 65000 R2(config-router)#neighbor 10.1.0.1 password G00Dluck R2(config-router)#end R2#
Since authentication is negotiated during the BGP session establishment, you need to clear the BGP session. If the session comes up, you’re good!
R1#clear ip bgp * R1# *Sep 21 13:08:32.247: %BGP-3-NOTIFICATION_MANY: sent to 1 sessions 6/4 (Administrative Reset) for all peers R1# *Sep 21 13:08:32.303: %BGP-5-ADJCHANGE: neighbor 10.1.0.2 Down User reset *Sep 21 13:08:32.305: %BGP_SESSION-5-ADJCHANGE: neighbor 10.1.0.2 IPv4 Unicast topology base removed from session User reset R1# *Sep 21 13:08:41.038: %BGP-5-ADJCHANGE: neighbor 10.1.0.2 Up R1#
Here’s a summary of the final configuration on both R1 and R2.
R1#show running | section router bgp router bgp 65000 bgp log-neighbor-changes neighbor 10.1.0.2 remote-as 65000 neighbor 10.1.0.2 password G00Dluck R1# R2#show running | section router bgp router bgp 65000 bgp log-neighbor-changes neighbor 10.1.0.1 remote-as 65000 neighbor 10.1.0.1 password G00Dluck R2#
Advertisement
BGP Neighbor Description
Adding a description to each peer helps to keep your configuration organized.
R1#config term Enter configuration commands, one per line. End with CNTL/Z. R1(config)#router bgp 65000 R1(config-router)#neighbor 10.1.0.2 description iBGP TO R2 R1(config-router)#end R1# R2#config term Enter configuration commands, one per line. End with CNTL/Z. R2(config)#router bgp 65000 R2(config-router)#neighbor 10.1.0.1 description iBGP TO R1 R2(config-router)#end R2#
Now you can check the running configuration on each router.
R1#show runn | sec router bgp router bgp 65000 bgp log-neighbor-changes neighbor 10.1.0.2 remote-as 65000 neighbor 10.1.0.2 description iBGP TO R2 neighbor 10.1.0.2 password G00Dluck R1# R2#show runn | sec router bgp router bgp 65000 bgp log-neighbor-changes neighbor 10.1.0.1 remote-as 65000 neighbor 10.1.0.1 description iBGP TO R1 neighbor 10.1.0.1 password G00Dluck R2#
When you see the running configuration of the router configuration’s BGP section, it will be easier to spot the neighbor you want to look at.
Advertisement
BGP Timers
Because BGP does not use periodic routing updates, BGP peers must exchange keepalive messages to maintain the BGP connection. The Cisco IOS default keepalive interval is 60 seconds. If three intervals (180 seconds) pass without a peer receiving a keepalive message, the peer declares its neighbor down. You can change these intervals globally or per peer.
Notice the default Cisco IOS timers on R1 and R2.
R1#show ip bgp neighbors
BGP neighbor is 10.1.0.2, remote AS 65000, internal link
Description: iBGP TO R2
BGP version 4, remote router ID 10.1.0.2
BGP state = Established, up for 00:13:24
Last read 00:00:41, last write 00:00:34, hold time is 180, keepalive interval is 60 seconds
Neighbor sessions:
1 active, is not multisession capable (disabled)
Neighbor capabilities:
Route refresh: advertised and received(new)
Four-octets ASN Capability: advertised and received
Address family IPv4 Unicast: advertised and received
Enhanced Refresh Capability: advertised and received
Multisession Capability:
Stateful switchover support enabled: NO for session 1
<truncated>
R2#show ip bgp neighbors
BGP neighbor is 10.1.0.1, remote AS 65000, internal link
Description: iBGP TO R1
BGP version 4, remote router ID 10.1.0.1
BGP state = Established, up for 00:14:12
Last read 00:00:27, last write 00:00:39, hold time is 180, keepalive interval is 60 seconds
Neighbor sessions:
1 active, is not multisession capable (disabled)
Neighbor capabilities:
Route refresh: advertised and received(new)
Four-octets ASN Capability: advertised and received
Address family IPv4 Unicast: advertised and received
Enhanced Refresh Capability: advertised and received
Multisession Capability:
Stateful switchover support enabled: NO for session 1
<truncated>
Here’s an example CLI configuration to change BGP timers globally and that will affect all the BGP speakers. To renegotiate the new BGP timers, you need to clear the BGP session. I’m changing the timers on R1 only. When I clear the BGP session on R1, R1 and R2 will renegotiate BGP parameters and they will agree on the smaller timers.
R1#config term Enter configuration commands, one per line. End with CNTL/Z. R1(config)#router bgp 65000 R1(config-router)#timers bgp 15 45 R1(config-router)#end R1# R1#clear ip bgp 10.1.0.2 R1# *Sep 22 13:15:08.825: %BGP-3-NOTIFICATION: sent to neighbor 10.1.0.2 6/4 (Administrative Reset) 0 bytes R1# *Sep 22 13:15:08.856: %BGP-5-ADJCHANGE: neighbor 10.1.0.2 Down User reset *Sep 22 13:15:08.858: %BGP_SESSION-5-ADJCHANGE: neighbor 10.1.0.2 IPv4 Unicast topology base removed from session User reset *Sep 22 13:15:09.303: %BGP-5-ADJCHANGE: neighbor 10.1.0.2 Up R1#
Let’s verify the new timers on R1 and R2.
R1#show ip bgp neighbors
BGP neighbor is 10.1.0.2, remote AS 65000, internal link
Description: iBGP TO R2
BGP version 4, remote router ID 10.1.0.2
BGP state = Established, up for 00:00:42
Last read 00:00:12, last write 00:00:02, hold time is 45, keepalive interval is 15 seconds
Configured hold time is 45, keepalive interval is 15 seconds
Minimum holdtime from neighbor is 0 seconds
Neighbor sessions:
1 active, is not multisession capable (disabled)
Neighbor capabilities:
Route refresh: advertised and received(new)
Four-octets ASN Capability: advertised and received
Address family IPv4 Unicast: advertised and received
Enhanced Refresh Capability: advertised and received
Multisession Capability:
Stateful switchover support enabled: NO for session 1
<truncated>
R2#show ip bgp neighbors
BGP neighbor is 10.1.0.1, remote AS 65000, internal link
Description: iBGP TO R1
BGP version 4, remote router ID 10.1.0.1
BGP state = Established, up for 00:01:18
Last read 00:00:11, last write 00:00:07, hold time is 45, keepalive interval is 15 seconds
Neighbor sessions:
1 active, is not multisession capable (disabled)
Neighbor capabilities:
Route refresh: advertised and received(new)
Four-octets ASN Capability: advertised and received
Address family IPv4 Unicast: advertised and received
Enhanced Refresh Capability: advertised and received
Multisession Capability:
Stateful switchover support enabled: NO for session 1
<truncated>
Here’s an example CLI configuration to change BGP timers on the BGP neighbor itself.
R1#config term Enter configuration commands, one per line. End with CNTL/Z. R1(config)#router bgp 65000 R1(config-router)#neighbor 10.1.0.2 timers 10 30 R1(config-router)#end R1#
Let’s clear now the BGP peerings and verify the new timers are in place on R1 and R2.
R1#
R1#clear ip bgp 10.1.0.2
R1#
*Sep 22 13:21:24.323: %BGP-3-NOTIFICATION: sent to neighbor 10.1.0.2 6/4 (Administrative Reset) 0 bytes
R1#
*Sep 22 13:21:24.354: %BGP-5-ADJCHANGE: neighbor 10.1.0.2 Down User reset
*Sep 22 13:21:24.355: %BGP_SESSION-5-ADJCHANGE: neighbor 10.1.0.2 IPv4 Unicast topology base removed from session User reset
*Sep 22 13:21:25.068: %BGP-5-ADJCHANGE: neighbor 10.1.0.2 Up
R1#
R1#show ip bgp neighbor
BGP neighbor is 10.1.0.2, remote AS 65000, internal link
Description: iBGP TO R2
BGP version 4, remote router ID 10.1.0.2
BGP state = Established, up for 00:00:51
Last read 00:00:01, last write 00:00:03, hold time is 30, keepalive interval is 10 seconds
Configured hold time is 30, keepalive interval is 10 seconds
Minimum holdtime from neighbor is 0 seconds
Neighbor sessions:
1 active, is not multisession capable (disabled)
Neighbor capabilities:
Route refresh: advertised and received(new)
Four-octets ASN Capability: advertised and received
Address family IPv4 Unicast: advertised and received
Enhanced Refresh Capability: advertised and received
Multisession Capability:
Stateful switchover support enabled: NO for session 1
<truncated>
R2#
*Sep 22 13:21:23.702: %BGP-3-NOTIFICATION: received from neighbor 10.1.0.1 6/4 (Administrative Reset) 0 bytes
R2#
*Sep 22 13:21:23.704: %BGP-5-NBR_RESET: Neighbor 10.1.0.1 reset (BGP Notification received)
*Sep 22 13:21:23.718: %BGP-5-ADJCHANGE: neighbor 10.1.0.1 Down BGP Notification received
*Sep 22 13:21:23.719: %BGP_SESSION-5-ADJCHANGE: neighbor 10.1.0.1 IPv4 Unicast topology base removed from session BGP Notification received
*Sep 22 13:21:24.442: %BGP-5-ADJCHANGE: neighbor 10.1.0.1 Up
R2#
R2#show ip bgp neighbor
BGP neighbor is 10.1.0.1, remote AS 65000, internal link
Description: iBGP TO R1
BGP version 4, remote router ID 10.1.0.1
BGP state = Established, up for 00:01:39
Last read 00:00:02, last write 00:00:01, hold time is 30, keepalive interval is 10 seconds
Neighbor sessions:
1 active, is not multisession capable (disabled)
Neighbor capabilities:
Route refresh: advertised and received(new)
Four-octets ASN Capability: advertised and received
Address family IPv4 Unicast: advertised and received
Enhanced Refresh Capability: advertised and received
Multisession Capability:
Stateful switchover support enabled: NO for session 1
<truncated>
Reducing timers help speed up your convergence; however, small timers could bring problems in the case of flapping interfaces. In fact, some Internet Service Providers will not allow you to configure your BGP timer below a certain value.
Advertisement
BGP Update-Source
The update-source statement designates the interface of which its IP address will be used as the source IP address to establish the BGP peering.
Let’s take a look at the following scenario.
We have an iBGP peering within AS 65000 and between R1 and R2 using the IP addresses of the common subnet between the two routers, which is 10.1.0.0/24.
R1 is peering with R2’s 10.1.0.2.
R1#show ip bgp summary BGP router identifier 10.1.0.1, local AS number 65000 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.1.0.2 4 65000 13 13 1 0 0 00:01:37 0 R1#
R2 is peering with R1’s 10.1.0.1.
R2#show ip bgp summary BGP router identifier 10.1.0.2, local AS number 65000 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.1.0.1 4 65000 19 18 1 0 0 00:02:35 0 R2#
If we want to change the peering addresses to each router’s loopback IP addresses, you have to use the update-source neighbor command.
- For R1 to peer with R2’s 2.2.2.2 IP address, you have to tell R2 to source from its Loopback0 interface.
- For R2 to peer with R1’s 1.1.1.1 IP address, you have to tell R1 to source from its Loopback0 interface.
The peering IP address has to match the source IP from the target router.
Let’s configure R1’s loopback address which will serve as the BGP source.
R1#config term Enter configuration commands, one per line. End with CNTL/Z. R1(config)#interface loopback0 *Sep 22 19:11:09.973: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up R1(config-if)#ip address 1.1.1.1 255.255.255.255 R1(config-if)#exit R1(config)# R1(config)#ip route 2.2.2.2 255.255.255.255 10.1.0.2 name R2_LOOPBACK_0 R1(config)#exit R1# *Sep 22 19:13:02.052: %SYS-5-CONFIG_I: Configured from console by console R1#
Likewise, let’s configure R2’s loopback address.
R2#config term Enter configuration commands, one per line. End with CNTL/Z. R2(config)#interface loopback0 *Sep 22 19:11:55.118: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up R2(config-if)#ip address 2.2.2.2 255.255.255.255 R2(config-if)#exit R2(config)#ip route 1.1.1.1 255.255.255.255 10.1.0.1 name R1_LOOPBACK_0 R2(config)#exit R2#
Now, let’s reconfigure R1 and R2 to peer with each other’s loopbacks.
R1# R1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R1(config)#router bgp 65000 R1(config-router)#no neighbor 10.1.0.2 R1(config-router)# *Sep 22 20:18:52.677: %BGP-3-NOTIFICATION: sent to neighbor 10.1.0.2 6/3 (Peer De-configured) 0 bytes *Sep 22 20:18:52.709: %BGP_SESSION-5-ADJCHANGE: neighbor 10.1.0.2 IPv4 Unicast topology base removed from session Neighbor deleted *Sep 22 20:18:52.717: %BGP-5-ADJCHANGE: neighbor 10.1.0.2 Down Neighbor deleted R1(config-router)#neighbor 2.2.2.2 remote-as 65000 R1(config-router)#neighbor 2.2.2.2 update-source loopback0 R1(config-router)#end R1# R2# *Sep 22 20:18:51.910: %BGP-3-NOTIFICATION: received from neighbor 10.1.0.1 6/3 (Peer De-configured) 0 bytes R2# *Sep 22 20:18:51.914: %BGP-5-NBR_RESET: Neighbor 10.1.0.1 reset (BGP Notification received) *Sep 22 20:18:51.929: %BGP-5-ADJCHANGE: neighbor 10.1.0.1 Down BGP Notification received *Sep 22 20:18:51.930: %BGP_SESSION-5-ADJCHANGE: neighbor 10.1.0.1 IPv4 Unicast topology base removed from session BGP Notification received R2# R2#config terminal Enter configuration commands, one per line. End with CNTL/Z. R2(config)#router bgp 65000 R2(config-router)#no neighbor 10.1.0.1 R2(config-router)#neighbor 1.1.1.1 remote-as 65000 R2(config-router)#neighbor 1.1.1.1 update-source loopback 0 R2(config-router)#end R2# *Sep 22 20:20:31.757: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up R2#
Let’s verify the BGP neighbors now.
R1# R1#show ip bgp summary BGP router identifier 10.1.0.1, local AS number 65000 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 2.2.2.2 4 65000 23 23 1 0 0 00:04:26 0 R1# R2# R2#show ip bgp summary BGP router identifier 10.1.0.2, local AS number 65000 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 1.1.1.1 4 65000 24 24 1 0 0 00:04:43 0 R2#
Notice that the BGP neighbors are now using their loopback addresses.
Advertisement
Advertising into BGP
You can advertise IP subnets in BGP by using the network command or redistribution. What’s important here to understand is the network command looks for the specified subnet in the routing table and if there’s a match, the route is inserted in the BGP table. Only the routes declared as “best” are sent to BGP peers. The best routes are those that win the tie-breaker process after analyzing all the BGP attributes from all competing routes to the same destination.
Routes in the routing table are routes being “used” by the router to route/forward packets. Routers don’t route packets based on the contents of the EIGRP topology table, the OSPF database, or BGP table. Routers only route packets based on routes placed in the routing table or Routing Information Base (RIB), so those are the routes that matter.
Let’s check the loopback interfaces and the BGP configuration on both R1 and R2.
R1#show running interface loopback0 Building configuration... Current configuration : 63 bytes ! interface Loopback0 ip address 1.1.1.1 255.255.255.255 end R1# R1#show running | sec router bgp router bgp 65000 bgp log-neighbor-changes neighbor 10.1.0.2 remote-as 65000 R1# R2#show running interface loopback0 Building configuration... Current configuration : 63 bytes ! interface Loopback0 ip address 2.2.2.2 255.255.255.255 end R2# R2#show running | sec router bgp router bgp 65000 bgp log-neighbor-changes neighbor 10.1.0.1 remote-as 65000 R2#
Let’s check R2’s BGP table.
R2#show ip bgp R2#
There’s nothing. That’s what we want for now. That means that R1 is not advertising its loopback 0 addresses.
Let’s now configure R1 to inject its loopback0 address into BGP with the BGP network command.
R1#config term Enter configuration commands, one per line. End with CNTL/Z. R1(config)#router bgp 65000 R1(config-router)#network 1.1.1.1 mask 255.255.255.255 R1(config-router)#end R1#
IMPORTANT: What the BGP network command does is that it looks at that specific prefix and mask in the routing table. If it finds the prefix-mask pair, it injects that route into the BGP table.
Let’s check for 1.1.1.1/32 on R1’s routing table.
R1#show ip route 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "connected", distance 0, metric 0 (connected, via interface)
Advertised by bgp 65000
Routing Descriptor Blocks:
* directly connected, via Loopback0
Route metric is 0, traffic share count is 1
R1#
Yes, it’s there. It’s a directly connected route.
Let’s take a look at whether R1 injected that route in its BGP table.
R1#show ip bgp
BGP table version is 4, local router ID is 10.1.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
R1#
Yes, it’s there. And because the BGP entry is marked at “best” route, that BGP route should be sent to R2. Let’s take a look at R2.
R2#show ip bgp
BGP table version is 4, local router ID is 10.1.0.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.1/32 10.1.0.1 0 100 0 i
R2#
R2 is indeed receiving 1.1.1.1/32.
Now, let’s undo what we did above and inject 1.1.1.1/32 via the redistribution of connected routes.
R1# R1#config term Enter configuration commands, one per line. End with CNTL/Z. R1(config)#router bgp 65000 R1(config-router)#no network 1.1.1.1 mask 255.255.255.255 R1(config-router)#redistribute connected R1(config-router)#end R1#
Let’s take a look at R1’s advertised routes to R2.
R1#show ip bgp neighbors 10.1.0.2 advertised-routes
BGP table version is 4, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 ?
*> 10.1.0.0/24 0.0.0.0 0 32768 ?
Total number of prefixes 2
R1#
Now, let’s take a look at R2 to see whether it is receiving those routes.
R2#show ip bgp
BGP table version is 8, local router ID is 10.1.0.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.1/32 10.1.0.1 0 100 0 ?
r>i 10.1.0.0/24 10.1.0.1 0 100 0 ?
R2#
And there they are.
Look at the origin code at the very right of the route underneath the Path column. There’s a question mark (?). That means the route was redistributed. Compare that origin code with the previous route injection with the network command. You’ll see an i for IGP instead of a ?. That i means that the route was injected with the network command.
Notice that R2 is also receiving the 10.1.0.0/24 subnet. That’s because R1 is redistributing all directly connected subnets. 10.1.0.0/24, the common subnet between R1 and R2, is also a connected subnet; however, notice that the entry on R2 for 10.1.0.0/24 has a Status Code on the very left of r, which means RIB-failure. In other words, the BGP process was not able to inject that route into the routing table. But, why? The routing table already has a route to 10.1.0.0/24 that comes from the directly connected interface. A connected route has an administrative distance (AD) of 0 that can’t be bumped out by an internal BGP route with an AD of 200.
R2#show ip route 10.1.0.0 255.255.255.0
Routing entry for 10.1.0.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via GigabitEthernet0/1
Route metric is 0, traffic share count is 1
R2#
Now you know how to originate directly connected routes into BGP using the network command or redistribution.
Advertisement
BGP Next-Hop-Self
When a BGP router receives a route from an eBGP peer and then propagates that route inside of its autonomous system by sending it to an iBGP peer, that route’s next-hop is the IP address of the sending eBGP peer. See the diagram below.
R10 and R1 are eBGP neighbors because they both belong to different autonomous systems (65100 and 65000), and R1 and R2 are iBGP peers because they both belong to the same autonomous system (65000).
The BGP next-hop-self command allows the edge BGP router (R1) to put itself as the next-hop (10.1.0.1) and overwrite the eBGP peer’s IP address (172.16.0.10). In other words, when you configure the next-hop-self option on the internal neighbor (R1), the next-hop attribute of the BGP external routes is changed to the source IP address (10.1.0.1) when the routes are sent to the internal neighbor (R2).
Following the diagram above, let’s take a quick look at the routers’ BGP configurations.
R10#show runn | sec router bgp router bgp 65100 bgp log-neighbor-changes network 10.10.10.10 mask 255.255.255.255 neighbor 172.16.0.1 remote-as 65000 R10# R1#show runn | sec router bgp router bgp 65000 bgp log-neighbor-changes neighbor 10.1.0.2 remote-as 65000 neighbor 172.16.0.10 remote-as 65100 R1# R2#show runn | sec router bgp router bgp 65000 bgp log-neighbor-changes neighbor 10.1.0.1 remote-as 65000 R2#
As you can see, R10 is advertising its loopback address to R1. Let’s take a look at how R2 sees that BGP route.
R2#show ip bgp
BGP table version is 1, local router ID is 10.1.0.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
* i 10.10.10.10/32 172.16.0.10 0 100 0 65100 i
R2#
In R10’s BGP table, the next hop is 172.16.0.10. That’s R10’s IP address, not R1’s. Why? Because 10.10.10.10/32 is entering the autonomous system from an eBGP peer. Also, notice that route is not selected as best route; there’s no > next to it. Why? Because R2 does not know how to get to 172.16.0.10. The next hop is invalid, and therefore, the route cannot be used. Although the route is on the BGP table, the route did not make it into the routing table.
R2#show ip route 10.10.10.10 % Subnet not in table R2#
Let’s change the next hop to be R1. How? We use the next-hop-self command on R1’s peering to R2.
R1#config term Enter configuration commands, one per line. End with CNTL/Z. R1(config)#router bgp 65000 R1(config-router)#neighbor 10.1.0.2 next-hop-self R1(config-router)#end R1#
Let’s verify the route to 10.10.10.10 on R2.
R2#show ip bgp
BGP table version is 2, local router ID is 10.1.0.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 10.10.10.10/32 10.1.0.1 0 100 0 65100 i
R2#
Now the next hop is 10.1.0.1, which is R1. R2 knows the next hop because it is a directly connected subnet. And also, the route is considered “best.” Notice the > on the left. Let’s see if the route is on the routing table.
R2#show ip route 10.10.10.10
Routing entry for 10.10.10.10/32
Known via "bgp 65000", distance 200, metric 0
Tag 65100, type internal
Last update from 10.1.0.1 00:02:29 ago
Routing Descriptor Blocks:
* 10.1.0.1, from 10.1.0.1, 00:02:29 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 65100
MPLS label: none
R2#
Yes, it is. We have successfully configured the BGP next-hop-self neighbor parameter.
Advertisement
BGP Filtering
With BGP, you can filter routes in the inbound and outbound direction with prefix lists, filter lists, and route maps.
You can apply prefix lists, filter lists (for AS path filtering), and route maps individually or all together at the same time; however, it is important that you understand the order in which filters are applied int the inbound and outbound directions.
The inbound route map, the inbound filter list (for AS path filtering), and the inbound prefix list must all permit the routes that are received from a neighbor before being accepted into the BGP table. At the same time, outgoing routes must pass the outbound prefix list, the outbound filter list (for AS path filtering), and the outbound route map before being transmitted to the neighbor.
- A prefix list allows you to filter prefixes based on the subnet and mask to inbound or outbound routes.
- A filter list allows you to filter based on the AS path attribute in the inbound or outbound direction.
- A route map allows you to filter prefixes and set/modify attributes to inbound or outbound routes.
Let’s do some BGP filtering based on this diagram.
Using a prefix list, let’s filter outbound the 1.1.1.1/32 prefix that R1 sends to R2.
Let’s see R2’s BGP table.
R2#show ip bgp
BGP table version is 12, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.1/32 10.1.0.1 0 100 0 i
* i 10.10.10.10/32 172.16.0.10 0 100 0 65100 i
R2#
So, R2 is receiving 1.1.1.1/32 (internal route) and 10.10.10.10/32 (external route) from R1. In other words, R10 is sending 10.10.10.10/32 to R1 and R1 is sending its own 1.1.1.1/32 and the external route 10.10.10.10/32 to R2.
Let’s use a prefix list to filter out 1.1.1.1/32 from R1 so R2 only receives 10.10.10.10/32.
R1#config term Enter configuration commands, one per line. End with CNTL/Z. R1(config)#ip prefix-list TO_R2 deny 1.1.1.1/32 R1(config)#ip prefix-list TO_R2 seq 1000 permit 0.0.0.0/0 le 32 R1(config)# R1(config)#router bgp 65000 R1(config-router)#neighbor 10.1.0.2 prefix-list TO_R2 out R1(config-router)#end R1# R1#clear ip bgp * out R1#
Since a prefix list has an implicit deny at the end, I added a sequence 1000 entry allowing all prefixes. So, I am denying the prefixes first and then allowing everything else.
The clear ip bgp * out command forces the router to resend all of its routes without bouncing the BGP peering.
Let’s take a look at R2’s BGP table now.
R2#show ip bgp
BGP table version is 13, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
* i 10.10.10.10/32 172.16.0.10 0 100 0 65100 i
R2#
Now R2 is only receiving 10.10.10.10/32.
Let’s now filter prefixes based on a filter list. Remember that the filter list filters based on the AS_PATH attribute. So, we’re going to filter out anything coming from AS 65100.
First, let’s remove the prefix list.
R1#config term R1(config)# R1(config)#router bgp 65000 R1(config-router)#no neighbor 10.1.0.2 prefix-list TO_R2 out R1(config-router)#end R1# R1#clear ip bgp * out R1#
And let’s check whether R2 is receiving 1.1.1.1/32 from R1.
R2#show ip bgp
BGP table version is 14, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.1/32 10.1.0.1 0 100 0 i
* i 10.10.10.10/32 172.16.0.10 0 100 0 65100 i
R2#
Yes, it is. Now, let’s filter anything coming from AS 65100. For this, you need to use a filter list. The filter list calls an as-path access list.
R1#config term R1(config)#ip as-path access-list 1 deny _65100$ R1(config)# R1(config)#router bgp 65000 R1(config-router)#neighbor 172.16.0.10 filter-list 1 in R1(config-router)#end R1# R1#clear ip bgp * in R1#
The _65000$ regular expression means anything in the AS path that starts with 65100. Since 10.10.10.10/32 is originated in AS 65100, that prefix has 65000 at the beginning of its AS_PATH.
Let’s take a look at R1’s and R2’s BGP tables.
R1#show ip bgp
BGP table version is 10, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
R1#
R2#show ip bgp
BGP table version is 14, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.1/32 10.1.0.1 0 100 0 i
R2#
As you can see, 10.10.10.10/32 is not present anymore.
Lastly, let’s filter routes based on route maps. We’re going to remove the filter list to allow the 10.10.10.10/32 prefix, and then we’re going to filter out that same prefix with a route map outbound on R1. R2 should stop receiving that prefix again.
R1# R1#config term Enter configuration commands, one per line. End with CNTL/Z. R1(config)#router bgp 65000 R1(config-router)#no neighbor 172.16.0.10 filter-list 1 in R1(config-router)#end R1# R1#clear ip bgp * in R1#
Let’s make sure that R2 is back to receiving this route.
R2#show ip bgp
BGP table version is 14, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.1/32 10.1.0.1 0 100 0 i
* i 10.10.10.10/32 172.16.0.10 0 100 0 65100 i
R2#
Yes, it is. Now, let’s configure a route map on R1 and apply it outbound on the neighbor to R2.
R1# R1#config term Enter configuration commands, one per line. End with CNTL/Z. R1(config)#ip prefix-list R10_LOOPBACK permit 10.10.10.10/32 R1(config)# R1(config)#route-map TO_R2_POLICY deny 10 R1(config-route-map)#match ip address prefix-list R10_LOOPBACK R1(config-route-map)#exit R1(config)#route-map TO_R2_POLICY permit 1000 R1(config-route-map)#exit R1(config)# R1(config)#router bgp 65000 R1(config-router)#neighbor 10.1.0.2 route-map TO_R2_POLICY out R1(config-router)#end R1# R1#clear ip bgp * out R1#
Because there’s an implicit deny at the end of a route map sequence, I address the route map entry 1000 allowing (permit) everything else. Notice that entry 1000 has no access list or prefix list to match, so all routes match.
Let’s see whether R2 stopped receiving 10.10.10.10/32 from R1.
R2#show ip bgp
BGP table version is 14, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.1/32 10.1.0.1 0 100 0 i
R2#
And yes, it stopped receiving R10’s loopback.
Let’s check whether 10.10.10.10/32 is on R1’s BGP table.
R1#show ip bgp
BGP table version is 11, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
*> 10.10.10.10/32 172.16.0.10 0 0 65100 i
R1#
Yes, it is. So R1 knows about 10.10.10.10/32 and has selected it as the best route (see the > to the left). R1 is filtering that prefix outbound to R2.
R1#
R1#show ip bgp neighbors 10.1.0.2 advertised-routes
BGP table version is 11, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
Total number of prefixes 1
R1#
Personally, I prefer to use route maps because they provide the option for attribute manipulation when needed. If you’re filtering with route maps today, later on, if needed, you edit them and manipulate attributes without having to change your router’s configuration to implement route maps. They’re already there in place. You just need to edit them.
Getting CCNA or CCNP Certified?
Self-paced Books. On-demand Courses. Practice Tests.
Sign up for a 10-day free trial with unlimited access!
Wrapping Up
Now that you’ve looked through the BGP configuration scenarios and commands, you should feel more comfortable with BGP.
I strongly recommend installing GNS3, Eve-NG, or Cisco CML and practicing all the BGP scenarios provided in this post.
If you have questions, please drop them in the comments section below.
