Haruskah perangkat keras jaringan diatur ke kecepatan “negosiasi otomatis” atau kecepatan tetap?


90

Kami baru-baru ini memiliki sedikit masalah dengan jaringan di mana beberapa server sebentar-sebentar akan kehilangan konektivitas jaringan dengan cara yang cukup menyakitkan untuk diselesaikan (diperlukan reboot keras). Ini telah berlangsung selama sekitar dua minggu, tampaknya secara acak, di server yang berbeda. Tidak ada pola khusus yang bisa kita pahami.

Setelah beberapa menggali ke dalamnya, kami melihat bahwa saklar melaporkan 100 Mbps untuk port masalah:

Ini terdengar sangat seperti apa yang terjadi dalam artikel Joel Spolsky Five Whys

Michael menghabiskan beberapa waktu melakukan post-mortem, dan menemukan bahwa masalahnya adalah masalah konfigurasi sederhana di sakelar. Ada beberapa kemungkinan kecepatan yang dapat digunakan saklar untuk berkomunikasi (10, 100, atau 1000 megabit / detik). Anda dapat mengatur kecepatan secara manual, atau Anda dapat membiarkan sakelar secara otomatis menegosiasikan kecepatan tertinggi yang dapat digunakan oleh kedua belah pihak. Sakelar yang gagal telah diatur ke negosiasi otomatis. Ini biasanya berhasil, tetapi tidak selalu, dan pada pagi hari tanggal 10 Januari, itu tidak berhasil.

Kami sekarang telah menonaktifkan negosiasi otomatis pada perangkat keras jaringan kami dan menetapkannya ke tingkat tetap 1000 Mbps (gigabit).

Pertanyaan saya kepada mereka yang memiliki keahlian jaringan perangkat keras server:

  1. Seberapa umum masalah negosiasi otomatis dengan perangkat keras jaringan modern?
  2. Apakah ini dianggap baik, praktik jaringan standar untuk menonaktifkan negosiasi otomatis dan mengatur kecepatan tetap saat mengatur jaringan?

Sudahkah Anda menonaktifkan negosiasi otomatis pada server Anda dan memperbaikinya hingga 1000 / penuh?
James

22
Ini hanya saya, tetapi jika saya berlari ke masalah Anda, saya akan bertanya-tanya mengapa saklar dan server tidak menegosiasikan kecepatan prioritas tertinggi (1000 / penuh). Itu memberitahu saya bahwa ada sesuatu yang rusak dan dengan memaksa tautan ke kecepatan tertentu Anda hanya menutupi masalah.
Doug Luxem

ada beberapa platform (terutama Solaris 9) yang memiliki masalah dengan negosiasi otomatis dalam skenario yang diketahui - saya hanya menggunakan autoneg dengan apa pun yang dibuat dalam dekade terakhir,
Warren

Sesuatu yang hampir membuat saya merah muda tergelincir: serverfault.com/questions/328105/ethernet-interface-errors
nixnotwin

Jawaban:


101
  1. Saya belum melihat masalah dengan negosiasi otomatis kecepatan jaringan yang tidak disebabkan oleh (a) ketidakcocokan manual di salah satu ujung tautan dan otomatis di sisi lain atau (b) komponen tautan yang gagal ( kabel, port, dll).

  2. Ini tergantung pada admin, tetapi pengalaman saya menunjukkan kepada saya bahwa jika Anda secara manual menentukan kecepatan tautan dan pengaturan dupleks, maka Anda akan mengalami ketidakcocokan kecepatan. Mengapa? Karena hampir tidak mungkin untuk mendokumentasikan berbagai koneksi antara sakelar dan server dan kemudian ikuti dokumentasi itu ketika membuat perubahan. Sebagian besar kegagalan yang saya lihat adalah karena 1 (a) dan Anda hanya masuk ke situasi itu ketika Anda mulai mengatur pengaturan kecepatan / dupleks secara manual.

Seperti disebutkan dalam dokumentasi Cisco :

