Cisco BGP Configuration Guide (IOS-XE, IOS-XR, NX-OS)

Original guide date Nov 8, 2026 · Enterprise review finalized Nov 13, 2026 · @Kerry Cordero

About this guide

This guide explains how to design, configure, verify and troubleshoot BGP on Cisco's three main network operating systems. It retains the original 13-chapter sequence, arranged to parallel the Junos OS BGP User Guide, so teams moving from Juniper can find comparable topics. The content is written for Cisco: Cisco defaults, Cisco command syntax and Cisco behaviour. Chapter 8 now points to the legacy CLNS appendix; modern deployments can skip it.

Conventions

• Each topic shows the config for IOS-XE, then IOS-XR, then NX-OS. Where two platforms share syntax, the guide says so.
• Documentation prefixes are 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 and 2001:db8::/32; some private-network examples also use RFC 1918 addresses. ASNs 64496-64511 and 65536-65551 are reserved for documentation, not production public-AS assignment. Private-use ASNs are 64512-65534 and 4200000000-4294967294. Do not advertise documentation prefixes or ASNs to the public Internet. S1 S2
• Placeholders are in angle brackets, for example <neighbor-ip>.
• IOS-XR examples leave out the final commit. Every IOS-XR change still needs one.
• Defaults and feature support change between releases. Check the exact device model, line card or ASIC, license, address family and software release before deployment. An operating-system family is not a feature-support guarantee.
• Configuration blocks are excerpts, not commands to concatenate into one router configuration. Existing interface, reachability and neighbor settings are assumed unless an example explicitly supplies them. Repeated ASNs and addresses do not mean every chapter shares one topology.
• Create prefix-lists, route-maps and route-policies before attaching them. Interface names and secrets must be adapted to the target device. Commands shown with optional brackets or angle-bracket placeholders are syntax descriptions, not paste-ready lines.

Validation status and how to use examples

This revision is a technical edit with targeted checks against Cisco documentation and RFCs, not a record of tests on physical or virtual Cisco devices. References identify the basis for significant corrections. Material retained from the original guide is not thereby certified for every release.

Appendix B is an integrated IOS-XE lab. Appendix C is a validation record to complete before approving a deployment. Advanced examples such as unnumbered BGP, PIC, TCP-AO, FlowSpec, MPLS VPN and EVPN need particular attention to hardware and release support.

Engineering recommendations in the design and test sections describe proposed practice, not an RFC requirement or a measured performance guarantee.

Contents

Key differences from Junos

• Groups vs. templates. Junos puts every neighbor in a group. Cisco uses peer-groups or peer templates on IOS-XE, neighbor-group/af-group/session-group on IOS-XR, and template peer on NX-OS.
• Policy default. Do not equate a permissive export default with advertising every route in the IP routing table. BGP advertises eligible BGP routes subject to its propagation rules and configured policy; connected or static routes are not automatically exported. IOS-XE and NX-OS commonly require explicit filters to constrain eligible advertisements. IOS-XR requires inbound and outbound policy for ordinary eBGP exchange; each missing direction is blocked. Use explicit policy rather than relying on defaults. S4 S9
• Address families. On Cisco, a neighbor must be activated under each address family. IOS-XE activates IPv4 unicast automatically unless you run no bgp default ipv4-unicast.
• Originating routes. Junos exports routes with a policy. Cisco uses network statements or redistribute under the address family.

Chapter 1 — BGP overview

BGP-4 (RFC 4271) is a path-vector exterior gateway protocol. It carries reachability between autonomous systems (ASes) and is the policy engine for large internal networks. BGP runs over TCP port 179 and sends incremental updates, not periodic full tables.

eBGP and iBGP

Message types

Finite state machine

BGP defines six states: Idle, Connect, Active, OpenSent, OpenConfirm and Established. They are not a mandatory linear progression: a successful connection can proceed from Connect directly to OpenSent; Active is associated with attempts to establish the TCP connection. S28 On Cisco, show bgp ... summary shows the state in the State/PfxRcd column. A number there means the session is Established and shows how many prefixes were received. A session stuck in Active usually means the TCP connection is failing: check reachability, the update-source, ACLs and the AS number.

Path attributes

Cisco best-path selection

For an eligible unicast path, the following is a practical baseline for Cisco best-path reasoning, not a universal specification for every AFI/SAFI and release. Next-hop reachability, loop checks and policy must first permit the path. Features such as RPKI validity-based selection, AIGP and VPN/EVPN-specific rules can add checks. S3 S9

1. Highest weight (Cisco-local).
2. Highest LOCAL_PREF.
3. Locally originated (network, redistribute, aggregate-address) over learned.
4. Lowest AIGP metric, if enabled.
5. Shortest AS_PATH (skipped with bgp bestpath as-path ignore; AS_SET counts as 1; confederation segments are not counted).
6. Lowest ORIGIN: IGP < EGP < incomplete.
7. Lowest MED (same neighbor AS only, unless bgp always-compare-med).
8. eBGP over iBGP (confederation-external counts as iBGP here).
9. Lowest IGP metric to the next hop.
10. If maximum-paths allows it, install multiple paths (the best path is still chosen below).
11. For eBGP paths, prefer the oldest path (skipped with bgp bestpath compare-routerid).
12. Lowest router ID (or ORIGINATOR_ID when reflected).
13. Shortest CLUSTER_LIST.
14. Lowest neighbor address.

Do not assume all three platforms implement every tie-breaker, knob or address-family exception identically. IOS-XE and NX-OS can set weight with neighbor configuration or a route-map; IOS-XR supports RPL set weight. Inspect show bgp ipv4 unicast <prefix> and, where available, IOS-XR show bgp ipv4 unicast <prefix> bestpath-compare. These commands explain BGP selection; verify the RIB and FIB separately. S3 S9

Policy precedence: which attribute actually wins?

These are reasoning examples for the same prefix, with reachable next hops and all earlier eligibility checks satisfied. S3

A more-specific prefix is a different forwarding choice, not a later BGP best-path tie-breaker. A permitted /25 can carry traffic instead of a /24 regardless of which /24 path has the highest local preference.

Design recommendation: define the intended preference once, document the attributes used at each routing boundary, and avoid overlapping weight, local-preference and prepend rules whose effects are difficult to explain.

Key standards supported

RFC 4271 (BGP-4), RFC 4760 (multiprotocol), RFC 4456 (route reflection), RFC 5065 (confederations), RFC 6793 (4-byte AS), RFC 2918/7313 (route refresh), RFC 4724 (graceful restart), RFC 7911 (add-path), RFC 6811 (RPKI origin validation), RFC 7606 (revised error handling), RFC 8092 (large communities), RFC 8212 (default eBGP policy), RFC 5925 (TCP-AO), RFC 5082 (GTSM), RFC 4364 (L3VPN), RFC 7432 (EVPN), RFC 8955 (flowspec). Check Cisco's feature navigator for support per release.

Chapter 2 — Basic BGP configuration

A working BGP session needs four things: a local AS, a router ID, a neighbor with its remote AS, and the neighbor activated in an address family. The examples in this chapter use this topology.

Point-to-point eBGP session

Scope: R1 configuration excerpts with complete routing-policy definitions. Configure the interfaces from the topology table first, confirm direct reachability, and configure R2 with the reciprocal neighbor. R1 accepts only a default route from R2 and exports only 203.0.113.0/24. Appendix B supplies both sides of an isolated IOS-XE lab.

The exact 203.0.113.0/24 route must exist in R1's RIB for the network statement to originate it. A discard route is shown only to make an isolated advertisement exercise deterministic. It is not evidence that a real destination is reachable. An unconditional Null0 aggregate can remain advertised after component routes disappear, blackholing traffic. For production, define the aggregation, withdrawal and downstream-reachability requirements first. S4

IOS-XE

ip route 203.0.113.0 255.255.255.0 Null0
!
ip prefix-list R2-DEFAULT-IN seq 10 permit 0.0.0.0/0
ip prefix-list R1-EXPORT seq 10 permit 203.0.113.0/24
!
route-map R2-IN permit 10
 match ip address prefix-list R2-DEFAULT-IN
route-map R2-OUT permit 10
 match ip address prefix-list R1-EXPORT
!
router bgp 64500
 bgp router-id 192.0.2.1
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 198.51.100.2 remote-as 64501
 neighbor 198.51.100.2 description R2-eBGP
 !
 address-family ipv4 unicast
  network 203.0.113.0 mask 255.255.255.0
  neighbor 198.51.100.2 activate
  neighbor 198.51.100.2 route-map R2-IN in
  neighbor 198.51.100.2 route-map R2-OUT out
 exit-address-family

IOS-XR

router static
 address-family ipv4 unicast
  203.0.113.0/24 Null0
!
prefix-set R2-DEFAULT-IN
  0.0.0.0/0
end-set
prefix-set R1-EXPORT
  203.0.113.0/24
end-set
!
route-policy R2-IN
  if destination in R2-DEFAULT-IN then
    pass
  else
    drop
  endif
end-policy
route-policy R2-OUT
  if destination in R1-EXPORT then
    pass
  else
    drop
  endif
end-policy
!
router bgp 64500
 bgp router-id 192.0.2.1
 address-family ipv4 unicast
  network 203.0.113.0/24
 !
 neighbor 198.51.100.2
  remote-as 64501
  description R2-eBGP
  address-family ipv4 unicast
   route-policy R2-IN in
   route-policy R2-OUT out

On ordinary IOS-XR eBGP sessions, missing policy blocks the affected direction even when the session is Established. Subsequent conceptual examples use the following explicitly permissive policy to avoid repeating long filters; PASS is a lab placeholder, not an Internet-edge policy. S9

route-policy PASS
  pass
end-policy

NX-OS

feature bgp
!
ip route 203.0.113.0/24 Null0
ip prefix-list R2-DEFAULT-IN seq 10 permit 0.0.0.0/0
ip prefix-list R1-EXPORT seq 10 permit 203.0.113.0/24
!
route-map R2-IN permit 10
 match ip address prefix-list R2-DEFAULT-IN
route-map R2-OUT permit 10
 match ip address prefix-list R1-EXPORT
!
router bgp 64500
 router-id 192.0.2.1
 log-neighbor-changes
 address-family ipv4 unicast
  network 203.0.113.0/24
 neighbor 198.51.100.2
  remote-as 64501
  description R2-eBGP
  address-family ipv4 unicast
   route-map R2-IN in
   route-map R2-OUT out

Define policies before referencing them. Do not use an undefined route-map as a substitute for an explicit deny-all policy; missing-policy handling can depend on platform settings and release.

Expected checks: R1 receives only 0.0.0.0/0 if R2 originates it, and R2 receives only 203.0.113.0/24. Confirm the advertisements on both peers. Test that an additional unwanted prefix is rejected. An Established session alone is not a pass condition.

iBGP session between loopbacks

iBGP peers usually use loopbacks, so the session survives a single link failure. The IGP (OSPF or IS-IS) must carry the loopbacks. The edge router sets itself as next hop for routes learned from eBGP.

IOS-XE

router bgp 64500
 neighbor 192.0.2.3 remote-as 64500
 neighbor 192.0.2.3 update-source Loopback0
 address-family ipv4 unicast
  neighbor 192.0.2.3 activate
  neighbor 192.0.2.3 next-hop-self
  neighbor 192.0.2.3 send-community both

IOS-XR

router bgp 64500
 neighbor 192.0.2.3
  remote-as 64500
  update-source Loopback0
  address-family ipv4 unicast
   next-hop-self

IOS-XR does not require a route-policy on iBGP neighbors and sends communities by default.

NX-OS

router bgp 64500
 neighbor 192.0.2.3
  remote-as 64500
  update-source loopback0
  address-family ipv4 unicast
   next-hop-self
   send-community both

The NX-OS send-community both form is documented for Nexus 9000 NX-OS 9.3(x). Confirm the supported syntax on older or different NX-OS releases. S33

Peer groups and templates

Grouping neighbors keeps config consistent and, on IOS-XE, lets the router build one update for many peers. This replaces the Junos group hierarchy.

IOS-XE (peer templates)

router bgp 64500
 template peer-session IBGP-SESSION
  remote-as 64500
  update-source Loopback0
 exit-peer-session
 template peer-policy IBGP-POLICY
  next-hop-self
  send-community both
 exit-peer-policy
 neighbor 192.0.2.3 inherit peer-session IBGP-SESSION
 address-family ipv4 unicast
  neighbor 192.0.2.3 activate
  neighbor 192.0.2.3 inherit peer-policy IBGP-POLICY

IOS-XR

router bgp 64500
 neighbor-group IBGP
  remote-as 64500
  update-source Loopback0
  address-family ipv4 unicast
   next-hop-self
 !
 neighbor 192.0.2.3
  use neighbor-group IBGP

NX-OS

router bgp 64500
 template peer IBGP
  remote-as 64500
  update-source loopback0
  address-family ipv4 unicast
   next-hop-self
   send-community both
 neighbor 192.0.2.3
  inherit peer IBGP

IPv6 peering

IPv6 uses the same process with the ipv6 unicast address family. For a link-local peer, name the interface the address belongs to.

IOS-XE

