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).
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.
The topological relationship of AS37721 to the external peers of AS37721 may be generally categorised into:
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.
Some policies are implemented uniformly across all adjacencies, whilst others will vary according to the topological relationship between AS37721 and the adjacent networks.
37721AS37721 will exchange routing information for Internet networks with external peers using Border Gateway Protocol version 4 only.
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)
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 |
AS37721 will not accept paths with length more than 32.
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 : AS-VTS-SETas-set : AS37721:AS-TRANSITas-set : AS37721:AS-PEERSas-set : AS37721:AS-CUSTOMERSPlease 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.
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 FiltersAS37721 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.
AS37721 will advertise one or more of the following sets of prefixes towards its customer peers:
0.0.0.0/0 or ::/0, generated locally on the border router upon which the eBGP session with AS37721 is configured.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.
The following BGP attribute handling policies define the expected route selection, for traffic routed to and from AS37721.
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.
| LOCAL_PREF | |
| Transit | 90 to 110 (default: 100) |
| Peer | 151 to 310 |
| Customer | 311 to 400 (default: 400) |
| Locally Originated | 450 |
| Blackhole Routes | 666 |
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.
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).