Hi Wajih,
So, can we say that all packets because of glean state are cef punt. I understand that there could be other reasons for punt but CEF glean state will definitely mark all these packets as punt ?
I would personally agree. In CEF parlance, "punting" a packet means pushing it to the next slower switching path as CEF is not capable of handling the forwarding of that packet alone. Glean adjacencies represent directly attached networks (I will explain later) and if a packet hits a glean adjacency, an ARP request needs to be generated for the packet's destination. Clearly, this is not really forwarding a packet, rather doing some resolution work to be added to CEF so that in the future, the packet can be forwarded directly. Therefore, handling a packet by a glean adjacency means punting it.
It is somewhat confusing that the show ip cef adjacency punt does not show the glean adjacencies as also being considered as punt adjacencies. To be quite honest, I haven't seen true punt adjacencies myself yet. Ivan Pepelnjak shows that on a serial interface with X.25 encapsulation, the attached network is handled by a punt adjacency, presumably because X.25 was not added to the CEF switching path and so sending packets over X.25 links has to be handled differently:
http://blog.ipspace.net/2007/01/cef-punt-adjancency.html
Second, L3 engine will update FIB as soon as a route is learn and generally it should come with L2 address ( as some other router will be sending the update). If I am right then what cause L2 address to vanish from adjacency tables and cause Glean state?
It is not about L2 addresses vanishing from adjacency tables. There is a different reasoning.
If you think about the way CEF works, it should be fairly obvious that CEF significantly accelerates routing of IP packets to remote networks: You find the destination network for the packet in the FIB quickly, and the pointer from the FIB points right into the adjacency table where the frame header for the next hop is already preconstructed. However, if a router receives a packet whose destination is one of the directly attached Ethernet networks of the router, the best matching entry (the longest prefix match) in the FIB would be just the prefix of the attached network itself. This prefix by itself does not tell anything more beyond stating the obvious that the network is attached to a particular Ethernet interface. However, CEF cannot point this FIB entry to any particular adjacency table entry because this FIB entry represents the whole network, not a particular node in it.
So what CEF does it install a glean adjacency for this FIB entry that represents the whole network. Packets hitting a glean adjacency will cause the router to perform an ARP lookup for the packet's destination, and when an ARP response arrives, the router will install a new /32 entry just for this directly connected host into the FIB and point it toward the adjacency table entry for this particular host. Further packets for this host will hit the /32 entry in the FIB and will thus be natively CEF switched (remember - the longest prefix match still applies), while packets to other destinations in the same directly attached network that haven't yet been spoken to will continue hitting the glean adjacency, hopefully causing the router to add more and more /32 entries to the CEF for them. This is how the glean adjacencies are created and used - they simply represent directly attached networks and all hosts in them they have not been spoken to yet.
This is the moment when the FIB contents start diverging from the contents of the routing table. Under normal circumstances, a routing table would never be populated with IP addresses of individual hosts in directly attached networks because that is largely unnecessary for the basic routing. For a routing table, it is entirely sufficient to have a directly connected network entry describing the network prefix of all hosts in that network, and an information about the interface to which the network is attached. However, CEF tries to accelerate the delivery of all packets, both to remote destinations over directly attached next hops, and to local destinations in directly attached networks. Now, for remote destinations, the next hop addresses are known from the routing table so CEF has enough information to construct a frame rewrite information in the adjacency table and point the appropriate FIB entry to it. However, for directly attached networks and stations in them, the starting knowledge is just the knowledge about the directly attached networks themselves. End hosts in these directly attached networks are, so to say, their own next hops (a next hop for a directly attached destination is that destination itself), but the routing table does not even tell CEF if such hosts exist at all. So the way of handling this is having a glean adjacency for each directly attached network and its network prefix, and in addition, populating the FIB with /32 (or in IPv6, /128) entries as individual stations in these directly connected networks are spoken to and discovered.
It is noteworthy to mention that glean adjacencies are interesting only for multi-access network types on which there is a mechanism of performing a dynamic Layer3-to-Layer2 mapping, such as Ethernet. Glean adjacencies are not installed for networks on point-to-point links such as HDLC, PPP, or tunnels. Also, multi-access technologies without dynamic Layer3-to-Layer2 mapping mechanisms, such as Frame Relay, are not eligible for glean adjacencies because there is no mechanism in these networks that would map a known Layer3 information to an unknown Layer2 information on demand (while Frame Relay has its InverseARP, that one works in the opposite direction and so it is not interesting to CEF).
Please feel free to welcome further.
Rick, I hope I haven't stolen your thread - I sincerely apologize if that happened!
Best regards,
Peter