router bgp 64500
 neighbor 2001:db8:12::2 remote-as 64501
 neighbor FE80::2%GigabitEthernet0/0/1 remote-as 64501
 address-family ipv6 unicast
  network 2001:db8:100::/48
  neighbor 2001:db8:12::2 activate
  neighbor FE80::2%GigabitEthernet0/0/1 activate

The IOS-XE 17.x link-local peering documentation uses the scoped %interface form in both the neighbor definition and address-family activation. The global and link-local neighbors above are alternative peering methods; normally choose one for a link. Check the exact syntax on older releases rather than assuming an unscoped link-local address is interchangeable. IPv6 origination also requires an exact RIB match. S16

IOS-XR

router bgp 64500
 address-family ipv6 unicast
  network 2001:db8:100::/48
 neighbor 2001:db8:12::2
  remote-as 64501
  address-family ipv6 unicast
   route-policy PASS in
   route-policy PASS out
 neighbor fe80::2%GigabitEthernet0/0/0/1
  remote-as 64501
  address-family ipv6 unicast
   route-policy PASS in
   route-policy PASS out

NX-OS

router bgp 64500
 address-family ipv6 unicast
  network 2001:db8:100::/48
 neighbor 2001:db8:12::2
  remote-as 64501
  address-family ipv6 unicast
 neighbor fe80::2%Ethernet1/1
  remote-as 64501
  address-family ipv6 unicast

Dynamic neighbors and unnumbered BGP

Cisco's equivalent of Junos auto-discovered neighbors is dynamic neighbors: the router accepts sessions from any address in a prefix range. NX-OS also supports interface-based peering for unnumbered fabrics.

IOS-XE

router bgp 64500
 bgp listen range 10.10.0.0/16 peer-group SPOKES
 bgp listen limit 200
 neighbor SPOKES peer-group
 neighbor SPOKES remote-as 64500
 address-family ipv4 unicast
  neighbor SPOKES activate

Use neighbor SPOKES remote-as 64512 alternate-as 64513 64514 when spokes sit in different ASes.

IOS-XR - Dynamic neighbors are documented on supported IOS-XR platforms. A neighbor prefix supplies the allowed source range; remote-AS constraints and maximum-peers bound admission. This is not an assertion of support on every XR image. Example excerpt: S15

router bgp 64500
 address-family ipv4 unicast
 neighbor 10.10.0.0/16
  remote-as 64500
  maximum-peers 200
  address-family ipv4 unicast

Restrict the reachable source range and control-plane access. For dynamic eBGP, also define and attach inbound and outbound policies. Use explicit neighbors when that is operationally simpler.

NX-OS (prefix peering and interface peering)

These are alternative excerpts. This version uses an explicit remote ASN instead of an unrestricted remote-as external assumption or an undefined AS-admission route-map.

router bgp 64500
 neighbor 10.10.0.0/16
  remote-as 64501
  address-family ipv4 unicast
 !
 neighbor Ethernet1/1
  remote-as 64501
  address-family ipv4 unicast

Interface peering uses IPv6 link-local neighbor discovery. The documented Nexus 3600 NX-OS 10.3(x) form accepts an ASN or an AS-admission route-map. IPv4 reachability over an IPv6 next hop requires extended-next-hop support and matching forwarding capabilities. Configure and verify the interface IPv6 and router-advertisement prerequisites using the target platform's unnumbered-BGP procedure; an interface stanza from another Nexus family is not sufficient proof of support. S17

Verify the session

Chapter 3 — Session attributes

Session attributes change how one session behaves: which AS it presents, how it handles AS_PATH loops, how fast it detects failure and how many prefixes it accepts. The table maps each Junos statement to its Cisco command; config examples follow.

Local AS (AS migration)

Use local-as when you merge networks or change AS numbers and do not want peers to change their config. With no-prepend replace-as, the peer sees only the old AS; dual-as lets the peer use either AS while it migrates.

IOS-XE

router bgp 64500
 neighbor 198.51.100.2 remote-as 64501
 neighbor 198.51.100.2 local-as 64999 no-prepend replace-as dual-as

IOS-XR

router bgp 64500
 neighbor 198.51.100.2
  remote-as 64501
  local-as 64999 no-prepend replace-as dual-as

NX-OS

router bgp 64500
 neighbor 198.51.100.2
  remote-as 64501
  local-as 64999 no-prepend replace-as dual-as

Multihop eBGP to a loopback

Peering between loopbacks requires a working route to the peer's loopback and a matching return path. Disabling the connected check can support loopback peering between directly attached routers, but it does not raise the packet TTL. If intermediate routers exist, configure the appropriate multihop or TTL-security behavior. Verify that loopback reachability does not depend solely on the BGP session it is intended to establish.

IOS-XE

ip route 192.0.2.2 255.255.255.255 198.51.100.2
router bgp 64500
 neighbor 192.0.2.2 remote-as 64501
 neighbor 192.0.2.2 update-source Loopback0
 neighbor 192.0.2.2 ebgp-multihop 2

IOS-XR

router static address-family ipv4 unicast 192.0.2.2/32 198.51.100.2
router bgp 64500
 neighbor 192.0.2.2
  remote-as 64501
  update-source Loopback0
  ebgp-multihop 2

NX-OS

ip route 192.0.2.2/32 198.51.100.2
router bgp 64500
 neighbor 192.0.2.2
  remote-as 64501
  update-source loopback0
  ebgp-multihop 2

Do not configure ebgp-multihop and TTL security together as a generic cross-platform recipe. Their interaction and precedence are platform-dependent; choose the supported method and verify the transmitted and accepted TTL behavior. See Chapter 10.

BFD for fast failure detection

BFD can detect certain forwarding-path failures faster than the BGP hold timer. It does not guarantee subsecond traffic recovery. Configure the timers where the platform requires them, then inspect the actual negotiated session values. With an effective 300 ms transmit interval and multiplier 3, the nominal asynchronous detection time is about 900 ms; peer constraints can make it longer. S6 S18

IOS-XE

interface GigabitEthernet0/0/1
 bfd interval 300 min_rx 300 multiplier 3
router bgp 64500
 neighbor 198.51.100.2 fall-over bfd

For multihop BFD to a loopback, use neighbor <ip> fall-over bfd multi-hop with a bfd map and bfd-template multi-hop.

IOS-XR

router bgp 64500
 neighbor 198.51.100.2
  bfd fast-detect
  bfd minimum-interval 300
  bfd multiplier 3

NX-OS

feature bfd
interface Ethernet1/1
 bfd interval 300 min_rx 300 multiplier 3
 no ip redirects
router bgp 64500
 neighbor 198.51.100.2
  bfd

Failure detection is not traffic restoration

For asynchronous BFD, the local detection time uses the remote detection multiplier and the greater of the local required receive interval and remote desired transmit interval. Echo and demand modes have additional behavior. Read the operational session rather than inferring the result from one endpoint's configuration. S18

Treat recovery as a sequence of observable events:

These stages can overlap; their durations are not necessarily a simple arithmetic sum. Test physical link-down separately from silent packet loss while the interface remains up. Test router failure and control-plane restart separately as well. Chapter 6 covers the GR interaction, and Chapter 13 provides an acceptance matrix.

Maximum prefix

Set a prefix limit appropriate to each eBGP peer and address family. As a planning example, expected count plus 20-50% headroom and an 80% warning may suit a stable private peer; growth and full-table peers need different sizing. Verify whether the platform counts accepted or received prefixes and what it does on overflow. A session-shutdown limit without automatic restart typically requires operator intervention; warning-only does not enforce a hard route-count ceiling. Repeated restart attempts can cause a flap cycle if the peer keeps exceeding the limit. This threshold selection is an engineering recommendation, not a protocol default.

IOS-XE

router bgp 64500
 address-family ipv4 unicast
  neighbor 198.51.100.2 maximum-prefix 1000 80 restart 15

IOS-XR

router bgp 64500
 neighbor 198.51.100.2
  address-family ipv4 unicast
   maximum-prefix 1000 80 restart 15

NX-OS

router bgp 64500
 neighbor 198.51.100.2
  address-family ipv4 unicast
   maximum-prefix 1000 80 restart 15

Remove private AS numbers

A provider that gives private ASNs to customers strips them before advertising to the internet. Add all (IOS-XE, NX-OS) or entire-aspath (IOS-XR) to remove private ASNs even when public ones appear in the path.

! IOS-XE
router bgp 64500
 address-family ipv4 unicast
  neighbor 198.51.100.2 remove-private-as all

! IOS-XR
router bgp 64500
 neighbor 198.51.100.2
  address-family ipv4 unicast
   remove-private-AS entire-aspath

! NX-OS
router bgp 64500
 neighbor 198.51.100.2
  address-family ipv4 unicast
   remove-private-as all

Router ID and 4-byte ASNs

Set the router ID explicitly to keep its identity stable across process restarts and configuration changes; an interface-down event does not necessarily cause immediate reselection. All three platforms support 4-byte ASNs (RFC 6793). IOS-XE shows them in asplain (4200000000) by default; use bgp asnotation dot to show asdot (64086.59904). IOS-XR and NX-OS accept either form in config.

Chapter 4 — Session policies

Policy decides which routes a session accepts and advertises, and with which attributes. Junos uses policy-statement with import and export. Cisco uses route-maps with prefix-lists on IOS-XE and NX-OS, and Route Policy Language (RPL) on IOS-XR.

How the policy languages compare

Policy semantics that prevent accidental leaks

IOS-XE and NX-OS: the inbound BGP route-map attachment for a neighbor/address-family references one route-map, not a stack of independently configured maps. Attaching a new named map replaces that attachment. Combine mandatory filtering and attribute changes in one deliberately constructed policy. Other mechanisms such as a neighbor prefix-list may coexist, but they do not make multiple inbound route-map attachments additive. S4 S11

In a conventional route-map, a matching permit sequence normally finishes processing unless an explicitly supported continuation mechanism is configured. A permit sequence with no match conditions is a catch-all. Distinct match types in one sequence impose combined requirements; multiple entries of the same match type need their own semantics checked. A deny inside a referenced prefix-list means that list does not match the route; it is not automatically a route-map-level rejection. S11

IOS-XR: pass permits a route unless later dropped; a set action can also grant acceptance; done accepts and terminates evaluation; drop rejects and terminates. A route reaches the implicit drop only if it has not acquired an accepting disposition. Therefore, an unconditional set before restrictive tests can inadvertently accept routes. Prefer explicit rejection of unauthorized destinations before changing attributes. S5

The next three examples deliberately use different names. They teach separate mechanisms; they are not complete customer-edge policies. The integrated example that follows combines them.

Prefix filtering

This example accepts only 10.0.0.0/8 routes between /16 and /24 from a customer, and advertises only your own aggregate.

IOS-XE / NX-OS

ip prefix-list CUST-PREFIX-IN seq 10 permit 10.0.0.0/8 ge 16 le 24
ip prefix-list MY-AGG seq 10 permit 203.0.113.0/24
!
route-map CUST-PREFIX-IN permit 10
 match ip address prefix-list CUST-PREFIX-IN
route-map CUST-PREFIX-OUT permit 10
 match ip address prefix-list MY-AGG

IOS-XR

prefix-set CUST-PREFIX-IN
  10.0.0.0/8 ge 16 le 24
end-set
prefix-set MY-AGG
  203.0.113.0/24
end-set
!
route-policy CUST-PREFIX-IN
  if destination in CUST-PREFIX-IN then
    pass
  endif
end-policy
route-policy CUST-PREFIX-OUT
  if destination in MY-AGG then
    pass
  endif
end-policy

AS path filtering

This standalone example allows an AS_SEQUENCE from customer AS 64510, optionally followed by its downstream AS 64511. Repeated occurrences of either ASN are allowed in their respective positions to accommodate prepending. It is not a substitute for a destination-prefix allowlist. S8

IOS-XE

ip as-path access-list 10 permit ^64510(_64510)*(_64511)*$
route-map CUST-ASPATH-IN permit 10
 match as-path 10

IOS-XR

as-path-set CUST-PATHS
  ios-regex '^64510(_64510)*(_64511)*$'
end-set
route-policy CUST-ASPATH-IN
  if as-path in CUST-PATHS then
    pass
  else
    drop
  endif
end-policy

NX-OS

ip as-path access-list CUST-PATHS permit "^64510(_64510)*(_64511)*$"
route-map CUST-ASPATH-IN permit 10
 match as-path CUST-PATHS

Test permitted paths such as 64510, 64510 64510, and 64510 64511, and rejected paths such as 64510 64512 and 64511. This deliberately narrow expression does not define a policy for arbitrary AS_SET or confederation segments.

Communities

Cisco supports standard (RFC 1997), extended (RFC 4360) and large (RFC 8092) communities. IOS-XE does not send communities until you add send-community; NX-OS also needs it; IOS-XR sends them to iBGP peers by default and to eBGP peers only with send-community-ebgp. Turn on ip bgp-community new-format on IOS-XE so communities display as AS:value.

IOS-XE — tag customer routes and set local preference from a community the customer sends

ip bgp-community new-format
ip community-list standard CUST-BACKUP permit 64500:80
!
route-map CUST-COMM-IN permit 10
 match community CUST-BACKUP
 set local-preference 80
 set community 64500:1000 additive
