Junos BGP Configuration Generator

Generate a Junos BGP peer group with import and export policy, prefix limits, MD5 authentication and the safety guards a transit session needs.

Config generator Juniper / Junos Runs in your browser

Result

Session

eBGP 65001 ↔ 64512

Peer

192.0.2.2

Prefix limit

1,000,000

teardown at 90%

Advertising

1 prefix

BGP session

set routing-options autonomous-system 65001
set protocols bgp group TRANSIT-A type external
set protocols bgp group TRANSIT-A local-address 192.0.2.1
set protocols bgp group TRANSIT-A peer-as 64512
set protocols bgp group TRANSIT-A neighbor 192.0.2.2
set protocols bgp group TRANSIT-A family inet unicast prefix-limit maximum 1000000
set protocols bgp group TRANSIT-A family inet unicast prefix-limit teardown 90 idle-timeout 10
set protocols bgp group TRANSIT-A import TRANSIT-A-IN
set protocols bgp group TRANSIT-A export TRANSIT-A-OUT

Policy (import and export)

set policy-options policy-statement TRANSIT-A-IN term reject-bogons from prefix-list BOGONS
set policy-options policy-statement TRANSIT-A-IN term reject-bogons then reject
set policy-options policy-statement TRANSIT-A-IN term accept-rest then accept
set policy-options policy-statement TRANSIT-A-OUT term own-1 from route-filter 203.0.113.0/24 exact
set policy-options policy-statement TRANSIT-A-OUT term own-1 then accept
set policy-options policy-statement TRANSIT-A-OUT term deny-rest then reject
set policy-options prefix-list OWN-PREFIXES 203.0.113.0/24

Verification

show bgp summary
show bgp neighbor 192.0.2.2
show route receive-protocol bgp 192.0.2.2
show route advertising-protocol bgp 192.0.2.2
show policy TRANSIT-A-OUT

Default deny on export

Junos rejects nothing by default on eBGP import but the export policy above ends in an explicit reject term. An eBGP session without a deny-by-default export policy is how transit customers accidentally become transit providers.

About Junos BGP Configuration Generator

Junos BGP is organised around groups: shared session properties in the group, individual peers as neighbours inside it. This generates a session with the guards a real peering session needs - prefix limits, explicit policy in both directions, and optional authentication.

RPKI and origin validation

Prefix lists protect against your peers; RPKI protects against everyone else. With validation configured against an RTR server, Junos marks routes valid, invalid or unknown, and policy can reject invalid origins outright — which is what stops a mis-originated prefix from being accepted at all. Publish ROAs for your own space too, so other networks can validate you. It is a modest configuration change with a disproportionate effect on the class of incident that takes prefixes offline globally.

Prefix limits are not optional

A misconfigured peer sending a full table into a session sized for a customer will exhaust memory and take the router down. prefix-limit maximum with teardown caps the damage: the session drops rather than the device. Set it to a small multiple of what the peer legitimately announces, not to the size of the global table.

Common use cases

Turning up a new transit or peering session with review-ready configuration.
Adding a customer BGP session with strict prefix filtering.
Standardising iBGP configuration across a fleet.

Edge cases and gotchas

Always commit confirmed when changing BGP on a device you reach through it.
Route filters use exact, orlonger, upto and through - the wrong keyword silently changes what is accepted.

Frequently asked questions

Why is my session stuck in Active?

TCP 179 is not establishing: check reachability to the peer address, the local-address matches what the peer expects, no filter blocks 179, and for eBGP that multihop is configured if there is more than one hop.

Do I need a cluster ID for iBGP?

Only on route reflectors. A plain iBGP full mesh needs no cluster ID, and setting one on a non-reflector changes loop-prevention behaviour.