Verifying PVC Status

Cisco.com

Indicates PVC status

R2# show frame-relay pvc

PVC Statistics for interface SerialO/O (Frame Relay DTE)

Local

Switched

Unused

Active 1 0 0

Inactive 0 0 0

Deleted 3 0 0

Static 0 0 0

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

input pkts 4 5 ou t bytes 0 in BECN pkts 0 in DE pkts 0 out bcast pkts 0

output pkts 0 dropped pkts 0 out FECN pkts 0 out DE pkts 0 out bcast bytes 0

in bytes 13230 in FECN pkts 0 out BECN pkts 0

pvc create time 01:46:39, last time pvc status changed

Indicates the DLCI number associated with the PVC

Indicates the interface on which the PVC was learned

© 2002, Cisco Systems, Inc. All rights reservec

50:19

To verify the status of PVCs on the router, enter the following command: Table 2-14: <show frame-relay pvc [dlci] > Command

Command

Description

show frame-relay pvc [dlci]

Displays PVC status

This command also displays parameters dealing with the number of dropped packets, packets marked as Discard Eligible (DE), the number of Backward Explicit Congestion Notifications (BECNs) and Forward Explicit Congestion Notifications (FECNs) received. These items are helpful in verifying the configuration of Frame Relay Traffic Shaping (FRTS). FRTS is covered in Module 12: VoIP, QoS, and Security. Under normal conditions, all PVCs should have a status of "Active".

Table 2-15:

PVC Status

Problem Description

Active

Both sides of the PVC are up and configured properly. The Frame Relay switch also has the correct Frame Relay route statements.

Inactive

This status indicates that the PVC associated with the corresponding DLCI number is being offered by the Frame Relay switch, but not being used by the router.

Deleted

This status indicates that the router has been configured with a DLCI number that is not offered by the Frame Relay switch. As a result, the PVC cannot be created and therefore is "deleted".

If you receive a PVC status of "Inactive" or "Deleted", double check the DLCI numbering and make certain that the router is configured with the correct DLCIs. DLCI numbers are configured with either the frame-relay map command for physical interfaces/multipoint subinterfaces or the frame-relay interface-dlci command for point-to-point subinterfaces. A common mistake is the accidental reversal of DLCI numbering. For instance, if the DLCI number that is supposedly assigned to the spoke router shows up as "Inactive" on the hub, there is a good chance that the DLCI numbers are reversed.

Verifying ACCress Mappings

Serial0/0 (up): ip 172.16.23.3 dlci 2 03(0xCB,0x3 0B0), static, broadcast,

CISCO, status defined, active

Serial0/0.134 (up): ip 172.16.134.1 dlci 3 01(0x12D,0x4 8D0), static, broadcast,

CISCO, status defined, active Serial0/0.134 (up): ip 172.16.134.4 dlci 3 04(0x13 0,0x4C00), static, broadcast,

CISCO, status defined, active Serial0/0.23 (up): point-to-point dlci, dlci 3 02(0x12E,0x4 8E0), broadcast status defined, active

© 2002, Cisco Systems, Inc. All rights reserved. Cisco CCIE Prep vl.O—Mod

le 2-39

Once you are certain the router is configured with the correct PVCs, you should verify the remote Layer 3 address-to-DLCI mappings. To view the address mapping table on a Cisco router, use the following command:

Table 2-16: < show frame-relay map > Command

Command

Description

show frame-relay map

Displays the current address mapping entries

Mappings in this table will either be marked as static or dynamic. Static means that they were statically configured using the frame-relay map command. Dynamic indicates that they were learned via Inverse ARP. Point-to-point subinterfaces do not use address mappings and will show up as a point-to-point dlci in the show frame relay map command.

If you are not using Inverse ARP and you notice dynamic mappings in the output of the show frame-relay map command, you should clear them with the following command:

Table 2-17: < clear frame-relay-inarp > Command

Command

Description

clear frame-relay-inarp

Clears dynamically created Frame Relay maps, which are created by the use of Inverse ARP

Note Some versions of the IOS will actually require a reload of the router to clear Inverse ARP

entries, even after this command has been entered.

Debugging IP Traffic

CiGco.com

R3(config)# access-list 101 permit ip host 172.16.134.3 host 172.16.134.1

R3# debug ip packet

101

R3# ping 172.16.134

4

Type escape sequence to abort.

Sending 5, 100-byte

ICMP Echos to 172.16.134.4, timeout is 2 seconds

Success rate is 100

percent (5/5), round-trip min/avg/max = 56/57/60

ms

R3# ping 172.16.134

1

Type escape sequence to abort.

Sending 5, 100-byte

ICMP Echos to 172.16.134.1, timeout is 2 seconds

Success rate is 100

