To announce an IP prefix with BGP, the Border Gateway Protocol, you need permission to announce the address space and a route the router can originate. An export policy must also allow that route to the intended peer. In FRRouting (FRR), the network statement identifies the prefix to originate; route availability and local and remote policies determine whether it is advertised and accepted.

A real Internet announcement also depends on the upstream accepting the prefix and origin autonomous system number, or ASN. A route in your local BGP table does not prove that the upstream accepted it, and an established session does not prove global reachability.

The configuration below illustrates IPv4 unicast origination in an isolated FRR 10.6 lab. It uses documentation addresses and ASNs, assumes the interfaces already exist, and presents expected checks rather than results from an executed test.

Agree on the Prefix and Origin before Configuring BGP

Start with the exact prefix, its prefix length, and the ASN that will originate it. Confirm that your organization is entitled to use the address block and that any separate holder has authorized the announcement. Copying a prefix from a registry lookup does not grant permission to route it.

The upstream needs to know which customer connection may announce that prefix. Ask which routing registry records it uses, whether it requires an authorization letter, and how it handles RPKI origin validation. An Internet Routing Registry, or IRR, route object describes a prefix and origin relationship. A Route Origin Authorization, or ROA, provides a signed authorization for an origin ASN and permitted prefix lengths within the Resource Public Key Infrastructure, or RPKI.

Keep these records consistent with the planned announcement. If the authorized origin differs from the ASN in the actual route, or the announced prefix is longer than the authorization allows, changing a local export filter will not correct the mismatch. Resolve the underlying routing information before enabling the announcement.

Obtain the upstream's accepted prefix lengths for the address family and service. A prefix that fits within your allocation may still be too specific for a particular upstream's policy. There is no configuration command that obligates every other network to accept it.

Check the Route That Supports Origination

The example assumes an active lab interface at 203.0.113.1/24, which supplies a connected route for 203.0.113.0/24. The peering link uses 192.0.2.2/30 locally and 192.0.2.1/30 on the lab neighbor. AS 64496 is the origin, and AS 64497 is the neighbor.

These address blocks and ASNs are reserved for documentation. They illustrate the relationships between a destination prefix, a peering subnet, and an origin ASN. They must not become a public Internet announcement.

Before adding BGP origination, inspect the route in the relevant routing instance. In FRR's vtysh command shell, the following commands identify the software build and the supporting route:

show version
show ip route 203.0.113.0/24

The route must represent the intended /24, rather than merely a default route or a route to one address inside the block. Keep the prefix length consistent across the route, network statement, export filter, and upstream authorization. In a deployment with separate virtual routing and forwarding instances, or VRFs, inspect the route table for that VRF instead of assuming that a route in the default instance is available everywhere.

FRR's network import check requires the underlying network to exist in the routing information base. Since FRR 7.4, both the traditional and datacenter profiles enable this check by default. The example enables the check explicitly so that its intent is clear.

Route Presence Does Not Prove Service Availability

An import check establishes route presence, not service health. A connected network can remain present while a server on that network is unavailable. Likewise, installing a discard route solely to satisfy origination can attract traffic that the router then drops.

A discard route can serve a deliberate aggregation design when usable more specific routes carry traffic to the actual destinations. Those more specific routes win forwarding decisions for the addresses they cover. If they disappear, the remaining discard route can continue supporting the aggregate announcement while discarding traffic, so the announcement condition must match the intended failure behavior.

Define a Narrow Export Policy before Opening the Session

For this lab, the intended export contains exactly one prefix. The neighbor supplies no incoming routes, so the import policy deliberately denies everything. This is an origination demonstration, not a complete Internet access configuration.

The following vtysh configuration applies to a new lab BGP instance with Zebra managing routing information and bgpd handling BGP. It keeps the neighbor administratively shut down while the policies and network statement are added. For an existing production instance, review the current configuration before planning changes to its peers or policies.

