Pertanyaan Haruskah perangkat keras jaringan diatur ke "autonegosiasi" kecepatan atau kecepatan tetap?


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

Setelah beberapa penggalian ke dalamnya, kami melihat bahwa switch melaporkan 100 Mbps untuk port masalah:

Ini terdengar sangat mirip dengan apa yang terjadi di artikel Joel Spolsky Lima Kenapa

Michael menghabiskan beberapa waktu melakukan bedah mayat, dan menemukan bahwa masalahnya adalah masalah konfigurasi sederhana pada saklar. Ada beberapa kemungkinan kecepatan yang dapat digunakan suatu tombol untuk berkomunikasi (10, 100, atau 1000 megabit / detik). Anda dapat mengatur kecepatan secara manual, atau Anda dapat membiarkan saklar secara otomatis menegosiasikan kecepatan tertinggi yang dapat digunakan kedua belah pihak. Saklar yang gagal telah diatur ke autonegosiasi. Ini biasanya berfungsi, tetapi tidak selalu, dan pada pagi hari tanggal 10 Januari, itu tidak terjadi.

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

Pertanyaan saya untuk mereka yang memiliki keahlian jaringan perangkat keras server lebih banyak:

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

87
2018-01-25 18:57




Sudahkah Anda menonaktifkan negosiasi otomatis di server Anda juga dan memperbaikinya hingga 1000 / penuh? - James
Ini hanya saya, tetapi jika saya berlari ke masalah Anda, saya akan bertanya-tanya mengapa switch dan server tidak menegosiasikan kecepatan prioritas tertinggi (1000 / penuh). Itu memberi tahu 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 autonegosiasi dalam skenario yang dikenal - Saya hanya menggunakan autoneg dengan apa pun yang dibuat dalam dekade terakhir, meskipun - warren
Sesuatu yang hampir membuat saya terpeleset merah muda: serverfault.com/questions/328105/ethernet-interface-errors - nixnotwin


Jawaban:


  1. Saya belum melihat masalah dengan negosiasi otomatis kecepatan jaringan yang tidak disebabkan oleh salah satu (a) ketidakcocokan manual pada 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 telah menunjukkan kepada saya bahwa jika Anda secara manual menentukan kecepatan tautan dan pengaturan dupleks, maka Anda pasti akan mengalami ketidakcocokan kecepatan. Mengapa? Karena hampir tidak mungkin untuk mendokumentasikan berbagai koneksi antara switch dan server dan kemudian mengikuti dokumentasi itu ketika membuat perubahan. Kebanyakan 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 di Dokumentasi Cisco:

Jika Anda menonaktifkan autonegosiasi, itu menyembunyikan tetes tautan dan masalah lapisan fisik lainnya. Hanya nonaktifkan autonegosiasi ke perangkat akhir, seperti NIC Gigabit yang lebih lama yang tidak mendukung autonegosiasi Gigabit. Jangan menonaktifkan autonegosiasi antara switch kecuali benar-benar diperlukan, karena masalah lapisan fisik bisa tidak terdeteksi dan menghasilkan loop pohon yang melebar.

Kecuali Anda siap untuk menyiapkan sistem manajemen perubahan untuk perubahan jaringan yang memerlukan verifikasi kecepatan / dupleks (dan jangan lupa kontrol aliran) atau bersedia menangani ketidaksesuaian sesekali yang berasal dari penetapan setelan ini secara manual di semua perangkat jaringan, kemudian tetap dengan konfigurasi default auto / auto.

Di masa depan, pertimbangkan untuk memantau kesalahan pada port switch dengan MRTG sehingga Anda dapat melihat masalah ini sebelum mengalami masalah.

Edit: Saya memang melihat banyak orang merujuk kegagalan negosiasi pada peralatan lama. Ya ini adalah masalah sejak lama ketika standar dibuat dan tidak semua perangkat mengikuti mereka. Apakah NIC Anda dan switch kurang dari 10 tahun? Jika demikian, maka ini tidak akan menjadi masalah.


