BGP Peering Setup: Configure External Routing (2026)

BGP peering is less about routing tables and more about negotiating who gets to tell whom what.

Let’s get a basic external BGP (eBGP) peering up and running between two routers, R1 and R2. This is the foundation for connecting your network to an Internet Service Provider (ISP) or another autonomous system (AS).

Here’s a typical scenario:

• R1: Your router, AS 65001
• R2: The ISP’s router, AS 65002
• Interface: GigabitEthernet0/1 on R1, connected to GigabitEthernet0/0 on R2.
• IP Addresses:
  • R1 GigabitEthernet0/1: 192.168.1.1/24
  • R2 GigabitEthernet0/0: 192.168.1.2/24
• BGP Configuration:
  • R1 will peer with R2 (neighbor 192.168.1.2).
  • R2 will peer with R1 (neighbor 192.168.1.1).

Configuring R1 (Your Router)

configure terminal
!
router bgp 65001
 neighbor 192.168.1.2 remote-as 65002
 neighbor 192.168.1.2 description **ISP_PEER_TO_R2**
 !
 address-family ipv4 unicast
  neighbor 192.168.1.2 activate
 exit-address-family
!
interface GigabitEthernet0/1
 ip address 192.168.1.1 255.255.255.0
 no shutdown
exit
!
end
write memory

Breakdown:

1. router bgp 65001: This starts the BGP process on R1 and assigns it AS number 65001.
2. neighbor 192.168.1.2 remote-as 65002: This is the core command. It tells R1 that 192.168.1.2 is a BGP neighbor and that this neighbor belongs to AS 65002. Because the remote-as is different from our local AS (65001), BGP knows this is an eBGP peering.
3. neighbor 192.168.1.2 description **ISP_PEER_TO_R2**: Good practice for labeling.
4. address-family ipv4 unicast: BGP uses address families to manage different types of routing information (IPv4, IPv6, VPNs, etc.). We need to activate IPv4 unicast for our peering.
5. neighbor 192.168.1.2 activate: This command within the address family explicitly enables the exchange of IPv4 unicast routes with this neighbor.
6. interface GigabitEthernet0/1 and ip address: Standard interface configuration. The no shutdown is crucial to bring the interface up.

Configuring R2 (ISP Router)

The ISP would configure their router similarly, but from their perspective.

configure terminal
!
router bgp 65002
 neighbor 192.168.1.1 remote-as 65001
 neighbor 192.168.1.1 description **CUSTOMER_PEER_TO_R1**
 !
 address-family ipv4 unicast
  neighbor 192.168.1.1 activate
 exit-address-family
!
interface GigabitEthernet0/0
 ip address 192.168.1.2 255.255.255.0
 no shutdown
exit
!
end
write memory

Breakdown:

1. router bgp 65002: R2’s BGP process, AS 65002.
2. neighbor 192.168.1.1 remote-as 65001: R2 sees R1 (192.168.1.1) as a neighbor in AS 65001. This is an eBGP peering.
3. address-family ipv4 unicast and neighbor 192.168.1.1 activate: Activates IPv4 unicast route exchange.

Verifying the Peering

Once both sides are configured and the interfaces are up, you can check the BGP status.

On R1, run:

show ip bgp summary

You’re looking for a line like this:

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.1.2     4        65002     150     120        5    0    0 00:15:30        10

• Neighbor: The IP address of the peer.
• V: BGP version (4 is common).
• AS: The remote AS number.
• MsgRcvd/MsgSent: Number of BGP messages exchanged.
• Up/Down: How long the session has been established. 00:15:30 means 15 minutes and 30 seconds. If it’s never or counting up from 0, the session isn’t up.
• State/PfxRcd: The state of the session. If it’s Established or shows a number of prefixes received (like 10 in the example), the peering is successful. If it’s Idle, Connect, Active, or OpenSent/OpenConfirm, there’s a problem.

If the State/PfxRcd shows a number, it means the BGP session is up and routes are being exchanged. The number indicates how many prefixes have been received from the neighbor.

What Happens Internally?

BGP establishes a TCP connection on port 179. Once the TCP session is up and the BGP OPEN messages are exchanged and validated (matching AS numbers, etc.), the session moves to the Established state. At this point, BGP starts exchanging UPDATE messages containing network prefixes and their attributes.

The most surprising true thing about BGP peering is that it doesn’t require an IP route to the neighbor to function, as long as the underlying network layer (like IP itself) can deliver TCP segments. The BGP session is the route discovery mechanism for BGP itself.

Consider this output from show ip bgp neighbors 192.168.1.2:

BGP neighbor is 192.168.1.2, remote AS number 65002
  Version 4, remote router ID 10.0.0.2
  BGP state = Established, up for 00:20:45
  Last reset at 00:05:00, due to Admin reset
  ...
  Address families:
    IPv4 Unicast: advertised and received
      ...
      Prefixes:
        Sent: 2
        Received: 15
      ...
  TCP connection: 192.168.1.1~179 to 192.168.1.2~179 - Active
  ...

This shows the BGP state (Established), the uptime, and crucially, the number of prefixes sent and received for the IPv4 Unicast address family. The TCP connection line confirms the underlying transport. When you configure neighbor <ip> remote-as <asn>, the router doesn’t check if there’s a pre-existing IP route to <ip>. Instead, it immediately tries to establish a TCP connection to <ip> on port 179. If the underlying network can deliver those TCP packets, the BGP session can form, and only then will BGP routes be exchanged.

The next concept you’ll need to grapple with is controlling which prefixes you advertise to your new neighbor and which prefixes you accept from them, which is managed through route maps and prefix lists.