I need help in getting the primary subnet of a machine which has multiple subnets.
The reason I am looking for this is because in Relay affiliation, we provide the list of subnets in a script to let the machine identify it’s subnet and compare with the list provided and then assign the respective site code that we have provided with the relay affiliation script.
Now in case of multiple subnet the machines assigns multiple “Location by Subnet” which in turns changes the way seeklist is going to read it.
Any best practice for this case would really helpful as well.
What I am looking for is a way to prioritize the adapters to get the one which is currently being used so that instead of getting the multiple subnets I will get the one which is currently participating in the communication.
Note that there is a limit to the number of subnets considered when checking for a registration subnet. I don’t recall the exact limit, but some of our systems with 9+ network interfaces return no value for “registration address of client” or “registration subnet address of client”.
Would you consider your “primary” interface to be the one with a default gateway? I’ve resorted to using default gateways for some of my configurations.
Part of the reason is if the relay can’t see the same address when the client registers (because it is behind a NAT for example) then the registration address will not be known as the information comes from the server during the registration interaction.
For example, if your IP is 10.0.0.100 and you go through a NAT and come out a 4.5.6.7 to the relay, then the IP address and subnet you provided during your registration command (you can see them in the log) will be thrown out by the relay as it thinks you registered from 4.5.6.7 and thus the 10.0.0.100 is useless to it.
I am not a network expert but if NAT IP is going to be an issue then registration subnet address would not help in my case as in my environment, we have DMZ Relay implemented.
Do you think that raising a PMR in this case would help?
I couldn’t say. [I DO NOT WORK FOR IBM]. Generally I don’t think they’ll work PMRs for custom content, but they do offer paid consulting services and custom authoring services that might be helpful. But I don’t think we’ve exhausted ideas yet here.
Given that “registration address” isn’t going to do what you need because of the NAT, once again we have to go back to the original question. If your client has multiple IP addresses, how would you decide which one is “Primary”?
I think the “Location by Property” Wizard is still a good place to start. The way in which I use it is
Create a list of Address Ranges (not subnets), so I can also have unique “exceptions” to the subnet rule - note here where the host at 192.168.3.201 is unique, and should be assigned Location2 even though the rest of the 192.168.3 subnet is at Location3
192.168.1.1-192.168.1.254 Location1
192.168.2.1-192.168.2.254 Location2
192.168.3.1-192.168.3.200 Location3
192.168.3.201-192.168.3.201 Location2
192.168.3.202-192.168.3.254 Location3
In the Location Property wizard, use the “Create a retrieved property that maps IP address range to location”
I keep the default Property Name of “Location by IP Range” but you could customize it if you want.
I think (but haven’t checked lately) if a multihomed host has more than one address, the first match “wins” so you could order your ranges in the text file accordingly. Or you could ensure the multihomed client only matches one of the ranges. Or if the client IP addresses are static you could make specific location ranges for all of their interfaces to match the same site.
It should be OK if the client and the immediate relay that the client is registering from agree on the IP address that the client has. Thats the main issue. The server doesn’t need to be able to see the IP, the relay above the client needs to. So as long as the DMZ Relay thinks the client is at the same IP as the client does, then it will work.
I have already tried “Location by IP Range” and it seems that either I am doing something wrong or this option is not good for environments with large number of endpoints.
The issue that I faced was that as soon as I deployed this by IP range, the action became unreachable. What I mean is that whenever i try to check the action, it gives me the error “Console out of memory” and because of that I am not able to check the current status of the action.
Hence “Location by IP Range” is a big NO for me.
Just curious, how many ranges did you have defined? I keep my list of ranges in a text file that I copy/paste into the dashboard; right now I have 121 ranges defined.
Perhaps you could split your ranges into several files, and open several different Actions from the dashboard, each targeting a different set of address ranges?
Perhaps we should revisit the initial problem. If you are using Automatic Relay Select, the client should locate the nearest Relay based on the ICMP hop counts. Relay Affiliation should really only be necessary if the clients see more than several Relays with the same “hop count” and you still need the client to prefer one set of relays over another. For instance in my environment, I have subnets where two different Relays are “two hops away”; one of those Relays is in the same building connected by 10 Gb-Ethernet backbones, and the other is a thousand miles away over a VPN. Is that case similar for you, or do you see some other reason to enforce Relay Affiliation?