Route reflectors (RR) achieve the same result as confederations — they remove the need for a full mesh of iBGP peers, allow all iBGP routes to be learned by all iBGP routers in the AS, and prevent loops.
In an iBGP design using RRs, a partial mesh of iBGP peers is designed. Some routers are configured as RR servers; these servers are allowed to learn iBGP routes from their RR clients and then advertise them to other iBGP peers.
Only the router acting as the RR uses modified rules; the other routers (clients and non-clients) are not even aware of the RR, nor do they change their operating rules.
Types of Neighbors to Which Prefixes Are Reflected:
A. Prefix learned from: Client
Routes Advertised to Clients: YES
Routes Advertised to Non-Clients: YES
B. Prefix learned from: Non-Client
Routes Advertised to Clients: YES
Routes Advertised to Non-Clients: NO
C. Prefix learned from: eBGP
Routes Advertised to Clients: YES
Routes Advertised to Non-Clients: YES
One (or more) RR servers, and their clients, create a single RR cluster. A BGP design using RRs can consist of:
- Clusters with multiple RRs in a cluster
- Multiple clusters, although using multiple clusters makes sense only when physical redundancy exists as well.
With multiple clusters, at least one RR from a cluster must be peered with at least one RR in each of the other clusters.
Typically, all RRs are peered directly, creating a full mesh of RR iBGP peers among RRs. Also, if some routers are nonclients, they should be included in the full mesh of RRs.
The RR feature uses several tools to prevent loops, as follows:
- CLUSTER_LIST — RRs add their cluster ID into a BGP PA called the CLUSTER_LIST before sending an Update. When receiving a BGP Update, RRs discard received prefixes for which their cluster ID already appears. As with AS_PATH for confederations, this prevents RRs from looping advertisements between clusters.
- ORIGINATOR_ID — This PA lists the RID of the first iBGP peer to advertise the route into the AS. If a router sees its own BGP ID as the ORIGINATOR_ID in a received route, it does not use or propagate the route.
- Only advertise the best routes — RRs reflect routes only if the RR considers the route to be a “best” route in its own BGP table. This further limits the routes rejected by the RR.
For this lab, we should first shutdown router R5. R1 and R3 will be part of the same BGP RR Cluster (ID 1) and R2 and R4 will be part of Clusted ID 2.
Also, we will shutdown the R1-R2, R1-R4 and R3-R2 links.
This way, we will not have full link redundancy inside the Enterprise (which is actually our goal when using BGP RRs): the only active links are R1-R3, R3-R4 and R4-R2.
Further more, R2 will not have any link to ISP 2 (R102), because it is the one that should receive reflected routes after all the configuration is done. That's why R102's and R103's configurations do not concern us in this lab. Both R102 and R103 could also be shutdown now.
R1(config)#interface serial 0/1
R1(config-if)#shutdown
R1(config)#interface serial 0/2
R1(config-if)#shutdown
R1(config)#interface fastEthernet 0/0
R1(config-if)#shutdown
R2(config)#interface serial 0/1
R2(config-if)#shutdown
R2(config)#interface serial 0/2
R2(config-if)#shutdown
R2(config)#interface fastEthernet 0/0
R2(config-if)#shutdown
R2(config)#interface fastEthernet 0/1
R2(config-if)#shutdown
R3(config)#interface serial 0/0
R3(config-if)#shutdown
R4(config)#interface serial 0/0
R4(config-if)#shutdown
The initial router configs:
R1:
!
interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
ip forward-protocol nd
ip route 3.3.3.3 255.255.255.255 10.1.0.13
ip route 101.101.101.101 255.255.255.255 201.1.1.2
!
R2:
!
interface Loopback2
ip address 2.2.2.2 255.255.255.255
!
ip forward-protocol nd
ip route 1.1.1.1 255.255.255.255 10.1.0.17
ip route 4.4.4.4 255.255.255.255 10.1.0.17
ip route 102.102.102.102 255.255.255.255 202.2.2.6
!
R3:
!
interface Loopback3
ip address 3.3.3.3 255.255.255.255
!
ip forward-protocol nd
ip route 1.1.1.1 255.255.255.255 10.1.0.14
ip route 4.4.4.4 255.255.255.255 10.1.0.10
!
R4:
!
interface Loopback4
ip address 4.4.4.4 255.255.255.255
!
ip forward-protocol nd
ip route 3.3.3.3 255.255.255.255 10.1.0.9
ip route 2.2.2.2 255.255.255.255 10.1.0.18
ip route 1.1.1.1 255.255.255.255 10.1.0.9
!
R101:
!
interface Loopback101
ip address 101.101.101.101 255.255.255.255
!
router bgp 101
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 password ccnp
neighbor 1.1.1.1 ebgp-multihop 2
neighbor 1.1.1.1 update-source Loopback101
neighbor 104.104.104.104 remote-as 104
neighbor 104.104.104.104 password ccnp
neighbor 104.104.104.104 ebgp-multihop 2
neighbor 104.104.104.104 update-source Loopback101
no auto-summary
!
ip forward-protocol nd
ip route 1.1.1.1 255.255.255.255 201.1.1.1
ip route 104.104.104.104 255.255.255.255 114.1.1.2
!
R104:
!
interface Loopback40
ip address 192.168.40.40 255.255.255.255
!
interface Loopback41
ip address 192.168.41.41 255.255.255.255
!
interface Loopback42
ip address 192.168.42.42 255.255.255.255
!
interface Loopback43
ip address 192.168.43.43 255.255.255.255
!
interface Loopback44
ip address 192.168.44.44 255.255.255.255
!
interface Loopback104
ip address 104.104.104.104 255.255.255.255
!
router bgp 104
no synchronization
bgp log-neighbor-changes
network 192.168.40.40 mask 255.255.255.255
network 192.168.41.41 mask 255.255.255.255
network 192.168.42.42 mask 255.255.255.255
network 192.168.43.43 mask 255.255.255.255
network 192.168.44.44 mask 255.255.255.255
neighbor 101.101.101.101 remote-as 101
neighbor 101.101.101.101 password ccnp
neighbor 101.101.101.101 ebgp-multihop 2
neighbor 101.101.101.101 update-source Loopback104
neighbor 103.103.103.103 remote-as 103
neighbor 103.103.103.103 ebgp-multihop 2
neighbor 103.103.103.103 update-source Loopback104
no auto-summary
!
ip route 101.101.101.101 255.255.255.255 114.1.1.1
ip route 103.103.103.103 255.255.255.255 134.1.1.1
!
BGP RR configurations:
Reminder: The RR Server - RR Client peering is iBGP. Also, peerings between RR Servers in different clusters are iBGP.
In our topology, in Cluster 1 R3 will be the RR Server and R1 will be the RR Client. In Cluster 2, R4 is the RR Server and R2 is the RR Client.
We will establish iBGP peerings between the server and client in each cluster and also between the servers in different clusters.
R101 will advertise to R1 the 192.168.x.x/32 routes coming from R104 and then the RR process will reflect those routes all the way to R2, following the R1-R3-R4-R2 circuit.
R1(config)#router bgp 100
R1(config-router)#neighbor 3.3.3.3 remote-as 100
R1(config-router)#neighbor 3.3.3.3 update-source loopback 1
R1(config-router)#neighbor 3.3.3.3 next-hop-self
R1(config-router)#neighbor 101.101.101.101 remote-as 101
R1(config-router)#neighbor 101.101.101.101 ebgp-multihop 2
R1(config-router)#neighbor 101.101.101.101 update-source loopback 1
R1(config-router)#neighbor 101.101.101.101 password ccnp
R3(config)#router bgp 100
R3(config-router)#bgp cluster-id 1
R3(config-router)#neighbor 1.1.1.1 remote-as 100
R3(config-router)#neighbor 1.1.1.1 update-source loopback 3
R3(config-router)#neighbor 1.1.1.1 route-reflector-client
R3(config-router)#neighbor 4.4.4.4 remote-as 100
R3(config-router)#neighbor 4.4.4.4 update-source loopback 3
R3(config-router)#neighbor 4.4.4.4 next-hop-self
R4(config)#router bgp 100
R4(config-router)#bgp cluster-id 2
R4(config-router)#neighbor 2.2.2.2 remote-as 100
R4(config-router)#neighbor 2.2.2.2 update-source loopback 4
R4(config-router)#neighbor 2.2.2.2 route-reflector-client
R4(config-router)#neighbor 2.2.2.2 next-hop-self
R4(config-router)#neighbor 3.3.3.3 remote-as 100
R4(config-router)#neighbor 3.3.3.3 update-source loopback 4
R2(config)#router bgp 100
R2(config-router)#neighbor 4.4.4.4 remote-as 100
R2(config-router)#neighbor 4.4.4.4 update-source loopback 2
Verification commands:
R3#show ip bgp 192.168.40.40
BGP routing table entry for 192.168.40.40/32, version 26
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
2
101 104, (Received from a RR-client)
1.1.1.1 from 1.1.1.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
R4#show ip bgp 192.168.40.40
BGP routing table entry for 192.168.40.40/32, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
Advertised to update-groups:
1
101 104
1.1.1.1 from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 1.1.1.1, Cluster list: 0.0.0.1
R2#show ip bgp 192.168.40.40
BGP routing table entry for 192.168.40.40/32, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
Not advertised to any peer
101 104
1.1.1.1 from 4.4.4.4 (4.4.4.4)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 1.1.1.1, Cluster list: 0.0.0.2, 0.0.0.1
The final working BGP RR configurations on all 4 routers are:
R1:
!
interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
router ospf 1
router-id 1.1.1.1
log-adjacency-changes
network 10.1.0.0 0.0.0.255 area 0
!
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 3.3.3.3 remote-as 100
neighbor 3.3.3.3 update-source Loopback1
neighbor 3.3.3.3 next-hop-self
neighbor 101.101.101.101 remote-as 101
neighbor 101.101.101.101 password ccnp
neighbor 101.101.101.101 ebgp-multihop 2
neighbor 101.101.101.101 update-source Loopback1
no auto-summary
!
ip forward-protocol nd
ip route 3.3.3.3 255.255.255.255 10.1.0.13
ip route 101.101.101.101 255.255.255.255 201.1.1.2
!
R3:
!
interface Loopback3
ip address 3.3.3.3 255.255.255.255
!
router ospf 1
router-id 3.3.3.3
log-adjacency-changes
network 10.1.0.0 0.0.0.255 area 0
!
router bgp 100
no synchronization
bgp cluster-id 1
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 update-source Loopback3
neighbor 1.1.1.1 route-reflector-client
neighbor 4.4.4.4 remote-as 100
neighbor 4.4.4.4 update-source Loopback3
neighbor 4.4.4.4 next-hop-self
no auto-summary
!
ip forward-protocol nd
ip route 1.1.1.1 255.255.255.255 10.1.0.14
ip route 4.4.4.4 255.255.255.255 10.1.0.10
!
R4:
!
interface Loopback4
ip address 4.4.4.4 255.255.255.255
!
router ospf 1
router-id 4.4.4.4
log-adjacency-changes
network 10.1.0.0 0.0.0.255 area 0
!
router bgp 100
no synchronization
bgp cluster-id 2
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 update-source Loopback4
neighbor 2.2.2.2 route-reflector-client
neighbor 2.2.2.2 next-hop-self
neighbor 3.3.3.3 remote-as 100
neighbor 3.3.3.3 update-source Loopback4
no auto-summary
!
ip forward-protocol nd
ip route 1.1.1.1 255.255.255.255 10.1.0.9
ip route 2.2.2.2 255.255.255.255 10.1.0.18
ip route 3.3.3.3 255.255.255.255 10.1.0.9
!
R2:
!
interface Loopback2
ip address 2.2.2.2 255.255.255.255
!
router ospf 1
router-id 2.2.2.2
log-adjacency-changes
network 10.1.0.0 0.0.0.255 area 0
!
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 4.4.4.4 remote-as 100
neighbor 4.4.4.4 update-source Loopback2
no auto-summary
!
ip forward-protocol nd
ip route 1.1.1.1 255.255.255.255 10.1.0.17
ip route 4.4.4.4 255.255.255.255 10.1.0.17
ip route 102.102.102.102 255.255.255.255 202.2.2.6
!
Note: For more details about this topic, check out CCIE Routing and Switching Certification Guide, Fourth Edition, Wendell Odom, Rus Healy, Denise Donohue, Cisco Press.
No comments:
Post a Comment