I have had strange problems like this before, but nothing exactly like this. The hellos should be sent by each router as a keepalive method on point to point lines, as well as to verify area id, subnet mask on the interface, authentication, hello interval and so on, and you should see the state transition to FULL eventually. On a broadcast network you would see FULL/DR, FULL/BDR, or 2WAY/DROTHER. The full relationships are for the designated and backup designated routers, the 2WAY indicates that the other routers are there and OSPF is configured and functioning, but that there is no adjacency formed (on a broadcast network). See below:
Point to Point r5#sh ip ospf neigh Neighbor ID Pri State Dead Time Address Interface 10.100.1.6 1 FULL/ - 00:00:33 10.65.1.1 Serial1 Broadcast Neighbor ID Pri State Dead Time Address Interface x.x.x.x 1 2WAY/DROTHER 00:00:33 x.x.x.x Ethernet0/0 x.x.x.x 1 2WAY/DROTHER 00:00:31 x.x.x.x Ethernet0/0 x.x.x.x 1 2WAY/DROTHER 00:00:36 x.x.x.x Ethernet0/0 x.x.x.x 1 2WAY/DROTHER 00:00:36 x.x.x.x Ethernet0/0 x.x.x.x 1 2WAY/DROTHER 00:00:37 x.x.x.x Ethernet0/0 x.x.x.x 1 2WAY/DROTHER 00:00:30 x.x.x.x Ethernet0/0 x.x.x.x 1 2WAY/DROTHER 00:00:33 x.x.x.x Ethernet0/0 x.x.x.x 1 2WAY/DROTHER 00:00:35 x.x.x.x Ethernet0/0 x.x.x.x 1 2WAY/DROTHER 00:00:33 x.x.x.x Ethernet0/0 x.x.x.x 1 2WAY/DROTHER 00:00:35 x.x.x.x Ethernet0/0 x.x.x.x 1 2WAY/DROTHER 00:00:36 x.x.x.x Ethernet0/0 x.x.x.x 1 FULL/BDR 00:00:30 x.x.x.x Ethernet0/0 x.x.x.x 1 2WAY/DROTHER 00:00:36 x.x.x.x Ethernet0/0 x.x.x.x 1 FULL/DR 00:00:39 x.x.x.x Ethernet0/0 As far as your encapsulation failed problem, this usually indicates that the router knows on which interface to send the packet, but for one reason or another it cannot. On a broadcast network this would indicate an ARP problem as you stated. I have seen issues where serial and line protocol are up, but the timeslots are off by one, this causes some strange issues on some hardware. If the timeslots are off by any more than one you usually would not see the circuit up, but in some instances the line will show up up if only off by one time slot. I would also check the MTU, as another person suggested, I know from experience that mismatches cause serious problems with multicast traffic. I don't suppose you changed the MTU after you brought the line up initially? Did you try shutting it down and then bringing it back up? Can you ping the interfaces from each router? ~-----Original Message----- ~From: Fraasch James [mailto:[EMAIL PROTECTED]] ~Sent: Monday, January 14, 2002 5:46 PM ~To: [EMAIL PROTECTED] ~Subject: Encapsulation Failed [7:31916] ~ ~ ~I ran into a problem this weekend. I have a 7204 on one end ~and an IBM 6611 ~on the other of a point to point T-1. IBM requires PPP ~encapsulation. I ~debugged and got the following: ~ ~*Jan 12 02:57:19.231: IP: s=172.25.137.201 (local), ~d=224.0.0.5 (Serial3/7), ~len ~ 64, sending broad/multicast ~*Jan 12 02:57:19.231: Se3/7 PPP: Outbound ip packet dropped, ~line protocol ~not u ~p ~*Jan 12 02:57:19.231: IP: s=172.25.137.201 (local), ~d=224.0.0.5 (Serial3/7), ~len ~ 64, encapsulation failed ~*Jan 12 02:57:19.347: LSP-TUNNEL-TIMER: timer fired for Tunnel ~Head Checkup ~ ~I know one of those lines says that the line protocol is not up but I ~guarantee that it is. We were switching out an existing router ~that used ~that line just fine. ~ ~The Cisco Tech I talked to wanted to talk about reversing the bits and ~seeing what that does. That's crap. It looks to be just an ~ARP problem but ~I can fix it. Has anyone other there ran into this problem ~before, and if ~so, how did it get fixed? ~ ~This is my first post. Please dont leave me hanging. ~ ~ ~Report misconduct ~and Nondisclosure violations to [EMAIL PROTECTED] ~ Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=32046&t=31916 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
