About an entry in the show ip cef command output.

[speculor_cisco]

This is an example of the show ip cef command output from an Official Certification Guide:

Switch#

show ip cef

Prefix                                   Next Hop                                  Interface

0.0.0.0/32                              receive

192.168.199.0/24                 attached                                     Vlan1

192.168.199.0/32                  receive

192.168.199.1/32                  receive

192.168.199.2/32            192.168.199.2                                 Vlan1

192.168.199.255/32              receive

I have understood all entries except this one: 192.168.199.0/32     receive

As I can not imagine a router receives an IP packet with IP destination address equal to the network address, even if it is possible to

generate it and send it to the router, I has thought that the entry was useful for distinguish connected network from not connected network.

So I have done an example with the GNS simulator and found that a connected network shows this entry while a not connected network does not show it. The output in the post does not show a not connected network and so it can not confirm my simulation. It seems then possible that it can distinguish connected from not connected networks, but in my logic I would have thought to the contrary behavior. At this point, really is it present for processing a "strange" IP packet with a "strange" IP destination address equal to the network address?

Thanks.

[Giuseppe Larosa]

Hello Matteo,

your understanding is correct a receive entry appears for connected IP subnets for the base address of  the IP subnet and for the local IP address in the IP subnet.

The second entry appears logical as it represents an IP address of a L3 interface.

The reason for the receive entry for the base IP subnet address ( all 0 in host portion) may be related to the intention to provide the best possible match for a binary search.

CEF looks for the most specific entry to find out how to perform packet rewrite.

This /32 provides an anchor point in the search

see this portiion of output from a real network device:

172.20.112.0/24      attached             Vlan112

172.20.112.0/32      receive              Vlan112

172.20.112.3/32      attached             Vlan112

172.20.112.5/32      attached             Vlan112

172.20.112.17/32     attached             Vlan112

Prefix               Next Hop             Interface

172.20.112.18/32     attached             Vlan112

172.20.112.31/32     attached             Vlan112

172.20.112.38/32     receive              Vlan112

172.20.112.146/32    attached             Vlan112

172.20.112.149/32    attached             Vlan112

the 172.20.112.0/24 is actually a management subnet, the local node has address 172.20.112.38 ( see receive flag near it)

the other entries of type 172.20.112.x are actually taken from the IP ARP table of the node and have a flag of attached

the 172.20.112.0/32 does not exist in the ARP table of course

remote networks are shown  with IP next-hop and L3 outgoing interface:

172.16.128.0/22      192.168.9.234        Vlan255

                     192.168.9.238        Vlan355

sh ip arp 192.168.9.234

Protocol  Address          Age (min)  Hardware Addr   Type   Interface

Internet  192.168.9.234         180   001a.e3b7.f974  ARPA   Vlan255

Hope to help

Giuseppe

[speculor_cisco]

Hello Giuseppe and thanks for your answer.

I am not sure if I have understood the core of your answer, but please correct me if I am wrong.

You suggest that the "strange" entry is there for architectural issue in firmware design.

In other words, the algorithm the designers was working to and that would have been implemented in hardware, at same point, needed

the presence of the entry, may be as you say for binary search.

I appreciate your daring idea because it makes sense.

But why did they decide to show it in the output if it was an internal contraption?

Why did the entry necessary only for connected networks?

If a packet with that "strange" address was arrived, what would happen? A black hole?

At this point, is it possible to answer the question or only guess?

[Peter Paluch]

Giuseppe, Matteo,

I see a slightly different explanation. The IP address of the network itself is often understood in the same way as the broadcast address, i.e. pinging the network address itself will result in the packet being broadcasted to all stations within that network, the same as if the packet was addressed to the broadcast address. I even remember some Unix operating system asking during installation whether the broadcast address is the lowest or the highest IP address in the network.

Thus, in my understanding, the receive entries set to the address of the connected network with the prefix length /32 serves to deliver the packets addresses to the address of the network itself to the CPU, just as all broadcast packets would be.

That's my guess.

Best regards,

Peter

[speculor_cisco]

Hello Peter and thanks for your answer.

Your reply let me remember, even if I am not sure, that I had read something like this.

The problem was that one of the texts I am consulting said:

"A FIB entry has been reserved for the exact network address.

This is used to contain an adjacency for packets sent to the network address, if the network is not directly connected."

The previous show ip cef command output showed a connected network instead!!!

So I have begun imagining a reason for the need in the case of not connected network and I succeded, fantasy has no limits !!!

Then I try with the simulator and see that the entry was present only for connected networks!!!

Your guess would make sense because you teach me that, in this case, only connected networks would need that entry.

And so no black hole but directed broadcast, operation not possible in hardware (why? do not worry I am joking!) may be

because too much difficult for this type of implementation.

Finally, do you feel to confirm me that "is not" in that text is a stupid error?

[Peter Paluch]

Matteo,

"A FIB entry has been reserved for the exact network address.
This is used to contain an adjacency for packets sent to the network address, if the network is not directly connected."

