Mengapa tabel Cisco 6509 BGP saya menggunakan dua entri di TCAM saya?


10

Saya memiliki masalah pada Cisco 6509 saya, setiap entri dalam tabel BGP saya menempati dua entri dalam TCAM. Jika saya menunjukkan penerusan kapasitas, saya melihat entri MPLS dalam sumber daya penerusan L3. Tapi, saya tidak menggunakan MPLS pada sasis saya!

#show run | i mpls
mls cef maximum-routes mpls 508
no mpls ldp advertise-labels
no mpls ip

Dan L3 Forwading saya:

L3 Forwarding Resources
             FIB TCAM usage:                     Total        Used       %Used
                  72 bits (IPv4, MPLS, EoM)     1032192      899612         87%
                 144 bits (IP mcast, IPv6)        8192           7          1%

                     detail:      Protocol                    Used       %Used
                                  IPv4                      450051         44%
                                  MPLS                      449560         44%
                                  EoM                            1          1%

                                  IPv6                           1          1%
                                  IPv4 mcast                     3          1%
                                  IPv6 mcast                     3          1%

            Adjacency usage:                     Total        Used       %Used
                                               1048576      448758         43%

Ada ide? Mungkinkah rute berada di VRF?


+1 pertanyaan menarik. Bisakah Anda menambahkan versi iOS Anda untuk perbandingan dengan jawaban Bigmstone?
jwbensley

Oups, versi iOS saya adalah s72033_rp-ADVENTERPRISEK9_WAN-M - Versi 12.2 (33) SXH3a
Johann M.

Jawaban:


10

Tampaknya 6500 menghasilkan label MPLS untuk setiap rute jika BGP dijalankan di VRF. Fakta bahwa penggunaan IPv4 dan MPLS TCAM Anda hampir identik juga menunjukkan hal ini. Bisakah Anda mencoba perintah ini:

show bgp vpnv4 uni all labels

Tampaknya ada perintah tersembunyi yang membuat iOS mengalokasikan label per VRF bukan per awalan.

mpls label mode all-vrfs protocol bgp-vpnv4 per-vrf

Ini adalah perintah tersembunyi sehingga iOS tidak akan menunjukkannya. Juga sebelum menjalankan yang dapat Anda coba jalankan:

show ip vrf detail

1
Ya, saya memiliki satu label per awalan BGP! #mpls label mode all-vrfs protocol bgp-vpnv4 per-vrf Hum bagus, tapi peringatan. Saya melihat sekarang "IPv4 VRF Aggr: 16" untuk semua awalan :) Tunggu sebentar dan ... IPv4 449979 44% MPLS 8 1% BAIK! Terima kasih :-)
Johann M.

7

Oh, 6500. Saya menjalankan jaringan penyedia layanan kecil dan menjalankan 6500 sebagai router PE. Keputusan terburuk dalam hidupku. (Itu pernyataan yang dibumbui, tetapi Anda mengerti maksud saya.)

Saya menjalankan rute BGP penuh dalam VRF dan telah mengalami banyak masalah seputar ini.

Contoh Anda tidak terlalu mengejutkan. Seperti yang dikatakan Daniel di posnya ada entri LFIB untuk setiap awalan VRF serta entri VPNv4. Ini dapat diubah dengan menambahkan perintah mpls label mode vrf Internet protocol all-afs per-vrfseperti yang dinyatakan; Namun, ini tidak membuat Anda keluar dari hutan. Jika Anda mengubah ke per awalan VRF itu menghapus entri LFIB (yay!) Tetapi menambahkan entri untuk setiap awalan tunggal ke dalam tabel Adjacency (tunggu, apa ?!). Karena perangkat penerusan 6500 dibagi antara penerusan L2 dan L3 ini tidak mengubah penggunaan memori perangkat keras Anda sama sekali. Jika ada, itu membuat masalah lebih sulit ditemukan.

Jika Anda melihat penggunaan Anda setelah Anda mengubah ke per penggunaan VRF (menggunakan show platform hardware cef resource-level) sepertinya Anda telah memperbaiki masalah. Namun jika Anda menggunakan perintah show platform hardware cef adjacencies resource-levelitu mengungkapkan masalah baru saja pindah ke lokasi yang berbeda.

Di bawah ini adalah output dari salah satu penggunaan sumber daya dan kedekatan tingkat 6500 saya. Menguraikan apa yang saya bicarakan.

Tingkat Sumber Daya

Global watermarks: apply to Fib shared area only.
Protocol watermarks: apply to protocols with non-default max-routes

Fib-size: 1024k (1048576), shared-size: 1016k (1040384), shared-usage: 458k(469769)

Global watermarks:
            Red_WM: 95%,   Greem_WM: 80%,   Current usage: 45%

Protocol watermarks:

 Protocol           Red_WM(%)      Green_WM(%)     Current(%)
 --------           ---------      ----------      ----------
 IPV4                --             --              42% (of shared)
 IPV4-MCAST          --             --              0 % (of shared)
 IPV6                --             --              2 % (of shared)
 IPV6-MCAST          --             --              0 % (of shared)
 MPLS                --             --              0 % (of shared)
 EoMPLS              --             --              0 % (of shared)
 VPLS-IPV4-MCAST     --             --              0 % (of shared)
 VPLS-IPV6-MCAST     --             --              0 % (of shared)

Penggunaan Adjacency

Watermarks apply to regions available for allocation and not pre-reserved
Stats region size for alloc:        444160
Non-stats region size for alloc:    376832

Adjacency Mgr watermarks:

 Type             Red_WM(%)      Green_WM(%)     Current usage(%)
 ----             ---------      ----------      ----------------
 Stats_WM         95%            80%             97%
 Non-Stats_WM     95%            80%             14%

Posting Ivan tentang ini didasarkan pada temuan saya di sini. Saat ini saya bekerja dengan Cisco untuk mencoba memperbaiki masalah ini, tetapi sayangnya saat ini tidak ada cara untuk memperbaikinya.

Jarak tempuh Anda mungkin bervariasi karena Anda tidak punya kedekatan MPLS. Akan tertarik untuk melihat penggunaan kedekatan Anda sekarang setelah Anda membuat perubahan.


+1 Tambahan yang bagus untuk jawaban Daniels. Saya memikirkan posting Ivan ketika saya membaca jawaban Anda, kemudian melihat Anda telah menautkannya :) Anda bilang Anda sedang mengerjakan solusi dengan Cisco, yang saya anggap sebagai kasus TAC. Bisakah Anda menambahkan ke pos Anda versi iOS Anda?
jwbensley

Komentar yang bagus! Tapi anehnya show platform hardware cef [...]tidak ada di C6509 saya. Tetapi jika saya melihat show cef fib, itu menakutkan: Totals : 96942392/97131416 ( 99%) [4296]dan ADJ: adjacency : 132616/132792 ( 99%) [4]
Johann M.

Saya SUP2T. Saya kira Anda SUP720?
bigmstone

@javno, saya percaya 15.1 (1) SY. Terlalu malas untuk VPN dengan nirkabel Bandara jelek ini. Saya akan mengonfirmasi itu dan mengedit jika perlu diubah ... tapi saya cukup yakin itulah yang saya jalankan. Ya, saya punya kasing TAC yang telah dibuka ~ 6 bulan sekarang. Bekerja dengan beberapa insinyur untuk melihat cara terbaik untuk menyelesaikannya. Saya mencoba meyakinkan mereka untuk menerapkan per label next-hop ... kita akan lihat.
bigmstone

@bigmstone: Ya, saya SUP720 (3BXL)
Johann M.
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.