Internet Routing Architectures (CISCO):Configurinbg Effective Internet Routing Policies

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.

Table of Contents