BGP Configuration

Submitted by rayc on Tue, 02/01/2022 - 14:44

In the previous article, I talked a little about BGP and how it works. This article will go through the configuration BGP using both IPv4 and IPv6 addressing. For this article, I will use the following topology.

BGP Configuration Topology

Here we have 6 routers inside 4 BGP AS's. AS123 represents Company 123 with a multihomed Internet connection to their Service Provider in AS4. AS5 and 6 represent smaller organisations that use a single Internet connection to connect to the same Service Provider. All routers have been configured with a Link Local IPv6 address of fe80:XX::Y where XX is the links router numbers (So the Link between R1 and R3 would be FE80:13::) and Y is the router number itself (So R1's Link Local address for the link between R1 and R3 would be FE80:13::1).

When configuring BGP, you first need to tell the router to use BGP and to specify the BGP AS that the router belongs to. To enable BGP, use the global configuration command router bgp <asn>. Once you have enabled BGP, it is best practice to manually configure the BGP Router ID. Manually configuring the RID prevents it from ever changing if an interface goes down or doesn't come up after a reboot. If the RID changes on a BGP router, it will reset all of the current BGP sessions. To configure the RID, use the bgp router subconfiguration command bgp router-id <id>. It is recommended to configure the RID as a value that is easily identifiable. 

Enabling BGP and configured the RID

Once you have enabled BGP, you will then need to specify the address family to use for your configuration (you can also disable the default IPv4 address family by using the command no bgp default ip 4-unicast​​​​​​​​​​​​.) Because we have both IPv4 and IPv6 addressing we will need to configure both address families. However, I will use 2 different methods of advertising IPv6 routes. The first method is by using all IPv6 addressing for neighbours and running a full dual stack environment. The second is by advertising IPv6 NLRI, over IPV4 BGP peering. 

BGP for IPv4

Let's start with configuring BGP for IPv4 NLRI and peering. I won't go through the configuration of each router as the configuration for IPv4 it is identical. We've already enabled BGP and configured the RID on R1. From here we need to configure the BGP peers and the autonomous systems that they belong to. R1 has two iBGP peers. We know they are iBGP peers as they are in the same ASN. To configure a BGP peer, use the command neighbor <ip> remote-as <asn>​​​​​​. On some IOS versions, you may also need to use the command neighbor <ip> activate, however I have not found this the case in most IOS versions i've used so far.  Before we configured the neighbour, we need to tell the router to use the IPv4 AFI for this BGP peer. To do that, use the command address-family <afi> <safi>.

Configuring BGP peer on R1

Now that we have a BGP peer configured, the router will attempt to establish a TCP session with the peer. This will currently fail though as we haven't configured R2 or R3 for BGP yet. If we take a look at the output of the show bgp ipv4 unicast summary command we can see that the neighbour state is in the Idle state. This is because no TCP session can be established yet.

Output of show bgp ipv4 unicast summary command pre R2/3 configuration

Now let's go ahead and configure R2 and R3 exactly the same way as R1 and check the output of the show bgp ipv4 unicast summary command again. Straight away, we can see that as soon as the BGP peer was configured, the BGP session came up and we can see in the output that we have an established session, but are not receiving any prefixes from the peer. 

Configuring BGP on R2 and verifying neighbour state.

Now that we have established the BGP sessions and out iBGP peering is working as expected. We need to start advertising networks. There are a couple of ways to do this in BGP. We can use the network <network> mask <netmask>  command, or we can redistribute routes from an IGP or from connected interfaces. On R1, I will specify specific network statements to advertise from BGP but from R2 and R3, I will use the command redistribute connected. When using the network <prefix> mask <netmask> command, you must specify prefixes that match exactly to what is in the RIB. 

Configuring network statements on R1

If we take a look at the BGP table on R2 now, we should be able see the prefixes for 1.1.1.0/24, 10.1.12,0/24, and 10.1.13.0/24 being advertised.

Verifying that NLRI are being received from R1

Here we see that we are receiving all 3 prefixes and two of them are selected as the best route. Notice the route for 10.1.12.0/24 has an r next to it, indicating that there is a RIB failure. The reason for a RIB failure is usually that there is a better route to the prefix in the RIB already. In this case, there is a Directly Connected route to the 10.1.12.0/24 network. Next I will configure the redistribute connected command on R2 and R3 and check the BGP table on R1 to confirm all routes are being received. 

