Cisco IOS XR BGP Configuration: iBGP and eBGP Step by Step

Cisco IOS XR keeps the familiar router bgp model but removes one of classic IOS's conveniences: there is no default address family, so every address family you want to use must be explicitly configured both globally and under each neighbor. New XR engineers usually trip on exactly this point when a BGP session stays idle. This article walks through a minimal iBGP and eBGP setup on IOS XR with the verification commands that confirm each session and prefix, then extends the example with the policies and options you need in production.

IOS XR BGP Basics

• Configure router bgp <as>, then add an address-family ipv4 unicast block globally; nothing is activated by default.
• Neighbor statements are entered in a submode: neighbor <ip> then remote-as, then an address-family block under the neighbor with the policies.
• Advertise local prefixes with the network statement inside the address family.
• All changes need an explicit commit — there is no implicit save.

The mental model that makes IOS XR BGP predictable is this: there are two parallel hierarchies, one for the routing process and one for each neighbor, and a feature is only active where both hierarchies agree. The global address-family ipv4 unicast block says "this process handles IPv4 unicast". The per-neighbor address-family ipv4 unicast block says "this neighbor may exchange IPv4 unicast prefixes". Configure one without the other and the session may reach Established while carrying no routes — a failure mode that confuses engineers far more than a session that simply stays down, because the session looks healthy.

The Address Family Requirement, Explained

In classic IOS you typed router bgp 65001, added a neighbor, and IPv4 unicast was implied. IOS XR makes the same configuration explicit in two places. That extra typing buys multi-protocol capability: the same neighbor block can carry IPv4 unicast, IPv6 unicast, VPNv4 and multicast families side by side, each with its own policy and each independently enabled.

RP/0/RSP0/CPU0:PE1(config)# router bgp 1
RP/0/RSP0/CPU0:PE1(config-bgp)# address-family ipv4 unicast
RP/0/RSP0/CPU0:PE1(config-bgp-af)# exit
RP/0/RSP0/CPU0:PE1(config-bgp)# neighbor 10.1.1.2
RP/0/RSP0/CPU0:PE1(config-bgp-nbr)# address-family ipv4 unicast
RP/0/RSP0/CPU0:PE1(config-bgp-nbr-af)# exit

Notice the CLI prompt: config-bgp-af is the global address-family submode and config-bgp-nbr-af is the neighbor address-family submode. If your prompt never changes to the second form, you typed the family in the wrong place and the neighbor is still carrying nothing.

Configuration Example: iBGP and eBGP

The example below mirrors the classic PE1/PE2 (iBGP, AS 1) with CE1 (eBGP, AS 2) topology. Loopbacks are used for the iBGP session, and an eBGP route to CE1 is learned over the direct link.

RP/0/RSP0/CPU0:PE1# configure
RP/0/RSP0/CPU0:PE1(config)# router bgp 1
RP/0/RSP0/CPU0:PE1(config-bgp)# bgp router-id 192.168.1.1
RP/0/RSP0/CPU0:PE1(config-bgp)# address-family ipv4 unicast
RP/0/RSP0/CPU0:PE1(config-bgp-af)# network 192.168.1.1/32
RP/0/RSP0/CPU0:PE1(config-bgp-af)# exit
RP/0/RSP0/CPU0:PE1(config-bgp)# neighbor 10.1.1.2
RP/0/RSP0/CPU0:PE1(config-bgp-nbr)# remote-as 1
RP/0/RSP0/CPU0:PE1(config-bgp-nbr)# update-source Loopback0
RP/0/RSP0/CPU0:PE1(config-bgp-nbr)# address-family ipv4 unicast
RP/0/RSP0/CPU0:PE1(config-bgp-nbr-af)# exit
RP/0/RSP0/CPU0:PE1(config-bgp-nbr)# exit
RP/0/RSP0/CPU0:PE1(config-bgp)# neighbor 172.16.1.2
RP/0/RSP0/CPU0:PE1(config-bgp-nbr)# remote-as 2
RP/0/RSP0/CPU0:PE1(config-bgp-nbr)# address-family ipv4 unicast
RP/0/RSP0/CPU0:PE1(config-bgp-nbr-af)# exit
RP/0/RSP0/CPU0:PE1(config-bgp-nbr)# exit
RP/0/RSP0/CPU0:PE1(config-bgp)# exit
RP/0/RSP0/CPU0:PE1(config)# commit

