Praktik terbaik untuk kombinasi HSRP dan ECMP

19

Kombinasi ECMP (atau penyebab lain jalur asimetris) dan HSRP rusak secara default di Cisco IOS; perilaku default dengan desain ini membanjiri lalu lintas unicast secara berlebihan.

Apa praktik terbaik untuk menggunakan HSRP dengan ECMP untuk mencegah banjir unicast yang tidak diketahui?

Detail / Latar Belakang

Kami memiliki topologi HSRP mirip dengan diagram pertama di bawah ini untuk banyak fasilitas kami. Router Cisco WAN kami memiliki rute dengan biaya yang sama ke semua situs lain; dengan demikian kita dapat melihat efek routing asimetris sepanjang waktu. Biasanya kami menetapkan R1 sebagai HSRP utama, tetapi ECMP memungkinkan lalu lintas kembali melalui R1 atau R2.

Masalahnya adalah ketika PC1 memasang drive iSCSI jarak jauh melintasi WAN, lalu lintas meninggalkan situs melalui R1, tetapi dapat kembali melalui R2. Selama lalu lintas iSCSI kembali melalui R1, tidak ada masalah.

HSRP_Broken_00

Masalahnya terjadi ketika lalu lintas PC1 kembali melalui R2. Asumsikan sesi iSCSI dimulai pukul 8:00:00, dan kedua router dan kedua sakelar mempelajari mac PC1 secara bersamaan. Antara 8:00:00 dan 8:00:05, tidak ada masalah banjir karena kedua switch masih memiliki mac-address PC1 di tabel CAM mereka.

HSRP_Broken_01

Lima menit setelah sesi iSCSI dimulai, entri CAM S2 untuk mac PC1 habis dari tabel CAM dan S2 membanjiri lalu lintas PC1 dari semua port (dalam hal ini ke Po1, Gi0 / 3 dan Gi0 / 4). Jika sesi iSCSI PC1 mengkonsumsi banyak bandwidth, banjir unicast yang tidak diketahui ini dapat menyedot kapasitas non-sepele dari tautan ke PC3 dan PC4.

Switch Cisco IOS memiliki timer CAM default 300 detik ...

S2# show mac address-table aging-time
Vlan Aging Time
---- ----------
1    300
17   300

Namun, penghitung waktu antarmuka default Cisco IOS adalah 4 jam ...

R2# show interface gi0/0
GigabitEthernet0/0 is up, line protocol is up 
  Hardware is AmdP2, address is 000a.dead.beef (bia 000a.dead.beef)
  Internet address is 172.17.1.252/24
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  ARP type: ARPA, ARP Timeout 04:00:00       <--------------

Oleh karena itu, S2 mulai membanjiri lalu lintas iSCSI PC1 setelah lima menit.

HSRP_Broken_02

— Mike Pennington
sumber

Mengapa orang terus memposting pertanyaan dan kemudian menjawabnya sendiri? Tidak seperti pada, yang dicari dan menemukan jawabannya, mereka sudah memilikinya? Ini adalah situs tanya jawab, bukan blog (bukan berarti Anda belum menulis yang baik!)

— jwbensley

8

@javano: menjawab sendiri secara eksplisit didorong oleh SE. ref meta.networkengineering.stackexchange.com/questions/4/…

— Craig Constantine

1

@CraigConstantine Ya saya tahu, tapi saya yakin orang mengirim pertanyaan dan kemudian menjawab dengan cepat, tidak beberapa waktu kemudian ketika mereka sudah menemukan jawaban untuk pertanyaan (bahkan jika hanya 5 menit kemudian), mereka menjawab dengan cepat. karena mereka sudah tahu jawabannya sebelum memposting pertanyaan. Saya menemukan ini agak aneh.

— jwbensley

6

Namun faktanya tetap, bahwa menulis Q dan jawaban langsung didorong secara eksplisit.

— Craig Constantine

4

