Configuring Frame Relay

Frame Relay does not require private and permanently connected wide-area network facilities, unlike some older WAN protocols.

The Frame Relay protocol allows network designers to reduce costs by using shared facilities that are managed by a Frame Relay service provider. Users pay fixed charges for the local connections from each site in the Frame Relay network to the first point of presence (POP) in which the provider maintains a Frame Relay switch. The portion of the network between the end point switches is shared by all the customers of the service provider, and individual Data Link Connection Identifiers (DLCIs) are assigned to ensure each customer receives only their own traffic. Users contract with their providers for a specific minimum portion of the shared bandwidth Committed Information Rate (CIR) and for a maximum allowable peak rate, Burst Information Rate (BIR). Depending on the terms of the contract, traffic exceeding the CIR can be marked as eligible for discard, in the event of network congestion, or a best effort term can apply up to the BIR rate.

Point-to-Point Protocol (PPP) encapsulation is the default encapsulation type for physical interfaces. You need not configure encapsulation for any physical interfaces that support PPP encapsulation. If you do not configure encapsulation, PPP is used by default. For physical interfaces that do not support PPP encapsulation, you must configure an encapsulation to use for packets transmitted on the interface. You can optionally configure an encapsulation on a logical interface, which is the encapsulation used within certain packet types.

Frame Relay encapsulation is defined in RFC 1490, Multiprotocol Interconnect over Frame Relay .

For Frame Relay interfaces, you configure Frame Relay encapsulation on the physical interface. SONET and T3 interfaces can use Frame Relay encapsulation. To configure Frame Relay encapsulation on a physical interface, include the encapsulation statement, specifying the frame-relay option:

 [edit interfaces  interface-name  ]  encapsulation frame-relay; 

When you configure a multipoint encapsulation (such as Frame Relay), the physical interface can have multiple logical units, and the units can be either point to point or multipoint. When you are using Frame Relay encapsulation, you must disable keepalives to ensure that the interface sends LMI requests . If keepalives are not disabled, LMI requests are not sent.

Generally, you configure an interface's encapsulation at the [edit interfaces interface-name ] hierarchy level. However, for Frame Relay encapsulation, you can also configure the encapsulation type that is used inside the Frame Relay packet itself. To do this, include the encapsulation statement, specifying the frame-relay-ccc option:

 [edit interfaces  interface-name  unit  logical-unit-number  ]  encapsulation frame-relay-ccc; 

For more information about MTUs, see Table 6.2, Table 6.3, and Table 6.4 beginning on page 191.

For Frame Relay interfaces, the default media MTU is 4,482 bytes. To modify the default media MTU size for a physical interface, include the mtu statement:

 [edit interfaces  interface-name  ]  mtu  bytes  ; 

If you change the size of the media MTU, you must ensure that the size is equal to or greater than the sum of the protocol MTU and the encapsulation overhead. You configure the protocol MTU by including the mtu statement at the [edit interfaces interface-name unit logical-unit-number family family ] hierarchy level:

 [edit interfaces  interface-name  unit  logical-unit-number  family  family  ] mtu  mtu  ; 

By default, physical interfaces configured with Cisco HDLC or PPP encapsulation send keepalive packets at 10-second intervals. The Frame Relay term for keepalives is Local Management Interface (LMI) packets; note that the JUNOS software supports both ANSI T1.617 Annex D LMIs and ITU Q933 Annex A LMIs. To disable the sending of keepalives on a physical interface, include the no-keepalives statement:

 [edit interfaces  interface-name  ]  no-keepalives; 

On interfaces configured with Frame Relay connections, you can tune the keepalive settings by using the lmi statement. A Frame Relay interface can be either data circuit-terminating equipment (DCE) or data terminal equipment (DTE) (the default JUNOS configuration). DTE acts as a master, requesting status from the DCE part of the link. By default, the JUNOS software uses ANSI T1.617 Annex D LMIs. To change to ITU Q933 Annex A LMIs, include the lmi-type itu statement:

 [edit interfaces  interface-name  lmi]  lmi-type itu; 

To configure Frame Relay keepalive parameters, include the lmi statement:

 [edit interfaces  interface-name  ]  lmi {   lmi-type (ansi  itu);   n391dte  number  ;   n392dce  number  ;   n392dte  number  ;   n393dce  number  ;   n393dte  number  ;   t391dte  seconds  ;   t392dce  seconds  ; } 

