Goldfish Networks wordmark
Create a free account
Guide

BGP Network Statement Not Advertising a Route? The Exact-Match Rule

You add a network line under router bgp, the session is Established, and the peer still never gets the prefix. Usually the line is valid as typed and wrong as a match. BGP's network command does not enable anything on an interface the way the OSPF command does. It is a lookup: the router searches its IP routing table for a route with exactly that prefix and exactly that mask, and originates the prefix only while that route exists. A /24 in the table does not satisfy a /16 statement, and BGP never summarizes or splits a route to make one fit. This guide shows how to prove which side of the match is wrong and how to fix it, with output captured on IOS XE 17.16 routers in Cisco Modeling Labs. It assumes a working peering; if you are building one from scratch, start with how to configure eBGP peering.

By Alec Gauldin, Principal Network Engineer · Published

Part of the BGP learning hub. Practice on hands-on CCNP labs.

eBGP at the edges, iBGP across the middle — the reference wiring for BGP, not a specific lab.

How the network command decides what to originate

network 172.16.1.0 mask 255.255.255.0 under router bgp 65001 asks the routing table one question: is there an entry for 172.16.1.0/24? Not a route that covers it and not a subnet inside it, but that prefix with that length. If there is, BGP creates a locally originated entry in its own table and offers it to every peer its outbound policy allows. If there is not, the line stays in the running config, does nothing, and prints no warning.

Any source counts: a connected interface, a static route, or an IGP route. BGP copies the next hop from the matched route, so a connected loopback or a static route to Null0 gives next hop 0.0.0.0 (this router), while a route learned through a neighbor gives that neighbor's address. Every locally originated entry gets weight 32768 and origin IGP (i), and the detailed view labels the path sourced, local.

The match stays live. When the route leaves the routing table, BGP loses the path and withdraws the prefix. When the route comes back, BGP originates it again without a session reset. On the routing-table side, show ip route for the exact prefix adds the line Advertised by bgp 65001 while BGP is originating it, so one command confirms both halves.

OSPF and EIGRP use network differently: there, a wildcard mask selects the interfaces the protocol runs on. Carrying that habit into BGP produces the mismatches below.

R1# show ip bgp 172.16.1.0/24
BGP routing table entry for 172.16.1.0/24, version 2
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1          2         
  Refresh Epoch 1
  Local
    0.0.0.0 from 0.0.0.0 (10.255.0.1)
      Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
      rx pathid: 0, tx pathid: 0x0
      Updated on Sep 17 2026 17:47:50 UTC

R1# show ip route 172.16.1.0 255.255.255.0
Routing entry for 172.16.1.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Advertised by bgp 65001
  Routing Descriptor Blocks:
  * directly connected, via Loopback1
      Route metric is 0, traffic share count is 1

R1 in the baseline: the connected /24 matches, and the routing table shows BGP advertising it. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

A route learned from OSPF counts too

R1 learns R2's Loopback0, 10.255.0.2/32, from OSPF at cost 11. A temporary network 10.255.0.2 mask 255.255.255.255 on R1 matches that route. The BGP entry takes the OSPF next hop, 10.0.12.2, instead of 0.0.0.0, and the OSPF cost becomes the entry's metric, which BGP hands to an eBGP peer as the MED.

R1(config)# router bgp 65001
R1(config-router)# network 10.255.0.2 mask 255.255.255.255

R1# show ip bgp 10.255.0.2/32
BGP routing table entry for 10.255.0.2/32, version 9
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1          2         
  Refresh Epoch 1
  Local
    10.0.12.2 from 0.0.0.0 (10.255.0.1)
      Origin IGP, metric 11, localpref 100, weight 32768, valid, sourced, local, best
      rx pathid: 0, tx pathid: 0x0
      Updated on Sep 17 2026 17:54:06 UTC

