Peering Policy

Overview

This policy outlines the requirements, procedures, and expectations for establishing and maintaining BGP peering with Gewape Cloud Group (AS203905). Peering requests that meet the criteria below will be considered. Requests that do not meet minimum standards will be declined.

Peering Philosophy

Gewape Cloud Group operates under the principle of "settlement-free" peering:

• We peer with networks of comparable traffic exchange
• No fees or settlements are exchanged for direct peering
• Peering is intended to be mutually beneficial for both parties
• Traffic ratios and asymmetry must remain reasonable over time

Autonomous Systems

Gewape Cloud Group operates the following ASNs:

• AS203905 – Primary network for Gewape Cloud Group backbone and services

Additional ASNs may be allocated for specific brands and services. Contact our network operations team for current routing information.

Peering Criteria

To establish peering with Gewape Cloud Group, your network should meet these basic criteria:

• Maintain a valid, unique Autonomous System Number (ASN) registered with RIR
• Operate a stable, production-grade network infrastructure
• Maintain proper routing security (RPKI) and ROA records
• Hold appropriate Internet Routing Registry (IRR) entries or WHOIS records
• Have redundant connectivity and redundant peering sessions where possible
• Agree to maintain this peering policy and standard operational practices
• Be reachable and responsive for network operations and troubleshooting

Technical Requirements

BGP Configuration

• BGP version 4 (RFC 4271)
• MD5 authentication on all sessions (optional but recommended)
• BFD (Bidirectional Forwarding Detection) for faster convergence
• Proper AS path filtering to prevent route hijacking
• Route filtering based on published prefix lists or RPKI validation

Routing Security

• All prefixes must be registered with their respective RIRs
• RPKI (Resource Public Key Infrastructure) validation is strongly encouraged
• Networks should publish ROAs (Route Origin Authorizations) for their address space
• IRR entries should be kept current and accurate

Physical Interconnection

• Peering can be established at Internet Exchange Points (IXPs) or private direct connections
• Current peering points include major regional IXPs in Africa, Asia Pacific, and the Americas
• Direct peering connections are welcome and should use modern cabling standards
• Both IPv4 and IPv6 peering is supported and encouraged

Peering Locations

Gewape Cloud Group offers peering opportunities at the following locations and exchange points:

• Africa: Kenya, Rwanda, Nigeria, South Africa (private interconnections at regional data centers)
• Asia Pacific: Singapore (major exchange and private direct connections)
• Americas: Brazil (established exchange points and direct connections)

For peering at specific locations or arrangements not listed, please contact our network operations team.

Prefix Requirements

• Minimum prefix length: /24 for IPv4, /64 for IPv6
• No bogon prefixes or reserved address space
• All advertised prefixes must be validated against RPKI or equivalent security
• Deaggregation beyond RIR allocations is not acceptable without prior approval
• Prefixes should be geographically relevant to the peering location when possible

Traffic Expectations

Peering relationships are maintained under the following traffic principles:

• Traffic should flow naturally between the networks with reasonable balance over time
• Sustained one-directional traffic imbalance (exceeding 2:1 ratio) may trigger review
• Networks engaging in transit-like behavior or systematic asymmetry may be asked to transition to paid interconnection
• Traffic prioritization, QoS, or artificial throttling is not permitted
• Peering sessions should be monitored and maintained to ensure optimal performance

Operational Policies

Maintenance and Notifications

• Planned maintenance should be scheduled with advance notice when possible
• Emergency maintenance or unplanned interventions should be communicated as soon as practicable
• Both parties should maintain NOC contacts and escalation procedures

DDoS and Abuse

• Peering sessions may be rate-limited or suspended in response to DDoS attacks originating from either network
• Networks must implement reasonable abuse response procedures
• Gewape Cloud Group reserves the right to filter or null-route traffic in response to active security threats

Session Management

• Peering sessions should be monitored continuously for health and performance
• Sessions with persistent issues or unresponsive operators may be disabled
• Regular testing and validation of route propagation is expected

How to Establish Peering

1. Verify your network qualifies – Review the peering criteria above to ensure your network meets our standards.
2. Submit a peering request – Contact our NOC at noc@gewapecloud.com with the following information:
   • Your ASN
   • Your network name and contact details
   • Preferred peering locations
   • IPv4 and IPv6 prefixes you plan to advertise
   • Technical contact information (preferably a NOC email)
3. Technical validation – Our team will review your RPKI/ROA status, IRR entries, and routing hygiene.
4. Configuration and testing – We will schedule a time to bring up the peering session and perform initial testing.
5. Ongoing monitoring – Once established, both teams should monitor the session and maintain regular communication.

Terms and Conditions

• This peering relationship is entered into by both parties on a voluntary, settlement-free basis
• Either party may terminate peering with reasonable notice (typically 30 days)
• Peering sessions are operated on an "as-is" basis without warranties or SLA commitments
• No party shall hold the other liable for network failures, data loss, or service interruptions
• This peering policy may be updated at any time; continued operation of a peering session implies acceptance of policy changes

Contact Information