Access Control Lists

Default Behavior

With no ACL options specified, all messages or requests are accepted.

Allow-Deny Order

If ‘allow’ or ‘deny’ lists are defined but no order is specified then ‘allow-deny’ order is assumed. This policy can be specified explicitly:

ptp_timing_acl_order allow-deny

The default policy for the allow-deny order is that all messages or requests are denied.

The ‘allow’ list defines networks and hosts that are permitted to communicate and the ‘deny’ list defines networks and hosts that will nevertheless be excluded. It makes sense for the deny list to be more specific than the allow list.

ptp_timing_acl_allow 172.16.128.0/21
ptp_timing_acl_deny 172.16.128.48/32 172.16.128.47/32

In the above example, the first line identifies a subnet from which, exclusively, PTP timing messages will be accepted. The second, optional, line identifies that access from the two specified hosts will be denied, despite being in the ‘allow’ list. These could perhaps be VPN end-points, DMZ hosts, or hosts running customer applications.

Deny-Allow Order

This policy is introduced with:

ptp_timing_acl_order deny-allow

The default policy for the deny-allow order is that all messages or requests are accepted.

The ‘deny’ list defines networks and hosts that will be disallowed and the ‘allow’ list defines networks and hosts that will nevertheless be permitted to communicate. It makes sense for the allow list to be more specific than the allow list.

ptp_timing_acl_deny 172.16.128.0/21
ptp_timing_acl_allow 172.16.128.48/32 172.16.128.47/32

In the above example, the first line identifies a subnet from which PTP timing messages will be denied. The second, optional, line identifies two specific hosts that will be allowed to send timing messages, despite being in the ‘deny’ list. These hosts could perhaps be company infrastructure that is on a subnet used as a DMZ for visiting vendors.