Enabling Secure Policies over eBGP Sessions in IOS XE
Overview
Introduction
Il ruolo del BGP nelle infrastrutture di backcone ha un ruolo chiave, poichè viene impiegato per annunciare le centinaia di migliaia di network attraverso l’Internet. Quando dunque si ha la necessità di creare un peering verso ad esempio un ISP è fondamentale assicurarsi che sia gli annunci ricevuti che quelli annunicati siano conformi a delle best-practice stabilita a livello globale. A tale scopo è stata fondata la Mutually Agreed Norms for Routing Security (MANRS), una community con lo scopo to implement crucial fixes needed to reduce the most common routing threats.
Com’è possile dunque mettere in sicurezza una neighbroship tra 2 peer fin dal principio? A tale scopo è stata pubblicato nel luglio 2017 l’RFC 8212 (che aggiornar l’originaria RFC 4271 A Border Gateway Protocol 4 (BGP-4)) in cui viene scritto qunato segue:
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.
Come si traduce questa statement lato implementazione di IOS XR e IOS XE? L’abilitazione menzionata nella RFC, si è tradotta lato implementativo, alla presenza di 1 / 2 routing policy in cui vengano delineati i criteri per cui una rotta possa essere annunicata / ricevuta applicata/e alla sessione verso il neighbor con cui si vuole stabilira la sessione di tipo external. Con la piattaform IOS XR tale comportamento è già implementato di default. Ogni qualvolta dunque che si coniura una sessoine eBGP è necessario dunque applicare almeno una routeing policy nelle direzioni sia di inbound che outbound. Con la piattaforma IOS XE invece, questa caratteristica non è presente di default. Quando dunque fa si che configurando una sessione eBGP con un peer remoto, questa permette fin da subito di scambiare network annuncements in both directions.
Default IOS XE Behavior
Partendo dunque dalla basilare topologia mostrata in figura, verifichiamo il comportamento didefault assunto dall’IOS XE. R1 ed R2 hanno 2 sessioni external MP-BGP. Come da figura, ciscuno dei 2 router annuncia 1 network relativa all?address family IPv4 Unicast /16 al rsipettivo peer.
Di eguito la configurazione di 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
Di seguito la configurazione di 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
exit-address-family
Per reference, di seguito è riportato l’output contenente tutte le finormazioni delle 2 sessioni tra R1 ed 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
Possiamo inoltre verificare come entrambi i peer ricevano le network dal peer remoto e la installino all’interno della RIB.
Verifichiamo dal seguente output come R1 abbia ricevuto un annuncio da 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
L’annuncio in questione è riportato in dettaglio con il seguente 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
Allo stesso modo verifichiamo come R1 abbia annunciato la network 10.10.0.0/14 al 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
Tale rotta è stata poi installata all’intenro della 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
Come confermato all’inizio, per l’IOS XE non vi sono alcun tipo di limitazioni relative agli annunci delle network.
Securing eBGP Sessions in IOS XE
In che modo è possibile allineare il comportamento delle 2 piattaforme? Alcuni anni fa è stato introdotto un nuovo comando da inserire all’interno della BGP conguration mode. Il comando in questione è bgp safe-ebgp-policy. Quest’ultimo permette di replicare il comportamento che si ha su l’IOS XR, anche su IOS XE.
Per procedere possiamo verificare 2 scenari: nel primo scenario il nuovo compando viene applicato quando la sessione MP-BGP tra i 2 peer è già stata stabilita. Nel secondo scenario invece, il comando viene applicato prima di stabliire la sessione.
Scenario 1: Securing an Already Established External MP-BGP Session
Con le 2 sessioni nello stato di Established inseriamo il nuovo comando riportato in precedenza all’interno della configurazione del router R1 e analizziamone i risultati. Le stesse considerazioni varrebbero inserendo lo stesso comando anche su R2.
R1(config-router)#bgp safe-ebgp-policy
Una volta inserito, tale comando triggera la generazione di alcuni messaggi BGP a tutti i peer. Tali messaggi, visto che sono presenti 2 address family (IPv4 e IPv6 unicast), vengaono contestualizzati per entrambe le sessioni.
Procedendo per step, verifichiamo inizialmente lo stato attuale della sesisone tra R1 ed R2. Di seguito l’output del usuale comando inserito su 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
Applicando li nuovo comando alla configurazione sono apparse delle nuove infomrazioni non presenti in precedenza. Sotto ogni address family è riportata la seguenete dicitura, che conferma quando detto all’inizio del post: ovvero che senza plicy applicate gli annunci ricevuti o inviati vengono “eliminati” (torneremo su questo concetto nel dettaglio tra poco).
Suppressing inbound/outbound propagation because policies are missing
Sempre per ogni address family per cui sono stati inviati o ricevuti degli annunci compare viene richiamato il riferimento al comando.
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
safe-ebgp-policy: 3 1
In generale poi sono aumentati i vari counter relativi alle tipologie di messaggi BGP inviati e ricevuti. Un esempio che salta subito all’occhio è la differenza tra i contatori relativi ai messaggi BGP ROUTE-REFRESH che da 0 sono stati incrementati (sia in trasmissione che ricezione).
Sent Rcvd
Refresh activity: ---- ----
Refresh Start-of-RIB 1 1
Refresh End-of-RIB 1 1
Di seguito è rioportata invece la sequenza dello scambio di pacchetti specifica per l’address famiy IPv4.
| 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 |
Da questa cattura si possono vedere 2 differenti operazioni:
- Con il pacchetto da #1 a #3, R1 ritira l’annuncio della network annunciata in precedenza ad R2.
- Con il pacchetto #11, R1 chiede ad R2 di re-inviare gli annunci. Con i pacchetti #14, #16, #19, R2 invia nuovamente gli annunci.
Ad avvalorare il primo punto, possiamo vedere come a differenza della precedente sezione, il comando di mostrante gli annunci inviati da R1 ad R2 non restituisca alcun risultato.
R1#show bgp ipv4 unicast neighbors 172.25.2.2 advertised-routes
Total number of prefixes 0
Contnuando con le altre verifiche, dal seguente output vediamo come il numero di annunci ricvevuti sia pari a 0. Inotlre è comparsa anche il !, per indicare l’assenza delle routing policy applicate al peer remoto.
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!
Lo stesso risultato si otterebbe specificando l’address family IPv6 Unicast.
Questi comportamenti sono in accordo con queanto riportato all’interno della Configuration Guide, seconod cui per ogni address family viene valuatata la presenza dellee routing policy per ciascun neighbor configurato.
Scenario 2: Securing an External MP-BGP Session at Session Establishment
Passiamo ora allo secondo scenario in cui, prima di attivare la neighborship, inseriamo il comando bgp safe-ebgp-policy su R1 e verifihciamo quanto succede.
Per poter proseguire, è necessario dunque effettuare delle modifiche alle configurazioni da entrambi i peer. Oltre a disabilitare il comando precedentemente inserito su R1, disabilitaimo le 2 sessioni. Disablitiamo poi anche l’attivazione automatica dell’address family IPv4 Unicast tramite li comando no bgp default ipv4-unicast.
Di seguito la conigurazione di partenza per questo scneario di R1.
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
Di seguito la conigurazione di partenza per questo scneario di R2.
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
Attivando ora il meccanismo di sicurezza sia su R1 che R2, non vi è alcun scambio di messaggi. Questo ovviamente perchè non c’è nessuna sessione nello stato di Established. Attiviamo ora le neighborship su entrambi R1 ed R2. Per semplicità eseguiamo la veriica solamente per l’address family IPv4 unicast. Rispetto al caso precedente c’è una differenza, di cui si avrebbe potuto sosposttare ancora prima di effettuare il test. Infatti, una volta che la sessione BGP ha raggiunto i 2 peer non si scambiano nessuna annuncio. I 2 peer si scambiano un uncio messaggio di update formattato come segue.
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
Non essendoci uno scambio di annunci, di conseguenza, non vi sono più i messaggi di tipo BGP ROUTE-REFRESH visti alla sezione precedente. I relativi contatori ripecchiano tale mancanza, essendo tutti posti a 0 come verificabile da 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
Per mettere in sicurezza le sessioni BGP di tipo external nelle piattaforme IOS XE, è caldamente consigliato utilizzare il comando introdotto in questo post, fin dal principio (e non in corso d’opera). Questa filosoia permette di avere un maggior controllo sugli annunci da annunciare e da ricevere, riducendo drasticamente eventuali errori che possono essere acilmente commettibili. La definizione di routeing policies da applicare a niehbor di tipo external, oltre ad essere customizzata per un determinato utlizzo, dovrebbe adottare le best practice a seconda della tipologia di peering da stabilire verso il peer remoto.