The iBGP neighbor uses update-source Loopback0 because the loopback is what both routers advertise; the eBGP neighbor to CE1 runs over the directly connected 172.16.1.0/30 link. Note that eBGP on directly connected links does not need ebgp-multihop, but a loopback-based eBGP session would.

Line-by-Line Notes on the Example

• bgp router-id — pin it explicitly. Without a router ID, BGP derives one from an interface address, and if that interface disappears the session can reset. A loopback-derived or explicitly configured router ID is stable.
• network 192.168.1.1/32 — the prefix must already exist in the routing table (a connected loopback or a static route). The network statement does not create a route; it matches one and injects it into BGP.
• remote-as 1 for a neighbor in your own AS makes it iBGP; a different AS makes it eBGP. The session type follows the AS comparison, not any separate command.
• update-source Loopback0 — required for any session whose TCP connection should terminate on a loopback rather than the outgoing interface.
• commit — nothing takes effect without it. If you forget, commit is the answer to "why is my neighbor still not there?"

Scaling Out: Neighbor Groups, Session Groups and af-groups

Typing an address-family block per neighbor does not scale to a full mesh, and IOS XR gives you template inheritance to avoid it. A neighbor-group holds configuration shared by a group of peers; a session-group (created with session-group inside router bgp) holds session-level settings that apply to many neighbors regardless of their policies; and an af-group holds address-family-level settings such as policies.

router bgp 1
 neighbor-group IBGP-PEERS
  remote-as 1
  update-source Loopback0
  address-family ipv4 unicast
  !
 !
 neighbor 10.1.1.2
  use neighbor-group IBGP-PEERS
 !
 neighbor 10.1.1.3
  use neighbor-group IBGP-PEERS
 !
!

The use keyword is the inheritance mechanism, and it exists for all three group types. Structuring configuration this way is the single biggest readability improvement you can make to an IOS XR BGP deployment: change the group and every member inherits, without touching each neighbor. The group model is covered in depth in the IOS XR routing configuration guides.

Routing Policy vs Classic IOS Filtering

IOS XR does not use neighbor ... route-map; filtering is done with route policies attached inside the neighbor address-family:

prefix-set CUSTOMER-ROUTES
  192.168.1.0/24 le 28,
  10.10.0.0/16 le 24
end-set
!
route-policy PASS
  pass
end-policy
!
route-policy CUSTOMER-IN
  if destination in CUSTOMER-ROUTES then
    pass
  else
    drop
  endif
end-policy
!
router bgp 1
 neighbor 172.16.1.2
  remote-as 2
  address-family ipv4 unicast
   route-policy PASS in
   route-policy CUSTOMER-IN out
  !
 !
!

Two habits separate working XR policies from broken ones. First, a route policy that matches nothing and has no explicit pass or drop at the end will drop everything — always terminate the policy. Second, policies are applied with a direction keyword (in or out) and the direction is relative to the neighbor, not to you; swapping them is a common cause of "the session is up and no prefixes are coming in". For the full mechanics of prefix-sets and policy structure, see our IOS XR RPL route policy and prefix-set guide.

Options You Will Need in Production

The minimal example works in a lab; production adds a handful of keywords:

router bgp 1
 neighbor 172.16.1.2
  remote-as 2
  ebgp-multihop 3
  bfd fast-detect
  timers 10 30
  address-family ipv4 unicast
   next-hop-self
   maximum-prefix 5000 90 warning-only
   soft-reconfiguration inbound
  !
 !
 neighbor 10.1.1.2
  remote-as 1
  update-source Loopback0
  address-family ipv4 unicast
   next-hop-self
  !
 !
!

• ebgp-multihop — needed when the eBGP peer is not directly connected, for example when peering over loopbacks or across a transit cloud.
• next-hop-self — required on most iBGP route reflectors and PE routers, otherwise iBGP peers learn next hops they cannot reach. It is exactly address-family ipv4 unicast / next-hop-self on XR, not a neighbor-level command.
• bfd fast-detect — ties the BGP session to BFD so failures are detected in milliseconds instead of waiting for the hold timer.
• maximum-prefix — a hard guard against a misbehaving peer filling the table; the warning-only form warns first without tearing the session down.
• soft-reconfiguration inbound — stores received routes unmodified so policy changes can be re-applied with clear bgp ... soft in without a session reset.

