RE: Encapsulation Failed [7:31916]
I will post an answer as soon I can come up with one. We will just have to see how good the Cisco TAC is! Thanks again for all the information. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=32176t=31916 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Encapsulation Failed [7:31916]
Well, that does make sense, now that you mention it. (OSPF sending multicast Hellos on a serial interface). OSPF uses Hellos as a keepalive, not just for establishing adjacencies. Notice, that your reply is still hard to read because we can't tell what you wrote and what I wrote. But if you're reading and writing e-mail from a Web page, I could see how that could happen. It's not a big deal. Thanks for the reply. Priscilla Priscilla, Here is how I acces this forum: http://www.groupstudy.com/form/list.php?f=7 I don't use e-mail at all because I travel too much and can't get to my account sometimes for days on end. The web interface isn't ideal, but it works. Anyway, you can see that I have to cut and paste previous text and then comment out the comments. Back to this guys problem James, You said that you knew the protocol must be up because another router had previously been working just fine on that line. However, PPP doesn't exist on the line or in the cloud. It must be successfully negotiated between the end points for layers 2 and 3 (LCPs and NCPs, respectively). A simple sh ip int b would be a good first place to start. From there you may need some more advanced debug of the ppp negotiation process (such as authentication). Scott Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=32001t=31916 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Encapsulation Failed [7:31916]
Priscilla, My apologies for the inaccuracy. Indeed, on a Serial link (point-to-point) the neighbor state does advance to FULL. Not stopping at 2-way as I had suggested. I config'd my lab quickly this morning for point-to-point, below are some snapshots: Neighbor ID Pri State Dead Time Address Interface 144.223.8.1 1 FULL/ -00:00:3910.0.0.37 Serial1 rtrB#debug ip ospf adj OSPF adjacency events debugging is on rtrB# 4d22h: OSPF: Rcv hello from 144.223.8.1 area 0 from Serial1 10.0.0.37 4d22h: OSPF: End of hello processing 4d22h: OSPF: Rcv hello from 144.223.8.1 area 0 from Serial1 10.0.0.37 4d22h: OSPF: End of hello processing rtrB#debug ip ospf packet 4d22h: OSPF: rcv. v:2 t:1 l:48 rid:144.223.8.1 aid:0.0.0.0 chk:50AC aut:0 auk: from Serial1 4d22h: OSPF: rcv. v:2 t:1 l:48 rid:144.223.8.1 aid:0.0.0.0 chk:50AC aut:0 auk: from Serial1 4d22h: OSPF: rcv. v:2 t:1 l:48 rid:144.223.8.1 The debug ip ospf packet is interesting. In this case, you get to see the pieces of the hello protocol broken up. v = VERSION t = TYPE (1 identifies this as an Hello packet) rid = ROUTER ID (I have a Loopback 0 and 1, 1's address is 144.223.8.1) aid = AREA ID (Area 0) chk = CHECKSUM aut = AUTHENTICATION (I don't have authentication configured so it's 0, null) auk = AUTHENTICATION KEY. Unfortunately I can't find a debug to tell that my Hellos are multicast rather than unicast. I guess I'll have to wait until Priscilla ponies up the $ for a WAN sniffer. :) Chris -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Monday, January 14, 2002 10:44 PM To: [EMAIL PROTECTED] Subject: RE: Encapsulation Failed [7:31916] At 10:04 PM 1/14/02, Kane, Christopher A. wrote: Yes, OSPF sends hellos on Serial interfaces. In point-to-point networks OSPF's hello is multicast. There is no DR/BDR so it's my understanding that it simply becomes a Master/Slave relationship. During the database description exchange state, the routers are in a master/slave relation. For the rest of the time, the adjacent neighbors are just friendly peers, wouldn't you say? Mindful that in OSPF a Neighbor is not the same as an Adjacency. All routers become neighbors (assuming all aspects of the Hello protocol are agreed upon) They only become Adjacent with the respective DR and BDR of the network in the case of a network on a broadcast medium. We're talking about non-broadcast WAN networks.. I'm pretty sure you only see 2-way as a neighbor state on point-to-point links rather than I should try it, but I thought 2-way was an intermediate state, regardless of the type of network. seeing Full as on a broadcast medium. I'd need someone else to chime in on point-to-multipoint as I haven't configured that lately. Chris -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Monday, January 14, 2002 8:40 PM To: [EMAIL PROTECTED] Subject: Re: Encapsulation Failed [7:31916] At 07:57 PM 1/14/02, s vermill wrote: Priscilla, May I ask what led you to believe that bridging was involved as opposed to just assuming that the source address was the Cisco router itself? Good question. The IBM 6611 does bridging for one thing. The other hint was that it was attempting to send an OSPF Hello on a serial interface. Does OSPF do that? How does it establish adjacency to a neighbor router on a WAN? On a point-to-point network, I figured it just knew who its neighbor was. On a non-broadcast, multiple-access network, such as Frame Relay, you normally configured the neighbor command. I've only seen the OSPF multicast Hellos on LANs, (but I can't afford a WAN Sniffer anymore! ;-) Gurus? Help? Thanks. Priscilla P.S. Anyone seeing this may be confused because you didn't include the original message. PLEASE, people, reply with the body of the message in the reply. We work in connectionless, stateless mode. How do you expect anyone to easily connect this to the discussion about a router failing to forward a packet on a PPP link to an IBM 6611. Hello? Just as an opportunity to learn something. Regards, Scott Priscilla Oppenheimer http://www.priscilla.com Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=32008t=31916 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Encapsulation Failed [7:31916]
You should be able to use the QUOTE button on the website to to quote the message. Please tell me if this is broken as I have been upgrading the internals of the website and may have missed a bug. Thanks! Paul - Original Message - From: s vermill To: Sent: Tuesday, January 15, 2002 10:41 AM Subject: Re: Encapsulation Failed [7:31916] Well, that does make sense, now that you mention it. (OSPF sending multicast Hellos on a serial interface). OSPF uses Hellos as a keepalive, not just for establishing adjacencies. Notice, that your reply is still hard to read because we can't tell what you wrote and what I wrote. But if you're reading and writing e-mail from a Web page, I could see how that could happen. It's not a big deal. Thanks for the reply. Priscilla Priscilla, Here is how I acces this forum: http://www.groupstudy.com/form/list.php?f=7 I don't use e-mail at all because I travel too much and can't get to my account sometimes for days on end. The web interface isn't ideal, but it works. Anyway, you can see that I have to cut and paste previous text and then comment out the comments. Back to this guys problem James, You said that you knew the protocol must be up because another router had previously been working just fine on that line. However, PPP doesn't exist on the line or in the cloud. It must be successfully negotiated between the end points for layers 2 and 3 (LCPs and NCPs, respectively). A simple sh ip int b would be a good first place to start. From there you may need some more advanced debug of the ppp negotiation process (such as authentication). Scott Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=32011t=31916 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Encapsulation Failed [7:31916]
Unfortunately I can't find a debug to tell that my Hellos are multicast rather than unicast. I guess I'll have to wait until Priscilla ponies up the $ for a WAN sniffer. :) Chris, Since you are in a lab environment, you can turn on 'debug ip packet' and see the destination address of 224.0.0.5. Of course, this doesn't tell you that what is being sent are hellos. You have to make that correlation using some of the other debugs that you mentioned. Regards, Scott Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=32012t=31916 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Encapsulation Failed [7:31916]
First, thanks for all the information. I forgot to mention that when I did a Show ip int brief I saw up and up. Next, here is some pertinent configuration information: Interface Serial 2/5 mtu 2044 ip address 172.25.x.x 255.255.255.252 encapsulation ppp ipx network B051 ipx update interval rip 300 ipx update interval sap 300 nrzi-encoding router ospf 200 log-adjacency-changes network 172.25.0.0 0.0.255.255 area 0.0.0.0 Sh ver is as follows: Version 12.0(7)XE1 IBM 6611 cisco 7204VXR (NPE225) processor with 122880K/8192K bytes of memory. R527x CPU at 262Mhz, Implementation 40, Rev 10.0, 2048KB L2 Cache 4 slot VXR midplane, Version 2.3 This router was exchanging OSPF updates with a Cisco 1601 via a different serial interface. I was also using PPP encapsulation on both interfaces there and it worked fine. Finally, I have to say that we have this configuration in another location with five serial ports connected to various IBM routers via T-1. All of the serial ports have identical configurations as the serial port listed above. Unfortunately, we are on a live network here and I cannot plug this router back into the network to look at logs. I would have to take down a courthouse and that has to be scheduled far in advance. Plus, they would not like it if I took them down to do 'testing'! Thanks again for the information and keep it coming! Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=32014t=31916 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Encapsulation Failed [7:31916]
Paul Borghese wrote: You should be able to use the QUOTE button on the website to to quote the message. Please tell me if this is broken as I have been upgrading the internals of the website and may have missed a bug. Thanks! Paul Paul, You just can't teach us newbies anything. Yes, the quote button works quite well (don't know how I didn't see it earlier) and should save us all lots of time. Thanks for what must be a lot of work to keep this thing up and running. It is a great forum! Regards, Scott Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=32017t=31916 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Encapsulation Failed [7:31916]
Fraasch James wrote: First, thanks for all the information. I forgot to mention that when I did a Show ip int brief I saw up and up. Next, here is some pertinent configuration information: Interface Serial 2/5 mtu 2044 ip address 172.25.x.x 255.255.255.252 encapsulation ppp ipx network B051 ipx update interval rip 300 ipx update interval sap 300 nrzi-encoding router ospf 200 log-adjacency-changes network 172.25.0.0 0.0.255.255 area 0.0.0.0 Sh ver is as follows: Version 12.0(7)XE1 IBM 6611 cisco 7204VXR (NPE225) processor with 122880K/8192K bytes of memory. R527x CPU at 262Mhz, Implementation 40, Rev 10.0, 2048KB L2 Cache 4 slot VXR midplane, Version 2.3 This router was exchanging OSPF updates with a Cisco 1601 via a different serial interface. I was also using PPP encapsulation on both interfaces there and it worked fine. Finally, I have to say that we have this configuration in another location with five serial ports connected to various IBM routers via T-1. All of the serial ports have identical configurations as the serial port listed above. Unfortunately, we are on a live network here and I cannot plug this router back into the network to look at logs. I would have to take down a courthouse and that has to be scheduled far in advance. Plus, they would not like it if I took them down to do 'testing'! Thanks again for the information and keep it coming! James, I don't know if this is acceptable advice in this forum, but I would seriously consider opening a case with the TAC. I say that because of your successful deployment of this setup elsewhere. It certainly doesn't look like anything too fancy or outlandish (although you don't see inverted NRZ everyday). Unfortunatley, I don't have any IBM routers laying around to play with. I would make this final point: MTU mismatch can and probably will cause your OSPF neighborship to fail. If you 'sh ip ospf neigh' you will see that they are stuck in exstart or exchange (when there is a mismatch - I am not presuming that you have one). Also, 'debug ip ospf adj' will tell you that MTU mismatch is the problem (if in fact it is). Best of luck and keep us posted. Scott Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=32024t=31916 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Encapsulation Failed [7:31916]
At 11:35 AM 1/15/02, Fraasch James wrote: First, thanks for all the information. I forgot to mention that when I did a Show ip int brief I saw up and up. Next, here is some pertinent configuration information: Interface Serial 2/5 mtu 2044 That's kind of a strange MTU. What is the other router using? The routers exchange their MTUs in their database description packets. They have to match. I guess you can't plug this router back in for testing, you said. But check again that this router's MTU isn't different from the others that are working. Also check its partner. Maybe it's different. Check out the info here, plus there's a lot more about OSPF debugging on Cisco's Tech Notes: http://www.cisco.com/warp/public/104/12.html It's just a guess. My last guess (about bridging!) was totally false, but I think I'm closer here. ;-) Also, in doing some research I found one mention of encapsulation failed meaning a hardware problem!!? That could explain it too. I have seen serial interfaces go bad on Cisco routers in some pretty weird ways. Good luck. Let us know what you find out please. It will be a good learning experience. Thanks. Priscilla ip address 172.25.x.x 255.255.255.252 encapsulation ppp ipx network B051 ipx update interval rip 300 ipx update interval sap 300 nrzi-encoding router ospf 200 log-adjacency-changes network 172.25.0.0 0.0.255.255 area 0.0.0.0 Sh ver is as follows: Version 12.0(7)XE1 IBM 6611 cisco 7204VXR (NPE225) processor with 122880K/8192K bytes of memory. R527x CPU at 262Mhz, Implementation 40, Rev 10.0, 2048KB L2 Cache 4 slot VXR midplane, Version 2.3 This router was exchanging OSPF updates with a Cisco 1601 via a different serial interface. I was also using PPP encapsulation on both interfaces there and it worked fine. Finally, I have to say that we have this configuration in another location with five serial ports connected to various IBM routers via T-1. All of the serial ports have identical configurations as the serial port listed above. Unfortunately, we are on a live network here and I cannot plug this router back into the network to look at logs. I would have to take down a courthouse and that has to be scheduled far in advance. Plus, they would not like it if I took them down to do 'testing'! Thanks again for the information and keep it coming! Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=32039t=31916 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Encapsulation Failed [7:31916]
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.61 FULL/ -00:00:3310.65.1.1 Serial1 Broadcast Neighbor ID Pri State Dead Time Address Interface x.x.x.x 1 2WAY/DROTHER00:00:33x.x.x.x Ethernet0/0 x.x.x.x 1 2WAY/DROTHER00:00:31x.x.x.x Ethernet0/0 x.x.x.x 1 2WAY/DROTHER00:00:36x.x.x.x Ethernet0/0 x.x.x.x 1 2WAY/DROTHER00:00:36x.x.x.x Ethernet0/0 x.x.x.x 1 2WAY/DROTHER00:00:37x.x.x.x Ethernet0/0 x.x.x.x 1 2WAY/DROTHER00:00:30x.x.x.x Ethernet0/0 x.x.x.x 1 2WAY/DROTHER00:00:33x.x.x.x Ethernet0/0 x.x.x.x 1 2WAY/DROTHER00:00:35x.x.x.x Ethernet0/0 x.x.x.x 1 2WAY/DROTHER00:00:33x.x.x.x Ethernet0/0 x.x.x.x 1 2WAY/DROTHER00:00:35x.x.x.x Ethernet0/0 x.x.x.x 1 2WAY/DROTHER00:00:36x.x.x.x Ethernet0/0 x.x.x.x 1 FULL/BDR00:00:30x.x.x.x Ethernet0/0 x.x.x.x 1 2WAY/DROTHER00:00:36x.x.x.x Ethernet0/0 x.x.x.x 1 FULL/DR 00:00:39x.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=7i=32046t=31916 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Encapsulation Failed [7:31916]
I just remembered that I actually have an Intel router connected to a 7513 via a T1 that comes in on an MCT3 card, and the encapsulation is PPP. The mtu is 1500 bytes, as opposed to the 2044 that is configured on yours. Just wanted to let you know. ~-Original Message- ~From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] ~Sent: Tuesday, January 15, 2002 2:01 PM ~To: [EMAIL PROTECTED] ~Subject: Re: Encapsulation Failed [7:31916] ~ ~ ~At 11:35 AM 1/15/02, Fraasch James wrote: ~First, thanks for all the information. I forgot to mention ~that when I did ~a Show ip int brief I saw up and up. Next, here is some pertinent ~configuration information: ~ ~Interface Serial 2/5 ~mtu 2044 ~ ~That's kind of a strange MTU. What is the other router using? ~The routers ~exchange their MTUs in their database description packets. They have to ~match. ~ ~I guess you can't plug this router back in for testing, you ~said. But check ~again that this router's MTU isn't different from the others that are ~working. Also check its partner. Maybe it's different. ~ ~Check out the info here, plus there's a lot more about OSPF ~debugging on ~Cisco's Tech Notes: ~ ~http://www.cisco.com/warp/public/104/12.html ~ ~It's just a guess. My last guess (about bridging!) was totally ~false, but I ~think I'm closer here. ;-) Also, in doing some research I ~found one mention ~of encapsulation failed meaning a hardware problem!!? That ~could explain ~it too. I have seen serial interfaces go bad on Cisco routers in some ~pretty weird ways. ~ ~Good luck. Let us know what you find out please. It will be a ~good learning ~experience. Thanks. ~ ~Priscilla ~ ~ ~ ~ip address 172.25.x.x 255.255.255.252 ~encapsulation ppp ~ipx network B051 ~ipx update interval rip 300 ~ipx update interval sap 300 ~nrzi-encoding ~ ~router ospf 200 ~log-adjacency-changes ~network 172.25.0.0 0.0.255.255 area 0.0.0.0 ~ ~Sh ver is as follows: ~ ~Version 12.0(7)XE1 ~ ~IBM 6611 ~ ~cisco 7204VXR (NPE225) processor with 122880K/8192K bytes of memory. ~R527x CPU at 262Mhz, Implementation 40, Rev 10.0, 2048KB L2 Cache ~4 slot VXR midplane, Version 2.3 ~ ~This router was exchanging OSPF updates with a Cisco 1601 via ~a different ~serial interface. I was also using PPP encapsulation on both ~interfaces ~there and it worked fine. ~ ~Finally, I have to say that we have this configuration in ~another location ~with five serial ports connected to various IBM routers via ~T-1. All of the ~serial ports have identical configurations as the serial port ~listed above. ~Unfortunately, we are on a live network here and I cannot ~plug this router ~back into the network to look at logs. I would have to take down a ~courthouse and that has to be scheduled far in advance. Plus, ~they would not ~like it if I took them down to do 'testing'! ~ ~Thanks again for the information and keep it coming! ~ ~ ~Priscilla Oppenheimer ~http://www.priscilla.com ~ ~ ~ ~ Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=32050t=31916 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Encapsulation Failed [7:31916]
Sent this yesterday but it doesn't seem to have come through. In response to some of the other comments on this thread, an MTU mismatch will definitely cause the OSPF neighbours to not be neighbourly :-) I have come across this when upgrading a frame relay service from standard serial (MTU 1500) to an HSSI (default MTU 4470 I think - not 1500, anyway). JMcL - Forwarded by Jenny Mcleod/NSO/CSDA on 16/01/2002 08:34 am - Jenny Mcleod 15/01/2002 03:30 pm To: [EMAIL PROTECTED] cc: Subject:RE: Encapsulation Failed [7:31916] Actually, OSPF neighbour states will become Full on point to point links. I don't have the time or playpen to double-check the state transitions at the moment, but a quick check shows Full across point to point frame relay sub-interfaces and also across leased lines. JMcL Kane, Christopher A. Sent by: [EMAIL PROTECTED] 15/01/2002 02:04 pm Please respond to Kane, Christopher A. To: [EMAIL PROTECTED] cc: Subject:RE: Encapsulation Failed [7:31916] Yes, OSPF sends hellos on Serial interfaces. In point-to-point networks OSPF's hello is multicast. There is no DR/BDR so it's my understanding that it simply becomes a Master/Slave relationship. Mindful that in OSPF a Neighbor is not the same as an Adjacency. All routers become neighbors (assuming all aspects of the Hello protocol are agreed upon) They only become Adjacent with the respective DR and BDR of the network in the case of a network on a broadcast medium. I'm pretty sure you only see 2-way as a neighbor state on point-to-point links rather than seeing Full as on a broadcast medium. I'd need someone else to chime in on point-to-multipoint as I haven't configured that lately. Chris -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Monday, January 14, 2002 8:40 PM To: [EMAIL PROTECTED] Subject: Re: Encapsulation Failed [7:31916] At 07:57 PM 1/14/02, s vermill wrote: Priscilla, May I ask what led you to believe that bridging was involved as opposed to just assuming that the source address was the Cisco router itself? Good question. The IBM 6611 does bridging for one thing. The other hint was that it was attempting to send an OSPF Hello on a serial interface. Does OSPF do that? How does it establish adjacency to a neighbor router on a WAN? On a point-to-point network, I figured it just knew who its neighbor was. On a non-broadcast, multiple-access network, such as Frame Relay, you normally configured the neighbor command. I've only seen the OSPF multicast Hellos on LANs, (but I can't afford a WAN Sniffer anymore! ;-) Gurus? Help? Thanks. Priscilla P.S. Anyone seeing this may be confused because you didn't include the original message. PLEASE, people, reply with the body of the message in the reply. We work in connectionless, stateless mode. How do you expect anyone to easily connect this to the discussion about a router failing to forward a packet on a PPP link to an IBM 6611. Hello? Just as an opportunity to learn something. Regards, Scott Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=32064t=31916 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Encapsulation Failed [7:31916]
Can we see the relevant portions of the config plus output from 'show int'? Thanks, John Fraasch James 1/14/02 3:45:41 PM 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. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=31920t=31916 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Encapsulation Failed [7:31916]
At 05:45 PM 1/14/02, Fraasch James wrote: 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 Are you doing bridging? I know the IBM 6611 can act as a bridge. A router wouldn't normally even attempt to forward this packet addressed to a multicast address. It seems like you must be running OSPF in addition to bridging, though. That's the multicast address used for OSPF Hellos. I think you'll have to send us your config and some information about the logical topology to get to the bottom of this. Priscilla *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. Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=31921t=31916 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Encapsulation Failed [7:31916]
Priscilla, May I ask what led you to believe that bridging was involved as opposed to just assuming that the source address was the Cisco router itself? Just as an opportunity to learn something. Regards, Scott Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=31924t=31916 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Encapsulation Failed [7:31916]
At 07:57 PM 1/14/02, s vermill wrote: Priscilla, May I ask what led you to believe that bridging was involved as opposed to just assuming that the source address was the Cisco router itself? Good question. The IBM 6611 does bridging for one thing. The other hint was that it was attempting to send an OSPF Hello on a serial interface. Does OSPF do that? How does it establish adjacency to a neighbor router on a WAN? On a point-to-point network, I figured it just knew who its neighbor was. On a non-broadcast, multiple-access network, such as Frame Relay, you normally configured the neighbor command. I've only seen the OSPF multicast Hellos on LANs, (but I can't afford a WAN Sniffer anymore! ;-) Gurus? Help? Thanks. Priscilla P.S. Anyone seeing this may be confused because you didn't include the original message. PLEASE, people, reply with the body of the message in the reply. We work in connectionless, stateless mode. How do you expect anyone to easily connect this to the discussion about a router failing to forward a packet on a PPP link to an IBM 6611. Hello? Just as an opportunity to learn something. Regards, Scott Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=31928t=31916 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Encapsulation Failed [7:31916]
Good question. The IBM 6611 does bridging for one thing. The other hint was that it was attempting to send an OSPF Hello on a serial interface. Does OSPF do that? How does it establish adjacency to a neighbor router on a WAN? On a point-to-point network, I figured it just knew who its neighbor was. On a non-broadcast, multiple-access network, such as Frame Relay, you normally configured the neighbor command. I've only seen the OSPF multicast Hellos on LANs, (but I can't afford a WAN Sniffer anymore! ;-) Gurus? Help? Thanks. Priscilla Priscilla, I was fairly certain that OSPF exchanges hellos on serial interfaces. I turned on OSPF on a router in my lab and then turned on debug ip packet. In deed, hellos with a destination address of 224.0.0.5 are going out all interfaces - including serial. P.S. Anyone seeing this may be confused because you didn't include the original message. PLEASE, people, reply with the body of the message in the reply. We work in connectionless, stateless mode. How do you expect anyone to easily connect this to the discussion about a router failing to forward a packet on a PPP link to an IBM 6611. Hello? I am fairly new around here. It appears that a lot of folks participate in this forum via a list. I have been doing so via the web page, so I am not familiar with what the rest of you see. Did I do it right this time? Regards, Scott Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=31934t=31916 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Encapsulation Failed [7:31916]
Good question. The IBM 6611 does bridging for one thing. The other hint was that it was attempting to send an OSPF Hello on a serial interface. Does OSPF do that? How does it establish adjacency to a neighbor router on a WAN? On a point-to-point network, I figured it just knew who its neighbor was. On a non-broadcast, multiple-access network, such as Frame Relay, you normally configured the neighbor command. I've only seen the OSPF multicast Hellos on LANs, (but I can't Sniffer anymore! ;-) Gurus? Help? Thanks. Priscilla You can also 'debug ip ospf hello' and see that hellos are coming in on the serial interfaces. That only displays incoming hellos though, so you have to match that up with your 'debug ip packets' from the other side. Scott Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=31942t=31916 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Encapsulation Failed [7:31916]
Yes, OSPF sends hellos on Serial interfaces. In point-to-point networks OSPF's hello is multicast. There is no DR/BDR so it's my understanding that it simply becomes a Master/Slave relationship. Mindful that in OSPF a Neighbor is not the same as an Adjacency. All routers become neighbors (assuming all aspects of the Hello protocol are agreed upon) They only become Adjacent with the respective DR and BDR of the network in the case of a network on a broadcast medium. I'm pretty sure you only see 2-way as a neighbor state on point-to-point links rather than seeing Full as on a broadcast medium. I'd need someone else to chime in on point-to-multipoint as I haven't configured that lately. Chris -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Monday, January 14, 2002 8:40 PM To: [EMAIL PROTECTED] Subject: Re: Encapsulation Failed [7:31916] At 07:57 PM 1/14/02, s vermill wrote: Priscilla, May I ask what led you to believe that bridging was involved as opposed to just assuming that the source address was the Cisco router itself? Good question. The IBM 6611 does bridging for one thing. The other hint was that it was attempting to send an OSPF Hello on a serial interface. Does OSPF do that? How does it establish adjacency to a neighbor router on a WAN? On a point-to-point network, I figured it just knew who its neighbor was. On a non-broadcast, multiple-access network, such as Frame Relay, you normally configured the neighbor command. I've only seen the OSPF multicast Hellos on LANs, (but I can't afford a WAN Sniffer anymore! ;-) Gurus? Help? Thanks. Priscilla P.S. Anyone seeing this may be confused because you didn't include the original message. PLEASE, people, reply with the body of the message in the reply. We work in connectionless, stateless mode. How do you expect anyone to easily connect this to the discussion about a router failing to forward a packet on a PPP link to an IBM 6611. Hello? Just as an opportunity to learn something. Regards, Scott Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=31944t=31916 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Encapsulation Failed [7:31916]
Well, that does make sense, now that you mention it. (OSPF sending multicast Hellos on a serial interface). OSPF uses Hellos as a keepalive, not just for establishing adjacencies. Notice, that your reply is still hard to read because we can't tell what you wrote and what I wrote. But if you're reading and writing e-mail from a Web page, I could see how that could happen. It's not a big deal. Thanks for the reply. Priscilla At 09:15 PM 1/14/02, s vermill wrote: Good question. The IBM 6611 does bridging for one thing. The other hint was that it was attempting to send an OSPF Hello on a serial interface. Does OSPF do that? How does it establish adjacency to a neighbor router on a WAN? On a point-to-point network, I figured it just knew who its neighbor was. On a non-broadcast, multiple-access network, such as Frame Relay, you normally configured the neighbor command. I've only seen the OSPF multicast Hellos on LANs, (but I can't afford a WAN Sniffer anymore! ;-) Gurus? Help? Thanks. Priscilla Priscilla, I was fairly certain that OSPF exchanges hellos on serial interfaces. I turned on OSPF on a router in my lab and then turned on debug ip packet. In deed, hellos with a destination address of 224.0.0.5 are going out all interfaces - including serial. P.S. Anyone seeing this may be confused because you didn't include the original message. PLEASE, people, reply with the body of the message in the reply. We work in connectionless, stateless mode. How do you expect anyone to easily connect this to the discussion about a router failing to forward a packet on a PPP link to an IBM 6611. Hello? I am fairly new around here. It appears that a lot of folks participate in this forum via a list. I have been doing so via the web page, so I am not familiar with what the rest of you see. Did I do it right this time? Regards, Scott Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=31945t=31916 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Encapsulation Failed [7:31916]
At 10:04 PM 1/14/02, Kane, Christopher A. wrote: Yes, OSPF sends hellos on Serial interfaces. In point-to-point networks OSPF's hello is multicast. There is no DR/BDR so it's my understanding that it simply becomes a Master/Slave relationship. During the database description exchange state, the routers are in a master/slave relation. For the rest of the time, the adjacent neighbors are just friendly peers, wouldn't you say? Mindful that in OSPF a Neighbor is not the same as an Adjacency. All routers become neighbors (assuming all aspects of the Hello protocol are agreed upon) They only become Adjacent with the respective DR and BDR of the network in the case of a network on a broadcast medium. We're talking about non-broadcast WAN networks.. I'm pretty sure you only see 2-way as a neighbor state on point-to-point links rather than I should try it, but I thought 2-way was an intermediate state, regardless of the type of network. seeing Full as on a broadcast medium. I'd need someone else to chime in on point-to-multipoint as I haven't configured that lately. Chris -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Monday, January 14, 2002 8:40 PM To: [EMAIL PROTECTED] Subject: Re: Encapsulation Failed [7:31916] At 07:57 PM 1/14/02, s vermill wrote: Priscilla, May I ask what led you to believe that bridging was involved as opposed to just assuming that the source address was the Cisco router itself? Good question. The IBM 6611 does bridging for one thing. The other hint was that it was attempting to send an OSPF Hello on a serial interface. Does OSPF do that? How does it establish adjacency to a neighbor router on a WAN? On a point-to-point network, I figured it just knew who its neighbor was. On a non-broadcast, multiple-access network, such as Frame Relay, you normally configured the neighbor command. I've only seen the OSPF multicast Hellos on LANs, (but I can't afford a WAN Sniffer anymore! ;-) Gurus? Help? Thanks. Priscilla P.S. Anyone seeing this may be confused because you didn't include the original message. PLEASE, people, reply with the body of the message in the reply. We work in connectionless, stateless mode. How do you expect anyone to easily connect this to the discussion about a router failing to forward a packet on a PPP link to an IBM 6611. Hello? Just as an opportunity to learn something. Regards, Scott Priscilla Oppenheimer http://www.priscilla.com Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=31949t=31916 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Encapsulation Failed [7:31916]
Actually, OSPF neighbour states will become Full on point to point links. I don't have the time or playpen to double-check the state transitions at the moment, but a quick check shows Full across point to point frame relay sub-interfaces and also across leased lines. JMcL Kane, Christopher A. Sent by: [EMAIL PROTECTED] 15/01/2002 02:04 pm Please respond to Kane, Christopher A. To: [EMAIL PROTECTED] cc: Subject:RE: Encapsulation Failed [7:31916] Yes, OSPF sends hellos on Serial interfaces. In point-to-point networks OSPF's hello is multicast. There is no DR/BDR so it's my understanding that it simply becomes a Master/Slave relationship. Mindful that in OSPF a Neighbor is not the same as an Adjacency. All routers become neighbors (assuming all aspects of the Hello protocol are agreed upon) They only become Adjacent with the respective DR and BDR of the network in the case of a network on a broadcast medium. I'm pretty sure you only see 2-way as a neighbor state on point-to-point links rather than seeing Full as on a broadcast medium. I'd need someone else to chime in on point-to-multipoint as I haven't configured that lately. Chris -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Monday, January 14, 2002 8:40 PM To: [EMAIL PROTECTED] Subject: Re: Encapsulation Failed [7:31916] At 07:57 PM 1/14/02, s vermill wrote: Priscilla, May I ask what led you to believe that bridging was involved as opposed to just assuming that the source address was the Cisco router itself? Good question. The IBM 6611 does bridging for one thing. The other hint was that it was attempting to send an OSPF Hello on a serial interface. Does OSPF do that? How does it establish adjacency to a neighbor router on a WAN? On a point-to-point network, I figured it just knew who its neighbor was. On a non-broadcast, multiple-access network, such as Frame Relay, you normally configured the neighbor command. I've only seen the OSPF multicast Hellos on LANs, (but I can't afford a WAN Sniffer anymore! ;-) Gurus? Help? Thanks. Priscilla P.S. Anyone seeing this may be confused because you didn't include the original message. PLEASE, people, reply with the body of the message in the reply. We work in connectionless, stateless mode. How do you expect anyone to easily connect this to the discussion about a router failing to forward a packet on a PPP link to an IBM 6611. Hello? Just as an opportunity to learn something. Regards, Scott Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=31954t=31916 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
