INA Router Issues

[drace1111]

Our network uses the INA module to split a T. Between the INA and our network is a DMZ of sorts, with a proxy/firewall in between. It looks like this:

Internet<--INA-->192.168.20.X (DMZ)<--Firewall-->192.168.10.X (internal).

We had no computers within the DMZ. Today I tried to put a computer within the DMZ for FTP purposes, but I'm getting an IP address conflict with the INA. I've checked the MAC address, and the INA is definitely the source of the conflict. Has anyone had this problem, or know how to fix it?

Darin Race
IT Systems Administrator
Cook Technologies Inc.

 

[gregarican]

Check the INA config to see what IP addresses it is using. The static IP address on the internal interface might coincide with the static IP address you are trying to assign your other box. Other than that perhaps check to see if the INA is trying to distribute addresses to other clients using DHCP. One or the other is likely the source of the issue.

If you have the PMVision application just backup the INA configuration and view this as a text file. It will show you all IP addresses associated with the INA as well as if it is configured to dish out addresses via DHCP.

 

[drace1111]

Sorry, I should have included those details in my first post. The internal side if the INA is static at 192.168.20.1 . The external side of our firewall is static at 192.168.20.2 . DHCP is turned off on both sides, so I can't find any reason why the INA would conflict if I put up a server with a 192.168.20.3 static address. Any other thoughts?

If it makes any difference, the ComOS is version 4.1.5dBeta.

Darin

 

[drace1111]

Another important detail. If I assign this computer any IP address within the 192.168.20.x range, I get an IP address conflict.

Darin

 

[gregarican]

That is weird. If there aren't any other hosts within the DMZ and the subnet mask is within a reasonable range I can't see what the issue would be. You mean even manually assigning a higher IP like 192.168.20.100 throws the same IP conflict error?

Can you try to add a different host to the DMZ and see if the same result occurs?

 

[drace1111]

I tried adding a different host to the DMZ, but got the same error. No matter what address I type in, from 3 to 254, same problem. Its got to be some obscure setting within the INA. I have a number for an Avaya network engineer who I'll be calling later this morning.

Darin

 

[gregarican]

If you could take production services down for awhile it would be interesting to temporarily disable the INA board, then try to add a host within the DMZ IP range. If it worked then that would really point to the INA board as being the root cause.

It's amazing if this big of a quirk exists within this INA board. If it indeed proves to be the case please post the results of the engineer's call.

I didn't think that multiple IP's could be bound to the same interface on these INA boards. If all IP's within the DMZ range would be conflicting this seems to be a possibility, though. And you say that DHCP is disabled. Even if it was enabled then IP reservations within the INA board wouldn't prohibit these same addresses from being grabbed by another host if they were inactive and no other host was physically using them.

Really interesting stuff. Again, please post your findings!

 

[gregarican]

Just bumping this up to see if you had any more ideas regarding the root cause. Did the Avaya engineer get back with you??

 

[drace1111]

I haven't heard from him yet. Of course, it's possible that he doesn't work for Avaya anymore. I have another person to try tomorrow.

 

[drace1111]

** UPDATE **

I finally talked to someone at Avaya about this problem. After several back and forth calls, they determined that the INA board is defective. They could find no reason why the INA would behave like this. The good thing is they are sending a tech out with a new INA free of charge. I certainly hope that this fixes the problem. The y new board is coming today, so I will post the results tonight.

Darin

 

[gregarican]

Great news. That's definitely an odd situation with the IP conflicts. I will check in tonight to see what the result was. There was a QPPCN from back in 4/2003 that I applied to our company's INA board. It was for data router buffer limits and came with a PMVision update. Probably wouldn't have made a difference in your case. There was also an INA firmware upgrade I flashed about a year and a half ago, but it didn't address anything similar to what you are seeing. This INA from what it sounds like is definitely out in left field!

 

[drace1111]

As usual, things have not worked out as promised. The tech arrived yesterday without a new board. He says he needed to see the number on the old board to be sure that he ordered the correct one. The new board is supposedly going to be here today. I'll believe it when I see it.

The tech did tell me that the board revision that we have (Rev A) has issues, and that he is ordering a Rev B board that should fix the problem. Again, I'll believe it when I see it. I'm keeping my fingers crossed. If this doesn't work, I'm going to skip the INA and purchase a REAL router from Cisco.

Darin

 

[gregarican]

So what's the latest chapter is the continuing saga? Did the tech bring the Rev B board to pop in?