Jika Anda menonaktifkan negosiasi otomatis, ini menyembunyikan tetes tautan dan masalah lapisan fisik lainnya. Hanya menonaktifkan negosiasi otomatis ke perangkat akhir, seperti NIC Gigabit yang lebih lama yang tidak mendukung negosiasi otomatis Gigabit. Jangan nonaktifkan negosiasi otomatis antar sakelar kecuali benar-benar diperlukan, karena masalah lapisan fisik tidak dapat terdeteksi dan menghasilkan spanning tree loop.

Kecuali jika Anda siap untuk menyiapkan sistem manajemen perubahan untuk perubahan jaringan yang memerlukan verifikasi kecepatan / dupleks (dan jangan lupa kontrol aliran) atau bersedia berurusan dengan ketidaksesuaian sesekali yang datang dari menentukan pengaturan ini secara manual pada semua perangkat jaringan, kemudian tetap dengan konfigurasi default otomatis / otomatis.

Di masa mendatang, pertimbangkan untuk memantau kesalahan pada port switch dengan MRTG sehingga Anda dapat menemukan masalah ini sebelum Anda memiliki masalah.

Sunting: Saya melihat banyak orang merujuk kegagalan negosiasi pada peralatan lama. Ya, ini merupakan masalah sejak dulu ketika standar dibuat dan tidak semua perangkat mengikutinya. Apakah NIC dan sakelar Anda berumur kurang dari 10 tahun? Jika demikian, maka ini tidak akan menjadi masalah.


6
Cacti pada dasarnya adalah MRTG tanpa kekacauan konfigurasi sehingga harus bagus. Mulailah memantau tetesan dan kesalahan RX, tabrakan TX, dll. Satu atau lebih penghitung ini akan "tinggi" jika Anda memiliki masalah negosiasi. Tinggi relatif terhadap jumlah lalu lintas di pelabuhan.
Doug Luxem

2
@ EEK - Konfigurasi perlu dilakukan pada sakelar dan perangkat. Mengganti perangkat (atau mungkin hanya memutakhirkan driver / firmware), memindahkan port, atau mengganti sakelar semuanya merupakan masalah pengaturan yang tidak cocok. Saya tidak yakin mengapa Anda melihat begitu banyak kesalahan - kami menjalankan HP, Cisco, Extreme dan Juniper di sini dan saya tidak pernah melihat masalah negosiasi otomatis. Satu-satunya masalah yang saya lihat adalah ketika salah satu ujung tautan diatur secara manual. Seperti yang disebutkan dalam dokumen Cisco, mungkin Anda memiliki beberapa masalah L1 yang mendasarinya?
Doug Luxem

7
Pengalaman saya menggunakan sakelar HP, Cisco, dan Dell cocok dengan w / DLux. Saya menduga dari upvotes bahwa banyak orang lain merasakan hal yang sama. Jaringan di mana admin religius mengatur kecepatan port / duplex selalu memiliki lebih banyak masalah dengan ketidakcocokan dibandingkan jaringan di mana semuanya diatur untuk negosiasi otomatis.
Evan Anderson

3
@Whisk WAN link adalah cerita yang berbeda. Ketika Anda diberikan tautan ethernet dari beberapa penyedia, mereka sering dipaksa untuk manual atau menggunakan transceiver yang tidak mendukung negosiasi otomatis. Mereka cukup banyak harus ditangani berdasarkan kasus per kasus.
Doug Luxem

3
Saya pikir pemungutan suara agak menyesatkan karena beberapa orang akan memiliki kemewahan perangkat keras dari 1 atau 2 vendor (atau hanya tidak berpengalaman banyak) dan tidak pernah melihat masalah sedangkan yang lain seperti saya akan mewarisi peralatan dari banyak vendor berbeda yang tidak berkelakuan buruk dalam kombinasi tertentu.
JamesRyan

23
  1. Sangat umum, saya punya banyak masalah selama bertahun-tahun dengan berbagai jenis perangkat keras.

  2. Menurut pendapat saya jika pengaturannya statis (yaitu rak server) dan Anda tidak berpikir akan ada perubahan, itu adalah ide yang baik untuk mengatur kecepatan dan dupleks secara manual. Asalkan didokumentasikan dengan baik sehingga masalah di masa depan dapat dihindari.

SUNTING:

