10.4 Case Study 4: Scaling BGP
10.4.1 Route ReflectorFigure 10-10 shows the topology we will implement. Typically you will not want to place your route-reflector server as a border router for an AS. We have included this scenario so that route propagation can be understood easily. For this case study, we will only implement one route-reflector server, and two route-reflector clients . AS100 is running OSPF area 0.0.0.0 on each of the routers with passive interfaces on the external links. Figure 10-10. Route-Reflector Case Study Topology Now we will take a look at the configurations for this topology and detail what is going on. First, we will take a look at San Francisco, Boston, and San Jose. These routers are external routers and are running only EBGP to AS100. The configurations for San Francisco, Boston, and San Jose are nothing more than your typical EBGP peering sessions. Each one of the routers is advertising a single prefix into BGP. We accomplish this by setting up a static route for our network to be advertised under the routing-options hierarchy. We then export static-routes in the group EBGP hierarchy. The first example shows the configuration for San Francisco. interfaces { fe-0/1/1 { unit 0 { family inet { address 10.0.16.1/24; } } } lo0 { unit 0 { family inet { address 127.0.0.1/32; address 192.168.16.1/32; } } } } routing-options { static { route 172.16.5.0/24 receive; } router-id 192.168.16.1; autonomous-system 500; } protocols { bgp { group EBGP { type external; export static-routes; neighbor 10.0.16.2 { peer-as 100; } } } } policy-options { policy-statement static-routes { from protocol static; then accept; } } The Boston and San Jose configurations are identical, except for the advertising addresses. The next two examples show their configurations. The configuration for Boston is listed here: interfaces { fe-0/1/0 { unit 0 { family inet { address 10.0.29.1/24; } } } lo0 { unit 0 { family inet { address 127.0.0.1/32; address 192.168.28.1/32; } } } } routing-options { static { route 172.16.6.0/24 receive; } router-id 192.168.28.1; autonomous-system 600; } protocols { bgp { group EBGP { type external; export static-routes; neighbor 10.0.29.2 { peer-as 100; } } } } policy-options { policy-statement static-routes { from protocol static; then accept; } } The configuration for San Jose is listed here: interfaces { fe-0/1/2 { unit 0 { family inet { address 10.0.50.1/24; } } } lo0 { unit 0 { family inet { address 127.0.0.1/32; address 192.168.20.1/32; } } } } routing-options { static { route 172.16.7.0/24 receive; } router-id 192.168.20.1; autonomous-system 700; } protocols { bgp { group EBGP { type external; export static-routes; neighbor 10.0.50.2 { peer-as 100; } } } } policy-options { policy-statement static-routes { from protocol static; then accept; } } When using route-reflector designs, each route reflector must be part of the AS's IBGP full-mesh. Next, we list the configuration for the nonclient IBGP peer in AS100, New York. New York is configured as a typical IBGP router. The peer session is set up on the physical interfaces for this example. This does not impact routing in this topology. interfaces { fe-0/1/0 { unit 0 { family inet { address 10.0.29.2/24; } } } fe-0/1/1 { unit 0 { family inet { address 10.0.24.2/24; } } } lo0 { unit 0 { family inet { address 127.0.0.1/32; address 192.168.24.1/32; } } } } routing-options { router-id 192.168.24.1; autonomous-system 100; } protocols { bgp { group IBGP { type internal; local-address 192.168.24.1; neighbor 192.168.2.1; } group EBGP { type external; neighbor 10.0.29.1 { peer-as 600; } } } ospf { area 0.0.0.0 { interface lo0.0; interface fe-0/1/1.0; interface fe-0/1/0.0 { passive; } } } } Until now, we have seen nothing more than typical BGP configurations. We did deviate from the typical loopback address peering for the IBGP neighbors in this study. Now we will discuss our route reflector and the clients. Washington D.C. is the route reflector. We need to do two things to make this topology successful. The first is to identify Washington D.C. as a route reflector by specifying the cluster ID in the BGP configuration, and the second is to create the IBGP links between Washington D.C. and Denver and between Washington D.C. and Atlanta. Owing to the nature of IBGP and the use of route reflectors to reduce the IBGP full-mesh problem, you will not see a peering session between Denver and Atlanta. Washington D.C.'s configuration is listed below. The group RRCLIENTS contains the route-reflector configuration. We will be using 192.168.2.1 as the cluster ID. This is also the loopback interface address and the RID. The cluster ID, you will recall, is unique to each route-reflector cluster. It is used for loop detection. Essentially, a cluster will not accept routes that have its own cluster ID in the prefix advertisement. In the [protocols bgp group RRCLIENT] hierarchy, we also specify our peers; these will be Denver and Atlanta, our route-reflector clients. interfaces { fe-0/1/0 { unit 0 { family inet { address 10.0.2.1/24; } } } fe-0/1/1 { unit 0 { family inet { address 10.0.24.1/24; } } } fe-0/1/2 { unit 0 { family inet { address 10.0.1.1/24; } } } fe-0/1/3 { unit 0 { family inet { address 10.0.50.2/24; } } } lo0 { unit 0 { family inet { address 127.0.0.1/32; address 192.168.2.1/32; } } } } routing-options { router-id 192.168.2.1; autonomous-system 100; } protocols { bgp { group RRCLIENTS { type internal; local-address 192.168.2.1; cluster 192.168.2.1; neighbor 192.168.0.1; neighbor 192.168.5.1; } group EBGP { type external; neighbor 10.0.50.1 { peer-as 700; } } group IBGP { type internal; local-address 192.168.2.1; neighbor 192.168.24.1; } } ospf { area 0.0.0.0 { interface all; interface fe-0/1/3.0 { passive; } } } } This next example shows Denver's configuration. Denver is one of the two route-reflector clients. The configuration for the peering session to the route reflection can be found under the [protocols bgp group RR] hierarchy. We also have Denver injecting a route into the BGP protocol, so we can view what the route will look like in the routing tables. Denver also has an external connection to AS500. interfaces { fe-0/1/1 { unit 0 { family inet { address 10.0.16.2/24; } } } fe-0/1/2 { unit 0 { family inet { address 10.0.1.2/24; } } } lo0 { unit 0 { family inet { address 127.0.0.1/32; address 192.168.0.1/32; } } } } routing-options { static { route 172.16.2.0/24 receive; } router-id 192.168.0.1; autonomous-system 100; } protocols { bgp { export static-routes; group RR { type internal; local-address 192.168.0.1; neighbor 192.168.2.1; } group EBGP { type external; neighbor 10.0.16.1 { peer-as 500; } } } ospf { area 0.0.0.0 { interface lo0.0; interface fe-0/1/2.0; interface fe-0/1/1.0 { passive; } } } } policy-options { policy-statement static-routes { from protocol static; then accept; } } Atlanta is the second route-reflector client. It only connects to Washington D.C. The configuration for Atlanta is below: interfaces { fe-0/1/2 { unit 0 { family inet { address 10.0.2.2/24; } } } lo0 { unit 0 { family inet { address 127.0.0.1/32; address 192.168.5.1/32; } } } } routing-options { router-id 192.168.5.1; autonomous-system 100; } protocols { bgp { group RR { type internal; local-address 192.168.5.1; neighbor 192.168.2.1; } } ospf { area 0.0.0.0 { interface lo0.0; interface fe-0/1/2.0; } } } Now that we have covered the configurations, we will take a look at how it all works together. The focus here is on Washington D.C., Denver, and Atlanta. In this situation, Denver is advertising a route 172.16.2.0/24 to Washington D.C. Washington D.C. will receive this route and advertise it, as it should, to the external peers, internal nonclient peers, and internal client peers. This differs from what we are used to with IBGP. When normal IBGP rules apply, Washington D.C. would not readvertise the prefix 172.16.2.0/24 to either Denver or New York. Since route reflection uses a relaxed rule set, the route-reflector server is able to make the necessary advertisements, so that the route can be propagated properly throughout the AS. The following output is of the show route 172.16.2.0 detail command. There is nothing significant here indicating that this is a reflector-client relationship. However, Washington D.C. will now advertise this route to Atlanta, New York, and San Jose. lab@DC> show route 172.16.2.0/24 detail inet.0: 20 destinations, 20 routes (19 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.16.2.0/24 (1 entry, 1 announced) *BGP Preference: 170/-101 Source: 192.168.0.1 Nexthop: 10.0.1.2 via fe-0/1/2.0, selected Protocol Nexthop: 192.168.0.1 Indirect nexthop: 83784c8 63 State: <Active Int Ext> Local AS: 100 Peer AS: 100 Age: 11:44 Metric2: 10 Task: BGP_100.192.168.0.1+179 Announcement bits (3): 0-KRT 1-BGP.0.0.0.0+179 4-Resolve inet.0 AS path: I Localpref: 100 Router ID: 192.168.0.1 The next example is the same show route 172.16.2.0/24 detail from router New York. You can see that the CLUSTER_LIST is 192.168.2.1 . This is the cluster ID we assigned to the router Washington D.C. The Originator ID is 192.168.0.1 . Router Washington D.C. adds the both of these to the prefix, before advertising it to another IBGP peer. If this route were to somehow be advertised back into this same route-reflector cluster, the route reflector would see its own cluster ID in this list and would not accept the advertisement. If the originator of a route receives a prefix with its RID as the Originator ID of the prefix, the router will not accept the announcement. lab@NewYork> show route 172.16.2.0/24 detail inet.0: 18 destinations, 18 routes (17 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.16.2.0/24 (1 entry, 1 announced) *BGP Preference: 170/-101 Source: 192.168.2.1 Nexthop: 10.0.24.1 via fe-0/1/1.0, selected Protocol Nexthop: 192.168.0.1 Indirect nexthop: 83784c8 47 State: <Active Int Ext> Local AS: 100 Peer AS: 100 Age: 12:40 Metric2: 20 Task: BGP_100.192.168.2.1+179 Announcement bits (3): 0-KRT 1-BGP.0.0.0.0+179 2-Resolve inet.0 AS path: I <Originator> Cluster list: 192.168.2.1 Originator ID: 192.168.0.1 Localpref: 100 Router ID: 192.168.2.1 The following example shows the output for show route 172.16.2.0 on Atlanta. It has the same type of results as the nonclient peer. lab@Atlanta> show route 172.16.2.0/24 detail inet.0: 17 destinations, 17 routes (16 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.16.2.0/24 (1 entry, 1 announced) *BGP Preference: 170/-101 Source: 192.168.2.1 Nexthop: 10.0.2.1 via fe-0/1/2.0, selected Protocol Nexthop: 192.168.0.1 Indirect nexthop: 8378550 58 State: <Active Int Ext> Local AS: 100 Peer AS: 100 Age: 15:40 Metric2: 20 Task: BGP_100.192.168.2.1+179 Announcement bits (2): 0-KRT 4-Resolve inet.0 AS path: I <Originator> Cluster list: 192.168.2.1 Originator ID: 192.168.0.1 Localpref: 100 Router ID: 192.168.2.1 Next, we will take a look at the routes that are advertised into AS100 from our external neighbors. Our next example shows the routing table for New York, looking for prefix 172.16.6.0/24 from Boston. There is nothing unusual about this route advertisement. It is a typical EBGP-advertised route. We will not show Washington D.C.'s table for this as there is no change in the route. The next-hop is shown to be New York. lab@NewYork> show route 172.16.6.0/24 detail inet.0: 18 destinations, 18 routes (17 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.16.6.0/24 (1 entry, 1 announced) *BGP Preference: 170/-101 Source: 10.0.29.1 Nexthop: 10.0.29.1 via fe-0/1/0.0, selected State: <Active Ext> Local AS: 100 Peer AS: 600 Age: 1:39:19 Task: BGP_600.10.0.29.1+2948 Announcement bits (3): 0-KRT 1-BGP.0.0.0.0+179 2-Resolve inet.0 AS path: 600 I Localpref: 100 Router ID: 192.168.28.1 Now we want to look at Denver's routing table. Here we see the Cluster list that was inserted by router Washington D.C. and the Originator ID . The Originator ID is the border router that learned the external route ”in this case, New York. lab@Denver> show route 172.16.6.0/24 detail inet.0: 18 destinations, 18 routes (17 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.16.6.0/24 (1 entry, 1 announced) *BGP Preference: 170/-101 Source: 192.168.2.1 Nexthop: 10.0.1.1 via fe-0/1/2.0, selected Protocol Nexthop: 10.0.29.1 Indirect nexthop: 8378550 46 State: <Active Int Ext> Local AS: 100 Peer AS: 100 Age: 27:59 Metric2: 30 Task: BGP_100.192.168.2.1+1263 Announcement bits (3): 0-KRT 1-BGP.0.0.0.0+179 4-Resolve inet.0 AS path: 600 I <Originator> Cluster list: 192.168.2.1 Originator ID: 192.168.24.1 Localpref: 100 Router ID: 192.168.2.1 Next, we see the routing table in route San Francisco. Notice that the Cluster list and Originator ID fields are no longer in the advertisement. This is because these attributes will not traverse outside the AS in which the route reflector resides. lab@SanFrancisco> show route 172.16.6.0/24 detail inet.0: 12 destinations, 12 routes (11 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.16.6.0/24 (1 entry, 1 announced) *BGP Preference: 170/-101 Source: 10.0.16.2 Nexthop: 10.0.16.2 via fe-0/1/1.0, selected State: <Active Ext> Local AS: 500 Peer AS: 100 Age: 31:29 Task: BGP_100.10.0.16.2+1383 Announcement bits (2): 0-KRT 1-BGP.0.0.0.0+179 AS path: 100 600 I Localpref: 100 Router ID: 192.168.0.1 In this case study, we have seen the configuration necessary to implement route reflectors. We understand through this discussion and our theory discussion in Section 9.5.1 how route reflectors can be used to scale BGP and further reduce the IBGP full-mesh problem that can exist in large networks. We have also seen how loop- avoidance mechanisms are in place in route-reflector scenarios, and how different announcements will affect which attributes will be passed to internal neighbors and external neighbors. In the next case study, we will see how confederations can be used to scale BGP. 10.4.2 ConfederationIn this case study, we will configure a simple confederation topology. Figure 10-11 shows the topology we will be using for this case study. We will look at the configuration for confederation BGP (CBGP) and how it can be used to scale your typical BGP implementation. We will use AS100 for our "real world" AS. This AS comprises all sub-ASs or confederations. AS100 will consist of three sub-ASs: 65501, 65504, and 65507. Remember in Section 9.1.2 our discussion of ASNs? We will be using ASNs from the private AS range. For the sake of ease, in this example we will not regionalize the IGP. However, we will use OSPF and multiple areas. We will place the sub-AS boundary routers Washington D.C., Atlanta, and Denver in OSPF area 0.0.0.0 and each sub-AS in its own area. Routers San Jose and Boston will be used as external peers to the AS100. Figure 10-11. Confederation Case Study Topology First, we will take a look at our configuration for the external neighbors to the confederation AS. We will begin by looking at the configuration of San Jose in AS900. San Jose has an EBGP peering session with router San Francisco, which is in sub-AS 65507. interfaces { fe-0/1/0 { unit 0 { family inet { address 10.0.21.2/24; } } } lo0 { unit 0 { family inet { address 127.0.0.1/32; address 192.168.20.1/32; } } } } routing-options { router-id 192.168.20.1; autonomous-system 900; } protocols { bgp { group EBGP { type external; neighbor 10.0.21.1 { peer-as 100; } } } } Next, we have our configuration for AS300. Boston's configuration is similar to that of San Jose. In addition, Boston will be injecting a route for the 172.16.0.0/16 network, which we will be tracking during this case study. Interfaces { fe-0/1/0 { unit 0 { family inet { address 10.0.29.1/24; } } } lo0 { unit 0 { family inet { address 127.0.0.1/32; address 192.168.28.1/32; } } } } routing-options { static { route 172.16.0.0/16 receive; router-id 192.168.28.1; autonomous-system 300; } protocols { bgp { group EBGP { type external; export static-routes; neighbor 10.0.29.2 { peer-as 100; } } } } policy-options { policy-statement static-routes { from protocol static; then accept; } } In the two previous configurations for San Jose and Boston, you will notice that the peer-as is AS100. This is because ultimately the AS with the confederations will appear to the outside world as a single AS. We will see that a bit more when we see the configurations for New York and San Francisco. We will now look at our configuration for AS100. AS100 is our confederation AS and is comprised of three confederations, or sub-ASs. The configuration for router New York is listed below. There exists a single EBGP connection between New York and Boston. In the configuration for Boston, you will notice that under the [routing-options] hierarchy, we set the ASN to 65501. In addition, there is a statement reading confederation 100 members [ 65501 65504 65507 ] . The confederation statement lets the BGP configuration process know that ASs 65501, 65504, and 65507 are all part of AS100. The global view of the AS will still be as AS100. Sub-AS 65501 consists of router Washington D.C. and New York. New York will also have an IBGP peering session with Washington D.C. We are running OSPF area 0.0.0.1 internal to sub-AS 65501. interfaces { fe-0/1/0 { unit 0 { family inet { address 10.0.29.2/24; } } } fe-0/1/1 { unit 0 { family inet { address 10.0.24.2/24; } } } lo0 { unit 0 { family inet { address 127.0.0.1/32; address 192.168.24.1/32; } } } } routing-options { router-id 192.168.24.1; autonomous-system 65501; confederation 100 members [ 65501 65504 65507 ]; } protocols { bgp { group IBGP { type internal; local-address 192.168.24.1; neighbor 192.168.2.1; } group EBGP { type external; neighbor 10.0.29.1 { peer-as 300; } } } ospf { area 0.0.0.1 { interface lo0.0; interface fe-0/1/1.0; interface fe-0/1/0.0 { passive; } } } } The next example shows Washington D.C.'s configuration. Washington D.C., in sub-AS 65501, is configured to peer with the other sub-ASs in the confederation AS100. Washington D.C. has a typical IBGP session with New York. Washington D.C. also has two EBGP sessions: Atlanta and Denver. An important note about these EBGP sessions is that they still have the TTL 1 restriction tied to them. Even though in CBGP the handling of several attributes have been relaxed, the handling of this one has not. In our case, we are peering between the physical interface IP addresses; therefore, the TTL limit of an EBGP session is not an issue. However, if we were going to be using a more resilient topology where redundant links would exist between several core members or potential customers, the use of the multihop statement and loopback address peering would be recommended. Peering with the use of the multihop statement is covered in the load-balancing case study in Section 10.3. As mentioned earlier, we are running OSPF for our IGP. Between all the boundary routers, we are running area 0.0.0.0 , and within sub-AS 65501 we use area 0.0.0.1 . Thus, we see our configuration for OSPF has interfaces fe-0/1/0 and fe-0/1/2 in area 0.0.0.0 and fe-0/1/1 in area 0.0.0.1 . interfaces { fe-0/1/0 { unit 0 { family inet { address 10.0.2.1/24; } } } fe-0/1/1 { unit 0 { family inet { address 10.0.24.1/24; } } } fe-0/1/2 { unit 0 { family inet { address 10.0.1.1/24; } } } lo0 { unit 0 { family inet { address 127.0.0.1/32; address 192.168.2.1/32; } } } } routing-options { router-id 192.168.2.1; autonomous-system 65501; confederation 100 members [ 65501 65504 65507 ]; } protocols { bgp { group IBGP { type internal; local-address 192.168.2.1; neighbor 192.168.24.1; } group CEBGP { type external; neighbor 10.0.1.2 { peer-as 65507; } neighbor 10.0.2.2 { peer-as 65504; } } } ospf { area 0.0.0.0 { interface lo0.0; interface fe-0/1/0.0; interface fe-0/1/2.0; } area 0.0.0.1 { interface fe-0/1/1.0; } } } The concepts for the remaining routers' configuration are the same as those we have just seen. We will now take a very quick look at the configuration for sub-AS 65507. In the next example, you can see that Denver peers via EBGP with Washington D.C. sub-AS 65501 and Atlanta sub-AS 65504. Interfaces fe-0/1/0 and fe-0/1/2 are in OSPF area 0.0.0.0 , while fe-0/1/1 is in area 0.0.0.7 . interfaces { fe-0/1/0 { unit 0 { family inet { address 10.0.0.1/24; } } } fe-0/1/1 { unit 0 { family inet { address 10.0.16.2/24; } } } fe-0/1/2 { unit 0 { family inet { address 10.0.1.2/24; } } } lo0 { unit 0 { family inet { address 127.0.0.1/32; address 192.168.0.1/32; } } } } routing-options { router-id 192.168.0.1; autonomous-system 65507; confederation 100 members [ 65501 65504 65507 ]; } protocols { bgp { group CEBGP { type external; neighbor 10.0.1.1 { peer-as 65501; } neighbor 10.0.0.2 { peer-as 65504; } } group IBGP { type internal; local-address 192.168.0.1; neighbor 192.168.16.1; } } ospf { area 0.0.0.0 { interface lo0.0; interface fe-0/1/0.0; interface fe-0/1/2.0; } area 0.0.0.7 { interface fe-0/1/1.0; } } } San Francisco, as you can see next, has an IBGP session with Denver and an EBGP session with San Jose in AS900: interfaces { fe-0/1/0 { unit 0 { family inet { address 10.0.21.1/24; } } } fe-0/1/1 { unit 0 { family inet { address 10.0.16.1/24; } } } lo0 { unit 0 { family inet { address 127.0.0.1/32; address 192.168.16.1/32; } } } } routing-options { router-id 192.168.16.1; autonomous-system 65507; confederation 100 members [ 65501 65504 65507 ]; } protocols { bgp { group IBGP { type internal; local-address 192.168.16.1; neighbor 192.168.0.1; } group EBGP { type external; neighbor 10.0.21.2 { peer-as 900; } } } ospf { area 0.0.0.7 { interface lo0.0; interface fe-0/1/1.0; interface fe-0/1/0.0 { passive; } } } } Next is sub-AS 65504. Atlanta is the sub-AS boundary router and has EBGP peering sessions with Washington D.C. and Denver. In addition, Atlanta takes part of an IBGP full-mesh within the sub-AS by peering with Dallas and Houston via IBGP. OSPF is running in area 0.0.0.0 on interfaces fe-0/1/0 and fe-0/1/2 . Area 0.0.0.4 is being used on interface fe-0/1/1 . interfaces { fe-0/1/0 { unit 0 { family inet { address 10.0.0.2/24; } } } fe-0/1/1 { unit 0 { family inet { address 10.0.8.1/24; } } } fe-0/1/2 { unit 0 { family inet { address 10.0.2.2/24; } } } lo0 { unit 0 { family inet { address 127.0.0.1/32; address 192.168.5.1/32; } } } } routing-options { router-id 192.168.5.1; autonomous-system 65504; confederation 100 members [ 65501 65504 65507 ]; } protocols { bgp { group CEBGP { type external; neighbor 10.0.2.1 { peer-as 65501; } neighbor 10.0.0.1 { peer-as 65507; } } group IBGP { type internal; local-address 192.168.5.1; neighbor 192.168.12.1; neighbor 192.168.8.1; } } ospf { area 0.0.0.0 { interface lo0.0; interface fe-0/1/0.0; interface fe-0/1/2.0; } area 0.0.0.4 { interface fe-0/1/1.0; } } } Dallas' configuration is shown next. Dallas is part of the IBGP full-mesh with Atlanta and Houston. OSPF area 0.0.0.4 is running on interfaces fe-0/1/0 and fe-0/1/1 . interfaces { fe-0/1/0 { unit 0 { family inet { address 10.0.13.2/24; } } } fe-0/1/1 { unit 0 { family inet { address 10.0.8.2/24; } } } lo0 { unit 0 { family inet { address 127.0.0.1/32; address 192.168.12.1/32; } } } } routing-options { router-id 192.168.12.1; autonomous-system 65504; confederation 100 members [ 65501 65504 65507 ]; } protocols { bgp { group IBGP { type internal; local-address 192.168.12.1; neighbor 192.168.5.1; neighbor 192.168.8.1; } } ospf { area 0.0.0.4 { interface fe-0/1/1.0; interface fe-0/1/0.0; interface lo0.0; } } } Houston is running in the IBGP full-mesh with Atlanta and Dallas, and OSPF area 0.0.0.4 on interface fe-0/1/0 . interfaces { fe-0/1/0 { unit 0 { family inet { address 10.0.13.1/24; } family iso; family mpls; } } lo0 { unit 0 { family inet { address 127.0.0.1/32; address 192.168.8.1/32; } } } } routing-options { router-id 192.168.8.1; autonomous-system 65504; confederation 100 members [ 65501 65504 65507 ]; } protocols { bgp { group IBGP { type internal; local-address 192.168.8.1; neighbor 192.168.5.1; neighbor 192.168.12.1; } } ospf { area 0.0.0.4 { interface lo0.0; interface fe-0/1/0.0; } } } Now that we have covered the configurations for our topology, let's take a look at what is happening. First, we have router Boston in AS300, advertising route 172.16.0.0/16 to the rest of the world. These networks are going to be used to gain a better understanding of how confederation route advertisement occurs. First, though, let's talk a little bit about our IGP implementation and how it fits into our topology. We are using OSPF for the IGP. Area 0.0.0.0 consists of the sub-AS boundary routers, Washington D.C., Atlanta, and Denver. Within each sub-AS, we run a different OSPF area. We could keep everything in area 0.0.0.0 , but that would not help teach you about scaling. We want to show you how you can set up an IGP to fit along with the topology. Now we will want to take a look at how our route from Boston is being propagated throughout our AS. In the example below, we see the show route 172.16.0.0/16 detail output from New York. This is a very typical looking route, learned via an EBGP session. The next-hop is New York in AS300; the AS_PATH list is 300 I , which is normal. However, look at the Local AS field; the value is 65501. Our peering session on Boston was set up to peer with AS100 though. Remember the confederation and autonomous-system statements under the [routing-options] hierarchy? They take care of all of the AS manipulation for us. Once it is defined in the configuration, we are done. lab@ny> show route 172.16.0.0/16 detail inet.0: 26 destinations, 26 routes (24 active, 0 holddown, 2 hidden) + = Active Route, - = Last Active, * = Both 172.16.0.0/16 (1 entry, 1 announced) *BGP Preference: 170/-101 Source: 10.0.29.1 Nexthop: 10.0.29.1 via fe-0/1/0.0, selected State: <Active Ext> Local AS: 65501 Peer AS: 300 Age: 1:51:32 Task: BGP_300.10.0.29.1+3110 Announcement bits (3): 0-KRT 1-BGP.0.0.0.0+179 2-Resolve inet.0 AS path: 300 I Localpref: 100 Router ID: 192.168.28.1 Our next example shows us the output from Washington D.C., using the show route 172.16.0.0/16 detail command. We see that the Local AS is 65501, and the Peer AS is 65501, as well. The AS_PATH list is still 300 I , which is exactly as it should be. lab@dc> show route 172.16.0.0/16 detail inet.0: 25 destinations, 25 routes (24 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.16.0.0/16 (1 entry, 1 announced) *BGP Preference: 170/-101 Source: 192.168.24.1 Nexthop: 10.0.24.2 via fe-0/1/1.0, selected Protocol Nexthop: 10.0.29.1 Indirect nexthop: 83784c8 37 State: <Active Int Ext> Local AS: 65501 Peer AS: 65501 Age: 1:56:29 Metric2: 20 Task: BGP_65501.192.168.24.1+1365 Announcement bits (3): 0-KRT 1-BGP.0.0.0.0+179 2-Resolve inet.0 AS path: 300 I Localpref: 100 Router ID: 192.168.24.1 Next, we take a look at Denver in sub-AS 65507. We see here that the AS path information looks a bit different. There is the inclusion of our confederation information in the path listing. Notice that our next-hop has not changed. Even though we have learned this route via an EBGP peering session, the next-hop rule is relaxed in the sense that it is maintained through the entire AS. It is very important when scaling through the use of confederations to take care in IGP implementation. If for some reason we were using different IGPs in sub-AS 65501 and 65507, and there was not a clean passing of route information between the two IGPs, there would be potential for sub-AS 65507 not to be able to resolve the next-hop, rendering the route useless. With the way we have our IGP (OSPF) configured in this case study, we allow for an unrestricted flow of routing information between the different OSPF areas. If we were using a mixture of OSPF and IS-IS, and redistribution policies were not configured properly, we might lose visibility of information that BGP needs to do a recursive lookup of the next-hop. lab@denver> show route 172.16.0.0/16 detail inet.0: 23 destinations, 23 routes (22 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.16.0.0/16 (1 entry, 1 announced) *BGP Preference: 170/-101 Source: 10.0.1.1 Nexthop: 10.0.1.1 via fe-0/1/2.0, selected Protocol Nexthop: 10.0.29.1 Indirect nexthop: 83784c8 56 State: <Active Int Ext> Local AS: 65507 Peer AS: 65501 Age: 2:11:32 Metric2: 3 Task: BGP_65501.10.0.1.1+179 Announcement bits (3): 0-KRT 1-BGP.0.0.0.0+179 2-Resolve inet.0 AS path: (65501) 300 I Localpref: 100 Router ID: 192.168.2.1 Our next example shows the routing table from Atlanta. Our concerns are the same as they were when looking at Denver. In addition, we see that Atlanta has two routes to the destination 172.16.0.0/16 . Because of the way confederations work with next-hop, the next-hop is retained. This is a perfect example of some different routing information you may see. Let's step through this. Atlanta receives a route for 172.16.0.0/16 from Washington D.C. and Denver. The path list from Washington D.C. is AS path: (65501) 300 I . The path list from Denver is AS path: (65507 65501) 300 I . You would naturally believe Denver was the longer path, but it's not in terms of how BGP sees it. Each path, in this case, consists of valid AS_PATH information with ASNs and Confed_Sequence . Going back to our path-selection discussion in Section 9.5.2, we know that Confed_Sequence is given a value of 0 when being evaluated. Thus, the resulting value of the AS_PATH attribute from Washington D.C. and Denver is 1. Ultimately, the prefix advertisement is chosen based upon the RID. Denver happens to have a lower RID than Washington D.C., so the prefix advertisement from Denver is our active route. What about the physical next-hop? It is 10.0.2.1 . Let's take a look at the details. When using confederations, the next-hop information is retained throughout the entire confederation AS. This means that the protocol next-hop ”the next-hop that BGP will do a recursive lookup on ”is 10.0.29.1 . When BGP on Atlanta looks at the 10.0.29.1 route in the IGP, it has a next-hop of 10.0.2.1 , which we already know is on Washington D.C. lab@Atlanta> show route 172.16.0.0/16 detail inet.0: 23 destinations, 23 routes (22 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.16.0.0/16 (2 entries, 1 announced) *BGP Preference: 170/-101 Source: 10.0.0.1 Nexthop: 10.0.2.1 via fe-0/1/2.0, selected Protocol Nexthop: 10.0.29.1 Indirect nexthop: 83784c8 23 State: <Active Int Ext> Local AS: 65504 Peer AS: 65507 Age: 2:21:27 Metric2: 30 Task: BGP_65507.10.0.0.1+179 Announcement bits (3): 0-KRT 1-BGP.0.0.0.0+179 4-Resolve inet.0 AS path: (65507 65501) 300 I Localpref: 100 Router ID: 192.168.0.1 BGP Preference: 170/-101 Source: 10.0.2.1 Nexthop: 10.0.2.1 via fe-0/1/2.0, selected Protocol Nexthop: 10.0.29.1 Indirect nexthop: 83784c8 23 State: <NotBest Int Ext> Inactive reason: Router ID Local AS: 65504 Peer AS: 65501 Age: 2:21:29 Metric2: 30 Task: BGP_65501.10.0.2.1+1309 AS path: (65501) 300 I Localpref: 100 Router ID: 192.168.2.1 The following output is the show route 10.0.29.1 command showing the next-hop as 10.0.2.1 . lab@Atlanta> show route 10.0.29.1 inet.0: 23 destinations, 23 routes (22 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 10.0.29.0/24 *[OSPF/10] 02:34:27, metric 30 > to 10.0.2.1 via fe-0/1/2.0 Last, we will look at the routing table for San Jose for our advertised prefix of 172.16.0.0/16 . The AS path list is right on target for our topology. Our next-hop is 10.0.21.1 , which is the EBGP peer from which we learned the route. lab@sj> show route 172.16.0.0/16 detail inet.0: 10 destinations, 10 routes (9 active, 0 holddown, 1 hidden) 172.16.0.0/16 (1 entry, 1 announced) *BGP Preference: 170/-101 Source: 10.0.21.1 Nexthop: 10.0.21.1 via fe-0/1/0.0, selected State: <Active Ext> Local AS: 900 Peer AS: 100 Age: 2:47:38 Task: BGP_100.10.0.21.1+179 Announcement bits (2): 0-KRT 1-BGP.0.0.0.0+179 AS path: 100 300 I Localpref: 100 Router ID: 192.168.16.1 This study has looked at the basic concept of confederations and how to implement them. It has also talked about how route information is propagated through a confederation and discussed some of the differences. The use of confederations is recommended when scaling BGP as it offers the greatest flexibility and truly scalable functionality. 10.4.3 AggregationIn this case study, we will show how to perform route aggregation in JUNOS. We will use the topology shown in Figure 10-12. The purpose of this case study is to show how aggregation occurs and to configure it in JUNOS. First, we will discuss the topology as this will provide insight into aggregation for those unfamiliar with it. Figure 10-12. Route-Aggregation Case Study Topology In this scenario, we have two routers that will be providing feeder routes: Boston and Dallas. Boston will announce networks 172.16.0.0/24 and 172.16.1.0/24 , and Dallas will announce 172.16.2.0/24 and 172.16.3.0/24 . The purpose of this is to provide routes for New York to aggregate. In this study, aggregation is configured such that New York announces the aggregate of 172.16.0.0/22 only if there is a contributing route in its own routing table. The first two examples below show the configurations for Boston and Dallas, respectively. These are pretty basic and are only used to get the routes into BGP. All of the routers in AS200 are in the IBGP mesh and use OSPF for the IGP. routing-options { static { route 172.16.0.0/24 receive; route 172.16.1.0/24 receive; } autonomous-system 200; } protocols { bgp { group ibgp { type internal; local-address 3.3.3.3; export static-routes; neighbor 2.2.2.2; neighbor 5.5.5.5; } } } policy-options { policy-statement static-routes { from protocol static; then accept; } } routing-options { static { route 172.16.2.0/24 receive; route 172.16.3.0/24 receive; } autonomous-system 200; } protocols { bgp { group ibgp { type internal; local-address 5.5.5.5; export static-routes; neighbor 2.2.2.2; neighbor 3.3.3.3; } } } policy-options { policy-statement static-routes { from protocol static; then accept; } } Next is the configuration for New York. This is where the aggregation will occur. New York receives the routes from Boston and Dallas. The aggregate route is configured under the [routing-options] hierarchy. The active parameter tells JUNOS to keep the route active only if there is a contributing route. We can force the route to stay in the table, but for now that is not necessary. Policy plays a major role here though. In the policy-statement announce , the term pass-agg tells JUNOS to filter on the aggregate with which we are concerned . It is possible to have multiple aggregates for different address spaces defined, especially on AS boundary routers; therefore, specifying the exact match criteria proves to be beneficial in exporting the correct route. The second portion of the policy, the term filter-more-specific , tells JUNOS to filter the more specific routes and reject them. This accomplishes our goal for getting the aggregate route advertised. There are times when you may wish to leak the more specific routes, perhaps to influence traffic flow to a particular network. Leaking more specific route information can be a useful way to attract more inbound traffic from a given upstream provider, as well. Either way, the more specific the information advertised, the higher the risk of route flaps during unstable conditions. The tradeoff can only be measured on a case-by-case basis. routing-options { aggregate { route 172.16.0.0/22 active; } autonomous-system 200; } protocols { bgp { group ibgp { type internal; local-address 2.2.2.2; neighbor 3.3.3.3; neighbor 5.5.5.5; } group ebgp { type external; export announce; neighbor 10.0.24.1 { peer-as 100; } } } } policy-options { policy-statement announce { term pass-agg { from { protocol aggregate; route-filter 172.16.0.0/22 exact; } then accept; } term filter-more-specific { from { route-filter 172.16.0.0/22 longer; } then reject; } } } Next, we want to take a look at the routing table for Washington D.C. This is more to prove the theory of operation than anything else. This next example shows the routing table prior to the aggregate-route policy being invoked. lab@DC> show route protocol bgp inet.0: 14 destinations, 14 routes (13 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.16.0.0/24 *[BGP/170] 00:18:06, localpref 100 AS path: 200 I > to 10.0.24.2 via fe-0/1/1.0 172.16.1.0/24 *[BGP/170] 00:18:06, localpref 100 AS path: 200 I > to 10.0.24.2 via fe-0/1/1.0 172.16.2.0/24 *[BGP/170] 00:18:06, localpref 100 AS path: 200 I > to 10.0.24.2 via fe-0/1/1.0 172.16.3.0/24 *[BGP/170] 00:18:06, localpref 100 AS path: 200 I > to 10.0.24.2 via fe-0/1/1.0 Once we implement our announce policy on New York, we see that the /24 addresses are replaced with the less specific aggregate of 172.16.0.0/22 . lab@DC> show route protocol bgp inet.0: 11 destinations, 11 routes (10 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.16.0.0/22 *[BGP/170] 00:06:51, localpref 100 AS path: 200 I > to 10.0.24.2 via fe-0/1/1.0 Our next example shows what happens when we remove our four contributing routes from Boston and Dallas. When we do this, we no longer see the aggregate in the routing table of Washington D.C. lab@DC> show route protocol bgp inet.0: 10 destinations, 10 routes (9 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both You have now seen the basic process of creating and advertising aggregate routes. Earlier in this case study, we filtered all contributing routes and advertised the aggregate only. This is acceptable, but some domains may wish to leak more specific route information for a given network or block of networks to influence inbound traffic. Since there are times when aggregation suppresses detailed information about a prefix, you may choose to let a more specific route, with your detailed path attributes, leak through. This next example will now show you how to let this route slip through, along with the aggregate, looking at New York and the table in Washington D.C. Notice the new addition to the policy-statement announce . The route-filter 172.16.3.0/24 exact accept statement will allow the one single route to pass, while the next statement will reject all of the other contributing routes. policy-statement announce { term pass-agg { from { protocol aggregate; route-filter 172.16.0.0/22 exact; } then accept; } term specific-pass-filter { from { route-filter 172.16.3.0/24 exact accept; route-filter 172.16.0.0/22 orlonger; } then reject; } } Next you can see Washington D.C.'s routing table, which proves our concept. lab@DC> show route protocol bgp inet.0: 12 destinations, 12 routes (11 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.16.0.0/22 *[BGP/170] 00:18:24, localpref 100 AS path: 200 I > to 10.0.24.2 via fe-0/1/1.0 172.16.3.0/24 *[BGP/170] 00:02:26, localpref 100 AS path: 200 I > to 10.0.24.2 via fe-0/1/1.0 In addition to using contributing routes, we can configure JUNOS to send an aggregate route, even when no contributing routes exist. We accomplish this by using the passive statement when configuring our aggregate route under the [routing-options] hierarchy. The following example shows the configuration necessary to accomplish this: routing-options { aggregate { route 172.16.0.0/22 passive; } autonomous-system 200; } protocols { bgp { group ebgp { type external; export announce; neighbor 10.0.24.1 { peer-as 100; } } } } policy-options { policy-statement announce { term pass-agg { from { protocol aggregate; route-filter 172.16.0.0/22 exact; } then accept; } term filter-more-specific { from { route-filter 172.16.0.0/22 longer; } then reject; } } } This concludes our case study on aggregate routes. You should now understand the basic concept of aggregation and how to configure it in JUNOS. Remember, when configuring aggregates, take into account the effect you will be having on any subset of routes that fall under the aggregate. Aggregation, while a useful tool, can cause undesired results if not implemented properly. |
EAN: 2147483647
Pages: 176