Permitted traffic
Only these Ethernet frame types may be sent to the peering LAN: IPv4 (0x0800), IPv6 (0x86DD) and ARP (0x0806). IPv4 and IPv6 traffic must be unicast between the peering addresses assigned by Maharlika IX, or between a member and the route servers. ICMP and ICMPv6 needed for normal operation (echo, unreachable, packet too big, neighbour discovery) are permitted. The MTU of the peering LAN is 1500 bytes; jumbo frames are not supported. The peering LAN is delivered untagged on the member port.
Not permitted
Interior routing and discovery protocols: OSPF, IS-IS, EIGRP, RIP, PIM, IGMP, VRRP, HSRP, CDP, LLDP and spanning-tree BPDUs. Tunnelling across the fabric: GRE, IP-in-IP, L2TP, VXLAN, Geneve, WireGuard, IPsec ESP and AH. DHCP and DHCPv6 servers, IPv6 router advertisements, proxy ARP, ICMP redirects, SNMP, and any traffic sourced from private, reserved, documentation or other special-purpose address space. Directed broadcasts and non-ARP broadcast or multicast floods are not allowed. The multicast that IPv6 neighbour discovery needs is permitted. Link-local protocols not required for BGP peering must be disabled on the member’s peering interface.
One MAC address per port
Each member port is allowed a single source MAC address, the address of the member’s peering router. Frames from additional addresses are dropped at the port. A port that also carries a private VLAN is set up for the addresses that the service needs. The NOC does this with you. A member that needs a second address, for example during a router replacement, contacts the NOC in advance. Members must not bridge the peering VLAN into their own network or extend it to third parties.
How it is enforced
Every member-facing port carries a port filter that drops the protocols above and privately sourced traffic, a MAC address limit in protect mode, broadcast and multicast storm control, and BPDU guard that disables the port if spanning-tree frames arrive. The peering VLAN is isolated from all management and transport VLANs of the exchange. The route servers check every announcement against RPKI and, where a member has an IRR filter, against its registered prefixes, so a misconfigured router cannot put arbitrary routes onto the exchange.
Monitoring and violations
Port counters, storm-control and filter logs are monitored by the NOC. When a port violates this policy the member is contacted with the evidence and asked to correct the configuration. A port that threatens the stability of the fabric, for example a bridging loop or continuous flood, may be disabled immediately and re-enabled once the cause is fixed.