101
2018-01-25 19:15



Cacti pada dasarnya adalah MRTG tanpa kekacauan konfigurasi sehingga seharusnya bagus. Cukup mulai pantau tetesan dan kesalahan RX, tabrakan TX, dll. Satu atau lebih dari penghitung ini akan "tinggi" jika Anda memiliki masalah negosiasi. Tinggi relatif terhadap jumlah lalu lintas di pelabuhan. - Doug Luxem
@EK - Konfigurasi harus dilakukan pada sakelar dan perangkat. Mengganti perangkat (atau mungkin hanya meng-upgrade driver / firmware), memindahkan port, atau mengganti sakelar semua adalah kekhawatiran untuk 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 disetel secara manual. Seperti yang disebutkan oleh dokumen Cisco, mungkin Anda memiliki beberapa masalah mendasar L1? - Doug Luxem
Pengalaman saya menggunakan HP, Cisco, dan Dell switch cocok dengan w / DLux. Saya tebak oleh upvote bahwa banyak orang lain merasakan hal yang sama. Jaringan di mana admin secara religius mengatur kecepatan port / duplex selalu memiliki masalah yang jauh lebih banyak dengan ketidaksesuaian daripada jaringan di mana semuanya diatur untuk autonegosiasi. - Evan Anderson
Tautan @Whisk WAN adalah cerita yang berbeda. Ketika Anda menyerahkan 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
Saya pikir pemungutan suara agak menyesatkan bahwa beberapa orang akan memiliki kemewahan perangkat keras dari 1 atau 2 vendor (atau hanya tidak mengalami banyak) dan tidak pernah melihat masalah sementara yang lain seperti saya akan mewarisi peralatan dari banyak vendor yang berbeda yang melakukan berkelakuan buruk dalam kombinasi tertentu. - JamesRyan


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

  2. Menurut pendapat saya jika setup 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 masa depan dapat dihindari.

EDIT:

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


23
2018-01-25 19:03



Saya telah menemukan masalah yang sama tetapi mungkin hanya 1/100 server yang memiliki masalah autonegosiasi. Ini 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 popup selama bertahun-tahun. Memiliki tim standar untuk menonaktifkan negosiasi otomatis untuk semua switch menghilangkan masalah itu bagi kami. - Joe Doyle
Tidak ada yang perlu ditambahkan ke ini, kecuali bahwa saya dapat menggemakan bahwa saya telah melihat banyak masalah. Jika orang lain memiliki info tentang WHY autonegosiasi gagal jadi (relatif) secara teratur, saya ingin mendengarnya. - Schof
@membiarkan begitu kemungkinan masalah autonegosiasi terjadi meningkat dengan ukuran dan kompleksitas jaringan - itu masuk akal. Juga, kami memperluas jaringan rak server kecil kami selama setahun terakhir dengan 3x ... - Jeff Atwood
@Jeff Atwood: Hanya sejauh migt "ukuran" berhubungan dengan memiliki peluang yang lebih baik dalam menambahkan perangkat dengan perilaku autonegosiasi yang rusak, maka potensi masalah akan meningkat. Ini tidak seperti membanjiri frame atau menyiarkan lalu lintas. Autonegosiasi secara ketat antara masing-masing perangkat klien dan setiap port switch. - Evan Anderson


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


15
2018-01-25 19:47



sepenuhnya mungkin; kami sudah melakukan banyak pemecahan masalah lainnya untuk menyelesaikan masalah, tetapi saya khawatir tim Joel memiliki masalah yang sama seperti yang didokumentasikan dalam "Lima Kenapa". Sepertinya agak luas .. - Jeff Atwood
Saya setuju masalah dengan autonegosiasi terjadi "sering" tetapi dalam banyak kasus setelah itu bekerja untuk "sementara". Itulah yang mendorong saya untuk ingin menyelidiki lebih lanjut daripada menggunakan tautan tetap sebagai "solusi" yang saya maksud ... jika mobil Anda yang "berjalan baik" mulai berjalan kasar kecuali memanas selama 10 menit, Anda tidak akan mengatakan kepada sendiri "Hei itu semakin tua dan sekarang perlu untuk pemanasan selama 10 menit" Anda akan mengambilnya untuk melihat pada kesempatan paling awal Anda karena "ada sesuatu yang salah" yang tidak sebelum :) - dimitri.p


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

