Skip to content
Log in Sign up My account

BGP Lab: eBGP, iBGP with Route Reflector, and Policy

This lab builds a small BGP network on IOS XE from nothing. Three routers in AS 65100 run OSPF and an iBGP route reflector design, and a fourth router in AS 65200 peers with two of them over eBGP. Then you add policy: local preference to choose the outbound exit, AS-path prepending to influence inbound traffic, and communities to signal intent between the two ASes. Every step has the config and the commands that prove it worked.

Topology

graph LR
    R4["R4 AS 65200<br/>lo0 10.0.0.4"]
    R1["R1 AS 65100<br/>lo0 10.0.0.1"]
    R3["R3 AS 65100<br/>lo0 10.0.0.3"]
    R2["R2 RR AS 65100<br/>lo0 10.0.0.2"]
    R4 ---|"172.16.14.0/30"| R1
    R4 ---|"172.16.34.0/30"| R3
    R1 ---|"10.1.12.0/30"| R2
    R3 ---|"10.1.23.0/30"| R2
Link Subnet Addresses
R1 - R2 10.1.12.0/30 R1 .1, R2 .2
R2 - R3 10.1.23.0/30 R2 .1, R3 .2
R1 - R4 172.16.14.0/30 R1 .1, R4 .2
R3 - R4 172.16.34.0/30 R3 .1, R4 .2

Loopback0 is 10.0.0.X/32 where X is the router number. Interface names below (GigabitEthernet2, 3) are placeholders. Match them to your platform.

R2 is the route reflector. R1 and R3 are its clients. R1 and R3 are the two exits from AS 65100. R4 is a customer or upstream originating two prefixes. R2 originates 10.100.0.0/24.

Step 1: Addressing and the IGP

iBGP needs loopback reachability, so run OSPF inside AS 65100. R4 does not run OSPF.

! R1
hostname R1
interface Loopback0
 ip address 10.0.0.1 255.255.255.255
 ip ospf 1 area 0
interface GigabitEthernet2
 description to R2
 ip address 10.1.12.1 255.255.255.252
 ip ospf 1 area 0
 ip ospf network point-to-point
 no shutdown
interface GigabitEthernet3
 description to R4
 ip address 172.16.14.1 255.255.255.252
 no shutdown
router ospf 1
 router-id 10.0.0.1

! R2
hostname R2
interface Loopback0
 ip address 10.0.0.2 255.255.255.255
 ip ospf 1 area 0
interface GigabitEthernet2
 description to R1
 ip address 10.1.12.2 255.255.255.252
 ip ospf 1 area 0
 ip ospf network point-to-point
 no shutdown
interface GigabitEthernet3
 description to R3
 ip address 10.1.23.1 255.255.255.252
 ip ospf 1 area 0
 ip ospf network point-to-point
 no shutdown
router ospf 1
 router-id 10.0.0.2

! R3
hostname R3
interface Loopback0
 ip address 10.0.0.3 255.255.255.255
 ip ospf 1 area 0
interface GigabitEthernet2
 description to R2
 ip address 10.1.23.2 255.255.255.252
 ip ospf 1 area 0
 ip ospf network point-to-point
 no shutdown
interface GigabitEthernet3
 description to R4
 ip address 172.16.34.1 255.255.255.252
 no shutdown
router ospf 1
 router-id 10.0.0.3

Verify before touching BGP.

R1# show ip ospf neighbor
R1# ping 10.0.0.3 source loopback0

R1 must reach R3's loopback through R2. If that fails, do not continue. iBGP sessions will not come up.

Step 2: iBGP with a route reflector

Without a reflector, iBGP needs a full mesh because a router will not advertise a route learned from one iBGP peer to another. A route reflector (RFC 4456) breaks that rule for its clients. Here R2 reflects between R1 and R3.

! R2 (route reflector)
router bgp 65100
 bgp router-id 10.0.0.2
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 10.0.0.1 remote-as 65100
 neighbor 10.0.0.1 update-source Loopback0
 neighbor 10.0.0.3 remote-as 65100
 neighbor 10.0.0.3 update-source Loopback0
 address-family ipv4
  network 10.100.0.0 mask 255.255.255.0
  neighbor 10.0.0.1 activate
  neighbor 10.0.0.1 route-reflector-client
  neighbor 10.0.0.1 send-community both
  neighbor 10.0.0.3 activate
  neighbor 10.0.0.3 route-reflector-client
  neighbor 10.0.0.3 send-community both
 exit-address-family
