How to Advertise Network in BGP Juniper?

Advertising networks via BGP (Border Gateway Protocol) on Juniper’s Junos OS requires defining which prefixes you want to share with your peers and then applying export policies to your BGP groups. Unlike some platforms where you simply use a network statement under the BGP process, Junos OS leverages its powerful policy-options framework to control route advertisement. In the simplest form, you will:

1. Ensure the route you want to advertise exists in your local routing table (via IGP, static route, or directly connected).
2. Create a routing policy under policy-options that matches the desired prefix(es).
3. Apply that policy as an export policy to your BGP group.

Once configured, Junos OS evaluates that policy for every BGP neighbor and advertises only the prefixes that your policy permits.

1. Why Junos Uses Export Policies

Junos OS separates route import (which determines what you learn from BGP) from route export (which controls what you send). This separation allows granular control over advertisement, enabling features such as:

• Selective advertisement based on prefix, protocol, or route attributes.
• Attribute manipulation, such as setting communities or MED on advertised routes.
• Advanced filtering, including suppressing inactive or peer-AS routes.

By contrast, the default BGP behavior in many routers is “advertise every BGP-learned route” unless explicitly filtered. Junos’s policy-based approach aligns with modern network-wide standardization on route policies.

2. Prerequisites

Before you advertise any network:

• Ensure the prefix exists locally. It can be a static route (routing-options static), a direct interface address, or learned via an Interior Gateway Protocol (OSPF, IS-IS, etc.).
• Configure your BGP group and neighbors. At minimum, you must have set protocols bgp group <name> neighbor <IP> peer-as <ASN>.
• Choose an AS number and routing instance. Most deployments use the default routing instance, but VRFs are also supported.

3. Basic Configuration Example

Suppose you want to advertise your internal network 10.1.0.0/24 to your eBGP neighbor at 203.0.113.2/30, AS 65002. Here’s how:

3.1. Ensure the Route Is Installed

shell
set routing-options static route 10.1.0.0/24 next-hop 192.0.2.1
set routing-options static route 10.1.0.0/24 install

This places the prefix into inet.0, making it a candidate for BGP advertisement.

3.2. Create an Export Policy

shell
set policy-options policy-statement EXPORT-10-1-0-0 term ADVERTISE-10-1-0-0 from route-filter 10.1.0.0/24 exact
set policy-options policy-statement EXPORT-10-1-0-0 term ADVERTISE-10-1-0-0 then accept
set policy-options policy-statement EXPORT-10-1-0-0 term REJECT-OTHERS then reject

• Route-filter matches only exactly 10.1.0.0/24.
• Then accept tells Junos to advertise it.
• The final term rejects all other prefixes, ensuring no unintended routes are sent.

3.3. Apply the Export Policy to the BGP Group

shell
set protocols bgp group EBGP-PEER type external
set protocols bgp group EBGP-PEER neighbor 203.0.113.2 peer-as 65002
set protocols bgp group EBGP-PEER export EXPORT-10-1-0-0
set routing-options autonomous-system 65001

After committing, Junos advertises only 10.1.0.0/24 to the peer.

4. Advertising Inactive or “Hidden” Routes

By default, BGP advertises only active routes—the best path installed in the routing table. If a route learned via BGP is made inactive by a more preferred static or IGP route, it won’t be advertised further. To override this behavior, use the advertise-inactive statement on your BGP group:

shell
set protocols bgp group EBGP-PEER advertise-inactive

This forces Junos to advertise BGP‐learned prefixes even if they are not the active path locally.

You can also match these inactive advertisements in your export policy:

shell
set policy-options policy-statement EXPORT-INACTIVE term MARK-INACTIVE from state inactive
set policy-options policy-statement EXPORT-INACTIVE term MARK-INACTIVE then community set INACTIVE-COMM
set policy-options policy-statement EXPORT-INACTIVE term ACCEPT-ALL from protocol bgp
set policy-options policy-statement EXPORT-INACTIVE term ACCEPT-ALL then accept
set community INACTIVE-COMM members 65001:999

This approach lets downstream routers identify and optionally filter routes that were inactive on the sender.

5. Advertising Routes Learned from the Same AS (“Advertise Peer AS”)

When you have two eBGP peers in the same AS—common in hub-and-spoke designs—Juniper suppresses route reflection to avoid loops. To explicitly advertise routes learned from one peer to another within the same AS, enable:

shell
set protocols bgp group EBGP-PEER advertise-peer-as

This overrides the default suppression and allows R2 in AS 65000 to forward R1’s routes back to R3 (also AS 65000). Remember to configure family inet unicast loops 2 on the siblings so they accept routes containing their own AS in the AS path.

6. Controlling Advertisement with Routing Instances and RIB Groups

In complex environments—such as VRFs or route‐reflector topologies—you may need distinct export rules per routing instance or share RIBs across instances:

• Routing Instances: Under [edit routing-instances NAME protocols bgp], you can define instance-specific groups and export policies.
• RIB Groups: Share a route table across instances, then selectively export into BGP sessions from each instance.

These advanced constructs ensure your policies remain modular and clear, even in multi-tenant or segmented networks.

7. Verifying Your Advertisements

After committing your configuration, validate what you’re sending:

• Show the export policy result Lists all prefixes you’re advertising.

shell
show route advertising-protocol bgp 203.0.113.2 

• Check policy matches Confirms which terms matched and the actions taken.

shell
show policy-options policy-statement EXPORT-10-1-0-0 detail 

• Inspect BGP summary Ensures the peer is established and prefixes are being exchanged.

shell
show bgp summary 

8. Common Pitfalls and Best Practices

• Missing “install” on static routes: Without install, the route never reaches inet.0 and can’t be advertised.
• Over-permissive policies: A default then accept without a reject term can unintentionally advertise your entire table.
• Neglecting inactive routes: If you rely on backup BGP paths, remember to set advertise-inactive.
• Loop prevention: When enabling advertise-peer-as, always include family inet unicast loops 2 on the original AS peers to accept paths containing their AS.
• Testing incrementally: Apply policies to a single neighbor first, verify behavior, then roll out network-wide.

9. Real-World Use Cases

1. Data Center to Cloud
   An enterprise advertises on-prem subnets to a cloud-based virtual router. Using export policies, they tag routes with communities for traffic engineering in transit.
2. Hub-and-Spoke MPLS
   A central hub advertises all customer VRF routes to spokes via eBGP in the same AS. advertise-peer-as ensures full mesh visibility without manual peering.
3. Backup Path Promotion
   When a primary IGP path fails, BGP-learned backup paths become active. With advertise-inactive, the hub still advertises those backups even before they switch to active.

Please follow and like us: