- Topics
- Network Infrastructure
- Security
- Collaboration, Voice and Video
- Wireless - Mobility
- Small Business Support Community
- International Zone
- Small Business FAQ
- Small Business Online Device Emulators
- OnPlus Service
- Small Business Security
- Voice Systems
- Small Business Support Community
- Jabber Video Support
- Small Business Network and Smart Storage
- Online Chat Support
- FindIT Network Management Discussions
- Non-Product Related Small Business Technical Questions
- Small Business Routers
- Small Business Smart Tips
- Small Business Wireless
- WebEx Telepresence
- Small Business Support Service
- Small Business Switches
- Small Business Surveillance
- Regional Service & Support Options
- ATAs, Gateways and Accessories
- Small Business Voice and Conferencing
- Data Center
- Service Providers
- Services
- Solutions and Architectures
- Experts
- Events
- Cisco Support Community
- :
- About dnickich
turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Member since
03-18-2003
08-18-2017
dnickich
Community Member
7
Posts
0
Helpful
0
Solutions
Created by
dnickich
in Other Network Infrastructure Subjects
07-11-2003
10:04 AM
07-11-2003
10:04 AM
I have looked at that page before I started this conversation but as I said at the very start I have a connection that is up and running on this interface. BUT when I do a debug I see that my router is sending "LCP: O CONFREQ" As if it were trying to start a connection. I can not understand why there is LCP: O CONFREQ packets being sent when the router has negotiated a PPP session on this interface successfully once already. The interface is up and up and passing traffic fine. I came across this when I was looking for debug info on a PPP negotiation problem on another interface on this router.
... View more
Created by
dnickich
in Other Network Infrastructure Subjects
07-09-2003
09:34 AM
07-09-2003
09:34 AM
Thank you for your reply. That is what the doc's on the Cisco site say but that is not what I am seeing. In this negotiation that completes successfully the Magic # and the ID are the same on ID 35. I then captured negotiation that worked. If I am reading this correctly. After ID 35 the LCP state is Open and so on until the route is added. Jul 7 10:01:32 kputel-gw.kpunet.net 261271: Jul 7 10:01:31.691 ADT: Se2/1:0 LCP: State is Listen Jul 7 10:01:33 kputel-gw.kpunet.net 261273: Jul 7 10:01:32.619 ADT: Se2/1:0 PPP: Using default call direction Jul 7 10:01:33 kputel-gw.kpunet.net 261274: Jul 7 10:01:32.619 ADT: Se2/1:0 PPP: Treating connection as a dedicated line Jul 7 10:01:33 kputel-gw.kpunet.net 261275: Jul 7 10:01:32.619 ADT: Se2/1:0 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load] Jul 7 10:01:33 kputel-gw.kpunet.net 261276: Jul 7 10:01:32.619 ADT: Se2/1:0 LCP: O CONFREQ [Closed] id 30 len 10 Jul 7 10:01:33 kputel-gw.kpunet.net 261277: Jul 7 10:01:32.619 ADT: Se2/1:0 LCP: MagicNumber 0x67B959F9 (0x050667B959F9) Jul 7 10:01:35 kputel-gw.kpunet.net 261278: Jul 7 10:01:34.619 ADT: Se2/1:0 LCP: TIMEout: State REQsent Jul 7 10:01:35 kputel-gw.kpunet.net 261279: Jul 7 10:01:34.619 ADT: Se2/1:0 LCP: O CONFREQ [REQsent] id 31 len 10 Jul 7 10:01:35 kputel-gw.kpunet.net 261280: Jul 7 10:01:34.619 ADT: Se2/1:0 LCP: MagicNumber 0x67B959F9 (0x050667B959F9) Jul 7 10:01:37 kputel-gw.kpunet.net 261281: Jul 7 10:01:36.619 ADT: Se2/1:0 LCP: TIMEout: State REQsent Jul 7 10:01:37 kputel-gw.kpunet.net 261282: Jul 7 10:01:36.619 ADT: Se2/1:0 LCP: O CONFREQ [REQsent] id 32 len 10 Jul 7 10:01:37 kputel-gw.kpunet.net 261283: Jul 7 10:01:36.619 ADT: Se2/1:0 LCP: MagicNumber 0x67B959F9 (0x050667B959F9) Jul 7 10:01:39 kputel-gw.kpunet.net 261284: Jul 7 10:01:38.619 ADT: Se2/1:0 LCP: TIMEout: State REQsent Jul 7 10:01:39 kputel-gw.kpunet.net 261285: Jul 7 10:01:38.619 ADT: Se2/1:0 LCP: O CONFREQ [REQsent] id 33 len 10 Jul 7 10:01:39 kputel-gw.kpunet.net 261286: Jul 7 10:01:38.619 ADT: Se2/1:0 LCP: MagicNumber 0x67B959F9 (0x050667B959F9) Jul 7 10:01:41 kputel-gw.kpunet.net 261287: Jul 7 10:01:40.619 ADT: Se2/1:0 LCP: TIMEout: State REQsent Jul 7 10:01:41 kputel-gw.kpunet.net 261288: Jul 7 10:01:40.619 ADT: Se2/1:0 LCP: O CONFREQ [REQsent] id 34 len 10 Jul 7 10:01:41 kputel-gw.kpunet.net 261289: Jul 7 10:01:40.619 ADT: Se2/1:0 LCP: MagicNumber 0x67B959F9 (0x050667B959F9) Jul 7 10:01:41 kputel-gw.kpunet.net 261290: Jul 7 10:01:41.607 ADT: Se2/1:0 LCP: I CONFREQ [REQsent] id 1 len 10 Jul 7 10:01:41 kputel-gw.kpunet.net 261291: Jul 7 10:01:41.607 ADT: Se2/1:0 LCP: MagicNumber 0x0BFF77B0 (0x05060BFF77B0) Jul 7 10:01:41 kputel-gw.kpunet.net 261292: Jul 7 10:01:41.607 ADT: Se2/1:0 LCP: O CONFACK [REQsent] id 1 len 10 Jul 7 10:01:41 kputel-gw.kpunet.net 261293: Jul 7 10:01:41.607 ADT: Se2/1:0 LCP: MagicNumber 0x0BFF77B0 (0x05060BFF77B0) Jul 7 10:01:43 kputel-gw.kpunet.net 261294: Jul 7 10:01:42.619 ADT: Se2/1:0 LCP: TIMEout: State ACKsent Jul 7 10:01:43 kputel-gw.kpunet.net 261295: Jul 7 10:01:42.619 ADT: Se2/1:0 LCP: O CONFREQ [ACKsent] id 35 len 10 Jul 7 10:01:43 kputel-gw.kpunet.net 261296: Jul 7 10:01:42.619 ADT: Se2/1:0 LCP: MagicNumber 0x67B959F9 (0x050667B959F9) Jul 7 10:01:43 kputel-gw.kpunet.net 261297: Jul 7 10:01:43.659 ADT: Se2/1:0 LCP: I CONFACK [ACKsent] id 35 len 10 Jul 7 10:01:43 kputel-gw.kpunet.net 261298: Jul 7 10:01:43.659 ADT: Se2/1:0 LCP: MagicNumber 0x67B959F9 (0x050667B959F9) Jul 7 10:01:43 kputel-gw.kpunet.net 261299: Jul 7 10:01:43.659 ADT: Se2/1:0 LCP: State is Open Jul 7 10:01:43 kputel-gw.kpunet.net 261300: Jul 7 10:01:43.659 ADT: Se2/1:0 PPP: Phase is UP [0 sess, 1 load] Jul 7 10:01:43 kputel-gw.kpunet.net 261301: Jul 7 10:01:43.663 ADT: Se2/1:0 IPCP: O CONFREQ [Closed] id 5 len 10 Jul 7 10:01:43 kputel-gw.kpunet.net 261302: Jul 7 10:01:43.663 ADT: Se2/1:0 IPCP: Address 64.114.232.169 (0x03064072E8A9) Jul 7 10:01:43 kputel-gw.kpunet.net 261303: Jul 7 10:01:43.663 ADT: Se2/1:0 IPCP: I CONFREQ [REQsent] id 1 len 10 Jul 7 10:01:43 kputel-gw.kpunet.net 261304: Jul 7 10:01:43.663 ADT: Se2/1:0 IPCP: Address 64.114.232.170 (0x03064072E8AA) Jul 7 10:01:43 kputel-gw.kpunet.net 261305: Jul 7 10:01:43.663 ADT: Se2/1:0 IPCP: O CONFACK [REQsent] id 1 len 10 Jul 7 10:01:44 kputel-gw.kpunet.net 261306: Jul 7 10:01:43.667 ADT: Se2/1:0 IPCP: Address 64.114.232.170 (0x03064072E8AA) Jul 7 10:01:44 kputel-gw.kpunet.net 261307: Jul 7 10:01:43.667 ADT: Se2/1:0 CDPCP: I CONFREQ [Not negotiated] id 1 len 4 Jul 7 10:01:44 kputel-gw.kpunet.net 261308: Jul 7 10:01:43.667 ADT: Se2/1:0 LCP: O PROTREJ [Open] id 36 len 10 protocol CDPCP (0x820701010004) Jul 7 10:01:44 kputel-gw.kpunet.net 261309: Jul 7 10:01:43.667 ADT: Se2/1:0 IPCP: I CONFACK [ACKsent] id 5 len 10 Jul 7 10:01:44 kputel-gw.kpunet.net 261310: Jul 7 10:01:43.667 ADT: Se2/1:0 IPCP: Address 64.114.232.169 (0x03064072E8A9) Jul 7 10:01:44 kputel-gw.kpunet.net 261311: Jul 7 10:01:43.671 ADT: Se2/1:0 IPCP: State is Open Jul 7 10:01:44 kputel-gw.kpunet.net 261312: Jul 7 10:01:43.675 ADT: Se2/1:0 IPCP: Install route to 64.114.232.170 Is there a trigger number of these matching Magic number and ID packets that it takes to tel the interface that it is looped? BTW I am the telephone company.
... View more
Created by
dnickich
in Other Network Infrastructure Subjects
07-07-2003
02:00 PM
07-07-2003
02:00 PM
I have an PPP connection up on this intergface. I find what looks like a second session trying to start on this interface. How do I stop this second PPP req? Jul 7 13:37:13.872 ADT: Se2/1:0 LCP: O CONFREQ [REQsent] id 253 len 10 Jul 7 13:37:13.872 ADT: Se2/1:0 LCP: MagicNumber 0x687EBC03 (0x0506687EBC03) Jul 7 13:37:15.872 ADT: Se2/1:0 LCP: TIMEout: State REQsent Jul 7 13:37:15.872 ADT: Se2/1:0 LCP: O CONFREQ [REQsent] id 254 len 10 Jul 7 13:37:15.872 ADT: Se2/1:0 LCP: MagicNumber 0x687EBC03 (0x0506687EBC03) Jul 7 13:37:17.872 ADT: Se2/1:0 LCP: TIMEout: State REQsent Jul 7 13:37:17.872 ADT: Se2/1:0 LCP: O CONFREQ [REQsent] id 255 len 10 Jul 7 13:37:17.872 ADT: Se2/1:0 LCP: MagicNumber 0x687EBC03 (0x0506687EBC03) Jul 7 13:37:19.872 ADT: Se2/1:0 LCP: TIMEout: State REQsent Jul 7 13:37:19.872 ADT: Se2/1:0 LCP: O CONFREQ [REQsent] id 0 len 10 Jul 7 13:37:19.872 ADT: Se2/1:0 LCP: MagicNumber 0x687EBC03 (0x0506687EBC03) Jul 7 13:37:21.872 ADT: Se2/1:0 LCP: TIMEout: State REQsent Jul 7 13:37:21.872 ADT: Se2/1:0 LCP: O CONFREQ [REQsent] id 1 len 10 Jul 7 13:37:21.872 ADT: Se2/1:0 LCP: MagicNumber 0x687EBC03 (0x0506687EBC03) Jul 7 13:37:23.872 ADT: Se2/1:0 LCP: TIMEout: State REQsent Jul 7 13:37:23.872 ADT: Se2/1:0 LCP: State is Listen Jul 7 13:37:53.872 ADT: Se2/1:0 LCP: TIMEout: State Listen Jul 7 13:37:53.872 ADT: Se2/1:0 LCP: O CONFREQ [Listen] id 2 len 10 Jul 7 13:37:53.872 ADT: Se2/1:0 LCP: MagicNumber 0x687F7F63 (0x0506687F7F63) Jul 7 13:37:55.872 ADT: Se2/1:0 LCP: TIMEout: State REQsent Jul 7 13:37:55.872 ADT: Se2/1:0 LCP: O CONFREQ [REQsent] id 3 len 10 Jul 7 13:37:55.872 ADT: Se2/1:0 LCP: MagicNumber 0x687F7F63 (0x0506687F7F63) Jul 7 13:37:57.872 ADT: Se2/1:0 LCP: TIMEout: State REQsent Jul 7 13:37:57.872 ADT: Se2/1:0 LCP: O CONFREQ [REQsent] id 4 len 10 Jul 7 13:37:57.872 ADT: Se2/1:0 LCP: MagicNumber 0x687F7F63 (0x0506687F7F63) Jul 7 13:37:59.872 ADT: Se2/1:0 LCP: TIMEout: State REQsent Jul 7 13:37:59.872 ADT: Se2/1:0 LCP: O CONFREQ [REQsent] id 5 len 10 Jul 7 13:37:59.872 ADT: Se2/1:0 LCP: MagicNumber 0x687F7F63 (0x0506687F7F63) Version 12.2(13b) on Cisco 3640
... View more
Created by
dnickich
in Other Network Infrastructure Subjects
07-03-2003
11:25 AM
07-03-2003
11:25 AM
3640 with 12.2(13b) on a T1 Channelized port point 1) I see that the MagicNumber on ID 60 CONFREQ in and ID 60 CONFACK out are the same. From what I understand this should not be the same number. The "remote" router would see this as a loopback. I have not confirmed this but I will. Point 2) ID does not match. I see this over and over again. The ID numbers change but never match. Jul 3 10:48:20.311 ADT: Se2/1:2 LCP: State is Listen Jul 3 10:48:21.243 ADT: Se2/1:2 LCP: I CONFREQ [Listen] id 60 len 20 Jul 3 10:48:21.247 ADT: Se2/1:2 LCP: MRU 1520 (0x010405F0) Jul 3 10:48:21.247 ADT: Se2/1:2 LCP: ACCM 0x00000000 (0x020600000000) Jul 3 10:48:21.247 ADT: Se2/1:2 LCP: MagicNumber 0xF7FDA290 (0x0506F7FDA290) Jul 3 10:48:21.247 ADT: Se2/1:2 LCP: O CONFREQ [Listen] id 46 len 10 Jul 3 10:48:21.247 ADT: Se2/1:2 LCP: MagicNumber 0x5348FB5E (0x05065348FB5E) Jul 3 10:48:21.247 ADT: Se2/1:2 LCP: O CONFACK [Listen] id 60 len 20 Jul 3 10:48:21.247 ADT: Se2/1:2 LCP: MRU 1520 (0x010405F0) Jul 3 10:48:21.251 ADT: Se2/1:2 LCP: ACCM 0x00000000 (0x020600000000) Jul 3 10:48:21.251 ADT: Se2/1:2 LCP: MagicNumber 0xF7FDA290 (0x0506F7FDA290) Jul 3 10:48:21.263 ADT: Se2/1:2 LCP: I CONFACK [ACKsent] id 24 len 10 Jul 3 10:48:21.263 ADT: Se2/1:2 LCP: MagicNumber 0x5348052D (0x05065348052D) Jul 3 10:48:21.263 ADT: Se2/1:2 LCP: ID 24 didn't match 46, discarding packet Jul 3 10:48:23.247 ADT: Se2/1:2 LCP: TIMEout: State ACKsent I have tried shut no shut on the se2/1:2 I can get the connection up for a while if I reboot the remote router. At first the ckt was up 2 weeks. Now it will only stay up for an hour or two. Any suggestions? PS sh int 2/1:2 shows many interface resets but no carrier transitions
... View more
Created by
dnickich
in Other Network Infrastructure Subjects
03-19-2003
11:35 AM
03-19-2003
11:35 AM
We have changed to provide clock on the local end and things are running better. We are still having some trouble. Also we have 2 other T1s that are running better than these that are timing off the line. They are on the same DS3, MUX and Microwave path and end at the same office. Our loop back tests show that when we loop back at the DSX Jacks the T-bird show they run with no errors while testing for 72 hours. Maybe you could check me on this. I know that our IXC is running clear channel. We connect to them on copper with no active network devices. I believe that clear channel is unframed by the IXC. I also believe that clock is recovered from the framing bit. If there is no Framing bit then there can be no recovered clock. Then the Framing bit has to be inserted at the end equipment, correct?
... View more
Created by
dnickich
in Other Network Infrastructure Subjects
03-18-2003
02:18 PM
03-18-2003
02:18 PM
How can I tell if the MUX is providing clock? I am using clocking line now but I am seeing errors. These errors seem to be bursty. The circuits run OK for a few hours at a time then take a stack of errors. I am thinking that this is a timing slip on the WAN (T1 spans). I can not figure out how to isolate the problem. I have removed one T1 from service and did a hard wire loopback at the far end and ran a test pattern on it for 24 hours with out an error. As to the common Timing source issue I don't think that I have that. I am connecting to AT&T which is on one end of a DS3 microwave hop and Telus owns the DS3 microwave equipment that it is "talking" to. Other than each network having it's own stratum one clock. I am told by the carrier that the circuits that I am using are "clear channel" "unframed". This make me think that I can not "recover" clock from the line.
... View more
Created by
dnickich
in Other Network Infrastructure Subjects
03-18-2003
12:53 PM
03-18-2003
12:53 PM
I am having trouble with several Point to Point T1 circuits. Two of these are between a couple 3640 routers. These routers are connected via a T1 to DS3 MUX to microwave hop to DS3 MUX back down to T1. There is no DACS in the circuit. My Current clock source is line on both ends of this circuit but I am seeing show service-module serial 0/0 ... Total Data (last 96 15 minute intervals): 27 Line Code Violations, 601 Path Code Violations 0 Slip Secs, 11 Fr Loss Secs, 21 Line Err Secs, 15220 Degraded Mins 191 Errored Secs, 77 Bursty Err Secs, 11 Severely Err Secs, 0 Unavail Secs I have heard that the clock source should be set to line AND I have heard that it shold be set to "internal". Which is correct for this WAN configuration? If timing off the line on both ends is correct where does the timing on the circuit come from?
... View more
Public Statistics
| Date Registered | 03-18-2003 12:29 PM |
| Date Last Visited | 08-18-2017 03:50 AM |
| Total Messages Posted | 7 |
Badges
