Scenario 2: Mismatched DLCI Settings
| The importance of this scenario is based on the fact that the DLCI is a super-identifier in Frame Relay. Recall the extended coverage of DLCI formats in Chapter 14, "Frame Relay Technology Background" and the numerous standards and committees that define the rules and scope of DLCI usage. Additionally, rules exist for the number of DLCIs that are configurable on any particular interface or router, and that are restricted by the amount of available memory. In this section, one of the simplest situations is coveredwhen the DLCI does not match the value provisioned by the local service provider. Use the #show frame-relay pvc command to clarify if you have the correct DLCI, as shown in Example 18-15. Example 18-15. Output from the Core Router from the show frame-relay pvc Command 7206-frame#show frame-relay pvc <output omitted> DLCI = 54, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial3/0:0.54 input pkts 0 output pkts 0 in bytes 0 out bytes 0 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 0 out bcast bytes 0 pvc create time 3w3d, last time pvc status changed 3w3d DLCI = 64, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0:0.64 input pkts 41898 output pkts 39200 in bytes 9673029 out bytes 17274236 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 41898 out DE pkts 0 out bcast pkts 10818 out bcast bytes 3245400 pvc create time 3w3d, last time pvc status changed 1d17h DLCI = 67, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial3/0:0.67 input pkts 0 output pkts 0 in bytes 0 out bytes 0 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 0 out bcast bytes 0 switched pkts 0 Detailed packet drop counters: no out intf 0 out intf down 0 no out PVC 0 in PVC down 0 out PVC down 0 pkt too big 0 shaping Q full 0 pkt above DE 0 policing drop 0 pvc create time 3w3d, last time pvc status changed 3w3d <output omitted> From this command, you learn details of the DLCI and the PVC status:
As shown in Example 18-15, DLCI = 64 is active and appears to be fully functional. If the router (on either end of the PVC) reports differently (inactive or deleted) and the cause is because of wrong DLCI settings that are provided by the service provider, an option for resolution is contacting the provider for the correct DLCI. However, Cisco IOS provides features that help recognize the issue. The remote user's router is used for this example. First and foremost, check the configuration shown in Example 18-16 to make sure that the DLCI matches the one provisioned by your provider, and that it is configured correctly. Example 18-16. Verifying the DLCI Settings in the Router Configuration1602-frame# show running-config <output omitted> interface Serial0 no ip address encapsulation frame-relay IETF no ip mroute-cache service-module 56k clock source line service-module 56k network-type dds frame-relay lmi-type ansi ! interface Serial0.16 point-to-point bandwidth 56 ip unnumbered Ethernet0 no ip mroute-cache frame-relay interface-dlci 17 IETF ! <output omitted> Next, check the status of the remote user's interfaces with the show ip interfaces brief command, as shown in Example 18-17. Example 18-17. Verifying the Status of the Interfaces1602-frame#show ip interfaces brief Interface IP-Address OK? Method Status Protocol Ethernet0 10.84.14.169 YES NVRAM up up Serial0 unassigned YES NVRAM up up ! Focus on the next line. What is wrong with serial0.16? Serial0.16 10.84.14.169 YES unset down down 1602-frame# The serial line reports line up, protocol up, but the subinterface is line down, protocol down. To determine what is wrong with the subinterface, identify what the LMI exchanges report, as shown in Example 18-18. Example 18-18. The LMI Statistics, as a Result of the debug frame-relay lmi Command1602-frame#debug frame-relay lmi Frame Relay LMI debugging is on Displaying all Frame Relay LMI data 1602-frame# 1d21h: Serial0(out): StEnq, myseq 175, yourseen 83, DTE up 1d21h: datagramstart = 0x2B9C888, datagramsize = 14 1d21h: FR encap = 0x00010308 1d21h: 00 75 95 01 01 01 03 02 AF 53 1d21h: 1d21h: Serial0(in): Status, myseq 175 1d21h: RT IE 1, length 1, type 1 1d21h: KA IE 3, length 2, yourseq 84, myseq 175 1d21h: Serial0(out): StEnq, myseq 176, yourseen 84, DTE up 1d21h: datagramstart = 0x2B9C888, datagramsize = 14 1d21h: FR encap = 0x00010308 1d21h: 00 75 95 01 01 01 03 02 B0 54 ! The keepalive exchanges are correct and the link is operational, but ! the DLCI requires additional attention. 1d21h: 1d21h: Serial0(in): Status, myseq 176 1d21h: RT IE 1, length 1, type 1 1d21h: KA IE 3, length 2, yourseq 85, myseq 176 1d21h: Serial0(out): StEnq, myseq 177, yourseen 85, DTE up 1d21h: datagramstart = 0x2B9C888, datagramsize = 14 1d21h: FR encap = 0x00010308 1d21h: 00 75 95 01 01 00 03 02 B1 55 1d21h: 1d21h: Serial0(in): Status, myseq 177 1d21h: RT IE 1, length 1, type 0 1d21h: KA IE 3, length 2, yourseq 86, myseq 177 ! Review the next line, it shows dlci 16 1d21h: PVC IE 0x7 , length 0x3 , dlci 16, status 0x2 1d21h: Serial0(out): StEnq, myseq 178, yourseen 86, DTE up 1d21h: datagramstart = 0x2B9C888, datagramsize = 14 1d21h: FR encap = 0x00010308 1d21h: 00 75 95 01 01 01 03 02 B2 56 ! This is an output from full status enquiry, where the listed ! DLCI is 16 and the status is reported 0x2 active. ! The other value would be Inactive 0x0. 1d21h: 1d21h: Serial0(in): Status, myseq 178 1d21h: RT IE 1, length 1, type 1 1d21h: KA IE 3, length 2, yourseq 87, myseq 178 1d21h: Serial0(out): StEnq, myseq 179, yourseen 87, DTE up 1d21h: datagramstart = 0x2B9C888, datagramsize = 14 1d21h: FR encap = 0x00010308 1d21h: 00 75 95 01 01 01 03 02 B3 57 At the same time, the core router report shows the output in Example 18-19 (the core router's configured DLCI is 62). Example 18-19. Verifying the Status of DLCI 62 on the Core Router7206-frame#show ip interface brief Serial3/3:0 unassigned YES NVRAM up up <output omitted> Serial3/3:0.50 10.84.5.222 YES unset up up Serial3/3:0.53 10.84.5.222 YES unset up up Serial3/3:0.55 10.84.5.222 YES unset up up Serial3/3:0.57 10.84.5.222 YES unset down down Serial3/3:0.61 10.84.5.222 YES unset down down ! The serial 3/3:0.62 is reporting UP, UP Serial3/3:0.62 10.84.5.222 YES unset up up Notice that DLCI = 62 is reported as up and up. The information reported from the remote user's router includes all configured PVCs, except for any PVCs with PVC STATUS = DELETED. So based on the initial service provider's confirmation of the service, the provider seems to have configured DLCI = 16, but DLCI=17 is configured on the remote user's router. To verify this suggestion, look at the show frame-relay pvc output, as shown in Example 18-20. Example 18-20. Output from the Remote User's Router After the show frame-relay pvc Command1602-frame#show frame-relay pvc PVC Statistics for interface Serial0 (Frame Relay DTE) Active Inactive Deleted Static Local 0 0 1 0 Switched 0 0 0 0 Unused 1 0 0 0 DLCI = 16, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0 input pkts 3 output pkts 0 in bytes 918 out bytes 0 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 0 out bcast bytes 0 Num Pkts Switched 0 pvc create time 00:02:45, last time pvc status changed 00:02:45 DLCI = 17, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial0.16 input pkts 0 output pkts 1 in bytes 0 out bytes 312 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 1 out bcast bytes 312 pvc create time 00:03:44, last time pvc status changed 00:02:50 1602-frame# You can clearly see that the non-configured Serial0.16 is ACTIVE, and that Serial0.17 is DELETED. The fix is standard and quick to implement, as shown in Example 18-21. Example 18-21. Implementing the Configuration ChangeChange DLCI = 17 to DLCI = 161602-frame#configure terminal Enter configuration commands, one per line. End with CNTL/Z. 1602-frame(config)#interface serial 0.16 1602-frame(config-subif)#frame-relay interface-dlci 16 ietf 1602-frame(config-fr-dlc)#end 1602-frame#write memory ! It is always good practice to check the status of interfaces after ! the change and make sure that the change is successful. ! This is shown in the following output. 1602-frame#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0 10.84.14.169 YES NVRAM up up Serial0 unassigned YES NVRAM up up Serial0.16 10.84.14.169 YES unset up up 1602-frame# After shutting down Serial0.17, verify the PVC status of the remote user's router with the show frame-relay pvc command, as shown in Example 18-22. Example 18-22. Output from the Remote User's Router, Showing the PVC Status1602-frame#show frame-relay pvc PVC Statistics for interface Serial0 (Frame Relay DTE) Active Inactive Deleted Static Local 1 0 0 0 Switched 0 0 0 0 Unused 0 0 0 0 DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.16 input pkts 2829 output pkts 1894 in bytes 505954 out bytes 524513 dropped pkts 0 in FECN pkts 19 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 95 out bcast bytes 30824 pvc create time 01:31:33, last time pvc status changed 01:31:33 1602-frame# NOTE The DLCI = 17 disappears from the configuration and from the show status command's outputs, but not immediately. It disappears only after the box is reloaded. One of the most common problems related to the same issue is that the remote user's router is unable to ping the core router's serial interface. The recommended steps to follow are verifying the correct network address and its mapping to the correct DLCI by using show frame-relay map: 7206-frame#show frame-relay map Serial3/3:0.62 (up): point-to-point dlci, dlci 62(0x3E,0xCE0), broadcast, IETF status defined, active This shows the network address, DLCI number, and interface in use. The status message of "defined and active" can be displayed, even if the DLCI is not working. The message actually indicates that the DLCI can carry data and that the router at the far end is active, which is important end-to-end information. Another important point is to distinguish between different designs, and to realize that you cannot always ping your own Ethernet interface, especially in a multipoint Frame Relay interface. Pings to your own interface address are successful on point-to-point subinterfaces, or HDLC links because the router on the other side of the link knows where to return the Internet Control Message Protocol (ICMP) echo and echo reply packets. Thus, an ICMP is sent and received in the right direction. In point-to-multipoint designs, the multipoint interface has multiple IPs and multiple destinations assigned. Therefore, to successfully send an ICMP reply, the router must have a mapping for every destination. If mapping is not configured, do not expect to receive an ICMP reply because the router does not have any Layer-2 to Layer-3 mapping for its own address and it does not know how to encapsulate the packet. An encapsulation failure is the typical result. You cannot ping from one spoke to another in a hub and spoke configuration by using multipoint interfaces because there is no mapping for the other spokes' IP addresses. Interestingly enough, the same logic applies when you use Frame Relay or ADSL over Asynchronous Transfer Mode (ATM), and use a spoke and hub configuration. Only the hub's address is learned through Inverse Address Resolution Protocol (InARP). If you configure a static map using the frame-relay map command for your IP address or the IP address of a remote spoke, you can ping your interface address and the addresses of other spokes. |
EAN: 2147483647
Pages: 235