route-map CUST-COMM-IN permit 20
 set community 64500:1000 additive
!
router bgp 64500
 address-family ipv4 unicast
  neighbor 198.51.100.6 send-community both
  neighbor 198.51.100.6 route-map CUST-COMM-IN in

IOS-XR

community-set CUST-BACKUP
  64500:80
end-set
!
route-policy CUST-COMM-IN
  if community matches-any CUST-BACKUP then
    set local-preference 80
  endif
  set community (64500:1000) additive
  pass
end-policy
!
router bgp 64500
 neighbor 198.51.100.6
  address-family ipv4 unicast
   send-community-ebgp
   route-policy CUST-COMM-IN in

NX-OS

ip community-list standard CUST-BACKUP permit 64500:80
route-map CUST-COMM-IN permit 10
 match community CUST-BACKUP
 set local-preference 80
 set community 64500:1000 additive
route-map CUST-COMM-IN permit 20
 set community 64500:1000 additive
router bgp 64500
 neighbor 198.51.100.6
  address-family ipv4 unicast
   send-community
   route-map CUST-COMM-IN in

Large communities use ip large-community-list and set large-community on IOS-XE and NX-OS, and large-community-set with set large-community on IOS-XR.

Additive communities: preserve tags instead of overwriting them

What “BGP additive” means: there is no universal bgp additive command. In day-to-day enterprise BGP discussions, additive usually refers to set community ... additive (and, when supported, adding extended/large communities). It means keep the communities already attached to this route and append the specified community. It is different from both maximum-paths and the BGP Additional Paths (Add-Path) capability in Chapter 5. S34 S35

The 10.200.0.0/21 range below is an illustrative RFC 1918 placeholder, not a published organizational allocation. Replace it with the prefixes explicitly authorized for your environment.

IOS-XE — add an enterprise-origin tag while preserving existing tags:

ip prefix-list APP-ROUTES seq 10 permit 10.200.0.0/21 le 24
!
route-map APP-TAG-IN permit 10
 match ip address prefix-list APP-ROUTES
 set community 64500:300 additive
!
router bgp 64500
 address-family ipv4 unicast
  neighbor 198.51.100.2 route-map APP-TAG-IN in

IOS-XR — same RPL intent:

prefix-set APP-ROUTES
  10.200.0.0/21 le 24
end-set
!
route-policy APP-TAG-IN
  if destination in APP-ROUTES then
    set community (64500:300) additive
    pass
  else
    drop
  endif
end-policy
!
router bgp 64500
 neighbor 198.51.100.2
  address-family ipv4 unicast
   route-policy APP-TAG-IN in

NX-OS — same route-map intent:

ip prefix-list APP-ROUTES seq 10 permit 10.200.0.0/21 le 24
!
route-map APP-TAG-IN permit 10
 match ip address prefix-list APP-ROUTES
 set community 64500:300 additive
!
router bgp 64500
 neighbor 198.51.100.2
  address-family ipv4 unicast
   route-map APP-TAG-IN in

The sample inbound policies permit only the illustrated application routes. They are feature excerpts: merge this tag action into the neighbor's already approved prefix/AS-path/RPKI policy, rather than attaching APP-TAG-IN and unintentionally replacing that policy. additive applies to the community attribute, not to route-map attachments. S34

Operational considerations:

• Adding a community locally does not mean that the neighbor receives it. Configure the appropriate send-community capability in the outbound direction toward the next BGP speaker, and verify the advertised route. Don't assume standard, extended and large communities have identical defaults.
• An inbound community tag is useful for classifying routes by source (Internet transit, cloud attachment, WAN region or customer), then setting local preference or controlling later exports. A standard community does not by itself alter best-path selection; your routing policy must interpret it.
• Avoid accidentally overwriting existing no-export, no-advertise or provider-required communities. Treat removal of existing communities as an explicit policy decision.
• IOS-XE route-map ... continue can accumulate additive community operations across sequences, but it can also change policy control flow. Do not introduce continue simply to mimic stacking multiple inbound route-maps. S36

Verification: compare the route's communities before and after policy, then inspect advertised routes toward the actual next neighbor. Useful commands include show bgp ipv4 unicast <prefix> (IOS-XE/NX-OS/IOS-XR) and platform-specific neighbor advertised-route views from Chapter 2. Test a route that already carries two communities: confirm that both survive and the new tag is present.

Integrated inbound policy: prefix, AS path, RPKI and communities

Scope: isolated customer-policy exercise, not a transit-provider filter. Customer AS 64510 at 192.0.2.2 may originate only 198.51.100.0/24, including its own AS prepends. The recognized backup community is 64500:80. All accepted routes receive an internal source tag, 64500:1000. Other prefixes and unexpected AS paths are rejected.

The RPKI check assumes that origin validation and the cache have already been configured as described in Chapter 10. Documentation addresses and ASNs must stay in a lab; exercising Valid and Invalid outcomes requires controlled lab validation data, not fabricated claims about public ROAs. The configuration below composes the existing mechanisms into one attachment. Its acceptance matrix is a proposed test, not captured device output. S5 S8 S12

IOS-XE

ip prefix-list CUSTOMER-ALLOWED seq 10 permit 198.51.100.0/24
ip as-path access-list 110 permit ^64510(_64510)*$
ip community-list standard CUSTOMER-BACKUP permit 64500:80
!
route-map CUSTOMER-IN deny 5
 match rpki invalid
route-map CUSTOMER-IN permit 10
 match ip address prefix-list CUSTOMER-ALLOWED
 match as-path 110
 match community CUSTOMER-BACKUP
 set local-preference 80
 set community 64500:1000 additive
route-map CUSTOMER-IN permit 20
 match ip address prefix-list CUSTOMER-ALLOWED
 match as-path 110
 set local-preference 150
 set community 64500:1000 additive
route-map CUSTOMER-IN deny 100
!
router bgp 64500
 neighbor 192.0.2.2 remote-as 64510
 address-family ipv4 unicast
  neighbor 192.0.2.2 activate
  neighbor 192.0.2.2 route-map CUSTOMER-IN in

NX-OS adaptation: use the same prefix-list, community-list and route-map sequences, but define a named AS-path list and replace both match as-path 110 lines with match as-path CUSTOMER-PATHS. Attach the map in the neighbor address family:

ip as-path access-list CUSTOMER-PATHS permit "^64510(_64510)*$"
!
router bgp 64500
 neighbor 192.0.2.2
  remote-as 64510
  address-family ipv4 unicast
   route-map CUSTOMER-IN in

IOS-XR

prefix-set CUSTOMER-ALLOWED
  198.51.100.0/24
end-set
as-path-set CUSTOMER-PATHS
  ios-regex '^64510(_64510)*$'
end-set
community-set CUSTOMER-BACKUP
  64500:80
end-set
!
route-policy CUSTOMER-IN
  if validation-state is invalid then
    drop
  elseif destination in CUSTOMER-ALLOWED and as-path in CUSTOMER-PATHS then
    if community matches-any CUSTOMER-BACKUP then
      set local-preference 80
    else
      set local-preference 150
    endif
    set community (64500:1000) additive
    pass
  else
    drop
  endif
end-policy
!
router bgp 64500
 address-family ipv4 unicast
 neighbor 192.0.2.2
  remote-as 64510
  address-family ipv4 unicast
   route-policy CUSTOMER-IN in

Only the inbound side is shown. Define a separate explicit outbound allowlist, maximum-prefix policy and session protections before deployment. Decide which externally received communities are authorized to affect internal policy; adding an internal tag does not sanitize pre-existing tags.

Do not subsequently attach an RPKI-only or community-only map to this neighbor and assume the prefix and AS-path checks remain in effect. Edit or replace the combined policy deliberately.

Traffic engineering with attributes

Route direction is not traffic direction. An inbound policy changes routes learned from a neighbor; those routes usually govern traffic leaving your network toward the advertised destinations. An outbound policy changes advertisements sent to a neighbor and can influence traffic arriving at your advertised prefixes. Neither statement means that policy rewrites packets.

A remote AS can override your prepending or MED with its own local preference, communities or other policies. Record both the desired outbound exit and the desired inbound entry, and verify each from the appropriate side. A symmetric-looking configuration does not prove symmetric traffic flow. S3

Conditional advertisement

Advertise a backup route only when the primary disappears.

! IOS-XE
router bgp 64500
 address-family ipv4 unicast
  neighbor 198.51.100.2 advertise-map BACKUP-PFX non-exist-map PRIMARY-PFX

! NX-OS
router bgp 64500
 neighbor 198.51.100.2
  address-family ipv4 unicast
   advertise-map BACKUP-PFX non-exist-map PRIMARY-PFX

Do not assume an arbitrary RPL condition is a drop-in replacement for IOS-XE advertise-map behavior. IOS-XR support, permitted policy attach points and re-evaluation triggers must be established for the exact release. Test both withdrawal and restoration of the tracked route; a condition checked only during an update does not by itself prove continuous conditional advertisement.

Default route to a neighbor

! IOS-XE
neighbor 198.51.100.6 default-originate [route-map <name>]
! IOS-XR (per AF)
default-originate [route-policy <name>]
! NX-OS (per AF)
default-originate [route-map <name>]

The unqualified default-originate form can generate a default advertisement without proving that the router has a usable upstream default. This is different from network 0.0.0.0 backed by a matching RIB route. Select a supported condition that represents the intended upstream health and test its loss; otherwise a router can continue attracting traffic it cannot forward. S4

Route aggregation and controlled advertisement

Enterprise WAN and cloud designs often originate aggregates rather than hundreds of individual component prefixes. aggregate-address ... summary-only constructs a BGP aggregate when qualifying more-specific BGP routes exist and suppresses covered specifics from normal BGP advertisement. It is not a permanent promise that the aggregate remains reachable when its components or next hops disappear. S37 S38 S39

IOS-XE

router bgp 64500
 address-family ipv4 unicast
  aggregate-address 10.200.0.0 255.255.248.0 summary-only

IOS-XR

router bgp 64500
 address-family ipv4 unicast
  aggregate-address 10.200.0.0/21 summary-only

NX-OS

router bgp 64500
 address-family ipv4 unicast
  aggregate-address 10.200.0.0/21 summary-only

Decision point: BGP aggregation summarizes reachability; it is not a substitute for valid forwarding toward every component prefix. Test the presence and withdrawal of contributing routes, summary-only suppression, the outbound allowlist, and any summary-to-Null0 approach used for locally originated network statements. Beware of accidentally advertising a broad aggregate into a site that cannot reach all destinations. Compare this with the network statement and conditional default-originate in this chapter.

Outbound route filtering (ORF)

With prefix-based ORF, the receiving router can send its inbound filter to its advertising peer, asking that peer to filter outbound updates before transmission. Both ends need the corresponding capability and configuration. Retain local inbound policy as the enforcement boundary; ORF is not a replacement for it.

! IOS-XE
neighbor 198.51.100.2 prefix-list CUST-IN in
neighbor 198.51.100.2 capability orf prefix-list both
! IOS-XR (per AF)
orf route-policy ORF-POLICY
capability orf prefix both

Applying policy changes

After a policy change, ask the peer to resend its routes rather than resetting the session. All three platforms support route refresh (RFC 2918) and enhanced route refresh (RFC 7313).

IOS-XR can reprocess affected policy after commit. NX-OS documents automatic BGP soft clear or refresh on route-map changes, so a manual clear is not universally required. On IOS-XE, use a neighbor-scoped soft refresh when needed to re-evaluate previously learned or advertised routes. Confirm the behavior on the target release and verify the resulting routes rather than relying on the absence of a session reset. S11 S4

Route refresh and inbound soft reconfiguration are different: refresh requests updates from the peer; soft reconfiguration retains an unfiltered local copy and consumes additional memory. received-routes availability is not proof that this copy exists on every platform. Avoid enabling it for every full-table peer solely for convenience. Hard clears disrupt sessions; use them only when explicitly required by the change.

Chapter 5 — Load balancing and enterprise multipath

By default, Cisco installs one best BGP path per prefix. maximum-paths installs several equal paths in the forwarding table; the best path is still the only one advertised to peers unless you enable add-path. This replaces the Junos multipath statement.

What makes paths equal

Multipath candidates must satisfy the platform and address-family eligibility rules. Compare weight, local preference, AS_PATH length, origin, MED and next-hop IGP cost, together with the applicable neighboring-AS and AS_PATH restrictions. Where supported, multipath-relax relaxes AS-path-related eligibility; it does not make unequal local preference or weight equivalent. Confirm the chosen paths and actual installed next hops. S8 S9

Multipath to two upstreams

IOS-XE

router bgp 64500
 bgp bestpath as-path multipath-relax
 address-family ipv4 unicast
  maximum-paths 4
  maximum-paths ibgp 4

IOS-XR

router bgp 64500
 bgp bestpath as-path multipath-relax
 address-family ipv4 unicast
  maximum-paths ebgp 4
  maximum-paths ibgp 4

NX-OS

router bgp 64500
 bestpath as-path multipath-relax
 address-family ipv4 unicast
  maximum-paths 4
  maximum-paths ibgp 4

