This technical guide explains the Internet Exchange starting from the problem it solves: how independent networks exchange traffic directly, where this infrastructure is hosted, and how to connect an Autonomous System (AS) to it. The focus is on the Brazilian IX.br model, operated by NIC.br, without losing sight of the universal view of how IXPs work.
By the end, the reader will be able to assess whether it's worth participating, choose the location and the PIX, size the port, prepare routing and security, request membership, and put the connection into production.
About this material: content consolidated from official sources (IX.br, docs.ix.br, Registro.br, PeeringDB, and RFCs), consulted in September 2026. Locations, PIX, values, requirements, and policies change — always confirm the current version before contracting or configuring. This is educational material and does not replace contractual documentation or the executive project.
Why the IX exists
The Internet is not a single cloud: it is a federation of thousands of independent networks — providers, clouds, CDNs, companies, universities, banks, and governments. Each network decides how to reach the others. Without an exchange point, two networks in the same city might send traffic through a transit provider and travel a longer path than necessary.
The real reason
- Localizing traffic: keeping regional communication close to users and content.
- Reducing dependency: not concentrating all traffic on a single upstream.
- Improving performance: reducing hops, latency, jitter, and congestion points.
- Improving economics: shifting eligible traffic from paid transit to peering relationships.
- Increasing resilience: creating additional paths between networks and local ecosystems.
- Stimulating the ecosystem: bringing ISPs, content, clouds, government, finance, and education closer together.
It's not "free Internet": the IX only carries routes made available by participants. To reach the rest of the Internet, IP transit, private peering, or other interconnections are usually still required.
How the IX works
The core of an IX is a layer 2 Ethernet network — the fabric — distributed across physical points. Each participant connects a port and receives addresses from the peering LAN. Over this LAN, it establishes BGP sessions with Route Servers and/or bilateral peers.
| Plane | What happens |
|---|---|
| Control | BGP announces and selects prefixes. Route Servers facilitate route distribution without needing a session with each participant. |
| Data | Ethernet packets go directly from the source router to the peer's router. The Route Server is not in the traffic path. |
Simplified flow
- Your router announces the authorized prefixes to the Route Server.
- The Route Server validates and exports these routes according to policies and communities.
- Your router learns routes from other members and chooses the best paths.
- For a destination learned at the IX, the packet leaves through the IX port and reaches the peer's MAC directly.
- Routes not available at the IX continue to use IP transit or another path.
IX, PIX, CIX, transport, and transit
| Component | Function | Not to be confused with |
|---|---|---|
| IX | Exchange ecosystem and fabric at a location. | Data center or transit carrier. |
| PIX | Authorized physical point connected to the fabric. | The entire IX. |
| CIX | Shares an IX port among customers and delivers logical access. | Route Server. |
| L2 transport | Carries a transparent VLAN/EVC to an IX port. | IP transit. |
| IP transit | Delivers full table / default and global reach. | Peering. |
| PNI | Dedicated private interconnection between two networks. | Multilateral ATM. |
Golden rule: peering decides with whom to exchange traffic; transport decides how to reach the IX physically; transit decides how to reach the rest of the Internet.
Where IX.br is hosted
IX.br is organized by metropolitan locations. Each location may have several PIX, connected to the same exchange environment. PIX can be hosted in commercial data centers, carriers, universities, academic networks, public agencies, and other qualified institutions.
Being in the same data center as a PIX reduces last-mile complexity, but it is not mandatory — it is possible to contract L2 transport or a CIX. Official documentation consulted in 2026 identifies locations in almost every state, from Aracaju, Belém, and Belo Horizonte to São Paulo, Teresina, and Vitória, passing through Brasília, Campinas, Curitiba, Fortaleza, Manaus, Porto Alegre, Recife, Rio de Janeiro, and Salvador, among many others.
Distributed hosting example: in Brasília, the official list of PIX includes data center facilities, RNP, Telebras, Serpro, BR.Digital, SAMM, and Eletronet. Other locations have their own sets of PIX, and the fabric interconnects these points so that the location functions as a single exchange domain. The existence of a location does not mean that all content is present there — before contracting, check participants, traffic, peering policies, and routes actually available.
Bilateral and multilateral peering
| Model | How it works | Advantages | Considerations |
|---|---|---|---|
| Multilateral (ATM) | One or two sessions with Route Servers provide access to the routes of the participating members. | Scale, quick deployment, and broad connectivity. | Apply filters, communities, and track changes. |
| Public bilateral | Two networks create BGP sessions directly over the IX LAN. | Specific policy and independence from the RS. | More sessions and operational coordination. |
| Private PNI | Dedicated circuit / port between two networks. | Dedicated capacity and isolation. | Cost and dependency on bilateral volume. |
When to use each
- Start with ATM to quickly capture the value of the ecosystem.
- Add bilateral sessions when a peer's policy requires it or when there is operational benefit.
- Evaluate PNI when the volume with a single network justifies a dedicated port/circuit, or when there are special capacity and isolation requirements.
Peering policy: each AS should document whether its policy is open, selective, or restrictive; minimum volumes; locations; capacity; NOC contacts; congestion criteria; and announcement rules. An updated PeeringDB account facilitates discovery and validations within the ecosystem.
Route Servers and the real traffic path
The Route Server receives routes from many participants and redistributes them according to policy, preserving the originator's next-hop. This way, your router sends packets directly to the peer. RS1 and RS2 provide control plane redundancy, but they do not replace the physical redundancy of the access.
Modern IX.br features
- Origin validation using registration data, IRR, and RPKI.
- Prefix filters, bogons, AS-PATH, and protection against improper announcements.
- Communities to control export, prepend, location, RTT, and loss.
- Support for graceful shutdown for controlled maintenance.
- Remote blackhole for specific prefixes, according to the current policy.
- Mechanisms to mitigate hidden paths, including add-path when supported.
Attention: the communities policy evolves. In July 2026, IX.br published version 4.4 — always use the most recent official table before configuring traffic engineering.
Technical and administrative prerequisites
Administrative
- Be an organization eligible to participate and have an Autonomous System linked in the portal.
- Create a user account on Meu IX.br and link it to the ASN.
- Accept and sign the applicable membership instruments.
- Keep technical, administrative, financial, and NOC contacts up to date.
- Negotiate physical and commercial services separately with the PIX, transport provider, or CIX.
Technical
- Own ASN and adequately registered numbering resources.
- Router with eBGP, IPv4, and preferably IPv6, with filtering and community capabilities.
- Ethernet and optical interface compatible with the contracted port/PIX.
- Transparent layer 2 connection to the fabric, without NAT and without intermediate routing on the peering LAN.
- Consistent prefixes and routing objects; RPKI ROAs and updated IRR/PeeringDB data.
- MAC, ARP/ND, broadcast control, and protocols allowed according to technical policy.
- Capacity, redundancy, monitoring, security, and 24x7 operational staff compatible with the service.
| Item | Evidence before requesting |
|---|---|
| ASN and prefixes | Official registration, responsible contact, and valid authorizations. |
| Router | Model, version, interfaces, TCAM/FIB, BGP, and IPv6 tested. |
| Access | PIX/CIX, port, cross-connect, or EVC contracted. |
| Policy | Prefixes, max-prefix, communities, preference, and contingency defined. |
| Security | Filters, RPKI, IRR, CoPP, LAN ACL, and incident response. |
Connection methods
| Option | Best when | Risks / precautions |
|---|---|---|
| Direct port at the PIX | Your infrastructure is already on site or the volumes justify presence. | Cross-connect, optics, colocation, and physical redundancy. |
| L2 transport | You have a POP at another address and want to control your own port. | MTU, VLAN, L2 transparency, latency, and transport SLA. |
| CIX | Quick entry, lower initial capacity, or simplified operation. | Sharing, provider policies, limits, visibility, and future migration. |
| Redundant access | The IX is critical and there is significant volume. | Avoid false redundancy: shared routes, ducts, equipment, and power. |
Questions for the provider
- Is delivery a dedicated port, a VLAN on a shared port, or transport to another PIX?
- What is the capacity, MTU, SLA, latency, lead time, and upgrade policy?
- Is there real route, duct, POP, switch, and power diversity?
- Who provides optics, cross-connect, LOA/CFA, and incident support?
- Is there protection against loops, storms, excessive MAC addresses, and protocol leakage?
Network design and sizing
The port should not be sized based on the average alone. Consider peak, 95th percentile, growth, peak traffic hours, per-peer traffic, and margin for failures.
| Metric | Use in the design |
|---|---|
| Inbound/outbound peak | Defines the immediate risk of saturation. |
| 95th percentile | Characterizes sustained usage without reacting to microbursts. |
| Monthly growth | Anticipates upgrades and contracting lead time. |
| Top peers / prefixes | Shows concentration and bilateral/PNI opportunities. |
| Latency, jitter, and loss | Validates quality, not just volume. |
| Received routes and FIB | Confirms equipment capacity. |
Recommended operational rule: define internal expansion triggers before saturation. As an engineering reference — not an IX rule — many networks start the upgrade process when sustained usage reaches around 60% to 70%, adjusting for lead time and risk tolerance.
Proper redundancy
- Two independent routers or chassis.
- Two ports and, when feasible, distinct PIX within the same location.
- Transport over independent physical routes and providers.
- Separate power and optics.
- Sessions with RS1 and RS2, plus critical bilaterals.
- A policy that preserves the service during maintenance or partial failure.
Step-by-step membership process
| Step | What to do |
|---|---|
| 1. Define the objective | Transit reduction, latency, resilience, regional presence, IPv6, or access to specific content. |
| 2. Choose the location | Analyze participants, traffic, distance, available routes, and regional strategy. |
| 3. Choose the access | Select direct PIX, L2 transport, or CIX; validate capacity, SLA, MTU, and diversity. |
| 4. Prepare the AS | Update registration, PeeringDB, IRR, ROAs, contacts, policy, and prefixes. |
| 5. Request membership | Use Meu IX.br, link the ASN, select activation/migration/expansion, and follow the contractual flow. |
| 6. Complete the physical layer | Cross-connect, optics, VLAN/EVC, light tests, and Ethernet validation. |
| 7. Receive parameters | LAN addresses, VLAN, Route Servers, limits, and location guidelines. |
| 8. Configure with security | Interfaces, MTU, ACLs, max-prefix, filters, RPKI, BGP, and communities. |
| 9. Test and certify | Test ARP/ND, ping, BGP, routes, traffic, asymmetry, loss, and failover. |
| 10. Go into production | Activate gradually, monitor, and compare KPIs with the previous baseline. |
Reference BGP configuration
Conceptual model: addresses, Route Server ASNs, communities, and limits should be replaced with the values provided by IX.br and the current policy. Do not copy into production without validation.
The logical structure follows: Ethernet interface → peering VLAN (when applicable) → LAN IPv4/IPv6 → eBGP with RS1/RS2 → import/export filters → preference policy → monitoring.
Policy principles
- Export: announce only authorized own prefixes; attach engineering communities when necessary; deny everything else.
- Import: reject default, bogons, and IX LAN prefixes; reject RPKI invalid according to internal policy; enforce prefix-length and AS-PATH limits.
- Limits: define max-prefix per session (with warning or teardown according to policy) and alerts before the limit.
- Repetition: apply the same configuration to RS1 and RS2, for both IPv4 and IPv6.
| Route origin | Common preference | Note |
|---|---|---|
| Critical PNI | Highest | When there is an agreement and dedicated capacity. |
| Peering at the IX | High | Avoids transit, subject to quality and policy. |
| IP transit | Baseline | Maintains global reach and contingency. |
Security and best practices
Routing protection
- Create and maintain RPKI ROAs; handle invalid announcements deliberately.
- Maintain route/route6 objects and AS-SETs in the IRR when used.
- Export only authorized prefixes; never accidentally redistribute the full table.
- Define max-prefix per session and alerts before the limit.
- Use filters for bogons, martians, prefix lengths, and anomalous AS-PATH.
- Apply graceful shutdown during planned maintenance.
- Use BGP authentication when supported and agreed upon.
Peering LAN protection
- Allow only the protocols and sources necessary on the interface.
- Do not enable IGP, DHCP, improper RA, STP, or discovery protocols on the port.
- Apply CoPP/CPPr and ARP/ND limits according to the platform.
- Do not announce the IX LAN to the Internet.
- Avoid ARP/ND proxies and any unnecessary service on the interface.
- Monitor MAC flapping, broadcast, optical errors, and unexpected changes.
DDoS and blackhole: Remote Triggered Black Hole can discard traffic destined to an attacked host to protect the rest of the network. This is an extreme measure — validation, communities, and accepted prefixes should follow current documentation, and the team needs to test the procedure before a crisis.
Operations, monitoring, and troubleshooting
| Symptom | Check first | Common cause |
|---|---|---|
| BGP does not come up | Light, VLAN, IP, ASN, ACL, MTU, and reachability. | Incorrect VLAN, filter, or mismatched parameter. |
| BGP comes up without routes | Import policy, max-prefix, AFI/SAFI family. | Excessive filter or incomplete IPv4/IPv6 session. |
| Routes are not accepted | ROA, IRR, prefix, origin, and AS-PATH. | Outdated object or unauthorized announcement. |
| Traffic does not pass | ARP/ND, MAC, next-hop, ACL, MTU, and return path. | L2 problem or peer asymmetry/policy. |
| Loss at peak | Utilization, drops, buffers, optics, and transport. | Saturation or microburst. |
| High latency | Path, per-peer RTT, transport, and geography. | Remote participant transported to the location. |
Essential KPIs
- Session status and uptime; number of IPv4/IPv6 routes.
- Traffic by direction, peer, application, and percentile.
- Errors, drops, optical power, interface flap, and MAC.
- Latency, jitter, loss, and traceroute to representative destinations.
- RPKI/IRR, rejected announcements, and policy changes.
- Transit savings and customer-perceived quality.
NOC: maintain runbooks, escalation contacts, windows, responsibility matrix, and test evidence. At the IX, a problem may involve your network, the transport, the PIX, the fabric, or the peer.
Costs, benefits, and business case
| Possible costs | Measurable benefits |
|---|---|
| Port or location fee, when applicable | Gbps removed from paid IP transit |
| Cross-connect, colocation, patch panel, and optics | Reduced latency, jitter, loss, and hops |
| L2 transport or CIX service | Capacity to absorb local peaks |
| Routers, licenses, ports, power, and support | Better video, gaming, cloud, and application experience |
| Deployment, monitoring, and operations | Additional resilience and less upstream concentration |
| Physical redundancy and future upgrades | Possibility of strategic relationships with peers and CDNs |
Simple decision model: estimated monthly benefit = transit savings + performance value + availability value − total recurring IX cost. Payback is the initial investment divided by the net monthly benefit. Beyond the calculation, include the risks: upgrade lead time, transport failure, peer concentration, operations, and growth.
Decision: an IX is attractive when there is significant traffic with participants present, an efficient physical path, and BGP maturity. Raw volume alone does not guarantee a return.
Scenarios and topologies
Scenario A — regional provider
The ISP maintains two IP transits and adds the IX through a 10 Gb/s CIX. It starts with ATM, measures the top peers, and, as it grows, migrates to a dedicated port and redundant transport. Two eBGP routers at the edge, two transit upstreams, and a policy that prefers peering when quality and capacity are adequate.
Scenario B — company with its own ASN
An institution with public digital services participates to reduce latency to ISPs and clouds. It maintains transit for global reach, announces only authorized services, and reinforces DDoS, RPKI, and observability.
Scenario C — CDN or SaaS platform
The network brings content closer to eyeball networks across multiple locations. It uses ATM for coverage, bilaterals for specific policies, and PNI when bilateral volume justifies it. Planning considers cache capacity, backhaul, and return.
Scenario D — high-availability architecture
Two routers, two ports, two PIX, and transport over independent routes. RS1/RS2 sessions and critical bilaterals. Scheduled tests prove that redundancy actually exists.
Readiness checklist
- Objective and success indicators defined.
- ASN, prefixes, and official contacts up to date.
- ROAs, IRR/AS-SET, and PeeringDB reviewed.
- Location chosen after analysis of participants and traffic.
- PIX, transport, or CIX contracted with a known SLA.
- Router, interfaces, optics, MTU, and capacity validated.
- IPv4 and IPv6 policies approved.
- Filters, max-prefix, CoPP, and communities reviewed.
- RS1/RS2 sessions and bilaterals planned.
- Monitoring, NOC, runbook, and escalation ready.
- Failure test, rollback, and acceptance criteria documented.
- Upgrade triggers and quarterly review defined.
Final questions for the decision-maker
- Which destinations represent most of our traffic?
- Are these networks present at the chosen location and do they accept peering?
- How much does it cost to bring redundant capacity to the PIX?
- What portion of transit can actually migrate?
- Is the quality gain measurable for customers?
- Can the team operate BGP, security, and incidents 24x7?
Essential glossary
| Acronym | Definition |
|---|---|
| AS / ASN | Autonomous System / identifying number in BGP. |
| BGP | Routing protocol between Autonomous Systems. |
| CDN | Content delivery network. |
| CIX | IX.br shared-port provider. |
| EVC | Ethernet virtual circuit used in L2 transport. |
| FIB | Forwarding table installed in hardware. |
| IRR | Routing policy and object registry. |
| IX / IXP | Traffic exchange point between networks. |
| Peering LAN | Ethernet segment over which participants form BGP. |
| PNI | Private interconnection between two networks. |
| PIX | Physical access point to IX.br. |
| RPKI / ROA | Cryptographic validation of prefix origin authorization. |
| Route Server | Server that redistributes BGP routes without carrying the packets. |
| IP transit | Global Internet reach service. |
Official references and further reading
Sources consulted in September 2026. Since locations, PIX, values, requirements, and policies change, always confirm the current version before contracting or configuring.
- IX.br — portal, locations, participants, topologies, and statistics: ix.br
- IX.br documentation: docs.ix.br
- Membership by location and dynamic list of PIX/CIX: docs.ix.br/adesao
- Meu IX.br — requests and participation management: meu.ix.br
- IX.br Technical Requirements Policy — official document
- BGP Communities and Route Servers Policy v4.4 (07/21/2026) — official document
- Registro.br — Numbering and Autonomous System Resources: registro.br/tecnologia/numeracao
- PeeringDB — public presence and peering policy data: peeringdb.com
- RFC 4271 — Border Gateway Protocol 4: rfc-editor.org/rfc/rfc4271
- RFC 7947 / 7948 — operation and use of Route Servers at IXPs
Editorial note
This material is educational and does not replace contractual documentation, current technical policy, the executive project, or validation by IX.br, PIX, CIX, and the providers involved. Connecting networks directly means reducing technical, economic, and operational distance.
EnQ Digital: Cloud • Data Center • Baremetal • Storage • Connectivity • Support