Customers can find below our policy for propagation of BGP announcements over our network.
All customers must be filtered by prefixes, using the automated tool that queries the IRR databases.
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.
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.
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.
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!
The following items are configured by default for all customers.
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.
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.
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.
Here is an example of configuration to use of this feature:
route-map static-to-bgp permit 5 match tag 12345 set community 6762:666 additive
router bgp 65535 <---------- replace with your AS number !! redistribute static route-map static-to-bgp no auto-summary
router bgp 65535 ! for each neighbor and/or eBGP peer group: neighbor x.y.z.t send-community
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.
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.
We accept only the communities listed in this document and the no-export community. All other communities are removed.
Last modified: Tue Aug 27 10:30:31 CEST 2013