can you explain the different types of cef adjacency states - punt , glean, discard, null, drop with examples and configuration?
may be a topology example
- Null adjacency: used to send packets to the null0 interface.
- Drop adjacency: you’ll see this for packets that can’t be forwarded because of encapsulation errors, routes that cannot be resolved or protocols that are not supported.
- Discard adjacency: this is for packets that have to be discarded because of an access-list or other policy.
- Punt adjacency: used for packets that can't be forwarded by CEF. They will be "punted" to the next switching method (fast switching and process switching).
- Glean adjacency: used for directly connected routes. It's used to tell the router that it should check the ARP table since it can reach the device directly.
Thanks for the adjacency explanation
Is it true that the “glean adjacency” in the FIB utilize process switching and not CEF?
According to Cisco, it is CEF that “…requests an ARP entry for the specific prefix, ARP sends the MAC address, and the adjacency entry for the host is built.” You can find out more about it here.
I hope this has been helpful!
I’m asking this question beacuse I have a confusion about the way glean adjacency works with DMVPN Phase 2.
As I learned - the first Spokes adjacency to the hub would be “glean” and for that reason the router would create an nhrp resolution request and sends it to the HUB by utilizing process switching method
Glean adjacency is when CEF does not know all the layer 2 information (for all multiaccess endpoints) on attached subnet.
Because you are speking about DMVPN Phase 2 then from spoke point of view adjacency to hub will be Attached, because spoke immediatelly registers to hub using NHRP.
But adjacency to attached tunnel subnet will probably be Punt, not Glean, but Punt until CEF has all the required L2 information about spokes. What makes the adjacency Punt is that CEF cant simply generate ARP from one spoke to another spoke, on DMVPN there is NHRP protocol who is in charge and CEF cant generate NHRP Request by itself, it has to Punt it to process switching so CPU will generate NHRP Request itself (NHRP Request for another spoke information) and this request has to be forwarded to Hub. First traffic goes always throught the hub, when NHRP resolution is completed then traffic can go from spoke to spoke directly.
Nitay, I dont know if information presented here is actually correct, its just my guess. Im also interested how it really is, thus I will lab it up when I have some free time, probably sunday evening. I will share the results after.
Thanks you very much,
I will be realy greatfull to see all the necessary conclusion about the experiment!
After all the DMVPN PHASE 3 does makes the nhrp requests to be proccessed by the CEF (i’m not quite remember how , gotta refresh my knowledge about that).
First i have to correct myself, glean adjacency is for dirrectly conected subnets and means that CEF should look to ARP table for L2 informations. In case not all L2 informations are known then “show adjacency” shows as “(incomplete)” for this subnet, CEF is performing ARP request in regular time intervals to make all the L2 information complete.
I did the lab regarding to DMVPN and tunnel subnet. Dont want to spam CEF internals, so here are the quick results.
G0/2 is physical interface used for connection to internet, its a Glean adjacency, using subnet 18.104.22.168/30.
Spoke1# show ip cef adjacency glean Prefix Next Hop Interface 22.214.171.124/30 attached GigabitEthernet0/2
Tunnel 10.0.0.0/29 has a Punt adjacency.
Spoke1# show ip cef adjacency punt Prefix Next Hop Interface 10.0.0.0/29 attached Tunnel0
Last one is loopback 126.96.36.199 configured as /24 subnet on purpose, the /24 subnet shows as Discard adjacency.
Spoke1# show ip cef adjacency discard Prefix Next Hop Interface 188.8.131.52/24 attached Loopback0
Now to the Phase 3.
Its like command “ip nhrp shortcut” allows to process nhrp redirect, thus insert nhrp /32 route into RIB (shows as “H”) and CEF updates itself accordingly.
Thanks for your reply,
So as it seems, the DMVPN Tunnel isn’t in the glean state at all as mentioned somewhere in the internet, maybe also in some lessons in the website, but it is in the punt state and the nhrp redirect does being processed as process switching but the sum time is less than the sum time it process switching without the nhrp redirect.
the nhrp shortcut meanwhile do changes the CEF and makes the spokes to be able sending the first traffic via CEF itself, butt he HUB himself doesn’t have to be configured with the nhrp shortcut and that should make him sending the nhrp redirect as a process switching method am I right?