Gateway
The Gateway adds advanced network service capabilities to the fabric, complementing its fast, scalable connectivity. The fabric delivers efficient, cut-through transport between workloads, while the Gateway provides additional capabilities such as NAT, PAT, and firewalling. Simple VPC Peerings use the full bandwidth of the fabric, whereas traffic using Gateway services is handled through the Gateway nodes, which determine the available throughput. Together, they offer both high-performance connectivity and rich network services.
Gateway Nodes and Fabric Connectivity
Gateway nodes are connected to the fabric by a set of physical connections that are modeled via Connection objects. See the section on Gateway Connections for connection requirements and example configuration.
When a Gateway Peering is used to connect two VPCs or externals, the gateway nodes attract traffic to themselves by advertising the appropriate routes to the fabric. In turn, the fabric uses these routes to steer traffic to the gateway so that the gateway can apply the configured peering policy.
Gateway nodes use BGP to advertise routes to the fabric, and the gateway gets its own ASN so it is possible to easily identify gateway-advertised routes in the fabric.
graph TD
%% Style definitions
classDef gateway fill:#FFF2CC,stroke:#CC9900,stroke-width:1px,color:#000
classDef spine fill:#F8CECC,stroke:#B85450,stroke-width:1px,color:#000
classDef leaf fill:#DAE8FC,stroke:#6C8EBF,stroke-width:1px,color:#000
classDef server fill:#D5E8D4,stroke:#82B366,stroke-width:1px,color:#000
classDef hidden fill:none,stroke:none
classDef legendBox fill:none,stroke:none,color:#000
%% Network diagram
Gateway_01["Gateway"]
subgraph Spines[" "]
direction LR
Spine_01["Spine-1"]
Spine_02["Spine-2"]
end
subgraph Leaves[" "]
direction LR
Leaf_01["Leaf-1"]
Leaf_02["Leaf-2"]
Leaf_03["Leaf-3"]
end
subgraph Servers[" "]
direction TB
Server_01["Server-1"]
Server_02["Server-2"]
Server_03["Server-3"]
Server_04["Server-4"]
Server_05["Server-5"]
Server_06["Server-6"]
end
%% Connections
%% Gateway_01 -> Spines
Gateway_01 --- Spine_01
Gateway_01 --- Spine_02
Spine_01 --- Leaf_01
Spine_01 --- Leaf_02
Spine_01 --- Leaf_03
Spine_02 --- Leaf_01
Spine_02 --- Leaf_02
Spine_02 --- Leaf_03
%% Leaves -> Servers
Leaf_01 --- Server_01
Leaf_01 --- Server_02
Leaf_02 --- Server_03
Leaf_02 --- Server_04
Leaf_03 --- Server_05
Leaf_03 --- Server_06
subgraph Legend["Network Connection Types"]
direction LR
%% Create invisible nodes for the start and end of each line
L1(( )) --- |"Gateway Links"| L2(( ))
L7(( )) --- |"Fabric Links"| L8(( ))
L9(( )) --- |"Server Links"| L10(( ))
end
class Gateway_01 gateway
class Spine_01,Spine_02 spine
class Leaf_01,Leaf_02,Leaf_03 leaf
class Server_06,Server_05,Server_04,Server_03,Server_02,Server_01 server
class L1,L2,L7,L8,L9,L10 hidden
class Legend legendBox
linkStyle default stroke:#666,stroke-width:2px
linkStyle 0,1 stroke:#CC9900,stroke-width:2px
linkStyle 2,3,4,5,6,7 stroke:#CC3333,stroke-width:2px
linkStyle 8,9,10,11,12,13 stroke:#6C8EBF,stroke-width:2px
linkStyle 14 stroke:#CC9900,stroke-width:2px
linkStyle 15 stroke:#CC3333,stroke-width:2px
linkStyle 16 stroke:#6C8EBF,stroke-width:2px
%% Make subgraph containers invisible
style Spines fill:none,stroke:none
style Leaves fill:none,stroke:none
style Servers fill:none,stroke:noneGateway Peering
Just as VPC Peerings provide VPC-to-VPC connectivity by way of the switches in the fabric, gateway peerings provide connectivity via the gateway nodes. Gateway services can be inserted between a pair of VPCs or a VPC and an external using a Gateway Peering. Each peering can be configured to provide the necessary services for traffic that uses that peering. Peering the same entities via gateway and fabric at the same time results in undefined behaviour. If two entities (VPCs or externals) are already peered via the fabric, delete this peering first, then peer them via the gateway.
Simple Gateway Peering Between VPCs
A simple peering with no services deployed between the VPCs. This traffic will transit the gateway node(s).
Gateway Peering with Stateless NAT
Stateless NAT translates source and/or destination IP addresses for all packets that traverse
the peering, but it does not maintain any flow state for the connection. A
one-to-one mapping is established between the addresses exposed in the CIDRs for
ips and the addresses to use represented by the CIDRs in
as: each address from the first group is consistently mapped to a single
address from the second group. Therefore, the total number of addresses covered
by the CIDRs YAML array entries from ips must be equal to the total number of
addresses covered by the CIDRs from as.
Gateway Peering with Stateful Source NAT
Stateful source NAT uses a flow table to track established connections.
When traffic is initiated from vpc-1 to vpc-2, the flow table is updated
with the connection details. In the return direction (from vpc-2 to vpc-1
in the following example), the flow table is consulted to determine if the packet
is part of an established connection. If it is, the packet is allowed to pass
through the peering. If it is not, the packet is dropped.
This behavior allows use of stateful NAT as a simple firewall.
Gateway Peering for External Connections
The following YAML listings show how to expose a default route to the
10.50.2.0/24 subnet inside of vpc-02. In this example the name of the
external is example-ext. Assuming this external is representing the WAN, this will
allow hosts inside of the 10.50.2.0/24 to the WAN. The following is an
example YAML file to create an external.
| example-external.yaml | |
|---|---|
Once the external is created, the gateway can be used to create a peering
between the external and a VPC. The following YAML is an example of this
configuration. Note that the name of the external is prefixed with ext..
| gw-peer-external.yaml | |
|---|---|