9/23/2011

NTP access control


Important trick I found on INE forum that should be remembered about NTP when you are using NTP access-control.


One of the important things that are not mentioned in the INE post is that by default no one will be rejected from the NTP master if it's not trying to authenticate that's why you will restrict those stations with ACL. 


"If your router is configured as NTP master, and you set up any access-control group, you must allow “peer” access type to a source with IP address “127.127.7.1”. This is because “127.127.7.1” is the internal server created by ntp master command, which the local router synchronizes to. If you forget to enable it peer access, your server will always be out of sync. Here are some examples. First one: configure R1 as NTP master and allow the server to be polled for NTP updates just by one client. Client should receive updates just from one source:"






reating an Access Group and Assign a Basic IP Access List to It


To control access to NTP services, you can create an NTP access group and apply a basic IP access list to it. To do so, use the following command in global configuration mode:
Command
Purpose
ntp access-group {query-only | serve-only | serve| peer} access-list-number
Creates an access group and applies a basic IP access list to it.


The access group options are scanned in the following order, from least restrictive to most restrictive:
1. peer—Allows time requests and NTP control queries and allows the system to synchronize itself to a system whose address passes the access list criteria.
2. serve—Allows time requests and NTP control queries, but does not allow the system to synchronize itself to a system whose address passes the access list criteria.
3. serve-only—Allows only time requests from a system whose address passes the access list criteria.
4. query-only—Allows only NTP control queries from a system whose address passes the access list criteria.
If the source IP address matches the access lists for more than one access type, the first type is granted. If no access groups are specified, all access types are granted to all systems. If any access groups are specified, only the specified access types will be granted.
For details on NTP control queries, see RFC 1305 (NTP version 3).






192.168.2.24 configured, insane, invalid, unsynced, stratum 16
ref ID 0.0.0.0, time 00000000.00000000 (02:00:00.000 GMT Mon Jan 1 1900)
our mode client, peer mode unspec, our poll intvl 512, peer poll intvl 512
root delay 0.00 msec, root disp 0.00, reach 0, sync dist 3774813.461
delay 0.00 msec, offset 0.0000 msec, dispersion 16000.00
precision 2**5, version 3
org time 00000000.00000000 (02:00:00.000 GMT Mon Jan 1 1900)
rcv time 00000000.00000000 (02:00:00.000 GMT Mon Jan 1 1900)
xmt time CEE8139F.D5044C0D (08:24:31.832 GMT Fri Jan 1 2010)
filtdelay =     0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
filtoffset =    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
filterror =  16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0


127.127.7.1 configured, our_master, sane, valid, stratum 4
ref ID 127.127.7.1, time CEE813A4.D3F3A778 (08:24:36.827 GMT Fri Jan 1 2010)
our mode active, peer mode passive, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.00, reach 377, sync dist 0.015
delay 0.00 msec, offset 0.0000 msec, dispersion 0.02
precision 2**18, version 3
org time CEE813A4.D3F3A778 (08:24:36.827 GMT Fri Jan 1 2010)
rcv time CEE813A4.D3F3A778 (08:24:36.827 GMT Fri Jan 1 2010)
xmt time CEE813A4.D3F38B82 (08:24:36.827 GMT Fri Jan 1 2010)
filtdelay =     0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
filtoffset =    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
filterror =     0.02    0.99    1.97    2.94    3.92    4.90    5.87    6.85
Reference clock status:  Running normally
Timecode: 

9/02/2011

Ethernet over SDH. It's interesting topic though, I got such question on job interview few days ago and I think I was too stressed to give the answer straight away but after I left the interview I came out with few answers about that and I used such solution few years ago in Iceland.

So, you want to carry native Ethernet over SDH but for some historical reasons you have a huge SDH/PDH network which carry mainly IP - so what you can do about it? I was thinking of Ethernet-over-IP-over SDH? why not? I tried something like that couple of years back and it works.

The Telco way is to convert the SDH to ethernet with pseudo-wire (tunnelling) and Axerra networks and Tellabs have such solutions or using the so well advertised rfc4448 (ethernet-over-mpls)