11.4 BGP Configuration & Policy Implementation
Key Takeaways
Junos configures BGP under the [edit protocols bgp] hierarchy, organizing peering sessions into logical groups defined as internal or external.
The default Junos BGP routing policy accepts all valid routes from EBGP peers upon ingress, but exports eligible active BGP routes subject to protocol rules; an explicit export policy is needed to originate non-BGP local prefixes.
Outbound enterprise traffic is manipulated on ingress border routers by applying an import policy that assigns a higher Local Preference (then local-preference
<val>) to preferred ISP sessions.Inbound enterprise traffic is manipulated on egress border routers by applying an export policy that artificially lengthens the AS-Path via prepending (then as-path-prepend) or tunes MED (then metric
<val>).BGP Communities provide 32-bit tagging mechanisms defined under [edit policy-options community] to trigger routing policy actions, including well-known communities no-export and no-advertise.
BGP Configuration & Policy Implementation
Implementing BGP on Juniper Networks EX Series switches, MX Series routers, and SRX Series gateways centers on a modular, group-based configuration model under the [edit protocols bgp] hierarchy. Because BGP is fundamentally an administrative protocol, raw peering sessions without routing policies are rarely deployed in enterprise production.
Routing policies applied at BGP ingress (import) and egress (export) dictate which prefixes are accepted into inet.0, which internal subnets are advertised to external peers, and how path attributes are transformed to engineer symmetric, predictable traffic patterns.
1. Junos BGP Configuration Hierarchy
Junos requires all BGP peers to reside inside a group. The group container provides operational modularity, allowing shared parameters—such as session type, local AS, authentication, timers, and routing policies—to be defined once and inherited by all member neighbors.
[edit]
user@Router# show protocols bgp
group EBGP-UPSTREAM {
type external;
peer-as 64500;
import ISP-A-IMPORT;
export ENTERPRISE-EXPORT;
neighbor 198.51.100.2 {
description "Primary Link to ISP A";
}
}
group IBGP-CORE {
type internal;
local-address 10.255.0.1;
export NEXT-HOP-SELF;
neighbor 10.255.0.2 {
description "Core Router R2";
}
neighbor 10.255.0.3 {
description "Core Router R3";
}
}
Essential Configuration Parameters
type <internal | external>: Specifies whether the group operates as IBGP (internal) or EBGP (external). Junos validates thatpeer-asmatches the local AS for internal groups, and differs for external groups.local-as <asn>: Overrides the global router AS configured at[edit routing-options autonomous-system]. Used during AS migrations or multi-AS transitions.peer-as <asn>: Defines the remote neighbor's Autonomous System number. In EBGP, this can be set at the group level (if all peers share the AS) or customized per neighbor.local-address <ip>: Mandates the source IP address used for the TCP three-way handshake. Essential for IBGP peering over loopback (lo0.0) interfaces.
2. Default BGP Routing Policies in Junos
Understanding default policy behavior is vital for JNCIS-ENT exam success and enterprise operations. Junos applies distinct default import and export actions based on peering type:
+---------------------------------------------------------------------------------------------------+
| JUNOS DEFAULT BGP ROUTING POLICIES |
+-----------+-----------------------+---------------------------------------------------------------+
| Direction | Peering Session Type | Default Action & Operational Impact |
+-----------+-----------------------+---------------------------------------------------------------+
| Import | External BGP (EBGP) | ACCEPT ALL valid BGP routes into inet.0. |
+-----------+-----------------------+---------------------------------------------------------------+
| Import | Internal BGP (IBGP) | ACCEPT ALL valid BGP routes into inet.0. |
+-----------+-----------------------+---------------------------------------------------------------+
| Export | External BGP (EBGP) | Export eligible active BGP routes subject to protocol rules. |
| | | (Explicit export is needed for local direct/static/aggregate prefixes.)|
+-----------+-----------------------+---------------------------------------------------------------+
| Export | Internal BGP (IBGP) | RE-ADVERTISE all active BGP routes learned from EBGP. |
| | | SUPPRESS all routes learned from other IBGP peers (Split-Hz). |
+-----------+-----------------------+---------------------------------------------------------------+
Default export trap: A router with only direct/static routes may advertise nothing until an export policy permits them. A router that has learned active BGP routes can advertise those routes to another EBGP peer under the normal default policy. Apply explicit prefix allowlists and a final reject when the enterprise must not become transit between providers; a one-term policy accepting static routes does not automatically block other eligible BGP routes.
3. Engineering Outbound Traffic: Local Preference
In an enterprise multi-homed to two providers (ISP-A and ISP-B), outbound traffic engineering determines which egress link internal users take when accessing the Internet. Because BGP evaluates Local Preference early in the path selection algorithm (after eligibility and route preference), manipulating local-preference on import influences outbound forwarding among otherwise eligible paths; route preference and next-hop reachability still apply.
[edit policy-options]
user@Router# set policy-statement ISP-A-IN term PRIMARY from route-filter 0.0.0.0/0 exact
user@Router# set policy-statement ISP-A-IN term PRIMARY then local-preference 200
user@Router# set policy-statement ISP-A-IN term PRIMARY then accept
user@Router# set policy-statement ISP-B-IN term BACKUP from route-filter 0.0.0.0/0 exact
user@Router# set policy-statement ISP-B-IN term BACKUP then local-preference 100
user@Router# set policy-statement ISP-B-IN term BACKUP then accept
[edit protocols bgp]
user@Router# set group EBGP-ISP-A import ISP-A-IN
user@Router# set group EBGP-ISP-B import ISP-B-IN
When both default routes are distributed via IBGP throughout the enterprise, all internal routers compare Local Preference 200 (via ISP-A) against 100 (via ISP-B). The Local Preference comparison selects ISP-A, directing all outbound enterprise Internet traffic across the primary link.
4. Engineering Inbound Traffic: AS-Path Prepending & MED
Controlling how external Internet traffic enters an enterprise network is fundamentally more complex because external routers make their own independent routing decisions. Furthermore, traffic flows in the opposite direction of BGP route advertisements.
To influence remote autonomous systems, the enterprise modifies the path attributes attached to the routes it exports to upstream providers:
+---------------------------------------------------------------------------------------------------+
| INBOUND TRAFFIC ENGINEERING MECHANICS |
| |
| 1. AS-Path Prepending (Global Scope): |
| [Enterprise AS 65001] |
| | |
| +--- Export to Primary ISP-A: Prefix 198.51.100.0/24 AS-Path: [65001] |
| | |
| +--- Export to Backup ISP-B: Prefix 198.51.100.0/24 AS-Path: [65001 65001 65001 65001]|
| |
| Result: Global Internet routers observe Path A has length 1, while Path B has length 4. |
| Internet traffic enters the enterprise via Primary ISP-A. |
| |
| 2. Multi-Exit Discriminator (MED) Manipulation (Local Neighbor AS Scope): |
| [Enterprise AS 65001] |
| | |
| +--- Export over Link 1 to ISP: Prefix 198.51.100.0/24 MED: 50 (Preferred) |
| | |
| +--- Export over Link 2 to ISP: Prefix 198.51.100.0/24 MED: 100 (Backup) |
| |
| Result: The single upstream ISP compares MED values and forwards inbound traffic on Link 1. |
+---------------------------------------------------------------------------------------------------+
Junos AS-Path Prepending Policy Configuration
To make the backup ISP-B path appear artificially longer and less attractive to the global Internet, the enterprise prepends its own Autonomous System number multiple times in an egress policy:
[edit policy-options]
user@Router# set policy-statement ADVERTISE-BACKUP term PREPEND-ENTERPRISE from route-filter 198.51.100.0/24 exact
user@Router# set policy-statement ADVERTISE-BACKUP term PREPEND-ENTERPRISE then as-path-prepend "65001 65001 65001"
user@Router# set policy-statement ADVERTISE-BACKUP term PREPEND-ENTERPRISE then accept
[edit protocols bgp group EBGP-ISP-B]
user@Router# set export ADVERTISE-BACKUP
Best Practice Rule: Only prepend your own local Autonomous System number. Prepending another entity's ASN can trigger upstream BGP loop detection filters or unintended path filtering, causing upstream providers to blackhole the prefix.
MED Manipulation Configuration
When dual links connect to the same single ISP, setting MED (the metric attribute) can influence link selection, subject to earlier attributes and the neighbor’s policy without cluttering the global AS-Path:
[edit policy-options policy-statement ADVERTISE-PRIMARY term SET-MED]
set from route-filter 198.51.100.0/24 exact
set then metric 50
set then accept
[edit policy-options policy-statement ADVERTISE-SECONDARY term SET-MED]
set from route-filter 198.51.100.0/24 exact
set then metric 100
set then accept
5. BGP Communities & Policy Tagging
A BGP Community is a 32-bit transitive optional attribute used to tag routes with administrative metadata. Standard communities are formatted as two 16-bit decimal integers in ASN:value syntax (e.g., 65001:100).
Well-Known Standard Communities (RFC 1997)
no-export(0xFFFFFF01/65535:65281): Do not advertise the route outside the local Autonomous System (or outside a BGP confederation). Routes are shared across IBGP peers but dropped before exiting any EBGP boundary.no-advertise(0xFFFFFF02/65535:65282): Do not advertise the route to any BGP peer (neither EBGP nor IBGP). The route remains strictly local to the receiving router.no-export-subconfed(0xFFFFFF03/65535:65283): Do not advertise the route outside the local confederation sub-AS.
Junos Community Definition & Application
Communities are defined under [edit policy-options community] using regular expressions or explicit string literals:
[edit policy-options]
user@Router# set community PRIMARY-COMM members 65001:100
user@Router# set community NO-EXPORT-COMM members no-export
user@Router# set policy-statement TAG-ROUTES term COMMUNITY-SET from route-filter 10.50.0.0/16 exact
user@Router# set policy-statement TAG-ROUTES term COMMUNITY-SET then community add [ PRIMARY-COMM NO-EXPORT-COMM ]
user@Router# set policy-statement TAG-ROUTES term COMMUNITY-SET then accept
In Junos policies, the community action supports three modifiers:
community add: Appends the specified community to existing communities already attached to the route.community set: Overwrites and replaces all existing communities with the specified community.community delete: Removes matching communities from the route's attribute list.
What is the default routing policy behavior in Junos OS for prefixes exported to an External BGP (EBGP) neighbor?
Eligible active BGP routes can be advertised subject to protocol rules; originating direct/static routes requires an explicit export policy.
All direct interface and static routes are automatically advertised to the EBGP peer
All active routes present in inet.0 with an IGP origin are automatically exported
All routes learned via IBGP are re-advertised to the EBGP peer with a reset next-hop address
An enterprise engineer must configure an egress routing policy toward a secondary Internet provider to make the secondary inbound path less attractive under normal operations. Which export action can influence remote path selection, subject to the providers’ policies?
Apply an import policy setting local-preference 50 on the secondary EBGP group
Configure an export policy applying 'then metric 0' toward the secondary provider
Configure an import policy tagging all secondary routes with community no-advertise
Apply an export policy toward the secondary provider utilizing 'then as-path-prepend' with the local ASN
When an enterprise router attaches the well-known BGP community 'no-export' to an internal prefix, how do downstream BGP routers handle the route?
The route is discarded immediately by all receiving routers and not installed into any routing table
The route is propagated across internal IBGP peers but suppressed from being advertised to any EBGP peer outside the AS
The route is exported exclusively to EBGP peers and blocked from being distributed across IBGP sessions
The route is converted into an Incomplete origin route and stripped of its AS-Path attribute
Sections you finish are checked off in the contents.