Hanya untuk memperjelas, saya tidak menganjurkan menggunakan kecepatan manual di seluruh jaringan Anda, saya akan mengatakan bahwa 95% dari waktu otomatis / otomatis adalah cara untuk pergi. Saya hanya mengatakan saya punya masalah dengan duplex / kecepatan dan ada bagian kecil dari jaringan saya (yaitu salah satu rak server kami) yang sebagian besar memiliki pengaturan manual. Kami mengoperasikan LAN yang sangat dikontrol ketat dengan port yang tidak digunakan sedang dimatikan dan MAC-Filter di sebagian besar port sehingga melacak kecepatannya tidak terlalu sulit.


5
Saya telah menemukan masalah yang sama, tetapi mungkin hanya 1/100 server yang akan mengalami masalah negosiasi otomatis. Biasanya tidak terlihat pada jaringan yang lebih kecil tetapi cukup mengganggu pada yang lebih besar.
Dave Drager

+1 - Saya juga telah melihat masalah auto-negotiate yang muncul selama bertahun-tahun. Memiliki tim yang distandarisasi dalam menonaktifkan auto-negotiate untuk semua switch menghilangkan masalah itu bagi kami.
Joe Doyle

Tidak ada yang ditambahkan ke ini, kecuali bahwa saya dapat menggemakan bahwa saya telah melihat banyak masalah. Jika ada orang lain yang memiliki info tentang MENGAPA negosiasi otomatis gagal (relatif) secara teratur, saya ingin mendengarnya.
Schof

@ telah jadi kemungkinan masalah negosiasi otomatis terjadi naik dengan ukuran dan kompleksitas jaringan - itu masuk akal. Juga, kami memperluas jaringan rak server kecil kami selama setahun terakhir sebesar 3x ...
Jeff Atwood

4
@ Jeff Atwood: Hanya sejauh "ukuran" migt berhubungan dengan memiliki peluang yang lebih baik untuk menambahkan perangkat dengan perilaku negosiasi otomatis yang rusak akan potensi masalah meningkat. Ini bukan seperti membanjirnya frame atau menyiarkan traffic. Negosiasi otomatis antara setiap perangkat klien dan setiap port switch.
Evan Anderson

15

Saya percaya jika negosiasi otomatis bekerja selama satu jam sehari atau sebulan dan kemudian untuk beberapa alasan "terjadi sesuatu" yang mengatur tautan ke kecepatan tetap "memperbaikinya" ada masalah yang tidak diselesaikan tetapi dielakkan sebagai gantinya. Saya kira saya melihat pengaturan tautan untuk diperbaiki sebagai solusi sementara sampai masalah yang sebenarnya diperbaiki.


sepenuhnya mungkin; kami sudah melakukan banyak pemecahan masalah lain untuk mengesampingkan, tapi saya khawatir tim Joel memiliki masalah yang sama seperti yang didokumentasikan dalam "Five Whys". Tampaknya agak meluas ..
Jeff Atwood

7
Saya setuju masalah dengan negosiasi otomatis terjadi "sering" tetapi dalam kebanyakan kasus setelah itu telah bekerja untuk "sementara". Itulah yang mendorong saya untuk ingin menyelidiki lebih lanjut alih-alih menggunakan tautan tetap sebagai "solusi" Maksud saya ... jika mobil Anda yang "berjalan dengan baik" mulai berjalan kasar kecuali memanas selama 10 menit, Anda tidak akan mengatakan kepada diri Anda "Hei, semakin tua dan sekarang perlu memanas selama 10 menit" Anda akan menerimanya untuk melihat peluang paling awal Anda karena "ada sesuatu yang salah" yang tidak terjadi sebelumnya :)
dimitri.p

15

