Tasks
Note: You must download the file initial.bgp.zip (Check Lab0: Initial Configurations) and load "initial BGP" configurations on all routers before starting this lab.
● Configure BGP R1 - R8 routers using AS 100.
● Create a full mesh of iBGP peerings between these devices without using their Loopback0 interfaces.
● Advertise the Loopback0 prefixes of these devices into BGP.
● Ensure full IPv4 reachability for Loopback0 prefixes of R1 - R8 routers.
Configurations
R1:
enable
configure terminal
!
router bgp 100
network 170.1.1.1 mask 255.255.255.255
neighbor 177.1.0.2 remote-as 100
neighbor 177.1.0.3 remote-as 100
neighbor 177.1.0.4 remote-as 100
neighbor 177.1.0.5 remote-as 100
neighbor 177.1.58.8 remote-as 100
neighbor 177.1.67.7 remote-as 100
neighbor 177.1.146.6 remote-as 100
!
end
!
write
!
R2:
!
enable
configure terminal
!
router bgp 100
network 170.1.2.2 mask 255.255.255.255
neighbor 177.1.0.1 remote-as 100
neighbor 177.1.0.3 remote-as 100
neighbor 177.1.0.4 remote-as 100
neighbor 177.1.0.5 remote-as 100
neighbor 177.1.37.7 remote-as 100
neighbor 177.1.58.8 remote-as 100
neighbor 177.1.146.6 remote-as 100
!
end
!
write
!
R3:
!
enable
configure terminal
!
router bgp 100
network 170.1.3.3 mask 255.255.255.255
neighbor 177.1.0.1 remote-as 100
neighbor 177.1.0.2 remote-as 100
neighbor 177.1.0.4 remote-as 100
neighbor 177.1.0.5 remote-as 100
neighbor 177.1.37.7 remote-as 100
neighbor 177.1.58.8 remote-as 100
neighbor 177.1.146.6 remote-as 100
!
end
!
write
!
R4:
!
enable
configure terminal
!
router bgp 100
network 170.1.4.4 mask 255.255.255.255
neighbor 177.1.0.1 remote-as 100
neighbor 177.1.0.2 remote-as 100
neighbor 177.1.0.3 remote-as 100
neighbor 177.1.0.5 remote-as 100
neighbor 177.1.58.8 remote-as 100
neighbor 177.1.67.7 remote-as 100
neighbor 177.1.146.6 remote-as 100
!
end
!
write
!
R5:
!
enable
configure terminal
!
router bgp 100
network 170.1.5.5 mask 255.255.255.255
neighbor 177.1.0.1 remote-as 100
neighbor 177.1.0.2 remote-as 100
neighbor 177.1.0.3 remote-as 100
neighbor 177.1.0.4 remote-as 100
neighbor 177.1.37.7 remote-as 100
neighbor 177.1.58.8 remote-as 100
neighbor 177.1.146.6 remote-as 100
!
end
!
write
!
R6:
!
enable
configure terminal
!
router bgp 100
network 170.1.6.6 mask 255.255.255.255
neighbor 177.1.0.2 remote-as 100
neighbor 177.1.0.3 remote-as 100
neighbor 177.1.0.5 remote-as 100
neighbor 177.1.58.8 remote-as 100
neighbor 177.1.67.7 remote-as 100
neighbor 177.1.146.1 remote-as 100
neighbor 177.1.146.4 remote-as 100
!
end
!
write
!
R7:
!
enable
configure terminal
!
router bgp 100
network 170.1.7.7 mask 255.255.255.255
neighbor 177.1.0.5 remote-as 100
neighbor 177.1.23.2 remote-as 100
neighbor 177.1.37.3 remote-as 100
neighbor 177.1.58.8 remote-as 100
neighbor 177.1.67.6 remote-as 100
neighbor 177.1.146.1 remote-as 100
neighbor 177.1.146.4 remote-as 100
!
end
!
write
!
R8:
!
enable
configure terminal
!
router bgp 100
network 170.1.8.8 mask 255.255.255.255
neighbor 177.1.0.1 remote-as 100
neighbor 177.1.0.2 remote-as 100
neighbor 177.1.0.3 remote-as 100
neighbor 177.1.0.4 remote-as 100
neighbor 177.1.37.7 remote-as 100
neighbor 177.1.58.5 remote-as 100
neighbor 177.1.146.6 remote-as 100
!
end
!
write
!
Verifications
The first step in any BGP configuration is always to establish peering relationships between the BGP speaking devices. Recall that because BGP does not have its own transport protocol, underlying IGP reachability must already be established to allow the TCP port 179 sessions to be successful between neighbors.
BGP is a normal TCP application, which means that a TCP client initiates the session to the TCP server with a SYN packet going to the well-known port of 179. If the BGP server is configured to accept the session, a reply with SYN/ACK comes from port 179 back to the client, going to the high port number generated by the client. If both BGP peers attempt to establish the connection at the same time, RFC 4271 (A Border Gateway Protocol 4) defines a “BGP Connection Collision Detection” mechanism, in which essentially the session originated from the device with the higher BGP router-id is maintained, and the secondary session is dropped.
The below debug output shows the step-by-step formation of the iBGP peering between R1 and R2. Note that access-list 100 is used to filter the debug output and only show the output pertinent to the BGP session between R1 and R2:
R1
configure terminal
access-list 100 permit tcp any host 177.1.0.2
access-list 100 permit tcp host 177.1.0.2 any
do debug ip packet detail 100
router bgp 100
neighbor 177.1.0.2 remote-as 100
R1 is configured with the neighbor statement pointing toward R2, and R2 is already configured with the neighbor statement pointing toward R1. A SYN is sent from R1 to initiate the session. Notice the source port of 11712 and the destination port of 179:
Because R2 has a neighbor statement pointing back toward the address 177.1.0.1, a reply of ACK/SYN is received, with the source port of 179 and the destination port randomly generated by R1, 11712. These two steps indicate that R1 is the client and R2 is the server:
R1 replies with ACK, completing the 3-way TCP handshake and opening the session for BGP attribute negotiation. Only after necessary parameters are correctly negotiated, such as remote-as numbers, authentication, and address-family support, will the BGP session actually be declared up:
The details of the peering negotiation between R1 and R2, such as the router-id and timers, can be seen below. The neighbor capability of “Address family IPv4 Unicast: advertised and received” means that by default, they can exchange IPv4 prefixes, but not other such as IPv6 Unicast or VPNv4/VPNv6. The details for IPv4 unicast address family show that one prefix has been received from the neighbor and one prefix has been advertised to the neighbor:
R1:
show ip bgp neighbor 177.1.0.2
For address family: IPv4 Unicast
The TTL of the outbound session is set to 255, because this is an iBGP session. This means that the iBGP neighbors need not be directly connected, as long as IGP reachability exists between them. EBGP sessions have a TTL of 1 by default, which means that neighbors must be directly connected, unless further configuration is applied. Also note the “Local port: 11712” and “Foreign port: 179.” These essentially mean the source and destination ports from R1’s perspective, which again enforces the notion that R1 is the client for this session and R2 is the server:
The following show ip bgp summary output shows a concise aggregation of all configured neighbors, with the important fields being the local AS, router-id, table size in both prefixes and memory, peer addresses, remote ASs, neighbor uptime, and number of prefixes learned:
R1:
show ip bgp summary
Note that for devices running multiple address-families, such as IPv4 unicast VPNv4/VPNv6, show commands are expressed as show bgp [AFI] [SAFI] [args] , such as the show bgp ipv4 unicast summary seen below. Although the output is the same as the above show ip bgp summary , it can quickly become hard to tell what output you are viewing in larger-scale BGP deployments without this logical separation:
R1
show bgp ipv4 unicast summary
After the peering relationships are established, the actual BGP prefixes learned can be viewed in the BGP table with show ip bgp or show bgp ipv4 unicast . This output is crucial to completely understand, especially when multiple paths to the same destination exist:
R1:
show ip bgp
R1
show ip route bgp
One of the most important fields in the above outputs is the next-hop value. Note that this field is set to the peering address for the neighbor from which the route is learned. For example, the prefix 170.1.7.7/32 is via the next-hop 177.1.67.7. To reach this prefix, a recursive lookup must now be performed on the next-hop until an outgoing interface is found:
R1
show ip route 170.1.7.7
show ip route 177.1.67.7
In the above case, recursion toward 170.1.7.7/32 continues until the outgoing interface GigabitEthernet0/2 is found. Note that unless route-recursion toward the next-hop of a BGP prefix is successful, the route cannot be considered for best path selection, which also implies that it cannot be installed in the IP routing table or advertised to any other BGP peer. This issue will be explored in detail in the coming tasks.
Also note that in this task, a full-mesh of iBGP peerings is established. This is because of the design requirement that an iBGP learned route cannot be advertised to another iBGP neighbor to prevent routing loops, unless exceptions such as route-reflection or confederation are implemented. The result is that the only routes advertised to the other BGP peers are the local Loopback0 prefixes, but not any of the routes learned from the other neighbors. This also implies that in this design, if any individual peering breaks, connectivity between prefixes advertised by those peers also breaks:
R1
show ip bgp neighbors 177.1.0.2 advertised-routes