R1# show ip route 10.255.0.2 255.255.255.255
Routing entry for 10.255.0.2/32
  Known via "ospf 1", distance 110, metric 11, type intra area
  Advertised by bgp 65001
  Last update from 10.0.12.2 on Ethernet0/0, 00:05:33 ago
  Routing Descriptor Blocks:
  * 10.0.12.2, from 10.255.0.2, 00:05:33 ago, via Ethernet0/0
      Route metric is 11, traffic share count is 1

The matched route is OSPF, so the BGP entry inherits its next hop and its cost. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

The topology behind the examples

Four IOS XE routers. R1 and R2 form AS 65001, peer over iBGP between their Loopback0 addresses, and run OSPF area 0 between them. R3 is AS 65002 and R4 is AS 65003. Each router originates its own prefixes from loopback interfaces with an exact-mask network statement. The examples follow R1's 172.16.1.0/24 toward its eBGP peer, R3.

  • R1 (AS 65001): Loopback0 10.255.0.1/32, Loopback1 172.16.1.1/24, Ethernet0/0 10.0.12.1/30 to R2, Ethernet0/1 10.0.13.1/30 to R3
  • R2 (AS 65001): Loopback0 10.255.0.2/32, Loopback1 172.16.2.1/24, Ethernet0/0 10.0.12.2/30 to R1, Ethernet0/1 10.0.24.1/30 to R4
  • R3 (AS 65002): Ethernet0/0 10.0.13.2/30 to R1, Ethernet0/1 10.0.34.1/30 to R4, originates 198.51.100.0/24
  • R4 (AS 65003): Ethernet0/0 10.0.24.2/30 to R2, Ethernet0/1 10.0.34.2/30 to R3, originates 203.0.113.0/24 and 192.0.2.0/24
R1(config)# router bgp 65001
R1(config-router)# bgp router-id 10.255.0.1
R1(config-router)# neighbor 10.255.0.2 remote-as 65001
R1(config-router)# neighbor 10.255.0.2 update-source Loopback0
R1(config-router)# neighbor 10.255.0.2 next-hop-self
R1(config-router)# neighbor 10.0.13.2 remote-as 65002
R1(config-router)# network 172.16.1.0 mask 255.255.255.0

R1's BGP configuration in the working baseline.

Step 1 — Confirm the session is Established

A prefix cannot reach a peer whose session is down, so rule that out first. In show ip bgp summary, a number under State/PfxRcd means the session is Established and shows how many prefixes arrived. A word such as Idle or Active means it is not, and no network statement will change that. For those states, work through BGP neighbor states before going further.

Both of R1's sessions show a prefix count here, so the rest of this guide looks only at origination.

R1# show ip bgp summary
BGP router identifier 10.255.0.1, local AS number 65001
BGP table version is 8, main routing table version 8
...
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.13.2       4        65002      10       8        8    0    0 00:02:56        3
10.255.0.2      4        65001       7       9        8    0    0 00:02:21        3

A number under State/PfxRcd on both lines: both sessions are Established. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

Step 2 — Check the originating router's BGP table

Run show ip bgp for the exact prefix on the router that should originate it, not on the peer. % Network not in table means BGP never created the entry, so the cause is the statement or the routing table, and nothing downstream matters yet. A path marked sourced, local means origination works and the fault is further along; skip to the last section.

A common version: the site owns 172.16.0.0/16, so the statement was rewritten for the whole block and the /24 line was removed. R1's routing table holds 172.16.1.0/24 and nothing of length /16, so the new statement matches nothing.

The running config hides a second trap. IOS leaves out the mask keyword whenever the mask is the classful default for the address, so the /16 statement is stored as network 172.16.0.0. Read a network line with no mask as a classful prefix: /8, /16 or /24, depending on the first octet.

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

R1# show ip bgp 172.16.0.0/16
% Network not in table

R1# show running-config | section router bgp
router bgp 65001
 bgp router-id 10.255.0.1
 bgp log-neighbor-changes
 network 172.16.0.0
 neighbor 10.0.13.2 remote-as 65002
 neighbor 10.255.0.2 remote-as 65001
 neighbor 10.255.0.2 update-source Loopback0
 neighbor 10.255.0.2 next-hop-self

