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]