This is an open-source, turnkey network architecture designed for deploying Internet Exchange Points (IXPs) in the Pacific Islands and similar emerging markets.
Designed for resource-constrained environments with high latency and limited local technical expertise, this reference design provides a modern, scalable, and secure foundation for local traffic exchange. It moves away from legacy Layer 2 spanning-tree designs to a robust EVPN/VXLAN fabric, ensuring stability across geographic distances (e.g., interconnecting islands).
- Network Operators in the Pacific (Samoa, Fiji, Tonga, Vanuatu, etc.).
- Grant Funders (ISOC, APNIC) looking for standardized deployment models.
- Emerging IXPs globally seeking a "best-practice" template.
This design utilizes a Collapsed Core topology with an EVPN/VXLAN control plane. This allows the exchange fabric to stretch across multiple physical sites (data centers or islands) without the risks associated with Spanning Tree Protocol (STP).
- Hardware Agnostic: Reference configurations provided for Arista EOS and Juniper QFX, with the architecture designed to be vendor-neutral.
- Dual-Stack: Native IPv4 and IPv6 peering support from day one.
- MANRS Compliant: Built-in security (RPKI, IRR filtering, Anti-spoofing).
- Automated: Integrated with IXP Manager for provisioning and member portals.
- Resilient: Active-Active Route Servers and redundant switching fabric.
graph TD
subgraph "IXP Site A (e.g., Apia)"
SW1[Switch A1] --- SW2[Switch A2]
RS1[Route Server 1] --- SW1
RS2[Route Server 2] --- SW2
end
subgraph "IXP Site B (e.g., Suva)"
SW3[Switch B1] --- SW4[Switch B2]
end
SW1 -.-|EVPN/VXLAN Tunnel| SW3
SW2 -.-|EVPN/VXLAN Tunnel| SW4
Member_ISP --> SW1
Member_Gov --> SW2
The repository is organized to guide you from planning to operations.
pacixp/
βββ TODO.md # Open work items
βββ configs/
β βββ switches/
β βββ arista_sw1.md # Arista EOS reference configuration
β βββ juniper_sw1.md # Juniper QFX reference configuration
βββ docs/
β βββ 00-design-principles.md # Governing principles β read before making changes
β βββ 01-high-level-design.md # Architecture, topology, and addressing plan
β βββ 03-security-hardening.md # MANRS compliance and hardening checklist
β βββ 05-ixp-manager.md # IXP Manager Docker deployment guide
βββ labs/
β βββ README.md # Lab setup instructions
β βββ pacixp.clabs.yml # Containerlab topology definition
β βββ configs/ # Lab switch, route server, and member configs
βββ runbooks/
β βββ ixp-manager-arista-switch.md # Integrating an Arista switch with IXP Manager
βββ strategy/
β βββ automation.md # Automation philosophy and scope
β βββ onboarding.md # Member onboarding workflow and training
β βββ virtualization.md # VM/container infrastructure strategy
βββ templates/
βββ ixp-manager-docker-compose.yml # Docker Compose for IXP Manager
- Read the Design Principles β these govern every architectural decision in this repo.
- Review the High Level Design to understand the topology and addressing plan.
- Contact APNIC (or your local NIR) to obtain a public ASN, IPv4 /24, and IPv6 /48 before any hardware is ordered. See DP-12 in the design principles for the full list of required allocations.
- Rack & Power: Install switches and servers according to the site plan.
- Switch Config: Navigate to
configs/switches/, select your vendor, and apply thebase-config.- Note: Update the
VTEP IPsandRouter IDsper the addressing plan.
- Note: Update the
- IXP Manager: Deploy the management platform using the Docker Guide.
- Route Servers: Install BIRD 2.x. Use
labs/configs/rs1.cfgas the starting-point template and adapt filters per the Security Hardening Guide.
- Follow the Member Onboarding Guide to connect your first peer.
- Verify security using the Hardening Checklist.
This design is strictly aligned with MANRS (Mutually Agreed Norms for Routing Security) for IXPs.
| Feature | Implementation |
|---|---|
| Action 1: Prevent Propagation of Incorrect Routing | Route Servers configured with RPKI (Routinator) and IRR filtering. |
| Action 2: Prevent Traffic with Spoofed Source IP | Strict uRPF and ACLs on switch ports; No Proxy-ARP. |
| Action 3: Protect the Peering Platform | BPDU Guard, Storm Control, IPv6 RA Guard, Port Security. |
| Action 4: Facilitate Global Communication | Standard contact info published in PeeringDB (via IXP Manager). |
| Action 5: Provide Monitoring and Debugging | Looking Glass and public traffic statistics enabled. |
We welcome contributions from network engineers globally!
- Fork the repository.
- Create a feature branch (e.g.,
feature/cisco-nexus-configs). - Submit a Pull Request detailing the changes.
Please ensure all network configurations are validated against a virtual lab (e.g., GNS3, EVE-NG, or Containerlab) before submission.
This project is licensed under the CC BY-NC-SA 4.0 (Creative Commons Attribution-NonCommercial-ShareAlike) license.
We believe in the open Internet. If you are a non-profit, cooperative, or community-governed IXP (even if you charge standard port fees to cover costs), you are free to use, modify, and deploy this architecture without restriction. We only ask that you credit the PacIXP project.
Commercial use requires a separate paid license. Any use by commercial entities β including for-profit data centers, commercial carriers, or paid consultants using this design to deliver client projects β is not permitted under the CC BY-NC-SA license and requires a commercial license from IEISI, for which a substantial fee applies.
Contact tcs@ieisi.org for commercial licensing terms and paid support options.
Acknowledgments:
- Based on best practices from Euro-IX and APNIC.
- Inspired by the open-source community behind IXP Manager and BIRD.
- Dedicated to the network operators connecting the Blue Pacific.