Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Flow improvement #43

Open
wants to merge 10 commits into
base: master
Choose a base branch
from
Open

Flow improvement #43

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
a5add18
adjust flow and section headings
mrbojangles3 Oct 30, 2024
8abff16
add oras and hhfab to prerequisites
mrbojangles3 Oct 30, 2024
96ee813
clearer text
mrbojangles3 Oct 30, 2024
4aa22fa
add username and password to ghcr login command
mrbojangles3 Oct 30, 2024
7a4b503
Apply suggestions from Quentin
mrbojangles3 Oct 31, 2024
c97c650
add username and password flag into example
mrbojangles3 Oct 31, 2024
a042b12
integrating comments from Quentin
mrbojangles3 Oct 31, 2024
9cb3690
title,proper noun, and cli
mrbojangles3 Oct 31, 2024
938bb89
Merge branch 'master' into flow_improvement
mrbojangles3 Oct 31, 2024
580863a
descriptions belong at the start
mrbojangles3 Nov 1, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/getting-started/download.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ After that you will be provided with the credentials to access the software on [
In order to use the software, log in to the registry using the following command:

```bash
docker login ghcr.io
docker login ghcr.io --username provided_user_name --password provided_token_string
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not using prompt?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am guessing that people will like to use the copy paste. But I am flexible.

```

## Downloading hhfab
Expand Down
254 changes: 127 additions & 127 deletions docs/vlab/demo.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -86,14 +86,126 @@ graph TD
L1 & L2 & L2 & L3 & L4 & L5 <----> S1 & S2
```

## Utility based VPC creation

### Setup VPCs
`hhfab vlab` includes a utility to create VPCs in vlab. This utility is a `hhfab vlab` sub-command. `hhfab vlab setup-vpcs`.

```
NAME:
hhfab vlab setup-vpcs - setup VPCs and VPCAttachments for all servers and configure networking on them

USAGE:
hhfab vlab setup-vpcs [command options]

OPTIONS:
--dns-servers value, --dns value [ --dns-servers value, --dns value ] DNS servers for VPCs advertised by DHCP
--force-clenup, -f start with removing all existing VPCs and VPCAttachments (default: false)
--help, -h show help
--interface-mtu value, --mtu value interface MTU for VPCs advertised by DHCP (default: 0)
--ipns value IPv4 namespace for VPCs (default: "default")
--name value, -n value name of the VM or HW to access
--servers-per-subnet value, --servers value number of servers per subnet (default: 1)
--subnets-per-vpc value, --subnets value number of subnets per VPC (default: 1)
--time-servers value, --ntp value [ --time-servers value, --ntp value ] Time servers for VPCs advertised by DHCP
--vlanns value VLAN namespace for VPCs (default: "default")
--wait-switches-ready, --wait wait for switches to be ready before and after configuring VPCs and VPCAttachments (default: true)

Global options:

--brief, -b brief output (only warn and error) (default: false) [$HHFAB_BRIEF]
--cache-dir DIR use cache dir DIR for caching downloaded files (default: "/home/ubuntu/.hhfab-cache") [$HHFAB_CACHE_DIR]
--verbose, -v verbose output (includes debug) (default: false) [$HHFAB_VERBOSE]
--workdir PATH run as if hhfab was started in PATH instead of the current working directory (default: "/home/ubuntu") [$HHFAB_WORK_DIR]
```

### Setup Peering
`hhfab vlab` includes a utility to create VPC peerings in VLAB. This utility is a `hhfab vlab` sub-command. `hhfab vlab setup-peerings`.

```
NAME:
hhfab vlab setup-peerings - setup VPC and External Peerings per requests (remove all if empty)

USAGE:
Setup test scenario with VPC/External Peerings by specifying requests in the format described below.

Example command:

$ hhfab vlab setup-peerings 1+2 2+4:r=border 1~as5835 2~as5835:subnets=sub1,sub2:prefixes=0.0.0.0/0,22.22.22.0/24
mrbojangles3 marked this conversation as resolved.
Show resolved Hide resolved

Which will produce:
1. VPC peering between vpc-01 and vpc-02
2. Remote VPC peering between vpc-02 and vpc-04 on switch group named border
3. External peering for vpc-01 with External as5835 with default vpc subnet and any routes from external permitted
4. External peering for vpc-02 with External as5835 with subnets sub1 and sub2 exposed from vpc-02 and default route
from external permitted as well any route that belongs to 22.22.22.0/24

VPC Peerings:

1+2 -- VPC peering between vpc-01 and vpc-02
demo-1+demo-2 -- VPC peering between demo-1 and demo-2
1+2:r -- remote VPC peering between vpc-01 and vpc-02 on switch group if only one switch group is present
1+2:r=border -- remote VPC peering between vpc-01 and vpc-02 on switch group named border
1+2:remote=border -- same as above

External Peerings:

1~as5835 -- external peering for vpc-01 with External as5835
1~ -- external peering for vpc-1 with external if only one external is present for ipv4 namespace of vpc-01, allowing
default subnet and any route from external
1~:subnets=default@prefixes=0.0.0.0/0 -- external peering for vpc-1 with auth external with default vpc subnet and
default route from external permitted
1~as5835:subnets=default,other:prefixes=0.0.0.0/0_le32_ge32,22.22.22.0/24 -- same but with more details
1~as5835:s=default,other:p=0.0.0.0/0_le32_ge32,22.22.22.0/24 -- same as above

OPTIONS:
--help, -h show help
--name value, -n value name of the VM or HW to access
--wait-switches-ready, --wait wait for switches to be ready before before and after configuring peerings (default: true)

Global options:

--brief, -b brief output (only warn and error) (default: false) [$HHFAB_BRIEF]
--cache-dir DIR use cache dir DIR for caching downloaded files (default: "/home/ubuntu/.hhfab-cache") [$HHFAB_CACHE_DIR]
--verbose, -v verbose output (includes debug) (default: false) [$HHFAB_VERBOSE]
--workdir PATH run as if hhfab was started in PATH instead of the current working directory (default: "/home/ubuntu") [$HHFAB_WORK_DIR]
```

### Test Connectivity
`hhfab vlab` includes a utility to test connectivity between servers inside VLAB. This utility is a `hhfab vlab` sub-command. `hhfab vlab test-connectivity`.

```
NAME:
hhfab vlab test-connectivity - test connectivity between all servers

USAGE:
hhfab vlab test-connectivity [command options]

OPTIONS:
--curls value number of curl tests to run for each server to test external connectivity (0 to disable) (default: 3)
--help, -h show help
--iperfs value seconds of iperf3 test to run between each pair of reachable servers (0 to disable) (default: 10)
--iperfs-speed value minimum speed in Mbits/s for iperf3 test to consider successful (0 to not check speeds) (default: 7000)
--name value, -n value name of the VM or HW to access
--pings value number of pings to send between each pair of servers (0 to disable) (default: 5)
--wait-switches-ready, --wait wait for switches to be ready before testing connectivity (default: true)

Global options:

--brief, -b brief output (only warn and error) (default: false) [$HHFAB_BRIEF]
--cache-dir DIR use cache dir DIR for caching downloaded files (default: "/home/ubuntu/.hhfab-cache") [$HHFAB_CACHE_DIR]
--verbose, -v verbose output (includes debug) (default: false) [$HHFAB_VERBOSE]
--workdir PATH run as if hhfab was started in PATH instead of the current working directory (default: "/home/ubuntu") [$HHFAB_WORK_DIR]

```
## Manual VPC creation
### Creating and attaching VPCs

You can create and attach VPCs to the VMs using the `kubectl fabric vpc` command on the Control Node or outside of the
cluster using the kubeconfig. For example, run the following commands to create 2 VPCs with a single subnet each, a DHCP
server enabled with its optional IP address range start defined, and to attach them to some of the test servers:

```console
```
Comment on lines -96 to +208
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't matter much here - these blocks are console output, because they contain both commands and their output. However, we won't get the highlight for commands, because the core@control-1 prefix in front of the prompt symbol and commands prevents GitHub to recognise the commands.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I have been looking at the docs as rendered via make serve I did that mass removal to avoid numbers in the output being colored for reasons I couldn't easily deduce. For examples the first 10 in the ip addresses. The rendering in GitHub is something that I have only started looking at because of this comment. Are you okay with a policy of, no console tag at all since the rendering seems to be spotty be between material-mkdocs and github?

core@control-1 ~ $ kubectl get conn | grep server
server-01--mclag--leaf-01--leaf-02 mclag 5h13m
server-02--mclag--leaf-01--leaf-02 mclag 5h13m
Expand All @@ -117,7 +229,7 @@ core@control-1 ~ $ kubectl fabric vpc attach --vpc-subnet vpc-2/default --connec

The VPC subnet should belong to an IPv4Namespace, the default one in the VLAB is `10.0.0.0/16`:

```console
```
core@control-1 ~ $ kubectl get ipns
NAME SUBNETS AGE
default ["10.0.0.0/16"] 5h14m
Expand All @@ -126,7 +238,7 @@ default ["10.0.0.0/16"] 5h14m
After you created the VPCs and VPCAttachments, you can check the status of the agents to make sure that the requested
configuration was applied to the switches:

```console
```
core@control-1 ~ $ kubectl get agents
NAME ROLE DESCR APPLIED APPLIEDG CURRENTG VERSION
leaf-01 server-leaf VS-01 MCLAG 1 2m2s 5 5 v0.23.0
Expand All @@ -149,7 +261,7 @@ the little helper pre-installed by Fabricator on test servers, `hhnet`.

For `server-01`:

```console
```
core@server-01 ~ $ hhnet cleanup
core@server-01 ~ $ hhnet bond 1001 enp2s1 enp2s2
10.0.1.10/24
Expand All @@ -173,7 +285,7 @@ core@server-01 ~ $ ip a

And for `server-02`:

```console
```
core@server-02 ~ $ hhnet cleanup
core@server-02 ~ $ hhnet bond 1002 enp2s1 enp2s2
10.0.2.10/24
Expand All @@ -199,7 +311,7 @@ core@server-02 ~ $ ip a

You can test connectivity between the servers before peering the switches using the `ping` command:

```console
```
core@server-01 ~ $ ping 10.0.2.10
PING 10.0.2.10 (10.0.2.10) 56(84) bytes of data.
From 10.0.1.1 icmp_seq=1 Destination Net Unreachable
Expand All @@ -210,7 +322,7 @@ From 10.0.1.1 icmp_seq=3 Destination Net Unreachable
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2003ms
```

```console
```
core@server-02 ~ $ ping 10.0.1.10
PING 10.0.1.10 (10.0.1.10) 56(84) bytes of data.
From 10.0.2.1 icmp_seq=1 Destination Net Unreachable
Expand All @@ -225,15 +337,15 @@ From 10.0.2.1 icmp_seq=3 Destination Net Unreachable

To enable connectivity between the VPCs, peer them using `kubectl fabric vpc peer`:

```console
```
core@control-1 ~ $ kubectl fabric vpc peer --vpc vpc-1 --vpc vpc-2
07:04:58 INF VPCPeering created name=vpc-1--vpc-2
```

Make sure to wait until the peering is applied to the switches using `kubectl get agents` command. After that, you can
test connectivity between the servers again:

```console
```
core@server-01 ~ $ ping 10.0.2.10
PING 10.0.2.10 (10.0.2.10) 56(84) bytes of data.
64 bytes from 10.0.2.10: icmp_seq=1 ttl=62 time=6.25 ms
Expand All @@ -245,7 +357,7 @@ PING 10.0.2.10 (10.0.2.10) 56(84) bytes of data.
rtt min/avg/max/mdev = 6.245/7.481/8.601/0.965 ms
```

```console
```
core@server-02 ~ $ ping 10.0.1.10
PING 10.0.1.10 (10.0.1.10) 56(84) bytes of data.
64 bytes from 10.0.1.10: icmp_seq=1 ttl=62 time=5.44 ms
Expand All @@ -260,12 +372,12 @@ rtt min/avg/max/mdev = 4.489/5.529/6.656/0.886 ms
If you delete the VPC peering with `kubectl delete` applied to the relevant object and wait for the agent to apply the
configuration on the switches, you can observe that connectivity is lost again:

```console
```
core@control-1 ~ $ kubectl delete vpcpeering/vpc-1--vpc-2
vpcpeering.vpc.githedgehog.com "vpc-1--vpc-2" deleted
```

```console
```
core@server-01 ~ $ ping 10.0.2.10
PING 10.0.2.10 (10.0.2.10) 56(84) bytes of data.
From 10.0.1.1 icmp_seq=1 Destination Net Unreachable
Expand All @@ -280,7 +392,7 @@ From 10.0.1.1 icmp_seq=3 Destination Net Unreachable
You can see duplicate packets in the output of the `ping` command between some of the servers. This is expected
behavior and is caused by the limitations in the VLAB environment.

```console
```
core@server-01 ~ $ ping 10.0.5.10
PING 10.0.5.10 (10.0.5.10) 56(84) bytes of data.
64 bytes from 10.0.5.10: icmp_seq=1 ttl=62 time=9.58 ms
Expand All @@ -294,124 +406,12 @@ From 10.0.1.1 icmp_seq=3 Destination Net Unreachable
3 packets transmitted, 3 received, +3 duplicates, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 6.987/8.720/9.595/1.226 ms
```
## Utility based VPC creation

### Setup VPCs
`hhfab vlab` includes a utility to create VPCs in vlab. This utility is a `hhfab vlab` sub-command. `hhfab vlab setup-vpcs`.

```console
NAME:
hhfab vlab setup-vpcs - setup VPCs and VPCAttachments for all servers and configure networking on them

USAGE:
hhfab vlab setup-vpcs [command options]

OPTIONS:
--dns-servers value, --dns value [ --dns-servers value, --dns value ] DNS servers for VPCs advertised by DHCP
--force-clenup, -f start with removing all existing VPCs and VPCAttachments (default: false)
--help, -h show help
--interface-mtu value, --mtu value interface MTU for VPCs advertised by DHCP (default: 0)
--ipns value IPv4 namespace for VPCs (default: "default")
--name value, -n value name of the VM or HW to access
--servers-per-subnet value, --servers value number of servers per subnet (default: 1)
--subnets-per-vpc value, --subnets value number of subnets per VPC (default: 1)
--time-servers value, --ntp value [ --time-servers value, --ntp value ] Time servers for VPCs advertised by DHCP
--vlanns value VLAN namespace for VPCs (default: "default")
--wait-switches-ready, --wait wait for switches to be ready before and after configuring VPCs and VPCAttachments (default: true)

Global options:

--brief, -b brief output (only warn and error) (default: false) [$HHFAB_BRIEF]
--cache-dir DIR use cache dir DIR for caching downloaded files (default: "/home/ubuntu/.hhfab-cache") [$HHFAB_CACHE_DIR]
--verbose, -v verbose output (includes debug) (default: false) [$HHFAB_VERBOSE]
--workdir PATH run as if hhfab was started in PATH instead of the current working directory (default: "/home/ubuntu") [$HHFAB_WORK_DIR]
```

### Setup Peering
`hhfab vlab` includes a utility to create VPC peerings in VLAB. This utility is a `hhfab vlab` sub-command. `hhfab vlab setup-peerings`.

```console
NAME:
hhfab vlab setup-peerings - setup VPC and External Peerings per requests (remove all if empty)

USAGE:
Setup test scenario with VPC/External Peerings by specifying requests in the format described below.

Example command:

$ hhfab vlab setup-peerings 1+2 2+4:r=border 1~as5835 2~as5835:subnets=sub1,sub2:prefixes=0.0.0.0/0,22.22.22.0/24

Which will produce:
1. VPC peering between vpc-01 and vpc-02
2. Remote VPC peering between vpc-02 and vpc-04 on switch group named border
3. External peering for vpc-01 with External as5835 with default vpc subnet and any routes from external permitted
4. External peering for vpc-02 with External as5835 with subnets sub1 and sub2 exposed from vpc-02 and default route
from external permitted as well any route that belongs to 22.22.22.0/24

VPC Peerings:

1+2 -- VPC peering between vpc-01 and vpc-02
demo-1+demo-2 -- VPC peering between demo-1 and demo-2
1+2:r -- remote VPC peering between vpc-01 and vpc-02 on switch group if only one switch group is present
1+2:r=border -- remote VPC peering between vpc-01 and vpc-02 on switch group named border
1+2:remote=border -- same as above

External Peerings:

1~as5835 -- external peering for vpc-01 with External as5835
1~ -- external peering for vpc-1 with external if only one external is present for ipv4 namespace of vpc-01, allowing
default subnet and any route from external
1~:subnets=default@prefixes=0.0.0.0/0 -- external peering for vpc-1 with auth external with default vpc subnet and
default route from external permitted
1~as5835:subnets=default,other:prefixes=0.0.0.0/0_le32_ge32,22.22.22.0/24 -- same but with more details
1~as5835:s=default,other:p=0.0.0.0/0_le32_ge32,22.22.22.0/24 -- same as above

OPTIONS:
--help, -h show help
--name value, -n value name of the VM or HW to access
--wait-switches-ready, --wait wait for switches to be ready before before and after configuring peerings (default: true)

Global options:

--brief, -b brief output (only warn and error) (default: false) [$HHFAB_BRIEF]
--cache-dir DIR use cache dir DIR for caching downloaded files (default: "/home/ubuntu/.hhfab-cache") [$HHFAB_CACHE_DIR]
--verbose, -v verbose output (includes debug) (default: false) [$HHFAB_VERBOSE]
--workdir PATH run as if hhfab was started in PATH instead of the current working directory (default: "/home/ubuntu") [$HHFAB_WORK_DIR]
```

### Test Connectivity
`hhfab vlab` includes a utility to test connectivity between servers inside VLAB. This utility is a `hhfab vlab` sub-command. `hhfab vlab test-connectivity`.

```console
NAME:
hhfab vlab test-connectivity - test connectivity between all servers

USAGE:
hhfab vlab test-connectivity [command options]

OPTIONS:
--curls value number of curl tests to run for each server to test external connectivity (0 to disable) (default: 3)
--help, -h show help
--iperfs value seconds of iperf3 test to run between each pair of reachable servers (0 to disable) (default: 10)
--iperfs-speed value minimum speed in Mbits/s for iperf3 test to consider successful (0 to not check speeds) (default: 7000)
--name value, -n value name of the VM or HW to access
--pings value number of pings to send between each pair of servers (0 to disable) (default: 5)
--wait-switches-ready, --wait wait for switches to be ready before testing connectivity (default: true)

Global options:

--brief, -b brief output (only warn and error) (default: false) [$HHFAB_BRIEF]
--cache-dir DIR use cache dir DIR for caching downloaded files (default: "/home/ubuntu/.hhfab-cache") [$HHFAB_CACHE_DIR]
--verbose, -v verbose output (includes debug) (default: false) [$HHFAB_VERBOSE]
--workdir PATH run as if hhfab was started in PATH instead of the current working directory (default: "/home/ubuntu") [$HHFAB_WORK_DIR]

```

## Using VPCs with overlapping subnets

First, create a second IPv4Namespace with the same subnet as the default one:

```console
```
core@control-1 ~ $ kubectl get ipns
NAME SUBNETS AGE
default ["10.0.0.0/16"] 24m
Expand Down Expand Up @@ -440,7 +440,7 @@ Let's assume that `vpc-1` already exists and is attached to `server-01` (see [Cr
Now we can create `vpc-3` with the same subnet as `vpc-1` (but in the different IPv4Namespace) and attach it to the
`server-03`:

```console
```
core@control-1 ~ $ cat <<EOF > vpc-3.yaml
apiVersion: vpc.githedgehog.com/v1beta1
kind: VPC
Expand Down
Loading
Loading