Seperti yang dimitri.p katakan, ketika sesuatu tiba-tiba gagal menghentikan autonegosiasi, itu biasanya merupakan indikasi masalah lain. Mengatur port secara manual sama dengan menempatkan bandaid pada seseorang yang ditikam di usus - itu bisa menghentikan pendarahan, tapi pasti ada kerusakan di bawahnya.

Daftar periksa saya yang biasa:

  • apakah ada yang berubah pada mesin? driver? Pengaturan tingkat OS atau BIOS? Mungkin autoneg dinonaktifkan di OS?
  • apakah Anda mengganti kabel patch, dan diverifikasi kabel berjalan (jika logner berjalan dari satu rak?)
  • sudahkah Anda menguji untuk melihat apakah port switch buruk atau gagal?
  • bisakah NIC menjadi buruk?

Kami, sebagai suatu peraturan, tak pernah nonaktifkan autoneg pada server (atau apa pun di pusat data) kecuali itu adalah situasi di mana semua penyebab lain yang mungkin telah dihapuskan, kami pindah port switch, kabel berubah, menguji NIC, dll. dan tidak ada pilihan lain. Dalam hal ini, ia didokumentasikan sampai mati. Ini sangat jarang terjadi, dan biasanya dengan peralatan yang tidak bisa kami akses untuk memeriksa pengaturan BIOS dan OS.

Workstation dan AP, di sisi lain, adalah cerita yang berbeda. Autoneg yang gagal adalah tanda klasik dari kabel yang buruk, dan berkali-kali kita harus mengatur kecepatan dan dupleks secara manual sampai musim panas berjalan-baru-kabel-di-dinding-datang sekitar.


14
2018-01-25 20:08



kami telah bertukar kabel dan port berulang kali pada server "masalah", dan kami kembali menggunakan driver jaringan "dalam kotak" (Server 2008 R2). Ini juga terjadi pada beberapa server dengan konfigurasi yang sama. Saya mengalami kesulitan untuk berdamai "jangan lakukan ini!" dan "selalu lakukan ini!" dalam jawaban atas pertanyaan yang sama. - Jeff Atwood
@Jeff: Menjadi akrab dengan pertanyaan yang Anda dan tim Anda awalnya diposting (serverfault.com/questions/104791) Saya tertarik untuk mendengar jika masalahnya adalah mengikuti port switch atau port NIC di komputer server bermasalah (s). Apa yang dimaksud dengan make / model NIC / chipset? - Evan Anderson
@Jeff - Beberapa jawaban tidak 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 apa pun. Jika masih masalah setelah perubahan ini, itu adalah masalah perangkat lunak. Servernya adalah Lenovo RS110 x6 dan Lenovo RD120 x2. - Jeff Atwood
Hanya untuk memastikan jawaban terakhir ada di sini, di suatu tempat: itu adalah masalah driver dengan Broadcom. Kami tidak bisa menyelesaikannya dengan set driver yang dikenal. Satu-satunya "perbaikan" adalah beralih ke NIC Intel. - Jeff Atwood


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

  1. Periksa log pada sakelar untuk melihat apakah itu memberi tahu Anda mengapa menggunakan 100M.
  2. Jika Anda masih menjalankannya, matikan omong kosong "load balancing Windows" yang sangat jahat yang mendorong Joel sepanjang waktu - cara kerjanya adalah dengan memecah cache switch, memaksanya ke perangkat lunak memproses setiap paket. Switch Anda dirancang untuk meneruskan paket di perangkat keras, dan hanya memiliki CPU yang diperlukan untuk mengetahui jalur fisik apa yang harus diambil oleh arus lalu lintas yang tidak diketahui (di -> asic -> out), dan memprogram perangkat keras untuk melakukannya (baca: kalkulator memiliki CPU yang lebih baik daripada switch Anda, jangan melakukan hal-hal bodoh yang membuat CPU switch Anda bekerja lebih keras). Load balancing Windows bekerja dengan membuat switch 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 - terdengar seperti Anda telah melakukannya
  4. Google untuk bug autoneg pada switch Anda - kecuali Anda membangunnya sendiri, Anda bukan satu-satunya yang mencoba menjalankan autoneg pada apa pun yang Anda gunakan
  5. Ganti kabel, dengan Cat5e terukur atau lebih baik - idealnya kabel yang Anda tahu bekerja, seperti yang dipasang di komputer Anda. Jangan mencoba untuk menggunakan Cat5, atau beberapa omong kosong yang dibuat seseorang, gunakan salah satu yang memiliki ujung cetakan dari sebuah paket.
  6. Pindahkan port - Tempatkan server pada port yang berbeda pada switch yang sama
  7. Ubah NIC - gunakan batch berbeda yang dipesan pada waktu yang berbeda

