Border Gateway Protocol Video
Tip: BGP peering can be established using Network Edge APIs. For more information, see Network Edge API – BGP and Network Edge API – Establish BGP Peering.
The settings specified in each BGP instance is pushed to the device as a configuration change to the interface associated with the connection.
The BGP service has the following attributes:
|
Values |
Data Requirements |
Notes |
|
|---|---|---|---|
|
Configure before launch |
No |
Can only be done after the connection is in provisioned state. |
|
|
Configure at launch |
No |
Can only be done after the connection is in provisioned state. |
|
|
Configure during lifecycle |
Yes |
Found on connection details once the connection has been provisioned. |
|
|
Optional or Required |
Optional |
Connections might not operate properly if some information is not entered here, but the system won’t force you to enter BGP information. Users can also enter manually on device directly. Some devices restrict or prevent BGP entry because it should be entered on the orchestration, GUI or software of the vendor. |
|
|
Local ASN |
Required |
Must be in numeric format and can be 2- or 4-byte, public or private. |
Local refers to the virtual device or the customer side equipment or images. Some restricted or pre-reserved AS' applies. |
|
Local IP Address |
Required |
Must be IPv4 address; can be public or private and must be part of same subnet as the local IP address; |
Expressed in CIDR format so that the subnet can be matched with a remote IP address. |
|
Remote ASN |
Required |
Must be in numeric format and can be 2- or 4-byte, public or private. |
Remote refers to the cloud, network, or other Z-end location that the user connects their device to. |
|
Remote IP Address |
Required |
Must be IPv4 address; can be public or private and must be part of same subnet as the remote IP address; |
Expressed in CIDR format so that the subnet can be matched with a local IP address. |
|
BGP Authentication Key |
Optional |
Can only be letters or numerals. Must not begin with a number. |
Some limits are based on single vendor differences. If the user needs to enter BGP auth key outside of these rules and device supports the format, it can be done manually through CLI. |
|
Connection |
UUID; Required |
Alphanumeric |
On the portal, the connection UUID is assumed based on the currently active connection that user is viewing. |
|
Provisioning Status |
NA |
Could include: Provisioning, Deprovisioning, Provisioned or Deprovisioned. |
Not user-defined; indicates whether the configuration has been pushed or pulled successfully from the device following a user request to add, edit or delete it. |
|
BGP State |
N/A |
Could include: Idle, Connect, Active, Open/Sent, Open/Confirm or Established. |
Not user-defined; follows BGP industry standards; BGP is peering successfully when it's in an established state. |
|
How many per connection? |
1 |
N/A |
|
|
Delete fully? |
No |
|
Once created, the BGP settings can only be deleted completely by deleting the associated connection. |
|
Required same on secondary? |
No |
When a BGP service is added to an Equinix Fabric Layer 2 connection, your device can peer with the equivalent settings on the other side of that connection, just as you would set up a physical router to do the same. A typical setup with a connection from your device to a public cloud provider might look something like this:
Unless the user specifically requests or configures a custom setup, all connections to the Equinix Fabric traverse a single VRF from multiple virtual interfaces.
See Platform Architecture for more information about the typical set up and architecture.
These various connections can then peer with each other or with sessions on other interfaces (such as toward the public internet or a VPN tunnel).
Unless specifically limited in certain cases, all BGP settings share these common attributes:
- Any allowed ASN can be appended to either public or private IPv4 address space
- Equinix does not restrict ASN and IP combinations, but third parties and providers can
The BGP service goes through a series of states that conform to the standards defined by RFC 4271, but might have some vendor-specific nuance. This state transition is different from the state of the overall device and should not be confused with a broader failure.
Although the BGP session can cycle through all seven standard stages, the most notable BGP states are:
- Idle – The connection is not actively peering
- Established – The connection is peering and route tables are being updated
- Failed – The attempt to peer or find the ASN has failed and should be deleted or tried again
Consult with your vendor guidance or common BGP tutorials for more detail and state possibilities if you see one not mentioned here.
Some devices do not support multi-ASN as specified in RFC 7705. If this is the case, you should not enter more than one ASN for across all connections you create to your device. If you do, the previous ones are overwritten immediately on all other connections. Where possible, the system warns you and prevents you from doing so, but always be sure you consult with your vendor and device guidance and specifications.
When a user adds a connection to a redundant pair, the system enforces two connections but does not force BGP settings be added to both at the same time. Users need to be aware that they must configure each connection separately. While traffic flows over one or the other if both are not configured, the solution won’t be complete and other systems or cloud environments might malfunction or alarm until both sessions are established.
In a redundant scenario, users can also perform customizations in the CLI. The BGP service does not support it from the portal or API, but an example would be BGP communities used to favor one route over another. Consult with your vendor guidance for how to do this and the tradeoffs associated. Equinix can't guarantee the flow of traffic when customizations are made in the device directly.