[c-nsp] How to debug this?

[Bill Nash]

On Wed, 14 Feb 2007, Tuc at T-B-O-H.NET wrote:

> > Also, check your arp cache.
> > 
> 	Ok, done... But all I see is :
> 
> .Feb 14 14:40:09 EST: %SEC-6-IPACCESSLOGDP: list 123 permitted icmp 204.107.90.128 (Tunnel0 ) -> 192.168.3.247 (0/0), 41 packets 
> 
> 	Yes, I tried to ping from 204.107.90.128, yes, it was supposed
> to go through the tunnel, yes it was icmp, no there weren't 41 of them
> that I know of, only 20, and yes, the destination was 192.168.3.247,
> and yes, it should be able to be seen off the 0/0 interface. But I
> have the access list of :
> 
> access-list 123 permit ip any any log-input
> 
> 	on both tunnel0 and eth0/0, shouldn't I have seen it 
> go out the eth0/0 also?
> 
> 	Hrm, now without any more pinging I see :
> 
> .Feb 14 14:42:09 EST: %SEC-6-IPACCESSLOGP: list 123 permitted udp 204.107.90.128(0) (Tunnel0 ) -> 192.168.3.247(0), 8 packets 
> .Feb 14 14:43:09 EST: %SEC-6-IPACCESSLOGDP: list 123 permitted icmp 192.168.3.247 (Ethernet0/0 0040.8c44.3bf9) -> 192.168.3.111 (0/0), 4 packets
> 

What I'm reading/guessing from these entries, is one of two scenarios:
A: 192.168.3.0/25 is local to you, and 192.168.3.128/25 is the remote 
subnet
B: 192.168.3.0/24 is bridged over this tunnel. 

In the case of scenario A, your remote router would need to know that 
192.168.3.0/25 is on the other end of Tunnel0. From the looks of that 
second log entry (without a third showing Tunnel0), your remote server 
sent a response to it's gateway (whatever IP e0/0 has) that entered via 
e0/0 and then either vanished because you're missing a route to 
192.168.3.0/25, or wasn't recorded because your ACL is applied to a single 
direction on the Tunnel0 interface.

I don't think it's scenario B, but I've already been wrong a couple times 
today, I don't see any reason for the trend not to continue. =)

On a side note, my comment regarding your arp cache amounts to a quick 
spot check to see if the device on the other end is even live and 
responding. Seeing that second entry with an icmp response clears that up, 
though.

- billn