Is that a direct, unmodified quotation? Would it be possible for me to see more of the text to understand the context? Note that this quotation does not say anything about the prefix length - it may not be the /32 which is currently the one we are discussing.

There is a so-called glean adjacency created for all stations in a directly connected network whose MAC address is not known currently. By virtue of longest-prefix match, the glean adjacency is tied to a CEF entry having the exact address of the network and its exact netmask (so not /32). Perhaps the statement you wrote referred to a glean adjacency.

It has to be stressed that an entry, say, 192.168.1.0/32 will not match any other packets than only the ones sent exactly to the destination 192.168.1.0. In other words, a /32 adjacency always needs to match the entire address and won't be used unless the packet is addressed to that exact address. A receive-type adjacency simply states that such a packet shall not be forwarded anywhere, through any physical port, just delivered to the CPU (remember that in switches, the packet routing/switching is done in hardware, independently of the CPU - CPU actually does not even know that something is happening in the switching matrix, so if a packet is to be delivered to the CPU, there must be a special adjacency for it).

Best regards,

Peter

[speculor_cisco]

Peter, here the text from Hucaby's guide:

Switch#

show ip cef

Prefix                                   Next Hop                             Interface

0.0.0.0/32                             receive

192.168.199.0/24               attached                                   Vlan1

192.168.199.0/32                 receive

192.168.199.1/32                 receive

192.168.199.2/32            192.168.199.2                            Vlan1

192.168.199.255/32             receive

On this switch, only VLAN 1 has been configured with the IP address 192.168.199.1 255.255.255.0.

Notice several things about the FIB for such a small configuration:

0.0.0.0/32—An FIB entry has been reserved for the default route. No next hop is

defined, so the entry is marked “receive” so that packets will be sent to the Layer 3

engine for further processing.

192.168.199.0/24—The subnet assigned to the VLAN 1 interface is given its own

entry. This is marked “attached” because it is connected directly to an SVI, VLAN 1.

192.168.199.0/32—An FIB entry has been reserved for the exact network address.

This is used to contain an adjacency for packets sent to the network address, if the

network is not directly connected. In this case, there is no adjacency, and the entry is

marked “receive.”

192.168.199.1/32—An entry has been reserved for the VLAN 1 SVI’s IP address.

Notice that this is a host route (/32). Packets destined for the VLAN 1 interface must

be dealt with internally, so the entry is marked “receive.”

192.168.199.2/32—This is an entry for a neighboring multilayer switch, found on

the VLAN 1 interface. The next-hop field has been filled in with the same IP address,

denoting that an adjacency is available.

192.168.199.255/32—An FIB entry has been reserved for the 192.168.199.0 subnet’s

broadcast address. The route processor (Layer 3 engine) handles all directed

broadcasts, so the entry is marked “receive.”

I would like to underline that with your guess it is ok, only it is a little strange that the author writes so different words

about the 192.168.199.0/32 and 192.168.199.255/32.

Why difficulty where not need? Was the author itself a little confused?

Thanks.

[Peter Paluch]

Hi Matteo,

I think we are being too scientific and complicated about an issue that is most probably very simple in itself.

FIrst of all, the adjacency type receive is self-explanatory: all packets handled by this adjacency are to be locally received and processed by the CPU. This is what the receive adjacency does: it hands the packets to the CPU so that they are locally received and processed. Note that the receive adjacency also means that the packets shall not be rerouted elsewhere. Simply, the packets handled by the receive adjacency are considered to be addressed to the local host.

Obviously, all IP addresses configured on a multilayer switch will be present in the CEF with the receive adjacency and with the /32 bit mask to match only the exact address configured on a SVI or on a routed port. The same goes for the broadcast IP address of each network configured on the switch: broadcast packets shall be delivered to the CPU. So, if we have two SVIs on a switch: 192.168.1.1/24 and 192.168.2.1/24, we can expect to see at least these entries in the CEF with the receive adjacency type:

192.168.1.1/32 (our own IP)

192.168.2.1/32 (our own ip)

192.168.1.255/32 (the broadcast)

192.168.2.255/32 (the broadcast)

What has confused us is that we are also seeing two another entries with the exact network numbers:

192.168.1.0/32

192.168.2.0/32

But considering the fact that the network number itself can also be used as a broadcast address, these two entries are simply of the same type like the entries for the broadcast address we have seen earlier and which have not surprised us.

The explanation as given in the book by Mr. David Hucaby does not make much sense to me. I do not want to say that the book is wrong on the subject. The fact is that I do not even comprehend the explanation as given in the book. And I happen to be quite satisfied with my own explanation of the issue

Best regards,

Peter

[speculor_cisco]

Hello Peter and thanks for your answer. I agree with you.

The last action I could do is to send an e-mail to the author.

Two weeks ago I found the address and try to send an e-mail for an other "pure" reading issue, but I have had not reply.

I would like to not disturb him. It is an hard work to accept that a text is sometimes not so understandable.

But may be the problem is mine.