SEACOM Peering Policy

SEACOM is a global communications service provider, with emphasis on enabling connectivity solutions between Africa and the rest of the world. We operate a global IP/MPLS backbone as well as submarine cable systems between Africa, Europe and the Asia Pacific. Below is a summary of our overall peering policy: We operate a Selective peering policy. We support both public and private peering. We do not require a minimum amount of traffic to peer. We do not consider traffic ratios to peer. While not mandatory, we encourage peering in multiple, mutual locations. We do not require a contract to peer. We do not support contracts for public peering. We can support contracts for private peering if required by our peering partner. We do not peer with our IP Transit or Internet Access customers. We may not peer with networks that are customers of our customers. We announce only SEACOM routes, SEACOM customer routes and Pamoja Africa routes from our global network. We announce routes consistently across all peering sessions, barring any customer-induced traffic engineering implementations across our network. We do not provide any kind of global IP Transit or Internet Access across peering sessions. We do not provide access to SEACOM on-net CDN clusters across peering sessions. We, generally, do not peer with route servers. However, we may do so in specific cases. We exchange both IPv4 and IPv6 routes. We do not do prefix- or AS_PATH-based filtering for peer routes. We rely on "max-prefix" values for route control. However, for the comfort of our peers, we do not accept (or announce) private or reserved IP address space, we do not accept (or announce) private AS numbers, and we do not accept (or announce) IPv4 routes longer than a /24 or IPv6 routes longer than a /48. We encourage our peers to rely on "max-prefix" values for route control in order to reduce administrative overhead and speed up improvement in routing quality enabled by peering. However, we understand each network employs its own policy in this regard, and we shall respect it. We perform a strict and extensive combination of prefix-, AS_PATH-, and "max-prefix"-based filtering on all BGP sessions with our downstream customers. As such, our peers are guaranteed of good, clean routing when they peer with SEACOM. We filter (and drop) traffic sourced from or destined to any private or reserved IP address space, in either direction of the peering session. We request our peers not to point a default route toward SEACOM, even though doing so will not provide any benefit to the offending peer. We do not accept customer routes from peers. We do not perform uRPF on our peering routers, as these routers do not hold a full BGP table. We require that peering sessions be setup directly across the public peering LAN or private peering link. We do not support eBGP Multi-Hop peering sessions. For a list of exchange points and data centre facilities where you can peer with SEACOM, please visit our PeeringDB record.