Verify configuration for public IPs

#56

wow… didn’t expect that a node needs to be rebooted for this… but that’s it! After rebooting the node I can ping the IP.

As already described I had to assign a public IP manually via Polkadot UI because it was not possible to set the (same) configs via TF portal. Once pub IP configuration is assigned (via Polkadot UI) the settings are shown in the pop-up window when clicking on the globe icon in TF portal and are also displayed on the nodes zos screen under network section (PUB). Bevor I rebooted the node the public IP was assigned as an additional IP-adress on the same NIC port where LAN is connected to (on zos screen under network section called “ZOS”). Of course this can’t work properly since LAN-side router settings are not configured for routing of public IPs. After a reboot the IP is now assigned to a second NIC port and it seems to work fine.

However… there is still some weird issue. a coupIe of days ago I tried to delete public IP settings for that node. Once again this was not possible via TF portal, so I used the Polkadot UI instead and did overwrite the settings with “0x” in each line. After that the TF portal shows no configuration when clicking on the globe icon. But (!!!)… the node still dispalys the public IP on it’s screen. after rebooting the node it has now assigned the pub IP like described above. Now I have a node with a public IP but in TF portal it says there is none configured for that node. So… is it working now or not?

At the moment it’s hard to find a proper documentation on that public IP thing. I think that the informations for this topic in forum, github or elsewhere online need to be improved. Well… looks like we are getting closer, but I still don’t know if the gateway configs are working like this… and I don’t get a picture yet on how gateways work in generall and what they are supposed to do so we can estimate whether or not to build more or assign IPs to farms.

#57

Thank you for you contribution @Dany. Let’s start to improve on the documentation and share out experiences there. There is such a lot of things that need attention that sometimes the basics are forgotten.

#59

Hello together,

I saw this discussion here and I have similar questions in scope of my Node Setup on a datacenter.

I am going to place two of my DIY nodes this week there in a datacenter.
I thought maybe you guys can help me directly.

These are my nodes, from Farm190:

  • 485 (16 VCores; reserved for L0 Validator)
  • 895 (64 VCores)

I have already received my Network configuration.

My network configuration will be:
——————————————————
Netzwerk: 85.88.16.216/29
Netzmaske: 255.255.255.248
Gateway: 85.88.16.217

IPs for the servers:
85.88.16.218 – 85.88.16.222

Nameserver :
85.88.0.92
85.88.1.92
——————————————————-

And now my questions:

  • How is the appropriate configuration for these 2 nodes and where I need to do it. TFT Chain portal or better polkadot UI? I understand that TFT Chain should be sufficient.
  • Is it enough just to set the IPs for both nodes directly with the „set the public Ip“ option for the specific node, without assigning the IPs to the farm?

For example:
Node 485: IP: 85.88.16.218/32 + Gateway: 85.88.16.217
Node 895: IP: 85.88.16.220/32 + Gateway: 85.88.16.217
(maybe I am wrong here)

  • Only node 485 is currently online at home because I am transferring them to an other location. Do I need to get them shortly online in order that they will takeover the configuration before placing them in the datacenter? I read that reset shall be done after the configuration is done (only one nodes has 2 NICs).
  • Would it make sense to have both nodes in one Farm without other DIY nodes that will not work in the datacenter.

Hope to get a hint, how to do my configuration in best way.

Regards,
Martin

#60

It seems that’s not possible at the moment. See…

So you can’t assign a public IP directly via TF Portal for now and configure the nodes as TF gateways. However I was able to configure this via Polkadot UI. But I’m not sure if it’s working properly (also I can ping that host). Still waiting for reply on my questions from dev team.

You can assign public IPs to the farm without assigning them directly to a specific node. In this case your farm would offer these public IPs but will only be used when users order one of them for their workload on your node. You can check this by yourself on TF Playground (grid.tf).

But watch out… you have the wrong netmask in your example!

should be 85.88.16.218/29

#61

Thanks Dany,

Well, looks like it will take me more time. I think I need to go few steps back. I have tried to do it with the Polkadot UI. Here I can’t even find the “tfgridModule” extrinsic in the selection field.

#62

@Martin,