Jadi langkah pemecahan masalah (anggap Anda berhenti setelah masing-masing dan menunggu masalah muncul kembali):

  1. Periksa log pada sakelar untuk melihat apakah itu memberi tahu Anda mengapa menggunakan 100 juta.
  2. Jika Anda masih menjalankannya, matikan omong kosong "Windows load balancing" yang sangat jahat yang mendorong Joel sepanjang waktu - cara kerjanya adalah dengan memecah cache switch, memaksanya untuk memroses perangkat lunak setiap paket. Switch Anda dirancang untuk meneruskan paket dalam perangkat keras, dan hanya memiliki CPU yang diperlukan untuk mengetahui jalur fisik apa yang harus diambil oleh aliran lalu lintas yang tidak diketahui (in -> asic -> out), dan program perangkat keras untuk melakukannya (baca: a kalkulator memiliki CPU yang lebih baik daripada switch Anda, jangan lakukan hal bodoh yang membuat CPU switch Anda bekerja lebih keras). Windows load balancing berfungsi dengan membuat saklar Anda membuat keputusan itu dan menginstal ulang cache perangkat keras untuk setiap paket. Itu mungkin tidak memperbaiki masalah khusus ini, tapi itu mengganggu saya dari podcast ... maaf.
  3. Pastikan konfigurasi cocok di kedua sisi - sepertinya Anda telah melakukan itu
  4. Google untuk bug autoneg pada saklar Anda - kecuali jika Anda membuatnya sendiri, Anda bukan satu-satunya yang mencoba menjalankan autoneg pada apa pun yang Anda gunakan
  5. Ganti kabel, dengan nilai Cat5e atau lebih baik - idealnya kabel yang Anda tahu berfungsi, seperti yang digunakan stasiun kerja Anda. Jangan mencoba menggunakan Cat5, atau omong kosong yang dibuat seseorang, gunakan yang memiliki ujung cetakan yang sebenarnya dari sebuah paket.
  6. Pindahkan port - Letakkan server pada port yang berbeda di sakelar yang sama
  7. Ganti NIC - gunakan batch berbeda yang dipesan pada waktu yang berbeda

Pada titik ini, Anda telah menghilangkan konfigurasi, port fisik yang Anda tancapkan, kabel di antaranya. Jika masih terjadi, beberapa penyebab lain mungkin:

  1. Perutean kabel - berhati-hatilah terhadap gangguan EM dari kabel daya AC Anda, rutekan ke sisi rak yang berbeda.
  2. Pendinginan - Pastikan suhu lingkungan Anda tidak sekitar 90 derajat dan kartu NIC Anda tidak jatuh ke mode "tuhan sayang izinkan saya untuk meneruskan paket yang satu ini". Saya pernah mendengar tetapi tidak melihat bahwa router Cisco berhenti melakukan paket pengalihan dan penerusan cepat melalui CPU ketika mereka terlalu panas, misalnya.
  3. Ganti switch dengan sesuatu yang tidak payah - periksa berapa banyak bandwidth host Anda berbicara per detik secara agregat, dan kemudian lihat kapasitas backplane terukur dari switch Anda. 7 host dari potensi 48, semua transmisi 1.0G sudah cukup untuk menghentikan Cisco 3750, misalnya. Juga menjadi sangat berhati-hati tentang murahan juga-lari vendor jaringan: D-Link, Linksys, Dell, Intel, dan HP. Tidak ada yang memperlakukan jaringan dengan serius menggunakan orang-orang itu, dan bukan karena "tidak ada yang dipecat karena menggunakan Cisco", tetapi karena "orang ingat bahwa saklar Intel yang memiliki 20/48 port gagal lebih dari 2 tahun" atau "Saya dulu menggunakan ProCurve secara eksklusif dan mencerca tentang betapa jahatnya Cisco, sampai saya benar-benar menggunakan Cisco, pada saat itu saya berhenti membeli sesuatu yang kurang ". Cisco dianggap kelas menengahvendor jaringan, jadi apa artinya itu kepada Anda tentang orang-orang di bawah ini Cisco ...? :-)

Latar belakang / mengapa jawaban saya adalah yang paling mengagumkan: Saya bekerja sebagai insinyur jaringan / sistem dalam industri keuangan, dan inilah pengalaman saya dengan jaringan global kecil-kecil kami (15 kantor cabang, 8 pusat data):

Semua port LAN kami adalah autoneg, karena kami mengontrol peralatan di kedua ujungnya, dan memiliki semacam akses ke kedua sisi --- yang mungkin sesederhana mendapatkan telepon ke seseorang dan meminta mereka memeriksa pengaturan. Dalam tiga tahun, saya hanya pernah mengalami salah satu port internal kami gagal karena kegagalan autoneg, dan itu karena kabel yang buruk --- hilang setelah mengganti kabel.