The fault: a /16 statement, and only a /24 in the routing table. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

The same display rule in a working config

R3 originates a /24 out of class C space, so its correct statement prints without a mask too. network 198.51.100.0 on R3 is the /24 it should be, while the similar-looking network 172.16.0.0 on R1 is a /16. The line tells you nothing on its own; the address does. show ip bgp abbreviates the same way in its Network column, so a bare 198.51.100.0 or 172.16.0.0 is a classful prefix while 172.16.1.0/24 keeps its length.

R3# show running-config | section router bgp
router bgp 65002
 bgp router-id 10.255.0.3
 bgp log-neighbor-changes
 network 198.51.100.0
 neighbor 10.0.13.1 remote-as 65001
 neighbor 10.0.34.2 remote-as 65003

R3's running config: a correct /24 statement, printed with no mask keyword. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

Step 3 — Look up the same prefix and mask in the routing table

Ask the routing table the question the statement asks. With a mask, show ip route 172.16.0.0 255.255.0.0 looks for that exact entry, and here it answers % Subnet not in table: R1 knows subnets inside 172.16.0.0 but holds no route of length /16. That is the whole fault. BGP looked, found nothing, and originated nothing.

Then add longer-prefixes to list what the table does hold under the block: R1's connected 172.16.1.0/24 with its /32 local entry, and R2's 172.16.2.0/24 learned over iBGP. The statement asks for a /16 and the table holds /24s.

R1# show ip route 172.16.0.0 255.255.0.0
% Subnet not in table

R1# show ip route 172.16.0.0 255.255.0.0 longer-prefixes
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
...
Gateway of last resort is not set
      172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C        172.16.1.0/24 is directly connected, Loopback1
L        172.16.1.1/32 is directly connected, Loopback1
B        172.16.2.0/24 [200/0] via 10.255.0.2, 00:08:07

No /16 in R1's routing table, only the more specific routes beneath it. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

Step 4 — Fix the statement or fix the routing table

Which fix you need depends on what you meant to advertise. The first option below matches the statement to the route that already exists; the other two put the /16 in the table so a statement written for the block has something to match.

If the /24 was the intent, remove the /16 line and restore the exact prefix. BGP originates it as soon as the statement matches.

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