Pada titik ini, Anda telah menghilangkan konfigurasi, port fisik yang Anda pasang, pemasangan kabel di antara mereka. Jika itu masih terjadi, beberapa penyebab lainnya mungkin:

  1. Perutean kabel - hati-hati terhadap gangguan EM dari kabel daya AC Anda, rutekan ke bawah pada sisi-sisi berbeda dari rak.
  2. Pendinginan - Pastikan suhu lingkungan Anda tidak seperti 90 derajat dan kartu NIC Anda tidak jatuh ke dalam semacam mode "my god let me just forward this one packet please". Saya pernah mendengar tetapi tidak melihat bahwa router Cisco berhenti melakukan paket fast-switching dan forward melalui CPU saat mereka sedang overheat, misalnya.
  3. Ganti saklar dengan sesuatu yang tidak menyedot - periksa berapa banyak bandwidth yang ditampung host Anda per detik secara keseluruhan, dan kemudian lihat kapasitas backplane yang dinilai dari switch Anda. 7 host dari potensi 48 semua transmisi 1.0G cukup untuk menghentikan Cisco 3750, misalnya. Juga menjadi sangat hati-hati tentang vendor jaringan murah juga-lari: D-Link, Linksys, Dell, Intel, dan HP. Tidak ada yang memperlakukan jaringan serius menggunakan orang-orang itu, dan bukan karena "tidak ada yang pernah dipecat karena menggunakan Cisco", tetapi karena "orang-orang ingat bahwa saklar Intel yang memiliki 20/48 port gagal selama 2 tahun" atau "Saya dulu menggunakan ProCurve secara eksklusif dan Tentang bagaimana jahatnya Cisco, sampai saya benar-benar menggunakan Cisco, pada titik mana saya berhenti membeli sesuatu yang kurang ". Cisco dianggap sebagai mid-range vendor jaringan, jadi apa yang memberi tahu Anda tentang orang-orang di bawah Cisco ...? :-)

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

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

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

Di beberapa tempat di mana kami mendapat handoff tembaga dari operator untuk WAN kami? Anda harus mengharapkan koneksi tembaga WAN / Internet untuk menyedot, sepanjang waktu --- sebagian karena Anda tidak tahu apa yang ada di sisi lain. Beberapa switch Extreme kuno yang memiliki firmware buggy untuk autoneg tetapi apakah MPLS memberi tag? Beberapa $ 5 media converter karena perangkat $ 200k Ciena ISP Anda terlalu keren untuk menyediakan Ethernet over twisted pair? Putuskan terlebih dahulu bagaimana hal itu akan ditangani dan patuhi itu, lalu perkirakan ada celah di dalam operator untuk mengubahnya pada jam 10 malam pada hari Sabtu karena konfigurasi yang disetujui tidak pernah didokumentasikan dan mereka memiliki beberapa kebijakan untuk diikuti.