Verification

show bgp summary
show bgp ipv4 unicast summary
show bgp ipv4 unicast neighbors 172.16.1.2
show bgp ipv4 unicast
show bgp ipv4 unicast neighbors 172.16.1.2 advertised-routes
show bgp ipv4 unicast neighbors 172.16.1.2 routes
show run router bgp

Check the St/PfxRcd column: an iBGP/eBGP neighbor in the Established state with received prefixes is the success indicator. If the column shows a state name instead of a number, the session is not up; if it shows 0, the session is up but policy or next-hop filtering is dropping everything — which is why advertised-routes and routes are worth their extra typing.

The show run router bgp check at the end is not redundant. Because XR inherits configuration from groups, what you typed and what the BGP process runs are not always the same set; reading the effective configuration catches an inheritance mistake that the neighbor summary hides.

Troubleshooting a Session That Stays Down

1. Idle: the router is not even trying. Usually no route to the neighbor address, a missing remote-as, or the neighbor is administratively shut down.
2. Active: TCP connect attempts are being sent and not answered. Check reachability to the peer's update source, an ACL or control-plane policy blocking TCP 179, and whether the peer has a matching neighbor statement pointing back at your source address.
3. Connect/OpenSent: TCP works but the session negotiation is failing — typically an AS number mismatch or a router ID collision.
4. Established with zero prefixes: always an address-family or policy problem. Confirm the neighbor address-family block exists, then check the inbound and outbound policies.

For the systematic version of this checklist, including the timer and transport-layer causes that produce repeated resets rather than a stable down state, see our BGP session stuck Idle or Active troubleshooting guide and the BGP neighbor flapping root causes article. For OSPF-to-BGP interplay on XR see our IOS XR OSPF configuration examples.

Scaling iBGP: Route Reflectors and Confederations

A full iBGP mesh grows as n(n-1)/2 sessions, which stops being practical somewhere around a dozen routers. IOS XR gives you the same two escape hatches as every other BGP implementation: route reflectors and confederations.

router bgp 1
 bgp cluster-id 192.168.1.1
 address-family ipv4 unicast
 !
 neighbor 10.1.1.2
  remote-as 1
  update-source Loopback0
  address-family ipv4 unicast
   route-reflector-client
   next-hop-self
  !
 !
!

route-reflector-client is configured on the reflector, in the neighbor address family, and it is directional: the reflector reflects routes from clients to clients and to non-clients, but never back to the client that sent them. Set bgp cluster-id explicitly when a router has more than one loopback that could serve as the cluster identifier, because two reflectors in the same cluster choosing different IDs will both reflect the same prefix and look like a loop.

Confederations attack the same problem from the other end: a large AS is split into sub-autonomous systems that look like a single AS to the outside world.

router bgp 65010
 bgp confederation identifier 1
 bgp confederation peers 65020 65030

The practical guidance is to standardise on one mechanism. Route reflectors are simpler to operate and to reason about during an outage; confederations give you more policy control between regions but add a layer of AS-path manipulation that makes every future troubleshooting session harder. Whatever you choose, document which routers are clients of which reflector, because that topology is invisible in the running configuration of the clients themselves.

Frequently Asked Questions

Why is my IOS XR BGP neighbor Established but I receive no routes?

The neighbor address-family block is missing, or an inbound route policy is dropping everything. Check show bgp ipv4 unicast neighbors <ip> for the "Nbr is using ... for updates" lines and confirm both the global and neighbor address-family ipv4 unicast blocks exist.

Do I need next-hop-self on iBGP sessions?

On any router that learns routes over eBGP and passes them to iBGP peers, yes — otherwise the iBGP peer inherits an external next hop it has no route to, and the prefix is unusable despite the session being up.

How do I activate a new policy without resetting the session?

Configure soft-reconfiguration inbound on the neighbor, then use clear bgp ipv4 unicast <ip> soft in after changing the policy. Route refresh, which both peers advertise by default, can achieve the same result without storing the extra copy.

原文链接：https://community.cisco.com/t5/networking-knowledge-base/bgp-basic-configuration-on-ios-xr-ibgp-and-ebgp/ta-p/3145638