AI, ML, Development + Cisco Learning Blog Learning about Machine Learning, Artificial Intelligence, related devlopment topics and formerly Routing and Switching, Datacenter, Security and other topics, CCIE #23664, Frank Wagner

There can be differnet kinds of frame-relay connections. You can lookup the status with „show frame-relay map“ to see what kind of conenction you have.

• dynamic mapping – if frame-relay uses inverse arp to dynamically map the dlci with the ip address, it’s a dynamic mapping
• static mapping – if you use a map statement to statically map the given dlci to an ip address, this is called a static connection.
• broadcast – pon point-to-point links there a „frame-relay interface-dlci“ statement can „setup“ mapping. So this would show up as neither dynamic or static, than broadcast.

These are technices used for congestion control within frame-relay.

A Bit marking 0 or 1 in the BECN oder FECN field, telling there is congestion.

Frame-relay is a layer 2 protocol and does no error checking. Another layer 3 protocol has to do this. But Frame-relay can send congestion notifications on the links, informing there is congestion and to slow down the sending device. It depends on the implementation of the remote device, if these notifications are noted.
Here is what can happen and when one of these are used. If congestion occurs, there are two possible ways of notifying this.

With FECN it’s possbile to send a notifcation to the receiving router, that congestion occured. If in case the receiving router does not have the bandwidth and would be overwhelmed.
With BECN it’s possible to send a notification to the sending local router, that congestion occured.

Source:

http://www.groupstudy.com/archives/ccielab/200209/msg01962.html

http://www.delmar.edu/Courses/ITSC1391/Sem4/6FrameRelay.htm

http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hwan_c/ch05/h_afrts.htm#wp1015437

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/frame.htm#wp1020620

Frame-Relay congestion control can be done on a DLCI basis. Real flow control is done by upper layer protocols. Remember frame-relay is just a layer 2 protocol. So frame-relay just throws packets away and only notifies about congestion. This could be done, for example, by TCP.

So with frame-relay the mechanisms are called congestion-notification. So if a sender is sending to quick, frame-relay is sending a congestion-notification to the sender to slow down. Frame-relay in the meantime, just throws away packets. If a packet is lost, the receiving device has to request e retransmition.
The following terms are important.

• FECN – Forward-explicit congestion notification
• BECN – Backward-explicit congestion notification
• DE – Discard Eligibility
• CIR – Committed Information Rate

Both informations FECN and BECN, are carried as single bit in the frame-relay header.

The header also includes a DE bit, which is responsible for dropping and marking no to important traffic in times of congestion. A frame with the DE bit set, has low priority and can be dropped in case of congestion.

CIR is an agreement about the normal transmission rate over a link in a certain time.

BECN – indicates to the receiving device that frames sent in the opposite direction may experience congestion.

FECN – indicates to the receiving device that the frame has experienced congestion.

DE – discard eligible, which mean, when the DE bit is set in a frame, the packet could be selected for discarding, it’s even possible to set this DE bit, for certain protocols

Terms to know about frame-relay traffic shaping and you can configure them on an interface dlci with a map-class command:

• EIR is the rate that you can exceed CIR before the ingress port will discard your frames.

• CIR – Committed information rate

is the average rate that you can transmit at measured over a time period Tc without having the ingress port on the Frame network flag your frames as over contract by setting the DE bit. If you have multiple connections, the aggregated total of the CIR for all PVC’s should not exceed the physical port speed.

• BC – committed burst

is the maximum amount of data that a network will transfer in one interval of time (Tc) or in other words is the total number of bits that you can send in period Tc and not have the frames marked with DE.

• BE – Burst in excess

is the maximum amount of data that the network will transfer above Bc in one interval of time. When transmitting data at excess burst (Be) these frames would either be dropped by the network at ingress or marked discard eligible (DE) and potentially dropped somewhere else in the network if congestion is experienced

or you can say is the total number of bits in addition to Bc that you can send in period Tc that the switch will allow before discarding any excess traffic at the ingress port to the Frame network.

• MINCIR – minimum committed information rate

The actual guaranteed rate obtained from service provider in bps. This value should be the minimum rate you should drop to in the event of congestion (dropping below this rate implies you are not getting the bandwidth you are paying for). In certain cases the mincir and cir values must be the same. The value of mincir is half of the CIR value in bps by default.

• TC the default is 1/8 = 0.125 seconds, BC=CIR*TC

For example, if you have a CIR of 64000 Bits per second and want for voice a TC of 10 ms (0,01) or 1/100, than BC would be 640 bits. 10 ms is the smallest value for TC.

Parameters you configure:

Example 1.

1. setup the interface for shaping

interface Serial0/0
ip address 152.2.0.1 255.255.255.0
encapsulation frame-relay
frame-relay traffic-shaping
frame-relay interface-dlci 103
class to-router3

2. define a map class containing shaping parameters

map-class frame-relay to-router3
frame-relay cir 32000

32000 Bits per second is the average amount of data on the agreed rate with the service provider. The default an an interface is 57000 bps. Make sure, that the sum of all cir’s configured for one interface does not exceed the bandwidth of the interface. If your remote router does only 16000 Bits per seconds, this CIR rate would be „frame-relay cir 16000“.