Unequal IGP cost is platform-specific. Do not use the IOS-XR argument order as a generic IOS-XE command. The Cisco IOS/IOS-XE command reference documents maximum-paths ibgp unequal-cost <n> in a supported VRF address-family context, while IOS-XR documents maximum-paths ibgp <n> unequal-cost. Check the exact image and AF before using either. S8 S9

! IOS-XE: supported VRF context only; CUST-A must already exist
router bgp 64500
 address-family ipv4 vrf CUST-A
  maximum-paths ibgp unequal-cost 4

! IOS-XR: supported platform and address family
router bgp 64500
 address-family ipv4 unicast
  maximum-paths ibgp 4 unequal-cost

Allowing different IGP next-hop costs is not the same as allocating traffic in proportion to link bandwidth. Neither option overrides all earlier BGP attribute requirements.

Enterprise implementation guide — maximum-paths versus multipath-relax

These commands solve different problems. maximum-paths enables multiple eligible paths to enter the RIB/FIB. AS-path multipath-relax broadens which otherwise-qualified paths can count as equivalent for multipath. Neither command overrides earlier BGP preferences such as weight or local preference; neither guarantees equal traffic utilization, and neither advertises multiple paths to an iBGP peer (that is the separate Add-Path feature). S40 S41 S42

IOS-XE — dual eBGP paths, including different upstream ASes:

router bgp 64500
 bgp bestpath as-path multipath-relax
 address-family ipv4 unicast
  maximum-paths 2

IOS-XR — equivalent address-family controls:

router bgp 64500
 bgp bestpath as-path multipath-relax
 address-family ipv4 unicast
  maximum-paths ebgp 2

NX-OS — equivalent address-family controls:

router bgp 64500
 bestpath as-path multipath-relax
 address-family ipv4 unicast
  maximum-paths 2

These are configuration fragments, assuming two already-established and properly filtered eBGP neighbors. In production, first test maximum-paths without multipath-relax and introduce relaxation only when the desired paths are blocked by AS-path equality rules. The path's origin, MED, weight, local preference, next-hop reachability, neighboring-AS rules and any additional platform-specific checks still matter. NX-OS also documents per-VRF scope for some multipath use cases. S40

Worked example — two cloud or carrier attachments for the same prefix:

Destination prefix: 203.0.113.0/24  (documentation only)
Path A: neighbor AS 64510, AS_PATH 64510 64496, LOCAL_PREF 100, valid next hop
Path B: neighbor AS 64520, AS_PATH 64520 64496, LOCAL_PREF 100, valid next hop

Both paths have AS_PATH length 2 but DIFFERENT AS_PATH content.
With maximum-paths 2 alone, default AS-path matching will prevent ECMP
between these two different neighboring ASes: only one path is installed.
With maximum-paths 2 + multipath-relax: both may qualify for ECMP,
provided every other required eligibility test passes.

Now change Path B's LOCAL_PREF to 80:
Path A should remain preferred; multipath-relax does not equalize preference.

Site-preference versus load-sharing: A fictional four-site design (Site A, Site B, Site C and Site D) may use progressively greater AS-path prepends so that one site is preferred and another is standby. That is a primary/backup strategy, not ECMP across metros. For ECMP within a metro, keep the intended parallel attachments equivalent. For standby metro preference, retain the deliberate asymmetry in attributes rather than adding multipath relaxation globally. Different inbound versus outbound policy directions still apply.

Verification and acceptance test:

1. Confirm the prefix has multiple eligible BGP paths: show bgp ipv4 unicast <prefix> and neighbor detail.
2. Confirm RIB next hops, not just BGP multipath labels: IOS-XE/NX-OS show ip route <prefix>; IOS-XR show route <prefix>.
3. Confirm FIB next hops: IOS-XE show ip cef <prefix> detail; IOS-XR show cef <prefix> detail; NX-OS platform forwarding-route view.
4. Generate many distinct flows to validate distribution, then remove one carrier and measure usable traffic restoration and surviving-link capacity. An even path count is not an even throughput guarantee.
5. Test what happens when Local Preference, MED, AS-path prepending or next-hop IGP cost changes. Record which check removes a path from the multipath set.

Advertising more than one path (add-path)

Route reflectors normally advertise a selected path, which can hide alternatives from clients. Add-Path (RFC 7911) can advertise additional paths for the same prefix after capability negotiation. It exposes alternatives; it does not itself enable ECMP, install a backup in hardware or guarantee faster recovery. The receiver still needs the applicable multipath or protection configuration. S21

IOS-XE (on the reflector)

router bgp 64500
 address-family ipv4 unicast
  bgp additional-paths select best 2
  bgp additional-paths send receive
  neighbor 192.0.2.3 advertise additional-paths best 2

IOS-XR

route-policy ADD-PATH
  set path-selection all advertise
end-policy
router bgp 64500
 address-family ipv4 unicast
  additional-paths receive
  additional-paths send
  additional-paths selection route-policy ADD-PATH

NX-OS

route-map ADD-PATH permit 10
 set path-selection all advertise
router bgp 64500
 address-family ipv4 unicast
  additional-paths send
  additional-paths receive
  additional-paths selection route-map ADD-PATH
 neighbor 192.0.2.3
  address-family ipv4 unicast
   capability additional-paths send
   capability additional-paths receive

BGP Prefix Independent Convergence (PIC)

BGP PIC uses forwarding structures that reduce the need to update every affected prefix individually. PIC Core protects reachability toward a BGP next hop; PIC Edge needs a usable alternate BGP exit. Supported implementations can switch rapidly to precomputed forwarding alternatives, but detection, backup availability, encapsulation and hardware support determine the result. Do not assume PIC is enabled by default or that a single additional-paths command guarantees subsecond recovery. The excerpts below require platform/AF validation and confirmation of the backup in the FIB. S24

! IOS-XE
router bgp 64500
 address-family ipv4 unicast
  bgp additional-paths install

! IOS-XR
route-policy BACKUP
  set path-selection backup 1 install
end-policy
router bgp 64500
 address-family ipv4 unicast
  additional-paths selection route-policy BACKUP

! NX-OS
router bgp 64500
 address-family ipv4 unicast
  additional-paths install backup

Check with show bgp ipv4 unicast <prefix>: the backup path is marked backup/repair (IOS-XE, IOS-XR) or backup (NX-OS).

Verify load sharing

ECMP is not a bandwidth guarantee

maximum-paths controls how many eligible paths can be installed. The forwarding implementation chooses among them, commonly by hashing packet fields. A single flow need not use every link, and equal-cost paths need not carry equal byte counts. Inspect the actual platform's hash fields and forwarding behavior. S23

Design and validation recommendations: test with multiple independent flows, inspect per-link counters and drops, and repeat after a path fails. ECMP over two 10 Gbps links does not promise 20 Gbps for one flow. If each link carries 6 Gbps and one fails, the surviving 10 Gbps link cannot carry the combined 12 Gbps offered load without congestion; this is a capacity calculation, not a BGP defect. Include downstream bottlenecks in the same review.

Validate three separate outcomes: multiple candidates in BGP, multiple usable next hops in the FIB, and acceptable traffic distribution under the intended workload.

Chapter 6 — Graceful restart, NSR and graceful shutdown

These features address different failure or maintenance conditions. NSR depends on supported state replication; graceful restart depends on surviving forwarding state and peer behavior; graceful shutdown drains traffic before planned work. Do not enable GR everywhere as an unconditional resiliency default. Choose the mechanisms against the failure model and validate their interaction with BFD. S7

Graceful restart

IOS-XE

router bgp 64500
 bgp graceful-restart
 bgp graceful-restart restart-time 120
 bgp graceful-restart stalepath-time 360

IOS-XR

router bgp 64500
 bgp graceful-restart
 bgp graceful-restart restart-time 120
 bgp graceful-restart stalepath-time 360

NX-OS (on by default)

router bgp 64500
 graceful-restart
 graceful-restart restart-time 120
 graceful-restart stalepath-time 300

Verify with show bgp ipv4 unicast neighbors <ip> (IOS-XE, NX-OS) or show bgp neighbor <ip> (IOS-XR). Look for graceful restart in the capabilities, advertised and received.

BFD and graceful restart must be tested together

GR asks a helper to retain stale routes during a restart; that is useful only if forwarding remains viable. BFD can help distinguish a forwarding failure from control-plane disruption when its implementation survives the latter. The BFD Control Plane Independent bit and the platform's integration determine how to interpret a BFD-down event. S7

Cisco's documented IOS-XE cBit integration distinguishes whether to purge routes or continue NSF during a BFD event. Do not infer that behavior from the configured BFD interval, or assume it applies identically to all peers. S6

Recommended lab cases: a physical circuit loss; a silent forwarding failure with carrier still up; a BGP-process restart while forwarding remains intact; and a full router or metro failure. For each, record whether routes became stale or were removed, whether a backup was installed, and how much bidirectional traffic was lost. Retaining stale routes during an actual forwarding failure is not successful recovery.

Nonstop routing

! IOS-XE (dual RP, SSO)
redundancy
 mode sso
router bgp 64500
 bgp ha-mode sso

! IOS-XR
router bgp 64500
 nsr

! NX-OS: stateful restart of the BGP process is built in on dual-supervisor systems

Check NSR readiness with show bgp nsr (IOS-XR) or show bgp ha sso summary (IOS-XE).

Graceful shutdown before maintenance

Activate graceful shutdown before planned work, then verify that both inbound and outbound traffic have drained sufficiently before taking the component down. The wait period is an operational decision, not proof that all remote ASes honored the signal. Remove the maintenance state in a controlled restoration step. Ensure standard communities are sent where the mechanism relies on 65535:0.

! IOS-XE: selected-neighbor maintenance (preferred when only one link is changing)
router bgp 64500
 neighbor 198.51.100.2 shutdown graceful 180 local-preference 20

! IOS-XE: router-wide maintenance (affects ALL neighbors; separate configure/activate steps)
router bgp 64500
 bgp graceful-shutdown all neighbors 180 local-preference 20
 bgp graceful-shutdown all neighbors activate

! IOS-XR
router bgp 64500
 graceful-maintenance activate all-neighbors
 neighbor 198.51.100.2
  graceful-maintenance
   local-preference 0
   as-prepends 3

! NX-OS
router bgp 64500
 graceful-shutdown activate

For IOS-XE, the shutdown graceful <seconds> neighbor form and the bgp graceful-shutdown all neighbors <seconds> ... plus activate router-wide form are distinct procedures; a single combined activate local-preference line is not valid. The neighbor-specific procedure adds the well-known GSHUT community by default; community propagation and the far end's inbound policy still determine the drain outcome. The router-wide procedure will shut down every affected neighbor after its timer: do not use it for a single-carrier change. S31

To honor the GRACEFUL_SHUTDOWN community (65535:0), the receiving AS should match it in its inbound policy and reduce local preference where appropriate. Do not blindly append an additional route-map that replaces the existing prefix, RPKI or leak-prevention filters. Check the NX-OS release's graceful-shutdown aware behavior and all applicable policy interactions.

Chapter 7 — Multiprotocol BGP

Multiprotocol BGP (MP-BGP, RFC 4760) carries many kinds of routes over one session. Each kind is an address family (AFI/SAFI). Junos lists them under family; Cisco configures them as address-family blocks, both globally and per neighbor. Peers must agree on an address family in their OPEN messages, or it stays inactive.

This table is a family-name comparison, not a supported-feature matrix. Hardware, software image and licensing may prevent a listed family from being configured or forwarded. A negotiated AF also does not supply the necessary data plane: verify native IP, MPLS, VXLAN or SRv6 forwarding separately.

Example: IPv4, IPv6 and VPNv4 on one iBGP session

IOS-XE

router bgp 64500
 no bgp default ipv4-unicast
 neighbor 192.0.2.3 remote-as 64500
 neighbor 192.0.2.3 update-source Loopback0
 address-family ipv4 unicast
  neighbor 192.0.2.3 activate
 exit-address-family
 address-family ipv6 unicast
  neighbor 192.0.2.3 activate
 exit-address-family
 address-family vpnv4
  neighbor 192.0.2.3 activate
  neighbor 192.0.2.3 send-community extended
 exit-address-family

Transporting an IPv6 address family over an IPv4 TCP session does not by itself supply native IPv6 forwarding or a complete 6PE service. Check the negotiated capabilities and advertised next-hop encoding, and ensure the resulting next hop resolves through the intended data plane. For a basic native dual-stack deployment, separate IPv4 and IPv6 peerings are often easier to verify. Treat 6PE as a separate labeled-forwarding design, not an automatic result of activating ipv6 unicast.

IOS-XR

router bgp 64500
 address-family ipv4 unicast
 address-family ipv6 unicast
 address-family vpnv4 unicast
 !
 neighbor 192.0.2.3
  remote-as 64500
  update-source Loopback0
  address-family ipv4 unicast
  address-family ipv6 unicast
  address-family vpnv4 unicast

On IOS-XR an address family must be enabled globally under router bgp before a neighbor can use it.

NX-OS

