«

Experimenting a few minutes ago, I found a couple of PIX 6.3(3)
and 6.3(4) 'name' enhancements that aren't documented. These might
have come into effect earlier still; I haven't checked.


Before, a value defined in a 'name' could only be used in the host
or network position of a location where an ip and mask pair was expected,
such as in

access-list FOO permit udp host MyServer MyISP 255.255.255.200 eq dns

object-group network BAR
network-object host MyOtherServer


In particular, using a name in the netmask area was not allowed:

name 255.255.255.0 ClassC
access-list FOO permit udp host MyServer MyISP ClassC eq dns


In 6.3(3) and 6.3(4) it is now valid to enter a name instead of a
netmask. This is not what the online help indicates, but it works.

When you display the access-list, the name will NOT be displayed in
the mask areas.

If, though, you use this in an object-group network, and you display
the object, then the name WILL be substituted:

npix(config-network)# show object-group id FOO
object-group network FOO
network-object 208.215.64.0 Bad64

But if this object is embedded into an ACL, then when you display the
ACL and the PIX expands out the object-group, then in the display
of the ACL, the mask names will NOT be shown -- only when you display
the objects as objects.


Interestingly, names of masks -will- be substituted when showing
'route' statements.


======

I also found that PIX 6.x accepts netmasks that are not CIDR. Before
I was under the impression that the masks had to have consequative
bits set. Somehow I suspect that some features (e.g., IPSec) don't
take kindly to non-consequative bits set in the mask...
--
Beware of bugs in the above code; I have only proved it correct,
not tried it. -- Donald Knuth

Walter Roberson wrote:

>
> I also found that PIX 6.x accepts netmasks that are not CIDR. Before
> I was under the impression that the masks had to have consequative
> bits set. Somehow I suspect that some features (e.g., IPSec) don't
> take kindly to non-consequative bits set in the mask...

What about non-consecutive netmask bits? Does it really mean I can represent all networks whose kind is indicated by the
last clear bits?

I mean

10.10.10.0 255.255.255.0 stands for 10.10.10.0-255

but

does 10.10.10.0 255.254.255.0 stand for 10.10.10.0-255 and 10.11.10.0-255 ?

Alex.

In article <Xjswe.26653$>, AM <> wrote:
:Walter Roberson wrote:

:> I also found that PIX 6.x accepts netmasks that are not CIDR. Before
:> I was under the impression that the masks had to have consequative
:> bits set.

:does 10.10.10.0 255.254.255.0 stand for 10.10.10.0-255 and 10.11.10.0-255 ?

Maybe. The PIX does not complain if you use 255.254.255.0 as
the mask, and -does- hold on to the mask as given, and -does-
check to see whether the network given pairs with the mask given.
But I would want to test this first: I -suspect- it does not work
in some contexts such as ip address pools and IPSec masks.
--
Look out, there are llamas!