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