BGP routing

[srimal99]

Hello Experts,

Hello Team,

Currently, we have two cloud environments (AWS and GCP) connected to our COLO endpoint devices through two transit hubs, with ECMP enabled across the paths.

Existing Design

• The network is presently operating in an Active/Active mode across both transit hubs.
• There is now a requirement to transition this setup to an Active/Standby model.

Transit Hub Architecture

Transit Hub 1 (TR-HUB1)

• Devices: Nexus 9K (SW1 & SW2) configured as vPC peers
• Protocol: iBGP
• VRFs:
• AWS VRF
• GCP VRF
• Endpoint VRF
• BGP is used as the  protocol
• Separate source VLANs are used per switch:
• VLAN 101 → TR-HUB1-SW1
• VLAN 102 → TR-HUB1-SW2

Transit Hub 2 (TR-HUB2)

• Devices: Arista switches (SW1 & SW2)
• MLAG: Not configured
•  Protocol: iBGP
• VRFs:
• AWS VRF
• GCP VRF
• Endpoint VRF

Endpoint Connectivity

• COLO endpoint devices are connected to both transit hubs.
• For future scalability and growth, additional “blue links” are planned between the transit hubs and the endpoint devices to increase capacity and resiliency.

Requirement

We need the ability to control traffic originating from the cloud (for example, AWS) such that:

• Traffic can be shifted to TR-HUB1  or TR-HUB2 when required (maintenance, failure, or operational needs)
• The design should remain scalable and compatible with the planned blue-link expansion

Questions

1. Can this traffic preference be achieved using BGP attributes on the transit hub routers?
2. Is it necessary to reconfigure any VLAN with HSRP, or can the requirement be met purely through BGP-based traffic engineering, even with the future blue links in place?

[Cristian Matei]

Hi,

    In network design, the more you can achieve with less configuration, without bloating it, the better the sign, it's called the KISS principle. So, given that you have iBGP, I recommend using Local Preference to ensure the following:

1. Choose which is your primary path, secondary path, etc

2. Ensure left-to-right an right-to-left, traffic is symmetric, aka follows same preferred path that you choose

Thanks,

Cristian.

[srimal99]

BGP is configured across the WAN and iBGP between internal routers. There is no Layer 2 redundancy mechanism (for example, HSRP) configured between the Nexus vPC peers.

The topology is as follows:

• Cloud ↔ eBGP ↔ Transit Hub 1 / Transit Hub 2

• Transit Hub Switch 1 ↔ iBGP ↔ Transit Hub Switch 2

• Transit Hub 1 / Transit Hub 2 ↔ eBGP ↔ Endpoint devices

On the transit hub switches, BGP is configured using source VLAN interfaces within each VRF . Additionally, each transit hub switch uses a dedicated VLAN per BGP peering. For example:

• Transit Hub 1 – Switch 1 uses VLAN 101 (/30) as the BGP source interface

• Transit Hub 1 – Switch 2 uses VLAN 102 (/30) for another BGP peering
  both switches are part of transit hub in same rack.

This design intentionally avoids the use of HSRP or any other Layer 2 gateway redundancy protocol. The current configuration is deployed in the production network and is operating successfully.

Objective

While the existing design is stable and functional, there is interest in optimizing the architecture to reduce CPU utilization on the transit hub switches and to redesign the BGP behavior to operate in an Active/Passive model rather than fully active. Guidance is requested on best practices or architectural changes that could achieve this optimization without compromising stability or resiliency. 

[paul driver · Accepted solution]

Hello
Ingress traffic from ebgp cloud- suggest as-prepending /or conditional route advertisement 

outbound traffic towards isp - local preference

[Edgar Benavente · Accepted solution]

The simplest way to prioritize your traffic is to consider "normal conditions" and/or "contingency conditions" scenarios and let the protocol handle them automatically.

The suggestion is:

- For traffic from the cloud, you could use AS Prepend.
- For outbound traffic to your ISP, use Local Preference.

Both scenarios include traffic selection.

Regards

[srimal99]