ip route 10.100.0.0 255.255.255.0 Null0

The network statement only advertises a route that exists in the routing table, which is why the Null0 static is there.

R1 and R3 peer only with R2 for iBGP. They use next-hop-self towards the reflector. This matters: a route learned from R4 has a next hop of 172.16.14.2, which is not in OSPF, so R3 would not be able to use it. With next-hop-self, R1 advertises itself (10.0.0.1) as the next hop, which every router can reach.

! R1
router bgp 65100
 bgp router-id 10.0.0.1
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 10.0.0.2 remote-as 65100
 neighbor 10.0.0.2 update-source Loopback0
 address-family ipv4
  neighbor 10.0.0.2 activate
  neighbor 10.0.0.2 next-hop-self
  neighbor 10.0.0.2 send-community both
 exit-address-family

! R3
router bgp 65100
 bgp router-id 10.0.0.3
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 10.0.0.2 remote-as 65100
 neighbor 10.0.0.2 update-source Loopback0
 address-family ipv4
  neighbor 10.0.0.2 activate
  neighbor 10.0.0.2 next-hop-self
  neighbor 10.0.0.2 send-community both
 exit-address-family

Verify:

R2# show ip bgp summary
R3# show ip bgp 10.100.0.0

R2 should show both neighbours with a prefix count in the State/PfxRcd column rather than Idle or Active. R3 should see 10.100.0.0/24 with next hop 10.0.0.2, internal, and localpref 100 (the default). If the neighbour sits in Active, the usual causes are no loopback reachability, a missing update-source, or a mismatched AS number.

Step 3: eBGP with AS 65200

! R4
hostname R4
interface Loopback0
 ip address 10.0.0.4 255.255.255.255
interface GigabitEthernet2
 description to R1
 ip address 172.16.14.2 255.255.255.252
 no shutdown
interface GigabitEthernet3
 description to R3
 ip address 172.16.34.2 255.255.255.252
 no shutdown
ip route 198.51.100.0 255.255.255.0 Null0
ip route 203.0.113.0 255.255.255.0 Null0
router bgp 65200
 bgp router-id 10.0.0.4
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 172.16.14.1 remote-as 65100
 neighbor 172.16.34.1 remote-as 65100
 address-family ipv4
  network 198.51.100.0 mask 255.255.255.0
  network 203.0.113.0 mask 255.255.255.0
  neighbor 172.16.14.1 activate
  neighbor 172.16.34.1 activate
 exit-address-family

Add the eBGP neighbours on R1 and R3. Peering is on directly connected addresses, so no update-source or multihop is needed.

! R1
router bgp 65100
 neighbor 172.16.14.2 remote-as 65200
 address-family ipv4
  neighbor 172.16.14.2 activate

! R3
router bgp 65100
 neighbor 172.16.34.2 remote-as 65200
 address-family ipv4
  neighbor 172.16.34.2 activate

Verify:

R2# show ip bgp
R4# show ip bgp

R2 should hold 198.51.100.0/24 and 203.0.113.0/24 twice, once via 10.0.0.1 and once via 10.0.0.3. It marks one with > (best). With equal attributes the tie is broken by lower router ID or neighbour address. R4 should see 10.100.0.0/24 twice, with paths 65100 i from both neighbours.

Note

IOS XE accepts and sends eBGP routes without any policy. IOS XR does not: there you must attach a route policy to every eBGP neighbour address family or the session carries no routes. Keep this in mind if you move the lab to XR.

Step 4: Local preference chooses the exit

Local preference is carried inside the AS and the highest value wins. The goal is for AS 65100 to send traffic towards R4's prefixes via R1.

! R1
route-map FROM-R4 permit 10
 set local-preference 200
router bgp 65100
 address-family ipv4
  neighbor 172.16.14.2 route-map FROM-R4 in

R1# clear ip bgp 172.16.14.2 soft in
R2# show ip bgp 198.51.100.0

On R2 the path via 10.0.0.1 should now show localpref 200 and be best, and the path via R3 stays at 100. On R3, the best path is also via R2's reflected route through R1, because the reflector sends only its best path to clients. Run traceroute 198.51.100.1 source 10.0.0.3 from R3 to see it go through R2 and R1.

