debug ip packet - recv

[CARLO CIANFARANI]

Hi,

In the simple Lab below all routers are running OSPF in area 0

R1----------------R2-----------------R3 (loop 192.168.0.2)

I tried successfully to ping R2 loopback (192.168.0.2) from R1 and turning on "debug ip packet detail" on R2 I can see

R2#debu ip pack det

IP packet debugging is on (detailed)

R2#

*Mar  1 00:01:41.211: IP: s=10.0.0.1 (Serial0/0), d=224.0.0.5, len 80, rcvd 0, proto=89

ì*Mar  1 00:01:47.423: IP: tableid=0, s=10.0.0.1 (Serial0/0), d=192.168.0.2 (Loopback0), routed via RIB

*Mar  1 00:01:47.427: IP: s=10.0.0.1 (Serial0/0), d=192.168.0.2, len 100, rcvd 4

*Mar  1 00:01:47.431:     ICMP type=8, code=0

*Mar  1 00:01:47.431: IP: tableid=0, s=192.168.0.2 (local), d=10.0.0.1 (Serial0/0), routed via FIB

*Mar  1 00:01:47.435: IP: s=192.168.0.2 (local), d=10.0.0.1 (Serial0/0), len 100, sending

*Mar  1 00:01:47.439:     ICMP type=0, code=0

R2#

The first message is related to the OSPF hello received by R2 from se0/0. The following 2 messages are related to the first packet ping entering in R2.

The question is: What does it means rcvd ? In the first message its value is 0 while in the second one is 4

Can someone help me ? 

[nkarpysh]

Here's what I think is the complete list of values.  Anyone please

feel free to correct or add to this:

"rcvd 0" we've decremented ttl on input.  it's now 0 but it might be for us (like OSPF MCAST which is TTL=1 from begining)

"rcvd 1" not routing this, we're passing it to bridging code. might also see this even with bridging turned off (router config'd as an endstation)

"rcvd 2" can't route the packet. final check to see if it's for us. usually packets sent to this router where debug is done.

"rcvd 3" input & output interface is the same but we can't redirect

the packet for some reason (NAT maybe?) and it's not for us

"rcvd local pkt" it came from us originally, dropping

"rcvd 4" not sure, but looks like it's for us, just not the input

interface (one of the other ones) - loopback in you case.

"rcvd 5" can't route the packet, see if it's for us before dropping

not sure but this could be failure at the output interface such as

encapsulation failure

"rcvd 6" looks like for us if we have an IP alias entry due to NAT

or something.  Should jive with "show ip alias"

"rcvd 7" goes to one of our secondary IP addresses

Hope this help.

Nik

[CARLO CIANFARANI]

Thanks Nik

Just a doubt about "rvcd 2". Can you give me any example of unroutable packet received by a router interface ? (e.g. I suppose a packet w/ local scope multicast address IP dst).  So, for instance, an EIGRP Hello sent to 224.0.0.10 (w/ TTL=2) should be traced w/ rcvd 2

However I tried to ping the R2 se0/0 (10.0.0.2) from R1 (se0/0 10.0.0.1). From "debug ip pack detail" on R2 I see

R2#

*Mar  1 00:06:52.027: IP: tableid=0, s=10.0.0.1 (Serial0/0), d=10.0.0.2 (Serial0/0), routed via RIB

*Mar  1 00:06:52.031: IP: s=10.0.0.1 (Serial0/0), d=10.0.0.2 (Serial0/0), len 100, rcvd 3 <---------------

*Mar  1 00:06:52.035: IP: tableid=0, s=10.0.0.2 (local), d=10.0.0.1 (Serial0/0), routed via FIB

*Mar  1 00:06:52.039: IP: s=10.0.0.2 (local), d=10.0.0.1 (Serial0/0), len 100, sending

Now the relevant message has rcvd 3. What do you think about ?

Thanks

[CARLO CIANFARANI]

Any idea ?

Regards

[nkarpysh]

Hi Carlo,

Thanks for your tests.

To your first question - yes passing by mcast, L3 broadcast should be recvd 2.

For the rcvd 3 example you showed - you received the packet on S0/0 and destination is also on S0/0 (seems to be configured there) from CPU logic. So number 3 above need removal of this sentence "it's not for us" I guess.

SO that is

"rcvd 3" input & output interface is the same but we can't redirect

the packet for some reason (NAT maybe?). 

SO in your case packet received on S0/0 and is for S0/0 - we can't redirect that as it is for us.

Good we have this slowly sorting out. I also did not find relevant documentation for same thus built list based on practise.

Nik,

[CARLO CIANFARANI]

Hi Nik,

Just some points for clarifying

yes - in the rcvd 3 example, ping destination address was the receiving interface ip address (S0/0 on R2). So, from your description, it seem to me that also for packets w/ dst address equal to ip address of receiving interface (S0/0 on R2 in the example) the CPU logic try to redirect the packet (for output processing ?) on the same interface code ( I may guess that at CPU level an interface is just an abstraction implemented by a specific sw code)

Does it make sense ?

Thanks in advance

[nkarpysh]

Hi Carlo,

That is what I think - don't know for sure. That list I got familiar with a long ago and we just compiled it a bit.

I guess in last case packet sent to CPU and it is debug interpritation of that packet has come on S0/0 and is for S0/0. I think CPU is handling that a bit differently but still same logic may apply.

Nik