vania-janet/multiturn-rag-retrieval-data huggingface dataset:
AC-4 (21) - Physical / Logical Separation of Information Flows 



  Control requirements 

AC-4 (21) - 0
:   The information system separates information flows logically or physically using [Assignment: organization-defined mechanisms and/or techniques] to accomplish [Assignment: organization-defined required separations by types of information].





  Implementation guidance 

See the resources that follow to learn more about how to implement this control.



*  [Connecting application provider to the management VPC](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-connectivity-management)







  NIST supplemental guidance 

Enforcing the separation of information flows by type can enhance protection by ensuring that information is not commingled while in transit and by enabling flow control by transmission paths perhaps not otherwise achievable. Types of separable information include, for example, inbound and outbound communications traffic, service requests and responses, and information of differing security categories.
[112-Developer-tools.svg](https://cloud.ibm.com/media/docs/images/homepage/112-Developer-tools.svg)](https://developer.ibm.com/depmodels/cloud/)[Architecture Center<br><br>Discover the architecture references available for this product.<br><br>![190-Application-Platform.svg](https://cloud.ibm.com/media/docs/images/homepage/190-Application-Platform.svg)](https://www.ibm.com/cloud/architecture)[IBM Training<br><br>Build your skills with IBM Cloud training.<br><br>![83-Elements-of-the-cloud.svg](https://cloud.ibm.com/media/docs/images/homepage/83-Elements-of-the-cloud.svg)](https://www.ibm.com/training/cloud)[Community<br><br>Join the IBM Cloud community and collaborate with others.<br><br>![35-Connectivity.svg](https://cloud.ibm.com/media/docs/images/homepage/35-Connectivity.svg)](https://community.ibm.com/community/user/publiccloud/home)

 Latest updates 

[View more](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-transit-gateway-release-notes)April 2023 | Multi-account support for IBM Cloud Direct Link

Transit Gateway now includes cross-account support for Direct Link connections.

November 2022 | Transit gateway unbound GRE tunnels

You can now use an unbound Generic Routing Encapsulation (GRE) tunnel transit gateway connection to connect endpoints, which allows a transit gateway to connect to overlay networks hosted on classic infrastructure resources.

March 2022 | Transit gateway prefix filtering

Network prefix filters simplify the management of the IP addresses that you reference in your resources to route network traffic. You can create prefix filters to permit or deny specific routes on specific connections.
[Layer 2 bridge setup with a new bridge edge cluster](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/arch-pattern-l2-bridge-edge.svg)

Figure 3. Layer 2 bridge setup with a new bridge edge cluster

Make sure you have the bridged VLANs transport zone (for example tz-bridge) configured on all wanted transport nodes.





 Considerations 

When you design or deploy this architecture pattern, consider the following steps:



* Using the existing workload edge cluster is good for testing the layer 2 capability and for small deployments.
* If you have a larger deployment, deploying a dedicated edge cluster or several edge clusters offers better performance and generally scales better.
* If you use new edge nodes for bridging, they do not have to be in the same network or POD as the workload edge. Edge nodes are transport nodes and they communicate with the other NSX-T transport nodes (edges or hosts) through Geneve tunnels over layer 3 routed connections by using the IBM Cloud classic network as a transport network.







 Related links 



* [VMware vSphere overview](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vs_vsphereclusteroverview)
* [Getting started with IBM Cloud Gateway Appliance](https://cloud.ibm.com/docs/gateway-appliance?topic=gateway-appliance-getting-started)
* [Installing NSX-T edge transport nodes](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.2/installation/GUID-5EF2998C-4867-4DA6-B1C6-8A6F8EBCC411.html)
However, without route optimization, Layer 3 communication requests must return to the on-premises network origin to be routed. This return trip is called tromboning or hairpinning.

Tromboning is inefficient because packets must travel back and forth between the network origin and the Cloud, even when both the source and destination VMs are in the Cloud. In addition to inefficiency, if the forwarding path includes stateful firewalls, or other inline equipment that must see both sides of the connection, communication might fail. VM communication (without route optimization) failure occurs when the egress path that exits the cloud can be either the stretched Layer 2 network or through the vCenter Server NSX Edge Gateway. The on-premises network does not know about the stretched network "shortcut." This problem is called asymmetric routing. The solution is to enable proximity routing so the on-premises network can learn the routes from IBM Cloud.

To prevent tromboning, HCX uses intelligent route management to choose routes appropriate to the VM state. The Cloud Gateway maintains an inventory of VMs in the cloud and it understands the VM states, which can be one of the following values:



* Transferred to the cloud with vMotion (zero-downtime migration).
* Migrated to the cloud by using host-based replication (low-downtime migration).
* Created in the cloud (on a stretched network).



For more information about HCX on-premises deployments, see the [VMware HCX documentation](https://docs.vmware.com/en/VMware-HCX/services/user-guide/GUID-BFD7E194-CFE5-4259-B74B-991B26A51758.html).







 Related links 



* [VMware HCX system requirements](https://docs.vmware.com/en/VMware-HCX/services/user-guide/GUID-D64901F4-6AB4-4820-9303-27927648A34D.html)
10.188.111.70/32;
}
protocol tcp;
port 8443;
}
then accept;
}
term DNS {
from {
protocol udp;
source-port 53;
}
then accept;
}
}
}
routing-options {
static {
route 166.9.0.0/16 next-hop 10.188.111.65;
route 0.0.0.0/0 next-hop 169.60.101.113;
route 161.26.0.0/16 next-hop 10.188.111.65;
route 10.0.0.0/8 next-hop 10.188.111.65;
}
}
Show more

