Enabling Secure Policies over eBGP Sessions in IOS XE
Overview
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. To address this need, the Mutually Agreed Norms for Routing Security (MANRS) initiative was established: a community-driven effort aimed at implementing essential measures to reduce the most common routing security threats.
How can a BGP neighborship between two peers be secured from the very beginning? To address this need, RFC 8212 was published in July 2017, updating the original RFC 4271 – A Border Gateway Protocol 4 (BGP-4). The RFC states the following.
This specification intends to improve this situation by requiring the explicit configuration of both BGP Import and Export Policies for any External BGP (EBGP) session such as customers, peers, or confederation boundaries for all enabled address families.
How does this requirement translate into the implementation of IOS XR and IOS XE? The enablement described in the RFC is reflected, from an implementation perspective, in the requirement to configure one or more routing policies that explicitly define which routes can be advertised and received on an external BGP session. On IOS XR, this behavior is enforced by default. Whenever an eBGP session is configured, it is mandatory to apply at least one routing policy in both the inbound and outbound directions. On IOS XE, however, this behavior is not enforced by default. As a result, when configuring an eBGP session with a remote peer, the session is able to exchange network announcements in both directions immediately, even in the absence of explicitly defined routing policies.
Default IOS XE Behavior
Starting from the basic topology shown in the figure, it can be observed that IOS XE adopts a permissive default behavior. R1 and R2 establish two external MP-BGP sessions. As illustrated, each router advertises a single IPv4 Unicast /16 network to its respective peer.
Below is the configuration of R1.
R1#show running-config | s r b
router bgp 65100
bgp log-neighbor-changes
neighbor 172.25.2.2 remote-as 65200
neighbor 172.25.2.2 transport multi-session
neighbor 172.25.2.2 disable-connected-check
neighbor 172.25.2.2 update-source Loopback0
!
address-family ipv4
network 10.10.0.0 mask 255.255.0.0
neighbor 172.25.2.2 activate
exit-address-family
!
address-family ipv6
neighbor 172.25.2.2 activate
exit-address-family
Below is the configuration of R2.
R2#show running-config | s r b
router bgp 65200
bgp log-neighbor-changes
neighbor 172.25.1.1 remote-as 65100
neighbor 172.25.1.1 transport multi-session
neighbor 172.25.1.1 disable-connected-check
neighbor 172.25.1.1 update-source Loopback0
!
address-family ipv4
network 10.20.0.0 mask 255.255.0.0
neighbor 172.25.1.1 activate
exit-address-family
!
address-family ipv6
neighbor 172.25.1.1 activate
exit-address-family
For reference, the following output shows all information for the two sessions between R1 and R2.
R1#show ip bgp neighbors 172.25.2.2
BGP neighbor is 172.25.2.2, remote AS 65200, external link
BGP version 4, remote router ID 172.25.2.2
Session state = Established, up for 00:00:23
Last read 00:00:23, last write 00:00:22, hold time is 180, keepalive interval is 60 seconds
BGP multisession with 2 sessions (2 established), first up for 00:00:23
Neighbor sessions:
2 active, is multisession capable
Session: 172.25.2.2 session 1
Topology IPv4 Unicast
Session: 172.25.2.2 session 2
Topology IPv6 Unicast
Neighbor capabilities:
Route refresh: advertised and received(new) on session 1, 2
Four-octets ASN Capability: advertised and received on session 1, 2
Address family IPv4 Unicast: advertised and received
Address family IPv6 Unicast: advertised and received
Enhanced Refresh Capability: advertised and received
Multisession Capability: advertised and received
Stateful switchover support enabled: NO for session 1, 2
Message statistics for 172.25.2.2 session 1, state Established:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 1 1
Notifications: 0 0
Updates: 1 2
Keepalives: 2 2
Route Refresh: 0 0
Total: 4 5
Message statistics for 172.25.2.2 session 2, state Established:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 1 1
Notifications: 0 0
Updates: 1 1
Keepalives: 2 2
Route Refresh: 0 0
Total: 4 4
Do log neighbor state changes (via global configuration)
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
Session: 172.25.2.2 session 1
BGP table version 3, neighbor version 2/3
Output queue size : 0
Index 105, Advertise bit 0
session 1 member
105 update-group member
Slow-peer detection is disabled
Slow-peer split-update-group dynamic is disabled
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 1 (Consumes 136 bytes)
Prefixes Total: 0 1
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 1
Used as multipath: n/a 0
Used as secondary: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Bestpath from this peer: 1 n/a
Total: 1 0
Number of NLRIs in the update sent: max 1, min 0
Current session network count peaked at 1 entries at 14:39:48 Jan 11 2026 UTC (00:00:24.784 ago)
Highest network count observed at 1 entries at 09:56:39 Jan 11 2026 UTC (04:43:33.784 ago)
Last detected as dynamic slow peer: never
Dynamic slow peer recovered: never
Refresh Epoch: 1
Last Sent Refresh Start-of-rib: never
Last Sent Refresh End-of-rib: never
Last Received Refresh Start-of-rib: never
Last Received Refresh End-of-rib: never
Sent Rcvd
Refresh activity: ---- ----
Refresh Start-of-RIB 0 0
Refresh End-of-RIB 0 0
For address family: IPv6 Unicast
Session: 172.25.2.2 session 2
BGP table version 1, neighbor version 1/0
Output queue size : 0
Index 55, Advertise bit 0
session 2 member
55 update-group member
Slow-peer detection is disabled
Slow-peer split-update-group dynamic is disabled
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0
Used as secondary: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 1, min 0
Last detected as dynamic slow peer: never
Dynamic slow peer recovered: never
Refresh Epoch: 1
Last Sent Refresh Start-of-rib: never
Last Sent Refresh End-of-rib: never
Last Received Refresh Start-of-rib: never
Last Received Refresh End-of-rib: never
Sent Rcvd
Refresh activity: ---- ----
Refresh Start-of-RIB 0 0
Refresh End-of-RIB 0 0
Address tracking is enabled, the RIB does have a route to 172.25.2.2
Route to peer address reachability Up: 1; Down: 0
Last notification 2w0d
Connections established 150; dropped 148
Last reset 00:00:24, due to Neighbor reset of session 2
External BGP neighbor not directly connected.
External BGP neighbor NOT configured for connected checks (single-hop disable-connected-check)
Interface associated: (none) (peering address NOT in same link)
Transport(tcp) path-mtu-discovery is enabled
Graceful-Restart is disabled
SSO is disabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 172.25.1.1, Local port: 31350
Foreign host: 172.25.2.2, Foreign port: 179
Connection tableid (VRF): 0
Maximum output segment queue size: 50
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x89B7814D):
Timer Starts Wakeups Next
Retrans 4 0 0x0
TimeWait 0 0 0x0
AckHold 3 0 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 1 0 0x89C04BC7
DeadWait 0 0 0x0
Linger 0 0 0x0
ProcessQ 0 0 0x0
iss: 2070046441 snduna: 2070046565 sndnxt: 2070046565
irs: 4037060639 rcvnxt: 4037060816
sndwnd: 16261 scale: 0 maxrcvwnd: 16384
rcvwnd: 16208 scale: 0 delrcvwnd: 176
SRTT: 413 ms, RTTO: 3205 ms, RTV: 2792 ms, KRTT: 0 ms
minRTT: 1 ms, maxRTT: 1000 ms, ACK hold: 200 ms
uptime: 23882 ms, Sent idletime: 22854 ms, Receive idletime: 22852 ms
Status Flags: active open
Option Flags: nagle, path mtu capable
IP Precedence value : 6
Datagrams (max data segment is 1460 bytes):
Rcvd: 7 (out of order: 0), with data: 4, total data bytes: 176
Sent: 8 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 4, total data bytes: 123
Packets received in fast path: 0, fast processed: 0, slow path: 0
fast lock acquisition failures: 0, slow path: 0
TCP Semaphore 0x7F193B70BC00 FREE
It is possible to verify how both peers receive networks from the remote peer and install them into the RIB. The following output shows that R1 has received an announcement from R2.
R1#show bgp ipv4 unicast summary
BGP router identifier 172.25.1.1, local AS number 65100
BGP table version is 3, main routing table version 3
2 network entries using 496 bytes of memory
2 path entries using 272 bytes of memory
2/2 BGP path/bestpath attribute entries using 576 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1368 total bytes of memory
BGP activity 65/63 prefixes, 71/69 paths, scan interval 60 secs
2 networks peaked at 09:56:39 Jan 11 2026 UTC (03:44:28.399 ago)
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.25.2.2 4 65200 127 126 3 0 0 01:50:44 1
The announcement in question is detailed in the following output.
R1#show bgp ipv4 unicast neighbors 172.25.2.2 routes
BGP table version is 21, local router ID is 172.25.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.20.0.0/16 172.25.2.2 0 0 65200 i
Similarly, it is possible to see how R1 advertised the 10.10.0.0/16 network to peer R2.
R1#show bgp ipv4 unicast neighbors 172.25.2.2 advertised-routes
BGP table version is 3, local router ID is 172.25.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.10.0.0/16 0.0.0.0 0 32768 i
Total number of prefixes 1
The route received by R1 was then installed in the RIB.
R1#show ip route bgp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks
B 10.20.0.0/16 [20/0] via 172.25.2.2, 00:03:34
As stated at the beginning, IOS XE does not impose any limitations on network announcements for external BGP sessions.
Securing eBGP Sessions in IOS XE
How can the behavior of the two platforms be aligned? A few years ago, a new command was introduced within BGP configuration mode: bgp safe-ebgp-policy. This command allows IOS XE to replicate the behavior already present by default on IOS XR.
Let’s now examine the effects of enabling this command using the topology shown at the beginning. Two scenarios can be considered:
- In the first scenario, the command is applied after the MP-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 External MP-BGP 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.
R1(config-router)#bgp safe-ebgp-policy
Once applied, this command triggers the generation of BGP messages to all peers. Since two address families (IPv4 and IPv6 unicast) are configured, these messages are processed for both sessions. Let’s examine, step by step, the session state information between R1 and R2. The following output shows the result of the usual command executed on R1.
R1#show ip bgp neighbors 172.25.2.2
BGP neighbor is 172.25.2.2, remote AS 65200, external link
BGP version 4, remote router ID 172.25.2.2
Session state = Established, up for 00:03:05
Last read 00:00:26, last write 00:00:26, hold time is 180, keepalive interval is 60 seconds
BGP multisession with 2 sessions (2 established), first up for 00:03:05
Neighbor sessions:
2 active, is multisession capable
Session: 172.25.2.2 session 1
Topology IPv4 Unicast
Session: 172.25.2.2 session 2
Topology IPv6 Unicast
Neighbor capabilities:
Route refresh: advertised and received(new) on session 1, 2
Four-octets ASN Capability: advertised and received on session 1, 2
Address family IPv4 Unicast: advertised and received
Address family IPv6 Unicast: advertised and received
Enhanced Refresh Capability: advertised and received
Multisession Capability: advertised and received
Stateful switchover support enabled: NO for session 1, 2
Message statistics for 172.25.2.2 session 1, state Established:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 1 1
Notifications: 0 0
Updates: 3 3
Keepalives: 3 4
Route Refresh: 1 0
Total: 10 10
Message statistics for 172.25.2.2 session 2, state Established:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 1 1
Notifications: 0 0
Updates: 1 1
Keepalives: 4 4
Route Refresh: 1 0
Total: 9 8
Do log neighbor state changes (via global configuration)
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
Session: 172.25.2.2 session 1
BGP table version 4, neighbor version 4/0
Output queue size : 0
Index 105, Advertise bit 0
session 1 member
105 update-group member
Suppressing inbound/outbound propagation because policies are missing
Slow-peer detection is disabled
Slow-peer split-update-group dynamic is disabled
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 1 1
Implicit Withdraw: 0 1
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0
Used as secondary: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
safe-ebgp-policy: 3 1
Bestpath from this peer: 1 n/a
Total: 4 1
Number of NLRIs in the update sent: max 1, min 0
Current session network count peaked at 1 entries at 14:39:48 Jan 11 2026 UTC (00:03:06.607 ago)
Highest network count observed at 1 entries at 09:56:39 Jan 11 2026 UTC (04:46:15.607 ago)
Last detected as dynamic slow peer: never
Dynamic slow peer recovered: never
Refresh Epoch: 2
Last Sent Refresh Start-of-rib: 00:00:57
Last Sent Refresh End-of-rib: 00:00:57
Refresh-Out took 0 seconds
Last Received Refresh Start-of-rib: 00:00:26
Last Received Refresh End-of-rib: 00:00:26
Refresh-In took 0 seconds
Sent Rcvd
Refresh activity: ---- ----
Refresh Start-of-RIB 1 1
Refresh End-of-RIB 1 1
For address family: IPv6 Unicast
Session: 172.25.2.2 session 2
BGP table version 1, neighbor version 1/0
Output queue size : 0
Index 55, Advertise bit 0
session 2 member
55 update-group member
Suppressing inbound/outbound propagation because policies are missing
Slow-peer detection is disabled
Slow-peer split-update-group dynamic is disabled
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0
Used as secondary: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 1, min 0
Last detected as dynamic slow peer: never
Dynamic slow peer recovered: never
Refresh Epoch: 2
Last Sent Refresh Start-of-rib: 00:00:57
Last Sent Refresh End-of-rib: 00:00:57
Refresh-Out took 0 seconds
Last Received Refresh Start-of-rib: 00:00:26
Last Received Refresh End-of-rib: 00:00:26
Refresh-In took 0 seconds
Sent Rcvd
Refresh activity: ---- ----
Refresh Start-of-RIB 1 1
Refresh End-of-RIB 1 1
Address tracking is enabled, the RIB does have a route to 172.25.2.2
Route to peer address reachability Up: 1; Down: 0
Last notification 2w0d
Connections established 150; dropped 148
Last reset 00:03:06, due to Neighbor reset of session 2
External BGP neighbor not directly connected.
External BGP neighbor NOT configured for connected checks (single-hop disable-connected-check)
Interface associated: (none) (peering address NOT in same link)
Transport(tcp) path-mtu-discovery is enabled
Graceful-Restart is disabled
SSO is disabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 172.25.1.1, Local port: 31350
Foreign host: 172.25.2.2, Foreign port: 179
Connection tableid (VRF): 0
Maximum output segment queue size: 50
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x89B9F980):
Timer Starts Wakeups Next
Retrans 8 0 0x0
TimeWait 0 0 0x0
AckHold 6 2 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 1 0 0x89C04BC7
DeadWait 0 0 0x0
Linger 0 0 0x0
ProcessQ 0 0 0x0
iss: 2070046441 snduna: 2070046732 sndnxt: 2070046732
irs: 4037060639 rcvnxt: 4037060953
sndwnd: 16094 scale: 0 maxrcvwnd: 16384
rcvwnd: 16071 scale: 0 delrcvwnd: 313
SRTT: 656 ms, RTTO: 2806 ms, RTV: 2150 ms, KRTT: 0 ms
minRTT: 1 ms, maxRTT: 1000 ms, ACK hold: 200 ms
uptime: 185725 ms, Sent idletime: 26986 ms, Receive idletime: 26986 ms
Status Flags: active open
Option Flags: nagle, path mtu capable
IP Precedence value : 6
Datagrams (max data segment is 1460 bytes):
Rcvd: 14 (out of order: 0), with data: 8, total data bytes: 313
Sent: 16 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 9, total data bytes: 290
Packets received in fast path: 0, fast processed: 0, slow path: 0
fast lock acquisition failures: 0, slow path: 0
TCP Semaphore 0x7F193B70BC00 FREE
After applying the new command to the configuration, new information appears that was not previously present. 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).
Suppressing inbound/outbound propagation because policies are missing
For each address family where announcements have been sent or received, a reference to the command is shown.
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
safe-ebgp-policy: 3 1
In general, the various counters for BGP message types sent and received have increased. One noticeable example is the BGP ROUTE-REFRESH counters, which have incremented from 0 for both transmitted and received messages.
Sent Rcvd
Refresh activity: ---- ----
Refresh Start-of-RIB 1 1
Refresh End-of-RIB 1 1
It’s worth making a brief note about the type of BGP ROUTE REFRESH messages. 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.
Now, why do the two points we just discussed mention exactly three BGP messages (which do not always correspond to three packets)? This can be explained by the intrinsic behavior of these messages. In general, the first BGP ROUTE REFRESH message informs the peer that the local router is about to send announcements or is requesting a re-send of announcements from the remote peer. The second message, a BGP UPDATE, contains the networks to be announced or withdrawn. The third and final BGP ROUTE REFRESH message signals the completion of the announcement (or withdrawal) exchange.
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 specific to the IPv4 address family.
| No. | Source | Destination | Protocol | Info |
|---|---|---|---|---|
| 1 | 172.25.1.1 | 172.25.2.2 | BGP | ROUTE-REFRESH Message |
| 3 | 172.25.1.1 | 172.25.2.2 | BGP | UPDATE Message, ROUTE-REFRESH Message |
| 6 | 172.25.2.2 | 172.25.1.1 | TCP | 41048 → 179 [ACK] Seq=1 Ack=73 Win=15854 Len=0 |
| 7 | 172.25.2.2 | 172.25.1.1 | BGP | KEEPALIVE Message |
| 8 | 172.25.1.1 | 172.25.2.2 | TCP | 179 → 41048 [ACK] Seq=73 Ack=20 Win=15930 Len=0 |
| 11 | 172.25.1.1 | 172.25.2.2 | BGP | ROUTE-REFRESH Message |
| 14 | 172.25.2.2 | 172.25.1.1 | BGP | ROUTE-REFRESH Message |
| 16 | 172.25.2.2 | 172.25.1.1 | BGP | UPDATE Message |
| 18 | 172.25.1.1 | 172.25.2.2 | TCP | 179 → 41048 [ACK] Seq=96 Ack=96 Win=15854 Len=0 |
| 19 | 172.25.2.2 | 172.25.1.1 | BGP | ROUTE-REFRESH Message |
| 20 | 172.25.1.1 | 172.25.2.2 | TCP | 179 → 41048 [ACK] Seq=96 Ack=119 Win=15831 Len=0 |
Two distinct operations can be observed from this capture:
- In packets #1 to #3, R1 withdraws the network announcement previously sent to R2.
- In packet #11, R1 requests that R2 resend the announcements. R2 then retransmits the announcements in packets #14, #16, and #19.
Supporting the first point, it can be observed that, unlike the previous section, the command showing announcements sent from R1 to R2 does not return any results.
R1#show bgp ipv4 unicast neighbors 172.25.2.2 advertised-routes
Total number of prefixes 0
Continuing with further verifications, the following output shows that the number of received announcements is 0. In addition, a ! appears, indicating the absence of routing policies applied to the remote peer.
R1#show bgp ipv4 unicast summary
[OUTPUT OMITTED]
2 networks peaked at 09:56:39 Jan 11 2026 UTC (01:51:47.999 ago)
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.25.2.2 4 65200 11 10 4 0 0 00:05:52 0!
The same result would be observed when specifying the IPv6 Unicast address family. 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 2: Securing an External MP-BGP Session at Session Establishment
Let’s now move 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, the two sessions are also disabled. 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 R1 for this scenario.
R1#show running-config | s r b
router bgp 65100
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 172.25.2.2 remote-as 65200
neighbor 172.25.2.2 transport multi-session
neighbor 172.25.2.2 disable-connected-check
neighbor 172.25.2.2 update-source Loopback0
!
address-family ipv4
network 10.10.0.0 mask 255.255.0.0
exit-address-family
!
address-family ipv6
exit-address-family
The following shows the initial configuration of R2 for this scenario.
R2#show running-config | s r b
router bgp 65200
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 172.25.1.1 remote-as 65100
neighbor 172.25.1.1 transport multi-session
neighbor 172.25.1.1 disable-connected-check
neighbor 172.25.1.1 update-source Loopback0
!
address-family ipv4
network 10.20.0.0 mask 255.255.0.0
exit-address-family
!
address-family ipv6
exit-address-family
Activating the security mechanism on both R1 and R2 does not result in any message exchange. This is because no session is in the Established state. The neighborship is now activated on both R1 and R2. 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 reaches the two peers, no announcements are exchanged. The peers exchange only a single update message, formatted as follows.
Frame 10: 77 bytes on wire (616 bits), 77 bytes captured (616 bits)
Ethernet II, Src: 52:54:00:98:36:c5 (52:54:00:98:36:c5), Dst: 52:54:00:4a:1c:da (52:54:00:4a:1c:da)
Internet Protocol Version 4, Src: 172.25.1.1, Dst: 172.25.2.2
Transmission Control Protocol, Src Port: 42775, Dst Port: 179, Seq: 101, Ack: 82, Len: 23
Border Gateway Protocol - UPDATE Message
Marker: ffffffffffffffffffffffffffffffff
Length: 23
Type: UPDATE Message (2)
Withdrawn Routes Length: 0
Total Path Attribute Length: 0
Since no announcements are exchanged, there are consequently no BGP ROUTE-REFRESH messages as observed in the previous section. The corresponding counters reflect this absence, all showing 0, as can be verified on R1.
R1#show ip bgp neighbors 172.25.2.2
[OUTPUT OMITTED]
Last Sent Refresh Start-of-rib: never
Last Sent Refresh End-of-rib: never
Last Received Refresh Start-of-rib: never
Last Received Refresh End-of-rib: never
Sent Rcvd
Refresh activity: ---- ----
Refresh Start-of-RIB 0 0
Refresh End-of-RIB 0 0
[OUTPUT OMITTED]
Takeaways
To secure external BGP sessions on IOS XE platforms, it is strongly recommended to use 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 peer.