 |
Seems like this is already in place with the vlan domains and vlan list within that. I noticed also in 0.20.1 that when adding a new network it gives me the option to relate it against an existing vlan domain + vlan id. However currently this gives me an error if I try and add a subnet which already exists in the database. |
 |
Hi, We are still not able to add a duplicate IP Address even though those IPs are in different vlan domains (tested on your demo server). VLAN tag is nice, but if the VRF tag is also there it would be also nice, so that we have different domains with the same IP space. Thanks for working on this feature. |
 |
We also need this feature please. |
 |
Hi, We have one more IDC sites, and we using same local IP address many.. I need this feature too. |
 |
Same deal here, that would be an awesome addition. Currently we have to have two database as we are managing two services with overlapping subnet. I suggest that overlapping subnet would require to be in different 802.1q domain and when addind an ip to an object, a selection screen would popup to let chose which domain it's part of. |
 |
I need it too... We have a lab with duplicate RFC1918 space in multiple test environments. Thanks -- we love RackTables. |
 |
oh yeah, we have the same requirement. |
 |
I too would like to see this functionality. With ipv6 "around the corner" (how long have we been saying that...) it will be much less of an issue, but for the foreseeable future 2-3 years, there's still going to be lots of ipv4 to deal with. A couple ideas here... - For the VRF, perhaps an extra dropdown option of VRF would allow it to be duplicated on multiple devices/ports. If it's VRF, it would show on the ipv4 side of things, since it's actually going to be used. - For the other cases (mostly virtualization, multiple private), add a type of "internal" which would automatically skip the duplicate check. - When creating these duplicate internal subnets, these are usually locked to a location or a virtual switch/network especially in virtualization. Could we make a requirement that to have a duplicate subnet, it is attached to a location/device/port? We are planning on using racktables to document customer networks, and we are trying to add locations for each customer. There is a lot of overlap in the private network side, and I am not looking forward to maintain multiple racktables db's. Thanks. |
|
|
Any progress on this idea ? |
 |
This is a feature that's holding us back from deploying Racktables. Is there any progress? |
 |
Hey all, would love to know if there is an update to this and if it's on the roadmap. Thanks everyone! |
 |
I can confirm it is on the roadmap. My employer also needs this feature now, so I hope I will code it before the end of this year. |
|
|
\o/ |
 |
This to is something I have been longing for a long time and even made good progress with on the old 20.3 branch. Unfortunately other projects got in the way and never quite worked all the kinks out. But if its of any use to you guys for how I approached the issue, then my forked code is here https://github.com/jamestutton/racktables. This is far from a finished article but if it saves you any time at all and gets this feature included I'll be glad I shared. Bottom line is in my implementation I introduced a new key vrf_id which exists in any and all ip related tables. Then the true unique index is the ip/vrf pair. Anywhere an ip is set or referenced a default routing instance vrf_id was assumed as vrf_id=1 but user would have the option to explicitly set if required. In theory the feature shouldnt be needed with IPv6 but carried it though for completeness as never know. |
 |
Hello, I recently posted to the mailing list [1] asking about Multi site suppor and was pointed here. I too have a need for the ability to track multiple duplicate IPs. Essentially, we are running out of IPs so are natting our network and duplicating IPs internally. So sites 1,2,3 all have a vlan 100 with ip range of 10.10.10.0/24, however, the ips at each site may be assigned to different hosts. Thinking about it more, it would actually make sense to duplicate racks since we tend to use similar naming conventions across multiple sites, there's the possibility that a rack name and number could be duplicated. Thanks, Jon A [1] http://www.freelists.org/post/racktables-users/Multisite-support-for-overlapping-subnets,1 |
 |
