Here is a really great response I received off-list that I thought would
be beneficial for others to read.
John
Received: from dymwsm06.mailwatch.com by fsutil01; Thu, 14 Jun 2001
19:11:44 -0600
Received: from mwsc0201.mw4.mailwatch.com (mwsc0201.mw4.mailwatch.com
[204.253.83.131]) by dymwsm06.mailwatch.com (8.11.0/8.11.0) with ESMTP
id f5F0qUM13601 for ; Thu, 14 Jun 2001
20:52:30 -0400
Received: from mail pickup service by mwsc0201.mw4.mailwatch.com with
Microsoft SMTPSVC; Thu, 14 Jun 2001 21:11:59 -0400
Received: from 204.253.83.72 ([204.253.83.72]) by MWSC0201 with SMTP id
000200011db9cb84-070d-4bbb-9a47-1fa6cf8fbabe; Thu, 14 Jun 2001
21:11:58 -0500
Received: from anchor-post-34.mail.demon.net
(anchor-post-34.mail.demon.net [194.217.242.92]) by
dymwsm10.mailwatch.com (8.11.0/8.11.0) with ESMTP id f5F1C0J18365 for
; Thu, 14 Jun 2001 21:12:00 -0400
Received: from whittle-systems.demon.co.uk ([212.228.18.2]) by
anchor-post-34.mail.demon.net with smtp (Exim 2.12 #1) id
15Ai94-0009Jq-0Y for [EMAIL PROTECTED]; Fri, 15 Jun 2001
02:11:31 +0100
Message-ID:
Date: Fri, 15 Jun 2001 02:09:43 +0100
To: John Neiberger
From: Peter Whittle
Subject: Frame Relay Encapsulation and LMI [7:8406] long reply
References:
In-Reply-To:
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 4.02aS
HOP-COUNT: 1
X-MAILWATCH-INSTANCEID: 010200011db9cb84-070d-4bbb-9a47-1fa6cf8fbabe
X-OriginalArrivalTime: 15 Jun 2001 01:11:59.0162 (UTC)
FILETIME=[2D3251A0:01C0F538]
Long reply
John,
Perhaps I could clarify a few points on Frame Relay for you.
1) 'encapsulation' refers to 2 separate items:
a) L2 Frame structure - Frame
Relay, HDLC, PPP etc
b) In the case of Frame Relay
L2, the way the L3 (IP) datagram is mapped into the payload portion of
the Frame Relay frame.
'encaps frame-relay Cisco' - says use Frame Relay as L2 and use
proprietary Cisco structure to place L3 IP datagrams into it.
'encaps frame-relay ietf' - says use Frame Relay as L2 and use rfc 1490
or NLPID to encapsulate the L3 IP datagram into the frame.
ie they both have the same L2 frames.
As far as a Cisco router acting as a frame relay switch is concerned it
is in the first instance only concerned with the 2 octet Frame Relay L2
frame header and not the payload portion. The way L3 is mapped into the
payload portion is only relevant to the two end points, the switches in
between are not interested they only read the headers. The exception to
this is if the switch is one of the end points ie you have 2 routers
back to back with serial cables.
Frame Relay L2 frame format:
flag flag .... flag [header,payload,frame check sequence] flag
The flag 7E hex is there to keep the line synchronised.
The header is normally 2 octets and controls which circuit it is on
(dlci), if the network is congested (FECN,BECN), whether the traffic has
exceed the average traffic level (known as 'Committed Information Rate'
or CIR) by setting the DE bit.
header:
Octet 0 dlci:6, c/r:1, ea:1
Octet 1 dlci continued:4,FECN:1,BECN:1,DE:1,ea:1
dlci is 10 bits in total (0..1023) the connection or circuit identifier
and only has local significance ie between the CPE kit at the A end and
the port on the Frame Relay switch. (If you like think of it as a
baggage label, it says on which circuit the frame is travelling on. When
the frame gets to the switch, the switch looks up the dlci and source
port in its routing (switching) table and replaces the baggage label
with a new one before sending the frame on its way out of the
destination port. This process is repeated for each switch in the Frame
Relay network until the final switch which delivers the frame to the CPE
B end.
c/r is a single bit and is not normally used.
ea bit is part of standard HDLC (not Cisco HDLC) and says that the
'address field' is extends into another octet.
FECN is a single bit flag used by the network to signal to down stream
receivers that the network is congested.
BECN is a single bit flag used by the network to signal to up stream
transmitters that the network is congested. It is actually set on frames
that return to the originator through the congested node.
DE is a single bit flag. The 'Discard Eligible' flag, normally set by
the port of ingress to the network (the port on the 1st switch facing
CPE A) if the traffic offered to the network exceeds the traffic
contract. (CIR) It is may also be set by the originating CPE to
identify low priority ie background frames from normal ie high priority.
Any node in the network, if it becomes too congested will discard any
frames with the DE bit set, and attempt to deliver the rest. If the
congestion persists, the switch(es) will eventually run out of buffers
and they will discard all frames arriving for a period of time
irrespective of whether the DE bit is set or not!
A Cisco router configured as a Frame Relay switch only offers a very
minimal emulation of a Frame Relay switch as used in a Telco network. It
is really only intended for lab type testing.
In principle there are 2 separate independent half circuits 'A to B' and
'B to A' they do not need to have symmetrical traffic parameters nor do
they need to follow reciprocal paths through the network, though it
would be normal for them to be configured to do so. Indeed in most
carrier class switches it is often the case that by default, one only
needs to configure a single entry in the routing (switching) table and
the reciprocal would automatically be put in.
----
2) Link Management Interface (LMI) is there to detect and to convey the
status of each link, a segment at a time.
Consider the model below with 2 switches between A & B.
CPE-A ....link1.....Switch1....link2......Switch2......link3....CPE-B
|------LMI--------| |-------LMI-------| |--------LMI------|
Please note in this case there are 3 independent segments each with
their own LMI. LMI is done a segment at a time and in principle THERE is
NO requirement to use the same lmi-type on each segment. However, both
ends of a link must agree upon which LMI to use.
The segment between the CPE and the switch is known as a UNI (User
Network Interface). The CPE is the User end (intf-type DTE in Cisco
terms). The switch is the Network end (intf-type DCE in Cisco terms)
In link management the User end polls the Network end. It sends LMI link
integrity checks, typically every 10 Seconds. The Network is a server
and only responds to poll requests. If the User does not receive a
response to its polls it marks the link as down.
In the case of a switch to switch link, the segment is known as an NNI
(Network to Network Interface) and is symmetrical. Switch1 polls Switch2
and Switch2 polls Switch1.
Typically every 6th poll is not a simple link integrity check but a
request for a full status update. The full status update message
includes details about all existing dlci s on that port of the switch.
It is this full status update that conveys the important information:
dlci created, dlci deleted, dlci active, and dlci inactive.
'dlci created' means that a new entry has been added to the switch's
routing table.
'dlci deleted' means that a previous entry has been removed from
switch's routing table.
'dlci inactive' means that 1 or more links are down.
'dlci active' means that all links are up from end to end.
Please note, that in principle, a single link may carry up to 1023
different circuits (dlcs) but that there is only a single LMI in
operation.
The LMI types are: Cisco version of Frame Relay Forum LMI (default)
ANSI (T.617 Annex D)
CCITT (Q.933 Annex A)
All three LMI types do basically the same thing. Whereas, ANSI and CCITT
are both sent on dlci 0, the format of the messages is different and
they are not compatible. Cisco LMI again different and is sent on dlci
1023.
So in summary if you change the LMI type at one end of a link then LMI
will cease to function. => The Frame Relay interface will show up, down.
ie L1 up, but L2 down.
If you change the LMI at both ends of a link you can have different LMI
types across a path.
If you want more information on Frame Relay, take a look at the articles
on frame relay forum.
I hope that this helps.
Peter
In article , John Neiberger
writes
>In response to the current frame relay switching thread I setup a little
>experiment at home last night. I configured frame relay switching
>between a hub and two spoke routers, all three using Cisco encapsulation
>and LMI. Show frame pvc indicated that all circuits were active.
>
>Then on one of the spokes I changed the encapsulation to IETF and then
>reset the interface. To my surprise the circuit came back active and
>stayed that way. I thought for certain that it would go inactive but it
>did not.
>
>I then changed the LMI type on the same router to ANSI and the circuit
>died a quick death.
>
>So, it seems that the encapsulation type did not effect the circuit
>status. I guess to understand this more I need to find the frame
>formats for Cisco and ANSI frame relay. Perhaps they are slightly
>interoperable but one has different features than the other.
>Regardless, I didn't expect the circuit to stay up, but it did.
>
>If I later discover why this occurred I will post to the list.
>
>Regards,
>John
>html
>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
--
Peter Whittle
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=8777&t=8777
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
