What is our primary use case?
We had it in our company. We were an Infoblox customer, but we migrated from it just a couple of months ago. We are no longer a customer, but we used to be.
We're multinational. We had a part of the company in Europe that was spun off many years ago and then we got that company back. When we acquired that part of the company, we realized we have two different DDI systems. The most amount of data was in our VitalQIP system, which is a product by Nokia. It's off the shelf and a competitor to Infoblox. We also had Infoblox for this one part of the world, and we wanted to combine the two systems into one. We did an RFP to see which system we should use. Do we get a new vendor? Do we go with VitalQIP? Do we go with Infoblox? So, we started from scratch and sent out an RFP. We then made our decision to go with VitalQIP.
We were using Infoblox for pretty standard DDI functions. We were tracking all of our subnets. We were tracking the IPs within those subnets, and we were adding DNS entries. They were offering out DHCP scopes. So, it was pretty standard DNS, DHCP, and IP address management DDI. It'd be a pretty standard operation to be able to do that. For that part of the world, it was internal DNS only. It was not for our public DNS.
In terms of the version, we were a little bit behind the latest version.
How has it helped my organization?
It was just the standard DHCP. The business problem we were trying to resolve was how can we easily, dynamically hand out an IP address and not have it be static. We wanted to have the helper addresses configured on the router to be able to say, "Okay, here's a DHCP scope." So, the business problem to be solved was to be able to hand out DHCP addresses automatically and quickly to all of our customers, and then, of course, we also had the ability to have static IPs for those things that needed static IPs and did not change. DHCP can change all the time. You don't really care what your address is. You just want to get on the network. We also had the ability to assign static IPs for servers, routers, switches, and printers where the address had to be fixed. We were able to use the tool to assign static addresses and dynamic DHCP addresses that can change all the time.
What is most valuable?
The features we found the most valuable were being able to handle DHCP scopes and handing out DHCP leases. We weren't doing some of the things that we can do, such as DNS query rate limiting. Our usage was pretty standard. We wanted to be able to track our IP addresses to create DNS entries and then create DHCP and manage DHCP scopes. We used the standard features the most.
What needs improvement?
How you track IPs within a subnet and how all of that works was not intuitive to me. If I compare it to VitalQIP, I create a subnet, and it's a slash 24 size. It's very easy. I look, and here are my 254 IPs. I can then see if I have assigned a static, do I have a DHCP scope, and what's the name of the device. That's all there in front of me. The thing that I found frustrating with Infoblox was that it was not very intuitive. There were certain things you could add, which I thought were confusing. It did not have a similar layout. You could add something as a normal object and you would get the DNS name, the IP address, and what's called a NAPTR record, or there was also something where you could just add a DNS entry tool, just the A record, but you won't necessarily see all of those showing up easily in a subnet. In summary, the graphical interface for showing what IPs are defined in a subnet was not very intuitive. It could have a better look and feel to it.
What do I think about the stability of the solution?
Infoblox is a stable product. They have a lot of customers. VitalQIP used to have the biggest market share a long time ago. Now, Infoblox seems to be the number one with market share. In general, it has a reputation as being a pretty stable product, and it was stable for us. When we had it, we were happy with its stability in terms of uptime.
What do I think about the scalability of the solution?
It's a scalable solution. That was one thing that was probably better than VitalQIP. I just felt like it was more scalable. The database had room for lots of records in there. You could add additional appliances and have them all talk to Grid Manager if you wanted to scale to new locations.
There were over 1,000 people who were using the system one way. They may not be logging into it or doing anything, but they were using it for DNS resolution or getting a DHCP address.
How are customer service and support?
Their technical support was good. It wasn't great, but it was above average. We struggled to get answers to some of the questions, but it was pretty good. I would rate them a 7 out of 10.
How would you rate customer service and support?
Which solution did I use previously and why did I switch?
That was VitalQIP. It's a product from Nokia. Our Europe business spun off from the main part of the company due to some regulations, and we ended up buying them back and putting them back into the company or integrating them again. So, for whatever reason, and again, before my time, the main part of the company used VitalQIP. When they went off and were their own subsidiary or their own company, the Europe folks decided to go with Infoblox because, in a sense, they were two separate companies.
When the two companies merged back together, then it got confusing. It wasn't good to have two different DDI systems because we would create some automation for VitalQIP, the Nokia product, for example, and that was great. We would get that to work, but it would not work with Infoblox. We had to either live without that functionality, or we had to make a duplicate effort to try and do a similar process with Infoblox because there were totally different servers, different data, and different ways of processing.
There were several catalysts for getting rid of Infoblox. One of them was the fact that we have tools that we automate with VitalQIP. VitalQIP had probably 80% of the company's data in the DDI space and only 20% was in Infoblox. So, we made the decision to go with QIP and get it all in one system so that the automation works.
We were also behind a little bit in terms of the version of Infoblox. One of the reasons for our decision was that it was time for renewal. If we had to renew the software to a new version, we had to renew the maintenance contract. It was also time to renew the hardware. As we looked at it, we made our decision. We chose to, for now, at least migrate out of that and put the Infoblox data into the VitalQIP system. So, we retired Infoblox in May, which is just the opposite because everybody else is doing the opposite.
Infoblox has the biggest market share. Many people are moving off VitalQIP and going to Infoblox, for example. We were a rare occasion, going in the other direction. We are definitely not the norm. They have a bigger market share, but for us, based on what we were doing and our layout throughout the world, it just made sense for us to go to VitalQIP instead of taking all the VitalQIP data and going into Infoblox. So, we did it backward compared to most.
How was the initial setup?
When we deployed the system, there was Grid Manager that managed all of the other appliances out there and communicated with them for zone transfers and DHCP servers and things like that. So, we had Grid Manager, and then we deployed servers in various offices or data centers within the region so that we had some diversity there. If you're handing out DHCP addresses in a certain office, you want to have a server somewhat close to that so that you get a good response time. The same thing is with DNS resolution. We made sure we had redundancy. We made sure that we deployed in multiple data centers so that if we ever had a data center that just went offline, we would have another backup where we could still receive services on the other data center.
What about the implementation team?
I didn't deploy that system. That was done many years ago before I started with the company. We do have a partner we work with for our DDI system, and they helped us with both Infoblox, as well as with VitalQIP. We still communicate with them, and they still help us out with some things, but I don't know the history of whether, with the initial deployment, we used our value-added reseller (VAR). That was probably 15 years ago, and I've only been with the company for eight and a half years. In general, we have a VAR that helps us with questions that we have with both Infoblox and VitalQIP. Now, it's just VitalQIP because Infoblox is gone.
We were responsible for its maintenance. It needed maintenance. With any DDI system or pretty much any software, you're always going to have maintenance. So, we had to do the maintenance. We had to maintain the system to make sure it was running and it was backed up. We had to keep the software current and apply patches. We were very serious about security in our organization. So, if any vulnerabilities were found, we had to do maintenance and figure out how to fix them. We figured them out ourselves or had to call Infoblox and say, "We have this vulnerability that got identified. How do we fix it? Give us a fix or tell us some configuration parameters we need to make so that we are no longer vulnerable." So, there was definitely maintenance on it, and we did the maintenance ourselves within the company.
What was our ROI?
That would really be hard for me to quantify. I can't say, "Okay, we did this, and the return on investment came back in three years," or "This is how we definitely saved money." With the DDI system, for me, it's really hard to quantify the ROI.
What's my experience with pricing, setup cost, and licensing?
They were expensive. They were known to be expensive. In general, they used to at least try to encourage you to upgrade to hardware every three years. Infoblox had a reputation as being one of the better solutions but also one of the more expensive solutions, whereas VitalQ was definitely a much more affordable solution.
With Infoblox, anytime you replace hardware, there would also be the cost of the hardware upgrade. So, besides the software licensing fee, there were also hardware maintenance and hardware upgrade fees. I would rate it a 3 out of 10 in terms of pricing.
What other advice do I have?
I helped write most of the request for proposal (RFP) for this because we were trying to decide, "Should we get rid of VitalQIP and go to Infoblox? Should we get rid of Infoblox and go to VitalQIP?", which was our decision. There was a series of four vendors that we analyzed. For that RFP process, I would suggest taking a look and figuring out:
- What are your requirements?
- What do you need?
- What are you trying to accomplish?
- What are you currently using?
If being in the cloud is important to you, and you definitely know that you want to have a cloud or a hybrid cloud solution, then write that requirement down and know why you're going to be in the cloud. After that, talk to the vendors within the space. In our case, we had four different, and we had a bunch of questions. So, if the cloud is important to you, ask them, "How do you work in the cloud? What are your advantages?" Also, ask yourself, "Is this system going to do public data that the whole world is going to use, or is it just for your internal corporate DNS within the company?" That makes a difference for me because, with DNS, you're going to want to have rate limiting and protection in there. You would need to have more security from DDoS attacks and things like that, whereas if you're doing internal DNS, you've got firewalls to protect you from some of the bad actors, like somebody in China, Russia, etc. So, basically know:
- What are your DNS and DHCP needs?
- Are you going to be in the cloud or not?
- How many locations are going to be to spread out your server?
Get all your requirements done, and then my suggestion would be to ask the vendor. Have a set of questions to ask the vendor. Then, of course, before you buy anything, you would want to prototype it in the lab. Before you go to Infoblox, get into the lab, test everything, and see how this looks.
First and foremost, it shouldn’t break anything that you have right now. So, make sure that works. Typically, everybody seems to have a DDI system, they just may decide, "It's time for us to change. We're going to go to Infoblox." What you would want to do is spend time with Infoblox to say, "Hey, this is what our current system does. Can you do this?" That's because you want to make sure you don't go backward or lose any functionality, or something is going to break when you migrate.
You've definitely got to document all of the functionality of your existing system and what you want the new system to do and then ask Infoblox. If you're not happy with your existing DDI system and you're thinking Infoblox is going to be better, what you want to do is ask them, "Okay, why is this going to be better?" or, "Hey, here's some functionality that I need that my current system can't do, and can you do this for me? If so, let's prototype it in the lab." I strongly suggest prototyping it in the lab.
It's pretty stable, and it's scalable. I wasn't using it all the time, but I do know the person who used it and he seemed pretty happy with it. He understood the system. So, based on his feedback, I would rate it an 8 out of 10.
Which deployment model are you using for this solution?
On-premises