Configuring connected network redistribution on R2

output of R1 show bgp ipv4 unicast

Notice the path attributes of these routes. Routes that are locally originated, have a next hop of 0.0.0.0, have no local preference value, and have a weight of 32768. I haven't gone through the BGP path selection process yet but weight is the first attribute that is used to influence path selection. 

Next let's configure the BGP peers between R2 and R4 and R3 and R4. These are eBGP peering sessions as they are between two routers in different ASN's. The configuration for an eBGP peering is exactly the same as an iBGP peering. To configure the peer use the command neighbor <ip> remote-as <asn>​​​​​​. 

Configuring R4 BGP peer on R2

With the rest of the routers in out topology the configuration is exactly the same and I have used the redistribute connected command on all other routers to advertise the NLRI information. Now that we have all peers configured, let's take a look at the Loc-RIB table on R1.

Output of show bgp ipv4 unicast after all BGP peers are up

Here we can see that we have received all BGP NLRI information from all routers from AS 4 and 5 as well as our iBGP peers. We can see more specific BGP Path Attributes about a route by using the show command show bgp ipv4 unicast <prefix>.

Output of the show bgp ipv4 unicast <prefix> command

Here we can see that there are 2 paths to the 6.6.6.0/24 network via R2, and R3. The router has chosen the path via R2 as the best. This is due to the BGP path selection criteria which I will go through in detail in another article but for now this would have been due to the route via R2 as it has the lowest RID value. If this was an eBGP peering, then it would be the oldest route received, but with iBGP, it is the Lowest RID. There are about 13 different criteria for BGP to select the best path.

To verify your BGP neighbours, and the neighbour state and number of prefixes being received from each neighbour, you can use the show command show bgp ipv4 unicast summary. This provides a brief output of the neighbour states etc.

Output of the show bgp ipv4 unicast summary command on R4

You can also see more detailed information about a neighbour by using the show command show bgp ipv4 unicast neighbor <ip>. This provides a detailed output of the specified neighbour including the RID, how long the session has been up, the BGP neighbour capabilities, how many messages and which types have been sent and received etc. Below is an example of the output of the R2 peer from R4.

R4#sh bgp ipv4 uni neig 10.1.24.2 
BGP neighbor is 10.1.24.2,  remote AS 123, external link
  BGP version 4, remote router ID 2.2.2.2
  BGP state = Established, up for 02:22:57
  Last read 00:00:13, last write 00:00:28, 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
  Message statistics:
    InQ depth is 0
    OutQ depth is 0
    
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:               12          6
    Keepalives:           156        158
    Route Refresh:          0          0
    Total:                171        165
  Default minimum time between advertisement runs is 30 seconds

 For address family: IPv4 Unicast
  Session: 10.1.24.2
  BGP table version 45, neighbor version 45/0
  Output queue size : 0
  Index 1, Advertise bit 0
  1 update-group member
  Slow-peer detection is disabled
  Slow-peer split-update-group dynamic is disabled
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:              12          5 (Consumes 320 bytes)
    Prefixes Total:                72          9
    Implicit Withdraw:             49          2
    Explicit Withdraw:              9          2
    Used as bestpath:             n/a          2
    Used as multipath:            n/a          0

                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Invalid Path:                        11        n/a
    Total:                               11          0
  Number of NLRIs in the update sent: max 4, min 0
  Last detected as dynamic slow peer: never
  Dynamic slow peer recovered: never
  Refresh Epoch: 1
  Last Sent Refresh Start-of-rib: 02:22:57
  Last Sent Refresh End-of-rib: 02:22:57
  Refresh-Out took 0 seconds
  Last Received Refresh Start-of-rib: never
  Last Received Refresh End-of-rib: never
                                       Sent       Rcvd
        Refresh activity:              ----       ----
          Refresh Start-of-RIB          1          0
          Refresh End-of-RIB            1          0

  Address tracking is enabled, the RIB does have a route to 10.1.24.2
  Connections established 3; dropped 2
  Last reset 23:49:04, due to Active open failed
  Transport(tcp) path-mtu-discovery is enabled
  Graceful-Restart is disabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0            
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 10.1.24.4, Local port: 63054
Foreign host: 10.1.24.2, Foreign port: 179
Connection tableid (VRF): 0
Maximum output segment queue size: 50

