Label untuk pemetaan Rute, skalabilitas generasi Label


9

Dalam router yang diaktifkan MPLS, apakah label unik dihasilkan per Awalan tujuan dalam Tabel perutean atau apakah itu per hop Berikutnya di tabel routing jika tidak keduanya, bagaimana pemetaan antara label unik dan entri tabel routing? Juga, jika sesuai awalan Tujuan, seberapa sclable itu? Sesuai pemahaman saya, nilai label maksimum adalah 2 ^ 20 = 1048576. Bagaimana jika jumlah entri tabel routing lebih besar dari 1048576?


Apakah Anda serius menyarankan Anda melihat skenario di mana seseorang mendekati 1 Juta entri LFIB, atau ini pertanyaan teoretis?
Mike Pennington

Saat ini saya bekerja dengan L3, saya telah melihat skenario pelanggan mendekati 1 juta rute (rute internet lengkap) di router Edge. Itu belum melewati angka itu. Tetapi saya telah melihat jumlah entri hampir setengah juta.
Hemanth

berapa banyak rute IGP + label RSVP-TE? Ini adalah desain yang buruk untuk mengikat label ke setiap rute internet. Anda hanya harus mengikat label ke semua BGP-hop berikutnya di tabel IGP Anda.
Mike Pennington

Mengikat Label per BGP nexthop masuk akal. Tetapi MPLS tidak memiliki pedoman umum untuk pembuatan label? Apakah tidak ada aturan umum yang mengatakan label unik harus dihasilkan per Destination-prefix atau per nexthop? atau hanya implementasi spesifik?
Hemanth

Apakah ada jawaban yang membantu Anda? jika demikian, Anda harus menerima jawabannya sehingga pertanyaan tidak terus muncul selamanya, mencari jawaban. Atau, Anda bisa memberikan dan menerima jawaban Anda sendiri.
Ron Maupin

Jawaban:


6

adalah label unik yang dihasilkan per Awalan tujuan dalam tabel routing atau apakah itu per Next-hop di tabel routing? ... saya telah melihat skenario pelanggan mendekati 1 juta rute ... Tetapi MPLS tidak memiliki pedoman umum untuk pembuatan label? Apakah tidak ada aturan umum yang mengatakan label unik harus dihasilkan per Destination-prefix atau per nexthop? atau hanya implementasi spesifik?

Tampaknya ada sedikit kebingungan. Agak tidak mungkin seseorang akan pernah ingin mengalokasikan label unik per rute internet. Jaringan MPLS yang dirancang dengan baik harus mengalokasikan label berdasarkan awalan IGP yang terikat ke BGP Anda berikutnya (ref RFC 3031, Bagian 4.6 ).

Karena itu, saya tidak begitu yakin 1 Juta label di LFIB adalah kendala desain MPLS yang serius saat ini.


Seperti rfc3031 section4.6, semua router inti akan mengalokasikan lables untuk awalan igp. Tetapi BGP akan mengalokasikan label unik untuk setiap rute (rute BGp) yang dikirimkannya ke rekan BGP. Tetapi di sini lagi BGP dapat mengiklankan ribuan rute, bukan? Apa yang akan terjadi jika jumlah rute BGP melebihi 2 ^ 20?
Hemanth

1
@Saran Anda benar, mungkin saja kehabisan label dalam skenario seperti itu (seperti RFC4364, opsi b). Apa yang akan terjadi adalah, Anda tidak dapat mengiklankan NLRI yang memerlukan label baru. Saya pikir itu agak tidak mungkin dan secara teknis selama PE far-end memiliki next-hop yang sama, untuk awalan, Anda bisa membagikan label. Karena opt-B perlu menciutkan semua IGP, label VPN menjadi satu label, sedikit lebih mudah untuk membayangkan skenario di mana ini mungkin terjadi, tetapi tampaknya tidak terlalu mungkin bagi saya.
ytti

@Saran, dalam skenario yang Anda sebutkan, itu adalah antar-AS MPLS VPN . Perutean BGP sederhana yang tampaknya Anda tanyakan dalam pertanyaan awal Anda tidak secara default mengalokasikan label untuk rute BGP. Skenario VPN MPLS apa pun dapat kehabisan label yang didistribusikan oleh VPNv4; pada saat itu Anda perlu mengelompokkan basis pelanggan Anda pada router terpisah jika Anda tidak menjalankan antar AS.
Mike Pennington

Pilihan C berskala seperti MPLS normal, seperti tumpukan [IGP, VPN] normal. Namun Opsi B hanya [label], yang akhirnya perlu memetakan di ASBR ke [IGP, VPN]. Jadi sementara di OptionC bagian VPN tidak harus unik untuk dua PE, di OptionB setiap kombinasi [IGP, VPN] harus unik di ASBR <-> tautan ASBR.
ytti

@ytti - "Saya pikir ini agak tidak mungkin dan secara teknis selama PE far-end memiliki next-hop yang sama, untuk awalan, Anda dapat membagikan label." Apakah tidak ada aturan keras bahwa Label perlu dibuat untuk setiap PRefix (awalan BGp)? Saya sangat mengerti bahwa lebih baik membagikan satu label untuk beberapa awalan, jika mereka mengikuti jalur yang sama untuk beralih. Tetapi pertanyaannya adalah, bagaimana ini diputuskan? Bagaimana router hilir mengetahui atau memutuskan rute mana untuk membagikan satu Label. Apakah ini hanya nexthop? jika banyak rute berbagi nexthop yang sama, akankah mereka hanya diberi satu label?
Hemanth

3

Skenario praktis yang tepat saat label mungkin habis masih bisa diperdebatkan. Ada beberapa masalah pemeliharaan rumah yang tidak secara langsung terkait dengan label yang habis tetapi berkontribusi pada efek itu.

Pengelola label hari ini di vendor utama (setidaknya CSCO, JNPR) diprogram sehingga mereka membutuhkan blok terus menerus per aplikasi label. Tentu saja ini bisa diperbaiki, dengan beberapa biaya dalam kinerja dan kompleksitas, tetapi tentu saja masalah lain yang perlu dipertimbangkan.

Beberapa layanan MPLS cukup haus akan ruang label pada intinya, sebagian besar tidak relevan karena kita dapat menutupinya di bawah 'label IGP' kami.
Kita perlu mengingat MPLS bukan hanya tentang IP, ini tentang FEC, jika kita perlu memberikan layanan yang berbeda / jalur dalam inti, kita perlu FEC baru.

Ada beberapa diskusi tentang mendukung label besar dan label besar , kasus penggunaannya , meskipun implementasi lebih mungkin akan melalui label tujuan khusus . Secara pribadi saya berharap / mengharapkan format kawat MPLS diubah sebelum 2 ^ 20 menjadi masalah. Karena MPLS sebagian besar hanya digunakan di dalam satu jaringan operator, mengubah format kawat sangat mudah dibandingkan dengan migrasi IPv4-> IPV6, jadi apa pun masalah yang akan kita hadapi, mengatasinya akan sangat sederhana. Beberapa masalah yang saya ingin selesaikan:

  1. Kemampuan untuk mempertahankan riwayat label dalam perjalanan
  2. Overhead byte rendah (TTL, TC berlebihan dalam label bertumpuk)
  3. Hapus kebutuhan untuk transit muatan MPLS P 'duck-typing' (rusak ECMP hari ini)
  4. Dapat diperpanjang dengan desain (label tujuan khusus memperkenalkan biaya byte besar)
  5. Ruang label meningkat
  6. Koeksistensi dengan MPLSv1
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.