Basic eBGP Configuration Lab — Free CCNP ENCOR Lab

ENCOR BGP EVE-NG

This CCNP ENCOR lab covers basic eBGP configuration in EVE-NG: you complete the tasks, then verify the result with show commands. The lab comes with the topology, initial configs for every device and a step-by-step solution. Need a refresher first? Read the EVE-NG Guide.

Establish an eBGP session between R1 and R2 over the 10.12.12.0/30 link.

R1: AS 65001, BGP router ID 1.1.1.1
R2: AS 65002, BGP router ID 2.2.2.2
Use the IP addresses of the GigabitEthernet0/0 interfaces for the neighbor relationship

On R1, advertise the network of Loopback0 (172.16.1.0/24) into BGP.

On R2, advertise the networks of Loopback0 (192.168.20.0/24) and Loopback1 (10.20.20.0/24) into BGP.

Advertise each network with its exact prefix length

Verify the result.

The BGP session is Established on both routers
Each router has the other router’s networks in its routing table as BGP routes
R1 can ping both loopbacks of R2, using its own Loopback0 as the source

Topology

Initial configs (addressing only, no BGP yet)

R1 Initial Config

hostname R1
!
interface Loopback0
 ip address 172.16.1.1 255.255.255.0
!
interface GigabitEthernet0/0
 ip address 10.12.12.1 255.255.255.252
 no shutdown

R2 Initial Config

hostname R2
!
interface Loopback0
 ip address 192.168.20.1 255.255.255.0
!
interface Loopback1
 ip address 10.20.20.1 255.255.255.0
!
interface GigabitEthernet0/0
 ip address 10.12.12.2 255.255.255.252
 no shutdown

Note

Two routers are enough: build it in Packet Tracer (two 2911 routers connected Gi0/0 to Gi0/0), in EVE-NG or on real equipment. Paste the initial configs first and check with ping 10.12.12.2 from R1 that the link works before you start with BGP. If your Packet Tracer version does not accept bgp router-id, skip that command: the router ID then becomes the highest loopback address (172.16.1.1 on R1, 192.168.20.1 on R2) and the rest of the lab works the same.

This lab covers the ENCOR 350-401 blueprint item on configuring and verifying eBGP between directly connected neighbors.

Show the solutiontry the tasks first

Task 1. Establish an eBGP session between R1 (AS 65001, router ID 1.1.1.1) and R2 (AS 65002, router ID 2.2.2.2).

BGP does not discover neighbors by itself: every neighbor is configured by hand with its IP address and its AS number. Because the AS numbers differ, this is an external (eBGP) session. The router ID is set explicitly so it does not depend on which interfaces happen to be up.

On R1:

R1(config)#router bgp 65001
R1(config-router)#bgp router-id 1.1.1.1
R1(config-router)#neighbor 10.12.12.2 remote-as 65002

On R2:

R2(config)#router bgp 65002
R2(config-router)#bgp router-id 2.2.2.2
R2(config-router)#neighbor 10.12.12.1 remote-as 65001

After a few seconds both routers log the session coming up:

On R1:

%BGP-5-ADJCHANGE: neighbor 10.12.12.2 Up

Verification

R1#show ip bgp summary

R1#show ip bgp summary
BGP router identifier 1.1.1.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.12.12.2      4        65002       5       5        1    0    0 00:00:42        0

-> The last column shows a number (0 prefixes received so far), which means the session is Established. A word such as Idle or Active there would mean the session is not up: check the neighbor address, the remote AS number and that the link answers ping.

Task 2. On R1, advertise 172.16.1.0/24 into BGP.

The BGP network command takes a subnet mask, not a wildcard mask as in OSPF or EIGRP. It also does not enable anything on interfaces: it only announces a prefix, and only if exactly that prefix (same network and mask) is already in the routing table.

On R1:

R1(config)#router bgp 65001
R1(config-router)#network 172.16.1.0 mask 255.255.255.0

Task 3. On R2, advertise 192.168.20.0/24 and 10.20.20.0/24 into BGP.

On R2:

R2(config)#router bgp 65002
R2(config-router)#network 192.168.20.0 mask 255.255.255.0
R2(config-router)#network 10.20.20.0 mask 255.255.255.0

A common mistake: network 10.20.20.0 without a mask makes IOS assume the classful mask, here 255.0.0.0 (10.0.0.0/8). The routing table has 10.20.20.0/24, not 10.0.0.0/8, so nothing is advertised and no error is shown. The same happens with network 10.20.0.0 mask 255.255.0.0. If a prefix does not appear in show ip bgp, compare the network statement with show ip route first.

Task 4. Verify the result.

R1#show ip bgp summary

R1#show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 65001
BGP table version is 4, main routing table version 4
3 network entries using 744 bytes of memory
3 path entries using 408 bytes of memory

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.12.12.2      4        65002      12      11        4    0    0 00:06:15        2

-> R1 now receives 2 prefixes from R2 (on R2 the same command shows 1).

R1#show ip bgp

R1#show ip bgp
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
Origin codes: i - IGP, e - EGP, ? - incomplete

     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.20.20.0/24    10.12.12.2               0             0 65002 i
 *>  172.16.1.0/24    0.0.0.0                  0         32768 i
 *>  192.168.20.0     10.12.12.2               0             0 65002 i

-> How to read it:

*>: the path is valid and is the best path.
Next hop 0.0.0.0, weight 32768: the prefix was originated on this router by its own network command.
Path 65002 i: the prefix came from AS 65002 and was injected there with a network command (origin IGP).
192.168.20.0 is shown without /24 because that is its classful mask. IOS leaves the length out in that case.

R1#show ip route bgp

R1#show ip route bgp
      10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
B        10.20.20.0/24 [20/0] via 10.12.12.2, 00:05:02
B     192.168.20.0/24 [20/0] via 10.12.12.2, 00:05:02

-> [20/0]: 20 is the administrative distance of eBGP routes (iBGP routes have 200), 0 is the metric (MED).

R1 ping with Loopback0 as the source

R1#ping 192.168.20.1 source 172.16.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms

R1#ping 10.20.20.1 source 172.16.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.20.20.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms

-> The ping works in both directions because R2 also knows 172.16.1.0/24 through BGP. Without the source option R1 would use 10.12.12.1, which proves only that the directly connected link works.

Save the configuration:

On R1 and R2:

copy running-config startup-config

← All ENCOR labs