Enqueued packets for retransmit: 0, input: 0  mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x1F9173B8):
Timer          Starts    Wakeups            Next
Retrans           164          0             0x0
TimeWait            0          0             0x0
AckHold           162        156             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger         7693       7692      0x1F9176BB
DeadWait            0          0             0x0
Linger              0          0             0x0
ProcessQ            0          0             0x0

iss:  581712859  snduna:  581716537  sndnxt:  581716537
irs: 1131825300  rcvnxt: 1131828629
          
sndwnd:  15642  scale:      0  maxrcvwnd:  16384
rcvwnd:  15985  scale:      0  delrcvwnd:    399

SRTT: 1000 ms, RTTO: 1003 ms, RTV: 3 ms, KRTT: 0 ms
minRTT: 24 ms, maxRTT: 1000 ms, ACK hold: 200 ms
Status Flags: active open
Option Flags: nagle, path mtu capable
IP Precedence value : 6

Datagrams (max data segment is 1460 bytes):
Rcvd: 327 (out of order: 0), with data: 163, total data bytes: 3328
Sent: 327 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 165, total data bytes: 3677

 Packets received in fast path: 0, fast processed: 0, slow path: 0
 fast lock acquisition failures: 0, slow path: 0
TCP Semaphore      0x69FFE034  FREE 

You can also see what specific routes you are sending to a BGP peer or receiving from a BGP peer. To view the routes being received by a specific BGP peer, use the show command show bgp ipv4 unicast neighbor <ip> received-routes and to show the routes that you are advertising to a specific BGP peer, use the show command show bgp ipv4 unicast neighbor <ip> advertised-routes.

Viewing the advertised and received routes - no soft-reconfiguration inbound

Notice the error when trying to view the received routes? In order for you to view what routes are being received, the router BGP neighbour keyword soft-reconfiguration [inbound|outbound] must be configured. Let's add the command to the BGP configuration and try again.

Viewing the BGP received routes with soft-reconfiguration inbound configured

Let's just take a quick look at the BGP table on R2.

Show bgp ipv4 unicast on R2

Notice something missing? There's no routes for any networks on R3. This is because with iBGP, a route learned from another iBGP peer, is not advertised to any other iBGP peer. This helps prevent routing loops etc. In order to resolve this issue, an iBGP implementation should always be configured in a full mesh. This means that R2 and R3 in our scenario should also be iBGP peers. This is possible with iBGP even though the networks are not directly connected due to the TTL value of 255. Let's configure R2 and R3 as iBGP peers and check the route table again on R2.

Configuring iBGP full mesh between R2 and R3

BGP for IPv6

Now that we have BGP for IPv4 configured let's take a look at the configuration of BGP for IPv6. As I mentioned earlier, there are 2 ways to advertise IPv6 NLRI over BGP. You can run both IPv4 and IPv6 address families and use IPv6 addressing for peers so that all information is sent over IPv6, or you can tell BGP to advertise IPv6 information to your IPv4 BGP peers. There is some additional configuration required when using the second method which I will go through. 

To start with, let's configure R1 to use the IPv6 address family and IPv6 addressing to establish a BGP peering with R2 and R3. To do this, the first thing you need to do is to enable IPv6 routing on the router with the global configuration command IPv6 unicast-routing​​​​​​. Once this is done you can then configure the BGP IPv6 address family and configure the IPv6 BGP peer using the commands address-family <afi> <safi>to enable the IPv6 AFI and the command neighbor <IPv6 address> remote-as <asn>is command to configure the BGP peer address. Let's go ahead and configure the peering between R1 and R2. 

R1 IPv6 BGP configuration

R2 IPv6 BGP Configuration

We should now be able to verify that we have an IPv6 BGP peer using the show command ​​show bgp ipv6 unicast summary ​​​.

output of show bgp ipv6 unicast sum on R1 pre network advertisement

