Serial lines in this context will refer to lines using HDLC
encapsulation, which is the default.
Isn't HDLC a standard ?
In one sense, yes. The frame format and bit stuffing are standards,
and are implemented by off the shelf components. However, what
is referred to as HDLC in books will usually have windowing and retransmission.
Cisco's HDLC does not. This can be called "unreliable" HDLC.
Is Cisco's HDLC proprietary ?
The method in which higher layer protocols are identified within
an HDLC frame is not standardized. It's very unlikely that another vendor
will encapsulate higher level datagrams within HDLC using our method. PPP
encapsulation should be used for interoperating with
What do the following states from "show interface" output
signify ?
"Serial0 is down, line protocol is down"
The interface isn't seeing the signals it requires. These
signals vary from only DCD, to DCD, DSR, CTS. (when operating in
DTE mode)
"Serial0 is up, line protocol is up"
Everything is fine. If keepalive is on both sides, they are
making it in each direction. This is assumed when the required signals
are supplied. if keepalives are off, line protocol is marked up.
"Serial0 is up, line protocol is down"
The required signals are present, but keepalives are not being
received in one direction or another. Possibly they are errored, turned
off on one side, or set to a different period on the two sides.
"Serial0 is up, line protocol is up (looped)"
The interface is receiving it's own keepalives. A looped
line is normally considered up, which is valuable for testing purposes.
A looped line can be considered down if "down-when-looped" is configured.
This is most useful when a backup line is available.
"Serial0 is down, line protocol is down (looped)"
The last state when the interface was up was looped. The
(looped) designation is a flag that isn't reset when the line is
down. The line must go up/up before it is reset. This is not a problem.
"Serial0 is up, line protocol is up (spoofing)"
Spoofing is a special flag used on dial on demand (DDR) interface
to solve chicken/egg issues. A DDR interface requires traffic to dial.
Traffic isn't usually sent to down interfaces. Spoofing means the
interface appears up to higher layers so that packets can be routed to
it, which may cause dialing.
What causes input errors ?
Input errors are usually caused by some kind of clocking problem.
Clocking must be set properly on the DSU/CSU.
The network clock setting is the first option to check. If the
network provides clock, the DSU/CSU should sync to it. If the network does
not provide clock, one DSU/CSU should run off an internal clock source
and the other must sync to the first.
A second clock setting that sometimes resolves problems is the
use of SCTE. Using SCTE can eliminate errors due to phase shift in the
cable between DSU/CSU and router. This is more common with A-chassis systems.
A good indication of this is that the circuit works fine at a lower speed
but not when the speed is increased.
Router hardware failures very rarely cause input errors. Rule
this in or out by using local loopbacks on the DSU/CSU or swapping hardware.
How is one's density guaranteed ?
The router does not guarantee one's density. In fact, HDLC does
the opposite, guaranteeing zero's density due to bit stuffing of a zero
after 5 consecutive ones. The DSU/CSU and line coding must guarantee one's
density on a full T1. There are at least three ways of doing so.
1) Use B8ZS line coding. The preferred method.
2) Use nX56 channels. A one is stolen from each byte. Possibly
necessary on older transmission gear that can't do B8ZS. Reduces available
bandwidth by 1/8. (1544 -> 1344 kbps)
3) Invert data on the DSU's. A clever solution that can work on
older transmission gear without the bandwidth penalty. As HDLC guarantees
1 zero every 5 ones, this meets the one's density requirement when inverted.
How do I figure out what's wrong when line protocol is down
?
Loopbacks are your friend. A local loopback at the DSU/CSU can
rule out or rule in a router hardware problem. Move the loopback towards
the far side, using the telco to help. Don't let the old BERT test
trick work on you. The line always tests fine with a BERT test. Always.
Why ? Usually they are going through the DSU, which is the real problem,
or they use some test with almost no zeros in it, while packets can have
lots of zeros. Pinging with different data patterns can also help narrow
this down. Every data patternm should always work.
What's in an HDLC frame ? (mostly stolen from an old email
from John Bashinski)
The first ("address") octet is set to 0x0F for unicast packets
and 0x8F for broadcast packets. Broadcast just means that the higher-level
protocol thought this was a broadcast packet.
The second ("control") octet is always 0.
The next two octets are a 16-bit protocol code, sent most-significant-first.
These codes are usually Ethernet type codes. Some common codes are
TYPE_IP10MB
0x0800 IP
TYPE_IEEE_SPANNING
0x4242 DSAP/SSAP for IEEE bridge spanningprot.
TYPE_DECNET
0x6003 DECnet phase IV
TYPE_BRIDGE
0x6558 Bridged Ethernet/802.3 packet
TYPE_REVERSE_ARP
0x8035 cisco SLARP (not real reverse ARP!)
TYPE_DEC_SPANNING
0x8038 DEC bridge spanning tree protocol
TYPE_ETHERTALK
0x809b Apple EtherTalk
TYPE_AARP
0x80f3 Appletalk ARP
TYPE_NOVELL1
0x8137 Novell IPX
TYPE_CLNS
0xFEFE ISO CLNP/ISO ES-IS DSAP/SSAP
Bytes after this are higher-level protocol data. These normally
look the same as they'd look on Ethernet. Bridging packets include Ethernet/802.3
MAC headers; no other packets do.
Packets with type 8035 (reverse ARP) don't contain reverse ARP
data as they would on an Ethernet. Instead, they carry a protocol cisco
refers to as SLARP. SLARP has two functions dynamic IP address determination
and serial line keepalive.
The serial line model supported by SLARP assumes that each serial
line is a separate IP subnet, and that one end of the line is host number
1, while the other end is host number 2. The SLARP address resolution protocol
allows system A to request that system B tell system A system B's IP address,
along with the IP netmask to be used on the network. It does this by sending
a SLARP address resolution request packet, to which system B responds with
a SLARP address resolution reply packet. System A then attempts to
determine its own IP address based on the address of system B. If
the host portion of system B's address is 1, system A will use 2
for the host portion of its own IP address. Conversely, if system
B's IP host number is 2, system A will use IP host number 1. If system
B replies with any IP host number other than 1 or 2, system A assumes
that system B is unable to provide it with an address via SLARP.
For the SLARP keepalive protocol, each system sends the other
a keepalive packet at a user-configurable interval. The default interval
is 10 seconds. Both systems must use the same interval to ensure
reliable operation. Each system assigns sequence numbers to the keepalive
packets it sends, starting with zero, independent of the other system.
These sequence numbers are included in the keepalive packets sent to the
other system. Also included in each keepalive packet is the sequence
number of the last keepalive packet _received_ from the other system, as
assigned by the other system. This number is called the returned sequence
number. Each system keeps track of the last returned sequence number
it has received. Immediately before sending a keepalive packet, it compares
the sequence number of the packet it is about to send with the returned
sequence number in the last keepalive packet it has received.
If the two differ by 3 or more, it considers the line to have failed, and
will route no further higher-level data across it until an acceptable
keepalive response is received.
*But were afraid to ask