vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* [Context](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_uc_transportuc_shipping_context)
* [Solution](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_uc_transportuc_shipping_solution)
* [Results](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_uc_transportuc_shipping_results)



* [Airline delivers innovative Human Resources (HR) benefits site in under 3 weeks](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_uc_transportuc_airline)



* [Context](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_uc_transportuc_airline_context)
* [Solution](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_uc_transportuc_airline_solution)
* [Results](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_uc_transportuc_airline_results)





[Government use cases for IBM Cloud](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_uc_govcs_uc_gov)



* [Regional government improves collaboration and velocity with community Developers who combine public-private data](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_uc_govuc_data_mashup)



* [Context](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_uc_govuc_data_mashup_context)
* [Solution](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_uc_govuc_data_mashup_solution)
* [VPC egress and ingress routing](https://cloud.ibm.com/docs/vpc?topic=vpc-about-custom-routes).
* Connectivity via [IBM Cloud® Direct Link](https://www.ibm.com/cloud/direct-link).
* Connectivity via [IBM Cloud Transit Gateway](https://www.ibm.com/cloud/transit-gateway).
* [Virtual Network Functions](https://cloud.ibm.com/docs/vpc?topic=vpc-about-vnf-ha).



A layered architecture will introduce resources and demonstrate connectivity. Each layer will add additional connectivity and resources. A layer may introduce small problems and demonstrate solutions in the context of a larger architecture. The layers are implemented using Infrastructure as Code in the form of Terraform configuration files. It will be possible to change parameters, like number of zones, by changing a Terraform variable.



 Objectives 



* Understand the concepts behind a VPC based hub and spoke model.
* Understand the implementation of a firewall-router and a transit VPC environment.
* Understand VPC ingress and egress routing.
* Identify and optionally resolve asymmetric routing issues.
* Connect VPCs via a Transit Gateway.







 Before you begin 

This tutorial requires:



* terraform to use Infrastructure as Code to provision resources,
* python to optionally run the pytest commands,
* Implementing a firewall-router will require that you [enable IP spoofing checks](https://cloud.ibm.com/docs/vpc?topic=vpc-ip-spoofing-aboutip-spoofing-enable-check),
* An SSH key to connect to the virtual servers. If you don't have an SSH key, follow [the instructions](https://cloud.ibm.com/docs/vpc?topic=vpc-ssh-keys) for creating a key for VPC.
Plan Network Connectivity Flows 

Taking the time to understand and plan network flows is a key ingredient to successful deployment. As you review this section, consider the connectivity requirements you have today but may also need in the future.



 Journey Map 

![Architecture](https://cloud.ibm.com/docs-content/v1/content/7f09c1b3f21dd05ddc2c4638a3dc66976ad73e53/vmware-classic-journey/images/solution-vmware-onboarding-hidden/network-flows/journey-map.png)





 Overview 

By using NSX logical switches with your own IP addresses (BYOIP) you gain the greatest flexibility to manage and secure your workload network in the IBM Cloud. However, with BYOIP comes the additional requirement of devising a strategy for connectivity from within your instance. There are four major areas of connectivity that need to be addressed:



1. VM to VM connectivity. How your VMs will be able to communicate with each other over the NSX software defined network. Considerations here include routing and whether microsegmentation will be implemented.
2. VM to public network (Internet) connectivity. Will your virtual machines connect to the Internet directly, utilize a gateway appliance such as FortiGate or vSRX, or utilize proxy servers deployed in the IBM Cloud network or on your own network accessed via VPN or Direct Link.
3. VM to IBM Cloud Private connectivity. Will your virtual machines require connectivity to services such as Cloud Object Storage or IBM Databases as a Service, and will that connectivity be secured through a gateway appliance or leverage the network address capabilities of NSX-T.
4. VM to on premise connectivity. Key to connectivity between your BYOIP NSX environment and on premise is the ability to perform route exchange between the two environments. Devising a solution to exchange routes using such technologies as BGP or GRE is essential to a complete working solution.







 Detailed Flows 

In this section, detailed network flows will be reviewed. The following network architecture will be broken down into five different flows:

!
Establish Transit Gateway Connectivity 



 Journey Map 

![Architecture](https://cloud.ibm.com/docs-content/v1/content/d50364af907081c3c38f99c11f35dd9cab4b2510/vpc-journey/images/tgw/journey-map.png)





 Overview 

The IBM Cloud VPC Transit Gateway allows you to establish inter-connectivity with your VPCs. Using Transit Gateway, you can establish connections between your VPC and:



* Other VPCs - Allows to communication to resources in other VPCs within the same region or in other regions
* IBM Cloud Classic Infrastructure - Allows for communication to resources still running on IBM Cloud Classic Infrastructure
* Direct Link - Allows for communication to on-prem resources



The following example depicts how Transit Gateway devices can be used to connect VPCs together.

![Architecture](https://cloud.ibm.com/docs-content/v1/content/d50364af907081c3c38f99c11f35dd9cab4b2510/vpc-journey/images/tgw/tgw-arch-sample1.png)

The following example depicts how Transit Gateway devices can be used to connect VPC to classic infrastructure together. Note that Classic infrastructure resource from any region can be acceesible to local Transit Gateway

![tgw-classic](https://cloud.ibm.com/docs-content/v1/content/d50364af907081c3c38f99c11f35dd9cab4b2510/vpc-journey/images/tgw/vpc-to-classic-tgw.png)

The following example depicts how Transit Gateway devices can be used to connect VPCs together with Direct link.

!
Understanding Internet Communication Protocols 

Generally speaking, a communication protocol is a system of rules that allow two or more entities of a communications system to transmit information. The internet has a large suite of protocols to cover many situations. In creating web-based applications and programming interfaces, software developers commonly use three of these communication protocols to describe the state of the network and the ways that data packets are moved across the network:



*  ICMP, Internet Control Message Protocol, part of the internet protocol suite defined in RFC 792.
*  TCP, Transmission Control Protocol
*  UDP, User Datagram Protocol



The protocols that are used for a particular implementation of, say, an API call, can influence the overall behavior of your network. So it is worthwhile to understand the basic differences between them. If you need more information, many good articles are available on the internet with detailed descriptions of the protocols.



  ICMP 

ICMP is a control protocol, meaning that it is designed to carry information about the status of the network itself. It is essentially a network layer (OSI layer 3) error-reporting and error-control protocol for the network. The best-known examples of ICMP in practice are the ping and traceroute utilities. The ping utility uses ICMP to probe remote hosts for responsiveness and overall round-trip time of the probe messages. The traceroute utility uses ICMP to discover and trace network routes that the ICMP packets take when they travel to their destination.

What developers need to know is that ICMP packets have no TCP or UDP port numbers that are associated with them because port numbers are a layer 4 (transport layer) construct.





  TCP and UDP 

Both Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) are OSI layer 4 transport protocols. These protocols are used to pass the actual data. The main difference between TCP and UDP, from a developer's perspective, is how they handle packet order.

TCP is a connection-oriented protocol, it guarantees that all sent packets reach the destination in the correct order.

Alternatively, UDP is a connection-less protocol. Communication is datagram-oriented, so the integrity is guaranteed only on the single datagram. Datagrams reach a destination and can arrive out of order, or possibly they don't arrive at all.

Typically, UDP is used for real-time communication, where a little percentage of the packet loss rate is preferable to the overhead of a TCP connection.
* [TLS requirements](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-encryption-in-transitshared-encryption-in-transit-tls-requirements)



* [TLS protocol requirements](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-encryption-in-transitshared-encryption-in-transit-tls-protocol-requirements)
* [Key size requirements](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-encryption-in-transitshared-encryption-in-transit-tls-key-size-requirements)
* [Acceptable cipher suites](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-encryption-in-transitshared-encryption-in-transit-tls-cipher-suites)
* [Certificate requirements](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-encryption-in-transitshared-encryption-in-transit-tls-cert-requirements)



* [Related controls in IBM Cloud Framework for Financial Services](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-encryption-in-transitshared-encryption-in-transit-related-controls)
* [Next steps](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-encryption-in-transitshared-encryption-in-transit-next-steps)







 Business continuity and disaster recovery 

[Business continuity and disaster recovery overview](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-bcdrshared-bcdr)
[Zones](https://cloud.ibm.com/docs-content/v1/content/6a28e4ae2660b609a18e90e1239ed772f80373d6/transit-gateway/includes/solution-tutorials/includes/solution-tutorials/images/vpc-transit/vpc-transit-zones.svg)

Zones

This diagram shows the traffic flow. Only the enterprise <-> spoke is passing through the firewall:

Zoom

![Traffic flow](https://cloud.ibm.com/docs-content/v1/content/6a28e4ae2660b609a18e90e1239ed772f80373d6/transit-gateway/includes/solution-tutorials/includes/solution-tutorials/images/vpc-transit/vpc-transit-part1-fw.svg)

Traffic flow

This was achieved with Direct Link, Transit Gateway and VPC routing. All zones are configured similarly and the diagram below shows the details of zone 1:

Zoom

![VPC Layout](https://cloud.ibm.com/docs-content/v1/content/6a28e4ae2660b609a18e90e1239ed772f80373d6/transit-gateway/includes/solution-tutorials/includes/solution-tutorials/images/vpc-transit/vpc-transit-part1.svg)

VPC Layout

The phantom address prefixes in the transit are used to advertise routes. The CIDR 10.1.0.0/16 covers transit and the spokes and is passed through Direct Link to the enterprise as an advertised route. Similarly the CIDR 192.168.0.0/24 covers the enterprise and is passed through the Transit Gateway to the spokes as an advertised route.

Egress routes in the spokes route traffic to the firewall-router. Ingress routes in the transit route enterprise <-> spoke traffic through the firewall-router.





 Step 1: Provision initial VPC resources routing all intra VPC traffic through the firewall-router
* 10.1.0.0/16 Dallas 1.
* 10.2.0.0/16 Dallas 2.
* 10.3.0.0/16 Dallas 3.



The transit VPC will only use a subset of each zone:



* 10.1.0.0/24 Dallas 1.
* 10.2.0.0/24 Dallas 2.
* 10.3.0.0/24 Dallas 3.



The address prefixes for the transit itself is expanded to include all of the spokes to allow the routes to flow to the enterprise.

With these additional address prefixes:



* Spoke VPCs learn that traffic spoke -> (192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24) should pass through the Transit Gateway tgw-link.
* Enterprise will learn that traffic enterprise -> (10.1.0.0/16, 10.2.0.0/16 10.3.0.0/16) should pass through the IBM Cloud® Direct Link









 Step 7: Removing the firewall for Transit destination traffic 

The IBM Cloud VPC uses the industry standard state-based routing for secure TCP connection tracking. It requires that the TCP connections use the same path on the way in as the way out. One exception is Direct Server Return used by routers like [Network Load Balancers](https://cloud.ibm.com/docs/vpc?topic=vpc-network-load-balancers). It allows incoming connections from the enterprise to pass through the firewall to the transit test instance and then return directly to the originator.

Zoom

![Incoming connections from the enterprise pass through the firewall](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/vpc-transit/vpc-transit-routing-green.svg)

Incoming connections from the enterprise pass through the firewall
* [Solution](https://cloud.ibm.com/docs/containers?topic=containers-cs_uc_transportuc_shipping_solution)
* [Results](https://cloud.ibm.com/docs/containers?topic=containers-cs_uc_transportuc_shipping_results)



* [Airline delivers innovative Human Resources (HR) benefits site in under 3 weeks](https://cloud.ibm.com/docs/containers?topic=containers-cs_uc_transportuc_airline)



* [Context](https://cloud.ibm.com/docs/containers?topic=containers-cs_uc_transportuc_airline_context)
* [Solution](https://cloud.ibm.com/docs/containers?topic=containers-cs_uc_transportuc_airline_solution)
* [Results](https://cloud.ibm.com/docs/containers?topic=containers-cs_uc_transportuc_airline_results)





[Government use cases for IBM Cloud](https://cloud.ibm.com/docs/containers?topic=containers-cs_uc_govcs_uc_gov)



* [Regional government improves collaboration and velocity with community Developers who combine public-private data](https://cloud.ibm.com/docs/containers?topic=containers-cs_uc_govuc_data_mashup)



* [Context](https://cloud.ibm.com/docs/containers?topic=containers-cs_uc_govuc_data_mashup_context)
* [Solution](https://cloud.ibm.com/docs/containers?topic=containers-cs_uc_govuc_data_mashup_solution)
* [Results](https://cloud.ibm.com/docs/containers?topic=containers-cs_uc_govuc_data_mashup_results)



* [Large public port secures exchange of port data and shipping manifests that connect public and private organizations](https://cloud.ibm.com/docs/containers?topic=containers-cs_uc_govuc_port)
The colons are shorthand for first (or config_tf) and last (vpe_dns_forwarding_rules_tf). The -p prints the layers:

./apply.sh -p : :
7. Apply all of the layers in part one and described above.

./apply.sh : spokes_egress_tf



If you were following along in part one some additional ingress routes were added to the transit ingress route table to avoid routing through the firewall-router. In this step these have been removed and the transit ingress route table has just these entries so that all incoming traffic for a zone is routed to the firewall-router in the same zone:



 Zone Destination Next hop 

 Dallas 1 0.0.0.0/0 10.1.0.196 
 Dallas 2 0.0.0.0/0 10.2.0.196 
 Dallas 3 0.0.0.0/0 10.3.0.196 



To observe this:



1. Open the [VPCs](https://cloud.ibm.com/vpc-ext/network/vpcs) in the IBM Cloud.
2. Select the transit VPC and notice the Address prefixes displayed.
3. Find the additional address prefixes for the enterprise CIDR blocks and note the associated zones.







 Route Spoke and Transit to the firewall-router 

Routing all cloud traffic originating at the spokes through the transit VPC firewall-router in the same zone as the originating instance is accomplished by these routes in the spoke's default egress routing table (shown for Dallas/us-south):



 Zone Destination Next hop 

 Dallas 1 10.0.0.0/8 10.1.0.196 
 Dallas 2 10.0.0.0/8 10.2.0.196 
 Dallas 3 10.0.0.0/8 10.3.0.196 



Similarly in the transit VPC route all enterprise and cloud traffic through the firewall-router in the same zone as the originating instance.
Networking - interconnectivity <br><br> * [IBM Cloud® Direct Link (2.0)](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-aboutservices-networking-direct-link)[6]<br> * [IBM Cloud® Transit Gateway](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-aboutservices-networking-transit-gateway)<br><br><br> 
 Storage <br><br> * [IBM® Cloud Block Storage for Virtual Private Cloud](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-aboutservices-storage-block)<br> * [IBM Cloud® Object Storage](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-aboutservices-storage-cos)<br><br><br> 
 Security <br><br> * [IBM Cloud® Hyper Protect Crypto Services](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-aboutservices-security-hpcs)<br><br><br> <br><br> * [IBM Cloud® Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-getting-started)<br> * [IBM Cloud® App ID](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-aboutservices-security-app-id)<br><br><br>
Transport layer protocols act as liaisons between the application layer protocols and the services that are provided by the network. Client VPN for VPC supports the following protocols:

UDP is recommended for optimal performance; TCP for reliability.



* User Datagram Protocol (UDP)

The User Datagram Protocol (UDP) is a simple, lightweight protocol with minimum overhead. If a process wants to send a small message and doesn't care about reliability, it can use UDP. Sending a message by using UDP takes much less time than using TCP. It performs little error checking and does not add any advantages to IP services except to provide process-to-process communication instead of host-to-host communication.
* Transmission Control Protocol (TCP)

Transmission Control Protocol (TCP) is a reliable but complex transport-layer protocol. TCP adds connection-oriented features and reliability to IP services.

TCP is a stream delivery service that guarantees delivery of data streams sent from one host to another without duplication or lost data. Since packet transfer is not reliable, a technique known as positive acknowledgment with retransmission is used to guarantee reliability of packet transfers. This fundamental technique requires the receiver to respond with an acknowledgment message as it receives the data.

The sender keeps a record of each packet it sends, and waits for acknowledgment before sending the next packet. The sender also keeps a timer from when the packet was sent, and retransmits a packet if the timer expires. This timer is needed in case a packet becomes lost or corrupted.







 Full versus split-tunnel mode 

When a VPN connection is set up, an encrypted tunnel is created over the internet to the VPN server. The VPN connection appears as a virtual network interface to the computer in addition to the existing LAN interface. You can now use both interfaces simultaneously by sending the private traffic destined to the VPC inside the VPN tunnel and the public traffic (internet traffic) over the other interface (outside the VPN tunnel). When the traffic is split between the VPN interface and other interfaces, split tunneling is said to be in use.
Understanding Network Flows 

Before provisioning your VPC network, it's important to understand what your connectivity requirements will be. Are you an existing IBM Cloud Classic Infrastructure user which requires connectivity to those resources? Will you require private connectivity to on-prem resources? How will interconnectivity between multiple VPCs be managed? In this section of the deployment guide, the underlying network flows which support these types of scenarios will be reviewed.

Taking the time to understand and plan network flows is a key ingredient to successful deployment. As you review this section, consider the connectivity requirements you have today but may also need in the future.



 Journey Map 

![Architecture](https://cloud.ibm.com/docs-content/v1/content/d50364af907081c3c38f99c11f35dd9cab4b2510/vpc-journey/images/network-flows/journey-map.png)





 Overview 

The following network flows will be covered. Please note that while these represent some common connectivity requirements, not all may be required in your environment.



1. VPC to/from On-Prem connectivity allows for private communication between your on-prem network and the cloud based VPC network, and allows you to access VPC based resources as if they were running locally. The connection also provides a private path for VPC based applications to communicate back to resources on your local network.
2. VPC to/from VPC and/or Classic Infrastructure connectivity allows for private communication between multiple VPCs via transit gateway. If you have existing resources still running on the IBM Cloud Classic Infrastructure, a similar flow can also be used to facilitate communication between VPC and Classic infrastructure resources.
3. VPC to/from VMware (in Classic Infrastructure) connectivity allows for private communication between your VPC and Virtual Machines (VMs) running in an IBM Cloud VMware on Classic Infrastructure environment. Typically, in a VMware deployment, an overlay network is defined which allows for BYOIP.
* Simple interconnectivity – logical network connections are established easily over any physical connection such as public internet, private VPN, or direct link.
* Layer 2 extension – on-premises networks are extended into the cloud. These networks include on-premises subnets and IP addressing.
* Encryption – network traffic is securely encrypted between the two sides.
* Optimized network – selects the best connection and efficiently floods the connection so that network traffic is moved as fast as possible.
* Data deduplication – as much as 50% reduction in network traffic can be achieved
* vMotion migration - a single running system can be moved between HCX enabled sites by using the VMware vMotion protocol with no service interruption.
* Bulk migration - multiple systems can be moved in parallel using VMware vSphere® Replication protocol between HCX enabled sites.
* Scheduled migration – any number of VMs can be replicated to the destination site and then activated on that site at a designated time. The replication replaces the systems that are running on the originating site.
* Migration of security policies – if NSX is used on-premises, any security policies or firewalls are moved along with the workload.





 Related links 



* [Glossary of HCX components and terms](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-hcxclient-components)
* [HCX Client deployment](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-hcxclient-vcs-client-deployment)
* [HCX on-premises Service Mesh](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-hcxclient-vcs-mesh-deployment)
* [VMware Hybrid Cloud migrations](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-hcxclient-migrations)