Klasifikasi QoS mana yang harus diterapkan pada NTP?

Referensi Jaringan Referensi Solusi QoS Solusi Cisco menyarankan mengklasifikasikan NTP sebagai lalu lintas manajemen jaringan dan menandainya sebagai CS2:

Saat menangani kebutuhan QoS untuk lalu lintas Manajemen Jaringan, Cisco merekomendasikan pedoman berikut:

Lalu lintas Manajemen Jaringan harus ditandai ke DSCP CS2.

Aplikasi Manajemen Jaringan harus dilindungi secara eksplisit dengan jaminan bandwidth minimal.

Lalu lintas manajemen jaringan penting untuk melakukan analisis dan pemecahan masalah tren dan kapasitas. Oleh karena itu, Anda dapat menyediakan antrean bandwidth minimal terpisah untuk lalu lintas Manajemen Jaringan, yang dapat mencakup SNMP, NTP , Syslog, NFS dan aplikasi manajemen lainnya .

Mengingat NTP sensitif terhadap jitter, mengapa NTP tidak ditandai sebagai Expediated Forwarding dan diperlakukan sama dengan data suara?

Apakah ada alasan mengapa tidak ditempatkan dalam antrian latensi rendah yang sama dengan suara?

— Stephen Craven
sumber

Saya tidak berpikir "sensitif jitter" adalah karakterisasi NTP yang adil. Ini menjelaskan banyak hal, tapi saya percaya algoritma dan interval pemungutan suara dapat menangani sejumlah jitter. Jadi itu akan membuat saya berpikir itu tidak perlu diperlakukan sama seperti suara. (Saya tahu sedikit tentang QoS.)

— Craig Constantine

@CraigConstantine Benar. Di sebagian besar lingkungan, selama Anda bisa mendapatkan antrian untuk mengalahkan lalu lintas BE, Anda mungkin unggul 95% dari data, bagaimanapun.

— Ryan Foley

@CraigConstantine lihat RFP4594 Bagus, tangkap Stephen. Saya kira Cisco tidak sejalan dengan IETF yang ini? ...

— Ronnie Royston

Cisco adalah perusahaan besar dengan banyak individu / grup. Tidak semua dari mereka selalu sepakat tentang apa yang terbaik. Secara pribadi, saya pikir rekomendasi IETF lebih baik ketika datang ke "waktu akurasi tinggi" tapi saya pribadi tidak ingin NTP untuk peralatan jaringan saya (yang saya biasanya tidak akan diklasifikasikan sebagai akurasi tinggi) menjadi "waktu jam dinding" atau DF seperti yang dikatakan RFC. Rekomendasi Cisco tampaknya lebih "tengah jalan" dan sesuai dengan apa yang saya harapkan akan memenuhi kebutuhan NTP umum untuk peralatan jaringan.

— YPelajari

@StevenCraven, agar ini menjadi pertanyaan yang bisa dijawab, kita perlu memahami seperti apa persyaratan presisi yang Anda miliki untuk NTP dan bagaimana itu digunakan.

— Mike Pennington

Jawaban:

Jawaban yang diedit: NTP harus ditempatkan di kelas EF (sama dengan paket suara real-time) sesuai dengan Pedoman Konfigurasi RET 4594 IETF untuk Kelas Layanan DiffServ .

5.2. Pemetaan untuk NTP

Dari tes yang dilakukan, indikasi adalah bahwa distribusi waktu yang tepat membutuhkan transportasi variasi paket keterlambatan (jitter) yang sangat rendah. Oleh karena itu, kami menyarankan agar pedoman berikut untuk Network Time Protocol (NTP) digunakan:

o Ketika NTP digunakan untuk menyediakan waktu dengan akurasi tinggi dalam jaringan administrator (operator) atau untuk pengguna / klien akhir, kelas layanan Telephony harus digunakan , dan paket NTP harus ditandai dengan nilai EF DSCP.

o Untuk aplikasi yang membutuhkan ketepatan waktu "jam dinding", kelas layanan standar harus digunakan, dan paket harus ditandai dengan DF DSCP.

— Ronnie Royston
sumber

dikoreksi di atas

— Ronnie Royston

NTP tidak terlalu sensitif terhadap jitter karena menggunakan originatedan transmitstempel waktu untuk melacak penundaan. Ntp.org menjelaskan secara terperinci bagaimana hal itu membuat penundaan dalam pemeriksaan , tetapi inilah cuplikannya:

Menyinkronkan klien ke server jaringan terdiri dari beberapa pertukaran paket di mana setiap pertukaran adalah sepasang permintaan dan balasan. Saat mengirim permintaan, klien menyimpan waktunya sendiri (asal timestamp) ke dalam paket yang dikirim. Ketika server menerima paket seperti itu, ia akan menyimpan waktunya sendiri (menerima stempel waktu) ke dalam paket, dan paket tersebut akan dikembalikan setelah memasukkan stempel waktu pengiriman ke dalam paket. Saat menerima balasan, penerima sekali lagi akan mencatat waktu penerimaan sendiri untuk memperkirakan waktu perjalanan paket. Waktu perjalanan (penundaan) diperkirakan setengah dari "total penundaan dikurangi waktu pemrosesan jarak jauh", dengan asumsi penundaan simetris.

Alasan ini tidak dalam kategori yang sama dengan kontrol jaringan adalah karena ini tidak secara langsung bertanggung jawab untuk operasi routing / penerusan paket. Semua hal dalam kategori manajemen jaringan bukanlah komponen penting dari sistem jaringan secara keseluruhan. Jika Anda kehilangan paket yang terkait dengan SNMP, syslog, atau NTP, Anda mungkin tidak akan menyadarinya.

SNMP hanya akan mengirimkan kembali informasi itu karena berbasis TCP. Bahkan jika koneksi terputus bersama, tidak ada bencana yang akan terjadi; Anda mungkin hanya mendapatkan agen snmp tidak merespons dan kemudian coba lagi. Jika Anda kehilangan lalu lintas syslog (UDP), Anda hanya akan kehilangan satu blip informasi logging, yang mungkin masih terkandung dalam buffer atau dalam file log pada perangkat. Karena NTP menghitung penundaan berdasarkan paket sebelumnya, sementara juga memperhitungkan kesalahan offset maksimum, Anda benar-benar tidak mengalami masalah apa pun. Skenario kasus terburuk, waktu Anda melayang oleh beberapa picoseconds ...

Jika Anda kehilangan paket yang terkait dengan perutean, bahkan untuk sesaat, Anda mungkin menghadapi seluruh sistem turun; membuat tanda lain tidak berharga. Pada saat itu, NTP hanya akan benar-benar tidak sinkron dan mengandalkan ticker lokal untuk menjaga waktu.

— Ryan Foley
sumber