feature bgp
feature nv overlay      ! only for EVPN
router bgp 64500
 address-family ipv4 unicast
 address-family ipv6 unicast
 address-family vpnv4 unicast
 neighbor 192.0.2.3
  remote-as 64500
  update-source loopback0
  address-family ipv4 unicast
  address-family ipv6 unicast
  address-family vpnv4 unicast
   send-community extended

Labeled unicast (BGP-LU)

BGP-LU distributes MPLS labels for loopbacks between IGP domains (seamless MPLS, inter-AS option C).

! IOS-XE
router bgp 64500
 address-family ipv4 unicast
  network 192.0.2.1 mask 255.255.255.255
  neighbor 192.0.2.3 send-label

! IOS-XR
router bgp 64500
 address-family ipv4 unicast
  network 192.0.2.1/32
  allocate-label all
 neighbor 192.0.2.3
  address-family ipv4 labeled-unicast

Flowspec

Flowspec (RFC 8955) pushes traffic filters, such as drop or rate-limit rules for a DDoS attack, to edge routers through BGP.

! IOS-XR controller side
class-map type traffic match-all ATTACK
 match destination-address ipv4 203.0.113.10/32
 match protocol udp
 match destination-port 53
 end-class-map
policy-map type pbr DROP-ATTACK
 class type traffic ATTACK
  drop
 end-policy-map
flowspec
 address-family ipv4
  service-policy type pbr DROP-ATTACK
!
router bgp 64500
 address-family ipv4 flowspec
 neighbor 192.0.2.3
  address-family ipv4 flowspec

On receiving routers, validate both FlowSpec route acceptance and supported hardware enforcement. The enforcement CLI is platform-specific; do not reuse the IOS-XR global flowspec/local-install hierarchy as a generic IOS-XE or NX-OS recipe. Check the exact interface types, actions, scale limits and release support. Start with a narrowly scoped lab rule and confirm its removal; an Established FlowSpec session does not prove that traffic is being filtered.

Verify address families

• show bgp all summary (IOS-XE, NX-OS) or show bgp all all summary (IOS-XR) lists every address family and its peers.
• show bgp <afi> <safi> neighbors <ip> shows which families were advertised and received in the capabilities exchange.
• show bgp vpnv4 unicast all (IOS-XE, NX-OS) or show bgp vpnv4 unicast (IOS-XR) shows VPN routes.

Chapter 8 — Legacy CLNS reference

The original chapter number is retained for navigation and comparison with the Junos topic sequence. Legacy CLNS considerations are in Appendix A. They are not prerequisites for the modern BGP examples in this guide.

Chapter 9 — Route reflectors and confederations

iBGP does not pass a route learned from one iBGP peer to another, so a plain iBGP design needs a full mesh: n(n−1)/2 sessions, or 190 sessions for 20 routers. Route reflectors and confederations remove that requirement. Route reflection is the usual choice; confederations suit networks that merge or need separate internal policy domains.

Route reflection rules

The reflector adds ORIGINATOR_ID and CLUSTER_LIST so routes cannot loop. It does not change the next hop, local preference or MED. Deploy reflectors in pairs, and peer every client with both.

Configure a route reflector

The reflector (192.0.2.10) serves clients R1 (192.0.2.1) and R3 (192.0.2.3). The clients need no special config; they just peer with the reflector.

IOS-XE

router bgp 64500
 bgp cluster-id 192.0.2.10
 neighbor RR-CLIENTS peer-group
 neighbor RR-CLIENTS remote-as 64500
 neighbor RR-CLIENTS update-source Loopback0
 neighbor 192.0.2.1 peer-group RR-CLIENTS
 neighbor 192.0.2.3 peer-group RR-CLIENTS
 address-family ipv4 unicast
  neighbor RR-CLIENTS activate
  neighbor RR-CLIENTS route-reflector-client
  neighbor RR-CLIENTS send-community both

IOS-XR

router bgp 64500
 bgp cluster-id 192.0.2.10
 neighbor-group RR-CLIENTS
  remote-as 64500
  update-source Loopback0
  address-family ipv4 unicast
   route-reflector-client
 !
 neighbor 192.0.2.1
  use neighbor-group RR-CLIENTS
 neighbor 192.0.2.3
  use neighbor-group RR-CLIENTS

NX-OS

router bgp 64500
 cluster-id 192.0.2.10
 template peer RR-CLIENTS
  remote-as 64500
  update-source loopback0
  address-family ipv4 unicast
   route-reflector-client
   send-community both
 neighbor 192.0.2.1
  inherit peer RR-CLIENTS
 neighbor 192.0.2.3
  inherit peer RR-CLIENTS

Design choices

• Cluster ID. A shared cluster ID can intentionally prevent reflectors in the same cluster from accepting each other's reflected routes; unique IDs permit different propagation behavior. Neither choice is universally best. Document client attachment, inter-reflector sessions, path visibility and the effect of losing one client-to-reflector session. A cluster-ID choice alone does not eliminate path hiding.
• Out-of-path reflectors. A dedicated control-plane reflector may use a supported RIB-download suppression or table-policy mechanism for selected reflected routes. Preserve the routes needed for peer reachability, next-hop resolution and management. Do not apply an unqualified drop-all policy to a router that also forwards traffic. Syntax and AF support differ between IOS-XE, IOS-XR and NX-OS. If changing client-to-client reflection, model the remaining iBGP propagation paths first; a full mesh and an RR are not interchangeable by a single command. S25
• Hierarchical reflection. A reflector can itself be the client of a higher-level reflector. Use this for very large networks, with a different cluster ID at each level.
• Optimal route reflection (ORR, RFC 9107). A centralized reflector picks the best path from its own position, which may not be best for a client far away. IOS-XR supports ORR (optimal-route-reflection), which computes best paths from a chosen root router's IGP position. On IOS-XE and NX-OS, use add-path (Chapter 5) to give clients the alternatives.
• Next-hop-self. Reflectors do not change next hops by default. Set next-hop-self on the edge routers toward the reflector, not on the reflector itself. For reflected routes, IOS-XE and IOS-XR need next-hop-self all / ibgp policy out enforce-modifications to change it anyway.

Route-reflector validation recommendation: disconnect one client-to-RR session, then one entire RR, and compare the routes visible at each remaining client. Confirm that the RR is not an unintended forwarding next hop. Where path diversity matters, verify Add-Path negotiation and actual alternate next hops rather than assuming two RRs produce two distinct exits.

Confederations

A confederation splits one AS into member sub-ASes. Inside each sub-AS you run normal iBGP (full mesh or reflectors); between sub-ASes you run confederation eBGP, which keeps local preference, MED and next hop. Outside peers see only the confederation identifier.

Example: AS 64500 is split into sub-ASes 65001 and 65002. R1 is in 65001 and peers with R4 (192.0.2.4) in 65002.

IOS-XE

router bgp 65001
 bgp confederation identifier 64500
 bgp confederation peers 65002
 neighbor 192.0.2.4 remote-as 65002
 neighbor 192.0.2.4 update-source Loopback0
 neighbor 192.0.2.4 ebgp-multihop 2

IOS-XR

router bgp 65001
 bgp confederation identifier 64500
 bgp confederation peers
  65002
 !
 neighbor 192.0.2.4
  remote-as 65002
  update-source Loopback0
  ebgp-multihop 2
  address-family ipv4 unicast
   route-policy PASS in
   route-policy PASS out

NX-OS

router bgp 65001
 confederation identifier 64500
 confederation peers 65002
 neighbor 192.0.2.4
  remote-as 65002
  update-source loopback0
  ebgp-multihop 2

The best-path algorithm treats confederation eBGP routes as iBGP when comparing eBGP over iBGP. Use bgp bestpath med confed if you want MED compared across sub-ASes.

Verify

Chapter 10 — BGP security

Secure BGP in layers: protect the session, restrict control-plane access, validate routes, constrain exports and bound accepted scale. The policy must match the peer's role; an Internet-transit filter is not a universal eBGP baseline. S19

Recommended deployment checklist:

• [ ] Define explicit inbound and outbound policy for each address family and peer role.
• [ ] Use mutually supported session authentication and appropriate TTL security.
• [ ] Permit only intended peering sources through ACL/CoPP/LPTS controls; preserve required BFD and IPv6 neighbor-discovery traffic.
• [ ] Size maximum-prefix limits for the actual peer and define the overflow response.
• [ ] Validate public-route origins where applicable, and test Invalid/Not Found handling and cache failure.
• [ ] Verify both permitted and prohibited exports; an enterprise edge must not become transit accidentally.

A common public IPv4 /24 or IPv6 /48 maximum accepted prefix length is a peering-policy choice, not a universal BGP requirement. Private WAN and cloud routes can legitimately be more specific. Keep both the IPv4 and IPv6 policies explicit. S19

Session authentication

MD5-based TCP authentication is widely supported, but lacks TCP-AO's rollover design. A password change does not universally trigger an immediate reset, and a mismatched key can stop authenticated traffic until the session expires. Coordinate both ends and test the actual implementation. TCP-AO supports stronger authentication and key rollover when both peers, algorithms, IDs and key lifetimes are compatible; do not equate that capability with every in-place key edit being hitless. S8 S20

IOS-XE

! MD5
router bgp 64500
 neighbor 198.51.100.2 password 7 <encrypted-key>

! TCP-AO
key chain BGP-AO tcp
 key 1
  send-id 1
  recv-id 1
  key-string <secret>
  cryptographic-algorithm hmac-sha-1
  send-lifetime 00:00:00 Jan 1 2026 infinite
  accept-lifetime 00:00:00 Jan 1 2026 infinite
router bgp 64500
 neighbor 198.51.100.2 ao BGP-AO

IOS-XR

! MD5
router bgp 64500
 neighbor 198.51.100.2
  password encrypted <key>

! TCP-AO
key chain BGP-AO
 key 1
  accept-lifetime 00:00:00 january 01 2026 infinite
  key-string password <secret>
  send-lifetime 00:00:00 january 01 2026 infinite
  cryptographic-algorithm HMAC-SHA1-96
tcp ao
 keychain BGP-AO
  key 1 SendID 1 ReceiveID 1
router bgp 64500
 neighbor 198.51.100.2
  ao BGP-AO include-tcp-options enable

NX-OS

router bgp 64500
 neighbor 198.51.100.2
  password 3 <encrypted-key>

Cisco documents Nexus 9000 TCP-AO support beginning with NX-OS 10.4(2)F; verify the precise device and image. Do not assume an MD5 password mismatch is harmless until the next scheduled reset. S22

The authentication blocks are separate feature excerpts. Before using TCP-AO, match the effective algorithm, secret encoding, send/receive IDs, option coverage and valid lifetimes on both ends; inspect the active key. The infinite lifetimes illustrate establishment, not a rotation policy. Do not configure MD5 and TCP-AO as simultaneous alternatives on one session. Password storage formats such as type 7 are not transport encryption or a substitute for protecting configuration backups. S20

GTSM (TTL security)

GTSM (RFC 5082) makes the router drop BGP packets whose TTL shows they came from more than n hops away. A spoofed packet from across the internet cannot arrive with TTL 255.

! IOS-XE
neighbor 198.51.100.2 ttl-security hops 1
! IOS-XR (under the neighbor)
ttl-security
! NX-OS (under the neighbor)
ttl-security hops 1

Coordinate the peers' transmitted TTL and receive-side validation. Symmetric TTL security is normally the clearest design, but both ends need compatible behavior, not necessarily identical CLI. Do not use multihop and TTL-security commands together without checking the target implementation and precedence. Neither mechanism authenticates the peer or protects against a compromised device on the permitted path. S19

RPKI origin validation

Origin validation compares the prefix length and origin ASN against validated authorization data supplied by a cache. The validator performs RPKI validation; the router normally receives validated prefix-origin records over RTR, not the full certificate-validation workload. Valid does not validate the entire AS path or prove that an advertisement is free of a route leak. Not Found is not the same as Invalid. S26

The excerpts below show a reject-Invalid policy. They are RPKI-only demonstrations: the catch-all permit is not a complete Internet or customer filter. In production, add the rejection to the combined policy from Chapter 4 or another approved peer-specific policy instead of replacing that policy.

IOS-XE - create policy before attachment; a functioning cache and correct routing context are required. Do not add allow-invalid to a reject-Invalid baseline without a separately reviewed reason. S12

route-map RPKI-IN deny 10
 match rpki invalid
route-map RPKI-IN permit 20
!
router bgp 64500
 bgp rpki server tcp 192.0.2.50 port 3323 refresh 600
 address-family ipv4 unicast
  neighbor 198.51.100.2 route-map RPKI-IN in

IOS-XR - classify origins and apply policy; verify that validation is active on the target release. A connected cache alone is not proof of enforcement. For the XR7 behavior described by Cisco, bgp bestpath origin-as use validity can exclude Invalid paths from best-path selection rather than merely lowering their preference; this is distinct from dropping them with RPL. The excerpt uses explicit inbound rejection and must be tested for the target image's validation enablement. S13

route-policy RPKI-IN
  if validation-state is invalid then
    drop
  else
    pass
  endif
end-policy
!
router bgp 64500
 rpki server 192.0.2.50
  transport tcp port 3323
  refresh-time 600
 address-family ipv4 unicast
  bgp origin-as validation enable
 neighbor 198.51.100.2
  address-family ipv4 unicast
   route-policy RPKI-IN in