R1# show ip bgp 172.16.1.0/24
BGP routing table entry for 172.16.1.0/24, version 18
Paths: (1 available, best #1, table default)
  Flag: 0x8100
  Advertised to update-groups: (Pending Update Generation)
     2         
  Refresh Epoch 1
  Local
    0.0.0.0 from 0.0.0.0 (10.255.0.1)
      Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
      rx pathid: 0, tx pathid: 0x0
      Updated on Sep 17 2026 18:00:27 UTC

Fixed: the statement and the connected route agree on /24. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

If the /16 was the intent, give the statement a route to match. A static route to Null0 keeps 172.16.0.0/16 in the routing table for as long as the route is configured, and BGP originates the block with next hop 0.0.0.0. Packets for any part of the /16 without a more specific route are discarded at R1 instead of following a default route somewhere else. The /24 statement is still in place, so R1 originates the subnet alongside the block.

R1(config)# ip route 172.16.0.0 255.255.0.0 Null0
R1(config)# router bgp 65001
R1(config-router)# network 172.16.0.0 mask 255.255.0.0

R1# show ip bgp 172.16.0.0/16
BGP routing table entry for 172.16.0.0/16, version 9
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1          2         
  Refresh Epoch 1
  Local
    0.0.0.0 from 0.0.0.0 (10.255.0.1)
      Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
      rx pathid: 0, tx pathid: 0x0
      Updated on Sep 17 2026 17:54:29 UTC

R1# show ip route 172.16.0.0 255.255.0.0
Routing entry for 172.16.0.0/16
  Known via "static", distance 1, metric 0 (connected)
  Advertised by bgp 65001
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 0, traffic share count is 1

The static route gives the /16 statement its exact match. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

Or let BGP build the summary

aggregate-address 172.16.0.0 255.255.0.0 summary-only builds the /16 from more specific prefixes already in the BGP table, with no static route. summary-only stops those prefixes from being advertised and marks them s in show ip bgp: below, both R1's own 172.16.1.0/24 and the 172.16.2.0/24 it learned from R2 fall under the aggregate and are suppressed. IOS installs its own Null0 route for the aggregate, this time at administrative distance 200 and marked type locally generated. The two methods differ in lifetime: the aggregate exists only while at least one more specific prefix is in the BGP table, while a Null0-anchored statement stays advertised as long as the static route is configured.

R1(config)# router bgp 65001
R1(config-router)# aggregate-address 172.16.0.0 255.255.0.0 summary-only

R1# show ip bgp | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>   172.16.0.0       0.0.0.0                            32768 i
 s>   172.16.1.0/24    0.0.0.0                  0         32768 i
 s>i  172.16.2.0/24    10.255.0.2               0    100      0 i
 *>i  192.0.2.0        10.255.0.2               0    100      0 65003 i
 *                     10.0.13.2                              0 65002 65003 i
 *>   198.51.100.0     10.0.13.2                0             0 65002 i
 *>i  203.0.113.0      10.255.0.2               0    100      0 65003 i
 *                     10.0.13.2                              0 65002 65003 i

R1# show ip route 172.16.0.0 255.255.0.0
Routing entry for 172.16.0.0/16
  Known via "bgp 65001", distance 200, metric 0, type locally generated
  Routing Descriptor Blocks:
  * directly connected, via Null0
      opaque_ptr 0x716C9E5462B0 
      Route metric is 0, traffic share count is 1
      AS Hops 0
      MPLS label: none

The aggregate is originated, and the /24s beneath it are marked suppressed. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

Step 5 — Confirm what R1 sends and what R3 receives

Check both ends after the fix. On R1, show ip bgp neighbors 10.0.13.2 advertised-routes lists what R1 is sending R3 right now. While the /16 statement stood alone, 172.16.1.0/24 was missing from that list. After the fix it is back, shown with the local next hop 0.0.0.0, which R1 replaces with its own address, 10.0.13.1, in the update to R3.

The list also carries R2's own 172.16.2.0/24 and the two prefixes R2 learned from R4, because the baseline has no outbound policy: R1 passes on what it hears from inside AS 65001. Filtering that is a separate job, covered in prefix-list and AS-path filtering.

On R3, show ip bgp 172.16.1.0/24 lists two paths for the prefix: one straight from R1 with AS path 65001, and one that went the long way round through R4 with 65003 65001. The shorter AS path wins, so R1's path is the best one, and its next hop is 10.0.13.1.

No session reset is needed at any point. A network statement that starts or stops matching sends the update or withdrawal by itself. Soft clears are for policy changes.

! While the /16 statement stood alone
R1# show ip bgp neighbors 10.0.13.2 advertised-routes
BGP table version is 15, local router ID is 10.255.0.1
...
     Network          Next Hop            Metric LocPrf Weight Path
 *>i  172.16.2.0/24    10.255.0.2               0    100      0 i
 *>i  192.0.2.0        10.255.0.2               0    100      0 65003 i
 *>i  203.0.113.0      10.255.0.2               0    100      0 65003 i

Total number of prefixes 3 

! After the fix
R1# show ip bgp neighbors 10.0.13.2 advertised-routes
BGP table version is 18, local router ID is 10.255.0.1
...
     Network          Next Hop            Metric LocPrf Weight Path
 *>   172.16.1.0/24    0.0.0.0                  0         32768 i
 *>i  172.16.2.0/24    10.255.0.2               0    100      0 i
 *>i  192.0.2.0        10.255.0.2               0    100      0 65003 i
 *>i  203.0.113.0      10.255.0.2               0    100      0 65003 i

Total number of prefixes 4

What R1 sends R3, before and after the fix: three prefixes, then four. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

The view from R3

R3 keeps both copies and marks the one it will use best. The losing path is still valid and still external, so it takes over the moment the winner is withdrawn.

R3# show ip bgp 172.16.1.0/24
BGP routing table entry for 172.16.1.0/24, version 5
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     1         
  Refresh Epoch 1
  65003 65001
    10.0.34.2 from 10.0.34.2 (10.255.0.4)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
      Updated on Sep 17 2026 17:49:53 UTC
  Refresh Epoch 1
  65001
    10.0.13.1 from 10.0.13.1 (10.255.0.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
      Updated on Sep 17 2026 17:49:31 UTC

R3 has the prefix from R1 and, with a longer AS path, from R4. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

Other ways the exact match fails

The mask mismatch above is one form. Each of these others leaves the same evidence: no usable path for the prefix in the originator's BGP table.

  • No mask keyword. network 172.16.1.0 is accepted without a warning, but IOS applies the classful mask and stores network 172.16.0.0, a /16 that matches nothing here. Type the mask for anything that is not a whole classful network.
  • Host bits in the address. network 172.16.1.1 mask 255.255.255.0 names the interface address, not the prefix. IOS XE rejects it with % BGP: Incorrect network or mask/prefix-length configured and adds nothing. Use the network address, 172.16.1.0.
  • The route left the table. A shut or failed interface, a deleted static route or a lost IGP route removes the match. BGP drops the path and withdraws the prefix, and restoring the route brings it back.
  • The route has a different length. A summary or a default route never satisfies a more specific statement, and a loopback that OSPF advertises as a /32 host route never satisfies a /24 statement written for that loopback's subnet. longer-prefixes shows what is really in the table.

Leaving out the mask, on the device

R1 already had the correct /24 statement, so this adds a second line instead of replacing one, and IOS stores that line as the classful network 172.16.0.0.

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

R1# show running-config | section router bgp
router bgp 65001
 bgp router-id 10.255.0.1
 bgp log-neighbor-changes
 network 172.16.0.0
 network 172.16.1.0 mask 255.255.255.0
 neighbor 10.0.13.2 remote-as 65002
 neighbor 10.255.0.2 remote-as 65001
 neighbor 10.255.0.2 update-source Loopback0
 neighbor 10.255.0.2 next-hop-self

R1# show ip bgp 172.16.0.0/16
% Network not in table

Typed as a /24 network address with no mask, stored as a /16 statement, and there is no /16 to originate. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

Host bits set

R1(config)# router bgp 65001
R1(config-router)# network 172.16.1.1 mask 255.255.255.0
% BGP: Incorrect network or mask/prefix-length configured

R1# show running-config | section router bgp
router bgp 65001
 bgp router-id 10.255.0.1
 bgp log-neighbor-changes
 network 172.16.1.0 mask 255.255.255.0
 neighbor 10.0.13.2 remote-as 65002
 neighbor 10.255.0.2 remote-as 65001
 neighbor 10.255.0.2 update-source Loopback0
 neighbor 10.255.0.2 next-hop-self

IOS XE refuses the line, so the running config still holds only the correct /24 statement. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

When the route leaves the table

Shutting R1's Loopback1 removes the connected /24. The routing-table lookup fails, the BGP entry drops to Paths: (0 available, no best path) and Not advertised to any peer, and the prefix disappears from what R1 advertises to R3. no shutdown restores the route, and BGP originates the prefix again without any BGP command.

R1(config)# interface Loopback1
R1(config-if)# shutdown

R1# show ip route 172.16.1.0 255.255.255.0
% Subnet not in table

R1# show ip bgp 172.16.1.0/24
BGP routing table entry for 172.16.1.0/24, version 17
Paths: (0 available, no best path)
  Not advertised to any peer

R1# show ip bgp neighbors 10.0.13.2 advertised-routes
BGP table version is 17, local router ID is 10.255.0.1
...
     Network          Next Hop            Metric LocPrf Weight Path
 *>i  172.16.2.0/24    10.255.0.2               0    100      0 i
 *>i  192.0.2.0        10.255.0.2               0    100      0 65003 i
 *>i  203.0.113.0      10.255.0.2               0    100      0 65003 i

Total number of prefixes 3 

R1(config)# interface Loopback1
R1(config-if)# no shutdown

R1# show ip bgp 172.16.1.0/24
BGP routing table entry for 172.16.1.0/24, version 18
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1          2         
  Refresh Epoch 1
  Local
    0.0.0.0 from 0.0.0.0 (10.255.0.1)
      Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
      rx pathid: 0, tx pathid: 0x0
      Updated on Sep 17 2026 17:57:46 UTC

Loopback1 down, then up again: origination follows the route. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

When R1 originates the prefix and R3 still lacks it

Once the originator shows a sourced, local path and the peer still does not have the prefix, the network statement is doing its job and the cause is elsewhere:

  • Policy. An outbound prefix-list, route-map or AS-path filter on R1, or an inbound one on R3, drops the prefix without a log message. Compare advertised-routes on the sender with show ip bgp neighbors 10.0.13.1 routes on the receiver. A prefix that stays in the first and never turns up in the second was dropped on the way in.
  • Next hop. An iBGP peer keeps the eBGP next hop unless the sender sets next-hop-self, and a path whose next hop the receiver cannot reach is never used. See iBGP update-source and next-hop-self.
  • Best path. The receiver has the prefix but prefers another path, or already has the same prefix from a source with a lower administrative distance. See BGP best path selection.
  • iBGP split horizon. A router does not pass a prefix learned from one iBGP peer to another iBGP peer, so in a partial iBGP mesh the prefix stops one router short.

Frequently asked questions

Does the route for a BGP network statement have to be a connected interface?

No. Any route in the IP routing table counts, whether it is connected, static, OSPF or EIGRP, as long as the prefix and mask match exactly. BGP copies the next hop from that route, so a connected or Null0 route shows next hop 0.0.0.0, and an OSPF route shows the OSPF next hop, with the OSPF cost as the metric.

Why does the running config show my network statement without a mask?

IOS leaves out the mask keyword when the mask is the classful default for the address. network 172.16.0.0 means 172.16.0.0/16, and network 198.51.100.0 means 198.51.100.0/24. The statement still needs a route of exactly that length. Typing network 172.16.1.0 with no mask is stored as network 172.16.0.0, a /16.

Do I need to clear the BGP session after fixing a network statement?

No. As soon as the statement matches a route, BGP originates the prefix and sends the update to its peers. A soft clear is for inbound or outbound policy changes. A hard clear resets the session and drops every prefix it carries while the session comes back up.

Should I use a Null0 static route or aggregate-address to advertise a summary?

Both work. A network statement matched by a static route to Null0 stays advertised as long as the static route is configured. aggregate-address builds the summary from more specific prefixes already in the BGP table and withdraws it when the last one disappears. Its summary-only keyword also stops the more specific prefixes from being advertised.

Can one network statement advertise all the subnets inside it?

No. One network statement originates one prefix, and only while a route of exactly that length exists. To advertise several subnets, write one statement per subnet, or advertise a summary and decide whether to suppress the subnets beneath it.

Practice prefix origination

Originate prefixes on real Cisco IOS in CML, then get the config graded.

All BGP labs →

Keep reading

What grading looks like

This is what grading your config looks like

A sample result — 4 of 5 requirements met. This is exactly what you see the moment you submit.

bgp-lab-export.yaml — read 3 device configs

Score: 80% — Keep going (4 of 5 checks passed)

  • Passed: BGP process running as AS 65001 on R1
  • Passed: eBGP neighbor 10.0.13.2 in AS 65002
  • Passed: Session to 10.0.13.2 is Established
  • Passed: 172.16.1.0/24 originated by an exact match
  • Failed: next-hop-self toward the iBGP peer — missing on R2
Solution revealed

The full node-by-node answer key unlocks the moment you submit — so you see exactly what you missed.

Don't just read it — configure it

Reading is step one. Build BGP on real Cisco IOS and have your own config graded.

Create a free accountBGP Fundamentals labs