On Mon, Oct 22, 2012 at 6:49 PM, Justin Krejci <jkrejci@usinternet.com> wrote:

And since owen has not yet mentioned it, consider something that supports having : in its address as well.

Sort of tangentially related, I had a support rep for a vendor once tell me that a 255 in the second or third octet was not valid for an ipv4 address. Hard to troubleshoot a problem when I had to first explain how ip addressing worked because the rep was so fixated on the 255 we were using on the network. If any product really doesn't like 255 in any position then you should consider yourself lucky to still be in business at all. Jimmy Hess <mysidia@gmail.com> wrote:On 10/22/12, Paul Zugnoni <paul.zugnoni@jivesoftware.com> wrote: [snip]

...

Any experience or recommendations? Besides replace the ISA proxy…. Since it's not mine to replace. Also curious whether there's an RFC recommending against the use of .0 or .255 addresses for this reason.

ISA is old, and might not be supported anymore, unless you have an extended support contract. If it's not supported anymore, then don't be surprised if it has breakage you will not be able to repair. I don't recommend upgrading to TMG, either: although still supported, that was just discontinued.

If ISA is refusing traffic to/from IPs ending in .0, then ISA is either broken, or misconfigured. Get a support case with the vendor, raise it as a critical issue -- unable to pass traffic to critical infrastructure that ends with a .255 or .0 IP address, demand that the vendor provide a resolution, And explain that changing the IP address of the remote server is not an option.

If the vendor can't or won't provide a resolution, then not only is the proxy server broken, but malfunctioning in a way that has an impact on network connectivity.

I would consider its removal compulsory, as you never know, when a network resource, web site, e-mail server, etc. your org has a business critical need to access, or be accessed from; may be placed on .255 or .0

-- -JH

this was also discussed back in August in this thread http://mailman.nanog.org/pipermail/nanog/2012-August/051290.html james