I'd like to contribute to this, or have someone on my dev team contribute. Has the RackTables dev team made any progress on this issue? If not, we can take the code that James Tutton provided as a baseline, and try to make that work. I don't want to start work that will be redundant. I can be reached at jeff dot zohrab at rakops dot com. |
|
|
Hi, Jeff. No, I have no progress on this feature at the moment, so your help would be appreciated. I think we should procuce a plan of the development process. What do you think should be changed in the James's work? I think it is wrong to change the prototype of every IP-related API function (adding the additional vrf parameter). It would break the compatibility with any local plugins and automation scripts. It would be better to implement IP namespaces that could be switched manually or implicitly by the current IP network. |
|
|
Hi All, My thoughts on this were always that the vrf should be an optional parameter for backwards compatibility. In the ISP/Managed Service world where I operate we have the concept of a global/default vrf so my theory was always to have the vrf_id map to default of say vrf_id =0 (0=GLOBAL). So on upgrade everything would remain exactly as it is with a new column added but set to 0. Api calls/functions would have a $vrf_id parameter added but it would be optional with a default of 0 set at all times. Or at least that was the long term aim. |
|
|
Thanks james.tutton and andriyanov. @james.tutton, I'm assuming that your changes are in the master branch in your repo (commits d540ccc: VRF Aware Code Dev Stage 1, eda300b: Work in Progress for VRf integration, 25c5569: VRF update Landmark 3). I've squashed those commits into a single commit, https://github.com/jzohrab/racktables/commit/dd11610d0b5292eb26e0f7fd6bcedc8a5a679da3. The code has changed enough since these commits that a straight merge of the code doesn't make sense. I'll look at manually porting the changes from that commit into a new branch (WIP_639_overlapping_IPv4) off the current maintenance branch as a starting point. While we might make a change in direction, based on your notes, mine, and andriyanov's, your work is helpful for me in making some progress. Thanks, you can reach me at the email above if you would like to talk about this further. |
 |
Wondering what the progress of this is and if any more testing is needed. We need this for a new deployment and it'd be nice to have it in mainline before I start folding it in. |
 |
I too am in the service provider industry and desperately need VRF separation for IPv4 tracking. I had thought that specifying a VLAN domain may do it, but as others had pointed out, it does not. Looking in the database it does not appear to store an association between the IP record and a vlan domain. I'm very glad to see there is already quite a lot of progress on this issue. Let me know if I can help in any way, I was going to open a ticket and offer to start contributing a patch for this after some research, but it looks like hooks into other things like the API has already been taken into consideration. |
 |
Hi, still nothing about this issue? We are all waiting impatiently :) Not sure how much you advanced on this issue but I was thinking on a different approach, by actually adding a location to a ipv4 range, this way each object in that location could look for ipv4 addresses only from the same location... Just my 2 cents... |
 |
hi guys this Feature is very important. Any update? |
 |
Main page : Configuration : User interface >> IPV4_JAYWALK=yes is this what you're looking for? |
|
|
@grin - That option has a description of "Enable IPv4 address allocations w/o covering network (system-wide)", which is not what this bug is about. Basically the jaywalk option would allow you to assign an IP to an object, that hasn't been created as a network block in the system. e.g. create 192.160.0.1 without creating 192.168.0.0/24 as a block. The bug is about creating and assigning the same block more than once and using it in different places/vlans. e.g. 192.168.0.0/24 that is assigned to servers in Data Centre A and a different 192.168.0.0/24 that is assigned to servers in Data Centre B. |
|
|
Where we can we assign non-overlapping private addresses, where we cannot we define a "multiple users" subnet and assign them multiple times, and use the subnet property description to take note of the actual users and their misc data. |
|
|
@grin - I believe the "overlapping" and "multiple instances" are the same thing in this case. <quote>Where we can we assign non-overlapping private addresses, where we cannot we define a "multiple users" subnet and assign them multiple times, and use the subnet property description to take note of the actual users and their misc data.</quote> I'm afraid this isn't a viable workaround in our case and probably not for all the other users who have requested this feature too. I haven't looked at the code, but maybe the blocks need to have a primary key that will allow unique instances of the same IP Block/Subnet which is then what is use to create the relationships to selections, routers, vlans etc. as you've mentioned. But that's just me thinking aloud :) |
|
|
@andriyanov Did you get a chance to look at this again? The ability to have VRF's is most important. |
 |
Hi! This feature is really important. We have very big amount of "duplicated" private networks in different VLAN's and VRF's. |
 |
Hi, this feature is really important for us too. Racktable is very usefull but we will certainly change because of this miss feature.. Have you some news about that ? |
|
|
Any update is this issue? |
 |
Any update/solution? |
 |
Any Update or solution to this issue? |
|
|
Since I requested this feature, my company has switched to using netbox which provides the feature set we need. |
- Anonymous