NX-OS - the Nexus 9000 NX-OS 10.6(x) procedure separates cache connectivity from eBGP origin validation. Enable origin-as validate, then attach the policy. Its cache timer uses refresh-interval, not the IOS-XR refresh-time spelling. S14

route-map RPKI-IN deny 10
 match rpki invalid
route-map RPKI-IN permit 20
!
router bgp 64500
 rpki cache 192.0.2.50
  transport tcp port 3323
  refresh-interval 600
 address-family ipv4 unicast
  origin-as validate
 neighbor 198.51.100.2
  address-family ipv4 unicast
   route-map RPKI-IN in

Use the actual validator port; 3323 is an example, not a protocol-wide default. Use the appropriate VRF/source configuration when the cache is not reachable in the default routing table. All three examples assume the neighbor itself already exists and has its necessary outbound policy.

Acceptance recommendations: test a Valid route, an Invalid route, a Not Found route, a change in authorization, and loss/expiry of cache data. Confirm Invalid routes cannot reach the FIB or unauthorized exports. Record cache retention and revalidation behavior. Public validation is not a prefix-authorization system for RFC 1918 networks. Maintain independent prefix, AS-path and export controls.

Inbound filtering baseline

Scope: illustrative public-Internet full-table acceptance filter. It rejects default here by design, common special-use ranges and IPv4 prefixes longer than /24. It is not an exhaustive, automatically maintained bogon feed or a private-cloud filter. Review the authoritative special-purpose registries and your peering contract before use. Documentation prefixes used elsewhere in this guide are deliberately blocked. S19 S27

! IOS-XE / NX-OS: a list of routes allowed to pass, not a bogon match set
ip prefix-list INTERNET-ACCEPT-V4 seq 1 deny 0.0.0.0/0
ip prefix-list INTERNET-ACCEPT-V4 seq 5 deny 0.0.0.0/8 le 32
ip prefix-list INTERNET-ACCEPT-V4 seq 10 deny 10.0.0.0/8 le 32
ip prefix-list INTERNET-ACCEPT-V4 seq 15 deny 100.64.0.0/10 le 32
ip prefix-list INTERNET-ACCEPT-V4 seq 20 deny 127.0.0.0/8 le 32
ip prefix-list INTERNET-ACCEPT-V4 seq 25 deny 169.254.0.0/16 le 32
ip prefix-list INTERNET-ACCEPT-V4 seq 30 deny 172.16.0.0/12 le 32
ip prefix-list INTERNET-ACCEPT-V4 seq 31 deny 192.0.0.0/29 le 32
ip prefix-list INTERNET-ACCEPT-V4 seq 32 deny 192.0.0.8/32
ip prefix-list INTERNET-ACCEPT-V4 seq 33 deny 192.0.0.170/31 le 32
ip prefix-list INTERNET-ACCEPT-V4 seq 35 deny 192.0.2.0/24 le 32
ip prefix-list INTERNET-ACCEPT-V4 seq 40 deny 192.168.0.0/16 le 32
ip prefix-list INTERNET-ACCEPT-V4 seq 45 deny 198.18.0.0/15 le 32
ip prefix-list INTERNET-ACCEPT-V4 seq 50 deny 198.51.100.0/24 le 32
ip prefix-list INTERNET-ACCEPT-V4 seq 55 deny 203.0.113.0/24 le 32
ip prefix-list INTERNET-ACCEPT-V4 seq 60 deny 224.0.0.0/3 le 32
ip prefix-list INTERNET-ACCEPT-V4 seq 65 deny 0.0.0.0/0 ge 25
ip prefix-list INTERNET-ACCEPT-V4 seq 100 permit 0.0.0.0/0 le 24

The 192.0.0.0/24 IETF protocol-assignment space contains specific globally reachable exceptions, including 192.0.0.9/32 and 192.0.0.10/32. Similarly, the deprecated 192.88.99.0/24 relay space contains a separately registered 192.88.99.2/32 address. Do not add a blanket deny 192.0.0.0/24 le 32 or deny 192.88.99.0/24 le 32 without evaluating IANA's current per-address attributes and your policy intent. This static excerpt is not a complete, automatically updated registry filter. S27

If used directly as a neighbor inbound prefix-list, denied entries are rejected. If used in a route-map, a permit sequence matching this list matches the permitted destinations. Do not place it in a route-map ... deny sequence and assume that its denied entries are what get rejected. Add own-prefix exclusions and all other required checks without a later catch-all that bypasses them. Chapter 4 explains composition.

Private-AS filtering on public transit must account for both 64512-65534 and 4200000000-4294967294. The original short expression covered only the 16-bit range; it has been removed rather than presenting a partial regex as complete protection. Use the platform's documented numeric AS-path mechanisms or a generated, tested expression for the AS notation actually displayed. Private-use ASNs remain legitimate inside private networks. S1 S2

Explicit outbound allowlists: prevent accidental transit

For an enterprise Internet edge that is not a transit provider, export only the prefixes it is authorized to originate or explicitly carry. Do not export routes learned from provider A to provider B merely because both BGP sessions are established. An AS-path condition alone is not a destination-authorization list.

IOS-XE / NX-OS policy definition - attach it using the platform-specific neighbor hierarchy shown in Chapter 2:

ip prefix-list ENTERPRISE-EXPORT-V4 seq 10 permit 203.0.113.0/24
!
route-map ENTERPRISE-OUT permit 10
 match ip address prefix-list ENTERPRISE-EXPORT-V4
route-map ENTERPRISE-OUT deny 100

IOS-XR equivalent:

prefix-set ENTERPRISE-EXPORT-V4
  203.0.113.0/24
end-set
route-policy ENTERPRISE-OUT
  if destination in ENTERPRISE-EXPORT-V4 then
    pass
  else
    drop
  endif
end-policy

These are documentation-prefix examples only. For each real peer, record the approved export set, then verify it locally and from the receiving side. Include a negative test using a learned third-party prefix in an isolated lab. Review redistribution, aggregate generation, default origination, VRF leaking and inherited templates as additional paths by which routes could become eligible for export. This is a proposed enterprise control, not a claim that all eBGP deployments should have the same export policy.

Control-plane protection

CoPP limits how much traffic can reach the route processor. Permit BGP only from configured peers. On IOS-XE, build a CoPP class that matches TCP/179 from your neighbor addresses. IOS-XR uses LPTS, which automatically lets in BGP only from configured neighbors; tune it with lpts pifib hardware police flow bgp. NX-OS ships a default CoPP policy (copp profile strict or moderate) that already classes BGP traffic.

Routing security practices (MANRS)

• Register your prefixes in an IRR (RIR database or RADB) and create ROAs for them.
• Build customer filters from IRR data with a tool such as bgpq4, and refresh them automatically.
• Do not leak routes from one provider or peer to another: use communities to tag where routes came from, and advertise only customer and own routes to peers and transit.
• Publish accurate contact information in PeeringDB.

Chapter 11 — Route flap damping and error handling

Route flap damping suppresses routes that go up and down repeatedly, which protects CPU on large tables. Use it with care: aggressive settings can keep a recovered route suppressed for an hour. RFC 7196 recommends a suppress threshold of at least 6000 if you enable it.

How damping works

In the documented Cisco IOS implementation, a withdrawal adds a penalty of 1000 and a route attribute change adds 500. Penalty behavior and which events are counted should be confirmed for the selected platform. When the accumulated penalty exceeds the suppress limit, the route is not used or advertised. The penalty halves every half-life. Once it falls below the reuse limit, the route can be used again, subject to other routing conditions. The max suppress time caps the suppression interval. S30

Configure damping

The argument order is half-life, reuse, suppress, max-suppress.

IOS-XE

router bgp 64500
 address-family ipv4 unicast
  bgp dampening 15 750 6000 60
! or per prefix set:
  bgp dampening route-map DAMPEN
route-map DAMPEN permit 10
 match ip address prefix-list CUSTOMERS
 set dampening 15 750 6000 60

IOS-XR

router bgp 64500
 address-family ipv4 unicast
  bgp dampening 15 750 6000 60

For selective damping on IOS-XR, use bgp dampening route-policy <name> with set dampening halflife 15 reuse 750 suppress 6000 max-suppress 60 in the policy.

NX-OS

router bgp 64500
 address-family ipv4 unicast
  dampening 15 750 6000 60

Error handling (RFC 7606)

Under the original RFC 4271, a malformed attribute in an UPDATE resets the whole session, so one bad route from far away can take down a peering. RFC 7606 replaces the reset with lighter actions where it is safe.

All three platforms implement revised error handling in current releases. On IOS-XE it is controlled with bgp enhanced-error (on by default). On IOS-XR, see show bgp neighbor <ip> for malformed-update counters.

Filtering problem attributes

If a peer sends an unknown or harmful optional transitive attribute, drop it or treat the route as withdrawn instead of passing it on.

! IOS-XE
router bgp 64500
 neighbor 198.51.100.2 path-attribute discard 128 in
 neighbor 198.51.100.2 path-attribute treat-as-withdraw 21 in

! IOS-XR
router bgp 64500
 attribute-filter group DROP-ATTR
  attribute 128 discard
 neighbor 198.51.100.2
  update in filtering
   attribute-filter group DROP-ATTR

This matches Junos drop-path-attributes. Check your NX-OS release for equivalent support.

Chapter 12 — BGP-based VPN

BGP carries VPN routes in MPLS Layer 3 VPNs (RFC 4364) and Ethernet VPNs (RFC 7432). Each customer has a VRF on the provider edge (PE) router. A route distinguisher (RD) makes overlapping customer prefixes unique in BGP; route targets (RT) decide which VRFs import which routes.

MPLS L3VPN on a PE

The PE (AS 64500, loopback 192.0.2.1) peers over iBGP VPNv4 with the reflector 192.0.2.10 and over eBGP with customer CE 172.16.1.2 (AS 65010) inside VRF CUST-A. MPLS (LDP or segment routing) must already run in the core.

IOS-XE

vrf definition CUST-A
 rd 64500:100
 address-family ipv4
  route-target export 64500:100
  route-target import 64500:100
!
interface GigabitEthernet0/0/2
 vrf forwarding CUST-A
 ip address 172.16.1.1 255.255.255.252
!
router bgp 64500
 neighbor 192.0.2.10 remote-as 64500
 neighbor 192.0.2.10 update-source Loopback0
 address-family vpnv4
  neighbor 192.0.2.10 activate
  neighbor 192.0.2.10 send-community extended
 exit-address-family
 address-family ipv4 vrf CUST-A
  neighbor 172.16.1.2 remote-as 65010
  neighbor 172.16.1.2 activate
  neighbor 172.16.1.2 as-override
 exit-address-family

IOS-XR

vrf CUST-A
 address-family ipv4 unicast
  import route-target 64500:100
  export route-target 64500:100
!
interface GigabitEthernet0/0/0/2
 vrf CUST-A
 ipv4 address 172.16.1.1 255.255.255.252
!
router bgp 64500
 address-family vpnv4 unicast
 neighbor 192.0.2.10
  remote-as 64500
  update-source Loopback0
  address-family vpnv4 unicast
 vrf CUST-A
  rd 64500:100
  address-family ipv4 unicast
  neighbor 172.16.1.2
   remote-as 65010
   address-family ipv4 unicast
    route-policy PASS in
    route-policy PASS out
    as-override

NX-OS - feature-set prerequisites follow the Nexus 9000 NX-OS 10.4(x) MPLS L3VPN procedure. That procedure is hardware-specific; do not assume a generic Nexus 3000/9000 or NX-OS virtual image supports this service. Existing core label transport and PE-loopback reachability are prerequisites. S10

feature bgp
install feature-set mpls
feature-set mpls
feature mpls l3vpn
vrf context CUST-A
 rd 64500:100
 address-family ipv4 unicast
  route-target import 64500:100
  route-target export 64500:100
!
interface Ethernet1/2
 no switchport
 vrf member CUST-A
 ip address 172.16.1.1/30
 no shutdown
!
router bgp 64500
 neighbor 192.0.2.10
  remote-as 64500
  update-source loopback0
  address-family vpnv4 unicast
   send-community extended
 vrf CUST-A
  address-family ipv4 unicast
  neighbor 172.16.1.2
   remote-as 65010
   address-family ipv4 unicast
    as-override

When customer sites reuse an ASN, evaluate provider-side as-override or a deliberately bounded CE-side allowas-in. These relax different aspects of AS-loop handling and are not interchangeable security controls. Multihomed designs may also need Site of Origin to prevent re-import into the originating site. SOO configuration and policy attachment differ by platform and service; verify them instead of assuming a shared site-of-origin neighbor command. Test withdrawal, dual-homing and any backdoor path before deployment.

EVPN

EVPN uses the l2vpn evpn address family to carry MAC and IP routes for Layer 2 and Layer 3 overlays. It is the standard control plane for VXLAN data center fabrics (NX-OS, Catalyst 9000) and for MPLS or SRv6 services (IOS-XR, ASR 1000).

NX-OS (VXLAN leaf, minimal)