Example 2.

1. Setup the interface for frame-relay traffic-shaping

interface Serial0/0
ip address 152.2.0.1 255.255.255.0
encapsulation frame-relay
frame-relay traffic-shaping
frame-relay interface-dlci 103
class to-router3

2. define a map class containig shaping parameters

map-class frame-relay to-router3
frame-relay cir 32000
frame-relay bc 320

So here i use a TC of 10 ms or 0,01 seconds for the configured BC. The advantage is that the router is more able to prioritize certain traffic, would be needed for voice. Because the shorter choosen intervals per second.

CIR = BC/TC

32000=BC/0,01

=> 320=BC

Example 3.

Your Frame-Relay provider gives you a line with a 512k circuit and a CIR of 384k to your network. You would configure it like this.

interface Serial0/0
ip address 152.2.0.1 255.255.255.0
encapsulation frame-relay
frame-relay traffic-shaping
frame-relay interface-dlci 103
class to-router3

map-class frame-relay to-router3
frame-relay cir 512000
frame-relay mincir 384000
frame-relay bc 64000
frame-relay be 128000

Whitch calculates as follows:

CIR = port speed
mincir = commited rate from prvider
be= port – commited rate
bc = port speed / 8

These parameters are inter-related.

CIR = Bc/Tc

BC = CIR * Tc

TC = BC / CIR

BE = Portspeed – CIR

EIR = Be/Tc

Source:

http://www.groupstudy.com/archives/ccielab/200209/msg01962.html

http://www.cisco.com/warp/public/125/traffic_shaping_6151.html

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/frame.htm#wp1020620

http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hwan_c/ch05/h_afrts.htm#wp1015437

To debug frame-relay there are several possibilities.

The first useful command is:

sh frame-relay pvc

With this command you could list all currently configured pvc’s.

This may look like:

DLCI = 314, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1/1

input pkts 1 output pkts 0 in bytes 30
out bytes 0 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:23:07, last time pvc status changed 00:23:07
Note the pcv ACTIVE status. This indicates the pvc is up and running and lmi messages are being send to and from the frame-relay switch .

The PVC can have four possible states. These are shown by the PVC STATUS field as follows:

• ACTIVE – PVC is up and functioning normally.
• INACTIVE – PVC is not up end-to-end. This may be because either there is no mapping (or incorrect mapping) for the local DLCI in the frame-relay cloud or the remote end of the PVC is Deleted.
• DELETED – Either the Local Management Interface (LMI) is not exchanged between the router and the local switch, or the switch does not have DLCI configured on the local switch.
• STATIC – no keepalive configured on the frame-relay interface of the router.

It’s also a good idea, if you have change frame-relay your configuration on an interface, to reload the router. Just to make sure, no old configuration settings are interferring.
The DLCI status can be one of the following:

The DLCI USAGE field contains one of the following entries:

• SWITCHED – the router or access server is used as a switch.
• LOCAL – the router or access server is used as data terminal equipment (DTE).
• UNUSED – the data-link connection identifier (DLCI) is not referenced by user-entered configuration commands on the router.

To find out something about the lmi layer 2 communications between the frame-relay devices you can use:

debug frame-relay lmi

This could also show some information about the satus of the frame-relay link:

*Mar 1 08:51:53.615: Serial1/1(out): StEnq, myseq 43, yourseen 41, DTE up
*Mar 1 08:51:53.615: datagramstart = 0x7B00854, datagramsize = 13
*Mar 1 08:51:53.615: FR encap = 0xFCF10309
*Mar 1 08:51:53.615: 00 75 01 01 00 03 02 2B 29
*Mar 1 08:51:53.615:
*Mar 1 08:51:53.631: Serial1/1(in): Status, myseq 43, pak size 45
*Mar 1 08:51:53.631: RT IE 1, length 1, type 0
*Mar 1 08:51:53.631: KA IE 3, length 2, yourseq 42, myseq 43
*Mar 1 08:51:53.631: PVC IE 0x7 , length 0x6 , dlci 311, status 0x0 , bw 0
*Mar 1 08:51:53.631: PVC IE 0x7 , length 0x6 , dlci 312, status 0x0 , bw 0
*Mar 1 08:51:53.631: PVC IE 0x7 , length 0x6 , dlci 314, status 0x2 , bw 0
R3#
*Mar 1 08:51:53.631: PVC IE 0x7 , length 0x6 , dlci 315, status 0x2 , bw 0
As you can see the lines with „status 0x0“ or „status 0x2“ this could tell you:

Notice the status of „DLCI 314“ in the output above. The possible values of the status field are explained below:

