BGP route reflection is described in RFC 4456.
The method of doing loop prevention inside the route reflection cluster is done by the route reflector adding a router ID to the ORIGINATOR_ID attribute of an update, corresponding to the router ID of the advertising router, before reflecting the route. The route is also reflected back to the same neighbor that originated it, which will discard it based on seeing its own router ID in the ORIGINATOR_ID field of the update message.
The route reflector also adds the cluster-ID to the CLUSTER_LIST attribute, when reflecting routes learned from clients and non-clients. If a route is received inbound on the route reflector, that is marked with that route reflectors local cluster-ID, it will be discarded.
There are essentially three roles a router can assume in a route reflection cluster: route reflector, client and non-client.
Route reflector: this router will act as a hub for the client routers to peer with and will advertise routes in the following ways:
- routes learned from non-client iBGP peers will be advertised to clients only
- routes learned from client peers will be advertised to clients and non-clients (except for the originator of the route)
- routes learned from eBGP peers will advertised to clients and non-clients
Non-client: this router is not part of the route reflection cluster. This is a regular iBGP or eBGP peer.
Below example is based on the topology from the previous post on peer groups. Building on top of that scenario, where the routers R2, R3 and R4 are peered only with R1, and R1 is configured with the routers R2, R3 and R4 in the same peer group.
 |
| Route Reflection Cluster topology |
First, see the problem with not having a full mesh iBGP network from the perspective of R2s routing table and BGP table.
R2#show ip route | begin GatewayThere are no dynamic routes in the routing table and the BGP table holds only one entry, which is the one injected locally by the router itself.
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.12.0/24 is directly connected, GigabitEthernet1.12
L 10.0.12.2/32 is directly connected, GigabitEthernet1.12
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.2.0/24 is directly connected, Loopback1
L 172.16.2.1/32 is directly connected, Loopback1
R2#show ip bgp
BGP table version is 6, local router ID is 10.0.12.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 172.16.2.0/24 0.0.0.0 0 32768 i
Now, we configure the router R1 to treat the routers R2, R3 and R4 as route reflector clients.
R1(config-router)#neighbor PGROUP route-reflector-clientNotice how the single command neighbor <peer group> route-reflector-client prompts the neighbors to reset their relationship - meaning, this is not something to tinker with in a live environment, as the forwarding plane will be affected during the transient period.
*Apr 9 09:37:16.347: %BGP-5-NBR_RESET: Neighbor 10.0.12.2 reset (RR client config change)
*Apr 9 09:37:16.347: %BGP-5-NBR_RESET: Neighbor 10.0.13.3 reset (RR client config change)
*Apr 9 09:37:16.347: %BGP-5-NBR_RESET: Neighbor 10.0.14.4 reset (RR client config change)
*Apr 9 09:37:16.348: %BGP-5-ADJCHANGE: neighbor 10.0.12.2 Down RR client config change
*Apr 9 09:37:16.348: %BGP_SESSION-5-ADJCHANGE: neighbor 10.0.12.2 IPv4 Unicast topology base removed from session RR client config change
*Apr 9 09:37:16.348: %BGP-5-ADJCHANGE: neighbor 10.0.13.3 Down RR client config change
*Apr 9 09:37:16.348: %BGP_SESSION-5-ADJCHANGE: neighbor 10.0.13.3 IPv4 Unicast topology base removed from session RR client config change
*Apr 9 09:37:16.348: %BGP-5-ADJCHANGE: neighbor 10.0.14.4 Down RR client config change
*Apr 9 09:37:16.348: %BGP_SESSION-5-ADJCHANGE: neighbor 10.0.14.4 IPv4 Unicast topology base removed from session RR client config change
*Apr 9 09:37:16.500: %BGP-5-ADJCHANGE: neighbor 10.0.12.2 Up
Below is the routing table and BGP table on R2 after the network has converged.
R2#show ip route | begin GatewayStill no dynamic routes in the routing table, but the BGP table now holds two more entries. Notice how they are marked as valid, but not as best. The route reflector (R1) receives the routes from R3 and R4 and proceeds to advertise them on to R2. The next hop of 10.0.13.3 and 10.0.14.4 is the problem here. Router R2 cannot reach the next hops and therefore the routes cannot be entered into the routing table.
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.12.0/24 is directly connected, GigabitEthernet1.12
L 10.0.12.2/32 is directly connected, GigabitEthernet1.12
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.2.0/24 is directly connected, Loopback1
L 172.16.2.1/32 is directly connected, Loopback1
R2#show ip bgp
BGP table version is 6, local router ID is 10.0.12.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 172.16.2.0/24 0.0.0.0 0 32768 i
* i 172.16.3.0/24 10.0.13.3 0 100 0 i
* i 172.16.4.0/24 10.0.14.4 0 100 0 i
To fix this issue - just run an IGP on the 10.0.0.0 /8 network and the routing information will flow. Below is shown the routing table and BGP table on R2 after EIGRP has been enabled on all routers in the network.
R2#show ip route | begin GatewayNow there are both EIGRP and BGP routes in the routing table. Also, the prefixes in the BGP table are now marked as valid and best due to the next hop reachability issue being fixed by enabling EIGRP.
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.0.12.0/24 is directly connected, GigabitEthernet1.12
L 10.0.12.2/32 is directly connected, GigabitEthernet1.12
D 10.0.13.0/24 [90/3072] via 10.0.12.1, 00:00:10, GigabitEthernet1.12
D 10.0.14.0/24 [90/3072] via 10.0.12.1, 00:00:10, GigabitEthernet1.12
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 172.16.2.0/24 is directly connected, Loopback1
L 172.16.2.1/32 is directly connected, Loopback1
B 172.16.3.0/24 [200/0] via 10.0.13.3, 00:00:05
B 172.16.4.0/24 [200/0] via 10.0.14.4, 00:00:05
R2#show ip bgp
BGP table version is 8, local router ID is 10.0.12.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 172.16.2.0/24 0.0.0.0 0 32768 i
*>i 172.16.3.0/24 10.0.13.3 0 100 0 i
*>i 172.16.4.0/24 10.0.14.4 0 100 0 i
In the upcoming post we will add some eBGP and non-clients to the fray and see how the RR cluster handles that.
No comments:
Post a Comment