• No results found

Full-Mesh Frame Relay Network with One IP Subnet (Multipoint Interfaces)

In document ccna-full (Page 168-172)

Figure 24-1: Full-Mesh Frame Relay Network with One IP Subnet - Frame Relay configuration on RT1, RT2, and RT3:

- Note: Watch out for split horizon issues on multipoint [sub]interfaces. Refer to Page 162 for the discussion and the resolution of this issue.

- Frame Relay configuration can be relatively simple due to the following default IOS settings:

i) The LMI type is automatically sensed. LMI information is exchanged every 10 seconds.

If a router unable to autosense the LMI type, it would use Cisco as the LMI type.

ii) The encapsulation type (of the LAPF headers) is Cisco, instead of IETF.

iii) PVC DLCIs are learned via LMI status messages.

iv) Inverse ARP is enabled by default. It is triggered when a router received the LMI Status Reply message that declares a VC is active. The router then uses Inverse ARP to discover and determine the network address of a remote device by advertising itself by sending an Inverse ARP to each active local DLCI. Inverse ARP messages are sent every 60 seconds.

Note: LMI keepalive messages and LMI status messages are different! LMI keepalive messages are exchanged between DTE and DCE while LMI status messages are only sent in LMI Status Reply messages which are sent from DCE to DTE.

- Frame Relay switches do not care about the encapsulation type and IP addressing. They only care about the LMI type and the CIR.

- A router will be able to figure out the LMI type used in the Frame Relay switch without manual configuration (with the autosense feature). Manual configuration disables the autosense feature.

RTx(config)#int s0/0

RTx(config-if)#encapsulation frame-relay

RTx(config-if)#ip add 200.1.1.{x} 255.255.255.0 RTx(config-if)#no shut

RTx(config-if)#exit

RTx(config)#router eigrp 1

RTx(config-router)#network 200.1.1.0 RTx(config-router)#network 172.16.0.0 RTx(config-router)#no auto-summary

RT1

RT2

S0/0 S0/0 S0/0

RT3 Full-Mesh Frame Relay

200.1.1.2

172.16.1.0

200.1.1.1

200.1.1.3

172.16.2.0

172.16.3.0 DLCI 101

DLCI 102

DLCI 103

- IETF Frame Relay encapsulation type must be used when there is a non-Cisco router (RT3).

Below shows the new configuration on all routers to support the following new requirements:

i) RT3 uses IETF encapsulation on all VCs on the interface.

ii) RT1 and RT2 LMI type should be ANSI, and LMI autosense should not be used.

- RT3 changes its encapsulation type on both VCs on the interface with the ietf keyword in the

encapsulation command. However, RT1 and RT2 cannot change their configuration in this way, as only one of their VCs needs to use IETF encapsulation, another one still use Cisco encapsulation. The encapsulation type can be changed in per-VC basis (use IETF encapsulation on VC to RT3) with the frame-relay interface-dlci {dest-dlci} ietf interface subcommand.

- Service provider’s Frame Relay switches (DCE) send LMI status messages to routers (DTE) to update the virtual circuit status to one of the following 3 states:

ACTIVE Everything is up, the connection is active, and the routers can exchange data.

INACTIVE The router’s interface is up and communicating with the local Frame Relay switch, but the remote router’s connection to its Frame Relay switch is having problem.

DELETED No LMI message is being received from the local Frame Relay switch. It could be a DLCI mapping problem, a line failure, or no service exists between the router and the Frame Relay switch.

RT1 and RT2 configuration:

!

interface Serial0/0

encapsulation frame-relay frame-relay lmi-type ansi

frame-relay interface-dlci 103 ietf ip address 200.1.1.{x} 255.255.255.0

!

RT3 configuration:

!

interface Serial0/0

encapsulation frame-relay ietf ip address 200.1.1.3 255.255.255.0

!

Frame Relay Address Mapping

- It is an important Frame Relay concept for mapping a L3 address with its corresponding L2 address, which is similar to the ARP process used for L3-to-L2 address mapping to figure out the MAC address of the destination device on the same LAN before data transmission. Mapping is only needed on multiaccess networks (point-to-point networks do not require mapping).

- Below shows the output of some Frame Relay address mapping commands on RT1:

- The show frame-relay pvc EXEC command can also be used to display the information of Frame Relay congestion control, eg: the number of FECN and BECN packets.

- There is no DLCIs address mapping configuration on all routers. So how the routers know the appropriate DLCI numbers to use in the Frame Relay LAPF headers when forwarding the encapsulated packets to each other?

- The DLCIs address mapping can be built with either static configuration, or via a dynamic process called Inverse ARP. Inverse ARP resolves an IP address from a DLCI.

- The Inverse ARP process differs from the ARP process on LANs. As soon as a VC is up, the Inverse ARP process starts with the learning of the DLCI via LMI messages, and the router then announces its network layer address by sending an Inverse ARP Request message over the VC, hence allow its neighbor router to build a mapping between its L3 and L2addresses (DLCI).

RT1#sh frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE) Active Inactive Deleted Static Local 2 0 0 0 Switched 0 0 0 0 Unused 0 0 0 0

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0

input pkts 55 output pkts 52 in bytes 4907 out bytes 4845 dropped pkts 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 8 out bcast bytes 482

pvc create time 00:10:51, last time pvc status changed 00:09:41

DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0

input pkts 39 output pkts 18 in bytes 2564 out bytes 4845 dropped pkts 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 8 out bcast bytes 482

pvc create time 00:10:51, last time pvc status changed 00:05:30 RT1#

RT1#sh frame-relay map

Serial0/0 (up): ip 200.1.1.2 dlci 102(0x66,0x1860), dynamic, broadcast,, status defined, active

Serial0/0 (up): ip 200.1.1.3 dlci 103(0x67,0x1870), dynamic, broadcast,, status defined, active

RT1#

Figure 24-2: Inverse ARP - Inverse ARP messages for Figure 24-2:

Sending

Frame Relay is a NBMA network, the broadcast keyword indicates that IP broadcasts can be forwarded to this address, which is necessary for the operations of dynamic routing protocols.

- Note: Issue the no frame-relay inverse-arp interface subcommand before issuing the no shutdown interface subcommand. This ensures that the interface does not perform InARP when it is being enabled.

- The clear frame-relay inarp privileged command clears the dynamic Frame Relay DLCI mappings created by Inverse ARP.

RT1(config)#int s0/0

RT1(config-if)#no frame-relay inverse-arp

RT1(config-if)#frame-relay map ip 200.1.1.2 102 broadcast RT1(config-if)#frame-relay map ip 200.1.1.3 103 broadcast ---

RT2(config)#int s0/0

RT2(config-if)#no frame-relay inverse-arp

RT2(config-if)#frame-relay map ip 200.1.1.1 101 broadcast RT2(config-if)#frame-relay map ip 200.1.1.3 103 broadcast ---

RT3(config)#int s0/0

RT3(config-if)#no frame-relay inverse-arp

RT3(config-if)#frame-relay map ip 200.1.1.1 101 broadcast RT3(config-if)#frame-relay map ip 200.1.1.2 102 broadcast

Frame Relay

Partial-Mesh Frame Relay Network with One IP Subnet Per VC

In document ccna-full (Page 168-172)