Partner GW Basics
search cancel

Partner GW Basics

book

Article ID: 330753

calendar_today

Updated On:

Products

VMware SD-WAN by VeloCloud

Issue/Introduction

The Partner Gateway (PG) configuration is used by many partners who want to have their own GWs for several purposes such as they want to connect the customers to their core network.
The PG will be connected core network via PE via BGP.
Moreover, few partners host their application behind PG, so via
PG they can connect multiple customers to these applications.
This will give them complete control to customer traffic. 


Symptoms:
NA

Environment

VMware SD-WAN by VeloCloud

Resolution

First, we have to understand the difference between NAT handoff and VLAN handoff interface.
 
NAT handoff :
The packets will be received on this interface from VeloCloud edges. The packets could be sent out from this interface to the internet. These packets will be NATed to GW public IP.
 
VLAN handoff : (doesn’t exist in Cloud GW)
This interface is used to connect GW with the partner’s core network. Packets will be received or sent out to the partner’s core network. When packets are sent out they won’t be NATed. When packets are sent out they will be tagged with specific VLAN ID (unique for each customer). As we hand off the traffic to core from this interface, it is called as VLAN handoff interface.
 
Cloud GW will have only one interface (eth0) which will be NAT handoff interface. But Partner GW will have one NAT handoff (eth0)and one VLAN handoff interface (eth1). This can be checked by checking
ifconfig on GW.
 
Cloud GW :
 
PGW-a01:COMMANDS phardik$ more ifconfig-a.out.txt
eth0      Link encap:Ethernet  HWaddr 52:54:00:05:fc:3d
          inet addr:10.6.10.52  Bcast:10.6.10.255  Mask:255.255.255.0
          inet6 addr: fe80::5054:ff:fe05:fc3d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6072566759 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5895629244 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:4096
          RX bytes:2904717739044 (2.9 TB)  TX bytes:2951021028611 (2.9 TB)
 
gwd1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:169.254.129.1  P-t-P:169.254.129.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:100754 errors:0 dropped:0 overruns:0 frame:0
          TX packets:69542 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:4096
          RX bytes:37914266 (37.9 MB)  TX bytes:4139564 (4.1 MB)
 
lo        Linkencap
:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:169825708 errors:0 dropped:0 overruns:0 frame:0
          TX packets:169825708 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:24007274179 (24.0 GB)  TX bytes:24007274179 (24.0 GB)
 
Partner GW:
 
PGW-a01:COMMANDS phardik$ more ifconfig-a.out.txt
eth0      Link encap:Ethernet  HWaddr 00:50:56:b2:6a:91
          inet addr:<removed>  Bcast:[IP REMOVED  ] Mask:255.255.255.248
          inet6 addr: fe80::250:56ff:feb2:6a91/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:75689 errors:0 dropped:0 overruns:0 frame:0
          TX packets:46931 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:4096
          RX bytes:10479963 (10.4 MB)  TX bytes:6273421 (6.2 MB)
 
eth1      Link encap:Ethernet  HWaddr 00:50:56:b2:30:1b
          inet addr:169.254.108.6  Bcast:169.254.108.255  Mask:255.255.255.0
          inet6 addr: fe80::250:56ff:feb2:301b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1508  Metric:1
          RX packets:16121 errors:0 dropped:9 overruns:0 frame:0
          TX packets:4354 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:4096
          RX bytes:917076 (917.0 KB)  TX bytes:184484 (184.4 KB)
 
gwd1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:169.254.129.1  P-t-P:169.254.129.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:4096
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
 
lo        Linkencap
:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:7952 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7952 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:549380 (549.3 KB)  TX bytes:549380 (549.3 KB)
 
 
There is one more way we can check whether it is Cloud or Partner GW.
 
check /etc/config/
gatewayd-tunnel file and for cloud GW you will see only one interface eth0 for cloud GW and eth1 & eth0 for PG.
 
PGW-a01:config phardik$ cat gatewayd-tunnel
# [.section tun_setup.sh] - used by tun_setup.sh script
wan="eth0"
 
PGW-a01:config phardik$ cat gatewayd-tunnel
# [.section tun_setup.sh] - used by tun_setup.sh script
wan="eth0 eth1"

 
 
 
 
 
As we can see by default eth0 will be NAT Handoff and VLAN Handoff interface. But it can be different based on configuration.

From VCO, we can do handoff configuration for a customer as shown in the page below. We can do this configuration per GW or for all GWs.
 

 
The handoff interface supports different tag types. You can assign unique VLAN ID for each customer here.
 

 
There are different tagging options are available.
Partner can choose appropriate option.
 
Also, you can configure
static route as you can see on this screen. You can define whether it will be reachable via NAT handoff or VLAN handoff. Based on this (NAT/VLAN handoff), traffic destined for the subnet configured in static route will be forwarded to eth0 or eth1.
 
From the diagnostic bundle of
GW you can find unique tag for each customer from file /COMMANDS/optvcbindebugpy--vrf_dump.out.txt. This file will also have enterprise id for each customer. This enterprise id will be used to to distinguish routes because routes will be marked with enterprise id to provide isolation between customers.
 
 
PGW-a01:COMMANDS phardik$ more optvcbindebugpy--vrf_dump.out.txt
{
      "c_tag": 107,
      "enteprise_id": "baaecf8f-2246-4886-a8a2-f8d05228c8ba",
      "enterprise_name": "<removed>",
      "lan_vlan_transport_mode": "NONE",
      "s_tag": 100,
      "vlan_vrf_mode": "QinQ (0x8100)",
      "vrf_ip": "172.18.3.50/30"
    },

 
GW route table truncated output :
 
PGW-a01:COMMANDS phardik$ more optvcbindebugpy--timeout30--routes.out.txt
EnterpriseID                                    Address           Netmask        Type                            Destination   Reachable   Metric   Preference   Flags   C-Tag   S-Tag   Handoff            Mode       Age
64f7de08-813b-43eb-a8d7-c3271305797f      [IP REMOVED  ]  255.255.255.255   edge2edge   e491c3a8-90f3-48ab-a770-13ba63f9bb2e        True        0            0     CSm      75       0       N/A             N/A   2710289
64f7de08-813b-43eb-a8d7-c3271305797f      [IP REMOVED  ]  255.255.255.255       cloud                                0.0.0.0        True        0          512     PSB     125     100      VLAN   QinQ (0x8100)   3534984
64f7de08-813b-43eb-a8d7-c3271305797f      [IP REMOVED  ]  255.255.255.255       cloud                                0.0.0.0        True        0          512     PSB     125     100      VLAN   QinQ (0x8100)   3534984