Routing Policy

VTS Routing Policy

This page describes the policy implemented at the borders of AS37721 to control the import and export of routing information with other autonomous systems.

The information provided maybe altered and updated at any time. Though our processes cover updates to documentation, there is no guarantee that it is always up-to-date. In case of doubt, transit customers should contact our NOC noc@vts.bf and peers should contact peering@vts.bf.

A list of communities used by AS37721 and their meaning can be found under bgp communities page on this website.

AS37721's main as-set is AS-VTS-SET (AFRINIC).

 

Finding Information

VTS maintains up to date information in multiple publicly available data sources, including:

If any of the information you find on this page does not contain what you are looking for or if the information within this page appears to be inaccurate, please email peering@vts.bf.

 

Peering Relationships

The topological relationship of AS37721 to the external peers of AS37721 may be generally categorised into:

  • Customers
  • Peers
  • Transits

These terms are used herein to describe the topological relationship between AS37721 and an adjacent network, and do not necessarily imply the existence of a particular commercial relationship.

AS37721 may have multiple distinct relationships with a given AS at different points of interconnection. Thus, polices described here as applying to particular types of interconnection relationship should be construed as applying only to those interconnections or peerings of that type, rather than to all adjacencies with a given AS.

 

Import and Export Policies

Some policies are implemented uniformly across all adjacencies, whilst others will vary according to the topological relationship between AS37721 and the adjacent networks.

Autonomous Systems

  • 37721

BGP Protocol

AS37721 will exchange routing information for Internet networks with external peers using Border Gateway Protocol version 4 only.

Bogon Address Space

  • AS37721 will not accept routing information for, and will not deliver IP packets addressed to or from, “Bogon” address space, including RFC1918, RFC2544, RFC3927, RFC 5735, RFC5737, RFC6598 and RFC6890)
  • IPv4 or IPv6 address space present in the Team Cymru Fullbogons list
  • IX (Exchange) LAN ranges VTS connects to

Bogon and reserved ASNs

AS37721 will not accept routing information that contain Bogon ASNs in the BGP path (private and reserved ASN numbers as defined by RFC7607, RFC6793, RFC5398, RFC6996, RFC7300)

Prefix Length

AS37721 will accept routing information for IP prefixes conforming to minimum and maximum prefix-lengths as follows:

Address Family Min Length Max Length
IPv4 8 bits 24 bits
IPv6 16 bits 48 bits

AS Path Length

AS37721 will not accept paths with length more than 32.

Import BGP Filtering

Prefix Filter

AS37721 makes use of RPSL data contained in the distributed IRR system to maintain per-neighbor AS filters for all customer and peer networks of AS37721.

AS37721 maintains the following RPSL datasets which may be used to prefix filter adjacencies with AS37721:

  • as-set : AS37721:AS-TRANSIT
  • as-set : AS37721:AS-PEERS
  • as-set : AS37721:AS-CUSTOMERS

Please note: The size of as-set should not be used as an indicator of the number of routes that a non-customer peer should expect to receive.

Ingress prefix-lists are built by recursively resolving the appropriate as-set down to a list of members ASNs, and then searching for route or route6 objects with the origin attribute set to one of these ASNs. This process is repeated daily, and updated prefix-lists are installed on border routers at approximately 03:00 in the timezone local to each router.

Prefixes received from customers and peers are accepted only if a route or route6 object matching the advertised prefix and origin AS is found. Prefixes received are subjected to the other conditions described in this document, including minimum and maximum prefix length.

Maximum Prefixes Limits

AS37721 sets limits on the maximum number of prefixes accepted from a given eBGP neighbor. When a reasonable suggested value is published in the PeeringDB, that value will be used. Otherwise, VTS use its discretion to arrive at an appropriate value.

AS_PATH Filters

AS37721 filters all eBGP adjacencies with customers and peers based on AS_PATH. All customer or peer routes must originate from their respective ASN, unless otherwise defined in a peer-specific agreement.

Export BGP Filtering

Export to Customers

AS37721 will advertise one or more of the following sets of prefixes towards its customer peers:

  1. Full Routes: All routes learned by AS37721 from customer and non-customer peers according to the policies described herein.
  2. Default Route: A single route of last resort, i.e. 0.0.0.0/0 or ::/0, generated locally on the border router upon which the eBGP session with AS37721 is configured.
  3. Partial Routes: In the case of “partial transit” customers, a subset of the full routes, being those imported from non-customer peers within the defined scope of the relevant customer’s service. In all cases, partial transit customers will be advertised all prefixes imported from other customers, regardless of their scope of service.
Export to Non-customers

AS37721 will export towards non-customer peers only routes that are originated in AS37721 or imported from customer peers.

Peers wishing to set a sensible maximum-prefixes limit on sessions with AS37721 should refer to the ‘IPv4 Prefixes’ and ‘IPv6 Prefixes’ field in our record on PeeringDB.

AS37721 will make every attempt to maintain consistent announcements of prefixes towards peers. However, advertisement of prefixes learned from customers may be suppressed at certain peering locations, or towards specific neighbor ASNs, as the result of traffic engineering communities received from customers.

To prevent the inadvertent advertisement of transit between non-customer networks, a BGP community will be appended on import to indicate that a prefix was imported from a customer peer, and only prefixes carrying such community will be exported to non-customer neighbors.

 

Route Control 

The following BGP attribute handling policies define the expected route selection, for traffic routed to and from AS37721.

Local Preference

AS37721 sets the BGP LOCAL_PREF attribute on import according to the relationship of AS37721 to the adjacent neighbor or the type of route, as per the below table.

Where a range of values is indicated, other factors such as whether a peering cross an IXP or PNI are used to select the eventual value. By default, the mid-range value will be used.

  LOCAL_PREF
Transit 101 to 150
Peer 151 to 300
Customer 301 to 400
Locally Originated 450
Blackhole Routes 666

AS Path

AS37721 will not modify the AS_PATH attribute of any route on import.

Customers of AS37721 may send BGP communities to influence the export of their routes to non-customer peers. Such communities may be used to suppress advertisement, prepend 37721 up to 3 times to selected groups of non-customer peers, or influence the LOCAL_PREF values of their prefixes relative to the AS37721 routing domain.

The above functionality is documented fully in BGP Communities.

MED

On export of any route, AS37721 will set the MULTI_EXIT_DISC (MED) attribute to a value equal to the IGP cost to the NEXT_HOP address of the route (before any changes are made to NEXT_HOP on export).

Similarly, unless agreed otherwise in advance, AS37721 will set the MED of any routes received from any single-homed peers (customer and non-customer) to zero on import. Multi-homed peers may be requested to adjust the MED values on export to align with AS37721 policy logic.

Routes received from customers with a MED value set will be imported unmodified by AS37721, and the route with the lowest such value will be preferred for selection (provided all other path selection factors are equal).

© VTS 2020. All rights reserved.