Re: ntp access-group serve-only

Ok. As soon as I hit send everyone lost synchronization. Disregard
the previous email. Looks like you do need the peer acl as well..

On Jul 24, 2009, at 4:37 PM, G2 wrote:

> Gents & Ladies,
>
> I am trying to replicate a scenario I was given in a lab and cannot
> get the same results when I tried it on dynamips. The situation
> involves using "ntp access-group serve-only ACL#" feature on R6.
> -R6 is pulling timing from BB1. BB1 is the clock source
> -R6 can only allow R3 to pull timing from it
> -R3 must pull timing from R6
>
>
>
> My answer:
> R6#
> ntp server 54.1.2.254 (BB1)
> ntp access-group serve-only 1
>
> ip access-list 1 permit 150.1.3.3
>
> R3#
> ntp server 150.1.6.6
> ntp source loopback0
>
>
>
>
> Correct solution:
> R6#
> ntp server 54.1.2.254 (BB1)
> ntp access-group serve-only 1
> ntp access-group peer 2
>
> ip access-list 1 permit 150.1.3.3
> ip access-list 2 permit 54.1.2.254
>
> R3#
> ntp server 150.1.6.6
> ntp source loopback0
>
>
>
> Explanation given:
> NTP access group options are scanned in the following order
> from least restrictive to most restrictive:
> - peer
> - serve
> - serve-only
> - query-only
> Access is granted for the first match that is found. If no access
> groups
> are specified, all access is granted to all sources. If any access
> groups
> are specified, only the specified access is granted.
> If only the serve option is configured your router is not allowed to
> synchronize to the remote system.
>
>
> My QUESTION:
> Is the "ntp acess-group peer #" really required as seen in the
> correct solution? When I simulated this behavior, R3 was able to
> successfully pull timing from R6 however any devices not in ACL#1
> were not able to pull the timing. The access-group peer was not
> required on R6, it kept its timing from BB1 no problems. I waited a
> few hours.
>
> What am I missing? Is this IOS behavior dependent?
>
>
> Thanks,
> Gary

Blogs and organic groups at http://www.ccie.net
Received on Fri Jul 24 2009 - 17:05:22 ART