Bridging Hybrid Cloud and Multi-Cloud Environments with Solace

With this blog post I will describe and demystify the prominent orange lines in this “marketecture” diagram, i.e. the means by which you can link or “bridge” multiple clouds with Solace open data movement technology. I will walk you through the general use cases and drill down to the actual implementation details including example configurations.

Topologies

In most cases, these inter-cloud links will be implement with Solace’s bridging feature, which provides robust fault tolerant links that support message filtering, compression and transport level security. Generally speaking, a Solace bridge is an embedded specialized client that can transfer messages from one message router or HA cluster to another, either one way or bi-directionally.  Solace bridges can be established between any combination or number of virtual message routers and hardware appliances.

Use Cases

Let’s look at some use cases and map them to commonly understood message exchange patterns, then see how each is implemented.


 

Datacenter to Cloud

This use case enables actions like moving analytics workloads to the cloud. This could mean distributing things like database transaction logs or other data events to the cloud where they can be digested by cloud-based analytics applications.  In this use case messaging traffic will move from the datacenter to the cloud using inter-router bridging.

The Solace message router in the datacenter connects to the message router in the cloud. This is the normal connection model as most datacenters will allow outbound connections and more tightly control inbound connections.  The cloud based message router then adds managed message topic subscriptions, or binds to a queue endpoint, and draws messages from the datacenter message router into the cloud.

Besides the basic advantages that Solace message routers offer such as high performance, easy manageability, secure and compressed WAN links, Solace excels at buffering data on both sides of the WAN link to avoid putting back pressure on the datacenter applications while providing guaranteed in-order delivery to analytics applications.

Example configuration using REST calls via cURL

See Example Configuration
These are the steps required to configure Solace message routers to allow data messaging to flow from a datacenter to cloud.

To be able to set up bridging for this use case you will need the following information. Values in blue are reasonable defaults, while values in red need to be configured.

DataCenVMRIP=<XX.XX.XX.XX>
DataCenVMRName=<stringName>
DataCenAdminPassword=<stringPassword>
DataCenQue=QForCloud
DataCenVPN=default
DataCenToCloudBridgeName=DCToCloud
DataCenClientUsername=bridgeUser
DataCenClientPassword=<stringPassword>
CloudVMRIP=<XX.XX.XX.XX>
CloudAdminPassword=<stringName>
CloudVPN= default
CloudToDataBridgeName=CloudToDC
CloudClientUsername= bridgeUser
CloudClientPassword=<stringPassword>

  1. Create a queue on Solace message router in the datacenter, and add topic subscriptions to that queue. These subscriptions route the messages you want attracted to the cloud.  In the next steps the cloud based message router will bind to this queue and receive messages:
    1. Create the queue
      curl -H "Content-Type: application/json" -X POST \
           -u admin:${DataCenAdminPassword}  \
      http://${DataCenVMRIP}:8080/SEMP/v2/config/msgVpns/${DataCenVPN}/queues \
           -d '{"queueName":" ${DataCenQue}",
                "egressEnabled":true,
                "ingressEnabled":true,
                "permission":"delete"}'
      
    2. Add subscriptions, repeat for all subscriptions. See subscriptions for topic description discussions.
          curl -H "Content-Type: application/json" -X POST \
           -u admin:${DataCenAdminPassword}  \
      http://${DataCenVMRIP}:8080/SEMP/v2/config/msgVpns/${DataCenVPN}/ queues/${DataCenQue}/subscriptions \
           -d '{"subscriptionTopic":"to/cloud"}'
      
  2. Connect and Bind to Queue First connect from datacenter to cloud. Then use this connection to create a flow binding in the reverse direction to allow the Cloud message router to bind and receive messages.
    1. Create bridge on datacenter message router
      curl -H "Content-Type: application/json" -X POST \
           -u admin:${DataCenAdminPassword}  \
      http://${DataCenVMRIP}:8080/SEMP/v2/config/msgVpns/${DataCenVPN}/ bridges \
           -d '{"bridgeName":"${DataCenToCloudBridgeName}”,
                "bridgeVirtualRouter":"primary",
                "enabled":true,
                "remoteAuthenticationBasicClientUsername":"${CloudClientUsername}",
                "remoteAuthenticationBasicPassword":"${CloudClientPassword}",
                "remoteAuthenticationScheme":"basic"}'
      
    2. Connect to cloud message router
      curl -H "Content-Type: application/json" -X POST \
           -u admin: ${DataCenAdminPassword} \
      http://${DataCenVMRIP}:8080/SEMP/v2/config/msgVpns/${DataCenVPN}/bridges/${DataCenToCloudBridgeName},primary/remoteMsgVpns \
           -d '{"enabled":true,
                "remoteMsgVpnLocation":"${CloudVMRIP}:55555",
                "remoteMsgVpnInterface":"intf0",
                "remoteMsgVpnName":"${CloudVPN}"}'
      
    3. Create bridge on cloud message router
      curl -H "Content-Type: application/json" -X POST \
           -u admin:${CloudAdminPassword} \
      http://${CloudVMRIP}:8080/ SEMP/v2/config/${CloudVPN}/bridges \
           -d '{"bridgeName":"${CloudToDataBridgeName}”,
                "bridgeVirtualRouter":"primary",
                "enabled":true,
                "remoteAuthenticationBasicClientUsername":"${DataCenClientUsername}",
                "remoteAuthenticationBasicPassword":"${DataCenClientPassword}",
                "remoteAuthenticationScheme":"basic"}'
      </li>
      
      
      
      
    4. Connect to datacenter message router and bind to queue
      curl -H "Content-Type: application/json" -X POST \
           -u admin:${CloudAdminPassword} \
      http://${CloudVMRIP}:8080/SEMP/v2/config/msgVpns/${CloudVPN}/bridges/${CloudToDataBridgeName}/remoteMsgVpns \
           -d '{"enabled":true,
                "queueBinding":”${DataCenQue}",
                "remoteMsgVpnLocation":"v:${DataCenVMRName}",
                "remoteMsgVpnName":"${DataCenVMRName}"}'
      


 