From the output we can see that we have an IPv6 peer, but no routes are being received. This is because we haven't advertised the networks or redistributed connected networks into BGP yet. The command is exactly the same with IPv6 as it is for IPv4 as are the concepts of how the network statement and aggregate statement work. To advertise the connected networks into BGP use the command network <prefix/length> or to redistribute the connected networks into BGP use the command redistribute connected under the IPv6 address family. 

Configuring the network statement on R1

Configuring IPv6 connected route redistribution

Now that we have some networks being advertised into our IPv6 BGP table, let's take another look at the output of the show bgp IPv6 unicast summary command and then view the IPv6 BGP table using the command show bgp IPv6 unicast ​​​​​​. 

Verifying the BGP neighbours and Loc-RIB table

Now let's take a look at the second option for advertising IPv6 NLRI, using IPv4 neighbours. In order to get this to work, under the IPv6 address family, you specify the neighbour IP address as the IPv4 address. This tells the router to use the IPv4 BGP address to advertise IPv6 information. Remember, BGP is kind of like an application that sends NLRI over TCP. Let's go ahead and configure the BGP peering between R1 and R3 to use the IPv4 address to advertise IPv6 NLRI. 

Configuring IPv6 peering over IPv4 neighbour

We've already configured the IPv6 network statements on R1, and I have configured redistribution on R3. Let's take a look at the IPv6 BGP table on R3 using the show command show bgp IPv6 unicast. 

R3 output of show bgp ipv6 unicast pre route-map

Notice the next-hop value of the routes? They're not correct IPv6 addresses like when we used IPv6 neighbours in our example before. This is because BGP, when it advertises the prefixes, the advertising router will use whatever Interface IP address the BGP peer is established on. This also prevents these routes from entering the IPv6 RIB as there is no valid next-hop address. To resolve this issue, we need use route-maps to tell the router to set the next-hop to the correct IPv6 interface address. This must be applied outbound on the sending Peer. To configure a route-map use the command route-map <name> <sequence> [permit|deny]. Once you have configured the route map, you can specify the correct next-hop IPv6 address using the command set ipv6 next-hop <address>. The route-map then needs to be applied to the BGP peer using the command neighbor <ip> route-map <name> [in|out]. Route-maps can be used to do much more than set the next-hop but I will go through that more in another article. Let's configure the route-map on R1 and R3. I will only show the configuration of R1 as it's exactly the same on R3 just with different Next-Hop addresses.

Configuring the Next Hop route-map on R1

Now that we have the route-maps configured and applied, let's take another look at the BGP IPv6 table on R3 again. 

Output of show bgp ipv6 unicast summary post route-map

Once again, we can see that there are no IPv6 routes for R2 on R3. The same rules for iBGP over IPv4 apply to IPv6 so once again, we need to configure a full mesh iBGP. Because i've decided to send IPv6 NLRI over IPv4 on R3, I will configure the same for the peering between R3 and R2. This again requires a route-map to be applied to the BGP peer outbound as routes are advertised. 

Configuring full mesh IPv6 iBGP and confirming routes

Now we have a full mesh IPv6 iBGP configuration. Let's go ahead and configure the IPv6 peering between R2 and R3. This is an eBGP peering and the configuration is exactly the same for all other routers. As usual, I haven't shown the configuration of each device as it's exactly the same as earlier. Throughout the rest of the topology, I have used IPv6 peering over IPv6 addressing with all BGP neighbours. Let's take a look at the BGP neighbour summary, and the IPv6 BGP table on R4 now that all IPv6 Peers have been configured. 

Output on R4 of sh bgp ipv6 unicast sum and sh bgp ipv6 unicast

Notice the Next Hop value of :: in the above output? With IPv6, a Next Hop value of ::, indicates that this route was a locally originated route. :: is the IPv6 equivalent of 0.0.0.0. Once again, we can view more detailed information about our IPv6 BGP peers and routes. To view a detailed output of a specific neighbour and it's capabilities etc, use the show command show bgp ipv6 unicast neighbor <ip>

