Figure 128 Typical ISP Setup with Static and BGP Customers

Figure 12-8 shows that the static customers are connected to the distribution routers or access routers. The distribution routers will always run BGP and, most of the time, will have BGP customers connected to them. In some cases, ISPs do not run BGP on the access routers if they have only static customers connected to them.

Figure 12-8 shows that the static customers are connected to the distribution routers or access routers. The distribution routers will always run BGP and, most of the time, will have BGP customers connected to them. In some cases, ISPs do not run BGP on the access routers if they have only static customers connected to them.

We recommend that static customers be c onnected first. Then, introduce BGP in order to carry customer routes through BGP instead of IGP. Three situations will arise once this has been accomplished:

• All IBGP routers must be fully meshed. In case the ISP introduces BGP at all the access routers, the IBGP mesh will be very large and can cause scaling difficulties with the BGP mesh.

• It may appear as if the full BGP routes must be sent to all access routers that were not previously receiving all BGP routes. Even if those access routers do not have external BGP neighbors, they are now receiving full BGP routes because they are part of the BGP mesh.

• If policies have been defined only at the external BGP peering routers, you must define policies on all BGP peering routers, now that BGP has been configured in the network. It may appear as if the policies must be implemented throughout the network because you have introduced BGP at the edges.

Now, we will address these issues one by one. The first issue is the IBGP mesh problem. With the introduction of the router reflector (for details on router reflectors, see Chapter 11, "Border Gateway Protocol" ), access routers only need to peer with their local distribution BGP routers. Distribution routers will become route reflectors for all the access routers. Next, these distribution routers become route reflector clients to the core routers. This introduces two-layer route reflection hierarchy and minimizes the BGP mesh.

The second issue involves the question of sending full BGP routes to the access routers that previously were receiving these routes. First of all, this suggestion does not require a full BGP table. Communities should be used to send only previously received routes. It is unnecessary to change the routing table. Only the protocol that is carrying the routes has changed.

The third issue is defining the policies. If you were only forming the BGP policies at the peering routers, how do you ensure that the BGP policies are not affected? This is accomplished by verifying that the routes that you imported into BGP from the IGP via the access list are correct. Now, you would form BGP policies at the access router that redistributes the static route.

You are then ready to begin migrating the network in Figure 12-8 from an OSPF carrying all customer route networks to an IBGP carrying customer route networks. The first step is to create IBGP peering with the local distribution routers. In Figure 12-8, you would assign D2 and D1 as the route reflectors for A1, A2, A3, and A5.

When configuring BGP peering, remember to define a distribute list or community list at the distribution routers. This will prevent the distribution routers from sending the complete BGP information to the access routers. This way, the distribution router will send only the routes that should be sent to the access routers.

If you do not choose to send any BGP routes to the access routers, simply send the OSPF default route to the access routers. You would use IBGP to receive customer routes. In this setup, the access router is not receiving any BGP routes from the distribution router—it is only sending customer routes via BGP.

After you have configured all the access routers that have static customers as clients and have ensured that the peering is up, you can focus on the distribution routers, if they are not already route reflector clients of core routers.

You would then repeat the same process throughout the network. When all the routers are ready to send and receive BGP routes, you would then enter the redistribution statement in the BGP process without removing the redistribution command from OSPF. This allows you to view all the customer routes into BGP. However, all the routes from OSPF continue to be visible because OSPF has a lower administrative distance than IBGP. Because there are no synchronization issues, IBGP will send routes to the neighbor. OSPF already carries all the customer routes.

After the redistribution is removed from under OSPF and when IBGP is the only protocol carrying customer routes, you should configure no sync.

For policy purposes, routes that are not sent to external BGP neighbors are not allowed to leak. Leaks are prevented by defining the access lists when BGP is configured at the access router. All customer routes that will be sent to the external peering BGP will be redistributed from the static route, as is the case with a community number. Routes that were not outside the autonomous system, but need to be sent to the IBGP neighbors, will be redistributed with a community number of local-as. You also can employ the no-export command. This way, routes with a community number of local-as will remain within the AS, and routes that only have a simple community number will be exported to the ISP's external neighbors.

Was this article helpful?

0 0

Post a comment