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 May 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. 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.
  4. All routes to be advertised in a peering session across CNX shall be registered in the APNIC or other public routing registry.

Route Server (RS)

  1. All peers in the public peering network must maintain a peering session with our route server.
  2. RPKI invalid routes will be dropped.
  3. All routes must have Route Origin Authorization (ROA) setup for the route to be propagated.
  4. All routes advertised shall be aggregated as far as possible, including across non-advertised address space.
  5. 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.

Revision History

DateChanges
May 2025Added Link Aggregation section and MTU policy; clarified MAC enforcement and vPNI policy.
Dec 2024Updated Physical Configuration section to clarify support and requirements for 100GE interfaces.
Before 2024Multiple updates based on operational experience since initial publication in 2010.

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