R1#sh bgp ipv6 uni neigh 2001:12::2 
BGP neighbor is 2001:12::2,  remote AS 123, internal link
  BGP version 4, remote router ID 2.2.2.2
  BGP state = Established, up for 15:53:44
  Last read 00:00:48, last write 00:00:25, 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 IPv6 Unicast: advertised and received
    Enhanced Refresh Capability: advertised and received
    Multisession Capability: 
    Stateful switchover support enabled: NO for session 1
  Message statistics:
    InQ depth is 0
    OutQ depth is 0
    
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:                4          6
    Keepalives:          1048       1049
    Route Refresh:          0          0
    Total:               1053       1056
  Default minimum time between advertisement runs is 0 seconds

 For address family: IPv6 Unicast
  Session: 2001:12::2
  BGP table version 15, neighbor version 15/0
  Output queue size : 0
  Index 1, Advertise bit 0
  1 update-group member
  Slow-peer detection is disabled
  Slow-peer split-update-group dynamic is disabled
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:               3          7 (Consumes 616 bytes)
    Prefixes Total:                 6          8
    Implicit Withdraw:              3          0
    Explicit Withdraw:              0          1
    Used as bestpath:             n/a          6
    Used as multipath:            n/a          0

                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Bestpath from this peer:              7        n/a
    Bestpath from iBGP peer:              4        n/a
    Invalid Path:                         1        n/a
    Total:                               12          0
  Number of NLRIs in the update sent: max 1, min 0
  Last detected as dynamic slow peer: never
  Dynamic slow peer recovered: never
  Refresh Epoch: 1
  Last Sent Refresh Start-of-rib: never
  Last Sent Refresh End-of-rib: never
  Last Received Refresh Start-of-rib: never
  Last Received Refresh End-of-rib: never
                                       Sent       Rcvd
        Refresh activity:              ----       ----
          Refresh Start-of-RIB          0          0
          Refresh End-of-RIB            0          0

  Address tracking is enabled, the RIB does have a route to 2001:12::2
  Connections established 1; dropped 0
  Last reset never
  Transport(tcp) path-mtu-discovery is enabled
  Graceful-Restart is disabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0            
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255
Local host: 2001:12::1, Local port: 179
Foreign host: 2001:12::2, Foreign port: 49582
Connection tableid (VRF): 0
Maximum output segment queue size: 50

Enqueued packets for retransmit: 0, input: 0  mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x24B9B4FC):
Timer          Starts    Wakeups            Next
Retrans          1052          0             0x0
TimeWait            0          0             0x0
AckHold          1055       1033             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger            0          0             0x0
DeadWait            0          0             0x0
Linger              0          0             0x0
ProcessQ            0          0             0x0

iss: 1392181662  snduna: 1392201892  sndnxt: 1392201892
irs: 2166651633  rcvnxt: 2166672059

sndwnd:  16384  scale:      0  maxrcvwnd:  16384
rcvwnd:  16251  scale:      0  delrcvwnd:    133

SRTT: 1000 ms, RTTO: 1003 ms, RTV: 3 ms, KRTT: 0 ms
minRTT: 8 ms, maxRTT: 1000 ms, ACK hold: 200 ms
Status Flags: passive open, gen tcbs
Option Flags: nagle, path mtu capable
IP Precedence value : 6

Datagrams (max data segment is 1440 bytes):
Rcvd: 2109 (out of order: 0), with data: 1056, total data bytes: 20425
Sent: 2103 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 2103, total data bytes: 104357

 Packets received in fast path: 0, fast processed: 0, slow path: 0
 fast lock acquisition failures: 0, slow path: 0
TCP Semaphore      0x6B20EB7C  FREE 

To view a routes specific BGP Path Attributes, use the show command show bgp ipv6 unicast <prefix>.

Output of the show bgp ipv6 unicast <prefix> command

Once again we can see that the best path is via R2. And once again, this would be due to the R2 peer, having a lower RID than the R3 peer. As with IPv4, you can see the specific IPv6 routes that are being received from and advertised to a specific BGP peer. To view the routes that are being advertised to a peer, use the show command show bgp ipv6 unicast neighbor <ip> advertised-routes and the view the routes that are being received from that peer, use the show command show bgp ipv6 unicast neighbor <ip> received-routes. This command requires that soft-reconfiguration inbound be configured on the BGP peer as well. 

Output of sh bgp ipv6 uni neig advertised and received routes on R4