1. 0x0-Added/inactive means that the switch has this DLCI programmed but for some reason (such as the other end of this PVC is down), it is not usable.
2. 0x2-Added/active means the Frame Relay switch has the DLCI and everything is operational. You can start sending it traffic with this DLCI in the header.
3. 0x3-0x3 is a combination of an active status (0x2) and the RNR (or r-bit) that is set (0x1). This means that the switch – or a particular queue on the switch – for this PVC is backed up, and you stop transmitting in case frames are spilled.
4. 0x4-Deleted means that the Frame Relay switch doesn’t have this DLCI programmed for the router. But it was programmed at some point in the past. This could also be caused by the DLCIs being reversed on the router, or by the PVC being deleted by the telco in the Frame Relay cloud. Configuring a DLCI (that the switch doesn’t have) will show up as a 0x4.
5. 0x8-New/inactive
6. 0x0a-New/active

List your static and dynamic mappings and show also witch link is active or has a differnt status:

show frame-relay map

Serial0/0 (up): ip 183.1.0.3 dlci 405(0x195,0x6450), static,
CISCO, status deleted
Serial0/0 (up): ip 183.1.0.5 dlci 405(0x195,0x6450), static,
broadcast,
CISCO, status deleted

or for example:

Serial0/0 (up): ip 183.1.0.4 dlci 504(0x1F8,0x7C80), static,
broadcast,
CISCO, status defined, active
Serial0/0 (up): ip 54.1.1.6 dlci 504(0x1F8,0x7C80), dynamic,
broadcast,, status defined, active
Source:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s12/12sfrsdg.htm

http://www.cisco.com/en/US/tech/tk713/tk237/technologies_tech_note09186a008014f8a7.shtml

The Broadcast keyword means, to allow the specified DLCI to forward broadcast and multicast packets. This is usefull for OSPF.

It is possible to map an ip dynamically or static on an serial interface. With inverse arp the dynamic address resolution is done by the router, trying to find out it’s mapping to the remote device and to make an entry in the local adress table. In this adress table all static and dynamic mappings are recorded.

Another definition is:

The information that correlates to the next-hop router’s Layer 3 address, and the Layer 2 address used to reach it, is called mapping. Mapping is needed on multiaccess networks.

show frame-relay map

inverse arp on the physical interface is enabled by default for configured network protocols (IP, IPX, Appletalk) on cisco routers.

Inverse ARP dynamically creates a mapping between the Layer 3 address (for example, the IP address) and the Layer 2 address (the DLCI). The end result of Inverse ARP is the same as IP ARP on a LAN: The router builds a mapping between a neighboring Layer 3 address and the corresponding Layer 2 address.

Note, „ip routing“ must be enabled on a router for frame-relay inverse-arp to work.

What does inverse arp in frame-relay?

With inverse-arp something is similiar done like with inverse arp in the IP world. The router is trying to map a Layer 2 adresse to a Layer 3 adress.

With show frame-relay map you can list those mappings.

With inverse arp these are dynamic mappings. It’s also possible to map statically.

frame-relay map [ip] [dlci] broadcast

When you configure point-to-point subinterface inverse arp is not needed, as it is disabled be default on each subinterface.

The comment’s on this i found have not been very clearly. I figured out that it might be no really difference between these two configurations.

There is a hard limit in the number of subinterfaces at about 300.

But generally it seems to be a better choice to use point-to-point subinterfaces.

On a point-to-point subinterface, you have to use the frame-relay interface-dlci command to associate a DLCI with the subinterface. There’s no inverse ARP – any IP address that matches the address/subnet-mask is assumed
to be at the end of the DLCI.
On a point-to-multipoint you can either use the frame-relay interface-dlci command and let the inverse-arp generate the frame-relay map, or you can use
the frame-relay map command.
Remember, the frame switch doesn’t know about sub-interfaces, only about a collection of DLCIs. It communicates active DLCI numbers via the ILMI
protocol to the router. The router then has to know which DLCIs are assigned to which subinterfaces. If you haven’t specified which subinterface a DLCI belongs to with either a „frame-relay interface-dlci“ or a „frame-relay map“ then the DLCI is put under the main interface by default.
The inverse ARP protocol is end-to-end between the routers – it has nothing to do with the switches in between.

The difference is also, that it is not possible to configure more than one dlci on a point-to-point interface. The error message is:

%PVC already assigned to sub-interface Serial0/0.3
So if you want to configure more than one dlci on an subinterface, you have to use multipoint. But also pysical interface are multipoint by default.

The formula N(N-1)/2 calculates the number of connections needed for a full mesh.

5 routers for example need 10 pvc’s for the full mesh. 5*4/2=10.

It’s easier to make a table and write down the connections first before configuering frame-relay.

For example here are the serial interfaces with the dlci.
S1      S2      S3      S4      S5

101—201

102 ———-301

103 ——————-401

104 —————————501

——–202–302

——–203———-402

——–204——————-502

—————-303–403

—————-304———–503

———————-404—–504
So if you have configured Router1 with

int s0

encap frame

frame-relay interface-dlci 101

frame-relay interface-dlci 102

frame-relay interface-dlci 103

frame-relay interface-dlci 104

and so on with the other routers r2,r3,r4

your have to configure the siwtch like this:

frame-relay switching

conf t

int s1

encap frame

frame-relay intf-type dce

frame-relay route 101 serial 2 201

frame-relay route 102 serial 3 301

frame-relay route 103 serial 4 401

frame-rleay route 104 serial 5 501

and so on with the other router, like in the table configured before.