84	ROUTING POLICY

Applying different configurations to different classes of customers is also potentially problematic. Keeping configurations as generic as possible reduces the problems associated with the application of the ‘wrong’ configuration to a particular customer.

In order to overcome some of the constraints of strict unicast RPF while relinquishing some of the absolute benefits, loose unicast RPF was proposed. Instead of checking whether the route back to the source is via the interface over which the packet was received, loose unicast RPF simply checks that a route back to the source exists in the forwarding table, irrespective of the interface via which the source is reached. The main benefit of this has already been described above. However, the main disadvantage, relative to strict unicast RPF, is that if packets are sent with their source address spoofed to a genuine address present on the Internet, then loose unicast RPF will not detect them. Also, in any environment in which there is a default route, loose unicast RPF will always accept a packet because it will always have a path, via the default route, to the source. Some people consider that these problems significantly reduce the benefit of loose unicast RPF almost to the point of being useless.

6.15 POLICY ROUTING/FILTER-BASED FORWARDING

Policy routing or filter-based forwarding is the forwarding of traffic based on policies or filters, rather than using the default routing table to decide the forwarding path.

Policy routing can be used to overcome many issues and provide functionality otherwise not possible with the standard routing protocols and processes. An example of this is the provisioning of self-selection transit exchange services. Consider a ‘transit exchange’ with connections to several large ISPs (the upstream providers), each of whom offers full transit. In addition, many customers connect to the exchange and through some unspecified mechanism, select their preferred upstream provider based on some arbitrary criteria (e.g. cost per Megabyte, latency across the upstream provider’s network, packet loss across the upstream provider’s network). Assuming that each upstream provider uses BGP to announce routes to the exchange, default routing processes would select one best path from among all the alternatives provided by each upstream provider and would announce only that route. Using policy routing, the exchange could force traffic to be sent to the selected upstream provider based on the customer from which the traffic was sent, regardless of whether that provider has the best path to the destination. Reverse traffic could be forced back through the correct upstream provider by applying filters to the outbound BGP announcements so that routes from only those customers using the upstream provider for outbound traffic are sent to each upstream provider.

6.16 POLICY RECOMMENDATIONS

6.16.1POLICY RECOMMENDATIONS FOR CUSTOMER CONNECTIONS

If you wish to earn more from your customers, you should ensure that they receive as much traffic from you as you can validly send to them and that you make it as attractive

6.16 POLICY RECOMMENDATIONS

85

as possible to them to send traffic your way. This is particularly true for those customers who pay for their service based on traffic volume. Therefore, a prefix announced by a customer should be preferred over the same prefix from any other source (see Table 6.9). That can easily be achieved by setting a high LOCAL PREF on all routes learned from the

customer. Since the default value of LOCAL PREF is 100 and the maximum value is 232- 1, there is plenty of scope for applying different values to different customers. Generally, you announce all routes in your routing table to your customers so it is unnecessary to apply any policy to select those routes.

6.16.2POLICY RECOMMENDATIONS FOR PEERING CONNECTIONS

Peerings are generally a zero cost exchange of routing information between two networks over which the neighbours announce their own networks and those of their customers (but not those of other peers and transit providers). Because traffic to or from these neighbours neither earns nor costs money, prefixes learned from these neighbours should be preferred over those learned from transit providers but should be less favoured than otherwise identical prefixes learned from customers.

Normally, peers only receive prefixes originated locally or learned from your customers. In order to implement this policy, it is necessary to be able identify routes originated locally or learned from customers, peers and transit providers (see below). This can be achieved with communities. By marking each prefix on ingress (or at the point of origin) with a community representing the source of the prefix, it is possible to use that community at the point of egress to select the routes to be announced based on the source of the prefix (see Table 6.10).

6.16.3POLICY RECOMMENDATIONS FOR TRANSIT CONNECTIONS

The relationship with a transit provider is invariably one for which you will pay, often a large amount of money and often on the basis of the volume of traffic they transport on your behalf. Therefore, it is important to minimize the volume of traffic sent to your transit providers (without reducing the overall connectivity of your network). This means that prefixes learned from transit providers should be the least preferred of a set of otherwise identical prefixes learned from a customer, a peer, and a transit provider.

As with peers, transit providers normally only accept prefixes originated locally and from your customers (see Table 6.11). In order to minimize the use of routes learned from transit providers, it is simply necessary to set the LOCAL PREF on routes learned from that neighbour to a low value. Since the default LOCAL PREF is 100, it is simply necessary to set LOCAL PREF to a value of less than 100.