@javano, Jika Anda memecahkan masalah yang Anda pikir orang lain akan hadapi, SE ingin lalu lintas mesin pencari untuk penyelesaian masalah itu ... mereka tidak peduli apakah saya memposting jawaban pada saat yang sama atau tidak ... pada kenyataannya, ada kotak centang kecil di bagian bawah formulir web pertanyaan untuk "Jawab pertanyaan Anda sendiri - bagikan pengetahuan Anda, Tanya Jawab"

— Mike Pennington

14

Jawaban sederhananya adalah untuk membuat timer CAM sama atau sedikit lebih lama dari timer ARP antarmuka yang sesuai , tetapi setidaknya ada tiga opsi berbeda untuk dipilih dari ...

Opsi 1: Turunkan semua ARP Timers antarmuka

Opsi ini bekerja paling baik jika Anda memiliki jaringan switch-layer2 berukuran layak, sejumlah entri ARP yang masuk akal dan beberapa antarmuka yang diarahkan. Metode ini juga lebih disukai jika Anda ingin melihat entri mac PC keluar dari topologi dengan cepat.

Pada semua antarmuka ethernet iOS yang menghadap ke switch ethernet: arp timeout 240
Pada semua antarmuka ethernet iOS yang menghadapi switch ethernet: hold-queue 200 indan hold-queue 200 outuntuk menghindari menjatuhkan paket ARP selama ARP-refresh berkala (batas-batas ini bisa lebih tinggi, atau lebih rendah tergantung pada berapa banyak refresh ARP yang Anda pikir perlu Anda tangani sekaligus). Jika Anda menyesuaikan nilai Buang Paket Selektif , maka Anda harus mengikuti pedoman dalam makalah yang saya tautkan.

Ini memaksa Cisco IOS untuk me-refresh tabel ARP dalam waktu empat menit, jika belum terjadi sebaliknya untuk entri ARP yang diberikan. Kerugian yang jelas adalah bahwa ini tidak skala dengan baik jika Anda memiliki banyak entri ARP ... batas bervariasi berdasarkan platform. Saya telah menggunakan ini dengan beberapa ratus ARP per router pada Catalyst 4500/6500 (SVI Layer3) tanpa masalah.

Opsi 2: Tambah saklar CAM Timer

Opsi ini berfungsi paling baik jika Anda memiliki banyak entri ARP (mis. Ribuan, seperti lingkungan VMWare yang intens dapat melihatnya).

Pada semua sakelar iOS :, mac address-table aging-time 14400atau mac address-table aging-time 14400 vlan <vlan-id>untuk Vlan apa pun yang menjadi perhatian.

Perubahan ini menyesuaikan timer yang dianggap kebanyakan orang diperbaiki pada 300 detik (pada Cisco IOS), jadi pastikan untuk memasukkan ini dalam dokumen kontinuitas. Efek samping dari ini adalah bahwa entri tabel CAM bertahan selama 4 jam setelah PC dihapus (yang bisa baik atau buruk, tergantung pada PoV Anda). Jika 4 jam terlalu lama, lihat opsi berikutnya ...

Opsi 3: Ubah pengatur waktu ARP antarmuka, dan sakelar Pengatur waktu CAM

Opsi ini menghindari penghitung waktu CAM yang sangat lama di Opsi 2 dengan mengorbankan lebih banyak konfigurasi. Anda dapat memilih apakah Anda membutuhkan 900 detik, 1800 detik, atau apa pun ... pastikan saja pencatat waktu CAM dan ARP Anda; dengan demikian, Anda harus mengonfigurasi Opsi 1 dan Opsi 2 di topologi Anda.

— Mike Pennington
sumber

4

Kami mengurutkan masalah ini dengan memilih solusi yang diusulkan pertama, tetapi kami tidak yakin urutan di mana IOS akan membersihkan tabel, kemudian kami menetapkan batas waktu ARP menjadi 293 (angka prima terdekat di bawah batas waktu tabel mac-address). Masih tidak tahu apakah ini pilihan yang baik atau tidak

— Marco Marzetti

1