Cloud to Datacenter

This use case enables actions like pushing web based application usage into legacy data centers.  In this use case messaging traffic will move from the cloud to the datacenter via inter-router bridging.

The Solace message router in the datacenter connects to the message router in the cloud.  This is the normal connection model as most data centers will allow outbound connections while more tightly controlling inbound connections.  The datacenter-based message router then adds managed message topic subscriptions, or binds to a queue endpoint, and draws messages from the cloud message router into the datacenter.

Solace offers protocol translation from web and mobile protocols like HTTP, MQTT and WebSocket into standards-based application message oriented middleware protocols like AMQP, JMS and SMF without the need to add additional bridges or gateways.  This simplifies the cloud messaging architecture and security model by reducing the number of nodes and eliminating the need to secure a heterogeneous messaging infrastructure.

Example configuration using REST calls via cURL

Expand
These are the steps required to configure Solace message routers to allow data messaging to flow from cloud to datacenter.

To be able to set up bridging for this use case you will need the following information. Values in blue are reasonable defaults, while values in red need to be configured:
DataCenVMRIP=<XX.XX.XX.XX>
DataCenAdminPassword=<stringPassword>
DataCenVPN=default
DataCenToCloudBridgeName=DCToCloud
DataCenClientUsername=bridgeUser
DataCenClientPassword=<stringPassword>
CloudVMRIP=<XX.XX.XX.XX>
CloudAdminPassword=<stringName>
CloudVPN= default
CloudQue=QForCloud

  1. Create a queue on cloud Solace message router and add topic subscriptions to that queue. These subscriptions route the messages you want attracted to the datacenter.  In the next steps the datacenter based message router will bind to this queue and receive messages:
      1. Create the queue
    curl -H "Content-Type: application/json" -X POST \
         -u admin:${CloudAdminPassword}  \
    http://${CloudVMRIP}:8080/SEMP/v2/config/msgVpns/${CloudVPN}/queues \
         -d '{"queueName":" ${CloudQue}",
              "egressEnabled":true,
              "ingressEnabled":true,
              "permission":"delete"}'
    
    1. Add subscriptions, repeat for all subscriptions. See subscriptions for topic description discussions.
          
      curl -H "Content-Type: application/json" -X POST \
           -u admin:${CloudAdminPassword}  \
      http://${CloudVMRIP}:8080/SEMP/v2/config/msgVpns/${CloudVPN}/ queues/${CloudQue}/subscriptions \
           -d '{"subscriptionTopic":"to/dataCenter"}'
      
  2. Connect and Bind to Queue First connect from datacenter to cloud. Then use this connection to create a flow binding to allow the datacenter message router to bind and receive messages.
    1. Create bridge on datacenter message router
      curl -H "Content-Type: application/json" -X POST \
           -u admin:${DataCenAdminPassword}  \
      http://${DataCenVMRIP}:8080/SEMP/v2/config/msgVpns/${DataCenVPN}/ bridges \
           -d '{"bridgeName":"${DataCenToCloudBridgeName}”,
                "bridgeVirtualRouter":"primary",
                "enabled":true,
                "remoteAuthenticationBasicClientUsername":"${CloudClientUsername}",
                "remoteAuthenticationBasicPassword":"${CloudClientPassword}",
                "remoteAuthenticationScheme":"basic"}'
      
    2. Connect to cloud message router
      curl -H "Content-Type: application/json" -X POST \
           -u admin: ${DataCenAdminPassword} \
      http://${DataCenVMRIP}:8080/SEMP/v2/config/msgVpns/${DataCenVPN}/bridges/${DataCenToCloudBridgeName},primary/remoteMsgVpns \
           -d '{"enabled":true,
                "remoteMsgVpnLocation":"${CloudVMRIP}:55555",
                "remoteMsgVpnInterface":"intf0",
                "remoteMsgVpnName":"${CloudVPN}",
                "queueBinding":”${CloudQue}"}'
      


 

