Building a Stack With Cloudify, VMWare, Brocade, and MetaSwitch

Since we at Cloudify have been working closely with VMWare, Brocade, and MetaSwitch for quite some time, it made perfect sense to showcase how the different pieces can be orchestrated together to demonstrate how a single solution stack made of multiple parts comes together.

We chose to go with Brocade Vyatta as the basis for the vCPE VNF for connecting multiple branch offices and allowing for chaining additional services on the cloud. We chose Metaswitch SBC to allow the customer to utilize existing on-premise PBX assets while enabling connectivity across branches and to external PBXs managed by a cloud-based Session Border Controller.

The VMWare NFV stack offered the power of NSX and vCenter with the cloud layer of vCloud.

Cloudify serves as both the orchestrator and VNF Manager (VNFM) for these VNFs. Cloudify provides not only the power of TOSCA and open standards, but is also tightly integrated with the entire VMWare NFV stack, including plugin support for vCloud, vSphere, NSX and a management pack for VROPS.

In this post, I will focus on the experience I had with the onboarding of the Brocade Vyatta VNF and how to configure a Site to Site IPSec tunnel overlay between two Vyatta VNFs.

Getting Vyatta up and running was simple. All it took was getting a template uploaded to the vCloud Catalog, which we have done manually, provisioning the necessary networks, provisioning the VM and connecting it to the networks.

When the Vyatta was up and running, it provided a RESTful API we used for configuring its settings such as the data planes, the FW zones, rules, and NAT. I did all this using the awesome vRouter plugin that one of our engineers, Josh, built a few months back which mapped these configurations to tidy TOSCA types.

When that was all configured, I continued to the Site to Site IPSec tunnel configuration. The plugin I used did not have this area covered, and, at first, I was tempted to add the missing types to the plugin which was nicely architected so that I could reuse most of Josh’s work and just focus on the types.

However, on second thought, I remembered these Vyatta devices supported Netconf and we have already had some basic example of how to use our Netconf plugin with Vyatta to establish an OpenVPN tunnel.

I decided to explore this route and focus on adding the VPN overlay using Netconf. I found an article explaining how to manually establish Site-Site VPN and opened the Vyatta YANG models to match the configuration described in the article with that model.

This proved to be quite an efficient process and, in a couple of hours, I had the Netconf configuration already written in the blueprint:

branch1_vpn:
    type: vyatta-machine
    properties:
      netconf_auth:
        user: { get_input: netconf_user }
        password: { get_input: netconf_user }
        key_content: { get_input: netconf_key_content }
    relationships:
    - type: cloudify.relationships.contained_in
      target: vrouter_branch1_VM
    - type: cloudify.relationships.depends_on
      target: branch1_dataplane_dp0s3
    - type: cloudify.relationships.depends_on
      target: branch1_dataplane_dp0s4
    - type: cloudify.relationships.depends_on
      target: branch1_dataplane_dp0s5
    interfaces:
      cloudify.interfaces.lifecycle:
        create:
          inputs:
            netconf_auth:
              ip: { get_attribute: [ vrouter_branch1_VM, networks, demo_management ]}
            lock:
              - rfc6020@candidate
            back_database: rfc6020@candidate
            front_database: rfc6020@running
            calls:
              - action: rfc6020@edit-config
                validate_xml: false
                payload:
                  rfc6020@config: 
                    vyatta-security-v1@security:
                      vyatta-security-vpn-ipsec-v1@vpn:
                        vyatta-security-vpn-ipsec-v1@ipsec:
                          vyatta-security-vpn-ipsec-v1@esp-group:
                            vyatta-security-vpn-ipsec-v1@tagnode: ESP-1W
                            vyatta-security-vpn-ipsec-v1@proposal:
                              vyatta-security-vpn-ipsec-v1@tagnode: 1
                              vyatta-security-vpn-ipsec-v1@encryption: aes256
                              vyatta-security-vpn-ipsec-v1@hash: sha1
                            vyatta-security-vpn-ipsec-v1@lifetime: 1800

              - action: rfc6020@edit-config
                validate_xml: false
                payload:
                  rfc6020@config: 
                    vyatta-security-v1@security:
                      vyatta-security-vpn-ipsec-v1@vpn:
                        vyatta-security-vpn-ipsec-v1@ipsec:
                          vyatta-security-vpn-ipsec-v1@ike-group:
                            vyatta-security-vpn-ipsec-v1@tagnode: IKE-1W
                            vyatta-security-vpn-ipsec-v1@proposal:
                              vyatta-security-vpn-ipsec-v1@tagnode: 1
                              vyatta-security-vpn-ipsec-v1@encryption: aes256
                              vyatta-security-vpn-ipsec-v1@hash: sha1
                            vyatta-security-vpn-ipsec-v1@lifetime: 3600
              - action: rfc6020@edit-config
                validate_xml: false
                payload:
                  rfc6020@config:
                    vyatta-if-v1@interfaces:
                      vyatta-interfaces-vti-v1@vti:
                        vyatta-interfaces-vti-v1@tagnode: vti0
                        vyatta-interfaces-vti-v1@address: 172.169.97.249/30 


        configure:
          inputs:
            netconf_auth:
              ip: { get_attribute: [ vrouter_branch1_VM, networks, demo_management ]}
            lock:
              - rfc6020@candidate
            back_database: rfc6020@candidate
            front_database: rfc6020@running
            calls:
              - action: rfc6020@get-config
                payload:
                  rfc6020@source:
                    rfc6020@running: {}
                save_to: origin_interfaces
              - action: rfc6020@edit-config
                validate_xml: false
                payload:
                  rfc6020@config:
                    vyatta-security-v1@security:
                      vyatta-security-vpn-ipsec-v1@vpn:
                        vyatta-security-vpn-ipsec-v1@ipsec:
                          vyatta-security-vpn-ipsec-v1@site-to-site:
                            vyatta-security-vpn-ipsec-v1@peer:
                              vyatta-security-vpn-ipsec-v1@tagnode: { get_attribute: [ vrouter_branch2_VM, networks, demo_public ] }
                              vyatta-security-vpn-ipsec-v1@authentication:
                                vyatta-security-vpn-ipsec-v1@pre-shared-secret: test_key_1
                              vyatta-security-vpn-ipsec-v1@ike-group: IKE-1W
                              vyatta-security-vpn-ipsec-v1@local-address: { get_attribute: [ vrouter_branch1_VM, networks, demo_public ] }
                              vyatta-security-vpn-ipsec-v1@vti:
                                vyatta-security-vpn-ipsec-v1@bind: vti0
                                vyatta-security-vpn-ipsec-v1@esp-group: ESP-1W

After placing this YAML into the blueprint, I tried testing it. The first attempt resulted in a failure. It turned out the Netconf service was not on by default on the Vyatta VNF.  To fix that, I chose the easy route and just updated the template with a configuration that started Netconf by default. With Netconf enabled, I could see the configuration changes applied to Vyatta.

Once I created a second copy with the matching site configuration, the tunnel was created and traffic could flow between the sites - quite cool.

For me, this was quite an important experience combining two different approaches:

• A custom plugin with TOSCA types mapped for each supported function.
• A generic Netconf plugin utilizing the existing YANG models that are supported by the device itself.

I see pros and cons with both approaches, but my personal choice from now on would be that if the VNF does not have a pre-built plugin, and Netconf is supported with published YANG models for it, I would choose the Netconf path.

Below is a detailed view of the architecture of the service provider network connected to the customer premises.

Watch the full video, courtesy of VMware, showing the fully orchestrated vCPE with Dynamic Service Insertion on VMware with Cloudify Orchestration.