Kami memiliki lebih banyak masalah di mana pendahulu telah melakukan hardcod 100 / penuh pada NIC mereka, dan tidak mendokumentasikan fakta itu. Setel ulang semuanya menjadi otomatis / otomatis pada jendela pemeliharaan berikutnya dan sejak itu tidak ada masalah dengannya.

Di beberapa tempat di mana kami mendapat handoff tembaga dari pembawa untuk WAN kami? Anda seharusnya cukup berharap koneksi WAN / Internet tembaga menyedot, sepanjang waktu --- sebagian karena Anda tidak tahu apa yang ada di sisi lain. Beberapa saklar Ekstrim kuno yang kebetulan memiliki firmware kereta untuk autoneg tetapi apakah pemberian tag MPLS? Konverter media seharga $ 5 karena perangkat Ciena edge Anda yang $ 200k terlalu bagus untuk menyediakan Ethernet daripada twisted pair? Tentukan terlebih dahulu bagaimana hal itu akan ditangani dan berpegang teguh pada itu, kemudian mengharapkan beberapa twit di dalam operator untuk mengubahnya pukul 10 malam pada hari Sabtu karena konfigurasi yang disepakati tidak pernah didokumentasikan dan mereka memiliki beberapa kebijakan untuk diikuti.

Namun, serius, dapatkan handoff serat dari ISP Anda.


2
Baru saja membaca ini - jawaban yang bagus.
Helvick

Jawaban yang sangat bagus.
Rushino

2
supaya jawaban akhirnya ada di sini, di suatu tempat, itu adalah driver Broadcom yang buruk. Kami tidak dapat menemukan set yang berfungsi. Beralih ke Intel NIC memperbaikinya 100%. blog.serverfault.com/2011/03/04/broadcom-die-mutha
Jeff Atwood

@ Jeff Jtff Apakah itu masalah yang sama? Saya pikir yang satu ini akhirnya dilacak ke mode hemat daya pada saklar ...
James Cape

14

Jaringan yang saya bertanggung jawab untuk (bersama dengan beberapa orang lain) terdiri dari ~ 40 server, 1000+ workstation (tersebar di kampus yang agak besar) dan ~ 1000 WAP juga tersebar di area yang luas dengan beragam jenis dan usia peralatan jaringan.

Seperti yang dikatakan dimitri.p, ketika sesuatu tiba-tiba gagal menghentikan negosiasi otomatis, biasanya itu merupakan indikasi masalah lain. Mengatur port secara manual mirip dengan meletakkan bandaid pada seseorang yang ditusuk di dalam usus - itu mungkin menghentikan pendarahan, tetapi pasti ada kerusakan di bawahnya.

Daftar periksa saya yang biasa:

  • apakah ada yang berubah pada mesin? driver? Pengaturan level OS atau BIOS? Mungkin autoneg dinonaktifkan di OS?
  • Sudahkah Anda menukar kabel patch, dan memverifikasi kabel berjalan (jika itu adalah logner run dari satu rak?)
  • sudahkah Anda diuji untuk melihat apakah port switch buruk atau gagal?
  • Mungkinkah NIC menjadi buruk?

Kami, sebagai suatu peraturan, tidak pernah menonaktifkan autoneg pada server (atau apa pun di pusat data) kecuali itu adalah situasi di mana semua kemungkinan penyebab lainnya telah dihilangkan, kami memindahkan port switch, mengubah kabel, menguji NIC, dll. Dan tidak ada pilihan lain. Dalam hal ini, itu akan didokumentasikan sampai mati. Ini sangat jarang terjadi, dan biasanya dengan peralatan yang kita tidak dapat mengakses untuk memeriksa pengaturan BIOS dan OS.

Sebaliknya, workstation dan AP adalah cerita yang berbeda. Gagal autoneg adalah tanda klasik dari kabel jelek, dan sering kali kita harus secara manual mengatur kecepatan dan dupleks sampai musim panas berjalan-kabel-baru-di-tembok-musim datang.


