12-01-2015 08:57 AM - edited 12-01-2015 08:58 AM
Do Infoblox have any plans to add a secondary IP address/pseudo-interface feature for networking purposes?
On Linux I can do "ifconfig eth0:1 192.168.0.10" and bring up a secondary IP address on a pseudo-interface but this is not possible in Infoblox, you have to add a loopback and then add a static route on the upstream router. Unfortunately that's not possible in this customers environment as Cisco won't allow that route to be added - I'm not a networking expert so have to take their word for it.
It's a migration project so I need to maintain the old IP's for a period of time so now we are looking at maybe using the LAN2 interface. However this would all be a lot easier if I could just configure a pseudo-interface like you can on Linux.
How about it?
12-02-2015 01:42 PM
No plans that I am aware of as the loopback interface typically meets the requirements and has been used for this use case.
Curious that the customer says "Cisco won't allow..." with regards to the static route. Just about any router should allow a static route to be set for any network/IP to any gateway/IP so perhaps the issue is more permission based or what is acceptable in their environment. Nothing fancy here.
Sorry I can't help on the secondary IP but perhaps you give the customer a little nudge for the static route if they need to maintain their old IP addresses as well!
12-02-2015 03:25 PM
I think it has something to do with the addresses in use, the old address we are trying to maintain is on the same subnet as the new LAN1 IP address, so it's got something to do with Cisco not allowing a /32 host route to be added when there's already a /26 route for the LAN1 interface. The other problem is that LAN1 and LAN2 can't be on the same subnet, so we can't bring up the old address on LAN2 either, the customer is basically saying they'll have to keep running the old servers for the time being until they have migrated everything off them.
I don't understand enough about networking to figure it out, I'll try and ask them tomorrow to see if I can get a better handle on the problem as they see it.
12-03-2015 01:11 AM
As both the old and new IPs are in the same vlan, adding a route would not help : the /26 and /32 route would have the same nexthop. So, this is more a L2 issue.
A quick and dirty solution could be to add the loopback on the appliance and have a static ARP entry for it on the vlan's gateway. I can't test it now but don't see why it would not work (could be wrong though).
12-03-2015 02:05 AM
Ok that's interesting, I have just been discussing this with the customer and they appreciate a static ARP entry would allow this to work, however they are not willing to do this.
Their reason is that a static ARP entry will hardcode the appliance MAC address on the router, so if for any reason the appliance is replaced due to a fault, the MAC address will change and someone will have to update the static ARP entry. They therefore think this is not a satisfatory solution as it introduces additional "non-standard" complexity to their configuration. They also say if the router has to be replaced the static ARP entry may get missed off the new router configuration as it won't be part of their standard build so someone will have to remember to add it after the new router is built.
So basically the customer is not willing to introduce what they see as a "hack" into their environment in order to support this.
They do use static ARP entries in the DMZ where there is a strategic reason for doing so (e.g. so that firewalls can "claim" multiple IP addresses), but it doesn't look like it's something they are willing to do on their internal network.
12-03-2015 03:24 AM
Yes those concerns are valid. I also would not want this on our network, this is why I mentionned "dirty".
Two small remarks though :
You did not mention if the deployment was HA. If so the MAC is known and fixed (as per VRRP protocol definition). It might be more convincing.
Second, since this is temporary situation, you could negociate a fxed duration after which they remove the static ARP.
12-03-2015 03:50 AM
There's no HA but they are using anycast.
We did talk about doing this just temporarily but they're not keen. We've converted the old servers to forwarding only now to Infoblox, they are just going to leave them and try and move everything over to using the anycast addresses.
07-31-2018 09:43 AM
Hello, this has just cropped up again, I am working on an HLD and we ideally need to migrate the IPs of the old DNS servers to Infoblox as pseudo-interface IPs, would prefer not to have to hack about with the local router. Don't suppose this got any traction? I did have a quick look in the 8.2/8.3 release notes and admin guide but couldn't find anything. Guess my plea fell on deaf ears. :-(
07-31-2018 10:00 AM
Your Infoblox account (Sales) representative would be the best resource for any enhancement requests that you are looking for. Without that, your request most likely will not reach the appropriate audience for consideration.
With regards to this request, if you are only looking to add one additional IP, that is where LAN2 would be used.
I am also trying to get a better understanding on why the loopback interface will not work for you as that has been used in countless deployments without issue. I do not know what your environment looks like but traditionally, you would not need a MAC address for a static route. For example, here is the command for adding a static route in Cisco IOS:
ip route 192.0.2.0/8 ethernet 1/2 192.0.2.4
The interface where the route is going to is hard coded, but this would not break if the appliance is replaced in case of something like an RMA. Of course this could have an issue if there is a switch failure, but most deployments would restore the config from backup so there would be no risk of data loss for that either. Is there anything specific to your environment where this is not the case?