Enabling Secure Policies over eBGP Sessions 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. 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.
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.
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-familyBelow is the configuration of R2.
1R2#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:23
5 Last read 00:00:23, last write 00:00:22, hold time is 180, keepalive interval is 60 seconds
6 BGP multisession with 2 sessions (2 established), first up for 00:00:23
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: 1 2
29 Keepalives: 2 2
30 Route Refresh: 0 0
31 Total: 4 5
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: 2 2
41 Route Refresh: 0 0
42 Total: 4 4
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 3, neighbor version 2/3
49 Output queue size : 0
50 Index 105, Advertise bit 0
51 session 1 member
52 105 update-group member
53 Slow-peer detection is disabled
54 Slow-peer split-update-group dynamic is disabled
55 Sent Rcvd
56 Prefix activity: ---- ----
57 Prefixes Current: 0 1 (Consumes 136 bytes)
58 Prefixes Total: 0 1
59 Implicit Withdraw: 0 0
60 Explicit Withdraw: 0 0
61 Used as bestpath: n/a 1
62 Used as multipath: n/a 0
63 Used as secondary: n/a 0
64
65 Outbound Inbound
66 Local Policy Denied Prefixes: -------- -------
67 Bestpath from this peer: 1 n/a
68 Total: 1 0
69 Number of NLRIs in the update sent: max 1, min 0
70 Current session network count peaked at 1 entries at 14:39:48 Jan 11 2026 UTC (00:00:24.784 ago)
71 Highest network count observed at 1 entries at 09:56:39 Jan 11 2026 UTC (04:43:33.784 ago)
72 Last detected as dynamic slow peer: never
73 Dynamic slow peer recovered: never
74 Refresh Epoch: 1
75 Last Sent Refresh Start-of-rib: never
76 Last Sent Refresh End-of-rib: never
77 Last Received Refresh Start-of-rib: never
78 Last Received Refresh End-of-rib: never
79 Sent Rcvd
80 Refresh activity: ---- ----
81 Refresh Start-of-RIB 0 0
82 Refresh End-of-RIB 0 0
83
84 For address family: IPv6 Unicast
85 Session: 172.25.2.2 session 2
86 BGP table version 1, neighbor version 1/0
87 Output queue size : 0
88 Index 55, Advertise bit 0
89 session 2 member
90 55 update-group member
91 Slow-peer detection is disabled
92 Slow-peer split-update-group dynamic is disabled
93 Sent Rcvd
94 Prefix activity: ---- ----
95 Prefixes Current: 0 0
96 Prefixes Total: 0 0
97 Implicit Withdraw: 0 0
98 Explicit Withdraw: 0 0
99 Used as bestpath: n/a 0
100 Used as multipath: n/a 0
101 Used as secondary: n/a 0
102
103 Outbound Inbound
104 Local Policy Denied Prefixes: -------- -------
105 Total: 0 0
106 Number of NLRIs in the update sent: max 1, min 0
107 Last detected as dynamic slow peer: never
108 Dynamic slow peer recovered: never
109 Refresh Epoch: 1
110 Last Sent Refresh Start-of-rib: never
111 Last Sent Refresh End-of-rib: never
112 Last Received Refresh Start-of-rib: never
113 Last Received Refresh End-of-rib: never
114 Sent Rcvd
115 Refresh activity: ---- ----
116 Refresh Start-of-RIB 0 0
117 Refresh End-of-RIB 0 0
118
119 Address tracking is enabled, the RIB does have a route to 172.25.2.2
120 Route to peer address reachability Up: 1; Down: 0
121 Last notification 2w0d
122 Connections established 150; dropped 148
123 Last reset 00:00:24, due to Neighbor reset of session 2
124 External BGP neighbor not directly connected.
125 External BGP neighbor NOT configured for connected checks (single-hop disable-connected-check)
126 Interface associated: (none) (peering address NOT in same link)
127 Transport(tcp) path-mtu-discovery is enabled
128 Graceful-Restart is disabled
129 SSO is disabled
130Connection state is ESTAB, I/O status: 1, unread input bytes: 0
131Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
132Local host: 172.25.1.1, Local port: 31350
133Foreign host: 172.25.2.2, Foreign port: 179
134Connection tableid (VRF): 0
135Maximum output segment queue size: 50
136
137Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
138
139Event Timers (current time is 0x89B7814D):
140Timer Starts Wakeups Next
141Retrans 4 0 0x0
142TimeWait 0 0 0x0
143AckHold 3 0 0x0
144SendWnd 0 0 0x0
145KeepAlive 0 0 0x0
146GiveUp 0 0 0x0
147PmtuAger 1 0 0x89C04BC7
148DeadWait 0 0 0x0
149Linger 0 0 0x0
150ProcessQ 0 0 0x0
151
152iss: 2070046441 snduna: 2070046565 sndnxt: 2070046565
153irs: 4037060639 rcvnxt: 4037060816
154
155sndwnd: 16261 scale: 0 maxrcvwnd: 16384
156rcvwnd: 16208 scale: 0 delrcvwnd: 176
157
158SRTT: 413 ms, RTTO: 3205 ms, RTV: 2792 ms, KRTT: 0 ms
159minRTT: 1 ms, maxRTT: 1000 ms, ACK hold: 200 ms
160uptime: 23882 ms, Sent idletime: 22854 ms, Receive idletime: 22852 ms
161Status Flags: active open
162Option Flags: nagle, path mtu capable
163IP Precedence value : 6
164
165Datagrams (max data segment is 1460 bytes):
166Rcvd: 7 (out of order: 0), with data: 4, total data bytes: 176
167Sent: 8 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 4, total data bytes: 123
168
169 Packets received in fast path: 0, fast processed: 0, slow path: 0
170 fast lock acquisition failures: 0, slow path: 0
171TCP 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.
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 65/63 prefixes, 71/69 paths, scan interval 60 secs
122 networks peaked at 09:56:39 Jan 11 2026 UTC (03:44:28.399 ago)
13
14Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
15172.25.2.2 4 65200 127 126 3 0 0 01:50:44 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 21, 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 iSimilarly, it is possible to see how R1 advertised 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 was then installed in 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:03:34As 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.
1R1(config-router)#bgp safe-ebgp-policyOnce 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.
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:03:05
5 Last read 00:00:26, last write 00:00:26, hold time is 180, keepalive interval is 60 seconds
6 BGP multisession with 2 sessions (2 established), first up for 00:03:05
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: 3 4
30 Route Refresh: 1 0
31 Total: 10 10
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: 4 4
41 Route Refresh: 1 0
42 Total: 9 8
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 105, Advertise bit 0
51 session 1 member
52 105 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 14:39:48 Jan 11 2026 UTC (00:03:06.607 ago)
73 Highest network count observed at 1 entries at 09:56:39 Jan 11 2026 UTC (04:46:15.607 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:00:57
78 Last Sent Refresh End-of-rib: 00:00:57
79 Refresh-Out took 0 seconds
80 Last Received Refresh Start-of-rib: 00:00:26
81 Last Received Refresh End-of-rib: 00:00:26
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 55, Advertise bit 0
93 session 2 member
94 55 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 1, 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:00:57
116 Last Sent Refresh End-of-rib: 00:00:57
117 Refresh-Out took 0 seconds
118 Last Received Refresh Start-of-rib: 00:00:26
119 Last Received Refresh End-of-rib: 00:00:26
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 2w0d
129 Connections established 150; dropped 148
130 Last reset 00:03:06, due to Neighbor reset of session 2
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: 31350
140Foreign host: 172.25.2.2, Foreign port: 179
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 0x89B9F980):
147Timer Starts Wakeups Next
148Retrans 8 0 0x0
149TimeWait 0 0 0x0
150AckHold 6 2 0x0
151SendWnd 0 0 0x0
152KeepAlive 0 0 0x0
153GiveUp 0 0 0x0
154PmtuAger 1 0 0x89C04BC7
155DeadWait 0 0 0x0
156Linger 0 0 0x0
157ProcessQ 0 0 0x0
158
159iss: 2070046441 snduna: 2070046732 sndnxt: 2070046732
160irs: 4037060639 rcvnxt: 4037060953
161
162sndwnd: 16094 scale: 0 maxrcvwnd: 16384
163rcvwnd: 16071 scale: 0 delrcvwnd: 313
164
165SRTT: 656 ms, RTTO: 2806 ms, RTV: 2150 ms, KRTT: 0 ms
166minRTT: 1 ms, maxRTT: 1000 ms, ACK hold: 200 ms
167uptime: 185725 ms, Sent idletime: 26986 ms, Receive idletime: 26986 ms
168Status Flags: active open
169Option Flags: nagle, path mtu capable
170IP Precedence value : 6
171
172Datagrams (max data segment is 1460 bytes):
173Rcvd: 14 (out of order: 0), with data: 8, total data bytes: 313
174Sent: 16 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 9, total data bytes: 290
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 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).
1Suppressing inbound/outbound propagation because policies are missingFor each address family where announcements have been sent or received, a reference to the command is shown.
1 Outbound Inbound
2 Local Policy Denied Prefixes: -------- -------
3 safe-ebgp-policy: 3 1In 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.
1 Sent Rcvd
2 Refresh activity: ---- ----
3 Refresh Start-of-RIB 1 1
4 Refresh End-of-RIB 1 1It’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.
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.
1R1#show bgp ipv4 unicast neighbors 172.25.2.2 advertised-routes
2
3Total 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.
1R1#show bgp ipv4 unicast summary
2[OUTPUT OMITTED]
32 networks peaked at 09:56:39 Jan 11 2026 UTC (01:51:47.999 ago)
4
5Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
6172.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.
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-familyThe following shows the initial configuration of R2 for this scenario.
1R2#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-familyActivating 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.
1Frame 10: 77 bytes on wire (616 bits), 77 bytes captured (616 bits)
2Ethernet 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)
3Internet Protocol Version 4, Src: 172.25.1.1, Dst: 172.25.2.2
4Transmission Control Protocol, Src Port: 42775, Dst Port: 179, Seq: 101, Ack: 82, Len: 23
5Border Gateway Protocol - UPDATE Message
6 Marker: ffffffffffffffffffffffffffffffff
7 Length: 23
8 Type: UPDATE Message (2)
9 Withdrawn Routes Length: 0
10 Total Path Attribute Length: 0Since 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.
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]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.