Step 5: AS-path prepend influences inbound traffic

Local preference only works for outbound decisions. To steer R4's traffic towards 10.100.0.0/24 to enter through R1, make the path via R3 look longer. R3 prepends its own AS on the advertisement to R4.

! R3
ip prefix-list OUR-NET seq 5 permit 10.100.0.0/24
route-map TO-R4 permit 10
 match ip address prefix-list OUR-NET
 set as-path prepend 65100 65100 65100
route-map TO-R4 permit 20
router bgp 65100
 address-family ipv4
  neighbor 172.16.34.2 route-map TO-R4 out

R3# clear ip bgp 172.16.34.2 soft out
R4# show ip bgp 10.100.0.0

R4 now shows two paths. The one via 172.16.14.1 has AS path 65100, and the one via 172.16.34.1 has 65100 65100 65100 65100. The shorter path wins, so R4 sends to R1. The empty permit at sequence 20 matters: without it the route-map has an implicit deny and R3 would stop advertising everything else to R4.

Tip

Prepend your own AS number. Prepending another AS is forging a path, and many providers filter it.

Step 6: Communities signal intent

A community is a tag attached to a route. Standard communities are 32 bits written AS:value (RFC 1997). The meaning is a convention you agree with the neighbour. Here R4 tells AS 65100 "treat the 203.0.113.0/24 route on this link as a backup" by tagging it with 65200:80, and R1 acts on the tag by lowering local preference.

First R4 attaches the community on the session to R1 only.

! R4
ip bgp-community new-format
ip prefix-list BACKUP-NET seq 5 permit 203.0.113.0/24
route-map TO-R1 permit 10
 match ip address prefix-list BACKUP-NET
 set community 65200:80
route-map TO-R1 permit 20
router bgp 65200
 address-family ipv4
  neighbor 172.16.14.1 send-community
  neighbor 172.16.14.1 route-map TO-R1 out

Then R1 matches the community on the way in and reacts. This replaces the Step 4 route-map.

! R1
ip bgp-community new-format
ip community-list standard BACKUP permit 65200:80
route-map FROM-R4 permit 10
 match community BACKUP
 set local-preference 80
route-map FROM-R4 permit 20
 set local-preference 200

R4# clear ip bgp 172.16.14.1 soft out
R1# clear ip bgp 172.16.14.2 soft in
R2# show ip bgp 203.0.113.0
R2# show ip bgp 198.51.100.0

For 203.0.113.0/24 the path via R1 shows localpref 80 and community 65200:80, so the path via R3 (100) wins and traffic exits through R3. For 198.51.100.0/24 nothing is tagged, so R1 gives 200 and traffic exits through R1. One policy, two behaviours, driven by a tag from the neighbour.

Communities reach R2 only because R1 uses send-community both towards the reflector. Forget that and the tag disappears at the first iBGP hop. Two well-known communities are worth knowing: no-export keeps a route inside the AS (or confederation) and no-advertise keeps it off all peers.

Step 7: Final verification checklist

show ip bgp summary
show ip bgp neighbors 10.0.0.2 advertised-routes
show ip bgp neighbors 172.16.14.2 received-routes
show ip bgp community 65200:80
show ip bgp regexp ^65200_
show ip route bgp

received-routes works only if you configure neighbor ... soft-reconfiguration inbound on that neighbour. Without it use show ip bgp neighbors ... routes, which shows what was accepted. In day-to-day work, show ip bgp x.x.x.x is the command that tells you why a given path won, and its output lists the attributes you used here in order of the best-path algorithm: weight, local preference, locally originated, AS-path length, origin, MED, eBGP over iBGP, IGP metric to next hop, then router ID.

Warning

Always use soft in and soft out when changing policy in production. A hard clear ip bgp tears down the session and withdraws every route.

Things to try next

  • Add neighbor ... password to the eBGP sessions and watch them fail when the passwords differ.
  • Replace the single reflector with two (give both the same cluster ID or different ones, and read what each choice does to loop prevention).
  • Set MED on R4's advertisements and see it compared only between paths from the same neighbouring AS.

For exam-focused BGP coverage start from the CCNP home page and the study plan. The next lab in this section is the OSPF multi-area lab.

References