BGP Safe Policy Enforcement in IOS XE
Introduction
The role of BGP in backbone infrastructures is critical, as it is used to advertise hundreds of thousands of networks across the Internet. When establishing peering relationships, such as with an ISP, it is essential to ensure that both received and advertised routes comply with globally recognized best practices. Several initiatives have emerged to address this need, among which the Mutually Agreed Norms for Routing Security (MANRS) stands out as a community-driven effort aimed at implementing essential measures to reduce the most common routing security threats. A practical example of such measures involves associating inbound and outbound filters with each eBGP session, known as route policies, prefix lists, or distribute lists depending on the platform, to prevent bogon prefixes from being advertised or accepted.
With this context in mind, how can a BGP neighborship between two peers be secured from the very beginning? RFC 8212, published in July 2017, represents one of several efforts to tackle this challenge at the protocol level, updating the original RFC 4271. The RFC states the following.
How does this RFC requirement apply in practice? It mandates the explicit configuration of one or more routing policies that define which routes can be advertised and received on an eBGP session. On IOS XR, this requirement is enforced by default: whenever an eBGP session is configured, at least one routing policy must be applied in both the inbound and outbound directions before any route can be exchanged. On IOS XE, however, no such enforcement exists. As a result, an eBGP session with a remote peer is able to exchange route announcements in both directions immediately, even in the absence of explicitly defined routing policies.
Default IOS XE Behavior
The topology used throughout this post is shown in the figure below. R1 and R2 establish two eBGP sessions, with each router advertising a single IPv4 Unicast /16 network to its respective peer.
1R1#show running-config | s r b
2router bgp 65100
3 bgp log-neighbor-changes
4 neighbor 172.25.2.2 remote-as 65200
5 neighbor 172.25.2.2 transport multi-session
6 neighbor 172.25.2.2 disable-connected-check
7 neighbor 172.25.2.2 update-source Loopback0
8 !
9 address-family ipv4
10 network 10.10.0.0 mask 255.255.0.0
11 neighbor 172.25.2.2 activate
12 exit-address-family
13 !
14 address-family ipv6
15 neighbor 172.25.2.2 activate
16 exit-address-family1R2#show running-config | s r b
2router bgp 65200
3 bgp log-neighbor-changes
4 neighbor 172.25.1.1 remote-as 65100
5 neighbor 172.25.1.1 transport multi-session
6 neighbor 172.25.1.1 disable-connected-check
7 neighbor 172.25.1.1 update-source Loopback0
8 !
9 address-family ipv4
10 network 10.20.0.0 mask 255.255.0.0
11 neighbor 172.25.1.1 activate
12 exit-address-family
13 !
14 address-family ipv6
15 neighbor 172.25.1.1 activate
16 exit-address-familyFor reference, the following output shows all information for the two sessions between R1 and R2.
1R1#show ip bgp neighbors 172.25.2.2
2BGP neighbor is 172.25.2.2, remote AS 65200, external link
3 BGP version 4, remote router ID 172.25.2.2
4 Session state = Established, up for 00:00:34
5 Last read 00:00:34, last write 00:00:34, hold time is 180, keepalive interval is 60 seconds
6 BGP multisession with 2 sessions (2 established), first up for 00:00:34
7 Neighbor sessions:
8 2 active, is multisession capable
9 Neighbor capabilities:
10 Route refresh: advertised and received(new) on session 1, 2
11 Four-octets ASN Capability: advertised and received on session 1, 2
12 Address family IPv4 Unicast: advertised and received
13 Address family IPv6 Unicast: advertised and received
14 Enhanced Refresh Capability: advertised and received
15 Multisession Capability: advertised and received
16 Stateful switchover support enabled: NO for session 1, 2
17 Message statistics for 172.25.2.2 session 1, state Established:
18 InQ depth is 0
19 OutQ depth is 0
20
21 Sent Rcvd
22 Opens: 1 1
23 Notifications: 0 0
24 Updates: 2 2
25 Keepalives: 2 2
26 Route Refresh: 0 0
27 Total: 5 5
28 Message statistics for 172.25.2.2 session 2, state Established:
29 InQ depth is 0
30 OutQ depth is 0
31
32 Sent Rcvd
33 Opens: 1 1
34 Notifications: 0 0
35 Updates: 1 1
36 Keepalives: 2 2
37 Route Refresh: 0 0
38 Total: 4 4
39 Do log neighbor state changes (via global configuration)
40 Default minimum time between advertisement runs is 30 seconds
41
42 For address family: IPv4 Unicast
43 Session: 172.25.2.2 session 1
44 BGP table version 3, neighbor version 3/0
45 Output queue size : 0
46 Index 25, Advertise bit 0
47 session 1 member
48 25 update-group member
49 Slow-peer detection is disabled
50 Slow-peer split-update-group dynamic is disabled
51 Sent Rcvd
52 Prefix activity: ---- ----
53 Prefixes Current: 1 1 (Consumes 136 bytes)
54 Prefixes Total: 1 1
55 Implicit Withdraw: 0 0
56 Explicit Withdraw: 0 0
57 Used as bestpath: n/a 1
58 Used as multipath: n/a 0
59 Used as secondary: n/a 0
60
61 Outbound Inbound
62 Local Policy Denied Prefixes: -------- -------
63 Bestpath from this peer: 1 n/a
64 Total: 1 0
65 Number of NLRIs in the update sent: max 1, min 0
66 Current session network count peaked at 1 entries at 05:35:36 Apr 15 2026 UTC (00:00:34.841 ago)
67 Highest network count observed at 1 entries at 20:27:51 Apr 13 2026 UTC (1d09h ago)
68 Last detected as dynamic slow peer: never
69 Dynamic slow peer recovered: never
70 Refresh Epoch: 1
71 Last Sent Refresh Start-of-rib: never
72 Last Sent Refresh End-of-rib: never
73 Last Received Refresh Start-of-rib: never
74 Last Received Refresh End-of-rib: never
75 Sent Rcvd
76 Refresh activity: ---- ----
77 Refresh Start-of-RIB 0 0
78 Refresh End-of-RIB 0 0
79
80 For address family: IPv6 Unicast
81 Session: 172.25.2.2 session 2
82 BGP table version 1, neighbor version 1/0
83 Output queue size : 0
84 Index 22, Advertise bit 0
85 session 2 member
86 22 update-group member
87 Slow-peer detection is disabled
88 Slow-peer split-update-group dynamic is disabled
89 Sent Rcvd
90 Prefix activity: ---- ----
91 Prefixes Current: 0 0
92 Prefixes Total: 0 0
93 Implicit Withdraw: 0 0
94 Explicit Withdraw: 0 0
95 Used as bestpath: n/a 0
96 Used as multipath: n/a 0
97 Used as secondary: n/a 0
98
99 Outbound Inbound
100 Local Policy Denied Prefixes: -------- -------
101 Total: 0 0
102 Number of NLRIs in the update sent: max 0, min 0
103 Last detected as dynamic slow peer: never
104 Dynamic slow peer recovered: never
105 Refresh Epoch: 1
106 Last Sent Refresh Start-of-rib: never
107 Last Sent Refresh End-of-rib: never
108 Last Received Refresh Start-of-rib: never
109 Last Received Refresh End-of-rib: never
110 Sent Rcvd
111 Refresh activity: ---- ----
112 Refresh Start-of-RIB 0 0
113 Refresh End-of-RIB 0 0
114
115 Address tracking is enabled, the RIB does have a route to 172.25.2.2
116 Route to peer address reachability Up: 1; Down: 0
117 Last notification 2w1d
118 Connections established 47; dropped 45
119 Last reset 00:17:35, due to Active open failed
120 External BGP neighbor not directly connected.
121 External BGP neighbor NOT configured for connected checks (single-hop disable-connected-check)
122 Interface associated: (none) (peering address NOT in same link)
123 Transport(tcp) path-mtu-discovery is enabled
124 Graceful-Restart is disabled
125 SSO is disabled
126Connection state is ESTAB, I/O status: 1, unread input bytes: 0
127Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
128Local host: 172.25.1.1, Local port: 179
129Foreign host: 172.25.2.2, Foreign port: 22611
130Connection tableid (VRF): 0
131Maximum output segment queue size: 50
132
133Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
134
135Event Timers (current time is 0x52251B77):
136Timer Starts Wakeups Next
137Retrans 3 0 0x0
138TimeWait 0 0 0x0
139AckHold 3 0 0x0
140SendWnd 0 0 0x0
141KeepAlive 0 0 0x0
142GiveUp 0 0 0x0
143PmtuAger 0 0 0x0
144DeadWait 0 0 0x0
145Linger 0 0 0x0
146ProcessQ 0 0 0x0
147
148iss: 4111509163 snduna: 4111509340 sndnxt: 4111509340
149irs: 2337700024 rcvnxt: 2337700201
150
151sndwnd: 16208 scale: 0 maxrcvwnd: 16384
152rcvwnd: 16208 scale: 0 delrcvwnd: 176
153
154SRTT: 330 ms, RTTO: 3159 ms, RTV: 2829 ms, KRTT: 0 ms
155minRTT: 3 ms, maxRTT: 1000 ms, ACK hold: 200 ms
156uptime: 34565 ms, Sent idletime: 34542 ms, Receive idletime: 34537 ms
157Status Flags: passive open, gen tcbs
158Option Flags: nagle, path mtu capable
159IP Precedence value : 6
160
161Datagrams (max data segment is 1460 bytes):
162Rcvd: 8 (out of order: 0), with data: 4, total data bytes: 176
163Sent: 7 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 4, total data bytes: 176
164
165 Packets received in fast path: 0, fast processed: 0, slow path: 0
166 fast lock acquisition failures: 0, slow path: 0
167TCP Semaphore 0x7F840CD6B148 FREEThe following output confirms that R1 has received the network announced by R2.
1R1#show bgp ipv4 unicast summary
2BGP router identifier 172.25.1.1, local AS number 65100
3BGP table version is 3, main routing table version 3
42 network entries using 496 bytes of memory
52 path entries using 272 bytes of memory
62/2 BGP path/bestpath attribute entries using 576 bytes of memory
71 BGP AS-PATH entries using 24 bytes of memory
80 BGP route-map cache entries using 0 bytes of memory
90 BGP filter-list cache entries using 0 bytes of memory
10BGP using 1368 total bytes of memory
11BGP activity 50/48 prefixes, 51/49 paths, scan interval 60 secs
123 networks peaked at 16:22:19 Apr 11 2026 UTC (3d13h ago)
13
14Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
15172.25.2.2 4 65200 6 6 3 0 0 00:01:12 1The announcement in question is detailed in the following output.
1R1#show bgp ipv4 unicast neighbors 172.25.2.2 routes
2BGP table version is 3, local router ID is 172.25.1.1
3Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
4 r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
5 x best-external, a additional-path, c RIB-compressed,
6 t secondary path, L long-lived-stale,
7Origin codes: i - IGP, e - EGP, ? - incomplete
8RPKI validation codes: V valid, I invalid, N Not found
9
10 Network Next Hop Metric LocPrf Weight Path
11 *> 10.20.0.0/16 172.25.2.2 0 0 65200 i
12
13Total number of prefixes 1Similarly, it is possible to see that R1 advertises the 10.10.0.0/16 network to peer R2.
1R1#show bgp ipv4 unicast neighbors 172.25.2.2 advertised-routes
2BGP table version is 3, local router ID is 172.25.1.1
3Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
4 r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
5 x best-external, a additional-path, c RIB-compressed,
6 t secondary path, L long-lived-stale,
7Origin codes: i - IGP, e - EGP, ? - incomplete
8RPKI validation codes: V valid, I invalid, N Not found
9
10 Network Next Hop Metric LocPrf Weight Path
11 *> 10.10.0.0/16 0.0.0.0 0 32768 i
12
13Total number of prefixes 1The route received by R1 is then installed into the RIB.
1R1#show ip route bgp
2Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
3 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
4 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
5 E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
6 n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
7 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
8 ia - IS-IS inter area, * - candidate default, U - per-user static route
9 H - NHRP, G - NHRP registered, g - NHRP registration summary
10 o - ODR, P - periodic downloaded static route, l - LISP
11 a - application route
12 + - replicated route, % - next hop override, p - overrides from PfR
13 & - replicated local route overrides by connected
14
15Gateway of last resort is not set
16
17 10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks
18B 10.20.0.0/16 [20/0] via 172.25.2.2, 00:02:33Securing eBGP Sessions in IOS XE
How can IOS XE behavior be aligned with IOS XR? In IOS XE release 17.2.1 (whose Last Date of Support was January 31, 2026) and later, a new command was introduced in BGP configuration mode: bgp safe-ebgp-policy.
The effects of enabling this command are examined below using the topology shown in the previous section. Two scenarios can be considered:
- In the first scenario, the command is applied after the BGP session between the two peers has already been established
- In the second scenario, it is applied before the session is established
Scenario 1: Securing an Already Established eBGP Session
With both sessions in the Established state, the new command introduced earlier is applied to the configuration of router R1, and the results are analyzed. The same considerations would apply if the command were also configured on R2.
1R1(config-router)#bgp safe-ebgp-policyOnce applied, this command triggers the generation of BGP messages to all active peers. Since two address families (IPv4 and IPv6 unicast) are configured, these messages are processed for both sessions. The session state information between R1 and R2 is examined step by step in the following output, showing the result of the show ip bgp neighbors <remote-peer-IP> command executed on R1.
1R1#show ip bgp neighbors 172.25.2.2
2BGP neighbor is 172.25.2.2, remote AS 65200, external link
3 BGP version 4, remote router ID 172.25.2.2
4 Session state = Established, up for 00:05:58
5 Last read 00:00:46, last write 00:00:46, hold time is 180, keepalive interval is 60 seconds
6 BGP multisession with 2 sessions (2 established), first up for 00:05:58
7 Neighbor sessions:
8 2 active, is multisession capable
9 Session: 172.25.2.2 session 1
10 Topology IPv4 Unicast
11 Session: 172.25.2.2 session 2
12 Topology IPv6 Unicast
13 Neighbor capabilities:
14 Route refresh: advertised and received(new) on session 1, 2
15 Four-octets ASN Capability: advertised and received on session 1, 2
16 Address family IPv4 Unicast: advertised and received
17 Address family IPv6 Unicast: advertised and received
18 Enhanced Refresh Capability: advertised and received
19 Multisession Capability: advertised and received
20 Stateful switchover support enabled: NO for session 1, 2
21 Message statistics for 172.25.2.2 session 1, state Established:
22 InQ depth is 0
23 OutQ depth is 0
24
25 Sent Rcvd
26 Opens: 1 1
27 Notifications: 0 0
28 Updates: 3 3
29 Keepalives: 7 7
30 Route Refresh: 1 0
31 Total: 14 13
32 Message statistics for 172.25.2.2 session 2, state Established:
33 InQ depth is 0
34 OutQ depth is 0
35
36 Sent Rcvd
37 Opens: 1 1
38 Notifications: 0 0
39 Updates: 1 1
40 Keepalives: 7 7
41 Route Refresh: 1 0
42 Total: 12 11
43 Do log neighbor state changes (via global configuration)
44 Default minimum time between advertisement runs is 30 seconds
45
46 For address family: IPv4 Unicast
47 Session: 172.25.2.2 session 1
48 BGP table version 4, neighbor version 4/0
49 Output queue size : 0
50 Index 25, Advertise bit 0
51 session 1 member
52 25 update-group member
53 Suppressing inbound/outbound propagation because policies are missing
54 Slow-peer detection is disabled
55 Slow-peer split-update-group dynamic is disabled
56 Sent Rcvd
57 Prefix activity: ---- ----
58 Prefixes Current: 0 0
59 Prefixes Total: 1 1
60 Implicit Withdraw: 0 1
61 Explicit Withdraw: 0 0
62 Used as bestpath: n/a 0
63 Used as multipath: n/a 0
64 Used as secondary: n/a 0
65
66 Outbound Inbound
67 Local Policy Denied Prefixes: -------- -------
68 safe-ebgp-policy: 3 1
69 Bestpath from this peer: 1 n/a
70 Total: 4 1
71 Number of NLRIs in the update sent: max 1, min 0
72 Current session network count peaked at 1 entries at 05:35:36 Apr 15 2026 UTC (00:05:59.065 ago)
73 Highest network count observed at 1 entries at 20:27:51 Apr 13 2026 UTC (1d09h ago)
74 Last detected as dynamic slow peer: never
75 Dynamic slow peer recovered: never
76 Refresh Epoch: 2
77 Last Sent Refresh Start-of-rib: 00:01:16
78 Last Sent Refresh End-of-rib: 00:01:16
79 Refresh-Out took 0 seconds
80 Last Received Refresh Start-of-rib: 00:00:46
81 Last Received Refresh End-of-rib: 00:00:46
82 Refresh-In took 0 seconds
83 Sent Rcvd
84 Refresh activity: ---- ----
85 Refresh Start-of-RIB 1 1
86 Refresh End-of-RIB 1 1
87
88 For address family: IPv6 Unicast
89 Session: 172.25.2.2 session 2
90 BGP table version 1, neighbor version 1/0
91 Output queue size : 0
92 Index 22, Advertise bit 0
93 session 2 member
94 22 update-group member
95 Suppressing inbound/outbound propagation because policies are missing
96 Slow-peer detection is disabled
97 Slow-peer split-update-group dynamic is disabled
98 Sent Rcvd
99 Prefix activity: ---- ----
100 Prefixes Current: 0 0
101 Prefixes Total: 0 0
102 Implicit Withdraw: 0 0
103 Explicit Withdraw: 0 0
104 Used as bestpath: n/a 0
105 Used as multipath: n/a 0
106 Used as secondary: n/a 0
107
108 Outbound Inbound
109 Local Policy Denied Prefixes: -------- -------
110 Total: 0 0
111 Number of NLRIs in the update sent: max 0, min 0
112 Last detected as dynamic slow peer: never
113 Dynamic slow peer recovered: never
114 Refresh Epoch: 2
115 Last Sent Refresh Start-of-rib: 00:01:16
116 Last Sent Refresh End-of-rib: 00:01:16
117 Refresh-Out took 0 seconds
118 Last Received Refresh Start-of-rib: 00:00:46
119 Last Received Refresh End-of-rib: 00:00:46
120 Refresh-In took 0 seconds
121 Sent Rcvd
122 Refresh activity: ---- ----
123 Refresh Start-of-RIB 1 1
124 Refresh End-of-RIB 1 1
125
126 Address tracking is enabled, the RIB does have a route to 172.25.2.2
127 Route to peer address reachability Up: 1; Down: 0
128 Last notification 2w1d
129 Connections established 47; dropped 45
130 Last reset 00:23:00, due to Active open failed
131 External BGP neighbor not directly connected.
132 External BGP neighbor NOT configured for connected checks (single-hop disable-connected-check)
133 Interface associated: (none) (peering address NOT in same link)
134 Transport(tcp) path-mtu-discovery is enabled
135 Graceful-Restart is disabled
136 SSO is disabled
137Connection state is ESTAB, I/O status: 1, unread input bytes: 0
138Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
139Local host: 172.25.1.1, Local port: 179
140Foreign host: 172.25.2.2, Foreign port: 22611
141Connection tableid (VRF): 0
142Maximum output segment queue size: 50
143
144Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
145
146Event Timers (current time is 0x522A0DF9):
147Timer Starts Wakeups Next
148Retrans 10 0 0x0
149TimeWait 0 0 0x0
150AckHold 9 5 0x0
151SendWnd 0 0 0x0
152KeepAlive 0 0 0x0
153GiveUp 0 0 0x0
154PmtuAger 0 0 0x0
155DeadWait 0 0 0x0
156Linger 0 0 0x0
157ProcessQ 0 0 0x0
158
159iss: 4111509163 snduna: 4111509530 sndnxt: 4111509530
160irs: 2337700024 rcvnxt: 2337700395
161
162sndwnd: 16018 scale: 0 maxrcvwnd: 16384
163rcvwnd: 16014 scale: 0 delrcvwnd: 370
164
165SRTT: 737 ms, RTTO: 2506 ms, RTV: 1769 ms, KRTT: 0 ms
166minRTT: 3 ms, maxRTT: 1000 ms, ACK hold: 200 ms
167uptime: 358791 ms, Sent idletime: 46232 ms, Receive idletime: 46232 ms
168Status Flags: passive open, gen tcbs
169Option Flags: nagle, path mtu capable
170IP Precedence value : 6
171
172Datagrams (max data segment is 1460 bytes):
173Rcvd: 21 (out of order: 0), with data: 11, total data bytes: 370
174Sent: 21 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 12, total data bytes: 366
175
176 Packets received in fast path: 0, fast processed: 0, slow path: 0
177 fast lock acquisition failures: 0, slow path: 0
178TCP Semaphore 0x7F840CD6B148 FREE After applying the command to the configuration, additional information appears in the neighbor output. Under each address family, the following statement is shown, confirming what was reported previously: without applied policies, received or sent announcements are effectively "discarded" (this concept will be discussed in more detail shortly).
1Suppressing inbound/outbound propagation because policies are missingFor each address family where announcements have been sent and/or received, a reference to the command is shown.
1 Outbound Inbound
2 Local Policy Denied Prefixes: -------- -------
3 safe-ebgp-policy: 3 1
4 Bestpath from this peer: 1 n/a
5 Total: 4 1In general, the various counters for BGP message types sent and received have increased, with a notable example being the BGP ROUTE-REFRESH counters, which have risen from 0 to 1 for both transmitted and received messages.
1 Sent Rcvd
2 Refresh activity: ---- ----
3 Refresh Start-of-RIB 1 1
4 Refresh End-of-RIB 1 1A brief observation on BGP ROUTE REFRESH messages is worth making. Some might wonder why these messages are used and what they represent. In general, this type of message allows a device to request a re-sending of routing announcements, or to re-announce its own updates, for example, as in this case following a configuration change. A detailed explanation of this process could easily be the subject of a dedicated post, so stay tuned! 😊
The following shows the packet exchange sequence between BGP peers once the command has been applied.
The following operations can be observed from this capture:
- In packets #5 and #8, R1 withdraws the IPv4 Unicast network announcement previously sent to R2
- In packets #6 and #7, R1 attempts to withdraw the IPv6 Unicast network announcement sent to R2; however, as no prefixes were advertised, no withdraw messages are generated
- In packets #13 and #14, R1 requests R2 to re-advertise both IPv4 and IPv6 Unicast network announcements
- From packets #15 to #18, R2, as R1 did previously, re-advertises the IPv4 Unicast network announcement (no IPv6 Unicast prefixes are advertised in this case as well)
Moving on to the debug verification, the behavior observed in the packet capture can also be confirmed by the following syslog messages.
1*Apr 15 05:40:18.185: BGP: 172.25.2.2 session 1 sending REFRESH_REQ(5) for afi/safi: 1/1, refresh code is 1
2*Apr 15 05:40:18.187: BGP: 172.25.2.2 session 2 sending REFRESH_REQ(5) for afi/safi: 2/1, refresh code is 1
3*Apr 15 05:40:18.194: BGP: 172.25.2.2 session 2 sending REFRESH_REQ(5) for afi/safi: 2/1, refresh code is 2
4*Apr 15 05:40:18.197: BGP(0): (base) 172.25.2.2 session 1 send unreachable (format) 10.10.0.0/16
5*Apr 15 05:40:18.197: BGP: 172.25.2.2 session 1 sending REFRESH_REQ(5) for afi/safi: 1/1, refresh code is 2
6*Apr 15 05:40:48.819: BGP: 172.25.2.2 session 1 sending REFRESH_REQ(5) for afi/safi: 1/1, refresh code is 0
7*Apr 15 05:40:48.819: BGP: 172.25.2.2 session 2 sending REFRESH_REQ(5) for afi/safi: 2/1, refresh code is 0
8*Apr 15 05:40:48.831: BGP: 172.25.2.2 session 1 rcv message type 5, length (excl. header) 4
9*Apr 15 05:40:48.831: BGP: 172.25.2.2 session 1 rcvd REFRESH_REQ for afi/safi: 1/1, refresh code is 1
10*Apr 15 05:40:48.832: BGP: nbr_topo global 172.25.2.2 IPv4 Unicast:base (0x7F83DA1539F0:1) rcvd Refresh Start-of-RIB
11*Apr 15 05:40:48.832: BGP: nbr_topo global 172.25.2.2 IPv4 Unicast:base (0x7F83DA1539F0:1) refresh_epoch is 2
12*Apr 15 05:40:48.832: BGP: 172.25.2.2 session 2 rcv message type 5, length (excl. header) 4
13*Apr 15 05:40:48.833: BGP: 172.25.2.2 session 2 rcvd REFRESH_REQ for afi/safi: 2/1, refresh code is 1
14*Apr 15 05:40:48.833: BGP: nbr_topo global 172.25.2.2 IPv6 Unicast:base (0x7F83DDCFE2D0:2) rcvd Refresh Start-of-RIB
15*Apr 15 05:40:48.834: BGP: nbr_topo global 172.25.2.2 IPv6 Unicast:base (0x7F83DDCFE2D0:2) refresh_epoch is 2
16*Apr 15 05:40:48.837: BGP: 172.25.2.2 session 2 rcv message type 5, length (excl. header) 4
17*Apr 15 05:40:48.838: BGP: 172.25.2.2 session 2 rcvd REFRESH_REQ for afi/safi: 2/1, refresh code is 2
18*Apr 15 05:40:48.838: BGP: nbr_topo global 172.25.2.2 IPv6 Unicast:base (0x7F83DDCFE2D0:2) rcvd Refresh End-of-RIB
19*Apr 15 05:40:48.841: BGP(0): 172.25.2.2 session 1 rcvd UPDATE w/ attr: nexthop 172.25.2.2, origin i, metric 0, merged path 65200, AS_PATH
20*Apr 15 05:40:48.842: BGP(0): 172.25.2.2 session 1 rcvd 10.20.0.0/16 -- DENIED due to: ebgp-safe-policy
21*Apr 15 05:40:48.844: BGP(0): no valid path for 10.20.0.0/16
22*Apr 15 05:40:48.844: BGP: 172.25.2.2 session 1 rcv message type 5, length (excl. header) 4
23*Apr 15 05:40:48.844: BGP: 172.25.2.2 session 1 rcvd REFRESH_REQ for afi/safi: 1/1, refresh code is 2
24*Apr 15 05:40:48.845: BGP: nbr_topo global 172.25.2.2 IPv4 Unicast:base (0x7F83DA1539F0:1) rcvd Refresh End-of-RIB
25*Apr 15 05:40:48.846: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.20.0.0/16Particular attention should be given to entry #20, where the network re-advertised by R2 is discarded due to the specific command.
In contrast to the previous section, the command displaying announcements sent from R1 to R2 now returns no results.
1R1#show bgp ipv4 unicast neighbors 172.25.2.2 advertised-routes
2
3Total number of prefixes 0 The following output confirms that the number of received announcements is 0. In addition, a ! appears, indicating the absence of routing policies applied to the remote peer.
1R1#show bgp ipv4 unicast summary
2[OUTPUT OMITTED]
3
4Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
5172.25.2.2 4 65200 17 18 4 0 0 00:09:02 0!The same result is observed when the IPv6 Unicast address family is specified. These behaviors are consistent with the Configuration Guide, which indicates that for each address family, the presence of routing policies is evaluated for every configured neighbor.
Scenario 1.1: Securing an Already Established eBGP Session with Soft-Reconfiguration
The behavior when the feature is applied to a session already in the Established state has therefore been examined in detail. What happens, however, if one (or both) peers have soft-reconfiguration enabled on that session? In this case, the behavior is slightly different from what has been described so far.
The analysis now resumes from an initial condition where the safe eBGP feature is not enabled, while soft-reconfiguration is configured on R1 under the IPv4 Unicast address family.
1R1#show running-config | s r b
2router bgp 65100
3 bgp log-neighbor-changes
4 neighbor 172.25.2.2 remote-as 65200
5 neighbor 172.25.2.2 transport multi-session
6 neighbor 172.25.2.2 disable-connected-check
7 neighbor 172.25.2.2 update-source Loopback0
8 !
9 address-family ipv4
10 network 10.10.0.0 mask 255.255.0.0
11 neighbor 172.25.2.2 activate
12 neighbor 172.25.2.2 soft-reconfiguration inbound
13 exit-address-family
14 !
15 address-family ipv6
16 neighbor 172.25.2.2 activate
17 exit-address-family1R2#show running-config | s r b
2router bgp 65200
3 bgp log-neighbor-changes
4 neighbor 172.25.1.1 remote-as 65100
5 neighbor 172.25.1.1 transport multi-session
6 neighbor 172.25.1.1 disable-connected-check
7 neighbor 172.25.1.1 update-source Loopback0
8 !
9 address-family ipv4
10 network 10.20.0.0 mask 255.255.0.0
11 neighbor 172.25.1.1 activate
12 exit-address-family
13 !
14 address-family ipv6
15 neighbor 172.25.1.1 activate
16 exit-address-familyOnce the configuration is updated, a hard reset is triggered via the clear ip bgp * command to start from a clean initial state. Before re-applying the safe eBGP command, it is worth verifying that the 10.20.0.0/16 network announcement received from R2 is present in R1's Adj-RIB-In table and is marked as best.
1R1#show bgp ipv4 unicast neighbors 172.25.2.2 received-routes
2BGP table version is 3, local router ID is 172.25.1.1
3Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
4 r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
5 x best-external, a additional-path, c RIB-compressed,
6 t secondary path, L long-lived-stale,
7Origin codes: i - IGP, e - EGP, ? - incomplete
8RPKI validation codes: V valid, I invalid, N Not found
9
10 Network Next Hop Metric LocPrf Weight Path
11 *> 10.20.0.0/16 172.25.2.2 0 0 65200 i
12
13Total number of prefixes 1The same debug commands used previously are enabled, and the bgp safe-ebgp-policy command is then applied. Its effects on this sub-scenario are examined below. For readability, the output is broken down into multiple parts.
Initially, following the application of the command, the same syslog messages encountered in the previous scenario appear, indicating that R1 initiates the refresh procedure starting from the announcements it had previously sent.
1R1(config-router)#bgp safe-ebgp-policy
2R1(config-router)#
3*Apr 15 05:59:07.196: BGP: 172.25.2.2 session 1 sending REFRESH_REQ(5) for afi/safi: 1/1, refresh code is 1
4*Apr 15 05:59:07.196: BGP: 172.25.2.2 session 2 sending REFRESH_REQ(5) for afi/safi: 2/1, refresh code is 1
5*Apr 15 05:59:07.199: BGP: 172.25.2.2 session 2 sending REFRESH_REQ(5) for afi/safi: 2/1, refresh code is 2
6*Apr 15 05:59:07.200: BGP(0): (base) 172.25.2.2 session 1 send unreachable (format) 10.10.0.0/16
7*Apr 15 05:59:07.200: BGP: 172.25.2.2 session 1 sending REFRESH_REQ(5) for afi/safi: 1/1, refresh code is 2The route previously received from R2 is then verified to still be present.
1R1(config-router)#do show bgp ipv4 unicast neighbors 172.25.2.2 received-routes
2BGP table version is 3, local router ID is 172.25.1.1
3Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
4 r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
5 x best-external, a additional-path, c RIB-compressed,
6 t secondary path, L long-lived-stale,
7Origin codes: i - IGP, e - EGP, ? - incomplete
8RPKI validation codes: V valid, I invalid, N Not found
9
10 Network Next Hop Metric LocPrf Weight Path
11 *> 10.20.0.0/16 172.25.2.2 0 0 65200 i
12
13Total number of prefixes 1The same route is also visible in the BGP Loc-RIB output shown below.
1R1(config-router)#do show bgp ipv4 unicast
2BGP table version is 3, local router ID is 172.25.1.1
3Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
4 r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
5 x best-external, a additional-path, c RIB-compressed,
6 t secondary path, L long-lived-stale,
7Origin codes: i - IGP, e - EGP, ? - incomplete
8RPKI validation codes: V valid, I invalid, N Not found
9
10 Network Next Hop Metric LocPrf Weight Path
11 *> 10.10.0.0/16 0.0.0.0 0 32768 i
12 *> 10.20.0.0/16 172.25.2.2 0 0 65200 iThe following output further confirms that the BGP process still retains the 10.20.0.0/16 route received from R2. It is worth noting that the configuration of the safe eBGP command has triggered the addition of ! in the last column.
1R1(config-router)#do show bgp ipv4 unicast summary
2BGP router identifier 172.25.1.1, local AS number 65100
3BGP table version is 3, main routing table version 3
42 network entries using 496 bytes of memory
52 path entries using 272 bytes of memory
62/2 BGP path/bestpath attribute entries using 576 bytes of memory
71 BGP AS-PATH entries using 24 bytes of memory
80 BGP route-map cache entries using 0 bytes of memory
90 BGP filter-list cache entries using 0 bytes of memory
10BGP using 1368 total bytes of memory
11BGP activity 53/51 prefixes, 54/52 paths, scan interval 60 secs
123 networks peaked at 16:22:19 Apr 11 2026 UTC (3d13h ago)
13
14Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
15172.25.2.2 4 65200 19 21 3 0 0 00:13:22 1!From this point onward, the effects of the newly activated feature begin to appear. The following output shows that the BGP Loc-RIB has changed compared to the previous state, with the route received from R2 no longer present.
1R1(config-router)#do show bgp ipv4 unicast
2BGP table version is 4, local router ID is 172.25.1.1
3Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
4 r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
5 x best-external, a additional-path, c RIB-compressed,
6 t secondary path, L long-lived-stale,
7Origin codes: i - IGP, e - EGP, ? - incomplete
8RPKI validation codes: V valid, I invalid, N Not found
9
10 Network Next Hop Metric LocPrf Weight Path
11 *> 10.10.0.0/16 0.0.0.0 0 32768 iExamining the log entries in order, it can be observed that R1 sends a BGP ROUTE REFRESH message to R2 for the IPv6 Unicast AFI/SAFI (entry #1). For the IPv4 Unicast AFI/SAFI, an inbound soft reconfiguration is triggered locally instead, reprocessing the route already stored in the Adj-RIB-In without involving R2 (entries #2 through #7). In the remaining entries (#8 through #14), R1 receives from R2 the ROUTE REFRESH messages for the IPv6 Unicast AFI/SAFI, with no network announcements in between, as no IPv6 prefixes were advertised by R2.
1*Apr 15 05:59:37.842: BGP: 172.25.2.2 session 2 sending REFRESH_REQ(5) for afi/safi: 2/1, refresh code is 0
2*Apr 15 05:59:37.844: BGP(0): start inbound soft reconfiguration for
3*Apr 15 05:59:37.845: BGP(0): process 10.20.0.0/16, next hop 172.25.2.2, metric 0 from 172.25.2.2
4*Apr 15 05:59:37.845: BGP(0): update denied, previous used path deleted
5*Apr 15 05:59:37.846: BGP(0): no valid path for 10.20.0.0/16
6*Apr 15 05:59:37.846: BGP(0): complete inbound soft reconfiguration, ran for 2ms
7*Apr 15 05:59:37.846: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.20.0.0/16
8*Apr 15 05:59:37.877: BGP: 172.25.2.2 session 2 rcv message type 5, length (excl. header) 4
9*Apr 15 05:59:37.877: BGP: 172.25.2.2 session 2 rcvd REFRESH_REQ for afi/safi: 2/1, refresh code is 1
10*Apr 15 05:59:37.877: BGP: nbr_topo global 172.25.2.2 IPv6 Unicast:base (0x7F8412269A70:2) rcvd Refresh Start-of-RIB
11*Apr 15 05:59:37.877: BGP: nbr_topo global 172.25.2.2 IPv6 Unicast:base (0x7F8412269A70:2) refresh_epoch is 2
12*Apr 15 05:59:37.877: BGP: 172.25.2.2 session 2 rcv message type 5, length (excl. header) 4
13*Apr 15 05:59:37.877: BGP: 172.25.2.2 session 2 rcvd REFRESH_REQ for afi/safi: 2/1, refresh code is 2
14*Apr 15 05:59:37.877: BGP: nbr_topo global 172.25.2.2 IPv6 Unicast:base (0x7F8412269A70:2) rcvd Refresh End-of-RIBContrary to what might be expected, the route is still present in the Adj-RIB-In table, though marked as not best, which corresponds to the update denied entry observed earlier.
1R1(config-router)#do show bgp ipv4 unicast neighbors 172.25.2.2 received-routes
2BGP table version is 4, local router ID is 172.25.1.1
3Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
4 r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
5 x best-external, a additional-path, c RIB-compressed,
6 t secondary path, L long-lived-stale,
7Origin codes: i - IGP, e - EGP, ? - incomplete
8RPKI validation codes: V valid, I invalid, N Not found
9
10 Network Next Hop Metric LocPrf Weight Path
11 * 10.20.0.0/16 172.25.2.2 0 0 65200 i
12
13Total number of prefixes 1A detailed inspection of the route in the following output reveals that it is marked as received-only, meaning it is not processed further (routes that are received and installed within the BGP Loc-RIB are associated with the received & used keywords).
1R1#show bgp ipv4 unicast 10.20.0.0/16
2BGP routing table entry for 10.20.0.0/16, version 4
3Paths: (1 available, no best path)
4 Not advertised to any peer
5 Refresh Epoch 1
6 65200, (received-only)
7 172.25.2.2 from 172.25.2.2 (172.25.2.2)
8 Origin IGP, metric 0, localpref 100, valid, external
9 rx pathid: 0, tx pathid: 0
10 Updated on Apr 15 2026 05:46:03 UTCFor completeness, the packet capture for this sub-scenario is also provided below.
A final observation is worth making before moving on. Is there any difference between the captures of Scenario 1 and Scenario 1.1? A closer look reveals a subtle but meaningful distinction, directly attributable to the neighbor 172.25.2.2 soft-reconfiguration inbound command configured on R1. The difference lies in the second part of both captures, where R1 requests R2 to retransmit its announcements. In a multisession environment, such requests are issued over two separate TCP sessions. In Scenario 1.1, however, this request is present only for the IPv6 Unicast AFI/SAFI and is absent for the IPv4 Unicast one. This behavior is a direct consequence of the soft-reconfiguration feature being active on R1 for that specific address family.
Scenario 2: Securing an eBGP Session at Session Establishment
The analysis now moves to the second scenario, in which the bgp safe-ebgp-policy command is applied on R1 before activating the neighborship, and the resulting behavior is observed. To proceed, configuration changes must be made on both peers. In addition to disabling the command previously applied on R1, automatic activation of the IPv4 Unicast address family is then disabled using the command no bgp default ipv4-unicast.
The following shows the initial configuration of both R1 and R2 for this scenario.
1R1#show running-config | s r b
2router bgp 65100
3 bgp log-neighbor-changes
4 no bgp default ipv4-unicast
5 neighbor 172.25.2.2 remote-as 65200
6 neighbor 172.25.2.2 transport multi-session
7 neighbor 172.25.2.2 disable-connected-check
8 neighbor 172.25.2.2 update-source Loopback0
9 !
10 address-family ipv4
11 network 10.10.0.0 mask 255.255.0.0
12 exit-address-family
13 !
14 address-family ipv6
15 exit-address-family1R2#show running-config | s r b
2router bgp 65200
3 bgp log-neighbor-changes
4 no bgp default ipv4-unicast
5 neighbor 172.25.1.1 remote-as 65100
6 neighbor 172.25.1.1 transport multi-session
7 neighbor 172.25.1.1 disable-connected-check
8 neighbor 172.25.1.1 update-source Loopback0
9 !
10 address-family ipv4
11 network 10.20.0.0 mask 255.255.0.0
12 exit-address-family
13 !
14 address-family ipv6
15 exit-address-familyOnce these configurations are applied, a hard reset of the BGP sessions is performed via the clear ip bgp * command. The bgp safe-ebgp-policy command is then enabled on both devices. Activating the security mechanism on both R1 and R2 does not result in any message exchange. This is because no session has been established yet (note that the neighbor <remote-peer-IP> activate is missing from the configuration). The neighborship is then activated on both peers by enabling the neighbor under each address family (for simplicity, the verification is performed only for the IPv4 Unicast address family). Compared to the previous case, there is one notable difference, which could have been anticipated before performing the test. Once the BGP session is established between the two peers, no announcements are exchanged. The peers exchange only a single UPDATE message, which carries no prefix information.
Since no announcements are exchanged, there are consequently no BGP ROUTE-REFRESH messages as observed in the previous packet capture. The corresponding counters reflect this absence, all showing 0, as can be verified on R1.
1R1#show ip bgp neighbors 172.25.2.2
2[OUTPUT OMITTED]
3 Last Sent Refresh Start-of-rib: never
4 Last Sent Refresh End-of-rib: never
5 Last Received Refresh Start-of-rib: never
6 Last Received Refresh End-of-rib: never
7 Sent Rcvd
8 Refresh activity: ---- ----
9 Refresh Start-of-RIB 0 0
10 Refresh End-of-RIB 0 0
11[OUTPUT OMITTED]Furthermore, unlike Scenario 1, only the safe-ebgp-policy entry appears in the following output.
1 Outbound Inbound
2 Local Policy Denied Prefixes: -------- -------
3 safe-ebgp-policy: 0 1
4 Total: 0 1Takeaways
Securing eBGP sessions is the first step toward ensuring stable and predictable behavior. To this end, IOS XE provides a range of features that enable the protection of both internal and external sessions. To secure eBGP sessions, one of the steps that can be taken is to enable the command introduced in this post from the outset, rather than applying it after the session is already established. This approach provides greater control over the announcements to be sent and received, significantly reducing the risk of errors. Routing policies applied to external neighbors should not only be customized for the specific use case but also follow best practices depending on the type of peering established with the remote BGP peer.
I hope this post has been helpful. If you have any additional thoughts to share, feel free to reach out via social media. See you in the next one! 🙂