BGP (Border Gateway Protocol) is typically used in wide-area networks (WANs) to exchange routing information between different autonomous systems (ASes) on the internet. It’s not commonly used in local area networks (LANs) because LANs typically use interior gateway protocols (IGPs) like OSPF or RIP for routing within the same network.
However, there are scenarios where BGP can be used within a LAN, particularly in large-scale data center environments or specialized network setups. One such scenario is when peering with third-party Network Virtual Appliances (NVAs) that are deployed within the LAN. These NVAs might need BGP to exchange routing information with the local network.
Aviatrix is a cloud networking solution that provides advanced networking and security services for cloud environments, including AWS, Azure, Google Cloud, and others. It does support BGP (Border Gateway Protocol) over LAN in the context of its cloud network orchestration and management capabilities.
Aviatrix allows organizations to set up and manage BGP peering with various network components, including third-party Network Virtual Appliances (NVAs), within their cloud-based LANs. This support for BGP over LAN enables more advanced routing and connectivity options for cloud-based workloads, making it a valuable feature for organizations looking to optimize their cloud network architecture.
Design
This network diagram illustrates an Aviatrix implementation utilizing BGP over LAN to establish robust connections. Aviatrix, a cloud networking solution, powers this architecture, enabling dynamic routing within the LAN. The implementation connects to Cisco Cloud Routers, which serve as gateways to multiple branches, ensuring efficient and secure data flow across the network.
This design creates two external connections instead of a single connection so as the traffic can be engineered using AS Path Prepend by specifying AS PATH for each BGP connection.
https://read.docs.aviatrix.com/HowTos/transit_advanced.html#connection-as-path-prepend
Configuration
First Connection: Transit Gateway x CSR1000v-1
GUI screenshots are great :). Same configuration can be done using terraform using the aviatrix_transit_external_device_conn resource:
A new interface is created:
We have not selected “Enable Remote Gateway HA”, the AVX Transit Gateway HA does not have a second interface.
Every-time we specify a different IP for the Local LAN IP, a new interface is created:
One important observation is that the Remote LAN IP should be unique in a AVX Transit Gateway:
Detachment of the connection also removes the extra interface created previously:
The BGP configuration for the CSR1000v can be downloaded from the Controller:
Once the configuration is applied to the CSR1000v the neighborhood is established:
Second Connection: Transit Gateway x CSR1000v-2
If no Local LAN IP is specified for the Transit Gateway, the controller will trigger the creation of a new interface/new IP address:
To avoid such situation, we need to specify the IP of the existent interface:
Keep in mind that using the same IP for multiple connections has a side effect of the Controller removing it if one of those connections is detached.
The way to trick the controller to create a single connection from the Transit Gateway HA is to provide a “fake” Remote LAN IP. Not really a trick because the connection will be created but it will be always down.
A second interface is created on the HA gateway:
Once the configuration is applied to the CSR1000v-2, the connection is established:
As expected, one connection is down. From the Multi-Cloud Transit BGP tab we can see the status of connections 1 and 2:
Traffic Engineering
Now with multiple connections, we can use Prepend to influence the traffic:
Configuring Prepend:
References
https://docs.aviatrix.com/previous/documentation/latest/planning-secure-networks/s2c-overview.html
