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? > >> > >> 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 > C
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 > > > 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? > > >> > >
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 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 advant
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]
