三層以太網(wǎng)交換機ip fdb表及其代碼示例
三層以太網(wǎng)交換機ip fdb表及其代碼示例，三層以太網(wǎng)交換機關于受到硬件處理流程的問題，將在下面的文字中涉及到，如何訪問列表過濾進出報文，搜集證據(jù)并聯(lián)系安全部門或機構呢？
硬件處理流程：
主要的表項是：二層MAC地址表，和三層以太網(wǎng)交換機的ip fdb表，這兩個表中用于保存轉(zhuǎn)發(fā)信息，在轉(zhuǎn)發(fā)信息比較全的情況下，報文的轉(zhuǎn)發(fā)和處理全部由硬件來完成處理，不需要軟件的干預。這兩個表的功能是獨立的，沒有相互的關系，因為一個報文只要一進入交換機，硬件就會區(qū)分出這個包是二層還是三層以太網(wǎng)交換機。非此即彼。
三層以太網(wǎng)交換機例如：display mac-address：
MAC ADDR VLAN IDSTATEPORT INDEX AGING TIME(s)
0000.21cf.73f4 1 Learned Ethernet0/19 266
0002.557c.5a791 Learned Ethernet0/12 225
0004.7673.0b381 Learned Ethernet0/9 262
0005.5d04.96481 Learned Ethernet0/16 232
0005.5df5.9f64 1 Learned Ethernet0/16 300
MAC地址表是精確匹配的IVL方式， 其中關鍵的參數(shù)是：Vlan ID, Port index。
三層以太網(wǎng)交換機例如：show ipfdb all：
0: System 1: Learned 2: UsrCfg Age 3: UsrCfg noAge Other: Error
Ip Address RtIf VTag VTValid Port Mac Status
10.11.83.77 22Invalid GigabitEthernet2/1 00-e0-fc-00-55-18 1
10.11.198.2822Invalid GigabitEthernet2/1 00-e0-fc-00-55-18 1
10.63.32.2 22Invalid GigabitEthernet2/1 00-e0-fc-00-55-18 1
10.72.255.100 22Invalid GigabitEthernet2/1 00-e0-fc-00-55-18 2
10.75.35.10322Invalid GigabitEthernet2/1 00-e0-fc-00-55-18 2
10.75.35.10622Invalid GigabitEthernet2/1 00-e0-fc-00-55-18 2
路由接口索引（RtIf）：
該索引用來確定該轉(zhuǎn)發(fā)表項位于哪個路由接口下面，對3526產(chǎn)品來講，支持的路由接口數(shù)目是32；Vlan tag: 該值用來表明所處的VLAN，該VLAN和路由接口是對應的；Vlan tag有效位（VTValid）：用來標識轉(zhuǎn)發(fā)出去的報文中是否需要插入Vlan tag標記。
端口索引（Port）：
用來說明該轉(zhuǎn)發(fā)表項的出端口；下一跳MAC：三層以太網(wǎng)交換機設備每完成一跳的轉(zhuǎn)發(fā)，會重新封裝報文中的MAC頭，硬件ASIC芯片一般依據(jù)這個域里面的數(shù)值來封裝報文頭。兩個重要的概念：
解析，未解析，每次收到報文，ASIC都會從其中提取出源和目的地址在MAC Table或者 IP Fdb Table中進行查找，如果地址在轉(zhuǎn)發(fā)表中可以找到，則認為該地址是解析的，如果找不到，則認為該地址是未解析的。
根據(jù)這個地址是源，還是目的，還可以有源解析，目的未解析等等的組合。對于二層未解析，硬件本身可以將該報文在VLAN內(nèi)廣播，但是對于三層以太網(wǎng)交換機報文地址的未解析報文硬件本身則不對該報文進行任何的處理，而產(chǎn)生CPU中斷，靠軟件來處理。
硬件部分的處理可以用這句話來描述：
收到報文后，判斷該報文是二或是三層以太網(wǎng)交換機報文，然后判斷其中的源，目的地址是否已經(jīng)解析，如果已經(jīng)解析，則硬件完成該報文的轉(zhuǎn)發(fā)，如果是未解析的情況，則產(chǎn)生CPU中斷，靠軟件來學習該未解析的地址。
驅(qū)動代碼部分：
其中關鍵的核心有：地址解析任務：在該任務中對已經(jīng)報上來的未解析的地址進行學習，以便硬件完成后續(xù)的報文的轉(zhuǎn)發(fā)而不需軟件干預。地址管理任務：為了便于軟件管理和維護，軟件部分保存了一份同硬件中轉(zhuǎn)發(fā)表相同的地址表copy。fib（forwarding information base）表: 這個表的信息來源于ip route table中的路由信息，之所以把它放在了driver部分， 是為了地址解析任務在學IP地址時查找的方便。
三層以太網(wǎng)交換機舉例：
display fib：
Destination/MaskNexthopFlag Interface
0.0.0.0/0 10.110.255.9 IVLAN-Interface2
10.110.48.0/21 10.110.48.1 D VLAN-Interface1
10.110.48.1/32 127.0.0.1 D InLoopBack0
10.110.255.8/3010.110.255.10 D VLAN-Interface2
10.110.255.10/32 127.0.0.1 D InLoopBack0
127.0.0.0/8127.0.0.1 D InLoopBack0
三層以太網(wǎng)交換機轉(zhuǎn)發(fā)主要涉及到兩個關鍵的線程：地址學習線程和報文轉(zhuǎn)發(fā)線程，這個和二層的線程是類似的；報文轉(zhuǎn)發(fā)線程主要根據(jù)地址學習線程生成的轉(zhuǎn)發(fā)表（ipfdb table）信息來對報文進行轉(zhuǎn)發(fā)，如果里面的信息足夠多，這個轉(zhuǎn)發(fā)的過程全部由硬件來完成，如果信息不夠。
則會要求地址學習線程來進行學習，同時該報文硬件不能轉(zhuǎn)發(fā)，會交給軟件協(xié)議棧來進行轉(zhuǎn)發(fā)。地址學習線程主要用來生成硬件轉(zhuǎn)發(fā)表（ipfdb table）其實ipfdb table和二層的MAC地址表也是類似的，只不過里面的具體表項所代表的含義和所起的作用不同罷了。
有一個問題：在路由器等軟件轉(zhuǎn)發(fā)引擎中，每收一個報文都會去查路由表查下一跳，然后再查ARP表找下一跳的MAC，可是在三層以太網(wǎng)交換機（如S3526）中，報文轉(zhuǎn)發(fā)的時候不需要去查路由表和ARP表，這樣的話，這兩個表是不是就沒有什么作用了？
回答當然是否定的，在S3526的三層以太網(wǎng)交換機轉(zhuǎn)發(fā)流程中，過程一般都是這樣的，第一個報文硬件無法轉(zhuǎn)發(fā)，要進行IP地址的學習，同時為了保證不丟包，該報文也由軟件來進行轉(zhuǎn)發(fā)，在學習完成以后。
第二，第三個報文以后就一直是由硬件來完成轉(zhuǎn)發(fā)了，這個過程也可以套用“一次路由，多次交換”來形象的進行總結(jié)，在一次路由中，要利用路由表和ARP表來學習IP地址，和轉(zhuǎn)發(fā)第一個報文，在以后的多次交換過程中，則只要有ipfdb table就可以了。