You can set the following parameters:

• n391dte ” DTE full status polling interval. The DTE sends a status inquiry to the DCE at the interval specified by the t391dte statement. The value specifies the frequency at which these inquiries expect a full status report; for example, a n391dte value of 10 would specify a full status report in response to every tenth inquiry. The intermediate inquiries ask for a keepalive exchange only. The range is 1 through 255, with a default value of 6.

• n392dce ” DCE error threshold, which is the number of errors required to bring down the link, within the event-count specified by the n393dce statement. The range is 1 through 10, with a default value of 3.

• n392dte ” DTE error threshold, which is the number of errors required to bring down the link, within the event-count specified by the n393dte statement. The range is 1 through 10, with a default value of 3.

• n393dce ” DCE monitored event-count. The range is 1 through 10, with a default value of 4.

• n393dte ” DTE monitored event-count. The range is 1 through 10, with a default value of 4.

• t391dte ” DTE keepalive timer, which is the period at which the DTE sends out a keepalive response request to the DCE and updates status depending on the DTE error threshold value. The range is 5 through 30 seconds, with a default value of 10 seconds.

• t392dce ” DCE keepalive timer, which is the period at which the DCE checks for keepalive responses from the DTE and updates status depending on the DCE error threshold value. The range is 5 through 30 seconds, with a default value of 15 seconds.

Frame Relay interfaces support inverse Frame Relay ARP, as described in RFC 2390. When inverse Frame Relay ARP is enabled, the router responds to received inverse Frame Relay ARP requests by providing IP address information to the requesting router on the other end of the Frame PVC (permanent virtual circuit). The router does not initiate inverse Frame Relay ARP requests. By default, inverse Frame Relay ARP is disabled. To configure a router to respond to inverse Frame Relay ARP requests, include the inverse-arp statement. You must also configure Frame Relay encapsulation on the logical interface to support inverse ARP.

 [edit interfaces  interface-name  unit  logical-unit-number  ]  inverse-arp ; 

By default, when you configure an interface with Frame Relay encapsulation, the router is assumed to be a DTE. That is, the router is assumed to be at a terminal point on the network. To configure the router to be a DCE, include the dce statement. When you configure the router to be a DCE, keepalives are disabled by default.

 [edit interfaces  interface-name  ]  dce; 

When you are using Frame Relay encapsulation on an interface, each logical interface corresponds to one or more permanent virtual circuits (PVCs) or switched virtual circuits (SVCs). For each PVC or SVC, you must configure one data-link connection identifier (DLCI). A Frame Relay interface can be a point-to-point interface or a point-to-multipoint (also called a multipoint nonbroadcast multiaccess [NBMA]) connection.

To configure a point-to-point Frame Relay connection, include the dlci statement:

 [edit interfaces  interface-name  unit  logical-unit-number  ]  dlci  dlci-identifier  ; 

dlci-identifier is the DLCI identifier, which is a number from 1 through 1,022. Numbers 1 through 15 are reserved. A point-to-point interface can have one DLCI. When you are configuring point-to-point connections, the MTU sizes on both sides of the connection must be the same.

To configure a point-to-multipoint Frame Relay connection (also called a multipoint NBMA connection), include the multipoint-destination statement:

 [edit interfaces  interface-name  unit  logical-unit-number  ]  address  address  {   multipoint-destination  destination  -  address  dlci  dlci-   identifier  ; } 

address is the interface's address. For each destination, include one multipoint-destination statement. destination - address is the address of the remote side of the connection, and dlci-identifier is the DLCI identifier for the connection. When you are configuring point-to-multipoint connections, all interfaces in the subnet must use the same MTU size. If keepalives are enabled, causing the interface to send LMI messages during idle times, the number of possible DLCI configurations is limited by the MTU selected for the interface.

By default, Frame Relay connections assume unicast traffic. If your Frame Relay switch performs multicast replication, you can configure the connection to support multicast traffic by including the multicast-dlci statement:

 [edit interfaces  interface-name  unit  logical-unit-number  ]  multicast-dlci  dlci-identifier  ; 

dlci-identifier is the DLCI identifier, which is a number from 1 through 1,022 that defines the Frame Relay DLCI over which the switch is expecting to receive multicast packets for replication. You can configure multicast support only on point-to-multipoint Frame Relay connections.