Advertising networks in BGP

Contents

Intro

You can advertise networks into BGP by using a network statement or by redistributing them from another protocol like OSPF. The network statement in BGP is very different than the network statement used in other routing protocols. In OSPF or EIGRP, the network statement is used to determine what interfaces the protocol will run on. For example, enable OSPF area 2 on G0/2.  The network statment in BGP has nothing to do with interfaces, it takes networks that are already in the routing table, into BGP.

I’ll configure BGP here and advertise networks a few different ways on R3 and we’ll verify everything is propagating on the other routers. 

For BGP to advertise networks there must first be an exact match in the routing table. Don't forget to download the EVE-NG topology file for this tutorial below.

Topology

Network topology diagram for BGP advertising tutorial featuring three routers: R1 in AS100, R2 in AS200, and R3 in AS300.
The last octet is the router number unless specified otherwise. Example: R1's G0/0 is 10.10.13.1/24

Intial Configs

Configuration Steps

1. Configure eBGP peerings between all routers

The first thing I need to do is get BGP configured between the 3 routers and make sure the neighbors are up.

R1:

router bgp 100
 neighbor 10.10.12.2 remote-as 200
 neighbor 10.10.13.3 remote-as 300

R2:

router bgp 200
 neighbor 10.10.12.1 remote-as 100

R3:

router bgp 300
 neighbor 10.10.13.1 remote-as 100

These peerings are eBGP peerings. You can tell because the locally configured AS number is different then the one used in the neighbor statements. After a few seconds a message pops up on the console letting me know the neighbors are up. 

R1:

%BGP-5-ADJCHANGE: neighbor 10.10.12.2 Up 
%BGP-5-ADJCHANGE: neighbor 10.10.13.3 Up

R2:

%BGP-5-ADJCHANGE: neighbor 10.10.12.1 Up

R3:

%BGP-5-ADJCHANGE: neighbor 10.10.13.1 Up

Even though the message says the neighbors are up, I still want to quickly verify myself by using the show ip bgp summary command. I’ll do this on all 3 routers. 

R1:

R1#sh ip bgp summary
BGP router identifier 10.10.13.1, local AS number 100
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.12.2      4          200       6       5        1    0    0 00:02:43        0
10.10.13.3      4          300       5       5        1    0    0 00:02:29        0

R1 has 2 neighbors that are up. 

R2:

R2#sh ip bgp summary
BGP router identifier 10.10.12.2, local AS number 200
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.12.1      4          100       5       6        1    0    0 00:02:44        0

R2’s peering with R1 is up.

R3:

R3#sh ip bgp summary
BGP router identifier 10.10.13.3, local AS number 300
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.13.1      4          100       5       5        1    0    0 00:02:29        0

R3’s peering with R1 is up as well. At this time no networks are being received on any router. This is because we haven’t advertised anything yet. Let’s change that. On R3 I’ll create Loopback3 with an IP of 3.3.3.3/32.

2. Advertise networks into BGP on R3 using the network statement.

R3:

interface Loopback3
 ip address 3.3.3.3 255.255.255.255

For a network to successfully make into BGP there must first be an exact match in the routing table. I’ve created Lo3 with an IP of 3.3.3.3/32 and it should be in the routing table as a directly connected route. I’ll confirm this by using the show ip route connected command. 

R3#show ip route connected 
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set

      3.0.0.0/32 is subnetted, 1 subnets
C        3.3.3.3 is directly connected, Loopback3

Perfect, there is a route in the routing table for that network. The next step is to go into the BGP process and use the network statement. 

R3:

router bgp 300
 network 3.3.3.0 mask 255.255.255.0

The network statement in BGP is completely different than the network statment used in IGP’s like OSPF for example. In OSPF the network statement tells it what interfaces the protocol should run on. BGP doesn’t care about interfaces when it comes to network statements. Network statements in BGP tell it what networks need to get installed installed or injected into the BGP table. Now I’ll check the BGP table on R3 to see if the network is there.

R3#sh ip bgp 3.3.3.3
% Network not in table

Is says “Network not in table” in the above output. What happened here? The problem is that my network statement in BGP is network 3.3.3.0 mask 255.255.255.0 this is a /24 and doesn’t match the /32 that’s in the IP routing table. 

Remember, for a network to make it to the BGP table there must be an exact match in the routing table. I’ll fix this now and check the BGP table again.

R3:

router bgp 300
no network 3.3.3.0 mask 255.255.255.0
network 3.3.3.3 mask 255.255.255.255

R3#sh ip bgp 3.3.3.3
BGP routing table entry for 3.3.3.3/32, version 2
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1         
  Refresh Epoch 1
  Local
    0.0.0.0 from 0.0.0.0 (10.10.12.2)
      Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
      rx pathid: 0, tx pathid: 0x0

After I fixed the network statement on R3, the network is now in the BGP table. If you want to see all of the networks in the BGP table just use the show ip bgp command. 

R3#show ip bgp
BGP table version is 2, local router ID is 10.10.12.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
 *>   3.3.3.3/32       0.0.0.0                  0         32768 i

R3 is neighbors with R1 and R1 is neighbors with R2 so this network should have been propagated to the rest of the routers. Sure we can assume but it’s best to verify.

R1#sh ip bgp
BGP table version is 2, local router ID is 10.10.13.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
 *>   3.3.3.3/32       10.10.13.3               0             0 300 i
R2#sh ip bgp
BGP table version is 2, local router ID is 10.10.13.3
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
 *>   3.3.3.3/32       10.10.12.1                             0 100 300 i

