Specifications

Page 97 /148
and origin. For match conditions, you also can specify lists of routes, which are
grouped so that a common action can be applied to them.
Examples of the elements the policy engine can take into account include:
§ IP prefix
§ AS path
§ Origin code
§ BGP community
§ MULTI-EXIT-DISCRIMINATOR
§ NEXT-HOP
§ LOCAL-PREFERENCE
§ IS-IS level
§ OSPF area
§ Peer from which the route was received
§ Routing protocol from which the route was received
§ Interface from which the route was received
The action in a policy specifies what to do if the route matches the match
conditions. The action can specify whether to accept or reject the route, it can
control how a series of policies is to be evaluated, and it allows you to set various
properties associated with the route, such as the AS path and BGP community
value.
Because the policy language is like a programming language, it is very general in
nature, permitting it to be extended over time by simply adding new attributes or
new actions. This results in a language that addresses today’s needs and
provides the ability to grow to support future Internet requirements.
JUNOS supports extensive filtering and manipulation of BGP parameters by the
use of it’s policy tolls as described below. The most commonly used are:
§ LOCAL_PREF. The LOCAL_PREF (local preference) attribute is used to
express preference within an autonomous system. For example, an AS is
multihomed to two service providers. Each provider advertises many routes
into the AS to the same destinations, but internal policy dictates that ISP1
should be preferred for certain destinations, with ISP2’s paths used only as
backup. For other destinations, ISP2 should be preferred over ISP1. By
setting the LOCAL_PREF value higher on the proper routes, those paths are
preferred by all BGP routers within the AS. LOCAL_PREF is strictly an
internal attribute, and is not communicated to neighboring autonomous
systems.
§ MULTI_EXIT_DISC (MED). Where LOCAL_PREF is used to set
preferences for outgoing traffic, MED is used to set preferences for incoming
traffic. If an AS is multihomed to the same provider, it may want the provider
to prefer certain ingress points for certain internal destinations. The AS can
vary the MED values of the routes advertised on the ingress points. If the
provider is configured to honor MEDs (perhaps as part of the peering
agreement), it will prefer the ingress path with the lower MED. MEDs only
influence neighboring autonomous systems; the provider in this example
does not advertise the MEDs to its other neighbors.
§ AS_PATH. The AS_PATH attribute is a listing, sequential or unordered, of
all autonomous systems the path traverses. When an AS is multihomed, it
can influence the ingress point chosen by remote systems with a technique
known as path prepending. Given otherwise equal BGP paths to the same
destination, a system normally selects the path with the lower AS_PATH. For
example, the path [601, 200, 45] would be preferred over the path [601, 310,
4002,45]. By adding its own AS number in some multiple to the AS_PATH of
routes advertised from a certain ingress point, an AS can cause remote
systems to view that point as less preferable. Path prepending can affect
routing decisions beyond neighboring autonomous systems.
§ COMMUNITY. The community attribute is used to group routes to which
common policies apply. For example, certain routes might be advertised to a
neighboring AS but that AS should not advertise the routes to any other AS.
The well-known community attribute NO_EXPORT can be set on these
routes to communicate that policy to the neighboring AS. COMMUNITY is a
very useful and powerful attribute when varying policies must be applied to
large numbers of routes.