BGP FAQ
With this FAQ we try to answer the most common questions about BGP Sessions at iFog along with the location-specific differences.
BGP
Where and which products support BGP Sessions?
-BGP Sessions are supported on all IXP Access VMs, Colocation, Dedicated and VPSs 512MB and above.
-BGP Sessions are not supported on 256MBs in Houston and Singapore. We may allow them at our discretion in those locations if the customer has multiple services in their account.
Where can I get a full table?
-Full tables are possible in Zurich, Frankfurt, London, Amsterdam, Barcelona, Oslo, Toronto, Kansas and Fremont.
-Partial Tables (IXP + HE) are available in Sydney.
-Default route only: Singapore, Houston.
-Full Tables are only supported on VPSs with 512MB and more RAM.
How are ASN Validations done?
-We ask that BGP and IXP Customers add AS34927 to their import/exports in the RIPE DB for Authentication. For other regions, the signup mail must match an email listed in the WHOIS. We may decline the request or ask for additional information if an ASN cannot be clearly authenticated with your account.
How do filter updates work?
-We require all prefixes to have a valid route object and RPKI ROA in the relevant registry (RIPE, ARIN, APNIC, AFRINIC, LACNIC). If a prefix is part of a larger block the same ASN/ORG holds, the parent prefix must have a route6 object as well to allow for aggregation and le filtering.
-We may refuse to route prefixes listed on EDROP or prefixes with unverifiable or 3rd party IRR.
-Filter updates are automated in Frankfurt, Zurich, London, Amsterdam, Barcelona, Norway, Toronto, Kansas , Fremont, Sydney (IPv6).
-The Prefix lists for ASNs are refreshed daily, no ticket is required to enable or add a prefix to it. To add downstream ASNs a ticket is still needed to whitelist the ASN (see downstream support).
-Filters in other locations can be updated by opening a ticket and must include the ASN & prefix list. The prefix list must include le if it shall be added as le. Generally, prefix list updates are done within 72h after which prefixes are usually also reachable.
-An LOA is required in the following locations: Singapore and Houston. An LOA must be on an official letterhead, include the prefix(es), ASN, and contact information, and must be signed. We may ask for an LOA in other locations at our discretion. LOAs are also required for 44net to create a route object for those ranges.
-Some of our upstreams require manual filter refreshes as well, eg. Sydney - updates therefore may take up to a week. Prefix ticket updates fall under our fair-use terms and we may deny or slow them down at our discretion should they be abnormally high.
Are there prefix limits on Transit sessions?
-We set a prefix limit on all transit and peering sessions. The default limit on downstream sessions is 10. Increasement is performed by 10 prefixes. with a maximum imposed for non-transit users.
-We determine the limit based on announced prefixes, then up to the next increment. For example, if you announce 3 prefixes the limit is 10. For 26 its 30.
-Prefix limits are configured to block, the session will stay up but not accept any more prefixes.
Are there BGP communities?
-A list of BGP communities can be found here: ifog.ch/en/blog/bgp-community-support
-In addition to our own action communities, we support passthrough, so you can attach communities from upstream or IXPs.
-All prefixes are tagged informational communities on import, 34927: followed by a 3-digit number. The first digit identifies the location, and the second two the type. The type matches the action community scheme: E.g. a route learned from HE in Amsterdam has the information community 34927:713. The corresponding action community is: 34927:913x
Locations Identifiers:
Frankfurt: 1xx, Kansas: 2xx, Fremont: 4xx, London: 5xx, Oslo: 6xx, Amsterdam: 7xx, Zurich: 8xx
Type Identifiers:
x2x: Originated by 34927 or downstream, x30: Learned from IXP
Note that your session must have BGP Community Support enabled, if communities do not seem to get applied open a ticket to enable Community Support on your session.
Are downstream supported?
-Downstreams are supported in Zurich, Frankfurt, London, Amsterdam, Barcelona, Oslo, Toronto, Kansas, Fremont and Sydney.
-To add a downstream let us know the ASN and prefix list, the ASN will be added to our as-path filter.
-We may ask for verification of downstream ASNs.
-We may refuse ASNs listed on EDROP or ASNs of persons or companies on our banlist.
-Note that the ASN must be part of your AS-Set, and your AS-Set and those included must be clean at all times, you are responsible for any downstreams that have an AS-SET nested within yours. Downstreams are a fair-use feature and are added at our discretion. Support may be withdrawn for any customer at any point if RPKI and route6 objects are repeatedly missing, the AS-Set is not clean, information is not provided, prefix leaks occur, or the fair-use clause is abused.
Which locations are connected to the Backbone and how are prefixes exchanged?
-Our European Backbone connects London, Zurich, Frankfurt, Barcelona and Amsterdam, Oslo and extends to the US. Our US Backbone connects Kansas, Houston and Toronto.
-Our own Prefixes and those from downstreams are exchanged with the neighbouring locations. Eg. Amsterdam to Frankfurt and Zurich. Downstream prefixes are exported to peers and IXPs in locations connected to the backbone but not upstreams. In some very limited cases, prefixes are also exported to upstream: LGI from Frankfurt to Amsterdam and Zurich. Routes learned over IXPs are exported to connected locations, eg. SwissIX routes to Frankfurt and London.