kami telah menukar kabel dan port berulang kali pada server "bermasalah", dan kami kembali menggunakan driver jaringan "in the box" (Server 2008 R2). Ini juga terjadi pada beberapa server dengan konfigurasi yang sama. Saya mengalami kesulitan mendamaikan "tidak pernah melakukan ini!" dan "selalu lakukan ini!" dalam jawaban atas pertanyaan yang sama.
Jeff Atwood

@ Jeff: Menjadi terbiasa dengan pertanyaan yang Anda dan tim Anda awalnya diposting ( serverfault.com/questions/104791 ) Saya tertarik untuk mendengar jika masalahnya mengikuti port switch atau port NIC di komputer server bermasalah . Apa sih yang membuat / model NIC / chipset?
Evan Anderson

1
@ Jeff - Beberapa jawaban bukan biner :) Lakukan ketika Anda harus, sampai Anda memiliki kesempatan untuk mencari tahu apa masalahnya.
dimitri.p

@evan terjadi di setiap server tingkat web, tidak mengikuti port switch atau kartu ethernet. Jika masih merupakan masalah setelah perubahan ini, itu adalah masalah perangkat lunak. Servernya adalah Lenovo RS110 x6 dan Lenovo RD120 x2.
Jeff Atwood

1
Hanya untuk memastikan jawaban akhir ada di sini, di suatu tempat: itu adalah masalah driver dengan Broadcom. Kami tidak dapat menyelesaikannya dengan set driver yang dikenal. Satu-satunya "perbaikan" adalah beralih ke Intel NIC.
Jeff Atwood

10

Ini adalah mitos jaringan. Orang-orang jaringan kami bersumpah dengan omong kosong ini, karena pada tahun 1998 Bay switch tidak akan bernegosiasi dengan Cisco atau sesuatu. Jadi, alih-alih menggunakan default untuk 99,999% dari peralatan di bumi, kami melakukan latihan manajemen konfigurasi yang konyol ini dan kambing hitam untuk saat-saat ketika pembaruan driver NIC me-reset pengaturan untuk bernegosiasi otomatis dan apa pun yang terjadi.

Itu membuat lebih lucu karena banyak server kami menggunakan fitur yang meragukan seperti NIC teaming, yang mencegah Anda kehilangan akses jaringan jika terjadi kegagalan switch, sementara membuat Anda terkena kemungkinan kegagalan perangkat lunak yang jauh lebih besar. (Driver selalu payah)

Dalam membela orang-orang jaringan, banyak severs berjalan dengan driver NIC Windows-default, yang biasanya payah. Jika Anda memiliki masalah dengan negosiasi otomatis, dan peralatan Anda tidak sesuai dengan pemerintahan Clinton, perbarui driver NIC tersebut.


1
Itu pada akhirnya driver yang buruk, tetapi satu-satunya perbaikan yang kami temukan adalah beralih ke Intel NIC. Kami sekarang memiliki dendam seumur hidup terhadap Broadcom NIC.
Jeff Atwood

10

Anda harus bernegosiasi otomatis. Jika Anda memiliki sakelar yang tidak akan dinegosiasikan secara andal, beli sakelar yang lebih baik.

Gigabit seharusnya dinegosiasikan secara otomatis, dan itu termasuk deteksi auto-crossover (MDI-X).

100baseT dijamin gagal jika salah satu ujungnya diatur ke otomatis dan yang lainnya diatur ke manual, dan itu sesuai spesifikasi. Jika Anda memaksa salah satu ujung ke 100 / penuh maka ujung lainnya akan dinegosiasikan secara otomatis ke 100 / setengah, memberikan Anda ketidakcocokan duplex.


9

Biasanya saya mengatur server untuk diperbaiki karena saya telah melihat peralatan jaringan bernegosiasi ke 10 / setengah bukannya 1000 / penuh.

Juga beberapa CoLos mengatur sakelar mereka untuk tidak bernegosiasi, tetapi hanya membuat tautan pada 1000 / penuh.


7

