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.

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

A route rule is added for each line in route-tables.cfg #11

Closed
brakthehack opened this issue Jan 21, 2021 · 0 comments
Closed

A route rule is added for each line in route-tables.cfg #11

brakthehack opened this issue Jan 21, 2021 · 0 comments
Labels
bug Something isn't working good first issue Good for newcomers

Comments

@brakthehack
Copy link
Collaborator

We observed that route rules are added for each route in /etc/vmware/route-tables.cfg. See below:

root@haproxy [ ~ ]# ip rule show
0:	from all lookup local
32762:	from 172.16.10.2/24 lookup rtctl_frontend
32763:	from 172.16.10.2/24 lookup rtctl_frontend
32764:	from 192.168.1.2/16 lookup rtctl_workload
32765:	from 192.168.1.2/16 lookup rtctl_workload
32766:	from all lookup main
32767:	from all lookup default
root@haproxy [ ~ ]# cat /etc/vmware/
anyip-routes.cfg  route-tables.cfg
root@haproxy [ ~ ]# cat /etc/vmware/route-tables.cfg
...
2,workload,00:50:56:b8:10:00,192.168.1.2/16,192.168.1.1
2,workload,00:50:56:b8:10:00,192.168.1.2/16
3,frontend,00:50:56:b8:48:f1,172.16.10.2/24,172.16.10.1
3,frontend,00:50:56:b8:48:f1,172.16.10.2/24

Instead we should see only a single lookup for each network for each route table, which means it should look something like this:

root@haproxy [ ~ ]# ip rule show
0:	from all lookup local
32764:	from 172.16.10.2/24 lookup rtctl_frontend
32765:	from 192.168.1.2/16 lookup rtctl_workload
32766:	from all lookup main
32767:	from all lookup default

There's no harm with this bug per se, but it may be confusing to users.

@brakthehack brakthehack added bug Something isn't working good first issue Good for newcomers labels Jan 21, 2021
brakthehack added a commit to brakthehack/vmware-haproxy that referenced this issue Mar 11, 2021
Given duplicate route entries can be added because of different
route types, we need to account for this in the route table addition
logic to ensure only a single route table gets added in case multiple
routes from that table exist.

Fixes haproxytech#11
brakthehack added a commit to brakthehack/vmware-haproxy that referenced this issue Mar 11, 2021
Previously, HAProxy would not route to additional workload networks
without user customization because we did not give them the option
to provide workload networks interfaces via the UI.

This change implements the ability for the user to provide workload
networks the user wishes to route to. Since we expect workload
networks to be routable to each other, we can program route rules
to user-provided CIDR ranges in which routes will exit via the
workload default gateway. These routes are configurable via a new
file located at /etc/vmware/workload-networks.cfg. This file is
written once just before cloud-init performs the bootstrapping.

This change also fixes a few bugs in route table configuration.

Closes haproxytech#15, haproxytech#11, haproxytech#10
brakthehack added a commit to brakthehack/vmware-haproxy that referenced this issue Mar 11, 2021
Previously, HAProxy would not route to additional workload networks
without user customization because we did not give them the option
to provide workload networks interfaces via the UI.

This change implements the ability for the user to provide workload
networks the user wishes to route to. Since we expect workload
networks to be routable to each other, we can program route rules
to user-provided CIDR ranges in which routes will exit via the
workload default gateway. These routes are configurable via a new
file located at /etc/vmware/workload-networks.cfg. This file is
written once just before cloud-init performs the bootstrapping.

This change also fixes a few bugs in route table configuration.

Closes haproxytech#15, haproxytech#11, haproxytech#10
brakthehack added a commit to brakthehack/vmware-haproxy that referenced this issue Mar 12, 2021
Previously, HAProxy would not route to additional workload networks
without user customization because we did not give them the option
to provide workload networks interfaces via the UI.

This change implements the ability for the user to provide workload
networks the user wishes to route to. Since we expect workload
networks to be routable to each other, we can program route rules
to user-provided CIDR ranges in which routes will exit via the
workload default gateway. These routes are configurable via a new
file located at /etc/vmware/workload-networks.cfg. This file is
written once just before cloud-init performs the bootstrapping.

This change also fixes a few bugs in route table configuration.

Closes haproxytech#15, haproxytech#11, haproxytech#10
brakthehack added a commit to brakthehack/vmware-haproxy that referenced this issue Apr 22, 2021
Given duplicate route entries can be added because of different
route types, we need to account for this in the route table addition
logic to ensure only a single route table gets added in case multiple
routes from that table exist.

Fixes haproxytech#11
brakthehack added a commit to brakthehack/vmware-haproxy that referenced this issue Apr 22, 2021
Previously, HAProxy would not route to additional workload networks
without user customization because we did not give them the option
to provide workload networks interfaces via the UI.

This change implements the ability for the user to provide workload
networks the user wishes to route to. Since we expect workload
networks to be routable to each other, we can program route rules
to user-provided CIDR ranges in which routes will exit via the
workload default gateway. These routes are configurable via a new
file located at /etc/vmware/workload-networks.cfg. This file is
written once just before cloud-init performs the bootstrapping.

This change also fixes a few bugs in route table configuration.

Closes haproxytech#15, haproxytech#11, haproxytech#10
brakthehack added a commit that referenced this issue Apr 22, 2021
Previously, HAProxy would not route to additional workload networks
without user customization because we did not give them the option
to provide workload networks interfaces via the UI.

This change implements the ability for the user to provide workload
networks the user wishes to route to. Since we expect workload
networks to be routable to each other, we can program route rules
to user-provided CIDR ranges in which routes will exit via the
workload default gateway. These routes are configurable via a new
file located at /etc/vmware/workload-networks.cfg. This file is
written once just before cloud-init performs the bootstrapping.

This change also fixes a few bugs in route table configuration.

Closes #15, #11, #10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

1 participant