HDLC [7:66324]

[maine dude]

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=7i=66324t=66324
--
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]

[Priscilla Oppenheimer]

=?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 try to get a tour of a company's network and
get a better feel for this? Talk to some network engineers about their
network designs and physical facilities, etc. This is something

Re: PPP vs HDLC [7:64362]

[Scott Roberts]

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=7i=64736t=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]

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=7i=64743t=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]

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=7i=64744t=64362
--
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Cisco HDLC Flags (was PPP vs HDLC) [7:64779]

[s vermill]

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=7i=64779t=64779
--
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]

[Priscilla Oppenheimer]

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=7i=64798t=64779
--
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]

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 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

Re: PPP vs HDLC [7:64362]

[s vermill]

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=7i=64666t=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]

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=7i=64676t=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]

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=7i=64657t=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]

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=7i=64686t=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]

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=7i=64485t=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]

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
 Churchill
 
 




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7i=64546t=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]

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?
  
 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

PPP vs HDLC [7:64362]

[Stuart Pittwood]

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=7i=64362t=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]

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=7i=64365t=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]

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=7i=64371t=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]

[JSalminen]

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=7i=64374t=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]

[Lupi, Guy]

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=7i=64377t=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]

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=7i=64386t=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]

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=7i=64389t=64362
--
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]

[Mossburg, Geoff (MAN-Corporate)]

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 SG, 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=7i=62988t=62928
--
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

HDLC, line protocols, and keepalives. [7:62928]

[Mossburg, Geoff (MAN-Corporate)]

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 SG, 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=7i=62928t=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]

[Priscilla Oppenheimer]

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 SG, 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=7i=62935t=62928
--
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]

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=7i=62250t=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]

[Ladrach, Daniel E.]

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=7i=62181t=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]

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=7i=62193t=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]

[s vermill]

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=7i=62194t=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]

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=7i=62197t=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]

[s vermill]

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=7i=62199t=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]

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=7i=62207t=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]

[s vermill]

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=7i=62214t=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)]

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=7i=62218t=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]

[s vermill]

[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=7i=62219t=62134
--
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]

[Deepak N]

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=7i=62134t=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]

[Claudio Spescha]

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=7i=62135t=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]

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=7i=62137t=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]

[Priscilla Oppenheimer]

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=7i=62142t=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]

[Claudio Spescha]

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=7i=62143t=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]

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]

[Claudio Spescha]

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=7i=62151t=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]

[Priscilla Oppenheimer]

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/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 

RE: IP unnumbered for HDLC connection [7:62134]

[Deepak N]

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=7i=62157t=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]

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=7i=62159t=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]

[cebuano]

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
 !
 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 

Final Conclusion Re: Question Regarding HDLC [7:60337]

[Simmi Singla]

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
  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 

Regarding HDLC Final view what i think [7:60496]

[Simmi Singla]

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=7i=60496t=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]

[The Long and Winding Road]

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 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 t

Question Regarding HDLC [7:60337]

[Simmi Singla]

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=7i=60337t=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]

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=7i=60356t=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]

[The Long and Winding Road]

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=7i=60358t=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]

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=7i=60364t=60337
--
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]

[Tim Champion]

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=7i=56073t=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]

[Metin YILDIZLI]

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=7i=56075t=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]

[Symon Thurlow]

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=7i=56079t=56073
--
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]

[Robert Fowler]

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=7i=38770t=38770
--
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]

[Cisco Nuts]

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=7i=38745t=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:38753]

[[EMAIL PROTECTED]]

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=7i=38753t=38753
--
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]

[BASSOLE Rock]

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=7i=25912t=25912
--
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]

[[EMAIL PROTECTED]]

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=7i=25916t=25912
--
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]

[John Neiberger]

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=7i=25683t=25601
--
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]

[Kannan Sadagopan]

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=7i=24086t=24086
--
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]

[Peter Whittle]

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 cloud.  However, in reality most Telco Frame
Relay networks run Frame Relay out to the customers and then use some
proprietary protocol in the core between the edge switches. So the most
likely place to find 3 and 4 octet Frame Relay headers would be on the
Inter Carrier Interface between 2 different

Re: EA bit of ISDN and Frame Relay (also in HDLC) [7:11035]

[Howard C. Berkowitz]

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=7i=11247t=11035
--
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]

[[EMAIL PROTECTED]]

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=7i=11035t=11035
--
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]

[Mohamed El Komy]

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=7i=10777t=10737
--
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]

[friend]

Dear all
pls show me difference ppp and hdlc




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7i=10737t=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]

[MikeN]

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=7i=10764t=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]

[Preston Kilburn]

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=7i=10766t=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]

[MikeN]

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=7i=10768t=10737
--
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]

[Rizzo Damian]

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=7i=5739t=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]

[Circusnuts]

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=7i=5743t=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]

[Graham, Darel R.]

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=7i=5747t=5739
--
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

[Andhy Indarto]

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]

Re: Sample configuration of FXO to FXS voice over HDLC

[Oleg Mazurov]

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

[Christopher Larson]

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]

do interface counters include HDLC?

[Christian Hammers]

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: HDLC

[Marty Adkins]

"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]

Re: HDLC

[Marty Adkins]

"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

[Howard C. Berkowitz]

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

[Erick B.]

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

[Brian]

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

[Howard C. Berkowitz]

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]

HDLC

[Jeremy Dumoit]

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

[Stuart Potts]

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

[Howard C. Berkowitz]

 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, SDLC...

[Yee, Jason]

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...

[michael champion]

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...

[Karen . Young]

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]   
   
claude_vincent@cc:
   
yahoo.com  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...

[Priscilla Oppenheimer]

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]

PPP or HDLC pros and cons

[John Zaggat]

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 or HDLC pros and cons

[Andrew Larkins]

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]