nv overlay evpn
feature bgp
feature nv overlay
feature vn-segment-vlan-based
!
router bgp 65001
 neighbor 10.0.0.1
  remote-as 65001
  update-source loopback0
  address-family l2vpn evpn
   send-community extended
!
evpn
 vni 10100 l2
  rd auto
  route-target import auto
  route-target export auto

IOS-XE (Catalyst 9000)

l2vpn evpn
 replication-type static
 router-id Loopback0
router bgp 65001
 neighbor 10.0.0.1 remote-as 65001
 neighbor 10.0.0.1 update-source Loopback0
 address-family l2vpn evpn
  neighbor 10.0.0.1 activate
  neighbor 10.0.0.1 send-community both

IOS-XR

router bgp 64500
 address-family l2vpn evpn
 neighbor 192.0.2.10
  remote-as 64500
  update-source Loopback0
  address-family l2vpn evpn
!
evpn
 evi 100
  bgp
   rd 64500:100
   route-target import 64500:100
   route-target export 64500:100

Completeness warning: these EVPN examples show BGP/control-plane elements only. They do not build a working VXLAN or MPLS/SRv6 service. A VXLAN leaf also needs the supported VTEP/NVE configuration, underlay reachability, VLAN/VNI and VRF mappings, endpoint-facing interfaces and the selected replication/IRB model. Verify the relevant EVPN route types, tunnel state and endpoint traffic. Treat equivalent control-plane syntax on different platforms as a comparison, not as equivalent forwarding capability.

Verify VPN routes

Chapter 13 — Monitoring, troubleshooting and routed WAN design

Most BGP problems fall into two groups: the session will not come up, or it is up but routes are missing or wrong. Work from the bottom up: IP reachability, then TCP, then the BGP session, then policy, then best-path selection, then the RIB and forwarding table.

Junos to Cisco command map

Session will not come up

Session is up but routes are missing

1. Is the peer sending it? Compare received-routes (before policy, needs soft reconfiguration) with routes (after policy). If it is in received but not in routes, your inbound policy dropped it.
2. IOS-XR only: is a route-policy attached in both directions? A missing policy shows as "Policy for incoming advertisements is not set" and drops everything.
3. Is the next hop reachable? A route with an unreachable next hop is shown as inaccessible (IOS-XE) or not marked valid. Fix the IGP, or set next-hop-self on the edge router.
4. Did it lose best-path? Run show bgp ipv4 unicast <prefix> and work through the steps in Chapter 1. Check weight and local preference first.
5. Is it in the RIB? A route with a lower administrative distance from another protocol wins over BGP. show ip route <prefix> shows which source is used; RIB failures appear in show bgp ipv4 unicast rib-failure (IOS-XE).
6. Are you advertising it? A network statement needs an exact RIB match. iBGP-learned routes are not sent to other iBGP peers without a reflector. Check advertised-routes.
7. Communities and export policy. If the peer filters on communities, confirm the required community types are sent and received. Inspect explicit export policy and well-known communities such as no-export; do not infer the transmitted attributes solely from one platform's pre-policy display.

Useful logs and debugs

Turn on bgp log-neighbor-changes (on by default on IOS-XR and NX-OS) so every state change is logged. Debugs on a busy router can overload the CPU, so filter them to one neighbor or prefix and turn them off as soon as you are done.

! IOS-XE: debug one neighbor's updates for one prefix
access-list 99 permit 203.0.113.0 0.0.0.255
debug bgp ipv4 unicast 198.51.100.2 updates 99
terminal monitor
! ...
undebug all

! IOS-XR: history kept without debugs
show bgp neighbor 198.51.100.2 detail
show bgp trace

! NX-OS: history kept without debugs
show bgp event-history events
show bgp event-history errors
show bgp internal mem-stats

Streaming telemetry and ongoing monitoring

Use the monitoring methods your deployed software and collector actually support. Model-driven telemetry can supplement SNMP, logs and event history; it is not a reason to discard a working operational baseline. Validate the available models, paths, encodings and subscription modes on each release. Do not assume every Cisco platform supports every OpenConfig BGP leaf over both gNMI and gRPC dial-out.

BMP can provide routing visibility to a collector, but pre-policy, post-policy and other monitored views depend on the implementation and configuration. Verify which view is exported; a collector does not automatically receive every route at every policy stage.

Recommended monitoring covers neighbor state and last-reset reason, accepted/advertised route counts, maximum-prefix events, policy changes, BFD state, next-hop reachability, RPKI cache health, stale routes, and interface utilization/errors/drops. Alert on deviation from an approved baseline, not simply on whether the process is running.

Worked troubleshooting scenarios

These are diagnostic exercises, not incident reports or measured outcomes.

1. Established session, zero useful routes. Confirm the correct AFI/SAFI, VRF and inbound/outbound policy attachment. Compare what the sender advertises with what the receiver accepts. On IOS-XR, check for a missing policy direction. On any platform, an empty permitted set or a newly replaced inbound map can explain zero routes without a TCP problem.

2. AS-path prepending has no apparent effect. Compare the same prefix at the router making the decision. If weight or local preference differs, resolve that policy first. When influencing an external network, obtain its view or the provider's documented policy; local advertised-routes output does not prove which path the remote AS selected. Check for a more-specific route as a separate forwarding issue.

3. BGP contains the route, but traffic still fails. Check whether it is eligible and best, whether another protocol won the RIB entry, and which next hop the FIB actually resolves. Then inspect adjacency resolution, interfaces, MTU, policy-based forwarding, ACL/firewall behavior and the return path. A retained or advertised route is not proof of viable forwarding.

4. Two multipaths are installed, but one link is busy. Check hash inputs and flow diversity, physical link counters, and downstream capacity. Repeat with several independent flows and inspect forwarding next hops. One ping stream or one large transfer does not establish that ECMP is broken. See Chapter 5.

Enterprise BGP feature selection checklist

The guide already contains many features commonly deployed in enterprise networks. Use this matrix to decide whether the feature is needed, not to enable every knob by default.

Enterprise operating rule: use ECMP for truly equivalent active paths, routing attributes for intentional preference and standby paths, BFD for failure detection, and route policies for trust boundaries. Verify each function at the BGP table, RIB, FIB, and application traffic layer.

Design scenarios to document before implementation

These are design prompts, not claims about a particular cloud provider's current product behavior. Consult its service documentation before mapping Cisco policy to a cloud control plane.

Failure and policy acceptance matrix

Run disruptive and malicious-input simulations only in an isolated lab or an approved maintenance test. Define the expected result before each test and record what actually occurred.

Measurement method: use synchronized timestamps and a continuous, sequence-numbered traffic stream at a known rate in both directions. Report packet loss, outage duration and the affected flow/path, not only BGP uptime. Repeat tests and report the observed range. Routing convergence, FIB repair and application reconnection may finish at different times.

Worked design scenario — BGP at scale over inter-site WAN transport

Purpose and status: this is a reference architecture and an IOS-XE configuration exercise, not a validated migration plan for any specific network. It is especially useful when a provider supplies Layer 2 Ethernet circuits but the enterprise's real requirement is Layer 3 reachability between sites.

Anti-pattern to evaluate: hundreds of carrier VLAN mappings, each supporting a separate /30 and BGP session, even though the sessions ultimately populate the same routing domain and do not enforce meaningful independent policy. The complexity is not caused by BGP or VLANs independently; it is the unnecessary multiplication of transport and session objects with no corresponding functional requirement. Do not assume every large Layer 2 design is wrong: distinct VRFs, customers, failure domains or regulatory separation may justify segmentation.

Illustrative link layout (two geographically diverse carrier paths):

          Carrier Ethernet E-Line A (link A /31)
Site A  ========================================== Site B
R1 AS64500             eBGP + optional BFD        R2 AS64501
       ==========================================
          Carrier Ethernet E-Line B (link B /31)

Two physical/logical links; two BGP adjacencies; both paths only used
in parallel when BGP multipath prerequisites and forwarding allow it.

A service handoff can be a physical L3 interface or one tagged subinterface if the carrier requires an 802.1Q handoff. This is not "eliminating Ethernet Layer 2"—it is eliminating unnecessary extended VLAN domains and repeated BGP sessions. Where both endpoints and the media support it, /31 IPv4 addressing conserves link addresses (RFC 3021). Use /127 for numbered IPv6 router-to-router point-to-point links where appropriate (RFC 6164); avoid unnumbered designs unless operational support is established. S32 S43

Intermediate WAN aggregation switches matter. The diagram above simplifies the physical path: real deployments can have enterprise WAN aggregation switches between the BGP routers and the carrier Ethernet handoffs. If those switches remain, an upstream carrier outage may leave the router-facing interface and SVI up/up, so physical link state alone cannot be relied on for failure detection. For rapid convergence across a silently failed transport, deploy and validate BFD end to end (or an equivalent transport-fault detection mechanism such as supported Ethernet OAM with a proven routing trigger). BFD is not an unconditional protocol requirement: without it, BGP timers or other mechanisms may eventually detect a failure, but convergence may be much slower. Confirm hardware support, timers, CoPP/LPTS treatment, and control-plane load for BFD on SVIs or subinterfaces.

The routed Layer 3 design does not require removing aggregation switches when they provide necessary fanout or resiliency. The goal is to eliminate unnecessary stretched VLAN-to-BGP-peer mappings, not to prescribe a physical-port topology for every site. If direct router-to-carrier handoffs are feasible, assess whether removing intermediate switches reduces failure-domain complexity before making that choice.

IOS-XE example — two parallel /31 carrier handoffs

The documentation-only loopback /24 networks stand in for real site aggregates. They are local and must not be exported to the Internet. This two-router example deliberately models direct handoffs for clarity. Where WAN aggregation switches remain in the physical path, the BFD/transport-fault caveat above applies. Physical carrier interfaces and reachability are assumptions of this isolated exercise. The example uses one eBGP neighbor per independent link; the same-AS path lengths and attributes are intended to permit ECMP when the selected hardware and policy support it.

Site A — AS 64500:

interface Loopback100
 description TEST-ONLY Site-A aggregate
 ip address 192.0.2.1 255.255.255.0
!
interface GigabitEthernet0/0/0
 description Carrier-A-to-Site-B
 ip address 198.51.100.0 255.255.255.254
 bfd interval 300 min_rx 300 multiplier 3
 no shutdown
!
interface GigabitEthernet0/0/1
 description Carrier-B-to-Site-B
 ip address 198.51.100.2 255.255.255.254
 bfd interval 300 min_rx 300 multiplier 3
 no shutdown
!
ip prefix-list SITE-B-IN seq 10 permit 203.0.113.0/24
ip prefix-list SITE-A-OUT seq 10 permit 192.0.2.0/24
route-map SITE-B-IN permit 10
 match ip address prefix-list SITE-B-IN
route-map SITE-A-OUT permit 10
 match ip address prefix-list SITE-A-OUT
!
router bgp 64500
 bgp router-id 192.0.2.1
 no bgp default ipv4-unicast
 neighbor 198.51.100.1 remote-as 64501
 neighbor 198.51.100.1 fall-over bfd
 neighbor 198.51.100.3 remote-as 64501
 neighbor 198.51.100.3 fall-over bfd
 address-family ipv4 unicast
  network 192.0.2.0 mask 255.255.255.0
  maximum-paths 2
  neighbor 198.51.100.1 activate
  neighbor 198.51.100.1 route-map SITE-B-IN in
  neighbor 198.51.100.1 route-map SITE-A-OUT out
  neighbor 198.51.100.3 activate
  neighbor 198.51.100.3 route-map SITE-B-IN in
  neighbor 198.51.100.3 route-map SITE-A-OUT out
 exit-address-family

Site B — AS 64501:

interface Loopback100
 description TEST-ONLY Site-B aggregate
 ip address 203.0.113.1 255.255.255.0
!
interface GigabitEthernet0/0/0
 description Carrier-A-to-Site-A
 ip address 198.51.100.1 255.255.255.254
 bfd interval 300 min_rx 300 multiplier 3
 no shutdown
!
interface GigabitEthernet0/0/1
 description Carrier-B-to-Site-A
 ip address 198.51.100.3 255.255.255.254
 bfd interval 300 min_rx 300 multiplier 3
 no shutdown
!
ip prefix-list SITE-A-IN seq 10 permit 192.0.2.0/24
ip prefix-list SITE-B-OUT seq 10 permit 203.0.113.0/24
route-map SITE-A-IN permit 10
 match ip address prefix-list SITE-A-IN
route-map SITE-B-OUT permit 10
 match ip address prefix-list SITE-B-OUT
!
router bgp 64501
 bgp router-id 203.0.113.1
 no bgp default ipv4-unicast
 neighbor 198.51.100.0 remote-as 64500
 neighbor 198.51.100.0 fall-over bfd
 neighbor 198.51.100.2 remote-as 64500
 neighbor 198.51.100.2 fall-over bfd
 address-family ipv4 unicast
  network 203.0.113.0 mask 255.255.255.0
  maximum-paths 2
  neighbor 198.51.100.0 activate
  neighbor 198.51.100.0 route-map SITE-A-IN in
  neighbor 198.51.100.0 route-map SITE-B-OUT out
  neighbor 198.51.100.2 activate
  neighbor 198.51.100.2 route-map SITE-A-IN in
  neighbor 198.51.100.2 route-map SITE-B-OUT out
 exit-address-family

