Leaking BGP routes is a common sport among the ISP community. I done a presentation on my personal experience at LINX 57 over ten years ago but it is still valid today.

Background

If you are joining an exchange you should assume that other member will leak, and be prepared. Please consider those method as non-exclusive, the more you filter the less likely you are to leak.

Things no-one should announce or accept

Small Prefixes

Many ISP carry their customer routes (DSL, etc.) in iBGP as the IGP should remain stable and small to converge quickly.

Should an ISP leask those route, you could see thousands of /32-/2x routes, as the smaller prefix routable over the internet is a /24, make sure to not accept very small prefixes

/* match and refuse any route smaller/longer than a /24 */

[edit policy-options]
policy-statement no-small-prefixes {
    from {
        route-filter 0.0.0.0/0 prefix-length-range /25-/32 reject;
    }
    then reject;
}

BOGONS

As well, make sure you do not accept (or announce) reserved ranges and non-routable ones.

/* bogon, rfc1918, etc. */

[edit policy-options]
policy-statement no-bogons {
    from {
        route-filter 224.0.0.0/4 orlonger reject;
        ......
    }
}

Things obviously wrong ..

Only you can know what you can not learn from your peers but the transfer lan of an IX may look like something you would only learn from a mis-configuration

/* Linx LAN */

[edit policy-options]
policy-statement no-ix {
    from {
        route-filter 195.66.224.0/22 orlonger reject;
    }
    then reject;
}

And then make sure you never see it .. or announce it

/* should never get in or out */

[edit protocols bgp group linx]
export [ no-small-prefixes no-ix no-bogons ];
import [ no-small-prefixes no-ix no-bogons ];

Protect yourself

Max Prefix

The quickest and simplest way to get some form of protection is a max-prefix limit, ie to put an upper bound to the number of routes you will accept from your peers

The router will prefix then will shutdown a session should the ebgp speaker send you more than a predefined number of routes (was it necessary to say it ?)

neighbor 195.66.224.xxx {
    description "AS-ACCEPTED | Peer name | noc@peer.co.uk | AS-SENT";
    family inet {
        unicast {
            prefix-limit {
                maximum 150;
                teardown 80 idle-timeout 5;
            }
        }
    }
    peer-as 1234;
}

Max Prefix Limitations

On cisco this works great as the count is performed on prefix accepted. On juniper not as good the counting is done on prefix received (before any kind of filtering) which is much less useful. For the clueful

Go and thanks RAS for his excelent max-prefix auto-tuning work at http://juniper.cluepon.net/index.php/OS_Auto_Tuning_Prefix_Limits

Please push for this feature to your SE.

Peers are not your transit providers

As an ISP you know who your transit providers are and their ASN. You should filter from your announcement any route with an AS-PATH which contain them

Here is an example for Juniper (assuming your transit is from Level3 and Sprint)

/* define the routes we have learned from transit (example) */
as-path routes-level3 3356.*;
as-path routes-sprint 1239.*;

/* create a policy blocking their distribution */
[edit policy-options]
policy-statement no-transit {
    term remove-path {
        from {
            protocol bgp;
            as-path [ routes-level3 route-sprint ];
        }
        then reject;
    }
}

/* make sure that no linx peer will ever get them again */
[edit protocols bgp group linx]
export [ no-transit ];

Peers are not your customers

You should never see your customers routes from your peers neither. Peers should know better

Your peers should not neither leak routes with reserved ASN, mainly when they can be filtered with one line.

[edit protocol bgp group linx]
  remove-private;

Protect your reputation

Filtering routes using communities

First you must tag your route to know what is what

It is in every book, your tag your route inbound and filter them outbound.

/* define a communtiy to identify routes learned from transit */
community route-transit members 1234:1239;

/* create a policy to apply this community to a route */
policy-statement tag-transit {
    then {
        community add route-transit;
    }               
}

/* make sure all routes from transit have that community */
[edit protocols bgp group transit]
import [ tag-transit tag-transit-provider-specific ];

(repeat with peers)

Then your use this to stop the annoucement to your peers

/* define a policy rejecting routes identified as transit */
[edit policy-options]
policy-statement export-transit {
    term remove-peering {
        from {      
            protocol bgp;
            community route-transit;
        }           
        then reject;
    }               
    term remove-peering ...
    term remove-community ...
    term prepend-one-time ...
}

/* and make sure no linx peer sees it */
[edit protocols bgp group linx]
export [ export-peering export-linx ];

Don’t make a typo with your community definition without filtering on as-path as it hurts.

Filter using AS-PATH

Most large networks have very “private” peering policies and it is unlikely that you should ever learn any of their route via peering (otherwise it would be called transit).

/* define the routes you will never see through peers */
as-path leaked-sprint ".{1,}1239.*";
as-path leaked-telia ".{1,}1299.*";

/* create a policy blocking their distribution */
[edit policy-options]
policy-statement no-leak {
    term remove-path {
        from {
            protocol bgp;
            as-path [ leaked-telia leaked-sprint ];
        }
        then reject;
    }
}

/* make sure that no linx peer will ever get them again */
[edit protocols bgp group linx]
import [ no-leak ];

Filtering using the registry DB

Some tools, such as irrpt_, exist to help with the generation of filter based on the content of the IRR DB (RIPE, ARIN, etc.) gather and track prefix within AS-Macro.