By accepting services from CLOUDXCHANGE, participants implicitly agree to the connection policy.
- CLOUDXCHANGE may be referred to as "CXC". CXC and the Participant may each be referred to herein individually as a "Party" and collectively as the "Parties".
- "Services" means physical reservation of a physical network switch port, and related services such as route servers.
- "Fees" means the fees for Services, as set forth in the fees section, as applicable.
There are no contractual term lengths associated with CXC participation. Either party may terminate services at any time. CXC does not refund or prorate port fees.
CXC is being engaged only to provide the Services set forth in this policy. CXC shall not be liable for any loss of data and shall not be responsible for restoring any lost data or software. CXC does not warrant any third party products or systems. CXC expressly disclaims all warranties of any kind relating to the Services, whether express or implied, including, without limitation, the implied warranties of merchantability, fitness for a particular use or purpose, title and non-infringement.
CXC makes no warranty that the Services will meet Participant's requirements other than those set forth in this policy, that the results obtained from the use of the Services will be satisfactory, accurate or reliable, or that the Services will meet Participant's expectations. The representatives of CXC have no authority to give any warranties on behalf of CXC.
Participant traffic filters must allow standard neighbor discovery protocols. Failure to do so may result in excess flooded packets on the exchange fabric, which can negatively impact other participants and CXC resources. CXC Team reserves the right to disable ports that violate the rules.
Port sharing only by carrier provider as remote exchange.
CXC support port type 1GE (802.3z), 10GE (802.3ae), 25GE (802.3af), 40GE (802.3bg), and 100GE (802.3bg) depending on location or available switch platform. CXC implement mac address filter on participants ports, please see Mac Address Limitation in allowed traffic page.
Participant routers must be configured to receive and respond to ARP packets from all CXC participants, even those that are not direct peers.
Participant routers must be configured to receive and respond to ICMPv6 neighbor solicitation packets from all CXC participant addresses, even those that are not direct peers.
Participants must use BGP-4 and must set NEXT_HOP_SELF if advertising routes from other CXC participants.
What Is Bilateral Peering?
Bilateral peering is a direct peering arrangement between two autonomous systems. While the two peers may use the CXC peering fabric to peer with one another, they do not utilize the CXC Route Servers to exchange routing information.
Participants must use BGP-4 and must set NEXT_HOP_SELF if advertising routes from other CXC participants.
What Is Multilateral Peering?
Multilateral peering is a "one to many" exchange of routing information where participants peer with the CXC Route Servers, which exports the routing information of other participants. The CXC ASN will not appear in the AS_PATH of exported routes.
CXC route server sync with PeeringDb record every 6 hours, check route server peering and and record are match. If participant not connect their PeeringDb record to CXC, peering configuration will be shutdown automatically from the CXC route server. If you have any problem for update PeeringDb record please contact CXC Team at peering@cloudxchange.id.
CXC Route Servers will only accept authorized routing information from participants. Authorized routes are determined in the following ways:
RPKI Route Origin Authorization
CXC leverages multiple sources of truth for RPKI route validation, and automatically drops invalid routes. Participants are strongly encouraged to create Route Origin Authorization objects with a valid RPKI Repository.
Direct Route Origin
CXC authorized routes with origin ASN peers (no transit allowed) except participants who have content or CDN and agree to share with other participants through Multilateral Peering.
Participants may not point a static route towards another participant's resources without their express permission. CXC reserves the right to disable ports belonging to participants found to be in violation of this policy without prior notice to the participant.
Please Inform Us of Unique Routing Arrangements
If two or more participants have mutually agreed to exchange traffic outside the participant's respective autonomous system, please inform the CXC Team so we don't inadvertently shut down a participant port upon detecting such traffic patterns.
Participants must not allow CXC prefixes to propagate externally from their network and should minimize internal propagation as much as possible.
CXC was founded on the principle of open communication. Participants must be communicative with other participants and CXC Team in order to protect the exchange and all its participants. Unresponsive participants risk service suspension depending on the severity of a given issue. If a participant's time to respond to communication regarding an active issue impacting other participants or CXC resources exceeds the time-frames defined in the Connection Policy, the participant's port(s) may be suspended until communication is re-established.
