Supported Platforms
Related Documentation
- ACX, J, M, MX, SRX Series
- Understanding External BGP Peering Sessions
- BGP Configuration Overview
Example: Configuring Route Authentication for BGP
All BGP protocol exchanges can be authenticated to guarantee that only trusted routing devices participate in autonomous system (AS) routing updates. By default, authentication is disabled.
Requirements
Before you begin:
- Configure the router interfaces.
- Configure an interior gateway protocol (IGP).
Overview
When you configure authentication, the algorithm creates an encoded checksum that is included in the transmitted packet. The receiving routing device uses an authentication key (password) to verify the packet’s checksum.
This example includes the following statements for configuring and applying the keychain:
- key—A keychain can have multiple keys.
Each key within a keychain must be identified by a unique integer
value. The range of valid identifier values is from 0 through 63.
The key can be up to 126 characters long. Characters can include any ASCII strings. If you include spaces, enclose all characters in quotation marks (“ ”).
- tolerance—(Optional) For each keychain, you can configure a clock-skew tolerance value in seconds. The clock-skew tolerance is applicable to the receiver accepting keys for BGP updates. The configurable range is 0 through 999,999,999 seconds. During the tolerance period, either the current or previous password is acceptable.
- key-chain—For each keychain, you must specify a name. This example defines one keychain: bgp-auth. You can have multiple keychains on a routing device. For example, you can have a keychain for BGP, a keychain for OSPF, and a keychain for LDP.
- secret—For each key in the keychain, you must set a secret password. This password can be entered in either encrypted or plain text format in the secret statement. It is always displayed in encrypted format.
- start-time—Each key must specify a start time in UTC format. Control gets passed from one key to the next. When a configured start time arrives (based on the routing device’s clock), the key with that start time becomes active. Start times are specified in the local time zone for a routing device and must be unique within the keychain.
- authentication-key-chain—Enables you to apply a keychain at the global BGP level for all peers, for a group, or for a neighbor. This example applies the keychain to the peers defined in the external BGP (EBGP) group called ext.
- authentication-algorithm—For each keychain,
you can specify a hashing algorithm. The algorithm can be AES-128,
MD5, or SHA-1.
You associate a keychain and an authentication algorithm with a BGP neighboring session.
This example configures a keychain named bgp-auth. Key 0 will be sent and accepted starting at 2011-6-23.20:19:33 -0700, and will stop being sent and accepted when the next key in the keychain (key 1) becomes active. Key 1 becomes active one year later at 2012-6-23.20:19:33 -0700, and will not stop being sent and accepted unless another key is configured with a start time that is later than the start time of key 1. A clock-skew tolerance of 30 seconds applies to the receiver accepting the keys. During the tolerance period, either the current or previous key is acceptable. The keys are shared-secret passwords. This means that the neighbors receiving the authenticated routing updates must have the same authentication keychain configuration, including the same keys (passwords). So Router R0 and Router R1 must have the same authentication-key-chain configuration if they are configured as peers. This example shows the configuration on only one of the routing devices.
Topology Diagram
Figure 1 shows the topology used in this example.
Figure 1: Authentication for BGP

