Filters and Policies

In Juniper routers, routing filters and policies are crucial components for controlling route advertisement, acceptance, and manipulation. They help secure your network by filtering unwanted routes and implementing routing policies for different peers.

Components of Route Filtering

1. Prefix Lists

Prefix lists define sets of IP prefixes that can be referenced in routing policies. They are commonly used to specify allowed or denied routes.

prefix-list pfx-as-example {
    1.1.1.0/24;
    1.0.0.0/24;
}

prefix-list pfx-as-example-v6 {
    2001:0000:0000::/48;
}

2. Route Filter Lists

Route filter lists provide more granular control over route matching, including prefix length matching:

route-filter-list bogon-routes {
    0.0.0.0/8 orlonger;                # RFC 1122 'this' network
    10.0.0.0/8 orlonger;               # RFC 1918 private space
    100.64.0.0/10 orlonger;            # RFC 6598 Shared Address Space
    127.0.0.0/8 orlonger;              # RFC 1122 localhost
    169.254.0.0/16 orlonger;           # RFC 3927 link local
    172.16.0.0/12 orlonger;            # RFC 1918 private space
    192.168.0.0/16 orlonger;           # RFC 1918 private space
    224.0.0.0/3 orlonger;              # RFC 5771 multicast
}

3. Route Filter Match Types

Common match types include:

• exact: Matches the exact prefix length

• orlonger: Matches the prefix and all more specific routes

• prefix-length-range: Matches prefixes within a length range

• longer: Matches all more specific routes (but not the prefix itself)

Example:

route-filter-list prefix-lengths {
    0.0.0.0/0 exact;                    # Match default route only
    0.0.0.0/0 prefix-length-range /0-/7; # Match very short prefixes
    0.0.0.0/0 prefix-length-range /25-/32; # Match very long prefixes
}

Policy Statements

Policy statements combine various match conditions and actions to implement routing policies. Here's an example of a comprehensive policy:

policy-statement customer-policy {
    term bogon-filter {
        from {
            route-filter-list bogon-routes;
        }
        then reject;
    }
    
    term prefix-list-match {
        from {
            prefix-list customer-prefixes;
        }
        then {
            local-preference 200;
            accept;
        }
    }
    
    then reject;    # Default action
}

Common Policy Components

1. RPKI Validation:

term rpki-valid {
    from {
        validation-database valid;
        policy rpki-check;
    }
    then accept;
}

term rpki-invalid {
    from community origin-validation-state-invalid;
    then reject;
}

policy-options community origin-validation-state-invalid members 0x4300:0.0.0.0:2;
policy-options community origin-validation-state-unknown members 0x4300:0.0.0.0:1;
policy-options community origin-validation-state-valid members 0x4300:0.0.0.0:0;

1. Bogon ASN Filtering:

term bogon-asns {
    from as-path-group bogon-asns;
    then reject;
}

1. Blackhole Route Handling:

term blackhole-route {
    from {
        community source-route-blackhole;
        route-filter-list source-route-blackhole;
    }
    then {
        community add upstream-route-blackhole;
        accept;
    }
}

Best Practices

1. Default Deny Always end policies with an explicit reject:

policy-statement example {
    /* policy terms */
    then reject;    # Default deny
}

1. Hierarchical Filtering Structure your policies in order of priority:

• RPKI validation

• Bogon ASN filtering

• Bogon prefix filtering

• Specific prefix matches

• Default action

1. IPv4 and IPv6 Separation Keep IPv4 and IPv6 filters separate for clarity:

term ipv4-filters {
    from {
        route-filter-list ipv4-bogons;
    }
    then reject;
}

term ipv6-filters {
    from {
        route-filter-list ipv6-bogons;
    }
    then reject;
}

1. Documentation Use descriptive names and comments for filters and policies:

prefix-list customer-prefixes {
    # Customer: Example Corp
    # ASN: AS12345
    # Last updated: 2024-02-23
    192.0.2.0/24;
    198.51.100.0/24;
}

Example Complete Configuration

Here's a complete example combining all elements:

policy-statement peer-import {
    term bogon-asns {
        from as-path-group bogon-asns;
        then reject;
    }
    
    term rpki-invalid {
        from community origin-validation-state-invalid;
        then reject;
    }
    
    term bogon-routes {
        from {
            route-filter-list bogon-routes;
        }
        then reject;
    }
    
    term customer-routes {
        from {
            prefix-list customer-prefixes;
        }
        then {
            local-preference 200;
            accept;
        }
    }
    
    then {
        local-preference 100;
        accept;
    }
}

Verification Commands

To verify your filter and policy configuration:

show policy peer-import
show route receive-protocol bgp peer-address
show route advertising-protocol bgp peer-address
show policy statistics policy-name
show validation database

Security Considerations

1. Always filter bogon routes and ASNs

2. Implement RPKI validation where possible

3. Set appropriate prefix length limits

4. Filter private and reserved address space

5. Implement route dampening for unstable prefixes

By properly implementing routing filters and policies, you can maintain a secure and stable routing environment while enforcing your network's routing policies.