Serius, meskipun, dapatkan handoff serat dari ISP Anda.


14
2018-01-26 12:37



Baru saja membaca ini - jawaban yang sangat baik. - Helvick
Jawaban yang bagus. - Rushino
hanya agar jawaban terakhir ada di sini, di suatu tempat, itu adalah driver Broadcom yang buruk. Kami tidak dapat menemukan set apa pun yang berhasil. Beralih ke Intel NIC memperbaikinya 100%. blog.serverfault.com/2011/03/04/broadcom-die-mutha - Jeff Atwood
@JeffAtwood Apakah itu masalah yang sama? Saya pikir yang satu ini akhirnya dilacak ke mode hemat daya pada sakelar ... - James Cape


Ini mitos jaringan. Jaringan orang-orang kami bersumpah dengan omong kosong ini, karena pada tahun 1998, switch Bay tidak akan bernegosiasi dengan Cisco atau sesuatu. Jadi daripada menggunakan default untuk 99,999% dari peralatan di bumi, kami memiliki latihan manajemen konfigurasi yang konyol dan kambing hitam besar untuk waktu-waktu di mana pembaruan driver NIC menyetel ulang pengaturan untuk dinegosiasikan secara otomatis dan apa pun yang terjadi.

Ini dibuat lebih lucu karena banyak server kami menggunakan fitur yang meragukan seperti tim NIC, yang mencegah Anda dari kehilangan akses jaringan jika terjadi kegagalan sakelar, sementara mengekspos Anda ke kegagalan perangkat lunak yang jauh lebih mungkin. (Pengemudi selalu mengisap)

Untuk mempertahankan jaringan, banyak pemakai yang menjalankan driver Windows-default NIC, yang biasanya menyedot. Jika Anda memiliki masalah dengan autonegosiasi, dan peralatan Anda tidak berlaku untuk pemerintahan Clinton, perbarui driver NIC tersebut.


10
2018-01-26 04:16



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


Anda harus bernegosiasi otomatis. Jika Anda memiliki tombol yang tidak dapat dinegosiasikan secara otomatis, beli saklar yang lebih baik.

Gigabit adalah seharusnya untuk bernegosiasi otomatis, dan itu termasuk deteksi auto-crossover (MDI-X).

100baseT adalah terjamin gagal jika salah satu ujung diatur ke otomatis dan yang lain diatur ke manual, dan itu sesuai spesifikasi. Jika Anda memaksa satu ujung ke 100 / penuh maka ujung yang lain akan bernegosiasi otomatis hingga 100 / setengah, memberi Anda ketidakcocokan dupleks.


10
2018-01-26 10:12





Biasanya saya mengatur server untuk diperbaiki karena saya telah melihat peralatan jaringan bernegosiasi menjadi 10 / setengah, bukan 1000 / penuh.

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


9
2018-01-25 19:06





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

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

Setel 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 pihak mengumumkan kemampuan dan pihak lain tidak, dan itu mungkin berarti banyak pelaksana juga tidak tahu. Beberapa akan memilih denominator umum terendah, yang 10-setengah dan yang lain akan menganggap semuanya baik-baik saja dan memilih kecepatan tercepat mungkin.

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


7
2018-01-25 20:43



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


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 itu cukup banyak prosedur standar untuk mengatur semuanya secara manual.


6
2018-01-25 19:12



Pernyataan operasi dalam jawaban ini adalah "Bertahun-tahun yang lalu." Autonegosiasi 10/100 bukanlah hal yang sama dengan autonegosiasi saat ini. - Evan Anderson
Anda benar sekali! Ini memang "bertahun-tahun yang lalu" dan sekarang dalam retrospeksi saya tidak ingat ini terjadi di mana saja dekat sering dengan salah satu peralatan gigabit, yang cukup baru pada saat itu.