Internet Routing Architectures (CISCO):Configurinbg Effective Internet Routing Policies Previous Table of Contents Next Trace route from RTG with a source of 172.16.112.1 and a destination 192.68.10.1. RTG#traceroute Protocol [ip]: Target IP address: 192.68.10.1 Source address: 172.16.112.1 Numeric display [n]: Timeout in seconds [3]: Probe count [3]: Minimum Time to Live [1]: Maximum Time to Live [30]: Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to gateway.aeg-aas.de (192.68.10.1) 1 172.16.70.1 4 msec 4 msec 0 msec 2 172.16.20.1 4 msec 4 msec 4 msec 3 192.68.6.1 4 msec 4 msec 4 msec Note how RTA has taken next hop 172.16.20.1 (second line in the trace route output) to reach 192.68.10.0/24, even though RTA's routing table indicates that 192.68.10.0/24 should be reached with next hop 172.16.80.2. This second attempt shows what will happen if Serial 0 is down, and next hop 172.16.20.1 is unreachable. Trace route from RTG with a source of 172.16.112.1 and a destination 192.68.10.1 while Serial 0 is down. RTG#traceroute Protocol [ip]: Target IP address: 192.68.10.1 Source address: 172.16.112.1 Numeric display [n]: Timeout in seconds [3]: Probe count [3]: Minimum Time to Live [1]: Maximum Time to Live [30]: Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to gateway.aeg-aas.de (192.68.10.1) 1 172.16.70.1 0 msec 4 msec 4 msec 2 172.16.80.2 8 msec 4 msec 4 msec RTA has taken the alternate next hop 172.16.80.2. Route Reflectors This example will illustrate a practical use of route reflectors and peer groups. In figure 11-13, RTG and RTA form one cluster where RTG is the route reflector. RTF, RTE, and RTD form another cluster where RTF is the route reflector. RTG and RTF are part of a peer group called REFLECTORS; if there are other route reflectors, all can be IBGP peered in a full mesh. RTF puts all its clients in a peer group called CLIENTS, where common policies can be applied. Figure 11-13  Route reflectors. Clients are indicated by the route reflectors using the "route-reflector-client." Because clients are part of a peer group, client-to-client reflection needs to be turned off to avoid potential problems. Full IBGP mesh will be maintained inside the RTF-RTD-RTE cluster. RTF configuration: router bgp 3 no synchronization no bgp client-to-client reflection network 172.16.65.0 mask 255.255.255.192 network 172.16.50.0 mask 255.255.255.0 network 172.16.25.0 mask 255.255.255.0 network 172.16.30.0 mask 255.255.255.0 neighbor REFLECTORS peer-group neighbor REFLECTORS remote-as 3 neighbor CLIENTS peer-group neighbor CLIENTS remote-as 3 neighbor CLIENTS route-reflector-client neighbor 172.16.25.2 peer-group CLIENTS neighbor 172.16.30.2 peer-group CLIENTS neighbor 172.16.50.2 peer-group REFLECTORS no auto-summary RTD is a client of RTF. From RTD's perspective, the BGP peering session with RTF is a normal IBGP session. Note in the following configuration how RTD has a full IBGP mesh with RTF and RTE. The same goes for RTE. RTD configuration: router bgp 3 no synchronization network 172.16.90.0 mask 255.255.255.0 network 172.16.30.0 mask 255.255.255.0 neighbor 172.16.25.2 remote-as 3 neighbor 172.16.25.2 next-hop-self neighbor 172.16.30.1 remote-as 3 neighbor 172.16.30.1 next-hop-self neighbor 192.68.20.2 remote-as 2 neighbor 192.68.20.2 filter-list 10 out no auto-summary ip as-path access-list 10 permit ^$ RTG configuration: router bgp 3 no synchronization network 172.16.112.0 mask 255.255.255.0 network 172.16.50.0 mask 255.255.255.0 network 172.16.70.0 mask 255.255.255.0 neighbor 172.16.50.1 remote-as 3 neighbor 172.16.70.1 remote-as 3 neighbor 172.16.70.1 route-reflector-client no auto-summary RTA configuration: router bgp 3 no synchronization network 172.16.220.0 mask 255.255.255.0 network 172.16.70.0 mask 255.255.255.0 neighbor 172.16.20.1 remote-as 1 neighbor 172.16.20.1 filter-list 10 out neighbor 172.16.70.2 remote-as 3 neighbor 172.16.70.2 next-hop-self no auto-summary ip as-path access-list 10 permit ^$ The following snapshot shows how RTD sees some of the routes that are being reflected into its own cluster. Note how RTD sees the originator of route 172.16.220.0/24 as 172.16.220.1, which is the router ID of RTA. The route also carries a cluster list that contains the router IDs of all the route reflectors that it passed through. RTD#show ip bgp 172.16.220.0 BGP routing table entry for 172.16.220.0/24, version 52 Paths: (1 available, best #1) Local 172.16.70.1 (metric 192) from 172.16.30.1 (172.16.220.1) Origin IGP, metric 0, localpref 100, valid, internal, best Originator : 172.16.220.1, Cluster list: 172.16.65.1, 172.16.112.1 In the case where multiple route reflectors are configured inside the cluster, all of them have to be configured with a common cluster-ID. This is needed to detect routing loops that might occur between clusters. If RTE, for example, were to be configured as a route reflector, then RTF's and RTE's configuration would need the additional router command bgp cluster-id number. RTF configuration: router bgp 3 no synchronization no bgp client-to-client reflection network 172.16.65.0 mask 255.255.255.192 network 172.16.50.0 mask 255.255.255.0 network 172.16.25.0 mask 255.255.255.0 network 172.16.30.0 mask 255.255.255.0 neighbor REFLECTORS peer-group neighbor REFLECTORS remote-as 3 neighbor CLIENTS peer-group neighbor CLIENTS remote-as 3 neighbor CLIENTS route-reflector-client neighbor 172.16.25.2 peer-group CLIENTS neighbor 172.16.30.2 peer-group CLIENTS neighbor 172.16.50.2 peer-group REFLECTORS bgp cluster-id 1000 no auto-summary Notes:  The cluster-id 1000 is a number identifying the cluster. This is needed in case RTF and RTE are both configured as route reflectors in the same cluster. Previous Table of Contents Next