Default Gateway .0

[jamanso]

Hi All,

I have a network that was upgraded to 4548GT Switches.
They are in the IP network 10.1.0.0/255.255.0.0
The default Gateway is 10.1.1.0

The software that came with the switches didn't accpet that configuration (invalid Default Gateway).

After upgrading to FW:5.3.0.3  SW:v5.6.0.008 BN:08. they start to accept the configuration.
But I was unable to use one as Default Gateway (10.1.1.0) because some other devices that were working correctly before were unable to function (for example a Policom MCU).

Any ideas?

Thanks,

[bylie]

Not to sound rude but the easiest solution to me would probably be to just use another default gateway IP, 10.1.0.1/16 or 10.1.255.254/16 come to mind as obvious choices. I'm more of a "last IP in the subnet .254" person myself ;-). Although it should technically be possible to use a .0 in this case I can imagine that there's always going to be some sofware, incorrectly written/implemented, that's going to trip over stuff like this.

[Michael McNamara]

There are a few different IP addresses that should be avoided (although they are legal).

Those include ending in .0, I've also see other equipment have issues with ending in .127 (loopback).

As mentioned by @blyie, it's probably best to just avoid using this IP addresses.

Cheers!

[jamanso]

You are both right, but I always tend to use this approach to detect pourly writen TCP/IP Stack, not only with address "exceptions" but other issues that are more rude and dificult to detect.

What can we expect from a network developer that does not knows how to implement a simple netmask?
Do we expct that the rest will be better?

In this case what is troubling me is the routing problem of Policom MCU, that points to other issues in the layer3 implemenation of Avaya switches.

I can always change the DG to anything else, but, I still have to workarround other issues.

Tks

There are a few different IP addresses that should be avoided (although they are legal).

Those include ending in .0, I've also see other equipment have issues with ending in .127 (loopback).

As mentioned by @blyie, it's probably best to just avoid using this IP addresses.

Cheers!

[bylie]

I also agree with your viewpoint that, in the end, this should be implemented correctly, no excuses (especially from a networkvendor). My first reply was tailored more on just getting things working because these days I'm often happy enough when stuff just works even if, in the back of my mind, I know that there might still be some issues that need resolving.
Maybe, if you already have the necessary steps to reproduce this, it might be a good idea to open a supportcase with Avaya so they can fix this.

[bylie]

Just read this today about a new Cisco IOS bug:

CSCtx12848 Bug Details : .255 address in NTP field receives "Invalid Server Address" error.
Symptom: Cannot add an IP ending in .255 in NTP Server field.
Conditions: Adding NTP.
Workaround: Don't use .255 IP address in NTP Server field.

It seems that everyone can drop the ball on the basics sometimes .