From: Paul Crist (pcrist@xxxxxxxxxxx)
Date: Sun Jun 03 2001 - 14:38:32 GMT-3
I tried that lab and got the same resonse. I turned off fast switching on
the serial interfaces of the ipsec routers. I still could not get the eigrp
packets between the 2 networks. I finally created a tunnel between r2 and
r4, enctrypted traffic between the source and destination of the tunnel and
everything was fine. I tried copying and pasting the solution configs from
the web site and it did not work until I created the tunnel. EIGRP must
have a problem if it is not directly attached to its neighbor, possible
hello problem. I hope this helps.
Paul Crist
----- Original Message -----
From: "Jeff K." <jeffbk@austin.rr.com>
To: <ccielab@groupstudy.com>
Sent: Sunday, June 03, 2001 1:00 PM
Subject: IPSEC
> I set up a test lab to do some basic IPSEC, using the Fatkid 393 lab for
the
> topology / addressing. Basically, couldn't get it to work.
Double-checked
> everything and it was all fine - routes, crypto statements, etc. The
> access-lists for interesting traffic were mirror-images of each other, so
no
> problem there either. I know that it was 'trying' to work by some ping
> responses. If I pinged from the peer routers without using extended to
change
> source, I would get unreachables; but, every other interface would
time-out.
> Went to debugs. The isakmp negotiation and then ipsec sa negotiation were
> agreed upon and it looked fine. On one peer, I noticed this in the debug:
>
> %IPFAST-2-PAKSTICK: Corrupted pak header for xxx, flags 0x80.
>
> I found a caveat for 12.0(11) saying this was from using fast or flow
> switching. It recommended CEF, but this is a 1600 so I just went to
process
> switching. Got rid of this one, even though I am running 12.0(8). Still
was
> not working. On the other peer (a 2502 also running 12.0(8)) I was
getting
> this error in the debug:
>
> Jun 3 11:41:53.558 CDT: ISAKMP (18): unknown error extracting ID.
>
> Couldn't find anything on this one. The debugs seemed to show traffic was
> going to the IPSEC peer, though. Went back to the other peer and did a
> detailed IP packet debug with an access-list to limit output to the
relevant
> traffic and found that the pings were being dropped as 'unroutable.' This
> means you don't have a route in place, but that was all fine. Anyway, I
tried
> telnet and it worked perfectly. No errors at all, came up very fast. Now
> ping, traceroute, everything works just fine. It just seemed like all the
> time I just couldn't start the sa with ping. Has anybody every had this
> problem or is it known that ping won't start the tunnel? I can clear the
sa
> and isakmp and reproduce this every time. Any thoughts?
>
> I didn't bother to post any configs because it is working... Here is the
ACL
> for the traffic, though, since that may be relevant:
> R1 (R2 on the lab):
> Extended IP access list IPSEC
> permit ip 10.1.0.0 0.0.255.255 10.2.0.0 0.0.255.255
> R5 (R4 on the lab):
> Extended IP access list IPSEC
> permit ip 10.2.0.0 0.0.255.255 10.1.0.0 0.0.255.255
>
> Thanks in advance and sorry if this is too lengthy,
>
> -Jeff
> **Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:31:17 GMT-3