Cloud to Cloud or Cloud to Datacenter Bi-Directional

In the previous two use cases the bridges were used for a single purpose and the application flow was in a single direction.   There are many cases where the application data is spread between Cloud and legacy data center or between clouds and bi-direction traffic is required.

The cloud1 Solace message router connects to the message router in the cloud2.  The cloud1 based message router then adds managed message topic subscriptions, or binds to queue endpoint, and draws messages from the cloud2 message router into the cloud.  As well the cloud2 based message router then adds managed message topic subscriptions, or binds to queue endpoint, and draws messages from the cloud1 message router for local forwarding based on topic routing rules.

Besides the basic advantages that Solace message routers offer, such as high performance, easy to manage, secure and compressed WAN links, Solace offers protocol translation from web and mobile protocols,( HTTP, WebSockets, MQTT), into standards based application message oriented middleware protocols, (JMS, AMQP, SMF), without need to additional bridges or gateways.  This greatly simplifies the cloud messaging architecture and security model, by reducing the number of nodes and eliminating the need to secure a heterogeneous messaging infrastructure. Solace also offers excellent ability to buffer data on both sides of the WAN link ensuring no backpressure on applications while providing guaranteed in order delivery of the exact required data to analytics applications.  Finally Solace message routers are cloud agnostics and provide application integration for most major public and private cloud providers including AWS, Azure, Google Cloud Platform, OpenShift, OpenStack, Pivotal Cloud Foundry, SAP Cloud Platform, VMWare and IBM Bluemix.

Example configuration using REST calls via cURL

Expand

These are the steps required to configure Solace message routers to allow data messaging to flow from cloud1 to cloud2 and vice-versa.  All connections will be originated from cloud1

To be able to set up bridging for this use case you will need the following information, Values in Blue are reasonable defaults. Values in red need to be configured.

