80	ROUTING POLICY
Table 6.7	(continued)
Juniper Configuration	Cisco Configuration
from {
protocol bgp;
community [ customers peers transit ];
}
then accept;
}
}
policy-statement from-transit {
term t1 {
from protocol bgp;
then {
community set transit;
accept;
}
}
}
community peers members 1:1;
community customers members 1:2;
community transit members 1:3;
}

•no-advertise. Informs the neighbour that this prefix should not be announced to any other neighbour, either internal or external.

•no-export-subconfed. This is relevant only within BGP confederations. It is used to indicate that this prefix should not be announced beyond the border of any individual member (sub-AS) of the confederation AS.

6.11 MULTI-EXIT DISCRIMINATOR (MED)

The Multi-Exit Discriminator is a metric carried in BGP NLRI and announced to external neighbours. MEDs are only used by routers in a single AS to distinguish between prefixes announced by one other AS.

MED is a metric, which has a NULL default value. This is the source of one problem. Some vendors consider NULL MEDs to be least preferred while others consider NULL MEDs to be most preferred. This contradictory behaviour is problematic when two neighbours use routers from two vendors with differing default behaviour. It is even more problematic if a single AS uses routers from two vendors with differing default behaviour.

MEDs can have a value between 0 and 232-1.

6.12 LOCAL PREFERENCE

Local Preference (LOCAL PREF) is a locally defined value that represents the preference of a prefix within a single AS. LOCAL PREF allows the administrator of a network to prefer one source of NLRI over another on a per prefix basis (although the configuration of LOCAL PREF values on a per prefix basis would be extremely complex and tedious).

6.13 DAMPING

81

Unlike most other metric like values, a high LOCAL PREF is more preferred than a low one. The value of LOCAL PREF can be anywhere between 0 and 232-1. The default value is 100.

6.13 DAMPING

Damping is the mechanism whereby prefixes that have been repeatedly announced and withdrawn over a limited period are marked unusable until the prefix has been present continuously for a period of time.

The mechanism is based on a figure of merit associated with each prefix. Each flap (announcement and withdrawal) of the prefix causes the figure of merit to be increased by a penalty. If the figure of merit rises above a threshold, the prefix is declared ineligible for use. The figure of merit is decayed exponentially, based on a half life, while the prefix remains stable. The prefix is marked eligible for use again only when the figure of merit has fallen below another threshold.

The aim of damping is to contain the flapping prefixes, which consume resources in Internet routers and, particularly with older designs, significantly impair forwarding performance.

Experience has shown that generally longer prefixes (less aggregated prefixes) are less stable than shorter prefixes (highly aggregated prefixes). Therefore, in order to gain the greatest impact, service providers often damp longer prefixes much more aggressively than shorter prefixes. Thus, in order to avoid having your prefixes damped, it is advisable to aggregate your prefixes as much as possible. This not only makes it less likely that your prefixes will be damped, but also reduces the total number of prefixes in the global routing table. However, it is not realistic to expect to maintain absolute aggregation. For example, any customer with addresses from your provider aggregatable address space that subsequently dual-homes to a second ISP will have to have their prefix deaggregated.

It is common practice to generate static aggregate routes that are redistributed into BGP. It is these aggregates that are announced to your neighbours. These routes are extremely stable, normally only disappearing if the router on which they are configured actually crashes. By generating the aggregate on multiple boxes in your network, you overcome this problem.

It has been noted that the use of inconsistent default parameters for damping by the two main vendors of Internet core routers has led in some cases to counter-productive results (see Table 6.8). Indeed, it has been observed that oscillations can propagate longer than they might otherwise have done in an undamped environment.

This issue was raised by Christian Panigl at two consecutive RIPE meetings and was the stimulus for the routing working group of RIPE to produce a document (RIPE-2291) making recommendations for the parameters that should be applied to route flap damping. The recommended values differ quite significantly from the default values on the various vendors’ routers, which also differ significantly from each other. Before implementing route flap damping, it is well worth reading RIPE-229, then read it again.

1 RIPE-229: RIPE Routing-WG Recommendations for Coordinated Route-Flap Damping Parameters

Christian Panigl, Joachim Schmitz, Philip Smith, Cristina Vistoli

82	ROUTING POLICY
Table 6.8 Configuring BGP route flap damping with JUNOS and IOS
Juniper configuration	Cisco configuration

protocols { bgp {

import [ damp-lite damp-norm damp-hard ];

damping;

}

}

policy-options { damping lite { half-life 5;

max-suppress 30; reuse 1000; suppress 4000;

}

damping norm { half-life 15; max-suppress 60; reuse 750; suppress 3000;

}

damping hard { half-life 30; max-suppress 120; reuse 500; suppress 2000;

}

policy-statement damp-lite { term t1 {

from { protocol bgp;

route-filter 1.0.0.0/8 orlonger;

}

then {

damping lite; accept;

}

}

}

policy-statement damp-norm { term t1 {

from { protocol bgp;

route-filter 2.0.0.0/8 orlonger;

}

then {

damping norm;

router bgp 1
bgp dampening	5	30 1000 4000
route-map damp-lite
bgp dampening	15 60 750 3000
route-map damp-norm
bgp dampening	30 120 500 2000
route-map damp-hard
!
ip prefix-list	1	permit 1.0.0.0/8
le 32
ip prefix-list	2	permit 2.0.0.0/8
le 32
ip prefix-list	3	permit 3.0.0.0/8
le 32

!

route-map lite permit 10 match ip prefix 1

!

route-map norm permit 10 match ip prefix 2

!

route-map hard permit 10 match ip prefix 3

(continued overleaf )

6.14 UNICAST REVERSE PATH FORWARDING	83
Table 6.8 (continued)
Juniper configuration	Cisco configuration

accept;

}

}

}

policy-statement damp-hard { term t1 {

from { protocol bgp;

route-filter 3.0.0.0/8 orlonger;

}

then {

damping hard; accept;

}

}

}

}

6.14UNICAST REVERSE PATH FORWARDING

Unicast reverse path forwarding (RPF) is a policy mechanism that is usually used to provide a degree of protection against spoofing of source addresses (a common feature of DoS packets). It works by checking the source of the inbound packet. If the route back to the source of the packet does not travel directly via the interface over which the packet was received, the packet is dropped.

While this is an attractive mechanism, particularly in today’s Internet where DoS attacks are a fact of daily life, it is essential that you take care when implementing it. If a network has only one path to the Internet and that path is via you, then implementing unicast RPF back towards that customer is safe. However, if there is more than one path via which a network can be reached, there is a risk of asymmetric routing. For example, suppose a multihomed customer is connected to you and to another ISP with which you peer. Your service is more expensive than the other ISP so your customer prefers to send traffic via the other ISP to reduce their costs. However, your policy is to prefer routes learned from customers over routes learned from peers. Therefore, when you receive a packet from that customer via your peer, if you have applied unicast RPF towards the peer, you will drop the packet because the path back to the customer is across the directly connected link.

For this reason, it is generally a bad idea to apply unicast RPF to anyone other than your singly homed customers. It is almost impossible to guarantee symmetric routing between your network and any other multihomed network since other networks will apply their own policy to meet their own business needs. Those business needs may be directly contradictory to your own.