HDLC
Getting some good info here.. So cisco has their own implementation of HDLC.. is it compatible with other non-cisco devices (nothing particular in mind here)? What does the control field of a cisco HDLC frame look like? Thanks!!! Jeremy _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: HDLC
Thats right, cisco hdlc is not compatible with other vendors implemenation of hdlc. An HDLC frame format is shown below: 111 2 variable 2 1 +++++---++-- --+ |flag|addr|ctrl|protocol|data | FCS |flag| |0x7E||0x00|| | |0x7E| +++++---++-- --+ flag = start/end of frame = 0x7E (Other special characters: Idle = 0xFF, Abort = 0x7F) address = this is really a frame type field 0x0F = Unicast Frame 0x80 = Broadcast Frame 0x40 = Padded Frame 0x20 = Compressed Frame Protocol = the Ethernet type of the encapsulated data: 0x0800 = IP 0x6003 = DECnet ... 0x6558 = Bridged Frame 0x8035 = Keepalive Frame 0x80C4 = CDP The bits in the frame (not counting the flag bytes) are 0 bit stuffed to insure that there is never more then 5 1 bits in a row on the wire. Therefore 0xFF, 0xFE, 0xFC, 0x7E, 0x7F, 0x3F bytes could never be in the data portion of the frame - so they are free to be used for start/end framing and other special functions on the wire. /Stuart. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeremy Dumoit Sent: Friday, February 09, 2001 1:45 PM To: [EMAIL PROTECTED] Subject: HDLC Getting some good info here.. So cisco has their own implementation of HDLC.. is it compatible with other non-cisco devices (nothing particular in mind here)? What does the control field of a cisco HDLC frame look like? Thanks!!! Jeremy _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: HDLC
> Getting some good info here.. So cisco has their own implementation of >HDLC.. is it compatible with other non-cisco devices (nothing particular in >mind here)? What does the control field of a cisco HDLC frame look like? >Thanks!!! > >Jeremy It's a little unfair to deprecate an "implementation" of HDLC. HDLC, as the standard is written, is much more an architecture for data link protocols than a protocol to be implemented and have multivendor compatibility. LAP, LAP-B, LAP-D, and LAP-F are all HDLC subsets that I would expect to be interoperable. Cisco, Codex/Motorola, Ascom/Timeplex, etc., would have made me much happier if they simply had said they had proprietary link protocols with HDLC-style framing. Remember that PPP wasn't around at the time these protocols were deployed. X.25 LAP (perhaps not LAP-B) was, but, again, link-level retransmission is not necessarily desirable. _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: HDLC
On Fri, 9 Feb 2001, Jeremy Dumoit wrote: > > Getting some good info here.. So cisco has their own implementation of > HDLC.. is it compatible with other non-cisco devices (nothing particular in > mind here)? What does the control field of a cisco HDLC frame look like? > Thanks!!! Several non-cisco manufacturers have reverse engineered the cisco proprietary HDLC and have it working fine..imagestream and redback come to mind... Brian > > Jeremy > > _ > FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > --- I'm buying used CISCO gear!! email me for a quote Brian Feeny e:[EMAIL PROTECTED] CCNP+Voice/ATM/Security p:318.222.2638x109 CCDPf:318.221.6612 Network Administrator ShreveNet Inc. (ASN 11881) _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: HDLC
>On Fri, 9 Feb 2001, Jeremy Dumoit wrote: > >> >> Getting some good info here.. So cisco has their own implementation of >> HDLC.. is it compatible with other non-cisco devices (nothing particular in >> mind here)? What does the control field of a cisco HDLC frame look like? >> Thanks!!! > >Several non-cisco manufacturers have reverse engineered the cisco >proprietary HDLC and have it working fine..imagestream and redback >come to mind... > >Brian There's nothing terribly secret about Cisco's HDLC, and, as far as I know, it's not one of their patented technologies. HDLC really doesn't offer any advantages over PPP, so it really reflects someone who doesn't want to do minimum reconfiguration of their Ciscos to worry about using PPP for multivendor compatibility. Neither PPP nor HDLC is really optimal for very high bandwidth, such as SONET. There are some protocols such as SRP being proposed for running IP over optical. _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: HDLC
"Howard C. Berkowitz" wrote: > > HDLC really doesn't offer any advantages over PPP, so it really > reflects someone who doesn't want to do minimum reconfiguration of > their Ciscos to worry about using PPP for multivendor compatibility. > Well, one small advantage is that Cisco's proprietary HDLC keepalive will report a loop condition on the layer 1. And it will also, by default, treat a looped interface as "line protocol up", which is great for testing, using just the router. Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 240-568-6526 133 National Business Pkwy WWW: http://www.mentortech.com Annapolis Junction, MD 20701Cisco CCIE #1289 _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: HDLC
I wasn't aware of that! Thanks. But isn't loop detection also a PPP option? At 10:16 PM 2/19/2001 -0500, Marty Adkins wrote: >"Howard C. Berkowitz" wrote: > > > > HDLC really doesn't offer any advantages over PPP, so it really > > reflects someone who doesn't want to do minimum reconfiguration of > > their Ciscos to worry about using PPP for multivendor compatibility. > > >Well, one small advantage is that Cisco's proprietary HDLC keepalive >will report a loop condition on the layer 1. And it will also, by >default, treat a looped interface as "line protocol up", which is >great for testing, using just the router. > > Marty Adkins Email: [EMAIL PROTECTED] > Mentor Technologies Phone: 240-568-6526 > 133 National Business Pkwy WWW: http://www.mentortech.com > Annapolis Junction, MD 20701Cisco CCIE #1289 _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: HDLC
PPP uses magic numbers to detect loops. You'll see warnings about receiving your magic #, etc if it detects a loop. The magic number is a optional feature though and every vendor doesn't use it or have it enabled by default. If using BayRS's 'Wellfleet Standard' which is their implementation of HDLC - IP will come up if the circuit/line is looped somewhere. Setting it to HDLC on Cisco or Bay is a good test for pointing problem to carrier when they've tested the line and swear its ok and tests clean. It's also a good way to make sure the cables between the router interface and the CSU/DSU config are good. To prove it's not your equipment you unplug the circuit from the CSU/DSU and IP will go down if your local equipment is functioning/configured fine. Also, HDLC is less picky then PPP usually. Changing the encaps to HDLC may be useful in troubleshooting either a PPP configuration problem or line/circuit issue. If IP comes up and you can ping other end then you have connectivity to the other site - but how good? :) Time to look at the interface stats to see what errors your getting. --- "Howard C. Berkowitz" <[EMAIL PROTECTED]> wrote: > > I wasn't aware of that! Thanks. > > But isn't loop detection also a PPP option? > > At 10:16 PM 2/19/2001 -0500, Marty Adkins wrote: > >"Howard C. Berkowitz" wrote: > > > > > > HDLC really doesn't offer any advantages over > PPP, so it really > > > reflects someone who doesn't want to do minimum > reconfiguration of > > > their Ciscos to worry about using PPP for > multivendor compatibility. > > > > >Well, one small advantage is that Cisco's > proprietary HDLC keepalive > >will report a loop condition on the layer 1. And > it will also, by > >default, treat a looped interface as "line protocol > up", which is > >great for testing, using just the router. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: HDLC
"Howard C. Berkowitz" wrote: > > I wasn't aware of that! Thanks. > > But isn't loop detection also a PPP option? > Yes, it's described as part of RFC1661, but it might be a catch-22. The magic number field used for this is optional and must be negotiated. Cisco routers do attempt magic number negotiation and do detect looped paths, and let me check current doc... DO maintain a line protocol up status as long as "down-when-looped" has NOT been configured. So you're quite right -- for Cisco to Cisco, PPP and HDLC will both treat this the same way. OTOH, if the encapsulation were frame-relay or some other, then a loop causes a line protocol down state (e.g., LMI or ILMI polling fails). With Cisco to non-Cisco, particularly Ascend Pipelines, I have seen the magic number negotiation fail, and the Cisco reported a loop condition because the Ascend was echoing back the packet with the Cisco's magic number. But that was a while back. So thanks, Howard, for responding! - Marty > At 10:16 PM 2/19/2001 -0500, Marty Adkins wrote: > >"Howard C. Berkowitz" wrote: > > > > > > HDLC really doesn't offer any advantages over PPP, so it really > > > reflects someone who doesn't want to do minimum reconfiguration of > > > their Ciscos to worry about using PPP for multivendor compatibility. > > > > >Well, one small advantage is that Cisco's proprietary HDLC keepalive > >will report a loop condition on the layer 1. And it will also, by > >default, treat a looped interface as "line protocol up", which is > >great for testing, using just the router. > > > > Marty Adkins Email: [EMAIL PROTECTED] > > Mentor Technologies Phone: 240-568-6526 > > 133 National Business Pkwy WWW: http://www.mentortech.com > > Annapolis Junction, MD 20701Cisco CCIE #1289 _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
HDLC, SDLC...
Dear all, I am a little bit confused about the difference of framing between hdlc, sdlc, lapb, lapd, llc2. Can someone help me? Thank you, cvp. __ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Cisco HDLC Flags (was PPP vs HDLC) [7:64779]
The question was whether or not Cisco used the "standard" 0x7E as a flag in their HDLC implementation. The only WAN protocol analzer I could dig up predates Cisco HDLC by a few decades. So I did rely on an o'scope as planned. Between keepalives, a constant binary 10011001100110 can be observed. This is the classic 7E7E scope trace. Seems to me that most HDLC implementations that I can remember do two 0x7Es and then all zeros for the remainder of the frame header (no "payload zeros"). Cisco apparently just keeps 'em a comin'. Of course, once keepalives or real data hit the line, there's no way to distinguish the 7E flag between frames. But given that 7E7E is used as an idle pattern, it isn't too much of stretch to assume they serve as frame delimiters as well. I'll try to verify that with a Cisco HDLC-capable WAN analyzer if I ever get my hands on one and can get it latched on to a Cisco serial connection. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=64779&t=64779 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: HDLC, SDLC...
I can explain the first three protocols namely hdlc, sdlc, lapb First of all they are all WAN protocols, which is layer 2 protocol for communicating across a WAN link, which protocol to use depends on two factors the WAN technology that you use and the communicating equipment HDLC stands for High-level Data link Control which is the default encapsulation type on point-to-point , dedicated links. It is used typically when communicating bet two CISCO devices. It is a bit oriented synchronous data link layer protocol.HDLC specifies a data encapsulation method on synchronous serial links using frame characters and checksums. If communicating with a non-Cisco device , synchronous PPP is a more viable option SDLC stands for Serial Data Link Control use mainly for SNA networks and lapb Link Access Procedure, Balanced is for X.25 links Jason -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of perez claude-vincent Sent: Wednesday, September 06, 2000 1:46 PM To: [EMAIL PROTECTED] Subject: HDLC, SDLC... Dear all, I am a little bit confused about the difference of framing between hdlc, sdlc, lapb, lapd, llc2. Can someone help me? Thank you, cvp. __ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: HDLC, SDLC...
They are all based on the original work done by IBM for SDLC. SDLC uses a complicated master-slave scheme that is not used in the other protocols. However, the fields in all of the frames of the protocols mentioned were basically derived from a special case of the SDLC protocol. Regards, MLC perez claude-vincent <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Dear all, > > I am a little bit confused about the difference of > framing between hdlc, sdlc, lapb, lapd, llc2. > > Can someone help me? > > Thank you, cvp. > > > > __ > Do You Yahoo!? > Yahoo! Mail - Free email you can access from anywhere! > http://mail.yahoo.com/ > > ___ > UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html > FAQ, list archives, and subscription info: http://www.groupstudy.com > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: HDLC, SDLC...
These are all Layer 2 protocols. This site has some very good explanations of the differences. http://www.sangoma.com/tutorial.htm LLC2 = IEEE 802.2 Logical Link Control Type 2. Used by SNA and NetBIOS on a LAN. Frame Format: http://www.protocols.com/pbook/lan.htm#LLC LAPD = Access protocol on ISDN D channel. Ensures error free transmission. Frame Format: http://www.protocols.com/pbook/isdn.htm#LAPD HDLC = Sets the framing structure for synchronous communications and is responsible for the error-free movement of data between network nodes. There are two different implementations of HDLC, HDLC NRM (also known as SDLC) and HDLC LAPB. NRM is MAster/slave. LAPB is peer-to-peer. Frame Format: http://www.protocols.com/pbook/x25.htm#HDLC LAPB = CCITT adaptation of HDLC. Used to carry X.25 commands and control frames. Supports full-duplex operations and is peer-to-peer (neither end plays the role of master on a permanent basis). Frame Format: http://www.protocols.com/pbook/x25.htm#LAPB SDLC = Developed by IBM. Performes the layer 2 functions of the SNA hierarchy. SDLC is virtually identical to HDLC Normal Response Mode and was developed to replace the Bisynchronous protocol for WAN connections between IBM equipment. Primarily half-duplex but is capable of supporting full-duplex. Not a peer-to-peer protocol like HDLC/LAPB, X.25, and Frame-Relay. Frame Format: http://www.protocols.com/pbook/sna.htm#SDLC Nope this helps, Karen E Young Network Engineer ELF Technologies, Inc [EMAIL PROTECTED] perez claude-vincent To: [EMAIL PROTECTED] Subject: HDLC, SDLC... Sent by: nobody@groupstud y.com 09/05/2000 10:46 PM Please respond to perez claude-vincent Dear all, I am a little bit confused about the difference of framing between hdlc, sdlc, lapb, lapd, llc2. Can someone help me? Thank you, cvp. __ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: HDLC, SDLC...
Another thing to keep in mind is that Cisco does not use a standard HDLC header. That's why PPP is recommended for interoperability with non-Cisco devices. Cisco doesn't take advantage of any of the reliability features of standard HDLC, and Cisco added a field to the header to identify the next layer up, such as IP, DDP, DECnet, etc. Cisco's HDLC has been discussed many times on this list, so check the archives for more details. Priscilla At 05:34 AM 9/6/00, michael champion wrote: >They are all based on the original work done by IBM for SDLC. SDLC uses a >complicated master-slave scheme that is not used in the other protocols. >However, the fields in all of the frames of the protocols mentioned were >basically derived from a special case of the SDLC protocol. > >Regards, >MLC > >perez claude-vincent <[EMAIL PROTECTED]> wrote in message >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > Dear all, > > > > I am a little bit confused about the difference of > > framing between hdlc, sdlc, lapb, lapd, llc2. > > > > Can someone help me? > > > > Thank you, cvp. > > > > > > > > __ > > Do You Yahoo!? > > Yahoo! Mail - Free email you can access from anywhere! > > http://mail.yahoo.com/ > > > > ___ > > UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html > > FAQ, list archives, and subscription info: http://www.groupstudy.com > > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > > > > >___ >UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html >FAQ, list archives, and subscription info: http://www.groupstudy.com >Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] Priscilla Oppenheimer http://www.priscilla.com ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
HDLC [7:66324]
Hi, I have a couple of queries regarding HDLC and Frame Relay. I gather they're both forms of data encapsulation for data and basically this means putting the data in headers and trailers to identify to the next layer or computer how to deal with the data. Please advise whether this is correct. If this is correct, could you please advise under what circumstances HDLC and Frame Relay are used in a real world environment? Do they function in their own right, or are they part of software or hardware or a protocol? I see that HDLC is for point to point transfer only; presumably this means that if a router is using HDLC it can only talk directly to one device out a single interface but with FR, it can send frames over a LAN-like structure? I seem to be in some confusion as to where these two things fit in; the rest of the two chapters (3 and 4) seem fine, I just keep contradicting myself over these two things. I'm sure it's one of those blindingly obvious things that will be really simple to understand once someone sets me straight - I think I'm interpreting these things differently each time I read about them. Thanks in advance for your help DJ - With Yahoo! Mail you can get a bigger mailbox -- choose a size that fits your needs Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=66324&t=66324 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
HDLC [7:18970]
Hi all, I am about to take a second attempt with the CIT(support) exam.My first attempt I had problem with HDLC topic.DO any one have any tips or web site, cisco or otherwise, I could go to find out about HDLC(troubleshooting tools,Methods and targets).Thanks. PS Also on IOS backups(problem isolation for tcpip,Troubleshooting tools,Methods and Targets) Regards, Muhammad Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=18970&t=18970 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Cisco HDLC Flags (was PPP vs HDLC) [7:64779]
Thanks Scott! To synthesize: The original question was whether efficiency would be improved if Cisco HDLC were used instead of PPP. Most of us said "no," which is correct, (taking efficiency to mean header overhead.) A few of us added the caveat that a Cisco HDLC header/trailer maybe has a couple bytes less than a PPP header/trailer. That's not true. RFC 1331 specifies the PPP header like this: Flag 1 byte (0110) Address 1 byte Control 1 byte Protocol 2 bytes info (variable) FCS 2 bytes Flag 1 byte (0110) With the new info from Scott that says Cisco HDLC uses flags also, one could say that the above description of PPP matches Cisco HDLC also. (The exact behavior of the flags for either one, from a frame-format and efficiency point of view, is really not too relevant. In fact the newer RFC for PPP (1661) doesn't mention them and the document on Cisco HDLC doesn't mention them either.) The main point is that Cisco HDLC and PPP are equivalent as far as efficiency, (if by efficiency we mean header overhead.) QED. :-) ___ Priscilla Oppenheimer www.troubleshootingnetworks.com www.priscilla.com s vermill wrote: > > The question was whether or not Cisco used the "standard" 0x7E > as a flag in their HDLC implementation. The only WAN protocol > analzer I could dig up predates Cisco HDLC by a few decades. > So I did rely on an o'scope as planned. Between keepalives, a > constant binary 10011001100110 can be > observed. This is the classic 7E7E scope trace. Seems to me > that most HDLC implementations that I can remember do two 0x7Es > and then all zeros for the remainder of the frame header (no > "payload zeros"). Cisco apparently just keeps 'em a comin'. > Of course, once keepalives or real data hit the line, there's > no way to distinguish the 7E flag between frames. But given > that 7E7E is used as an idle pattern, it isn't too much of > stretch to assume they serve as frame delimiters as well. I'll > try to verify that with a Cisco HDLC-capable WAN analyzer if I > ever get my hands on one and can get it latched on to a Cisco > serial connection. > > > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=64798&t=64779 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
ppp &hdlc [7:10737]
Dear all pls show me difference ppp and hdlc Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=10737&t=10737 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: HDLC [7:66324]
=?iso-8859-1?q?maine=20dude?= wrote: > > Hi, I have a couple of queries regarding HDLC and Frame Relay. > I gather they're both forms of data encapsulation for data and > basically this means putting the data in headers and trailers > to identify to the next layer or computer how to deal with the > data. Please advise whether this is correct. Both HDLC and Frame Relay have a header and trailer and yes, they do encapsulate network-layer data and above. But it's a bit of an exaggeration to say that they "identify to the next layer or computer how to deal with the data." HDLC and Frame Relay are data-link layer protocols that provide Wide Area Networking (WAN) connectivity. Acting at the data-link layer, they are analagous to Ethernet or Token Ring in a LAN. You wouldn't say that Ethernet "identifies to the next layer or computer how to deal with the data" and you shouldn't say this about HDLC or Frame Relay either. They may identify what the next layer is, but not "how to deal with the data." Think of the OSI model. Each layer calls on the layer below and depends on the service provided by the layer below, but not the other way around. Each layer passes the encapsulated data to the layer above without touching it or understanding what it does. Sorry if that's picky. The original HDLC packet format did not have a field to identify the payload, i.e. the type of network-layer data that is encapsulated. But modern derivitaves of HDLC, including Cisco HDLC and PPP do have such a field. The standard Frame Relay packet format doesn't have a field to identify the next layer either, but Cisco's Frame Relay format does. As mentioned, HDLC and Frame Relay are WAN protocols. The obvious difference from LANs is that they connect devices or sites across a relatively long distance. The other, and possibly more important, difference is that you need a service provider or telco to implement a WAN. With LANs, you own the whole thing. With WANs, you own the routers, but then you lease capacity from a service provider or telco and get an agreement that the provider will send your data across its internal network of switches that span the long distance. This brings with it an entire set of administrative, political, and monetary issues, and means from an implementation and troubleshooting point of view that you have to work with the provider's engineers and sales geeks. But it's worth it. There's no way you can set up your own link between San Francisco and Los Angeles, for example, without the help of a telco/service provider. Things like mountains, roads, earthquake faults, and pot farms would get in your way. Just kidding. :-) In the olden days, HDLC was sometimes used to connect computers, such as mainframes and terminal controllers. These days, in a Cisco-oriented environment, both HDLC and Frame Relay are used to connect routers. That's another difference from LANs. You wouldn't normally put HDLC or Frame Relay on an end computer, whereas an end computer does have an Ethernet NIC in it. HDLC and Frame Relay are built into the Cisco Internetwork Operating System (IOS) and use a serial interface for the hardware. Now, for the differences between HDLC and frame Relay. HDLC is used for a point-to-point link, as you mentioned. It's used on a leased line that you get from a telco. You could connect a router in Atlanta, for example, to the local telco and contract with them to get your data to a telco in New York, for example, where you connect another router to the telco there. The result is a permanent, real circuit (as opposed to virtual circuit) between Atlanta and New York that only you can use. What if you also have sites in Boston, Los Angeles, and Chicago, as well as Atlanta? Should you lease a point-to-point link to make every connection? The number of circuits would be n(n-1)/2 where n is the number of sites. That's expensive. And that's where Frame Relay comes in. Frame Relay allows you to have virtual circuits to many different sites. With Frame Relay, you can lease a single line into the service provider's Frame Relay "cloud" and then contract with them for virtual circuits to other sites. For example, if New York is your HQ, you could have just one line into the telco in New York, but a virtual circuit to every other site. The outlying sites communicate with each other through New York. Each of them also just has one link into their local telco. Your network traffic travels across the Frame Relay provider "cloud," which is shared by all the provider's customers. Well, I'm running out of steam here and have to get to work. This is covered in many books and white papers, as you probably know. I'm not sure which book you are using. Cisco Academy maybe? But if you have some specific questions, let us know. I'm wondering too if you could t
Re: HDLC [7:18970]
Cisco's categorization of topics for CIT is messed up and there really are very few questions on HDLC troubleshooting, despite what they say. My guess is that you missed other types of questions. Are you aware of the Internetwork Troubleshooting Guide here: http://www.cisco.com/univercd/cc/td/doc/cisintwk/itg_v1/index.htm Also, try my CIT flash cards here: http://www.priscilla.com Good luck! Priscilla At 10:39 AM 9/7/01, Muhammad Alkhattab wrote: >Hi all, >I am about to take a second attempt with the CIT(support) exam.My first >attempt I had problem with HDLC topic.DO any one have any tips or web site, >cisco or otherwise, I could go to find out about HDLC(troubleshooting >tools,Methods and targets).Thanks. > >PS >Also on IOS backups(problem isolation for tcpip,Troubleshooting >tools,Methods and Targets) > >Regards, > >Muhammad Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=19025&t=18970 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
do interface counters include HDLC?
Hello My interface counters on a Serial line with HDLC are 4 bytes per IP packet too high. I had the idea that this could be the HDLC frame but this is much longer than 4 bytes. Where is documented what exactly an interface counter counts? TIA & bye, -christian- _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: ppp &hdlc [7:10737]
one glaring difference, I have heard that Cisco's hdlc is modified so it will not work with non cisco hdlc. PPP is PPP, you can attach a non Cisco router running pp to it and be successful. Brian "Sonic" Whalen Success = Preparation + Opportunity On Mon, 2 Jul 2001, friend wrote: > Dear all > pls show me difference ppp and hdlc Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=10740&t=10737 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: ppp &hdlc [7:10737]
I agree. PPP is a non-proprietary protocol and HDLC is vendor specific. If you are connecting to a non Cisco device, use PPP. If you are connecting 2 Cisco devices, use HDLC. HDLC is the default encapsulation on Cisco routers. HTH MikeN Network Engineer ""Brian"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > one glaring difference, I have heard that Cisco's hdlc is modified so it > will not work with non cisco hdlc. PPP is PPP, you can attach a non Cisco > router running pp to it and be successful. > > Brian "Sonic" Whalen > Success = Preparation + Opportunity > > > On Mon, 2 Jul 2001, friend wrote: > > > Dear all > > pls show me difference ppp and hdlc Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=10764&t=10737 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: ppp &hdlc [7:10737]
One difference between PPP and HDLC is that PPP supports authentication from PAP (password authentication protocol) and CHAP (Challenge Handshake Authentication Protocol). I believe that PPP runs over ISDN and HDLC doesn't (but don't quote me on that one, I'm not sure). -P Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=10766&t=10737 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: ppp &hdlc [7:10737]
Excellent point Preston. We can't forget multilink either. HDLC is also the default encap for ISDN: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/dial ts_c/dtsprt3/dcdbri.htm#xtocid771414 HTH MikeN Network Engineer ""Preston Kilburn"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > One difference between PPP and HDLC is that PPP supports authentication from > PAP (password authentication protocol) and CHAP (Challenge Handshake > Authentication Protocol). I believe that PPP runs over ISDN and HDLC > doesn't (but don't quote me on that one, I'm not sure). > -P Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=10768&t=10737 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: ppp &hdlc [7:10737]
Both PPP and HDLC are encapsulation protocols on serial interfaces.But PPP is better than HDLC in 2 main points: 1- PPP supports multiple network layer encapsulation (IP,IPX,AppleTalk,...) while standard HDLC supports only IP encapsulation.[Cisco HDLC supports multiple network layer encapsulation]. 2- PPP suports both PAP and CHAP authentication protocols which provides a secure point-to-point session while HDLC doesn't support that. "friend" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Dear all > pls show me difference ppp and hdlc Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=10777&t=10737 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
PPP vs HDLC [7:64362]
It has been mooted to me that we might get better performance from our 1Mb line by using HDLC rather than PPP. Is this correct? If so is it just a case of changing the Encapsulation PPP to Encapsulation HDLC on both ends of the link? Are there any implications I should be aware of? Thanks _ Stuart Pittwood, MCSE IT Technician Amery-Parkes Solicitors Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=64362&t=64362 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
HDLC STAC Compression [7:56073]
Is anyone out there using STAC compression on HDLC links in a live network? If so what is the maximum speed link you would apply it to and has it brought significant benefits. Many thanks in advance Tim Champion Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=56073&t=56073 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Question Regarding HDLC [7:60337]
Hi All, I have question regarding HDLC,a silly question but still a doubt.See I have HDLC connection back to back.on one interface I configure compression and other interface on other router no compression.Now when I debug the my seq and mine seen no.s are in sync I mean same they inncrease ,that different no layer 3 communication I am able to do.If such case occurs how from debug commands I will come to know. I enabled debug serial interface but it only shows me that the no get increment that too in proper order but I have read that in Karl Solie book Vol1 that it will stop increment the keepalives. So can anybody guide me. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=60337&t=60337 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
HDLC and Routing protocols [7:5739]
Anyone know why I would have problems with apparently ANY routing protocol over an HDLC point-to-point Link? Works fine with static routes, but when I try to implement any routing protocol (RIP, EIGRP, OSPF, etc..) they don't seem to work (no routes discovered). Am I missing something? Thanks! -Rizzo Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=5739&t=5739 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
PPP or HDLC pros and cons
Hi guys, In a point to point T1 link what would be advantages or disadvantages of using HDLC vs PPP. Thank you = JZ [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: PPP vs HDLC [7:64362]
I've never heard efficiency as a reason to use PPP over HDLC. there are more options with PPP, but otherwise both are based upon SDLC and therefore nearly identical from a protocol perspective. I suppose HDLC are a couple bytes smaller, but this would be negligable. I'd say if your PPP is configured and working fine, why bother to go through the motions of changing for a 0.1% benefit? scott ""Stuart Pittwood"" wrote in message news:[EMAIL PROTECTED] > It has been mooted to me that we might get better performance from our > 1Mb line by using HDLC rather than PPP. > > > > Is this correct? > > > > If so is it just a case of changing the Encapsulation PPP to > Encapsulation HDLC on both ends of the link? > > > > Are there any implications I should be aware of? > > > > Thanks > > > > _ > > Stuart Pittwood, MCSE > > IT Technician > > Amery-Parkes Solicitors Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=64365&t=64362 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: PPP vs HDLC [7:64362]
Scott Roberts wrote: > > I've never heard efficiency as a reason to use PPP over HDLC. > there are more > options with PPP, but otherwise both are based upon SDLC and > therefore > nearly identical from a protocol perspective. I suppose HDLC > are a couple > bytes smaller, but this would be negligable. > > I'd say if your PPP is configured and working fine, why bother > to go through > the motions of changing for a 0.1% benefit? I agree. A PPP link might take a second or two longer to come up because of the option negotiation and any PAP or CHAP authentication, but once it's running, there's no reason it would be significantly less efficient than HDLC. Cisco's HDLC implementation is the simplest protocol in the world. The header is very small. It sends keepalives every 10 seconds by default. But PPP is very simple too and the LCP layer of PPP uses keepalives or something equivalent too, if I'm not mistaken. Priscilla > > scott > > ""Stuart Pittwood"" wrote in > message > news:[EMAIL PROTECTED] > > It has been mooted to me that we might get better performance > from our > > 1Mb line by using HDLC rather than PPP. > > > > > > > > Is this correct? > > > > > > > > If so is it just a case of changing the Encapsulation PPP to > > Encapsulation HDLC on both ends of the link? > > > > > > > > Are there any implications I should be aware of? > > > > > > > > Thanks > > > > > > > > _ > > > > Stuart Pittwood, MCSE > > > > IT Technician > > > > Amery-Parkes Solicitors > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=64371&t=64362 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: PPP vs HDLC [7:64362]
Actually, I use PPP so that I can combine two T1 lines into a single virtual interface (multilink PPP). There wasn't the capability of doing this with HDLC. ""Stuart Pittwood"" wrote in message news:[EMAIL PROTECTED] > It has been mooted to me that we might get better performance from our > 1Mb line by using HDLC rather than PPP. > > > > Is this correct? > > > > If so is it just a case of changing the Encapsulation PPP to > Encapsulation HDLC on both ends of the link? > > > > Are there any implications I should be aware of? > > > > Thanks > > > > _ > > Stuart Pittwood, MCSE > > IT Technician > > Amery-Parkes Solicitors Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=64374&t=64362 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: PPP vs HDLC [7:64362]
I have never heard of a performance boost by going with one or the other, PPP does support some things like quality monitoring and authentication that are useful in certain situations. One thing to be aware of is that some vendors only support PPP encapsulation, with others supporting both PPP and Cisco's HDLC. If one of the devices is not a Cisco, you would have to check the documentation to verify that they are able to support Cisco HDLC. -Original Message- From: Stuart Pittwood [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 11:48 AM To: [EMAIL PROTECTED] Subject: PPP vs HDLC [7:64362] It has been mooted to me that we might get better performance from our 1Mb line by using HDLC rather than PPP. Is this correct? If so is it just a case of changing the Encapsulation PPP to Encapsulation HDLC on both ends of the link? Are there any implications I should be aware of? Thanks _ Stuart Pittwood, MCSE IT Technician Amery-Parkes Solicitors Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=64377&t=64362 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: PPP vs HDLC [7:64362]
Stuart Pittwood wrote: > It has been mooted to me that we might get better performance from our > 1Mb line by using HDLC rather than PPP. > > > > Is this correct? HDLC is more efficient so I guess yes. If I recall correctly, (someone will let me know if not;) PPP rides on top of HDLC. > > > > If so is it just a case of changing the Encapsulation PPP to > Encapsulation HDLC on both ends of the link? Assuming you have a Cisco on both ends, yes. > > > > Are there any implications I should be aware of? One big advantage of PPP in the ability to authenticate. Though 1M seems odd I assume it's a dedicated link and authentication is not an issue. Dave > > > > Thanks > > > > _ > > Stuart Pittwood, MCSE > > IT Technician > > Amery-Parkes Solicitors -- David Madland CCIE# 2016 Sr. Network Engineer Qwest Communications 612-664-3367 "You don't make the poor richer by making the rich poorer." --Winston Churchill Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=64386&t=64362 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: PPP vs HDLC [7:64362]
MADMAN wrote: > > Stuart Pittwood wrote: > > It has been mooted to me that we might get better performance > from our > > 1Mb line by using HDLC rather than PPP. > > > > > > > > Is this correct? > >HDLC is more efficient so I guess yes. In what way is HDLC more efficient than PPP? > If I recall > correctly, > (someone will let me know if not;) PPP rides on top of HDLC. I would be glad to correct you. :-) HDLC is really more of an architecture than a specific protocol and there are many derivatives of it. PPP is just one of them, as is Cisco's HDLC. Other derivitaves include LAPB, LAPD, and LLC2. The standard PPP and Cisco HDLC are so similar in frame format you can barely tell them apart. Cisco HDLC encapsulation has: one-byte address field, which is set to 0x0F for most frames one-byte control byte that is always set to 0x00 two-byte protocol type field Guess what PPP has? Essentially the exact same thing: one-byte flag field set to 0x7F one-byte address field, set to 0x11 one-byte control field set to 0xC0 one or two-byte protocol field Both HDLC and PPP also have a control protocol for keeping the link up. HDLC has SLARP. It sends keepalives. PPP has the Link Control Protocol. It brings the link up and send echos and echo replies. Cisco HDLC can also use SLARP to assign an IP address to the other end. PPP has the Network Control Protocols in many different varieties. The IP variety can assign IP addresses. PPP also supports authentication, which Cisco HDLC doesn't. ___ Priscilla Oppenheimer www.troubleshootingnetworks.com www.priscilla.com > > > > > > > > > If so is it just a case of changing the Encapsulation PPP to > > Encapsulation HDLC on both ends of the link? > >Assuming you have a Cisco on both ends, yes. > > > > > > > > > Are there any implications I should be aware of? > >One big advantage of PPP in the ability to authenticate. > Though 1M > seems odd I assume it's a dedicated link and authentication is > not an issue. > >Dave > > > > > > > > > Thanks > > > > > > > > _ > > > > Stuart Pittwood, MCSE > > > > IT Technician > > > > Amery-Parkes Solicitors > -- > David Madland > CCIE# 2016 > Sr. Network Engineer > Qwest Communications > 612-664-3367 > > "You don't make the poor richer by making the rich poorer." > --Winston > Churchill > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=64389&t=64362 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: PPP vs HDLC [7:64362]
Priscilla Oppenheimer wrote: > MADMAN wrote: > >>Stuart Pittwood wrote: >> >>>It has been mooted to me that we might get better performance >> >>from our >> >>>1Mb line by using HDLC rather than PPP. >>> >>> >>> >>>Is this correct? >> >> HDLC is more efficient so I guess yes. > > > In what way is HDLC more efficient than PPP? Since there is a little less overhead it is more efficient but not to the extent that one should be concerned. > > >>If I recall >>correctly, >>(someone will let me know if not;) PPP rides on top of HDLC. You definately know more details than I but I did a quick search and the second item on this URL mentions the PPP/HDLC relationship so I somewhat in the ballpark no? ;) http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ppp.htm Dave > > > I would be glad to correct you. :-) > > HDLC is really more of an architecture than a specific protocol and there > are many derivatives of it. PPP is just one of them, as is Cisco's HDLC. > Other derivitaves include LAPB, LAPD, and LLC2. > > The standard PPP and Cisco HDLC are so similar in frame format you can > barely tell them apart. > > Cisco HDLC encapsulation has: > > one-byte address field, which is set to 0x0F for most frames > one-byte control byte that is always set to 0x00 > two-byte protocol type field > > > Guess what PPP has? Essentially the exact same thing: > > one-byte flag field set to 0x7F > one-byte address field, set to 0x11 > one-byte control field set to 0xC0 > one or two-byte protocol field > > > Both HDLC and PPP also have a control protocol for keeping the link up. HDLC > has SLARP. It sends keepalives. PPP has the Link Control Protocol. It brings > the link up and send echos and echo replies. > > Cisco HDLC can also use SLARP to assign an IP address to the other end. > > PPP has the Network Control Protocols in many different varieties. The IP > variety can assign IP addresses. > > PPP also supports authentication, which Cisco HDLC doesn't. > > ___ > > Priscilla Oppenheimer > www.troubleshootingnetworks.com > www.priscilla.com > > > > >>> >>> >>>If so is it just a case of changing the Encapsulation PPP to >>>Encapsulation HDLC on both ends of the link? >> >> Assuming you have a Cisco on both ends, yes. >> >> >>> >>> >>>Are there any implications I should be aware of? >> >> One big advantage of PPP in the ability to authenticate. >>Though 1M >>seems odd I assume it's a dedicated link and authentication is >>not an issue. >> >> Dave >> >> >>> >>> >>>Thanks >>> >>> >>> >>>_ >>> >>>Stuart Pittwood, MCSE >>> >>>IT Technician >>> >>>Amery-Parkes Solicitors >> >>-- >>David Madland >>CCIE# 2016 >>Sr. Network Engineer >>Qwest Communications >>612-664-3367 >> >>"You don't make the poor richer by making the rich poorer." >>--Winston >>Churchill -- David Madland CCIE# 2016 Sr. Network Engineer Qwest Communications 612-664-3367 "You don't make the poor richer by making the rich poorer." --Winston Churchill Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=64485&t=64362 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: PPP vs HDLC [7:64362]
MADMAN wrote: > > Priscilla Oppenheimer wrote: > > MADMAN wrote: > > > >>Stuart Pittwood wrote: > >> > >>>It has been mooted to me that we might get better performance > >> > >>from our > >> > >>>1Mb line by using HDLC rather than PPP. > >>> > >>> > >>> > >>>Is this correct? > >> > >> HDLC is more efficient so I guess yes. > > > > > > In what way is HDLC more efficient than PPP? > >Since there is a little less overhead it is more efficient > but not to > the extent that one should be concerned. Cisco HDLC may have a couple bytes less than PPP in its header. Not a big deal, as you say. > > > > > >>If I recall > >>correctly, > >>(someone will let me know if not;) PPP rides on top of HDLC. > >You definately know more details than I but I did a quick > search and > the second item on this URL mentions the PPP/HDLC relationship > so I > somewhat in the ballpark no? ;) OK, in the ballpark. :-) One way to look at it is that PPP specifies the 2-byte protocol field, but then uses an HDLC-like header for the other parts. The older RFC for PPP (1331) specifies the PPP header: Flag 1 byte (0110) Address 1 byte Control 1 byte Protocol 2 bytes (not present in most HDLC derivatives, though added by Cisco for Cisco HDLC) info (variable) FCS 2 bytes Flag 1 byte (0110) The current RFC for PPP (1661) just says this: "encapsulation requires framing to indicate the beginning and end of the encapsulation. Methods of providing framing are specified in companion documents." Real helpful. :-) Sort of implies you could do something shorter if desired, though? Now, notice that if you do use the wording that "PPP rides on top of HDLC," as you did, it's not quite right and it's referring to the generic HDLC, not Cisco HDLC. Cisco HDLC just has this: Address - 1 byte Control - 1 bytes Protocol - 2 bytes It's curious that Cisco HDLC doesn't have the flag fields. Maybe they just aren't mentioned in the only document I have on Cisco HDLC?? The 0x7E flag is present in most derivatives of HDLC, including SDLC. It's used to signal the beginning and end of a frame and can be sent multiple times and during silence to keep the link up, from what I remember. Howard would know for sure, but I thought it was necessary in order for the other end to synch up. Don't cringe, Howard. :-) Bit stuffing is required to make sure it doesn't show up in the actual data. Well, that might explain why Cisco dropped it! Priscilla > > > http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ppp.htm > > Dave > > > > > > > I would be glad to correct you. :-) > > > > HDLC is really more of an architecture than a specific > protocol and there > > are many derivatives of it. PPP is just one of them, as is > Cisco's HDLC. > > Other derivitaves include LAPB, LAPD, and LLC2. > > > > The standard PPP and Cisco HDLC are so similar in frame > format you can > > barely tell them apart. > > > > Cisco HDLC encapsulation has: > > > > one-byte address field, which is set to 0x0F for most frames > > one-byte control byte that is always set to 0x00 > > two-byte protocol type field > > > > > > Guess what PPP has? Essentially the exact same thing: > > > > one-byte flag field set to 0x7F > > one-byte address field, set to 0x11 > > one-byte control field set to 0xC0 > > one or two-byte protocol field > > > > > > Both HDLC and PPP also have a control protocol for keeping > the link up. HDLC > > has SLARP. It sends keepalives. PPP has the Link Control > Protocol. It brings > > the link up and send echos and echo replies. > > > > Cisco HDLC can also use SLARP to assign an IP address to the > other end. > > > > PPP has the Network Control Protocols in many different > varieties. The IP > > variety can assign IP addresses. > > > > PPP also supports authentication, which Cisco HDLC doesn't. > > > > ___ > > > > Priscilla Oppenheimer > > www.troubleshootingnetworks.com > > www.priscilla.com > > > > > > > > > >>> > >>> > >>>If so is it just a case of changing the Encapsulation PPP to > >>>Encapsulation HDLC on both ends of the link? > >> > >> Assuming you have a Cisco on both ends, yes. > >> > >> > >>> > >>> > >>>Are there any implications I should be aware of?
Re: PPP vs HDLC [7:64362]
By the way, the document I have on Cisco HDLC (which I can no longer find on a Web site) not only doesn't mention any flags but also doesn't mention an FCS. It must have an FCS. We know it drops bad frames. Cisco HDLC is starting to sound as big as PPP! :-) I'm not sure it really wins in the "who has a shorter header/trailer war." I think there's a good chance it really does have the flags and I'm sure it has an FCS, which would make it the same size as PPP's header/trailer. Oh, I would kill for a WAN sniffer! :-) Priscilla Priscilla Oppenheimer wrote: > > MADMAN wrote: > > > > Priscilla Oppenheimer wrote: > > > MADMAN wrote: > > > > > >>Stuart Pittwood wrote: > > >> > > >>>It has been mooted to me that we might get better > performance > > >> > > >>from our > > >> > > >>>1Mb line by using HDLC rather than PPP. > > >>> > > >>> > > >>> > > >>>Is this correct? > > >> > > >> HDLC is more efficient so I guess yes. > > > > > > > > > In what way is HDLC more efficient than PPP? > > > >Since there is a little less overhead it is more efficient > > but not to > > the extent that one should be concerned. > > Cisco HDLC may have a couple bytes less than PPP in its header. > Not a big deal, as you say. > > > > > > > > > >>If I recall > > >>correctly, > > >>(someone will let me know if not;) PPP rides on top of HDLC. > > > >You definately know more details than I but I did a quick > > search and > > the second item on this URL mentions the PPP/HDLC relationship > > so I > > somewhat in the ballpark no? ;) > > OK, in the ballpark. :-) One way to look at it is that PPP > specifies the 2-byte protocol field, but then uses an HDLC-like > header for the other parts. The older RFC for PPP (1331) > specifies the PPP header: > > Flag 1 byte (0110) > Address 1 byte > Control 1 byte > Protocol 2 bytes (not present in most HDLC derivatives, though > added by Cisco for Cisco HDLC) > info (variable) > FCS 2 bytes > Flag 1 byte (0110) > > The current RFC for PPP (1661) just says this: > > "encapsulation requires framing to indicate the beginning and > end of the encapsulation. Methods of providing framing are > specified in companion documents." > > Real helpful. :-) Sort of implies you could do something > shorter if desired, though? > > Now, notice that if you do use the wording that "PPP rides on > top of HDLC," as you did, it's not quite right and it's > referring to the generic HDLC, not Cisco HDLC. Cisco HDLC just > has this: > > Address - 1 byte > Control - 1 bytes > Protocol - 2 bytes > > It's curious that Cisco HDLC doesn't have the flag fields. > Maybe they just aren't mentioned in the only document I have on > Cisco HDLC?? The 0x7E flag is present in most derivatives of > HDLC, including SDLC. It's used to signal the beginning and end > of a frame and can be sent multiple times and during silence to > keep the link up, from what I remember. Howard would know for > sure, but I thought it was necessary in order for the other end > to synch up. Don't cringe, Howard. :-) Bit stuffing is required > to make sure it doesn't show up in the actual data. Well, that > might explain why Cisco dropped it! > > Priscilla > > > > > > > > http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ppp.htm > > > >Dave > > > > > > > > > > > I would be glad to correct you. :-) > > > > > > HDLC is really more of an architecture than a specific > > protocol and there > > > are many derivatives of it. PPP is just one of them, as is > > Cisco's HDLC. > > > Other derivitaves include LAPB, LAPD, and LLC2. > > > > > > The standard PPP and Cisco HDLC are so similar in frame > > format you can > > > barely tell them apart. > > > > > > Cisco HDLC encapsulation has: > > > > > > one-byte address field, which is set to 0x0F for most > frames > > > one-byte control byte that is always set to 0x00 > > > two-byte protocol type field > > > > > > > > > Guess what PPP has? Essentially the exact same thing: > > > > > > one-byte flag field set to 0x7F > > > one-byte address field, set to 0x11 > > > one-byte control field set to 0xC0
Re: PPP vs HDLC [7:64362]
Priscilla Oppenheimer wrote: > > MADMAN wrote: > > > > Priscilla Oppenheimer wrote: > > > MADMAN wrote: > > > > > >>Stuart Pittwood wrote: > > >> > > >>>It has been mooted to me that we might get better > performance > > >> > > >>from our > > >> > > >>>1Mb line by using HDLC rather than PPP. > > >>> > > >>> > > >>> > > >>>Is this correct? > > >> > > >> HDLC is more efficient so I guess yes. > > > > > > > > > In what way is HDLC more efficient than PPP? > > > >Since there is a little less overhead it is more efficient > > but not to > > the extent that one should be concerned. > > Cisco HDLC may have a couple bytes less than PPP in its header. > Not a big deal, as you say. > > > > > > > > > >>If I recall > > >>correctly, > > >>(someone will let me know if not;) PPP rides on top of HDLC. > > > >You definately know more details than I but I did a quick > > search and > > the second item on this URL mentions the PPP/HDLC relationship > > so I > > somewhat in the ballpark no? ;) > > OK, in the ballpark. :-) One way to look at it is that PPP > specifies the 2-byte protocol field, but then uses an HDLC-like > header for the other parts. The older RFC for PPP (1331) > specifies the PPP header: > > Flag 1 byte (0110) > Address 1 byte > Control 1 byte > Protocol 2 bytes (not present in most HDLC derivatives, though > added by Cisco for Cisco HDLC) > info (variable) > FCS 2 bytes > Flag 1 byte (0110) > > The current RFC for PPP (1661) just says this: > > "encapsulation requires framing to indicate the beginning and > end of the encapsulation. Methods of providing framing are > specified in companion documents." > > Real helpful. :-) Sort of implies you could do something > shorter if desired, though? > > Now, notice that if you do use the wording that "PPP rides on > top of HDLC," as you did, it's not quite right and it's > referring to the generic HDLC, not Cisco HDLC. Cisco HDLC just > has this: > > Address - 1 byte > Control - 1 bytes > Protocol - 2 bytes > > It's curious that Cisco HDLC doesn't have the flag fields. > Maybe they just aren't mentioned in the only document I have on > Cisco HDLC?? The 0x7E flag is present in most derivatives of > HDLC, including SDLC. It's used to signal the beginning and end > of a frame and can be sent multiple times and during silence to > keep the link up, from what I remember. Every HDLC derivative I've ever worked with uses the ol' 7E7E idle pattern. Next time I have an o'scope out, I'll take a peek at a Cisco HDLC encapsulated link. >Howard would know for > sure, but I thought it was necessary in order for the other end > to synch up. Than's the general idea. You don't want to wait until there's data to be transferred before declaring protocol down. Loss of, say, three consecutive idles can trigger a protocol down condition. > Don't cringe, Howard. :-) Bit stuffing is required > to make sure it doesn't show up in the actual data. Well, that > might explain why Cisco dropped it! > > Priscilla > > > > > > > > http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ppp.htm > > > >Dave > > > > > > > > > > > I would be glad to correct you. :-) > > > > > > HDLC is really more of an architecture than a specific > > protocol and there > > > are many derivatives of it. PPP is just one of them, as is > > Cisco's HDLC. > > > Other derivitaves include LAPB, LAPD, and LLC2. > > > > > > The standard PPP and Cisco HDLC are so similar in frame > > format you can > > > barely tell them apart. > > > > > > Cisco HDLC encapsulation has: > > > > > > one-byte address field, which is set to 0x0F for most > frames > > > one-byte control byte that is always set to 0x00 > > > two-byte protocol type field > > > > > > > > > Guess what PPP has? Essentially the exact same thing: > > > > > > one-byte flag field set to 0x7F > > > one-byte address field, set to 0x11 > > > one-byte control field set to 0xC0 > > > one or two-byte protocol field > > > > > > > > > Both HDLC and PPP also have a control protocol for keeping > > the link
Re: PPP vs HDLC [7:64362]
Priscilla Oppenheimer wrote: > > s vermill wrote: > >> Cisco HDLC just > > > has this: > > > > > > Address - 1 byte > > > Control - 1 bytes > > > Protocol - 2 bytes > > > > > > It's curious that Cisco HDLC doesn't have the flag fields. > > > Maybe they just aren't mentioned in the only document I have > > on > > > Cisco HDLC?? The 0x7E flag is present in most derivatives of > > > HDLC, including SDLC. It's used to signal the beginning and > > end > > > of a frame and can be sent multiple times and during silence > > to > > > keep the link up, from what I remember. > > > > Every HDLC derivative I've ever worked with uses the ol' 7E7E > > idle pattern. Next time I have an o'scope out, I'll take a > > peek at a Cisco HDLC encapsulated link. > > Oh, yes, do please get your scope out! :-) I'm really curious > about Cisco HDLC and expect the doc I have doesn't tell the > whole story. > > I wonder if a scope would strip out the flags, sort of like an > Ethernet analyzer doesn't show the preamble, though. Priscilla, Most WAN protocol analyzers can be set to sync on 7E7E. Further, most can be set to blank the idle pattern from the display (whether 7E7E or something else). An o'scope, on the other hand, is completely protocol unaware. It simply deflects a trace horizontally and vertically based on time and signal amplitude, respectively. A typical HDLC idle on an o'scope looks like (hopefully this will align somewhat): | || |_ This assumes a "negative mark" environment. What you see are six bit times at the mark condition (no voltage) and two bit times at the space condition (positive voltage), repeated again, and then followed by some quiet period. I can't remember how many quite bit times there are between 7E7E idles. Pretty sure it's one 7E7E flag per frame interval (in other words, a frame of all zeros follows the flag). You can get an estimate of what an o'scope trace of a digital pattern will be by simply converting the hex to binary and visualizing the ones and zeros as the simple voltage/no voltage conditions that they really are. I'll see if we have a scope handy in one of the labs soon and fire up a Cisco HDLC interface. I suspect I'll see the 7E7E. > > THANKS > > Priscilla > > > > > >Howard would know for > > > sure, but I thought it was necessary in order for the other > > end > > > to synch up. > > > > Than's the general idea. You don't want to wait until there's > > data to be transferred before declaring protocol down. Loss > > of, say, three consecutive idles can trigger a protocol down > > condition. > > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=64666&t=64362 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: PPP vs HDLC [7:64362]
Hmm. Well maybe I didn't really want you to get your scope out then, but rather a protocol analyzer. That didn't sound as "appealing" though. :-) I'm most interested in the fields in the Cisco HDLC header. OK, I guess I'm curious about the signal too, now that you picqued my interest! It occurs to me that on another thread I mentioned that we could discuss just about anything on this list, except maybe the ones and zeros sent across a line, and here we are discussing the ones and zeros! I love it. THANKS Priscilla s vermill wrote: > > Priscilla Oppenheimer wrote: > > > > s vermill wrote: > > >> Cisco HDLC just > > > > has this: > > > > > > > > Address - 1 byte > > > > Control - 1 bytes > > > > Protocol - 2 bytes > > > > > > > > It's curious that Cisco HDLC doesn't have the flag fields. > > > > Maybe they just aren't mentioned in the only document I > have > > > on > > > > Cisco HDLC?? The 0x7E flag is present in most derivatives > of > > > > HDLC, including SDLC. It's used to signal the beginning > and > > > end > > > > of a frame and can be sent multiple times and during > silence > > > to > > > > keep the link up, from what I remember. > > > > > > Every HDLC derivative I've ever worked with uses the ol' > 7E7E > > > idle pattern. Next time I have an o'scope out, I'll take a > > > peek at a Cisco HDLC encapsulated link. > > > > Oh, yes, do please get your scope out! :-) I'm really curious > > about Cisco HDLC and expect the doc I have doesn't tell the > > whole story. > > > > I wonder if a scope would strip out the flags, sort of like an > > Ethernet analyzer doesn't show the preamble, though. > > Priscilla, > > Most WAN protocol analyzers can be set to sync on 7E7E. > Further, most can be set to blank the idle pattern from the > display (whether 7E7E or something else). An o'scope, on the > other hand, is completely protocol unaware. It simply deflects > a trace horizontally and vertically based on time and signal > amplitude, respectively. A typical HDLC idle on an o'scope > looks like (hopefully this will align somewhat): > > > | || > |_ > > > This assumes a "negative mark" environment. What you see are > six bit times at the mark condition (no voltage) and two bit > times at the space condition (positive voltage), repeated > again, and then followed by some quiet period. I can't > remember how many quite bit times there are between 7E7E > idles. Pretty sure it's one 7E7E flag per frame interval (in > other words, a frame of all zeros follows the flag). > > You can get an estimate of what an o'scope trace of a digital > pattern will be by simply converting the hex to binary and > visualizing the ones and zeros as the simple voltage/no voltage > conditions that they really are. I'll see if we have a scope > handy in one of the labs soon and fire up a Cisco HDLC > interface. I suspect I'll see the 7E7E. > > > > > THANKS > > > > Priscilla > > > > > > > > >Howard would know for > > > > sure, but I thought it was necessary in order for the > other > > > end > > > > to synch up. > > > > > > Than's the general idea. You don't want to wait until > there's > > > data to be transferred before declaring protocol down. Loss > > > of, say, three consecutive idles can trigger a protocol down > > > condition. > > > > > > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=64676&t=64362 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: PPP vs HDLC [7:64362]
s vermill wrote: >> Cisco HDLC just > > has this: > > > > Address - 1 byte > > Control - 1 bytes > > Protocol - 2 bytes > > > > It's curious that Cisco HDLC doesn't have the flag fields. > > Maybe they just aren't mentioned in the only document I have > on > > Cisco HDLC?? The 0x7E flag is present in most derivatives of > > HDLC, including SDLC. It's used to signal the beginning and > end > > of a frame and can be sent multiple times and during silence > to > > keep the link up, from what I remember. > > Every HDLC derivative I've ever worked with uses the ol' 7E7E > idle pattern. Next time I have an o'scope out, I'll take a > peek at a Cisco HDLC encapsulated link. Oh, yes, do please get your scope out! :-) I'm really curious about Cisco HDLC and expect the doc I have doesn't tell the whole story. I wonder if a scope would strip out the flags, sort of like an Ethernet analyzer doesn't show the preamble, though. THANKS Priscilla > > >Howard would know for > > sure, but I thought it was necessary in order for the other > end > > to synch up. > > Than's the general idea. You don't want to wait until there's > data to be transferred before declaring protocol down. Loss > of, say, three consecutive idles can trigger a protocol down > condition. > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=64657&t=64362 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: PPP vs HDLC [7:64362]
>Hmm. Well maybe I didn't really want you to get your scope out then, but >rather a protocol analyzer. That didn't sound as "appealing" though. :-) > >I'm most interested in the fields in the Cisco HDLC header. OK, I guess I'm >curious about the signal too, now that you picqued my interest! > >It occurs to me that on another thread I mentioned that we could discuss >just about anything on this list, except maybe the ones and zeros sent >across a line, and here we are discussing the ones and zeros! I love it. > >THANKS > >Priscilla Why limit to ones and zeroes? How about -3 to +3 volts on RS-232? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=64686&t=64362 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: PPP vs HDLC [7:64362]
I guess my understaning is limited, so I'm interested in hearing the results of this also. I've seen the flags left off of various protocols before, but I assumed they were simply being sloppy. I can't understand how any protocol could be transmitted without any flag/preamble at all. scott ""Priscilla Oppenheimer"" wrote in message news:[EMAIL PROTECTED] > s vermill wrote: > >> Cisco HDLC just > > > has this: > > > > > > Address - 1 byte > > > Control - 1 bytes > > > Protocol - 2 bytes > > > > > > It's curious that Cisco HDLC doesn't have the flag fields. > > > Maybe they just aren't mentioned in the only document I have > > on > > > Cisco HDLC?? The 0x7E flag is present in most derivatives of > > > HDLC, including SDLC. It's used to signal the beginning and > > end > > > of a frame and can be sent multiple times and during silence > > to > > > keep the link up, from what I remember. > > > > Every HDLC derivative I've ever worked with uses the ol' 7E7E > > idle pattern. Next time I have an o'scope out, I'll take a > > peek at a Cisco HDLC encapsulated link. > > Oh, yes, do please get your scope out! :-) I'm really curious about Cisco > HDLC and expect the doc I have doesn't tell the whole story. > > I wonder if a scope would strip out the flags, sort of like an Ethernet > analyzer doesn't show the preamble, though. > > THANKS > > Priscilla > > > > > >Howard would know for > > > sure, but I thought it was necessary in order for the other > > end > > > to synch up. > > > > Than's the general idea. You don't want to wait until there's > > data to be transferred before declaring protocol down. Loss > > of, say, three consecutive idles can trigger a protocol down > > condition. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=64736&t=64362 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: PPP vs HDLC [7:64362]
Howard C. Berkowitz wrote: > > >Hmm. Well maybe I didn't really want you to get your scope out > then, but > >rather a protocol analyzer. That didn't sound as "appealing" > though. :-) > > > >I'm most interested in the fields in the Cisco HDLC header. > OK, I guess I'm > >curious about the signal too, now that you picqued my interest! > > > >It occurs to me that on another thread I mentioned that we > could discuss > >just about anything on this list, except maybe the ones and > zeros sent > >across a line, and here we are discussing the ones and zeros! > I love it. > > > >THANKS > > > >Priscilla > Why limit to ones and zeroes? How about -3 to +3 volts on > RS-232? > > Hey...that's the infamous "transition region" that is neither a one nor a zero! No fair. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=64743&t=64362 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: PPP vs HDLC [7:64362]
Priscilla Oppenheimer wrote: > > Hmm. Well maybe I didn't really want you to get your scope out > then, but rather a protocol analyzer. That didn't sound as > "appealing" though. :-) > > I'm most interested in the fields in the Cisco HDLC header. OK, > I guess I'm curious about the signal too, now that you picqued > my interest! We used to have a good number of WAN PAs laying around, but not anymore. So they're more difficult for me to get my hands on in a lab environment (they're usually out making money somewhere). I've been looking at this sort of thing on o'scopes long enough that I know a 7E7E when I see it. I'll be setting this up in next few hours if there is, in fact, a scope in the "tool crib." > > It occurs to me that on another thread I mentioned that we > could discuss just about anything on this list, except maybe > the ones and zeros sent across a line, and here we are > discussing the ones and zeros! I love it. Understanding the nuts and bolts of ones and zeros transmission isn't terribly difficult once you've been around it a while (but not to be taken for granted!). Not too many folks bother or have the test equipment + opportunity, though. That leaves a profitable niche market out there -- especially if you truly understand timing and synchronization of serial comm. Again, not terribly difficult but rare these days. I love it too! > > THANKS > > Priscilla > > > s vermill wrote: > > > > Priscilla Oppenheimer wrote: > > > > > > s vermill wrote: > > > >> Cisco HDLC just > > > > > has this: > > > > > > > > > > Address - 1 byte > > > > > Control - 1 bytes > > > > > Protocol - 2 bytes > > > > > > > > > > It's curious that Cisco HDLC doesn't have the flag > fields. > > > > > Maybe they just aren't mentioned in the only document I > > have > > > > on > > > > > Cisco HDLC?? The 0x7E flag is present in most > derivatives > > of > > > > > HDLC, including SDLC. It's used to signal the beginning > > and > > > > end > > > > > of a frame and can be sent multiple times and during > > silence > > > > to > > > > > keep the link up, from what I remember. > > > > > > > > Every HDLC derivative I've ever worked with uses the ol' > > 7E7E > > > > idle pattern. Next time I have an o'scope out, I'll take > a > > > > peek at a Cisco HDLC encapsulated link. > > > > > > Oh, yes, do please get your scope out! :-) I'm really > curious > > > about Cisco HDLC and expect the doc I have doesn't tell the > > > whole story. > > > > > > I wonder if a scope would strip out the flags, sort of like > an > > > Ethernet analyzer doesn't show the preamble, though. > > > > Priscilla, > > > > Most WAN protocol analyzers can be set to sync on 7E7E. > > Further, most can be set to blank the idle pattern from the > > display (whether 7E7E or something else). An o'scope, on the > > other hand, is completely protocol unaware. It simply > deflects > > a trace horizontally and vertically based on time and signal > > amplitude, respectively. A typical HDLC idle on an o'scope > > looks like (hopefully this will align somewhat): > > > > > > | || > > |_ > > > > > > This assumes a "negative mark" environment. What you see are > > six bit times at the mark condition (no voltage) and two bit > > times at the space condition (positive voltage), repeated > > again, and then followed by some quiet period. I can't > > remember how many quite bit times there are between 7E7E > > idles. Pretty sure it's one 7E7E flag per frame interval (in > > other words, a frame of all zeros follows the flag). > > > > You can get an estimate of what an o'scope trace of a digital > > pattern will be by simply converting the hex to binary and > > visualizing the ones and zeros as the simple voltage/no > voltage > > conditions that they really are. I'll see if we have a scope > > handy in one of the labs soon and fire up a Cisco HDLC > > interface. I suspect I'll see the 7E7E. > > > > > > > > THANKS > > > > > > Priscilla > > > > > > > > > > > >Howard would know for > > > > > sure, but I thought it was necessary in order for the > > other > > > > end > > > > > to synch up. > > > > > > > > Than's the general idea. You don't want to wait until > > there's > > > > data to be transferred before declaring protocol down. > Loss > > > > of, say, three consecutive idles can trigger a protocol > down > > > > condition. > > > > > > > > > > > > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=64744&t=64362 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
PPP encapsulation over HDLC [7:25912]
Hello group, I have a configuration on a router that does "ppp encapsulation" over a serial line. Our operator is running HDLC on the line. On this line we get some CRC errors from time to time. Can this configuration be responsible for the CRC errors? Is it correct to run "ppp encapsulation" over hdlc lines? Thank you group Rock BASSOLE Til: +33 (0) 1 45 96 22 03 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=25912&t=25912 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: HDLC STAC Compression [7:56073]
I have applied that command on Cisco Router in a live network. It increases bandwidth that 64k to 128 Kbps. I have tested it works by ping response times and file transfer. It really works... Tim Champion wrote: >Is anyone out there using STAC compression on HDLC links in a live network? >If so what is the maximum speed link you would apply it to and has it >brought significant benefits. > >Many thanks in advance > >Tim Champion -- Metin YILDIZLI SEKOM Iletisim Sistemleri Fulya Mahallesi Akincibayiri Sokak No:10/1 Mecidiyekvy /ISTANBUL Tel: (90) 212 2889352 Fax: (90) 212 2674961 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=56075&t=56073 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: HDLC STAC Compression [7:56073]
What router models did you enable it on, and what sort of traffic goes over the link? -Original Message- From: Metin YILDIZLI [mailto:metin@;sekom.com.tr] Sent: 22 October 2002 12:06 To: [EMAIL PROTECTED] Subject: Re: HDLC STAC Compression [7:56073] I have applied that command on Cisco Router in a live network. It increases bandwidth that 64k to 128 Kbps. I have tested it works by ping response times and file transfer. It really works... Tim Champion wrote: >Is anyone out there using STAC compression on HDLC links in a live >network? If so what is the maximum speed link you would apply it to and >has it brought significant benefits. > >Many thanks in advance > >Tim Champion -- Metin YILDIZLI SEKOM Iletisim Sistemleri Fulya Mahallesi Akincibayiri Sokak No:10/1 Mecidiyekvy /ISTANBUL Tel: (90) 212 2889352 Fax: (90) 212 2674961 = This email has been content filtered and subject to spam filtering. If you consider this email is unsolicited please forward the email to [EMAIL PROTECTED] and request that the sender's domain be blocked from sending any further emails. = Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=56079&t=56073 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Question Regarding HDLC [7:60337]
WAN compression usually compresses the data payload. The HDLC sequence numbers are not in data packets; they are in keepalive packets. They are in the control plane, not the user plane. I can't say for sure, but my guess is that they are not compressed. If they were, the interfaces wouldn't have a way to monitor the status of the link. What does Cisco documentation say? Sorry I'm in a rush and can't look it up. Good question! Thanks for returning the forum to something meaningfull. Priscilla Simmi Singla wrote: > > Hi All, > I have question regarding HDLC,a silly question but still a > doubt.See I have HDLC connection back to back.on one interface > I configure compression and other interface on other router no > compression.Now when I debug the my seq and mine seen no.s are > in sync I mean same they inncrease ,that different no layer 3 > communication I am able to do.If such case occurs how from > debug commands I will come to know. > I enabled debug serial interface but it only shows me that the > no get increment that too in proper order but I have read that > in Karl Solie book Vol1 that it will stop increment the > keepalives. > So can anybody guide me. > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=60356&t=60337 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Question Regarding HDLC [7:60337]
""Priscilla Oppenheimer"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > WAN compression usually compresses the data payload. The HDLC sequence > numbers are not in data packets; they are in keepalive packets. They are in > the control plane, not the user plane. > > I can't say for sure, but my guess is that they are not compressed. If they > were, the interfaces wouldn't have a way to monitor the status of the link. > What does Cisco documentation say? Sorry I'm in a rush and can't look it up. I checked the 12.1 docs. no help there. both the config guide and the command reference talk about "frame compression" I "believe" the implication is that the data itself is compressed, but the frame header is not. Separately, there are sections on RTP header compression, but that is a different issue. Let me step out on a limb here and postulate that in terms of process, the router first compresses the data, then attaches the HDLC frame. Much the same way that when compression is uese on the LAN, the data is compressed, but the L2 header is not. Anyone snifed this and have a scientific answer? > > Good question! Thanks for returning the forum to something meaningfull. > > Priscilla > > Simmi Singla wrote: > > > > Hi All, > > I have question regarding HDLC,a silly question but still a > > doubt.See I have HDLC connection back to back.on one interface > > I configure compression and other interface on other router no > > compression.Now when I debug the my seq and mine seen no.s are > > in sync I mean same they inncrease ,that different no layer 3 > > communication I am able to do.If such case occurs how from > > debug commands I will come to know. > > I enabled debug serial interface but it only shows me that the > > no get increment that too in proper order but I have read that > > in Karl Solie book Vol1 that it will stop increment the > > keepalives. > > So can anybody guide me. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=60358&t=60337 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Question Regarding HDLC [7:60337]
HDLC sequences numbers aren't in data frames. They are in separate keepalive frames. They aren't like TCP sequence numbers, which sequence the data. They aren't in the header of the data frame. They are in separate frames in the control plane. Which, to make a long and winding story short, probably supports our theory that the Cisco HDLC sequence numbers are not compressed. But it's not possible to tell from Cisco documentation and sniffing is difficult because most of us can't afford a WAN sniffer. But I think that what the original poster is seeing may prove the point also. Priscilla The Long and Winding Road wrote: > > ""Priscilla Oppenheimer"" wrote in > message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > WAN compression usually compresses the data payload. The HDLC > sequence > > numbers are not in data packets; they are in keepalive > packets. They are > in > > the control plane, not the user plane. > > > > I can't say for sure, but my guess is that they are not > compressed. If > they > > were, the interfaces wouldn't have a way to monitor the > status of the > link. > > What does Cisco documentation say? Sorry I'm in a rush and > can't look it > up. > > > I checked the 12.1 docs. no help there. both the config guide > and the > command reference talk about "frame compression" I "believe" > the implication > is that the data itself is compressed, but the frame header is > not. > Separately, there are sections on RTP header compression, but > that is a > different issue. > > Let me step out on a limb here and postulate that in terms of > process, the > router first compresses the data, then attaches the HDLC frame. > Much the > same way that when compression is uese on the LAN, the data is > compressed, > but the L2 header is not. > > Anyone snifed this and have a scientific answer? > > > > > > > > Good question! Thanks for returning the forum to something > meaningfull. > > > > Priscilla > > > > Simmi Singla wrote: > > > > > > Hi All, > > > I have question regarding HDLC,a silly question but still a > > > doubt.See I have HDLC connection back to back.on one > interface > > > I configure compression and other interface on other router > no > > > compression.Now when I debug the my seq and mine seen no.s > are > > > in sync I mean same they inncrease ,that different no layer > 3 > > > communication I am able to do.If such case occurs how from > > > debug commands I will come to know. > > > I enabled debug serial interface but it only shows me that > the > > > no get increment that too in proper order but I have read > that > > > in Karl Solie book Vol1 that it will stop increment the > > > keepalives. > > > So can anybody guide me. > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=60364&t=60337 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: HDLC and Routing protocols [7:5739]
Are you treating them as NBMA ??? - Original Message - From: Rizzo Damian To: Sent: Thursday, May 24, 2001 10:49 AM Subject: HDLC and Routing protocols [7:5739] > Anyone know why I would have problems with apparently ANY routing > protocol over an HDLC point-to-point Link? Works fine with static routes, > but when I try to implement any routing protocol (RIP, EIGRP, OSPF, etc..) > they don't seem to work (no routes discovered). Am I missing something? > Thanks! > > -Rizzo > FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=5743&t=5739 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: HDLC and Routing protocols [7:5739]
Not to be rude or anything, but did you turn on IP routing? Darel R Graham -Original Message- From: Rizzo Damian [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 24, 2001 10:49 AM To: [EMAIL PROTECTED] Subject: HDLC and Routing protocols [7:5739] Anyone know why I would have problems with apparently ANY routing protocol over an HDLC point-to-point Link? Works fine with static routes, but when I try to implement any routing protocol (RIP, EIGRP, OSPF, etc..) they don't seem to work (no routes discovered). Am I missing something? Thanks! -Rizzo FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=5747&t=5739 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: PPP or HDLC pros and cons
ppp is generic HDLC is cisco propriatory.. Andrew Larkins BCom, CCNA Usko Communications Tel: +2711 800-9300 Fax: +2711 800-9495/6/7/8/9 Cell: +2783-656-7214 Email: [EMAIL PROTECTED] OR [EMAIL PROTECTED] “This message may contain information which is confidential and subject to legal privilege. If you are not the intended recipient, you may not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify the sender immediately by email, facsimile or telephone and return and/or destroy the original message.” -Original Message- From: John Zaggat [mailto:[EMAIL PROTECTED]] Sent: 15 June 2000 04:44 To: CiscoGroupstudy Subject: PPP or HDLC pros and cons Hi guys, In a point to point T1 link what would be advantages or disadvantages of using HDLC vs PPP. Thank you = JZ [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: PPP or HDLC pros and cons
Keep in mind that if you use HDLC, you have to be sticking with a particular vendor... HDLC is a little better for troubleshooting...but my pref is to use PPP. That way you can use things like PPP CHAP authentication and other neat features of PPP. stanford "John Zaggat" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Hi guys, > In a point to point T1 link what would be advantages > or disadvantages of using HDLC vs PPP. > Thank you > > = > JZ > [EMAIL PROTECTED] > > > > __ > Do You Yahoo!? > Yahoo! Photos -- now, 100 FREE prints! > http://photos.yahoo.com > > ___ > UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html > FAQ, list archives, and subscription info: http://www.groupstudy.com > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > --- ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
HDLC, line protocols, and keepalives. [7:62928]
All, I'm having a problem that I don't understand and I was hoping someone out there might be able to give me some insight. I have a 2503 with an HDLC connection on Serial0 going out to my service provider. The running-config is very basic (sanitized, of course): version 11.2 ! ip subnet-zero ! interface Serial0 ip address x.x.x.18 255.255.255.252 keepalive 9 no fair-queue ! interface Serial1 shutdown ! interface BRI0 no ip address shutdown ! router eigrp 100 network 10.0.0.0 ! no ip classless ! bridge 11 protocol ieee end The problem I am having is that the line protocol is bouncing, but neither my provider nor I can find a problem. I have swapped all the cables AND the router, but the problem persists. I noticed that the line protocol goes down for 9 seconds, then is up for 18 seconds, then the cycle repeats. For S&G, I lowered the keepalives to 2 seconds; sure enough, the line protocol dropped for 2 seconds, then was up for 4. By removing keepalives altogether, the circuit stays up! What is going on here? Am I missing something painfully obvious? Thanks! Geoff Mossburg Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62928&t=62928 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
DTE-DTE - PPP / HDLC Encap [7:24086]
hi i want to test the connection between two serial interfaces of a router back to back, without modems. i want the sample configuration from you friends, in testing this. Regards K. Sadagopan Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=24086&t=24086 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Illegal HDLC type code?? [7:25601]
This was my thought, as well, but the tech checked the encapsulation. It appears that the message says "HDLC" even if you have the interface set for HDLC, Frame Relay, or SDLC. I'd love to find a list of those type codes but I gave up after searching for about ten minutes using CCO, Hotbot, and Google. Thanks, John >>> "Priscilla Oppenheimer" 11/7/01 5:31:53 PM >>> Cisco's HDLC has a type field that is like an EtherType to identify the network layer. If you're really using SDLC, then this wouldn't apply, but maybe the router "forgot" that it was SDLC and went back to HDLC. Weirder things have happened! Priscilla At 03:52 PM 11/7/01, John Neiberger wrote: >I've never seen this one before and CCO isn't very helpful. We have an >ATM connected via SDLC to a 2610 router. It went belly up at some point >and debugging on the router reports an Illegal HDLC Type Code of 831. > >I've searched every site I could think of and can't find a list of >serial line type codes, assuming there even is such a beast. My guess >is that the ATM has lost its mind and isn't using SDLC any longer but >this has made me curious about this error message. > >Do any of you know how to find out more about these serial type codes? > >Thanks, >John Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=25683&t=25601 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: PPP encapsulation over HDLC [7:25912]
Rock - On a serial line, one generally runs either PPP, hdlc, or frame -- but only one! If the command "encapsulation ppp" is used, then that is your encapsulation type, not hdlc. The source of your errors is elsewhere. BASSOLE Rock wrote: > I have a configuration on a router that does "ppp encapsulation" over a > serial line. Our operator is running HDLC on the line. On this line we get > some CRC errors from time to time. Can this configuration be responsible for > the CRC errors? > > Is it correct to run "ppp encapsulation" over hdlc lines? A good starting point is to read up on troublshooting serial line problems you can do that at http://www.cisco.com/warp/public/112/chapter15.htm The article at this link suggests that you only worry if errors are more than about 1% of the traffic passed. -- Jason Boson BCMSN1 BSCN2 BSCI2 practice tests E-Quizware CCIE practice test Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=25916&t=25912 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
IP unnumbered for HDLC connection [7:62134]
HI All I have simple configuration of HDLC connected back to back. If i give ip unnumbered at one end and the static ip address at the other end, I cant ping the either end. But when i give show ip int brief, it shows the line and protocol are up. If i give ip unnumbered at both ends, now i am able to ping either end. could anybody help me out in this. Regards Deepak Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62134&t=62134 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: HDLC, line protocols, and keepalives. [7:62928]
It sure sounds like your service provider isn't using keepalives, i.e. has "no keepalive" configured on their serial interface. Both ends have to either be using keepalives or not, with the same timer. You would think that they would checked that, but the symptoms point to that being the problem. Let us know if that's not the case, though. In fact, let us know if you find out that it is the case! Thanks. Priscilla Mossburg, Geoff (MAN-Corporate) wrote: > > All, > I'm having a problem that I don't understand and I was hoping > someone out there might be able to give me some insight. I have > a 2503 with > an HDLC connection on Serial0 going out to my service provider. > The > running-config is very basic (sanitized, of course): > > version 11.2 > ! > ip subnet-zero > ! > interface Serial0 > ip address x.x.x.18 255.255.255.252 > keepalive 9 > no fair-queue > ! > interface Serial1 > shutdown > ! > interface BRI0 > no ip address > shutdown > ! > router eigrp 100 > network 10.0.0.0 > ! > no ip classless > ! > bridge 11 protocol ieee > end > > The problem I am having is that the line protocol is bouncing, > but neither > my provider nor I can find a problem. I have swapped all the > cables AND the > router, but the problem persists. I noticed that the line > protocol goes down > for 9 seconds, then is up for 18 seconds, then the cycle > repeats. For S&G, I > lowered the keepalives to 2 seconds; sure enough, the line > protocol dropped > for 2 seconds, then was up for 4. By removing keepalives > altogether, the > circuit stays up! What is going on here? Am I missing something > painfully > obvious? > Thanks! > Geoff Mossburg > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62935&t=62928 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: HDLC, line protocols, and keepalives. [7:62928]
As usual, you were absolutely correct Pricilla! The part which I didn't mention (because, for some reason, I figured that it was unimportant) was that this is an HDLC circuit going to my provider for a VPN circuit. They have a Nortel Shasta 5000 (essentially an IP multi-service edge router) and the tech confirmed that they do not have keepalives set on it. Thank you very much for your expertise! Geoff Mossburg -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 12, 2003 11:02 PM To: [EMAIL PROTECTED] Subject: RE: HDLC, line protocols, and keepalives. [7:62928] It sure sounds like your service provider isn't using keepalives, i.e. has "no keepalive" configured on their serial interface. Both ends have to either be using keepalives or not, with the same timer. You would think that they would checked that, but the symptoms point to that being the problem. Let us know if that's not the case, though. In fact, let us know if you find out that it is the case! Thanks. Priscilla Mossburg, Geoff (MAN-Corporate) wrote: > > All, > I'm having a problem that I don't understand and I was hoping > someone out there might be able to give me some insight. I have > a 2503 with > an HDLC connection on Serial0 going out to my service provider. > The > running-config is very basic (sanitized, of course): > > version 11.2 > ! > ip subnet-zero > ! > interface Serial0 > ip address x.x.x.18 255.255.255.252 > keepalive 9 > no fair-queue > ! > interface Serial1 > shutdown > ! > interface BRI0 > no ip address > shutdown > ! > router eigrp 100 > network 10.0.0.0 > ! > no ip classless > ! > bridge 11 protocol ieee > end > > The problem I am having is that the line protocol is bouncing, > but neither > my provider nor I can find a problem. I have swapped all the > cables AND the > router, but the problem persists. I noticed that the line > protocol goes down > for 9 seconds, then is up for 18 seconds, then the cycle > repeats. For S&G, I > lowered the keepalives to 2 seconds; sure enough, the line > protocol dropped > for 2 seconds, then was up for 4. By removing keepalives > altogether, the > circuit stays up! What is going on here? Am I missing something > painfully > obvious? > Thanks! > Geoff Mossburg Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62988&t=62928 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Final Conclusion Re: Question Regarding HDLC [7:60337]
Hi Priscilla/All, Thanx for the reply.all are absolutely right when keepalives are exchanged they are not compressed.i would like to mention here only keepalives.I debug the o/p again ,even the cdp frames are compressed. Like to share the Debug O/P with u all for dummy setup client--server(DCE) 1.1.1.1 1.1.1.2 cdp enabled cdp enabled Stac enabled no compression In this scenario the keepalives are exchanged properly and the link status also remains up. Debug all client side# 00:15:55: Serial0: HDLC myseq 27, mineseen 27*, yourseen 28, line up 00:15:55: Serial0: COMPRESS: (expansion) status: 6, size in: 20, size out: 14 00:15:57: CDP-PA: Packet received from server on interface Serial0 00:16:05: Serial0: HDLC myseq 28, mineseen 28*, yourseen 29, line up 00:16:05: Serial0: COMPRESS: (expansion) status: 6, size in: 20, size out: 14 00:16:15: Serial0: HDLC myseq 29, mineseen 29*, yourseen 30, line up 00:16:15: Serial0: COMPRESS: (expansion) status: 6, size in: 20, size out: 14PQU 00:16:25: Serial0: HDLC myseq 30, mineseen 30*, yourseen 31, line up 00:16:25: Serial0: COMPRESS: (expansion) status: 6, size in: 20, size out: 14PQU debug all server# *Mar 1 00:15:35.791: Serial0: HDLC myseq 27, mineseen 27*, yourseen 27, line up * *Mar 1 00:15:45.791: Serial0: HDLC myseq 28, mineseen 28*, yourseen 28, line up *Mar 1 00:15:55.791: Serial0: HDLC myseq 29, mineseen 29*, yourseen 29, line up *Mar 1 00:16:05.791: Serial0: HDLC myseq 30, mineseen 30*, yourseen 30, line up *Mar 1 00:16:08.815: crm_send_periodic_update *Mar 1 00:16:09.763: IP-ST: if_list try 0 *Mar 1 00:16:09.763: IP-ST: gw_list total 0, try 0, completed list TRUE *Mar 1 00:16:09.763: IP-Static: all_list, time elapsed 0 msPQUICC_FEC(0/0): PHY *Mar 1 00:16:15.791: Serial0: HDLC myseq 31, mineseen 31*, yourseen 31, line up *Mar 1 00:16:25.211: CDP-EV: Bad checksum in header *Mar 1 00:16:25.791: Serial0: HDLC myseq 32, mineseen 32*, yourseen 32, line up See the Cdp Bad checksum error in header. client side# sh cdp nei Device IDLocal Intrfce HoldtmeCapability Platform Port ID server Ser 0 171 R1721 Ser 0 This Indicates that still I can accept Uncompressed packets although compression is enabled.But when it will send packets it will only send compressed packets. server side# sh cdp nei nothing is displayed Client side# ping 1.1.1.2(server) Server side#debug all *Mar 1 00:18:50.663: IP: s=120.7.3.160 (Serial0), d=32.64.1.230, len 6, dispose ip.formaterr *Mar 1 00:18:52.663: IP: s=112.7.3.160 (Serial0), d=32.64.1.214, len 6, dispose ip.formaterr *Mar 1 00:18:54.663: IP: s=104.7.3.160 (Serial0), d=32.64.1.200, len 6, dispose ip.formaterr *Mar 1 00:18:55.791: Serial0: HDLC myseq 47, mineseen 47*, yourseen 47, line up *Mar 1 00:18:56.663: IP: s=96.7.3.160 (Serial0), d=44.120.220.46, len 6, dispos e ip.formaterr * ial0: HDLC myseq 55, mineseen 55*, yourseen 55, line up Again the errors as it doesnot understand compressed data.But what are these ips ,ok the client before sending the packets on the interface have compressed the data thats why it shows strange ips after conversion.It is unable to decompress the data and displaying compressed data. anyway the question was whether keepalives are compressed are not so I used show compress which gave me the indication that no counters get incremented for compressed stats when keepalives are exchanged,but uncompressed sats were increasing that too with 20 byte increment that what i suspect is Compression stats messages which are exchanged although here on ine side command worked as compression was not enabled.this might not be a keepalive increment as keepalives as nothing to do with compression. Now for tcp header compression if enabled on one side I was unable to send tcp traffic from any side but we can ping as it doesnot use layer 4.. Thanx for all answers Bye Priscilla Oppenheimer wrote: > > HDLC sequences numbers aren't in data frames. They are in > separate keepalive frames. They aren't like TCP sequence > numbers, which sequence the data. They aren't in the header of > the data frame. They are in separate frames in the control plane. > > Which, to make a long and winding story short, probably > supports our theory that the Cisco HDLC sequence numbers are > not compressed. But it's not possible to tell from Cisco > documentation and sniffing is difficult because most of us > can't afford a WAN sniffer. But I think that what the original > poster is seeing may prove the point also. > > Priscilla > > The Long and Winding Road wrote: > > > > ""Priscilla Oppenheimer"" wrote in > > message > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > WAN compression usually compresses the data payload. The > HDLC > >
RE: IP unnumbered for HDLC connection [7:62134]
Hi Deepak When you configure "ip unnnumbered" on an interfaces it looks like an interface with a /0 mask. On the other side with a configured ip address on the interface you have a different mask. So the two connected interfaces don't belong to the same network. What you could do is to configure on the router with the static ip address a route outwards the connecting interface for the other router's network. But I have never tried this before. The interface an line protocol will come undependently of the configured ip address. see you Claudio Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62135&t=62134 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: IP unnumbered for HDLC connection [7:62134]
Hi Claudio Thanks for quick response. But i have tried that options. i defined a static ip route to the network on the other end through the connecting interface.it did work. But when i am using the routing protocol, i am not able to ping either end. But if i make the other end also unnumbered, n run the routing protocol, then i am able to ping either end. Regards Deepak Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62137&t=62134 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: IP unnumbered for HDLC connection [7:62134]
Which is failing to get to the other side? The ping (echo) or the ping reply (echo reply). Pinging could fail for either reason. Debug icmp and you might get more info. Also, send us your configs. Help us help you. Priscilla Deepak N wrote: > > Hi Claudio > Thanks for quick response. > But i have tried that options. i defined a static ip route > to the network on the other end through the connecting > interface.it did work. > But when i am using the routing protocol, i am not able to ping > either end. But if i make the other end also unnumbered, n run > the routing protocol, then i am able to ping either end. > > Regards > Deepak Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62142&t=62134 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: IP unnumbered for HDLC connection [7:62134]
Hi What kind of routing protocol are you using? Ospf can not build an adjacency this way. With other routing protocols you should be able to exchange routing tables. But you won't be able to send traffic, because the router does not know where the next-hop address is. So you still need this static route to tell the router where the next-hop address is reachable. see you Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62143&t=62134 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: IP unnumbered for HDLC connection [7:62134]
Hi all The following are the configurations of the routers and the ping outputs. I have given 3 cases. 1) When ip unnumbered at one end and static routes are defined sdmheadend#sh run Building configuration... Current configuration : 1115 bytes ! version 12.2 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname sdmheadend ! ! ! ! ip subnet-zero ! ! ! ip audit notify log ip audit po max-events 100 ! ! ! voice call carrier capacity active ! ! ! ! ! ! ! ! ! mta receive maximum-recipients 0 ! ! ! ! interface FastEthernet0/0 ip address 172.20.110.10 255.255.255.192 duplex auto speed auto ! interface FastEthernet0/1 no ip address shutdown duplex auto speed auto ! interface ATM1/0 no ip address shutdown no atm ilmi-keepalive dsl operating-mode auto no fair-queue ! interface FastEthernet1/0 no ip address shutdown duplex auto speed auto ! interface Serial1/0 ip address 12.12.12.1 255.255.255.0 no fair-queue clockrate 200 ! interface FastEthernet1/1 no ip address shutdown duplex auto speed auto ! interface Serial1/1 no ip address shutdown clockrate 200 ! ip classless ip route 200.200.200.0 255.255.255.0 Serial1/0 ip http server ! ! ! ! call rsvp-sync ! ! mgcp profile default ! dial-peer cor custom ! ! ! ! ! line con 0 line aux 0 line vty 0 4 ! ! end sdmheadend# ping 200.200.200.11 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 200.200.200.11, timeout is 2 seconds: ! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms sdmheadend# switchrouter#sh run Building configuration... Current configuration : 746 bytes ! version 12.2 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname switchrouter ! ! memory-size iomem 5 ip subnet-zero ! ! ! ip audit notify log ip audit po max-events 100 ip ssh time-out 120 ip ssh authentication-retries 3 ! ! ! ! ! ! ! ! ! ! ! interface Loopback0 ip address 200.200.200.11 255.255.255.0 ! interface FastEthernet0/0 no ip address shutdown speed auto ! interface Serial0/0 ip unnumbered Loopback0 no fair-queue ! interface Serial0/1 no ip address shutdown ! ip classless ip route 12.12.12.0 255.255.255.0 Serial0/0 no ip http server ip pim bidir-enable ! ! ! call rsvp-sync ! dial-peer cor custom ! ! ! ! line con 0 line aux 0 line vty 0 4 ! no scheduler allocate end switchrouter#ping 12.12.12.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 12.12.12.1, timeout is 2 seconds: ! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms switchrouter# 2) When routing protocol RIP is running sdmheadend#sh run Building configuration... Current configuration : 1099 bytes ! version 12.2 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname sdmheadend ! ! ! ! ip subnet-zero ! ! ! ip audit notify log ip audit po max-events 100 ! ! ! voice call carrier capacity active ! ! ! ! ! ! ! ! ! mta receive maximum-recipients 0 ! ! ! ! interface FastEthernet0/0 ip address 172.20.110.10 255.255.255.192 duplex auto speed auto ! interface FastEthernet0/1 no ip address shutdown duplex auto speed auto ! interface ATM1/0 no ip address shutdown no atm ilmi-keepalive dsl operating-mode auto no fair-queue ! interface FastEthernet1/0 no ip address shutdown duplex auto speed auto ! interface Serial1/0 ip address 12.12.12.1 255.255.255.0 no fair-queue clockrate 200 ! interface FastEthernet1/1 no ip address shutdown duplex auto speed auto ! interface Serial1/1 no ip address shutdown clockrate 200 ! router rip network 12.0.0.0 ! ip classless ip http server ! ! ! ! call rsvp-sync ! ! mgcp profile default ! dial-peer cor custom ! ! ! ! ! line con 0 line aux 0 line vty 0 4 ! ! end sdmheadend# ping 200.200.200.11 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 200.200.200.11, timeout is 2 seconds: . Success rate is 0 percent (0/5) sdmheadend# switchrouter#sh run Building configuration... Current configuration : 738 bytes ! version 12.2 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname switchrouter ! ! memory-size iomem 5 ip subnet-zero ! ! ! ip audit notify log ip audit po max-events 100 ip ssh time-out 120 ip ssh authentication-retries 3 ! ! ! ! ! ! ! ! ! ! ! interface Loopback0 ip address 200.200.200.11 255.255.255.0 ! interface FastEthernet0/0 no ip address shutdown speed auto ! interface Serial0/0 ip unnumbered Loopback0 no fair-queue ! interface Serial0/1 no ip address shutdown ! router rip network 200.200.200.0 ! ip classless no ip http server ip pim bidir-enable ! ! ! call rsvp-sync ! dial-peer cor custom ! ! ! ! line con 0 line aux 0 line vty 0 4 ! no scheduler allocate end switchrouter#ping 12.12.12.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 12.12.12.1, timeout is
RE: IP unnumbered for HDLC connection [7:62134]
Hi Give us a look at the routing table from both routers. The router with the configured ip address on the Serial interface does not know how to get to the next hop address. Do you see in the routing table the next-hop address or the outbound interface? see you Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62151&t=62134 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: IP unnumbered for HDLC connection [7:62134]
So it fails when you have numbered on one side and unnumbered on the other side and you are running RIP? What did "show ip route" tell you when the problem occured? Were the relevant routes in both routers' tables? What address does sdmheadend use to send the echo? If it's using 172.20.110.10, then it won't work because switchrouter doesn't have a route back to that. It only has a route back to 12.0.0.0? With extended ping you can set the ip address that the router should use. Also, enable debug ip icmp (on a non-operational router anyway) and see what's really happening. Also, see the last message from Claudio. It may have something to do with sdmheadend not having a valid next hop address since its next hop is unnumbered, but then we would expect when they are both unnumbered and the loopbacks are in different subnets, there would be a problem too, and there isn't. Anyway, "show ip route" should tell you a lot. Priscilla Deepak N wrote: > > Hi all > > The following are the configurations of the routers and the > ping outputs. > I have given 3 cases. > > 1) When ip unnumbered at one end and static routes are defined > > sdmheadend#sh run > Building configuration... > > Current configuration : 1115 bytes > ! > version 12.2 > service timestamps debug datetime msec > service timestamps log datetime msec > no service password-encryption > ! > hostname sdmheadend > ! > ! > ! > ! > ip subnet-zero > ! > ! > ! > ip audit notify log > ip audit po max-events 100 > ! > ! > ! > voice call carrier capacity active > ! > ! > ! > ! > ! > ! > ! > ! > ! > mta receive maximum-recipients 0 > ! > ! > ! > ! > interface FastEthernet0/0 > ip address 172.20.110.10 255.255.255.192 > duplex auto > speed auto > ! > interface FastEthernet0/1 > no ip address > shutdown > duplex auto > speed auto > ! > interface ATM1/0 > no ip address > shutdown > no atm ilmi-keepalive > dsl operating-mode auto > no fair-queue > ! > interface FastEthernet1/0 > no ip address > shutdown > duplex auto > speed auto > ! > interface Serial1/0 > ip address 12.12.12.1 255.255.255.0 > no fair-queue > clockrate 200 > ! > interface FastEthernet1/1 > no ip address > shutdown > duplex auto > speed auto > ! > interface Serial1/1 > no ip address > shutdown > clockrate 200 > ! > ip classless > ip route 200.200.200.0 255.255.255.0 Serial1/0 > ip http server > ! > ! > ! > ! > call rsvp-sync > ! > ! > mgcp profile default > ! > dial-peer cor custom > ! > ! > ! > ! > ! > line con 0 > line aux 0 > line vty 0 4 > ! > ! > end > > > sdmheadend# ping 200.200.200.11 > > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to 200.200.200.11, timeout is 2 > seconds: > ! > Success rate is 100 percent (5/5), round-trip min/avg/max = > 1/2/4 ms > sdmheadend# > > > > > > > switchrouter#sh run > Building configuration... > > Current configuration : 746 bytes > ! > version 12.2 > service timestamps debug uptime > service timestamps log uptime > no service password-encryption > ! > hostname switchrouter > ! > ! > memory-size iomem 5 > ip subnet-zero > ! > ! > ! > ip audit notify log > ip audit po max-events 100 > ip ssh time-out 120 > ip ssh authentication-retries 3 > ! > ! > ! > ! > ! > ! > ! > ! > ! > ! > ! > interface Loopback0 > ip address 200.200.200.11 255.255.255.0 > ! > interface FastEthernet0/0 > no ip address > shutdown > speed auto > ! > interface Serial0/0 > ip unnumbered Loopback0 > no fair-queue > ! > interface Serial0/1 > no ip address > shutdown > ! > ip classless > ip route 12.12.12.0 255.255.255.0 Serial0/0 > no ip http server > ip pim bidir-enable > ! > ! > ! > call rsvp-sync > ! > dial-peer cor custom > ! > ! > ! > ! > line con 0 > line aux 0 > line vty 0 4 > ! > no scheduler allocate > end > > switchrouter#ping 12.12.12.1 > > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to 12.12.12.1, timeout is 2 > seconds: > ! > Success rate is 100 percent (5/5), round-trip min/avg/max = > 1/2/4 ms > switchrouter# > > > > > > > > > > 2) When routing protocol RIP is running > > > sdmheadend#sh run > Building configuration... > > Current configuration : 1099 bytes > ! > version 12.2 > service timestamps debug datetime msec > service timestamps log datetime msec > no service password-encryption > ! > hostname sdmheadend > ! > ! > ! > ! > ip subnet-zero > ! > ! > ! > ip audit notify log > ip audit po max-events 100 > ! > ! > ! > voice call carrier capacity active > ! > ! > ! > ! > ! > ! > ! > ! > ! > mta receive maximum-recipients 0 > ! > ! > ! > ! > interface FastEthernet0/0 > ip address 172.20.110.10 255.255.255.192 > duplex auto > speed auto > ! > interface FastEthernet0/1 > no ip address > shutdown > duplex auto > speed auto > ! > interface ATM1/0 > no ip address > shutdown > no atm ilmi-keepalive > dsl operating-mode auto > no fair-queue > ! > interface FastEthernet1/0 > no ip address > shutdown > duplex auto > speed auto > ! > interface Serial1
RE: IP unnumbered for HDLC connection [7:62134]
HI Claudio Please find the following for the different cases i mentioned. Regards Deepak 1)When ip unnumbered at one end and static routes are defined sdmheadend#sh ip rou Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set S200.200.200.0/24 is directly connected, Serial1/0 172.20.0.0/26 is subnetted, 1 subnets C 172.20.110.0 is directly connected, FastEthernet0/0 12.0.0.0/24 is subnetted, 1 subnets C 12.12.12.0 is directly connected, Serial1/0 sdmheadend# switchrouter#sh ip rou Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set C200.200.200.0/24 is directly connected, Loopback0 12.0.0.0/24 is subnetted, 1 subnets S 12.12.12.0 is directly connected, Serial0/0 switchrouter# 2)When routing protocol RIP is running sdmheadend#sh ip rout Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set 172.20.0.0/26 is subnetted, 1 subnets C 172.20.110.0 is directly connected, FastEthernet0/0 12.0.0.0/24 is subnetted, 1 subnets C 12.12.12.0 is directly connected, Serial1/0 sdmheadend# switchrouter#sh ip rou Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set C200.200.200.0/24 is directly connected, Loopback0 switchrouter# 3)When both sides are unnumbered and running routing protocol sdmheadend#sh ip rou Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set R200.200.200.0/24 [120/1] via 200.200.200.11, 00:00:03, Serial1/0 20.0.0.0/24 is subnetted, 1 subnets C 20.20.20.0 is directly connected, Loopback0 172.20.0.0/26 is subnetted, 1 subnets C 172.20.110.0 is directly connected, FastEthernet0/0 sdmheadend# switchrouter#sh ip rou Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set C200.200.200.0/24 is directly connected, Loopback0 20.0.0.0/8 is variably subnetted, 2 subnets, 2 masks R 20.20.20.0/32 [120/1] via 20.20.20.1, 00:00:01, Serial0/0 R 20.0.0.0/8 [120/1] via 20.20.20.1, 00:00:01, Serial0/0 switchrouter# Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62157&t=62134 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: IP unnumbered for HDLC connection [7:62134]
Hi when i did debug ip icmp, i got the message that its unroutable when one end is numbered and the other end is unnumbered. This is expected because it doesnt have the next hop ip address to reach. But i expect the same behaviour when both are unnumbered. But it is able to send the rip updates and receive also therby reaching both ends. This is somewhat strange Regards Deepak Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62159&t=62134 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: IP unnumbered for HDLC connection [7:62134]
Do these labs for better understanding... http://www.cisco.com/en/US/tech/tk648/tk365/technologies_tech_note09186a 0080094e8d.shtml WATCH THE WORD WRAP! Deepak N wrote: > > Hi all > > The following are the configurations of the routers and the > ping outputs. > I have given 3 cases. > > 1) When ip unnumbered at one end and static routes are defined > > sdmheadend#sh run > Building configuration... > > Current configuration : 1115 bytes > ! > version 12.2 > service timestamps debug datetime msec > service timestamps log datetime msec > no service password-encryption > ! > hostname sdmheadend > ! > ! > ! > ! > ip subnet-zero > ! > ! > ! > ip audit notify log > ip audit po max-events 100 > ! > ! > ! > voice call carrier capacity active > ! > ! > ! > ! > ! > ! > ! > ! > ! > mta receive maximum-recipients 0 > ! > ! > ! > ! > interface FastEthernet0/0 > ip address 172.20.110.10 255.255.255.192 > duplex auto > speed auto > ! > interface FastEthernet0/1 > no ip address > shutdown > duplex auto > speed auto > ! > interface ATM1/0 > no ip address > shutdown > no atm ilmi-keepalive > dsl operating-mode auto > no fair-queue > ! > interface FastEthernet1/0 > no ip address > shutdown > duplex auto > speed auto > ! > interface Serial1/0 > ip address 12.12.12.1 255.255.255.0 > no fair-queue > clockrate 200 > ! > interface FastEthernet1/1 > no ip address > shutdown > duplex auto > speed auto > ! > interface Serial1/1 > no ip address > shutdown > clockrate 200 > ! > ip classless > ip route 200.200.200.0 255.255.255.0 Serial1/0 > ip http server > ! > ! > ! > ! > call rsvp-sync > ! > ! > mgcp profile default > ! > dial-peer cor custom > ! > ! > ! > ! > ! > line con 0 > line aux 0 > line vty 0 4 > ! > ! > end > > > sdmheadend# ping 200.200.200.11 > > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to 200.200.200.11, timeout is 2 > seconds: > ! > Success rate is 100 percent (5/5), round-trip min/avg/max = > 1/2/4 ms > sdmheadend# > > > > > > > switchrouter#sh run > Building configuration... > > Current configuration : 746 bytes > ! > version 12.2 > service timestamps debug uptime > service timestamps log uptime > no service password-encryption > ! > hostname switchrouter > ! > ! > memory-size iomem 5 > ip subnet-zero > ! > ! > ! > ip audit notify log > ip audit po max-events 100 > ip ssh time-out 120 > ip ssh authentication-retries 3 > ! > ! > ! > ! > ! > ! > ! > ! > ! > ! > ! > interface Loopback0 > ip address 200.200.200.11 255.255.255.0 > ! > interface FastEthernet0/0 > no ip address > shutdown > speed auto > ! > interface Serial0/0 > ip unnumbered Loopback0 > no fair-queue > ! > interface Serial0/1 > no ip address > shutdown > ! > ip classless > ip route 12.12.12.0 255.255.255.0 Serial0/0 > no ip http server > ip pim bidir-enable > ! > ! > ! > call rsvp-sync > ! > dial-peer cor custom > ! > ! > ! > ! > line con 0 > line aux 0 > line vty 0 4 > ! > no scheduler allocate > end > > switchrouter#ping 12.12.12.1 > > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to 12.12.12.1, timeout is 2 > seconds: > ! > Success rate is 100 percent (5/5), round-trip min/avg/max = > 1/2/4 ms > switchrouter# > > > > > > > > > > 2) When routing protocol RIP is running > > > sdmheadend#sh run > Building configuration... > > Current configuration : 1099 bytes > ! > version 12.2 > service timestamps debug datetime msec > service timestamps log datetime msec > no service password-encryption > ! > hostname sdmheadend > ! > ! > ! > ! > ip subnet-zero > ! > ! > ! > ip audit notify log > ip audit po max-events 100 > ! > ! > ! > voice call carrier capacity active > ! > ! > ! > ! > ! > ! > ! > ! > ! > mta receive maximum-recipients 0 > ! > ! > ! > ! > interface FastEthernet0/0 > ip address 172.20.110.10 255.255.255.192 > duplex auto > speed auto > ! > interface FastEthernet0/1 > no ip address > shutdown > duplex auto > speed auto > ! > interface ATM1/0 > no ip address > shutdown > no atm ilmi-keepalive > dsl operating-mode auto > no fair-queue > ! > interface FastEthernet1/0 > no ip address > shutdown > duplex auto > speed auto > ! > interface Serial1/0 > ip address 12.12.12.1 255.255.255.0 > no fair-queue > clockrate 200 > ! > interface FastEthernet1/1 > no ip address > shutdown > duplex auto > speed auto > ! > interface Serial1/1 > no ip address > shutdown > clockrate 200 > ! > router rip > network 12.0.0.0 > ! > ip classless > ip http server > ! > ! > ! > ! > call rsvp-sync > ! > ! > mgcp profile default > ! > dial-peer cor custom > ! > ! > ! > ! > ! > line con 0 > line aux 0 > line vty 0 4 > ! > ! > end > > sdmheadend# ping 200.200.200.11 > > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to 200.200.200.11, timeout is 2 > seconds: > . > Success rate is 0 percent (0/5) > sdmheadend# > > > > switchrouter#sh run > Building configuration... > > Current configuration : 738 bytes >
RE: IP unnumbered for HDLC connection [7:62134]
If it is a loopback address lets say 192.168.1.2 255.255.255.252 the router will see the netblock local to the router. Lets say the other end is 192.168.1.1 255.255.255.252 Point-to-point. Try putting a route statement ip route 192.168.1.1 255.255.255.255 out the interface. This creates a more specific route for that IP. Daniel Ladrach CCNP,CCNA WorldCom -Original Message- From: Deepak N [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 29, 2003 4:07 PM To: [EMAIL PROTECTED] Subject: IP unnumbered for HDLC connection [7:62134] HI All I have simple configuration of HDLC connected back to back. If i give ip unnumbered at one end and the static ip address at the other end, I cant ping the either end. But when i give show ip int brief, it shows the line and protocol are up. If i give ip unnumbered at both ends, now i am able to ping either end. could anybody help me out in this. Regards Deepak Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62181&t=62134 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: IP unnumbered for HDLC connection [7:62134]
Hi Ladrach I tried with the route statement. it worked perfectly. but the problem is when i am running the routing protocol. i have given detailed configs for 3 different cases in the previous mails. Regards Deepak Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62193&t=62134 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: IP unnumbered for HDLC connection [7:62134]
Deepak N wrote: > > HI All > I have simple configuration of HDLC connected back to back. > If i give ip unnumbered at one end and the static ip address at > the other end, I cant ping the either end. But when i give show > ip int brief, it shows the line and protocol are up. > If i give ip unnumbered at both ends, now i am able to ping > either end. > could anybody help me out in this. > > Regards > Deepak This stuff is impossible to remember. Everytime I think I have it committed to memory, I wind up back at: http://www.cisco.com/en/US/tech/tk648/tk365/technologies_tech_note09186a0080094e8d.shtml An interesting excerpt: "The only real disadvantage that the unnumbered interface suffers from is that it is unavailable for remote testing and management." But more importantly: When unnumbered is used, a route that is learned via the unnumbered interace is placed into the routing table using the unnumbered _interface_ it came in on as opposed to the next hop IP. If the next hop IP were to be used, problems would arrise because tit isn't directly attached (everything eventually has to boil down to a directly attached interface so the packet can be offloaded). The next hop IP is on the back side of the distant-end unnumbered interface. Unnumbered was meant to conserve address space on p-t-p serial links. It was assumed that both ends would implement it. In the case of a numbered interface, the "use the interface instead of next hop IP" logic isn't implemented. Thus, the router inserts the next hop (which is behind the unnumbered inteface on the other end). The problem, of course, is that the next hop isn't directly attached. And no special logic has been implemented to compensate. I think I got that right. Read the link and see if it adds up. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62194&t=62134 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: IP unnumbered for HDLC connection [7:62134]
Hi Vermill Now I got the point. So when i am using the numbered interface, the router tries to reach the next hop via the next hop ip address, in my case it is behind the directly connected interface.But it has no way of finding the next hop ip address behind the unnumbered interface. So it was not able to reach the other end. While both are unnumbered, the routes were installed based on the outgoing interface. Thank you all for helping me out to find the solution. Thanks n regards Deepak Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62197&t=62134 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: IP unnumbered for HDLC connection [7:62134]
Deepak N wrote: > > Hi Vermill > Now I got the point. So when i am using the numbered > interface, the router tries to reach the next hop via the next > hop ip address, in my case it is behind the directly connected > interface.But it has no way of finding the next hop ip address > behind the unnumbered interface. So it was not able to reach > the other end. While both are unnumbered, the routes were > installed based on the outgoing interface. > > Thank you all for helping me out to find the solution. > > Thanks n regards > Deepak Yes, I think you have it. But I was interested in some other suggestions that were made. If, on the numbered end, you entered a static route to the unnumbered interface IP using the outgoing interface, it seems like it might work. Something like: 'ip route 192.168.100.1 s0' where 192.168.100.1 was the IP of the interface being referenced in the 'ip unnumbered' statement and s0 attaches to the unnumbered interface. But something might break in the routing protocol. Again, I think it was assumed that you're going to implement unnumbered on both ends of the link in order to realize address conservation. There might also be some exchanges of information between the unnumbered interfaces that we're not aware of. An asymetrical configuration might break that. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62199&t=62134 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: IP unnumbered for HDLC connection [7:62134]
Glad you got it figured out and I hope you learned some reason(s) not to do unnumbered. I can't think of and good reasons for it and if you running out of addresses I have an RFC full of them for you;) Dave Deepak N wrote: > Hi Vermill > Now I got the point. So when i am using the numbered interface, the router > tries to reach the next hop via the next hop ip address, in my case it is > behind the directly connected interface.But it has no way of finding the > next hop ip address behind the unnumbered interface. So it was not able to > reach the other end. While both are unnumbered, the routes were installed > based on the outgoing interface. > > Thank you all for helping me out to find the solution. > > Thanks n regards > Deepak -- David Madland CCIE# 2016 Sr. Network Engineer Qwest Communications 612-664-3367 "You don't make the poor richer by making the rich poorer." --Winston Churchill Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62207&t=62134 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: IP unnumbered for HDLC connection [7:62134]
MADMAN wrote: > > Glad you got it figured out and I hope you learned some > reason(s) not > to do unnumbered. I can't think of and good reasons for it and > if you > running out of addresses I have an RFC full of them for you;) Dave, I heard rumor to the effect that Cisco would introduce /31 mask support for serial p-t-p links. Anyone tried that yet? I keep forgeting to when on a router with shiny new IOS. Scott > >Dave > > Deepak N wrote: > > Hi Vermill > > Now I got the point. So when i am using the numbered > interface, the router > > tries to reach the next hop via the next hop ip address, in > my case it is > > behind the directly connected interface.But it has no way of > finding the > > next hop ip address behind the unnumbered interface. So it > was not able to > > reach the other end. While both are unnumbered, the routes > were installed > > based on the outgoing interface. > > > > Thank you all for helping me out to find the solution. > > > > Thanks n regards > > Deepak > -- > David Madland > CCIE# 2016 > Sr. Network Engineer > Qwest Communications > 612-664-3367 > > "You don't make the poor richer by making the rich poorer." > --Winston > Churchill > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62214&t=62134 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: IP unnumbered for HDLC connection [7:62134]
In mail.net.groupstudy.pro, you wrote: > I heard rumor to the effect that Cisco would introduce /31 mask support for > serial p-t-p links. Anyone tried that yet? I keep forgeting to when on a > router with shiny new IOS. It works well on all platforms I've used it on. Introduced in 12.2(2)T, ie. a long time ago ;-) // kaj Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62218&t=62134 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: IP unnumbered for HDLC connection [7:62134]
[EMAIL PROTECTED] (Kaj J. Niemi) wrote: > > In mail.net.groupstudy.pro, you wrote: > > > I heard rumor to the effect that Cisco would introduce /31 > mask support for > > serial p-t-p links. Anyone tried that yet? I keep > forgeting to when on a > > router with shiny new IOS. > > It works well on all platforms I've used it on. Introduced in > 12.2(2)T, Cool! > ie. a long time ago ;-) Yeah, most of my clients are of the "if it aint broke, don't upgrade it" mentality. And a lot of my lab stuff doesn't have enough memory to go beyond 12.1. I'm often times 6 or more months behind the curve on IOS. Thanks for the update. > > > > // kaj > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62219&t=62134 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: IP unnumbered for HDLC connection [7:62134]
I think support for /31 masks was introduced in 12.2.8 though I'm sure someone will correct me if I'm mistaken;) Dave s vermill wrote: > MADMAN wrote: > >>Glad you got it figured out and I hope you learned some >>reason(s) not >>to do unnumbered. I can't think of and good reasons for it and >>if you >>running out of addresses I have an RFC full of them for you;) > > > Dave, > > I heard rumor to the effect that Cisco would introduce /31 mask support for > serial p-t-p links. Anyone tried that yet? I keep forgeting to when on a > router with shiny new IOS. > > Scott > > >> Dave >> >>Deepak N wrote: >> >>>Hi Vermill >>> Now I got the point. So when i am using the numbered >> >>interface, the router >> >>>tries to reach the next hop via the next hop ip address, in >> >>my case it is >> >>>behind the directly connected interface.But it has no way of >> >>finding the >> >>>next hop ip address behind the unnumbered interface. So it >> >>was not able to >> >>>reach the other end. While both are unnumbered, the routes >> >>were installed >> >>>based on the outgoing interface. >>> >>>Thank you all for helping me out to find the solution. >>> >>>Thanks n regards >>>Deepak >> >>-- >>David Madland >>CCIE# 2016 >>Sr. Network Engineer >>Qwest Communications >>612-664-3367 >> >>"You don't make the poor richer by making the rich poorer." >>--Winston >>Churchill -- David Madland CCIE# 2016 Sr. Network Engineer Qwest Communications 612-664-3367 "You don't make the poor richer by making the rich poorer." --Winston Churchill Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62250&t=62134 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Sample configuration of FXO to FXS voice over HDLC
Dear all, I have difficult inc onfigure FXO to FXS voice over HDLC, does anyone has the sample configuration of FXO to FXS voice over HDLC or the address of website < because I have already try to search at cisco site but the result is nothing. Thanks, Andhy _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Regarding HDLC Final view what i think [7:60496]
Hi Priscilla/All, Thanx for the reply.all are absolutely right when keepalives are exchanged they are not compressed.i would like to mention here only keepalives.I debug the o/p again ,even the cdp frames are compressed. Like to share the Debug O/P with u all for dummy setup client--server(DCE) 1.1.1.1 1.1.1.2 cdp enabled cdp enabled Stac enabled no compression In this scenario the keepalives are exchanged properly and the link status also remains up. Debug all client side# 00:15:55: Serial0: HDLC myseq 27, mineseen 27*, yourseen 28, line up 00:15:55: Serial0: COMPRESS: (expansion) status: 6, size in: 20, size out: 14 00:15:57: CDP-PA: Packet received from server on interface Serial0 00:16:05: Serial0: HDLC myseq 28, mineseen 28*, yourseen 29, line up 00:16:05: Serial0: COMPRESS: (expansion) status: 6, size in: 20, size out: 14 00:16:15: Serial0: HDLC myseq 29, mineseen 29*, yourseen 30, line up 00:16:15: Serial0: COMPRESS: (expansion) status: 6, size in: 20, size out: 14PQU 00:16:25: Serial0: HDLC myseq 30, mineseen 30*, yourseen 31, line up 00:16:25: Serial0: COMPRESS: (expansion) status: 6, size in: 20, size out: 14PQU debug all server# *Mar 1 00:15:35.791: Serial0: HDLC myseq 27, mineseen 27*, yourseen 27, line up * *Mar 1 00:15:45.791: Serial0: HDLC myseq 28, mineseen 28*, yourseen 28, line up *Mar 1 00:15:55.791: Serial0: HDLC myseq 29, mineseen 29*, yourseen 29, line up *Mar 1 00:16:05.791: Serial0: HDLC myseq 30, mineseen 30*, yourseen 30, line up *Mar 1 00:16:08.815: crm_send_periodic_update *Mar 1 00:16:09.763: IP-ST: if_list try 0 *Mar 1 00:16:09.763: IP-ST: gw_list total 0, try 0, completed list TRUE *Mar 1 00:16:09.763: IP-Static: all_list, time elapsed 0 msPQUICC_FEC(0/0): PHY *Mar 1 00:16:15.791: Serial0: HDLC myseq 31, mineseen 31*, yourseen 31, line up *Mar 1 00:16:25.211: CDP-EV: Bad checksum in header *Mar 1 00:16:25.791: Serial0: HDLC myseq 32, mineseen 32*, yourseen 32, line up See the Cdp Bad checksum error in header. client side# sh cdp nei Device IDLocal Intrfce HoldtmeCapability Platform Port ID server Ser 0 171 R1721 Ser 0 This Indicates that still I can accept Uncompressed packets although compression is enabled.But when it will send packets it will only send compressed packets. server side# sh cdp nei nothing is displayed Client side# ping 1.1.1.2(server) Server side#debug all *Mar 1 00:18:50.663: IP: s=120.7.3.160 (Serial0), d=32.64.1.230, len 6, dispose ip.formaterr *Mar 1 00:18:52.663: IP: s=112.7.3.160 (Serial0), d=32.64.1.214, len 6, dispose ip.formaterr *Mar 1 00:18:54.663: IP: s=104.7.3.160 (Serial0), d=32.64.1.200, len 6, dispose ip.formaterr *Mar 1 00:18:55.791: Serial0: HDLC myseq 47, mineseen 47*, yourseen 47, line up *Mar 1 00:18:56.663: IP: s=96.7.3.160 (Serial0), d=44.120.220.46, len 6, dispos e ip.formaterr * ial0: HDLC myseq 55, mineseen 55*, yourseen 55, line up Again the errors as it doesnot understand compressed data.But what are these ips ,ok the client before sending the packets on the interface have compressed the data thats why it shows strange ips after conversion.It is unable to decompress the data and displaying compressed data. anyway the question was whether keepalives are compressed are not so I used show compress which gave me the indication that no counters get incremented for compressed stats when keepalives are exchanged,but uncompressed sats were increasing that too with 20 byte increment that what i suspect is Compression stats messages which are exchanged although here on ine side command worked as compression was not enabled.this might not be a keepalive increment as keepalives as nothing to do with compression. Now for tcp header compression if enabled on one side I was unable to send tcp traffic from any side but we can ping as it doesnot use layer 4.. Thanx for all answers Bye Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=60496&t=60496 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Final Conclusion Re: Question Regarding HDLC [7:60337]
nice job of examination and observation. thanks. may I suggest that CDP packets, as with ftp, tftp, or any other data packets, are payload to the HDLC frame. -- TANSTAAFL "there ain't no such thing as a free lunch" ""Simmi Singla"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Hi Priscilla/All, > Thanx for the reply.all are absolutely right when keepalives are exchanged > they are not compressed.i would like to mention here only keepalives.I debug > the o/p > again ,even the cdp frames are compressed. > Like to share the Debug O/P with u all for dummy setup > client--server(DCE) > 1.1.1.1 1.1.1.2 > cdp enabled cdp enabled > Stac enabled no compression > > In this scenario the keepalives are exchanged properly and the link status > also remains up. > Debug all > client side# > 00:15:55: Serial0: HDLC myseq 27, mineseen 27*, yourseen 28, line up > 00:15:55: Serial0: COMPRESS: (expansion) status: 6, size in: 20, size out: 14 > 00:15:57: CDP-PA: Packet received from server on interface Serial0 > > > 00:16:05: Serial0: HDLC myseq 28, mineseen 28*, yourseen 29, line up > 00:16:05: Serial0: COMPRESS: (expansion) status: 6, size in: 20, size out: 14 > > 00:16:15: Serial0: HDLC myseq 29, mineseen 29*, yourseen 30, line up > 00:16:15: Serial0: COMPRESS: (expansion) status: 6, size in: 20, size out: > 14PQU > > 00:16:25: Serial0: HDLC myseq 30, mineseen 30*, yourseen 31, line up > 00:16:25: Serial0: COMPRESS: (expansion) status: 6, size in: 20, size out: > 14PQU > > debug all > server# > *Mar 1 00:15:35.791: Serial0: HDLC myseq 27, mineseen 27*, yourseen 27, > line up > > * > *Mar 1 00:15:45.791: Serial0: HDLC myseq 28, mineseen 28*, yourseen 28, > line up > > *Mar 1 00:15:55.791: Serial0: HDLC myseq 29, mineseen 29*, yourseen 29, > line up > > *Mar 1 00:16:05.791: Serial0: HDLC myseq 30, mineseen 30*, yourseen 30, > line up > > *Mar 1 00:16:08.815: crm_send_periodic_update > *Mar 1 00:16:09.763: IP-ST: if_list try 0 > *Mar 1 00:16:09.763: IP-ST: gw_list total 0, try 0, completed list TRUE > *Mar 1 00:16:09.763: IP-Static: all_list, time elapsed 0 msPQUICC_FEC(0/0): > PHY > > *Mar 1 00:16:15.791: Serial0: HDLC myseq 31, mineseen 31*, yourseen 31, > line up > > *Mar 1 00:16:25.211: CDP-EV: Bad checksum in header > *Mar 1 00:16:25.791: Serial0: HDLC myseq 32, mineseen 32*, yourseen 32, > line up > See the Cdp Bad checksum error in header. > > client side# sh cdp nei > Device IDLocal Intrfce HoldtmeCapability Platform Port ID > server Ser 0 171 R1721 Ser 0 > This Indicates that still I can accept Uncompressed packets although > compression is enabled.But when it will send packets it will only send > compressed packets. > server side# sh cdp nei > nothing is displayed > > Client side# ping 1.1.1.2(server) > Server side#debug all > *Mar 1 00:18:50.663: IP: s=120.7.3.160 (Serial0), d=32.64.1.230, len 6, > dispose > ip.formaterr > *Mar 1 00:18:52.663: IP: s=112.7.3.160 (Serial0), d=32.64.1.214, len 6, > dispose > ip.formaterr > *Mar 1 00:18:54.663: IP: s=104.7.3.160 (Serial0), d=32.64.1.200, len 6, > dispose > ip.formaterr > *Mar 1 00:18:55.791: Serial0: HDLC myseq 47, mineseen 47*, yourseen 47, > line up > > *Mar 1 00:18:56.663: IP: s=96.7.3.160 (Serial0), d=44.120.220.46, len 6, > dispos > e ip.formaterr > * ial0: HDLC myseq 55, mineseen 55*, yourseen 55, line up > > Again the errors as it doesnot understand compressed data.But what are these > ips ,ok the client before sending the packets on the interface have > compressed the > data thats why it shows strange ips after conversion.It is unable to > decompress the data and displaying compressed data. > > anyway the question was whether keepalives are compressed are not > so I used show compress which gave me the indication that no counters get > incremented for compressed stats when keepalives are exchanged,but > uncompressed > sats were increasing that too with 20 byte increment that what i suspect is > Compression stats messages which are exchanged although here on ine side > command > worked as compression was not enabled.this might not be a keepalive > increment as keepalives as nothing to do with compression. > Now for tcp header compression if enabled on one side I was unable to send > tcp traffic from any side but we can ping as it doesnot use layer 4.. > Thanx for all answers > Bye > > Priscilla Oppenheimer wrote: > > > > HDLC sequences numbers aren't in data frames. They are in > > separate keepalive frame
Re: Sample configuration of FXO to FXS voice over HDLC
IIRC there's no voice over HDLC thing (from Cisco). Forget about the voice for a moment, and make IP running over HDLC. Then make voice running over IP. /felis Andhy Indarto wrote: > > Dear all, > > I have difficult inc onfigure FXO to FXS voice over HDLC, does anyone has > the sample configuration of FXO to FXS voice over HDLC or the address of > website < because I have already try to search at cisco site but the result > is nothing. > > Thanks, > > Andhy > > _ > FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Sample configuration of FXO to FXS voice over HDLC
Actually there is voice over hdlc. It is done on the Cisco MC3810 concentrator. In fact there is a good lab at mentortech dealing with voice over hdlc. Lab 2400 Voice over HDLC Using MC3810 -Original Message- From: Oleg Mazurov [mailto:[EMAIL PROTECTED]] Sent: Friday, March 16, 2001 1:25 PM To: [EMAIL PROTECTED] Subject: Re: Sample configuration of FXO to FXS voice over HDLC IIRC there's no voice over HDLC thing (from Cisco). Forget about the voice for a moment, and make IP running over HDLC. Then make voice running over IP. /felis Andhy Indarto wrote: > > Dear all, > > I have difficult inc onfigure FXO to FXS voice over HDLC, does anyone has > the sample configuration of FXO to FXS voice over HDLC or the address of > website < because I have already try to search at cisco site but the result > is nothing. > > Thanks, > > Andhy > > _ > FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
compress command unavailable on FR or hdlc intf??.....Why? [7:38745]
Hello,Can't seem to get the compress command to work on Fr intfsAlso on hdlc inft. only the stac compression shows up Any reason as to why??Ex. On a FR inft.RTD(config)#int s0/0 RTD(config-if)#compress ? % Unrecognized command On a PPP intf.RTB(config-if)#compress ? mppc MPPC compression type predictor predictor compression type stac stac compression algorithm On a HDLC intf.RTC(config)#int s 0 RTC(config-if)#compress ? stac stac compression algorithm Chat with friends online, try MSN Messenger: Click Here Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=38745&t=38745 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
compress command unavailable on FR or hdlc intf??.....Why? [7:38746]
Hello,Can't seem to get the compress command to work on Fr intfsAlso on hdlc inft. only the stac compression shows up Any reason as to why?? Ex. On a FR inft.RTD(config)#int s0/0 RTD(config-if)#compress ? % Unrecognized command On a PPP intf.OKRTB(config-if)#compress ? mppc MPPC compression type predictor predictor compression type stac stac compression algorithm On a HDLC intf.RTC(config)#int s 0 RTC(config-if)#compress ? stac stac compression algorithm Thank you for your help. Join the worlds largest e-mail service with MSN Hotmail. Click Here Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=38746&t=38746 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
compress command unavailable on FR or hdlc intf??.....Why? [7:38753]
Well, you haven't said what IOS or hardware you're using, which could make a difference. Have a look at the following URL - it may clear up your questions. I haven't read it thoroughly myself, but note the usage guidelines..."You can configure point-to-point software compression for all LAPB, PPP, and HDLC encapsulations. HDLC encapsulations supports the Stacker compression algorithm. PPP and LAPB encapsulations support both predictor and Stacker compression algorithms. " Note no mention of FR encapsulation. http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/inter_r/irdacces.htm#1019592 JMcL - Forwarded by Jenny Mcleod/NSO/CSDA on 19/03/2002 03:35 pm - "Cisco Nuts" Sent by: [EMAIL PROTECTED] 19/03/2002 01:49 pm Please respond to "Cisco Nuts" To: [EMAIL PROTECTED] cc: Subject: compress command unavailable on FR or hdlc intf??.Why? [7:38746] Hello,Can't seem to get the compress command to work on Fr intfsAlso on hdlc inft. only the stac compression shows up Any reason as to why?? Ex. On a FR inft.RTD(config)#int s0/0 RTD(config-if)#compress ? % Unrecognized command On a PPP intf.OKRTB(config-if)#compress ? mppc MPPC compression type predictor predictor compression type stac stac compression algorithm On a HDLC intf.RTC(config)#int s 0 RTC(config-if)#compress ? stac stac compression algorithm Thank you for your help. Join the worlds largest e-mail service with MSN Hotmail. Click Here Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=38753&t=38753 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
EA bit of ISDN and Frame Relay (also in HDLC) [7:11035]
Dear Guru's, Have seen that in the frame format of ISDN, Frame Relay and HDLC, there are two bits of Extended Address field. I would like to know why two fields when one can suffice? With my limited knowledge, I can understand that may be when (in case of FR) the DLCI bits increase beyond 10 bits, then might require another frame to take along the extra bits. This is purely my understanding, nothing to do with any whitepaper or site. Have I hit the taget? Moreover I was thinking why do we need more than 10 bits of DLCI? When will we need it? Do throw some light here, please. Amit Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=11035&t=11035 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: compress command unavailable on FR or hdlc intf??.....Why? [7:38770]
Page 314 Remote Access Book. - For HDLC links, STAC is the only available choice. Page 316 - For FRame RElay deployments, use the frame-relay payload-compress command to enable STAC compression on an interface or a subinterface. The reason that you can only use payload compression on a framer-relay interface is becuase the header information needs to remain intact so it can be read by the switches that the transmission crosses. Robert -Original Message- From: Cisco Nuts [mailto:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 9:50 PM To: [EMAIL PROTECTED] Subject: compress command unavailable on FR or hdlc intf??.Why? [7:38746] Hello,Can't seem to get the compress command to work on Fr intfsAlso on hdlc inft. only the stac compression shows up Any reason as to why?? Ex. On a FR inft.RTD(config)#int s0/0 RTD(config-if)#compress ? % Unrecognized command On a PPP intf.OKRTB(config-if)#compress ? mppc MPPC compression type predictor predictor compression type stac stac compression algorithm On a HDLC intf.RTC(config)#int s 0 RTC(config-if)#compress ? stac stac compression algorithm Thank you for your help. Join the worlds largest e-mail service with MSN Hotmail. Click Here Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=38770&t=38770 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: EA bit of ISDN and Frame Relay (also in HDLC) [7:11035]
>Dear Guru's, >Have seen that in the frame format of ISDN, Frame Relay and HDLC, there are >two bits of Extended Address field. I would like to know why two fields when >one can suffice? >With my limited knowledge, I can understand that may be when (in case of FR) >the DLCI bits increase beyond 10 bits, then might require another frame to >take along the extra bits. This is purely my understanding, nothing to do >with any whitepaper or site. Have I hit the taget? >Moreover I was thinking why do we need more than 10 bits of DLCI? When will >we need it? >Do throw some light here, please. >Amit You ask a question here that digs deeply into why protocols are designed the way they are. First, it's worth remembering that protocol standards developed by ISO, ITU and CCITT usually are developed on paper long before there are any prototypes or products. In contrast, IETF standards require at least two running implementations before you can move to the second of three levels of standardization. So, without real-world modifiers about how the technology will be used, ISO/ITU standards (including ISDN, Frame, and HDLC), are rather consciously designed so there can be extensions later. You have correctly interpreted why the EA bit is there -- it's for extending the field length. And you are also quite correct that no one has found a real reason to use more than 10 bits. But the capability is there if it's needed. We have a long history of running out of space in protocol fields -- witness IPv4 addressess. Another good comparison is the difference in detailed protocol message design in OSPF and ISIS. OSPF is designed for processing efficiency. You will find that most important fields are aligned on 32-bit boundaries. There's a lot of bit-flag level encoding. ISIS, however, was designed for extensibility. Its optional fields are in variable-length Type-Length-Value constructs, so it's much easier to add features than it is to OSPF. Again, rememeber when these protocol were designed, conditions weren't the same as they are today. Processors were much slower. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=11247&t=11035 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: EA bit of ISDN and Frame Relay (also in HDLC) [7:11035]
In article , Howard C. Berkowitz
writes
>>Dear Guru's,
>>Have seen that in the frame format of ISDN, Frame Relay and HDLC, there are
>>two bits of Extended Address field. I would like to know why two fields
when
>>one can suffice?
>>With my limited knowledge, I can understand that may be when (in case of
FR)
>>the DLCI bits increase beyond 10 bits, then might require another frame to
>>take along the extra bits. This is purely my understanding, nothing to do
>>with any whitepaper or site. Have I hit the taget?
>>Moreover I was thinking why do we need more than 10 bits of DLCI? When will
>>we need it?
>>Do throw some light here, please.
>>Amit
>
>You ask a question here that digs deeply into why protocols are
>designed the way they are. First, it's worth remembering that
>protocol standards developed by ISO, ITU and CCITT usually are
>developed on paper long before there are any prototypes or products.
>In contrast, IETF standards require at least two running
>implementations before you can move to the second of three levels of
>standardization.
>
>So, without real-world modifiers about how the technology will be
>used, ISO/ITU standards (including ISDN, Frame, and HDLC), are rather
>consciously designed so there can be extensions later. You have
>correctly interpreted why the EA bit is there -- it's for extending
>the field length.
>
HDLC is a standard (the real HDLC not Cisco's version) and is the basis
of most layer 2 protocols, X.25 LAPB, Q.922 Frame Relay, ISDN Q.921
LAPD, V42bis (LAPM), PPP and various vendor specific flavours of HDLC.
Perhaps a brief look into HDLC may help.
HDLC frame layout
-
flag ... flag | HDLC hdr | payload | FCS | flag ...
The flags separate the HDLC frames and identify the end of a frame.
They are hex 7E, ie 6 consecutive '1's. This pattern is illegal in a
frame and the transmitting chip set will break a pattern of 5
consecutive '1's by inserting an additional '0' bit (zero bit stuffing).
The receiving chip set will delete the '0' following 5 consecutive '1's,
so it is transparent to any higher layers.
The flags force clock transitions and hence help to maintain bit clock
synchronisation between frames. There must be at least 1 flag between
frames and there may be any number. When flags are nolonger sent it is
assumed that a new frame is beginning.
FCS (Frame Check Sequence) is some type of polynomial to enable the
detection of faulty frames. (Most modern L2 protocols only detect faulty
frames and then discard them, some of the legacy protocols X.25 LAPB,
perform error recovery at L2.)
The payload is what you wish to carry eg IP, IPX etc and normally has
some form of wrapper round it.
Now to the main part the HDLC header field. This is normally split into
2 sub parts, the address field and the control field.
By default an HDLC header address field is a single octet. As Howard
says standards bodies like protocols to be extendable. The HDLC address
field is extendable to as many octets as you like! The protocol says
that if the ea bit (least significant bit) is a '0' then the address
field extends into at least another octet. So if you want a 4 octet
address field the ea bit in the first 3 octets is a '0' ("more to
follow") and in the final, 4th octet, the ea bit is a '1'. ("END OF THE
LINE") In other words you just daisy chain the extensions to the address
field to as many octets as you need.
So for ISDN Q.921 and normal Q.922 Frame Relay it may seem as a waste to
have 2 ea bits just to say that we have a 2 octet address field. But at
least it is extendable. I have heard rumours of early IP developers
saying 'you must be nuts 32 bit IP addresses, we only ever need a
handful of networks with a couple of dozen hosts'...
So HDLC has and ea bit in every address octet!
Frame Relay supports 2, 3 & 4 octet header fields, controlled by the ea
bits in each octet. Yes in the Cisco world you are most unlikely to
come across Frame Relay frames with anything other than 2 octet address
fields.
In CPE land 1023 dlci per port may seem excessive but just think of the
poor old Frame Relay switches in the Frame cloud.
Let us suppose that a Frame Relay edge switch has say 500 customers
hanging off it, each with moderately large networks say needing 64 dlci
per customer and the Telco wants to switch these onto a single common
trunk. 64 x 500 dlci on the trunk! Oops! You can't do that!
Remember a dlci only has to be unique on a particular port, but when all
those dlcis are switched onto a single trunk, they must still be unique.
Hence the need for 3 and 4 octet frame header fields. You may come
across them on the NNI (Network - Network Interface) between switches,
within the Frame Relay c
