relation between kernel FIB and hardware FIB

Hello

This is more a genric question on the implementation of routers. Does a software in the control plane (let's consider RIP, OSPF or BGP protocols) have to install routing entries in both kernel and underlying hardware (given that the hardware is capable to maintain its FIB), or in such case the kernel doesn't need to have a routing table and the routing table is constructed and maintained entirely by the control plane routing prototols ?

Thanks.

Mark

Reply to
Mark
Loading thread data ...

Usually they each maintain separate tables. Each routing protocol typically needs to maintain its own state, because they operate independently -- a RIP route shouldn't normally be advertised via BGP. The hardware FIB is created by merging all the information from the different protocols.

Also, the memory for the hardware FIB is usually limited, so you just want the minimal forwarding information. But routing protocols need to maintain state, sometimes quite a bit of it (e.g. the AS path in BGP).

Reply to
Barry Margolin

Thanks for the reply. To be more specific -- a routing protocol maintains its state and RIB table should reflect the RIB information down to the kernel or/and hardware; so my question is -- should it be done on both kernel and hardware, i.e. FIB in the hardware, or only FIB in hardware? (By the hardware let's consider L3 switch, or network processor). Obviously if we have a generic x86 machine with NICs and OS Linux, then the only FIB we update is the kernel's FIB, but what if we have Linux and user-level applications implementing routing protocols, and underlying network processor capable of maintaining its own FIB tables?

Mark

Reply to
Mark

If you're implementing a router, you can do whatever you want. The main benefit of keeping a copy of the FIB in the kernel is that it doesn't have to interrupt the hardware if an application asks to view the FIB.

Reply to
Barry Margolin

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.