configure terminal
ip prefix-list ORIGIN-ONLY seq 10 permit 203.0.113.0/24
route-map LAB-EXPORT permit 10
 match ip address prefix-list ORIGIN-ONLY
exit
route-map LAB-IMPORT deny 10
exit
router bgp 64496
 bgp router-id 192.0.2.2
 bgp network import-check
 bgp ebgp-requires-policy
 no bgp default ipv4-unicast
 neighbor 192.0.2.1 remote-as 64497
 neighbor 192.0.2.1 shutdown
 address-family ipv4 unicast
  neighbor 192.0.2.1 activate
  neighbor 192.0.2.1 route-map LAB-IMPORT in
  neighbor 192.0.2.1 route-map LAB-EXPORT out
  network 203.0.113.0/24
 exit-address-family
exit
end

Check the Import and Export Restrictions

The prefix list has no length range, so it matches only 203.0.113.0/24. It does not authorize the /25s inside that block or any unrelated destination. The export route map permits that match and denies unmatched routes through its default behavior.

Keep the prefix list and route map names consistent. A broad permit entry added after the narrow match would change what the route map allows. Review the entire policy rather than treating the first correct line as proof that the remaining policy is restrictive.

The explicit eBGP policy requirement treats the two directions separately: no incoming filter means no routes are accepted, and no outgoing filter means no routes are advertised. The default depends on FRR's configuration profile, but an explicit setting can override it. Changing this setting on an existing session requires clearing that session, so include the reset in the change plan.

Do not add unrestricted redistribution of connected or static routes as a substitute for the intended network statement. That can place additional infrastructure routes into BGP. An export allowlist provides a separate restriction, but keeping origination narrow makes the announced set easier to understand.

Check Origination Separately from Advertisement

While the peer remains shut down, inspect the local BGP route, prefix list, and route map. These checks answer whether the intended route exists and whether the attached policy describes the intended export:

show bgp ipv4 unicast 203.0.113.0/24
show ip prefix-list ORIGIN-ONLY
show route-map LAB-EXPORT

If the BGP route is absent, check the supporting route and import check before adjusting neighbor filters. A route map attached to the wrong neighbor or address family will not control exports on the intended session. The running configuration should show both policy directions under IPv4 unicast.

After both lab routers are configured and the announcement is permitted, the neighbor can be enabled in router configuration mode with no neighbor 192.0.2.1 shutdown. The expected result depends on the neighbor having a matching session configuration and an import policy that accepts the documentation prefix within this isolated lab.

Once the BGP session is established, inspect it and its advertised routes:

show bgp ipv4 unicast summary
show bgp ipv4 unicast neighbors 192.0.2.1 advertised-routes

The advertised set should contain the intended /24 and no extra prefix. This output shows what the local router advertised to that neighbor. Inspect the receiving lab router separately to establish whether it accepted the route and can resolve its next hop.

Configuration entered through vtysh changes the running router settings. This example assumes that FRR uses its integrated configuration file. After the lab checks succeed, run write memory in vtysh and confirm that the configuration was saved successfully for the next startup.

Confirm What the Upstream and Remote Networks See

For an authorized public announcement using real assigned resources, ask the upstream to confirm the received prefix, accepted origin, and relevant export toward its other neighbors. Record the observation time and address family. A rejected update and an accepted route that the upstream does not export require different corrections.

A route collector or looking glass adds a remote view. Compare the observed prefix and origin ASN with the intended values, and examine the AS path rather than merely noting that some covering route exists. A collector sees routes supplied by its peers, so visibility there describes those observations rather than every network on the Internet.

If local export is correct but the immediate upstream rejects the route, investigate its authorization and prefix filters. If the upstream accepts and propagates it but one remote network lacks it, investigate that network's view and policies. Neither situation is resolved by permitting all routes on your own router.

Separately, check forwarding to an authorized destination in the announced block. An accepted BGP route can coexist with a missing internal route, blocked traffic, or an unavailable application. Preserve the exact prefix, origin, observation point, and time when recording evidence so that a later change can be compared with the same announcement.