Let's test now Scenario 2. If you do not recall what was Scenario 2 take a look here. As said before, Scenario 2 is more realistic, thus it is a better testing approach providing better results.
Let's take it step by step. First let's do a basic configuration (configure the interfaces, default gateways and NAT rules) on every Vyatta VC4 machine, just to make sure that connectivity is not a problem and things work the way we want.
Since we are using a virtual environment we can easily capture traffic and actually view how packets are flowing. For this, I will enable VMware Network Adapter VMnet5, VMware Network Adapter VMnet6, VMware Network Adapter VMnet7 on the host machine, see Figure125.

Figure125: VMware Network Adapters VMnet5, VMnet6 and VMnet7 Enabled

Also, since VMware Network Adapters VMnet5, VMnet6 and VMnet7 are enabled, I can use a SSH client from the host machine to configure the routers.

First let's configure Glendale ISP.

Now I can use a SSH client to quickly enter the rest of the configuration.

Set the name of the machine and a default route to the gateway of this lab.

set system host-name ISP
set protocols static route 0.0.0.0/0 next-hop 192.168.22.1
commit

set service nat rule 10 type masquerade
set service nat rule 10 source address 192.168.50.0/24
set service nat rule 10 outbound-interface eth0

set service nat rule 15 type masquerade
set service nat rule 15 source address 192.168.60.0/24
set service nat rule 15 outbound-interface eth0

set service nat rule 20 type masquerade
set service nat rule 20 source address 192.168.70.0/24
set service nat rule 20 outbound-interface eth0
commit
save

And Glendale ISP's configuration is done.

set interfaces ethernet eth0 address 192.168.50.2/24
set interfaces ethernet eth1 address 192.168.10.1/24
set service ssh protocol-version 2
commit

Now I can use a SSH client to quickly enter the rest of the configuration.

Set the name of the machine and a default route to the gateway.

set system host-name HQ
set protocols static route 0.0.0.0/0 next-hop 192.168.50.1
commit

Since the network behind the Glendale HQ machine is from private IP address space, in practice we will need a NAT rule in place. In our lab, IP addresses from the 192.168.50.0/24 network act as public IP addresses. Thus I will add a NAT rule on the Glendale HQ machine.

Now I will check from a host behind Glendale HQ machine if I can reach my lab's physical gateway and if I have Internet connectivity.

Figure126: Ping from a host behind Glendale HQ machine

We can capture some packets to see how they are translated when they pass through the Vyatta VC4 machines. I will start a Wireshark capture on the VMnet5 interface on the host machine, another one on my physical interface(see Figure127 and Figure128, make sure "Capture packets in promiscous mode " is selected, see Figure129 ) and another one on the VM behind Glendale HQ.

Figure127: Wireshark Capture Menu: Interfaces

Figure128:  Start the Wireshark captures on the host machine

Figure129: Start a Wireshark capture on the VMnet5 interface on the host machine

In Figure130 we can see the original echo request packet sent by a VM behind Glendale HQ to 192.168.22.1. As can be noticed an echo reply was received back. So connectivity is OK.

Figure130: Wireshark Capture on the VM Behind Glendale HQ: Ping

In Figure131 we can spot that our NAT rule set on Glendale HQ is working.

Figure131: Wireshark Capture - The Echo Request Packet Translated by Glendale HQ

And in Figure132 we will see that the NAT rule set on Glendale ISP is working too.

Figure132: Wireshark Capture - The Echo Request Packet Translated by Glendale ISP

So if necessary, our physical network can be unaware of the virtual lab, thus no need for any modifications on the physical gateway.