Secara teknis Cisco IOS memecat ARP walker pada interval 60 detik sehingga Anda harus menggunakan 240 ... Saya lupa memasukkannya dalam jawaban saya ... mengeditnya di ... saya ingin tahu mengapa Anda memilih nomor utama ...

— Mike Pennington

ACK. Batas waktu ARP kurang atau sama dengan batas waktu MAC harus BCP. Bahkan tidak perlu menjadi HSRP, hanya jika ada dua router dapat menggigit Anda dan bahkan menyebabkan loop.

— ytti

Tidak tahu Jadi trik kita sama sekali tidak berguna. Kami memilih nomor utama untuk meminimalkan tumpang tindih timer.

— Marco Marzetti

4

@ MikePennington, terima kasih. Pokoknya Anda sudah benar, resolusi batas waktu ARP diterapkan dalam hitungan menit

— Marco Marzetti

1

Bagi saya, ECMP adalah masalah sebenarnya di sini - jadi selain langkah-langkah di atas untuk membatasi banjir unicast yang tidak diketahui, Anda juga dapat menyetel metrik rute ke WAN sehingga R1 lebih disukai daripada R2 untuk lalu lintas kembali. Salah satu cara untuk mencapai ini adalah melalui daftar distribusi pada R2 sebagai berikut: (EIGRP hanya digunakan misalnya, hal yang sama dapat dicapai dengan OSPF atau BGP dengan perintah lain)

!
ip awalan-daftar R1-PREFER seq 5 izin 172.17.1.0/24
!
izin rute-peta R1-PREFER-MAP 10
 cocok dengan daftar awalan ip address R1-PREFER
 setel metrik 1 1 1 1 1
... (izinkan semua rute lain)
!
router eigrp 1
 ....
 mendistribusikan-daftar rute-peta R1-PREFER-MAP keluar Ser1 / 0
 ....
!

Ini akan menghasilkan WAN meneruskan semua lalu lintas untuk 172.17.1.0 ke R1. Jika R1 Se1 / 0 gagal, rute akan diinstal ke R2. Anda dapat menyetel lebih lanjut metrik ini sehingga rute cadangan ke R2 sebenarnya merupakan penerus yang layak untuk failover yang lebih cepat. HSRP dan pelacakan akan menangani lalu lintas keluar.

— smoothbSE
sumber

pada dasarnya Anda menjawab pertanyaan yang Anda inginkan, alih-alih pertanyaan saya ... yang membutuhkan fhrp dan ecmp

— Mike Pennington

maaf soal itu - saya mulai terbiasa dengan forum ini dan melewatkan persyaratan itu!

— smoothbSE

Tidak masalah ... selamat datang di NE :)

— Mike Pennington

0

Gagasan jika tidak menggunakan ECMP jika HSRP sedang digunakan mungkin ok untuk SERVER di mana lalu lintas masuk mungkin lebih tinggi dari lalu lintas keluar, dalam situasi PC DI UMUM lalu lintas masuk dari WAN (tanggapan) lebih tinggi dari lalu lintas keluar (masuk). Kami menyukai kebanyakan orang hanya mengatur penghitung waktu ARP. Anda dapat mengacaukan dengan pengatur waktu CAM TETAPI jika Anda mengatakan sebuah MDF dengan sakelar layer 3 dan IDF dengan 2 sakelar pengumpul dan mengatakan 5 sakelar akses, ini adalah BANYAK easer untuk mengkonfigurasi pada L3 SVI daripada melakukan semua sakelar akses.

— fredpbaker
sumber

0

Orang bisa menggunakan setumpuk switch untuk mengurangi masalah entri alamat MAC yang kedaluwarsa ini di switch kedua.

— Eugene Smirnov
sumber

0

Ah, saya ingat yang ini. Berminggu-minggu yang menyenangkan telah berurusan dengan ini kembali beberapa pekerjaan yang lalu. Satu kerutan adalah bahwa peristiwa STP akan menempatkan vlan dalam mode penuaan cepat, jadi mengatur penghitung MAC lebih lama dari penghitung ARP tidak membantu