The above output from the show ip bgp command on R1 and R2 confirm that that the router is being advertised to all routers. Notice the ‘i’ origin code on the far right of the network this is the default origin code when the network is injected to the BGP tables using the ‘network’ statement. 

3. Advertise networks into BGP using redistribution.

Another method of getting networks into BGP is by redistributing them from another protocol. Currently R3’s G0/0 interface has an IP of 10.10.13.3/24. So there should be a connected route for that network in the routing table. Let me show you. 

R3#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set

      3.0.0.0/32 is subnetted, 1 subnets
C        3.3.3.3 is directly connected, Loopback3
      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.10.13.0/24 is directly connected, GigabitEthernet0/0
L        10.10.13.3/32 is directly connected, GigabitEthernet0/0

If I need to get this connected network into BGP I can use a network statement of 10.10.13.0 mask 255.255.255.0 since an exact match is currently in the routing table or I can redistribute this connected network into BGP. 

R3:

router bgp 300
 redistribute connected

R3#show ip bgp
BGP table version is 3, local router ID is 10.10.12.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
 *>   3.3.3.3/32       0.0.0.0                  0         32768 i
 *>   10.10.13.0/24    0.0.0.0                  0         32768 ?

Now the connected network of 10.10.13.0/24 is present in the BGP table of R3. Notice the origin code of “?” this is the default origin code when something is redistributed into BGP. Let me check the BGP tables of R1 and R2 to make sure this new prefix made it into their BGP tables. 

R1#sh ip bgp
BGP table version is 3, local router ID is 10.10.13.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
 *>   3.3.3.3/32       10.10.13.3               0             0 300 i
 r>   10.10.13.0/24    10.10.13.3               0             0 300 ?
The "r" code next to the 10.10.13.0/24 network on R1 stands for RIB-failure. BGP learned about this network from a peer but didn't install it in the routing table because another routing protocol has this route with a lower administrative distance. The connected routes AD of 0 beats eBGP's AD of 20. 
R2#sh ip bgp
BGP table version is 3, local router ID is 10.10.13.3
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
 *>   3.3.3.3/32       10.10.12.1                             0 100 300 i
 *>   10.10.13.0/24    10.10.12.1                             0 100 300 ?

The redistributed network is making it to the other routers BGP table with no issues.

4. Advertising routes into BGP using Null0.

The Null0 interface is a virtual interface that discards traffic sent to it. It’s used to advertise prefixes into BGP that are not dynamically learned or directly connected. Adding a static route to a Null0 interface can be done to ensure the route remains in the routing table without actually routing packets destined for that network. If I want to advertise the 4.4.0.0/16 network on R3 into BGP using a network statement, it won’t work because I don’t have a matching route for 4.4.0.0/16 in my routing table. 

R3#sh ip route 4.4.0.0
% Network not in table

I can fix this by adding a static route for 4.4.0.0/16 and pointing the next-hop to null0.

ip route 4.4.0.0 255.255.0.0 null 0

Now I’ll check the routing table again. 

R3#sh ip route 4.4.0.0
Routing entry for 4.4.0.0/16
  Known via "static", distance 1, metric 0 (connected)
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 0, traffic share count is 1

You can see the route is in the routing table and points to null0. Now I’ll add a network statement in BGP for 4.4.0.0/16 and check the BGP table to see if it was successfully added. I’ll make sure my network statement matches exactly what’s in the routing table.

router bgp 300
 network 4.4.0.0 mask 255.255.0.0

R3#show ip bgp
BGP table version is 4, local router ID is 10.10.12.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
 *>   3.3.3.3/32       0.0.0.0                  0         32768 i
 *>   4.4.0.0/16       0.0.0.0                  0         32768 i
 *>   10.10.13.0/24    0.0.0.0                  0         32768 ?

After I added the network statement for 4.4.0.0/16 I can see that prefix in the BGP table on R3. R1 and R2 should have received this new prefix as well. Let’s verify.

R1#sh ip bgp
BGP table version is 4, local router ID is 10.10.13.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
 *>   3.3.3.3/32       10.10.13.3               0             0 300 i
 *>   4.4.0.0/16       10.10.13.3               0             0 300 i
 r>   10.10.13.0/24    10.10.13.3               0             0 300 ?>
R2#sh ip bgp
BGP table version is 4, local router ID is 10.10.13.3
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
 *>   3.3.3.3/32       10.10.12.1                             0 100 300 i
 *>   4.4.0.0/16       10.10.12.1                             0 100 300 i
 *>   10.10.13.0/24    10.10.12.1                             0 100 300 ?

Looks like R1 and R2 have no issues receiving any of the networks we advertised in BGP. I hope you found this tutorial helpful if you have any questions please let me know. Dont’ forget to try this lab in EVE-NG, the topology file is below. 

Take a look at the BGP UPDATE message in Wireshark. This is what R3 sent to R2. One of the things the update message contains is the actual the prefixes that need to be advertised or withdrawn.

When learning about BGP you'll hear the terms networks, prefixes and Next Layer Reachability Information (NLRI) used interchangeably. They're just fancy words for "routes"
Wireshark capture displaying a BGP update message with three networks advertised.

EVE-NG Lab File

To download the EVE-NG topology file you'll need to be a member. You can register here. It will be right here once you log in.

Full Configs

Here are the full configs from all routers if you want to try it out yourself.

Discussion

You'll need to be a member if you want to participate in the discussion. You can register right here. The discussion will be visible here once you log in.