Seabone home page

Seabone BGP Policy for Customers


Customers can find below our policy for propagation of BGP announcements over our network.

Filtering

All customers must be filtered by prefixes, using the automated tool that queries the IRR databases.

Automated Prefix Filtering

Customers are required to maintain their IRR objects (as-set or route-set) in one of the well known routing databases. Our tool queries by default the databases at RIPE, RADB, APNIC, ARIN in this order. Other databases are possible, so long as they are currently mirrored by RADB.

The customer's as-set must contain a reference to the customer's ASN, and to all of the indirect customers behind. Make sure not to include peers and transits in your as-set. Please also ask your customers to keep their objects up to date and clean.

Please note that the tool works by looking at all route objects whose origin field matches the AS numbers listed in the as-set. This means that the owner of the ip address block must correctly register a route object in an IRR database. The as-set alone is not sufficient.

The tool that updates the prefix lists runs Mon-Fri at 06:00 CET/CEST, and it takes a couple of hours to complete. Customers that wish so may receive a monthly email with the full prefix list as a reminder.

For any query about the automated tool, contact tech support.

Accepted prefix length

IPv4

We filter all announcements longer than /24 (i.e. a /25 or /26 is not accepted). Please consider using no-export if you need to deaggregate for traffic engineering purposes.

IPv6

We don't allow fragmentation of IPv6 space. Routes are accepted only as an exact-match against the route6 objects registered in the IRR.

Special arrangements for customers with multiple links are possible for traffic engineering purposes. Contact tech support for details.

Prefix lists

We recommend that you maintain an Internet Routing Registry (IRR) object (as-set or route-set) in one of the well known registries (RIPE, RADB, ALTDB, etc) so that all partners that use automated filters can properly build a list of prefixes.

Standard query is on RIPE,RADB,APNIC,AFRINIC,ARIN,SCW Dbs.
NOTE that if your prefixes are not registered on other Db ask, in activation phase to add appropriate db in your query!

Other BGP parameters

The following items are configured by default for all customers.

Maximum Prefix

We apply a maximum prefix limitation to all customers, usually set at a value double of the number of prefixes received at activation time. Please send us a notice when you're about to add a large customer that could raise your total number of prefixes significatively, so that we can raise the maximum prefix beforehand to avoid service interruption.

MD5

We don't require MD5 on BGP sessions but we support it if the customer desires so. All BGP sessions with the same customer must have the same password.

Remote-triggered blackholing

If you are experiencing a Denial of Service (DoS) against one or more of your ip addresses, you can send us a route labelled with the community 6762:666, and we will immediately null-route that address. Warning: this means that this ip address will be TOTALLY unreachable! If you need to block only a certain type of traffic (e.g. udp traffic), you will still need to call our NOC and have a traditional access list installed in place.

This feature is supported only for blackholing single hosts (/32). If you need to blackhole a larger block, please contact NOC.

Abuse of these features may lead to termination of service and legal action to recover any damage.

This feature is currently not available in IPv6.

Technical informations

Here is an example of configuration to use of this feature:

  1. Define a route map to redistribute statics into bgp
    route-map static-to-bgp permit 5
    match tag 12345      
    set community 6762:666 additive
    	
  2. Enable redistribution and disable summarization
    router bgp 65535      <---------- replace with your AS number !!
    redistribute static route-map static-to-bgp
    no auto-summary
    	
  3. Enable passing of communities to bgp neighbors
    router bgp 65535
    ! for each neighbor and/or eBGP peer group:
    neighbor x.y.z.t send-community
    	
  4. Enable visualization of community in sane format:
    ip bgp-community new-format
    	

This ends the preparation phase. Now, when one of your servers is under attack, you can immediately block traffic to it by setting a static route on your router:

ip route 192.168.0.1 255.255.255.255 Null0 tag 12345
    

Replace 192.168.0.1 with the actual ip address of the attacked server.

Next Hop Tracking

Our network uses Cisco's Next Hop Tracking feature internally. This means that routes are propagated in iBGP without setting next-hop-self.

Customers are advised not to use the same loopback address to setup multiple BGP sessions with us. If you do this, traffic for you will be routed towards your loopback following our IGP metric without taking into consideration the BGP announcements on each session.

Communities

We accept only the communities listed in this document and the no-export community. All other communities are removed.


See also:


Last modified: Tue Aug 27 10:30:31 CEST 2013