A clean and powerful design of a routing policy in Juniper JUNOS rewards many network engineers, tired of looking into Cisco IOS route-maps, for crossing the line and juniperizeing themselves.

Routing tables (Routing information base – RIB) are like a heart in the router. These tables are pumping routes from one network neighbour to another and building up the forwarding table (Forwarding information base – FIB) which actually conducts the flow of the data packets. The interaction with network neighbours is controlled by policy. Routes are imported from some neighbour via some routing protocol and through some policy into a corresponding routing table. From there they can be exported via another policy to another protocol and to the outside world. Feeding the forwarding table is also controlled by an export policy.

It is easy to remember (while keeping in mind that routing table is the one in the centre): import to a routing table, export from a routing table, import to, export from, import to, export from …

A good example to start with is the advertisement of a default route to a neighbour via BGP. Cisco’s neighbor default-originate, so to speak. There is no magic and no tricks with funny keywords in JUNOS. Simply take the default route from the routing table in put it into the BGP-protocolish talk with your neighbour via an appropriate export policy. Remember: import to a routing table from a protocol, export from a routing table to a protocol.

Your configuration might look like this:
[edit policy-options policy-statement OriginateDefault]
term DefaultRoute {
    from {
        route-filter exact;
    then {
        next-hop self;
term DenyOther {
    then reject;

[edit protocols bgp group Member]
export [...other policies...  OriginateDefault];

Another example of an export policy is route classification. For example, you might be marking all prefixes received from the Google autonomous system (AS) for some accounting purpose. Here is your policy:

[edit policy-options policy-statement ClassifyPrefixes]
/* Google prefixes (AS15169) */
term Google {
    from {
        protocol bgp;
        as-path ASGoogle;
    then {
        destination-class GoogleDestinations;
        source-class GoogleSources;
...other terms...

[edit policy-options]
as-path ASGoogle ".* 15169";

When you apply this policy into the forwarding table feed

[edit routing-options]
forwarding-table {
    export ClassifyPrefixes;

… all prefixes which originate from Google AS will become members of corresponding source and destination classes (GoogleSources and GoogleDestinations), for example:

me@router.re0> show route ipv6.google.com extensive table inet6.0    
inet6.0: 8083 destinations, 22397 routes (8082 active, 1 holddown, 0 hidden)
2a00:1450::/32 (2 entries, 1 announced)
KRT in-kernel 2a00:1450::/32 -> {indirect(1048582)}
Destination class: GoogleDestinations
Source class: GoogleSources
Standby generator for ::/0
        *BGP    Preference: 200/-157
                Next hop type: Indirect
                AS path:  15169 I

You policy affects or modifies some attributes of the routes which are being exported from a routing table to the forwarding table (FIB). In our examples these attributes are source and destination classes which can be used in firewall filters, policers, accounting etc.

A Juniper router brain is controlled by policies. Well, I admit – it sounds scary, but it is very clean and efficient from a technical perspective.