Trivia Friday: ip subnet-zero

The ip subnet-zero command has been largely irrelevant since it became the default in IOS quite some time ago, but it still generates occasional discussion among consumers of IOS trivia.

For whatever reason, a lot of people seem to think that setting no ip subnet-zero causes you to be unable to use either the all-zeros OR all-ones subnets of a classful network. This is not the case. Turning off ip subnet-zero (not that you would want to do this outside of an IOS trivial pursuit game!) only prevents you from assigning the all-zeros subnet of a network:

R2(config)#no ip subnet-zero
R2(config)#int loopback 0
R2(config-if)#ip add 10.0.0.1 255.255.255.192
Bad mask /26 for address 10.0.0.1
R2(config-if)#ip add 10.255.255.254 255.255.255.192
R2(config-if)#ip add 192.168.0.1 255.255.255.192
Bad mask /26 for address 192.168.0.1
R2(config-if)#ip add 192.168.254.254 255.255.255.192
R2(config-if)#

Note that we are only prevented from assigning the all-zeros subnet of the network, and there's no restriction on assigning the all-ones subnet.

troubleshooting basic POTS calls on a router

We get calls fairly regularly from users at sites with router-based VoIP systems (whether UCM Express or distributed UCM, it doesn't matter) saying that callers to their outside lines are getting ring-no-answer behavior.

The first thing I want to do is see if the calls are actually getting to the router. So I access the CLI and do the following:

Router#terminal monitor
Router#debug vpm signal

Then I place a test call to one of their outside lines. If the router just sits there and produces no output, then the problem is almost certainly either in the PSTN, or somebody has unplugged the cable from the FXO port.

If the router produces a bunch of barely comprehensible output, then the line is ringing and you've got further troubleshooting to do. Don't forget to turn off debugging when you're done!