South American – African Astronomy Coordination Committee (SA3CC) Meeting 2024


AmLight supporting Network Research Exhibition (NRE) demonstrations at SuperComputing (SC23)


FIU AmLight supporting the Advanced Cyberinfrastructure Coordination Ecosystem: Services & Support (ACCESS)



CI Lunch and Learn talk: Microburst Detection at AmLight







Subscribe to AMPATH mailing list




AMPATH's BGP Policy for IP Transit (commodity Internet transit)

This document defines how AMPATH manages their BGP routing infrastructure for the IP transit service.

General Information:

    1. 1. AMPATH's AS number is 20080 and supports both IPv4 and IPv6;
      2. AMPATH recommends that all customers use MD5 authentication on their BGP sessions:
          a. If the customer wants to use MD5 authentication, it should supply a password string;
      3. AMPATH reserves the right to disable a BGP peer that is adversely affecting other AMPATH customers or AMPATH's network stability and/or performance until the problem is remedied. A reasonable effort will be made to contact the customer prior to turning down the peer; however, the integrity of the AMPATH network remains the top priority;
      4. AMPATH makes no guarantees, explicit or implicit, about the routing policies of other providers and the routes that they accept into their routing tables;
      5. AMPATH filters BGP announcements from the customer based on network address space;
      6. Every new IPv4/IPv6 prefix to advertise from customers must be inserted in AMPATH's prefix-lists. To request this insertion, customers can:
          a. Request by ticket/email providing the information of new IPv4/IPv6 prefix.
          b. Provide a route-set from any public IRR.
      7. AMPATH uses RADB IRR for manage its and users IPv4/IPv6 prefixes. The following objects are used:
          a. Mnt-by: MAINT-AS20080
          b. Route-set: RS-AS20080-Transit
          c. Route-set per customer: RS-AS20080-AS<ASN#>
      8. Announcements are allowed on the following basis:
          a. AMPATH assigns the IP prefix to the customer;
          b. ARIN or other RIR assigns the IP prefix to the customer;
          c. When another provider assigns the IP prefix, AMPATH will verify the announcements by one of the following:
               i. The information is in RWHOIS or other RIR database.
               ii. The IP prefix already being announced globally from the customer
      9. Every new IP prefix usually takes up to 48 hours to be completely functional on the Internet;
      10. At any moment, customers may decide receive one of the following set of routes:
          a. Full Routing: all prefixes received from all BGP sessions;
          b. Partial Routing: only prefixes from AMPATH's customers and peers;
          c. Default Route: only default route;
          d. Full Routing + Default Route: all prefixes plus the default route;
          e. BGP Communities on Appendix B could be used by customers for more specific selection of routes;
      11. AMPATH does not accept announcements that are more specific than /24 for IPv4 or /48 for IPv6;
      12. AMPATH removes all community strings that are not on the list on Appendix B – AMPATH BGP Communities;
      13. AS Prepending: Customers with public AS numbers may prepend their AS path to control the desirability of their connections. Customers with an assigned private AS number from AMPATH may not pad their AS path. AMPATH will ignore any padding of private AS numbers from customers;
      14. BGP Multi-Exit Discriminator: customers with more than one BGP session could control their incoming traffic based on MED or BGP Communities to change the BGP Local Preference;
      15. AMPATH does not accept any RFC1918 prefix or private address;
      16. AMPATH uses 160 as default BGP Local Preference;
      17. AMPATH makes use of Unicast Reverse Path Forward (uRPF) in Loose mode to validate incoming traffic from users' IP interfaces, using IP prefixes provided by users on item #6;
      18. AMPATH provides a set of community strings to help customers to manage their traffic. These communities are listed on Appendix B – AMPATH BGP Communities;
      19. AMPATH reserves the right to perform inbound and outbound traffic engineering with its upstreams providers, using AS-Path prepending or BGP Communities;
      20. Any question about IP transit, BGP or this document can be sent to

RPKI Validation:

    1. 1. AMPATH implements Origin Validation using RPKI security framework;
      2. The "invalid" routes have their local preference changed to 90 in the AMPATH routers; The "valid" and "unknown" routes are accepted;
      3. AMPATH adds communities to the announced routes to inform our customers about the validation state. These communities are listed in Appendix C – RPKI BGP Communities.


APPENDIX A – BGP Local Preference Information

The following table displays all BGP Local Preferences used in AMPATH’s backbone. This information is useful when using BGP Communities from Appendix B.

These are the assigned BGP Local Preferences in use in AMPATH:


Local Preferences

Smaller LP 110
Transit Upstreams 12X
Under Peerings 130
Peerings 14X
User's Secondary 150
User's Primary (default) 160




Local Pref

FLR Transit 11096 120
NTT 2914 125
LANautilus 6762 125
TR-CPS Peers - 145
FLR-Members 11096 148
NOTA Peers - 148
FL-IX Peers - 148
Default for users - 160


Appendix B – BGP Communities

AMPATH’s community strings are separated in two tables. The Table A introduces all informational and the Table B introduces all traffic-engineering BGP communities.

Table A: Informational BGP Communities Table B: Traffic engineering communities

Information BGP Communities

String Function
20080:1000 Represents all users
20080:1001 Represents AMPATH
20080:1002 Represents FIU
20080:1004 Represents ANSP
20080:1005 Represents RedClara
20080:1006 Represents AURA
20080:1007 Represents NWS
20080:1009 Represents CENIT
20080:1012 Represents UVI
20080:1013 Represents B.Root-Server-OPS
20080:1014 Represents UPR
20080:3000 Represents All IXPs
20080:3002 Represents NOTA
20080:3004 Represents FL-IX
20080:4000 Represents All Upstreams
20080:4003 Represents LAN
20080:4004 Represents FLR
20080:4005 Represents NTT
20080:5000 Represents all

Traffic Engineering BGP Communities

String Function
20080:110 Changes the BGP Local Preference to 110, 130 or 150.
20080:660 Black-hole to all upstreams
20080:662 Black-hole to Lanautilus
20080:664 Black-hole to NTT
20080:666 Black-hole to all upstreams
20080:700 Don't send to any peering
20080:701 Don't send to any customer
20080:702 Don't send to any upstream
20080:703 Don't send to NTT
20080:704 Don't send to LAN/TISparkle
20080:705 Don't send to NOTA/Equinix
20080:706 Don't send to FL-IX
20080:801 Add one prepend
20080:802 Add two prepends
20080:803 Add three prepends
20080:804 Add four prepends
20080:900 Don't send to Hurricane Electric
20080:901 Add one prepend to Hurricane Electric
20080:902 Add two prepends to Hurricane Electric
20080:903 Add three prepends to Hurricane Electric
20080:904 Add four prepends to Hurricane Electric


Appendix C – RPKI BGP Communities

The following table displays all RPKI BGP communities used in the AMPATH environment.

RPKI Communities

String Function
20080:6500 Invalid Routes
20080:6501 Unknown Routes
20080:6502 Valid Routes