Network Features

Currently BGP sessions for Layer 3 management networks are limited to the primary / first IP of the network. If a user deploys a server with a larger subnet size such as /29 it's not possible to have BGP sessions from the other IPs inside the same subnet. It has to be the first available host IP. This is useful for certain situations such as deploying a virtual network functions appliance or Google Anthos Layer 3 bundled load balancers with BGP.

The Equinix Metal platform knows which ToR switch ports are owned by which customers. When the Equinix Metal network sees or creates an event for a customers ports, that event should be surfaced in the EM customer portal or Equinix Observeability stack Examples of these would be: Shutting ports because of LACP Shutting ports because of duplicate MACs Flapping events BGP Shut / Open This would help customers become self sufficient on the platform as well as reduce the "confirmation" "go to NetOps and ask" burden on the support and operations teams. Initial idea would be to centralize and aggregate switch log data, and then summarize that with a simple ETL the runs every 5 minutes or so.

Customers have asked for support BGP in a similar matter on regular Metal Gateway instances (not in a VRF) as those within a VRF. The proposal would be to copy the existing BGP support available in the default VRF and extend it to working behind a Metal Gateway with a listen range. This would ideally allow customers to announce Elastic IPs or their own IPs to the Metal Network over a VLAN similar to how L3/Hybrid instances work today.

Some use cases require dozens or even hundreds of VLANs. Currently, projects are limited to 5 VLANs , with no formal path for buying or unlocking more (support can increase the limit modestly). Provide a service tier or a way for users to safely deploy and manage up to ~100 and then up to max (~4k) VLANs.

Provide a VLAN to connect from one project to another within Metal over a VLAN dedicated to the purpose, to share a resource (such as Pure storage) with multiple projects.

Users should be able to create custom Firewall rules to regulate traffic to and from their backend infrastructure. Firewall rules would help define trusted IP addresses, ports, and protocols.

BGP neighbor support allows dynamic updates of BGP peers from a CIDR range instead of a single IP address. The ask here is to add an endpoint to metal gateway that allows the customer to specify a BGP range peering can be formed from.

Adding a DHCP Relay feature to Metal VRF would allow customers to extend existing DHCP and Dynamic DNS Services running in Fabric Connected deployments to their workloads on Metal.