Cloud1VMRIP=<XX.XX.XX.XX>
Cloud1VMRName=<stringName>
Cloud1AdminPassword=<stringPassword>
Cloud1Que=QForCloud2
Cloud1VPN=default
Cloud1ToCloud2BridgeName=Cloud1ToCloud2
Cloud1ClientUsername=bridgeUser
Cloud1ClientPassword=<stringPassword>
Cloud2VMRIP=<XX.XX.XX.XX>
Cloud2AdminPassword=<stringName>
Cloud2Que=QForCloud1
Cloud2VPN= default
Cloud2ToClound1BridgeName=Cloud2ToCloud1
Cloud2ClientUsername= bridgeUser
Cloud2ClientPassword=<stringPassword>

  1. Create a queue on Cloud1 Solace message router and add topic subscriptions to that queue. These subscriptions route the messages you want attracted to the cloud2.  In the next steps the cloud2 based message router will bind to this queue and receive messages:
    1. create the queue
      curl -H "Content-Type: application/json" -X POST \
           -u admin:${Cloud1AdminPassword}  \
      http://${Cloud1VMRIP}:8080/SEMP/v2/config/msgVpns/${Cloud1VPN}/queues \
           -d '{"queueName":" ${Cloud1Que}",
                "egressEnabled":true,
                "ingressEnabled":true,
                "permission":"delete"}'
      
    2. add subscriptions, repeat for all subscriptions. See subscriptions for topic description discussions.
          curl -H "Content-Type: application/json" -X POST \
           -u admin:${Cloud1AdminPassword}  \
      http://${Cloud1VMRIP}:8080/SEMP/v2/config/msgVpns/${Cloud1VPN}/queues/${Cloud1Que}/subscriptions \
           -d '{"subscriptionTopic":"to/cloud2"}'
      
  2. Create a queue on Cloud2 Solace message router and add topic subscriptions to that queue. These subscriptions route the messages you want attracted to the cloud1.  In the next steps the cloud1 based message router will bind to this queue and receive messages:
    1. create the queue
      curl -H "Content-Type: application/json" -X POST \
           -u admin:${Cloud2AdminPassword}  \
      http://${Cloud2VMRIP}:8080/SEMP/v2/config/msgVpns/${Cloud2VPN}/queues \
           -d '{"queueName":" ${Cloud2Que}",
                "egressEnabled":true,
                "ingressEnabled":true,
                "permission":"delete"}'
      
    2. add subscriptions, repeat for all subscriptions. See subscriptions for topic description discussions.
          curl -H "Content-Type: application/json" -X POST \
           -u admin:${Cloud2AdminPassword}  \
      http://${Cloud2VMRIP}:8080/SEMP/v2/config/msgVpns/${Cloud2VPN}/queues/${Cloud2Que}/subscriptions \
           -d '{"subscriptionTopic":"to/cloud1"}'
      
  3. Connect and Bind to Queue First connect from datacenter to cloud. Then use this connection to create a flow binding in the reverse direction to allow the Cloud message router to bind and receive messages.
    1. Create bridge on datacenter message router
      curl -H "Content-Type: application/json" -X POST \
           -u admin:${Cloud1AdminPassword}  \
      http://${Cloud1VMRIP}:8080/SEMP/v2/config/msgVpns/${Cloud1VPN}/ bridges \
           -d '{"bridgeName":"${Cloud1ToCloud2BridgeName}”,
                "bridgeVirtualRouter":"primary",
                "enabled":true,
                "remoteAuthenticationBasicClientUsername":"${Cloud2ClientUsername}",
                "remoteAuthenticationBasicPassword":"${Cloud2ClientPassword}",
                "remoteAuthenticationScheme":"basic"}'
      
    2. Connect to cloud message router
          curl -H "Content-Type: application/json" -X POST \
           -u admin: ${Cloud1AdminPassword} \
      http://${Cloud1VMRIP}:8080/SEMP/v2/config/msgVpns/${Cloud1VPN}/bridges/${Cloud1ToCloud2BridgeName},primary/remoteMsgVpns \
           -d '{"enabled":true,
                "remoteMsgVpnLocation":"${Cloud2VMRIP}:55555",
                "remoteMsgVpnInterface":"intf0",
                "remoteMsgVpnName":"${Cloud2VPN}",
                "queueBinding":”${Cloud1Que}"}'
      
    3. Create bridge on cloud message router
          curl -H "Content-Type: application/json" -X POST \
           -u admin:${Cloud2AdminPassword} \
      http://${Cloud2VMRIP}:8080/ SEMP/v2/config/${Cloud2VPN}/bridges \
           -d '{"bridgeName":"${Cloud2ToCloud1Name}”,
                "bridgeVirtualRouter":"primary",
                "enabled":true,
                "remoteAuthenticationBasicClientUsername":"${Cloud1ClientUsername}",
                "remoteAuthenticationBasicPassword":"${Cloud1ClientPassword}",
                "remoteAuthenticationScheme":"basic"}'
      
    4. Connect to datacenter message router and bind to queue
          curl -H "Content-Type: application/json" -X POST \
           -u admin:${Cloud2AdminPassword} \
      http://${Cloud2VMRIP}:8080/SEMP/v2/config/msgVpns/${Cloud2VPN}/bridges/${Cloud2ToCloud1BridgeName}/remoteMsgVpns \
           -d '{"enabled":true,
                "queueBinding":”${Cloud1Que}",
                "remoteMsgVpnLocation":"v:${Cloud1VMRName}",
                "remoteMsgVpnName":"${Cloud1VMRName}"}'
      

Filtering

