L3 anahtar vs yönlendirici üzerinde CEF işlemleri

L3 anahtarlarının daha hızlı paket iletimi için CEF kullandığını biliyorum. Ancak, CEF, NAT işlemine tabi tutulması gereken paketler için çalışmaz. Bu, CEF'in kenar yönlendiricileri ve kenar L3 anahtarları tarafından kullanılmadığı anlamına mı geliyor? CEF'in kullanışlılığı LAN ile sınırlı mı?

NAT elbette CEF kullanabilir. Bu, Cisco'nun buradaki kendi rehberindendir: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_q_and_a_item09186a00800e523b.shtml

Q. What kind of routing performance can be expected when using Cisco IOS NAT?

    A. Cisco IOS NAT supports Cisco Express Forwarding switching, fast switching, and process switching. For 12.4T release and later, fast-switching path is no longer supported. For Cat6k platform, the switching order is Netflow (HW switching path), CEF, process path.

    Performance depends on several factors:

        The type of application and its type of traffic

        Whether IP addresses are embedded

        Exchange and inspection of multiple messages

        Source port required

        The number of translations

        Other applications running at the time

        The type of hardware and processor

FIB'nin hat kartlarına dağıtıldığı IOS-XR'yi çalıştıran daha büyük platformlar, aynı zamanda taşıyıcı sınıfı NAT'ı da desteklemektedir, bu nedenle faydası yalnızca LAN ile sınırlı değildir.

Ayrıca Cisco'nun L3 switch'lerinin çoğu NAT yapmıyor

CEF, Cisco'nun FIB'si için kullandığı kelimedir. L3 anahtarı size 'sh ip cef', bu bilgilerin hiçbiri aslında hiç paketleri çekmek için kullanılmasına yaptığınızda, bu sadece bir yazılımdır tray donanım ASIC doldurmak için kullanılır.

CEF, Cisco'nun optimize veri depolama / alma kodunu tanımlamak için kullandığı bir terimdir, belirli bir işlevi olan belirli bir teknoloji değildir.

Çoğu HW platformunda, HW'ye özgü bilgileri derlemek için CEF veri yapısına ihtiyaç duyulduğundan, CEF'siz kutuyu basitçe çalıştıramazsınız.
MPLS gibi bazı özellikler CEF veri yapısına da bağımlıdır ve bu yüzden onsuz çalışmayacaktır.

LAN (L2) anahtarlaması CEF üzerinden soyutlanmaz, bu nedenle CEF'e hiç bağlı değildir.

Bu kitabı CEF hakkında oldukça güncel bilgiler için tavsiye ederim (12.2S civarında büyük CEF'in yeniden yazılmasından sonra yazılmıştır).

IP Trie FIB'in CEF tanımını kısıtlarsanız, o zaman açıkça NAPT için kullanılamaz, çünkü neyin nerede bulunduğunu önceden belirleyemezsiniz. Ancak açıklandığı gibi, CEF spesifik bir teknoloji değildir, daha geniş bir konsepttir ve bu nedenle CEF'in NAT özelliği olup olmadığı tartışmalıdır.

bu.ip.fi#sh cef features global  | b Local
  Global Local features not attached to a specific interface:
     NAT
bu.ip.fi#

CEF olmadan hiçbir şey çalıştırmam ve muhtemelen sadece eski sebeplerden dolayı onu devre dışı bırakma seçeneği bile var. Juniper'i ele alalım, aynı kavramı tanımlamak için kullandıkları belirli bir terimleri yoktur, çünkü bu gibi düşük bir alternatif olmadığı için onu alternatif bir yöntemden ayırt etmeleri gerekmez.

Bu, CEF'in kenar yönlendiricileri ve kenar L3 anahtarları tarafından kullanılmadığı anlamına mı geliyor? CEF'in kullanışlılığı LAN ile sınırlı mı?

CEF, bir yönlendiricinin Katman3 iletme işlemleri sırasında Katman2 bilgilerini hızlı bir şekilde yeniden yazmasına izin verdiği için yararlıdır. WAN yönlendiricileri, tıpkı LAN anahtarları gibi Layer2 başlık bilgisini de yeniden yazmalıdır ... CEF, her iki yönlendirici türü için de son derece faydalıdır.

Yüksek seviyede CEF iki işlevi yerine getirir:

• Yönlendirilen ön eki sonraki sekmeyle eşleyen yönlendirme tablosunun bir gölge kopyasını içerir
• IP paketini birinci mermide belirtilen sonraki sıçrama boyunca yeniden yazmak için gereken Katman2 başlıkları hakkında önbelleklenmiş bilgi sağlayan bir Katman2 bitişik tabloya bir referans içerir.

Örnek:

Seri1 / 0’da WAN HDLC bağlantısı ve FastEthernet0 / 0 ... aracılığıyla LAN bağlantısı olan bu yönlendiriciyi düşünün.

R1#show adjacency internal
Protocol Interface                 Address
IP       Serial1/0                 point2point(5)
                                   0 packets, 0 bytes
                                   0F000800             <--------- HDLC Header rewrite info
                                   CEF   expires: 00:02:17
                                         refresh: 00:00:17
                                   Epoch: 0
                                   Fast adjacency disabled
                                   IP redirect enabled
                                   IP mtu 1500 (0x0)
                                   Fixup disabled
                                   Adjacency pointer 0x6663D3E0, refCount 5
                                   Connection Id 0x000000
                                   Bucket 6

192.0.2.1'e giden bir IPv4 paketinin yönlendiriciye LAN üzerindeki FastEthernet0 / 0'dan girdiğini ve WAN üzerindeki Serial1 / 0'dan çıkması gerektiğini (Serial1 / 0'dan çıkması CEF tablosunda ... ve CEF'de bulunması gerektiğini varsayalım) tablo bitişik tabloya başvuruyor).

Yönlendirici FastEthernet0 / 0 IPv4 paket aldığında, yönlendirici eternet başlığını çıkarıp öne eklemek gerekir HDLC başlığı olup, 0F000800bu IPv4 hedef (beri 0x0800Bir sonraki başlık olduğunu söylemek değer bir HDLC "türü" olarak orada IPv4).

CEF, Seri1 / 0 için (önemsiz) başlık yeniden yazma bilgisini önbelleğe almadıysa, bilgiyi manuel olarak işlem değiştirme seviyesinde (çok yavaş) aramak zorundadır. Bu bitişik tablo değerleri, Seri 1 / 0'daki enkapsülasyon değişmediği sürece değişmez; bu nedenle Cisco IOS, bitişik tablodaki bitişik yeniden yazma bilgisini önbelleğe alır.

Çerçeve rölesi veya ATM PVC'lerine baktığınızda yeniden yazma bilgileri daha da karmaşıklaşıyor.

CCO'daki bu belge (Belge Kimliği: 17812) , bir sürü CCO içeriğini yeniden şekillendirip benden daha iyi şeyler açıklayabilir.