Technical Requirements

These Technical Requirements (TR) define how CNX services may be used and what configurations are prohibited. This document will be regularly reviewed and revised in the light of operational experience to ensure maximum protection of service to CNX members.

last update June 2025

Physical Configuration

1. No media converters are allowed, all connections must terminate to a transceiver module (SFP/SFP+/QSFP28) on a CNX switch.
2. The connection should be a direct dark fiber connection from the CNX member`s router (or L3 switch) to the CNX switch, with no devices in between such as media converters or L2 switches.

Allowed Optical Interfaces for Connections

1. Fiber Type: Only single-mode optical fiber (SMF) compliant with ITU-T G.652 standards is permitted for physical layer connections.
2. Optical Transceiver Compatibility:
• The IXP supports connections exclusively using fiber transceiver (SFP/SFP+/QSFP28).
• Transceivers must operate on wavelengths compatible with the 1310 nm or 1550 nm spectrum, as per IEEE 802.3 specifications for Ethernet interfaces.
3. Physical Interface Requirements:
• All connections must terminate using LC connectors for duplex operation.
• Fiber patch cords must be of sufficient quality to meet or exceed insertion loss and return loss requirements for the respective speeds (1GE, 10GE, 100GE).
4. Prohibited Media:
• Multimode fiber (MMF) and any other optical interfaces not meeting the above specifications are not allowed.
• Copper-based Ethernet or any non-optical media is not supported.

MAC Layer

1. Only specified ethertypes are allowed on the CNX VLANs. The policy is enforced with a VACL configured on the CNX switches.
2. The following ethertypes are allowed:
   • 0x0800: IPv4
   • 0x0806: ARP
   • 0x86dd: IPv6
   • 0x8809: LACP
3. Frames with any other ethertypes are dropped on CNX switch ingress.
4. All frames of a service forwarded from an individual CNX port shall have the same source MAC address.
5. All MAC addresses received on a CNX port must belong to a single participant. CNX does not permit ports to be shared between multiple customers or networks.
6. On the public peering network (VLAN 500) only 1 MAC address is permitted per port. CNX actively enforces this limit; violation may result in port shutdown.

Link Aggregation

1. CNX supports link aggregation using LACP (IEEE 802.3ad) in active mode.
2. Link aggregation may be requested for a single port to allow future expansion.
3. LAG interfaces are configured with L3+L4 hashing (source and destination IP and port).
4. All member links must operate at the same speed and duplex and terminate in the same site.

IP Layer

1. Interfaces connected to public CNX peering ports shall only use IP addresses and netmasks (prefix lengths) assigned to them by CNX. In particular:
   • IPv6 addresses (both link-local and global scope) must be explicitly configured. SLAAC and DHCPv6 auto-configuration must be disabled.
   • IPv6 site-local addresses shall not be used
   • IPv6 router advertisements shall be disabled

MTU Requirements

1. The standard MTU for all CNX public VLAN interfaces is 1500 bytes. Jumbo frames are not supported on the public peering network.
2. Custom MTU settings may be negotiated on private interconnects (PNIs) only.

Routing

1. All exchange of routes across the open CNX peering network shall be via BGP4(+).
2. AS numbers used in BGP4(+) sessions across the CNX peering network shall not be from range reserved for private use.
3. IP address space assigned to CNX peering LAN shall not be advertised to other networks.

Route Server (RS)

1. All peers in the public peering network must maintain a peering session with our route server.
2. BGP announcements from your ASN will only be accepted if all downstream ASNs are properly registered and referenced in a AS-SET object
3. All routes to be advertised in a peering session across CNX shall be registered in the APNIC or other public routing registry.
4. RPKI invalid routes will be dropped according to our prefix filtering.
5. All routes must have Route Origin Authorization (ROA) setup for the route to be propagated.
6. All routes advertised shall be aggregated as far as possible, including across non-advertised address space.
7. Additional information about our RS polices can be found at route server policy.

Forwarding

1. Traffic shall only be forwarded to a CNX member when permission has been given by the receiving member either:
   • by advertising a route across the CNX network (directly or via the routeserver)
   • by explicit agreement between members.
2. Traffic shall not be routinely exchanged on the public peering network between two CNX ports owned by the same CNX member. For traffic between ports owned by the same member, a free virtual PNI (vPNI) can be provisioned upon request. Public VLAN use for intra-member traffic is not permitted.

VLAN Provisioning and Usage

1. CNX supports 802.1Q trunk ports for carrying multiple tagged VLANs. VLANs must be explicitly assigned and provisioned by CNX.
2. All VLANs are provisioned and assigned by CNX. Participants may not use unassigned or duplicate VLAN IDs on any CNX port.
3. Each VLAN is mapped to a single service and must not be reused across unrelated services or participants.
4. CNX supports the setup of closed user groups (CUGs), where multiple ports may share the same VLAN for private interconnection (e.g., PNIs or transport extensions).
5. CNX maps VLANs to bridge domains (BDs), which are in turn mapped to VXLAN VNIs. VLAN IDs used by different participants for the same service (e.g., in a closed user group) do not need to match. CNX will assign locally available VLANs per port and map them to a common BD/VNI as required.
6. CNX does not allow multiple participants to share access to the public peering service via a common physical port. Each public peering participant must connect to CNX using a dedicated port assigned to their ASN and network identity.
7. The public peering VLAN is not multiplexed. Only one instance of the public peering VLAN may be configured per port, and only one MAC address is permitted within that service per port.
8. Participants must not bridge, extend, or forward traffic from the public peering VLAN beyond the directly connected system.

Revision History

CNX configuration

global mac access list

mac access-list extended ix-protocols
 permit any any 0x800 0x0
 permit any any 0x806 0x0
 permit any any 0x86DD 0x0
 permit any any 0x8809 0x0

per port configuration

mac access-group ix-protocols in

default switchport configuration; if some configuration is missing, your port may not work or may be blocked

interface GigabitEthernet1/0/1
 switchport nonegotiate
 no lldp transmit
 no lldp receive
 no cdp enable
 no keepalive
 spanning-tree portfast trunk
 spanning-tree bpdufilter enable
 spanning-tree bpduguard enable
 no shutdown