The following table illustrates network interface definitions for the previous configuration:



Table 1. Network interface definitions

 Interface name Interface function 

 ge-0/0/0 Gigabit ethernet interface for SL-PRIVATE transit VLAN 
 ge-0/0/1 Gigabit ethernet interface for SL-PUBLIC transit VLAN 
 ge-0/0/2 Gigabit ethernet interface for SL-PRIVATE transit VLAN 
 ge-0/0/3 Gigabit ethernet interface for SL-PUBLIC transit VLAN 
 ae0.0 Aggregated Ethernet interface 
 ae1.0 Aggregated Ethernet interface 
 fxp0 Management interface 
 lo0 loopback interface 







 Default Configuration of a sample 10G HA SR-IOV Public and Private vSRX Gateway 

 Last commit: 2020-04-21 17:22:34 UTC by root
version 18.4R1-S1.3;
groups {
node0 {
system {
host-name asloma-tc1b-18-10g-pubpriv-dual-ha1-vsrx-vSRX-Node0;
}
}
node1 {
system {
host-name asloma-tc1b-18-10g-pubpriv-dual-ha1-vsrx-vSRX-Node1;
}
}
}
* Over time, you can gradually migrate specific parts of the NSX-V workloads.
* Logically extending networks between both environments and move the workloads gradually from NSX-V to NSX-T.



The journey from NSX-V to NSX-T requires careful planning and preparation. You must be familiar with NSX-T concepts and administration tasks before any migrations. This journey must involve the following steps:



* Education - Training for the team who migrates to NSX-T and then runs NSX-T.
* Migration planning and preparation - Review the current NSX-V environment to understand the complexity of the migration, and key business drivers that impact migration. Select the topology for the target NSX-T environment.
* Target platform selection, deployment, and configuration - This step also includes the setting-up of migration tools such as L2 bridging or VMware HCX. Or also third-party tools such as SPJ's cITopus or ReSTNSX's Migration Assistance Tool.
* Configuration migration - These tasks include the setting-up of overlay components, which includes NSX-T segments, routing, load balancing, edge firewall, distributed firewall, and tagging. Configuration migration can be done manually through scripting, such as Terraform or third-party tools such as SPJ's cITopus.
* Workload migration - This step includes layer 2 network stretching, if required, and virtual machine migration. Migration techniques include VMware HCX migrations or Advanced vCenter vMotion.



An example of high-level migration workflow that uses the lift-and-shift migration approach with NSX-T L2 Bridge is as follows:



* Deploy the new vCenter Server with NSX-T instance.
* Create your required NSX-T network topology and configure the necessary network services.
* Configure an NSX-T Edge bridge to extend the NSX-V VXLAN/logical switch/virtual wire to an overlay segment in NSX-T.
* Use the VMware Migration Coordinator to migrate (copy across) the Distributed Firewall (dFW) configuration.
* The dFW only migration mode of the migration coordinator must be run only one time.
You can move the workloads between the NSX-V and NSX-T environments, while you keep the default gateway either on the NSX-V or move it to the new NSX-T. This action allows a smoother network migration. However, it is not mandatory if your environment can tolerate downtime.