percent (5/5), round-trip min/avg/max = 56/58/60

ms

R3#

06:25:51: IP: s=172

16.134.3 (local), d=172.16.134.1 (Serial0/0.134)

len

100,

s

ending

06:25:51: IP: s=172

16.134.3 (local), d=172.16.134.1 (Serial0/0.134)

len

100,

s

ending

06:25:51: IP: s=172

16.134.3 (local), d=172.16.134.1 (Serial0/0.134)

len

100,

s

ending

06:25:51: IP: s=172

16.134.3 (local), d=172.16.134.1 (Serial0/0.134)

len

100,

s

ending

06:25:51: IP: s=172

16.134.3 (local), d=172.16.134.1 (Serial0/0.134)

len

100,

s

ending

© 2002, CiscoSystems, Inc. All rights reserved.

Cisco CCIE Prep

v1.0—Module 2-28

If everything looks good up to this point, you are probably dealing with a Layer 3 or remote Layer 3 address-to-DLCI mapping issue. You can pinpoint this by using the following command:

Table 2-18: < debug ip packet [ access-list number ] > Command

Command

Description

debug ip packet

[ access-list number ]

Displays general IP debugging information

access-list number

IP access list that you can specify. If the datagram is not permitted by that access list, the related debugging output is suppressed.

If you see the following output in the debug ip packet command when trying to ping a remote Frame Relay router, you are dealing with a Layer 2 or remote Layer 3 address-to-DLCI mapping issue.

IP: s=172.16.1.3 (local), d=172.16.1.1 (SerialO), len 100 sending

IP: s=172.16.1.3 (local), d=172.16.1.1 (SerialO), len 100, encapsulation failed.

Note The debug ip packet command generates a significant amount of output. Use it only when traffic on the IP network is low, so that other activity on the router is not adversely affected. It is also highly recommend that you use an access list with this command to filter out traffic that you are not interested in debugging.

R4# show frame-relay map

SerialO/1 (up): ip 172.16.134.3 dlci 4 03(0x193,0x643 0), static, broadcast,

CISCO, status defined, active R4# debug frame-relay packet

R4# ping 172.16.134.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.134.3, timeout is 2 seconds:

Success rate is 100 percent (5/5), round-trip min/avg/max = 56/58/60 ms 06:40:38: Serial0/1(o): dlci 403(0x6431), pkt type 0x800(IP), datagramsize 104 06:40:38: Serial0/1(i): dlci 403(0x6431), pkt type 0x800, datagramsize 104 <output omitted>

R4# ping 172.16.134.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.134.1, timeout is 2 seconds:

06

41

58:

Serial0/1

Encaps

failed-

-no

map

entry

link

7(IP)

06

42

00:

Serial0/1

Encaps

failed-

-no

map

entry

link

7(IP)

06

42

02:

Serial0/1

Encaps

failed-

-no

map

entry

link

7(IP)

06

42

04:

Serial0/1

Encaps

failed-

-no

map

entry

link

7(IP)

06

42

06:

Serial0/1

Encaps

failed-

-no

map

entry

link

7(IP)

Success rate is 0 percent (0/5)

Success rate is 0 percent (0/5)

© 2002, Cisco Systems, Inc. All rights reservec

To see what is happening at the packet level of a Frame Relay packet in real-time use the following command:

Table 2-19: < debug frame-relay packet [interface [dlci value]] > Command

Command

Description

debug frame-relay packet [interface [dlci value]]

Displays information on packets that have been sent and received on a Frame Relay interface

This command allows you to analyze packets that are sent across a Frame Relay interface. Due to the fact that the debug frame-relay packet command generates large amounts of output, use it only when traffic on the Frame Relay network is less than 25 packets per second. Additionally, you should use the optional keywords to limit the debugging output to a specific DLCI or interface.

This command is very useful in verifying the configuration of remote Layer 3 address-to-DLCI mappings.

The following line in the output of the command indicates that no address mapping exists for the destination IP address.

SerialO:Encaps failed—no map entry link 7(IP)

Table 2-20:

Field Descriptions - debug frame-relay packet

Description

serialO:

Interface that has been sent to the Frame Relay packet

broadcast = 1

Destination of the packet. Possible values include the following:

■ broadcast = 1—Broadcast address

■ broadcast = O—Particular destination broadcast search—Searches all Frame Relay map entries for this particular protocol that include the keyword broadcast

link 8O9B

Link type, as documented in the debug frame-relay command

addr 172.16.1.1

Destination protocol address for this packet. In this case, it is an IP address.

SerialO(o):

(o) indicated that this is an output event

DLCI 5OO

Decimal value of the DLCI

type 8O9B

Packet type, as documented in the debug frame-relay command

size 24

Size of this packet (in bytes)

0 0

Post a comment