diff --git a/sandbox/Sandbox1/configurations.rst b/sandbox/Sandbox1/configurations.rst index 8b9b148fb..1db04fec7 100644 --- a/sandbox/Sandbox1/configurations.rst +++ b/sandbox/Sandbox1/configurations.rst @@ -70,7 +70,7 @@ You may also observe the functioning NAT rule in action by pinging any public IP * In a terminal window: - 1. SSH to server **srv04-nyc**: ``ssh demo@166.88.17.24 -p 30064``. + 1. SSH to server **srv04-nyc**: ``ssh demo@216.172.128.201 -p 30064``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping4 1.1.1.1`` diff --git a/sandbox/Sandbox1/creating-services.rst b/sandbox/Sandbox1/creating-services.rst index 46f608371..6edc9c0f9 100644 --- a/sandbox/Sandbox1/creating-services.rst +++ b/sandbox/Sandbox1/creating-services.rst @@ -17,7 +17,7 @@ Let's create a V-Net service to give server **srv05-nyc** the ability to reach i * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.24 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.201 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Type ``ip route ls`` and we can see **192.168.46.1** is configured as the default gateway, indicated by the "**default via 192.168.46.1 dev eth1 proto kernel onlink**" line in the output. 4. Start a ping session towards the default gateway: ``ping 192.168.46.1`` @@ -90,7 +90,7 @@ Now that we have both internal and external facing services, we can aim for our * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.24 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.201 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session towards any public IP address (e.g. ``ping 1.1.1.1``). 4. Keep the ping running as an indicator for when the service starts to work. @@ -176,7 +176,7 @@ Now that **srv05-nyc** can communicate with both internal and external hosts, le * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.24 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.201 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping 1.1.1.1``. 4. If the previous steps were followed, you should see successful ping replies in the form of "**64 bytes from 1.1.1.1: icmp_seq=55 ttl=62 time=1.23 ms**". diff --git a/sandbox/Sandbox1/index.rst b/sandbox/Sandbox1/index.rst index 7d1105025..f01bc8615 100644 --- a/sandbox/Sandbox1/index.rst +++ b/sandbox/Sandbox1/index.rst @@ -7,7 +7,7 @@ ------------------------------------------------------------------------------------------------ Sandbox1 # Sandbox name Uppercase(case sensitive) sandbox1 # Sandbox name Lowercase - 166.88.17.24 # Hypervisor PUBLIC IP + 216.172.128.201 # Hypervisor PUBLIC IP 10.254.45.0/24 # *STATIC NO NEED TO REPLACE* MANAGEMENT Allocation/Subnet 10.254.46.0/24 # *STATIC NO NEED TO REPLACE* LOOPBACK Allocation/Subnet 192.168.44.0/24 # *STATIC NO NEED TO REPLACE* ROH Allocation/Subnet diff --git a/sandbox/Sandbox1/sandbox-info.rst b/sandbox/Sandbox1/sandbox-info.rst index 2c190e71a..df2fb7b10 100644 --- a/sandbox/Sandbox1/sandbox-info.rst +++ b/sandbox/Sandbox1/sandbox-info.rst @@ -49,11 +49,11 @@ Example pre-configured Netris services: .. code-block:: shell-session - srv01-nyc: ssh demo@166.88.17.24 -p 30061 - srv02-nyc: ssh demo@166.88.17.24 -p 30062 - srv03-nyc: ssh demo@166.88.17.24 -p 30063 - srv04-nyc: ssh demo@166.88.17.24 -p 30064 - srv05-nyc: ssh demo@166.88.17.24 -p 30065 + srv01-nyc: ssh demo@216.172.128.201 -p 30061 + srv02-nyc: ssh demo@216.172.128.201 -p 30062 + srv03-nyc: ssh demo@216.172.128.201 -p 30063 + srv04-nyc: ssh demo@216.172.128.201 -p 30064 + srv05-nyc: ssh demo@216.172.128.201 -p 30065 Kubernetes cluster diff --git a/sandbox/Sandbox10/configurations.rst b/sandbox/Sandbox10/configurations.rst index 9460270c0..737adcd37 100644 --- a/sandbox/Sandbox10/configurations.rst +++ b/sandbox/Sandbox10/configurations.rst @@ -62,7 +62,7 @@ You may also observe the functioning NAT rule in action by pinging any public IP * In a terminal window: - 1. SSH to server **srv04-nyc**: ``ssh demo@166.88.17.19 -p 30064``. + 1. SSH to server **srv04-nyc**: ``ssh demo@216.172.128.210 -p 30064``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping4 1.1.1.1`` diff --git a/sandbox/Sandbox10/creating-services.rst b/sandbox/Sandbox10/creating-services.rst index fb5712878..015a7dfd8 100644 --- a/sandbox/Sandbox10/creating-services.rst +++ b/sandbox/Sandbox10/creating-services.rst @@ -14,7 +14,7 @@ Let's create a V-Net service to give server **srv05-nyc** the ability to reach i * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.19 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.210 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Type ``ip route ls`` and we can see **192.168.46.1** is configured as the default gateway, indicated by the "**default via 192.168.46.1 dev eth1 proto kernel onlink**" line in the output. 4. Start a ping session towards the default gateway: ``ping 192.168.46.1`` @@ -86,7 +86,7 @@ Now that we have both internal and external facing services, we can aim for our * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.19 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.210 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session towards any public IP address (e.g. ``ping 1.1.1.1``). 4. Keep the ping running as an indicator for when the service starts to work. @@ -168,7 +168,7 @@ Now that **srv05-nyc** can communicate with both internal and external hosts, le * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.19 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.210 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping 1.1.1.1``. 4. If the previous steps were followed, you should see successful ping replies in the form of "**64 bytes from 1.1.1.1: icmp_seq=55 ttl=62 time=1.23 ms**". diff --git a/sandbox/Sandbox10/index.rst b/sandbox/Sandbox10/index.rst index 97891e80b..a6a5f4852 100644 --- a/sandbox/Sandbox10/index.rst +++ b/sandbox/Sandbox10/index.rst @@ -7,7 +7,7 @@ ------------------------------------------------------------------------------------------------ Sandbox10 # Sandbox name Uppercase(case sensitive) sandbox10 # Sandbox name Lowercase - 166.88.17.19 # Hypervisor PUBLIC IP + 216.172.128.210 # Hypervisor PUBLIC IP 10.254.45.0/24 # *STATIC NO NEED TO REPLACE* MANAGEMENT Allocation/Subnet 10.254.46.0/24 # *STATIC NO NEED TO REPLACE* LOOPBACK Allocation/Subnet 192.168.44.0/24 # *STATIC NO NEED TO REPLACE* ROH Allocation/Subnet diff --git a/sandbox/Sandbox10/sandbox-info.rst b/sandbox/Sandbox10/sandbox-info.rst index 1c0180c15..9a6a8a42d 100644 --- a/sandbox/Sandbox10/sandbox-info.rst +++ b/sandbox/Sandbox10/sandbox-info.rst @@ -46,11 +46,11 @@ Example pre-configured Netris services: .. code-block:: shell-session - srv01-nyc: ssh demo@166.88.17.19 -p 30061 - srv02-nyc: ssh demo@166.88.17.19 -p 30062 - srv03-nyc: ssh demo@166.88.17.19 -p 30063 - srv04-nyc: ssh demo@166.88.17.19 -p 30064 - srv05-nyc: ssh demo@166.88.17.19 -p 30065 + srv01-nyc: ssh demo@216.172.128.210 -p 30061 + srv02-nyc: ssh demo@216.172.128.210 -p 30062 + srv03-nyc: ssh demo@216.172.128.210 -p 30063 + srv04-nyc: ssh demo@216.172.128.210 -p 30064 + srv05-nyc: ssh demo@216.172.128.210 -p 30065 Kubernetes cluster diff --git a/sandbox/Sandbox11/configurations.rst b/sandbox/Sandbox11/configurations.rst index 1c1b9a2ea..df738cbae 100644 --- a/sandbox/Sandbox11/configurations.rst +++ b/sandbox/Sandbox11/configurations.rst @@ -70,7 +70,7 @@ You may also observe the functioning NAT rule in action by pinging any public IP * In a terminal window: - 1. SSH to server **srv04-nyc**: ``ssh demo@50.117.27.82 -p 30064``. + 1. SSH to server **srv04-nyc**: ``ssh demo@216.172.128.211 -p 30064``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping4 1.1.1.1`` diff --git a/sandbox/Sandbox11/creating-services.rst b/sandbox/Sandbox11/creating-services.rst index 8118eb792..3cdea0f68 100644 --- a/sandbox/Sandbox11/creating-services.rst +++ b/sandbox/Sandbox11/creating-services.rst @@ -17,7 +17,7 @@ Let's create a V-Net service to give server **srv05-nyc** the ability to reach i * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@50.117.27.82 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.211 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Type ``ip route ls`` and we can see **192.168.46.1** is configured as the default gateway, indicated by the "**default via 192.168.46.1 dev eth1 proto kernel onlink**" line in the output. 4. Start a ping session towards the default gateway: ``ping 192.168.46.1`` @@ -90,7 +90,7 @@ Now that we have both internal and external facing services, we can aim for our * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@50.117.27.82 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.211 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session towards any public IP address (e.g. ``ping 1.1.1.1``). 4. Keep the ping running as an indicator for when the service starts to work. @@ -176,7 +176,7 @@ Now that **srv05-nyc** can communicate with both internal and external hosts, le * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@50.117.27.82 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.211 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping 1.1.1.1``. 4. If the previous steps were followed, you should see successful ping replies in the form of "**64 bytes from 1.1.1.1: icmp_seq=55 ttl=62 time=1.23 ms**". diff --git a/sandbox/Sandbox11/index.rst b/sandbox/Sandbox11/index.rst index 2f648ba50..8e43bbe49 100644 --- a/sandbox/Sandbox11/index.rst +++ b/sandbox/Sandbox11/index.rst @@ -7,7 +7,7 @@ ------------------------------------------------------------------------------------------------ Sandbox11 # Sandbox name Uppercase(case sensitive) sandbox11 # Sandbox name Lowercase - 50.117.27.82 # Hypervisor PUBLIC IP + 216.172.128.211 # Hypervisor PUBLIC IP 10.254.45.0/24 # *STATIC NO NEED TO REPLACE* MANAGEMENT Allocation/Subnet 10.254.46.0/24 # *STATIC NO NEED TO REPLACE* LOOPBACK Allocation/Subnet 192.168.44.0/24 # *STATIC NO NEED TO REPLACE* ROH Allocation/Subnet diff --git a/sandbox/Sandbox11/sandbox-info.rst b/sandbox/Sandbox11/sandbox-info.rst index 6d39bb6cc..a623002cd 100644 --- a/sandbox/Sandbox11/sandbox-info.rst +++ b/sandbox/Sandbox11/sandbox-info.rst @@ -49,11 +49,11 @@ Example pre-configured Netris services: .. code-block:: shell-session - srv01-nyc: ssh demo@50.117.27.82 -p 30061 - srv02-nyc: ssh demo@50.117.27.82 -p 30062 - srv03-nyc: ssh demo@50.117.27.82 -p 30063 - srv04-nyc: ssh demo@50.117.27.82 -p 30064 - srv05-nyc: ssh demo@50.117.27.82 -p 30065 + srv01-nyc: ssh demo@216.172.128.211 -p 30061 + srv02-nyc: ssh demo@216.172.128.211 -p 30062 + srv03-nyc: ssh demo@216.172.128.211 -p 30063 + srv04-nyc: ssh demo@216.172.128.211 -p 30064 + srv05-nyc: ssh demo@216.172.128.211 -p 30065 Kubernetes cluster diff --git a/sandbox/Sandbox12/configurations.rst b/sandbox/Sandbox12/configurations.rst index 8381ad796..1f87facf0 100644 --- a/sandbox/Sandbox12/configurations.rst +++ b/sandbox/Sandbox12/configurations.rst @@ -1,83 +1,91 @@ -.. _s12-pre-configured: +.. _2607:f358:11:ffc0::18: ******************************** Provided Example Configurations ******************************** -Once you log into the Netris Controller, you will find that certain services have already been pre-configured for you to explore and interact with. You can also learn how to create some of these services yourself by following the step-by-step instructions in the :ref:`"Learn by Creating Services"` document. + +.. contents:: + :local: + +Once you log into the Netris Controller, you will find that certain services have already been pre-configured for you to explore and interact with. You can also learn how to create some of these services yourself by following the step-by-step instructions in the :ref:`"Learn by Creating Services"` document. V-Net (Ethernet/Vlan/VXlan) Example =================================== -After logging into the Netris Controller by visiting `https://sandbox12.netris.io `_ and navigating to **Services → V-Net**, you will find a V-Net service named "**vnet-example**" already configured for you as an example. +To access the V-Net service example, first log into the Netris Controller by visiting `https://Sandbox12.netris.io `_ and navigating to **Services → V-Net**, where you will find a pre-configured V-Net service named "**vnet-example**" available as an example. + +To examine the service settings, select **Edit** from the **Actions** menu indicated by three vertical dots (**⋮**) on the right side of the "**vnet-example**" service, where you'll see that the V-Net service is configured with VLAN ID **45** in order to enable **EVPN Multihoming** on the underlying switches. -If you examine the particular service settings ( select **Edit** from the **Actions** menu indicated by three vertical dots (**⋮**) on the right side of the "**vnet-example**" service), you will find that the services is configured on the second port of **switch 21** named "**swp2(swp2)@sw21-nyc (Admin)**". +You'll also see that the V-Net service is configured with both an IPv4 gateway (**192.168.45.1**) from the "**192.168.45.0/24 (EXAMPLE)**" subnet and an IPv6 gateway (**45.38.161.1251**) from the "**45.38.161.125/64 (EXAMPLE IPv6)**" subnet. -The V-Net servicers is also configured with both an IPv4 and IPv6 gateway, **192.168.45.1** (from the "**192.168.45.0/24 (EXAMPLE)**" subnet) and **2607:f358:11:ffcc::1** (from the "**2607:f358:11:ffcc::/64 (EXAMPLE IPv6)**" subnet) respectively. +Additionally, the V-Net service is configured to utilize network interfaces on both switches 21 and 22. Specifically, it is connected to **swp4(swp4)@sw21-nyc (Admin)** on switch 21 and **swp4(swp4)@sw22-nyc (Admin)** on switch 22. You may also verify that the service is working properly from within the GUI: (*\*Fields not specified should remain unchanged and retain default values*) -1. Navigate to **Net → Looking Glass**. -2. Select switch "**sw21-nyc(10.254.46.21)**" (the switch the "**vnet-example**" service is configured on) from the **Select device** drop-down menu. -3. Select "**Ping**" from the **Command** drop-down menu. -4. Type ``192.168.45.64`` (the IP address of **srv04-nyc** connected to **swp2@sw21-nyc**) in the field labeled **IPv4 address**. -5. Click **Submit**. +1. Navigate to **Network → Looking Glass**. +2. Make sure "**vpc-1:Default**" is selected from the **VPC** drop-down menu. +3. Select "**SoftGate1(1122)**" from the **Hardware** drop-down menu. +4. Leave the "**Family: IPV4**" as the selected choice from the **Adrress Family** drop-down menu. +5. Select "**Ping**" from the **Command** drop-down menu. +6. Leave the "**Selecet IP address**" as the selected choice from the **Source** drop-down menu. +7. Type ``192.168.45.64`` (the IP address configured on **bond0.45** on **srv04-nyc**) in the field labeled **IPv4 address**. +8. Click **Submit**. -The result should look similar to the output below, indicating that the communication between switch **sw21-nyc** and server **srv04-nyc** is working properly thanks to the configured V-Net service. +The result should look similar to the output below, indicating that the communication between SoftGate **SoftGate1** and server **srv04-nyc** is working properly thanks to the configured V-Net service. .. code-block:: shell-session - sw21-nyc# ip vrf exec Vrf_netris ping -c 5 192.168.45.64 + SoftGate1# ping -c 5 192.168.45.64 PING 192.168.45.64 (192.168.45.64) 56(84) bytes of data. - 64 bytes from 192.168.45.64: icmp_seq=1 ttl=64 time=0.562 ms - 64 bytes from 192.168.45.64: icmp_seq=2 ttl=64 time=0.745 ms - 64 bytes from 192.168.45.64: icmp_seq=3 ttl=64 time=0.690 ms - 64 bytes from 192.168.45.64: icmp_seq=4 ttl=64 time=0.737 ms - 64 bytes from 192.168.45.64: icmp_seq=5 ttl=64 time=0.666 ms - + 64 bytes from 192.168.45.64: icmp_seq=1 ttl=61 time=6.29 ms + 64 bytes from 192.168.45.64: icmp_seq=2 ttl=61 time=5.10 ms + 64 bytes from 192.168.45.64: icmp_seq=3 ttl=61 time=4.82 ms + 64 bytes from 192.168.45.64: icmp_seq=4 ttl=61 time=4.82 ms + 64 bytes from 192.168.45.64: icmp_seq=5 ttl=61 time=4.79 ms --- 192.168.45.64 ping statistics --- - 5 packets transmitted, 5 received, 0% packet loss, time 4092ms - rtt min/avg/max/mdev = 0.562/0.680/0.745/0.065 ms + 5 packets transmitted, 5 received, 0% packet loss, time 4002ms + rtt min/avg/max/mdev = 4.787/5.161/6.285/0.572 ms -If you are interested in learning how to create a V-Net service yourself, please refer to the step-by-step instructions found in the :ref:`"V-Net (Ethernet/Vlan/VXlan)"` section of the :ref:`"Learn by Creating Services"` document. +If you are interested in learning how to create a V-Net service yourself, please refer to the step-by-step instructions found in the :ref:`"V-Net (Ethernet/Vlan/VXlan)"` section of the :ref:`"Learn by Creating Services"` document. -More details about V-Net (Ethernet/Vlan/VXlan) can be found on the the :ref:`"V-NET"` page. +More details about V-Net (Ethernet/Vlan/VXlan) can be found on the the :ref:`V-Net"` page. E-BGP (Exterior Border Gateway Protocol) Example ================================================ -Navigate to **Net → E-BGP**. Here, aside from the necessary system generated IPv4/IPv6 E-BGP peer connections between the two border routers ( **SoftGate1** & **SoftGate2** ) and the rest of the switching fabric (which can be toggled on/off using the **Show System Generated** toggle at the top of the page), you will also find two E-BGP sessions named "**iris-isp1-ipv4-example**" and "**iris-isp1-ipv6-example**" configured as example with **IRIS ISP1**. This ensures communication between the internal network with the Internet. +Navigate to **Network → E-BGP**. Here, aside from the required system generated IPv4/IPv6 E-BGP peer connections between the two border routers ( **SoftGate1** & **SoftGate2** ) and the rest of the switching fabric (which can be toggled on/off using the **Show System Generated** toggle at the top of the page), you will also find two E-BGP sessions named "**iris-isp1-ipv4-example**" and "**iris-isp1-ipv6-example**" configured as examples with **IRIS ISP1**. This ensures communication between the internal network and the Internet. You may examine the particular session configurations of the E-BGP connections by selecting **Edit** from the **Actions** menu indicated by three vertical dots (**⋮**) on the right side of either the "**iris-isp1-ipv4-example**" and "**iris-isp1-ipv6-example**" connections. You may also expand the **Advanced** section located toward the bottom of the **Edit** window to be able to access the more advanced settings available while configuring an E-BGP session. -If you are interested in learning how to create an additional E-BGP session with **IRIS ISP2** in order to make the Sandbox upstream connections fault tolerant yourself, please refer to the step-by-step instructions found in the :ref:`"E-BGP (Exterior Border Gateway Protocol)"` section of the :ref:`"Learn by Creating Services"` document. +If you are interested in learning how to create an additional E-BGP session with **IRIS ISP2** in order to make the Sandbox upstream connections fault tolerant yourself, please refer to the step-by-step instructions found in the :ref:`"E-BGP (Exterior Border Gateway Protocol)"` section of the :ref:`"Learn by Creating Services"` document. More details about E-BGP (Exterior Border Gateway Protocol) can be found on the the :ref:`"BGP"` page. NAT (Network Address Translation) Example ========================================= -Navigate to **Net → NAT** and you will find a NAT rule named "**NAT Example**" configured as an example for you. The configured "**SNAT**" rule ensures that there can be communication between the the private "**192.168.45.0/24 (EXAMPLE)**" subnet and the Internet. +Navigate to **Network → NAT** and you will find a NAT rule named "**NAT Example**" configured as an example for you. The configured "**SNAT**" rule ensures that there can be communication between the the private "**192.168.45.0/24 (EXAMPLE)**" subnet and the Internet. You can examine the particular settings of the NAT rule by clicking **Edit** from the **Actions** menu indicated by three vertical dots (**⋮**) on the right side of the "**NAT Example**" service. You may also observe the functioning NAT rule in action by pinging any public IP address (e.g. **1.1.1.1**) from the **srv04-nyc** server. -* In a terminal window: - - 1. SSH to server **srv04-nyc**: ``ssh demo@50.117.27.83 -p 30064``. +* In a terminal window: + + 1. SSH to server **srv04-nyc**: ``ssh demo@sandbox12 -p 30064``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping4 1.1.1.1`` You will see replies in the form of "**64 bytes from 1.1.1.1: icmp_seq=1 ttl=62 time=1.10 ms**" indicating proper communication with the **1.1.1.1** public IP address. -If you are interested in learning how to create a NAT rule yourself, please refer to the step-by-step instructions found in the :ref:`"NAT (Network Address Translation)"` section of the :ref:`"Learn by Creating Services"` document. +If you are interested in learning how to create a NAT rule yourself, please refer to the step-by-step instructions found in the :ref:`"NAT (Network Address Translation)"` section of the :ref:`"Learn by Creating Services"` document. More details about NAT (Network Address Translation) can be found on the :ref:`"NAT"` page. ACL (Access Control List) Example ================================= -Navigate to **Services → ACL** and you will find an ACL services named "**V-Net Example to WAN**" set up as an example for you. This particular ACL ensures that the connectivity between the the private "**192.168.45.0/24 (EXAMPLE)**" subnet and the Internet is permitted through all protocols and ports, even in a scenario where the the "**ACL Default Policy**" for the "**US/NYC**" site configured under **Net → Sites** in our Sandbox is changed from **Permit** to **Deny**. +Navigate to **Services → ACL** and you will find an ACL services named "**V-Net Example to WAN**" set up as an example for you. This particular ACL ensures that the connectivity between the the private "**192.168.45.0/24 (EXAMPLE)**" subnet and the Internet is permitted through all protocols and ports, even in a scenario where the the "**ACL Default Policy**" for the "**US/NYC**" site configured under **Network → Sites** in our Sandbox is changed from **Permit** to **Deny**. You can examine the particular settings of this ACL policy by selecting **Edit** from the **Actions** menu indicated by three vertical dots (**⋮**) on the right side of the "**V-Net Example to WAN**" ACL policy. -By utilizing ACLs, you can impose granular controls and implement policies that would permit or deny particular connections of any complexity. If you are interested in learning how to create ACL policies yourself, please refer to the step-by-step instructions found in the :ref:`"ACL (Access Control List)"` section of the :ref:`"Learn by Creating Services"` document. +By utilizing ACLs, you can impose granular controls and implement policies that would permit or deny particular connections of any complexity. If you are interested in learning how to create ACL policies yourself, please refer to the step-by-step instructions found in the :ref:`"ACL (Access Control List)"` section of the :ref:`"Learn by Creating Services"` document. -More details about ACL (Access Control List) can be found on the :ref:`"ACL"` page. \ No newline at end of file +More details about ACL (Access Control List) can be found on the :ref:`"ACL"` page. diff --git a/sandbox/Sandbox12/creating-services.rst b/sandbox/Sandbox12/creating-services.rst index fceda0087..fd9834bcd 100644 --- a/sandbox/Sandbox12/creating-services.rst +++ b/sandbox/Sandbox12/creating-services.rst @@ -1,12 +1,15 @@ -.. _s12-learn-by-doing: +.. _s12-pre-configured: ************************** Learn by Creating Services ************************** +.. contents:: + :local: + Following these short exercises we will be able to demonstrate how the :ref:`Netris Controller`, in conjunction with the :ref:`Netris Agents` deployed on the switches and SoftGates, is able to intelligently and automagically deploy the necessary configurations across the network fabric to provision the desired services within a matter of seconds. -.. _s12-v-net: +.. _s12-e-bgp: V-Net (Ethernet/Vlan/VXlan) =========================== @@ -14,34 +17,35 @@ Let's create a V-Net service to give server **srv05-nyc** the ability to reach i * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@50.117.27.83 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@sandbox12 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Type ``ip route ls`` and we can see **192.168.46.1** is configured as the default gateway, indicated by the "**default via 192.168.46.1 dev eth1 proto kernel onlink**" line in the output. - 4. Start a ping session towards the default gateway: ``ping 192.168.46.1`` + 4. Start a ping session towards the default gateway: ``ping 192.168.46.1`` 5. Keep the ping running as an indicator for when the service becomes fully provisioned. 6. Until the service is provisioned, we can see that the destination is not reachable judging by the outputs in the form of "**From 192.168.46.64 icmp_seq=1 Destination Host Unreachable**". * In a web browser: (*\*Fields not specified should remain unchanged and retain default values*) - 1. Log into the Netris Controller by visiting `https://sandbox12.netris.io `_ and navigate to **Services → V-Net**. + 1. Log into the Netris Controller by visiting `https://Sandbox12.netris.io `_ and navigate to **Services → V-Net**. 2. Click the **+ Add** button in the top right corner of the page to get started with creating a new V-Net service. 3. Define a name in the **Name** field (e.g. ``vnet-customer``). 4. From the **Sites** drop-down menu, select "**US/NYC**". - 5. From the **Owner** drop-down menu, select "**Demo**". - 6. From the **IPv4 Gateway** drop-down menu, select the "**192.168.46.0/24(CUSTOMER)**" subnet. - 7. The first available IP address "**192.168.46.1**" is automatically selected in the second drop-down menu of the list of IP addresses. This matches the results of the ``ip route ls`` command output on **srv05-nyc** we observed earlier. - 8. From the **Add Network Interface** drop-down menu put a check mark next to switch port "**swp2(swp2 | srv05-nyc)@sw22-nyc (Demo)**", which we can see is the the port where **srv05-nyc** is wired into when we reference the :ref:`"Sandbox Topology diagram"`. + 5. From the **VLAN ID** drop-down menu, select "**Enter manually**" and type in "**46**" in the field to the right. + 6. From the **Owner** drop-down menu, select "**Demo**". + 7. From the **IPv4 Gateway** drop-down menu, select the "**192.168.46.0/24(CUSTOMER)**" subnet. + 8. The first available IP address "**192.168.46.1**" is automatically selected in the second drop-down menu of the list of IP addresses. This matches the results of the ``ip route ls`` command output on **srv05-nyc** we observed earlier. + 9. From the **Add Network Interface** drop-down menu put a check mark next to both network interfaces "**swp5(swp5 | srv05-nyc)@sw12-nyc (Demo)**" and "**swp5(swp5 | srv05-nyc)@sw21-nyc (Demo)**", which we can see are the interfaces where **srv05-nyc** is wired into when we reference the :ref:`"Sandbox Topology diagram"`. - * The drop-down menu only contains this single switch port as it is the only port that has been assigned to the **Demo** tenant. + * The drop-down menu only contains these two network interfaces as they are the only interfaces that have been assigned to the **Demo** tenant. - 9. Check the **Untag** check-box and click the **Add** button. - 10. Click the **Add** button at the bottom right of the "**Add new V-Net**" window and the service will start provisioning. + 10. Click the **Add** button. + 11. Click the **Add** button at the bottom right of the "**Add new V-Net**" window and the service will start provisioning. -After just a few seconds, once fully provisioned, you will start seeing successful ping replies, similar in form to "**64 bytes from 192.168.46.1: icmp_seq=55 ttl=64 time=1.66 ms**", to the ping that was previously started in the terminal window, indicating that now the gateway address is reachable from host **srv05-nyc**. +After just a few seconds, once fully provisioned, you will start seeing successful ping replies, similar in form to "**64 bytes from 192.168.46.1: icmp_seq=55 ttl=64 time=1.66 ms**", to the ping that was previously started in the terminal window, indicating that now the gateway address is accessible from host **srv05-nyc**. -More details about V-Net (Ethernet/Vlan/VXlan) can be found on the the :ref:`"V-NET"` page. +More details about V-Net (Ethernet/Vlan/VXlan) can be found on the the :ref:`"V-Network"` page. -.. _s12-e-bgp: +.. _s12-learn-by-doing: E-BGP (Exterior Border Gateway Protocol) ======================================== @@ -51,7 +55,7 @@ Optionally you can configure an E-BGP session to IRIS ISP2 for fault tolerance. * In a web browser: (*\*Fields not specified should remain unchanged and retain default values*) - 1. Log into the Netris Controller by visiting `https://sandbox12.netris.io `_ and navigate to **Net → E-BGP**. + 1. Log into the Netris Controller by visiting `https://Sandbox12.netris.io `_ and navigate to **Network → E-BGP**. 2. Click the **+ Add** button in the top right corner of the page to configure a new E-BGP session. 3. Define a name in the **Name** field (e.g. ``iris-isp2-ipv4-customer``). 4. From the **Site** drop-down menu, select "**US/NYC**". @@ -60,25 +64,25 @@ Optionally you can configure an E-BGP session to IRIS ISP2 for fault tolerance. * For the purposes of this exercise, the required switch port can easily be found by typing ``ISP2`` in the Search field. - 7. For the **VLAN ID** field, uncheck the **Untag** check-box and type in ``1122``. + 7. For the **VLAN ID** field, type in ``1121`` while leaving the **Untagged** check-box unchecked. 8. In the **Neighbor AS** field, type in ``65007``. - 9. In the **Local IP** field, type in ``45.38.161.126``. - 10. In the **Remote IP** field, type in ``45.38.161.125``. + 9. In the **Local IP** field, type in ``45.38.161.121``. + 10. In the **Remote IP** field, type in ``45.38.161.126``. 11. Expand the **Advanced** section - 12. In the **Prefix List Inbound** field, type in ``permit 0.0.0.0/0`` - 13. In the **Prefix List Outbound** field, type in ``permit 45.38.161.128/28 le 32`` - 14. And finally click **Add** + 12. In the **Prefix List Outbound** field, type in ``permit 1122/28 le 32`` + 13. And finally click **Add** -Allow up to 1 minute for both sides of the BGP sessions to come up and then the BGP state on **Net → E-BGP** page as well as on **Telescope → Dashboard** pages will turn green, indication a successfully established BGP session. We can glean further insight into the BGP session details by navigating to **Net → Looking Glass**. +Allow up to 1 minute for both sides of the BGP sessions to come up and then the BGP state on **Network → E-BGP** page as well as on **Telescope → Dashboard** pages will turn green, indication a successfully established BGP session. We can glean further insight into the BGP session details by navigating to **Net → Looking Glass**. - 1. Select "**SoftGate2(45.38.161.129)**" (the border router where our newly created BGP session is terminated on) from the **Select device** drop-down menu. - 2. Leaving the **Family** drop-down menu on IPv4 and the **Command** drop-down menu on "**BGP Summary**", click on the **Submit** button. + 1. Make sure "**vpc-1:Default**" is selected from the **VPC** drop-down menu. + 2. Select "**SoftGate2(45.38.161.128)**" (the border router where our newly created BGP session is terminated on) from the **Hardware** drop-down menu. + 3. Leaving the **Address Family** drop-down menu on "**Family: IPV4**" and the **Command** drop-down menu on "**Command: BGP Summary**", click on the **Submit** button. We are presented with the summary of the BGP sessions terminated on **SoftGate2**. You can also click on each BGP neighbor name to further see the "**Advertised routes**" and "**Routes**" received to/from that BGP neighbor. More details about E-BGP (Exterior Border Gateway Protocol) can be found on the the :ref:`"BGP"` page. -.. _s12-nat: +.. _s12-v-net: NAT (Network Address Translation) ================================= @@ -86,28 +90,28 @@ Now that we have both internal and external facing services, we can aim for our * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@50.117.27.83 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@sandbox12 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session towards any public IP address (e.g. ``ping 1.1.1.1``). 4. Keep the ping running as an indicator for when the service starts to work. -Let's configure a source NAT so our Customer subnet **192.168.46.0/24**, which is used in the V-Net services called **vnet-customer**, can communicate with the Internet. +Let's configure a Source NAT so our Customer subnet **192.168.46.0/24**, which is used in the V-Net services called **vnet-customer**, can communicate with the Internet. * In a web browser: (*\*Fields not specified should remain unchanged and retain default values*) - 1. Log into the Netris Controller by visiting `https://sandbox12.netris.io `_ and navigate to **Net → NAT**. + 1. Log into the Netris Controller by visiting `https://Sandbox12.netris.io `_ and navigate to **Network → NAT**. 2. Click the **+ Add** button in the top right corner of the page to define a new NAT rule. 3. Define a name in the **Name** field (e.g. ``NAT Customer``). 4. From the **Site** drop-down menu, select "**US/NYC**". 5. From the **Action** drop-down menu, select "**SNAT**". - 6. From the **Protocol** drop-down menu, select "**ALL**". + 6. Leave **ALL** selected in the **Protocol** drop-down menu. 7. In the **Source Address** field, type in ``192.168.46.0/24``. - 8. In the **Destination Address** field, type in ``0.0.0.0/0``. + 8. In the **Destination Address** field, leave the default value of ``0.0.0.0/0``. 9. Toggle the switch from **SNAT to Pool** to **SNAT to IP**. - 10. From the **Select subnet** drop-down menu, select the "**45.38.161.132/30 (NAT)**" subnet. - 11. From the **Select IP** drop-down menu, select the "**45.38.161.132/32**" IP address. + 10. From the **Select subnet** drop-down menu, select the "**45.38.161.129/30 (NAT)**" subnet. + 11. From the **Select IP** drop-down menu, select the "**45.38.161.129/32**" IP address. - * This public IP is part of **45.38.161.132/30 (NAT)** subnet which is configured in the **NET → IPAM** section with the purpose of **NAT** and indicated in the SoftGate configurations to be used as a global IP for NAT by the :ref:`"Netris SoftGate Agent"`.. + * This public IP address is part of **45.38.161.129/30 (NAT)** subnet which is configured in the **Network → IPAM** section with the purpose of **NAT** and indicated in the **SoftGate** configurations to be used as a global IP for NAT by the :ref:`"Netris SoftGate Agent"`. 12. Click **Add** @@ -115,52 +119,56 @@ Soon you will start seeing replies similar in form to "**64 bytes from 1.1.1.1: More details about NAT (Network Address Translation) can be found on the :ref:`"NAT"` page. -.. _s12-l3lb: +.. _s12-acl: -L3LB (Anycast L3 load balancer) +L3LB (Anycast L3 Load Balancer) =============================== -In this exercise we will quickly configure an Anycast IP address in the Netris Controller for two of our :ref:`"ROH (Routing on the Host)"` servers (**srv01-nyc** & **srv02-nyc**) which both have a running Web Server configured to display a simple HTML webpage and observe **ECMP** load balancing it in action. +In this exercise we will quickly configure an Anycast IP address in the Netris Controller for two of our :ref:`"ROH (Routing on the Host)"` servers (**srv01-nyc** & **srv02-nyc**) which both have a running **Web Server** configured to display a simple HTML webpage and observe **ECMP** load balancing it in action. * In a web browser: (*\*Fields not specified should remain unchanged and retain default values*) - 1. Log into the Netris Controller by visiting `https://sandbox12.netris.io `_ and navigate to **Services → ROH**. + 1. Log into the Netris Controller by visiting `https://Sandbox12.netris.io `_ and navigate to **Services → ROH**. 2. Click **Edit** from the **Actions** menu indicated by three vertical dots (**⋮**) on the right side of the "**srv01-nyc**" server. - 3. From the **IPv4** drop-down menu, select the "**45.38.161.136/30 (L3 LOAD BALANCER)**" subnet. - 4. From the second drop-down menu that appears to the right, select the first available IP "**45.38.161.136**". - 5. Check the **Anycast** check-box next to the previously selected IP and click the **Save** button. + 3. From the **IPv4** drop-down menu, select the "**45.38.161.132/30 (L3 LOAD BALANCER)**" subnet. + 4. From the second drop-down menu that appears to the right, select the first available IP "**45.38.161.132**". + 5. Check the **Anycast** check-box next to the previously selected IP and click the **Save** button. 6. Repeat steps **3** through **4** for "**srv02-nyc**" by first clicking **Edit** from the **Actions** menu indicated by three vertical dots (**⋮**) on the right side of the "**srv02-nyc**" server. - * While editing "**srv02-nyc**", after selecting the "**45.38.161.136**" IP address , the **Anycast** check-box will already be automatically checked as we had designated the IP address as such in step **5**. + * While editing "**srv02-nyc**", after selecting the "**45.38.161.132**" IP address , the **Anycast** check-box will already be automatically checked as we had designated the IP address as such in step **5**. * In a new web browser window/tab: - 1. Type in the Anycast IP address we just configured (**45.38.161.136**) into the browser's address bar or simply visit `http://45.38.161.136/ `_. + 1. Type in the Anycast IP address we just configured (**45.38.161.132**) into the browser's address bar or simply visit `http://45.38.161.132/ `_. 2. Based on the unique hash calculated from factors such as source IP/Protocol/Port, the **L3LB** will use **ECMP** to load balance the traffic from your browser to either **srv01-nyc** or **srv02-nyc**, with the text on the website indicating where the traffic ended up. * It should be noted that the TCP session will continue to exist between the given end-user and server pair for the lifetime of the session. In our case we have landed on **srv01-nyc**. .. image:: /images/l3lb_srv01.png :align: center + :alt: SRV01 L3LB + :target: ../../_images/l3lb_srv01.png -In order to trigger the L3 load balancer to switch directing the traffic towards the other backend server (in this case from **srv01-nyc** to **srv02-nyc**, which based on the unique hash in your situation could be the other way around), we can simulate the unavailability of backend server we ended up on by putting it in **Maintenance** mode. +In order to trigger the L3 load balancer to switch directing the traffic towards the other backend server (in this case from **srv01-nyc** to **srv02-nyc**, which based on the unique hash in your situation could be the other way around), we can simulate the unavailability of the backend server we ended up on by putting it in **Maintenance** mode. * Back in the Netris Controller, navigate to **Services → L3 Load Balancer**. - 1. Expand the **LB Vip** that was created when we defined the **Anycast** IP address earlier by clicking on the **>** to the left of "**45.38.161.136 (name_45.38.161.136)**". + 1. Expand the **LB Vip** that was created when we defined the **Anycast** IP address earlier by clicking on the **>** button to the left of "**45.38.161.132 (name_45.38.161.132)**". 2. Click **Action v** to the right of the server you originally ended up on (in this case **srv01-nyc**). 3. Click **Maintenance on**. 4. Click **Maintenance** one more time in the pop-up window. -* Back in the browser window/tab directed at the **45.38.161.136** Anycast IP address. +* Back in the browser window/tab directed at the **45.38.161.132** Anycast IP address. 1. After just a few seconds, we can observe that now the website indicates that the traffic is routed to **srv02-nyc** (once more, your case could be opposite for you based on the original hash). .. image:: /images/l3lb_srv02.png :align: center + :alt: SRV02 L3LB + :target: ../../_images/l3lb_srv02.png More details about AL3LB (Anycast L3 load balancer) can be found on the :ref:`"L3 Load Balancer (Anycast LB)"` page. -.. _s12-acl: +.. _s12-nat: ACL (Access Control List) ========================= @@ -168,7 +176,7 @@ Now that **srv05-nyc** can communicate with both internal and external hosts, le * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@50.117.27.83 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@sandbox12 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping 1.1.1.1``. 4. If the previous steps were followed, you should see successful ping replies in the form of "**64 bytes from 1.1.1.1: icmp_seq=55 ttl=62 time=1.23 ms**". @@ -176,12 +184,12 @@ Now that **srv05-nyc** can communicate with both internal and external hosts, le * In a web browser: (*\*Fields not specified should remain unchanged and retain default values*) - 1. Log into the Netris Controller by visiting `https://sandbox12.netris.io `_ and navigate to **Net → Sites**. + 1. Log into the Netris Controller by visiting `https://Sandbox12.netris.io `_ and navigate to **Network → Sites**. 2. Click **Edit** from the **Actions** menu indicated by three vertical dots (**⋮**) on the right side of the **UC/NYC** site. 3. From the **ACL Default Policy** drop-down menu, change the value from "**Permit**" to "**Deny**". 4. Click **Save**. -Soon you will notice that there are no new replies to our previously started ``ping 1.1.1.1`` command in the terminal window, indicating that the **1.1.1.1** IP address is no longer reachable.Now that the **Default ACL Policy** is set to **Deny**, we need to configure an **ACL** entry that will allow the **srv05-nyc** server to communicate with the Internet. +Soon you will notice that there are no new replies to our previously started ``ping 1.1.1.1`` command in the terminal window, indicating that the **1.1.1.1** IP address is no longer reachable. Now that the **Default ACL Policy** is set to **Deny**, we need to configure an **ACL** entry that will allow the **srv05-nyc** server to communicate with the Internet. * Back in the web browser: (*\*Fields not specified should remain unchanged and retain default values*) @@ -192,9 +200,7 @@ Soon you will notice that there are no new replies to our previously started ``p 5. In the Source field, type in ``192.168.46.0/24``. 6. In the Destination field, type in ``0.0.0.0/0``. 7. Click **Add**. - 8. Select **Approve** from the **Actions** menu indicated by three vertical dots (**⋮**) on the right side of the newly created "**V-Net Customer to WAN**" ACL. - 9. Click **Approve** one more time in the pop-up window. -Once the Netris Controller has finished syncing the new ACL policy with all member devices, we can see in the terminal window that replies to our ``ping 1.1.1.1`` command have resumed, indicating that the **srv05-nyc** server can communicate with the Internet once again.. +You can observer the status of the syncing process by clicking on the **Syncing** yellow label at the top right of the **ACL** windown. Once the Netris Controller has finished syncing the new ACL policy with all relevant member devices, the label will turn green and read as **Synced**. Back in the terminal window we can observer that the replies to our ``ping 1.1.1.1`` command have resumed, indicating that the **srv05-nyc** server can communicate with the Internet once again.. More details about ACL (Access Control List) can be found on the :ref:`"ACL"` page. diff --git a/sandbox/Sandbox12/index.rst b/sandbox/Sandbox12/index.rst index a72bac6f8..86f50ddef 100644 --- a/sandbox/Sandbox12/index.rst +++ b/sandbox/Sandbox12/index.rst @@ -8,7 +8,7 @@ ------------------------------------------------------------------------------------------------ Sandbox12 # Sandbox name Uppercase(case sensitive) sandbox12 # Sandbox name Lowercase - 50.117.27.83 # Hypervisor PUBLIC IP + 216.172.128.212 # Hypervisor PUBLIC IP 10.254.45.0/24 # *STATIC NO NEED TO REPLACE* MANAGEMENT Allocation/Subnet 10.254.46.0/24 # *STATIC NO NEED TO REPLACE* LOOPBACK Allocation/Subnet 192.168.44.0/24 # *STATIC NO NEED TO REPLACE* ROH Allocation/Subnet diff --git a/sandbox/Sandbox12/onprem-k8s.rst b/sandbox/Sandbox12/onprem-k8s.rst index 02b67c61b..915bcfd09 100644 --- a/sandbox/Sandbox12/onprem-k8s.rst +++ b/sandbox/Sandbox12/onprem-k8s.rst @@ -1,37 +1,41 @@ -.. _s12-k8s: +.. _s12-l3lb: *************************************** -Learn Netris operations with Kubernetes +Learn Netris Operations with Kubernetes *************************************** -.. contents:: - :local: +.. contents:: + :local: Intro ===== -This Sandbox environment provides an existing Kubernetes cluster that has been deployed via `Kubespray `_. For this scenario, we will be using the `external LB `_ option in Kubespray. A dedicated Netris L4LB service has been created in the Sandbox Controller to access the k8s apiservers from users and non-master nodes sides. +The Sandbox environment offers a pre-existing 3 node Kubernetes cluster deployed through K3S in `HA Mode `_. To enable user access to the Kubernetes API, a dedicated Netris L4LB service has been created in the Sandbox Controller. Furthermore, this L4LB address serves as ``K3S_URL`` environment variable for all nodes within the cluster. .. image:: /images/sandbox-l4lb-kubeapi.png :align: center + :alt: Sandbox L4LB KubeAPI + :target: ../../_images/sandbox-l4lb-kubeapi.png -To access the built-in Kubernetes cluster, put "Kubeconfig" file which you received by the introductory email into your ``~/.kube/config`` or set "KUBECONFIG" environment variable ``export KUBECONFIG=~/Downloads/config`` on your local machine. After that try to connect to the k8s cluster: +To access the built-in Kubernetes cluster, put the "Kubeconfig" file which you received via the introductory email into your ``~/.kube/config`` or set "KUBECONFIG" environment variable using ``export KUBECONFIG=~/Downloads/config`` on your local machine. Afterwards, try to connect to the k8s cluster: .. code-block:: shell-session kubectl cluster-info -The output below means you've successfully connected to the sandbox cluster: +If your output matches the one below, that means you've successfully connected to the Sandbox cluster: .. code-block:: shell-session - Kubernetes master is running at https://api.k8s-sandbox12.netris.io:6443 + Kubernetes control plane is running at https://api.k8s-Sandbox12.netris.io:6443 + CoreDNS is running at https://api.k8s-Sandbox12.netris.io:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy + Metrics-server is running at https://api.k8s-Sandbox12.netris.io:6443/api/v1/namespaces/kube-system/services/https:metrics-server:https/proxy - To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. + To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. Install Netris Operator ======================= -The first step to integrate the Netris Controller with the Kubernetes API is to install the Netris Operator. Installation can be accomplished by installing regular manifests or a `helm chart `_. For this example we will use the Kubernetes regular manifests: +The first step to integrate the Netris Controller with the Kubernetes API is to install the Netris Operator. Installation can be accomplished by installing a regular manifests or a `helm chart `_. For this example we will use the Kubernetes regular manifests: 1. Install the latest Netris Operator: @@ -44,7 +48,7 @@ The first step to integrate the Netris Controller with the Kubernetes API is to .. code-block:: shell-session kubectl -nnetris-operator create secret generic netris-creds \ - --from-literal=host='https://sandbox12.netris.io' \ + --from-literal=host='https://Sandbox12.netris.io' \ --from-literal=login='demo' --from-literal=password='Your Demo user pass' 3. Inspect the pod logs and make sure the operator is connected to Netris Controller: @@ -60,13 +64,13 @@ Example output demonstrating the successful operation of Netris Operator: {"level":"info","ts":1629994653.6441543,"logger":"controller","msg":"Starting workers","reconcilerGroup":"k8s.netris.ai","reconcilerKind":"L4LB","controller":"l4lb","worker count":1} .. note:: - - After installing the Netris Operator, your Kubernetes cluster and physical network control planes are connected. + + After installing the Netris Operator, your Kubernetes cluster and physical network control planes are connected. Deploy an Application with an On-Demand Netris Load Balancer ============================================================ -In this scenario we will be installing a simple application that requires a network load balancer: +In this scenario we will be installing a simple application that requires a network load balancer: Install the application `"Podinfo" `_: @@ -85,11 +89,12 @@ As you can see, the service type is "ClusterIP": .. code-block:: shell-session NAME READY STATUS RESTARTS AGE - pod/podinfo-576d5bf6bd-7z9jl 1/1 Running 0 49s - pod/podinfo-576d5bf6bd-nhlmh 1/1 Running 0 33s - - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - service/podinfo ClusterIP 172.21.65.106 9898/TCP,9999/TCP 50s + pod/podinfo-7cf557d9d7-6gfwx 1/1 Running 0 34s + pod/podinfo-7cf557d9d7-nb2t7 1/1 Running 0 18s + + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + service/kubernetes ClusterIP 10.43.0.1 443/TCP 33m + service/podinfo ClusterIP 10.43.68.103 9898/TCP,9999/TCP 35s In order to request access from outside, change the type to "LoadBalancer": @@ -107,13 +112,16 @@ Now we can see that the service type has changed to LoadBalancer, and "EXTERNAL- .. code-block:: shell-session - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - podinfo LoadBalancer 172.21.65.106 9898:32584/TCP,9999:30365/TCP 8m57s + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + kubernetes ClusterIP 10.43.0.1 443/TCP 37m + podinfo LoadBalancer 10.43.68.103 9898:32486/TCP,9999:30455/TCP 3m45s Going into the Netris Controller web interface, navigate to **Services → L4 Load Balancer**, and you may see L4LBs provisioning in real-time. If you do not see the provisioning process it is likely because it already completed. Look for the service with the name **"podinfo-xxxxxxxx"** .. image:: /images/sandbox-podinfo-prov.png :align: center + :alt: Sandbox PodInfo Provisioning + :target: ../../_images/sandbox-podinfo-prov.png After provisioning has finished, let's one more time look at service in k8s: @@ -124,32 +132,33 @@ After provisioning has finished, let's one more time look at service in k8s: You can see that "EXTERNAL-IP" has been injected into Kubernetes: .. code-block:: shell-session - - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - podinfo LoadBalancer 172.21.65.106 45.38.161.141 9898:32584/TCP,9999:30365/TCP 9m17s + + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + kubernetes ClusterIP 10.43.0.1 443/TCP 29m + podinfo LoadBalancer 10.43.42.190 45.38.161.140 9898:30771/TCP,9999:30510/TCP 5m14s Let's try to curl it (remember to replace the IP below with the IP that has been assigned in the previous command): .. code-block:: shell-session - curl 45.38.161.141:9898 + curl 45.38.161.140:9898 The application is now accessible directly on the internet: .. code-block:: json - + { - "hostname": "podinfo-576d5bf6bd-nhlmh", - "version": "6.0.0", - "revision": "", - "color": "#34577c", - "logo": "https://raw.githubusercontent.com/stefanprodan/podinfo/gh-pages/cuddle_clap.gif", - "message": "greetings from podinfo v6.0.0", - "goos": "linux", - "goarch": "amd64", - "runtime": "go1.16.5", - "num_goroutine": "8", - "num_cpu": "4" + "hostname": "podinfo-7cf557d9d7-6gfwx", + "version": "6.6.0", + "revision": "357009a86331a987811fefc11be1350058da33fc", + "color": "#34577c", + "logo": "https://raw.githubusercontent.com/stefanprodan/podinfo/gh-pages/cuddle_clap.gif", + "message": "greetings from podinfo v6.6.0", + "goos": "linux", + "goarch": "amd64", + "runtime": "go1.21.7", + "num_goroutine": "8", + "num_cpu": "2" } As seen, "PodInfo" developers decided to expose 9898 port for HTTP, let's switch it to 80: @@ -162,29 +171,31 @@ Wait a few seconds, you can see the provisioning process on the controller: .. image:: /images/sandbox-podinfo-ready.png :align: center + :alt: Sandbox PodInfo Ready + :target: ../../_images/sandbox-podinfo-ready.png Curl again, without specifying a port: .. code-block:: shell-session - curl 45.38.161.141 + curl 45.38.161.140 The output is similar to this: .. code-block:: json - + { - "hostname": "podinfo-576d5bf6bd-nhlmh", - "version": "6.0.0", - "revision": "", - "color": "#34577c", - "logo": "https://raw.githubusercontent.com/stefanprodan/podinfo/gh-pages/cuddle_clap.gif", - "message": "greetings from podinfo v6.0.0", - "goos": "linux", - "goarch": "amd64", - "runtime": "go1.16.5", - "num_goroutine": "8", - "num_cpu": "4" + "hostname": "podinfo-7cf557d9d7-6gfwx", + "version": "6.6.0", + "revision": "357009a86331a987811fefc11be1350058da33fc", + "color": "#34577c", + "logo": "https://raw.githubusercontent.com/stefanprodan/podinfo/gh-pages/cuddle_clap.gif", + "message": "greetings from podinfo v6.6.0", + "goos": "linux", + "goarch": "amd64", + "runtime": "go1.21.7", + "num_goroutine": "8", + "num_cpu": "2" } You can also verify the application is reachable by putting this IP address directly into your browser. @@ -216,8 +227,8 @@ As you can see, there are two L4LB resources, one for each podinfo's service por .. code-block:: shell-session NAME STATE FRONTEND PORT SITE TENANT STATUS AGE - podinfo-default-66d44feb-0278-412a-a32d-73afe011f2c6-tcp-80 active 45.38.161.141 80/TCP US/NYC Admin OK 33m - podinfo-default-66d44feb-0278-412a-a32d-73afe011f2c6-tcp-9999 active 45.38.161.141 9999/TCP US/NYC Admin OK 32m + podinfo-default-5bdf0a53-027d-449f-8896-547e06028c6b-tcp-80 active 45.38.161.140 80/TCP US/NYC Admin OK 7m21s + podinfo-default-5bdf0a53-027d-449f-8896-547e06028c6b-tcp-9999 active 45.38.161.140 9999/TCP US/NYC Admin OK 15m You can't edit/delete them, because Netris Operator will recreate them based on what was originally deployed in the service specifications. @@ -264,15 +275,15 @@ As you can see, provisioning started: .. code-block:: shell-session NAME STATE FRONTEND PORT SITE TENANT STATUS AGE - podinfo-default-d07acd0f-51ea-429a-89dd-8e4c1d6d0a86-tcp-80 active 45.38.161.141 80/TCP US/NYC Admin OK 2m17s - podinfo-default-d07acd0f-51ea-429a-89dd-8e4c1d6d0a86-tcp-9999 active 45.38.161.141 9999/TCP US/NYC Admin OK 3m47s - srv04-5-nyc-http active 45.38.161.142 80/TCP US/NYC Admin Provisioning 6s + podinfo-default-5bdf0a53-027d-449f-8896-547e06028c6b-tcp-80 active 45.38.161.140 80/TCP US/NYC Admin OK 9m56s + podinfo-default-5bdf0a53-027d-449f-8896-547e06028c6b-tcp-9999 active 45.38.161.140 9999/TCP US/NYC Admin OK 17m + srv04-5-nyc-http active 45.38.161.141 80/TCP US/NYC Admin Provisioning 5s When provisioning is finished, you should be able to connect to L4LB. Try to curl, using the L4LB frontend address displayed in the above command output: .. code-block:: shell-session - curl 45.38.161.142 + curl 45.38.161.141 You will see the servers' hostname in curl output: @@ -284,11 +295,13 @@ You can also inspect the L4LB in the Netris Controller web interface: .. image:: /images/sandbox-l4lbs.png :align: center + :alt: Sandbox L4LBs + :target: ../../_images/sandbox-l4lbs.png V-Net Custom Resource --------------------- -If one of the backend health-checks is marked as unhealthy like in the screenshot above, it means you didn't create "vnet-customer" V-Net as described in the :ref:`"Learn by Creating Services"` manual. If that's the case, let's create it from Kubernetes using the V-Net custom resource. +If one of the backend health-checks is marked as unhealthy like in the screenshot above, it means you didn't create "vnet-customer" V-Net as described in the :ref:`"Learn by Creating Services"` manual. If that's the case, let's create it from Kubernetes using the V-Net custom resource. Let's create our V-Net manifest: @@ -298,16 +311,20 @@ Let's create our V-Net manifest: apiVersion: k8s.netris.ai/v1alpha1 kind: VNet metadata: - name: vnet-customer + name: vnet-customer spec: - ownerTenant: Demo - guestTenants: [] - sites: - - name: US/NYC - gateways: - - 192.168.46.1/24 - switchPorts: - - name: swp2@sw22-nyc + ownerTenant: Demo + guestTenants: [] + vlanId: "46" + sites: + - name: US/NYC + gateways: + - prefix: 192.168.46.1/24 + switchPorts: + - name: swp5@sw12-nyc + untagged: "no" + - name: swp5@sw21-nyc + untagged: "no" EOF And apply it: @@ -329,34 +346,34 @@ As you can see, provisioning for our new V-Net has started: NAME STATE GATEWAYS SITES OWNER STATUS AGE vnet-customer active 192.168.46.1/24 US/NYC Demo Active 10s -After provisioning has completed, the L4LB's checks should work for both backend servers, and incoming requests should be balanced between them. +After provisioning has completed, the L4LB's checks should work for both backend servers, and incoming requests should be balanced between them. Let's curl several times to see that: .. code-block:: shell-session - curl 45.38.161.142 + curl 45.38.161.141 As we can see, the curl request shows the behavior of "round robin" between the backends: .. code-block:: shell-session SRV05-NYC - curl 45.38.161.142 - - SRV05-NYC - curl 45.38.161.142 - + curl 45.38.161.141 + SRV05-NYC - curl 45.38.161.142 - + curl 45.38.161.141 + + SRV04-NYC + curl 45.38.161.141 + SRV04-NYC .. note:: - *If intermittently the result of the curl command is "Connection timed out", it is likely that the request went to the srv05-nyc backend, and the "Default ACL Policy" is set to "Deny". To remedy this, configure an ACL entry that will allow the srv05-nyc server to communicate with external addresses. For step-by-step instruction review the* :ref:`ACL documentation`. + *If intermittently the result of the curl command is "Connection timed out", it is likely that the request went to the srv05-nyc backend, and the "Default ACL Policy" is set to "Deny". To remedy this, configure an ACL entry that will allow the srv05-nyc server to communicate with external addresses. For step-by-step instruction review the* :ref:`ACL documentation`. -BTW, if you already created "vnet-customer" V-Net as described in the :ref:`"Learn by Creating Services"`, you may import that to k8s, by adding ``resource.k8s.netris.ai/import: "true"`` annotation in V-Net manifest, the manifest should look like this: +BTW, if you already created "vnet-customer" V-Net as described in the :ref:`"Learn by Creating Services"`, you may import that to k8s, by adding ``resource.k8s.netris.ai/import: "true"`` annotation in V-Net manifest, the manifest should look like this: .. code-block:: shell-session @@ -364,18 +381,22 @@ BTW, if you already created "vnet-customer" V-Net as described in the :ref:`"Lea apiVersion: k8s.netris.ai/v1alpha1 kind: VNet metadata: - name: vnet-customer - annotations: - resource.k8s.netris.ai/import: "true" + name: vnet-customer + annotations: + resource.k8s.netris.ai/import: "true" spec: - ownerTenant: Demo - guestTenants: [] - sites: - - name: US/NYC - gateways: - - 192.168.46.1/24 - switchPorts: - - name: swp2@sw22-nyc + ownerTenant: Demo + guestTenants: [] + vlanId: "46" + sites: + - name: US/NYC + gateways: + - prefix: 192.168.46.1/24 + switchPorts: + - name: swp5@sw12-nyc + untagged: "no" + - name: swp5@sw21-nyc + untagged: "no" EOF Apply it: @@ -391,12 +412,12 @@ After applying the manifest containing "import" annotation, the V-Net, created f kubectl get vnet NAME STATE GATEWAYS SITES OWNER STATUS AGE - vnet-customer active 192.168.46.1/24 US/NYC Demo Active 7s - + vnet-customer active 192.168.46.1/24 US/NYC Demo Active 2m + BGP Custom Resource ------------------- -Let's create a new BGP peer, that is listed in the :ref:`"Learn by Creating Services"`. +Let's create a new BGP peer, that is listed in the :ref:`"Learn by Creating Services"`. Create a yaml file: @@ -413,14 +434,12 @@ Create a yaml file: neighborAs: 65007 transport: name: swp16@sw02-nyc - vlanId: 1122 - localIP: 45.38.161.126/30 - remoteIP: 45.38.161.125/30 + vlanId: 1121 + localIP: 45.38.161.121/30 + remoteIP: 45.38.161.126/30 description: Example BGP to ISP2 - prefixListInbound: - - permit 0.0.0.0/0 prefixListOutbound: - - permit 45.38.161.128/28 le 32 + - permit 1122/28 le 32 EOF And apply it: @@ -440,7 +459,7 @@ Allow up to 1 minute for both sides of the BGP sessions to come up: .. code-block:: shell-session NAME STATE BGP STATE PORT STATE NEIGHBOR AS LOCAL ADDRESS REMOTE ADDRESS AGE - iris-isp2-ipv4-customer enabled Link Up 65007 45.38.161.126/30 45.38.161.125/30 15s + iris-isp2-ipv4-customer enabled Link Up 65007 45.38.161.121/30 45.38.161.126/30 15s Then check the state again: @@ -452,24 +471,24 @@ The output is similar to this: .. code-block:: shell-session - NAME STATE BGP STATE PORT STATE NEIGHBOR AS LOCAL ADDRESS REMOTE ADDRESS AGE - iris-isp2-ipv4-customer enabled bgp: Established; prefix: 160; time: 00:01:27 Link Up 65007 45.38.161.126/30 45.38.161.125/30 2m3s +NAME STATE BGP STATE PORT STATE NEIGHBOR AS LOCAL ADDRESS REMOTE ADDRESS AGE +iris-isp2-ipv4-customer enabled bgp: Established; prefix: 957240; time: 00:04:02 65007 45.38.161.121/30 45.38.161.126/30 2m3s Feel free to use the import annotation for this BGP if you created it from the Netris Controller web interface previously. -Return to the Netris Controller and navigate to **Net → Topology** to see the new BGP neighbor you created. +Return to the Netris Controller and navigate to **Network → Topology** to see the new BGP neighbor you created. Importing Existing Resources from Netris Controller to Kubernetes ----------------------------------------------------------------- -You can import any custom resources already created from the Netris Controller to k8s by adding the following annotation: + You can import any custom resources already created from the Netris Controller to k8s by adding the following annotation: .. code-block:: yaml resource.k8s.netris.ai/import: "true" Otherwise, if try to apply them without the "import" annotation, the Netris Operator will complain that the resource with such name or specs already exists. - + After importing resources to k8s, they will belong to the Netris Operator, and you won't be able to edit/delete them directly from the Netris Controller web interface, because the Netris Operator will put everything back, as declared in the custom resources. Reclaim Policy @@ -491,7 +510,7 @@ Just add this annotation in any custom resource while creating it. Or if the cus Netris Calico CNI Integration ============================= -Netris Operator can integrate with Calico CNI, in your Sandbox k8s cluster, Calico has already been configured as the CNI, so you can try this integration. It will automatically create BGP peering between cluster nodes and the leaf/TOR switch for each node, then to clean up it will disable Calico Node-to-Node mesh. To understand why you need to configure peering between Kubernetes nodes and the leaf/TOR switch, and why you should disable Node-to-Node mesh, review the `calico docs `_. +Netris Operator can integrate with Calico CNI, in your Sandbox k8s cluster, Calico has already been configured as the CNI, so you can try this integration. It will automatically create BGP peering between cluster nodes and the leaf/TOR switch for each node, then to clean up it will disable Calico Node-to-Node mesh. To understand why you need to configure peering between Kubernetes nodes and the leaf/TOR switch, and why you should disable Node-to-Node mesh, review the `Calico docs `_. Integration is very simple, you just need to add the annotation in calico's ``bgpconfigurations`` custom resource. Before doing that, let's see the current state of ``bgpconfigurations``: @@ -499,11 +518,11 @@ Integration is very simple, you just need to add the annotation in calico's ``bg kubectl get bgpconfigurations default -o yaml -As we can see, ``nodeToNodeMeshEnabled`` is enabled, and ``asNumber`` is 64512 (it's Calico default AS number): +As we can see, ``nodeToNodeMeshEnabled`` is enabled: .. code-block:: yaml - apiVersion: crd.projectcalico.org/v1 + apiVersion: projectcalico.org/v3 kind: BGPConfiguration metadata: annotations: @@ -511,8 +530,6 @@ As we can see, ``nodeToNodeMeshEnabled`` is enabled, and ``asNumber`` is 64512 ( name: default ... spec: - asNumber: 64512 - logSeverityScreen: Info nodeToNodeMeshEnabled: true Let's enable the "netris-calico" integration: @@ -531,11 +548,11 @@ Here are our freshly created BGPs, one for each k8s node: .. code-block:: shell-session - NAME STATE BGP STATE PORT STATE NEIGHBOR AS LOCAL ADDRESS REMOTE ADDRESS AGE - iris-isp2-ipv4-customer enabled bgp: Established; prefix: 160; time: 00:06:18 Link Up 65007 45.38.161.126/30 45.38.161.125/30 7m59s - sandbox12-srv06-nyc-192.168.110.66 enabled 4230000000 192.168.110.1/24 192.168.110.66/24 26s - sandbox12-srv07-nyc-192.168.110.67 enabled 4230000001 192.168.110.1/24 192.168.110.67/24 26s - sandbox12-srv08-nyc-192.168.110.68 enabled 4230000002 192.168.110.1/24 192.168.110.68/24 26s + NAME STATE BGP STATE PORT STATE NEIGHBOR AS LOCAL ADDRESS REMOTE ADDRESS AGE + iris-isp2-ipv4-customer enabled bgp: Established; prefix: 957241; time: 00:15:03 65007 45.38.161.121/30 45.38.161.126/30 16m + sandbox-srv06-192.168.110.66 enabled 4230000000 192.168.110.1/24 192.168.110.66/24 37s + sandbox-srv07-192.168.110.67 enabled 4230000001 192.168.110.1/24 192.168.110.67/24 37s + sandbox-srv08-192.168.110.68 enabled 4230000002 192.168.110.1/24 192.168.110.68/24 37s You might notice that peering neighbor AS is different from Calico's default 64512. The is because the Netris Operator is setting a particular AS number for each node. @@ -549,11 +566,11 @@ As we can see, our BGP peers have become established: .. code-block:: shell-session - NAME STATE BGP STATE PORT STATE NEIGHBOR AS LOCAL ADDRESS REMOTE ADDRESS AGE - iris-isp2-ipv4-customer enabled bgp: Established; prefix: 160; time: 00:07:48 Link Up 65007 45.38.161.126/30 45.38.161.125/30 8m41s - sandbox12-srv06-nyc-192.168.110.66 enabled bgp: Established; prefix: 5; time: 00:00:44 N/A 4230000000 192.168.110.1/24 192.168.110.66/24 68s - sandbox12-srv07-nyc-192.168.110.67 enabled bgp: Established; prefix: 5; time: 00:00:19 N/A 4230000001 192.168.110.1/24 192.168.110.67/24 68s - sandbox12-srv08-nyc-192.168.110.68 enabled bgp: Established; prefix: 5; time: 00:00:44 N/A 4230000002 192.168.110.1/24 192.168.110.68/24 68s + NAME STATE BGP STATE PORT STATE NEIGHBOR AS LOCAL ADDRESS REMOTE ADDRESS AGE + iris-isp2-ipv4-customer enabled bgp: Established; prefix: 957194; time: 00:18:24 65007 45.38.161.121/30 45.38.161.126/30 19m + sandbox-srv06-192.168.110.66 enabled bgp: Established; prefix: 1; time: 00:01:26 N/A 4230000000 192.168.110.1/24 192.168.110.66/24 2m7s + sandbox-srv07-192.168.110.67 enabled bgp: Established; prefix: 1; time: 00:01:26 N/A 4230000001 192.168.110.1/24 192.168.110.67/24 2m7s + sandbox-srv08-192.168.110.68 enabled bgp: Established; prefix: 1; time: 00:01:26 N/A 4230000002 192.168.110.1/24 192.168.110.68/24 2m7s Now let's check if ``nodeToNodeMeshEnabled`` is still enabled: @@ -565,16 +582,16 @@ It is disabled, which means the "netris-calico" integration process is finished: .. code-block:: yaml - apiVersion: crd.projectcalico.org/v1 + apiVersion: projectcalico.org/v3 kind: BGPConfiguration metadata: annotations: + ... manage.k8s.netris.ai/calico: "true" ... name: default ... spec: - asNumber: 64512 nodeToNodeMeshEnabled: false .. note:: @@ -585,24 +602,24 @@ Finally, let's check if our earlier deployed "Podinfo" application is still work .. code-block:: shell-session - curl 45.38.161.141 + curl 45.38.161.140 Yes, it works: .. code-block:: json { - "hostname": "podinfo-576d5bf6bd-mfpdt", - "version": "6.0.0", - "revision": "", - "color": "#34577c", - "logo": "https://raw.githubusercontent.com/stefanprodan/podinfo/gh-pages/cuddle_clap.gif", - "message": "greetings from podinfo v6.0.0", - "goos": "linux", - "goarch": "amd64", - "runtime": "go1.16.5", - "num_goroutine": "8", - "num_cpu": "4" + "hostname": "podinfo-7cf557d9d7-nb2t7", + "version": "6.6.0", + "revision": "357009a86331a987811fefc11be1350058da33fc", + "color": "#34577c", + "logo": "https://raw.githubusercontent.com/stefanprodan/podinfo/gh-pages/cuddle_clap.gif", + "message": "greetings from podinfo v6.6.0", + "goos": "linux", + "goarch": "amd64", + "runtime": "go1.21.7", + "num_goroutine": "8", + "num_cpu": "2" } Disabling Netris-Calico Integration @@ -618,4 +635,4 @@ or change its value to ``"false"``. .. topic:: Milestone 2 - Congratulations! You completed Milestone 2. Time to get yourself another iced coffee or even a beer depending on what time it is! + Congratulations on completing Milestone 2! diff --git a/sandbox/Sandbox12/sandbox-info.rst b/sandbox/Sandbox12/sandbox-info.rst index 794dbd353..f7a486bfd 100644 --- a/sandbox/Sandbox12/sandbox-info.rst +++ b/sandbox/Sandbox12/sandbox-info.rst @@ -2,10 +2,13 @@ Welcome to Netris Sandbox ************************* -Netris Sandbox is a ready-to-use environment for testing Netris automatic NetOps. -We have pre-created some example services for you, details of which can be found in the :ref:`"Provided Example Configurations"` document. Feel free to view, edit, delete, and create new services. In case of any questions, reach out to us on `Slack `__. +.. contents:: + :local: -The credentials for the sandbox have been provided to you by email in response to your Sandbox request. +Netris Sandbox is a ready-to-use environment for testing Netris automatic NetOps. +We have pre-created some example services for you, details of which can be found in the :ref:`"Provided Example Configurations"<2607:f358:11:ffc0::18>` document. Feel free to view, edit, delete, and create new services. In case of any questions, reach out to us on `Slack `__. + +The credentials for the sandbox have been provided to you via email in response to your Sandbox request. The Sandbox environment includes: @@ -17,95 +20,95 @@ The Sandbox environment includes: * **Kubernetes cluster**: A 3 node Kubernetes cluster, user integratable with Netris controller, feel free to deploy any applications for your tests. * **ISP**: Internet upstream with IRIS ISP, providing the sandbox Internet connectivity with real-world routable public IP addresses. -.. _s12-topology: +.. _s12-k8s: Topology diagram ================ -.. image:: /images/sandbox_topology.png +.. image:: /images/sandbox_topology_new.png :align: center :alt: Sandbox Topology - :target: ../../_images/sandbox_topology.png - + :target: ../../_images/sandbox_topology_new.png Netris Controller ================= -https://sandbox12.netris.io +https://Sandbox12.netris.io Linux servers ============= Example pre-configured Netris services: - * **srv01-nyc**, **srv02-nyc**, **srv03-nyc** & **Netris Controller** - are consuming :ref:`"ROH (Routing on the Host)"` Netris example service, see **Services → ROH.** - * **srv01-nyc**, **srv02-nyc** - are behind :ref:`"Anycast L3 load balancer"`, see **Services → Load Balancer**. - * **srv04-nyc**, **srv05-nyc** - are consuming :ref:`"V-NET (routed VXLAN)"` Netris service, see **Services → V-NET**. + * **srv01-nyc**, **srv02-nyc**, **srv03-nyc** & **Netris Controller** - are consuming :ref:`"ROH (Routing on the Host)"` Netris example service, see **Services → ROH.**. + * **srv01-nyc**, **srv02-nyc** - can be configured with :ref:`"L3 Load Balancer (Anycast LB)"`, see **Services → L3 Load Balancer**. + * **srv04-nyc**, **srv05-nyc**, **srv06-nyc**, **srv07-nyc** & **srv08-nyc** - are consuming :ref:`"V-Net (routed VXLAN)"` Netris service, see **Services → V-Net**. + * **srv06-nyc**, **srv07-nyc**, **srv08-nyc** - are members of a 3 node Kubernetes cluser, and the K8s API servers are behind :ref:`"L4 Load Balancer (L4LB)"`, see **Services → L4 Load Balancer**. **Accessing the Linux servers:** - -.. code-block:: shell-session - - srv01-nyc: ssh demo@50.117.27.83 -p 30061 - srv02-nyc: ssh demo@50.117.27.83 -p 30062 - srv03-nyc: ssh demo@50.117.27.83 -p 30063 - srv04-nyc: ssh demo@50.117.27.83 -p 30064 - srv05-nyc: ssh demo@50.117.27.83 -p 30065 - + +.. code-block:: shell-session + + srv01-nyc: ssh demo@sandbox12 -p 30061 + srv02-nyc: ssh demo@sandbox12 -p 30062 + srv03-nyc: ssh demo@sandbox12 -p 30063 + srv04-nyc: ssh demo@sandbox12 -p 30064 + srv05-nyc: ssh demo@sandbox12 -p 30065 + Kubernetes cluster ================== -This Sandbox provides an up and running 3 node Kubernetes cluster. You can integrate it with the Netris Controller by installing the **netris-operator**. Step-by-step instructions are included in the :ref:`"Learn Netris operations with Kubernetes"` document. +This Sandbox provides an up and running 3 node Kubernetes cluster. You can integrate it with the Netris Controller by installing the **netris-operator**. Step-by-step instructions are included in the :ref:`"Learn Netris operations with Kubernetes"` document. Upstream ISP ============ This Sandbox also provides an upstream ISP service with real-world Internet routing configured through :ref:`"BGP"`. -There are two pre-configured examples under **NET → E-BGP** , one using IPv4 and the other using IPv6, which are advertising the public IP subnets belonging to the sandbox to the upstream ISP IRIS. +There are two pre-configured examples under **Network → E-BGP** , one using IPv4 and the other using IPv6, which are advertising the public IP subnets belonging to the Sandbox to the upstream ISP IRIS. ISP settings: .. code-block:: shell-session - + (pre-configured examples) Name: iris-isp1-ipv4-example BGP Router: Softage1 Switch Port: swp16@sw01-nyc Neighbor AS: 65007 - VLAN ID: 1121 - Local Address: 45.38.161.122/30 - Remote Address: 45.38.161.121/30 + VLAN ID: 216.172.128.212 + Local Address: 45.38.161.142/30 + Remote Address: 45.38.161.122/30 Prefix List Inbound: permit 0.0.0.0/0 - Prefix List Outbound: permit 45.38.161.128/28 le 32 - + Prefix List Outbound: permit 1122/28 le 32 + Name: iris-isp1-ipv6-example BGP Router: Softage1 Switch Port: swp16@sw01-nyc Neighbor AS: 65007 - VLAN ID: 1121 - Local Address: 2607:f358:11:ffc0::19/127 - Remote Address: 2607:f358:11:ffc0::18/127 + VLAN ID: 216.172.128.212 + Local Address: 2607:f358:11:ffcc::1/127 + Remote Address: 2607:f358:11:ffc0::19/127 Prefix List Inbound: permit ::/0 - Prefix List Outbound: permit 2607:f358:11:ffcc::/64 + Prefix List Outbound: permit 45.38.161.125/64 (configurable by you) BGP Router: Softage2 Switch Port: swp16@sw02-nyc Neighbor AS: 65007 - VLAN ID: 1122 - Local Address: 45.38.161.126/30 - Remote Address: 45.38.161.125/30 + VLAN ID: 1121 + Local Address: 45.38.161.121/30 + Remote Address: 45.38.161.126/30 Prefix List Inbound: permit 0.0.0.0/0 - Prefix List Outbound: permit 45.38.161.128/28 le 32 + Prefix List Outbound: permit 1122/28 le 32 -Networks Used +Networks Used ============= -Allocations and subnets defined under :ref:`"IPAM"`, see **Net → IPAM**. +Allocations and subnets defined under :ref:`"IPAM"`, see **Network → IPAM**. .. code-block:: shell-session - | MANAGEMENT Allocation: 10.254.45.0/24 + | MANAGEMENT Allocation: 10.254.45.0/24 |___ MANAGEMENT Subnet: 10.254.45.0/24 | LOOPBACK Allocation: 10.254.46.0/24 @@ -123,12 +126,11 @@ Allocations and subnets defined under :ref:`"IPAM"`, see **Net → IPA | K8s Allocation: 192.168.110.0/24 |___ K8s Subnet: 192.168.110.0/24 - | PUBLIC IPv4 Allocation: 45.38.161.128/28 - |___ PUBLIC LOOPBACK Subnet: 45.38.161.128/30 - |___ NAT Subnet: 45.38.161.132/30 - |___ L3 LOAD BALANCER Subnet: 45.38.161.136/30 - |___ L4 LOAD BALANCER Subnet: 45.38.161.140/30 + | PUBLIC IPv4 Allocation: 1122/28 + |___ PUBLIC LOOPBACK Subnet: 1122/30 + |___ NAT Subnet: 45.38.161.129/30 + |___ L3 LOAD BALANCER Subnet: 45.38.161.132/30 + |___ L4 LOAD BALANCER Subnet: 45.38.161.136/30 - | EXAMPLE IPv6 Allocation: 2607:f358:11:ffcc::/64 - |___ EXAMPLE IPv6 Subnet: 2607:f358:11:ffcc::/64 - + | EXAMPLE IPv6 Allocation: 45.38.161.125/64 + |___ EXAMPLE IPv6 Subnet: 45.38.161.125/64 diff --git a/sandbox/Sandbox13/configurations.rst b/sandbox/Sandbox13/configurations.rst index 55959e93e..dd2b66a5c 100644 --- a/sandbox/Sandbox13/configurations.rst +++ b/sandbox/Sandbox13/configurations.rst @@ -70,7 +70,7 @@ You may also observe the functioning NAT rule in action by pinging any public IP * In a terminal window: - 1. SSH to server **srv04-nyc**: ``ssh demo@50.117.27.84 -p 30064``. + 1. SSH to server **srv04-nyc**: ``ssh demo@216.172.128.213 -p 30064``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping4 1.1.1.1`` diff --git a/sandbox/Sandbox13/creating-services.rst b/sandbox/Sandbox13/creating-services.rst index c2df73902..f92c8fdf2 100644 --- a/sandbox/Sandbox13/creating-services.rst +++ b/sandbox/Sandbox13/creating-services.rst @@ -17,7 +17,7 @@ Let's create a V-Net service to give server **srv05-nyc** the ability to reach i * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@50.117.27.84 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.213 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Type ``ip route ls`` and we can see **192.168.46.1** is configured as the default gateway, indicated by the "**default via 192.168.46.1 dev eth1 proto kernel onlink**" line in the output. 4. Start a ping session towards the default gateway: ``ping 192.168.46.1`` @@ -90,7 +90,7 @@ Now that we have both internal and external facing services, we can aim for our * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@50.117.27.84 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.213 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session towards any public IP address (e.g. ``ping 1.1.1.1``). 4. Keep the ping running as an indicator for when the service starts to work. @@ -176,7 +176,7 @@ Now that **srv05-nyc** can communicate with both internal and external hosts, le * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@50.117.27.84 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.213 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping 1.1.1.1``. 4. If the previous steps were followed, you should see successful ping replies in the form of "**64 bytes from 1.1.1.1: icmp_seq=55 ttl=62 time=1.23 ms**". diff --git a/sandbox/Sandbox13/index.rst b/sandbox/Sandbox13/index.rst index 022b6775b..ae3a0259b 100644 --- a/sandbox/Sandbox13/index.rst +++ b/sandbox/Sandbox13/index.rst @@ -7,7 +7,7 @@ ------------------------------------------------------------------------------------------------ Sandbox13 # Sandbox name Uppercase(case sensitive) sandbox13 # Sandbox name Lowercase - 50.117.27.84 # Hypervisor PUBLIC IP + 216.172.128.213 # Hypervisor PUBLIC IP 10.254.45.0/24 # *STATIC NO NEED TO REPLACE* MANAGEMENT Allocation/Subnet 10.254.46.0/24 # *STATIC NO NEED TO REPLACE* LOOPBACK Allocation/Subnet 192.168.44.0/24 # *STATIC NO NEED TO REPLACE* ROH Allocation/Subnet diff --git a/sandbox/Sandbox13/sandbox-info.rst b/sandbox/Sandbox13/sandbox-info.rst index 2c2a88247..10e9782ce 100644 --- a/sandbox/Sandbox13/sandbox-info.rst +++ b/sandbox/Sandbox13/sandbox-info.rst @@ -49,11 +49,11 @@ Example pre-configured Netris services: .. code-block:: shell-session - srv01-nyc: ssh demo@50.117.27.84 -p 30061 - srv02-nyc: ssh demo@50.117.27.84 -p 30062 - srv03-nyc: ssh demo@50.117.27.84 -p 30063 - srv04-nyc: ssh demo@50.117.27.84 -p 30064 - srv05-nyc: ssh demo@50.117.27.84 -p 30065 + srv01-nyc: ssh demo@216.172.128.213 -p 30061 + srv02-nyc: ssh demo@216.172.128.213 -p 30062 + srv03-nyc: ssh demo@216.172.128.213 -p 30063 + srv04-nyc: ssh demo@216.172.128.213 -p 30064 + srv05-nyc: ssh demo@216.172.128.213 -p 30065 Kubernetes cluster diff --git a/sandbox/Sandbox14/configurations.rst b/sandbox/Sandbox14/configurations.rst index 49b7befc7..388346727 100644 --- a/sandbox/Sandbox14/configurations.rst +++ b/sandbox/Sandbox14/configurations.rst @@ -70,7 +70,7 @@ You may also observe the functioning NAT rule in action by pinging any public IP * In a terminal window: - 1. SSH to server **srv04-nyc**: ``ssh demo@50.117.27.85 -p 30064``. + 1. SSH to server **srv04-nyc**: ``ssh demo@216.172.128.214 -p 30064``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping4 1.1.1.1`` diff --git a/sandbox/Sandbox14/creating-services.rst b/sandbox/Sandbox14/creating-services.rst index 44b68743a..f9b2a1e75 100644 --- a/sandbox/Sandbox14/creating-services.rst +++ b/sandbox/Sandbox14/creating-services.rst @@ -17,7 +17,7 @@ Let's create a V-Net service to give server **srv05-nyc** the ability to reach i * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@50.117.27.85 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.214 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Type ``ip route ls`` and we can see **192.168.46.1** is configured as the default gateway, indicated by the "**default via 192.168.46.1 dev eth1 proto kernel onlink**" line in the output. 4. Start a ping session towards the default gateway: ``ping 192.168.46.1`` @@ -90,7 +90,7 @@ Now that we have both internal and external facing services, we can aim for our * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@50.117.27.85 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.214 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session towards any public IP address (e.g. ``ping 1.1.1.1``). 4. Keep the ping running as an indicator for when the service starts to work. @@ -176,7 +176,7 @@ Now that **srv05-nyc** can communicate with both internal and external hosts, le * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@50.117.27.85 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.214 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping 1.1.1.1``. 4. If the previous steps were followed, you should see successful ping replies in the form of "**64 bytes from 1.1.1.1: icmp_seq=55 ttl=62 time=1.23 ms**". diff --git a/sandbox/Sandbox14/index.rst b/sandbox/Sandbox14/index.rst index f48f80f4f..f41555557 100644 --- a/sandbox/Sandbox14/index.rst +++ b/sandbox/Sandbox14/index.rst @@ -7,7 +7,7 @@ ------------------------------------------------------------------------------------------------ Sandbox15 # Sandbox name Uppercase(case sensitive) sandbox15 # Sandbox name Lowercase - 50.117.27.85 # Hypervisor PUBLIC IP + 216.172.128.214 # Hypervisor PUBLIC IP 10.254.45.0/24 # *STATIC NO NEED TO REPLACE* MANAGEMENT Allocation/Subnet 10.254.46.0/24 # *STATIC NO NEED TO REPLACE* LOOPBACK Allocation/Subnet 192.168.44.0/24 # *STATIC NO NEED TO REPLACE* ROH Allocation/Subnet diff --git a/sandbox/Sandbox14/sandbox-info.rst b/sandbox/Sandbox14/sandbox-info.rst index f5f6d851a..38fe71bcb 100644 --- a/sandbox/Sandbox14/sandbox-info.rst +++ b/sandbox/Sandbox14/sandbox-info.rst @@ -49,11 +49,11 @@ Example pre-configured Netris services: .. code-block:: shell-session - srv01-nyc: ssh demo@50.117.27.85 -p 30061 - srv02-nyc: ssh demo@50.117.27.85 -p 30062 - srv03-nyc: ssh demo@50.117.27.85 -p 30063 - srv04-nyc: ssh demo@50.117.27.85 -p 30064 - srv05-nyc: ssh demo@50.117.27.85 -p 30065 + srv01-nyc: ssh demo@216.172.128.214 -p 30061 + srv02-nyc: ssh demo@216.172.128.214 -p 30062 + srv03-nyc: ssh demo@216.172.128.214 -p 30063 + srv04-nyc: ssh demo@216.172.128.214 -p 30064 + srv05-nyc: ssh demo@216.172.128.214 -p 30065 Kubernetes cluster diff --git a/sandbox/Sandbox15/configurations.rst b/sandbox/Sandbox15/configurations.rst index d4b790d0a..117a88e76 100644 --- a/sandbox/Sandbox15/configurations.rst +++ b/sandbox/Sandbox15/configurations.rst @@ -70,7 +70,7 @@ You may also observe the functioning NAT rule in action by pinging any public IP * In a terminal window: - 1. SSH to server **srv04-nyc**: ``ssh demo@50.117.27.86 -p 30064``. + 1. SSH to server **srv04-nyc**: ``ssh demo@216.172.128.215 -p 30064``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping4 1.1.1.1`` diff --git a/sandbox/Sandbox15/creating-services.rst b/sandbox/Sandbox15/creating-services.rst index f01f7b18c..269e74053 100644 --- a/sandbox/Sandbox15/creating-services.rst +++ b/sandbox/Sandbox15/creating-services.rst @@ -17,7 +17,7 @@ Let's create a V-Net service to give server **srv05-nyc** the ability to reach i * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@50.117.27.86 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.215 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Type ``ip route ls`` and we can see **192.168.46.1** is configured as the default gateway, indicated by the "**default via 192.168.46.1 dev eth1 proto kernel onlink**" line in the output. 4. Start a ping session towards the default gateway: ``ping 192.168.46.1`` @@ -90,7 +90,7 @@ Now that we have both internal and external facing services, we can aim for our * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@50.117.27.86 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.215 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session towards any public IP address (e.g. ``ping 1.1.1.1``). 4. Keep the ping running as an indicator for when the service starts to work. @@ -176,7 +176,7 @@ Now that **srv05-nyc** can communicate with both internal and external hosts, le * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@50.117.27.86 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.215 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping 1.1.1.1``. 4. If the previous steps were followed, you should see successful ping replies in the form of "**64 bytes from 1.1.1.1: icmp_seq=55 ttl=62 time=1.23 ms**". diff --git a/sandbox/Sandbox15/index.rst b/sandbox/Sandbox15/index.rst index 14072593f..27b4ee674 100644 --- a/sandbox/Sandbox15/index.rst +++ b/sandbox/Sandbox15/index.rst @@ -7,7 +7,7 @@ ------------------------------------------------------------------------------------------------ Sandbox15 # Sandbox name Uppercase(case sensitive) sandbox15 # Sandbox name Lowercase - 50.117.27.86 # Hypervisor PUBLIC IP + 216.172.128.215 # Hypervisor PUBLIC IP 10.254.45.0/24 # *STATIC NO NEED TO REPLACE* MANAGEMENT Allocation/Subnet 10.254.46.0/24 # *STATIC NO NEED TO REPLACE* LOOPBACK Allocation/Subnet 192.168.44.0/24 # *STATIC NO NEED TO REPLACE* ROH Allocation/Subnet diff --git a/sandbox/Sandbox15/sandbox-info.rst b/sandbox/Sandbox15/sandbox-info.rst index 2eccb270c..f05ada9e6 100644 --- a/sandbox/Sandbox15/sandbox-info.rst +++ b/sandbox/Sandbox15/sandbox-info.rst @@ -49,11 +49,11 @@ Example pre-configured Netris services: .. code-block:: shell-session - srv01-nyc: ssh demo@50.117.27.86 -p 30061 - srv02-nyc: ssh demo@50.117.27.86 -p 30062 - srv03-nyc: ssh demo@50.117.27.86 -p 30063 - srv04-nyc: ssh demo@50.117.27.86 -p 30064 - srv05-nyc: ssh demo@50.117.27.86 -p 30065 + srv01-nyc: ssh demo@216.172.128.215 -p 30061 + srv02-nyc: ssh demo@216.172.128.215 -p 30062 + srv03-nyc: ssh demo@216.172.128.215 -p 30063 + srv04-nyc: ssh demo@216.172.128.215 -p 30064 + srv05-nyc: ssh demo@216.172.128.215 -p 30065 Kubernetes cluster diff --git a/sandbox/Sandbox2/configurations.rst b/sandbox/Sandbox2/configurations.rst index 77a921721..92b835ebd 100644 --- a/sandbox/Sandbox2/configurations.rst +++ b/sandbox/Sandbox2/configurations.rst @@ -70,7 +70,7 @@ You may also observe the functioning NAT rule in action by pinging any public IP * In a terminal window: - 1. SSH to server **srv04-nyc**: ``ssh demo@166.88.17.190 -p 30064``. + 1. SSH to server **srv04-nyc**: ``ssh demo@216.172.128.202 -p 30064``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping4 1.1.1.1`` diff --git a/sandbox/Sandbox2/creating-services.rst b/sandbox/Sandbox2/creating-services.rst index 839bca3e0..1159750b8 100644 --- a/sandbox/Sandbox2/creating-services.rst +++ b/sandbox/Sandbox2/creating-services.rst @@ -17,7 +17,7 @@ Let's create a V-Net service to give server **srv05-nyc** the ability to reach i * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.190 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.202 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Type ``ip route ls`` and we can see **192.168.46.1** is configured as the default gateway, indicated by the "**default via 192.168.46.1 dev eth1 proto kernel onlink**" line in the output. 4. Start a ping session towards the default gateway: ``ping 192.168.46.1`` @@ -90,7 +90,7 @@ Now that we have both internal and external facing services, we can aim for our * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.190 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.202 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session towards any public IP address (e.g. ``ping 1.1.1.1``). 4. Keep the ping running as an indicator for when the service starts to work. @@ -176,7 +176,7 @@ Now that **srv05-nyc** can communicate with both internal and external hosts, le * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.190 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.202 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping 1.1.1.1``. 4. If the previous steps were followed, you should see successful ping replies in the form of "**64 bytes from 1.1.1.1: icmp_seq=55 ttl=62 time=1.23 ms**". diff --git a/sandbox/Sandbox2/index.rst b/sandbox/Sandbox2/index.rst index b5f4205fd..332fc9240 100644 --- a/sandbox/Sandbox2/index.rst +++ b/sandbox/Sandbox2/index.rst @@ -7,7 +7,7 @@ ------------------------------------------------------------------------------------------------ Sandbox2 # Sandbox name Uppercase(case sensitive) sandbox2 # Sandbox name Lowercase - 166.88.17.190 # Hypervisor PUBLIC IP + 216.172.128.202 # Hypervisor PUBLIC IP 10.254.45.0/24 # *STATIC NO NEED TO REPLACE* MANAGEMENT Allocation/Subnet 10.254.46.0/24 # *STATIC NO NEED TO REPLACE* LOOPBACK Allocation/Subnet 192.168.44.0/24 # *STATIC NO NEED TO REPLACE* ROH Allocation/Subnet diff --git a/sandbox/Sandbox2/sandbox-info.rst b/sandbox/Sandbox2/sandbox-info.rst index 778682845..6959a1247 100644 --- a/sandbox/Sandbox2/sandbox-info.rst +++ b/sandbox/Sandbox2/sandbox-info.rst @@ -49,11 +49,11 @@ Example pre-configured Netris services: .. code-block:: shell-session - srv01-nyc: ssh demo@166.88.17.190 -p 30061 - srv02-nyc: ssh demo@166.88.17.190 -p 30062 - srv03-nyc: ssh demo@166.88.17.190 -p 30063 - srv04-nyc: ssh demo@166.88.17.190 -p 30064 - srv05-nyc: ssh demo@166.88.17.190 -p 30065 + srv01-nyc: ssh demo@216.172.128.202 -p 30061 + srv02-nyc: ssh demo@216.172.128.202 -p 30062 + srv03-nyc: ssh demo@216.172.128.202 -p 30063 + srv04-nyc: ssh demo@216.172.128.202 -p 30064 + srv05-nyc: ssh demo@216.172.128.202 -p 30065 Kubernetes cluster diff --git a/sandbox/Sandbox3/configurations.rst b/sandbox/Sandbox3/configurations.rst index e4e99a6ac..ac48ab83f 100644 --- a/sandbox/Sandbox3/configurations.rst +++ b/sandbox/Sandbox3/configurations.rst @@ -70,7 +70,7 @@ You may also observe the functioning NAT rule in action by pinging any public IP * In a terminal window: - 1. SSH to server **srv04-nyc**: ``ssh demo@166.88.17.189 -p 30064``. + 1. SSH to server **srv04-nyc**: ``ssh demo@216.172.128.203 -p 30064``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping4 1.1.1.1`` diff --git a/sandbox/Sandbox3/creating-services.rst b/sandbox/Sandbox3/creating-services.rst index 109be7dee..43acfec24 100644 --- a/sandbox/Sandbox3/creating-services.rst +++ b/sandbox/Sandbox3/creating-services.rst @@ -17,7 +17,7 @@ Let's create a V-Net service to give server **srv05-nyc** the ability to reach i * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.189 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.203 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Type ``ip route ls`` and we can see **192.168.46.1** is configured as the default gateway, indicated by the "**default via 192.168.46.1 dev eth1 proto kernel onlink**" line in the output. 4. Start a ping session towards the default gateway: ``ping 192.168.46.1`` @@ -90,7 +90,7 @@ Now that we have both internal and external facing services, we can aim for our * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.189 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.203 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session towards any public IP address (e.g. ``ping 1.1.1.1``). 4. Keep the ping running as an indicator for when the service starts to work. @@ -176,7 +176,7 @@ Now that **srv05-nyc** can communicate with both internal and external hosts, le * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.189 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.203 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping 1.1.1.1``. 4. If the previous steps were followed, you should see successful ping replies in the form of "**64 bytes from 1.1.1.1: icmp_seq=55 ttl=62 time=1.23 ms**". diff --git a/sandbox/Sandbox3/index.rst b/sandbox/Sandbox3/index.rst index 45e3a10c1..f1ae80a3f 100644 --- a/sandbox/Sandbox3/index.rst +++ b/sandbox/Sandbox3/index.rst @@ -7,7 +7,7 @@ ------------------------------------------------------------------------------------------------ Sandbox3 # Sandbox name Uppercase(case sensitive) sandbox3 # Sandbox name Lowercase - 166.88.17.189 # Hypervisor PUBLIC IP + 216.172.128.203 # Hypervisor PUBLIC IP 10.254.45.0/24 # *STATIC NO NEED TO REPLACE* MANAGEMENT Allocation/Subnet 10.254.46.0/24 # *STATIC NO NEED TO REPLACE* LOOPBACK Allocation/Subnet 192.168.44.0/24 # *STATIC NO NEED TO REPLACE* ROH Allocation/Subnet diff --git a/sandbox/Sandbox3/sandbox-info.rst b/sandbox/Sandbox3/sandbox-info.rst index 9c0726eb7..51ea85a86 100644 --- a/sandbox/Sandbox3/sandbox-info.rst +++ b/sandbox/Sandbox3/sandbox-info.rst @@ -49,11 +49,11 @@ Example pre-configured Netris services: .. code-block:: shell-session - srv01-nyc: ssh demo@166.88.17.189 -p 30061 - srv02-nyc: ssh demo@166.88.17.189 -p 30062 - srv03-nyc: ssh demo@166.88.17.189 -p 30063 - srv04-nyc: ssh demo@166.88.17.189 -p 30064 - srv05-nyc: ssh demo@166.88.17.189 -p 30065 + srv01-nyc: ssh demo@216.172.128.203 -p 30061 + srv02-nyc: ssh demo@216.172.128.203 -p 30062 + srv03-nyc: ssh demo@216.172.128.203 -p 30063 + srv04-nyc: ssh demo@216.172.128.203 -p 30064 + srv05-nyc: ssh demo@216.172.128.203 -p 30065 Kubernetes cluster diff --git a/sandbox/Sandbox4/configurations.rst b/sandbox/Sandbox4/configurations.rst index 13e5a4501..77d913b85 100644 --- a/sandbox/Sandbox4/configurations.rst +++ b/sandbox/Sandbox4/configurations.rst @@ -70,7 +70,7 @@ You may also observe the functioning NAT rule in action by pinging any public IP * In a terminal window: - 1. SSH to server **srv04-nyc**: ``ssh demo@166.88.17.188 -p 30064``. + 1. SSH to server **srv04-nyc**: ``ssh demo@216.172.128.204 -p 30064``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping4 1.1.1.1`` diff --git a/sandbox/Sandbox4/creating-services.rst b/sandbox/Sandbox4/creating-services.rst index c5510511e..d9235f065 100644 --- a/sandbox/Sandbox4/creating-services.rst +++ b/sandbox/Sandbox4/creating-services.rst @@ -17,7 +17,7 @@ Let's create a V-Net service to give server **srv05-nyc** the ability to reach i * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.188 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.204 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Type ``ip route ls`` and we can see **192.168.46.1** is configured as the default gateway, indicated by the "**default via 192.168.46.1 dev eth1 proto kernel onlink**" line in the output. 4. Start a ping session towards the default gateway: ``ping 192.168.46.1`` @@ -90,7 +90,7 @@ Now that we have both internal and external facing services, we can aim for our * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.188 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.204 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session towards any public IP address (e.g. ``ping 1.1.1.1``). 4. Keep the ping running as an indicator for when the service starts to work. @@ -176,7 +176,7 @@ Now that **srv05-nyc** can communicate with both internal and external hosts, le * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.188 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.204 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping 1.1.1.1``. 4. If the previous steps were followed, you should see successful ping replies in the form of "**64 bytes from 1.1.1.1: icmp_seq=55 ttl=62 time=1.23 ms**". diff --git a/sandbox/Sandbox4/index.rst b/sandbox/Sandbox4/index.rst index 066815cce..988205b91 100644 --- a/sandbox/Sandbox4/index.rst +++ b/sandbox/Sandbox4/index.rst @@ -7,7 +7,7 @@ ------------------------------------------------------------------------------------------------ Sandbox4 # Sandbox name Uppercase(case sensitive) sandbox4 # Sandbox name Lowercase - 166.88.17.188 # Hypervisor PUBLIC IP + 216.172.128.204 # Hypervisor PUBLIC IP 10.254.45.0/24 # *STATIC NO NEED TO REPLACE* MANAGEMENT Allocation/Subnet 10.254.46.0/24 # *STATIC NO NEED TO REPLACE* LOOPBACK Allocation/Subnet 192.168.44.0/24 # *STATIC NO NEED TO REPLACE* ROH Allocation/Subnet diff --git a/sandbox/Sandbox4/sandbox-info.rst b/sandbox/Sandbox4/sandbox-info.rst index 743e5487d..cb37610bc 100644 --- a/sandbox/Sandbox4/sandbox-info.rst +++ b/sandbox/Sandbox4/sandbox-info.rst @@ -49,11 +49,11 @@ Example pre-configured Netris services: .. code-block:: shell-session - srv01-nyc: ssh demo@166.88.17.188 -p 30061 - srv02-nyc: ssh demo@166.88.17.188 -p 30062 - srv03-nyc: ssh demo@166.88.17.188 -p 30063 - srv04-nyc: ssh demo@166.88.17.188 -p 30064 - srv05-nyc: ssh demo@166.88.17.188 -p 30065 + srv01-nyc: ssh demo@216.172.128.204 -p 30061 + srv02-nyc: ssh demo@216.172.128.204 -p 30062 + srv03-nyc: ssh demo@216.172.128.204 -p 30063 + srv04-nyc: ssh demo@216.172.128.204 -p 30064 + srv05-nyc: ssh demo@216.172.128.204 -p 30065 Kubernetes cluster diff --git a/sandbox/Sandbox5/configurations.rst b/sandbox/Sandbox5/configurations.rst index a9b28a548..8815bd652 100644 --- a/sandbox/Sandbox5/configurations.rst +++ b/sandbox/Sandbox5/configurations.rst @@ -70,7 +70,7 @@ You may also observe the functioning NAT rule in action by pinging any public IP * In a terminal window: - 1. SSH to server **srv04-nyc**: ``ssh demo@166.88.17.187 -p 30064``. + 1. SSH to server **srv04-nyc**: ``ssh demo@216.172.128.205 -p 30064``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping4 1.1.1.1`` diff --git a/sandbox/Sandbox5/creating-services.rst b/sandbox/Sandbox5/creating-services.rst index e0cc42d4c..86858b8c6 100644 --- a/sandbox/Sandbox5/creating-services.rst +++ b/sandbox/Sandbox5/creating-services.rst @@ -17,7 +17,7 @@ Let's create a V-Net service to give server **srv05-nyc** the ability to reach i * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.187 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.205 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Type ``ip route ls`` and we can see **192.168.46.1** is configured as the default gateway, indicated by the "**default via 192.168.46.1 dev eth1 proto kernel onlink**" line in the output. 4. Start a ping session towards the default gateway: ``ping 192.168.46.1`` @@ -90,7 +90,7 @@ Now that we have both internal and external facing services, we can aim for our * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.187 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.205 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session towards any public IP address (e.g. ``ping 1.1.1.1``). 4. Keep the ping running as an indicator for when the service starts to work. @@ -176,7 +176,7 @@ Now that **srv05-nyc** can communicate with both internal and external hosts, le * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.187 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.205 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping 1.1.1.1``. 4. If the previous steps were followed, you should see successful ping replies in the form of "**64 bytes from 1.1.1.1: icmp_seq=55 ttl=62 time=1.23 ms**". diff --git a/sandbox/Sandbox5/index.rst b/sandbox/Sandbox5/index.rst index fabe3e986..e0e24ffbd 100644 --- a/sandbox/Sandbox5/index.rst +++ b/sandbox/Sandbox5/index.rst @@ -7,7 +7,7 @@ ------------------------------------------------------------------------------------------------ Sandbox5 # Sandbox name Uppercase(case sensitive) sandbox5 # Sandbox name Lowercase - 166.88.17.187 # Hypervisor PUBLIC IP + 216.172.128.205 # Hypervisor PUBLIC IP 10.254.45.0/24 # *STATIC NO NEED TO REPLACE* MANAGEMENT Allocation/Subnet 10.254.46.0/24 # *STATIC NO NEED TO REPLACE* LOOPBACK Allocation/Subnet 192.168.44.0/24 # *STATIC NO NEED TO REPLACE* ROH Allocation/Subnet diff --git a/sandbox/Sandbox5/sandbox-info.rst b/sandbox/Sandbox5/sandbox-info.rst index a5c3aa970..032acd1e0 100644 --- a/sandbox/Sandbox5/sandbox-info.rst +++ b/sandbox/Sandbox5/sandbox-info.rst @@ -49,11 +49,11 @@ Example pre-configured Netris services: .. code-block:: shell-session - srv01-nyc: ssh demo@166.88.17.187 -p 30061 - srv02-nyc: ssh demo@166.88.17.187 -p 30062 - srv03-nyc: ssh demo@166.88.17.187 -p 30063 - srv04-nyc: ssh demo@166.88.17.187 -p 30064 - srv05-nyc: ssh demo@166.88.17.187 -p 30065 + srv01-nyc: ssh demo@216.172.128.205 -p 30061 + srv02-nyc: ssh demo@216.172.128.205 -p 30062 + srv03-nyc: ssh demo@216.172.128.205 -p 30063 + srv04-nyc: ssh demo@216.172.128.205 -p 30064 + srv05-nyc: ssh demo@216.172.128.205 -p 30065 Kubernetes cluster diff --git a/sandbox/Sandbox6/configurations.rst b/sandbox/Sandbox6/configurations.rst index f7823f513..b01341afd 100644 --- a/sandbox/Sandbox6/configurations.rst +++ b/sandbox/Sandbox6/configurations.rst @@ -54,7 +54,7 @@ You may observe the functioning service by pinging the pubblic **1.1.1.1** IP ad * In a terminal window: - 1. SSH to srv04-nyc by typing ``ssh demo@166.88.17.186 -p 30064``. + 1. SSH to srv04-nyc by typing ``ssh demo@216.172.128.206 -p 30064``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session by typing ``ping 1.1.1.1`` diff --git a/sandbox/Sandbox6/creating-services.rst b/sandbox/Sandbox6/creating-services.rst index fd8cc5864..8aa15deb7 100644 --- a/sandbox/Sandbox6/creating-services.rst +++ b/sandbox/Sandbox6/creating-services.rst @@ -11,7 +11,7 @@ Let's create a V-Net service to give server **srv05-nyc** the ability to reach i * In a terminal window: - 1. SSH to the **srv05-nyc** server by typing ``ssh demo@166.88.17.186 -p 30065``. + 1. SSH to the **srv05-nyc** server by typing ``ssh demo@216.172.128.206 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Type ``ip route ls`` and we can see ``192.168.46.1`` is configured as the default gateway, indicated by the "**default via 192.168.46.1 dev eth1 proto kernel onlink**" line in the output. 4. Start a ping session towards the default gateway by typing ``ping 192.168.46.1`` and keep it running as an indicator for when the service becomes fully provisioned. @@ -71,7 +71,7 @@ Now when we have both internal and external facing services, we can aim for our * In a terminal window: - 1. SSH to srv05-nyc by typing ``ssh demo@166.88.17.186 -p 30065``. + 1. SSH to srv05-nyc by typing ``ssh demo@216.172.128.206 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session by typing ``ping 1.1.1.1`` and keep it running as an indicator for when the service starts to work. @@ -102,7 +102,7 @@ Now that **srv05-nyc** can communicate with both internal and external hosts, le * In a terminal window: - 1. SSH to srv05-nyc by typing ``ssh demo@166.88.17.186 -p 30065``. + 1. SSH to srv05-nyc by typing ``ssh demo@216.172.128.206 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session by typing ``ping 1.1.1.1`` and keep it running for the duration of this exercise. diff --git a/sandbox/Sandbox6/index.rst b/sandbox/Sandbox6/index.rst index 1af6cfa72..a6239b9e0 100644 --- a/sandbox/Sandbox6/index.rst +++ b/sandbox/Sandbox6/index.rst @@ -6,7 +6,7 @@ values | description ------------------------------------------------------------------------------------------------ sandbox6 # sandbox name - 166.88.17.186 # hypervisor public ip + 216.172.128.206 # hypervisor public ip 300 # *STATIC NO NEED TO REPLACE* ssh NAT port *SHORT QUERY BE CAREFUL WHILE REPLACING* 10.254.45.0/24 # *STATIC NO NEED TO REPLACE* management subnet 10.254.46.0/24 # *STATIC NO NEED TO REPLACE* loopback subnet diff --git a/sandbox/Sandbox6/sandbox-info.rst b/sandbox/Sandbox6/sandbox-info.rst index d11f970cc..4bb02030b 100644 --- a/sandbox/Sandbox6/sandbox-info.rst +++ b/sandbox/Sandbox6/sandbox-info.rst @@ -40,11 +40,11 @@ Example pre-configured Netris services: .. code-block:: shell-session - srv01: ssh demo@166.88.17.186 -p 30061 - srv02: ssh demo@166.88.17.186 -p 30062 - srv03: ssh demo@166.88.17.186 -p 30063 - srv04: ssh demo@166.88.17.186 -p 30064 - srv05: ssh demo@166.88.17.186 -p 30065 + srv01: ssh demo@216.172.128.206 -p 30061 + srv02: ssh demo@216.172.128.206 -p 30062 + srv03: ssh demo@216.172.128.206 -p 30063 + srv04: ssh demo@216.172.128.206 -p 30064 + srv05: ssh demo@216.172.128.206 -p 30065 Kubernetes cluster diff --git a/sandbox/Sandbox7/configurations.rst b/sandbox/Sandbox7/configurations.rst index 887956fa2..7377a8baa 100644 --- a/sandbox/Sandbox7/configurations.rst +++ b/sandbox/Sandbox7/configurations.rst @@ -70,7 +70,7 @@ You may also observe the functioning NAT rule in action by pinging any public IP * In a terminal window: - 1. SSH to server **srv04-nyc**: ``ssh demo@166.88.17.185 -p 30064``. + 1. SSH to server **srv04-nyc**: ``ssh demo@216.172.128.207 -p 30064``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping4 1.1.1.1`` diff --git a/sandbox/Sandbox7/creating-services.rst b/sandbox/Sandbox7/creating-services.rst index 8569eea9e..7b762af62 100644 --- a/sandbox/Sandbox7/creating-services.rst +++ b/sandbox/Sandbox7/creating-services.rst @@ -17,7 +17,7 @@ Let's create a V-Net service to give server **srv05-nyc** the ability to reach i * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.185 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.207 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Type ``ip route ls`` and we can see **192.168.46.1** is configured as the default gateway, indicated by the "**default via 192.168.46.1 dev eth1 proto kernel onlink**" line in the output. 4. Start a ping session towards the default gateway: ``ping 192.168.46.1`` @@ -90,7 +90,7 @@ Now that we have both internal and external facing services, we can aim for our * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.185 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.207 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session towards any public IP address (e.g. ``ping 1.1.1.1``). 4. Keep the ping running as an indicator for when the service starts to work. @@ -176,7 +176,7 @@ Now that **srv05-nyc** can communicate with both internal and external hosts, le * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.185 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.207 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping 1.1.1.1``. 4. If the previous steps were followed, you should see successful ping replies in the form of "**64 bytes from 1.1.1.1: icmp_seq=55 ttl=62 time=1.23 ms**". diff --git a/sandbox/Sandbox7/index.rst b/sandbox/Sandbox7/index.rst index 04275ae82..170516e2c 100644 --- a/sandbox/Sandbox7/index.rst +++ b/sandbox/Sandbox7/index.rst @@ -7,7 +7,7 @@ ------------------------------------------------------------------------------------------------ Sandbox7 # Sandbox name Uppercase(case sensitive) sandbox7 # Sandbox name Lowercase - 166.88.17.185 # Hypervisor PUBLIC IP + 216.172.128.207 # Hypervisor PUBLIC IP 10.254.45.0/24 # *STATIC NO NEED TO REPLACE* MANAGEMENT Allocation/Subnet 10.254.46.0/24 # *STATIC NO NEED TO REPLACE* LOOPBACK Allocation/Subnet 192.168.44.0/24 # *STATIC NO NEED TO REPLACE* ROH Allocation/Subnet diff --git a/sandbox/Sandbox7/sandbox-info.rst b/sandbox/Sandbox7/sandbox-info.rst index 11926e0b3..c1df99a20 100644 --- a/sandbox/Sandbox7/sandbox-info.rst +++ b/sandbox/Sandbox7/sandbox-info.rst @@ -49,11 +49,11 @@ Example pre-configured Netris services: .. code-block:: shell-session - srv01-nyc: ssh demo@166.88.17.185 -p 30061 - srv02-nyc: ssh demo@166.88.17.185 -p 30062 - srv03-nyc: ssh demo@166.88.17.185 -p 30063 - srv04-nyc: ssh demo@166.88.17.185 -p 30064 - srv05-nyc: ssh demo@166.88.17.185 -p 30065 + srv01-nyc: ssh demo@216.172.128.207 -p 30061 + srv02-nyc: ssh demo@216.172.128.207 -p 30062 + srv03-nyc: ssh demo@216.172.128.207 -p 30063 + srv04-nyc: ssh demo@216.172.128.207 -p 30064 + srv05-nyc: ssh demo@216.172.128.207 -p 30065 Kubernetes cluster diff --git a/sandbox/Sandbox8/configurations.rst b/sandbox/Sandbox8/configurations.rst index 4bbbbb66c..147c4ecad 100644 --- a/sandbox/Sandbox8/configurations.rst +++ b/sandbox/Sandbox8/configurations.rst @@ -70,7 +70,7 @@ You may also observe the functioning NAT rule in action by pinging any public IP * In a terminal window: - 1. SSH to server **srv04-nyc**: ``ssh demo@166.88.17.29 -p 30064``. + 1. SSH to server **srv04-nyc**: ``ssh demo@216.172.128.208 -p 30064``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping4 1.1.1.1`` diff --git a/sandbox/Sandbox8/creating-services.rst b/sandbox/Sandbox8/creating-services.rst index a4b9b6248..55cd97e62 100644 --- a/sandbox/Sandbox8/creating-services.rst +++ b/sandbox/Sandbox8/creating-services.rst @@ -17,7 +17,7 @@ Let's create a V-Net service to give server **srv05-nyc** the ability to reach i * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.29 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.208 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Type ``ip route ls`` and we can see **192.168.46.1** is configured as the default gateway, indicated by the "**default via 192.168.46.1 dev eth1 proto kernel onlink**" line in the output. 4. Start a ping session towards the default gateway: ``ping 192.168.46.1`` @@ -90,7 +90,7 @@ Now that we have both internal and external facing services, we can aim for our * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.29 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.208 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session towards any public IP address (e.g. ``ping 1.1.1.1``). 4. Keep the ping running as an indicator for when the service starts to work. @@ -176,7 +176,7 @@ Now that **srv05-nyc** can communicate with both internal and external hosts, le * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.29 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.208 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping 1.1.1.1``. 4. If the previous steps were followed, you should see successful ping replies in the form of "**64 bytes from 1.1.1.1: icmp_seq=55 ttl=62 time=1.23 ms**". diff --git a/sandbox/Sandbox8/index.rst b/sandbox/Sandbox8/index.rst index 53b95ef0d..770d250a4 100644 --- a/sandbox/Sandbox8/index.rst +++ b/sandbox/Sandbox8/index.rst @@ -7,7 +7,7 @@ ------------------------------------------------------------------------------------------------ Sandbox8 # Sandbox name Uppercase(case sensitive) sandbox8 # Sandbox name Lowercase - 166.88.17.29 # Hypervisor PUBLIC IP + 216.172.128.208 # Hypervisor PUBLIC IP 10.254.45.0/24 # *STATIC NO NEED TO REPLACE* MANAGEMENT Allocation/Subnet 10.254.46.0/24 # *STATIC NO NEED TO REPLACE* LOOPBACK Allocation/Subnet 192.168.44.0/24 # *STATIC NO NEED TO REPLACE* ROH Allocation/Subnet diff --git a/sandbox/Sandbox8/sandbox-info.rst b/sandbox/Sandbox8/sandbox-info.rst index 9725bdace..2751df538 100644 --- a/sandbox/Sandbox8/sandbox-info.rst +++ b/sandbox/Sandbox8/sandbox-info.rst @@ -49,11 +49,11 @@ Example pre-configured Netris services: .. code-block:: shell-session - srv01-nyc: ssh demo@166.88.17.29 -p 30061 - srv02-nyc: ssh demo@166.88.17.29 -p 30062 - srv03-nyc: ssh demo@166.88.17.29 -p 30063 - srv04-nyc: ssh demo@166.88.17.29 -p 30064 - srv05-nyc: ssh demo@166.88.17.29 -p 30065 + srv01-nyc: ssh demo@216.172.128.208 -p 30061 + srv02-nyc: ssh demo@216.172.128.208 -p 30062 + srv03-nyc: ssh demo@216.172.128.208 -p 30063 + srv04-nyc: ssh demo@216.172.128.208 -p 30064 + srv05-nyc: ssh demo@216.172.128.208 -p 30065 Kubernetes cluster diff --git a/sandbox/Sandbox9/configurations.rst b/sandbox/Sandbox9/configurations.rst index 190ae4602..88da23697 100644 --- a/sandbox/Sandbox9/configurations.rst +++ b/sandbox/Sandbox9/configurations.rst @@ -70,7 +70,7 @@ You may also observe the functioning NAT rule in action by pinging any public IP * In a terminal window: - 1. SSH to server **srv04-nyc**: ``ssh demo@166.88.17.22 -p 30064``. + 1. SSH to server **srv04-nyc**: ``ssh demo@216.172.128.209 -p 30064``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping4 1.1.1.1`` diff --git a/sandbox/Sandbox9/creating-services.rst b/sandbox/Sandbox9/creating-services.rst index 5584c8251..6ee361146 100644 --- a/sandbox/Sandbox9/creating-services.rst +++ b/sandbox/Sandbox9/creating-services.rst @@ -17,7 +17,7 @@ Let's create a V-Net service to give server **srv05-nyc** the ability to reach i * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.22 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.209 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Type ``ip route ls`` and we can see **192.168.46.1** is configured as the default gateway, indicated by the "**default via 192.168.46.1 dev eth1 proto kernel onlink**" line in the output. 4. Start a ping session towards the default gateway: ``ping 192.168.46.1`` @@ -90,7 +90,7 @@ Now that we have both internal and external facing services, we can aim for our * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.22 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.209 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session towards any public IP address (e.g. ``ping 1.1.1.1``). 4. Keep the ping running as an indicator for when the service starts to work. @@ -176,7 +176,7 @@ Now that **srv05-nyc** can communicate with both internal and external hosts, le * In a terminal window: - 1. SSH to server **srv05-nyc**: ``ssh demo@166.88.17.22 -p 30065``. + 1. SSH to server **srv05-nyc**: ``ssh demo@216.172.128.209 -p 30065``. 2. Enter the password provided in the introductory e-mail. 3. Start a ping session: ``ping 1.1.1.1``. 4. If the previous steps were followed, you should see successful ping replies in the form of "**64 bytes from 1.1.1.1: icmp_seq=55 ttl=62 time=1.23 ms**". diff --git a/sandbox/Sandbox9/index.rst b/sandbox/Sandbox9/index.rst index 351ff318d..a5c19c494 100644 --- a/sandbox/Sandbox9/index.rst +++ b/sandbox/Sandbox9/index.rst @@ -7,7 +7,7 @@ ------------------------------------------------------------------------------------------------ Sandbox9 # Sandbox name Uppercase(case sensitive) sandbox9 # Sandbox name Lowercase - 166.88.17.22 # Hypervisor PUBLIC IP + 216.172.128.209 # Hypervisor PUBLIC IP 10.254.45.0/24 # *STATIC NO NEED TO REPLACE* MANAGEMENT Allocation/Subnet 10.254.46.0/24 # *STATIC NO NEED TO REPLACE* LOOPBACK Allocation/Subnet 192.168.44.0/24 # *STATIC NO NEED TO REPLACE* ROH Allocation/Subnet diff --git a/sandbox/Sandbox9/sandbox-info.rst b/sandbox/Sandbox9/sandbox-info.rst index 5eba3f2d8..1750c6c36 100644 --- a/sandbox/Sandbox9/sandbox-info.rst +++ b/sandbox/Sandbox9/sandbox-info.rst @@ -49,11 +49,11 @@ Example pre-configured Netris services: .. code-block:: shell-session - srv01-nyc: ssh demo@166.88.17.22 -p 30061 - srv02-nyc: ssh demo@166.88.17.22 -p 30062 - srv03-nyc: ssh demo@166.88.17.22 -p 30063 - srv04-nyc: ssh demo@166.88.17.22 -p 30064 - srv05-nyc: ssh demo@166.88.17.22 -p 30065 + srv01-nyc: ssh demo@216.172.128.209 -p 30061 + srv02-nyc: ssh demo@216.172.128.209 -p 30062 + srv03-nyc: ssh demo@216.172.128.209 -p 30063 + srv04-nyc: ssh demo@216.172.128.209 -p 30064 + srv05-nyc: ssh demo@216.172.128.209 -p 30065 Kubernetes cluster