In all use cases data movement costs money, but in these data-center to cloud and cloud-to-cloud use cases the data movement costs are very visible and can drive decisions on what approaches and technologies to use.   It is therefore very important to get exactly the correct data into and out of the different cloud environments.  To achieve this fine grain filtering is needed.  It is also important to de-couple publisher and consumers view of the data and allow the consumer to select exactly what data it wants without affecting the publisher flows.  Here is an example.  Let’s envision an application that receives customers’ orders and produces a messages for downstream processing.  The topic for this message could be of a form like:  order/region/brand/category/subcategory/product
Then Consumers could receive all orders in a region: order/region/>
Or all orders for a specific brand: order/*/brand/>
Or all orders of a specific product category: order/*/*/category/>

What is important here is that a topic subscription is added to the bridge, this attracts a single copy of the message across the bridge, then the message is fanned out to the individual applications tailored to their specific needs.

Security

It is important to have authentication and authorization at every level of the messaging infrastructure.  The bridge connections can be configured with basic authentication, use authentication servers such as LDAP or Radius, or use client/server certificates.  It is also possible to enable integrated transport layer security and data at rest encryption via cloud infrastructure.  To learn more about Solace bridging TLS see here.

Compression

Integrated stream based compression on the bridge also helps reduce message movement costs. Reducing bandwidth is particularly important when data is leaving a cloud since data entering is free but there are charges for bandwidth leaving the cloud, or being distributed between regions of a cloud. To learn more about Solace message router compression see here.

Performance

Tuning for optimum performance across the WAN is about right sizing, queueing, and windowing at all layers of the stack to maximize the available bandwidth.

TCP Tuning

At the lowest level there is TCP buffering and sliding windowing.  In the TCP handshake a TCP window is negotiated between sender and receiver.  Once congestion windows are open, a sender can send up to a windows worth of bytes.  As the sender sends bytes, it closes its send window by that many bytes. As it receives an ACK for a fixed number of bytes, the sender opens its window by that many bytes.

In the example below the sender and receiver have negotiated a window of 4500 Bytes.  As a receiver could request a retransmission anywhere within the TCP window each host must maintain at least a 4500 byte buffer for the TCP session to be able to gap fill the TCP flow.

As the sender sends the first 1500 bytes, (with relative sequence number 0000), it closes its TCP window by that amount, this continues for the next 3 segments until the available window equals 0.

Then when the sender receive an ACK for 4500 bytes, it opens its send window by that amount and continues sending.

If this was a WAN link with 20milliSeconds,(mSec), round trip time,(rtt), then the time from sending Sequence 3000 and receiving ACK 4500 would be 20 mSec.  Thus throughput would be maximum 4500 Bytes/0.02Seconds = 225KBytes/sec.  In reality the receiver will send and ACK before reaching a full window size, but in some situations even this optimization is not enough and we need to tune up the TCP window size to accommodate for high byte rates or large rtt, or both.

Here is a good guide to figure out what your minimum latency will be between various regions globally.

To tune the TCP buffers and windows we need to know Byte rate and RTT.  Formula would be :
TCP_Window_Size = (Desired_Rate Bytes/sec * RTT sec) Bytes

Example configuration using REST calls via cURL

Expand
So for example NewYork to London has an rtt of 90mSec and NewYork to Japan has 45+160=205mSec rtt.  If you want to move 50 MBytes/sec from NewYork to London you will need a window of 50,000,000 Bytes/sec * 0.09 sec = 4.5MBytes.  This means we need 4.5MBytes of TCP buffers and windows to transmit this data.

To set this value we must first ensure the Linux kernel has enough memory allocated to the TCP stack buffers.  This is done with Linux level kernel tuning on both sides of the link as follows:

sudo sysctl –w net.core.rmem_max = 134217728
sudo sysctl –w net.core.wmem_max = 134217728
sudo sysctl –w net.ipv4.tcp_rmem = 4096 25165824 67108864 
sudo sysctl –w net.ipv4.tcp_wmem = 4096 25165824 67108864
sudo sysctl –w net.ipv4.tcp_mtu_probing=1

Now we can tune the client-profiles used on the bridge connections.

