View Issue Details

IDProjectCategoryView StatusLast Update
0000639RackTablesIPv4/IPv6/SLBpublic2017-02-24 15:14
Reporternrobst 
Assigned Toandriyanov 
PrioritynormalSeverityfeatureReproducibilityN/A
Status assignedResolutionopen 
Product Version0.20.1 
Target VersionFixed in Version 
Summary0000639: Overlapping IPv4 address space
DescriptionHi,

As discussed in this thread: http://www.freelists.org/post/racktables-users/IP-tracking-for-Service-Providors,5

I would like to log an enhancement / feature request for RackTables (which is otherwise awesome!) to support overlapping IPv4 Address space. I work for a Service Provider who has several customers with their own RFC1918 address space and much of it over laps with each other - however my teams need to keep track of it!

Thanks,
Neil
TagsNo tags attached.

Relationships

has duplicate 0001119 closedandriyanov can't add IPv4 space with the same prefix belong to different vlan 
has duplicate 0001525 closed Feature request: Implimenting VRF support. 

Activities

nrobst

2012-10-22 12:49

reporter   ~0000931

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.

dnegreira

2013-02-12 13:58

reporter   ~0001127

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.

mahomedsh

2013-04-24 18:02

reporter   ~0001331

We also need this feature please.

Hyunmin

2013-05-15 13:33

reporter   ~0001413

Hi,
We have one more IDC sites, and we using same local IP address many..
I need this feature too.

melpheos

2013-08-23 21:00

reporter   ~0001719

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.

pbmax

2013-12-03 22:17

reporter   ~0002007

I need it too... We have a lab with duplicate RFC1918 space in multiple test environments.

Thanks -- we love RackTables.

dika.ye

2013-12-19 09:39

reporter   ~0002031

oh yeah, we have the same requirement.

carlosmp

2014-02-04 18:22

reporter   ~0002175

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.

melpheos

2014-07-08 09:58

reporter   ~0002413

Any progress on this idea ?

aleheux

2014-10-30 14:01

reporter   ~0002539

This is a feature that's holding us back from deploying Racktables.

Is there any progress?

hackmaster

2014-11-25 20:19

reporter   ~0002561

Hey all, would love to know if there is an update to this and if it's on the roadmap.

Thanks everyone!

andriyanov

2014-11-25 21:02

administrator   ~0002563

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.

aleheux

2014-11-26 20:51

reporter   ~0002565

\o/

james.tutton@redstone.com

2015-01-26 17:00

reporter   ~0002679

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.

three18ti

2015-03-10 17:26

reporter   ~0002767

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

jzohrab

2015-03-17 04:11

reporter   ~0002783

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.

andriyanov

2015-03-17 09:15

administrator   ~0002785

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.

james.tutton@redstone.com

2015-03-17 13:17

reporter   ~0002787

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.

jzohrab

2015-03-17 23:01

reporter   ~0002789

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.

sgroat

2015-05-05 18:50

reporter   ~0002819

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.

walterkeen

2015-10-06 01:52

reporter   ~0002989

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.

lordofgore

2016-04-21 17:28

reporter   ~0003163

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...

migalhas

2017-02-23 12:41

reporter   ~0003567

hi guys this Feature is very important.
Any update?

grin

2017-02-23 22:56

reporter   ~0003569

Main page : Configuration : User interface >> IPV4_JAYWALK=yes
is this what you're looking for?

mahomedsh

2017-02-24 11:41

reporter   ~0003571

@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.

grin

2017-02-24 13:48

reporter   ~0003573

@mahomedsh okay, the original issue was talking about "overlapping" and not "multiple instances". Jaywalk basically deactivates checks so you can use overlaps, you can delete subnets which overlap others, etc. You cannot enter duplicates, though. But since the whole IP assignment logic is based on unique IP addresses I doubt there'll be multiple equal subnets soon, since plenty of parts of the code depends on them being unique (eg. selections, router determination, vlans ....)

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.

mahomedsh

2017-02-24 15:14

reporter   ~0003575

@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 :)

Issue History

Date Modified Username Field Change
2012-10-15 16:39 nrobst New Issue
2012-10-15 16:39 nrobst Status new => assigned
2012-10-15 16:39 nrobst Assigned To => andriyanov
2012-10-22 12:49 nrobst Note Added: 0000931
2013-02-12 13:58 dnegreira Note Added: 0001127
2013-04-24 18:02 mahomedsh Note Added: 0001331
2013-05-15 13:33 Hyunmin Note Added: 0001413
2013-08-23 21:00 melpheos Note Added: 0001719
2013-12-03 22:17 pbmax Note Added: 0002007
2013-12-19 09:39 dika.ye Note Added: 0002031
2013-12-22 07:44 infrastation Relationship added has duplicate 0001119
2014-02-04 18:22 carlosmp Note Added: 0002175
2014-07-08 09:58 melpheos Note Added: 0002413
2014-10-30 14:01 aleheux Note Added: 0002539
2014-11-25 20:19 hackmaster Note Added: 0002561
2014-11-25 21:02 andriyanov Note Added: 0002563
2014-11-26 20:51 aleheux Note Added: 0002565
2015-01-26 17:00 james.tutton@redstone.com Note Added: 0002679
2015-03-10 17:26 three18ti Note Added: 0002767
2015-03-17 04:11 jzohrab Note Added: 0002783
2015-03-17 09:15 andriyanov Note Added: 0002785
2015-03-17 13:17 james.tutton@redstone.com Note Added: 0002787
2015-03-17 23:01 jzohrab Note Added: 0002789
2015-05-05 18:50 sgroat Note Added: 0002819
2015-09-16 18:29 infrastation Relationship added has duplicate 0001525
2015-10-06 01:52 walterkeen Note Added: 0002989
2016-04-21 17:28 lordofgore Note Added: 0003163
2017-02-23 12:41 migalhas Note Added: 0003567
2017-02-23 22:56 grin Note Added: 0003569
2017-02-24 11:41 mahomedsh Note Added: 0003571
2017-02-24 13:48 grin Note Added: 0003573
2017-02-24 15:14 mahomedsh Note Added: 0003575