Menonaktifkan negosiasi otomatis dalam konfigurasi awal yang belum diuji mirip dengan pemrograman voodoo - Anda mengubah sesuatu tanpa alasan yang kuat. Jika, setelah diuji, Anda melihat ada ketidakcocokan dupleks atau kecepatan atau ada kesalahan berlebihan pada port, kemudian terlibat dalam pemecahan masalah lainnya dan akhirnya memperbaiki konfigurasi jika perlu.

Ketika Anda meningkatkan driver atau mengganti perangkat keras, tidak ada jaminan bahwa pengaturan Anda akan dipertahankan di sisi server.

Atur kedua sisi tautan untuk bernegosiasi, atau perbaiki kedua sisi. Ketika Anda memperbaiki pengaturan kecepatan dan dupleks pada beberapa perangkat, mereka tidak lagi mengumumkan kemampuan mereka kepada rekan-rekan mereka. Saya tidak tahu apa yang dikatakan standar Ethernet tentang apa yang harus dilakukan ketika satu sisi mengumumkan kemampuan dan sisi lainnya tidak, dan itu mungkin berarti banyak pelaksana yang juga tidak tahu. Beberapa akan memilih penyebut umum terendah, yaitu 10-setengah dan yang lain akan menganggap semuanya baik-baik saja dan memilih kecepatan tercepat yang mungkin.

Ada beberapa perangkat keras kontemporer yang tidak mendukung negosiasi otomatis pada Ethernet tembaga gigabit, seperti (setidaknya beberapa) switch Cisco dengan SFP tembaga.


Modul 6748-SFP mendukung autoneg dengan baik, mereka hanya tidak memungkinkan Anda untuk bernegosiasi untuk apa pun kecuali 1000 / penuh. :-)
James Cape

6

Bertahun-tahun yang lalu saya menghabiskan beberapa waktu bekerja untuk 3com melakukan dukungan teknis untuk hampir semua peralatan jaringan mereka. Sungguh menakjubkan betapa sering masalah ini muncul dan cukup banyak prosedur standar untuk mengatur semuanya secara manual.


4
Pernyataan operatif dalam jawaban ini adalah "Bertahun-tahun yang lalu." Negosiasi 10/100 tidak sama dengan negosiasi otomatis gigabit hari ini.
Evan Anderson

1
Anda benar sekali! Ini memang "bertahun-tahun yang lalu" dan sekarang dalam retrospeksi saya tidak ingat ini terjadi di dekat sering dengan salah satu peralatan gigabit, yang cukup baru pada saat itu.

4

Saya punya banyak masalah dengan negosiasi otomatis. Banyak, tentu saja, berarti satu setiap beberapa bulan, tetapi itu satu masalah terlalu banyak dalam buku saya.

Masalah negosiasi otomatis sulit ditemukan, terutama ketika orang yang menangani jaringan, server, aplikasi, dan basis data adalah empat tim yang berbeda. Biasanya, dua yang terakhir akan menghabiskan banyak waktu untuk bolak-balik, menuduh satu sama lain kinerja buruk dan berbohong tentang pengukuran, dan kadang-kadang menendang ke orang-orang server, yang sepatutnya akan melihat output "atas" dan mengatakan semuanya baik-baik saja dengan server.

Ini berlanjut sampai masalah meningkat ke titik di mana "ahli" (sebenarnya, seseorang yang generalis, dan dengan demikian memahami jaringan, perangkat keras, sistem operasi, database, kerangka kerja dan aplikasi) ditugaskan untuk masalah, dan menemukan masalah dalam lima atau sepuluh menit.

Jadi, aturan praktis saya sendiri, setiap kali saya memiliki kemampuan untuk melakukan sesuatu tentang hal itu, adalah SELALU menetapkan kecepatan tetap pada server produksi, switcher dan router. Server non-produksi juga, jika mereka cukup terpisah untuk orang-orang yang menggunakannya tidak memiliki akses root di dalamnya.

Switch yang menangani akses desktop / notebook dapat dibiarkan melakukan negosiasi otomatis, dan ada pengecualian untuk aturan tersebut. Untuk menyebutkan satu saja, jika ada banyak perubahan yang terjadi di jaringan, lebih baik membiarkannya di auto dan mengawasi hal-hal.