Cloud1VMRIP=<XX.XX.XX.XX>
Cloud1VMRName=<stringName>
Cloud1AdminPassword=<stringPassword>
Cloud1Que=QForCloud2
Cloud1VPN=default
Cloud1ClientProfile=default
Cloud1ToCloud2BridgeName=Cloud1ToCloud2
Cloud1ClientUsername=bridgeUser
Cloud1ClientPassword=<stringPassword>
Cloud2VMRIP=<XX.XX.XX.XX>
Cloud2AdminPassword=<stringName>
Cloud2Que=QForCloud1
Cloud2VPN= default
Cloud2ToClound1BridgeName=Cloud2ToCloud1
Cloud2ClientUsername= bridgeUser
Cloud2ClientPassword=<stringPassword>

curl -H "Content-Type: application/json" -X POST \
     -u admin:${Cloud1AdminPassword} \ http://${Cloud1VMRIP}:8080/SEMP/v2/config/msgVpns/${Cloud1VPN}/clientProfiles \
     -d '{"clientProfileName":"${Cloud1ClientProfile}",
          "msgVpnName":"${Cloud1VPN}",
          "tcpMaxWindowSize":4500}'

If this is a uni-directional bridge like the cloud-to-datacenter use case we need to modify the bridge to use this new profile, or set the tcpMaxWindowSize in the default message vpn.

curl -H "Content-Type: application/json" -X PATCH \
     -u admin:${Cloud1AdminPassword} \ http://${Cloud1VMRIP}:8080/SEMP/v2/config/msgVpns/${Cloud1VPN}/bridges/${Cloud1ToCloud2BridgeName},primary/remoteMsgVpns/${Cloud2VPN},${Cloud2VMRIP},intf0 \
     -d '{"unidirectionalClientProfile":"${Cloud1ClientProfile}"}'

Finally we need to set the client-usernames used on the bridges to use the new profiles.

curl -H "Content-Type: application/json" -X PATCH \
     -u admin:${Cloud1AdminPassword} \
http://${Cloud1VMRIP}:8080/SEMP/v2/config/msgVpns/${Cloud1VPN}/clientUsernames/Cloud1ClientUsername \
     -d '{"clientProfileName":"${Cloud1ClientProfile}"}'

Assured Delivery Window Tuning

Now we have the TCP windows and buffers tuned for the desired byte rates, we need to do the same for Assured delivery messages.  On top of the TCP session the Solace message routers maintain an Assured Delivery flow with buffers and windows to allow the flow consumer, (bridge endpoint in the case), to backpressure to producer to allow the consumer an opportunity to persist the message before ACKing it.

To tune the AD buffers and windows we need to know the average message size.  Formula would be :
AD_Window_Size = ((Desired_Rate Bytes/sec * RTT sec) / Average_Message_Size Bytes/msg) msg

Example configuration using REST calls via cURL

Expand
If we take the previous example of 50Mbyte/sec from NewYork To London and predict the average message size is 1Kbytes, we would have (50,000,000 Bytes/sec * 0.09sec) / 1000 Bytes/message = 4500 messages.  This means we need 4500 message AD buffers and Windows to transmit this data.

To set the correct buffering we need to modify the client-profile.

curl -H "Content-Type: application/json" -X PATCH \
     -u admin:${Cloud1AdminPassword} http://${Cloud1VMRIP}:8080/SEMP/v2/config/msgVpns/${Cloud1VPN}/clientProfiles/${Cloud1ClientProfile} \
     -d '{" queueGuaranteed1MinMsgBurst ":4500}'

curl -H "Content-Type: application/json" -X PATCH \
     -u admin:${Cloud2AdminPassword} http://${Cloud2VMRIP}:8080/SEMP/v2/config/msgVpns/${Cloud2VPN}/clientProfiles/${Cloud2ClientProfile} \
     -d '{"queueGuaranteed1MinMsgBurst ":4500}'

Finally to set the set the actual AD Window on the bridge:

curl -H "Content-Type: application/json" -X PATCH \
     -u admin:${Cloud1AdminPassword} http://${Cloud1VMRIP}:8080/SEMP/v2/config/msgVpns/${Cloud1VPN}/bridges/${Cloud1ToCloud2BridgeName},primary/remoteMsgVpns/${Cloud2VMRIP},intf0 \
     -d '{"egressFlowWindowSize":4500}'

curl -H "Content-Type: application/json" -X PATCH \
     -u admin:${Cloud2AdminPassword} http://${Cloud2VMRIP}:8080/SEMP/v2/config/msgVpns/${Cloud2VPN}/bridges/${Cloud2ToCloud1BridgeName},primary/remoteMsgVpns/${Cloud1VMRIP},intf0 \
     -d '{"egressFlowWindowSize":4500}'