Configuring Direct Link on Classic

Basic network configuration

1. Define your remote network that uses the standard RFC1918 private address space.

   • For new environments, the 10.0.0.0/8 space.
   • For existing environments that use 10.0.0.0/8, we recommend that you obtain a more detailed assessment to ensure that there is not a conflict with the IBM Cloud services network, or with the networks that are already assigned to your account.

2. Our staff at IBM Cloud assigns a /31 or /30 for each connection and configures an interface IP address on the IBM Cloud cross-connect router (XCR) infrastructure.

3. Configure the interface on your customer edge router (CER) by using the IP address provided: use the IBM Cloud XCR IP as a next-hop for any traffic that is destined to IBM Cloud.

4. For return traffic, IBM Cloud uses the assigned CER IP as a next-hop for any traffic destined for the remote network, as advertised via BGP.

Configuring BGP

To exchange route information with your environment, IBM Cloud requires BGP to be configured. Options are as follows:

• ASN: IBM Cloud assigns a private ASN for each customer's use. Alternatively, you can use your own public ASN. Your preference is requested at the time you place your order. Your assigned private ASN is provided to you during the implementation process.

• VRF: Using VRF, IBM Cloud advertises the specific private subnets that are assigned to your customer account. You must advertise the remote networks that you want to be reachable from the IBM Cloud private network. It is your responsibility as a customer to manage the advertisements to and from the IBM Cloud network. (More details about VRF are included in the next section.)

  The following networks are filtered out and cannot be accepted: 10.0.0.0/14, 10.198.0.0/15, 10.200.0.0/14, 169.254.0.0/16, 224.0.0.0/4.

• ECMP: For customers who elect to build redundancy at a supported location, IBM Cloud supports the implementation of equal-cost multipath (ECMP) to provide load balancing and redundancy across the two links. This ECMP setup should be requested at the time of order.

BGP specifications for IBM Cloud Direct Link

The BGP specifications are as follows:

As stated in the preceding section, BGP is mandatory for managing your routing through Direct Link. An account that orders Direct Link is migrated to a VRF environment.

Caveats for VLANS and VRF:

• Inter-account VLAN spanning isn't allowed in the VRF environment.
• IPsec VPN service is limited.

VRF doesn't prevent SSL VPN access, but the behavior changes. Without VRF, one VPN connection is enough to see all servers on your account. With VRF, you can access resources only in the market that is associated with your VPN. So if you connect to the DAL VPN, you can connect to DAL servers only.

IBM Cloud ASN is 13884, for public and private services.

• The default ASN for a customer when ordering is 64999, but the default can be changed by customer request.
• Optionally, a 4-byte private ASN 4201000000 - 4201064511 can be supported.
• If you're using Direct Link Connect with a layer-3 service, such as IP VPN, IBM Cloud establishes BGP with the Direct Link Connect provider's ASN.

Recommendations, Defaults, and Limits:

• Tunneling (that is, GRE) is supported and recommended if IP overlap becomes an issue.
• BGP timer defaults are Keepalive:30, Holdtime:90.
• Authentication is not enabled by default.
• BGP BFD is not enabled by default.
• Maximum received (from customer or provider) prefix limit is 200 per VRF.

Strict limitations on IP assignments

• If you use the 10.x.x.x network, you still cannot create overlap with your hosts within IBM Cloud nor with the IBM Cloud services network, which occupies 10.0.0.0/14, 10.198.0.0/15, and 10.200.0.0/14.

• The following ranges are not allowed in the Federal system and they are rejected by IBM servers: 169.254.0.0/16, 224.0.0.0/4.

Redundancy and diversity

IBM Cloud Direct Link provides diversity, and customers are responsible for implementing redundancy through their BGP schemas.

If you select ECMP for redundancy, both BGP sessions must exist on the same XCR; therefore, you give up router diversity and are exposed to risk if the router fails. You gain Layer-3 redundancy, but you lose router diversity.

More about using VRF

All accounts that use an IBM Cloud Direct Link solution must migrate to a VRF. By using VRF, customers advertise the available routes to their self-defined remote networks. This configuration does not permit you to use self-defined IP addresses on the IBM Cloud network.

Migrating to a VRF is done during the setup process. It requires a short outage window (up to 30 minutes for large accounts with multiple VLANs/locations), during which the backend network VLANs lose mutual connectivity while they are moved to the VRF. The VRF migration is scheduled with the implementing engineer.

VRF eliminates the "VLAN Spanning" option for your account, including any account-to-account VLAN spanning capabilities, because all VLANs are able to communicate unless a gateway appliance is introduced to manage traffic. VRF also limits the ability to use IBM Cloud VPN services because it is not compatible with IBM Cloud SSL and IPsec VPN services.

An alternative is to use the IBM Cloud Direct Link offering itself to manage your servers, or to run your own VPN solution (such as a Vyatta) that can be configured with different types of VPN. After migrating to a VRF, SSL VPN typically works when a VPN connection is made to the same data center location in which a compute VM is running, but it does not allow access globally.

Using BYOIP and NAT with Direct Link

IBM Cloud Direct Link does not offer BYOIP on the private network. Therefore, traffic with a destination IP address that was not assigned by IBM Cloud is dropped. However, customers can encapsulate traffic between the remote network and their IBM Cloud network that uses GRE, IPsec, or VLAN.

Most commonly, the BYOIP environment is implemented within the scope of either a Network Gateway (Vyatta) or a VMWare NSX deployment. This configuration enables customers to use any desirable IP space on the IBM Cloud side, and to route back across the tunnel to the remote network. This configuration must be managed and supported by the customer, independent of IBM Cloud. Furthermore, this configuration can break connectivity to the IBM Cloud services network if the customer assigns a 10.x.x.x block that IBM Cloud has in use for services.

This solution also requires that each host that needs connectivity to the IBM Cloud services network and the remote network must have two IP addresses assigned: one from the IBM 10.x.x.x block, and one from the remote network block. Static routes must be set up on the host to ensure that traffic is routed. You cannot assign IP space directly on the IBM Cloud hosts (BYOIP) and have it routable on the IBM Cloud network inherently. The only way to implement this ability is as outlined previously, but it is not supported by IBM Cloud.

Alternatively, customers frequently assign a remote network block for use in a NAT table that is configured on their remote edge router. This configuration allows customers to limit the changes that are required to both networks, while still translating traffic into a network address space that is compatible with both networks.