Configuration
CLI Quick Configuration
To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.
Step-by-Step Procedure
The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure Router R1 to accept route filters from Device CE1 and perform outbound route filtering using the received filters:
- Configure the local autonomous system.[edit routing-options]user@R1# set autonomous-system 65533
- Configure one or more BGP groups.[edit protocols bgp group ext]user@R1# set type externaluser@R1# set peer-as 65530 user@R1# set neighbor 172.16.2.1
- Configure authentication with multiple keys.[edit security authentication-key-chains key-chain bgp-auth]user@R1# set key 0 secret this-is-the-secret-passworduser@R1# set key 0 start-time 2011-6-23.20:19:33-0700user@R1# set key 1 secret this-is-another-secret-passworduser@R1# set key 1 start-time 2012-6-23.20:19:33-0700
The start time of each key must be unique within the keychain.
- Apply the authentication keychain to BGP, and set the
hashing algorithm.[edit protocols bgp group ext]user@R1# set authentication-key-chain bgp-auth user@R1# set authentication-algorithm md5
- (Optional) Apply a clock-skew tolerance value in seconds.[edit security authentication-key-chains key-chain bgp-auth]user@R1# set tolerance 30
Results
From configuration mode, confirm your configuration by entering the show protocols, show routing-options, and show security commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
If you are done configuring the device, enter commit from configuration mode.
Repeat the procedure for every BGP-enabled device in the network, using the appropriate interface names and addresses for each BGP-enabled device.
Verification
Confirm that the configuration is working properly.
- Verifying Authentication for the Neighbor
- Verifying That Authorization Messages Are Sent
- Checking Authentication Errors
- Verifying the Operation of the Keychain
Verifying Authentication for the Neighbor
Purpose
Make sure that the AutheKeyChain option appears in the output of the show bgp neighbor command.
Action
From operational mode, enter the show bgp neighbor command.
user@R1> show bgp neighbor
Peer: 172.16.2.1+179 AS 65530 Local: 172.16.2.2+1222 AS 65533 Type: External State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ direct-lo0 ] Options: <Preference PeerAS Refresh> Options: <AutheKeyChain> Authentication key is configured Authentication key chain: jni Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 172.16.2.1 Local ID: 10.255.124.35 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 Local Interface: fe-0/0/1.0 NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 2 Received prefixes: 2 Suppressed due to damping: 0 Advertised prefixes: 1 Last traffic (seconds): Received 2 Sent 2 Checked 2 Input messages: Total 21 Updates 2 Refreshes 0 Octets 477 Output messages: Total 22 Updates 1 Refreshes 0 Octets 471 Output Queue[0]: 0
Verifying That Authorization Messages Are Sent
Purpose
Confirm that BGP has the enhanced authorization option.
Action
From operational mode, enter the monitor traffic interface fe-0/0/1 command.
user@R1> monitor traffic interface fe-0/0/1
verbose output suppressed, use <detail> or <extensive> for full protocol decode Listening on fe-0/0/1, capture size 96 bytes 13:08:00.618402 In arp who-has 172.16.2.66 tell 172.16.2.69 13:08:02.408249 Out IP 172.16.2.2.1122 > 172.16.2.1.646: P 1889289217:1889289235(18) ack 2215740969 win 58486 <nop,nop,timestamp 167557 1465469,nop,Enhanced Auth keyid 0 diglen 12 digest: fe3366001f45767165f17037>: 13:08:02.418396 In IP 172.16.2.1.646 > 172.16.2.2.1122: P 1:19(18) ack 18 win 57100 <nop,nop,timestamp 1466460 167557,nop,Enhanced Auth keyid 0 diglen 12 digest: a18c31eda1b14b2900921675>: 13:08:02.518146 Out IP 172.16.2.2.1122 > 172.16.2.1.646: . ack 19 win 58468 <nop,nop,timestamp 167568 1466460,nop,Enhanced Auth keyid 0 diglen 12 digest: c3b6422eb6bd3fd9cf79742b> 13:08:28.199557 Out IP 172.16.2.2.nerv > 172.16.2.1.bgp: P 286842489:286842508(19) ack 931203976 win 57200 <nop,Enhanced Auth keyid 0 diglen 12 digest: fc0e42900a73736bcc07c1a4>: BGP, length: 19 13:08:28.209661 In IP 172.16.2.1.bgp > 172.16.2.2.nerv: P 1:20(19) ack 19 win 56835 <nop,Enhanced Auth keyid 0 diglen 12 digest: 0fc8578c489fabce63aeb2c3>: BGP, length: 19 13:08:28.309525 Out IP 172.16.2.2.nerv > 172.16.2.1.bgp: . ack 20 win 57181 <nop,Enhanced Auth keyid 0 diglen 12 digest: ef03f282fb2ece0039491df8> 13:08:32.439708 Out IP 172.16.2.2.1122 > 172.16.2.1.646: P 54:72(18) ack 55 win 58432 <nop,nop,timestamp 170560 1468472,nop,Enhanced Auth keyid 0 diglen 12 digest: 76e0cf926f348b726c631944>: 13:08:32.449795 In IP 172.16.2.1.646 > 172.16.2.2.1122: P 55:73(18) ack 72 win 57046 <nop,nop,timestamp 1469463 170560,nop,Enhanced Auth keyid 0 diglen 12 digest: dae3eec390d18a114431f4d8>: 13:08:32.549726 Out IP 172.16.2.2.1122 > 172.16.2.1.646: . ack 73 win 58414 <nop,nop,timestamp 170571 1469463,nop,Enhanced Auth keyid 0 diglen 12 digest: 851df771aee2ea7a43a0c46c> 13:08:33.719880 In arp who-has 172.16.2.66 tell 172.16.2.69 ^C 35 packets received by filter 0 packets dropped by kernel
Checking Authentication Errors
Purpose
Check the number of packets dropped by TCP because of authentication errors.
Action
From operational mode, enter the show system statistics tcp | match auth command.
user@R1> show system statistics tcp | match
auth
0 send packets dropped by TCP due to auth errors 58 rcv packets dropped by TCP due to auth errors
Verifying the Operation of the Keychain
Purpose
Check the number of packets dropped by TCP because of authentication errors.
Action
From operational mode, enter the show security keychain detail command.
user@R1> show security keychain detail
keychain Active-ID Next-ID Transition Tolerance Send Receive Send Receive bgp-auth 3 3 1 1 1d 23:58 30 Id 3, Algorithm hmac-md5, State send-receive, Option basic Start-time Wed Aug 11 16:28:00 2010, Mode send-receive Id 1, Algorithm hmac-md5, State inactive, Option basic Start-time Fri Aug 20 11:30:57 2010, Mode send-receive
Related Documentation
- ACX, J, M, MX, SRX Series
- Understanding External BGP Peering Sessions
- BGP Configuration Overview
Published: 2014-07-23
Supported Platforms
Related Documentation
- ACX, J, M, MX, SRX Series
- Understanding External BGP Peering Sessions
- BGP Configuration Overview