Poin lain yang mungkin berguna, pilihan apa pun yang Anda buat mengenai negosiasi otomatis , adalah memantau masalahnya. Cukup konfigurasikan Nagios atau apa pun yang Anda miliki untuk mengawasi keadaan port penting. Anda sudah memantau peralatan jaringan itu, bukan?


4

Yang kasar. Saya telah melihat 100MB NIC 3com yang tidak akan terhubung pada apa pun di atas 10MB jika Anda memaksa kecepatan atau duplex. Anda hanya bisa mendapatkan kecepatan penuh dengan membiarkan mereka bernegosiasi meskipun pengemudi memiliki pengaturan 100Mb Penuh dan Setengah 100Mb.

Banyak driver NIC tidak akan membiarkan Anda menentukan 1000Mb. Satu-satunya pilihan adalah 10, 100, Otomatis. Sekali lagi memaksa Anda untuk melakukan Otomatis jika Anda ingin kecepatan penuh. misalnya driver Broadcom netXtreme 57xx Gigabit berperilaku seperti ini.

Anda dapat dengan mudah memaksa Gigabit pada saklar tetapi saya pikir Anda akan dipaksa untuk membiarkan sebagian besar NIC otomatis dinegosiasikan.


5
Spesifikasi gigabit membutuhkan negosiasi otomatis.
duffbeer703

3
  1. Dalam pengalaman saya (kebanyakan peralatan 3Com dan HP, tidak banyak Cisco), negosiasi otomatis tidak menyebabkan banyak masalah.

  2. Demikian pula untuk mrdenny, saya biasanya akan mengatur server ke kecepatan tercepat mereka (kami masih punya beberapa di 100), dupleks penuh, dan kemudian meninggalkan saklar di otomatis. Karena kami memiliki campuran kecepatan pada kedua server dan workstation, saya lebih suka membiarkan sakelar pada otomatis dan membiarkannya beradaptasi dengan titik akhir.


2
Dengan peralatan Cisco jika Anda secara manual mengatur kecepatan pada tuan rumah dan membiarkan sakelarnya bekerja secara otomatis, Anda memperbesar kemungkinan masalah. Ciscos lebih suka Auto-Auto atau manual-manual
einstiien

Bukan hanya Cisco - semuanya bekerja lebih baik ketika kedua ujung tautan cocok.
James

3

Saya punya beberapa masalah dengan negosiasi otomatis dalam pengaturan rumah dan masalahnya adalah kabel, khususnya kabel jaringan digulung dalam satu lingkaran dengan diameter terlalu kecil atau meletakkannya terlalu dekat dengan kabel listrik.

Tapi saya pikir saran itu agak terlalu sepele untuk pengaturan Anda. ;)


2

Saya baru-baru ini membaca tentang ini di Network Warrior oleh Gary Donahue. Berdasarkan buku ini untuk negosiasi-otomatis berfungsi dengan baik KEDUA saklar dan NIC harus diatur ke negosiasi-otomatis. Mengatur NIC ke mode kecepatan dan dupleks tertentu dan meninggalkan server pada negosiasi otomatis tidak akan berfungsi dengan baik - negosiasi otomatis adalah protokol dan kedua belah pihak perlu berbicara untuk pengaturan agar berfungsi dengan benar.

Jika Anda ingin mengatur mode kecepatan dan dupleks secara eksplisit, Anda harus melakukannya di kedua ujung koneksi.


itu tergantung apakah Anda berbicara tentang negosiasi-gigabit baru-ketinggalan jaman - ini benar-benar berbeda dari negosiasi 10/100 yang lama.
Jeff Atwood


1

Aturan praktis saya adalah menggunakan negosiasi otomatis untuk semuanya kecuali tautan router kecuali Anda secara khusus memiliki masalah (seperti kartu Broadcom baru-baru ini ... BAH!)

Jika Anda memiliki dua router yang terhubung melalui ethernet misalnya, atur kecepatan secara manual di kedua ujungnya.


2
Mengapa Anda mengatur kecepatan antar router secara manual?
Amok

Saya kira itu kebiasaan. Tetapi ketika Anda mulai berpikir tentang tautan non-ethernet, Anda biasanya harus mengatur kecepatan.
Aaron C. de Bruyn
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.