[c-nsp] How to debug this?
Tuc at T-B-O-H.NET
ml at t-b-o-h.net
Thu Feb 15 22:57:57 EST 2007
>
> 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
>
Sorry.... I keep just assuming the entire world always knows what I
want to do and what my network looks like. ;)
204.107.90.128 is a FreeBSD personal server. Its gateway is 204.107.90.1 .
204.107.90.1 is a (Insert some other router company name here) that
has a ip route of 192.136.64.117 for the 192.168.3.0 subnet.
192.136.64.117 is a Cisco 3640 with an IPSEC/GRE tunnel over satellite
and NAT. Local end is 192.168.4.1, remote end is 192.168.4.2.
It has an E0/0 interface of 192.168.3.111 .
E0/0 is into a Cisco 2924, and then off that is 192.168.3.247, which is
an Axis webcam.
Unfortunately I'd guess A and B are both wrong. What the
records show are :
UDP of some sort from my server to destination make it
atleast to the far end tunnel, but it seems like its saying it
doesn't go anywhere after that (0)....
Then it says that an ICMP comes back from the device to
the local IP on the E0/0 but then it doesn't seem to go anywhere
after that. (See above)
As for the ARP, sorry. I didn't realize thats why you
were asking... From the far end :
Ethernet0/0 is up, line protocol is up
Hardware is AmdP2, address is 00b0.640f.f101 (bia 00b0.640f.f101)
Internet address is 192.168.3.111/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:06, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/40/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 1000 bits/sec, 1 packets/sec
5 minute output rate 1000 bits/sec, 1 packets/sec
935965 packets input, 108260538 bytes, 0 no buffer
Received 419712 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
828361 packets output, 87405610 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
C3640-1#sho arp | inc 247
Internet 192.168.3.247 3 0040.8c44.3bf9 ARPA Ethernet0/0
C3640-1#telnet 192.168.3.247 80
Trying 192.168.3.247, 80 ... Open
GET / HTTP/1.0
HTTP/1.0 200 OK
Date: Thu, 15 Feb 2007 22:56:10 GMT
Server: Boa/0.92o
Content-Length: 318
Last-Modified: Thu, 15 Feb 2007 22:56:10 GMT
Content-Type: text/html
<HTML>
<HEAD>
<META HTTP-EQUIV="Expires" CONTENT="Tue, 01 Jan 1980 1:00:00 GMT
">
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Cache-
Control" CONTENT="no-cache">
<META HTTP-EQUIV="Refresh" CONTENT="0; URL=/inde
x2.shtml">
<TITLE>AXIS 2120 Network Camera</TITLE>
</HEAD>
<BODY>
</BODY>
</HTML>
[Connection to 192.168.3.247 closed by foreign host]
Thanks, Tuc
More information about the cisco-nsp
mailing list