86	ROUTING POLICY
Table 6.9 Limited sample BGP configuration to customers using JUNOS and IOS
Juniper Configuration	Cisco Configuration
interfaces {	ip cef distributed
e1-0/0/0 {	!
unit 0 {	interface serial 0/0/0
family inet {	ip address 10.255.101.1
address 10.255.101.1/30;	255.255.255.252
rpf-check fail-filter	ip verify unicast reverse-path
cust-rpf;	!
}	ip prefix-list customerA permit
}	192.168.0.0/24
}	ip prefix-list customerA permit
}	192.168.2.0/23
routing-options {	ip prefix-list customerA2 permit
aggregate route 158.43.0.0/16;	172.16.0.0/16
aggregate route 146.188.0.0/16;	ip prefix-list local-aggregates
}	permit 172.20.0.0/15
firewall {	!
filter cust-rpf {	ip community-list 1 permit 1:1
term customer-networks {	ip community-list 2 permit 1:2
from {	ip community-list 3 permit 1:3
source-address {	ip community-list 199 permit 1:1000
192.168.103.0/24;	!
}	! accept known prefixes and
}	aggregate
then accept;	route-map from-customers-template
}	permit 10
term block-the-rest {	match ip prefix customerA
then {	set community 1:2
count rpf-rejects;	set local-preference 120
reject;	!
}	! accept known prefixes and leak
}	route-map from-customers-template
}	permit 15
}	match ip prefix customerA2
policy-options {	match community-list 199
prefix-list local-aggregates {	set community 1:2 additive
158.43.0.0/16;	set local-preference 120
146.188.0.0/16;	!
}	! default reject
policy-statement	route-map from-customers-template
from-customers-template {	deny 100
term accept-known-prefixes-and-	!
aggregate {	! accept peer routes
from {	route-map to-customers permit 10
protocol bgp;	match community-list 1
route-filter 192.168.0.0/24	!
exact;	! accept customer routes

(continued overleaf )

6.16 POLICY RECOMMENDATIONS	87
Table 6.9	(continued)
Juniper Configuration	Cisco Configuration
route-filter 192.168.2.0/23	route-map to-customers permit 15
exact;	match community-list 2
}	!
then {	! accept transit routes
community set customers;	route-map to-customers permit 20
local-preference 120;	match community-list 3
accept;	!
}	! accept local aggregate prefixes
}	route-map to-customers permit 25
term accept-known-prefixes-and-	match ip prefix local-aggregates
leak {	!
from {	! default reject
protocol bgp;	route-map to-customers deny 100
route-filter 172.16.0.0/16
exact;
community please-leak-this;
}
then {
community add customers;
local-preference 120;
accept;
}
}
term default-reject {
then reject;
}
}
policy-statement to-customers {
term accept-peer-routes {
from {
protocol bgp;
community peers;
}
then accept;
}
term accept-customer-routes {
from {
protocol bgp;
community customers;
}
then accept;
}
term accept-transit-routes {
from {
protocol bgp;
community transit;
}

(continued overleaf )

88	ROUTING POLICY
Table 6.9	(continued)
Juniper Configuration	Cisco Configuration

then accept;

}

term accept-local-aggregate- prefixes {

from {

protocol aggregate; prefix-list

local-aggregates;

}

then accept;

}

term default-reject { then reject;

}

}

community peers members 1:1; community customers members 1:2; community transit members 1:3; community please-leak-this

members 1:1000;

}

Table 6.10 Limited sample BGP configurations to peers using JUNOS and IOS

Juniper Configuration	Cisco Configuration
Routing-options {	ip prefix-list peerA permit
aggregate route 158.43.0.0/16;	192.168.100.0/24
aggregate route 146.188.0.0/16;	ip prefix-list peerA permit
}	192.168.200.0/23
policy-options {	!
prefix-list local-aggregates {	ip as-path access-list 1 permit
158.43.0.0/16;	^1000_
146.188.0.0/16;	!
}	ip community-list 1 permit 1:1
policy-statement	ip community-list 2 permit 1:2
from-peers-template {	ip community-list 3 permit 1:3
term accept-known-prefixes-and-	!
as-paths {	! accept known prefixes and AS
from {	paths
protocol bgp;	route-map from-peers-template
route-filter	permit 10
192.168.100.0/24 exact;	match ip prefix peerA
route-filter	match as-path 1
192.168.200.0/23 exact;	set community 1:1
as-path this-peer;	set local-preference 105
}	!

(continued overleaf )

6.16 POLICY RECOMMENDATIONS	89
Table 6.10	(continued)
Juniper Configuration	Cisco Configuration
then {	! default reject
community set peers;	route-map from-peers-template deny
accept;	100
}	!
}	! accept customer routes
term default-reject {	route-map to-peers permit 10
then reject;	match community-list 2
}	!
}	! need mechanism to match
policy-statement to-peers {	prefix-list
term reject-peer-routes {	route-map to-peers permit 15
from {	match ip prefix local-aggregates
protocol bgp;	!
community peers;	! default reject
}	route-map to-peers deny 100
then reject;
}
term reject-transit-routes {
from {
protocol bgp;
community transit;
}
then reject;
}
term accept-customer-routes {
from {
protocol bgp;
community customers;
}
then accept;
}
term accept-local-aggregate-
prefixes {
from {
protocol aggregate;
prefix-list
local-aggregates;
}
then accept;
}
term default-reject {
then reject;
}
}
as-path this-peer “1000 .*”;
community peers members 1:1;
community customers members 1:2;
community transit members 1:3;
}

90 ROUTING POLICY

Table 6.11 Limited sample BGP configurations to transit providers using JUNOS and IOS

Juniper Configuration Cisco Configuration

routing-options {

aggregate route 158.43.0.0/16; aggregate route 146.188.0.0/16;

}

policy-options {

prefix-list local-aggregates { 158.43.0.0/16; 146.188.0.0/16;

}

policy-statement from-transit-template {

term accept-everything-from- transit {

from protocol bgp; then {

community set transit; accept;

}

}

term default-reject { then reject;

}

}

policy-statement to-peers { term reject-peer-routes {

from { protocol bgp;

community peers;

}

then reject;

}

term reject-transit-routes { from {

protocol bgp; community transit;

}

then reject;

}

term accept-customer-routes { from {

protocol bgp; community customers;

}

then accept;

}

term accept-local-aggregate- prefixes {

ip prefix-list local-agg permit 158.43.0.0/16

ip prefix-list local-agg permit 146.188.0.0/16

!

ip community-list 1 permit 1:1 ip community-list 2 permit 1:2 ip community-list 3 permit 1:3

!

!accept everything from transit route-map from-peers-template

permit 10

set community 1:3 !local-preference defaults to 100

!default reject

route-map from-peers-template deny 100

!

!accept customer routes route-map to-peers permit 10

match community-list 2

!need mechanism to match prefix-list

route-map to-peers permit 15 match ip prefix local-aggregates

!

! default reject

route-map to-peers deny 100

(continued overleaf )