Consider the following details for Layer 3 network migration:



* VM by VM migration – This approach moves a VM at a time and /32 route for that host is injected into the NSX-T environment. Therefore, a specific route is defined to this IP address to the NSX-T environment while all other IP addresses in the subnet are still routed to the NSX-V environment.
* Subnet by subnet migration – This approach moves all the VMs on a subnet at a time. The subnet is advertised out of the NSX-T environment and not advertised from the NSX-V environment.
* Big-bang - All subnets and their connected VMs are moved and then all subnets advertised from the NSX-T environment.



Consider the following details for Layer 2 network extension during migration:



* NSX-T L2 bridge - In this approach an NSX-T Edge VM or preferably a pair of NSX-T Edge VMs, are deployed on the NSX-V prepared hosts. These Edge VMs are registered with NSX-T Manager and a L2Bridge configured to connect the required NSX-V VXLAN (virtual wire) to an NSX-T segment. For more information, see [Migration that uses vMotion or third-party tools and NSX-T L2 bridge](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-v2t-l2-nsx-t).
* VMware HCX - VMware HCX is a solution that is primarily used for migrating workloads between environments, and consists of a number of services to achieve workload mobility. HCX integrates into both NSX-V and NSX-T. HCX Network Extension (NCX-NE) allows simultaneous bridging of multiple networks.
* [Provision Transit Gateway](https://cloud.ibm.com/interconnectivity/transit/provision)
* Add all VPCs (Hub and spokes) as connections to transit gateway ![tgw-connections](https://cloud.ibm.com/docs-content/v1/content/d50364af907081c3c38f99c11f35dd9cab4b2510/vpc-journey/images/advanced-elements/transit-gateway-connections.png)
* Define an ingress rule in hub VPC's custom routing table to force packets from on-premises to transit via VNF to reach target workloads ![ingress-rule](https://cloud.ibm.com/docs-content/v1/content/d50364af907081c3c38f99c11f35dd9cab4b2510/vpc-journey/images/advanced-elements/hub-ingress-rule.png)
* Define an egress rule in spoke VPC's custom routing table to force the return path from target destined to on-premises to transit via VNF. ![egress-rule1](https://cloud.ibm.com/docs-content/v1/content/d50364af907081c3c38f99c11f35dd9cab4b2510/vpc-journey/images/advanced-elements/spoke1-egress-rule.png)![egress-rule2](https://cloud.ibm.com/docs-content/v1/content/d50364af907081c3c38f99c11f35dd9cab4b2510/vpc-journey/images/advanced-elements/spoke2-egress-rule.png)







 Next Steps
* [Communication with resources in on-premises data centers](https://cloud.ibm.com/docs/containers?topic=containers-vpc-vpnaasonprem)



* [IBM Cloud VPC VPN](https://cloud.ibm.com/docs/containers?topic=containers-vpc-vpnaasvpc-vpn-def)
* [Direct Link](https://cloud.ibm.com/docs/containers?topic=containers-vpc-vpnaasvpc-directlink-def)



* [Communication with resources in other VPCs](https://cloud.ibm.com/docs/containers?topic=containers-vpc-vpnaasvpc-vpc)



* [IBM Cloud VPC VPN](https://cloud.ibm.com/docs/containers?topic=containers-vpc-vpnaasvpc-vpn-other)
* [IBM Cloud Transit Gateway](https://cloud.ibm.com/docs/containers?topic=containers-vpc-vpnaasvpc-transit-def)



* [Communication with IBM Cloud classic resources](https://cloud.ibm.com/docs/containers?topic=containers-vpc-vpnaasvpc-classic)



* [Create a classic-access VPC](https://cloud.ibm.com/docs/containers?topic=containers-vpc-vpnaasvpc-create-classic)
* [Use IBM Cloud Transit Gateway](https://cloud.ibm.com/docs/containers?topic=containers-vpc-vpnaasvpc-use-transit-gw)





[Adding static routes to worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-static-routesstatic-routes)



* [About static routes](https://cloud.ibm.com/docs/containers?topic=containers-static-routesabout-static-routes)
* [Enabling the static route add-on](https://cloud.ibm.com/docs/containers?topic=containers-static-routesenable-add-on)
[Architecture](https://cloud.ibm.com/docs-content/v1/content/d50364af907081c3c38f99c11f35dd9cab4b2510/vpc-journey/images/advanced-elements/hub-and-spoke-standalone.png)





 Configuration Steps 



* [Provision VPC as hub](https://cloud.ibm.com/vpc-ext/provision/vpc) with following prefixes: ![hub-prefixes](https://cloud.ibm.com/docs-content/v1/content/d50364af907081c3c38f99c11f35dd9cab4b2510/vpc-journey/images/advanced-elements/hub-prefixes.png)
* Provision VNF of your choice. In this example using centOS-7 as VNF and enable ip spoofing on the NIC. ![ip-spoofing](https://cloud.ibm.com/docs-content/v1/content/d50364af907081c3c38f99c11f35dd9cab4b2510/vpc-journey/images/advanced-elements/ip-spoofing-enable.png)
* Enable IP forwarding in centOS-7 (sysctl -w net.ipv4.ip_forward=1)
* Provision VPCs as spokes.
* Deploy VM-based or container-based clusters on spoke VPCs.
* [Provision Transit Gateway](https://cloud.ibm.com/interconnectivity/transit/provision)
* Add all VPCs (Hub and spokes) as connections to transit gateway ![tgw-connections](https://cloud.ibm.com/docs-content/v1/content/d50364af907081c3c38f99c11f35dd9cab4b2510/vpc-journey/images/advanced-elements/transit-gateway-connections.png)
Networking <br><br> * [VPC infrastructure services](https://cloud.ibm.com/docs/vpc?topic=vpc-resource-authorizations-required-for-api-and-cli-calls)<br> * [Direct Link](https://cloud.ibm.com/docs/dl?topic=dl-iam)<br> * [Transit Gateway](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-iam)<br><br><br> 
 Storage <br><br> * [Block Storage for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-resource-authorizations-required-for-api-and-cli-calls)<br> * [Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-iam)<br><br><br> <br><br> * [Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-iam)<br><br><br> 
 Security <br><br> * [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-manage-access)<br><br><br> <br><br> * [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-manage-access)<br><br><br> <br><br> * [App ID](https://cloud.ibm.com/docs/appid?topic=appid-service-access-management)<br><br><br>
* Add [flow log capture](https://cloud.ibm.com/docs/vpc?topic=vpc-flow-logs) in the transit.
* Put each of the spokes in a separate account in an [enterprise](https://cloud.ibm.com/docs/account?topic=account-enterprise-tutorialaccount_groups_tutorial).
* Force some of the spoke to spoke traffic through the firewall and some not through the firewall.
* Replace the worker VSIs with [Red Hat OpenShift on IBM Cloud and VPC load balancer](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaas).
* Force all out bound traffic through the firewall in the transit VPC and through [Public gateways](https://cloud.ibm.com/docs/vpc?topic=vpc-public-gateways) .







 Related content 



* [IBM Cloud for Financial Services](https://cloud.ibm.com/docs/framework-financial-services)
* Tutorial: [Best practices for organizing users, teams, applications](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-users-teams-applicationsusers-teams-applications)
* [How to deploy isolated workloads across multiple locations and regions](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vpc-multi-region)
* [Public front end and private backend in a Virtual Private Cloud](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vpc-public-app-private-backend),
* [Network Function Virtualization](https://cloud.ibm.com/docs/vpc?topic=vpc-about-vnf)
* [Private hub and spoke with transparent VNF and spoke-to-spoke traffic](https://cloud.ibm.com/docs/vpc?topic=vpc-about-vnf-ha)
* The vMotion migration of a VM within HCX does not generate more throughput than the vMotion networking for a single ESXi host.
* As bulk migration can have multiple migrations in flight simultaneously, it achieves higher bandwidth use than a vMotion migration. The ratio observed at a customer side with 1 Gbps vMotion links to the ESX hosts was of 8 replications = bandwidth use of 1 vMotion.
* As a result of moving empty space on disk, a high LAN use with a high ratio is displayed, therefore, low WAN use. 1 Gbps seems to be the limit. Indeed, in this particular case the vMotion network is only capable of 1 Gbps, which is the bottleneck.
* For the vMotion migration of a multi TB Oracle database with a WAN link of 1 Gbps, the limitation is the vMotion network of 1 Gbps.









 Stretched Layer 2 traffic 

The HCX fleet component Layer 2 Concentrator has a bandwidth limitation of approximately 4 Gbps for all L2 network traffic that traverses it. Individually stretched networks have a bandwidth limit of approximately 1 Gbps or less depending on the traffic type. It is possible to have many stretched L2 networks across a single L2C pair (theoretical allowable max of 4096 networks per L2C pair). The L2C is engineered to detect and protect small traffic flows so that they are not overcome by large flows within the same L2C pair. It can be advantageous to identify if this situation is occurring and start more L2Cs to increase overall bandwidth capability.

Deploying multiple L2Cs can also be advantageous where multiple paths exist between the customer site and IBM Cloud®, such as direct link and internet. A single network cannot be made redundant or given increased bandwidth across multiple L2C pairs.

Monitor the traffic across all interfaces that use the Monitoring tab of the L2C VM. If the total data rate is approaching 8 Gbps (4 Gbps in / out) consider adding another L2 pair and redistribute stretched networks to rebalance.





 Related links
[Centralize communication through a VPC Transit Hub and Spoke architecture - Part two](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vpc-transit2)Centralize communication through a VPC Transit Hub and Spoke architecture - Part two

A layered architecture will introduce resources and demonstrate connectivity. Each layer will add additional connectivity and resources. The layers are implemented in Terraform. It will be possible to change parameters, like number of zones, by changing a Terraform variable. A layered approach allows the tutorial to introduce small problems and demonstrate a solution in the context of a complete architecture.

Virtual Private Cloud (VPC) Transit Gateway

+4

Direct Link on Classic,DNS Services,IBM Cloud Databases,Databases For Redis



* 2 hours
* 2023-05-05



[Getting Started](https://cloud.ibm.com/docs/databases-for-elasticsearch?topic=databases-for-elasticsearch-getting-started)Getting Started

This tutorial is a short introduction to using an IBM Cloud® Databases for Elasticsearch deployment. Connect to your deployment using Kibana, an open source tool that adds visualization capabilities to your Elasticsearch database. This tutorial runs Kibana in a Docker container by using the Kibana image from the Docker image repository. Install Kibana with Docker to run a system you control.

Databases For Elasticsearch



* 30 minutes
* 2023-05-11



[Getting Started](https://cloud.ibm.com/docs/databases-for-enterprisedb?topic=databases-for-enterprisedb-getting-started)Getting Started

This tutorial is a short introduction to using an IBM Cloud® Databases for EnterpriseDB deployment. pgAdmin is an open source administration platform for PostgreSQL, and provides many tools for managing your data and databases. Download and install the version that is appropriate to your environment, and then follow the steps to connect it to your Databases for EnterpriseDB deployment.

Databases For EnterpriseDB



* 30 minutes
* 2023-04-27
Architecture pattern for using layer 2 (L2) bridging with NSX-T 

With layer 2 bridging, you can have a L2 connection to a VLAN-backed port group or a device that is outside of your NSX-T data center deployment. An L2 bridge is also useful in a migration scenario, in which you need to split a subnet across physical and virtual workloads. Or when you run a database cluster on IBM Cloud bare metal servers.

You can use layer 2 bridging in IBM Cloud by following the principles that are presented in this pattern. You can adapt the pattern based on your needs by following VMware® best practices and IBM Cloud Classic network capabilities.



 Layer 2 bridging with NSX-T 

The following diagram presents an overview for an architecture pattern for using layer 2 bridging with NSX-T edges in IBM Cloud classic infrastructure.

Zoom

![Layer 2 bridging with NSX-T](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/arch-pattern-l2-bridge.svg)

Figure 1. Layer 2 bridging with NSX-T

The following list is a summary of the architecture pattern deployment:



1. An L2 bridge requires an Edge cluster and an Edge Bridge profile to be deployed. An Edge Bridge profile specifies which Edge cluster to use for bridging and which Edge transport node acts as the primary and backup bridge.
2. You need to have a new VLAN for the bridged devices. After the VLAN is provisioned, you can request to trunk the hosts. VLAN must be trunked to all hosts in your cluster through IBM Cloud Classic portal (Classic Infrastructure > Network > Gateway appliances). Then, add the ESX hosts to a wanted NSX-T VLAN transport zone, for example tz-bridge.
3. On the edge cluster uplink distributed port group, enable Promiscuous mode and Forged transmits for bridging.