Saya memecahkan masalah ini dengan memaksa ECMP kembali dari server, dengan membuat dua gateway HSRP mengambang, dengan satu primer pada setiap router. Kami kemudian mengkonfigurasi kedua gateway di setiap host. Dengan memaksa lalu lintas host ke R1 dan R2 dengan cara ini, kami akan yakin bahwa R2 tidak akan pernah menua berdasarkan alamat MAC.

Idealnya, ini tidak akan menjadi masalah jika L2 / 3 beralih membersihkan entri ARP yang terkait dengan alamat MAC yang sudah usang. Paket selanjutnya ke IP kemudian akan menghasilkan permintaan ARP baru, mengisi kedua cache ARP dan tabel MAC. Saya pikir Cisco akhirnya menerapkan ini, tetapi saya tidak bisa mengatakan dengan pasti.

— gak
sumber

0

Ringkasan: MC-LAG atau HSRP GARP

Saya belum pernah menjadi penggemar tweaker timer. Pengatur waktu diatur dengan cara tertentu biasanya karena berbagai alasan. Mengubah mereka:

berpotensi secara operasional intensif untuk mempertahankan di mana pun sama
membuat segalanya lebih rumit dan sulit untuk dipecahkan
sebagai komentator baru-baru ini menunjukkan, dapat memiliki efek samping yang tidak terduga
mungkin tidak "bermain baik" dengan perangkat tambahan Cisco di masa depan

Bergantian:

Gunakan MC-LAG (alias "MEC" dalam dokumentasi Cisco). Ini adalah pilihan terbaik Anda, meskipun Anda harus memahami skenario penempatan di mana MC-LAG dapat digunakan (ini bukan solusi universal, dan hanya akan digunakan setelah penelitian dan pengujian yang sesuai). Varian MC-LAG tergantung pada perangkat keras. Contohnya adalah:

Sebuah. Susun (Kucing 3k)

b. VSS (Cat4k / 6k)

c. VPC (Nexus)

d. Pseudo mLACP (ASR1k)

e. MC-LAG (ASR9k)

f. Clustering (ASA)
Aktifkan HSRP untuk secara berkala mengirim paket ARP serampangan . Memang, ini mirip dengan mengubah timer, tapi ini adalah perubahan yang jauh lebih anggun daripada memanipulasi tabel CAM dan timer ARP. (Namun perlu dicatat bahwa ini tergantung pada kombinasi perangkat keras dan perangkat lunak Anda, tidak semua implementasi HSRP menawarkan ini.)

Secara default, HSRP mengirim 3 GARP, pada 0, 2, dan 4 detik setelah router menjadi gateway penerusan. Namun, ada parameter konfigurasi yang memungkinkan Anda memilih jumlah GARP (termasuk "tak terbatas") dan intervalnya.

Saya menggunakan MC-LAG cukup luas, terutama VSS, VPC, dan Clustering (Saya bukan penggemar susun).

Di mana saya tidak dapat menggunakan MC-LAG atau GLBP, ini adalah apa yang saya terapkan pada router batas L2 / L3 kampus saya (saya memiliki kampus 350-gedung jadi saya menggunakan Cat6k dengan cukup berat):

Cat6k-v15(config)#interface vlan 100
Cat6k-v15(config-if)#standby arp ?
  gratuitous  Setup gratuitous ARP interval and count

Cat6k-v15(config-if)#standby arp gratuitous ?
  count     Set HSRP gratuitous ARP count
  interval  Set HSRP gratuitous ARP interval
  <cr>

Cat6k-v15(config-if)#standby arp gratuitous count ?
  <0-60>  Number of gratuitous ARPs to send after group is activated (0 for continuous)

Cat6k-v15(config-if)#standby arp gratuitous count 0 ?
  count     Set HSRP gratuitous ARP count
  interval  Set HSRP gratuitous ARP interval
  <cr>

Cat6k-v15(config-if)#standby arp gratuitous count 0 interval ?
  <3-1800>  Gratuitous ARP Interval (sec)

Cat6k-v15(config-if)#standby arp gratuitous count 0 interval 60 ?
  count     Set HSRP gratuitous ARP count
  interval  Set HSRP gratuitous ARP interval
  <cr>

