Example: Using Routing Policy in an ISP Network
This section provides an example of how policies might be used in a typical Internet service provider (ISP) network. In this network example (see Figure 1), the ISP’s AS number is 1000. The ISP has two transit peers (AS 11111 and AS 22222) to which it connects at an exchange point. The ISP is also connected to two private peers (AS 7000 and AS 8000) with which it exchanges specific customer routes. The ISP has two customers (AS 1234 and AS 2468) to which it connects using BGP.
Figure 1: ISP Network Example
In this example, the ISP policies are configured in an outbound direction; that is, the example focuses on the routes that the ISP announces to its peers and customers, and includes the following:
- The ISP has been assigned AS 1000 and the routing space of 192.168.0/17. With the exception of the two customer networks shown in Figure 1, all other customer routes are simulated with static routes.
- The ISP has connectivity to two different exchange peers: AS 11111 and AS 22222. These peers are used for transit service to other portions of the Internet. This means that the ISP is accepting all routes (the full Internet routing table) from those BGP peers. To help maintain an optimized Internet routing table, the ISP is configured to advertise only two aggregate routes to the transit peers.
- The ISP also has direct connectivity to two private peers: AS 7000 and AS 8000. The ISP administrators want all data to the private peers to use this direct link. As a result, all the customer routes from the ISP are advertised to those private peers. These peers then advertise all their customer routes to the ISP.
- Finally, the ISP has two customers with which it communicates using BGP: AS 1234 and AS 2468. Each customer has a different set of requirements.
The following sections discuss the following topics:
- Requesting a Single Default Route on the Customer 1 Router
- Requesting Specific Routes on the Customer 2 Router
- Configuring a Peer Policy on ISP Router 3
- Configuring Private and Exchange Peers on ISP Router 1 and 2
- Configuring Locally Defined Static Routes on the Exchange Peer 2 Router
- Configuring Outbound and Generated Routes on the Private Peer 2 Router
Requesting a Single Default Route on the Customer 1 Router
Customer 1 has only a single route to the ISP and is using the ISP for transit service. This customer has requested a single default route (0.0.0.0/0) from the ISP.
Requesting Specific Routes on the Customer 2 Router
Customer 2 has a link to the ISP, as well as a link to
AS 8000. This customer has requested specific customer routes
from the ISP, as well as from AS 8000.
Customer 2
wants to use the ISP for transit service to the Internet, and has
requested a default route from the ISP.
Configuring a Peer Policy on ISP Router 3
On ISP Router 3, a separate policy is in place for each customer. The default route for Customer 1 is being sent by the customer-1-peer policy. This policy finds the 0.0.0.0/0 default route in inet.0 and accepts it. The policy also rejects all other routes, thereby not sending all BGP routes on the ISP router. The customer-2-peer policy is for Customer 2 and contains the same policy terms, which also send the default route and no other transit BGP routes. The additional terms in the customer-2-peer policy send the ISP customer routes to Customer 2. Because there are local static routes on ISP router 3 that represent local customers, these routes are sent as well as all other internal (192.168.0/17) routes announced to the local router by the other ISP routers.
Configuring Private and Exchange Peers on ISP Router 1 and 2
ISP Router 1 and ISP Router 2 each have two policies configured: the private-peers policy and the exchange-peers policy. Because of their similar configurations, this example describes the configuration only for ISP Router 2.
On ISP Router 2, the private-peers policy sends the ISP customer routes to the Private Peer 2 router. The policy accepts all local static routes (local ISP Router 2 customers) and all BGP routes in the 192.168.0/17 range (advertised by other ISP routers). These two terms represent the ISP customer routes. The final term rejects all other routes, which includes the entire Internet routing table sent by the exchange peers. These routes do not need to be sent to Private Peer 2 for two reasons:
- The peer already maintains a connection to Exchange Peer 2 in our example, so the routes are redundant.
- The Private Peer wants customer routes only. The private-peers policy accomplishes this goal. The exchange-peers policy sends routes to the Exchange Peer 2 router.
In the example, only two routes need to be sent to Exchange Peer 2:
- The aggregate route that represents the AS 1000 routing space of 192.168.0/17. This route is configured as an aggregate route locally and is advertised by the exchange-peers policy.
- The address space assigned to Customer 2, 192.168.64/22. This smaller aggregate route needs to be sent to Exchange Peer 2 because the customer is also attached to the AS 8000 peer (Private Peer 2).
Sending these two routes to Exchange Peer 2 allows other networks in the Internet to reach the customer through either the ISP or the Private Peer. If just the Private Peer were to advertise the /22 network while the ISP maintained only its /17 aggregate, then all traffic destined for the customer would transit AS 8000 only. Because the customer also wants routes from the ISP, the 192.168.64/22 route is announced by ISP Router 2. Like the larger aggregate route, the 192.168.64/22 route is configured locally and is advertised by the exchange-peers policy. The final term in that policy rejects all routes, including the specific customer networks of the ISP, the customer routes from Private Peer 1, the customer routes from Private Peer 2, and the routing table from Exchange Peer 1. In essence, this final term prevents the ISP from performing transit services for the Internet at large.
Configuring Locally Defined Static Routes on the Exchange Peer 2 Router
The Exchange Peer 2 router exchanges all routes with all BGP peers. The outbound-routes policy for Exchange Peer 2 advertises locally defined static routes using BGP.
Configuring Outbound and Generated Routes on the Private Peer 2 Router
The Private Peer 2 router performs two main functions:
- Advertises routes local to AS 8000 to both the Exchange Peers and the ISP routers. The outbound-routes policy advertises the local static routes (that is, customers) on the router, and also advertises all routes learned by BGP that originated in either AS 8000 or AS 2468. These routes include other AS 8000 customer routes in addition to the AS 2468 customer. The AS routes are identified by an AS path regular expression match criteria in the policy.
- Advertises the 0.0.0.0/0 default route to the
AS 2468 customer router. To accomplish this, the Private Peer
creates a generated route for 0.0.0.0/0 locally on the router.
This generated route is further assigned a policy called if-upstream-routes-exist, which allows only certain routes to contribute to the generated
route, making it an active route in the routing table. Once the route
is active, it can be sent to the AS 2468 router using BGP and
the configured policies. The if-upstream-routes-exist policy
accepts only the 20.100.0.0/17 route from Exchange Peer 2,
and rejects all other routes. If the 20.100.0.0/17 route
is withdrawn by the Exchange Peer, the Private Peer loses the 0.0.0.0/0 default route and withdraws the default route from
the AS 2468 customer router.[edit]routing-options { # simulate local customer routesstatic {route 172.16.64.0/20 reject;route 172.16.80.0/20 reject;route 172.16.96.0/20 reject;route 172.16.112.0/20 reject;route 172.16.72.0/21 reject;route 172.16.88.0/21 reject;route 172.16.104.0/21 reject;route 172.16.120.0/21 reject;}generate {route 0.0.0.0/0 policy if-upstream-routes-exist;}autonomous-system 8000;protocols {bgp {group External-Peers {type external;export outbound-routes;neighbor 10.222.44.1 {peer-as 22222;}neighbor 10.222.45.1 {peer-as 1000;}}group Customers {type external;export internal-routes;neighbor 10.222.6.1 {peer-as 2468;}}}}policy-options {policy-statement outbound-routes { # advertise local customer routesterm statics {from protocol static;then accept;}term allowed-bgp-routes {from { # advertise routesas-path [ my-own-routes AS2468-routes ];}then accept;}term no-transit {then reject; # do not advertise any other routes}}policy-statement internal-routes { # advertise local customer routesterm statics {from protocol static;then accept;}term default-route { # advertise just the default routefrom {route-filter 0.0.0.0/0 exact;}then accept;}term reject-all-other-routes { # do not advertise any other routesthen reject;}}policy-statement if-upstream-routes-exist {term as-22222-routes {from { # allow the 10.100.0.0/17 route to activateroute-filter 10.100.0.0/17 exact; # the generated route in the routing # table}then accept;}term reject-all-other-routes {then reject; # do not allow any other route to activate} # the generated route in the routing table}as-path my-own-routes "()";as-path AS2468-routes "2468";}