I can’t recommend to adjust any settings in Polkadot UI as long as we (farmers) don’t know what’s exactly going on there. I was playing around with Polkadot UI and however I managed to assign a public IP on a second NIC port in order to test routing. But (!!) I can’t confirm that these settings I manually changed in Polkadot UI result in a proper configuration in the way the TF grid expects/needs it. F. e. the second NIC port seems to be set to a fixed public IP, but in Grid Explorer the node is not shown as gateway. After I tried to delete the settings in Polkadot UI the public IP remains on that NIC port although the TF Portal shows that there are no configurations. That looks like some weird behavier to me.

I think we should wait until the issue in TF Portal is fixed so the configurations can be set there. In the meantime you can assign a public IP pool to your farm (not a specific node). I can confirm that this is working properly.

#63

Hey @Martin,

have you moved in? Did you work it out?

#64

Polka UI feels a little adventurous, but it’s actually pretty safe to play with :slight_smile:

Gateway nodes are those with a domain assigned to them. Nodes that have a public IP but no domain can serve as Wireguard access points, but the gateway functionality, which provides public access to workloads, depends on handing out subdomains.

It might require a reboot for a node to lose it’s public config. I know that nodes try to apply incoming changes, but I don’t know how this applies to clearing the config entirely. I’ll make a note to play with this when I have a chance to see if I observe the same behavior.

2 Likes
The "Public IP" question
#65

Hey Scott, I’ve got domains assigned to my nodes, but you mention deploying sub domains, is this something I would have to deploy more then the one sub domain?

How would I know another is needed?

#66

No, just one domain per node is needed, and it can be a subdomain itself. For example, node 1 on testnet has gent01.test.grid.tf as it’s domain. When a user deploys a web gateway using this node, it will be assigned a subdomain xyz.gent01.test.grid.tf. Zos handles all of this automatically.

#67

Cool that’s how mine are setup, the subdomains are the nodes “names” lol, gotta have cool names for everything

1 Like
#68

thanks @scott for these information. I finaly was able to create a new gateway.

The configs can be set in Polkadot UI. That would look like this:
image

.
The settings were instantly shown in TF Chain Portal as can be seen here
image

.
It’s takes a couple of minutes until it’s also shown in Grid Explorerimage

I can confirm that it is neccessary to reboot the node for any changes made in Pokadot UI to take place. After rebooting the node responds on pings to the subdomain.

image

Looks like we have another gateway online

image

5 Likes
Node 1655 does not seem to be connected correctly [RESOLVED]
#69

Thanks for the info.
I’ll add this to the documentation so it’s clear for everyone, it’s a good detail to keep in mind!

1 Like
#70

Hey @Mik, you should also consider to take @ParkerS advise into the documentation.

See: Verify configuration for public IPs

I was struggling in the first place to work with polkadot UI. See chat history

1 Like
#71

I liked your domain, just bought tfcloud.us, gonna move em over when I do upgrades next Monday

2 Likes
#72

Most excellent idea. Thanks for this @sigzag . Indeed we could even write a complete book with all the information @ParkerS shared here on the forum!

It’s definitely great contents to put on the TF documentation. Excellent idea.

There is so much great contributions from many people here. We need to get more organized and have ways to share and create documentation that builds on each other, and that is accessible for all, and updatable as we get better data. Also, being more organized would allow us to avoid re-inventing the wheel in terms of documentation and findings, if it ever was to happen.

Those two links are a part of the overall discussion. Amazing to see TF grows. Thanks again for the idea.

1 Like
#73

Just in case anyone on this thread can benefit from hearing this…

@teisie asked me if there was any more efficient way to add public IPs to a farm than adding them one by one through the portal. I thought there was a way to add a block, but alas no such thing currently exists in the UIs (including Polkadot.js).

However, I had been playing a bit with the TF Chain command line too recently and figured there would be a way to automate this process. After some fiddling around today, I produced a working script that can add a continuous block of IPs to a farm. It shouldn’t be too difficult to adjust the values and run this script on any OS. I’ll work on that some more on Monday.

4 Likes
#74

Hey Scott, I’m planing to go from an 8 block to a 64 at the beginning of next week, we could get together and do some testing when that plays out if it would be helpful

1 Like
#75

I’d love to get that script!! Have to assign a block of 200 IPs and definitely don’t want to add them one by one

3 Likes
#76

@sigzag, I put the finishing touches on today and would be happy to share with you for testing.

@ParkerS, sounds good!

3 Likes