Cat6k-v15(config-if)#standby arp gratuitous count 0 interval 60

(Saya akan memposting referensi untuk semua ini, tetapi saya tidak memiliki "reputasi" yang cukup tinggi di situs ini untuk mengirim lebih dari dua URL.)

— Weylin Piegorsch
sumber

Apa yang Anda panggil MC-LAG tentu saja merupakan pilihan, tetapi ketersediaannya pada platform iOS klasik sangat sulit. Saya juga kehilangan bagaimana HSRP Gratuitous ARP membantu menyelesaikan masalah ini. Dengan menggunakan contoh dalam pertanyaan saya, dapatkah Anda menguraikan bagaimana HSRP Gratuitous ARP memecahkan batas waktu entri ARP dari 172.17.1.1? Perhatikan bahwa GW default adalah 172.17.1.254

— Mike Pennington

Jawaban panjang, jadi izinkan saya memecah ini menjadi dua bagian. Bagian 1 ... Masalah dengan HSRP adalah bahwa router merespons permintaan ARP dengan MAC virtual. Namun, ketika router meneruskan datagram ke host, ia menggunakan alamat MAC fisik . Switch menghapus tabel penerusannya dengan cukup cepat (sering 300 detik, atau 5 menit), tetapi entri ARP sering bertahan lebih lama dari itu (8 jam biasa).

— Weylin Piegorsch

Bagian 2 ... Setelah sakelar time-out alamat MAC virtual dari tabel penerusan, lalu lintas dari server ke MAC virtual menjadi "unicast tidak dikenal", di mana sakelar default ke perilaku seperti hub dan membanjiri lalu lintas semua port. Dengan mengirim GARP secara berkala, router memperbarui tabel penerusan sakelar. Selain itu, dengan mengirimkan GARP, tabel ARP di server diperbarui, sehingga tidak perlu mengirim kueri ARP.

— Weylin Piegorsch

Sekunder jawaban 2-bagian saya, saya baru menyadari pertanyaannya adalah bertanya dari arah yang berlawanan: alamat MAC server memerah dari switch, bukan MAC virtual router. Kami memiliki masalah khusus ini dan akhirnya menyelesaikannya pada awalnya melalui MC-LAG (khusus VPC), dan kemudian karena kami sudah menggunakan Nexus, kami beralih ke FabricPath alias TRILL, yang membuat masalah hilang. Namun, keduanya bergantung pada perangkat keras dan topologi.

— Weylin Piegorsch

Saya baru menyadari komentar asli saya valid - tetapi sayangnya tidak lengkap. Bukan hanya MC-LAG, tetapi MC-LAG di kedua lapisan. Kemudian Anda berhadapan dengan tabel CAM bersama di level switch dan level router.

— Weylin Piegorsch

0

Saya baru menyadari komentar asli saya valid - tetapi sayangnya tidak lengkap. Rekomendasi desain vendor netral adalah untuk membangun segitiga, bukan persegi panjang. Begitu:

Bukan hanya MC-LAG, tetapi MC-LAG di kedua lapisan. Kemudian Anda berhadapan dengan tabel CAM bersama di level switch dan level router.
Jika Anda tidak bisa melakukan itu, MC-LAG baik router atau switch, dan MC-LAG ke lapisan lain dengan tautan tambahan (yaitu full-mesh antara router dan switch). STP akan memastikan topologi bebas loop.
Jika Anda tidak bisa melakukan itu, tetap penuh dengan router dan switch. STP akan memastikan topologi bebas loop, dan tabel CAM switch masih akan mengetahui semua aturan penerusan MAC yang sesuai. Server akan selalu mengirimkan MAC-nya, dan jika Anda mengkonfigurasi HSRP GARP pada interval 1 menit, sakelar juga tidak akan melupakan HSRP vMAC.

Opsi yang diinginkan ada dalam urutan itu. Tapi paling tidak, pasang sepasang tautan ekstra itu.

— Weylin Piegorsch
sumber