What to test before selecting a routed design

1. Number of stateful objects: inventory VLANs, SVIs/subinterfaces, /30s, BGP sessions, BFD sessions, peer templates, monitoring targets and operational change points. Compare by actual VRF/policy/forwarding requirement, not raw counts alone.
2. Session scale and control plane: verify platform-specific limits and actual resource use for simultaneous BGP peers, BFD sessions and BGP update groups. CoPP (IOS-XE/NX-OS) or LPTS (IOS-XR) must allow expected BGP/BFD/control traffic without opening an unlimited control-plane path. Determine whether BFD is hardware-offloaded and supported on each port, SVI or subinterface; don't infer SVI failure from link state.
3. BFD and silent carrier failure: disconnect one physical handoff, then separately blackhole traffic while the provider Ethernet handoff remains up. If a WAN aggregation switch is between the router and provider, explicitly test both an edge port failure and a remote E-Line failure that leaves the router-facing port/SVI up/up. Measure BFD or alternative fault-detection time, BGP withdrawals, RIB/FIB changes and actual bidirectional loss. Compare with a case that has no rapid failure detector.
4. ECMP and capacity: verify maximum-paths results in two usable FIB next hops, then measure per-link and per-flow distribution. Re-run at offered load when only one carrier survives; ensure the surviving path has enough capacity and no downstream shared bottleneck invalidates the redundant-path claim.
5. Site/aggregation failure: check router, carrier metro, shared switch, and shared LAG dependencies. Two apparent circuits may have the same provider POP, cross-connect or remote 10G aggregation. Draw the failure domain through to the application and return path.
6. Phased migration and rollback: build and validate new routed handoffs first. Use explicit route policies and administrative preference to migrate one prefix group or service at a time. Set a traffic-based rollback threshold; do not promise zero interruption without measured tests.

Design recommendation: if many VLANs carry BGP peerings to the same routing table without independent segmentation requirements, strongly consider terminating carrier circuits as distinct point-to-point Layer 3 interfaces, retaining only the necessary BGP sessions. The benefit is lower operational coupling and clearer failure domains—not an automatic subsecond recovery guarantee. Preserve L2 services when genuine L2 reachability, tenancy or service requirements justify them.

Deployment checklist and rollback

Before the change: save the current configuration and routing baseline; confirm out-of-band access; document the approved prefix sets, expected route counts, next hops and traffic preference; verify hardware/release support; identify the rollback owner and trigger. Keep new policy names distinct from live policies while reviewing them. IOS-XE/NX-OS line-by-line edits can have immediate effects; IOS-XR needs a controlled commit.

During the change: stage policies first, review their final permit/deny behavior, and attach them only to the intended neighbor, VRF and address family. Use the smallest supported refresh scope. Do not apply global clears or copy an example over an existing production routing process.

After the change: verify negotiated capabilities and timers, accepted and rejected routes, transmitted attributes, RIB/FIB next hops and bidirectional traffic. Compare route counts and interface counters with the baseline. Complete an appropriate failover/restore test rather than declaring success at Established.

Rollback triggers: unintended exports, missing critical prefixes, wrong egress/ingress, recurrent flaps, uncontrolled stale routes, unacceptable loss or a saturated surviving path. Restore the prior policy association and dependent objects in a controlled sequence using the platform's approved rollback method. Verify routing and traffic after rollback; a successful configuration command is not the end of recovery.

Use platform-supported checkpoints or confirmed commits where appropriate, but validate their scope and behavior before relying on them remotely. Populate Appendix C with actual results and only then mark an example as lab-validated.

Appendix A — Legacy CLNS considerations

CLNS/OSI management networks are a legacy consideration, separate from modern IP BGP design. The original guide included them to preserve its Junos chapter mapping. IS-IS adjacency transport and an OSI/CLNS service routed with BGP are different requirements.

If you maintain a legacy SONET/SDH data communications network, identify its actual NSAP/CLNS dependency and check the exact Cisco image for support. Do not assume historical address-family nsap commands remain available in IOS-XE, IOS-XR or NX-OS, and do not propose GRE transport without validating the endpoints' support.

For a new design, keep management reachability requirements in the IP architecture unless a documented application requires an OSI service. This appendix is a legacy scoping note, not a validated migration procedure.

Appendix B — Integrated IOS-XE two-router lab

Status: configuration-complete for the stated isolated topology; not executed or lab-validated. This exercise supplies both peers, their interface addresses, route origination and explicit policies. The results below are expectations to test, not captured device output. The basic routing and policy mechanisms are documented in Cisco's IOS-XE BGP guide. S4

Scope and prerequisites

Use two isolated IOS-XE routers or supported virtual images with Layer 3 interfaces. The intended interface name is GigabitEthernet0/0/1; substitute the correct name on both the topology and configuration before use. Start with a clean lab configuration, console access and no conflicting BGP process, VRF, ACL, policy or address assignment. Record the actual model and image in Appendix C.

This lab has one link and no alternate path. It demonstrates explicit import/export control and origination/withdrawal, not high availability. Authentication, BFD, RPKI, IPv6 and production control-plane protections are intentionally outside the baseline. Do not attach it to a production network or an Internet exchange.

The two test networks are connected loopbacks, not remote applications. LAB-R2's default to Null0 is an isolated lab origination mechanism, not an upstream service. It deliberately discards destinations without a more-specific route. It must not be copied into an Internet-edge design as evidence that an upstream is healthy.

LAB-R1 configuration

hostname LAB-R1
!
interface Loopback0
 ip address 192.0.2.1 255.255.255.255
!
interface Loopback100
 description LAB-TEST-PREFIX
 ip address 203.0.113.1 255.255.255.0
!
interface GigabitEthernet0/0/1
 description ISOLATED-LINK-TO-LAB-R2
 ip address 198.51.100.1 255.255.255.252
 no shutdown
!
ip prefix-list LAB-R1-IN seq 10 permit 0.0.0.0/0
ip prefix-list LAB-R1-OUT seq 10 permit 203.0.113.0/24
!
route-map LAB-R1-IN permit 10
 match ip address prefix-list LAB-R1-IN
route-map LAB-R1-IN deny 100
!
route-map LAB-R1-OUT permit 10
 match ip address prefix-list LAB-R1-OUT
route-map LAB-R1-OUT deny 100
!
router bgp 64500
 bgp router-id 192.0.2.1
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 198.51.100.2 remote-as 64501
 neighbor 198.51.100.2 description LAB-R2
 address-family ipv4 unicast
  network 203.0.113.0 mask 255.255.255.0
  neighbor 198.51.100.2 activate
  neighbor 198.51.100.2 route-map LAB-R1-IN in
  neighbor 198.51.100.2 route-map LAB-R1-OUT out
  neighbor 198.51.100.2 maximum-prefix 5 80
 exit-address-family

LAB-R2 configuration

hostname LAB-R2
!
interface Loopback0
 ip address 192.0.2.2 255.255.255.255
!
interface Loopback100
 description LAB-TEST-ENDPOINT
 ip address 192.0.2.129 255.255.255.128
!
interface GigabitEthernet0/0/1
 description ISOLATED-LINK-TO-LAB-R1
 ip address 198.51.100.2 255.255.255.252
 no shutdown
!
! LAB ONLY: originate a default; this is not a real upstream.
ip route 0.0.0.0 0.0.0.0 Null0 250
!
ip prefix-list LAB-R2-IN seq 10 permit 203.0.113.0/24
ip prefix-list LAB-R2-OUT seq 10 permit 0.0.0.0/0
!
route-map LAB-R2-IN permit 10
 match ip address prefix-list LAB-R2-IN
route-map LAB-R2-IN deny 100
!
route-map LAB-R2-OUT permit 10
 match ip address prefix-list LAB-R2-OUT
route-map LAB-R2-OUT deny 100
!
router bgp 64501
 bgp router-id 192.0.2.2
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 198.51.100.1 remote-as 64500
 neighbor 198.51.100.1 description LAB-R1
 address-family ipv4 unicast
  network 0.0.0.0
  neighbor 198.51.100.1 activate
  neighbor 198.51.100.1 route-map LAB-R2-IN in
  neighbor 198.51.100.1 route-map LAB-R2-OUT out
  neighbor 198.51.100.1 maximum-prefix 5 80
 exit-address-family

Baseline verification and expected results

Run the following in EXEC mode on LAB-R1:

show ip interface brief
show bgp ipv4 unicast summary
show bgp ipv4 unicast neighbors 198.51.100.2
show bgp ipv4 unicast neighbors 198.51.100.2 routes
show bgp ipv4 unicast neighbors 198.51.100.2 advertised-routes
show bgp ipv4 unicast 0.0.0.0/0
show ip route 0.0.0.0
show ip cef 192.0.2.129 detail
ping 192.0.2.129 source 203.0.113.1

Run the corresponding checks on LAB-R2:

show ip interface brief
show bgp ipv4 unicast summary
show bgp ipv4 unicast neighbors 198.51.100.1 routes
show bgp ipv4 unicast neighbors 198.51.100.1 advertised-routes
show bgp ipv4 unicast 203.0.113.0/24
show ip route 203.0.113.0
show ip cef 203.0.113.1 detail
ping 203.0.113.1 source 192.0.2.129

Do not infer accepted routes from a total BGP-table count: locally originated routes are also present. Use the neighbor's accepted-route view, actual selected routes and forwarding entries. received-routes before policy may require inbound soft reconfiguration; it is not required for this baseline exercise.

Negative tests and withdrawal tests

Make one change at a time and restore the baseline before the next test. Apply the appropriate neighbor-scoped soft refresh after changing policy if the target release does not reprocess it automatically. Check both the sender's advertised routes and the receiver's accepted routes.

Test 1: unauthorized local export. On LAB-R1, add network 192.0.2.1 mask 255.255.255.255 under the IPv4 BGP address family. The loopback provides an exact RIB match, but LAB-R1-OUT must still prevent this /32 from being advertised to LAB-R2. Remove that network statement after recording the result. This separates route origination from export authorization.

Test 2: unauthorized inbound prefix. On LAB-R2, add network 192.0.2.128 mask 255.255.255.128 under the IPv4 BGP address family and temporarily add ip prefix-list LAB-R2-OUT seq 20 permit 192.0.2.128/25. The connected Loopback100 supplies the exact RIB match. Confirm that LAB-R2 advertises this extra route; then confirm that LAB-R1 does not accept it into its BGP table. A ping to 192.0.2.129 can still succeed through LAB-R1's authorized default, so ping alone does not prove the filter failed. Remove the extra network statement and prefix-list sequence after the test.

Test 3: local prefix withdrawal. Shut down LAB-R1's Loopback100. With no other exact 203.0.113.0/24 route, its network origination should stop and LAB-R2 should lose the BGP route. Restore the loopback and verify re-advertisement and traffic. This tests the connected route's dependency; the lab has no failover path.

Test 4: default withdrawal. Remove LAB-R2's lab default using no ip route 0.0.0.0 0.0.0.0 Null0 250. With no other exact default route in its RIB, LAB-R2 should stop originating 0.0.0.0/0. Verify its removal on LAB-R1, restore the static route, and verify recovery. This is not a test of real upstream reachability.

Test 5: link loss. Shut the inter-router interface from a console or otherwise interrupt the isolated link. Confirm loss of the session and learned routes. No traffic continuity is expected because the topology has no second path. Restore the link and record recovery; do not label the observed time as a BFD or PIC result, because neither is configured here.

After every test, compare the running configuration, accepted/exported prefixes and forwarding state with the baseline. Save only the intended baseline, not temporary permits used to inject unauthorized routes.

Appendix C — Validation record and remaining scope

Use one record per example and exact platform/image combination. A documentation reference is evidence of described behavior, not proof that the configuration passed on a device.

Coverage statement for this revision

Priorities for device validation

Begin with the basic session and policy examples, including rejection tests and deliberate withdrawal. Then validate IPv6 link-local and unnumbered peering syntax, AF capabilities and next-hop resolution on the actual target releases. Test authentication and key rotation with both endpoints, not just the local parser.

For multipath, Add-Path, PIC, BFD and GR, record actual forwarding behavior under each relevant failure. For route reflection, include loss of one client session as well as an entire reflector. For VPN/EVPN and FlowSpec, complete the underlay, transport, label/VNI, RT/RD and enforcement prerequisites before testing service reachability and isolation.

Retained command maps and advanced fragments, including ORF, damping, platform-specific show/debug commands and optional AF features, still require target-device checks. Do not treat absence of a warning beside an individual line as an assertion that it was executed or exhaustively verified.

References and validation scope

Documentation was checked and enterprise-feature sections were refined on November 13, 2026. Cisco sources are intentionally tied to their named platforms and releases; a cited feature on one family does not establish support on another. Consult the current command reference, configuration guide and release notes for the exact target image before deployment.

These sources support the targeted corrections and explanations. They are not a claim that every retained example was traced to a source or run on a device. Design recommendations and expected lab outcomes are identified separately from documented mechanisms and observed results.