This article explains prefix-list in a very easy way to understand.

Legacy Frame Relay Traffic Shaping

int s0/0/0
 band 1536
 frame-relay traffic-shaping
 frame-relay interface-dlci 513
  class MC_513
 frame-relay interface-dlci 504
  class MC_504
 exit
exit

map-class frame-relay MC_513
 frame-relay cir 128000
 frame-relay bc  6400
 frame-relay be  51200
 frame-relay mincir 96000
 frame-relay adaptive-shaping becn
map-class frame-relay MC_504
 frame-relay cir 512000
 frame-relay bc  25600
 frame-relay be  0
 frame-relay mincir 384000
 frame-relay adaptive-shaping becn
exit

Class-Based Generic Traffic Shaping for Frame Relay

class-map CM_DLCI_513
 match fr-dlci 513
class-map CM_DLCI_504
 match fr-dlci 504
exit

policy-map PM_FRTS
 class CM_DLCI_513
  shape average 128000 6400 0
  shape adaptive 96000
 class CM_DLCI_504
  shape average 512000 25600 51200
  shape adaptive 384000
 exit
exit

int s0/0/0
 bandwidth 1536
 no frame-relay traffic-shaping
 service-policy output PM_FRTS
exit

MQC-based Frame Relay Traffic Shaping

int s0/0/0
 band 1536
 no frame-relay traffic-shaping
 frame-relay interface dlci 513
  class MC_513
 frame-relay interface dlci 504
  class MC_504
 exit
exit

map-class frame-relay MC_513
 service-policy out PM_513
map-class frame-relay MC_504
 service-policy out PM_504
exit

policy-map PM_513
 class class-default
  shape average 128000 6400 0
  shape adaptive 96000 ! automatically adapt to BECN
 exit
exit

policy-map PM_504
 class class-default
  shape average 512000 25600 51200
  shape adaptive 384000 ! automatically adapt to BECN
 exit
exit

Notes.
Bc = CIR (in bits per seconds) * (Tc/1000)
(Bc + Be) / (Tc/1000) = AIR

Example.

Bc = CIR (in bits per seconds) * (Tc/1000)
Bc = 512000 * 50/1000
Bc = 512000 * 0.05
Bc = 25600

(Bc + Be) / (Tc/1000) = AIR
(25600 + Be) / 0.05 = 1536000
Be = (1536000 * 0.05) – 25600
Be = 51200

Note – 30 December 2011.
For MQC-based Frame Relay Traffic Shaping, inside the policy-map, command shape average needs to be applied first.

ROUTER(config)#policy-map PM_513
ROUTER(config-pmap)# class class-default
ROUTER(config-pmap-c)#  shape adaptive 256000
Traffic Shaping must be enabled on this class before the command can be issued
ROUTER(config-pmap-c)# shape average 384000
ROUTER(config-pmap-c)#shape adaptive 256000

R5 (s0/0/0 – DLCI 504) — (DLCI 405 – s0/0/0) R4
R5 (f0/1 – DLCI 504) — (DLCI 405 – f0/0) R4

I’m trying to configure and mpls ldp between R4 and R5. The configuration is quite straightforward and I’m expecting to have two peering between R5-R4 via serial and fastethernet interfaces.

!R4

conf t

mpls ip
mpls label protocol ldp

int f0/0
 mpls ip
int s0/0/0
 mpls ip
exit

exit

!R5

conf t

mpls ip

int f0/1
 mpls ip
int s0/0/0
 mpls ip
exit

exit

Apparently the ldp peering is only happening between fastethernet interfaces. No adjacency between serial interfaces.

Rack13R5#sh mpls ldp nei
    Peer LDP Ident: 150.13.4.4:0; Local LDP Ident 150.13.5.5:0
        TCP connection: 150.13.4.4.646 - 150.13.5.5.18850
        State: Oper; Msgs sent/rcvd: 126/144; Downstream
        Up time: 01:24:48
        LDP discovery sources:
          FastEthernet0/1, Src IP addr: 183.13.45.4
        Addresses bound to peer LDP Ident:
          183.13.45.4     183.13.46.4     183.13.0.4      150.13.4.4    

Rack13R4#sh mpls ldp nei
    Peer LDP Ident: 150.13.5.5:0; Local LDP Ident 150.13.4.4:0
        TCP connection: 150.13.5.5.18850 - 150.13.4.4.646
        State: Oper; Msgs sent/rcvd: 144/126; Downstream
        Up time: 01:25:07
        LDP discovery sources:
          FastEthernet0/0, Src IP addr: 183.13.45.5
        Addresses bound to peer LDP Ident:
          183.13.105.5    183.13.45.5     183.13.0.5      150.13.5.5

Checking the ldp peering discovery resulting as below

Rack13R5#
Feb 10 23:23:11.183: ldp: Send ldp hello; Serial0/0/0, src/dst 183.13.0.5/224.0.0.2, inst_id 0
Feb 10 23:23:11.375: ldp: Send ldp hello; FastEthernet0/1, src/dst 183.13.45.5/224.0.0.2, inst_id 0
Feb 10 23:23:11.819: ldp: Rcvd ldp hello; FastEthernet0/1, from 183.13.45.4 (150.13.4.4:0), intf_id 0, opt 0xC
Rack13R5#
Feb 10 23:23:15.275: ldp: Send ldp hello; FastEthernet0/1, src/dst 183.13.45.5/224.0.0.2, inst_id 0
Feb 10 23:23:15.871: ldp: Rcvd ldp hello; FastEthernet0/1, from 183.13.45.4 (150.13.4.4:0), intf_id 0, opt 0xC
Feb 10 23:23:15.975: ldp: Send ldp hello; Serial0/0/0, src/dst 183.13.0.5/224.0.0.2, inst_id 0
Rack13R5#
Feb 10 23:23:19.999: ldp: Send ldp hello; FastEthernet0/1, src/dst 183.13.45.5/224.0.0.2, inst_id 0
Feb 10 23:23:20.655: ldp: Rcvd ldp hello; FastEthernet0/1, from 183.13.45.4 (150.13.4.4:0), intf_id 0, opt 0xC
Feb 10 23:23:20.911: ldp: Send ldp hello; Serial0/0/0, src/dst 183.13.0.5/224.0.0.2, inst_id 0
Rack13R5#
Feb 10 23:23:23.751: ldp: Data received!
Feb 10 23:23:24.527: ldp: Send ldp hello; FastEthernet0/1, src/dst 183.13.45.5/224.0.0.2, inst_id 0

I can see R5 is sending ldp hello via f0/1 and s0/0/0. However, R5 only receiving ldp hello back from f0/1 but not s0/0/0.

What’s going on with s0/0/0 sending packet to 224.0.0.2?

Let’s check it out!

Rack13R5#sh access-list 100
Extended IP access list 100
    10 permit ip 183.13.0.0 0.0.0.255 host 224.0.0.2 (140 matches)
Rack13R5#debug ip packet 100
IP packet debugging is on for access list 100
Rack13R5#
Feb 10 23:25:37.435: IP: s=183.13.0.5 (local), d=224.0.0.2 (Serial0/0/0), len 62,
sending broad/multicast
Feb 10 23:25:37.435: IP: s=183.13.0.5 (local), d=224.0.0.2 (Serial0/0/0), len 62,
encapsulation failed
Rack13R5#
Feb 10 23:25:41.859: IP: s=183.13.0.5 (local), d=224.0.0.2 (Serial0/0/0), len 62,
sending broad/multicast
Feb 10 23:25:41.859: IP: s=183.13.0.5 (local), d=224.0.0.2 (Serial0/0/0), len 62,
encapsulation failed

Apparently s0/0/0 having problem sending broadcast/multicast packet destined to 224.0.0.2.

The ultimate question is, does R5 s0/0/0 DLCI 504 and R4 s0/0/0 DLCI 405 configured as broadcast or non-broadcast?

Rack13R5#sh frame-relay map 504
Serial0/0/0 (up): ip 183.13.0.4 dlci 504(0x1F8,0x7C80), static,
              CISCO, status defined, active

Rack13R4#sh frame-relay map 405
Serial0/0/0 (up): ip 183.13.0.5 dlci 405(0x195,0x6450), static,
              CISCO, status defined, active

Apparently they’re not. Therefore, the fix should be pretty should be easy

! R4
int s0/0/0
 frame-relay map ip 183.13.0.5 405 broadcast
! R5
int s0/0/0
 frame-relay map ip 183.13.0.4 504 broadcast

Rack13R5#debug mpls ldp transport events
LDP transport events debugging is on
Rack13R5#
Feb 10 23:32:48.795: ldp: Send ldp hello; FastEthernet0/1, src/dst 183.13.45.5/224.0.0.2, inst_id 0
Rack13R5#
Feb 10 23:32:50.699: ldp: Rcvd ldp hello; Serial0/0/0, from 183.13.0.4 (150.13.4.4:0), intf_id 0, opt 0xC
Feb 10 23:32:51.695: ldp: Send ldp hello; Serial0/0/0, src/dst 183.13.0.5/224.0.0.2, inst_id 0
Rack13R5#
Feb 10 23:32:51.847: ldp: Rcvd ldp hello; FastEthernet0/1, from 183.13.45.4 (150.13.4.4:0), intf_id 0, opt 0xC
Feb 10 23:32:52.687: ldp: Send ldp hello; FastEthernet0/1, src/dst 183.13.45.5/224.0.0.2, inst_id 0
Rack13R5#
Feb 10 23:32:55.387: ldp: Rcvd ldp hello; Serial0/0/0, from 183.13.0.4 (150.13.4.4:0), intf_id 0, opt 0xC
Feb 10 23:32:55.663: ldp: Rcvd ldp hello; FastEthernet0/1, from 183.13.45.4 (150.13.4.4:0), intf_id 0, opt 0xC
Feb 10 23:32:55.911: ldp: Data received!
Feb 10 23:32:56.119: ldp: Send ldp hello; Serial0/0/0, src/dst 183.13.0.5/224.0.0.2, inst_id 0
Rack13R5#
Feb 10 23:32:56.887: ldp: Send ldp hello; FastEthernet0/1, src/dst 183.13.45.5/224.0.0.2, inst_id 0
Rack13R5#
Feb 10 23:32:59.443: ldp: Rcvd ldp hello; FastEthernet0/1, from 183.13.45.4 (150.13.4.4:0), intf_id 0, opt 0xC
Feb 10 23:32:59.987: ldp: Rcvd ldp hello; Serial0/0/0, from 183.13.0.4 (150.13.4.4:0), intf_id 0, opt 0xC
Rack13R5#
Feb 10 23:33:00.795: ldp: Send ldp hello; FastEthernet0/1, src/dst 183.13.45.5/224.0.0.2, inst_id 0
Feb 10 23:33:00.971: ldp: Send ldp hello; Serial0/0/0, src/dst 183.13.0.5/224.0.0.2, inst_id 0

Rack13R5#sh mpls ldp nei
    Peer LDP Ident: 150.13.4.4:0; Local LDP Ident 150.13.5.5:0
        TCP connection: 150.13.4.4.646 - 150.13.5.5.18850
        State: Oper; Msgs sent/rcvd: 140/158; Downstream
        Up time: 01:37:04
        LDP discovery sources:
          FastEthernet0/1, Src IP addr: 183.13.45.4
          Serial0/0/0, Src IP addr: 183.13.0.4
        Addresses bound to peer LDP Ident:
          183.13.45.4     183.13.46.4     183.13.0.4      150.13.4.4 

Rack13R4#sh mpls ldp nei
    Peer LDP Ident: 150.13.5.5:0; Local LDP Ident 150.13.4.4:0
        TCP connection: 150.13.5.5.18850 - 150.13.4.4.646
        State: Oper; Msgs sent/rcvd: 158/140; Downstream
        Up time: 01:37:19
        LDP discovery sources:
          FastEthernet0/0, Src IP addr: 183.13.45.5
          Serial0/0/0, Src IP addr: 183.13.0.5
        Addresses bound to peer LDP Ident:
          183.13.105.5    183.13.45.5     183.13.0.5      150.13.5.5

This frame relay troubleshooting hit me big time. I’ve spent about 7.5 hours just to get this up and running, apparently, due to simple mistake.

The network configured as below.

R5 (s0/0/0 - DLCI 504) --- ( DLCI 405 - s0/0/0) R4
R5 (s0/0/0 - DLCI 513) --- ( DLCI 315 - s1/1) R3

Rack13R5#sh run int s0/0/0
interface Serial0/0/0
 ip address 183.13.0.5 255.255.255.0
 ip pim sparse-dense-mode
 encapsulation frame-relay
 ip ospf network broadcast
 ip ospf dead-interval minimal hello-multiplier 3
 ip ospf priority 255
 frame-relay map ip 183.13.0.3 513 broadcast
 frame-relay map ip 183.13.0.4 504 broadcast
 no frame-relay inverse-arp
end

Rack13R4(config-router)#do sh run int s0/0/0
interface Serial0/0/0
 ip address 183.13.0.4 255.255.255.0
 encapsulation frame-relay
 ip ospf network broadcast
 ip ospf dead-interval minimal hello-multiplier 3
 ip ospf priority 0
 no keepalive
 frame-relay map ip 183.13.0.5 405 broadcast
 frame-relay map ip 183.13.0.3 405
 no frame-relay inverse-arp
end

!R3
interface Serial1/1
 no shutdown
 ip address 183.13.0.3 255.255.255.0
 ip pim sparse-dense-mode
 encapsulation frame-relay
 ip ospf network broadcast
 ip ospf dead-interval minimal hello-multiplier 3
 ip ospf priority 0
 frame-relay map ip 183.13.0.4 315
 frame-relay map ip 183.13.0.5 315 broadcast
 no frame-relay inverse-arp
end

R5-R3 connection is fine but I cannot ping R4 FR IP Addr 183.13.0.4 from R5 and R3.

Rack13R5#ping 183.13.0.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 183.13.0.4, timeout is 2 seconds:
..
Success rate is 0 percent (0/2)

debug ip packet shown below.

Rack13R5#x
*Feb  5 22:09:48.171: IP: s=183.13.0.5 (local), d=183.13.0.4 (Serial0/0/0), len 100, sending
*Feb  5 22:09:48.171:     ICMP type=8, code=0
*Feb  5 22:09:48.171: IP: s=183.13.0.5 (local), d=183.13.0.4 (Serial0/0/0), len 100,
encapsulation failed
*Feb  5 22:09:48.171:     ICMP type=8, code=0
*Feb  5 22:09:50.171: IP: s=183.13.0.5 (local), d=183.13.0.4 (Serial0/0/0), len 100, sending
*Feb  5 22:09:50.171:     ICMP type=8, code=0
*Feb  5 22:09:50.171: IP: s=183.13.0.5 (local), d=183.13.0.4 (Serial0/0/0), len 100,
encapsulation failed
*Feb  5 22:09:50.171:     ICMP type=8, code=0

Apparently the L2 is having problem. Let’s check the DLCI mapping.

Rack13R5#sh frame-relay map
Serial0/0/0 (up): ip 183.13.0.4 dlci 504(0x1F8,0x7C80), static,
              broadcast,
              CISCO, status defined, inactive
Serial0/0/0 (up): ip 183.13.0.3 dlci 513(0x201,0x8010), static,
              broadcast,
              CISCO, status defined, active

Rack13R5#sh frame-relay pvc 504

PVC Statistics for interface Serial0/0/0 (Frame Relay DTE)

DLCI = 504, DLCI USAGE = LOCAL, PVC STATUS = INACTIVE, INTERFACE = Serial0/0/0

  input pkts 0             output pkts 24           in bytes 0
  out bytes 1918           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 26        out bcast bytes 1966
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:04:16, last time pvc status changed 00:04:06

Gotcha, the DLCI 504 is inactive. This is why R5 cannot send L3 packets to R4 via DLCI 504 due to the PVC is INACTIVE. This would also mean that R3 won’t be able to ping R4 as R5 is the hub to reach R4.

Rack13R3#ping 183.13.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 183.13.0.4, timeout is 2 seconds:
..
Success rate is 0 percent (0/2)

Let’s see whether R4 can send the packets out to R5 via DLCI 405.

Rack13R4#ping 183.13.0.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 183.13.0.5, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Rack13R4#
Feb  5 22:04:55.270: IP: s=183.13.0.4 (local), d=183.13.0.5 (Serial0/0/0), len 100, sending
Feb  5 22:04:55.270:     ICMP type=8, code=0
Feb  5 22:04:55.270: IP: s=183.13.0.4 (local), d=183.13.0.5 (Serial0/0/0), len 100,
sending full packet
Feb  5 22:04:55.270:     ICMP type=8, code=0
Feb  5 22:04:57.270: IP: s=183.13.0.4 (local), d=183.13.0.5 (Serial0/0/0), len 100, sending
Feb  5 22:04:57.270:     ICMP type=8, code=0
Feb  5 22:04:57.270: IP: s=183.13.0.4 (local), d=183.13.0.5 (Serial0/0/0), len 100,
sending full packet
Feb  5 22:04:57.270:     ICMP type=8, code=0
Feb  5 22:04:59.270: IP: s=183.13.0.4 (local), d=183.13.0.5 (Serial0/0/0), len 100, sending
Feb  5 22:04:59.270:     ICMP type=8, code=0
Feb  5 22:04:59.270: IP: s=183.13.0.4 (local), d=183.13.0.5 (Serial0/0/0), len 100,
sending full packet
Feb  5 22:04:59.270:     ICMP type=8, code=0
Feb  5 22:05:01.270: IP: s=183.13.0.4 (local), d=183.13.0.5 (Serial0/0/0), len 100, sending
Feb  5 22:05:01.270:     ICMP type=8, code=0
Feb  5 22:05:01.270: IP: s=183.13.0.4 (local), d=183.13.0.5 (Serial0/0/0), len 100,
sending full packet
Feb  5 22:05:01.270:     ICMP type=8, code=0
Feb  5 22:05:03.270: IP: s=183.13.0.4 (local), d=183.13.0.5 (Serial0/0/0), len 100, sending
Feb  5 22:05:03.270:     ICMP type=8, code=0
Feb  5 22:05:03.270: IP: s=183.13.0.4 (local), d=183.13.0.5 (Serial0/0/0), len 100,
sending full packet
Feb  5 22:05:03.270:     ICMP type=8, code=0

Rack13R4#sh frame-relay pvc 405

PVC Statistics for interface Serial0/0/0 (Frame Relay DTE)

DLCI = 405, DLCI USAGE = LOCAL, PVC STATUS = STATIC, INTERFACE = Serial0/0/0

  input pkts 2606          output pkts 38365        in bytes 197551
  out bytes 3061869        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 37556     out bcast bytes 3011444
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 1000 bits/sec, 3 packets/sec
  pvc create time 06:34:40, last time pvc status changed 00:12:34

Looks like R4 is just fine, sending packets out to R5.

INACTIVE status means the PVC is not up. The reason can be the local DLCI mapping issue or the other end is not up. Obviously, the local DLCI mapping is just fine. So, this could be an issue on the other end. (well, there is an FR switch in the middle but I really doubt it causing the problem. I did reload and check the config on the FR switch, all ok)

Rack13R5#sh run int s0/0/0
interface Serial0/0/0
 ip address 183.13.0.5 255.255.255.0
 ip pim sparse-dense-mode
 encapsulation frame-relay
 ip ospf network broadcast
 ip ospf dead-interval minimal hello-multiplier 3
 ip ospf priority 255
 frame-relay map ip 183.13.0.3 513 broadcast
 frame-relay map ip 183.13.0.4 504 broadcast
 no frame-relay inverse-arp
end

If we look the PVC 504 on R5, we could see that the input packets is 0, it means that pvc 504 is not receiving LMI from 405.

Rack13R5#sh frame-relay pvc 504

PVC Statistics for interface Serial0/0/0 (Frame Relay DTE)

DLCI = 504, DLCI USAGE = LOCAL, PVC STATUS = INACTIVE, INTERFACE = Serial0/0/0

  input pkts 0             output pkts 24           in bytes 0
  out bytes 1918           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 26        out bcast bytes 1966
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:04:16, last time pvc status changed 00:04:06

Checking the PVC 405 on R4 again

Rack13R4#sh frame-relay pvc 405

PVC Statistics for interface Serial0/0/0 (Frame Relay DTE)

DLCI = 405, DLCI USAGE = LOCAL, PVC STATUS = STATIC, INTERFACE = Serial0/0/0

  input pkts 2606          output pkts 38365        in bytes 197551
  out bytes 3061869        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 37556     out bcast bytes 3011444
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 1000 bits/sec, 3 packets/sec
  pvc create time 06:34:40, last time pvc status changed 00:12:34

The DLCI 405 is showing STATIC. What STATIC? I know INACTIVE, ACTIVE, and DELETED. But STATIC? Cisco Doco in here and here shows that STATIC means that the PVC is statically created thus no LMI/keepalive being sent.

Checking the config again on R4, you will find the culprit keepalive was disabled.

Rack13R4(config-router)#do sh run int s0/0/0
interface Serial0/0/0
 ip address 183.13.0.4 255.255.255.0
 encapsulation frame-relay
 ip ospf network broadcast
 ip ospf dead-interval minimal hello-multiplier 3
 ip ospf priority 0
 no keepalive <<<===
 frame-relay map ip 183.13.0.5 405 broadcast
 frame-relay map ip 183.13.0.3 405
 no frame-relay inverse-arp
end

Rack13R4(config-if)#do sh int s0/0/0
Serial0/0/0 is up, line protocol is up
  Hardware is GT96K Serial
  Internet address is 183.13.0.4/24
  MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation FRAME-RELAY, loopback not set
  Keepalive not set <<<===
  CRC checking enabled
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 11470/0, interface broadcasts 11470
  Last input 01:36:59, output 00:35:57, output hang never
  Last clearing of "show interface" counters 01:37:00
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/1/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 1158 kilobits/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     1 packets input, 53 bytes, 0 no buffer

Enabling the keepalive (default 10 seconds) brings back both the PVC 405 and 504 to ACTIVE.

Rack13R4(config-if)#int s0/0/0
Rack13R4(config-if)#keepalive ?
  <0-30>  Keepalive period (default 10 seconds)
  

Rack13R4(config-if)#keepalive
Rack13R4(config-if)#
Feb  6 22:52:30.611: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
changed state to down
Rack13R4(config-if)#
Feb  6 22:52:50.611: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
changed state to up
Rack13R4(config-if)#do sh fram pvc 405

PVC Statistics for interface Serial0/0/0 (Frame Relay DTE)

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

  input pkts 0             output pkts 0            in bytes 0
  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:36:53, last time pvc status changed 00:00:20

Rack13R5(config-if)#do sh fram pvc 504

PVC Statistics for interface Serial0/0/0 (Frame Relay DTE)

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

  input pkts 6446          output pkts 6446         in bytes 540482
  out bytes 540590         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 2000 bits/sec, 3 packets/sec
  5 minute output rate 2000 bits/sec, 3 packets/sec
  pvc create time 01:13:54, last time pvc status changed 00:35:42

We can also see that PVC 504 receiving packets.

Initially, I could point the issue that R5 is not receiving LMI. But I guess that’s not good enough. Knowing that PVC STATIC is basically statically assigned DLCI thus won’t send any LMI out would save a lot of my time.

On the other hand, I also need to fix the OSPF issue on this FR by applying non-broadcast network type as shown below.

I realized that I’m really weak on QoS. I’ve read Cisco QOS Exam Certification Guide (IP Telephony Self-Study) (2nd Edition) at least twice, watching the INE QoS WB1, did the INE QoS WB1 twice and I felt like I’ve saturated my head with all of the QoS information.

Knowing that INE releasing a new 642-642 QoS material, I tempted to buy since the description looked promising and pretty comprehensive.

Looking at the outline below, I was convinced that this is the one I was looking for.

Apparently I was right. This product completes my QoS study and I wish INE released this product a very long time ago.

The presentation is very structured and makes you to understand the very basic element of QoS without making things getting very complicated. For example, Anthony Sequeira will guide you literraly step by step, often repeating what he just said in a slower speaking speed, to emphasize the part.

The best part is basically the way this VoD is presented in such a way that each feature is placed under appropriate section. For example, some parts of QoS are Congestion Management, Congestion Avoidance, and Policing and Shaping. I didn’t even know before the difference between Congestion Management and Congestion Avoidance and what were the features involved in it.

I know that Anthony was trying to cover all QoS subject within 5 days but that’s just impossible. QoS is just too vast to cover within just 5 days.

I can say that this product is almost perfect for you to complete your QoS study. I said almost perfect because you need to go deeper by reading Cisco QOS Exam Certification Guide (IP Telephony Self-Study) (2nd Edition) and particularly the INE QoS WB1. I just cannot find any better and painstakinly detailed QoS subject than INE QoS WB1 but you need this QoS Video to start with otherwise you’ll just keep reading without knowing the structure.

One last thing, when you buy this product, you’ll get to have the recorded class session when Anthony did this, the self-paced VoD, and the MP3 version within just one product. This is just awesome.

When you specify the priority command for a class, it takes a bandwidth argument that gives maximum bandwidth in kbps. You use this parameter to specify the maximum amount of bandwidth allocated for packets belonging to the class configured with the priority command. The bandwidth parameter both guarantees bandwidth to the priority class and restrains the flow of packets from the priority class.

In the event of congestion, policing is used to drop packets when the bandwidth is exceeded. – LLQ Bandwidth Allocation

Now, let’s try to simulate this with two routers connected to each other via 64Kbps serial link (int s0/1).

First, see whether the command priority drops packets in the event of congestion.

Rack1R4#sh run int s0/1
Building configuration...

Current configuration : 125 bytes
!
interface Serial0/1
 bandwidth 64000
 ip address 155.1.45.4 255.255.255.0
 clock rate 64000
end

Rack1R5#sh run int s0/1
Building configuration...

Current configuration : 82 bytes
!
interface Serial0/1
 ip address 155.1.45.5 255.255.255.0
 clock rate 64000
end

Rack1R5#ping 155.1.45.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.45.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/7/16 ms
Rack1R5#

Let’s create a simple CBWFQ + LLQ on R4 to prioritize all ICMP packets as much as 48Kbps

! Rack1R4

class-map match-all CM
 match protocol icmp
exit

policy-map PM
 class CM
  priority 48000
 exit
exit

int s0/1
 service-policy out PM
exit

Rack1R4#sh policy-map int s0/1
 Serial0/1 

  Service-policy output: PM

    Class-map: CM (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol icmp
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 48 (kbps) Burst 1200 (Bytes)
        (pkts matched/bytes matched) 0/0
        (total drops/bytes drops) 0/0

    Class-map: class-default (match-any)
      1 packets, 24 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

Let’s flood this link with icmp packets and see whether we can see any drops.

Rack1R5#ping 155.1.45.4 re 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 155.1.45.4, timeout is 2 seconds:
!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!
!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!
Success rate is 94 percent (94/100), round-trip min/avg/max = 1/3/24 ms
Rack1R5# 

Rack1R4#sh policy-map int s0/1
 Serial0/1 

  Service-policy output: PM

    Class-map: CM (match-all)
      100 packets, 10400 bytes
      5 minute offered rate 4000 bps, drop rate 0 bps
      Match: protocol icmp
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 48 (kbps) Burst 1200 (Bytes)
        (pkts matched/bytes matched) 100/10400
        (total drops/bytes drops) 6/624 <<<===

    Class-map: class-default (match-any)
      11 packets, 568 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

We can see that R4 is dropping packets.

Having LLQ limiting packets, what if we put policing inside the class?

Let's make another test by policing the icmp traffic as much as the priority does, 48Kbps and flooding the link again.

class-map match-all CM
 match protocol icmp

policy-map PM
 class CM
  priority 48
    police 48000

interface Serial0/1
 bandwidth 64000
 ip address 155.1.45.4 255.255.255.0
 clock rate 64000
 service-policy output PM

Rack1R4#sh policy-map int s0/1
 Serial0/1 

  Service-policy output: PM

    Class-map: CM (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol icmp
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 48 (kbps) Burst 1200 (Bytes)
        (pkts matched/bytes matched) 0/0
        (total drops/bytes drops) 0/0
      police:
          cir 48000 bps, bc 1500 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        conformed 0 bps, exceed 0 bps

    Class-map: class-default (match-any)
      1 packets, 24 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any 

Rack1R5#ping 155.1.45.4 re 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 155.1.45.4, timeout is 2 seconds:
!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!
!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!
Success rate is 94 percent (94/100), round-trip min/avg/max = 1/3/16 ms

Rack1R4#sh policy-map int s0/1
 Serial0/1 

  Service-policy output: PM

    Class-map: CM (match-all)
      100 packets, 10400 bytes
      5 minute offered rate 3000 bps, drop rate 0 bps
      Match: protocol icmp
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 48 (kbps) Burst 1200 (Bytes)
        (pkts matched/bytes matched) 100/10400
        (total drops/bytes drops) 6/624 <<<===
      police:
          cir 48000 bps, bc 1500 bytes
        conformed 100 packets, 10400 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions: <<<===
          drop
        conformed 3000 bps, exceed 0 bps

    Class-map: class-default (match-any)
      9 packets, 520 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

It seems that the priority command keeps dropping the packets thus making the policing is superfluous.

Let's do another test by lowering the policing limit below the priority and see whether policing is actually dropping the packets.

! @ Rack1R4

policy-map PM
 class CM
  priority 48
    police 48000

Rack1R4#sh policy-map int s0/1
 Serial0/1 

  Service-policy output: PM

    Class-map: CM (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol icmp
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 48 (kbps) Burst 1200 (Bytes)
        (pkts matched/bytes matched) 0/0
        (total drops/bytes drops) 0/0
      police:
          cir 8000 bps, bc 1500 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        conformed 0 bps, exceed 0 bps

    Class-map: class-default (match-any)
      1 packets, 24 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any 

Rack1R5#ping 155.1.45.4 re 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 155.1.45.4, timeout is 2 seconds:
!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!
!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!
Success rate is 94 percent (94/100), round-trip min/avg/max = 1/3/12 ms

Rack1R4#sh policy-map int s0/1
 Serial0/1 

  Service-policy output: PM

    Class-map: CM (match-all)
      100 packets, 10400 bytes
      5 minute offered rate 4000 bps, drop rate 0 bps
      Match: protocol icmp
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 48 (kbps) Burst 1200 (Bytes)
        (pkts matched/bytes matched) 97/10088
        (total drops/bytes drops) 3/312 <<<===
      police:
          cir 8000 bps, bc 1500 bytes
        conformed 97 packets, 10088 bytes; actions:
          transmit
        exceeded 3 packets, 312 bytes; actions: <<<===
          drop
        conformed 4000 bps, exceed 0 bps

    Class-map: class-default (match-any)
      7 packets, 472 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

We can see that policing is dropping packets.

Priority is a conditional policer. For example, if you prioritize 48Kbps icmp traffic and there is no congestion, the traffic can utilize the unused bandwidth.

Policing is an unconditional policer. For example, if you police 48Kbps icmp traffic and there is no congestion, policing will still keep the traffic 48Kbps maximum.

Unless you want to make sure the prioritized traffic is using exact amount of bandwidth without having the option to utilize the unused bandwidth, having policing set with priority will make superfluous configuration task.

The BPDUs communicate and compute the spanning-tree topology. Each configuration BPDU contains this information:

• The unique bridge ID of the switch that the sending switch identifies as the root switch
• The spanning-tree path cost to the root
• The bridge ID of the sending switch
• Message age
• The identifier of the sending interface
• Values for the hello, forward delay, and max-age protocol timers

– Spanning-Tree Topology and BPDUs

Port Fast immediately brings an interface configured as an access or trunk port to the forwarding state from a blocking state, bypassing the listening and learning states. You can use Port Fast on interfaces connected to a single workstation or server, as shown in Figure 18-1, to allow those devices to immediately connect to the network, rather than waiting for the spanning tree to converge.

Interfaces connected to a single workstation or server should not receive bridge protocol data units (BPDUs). An interface with Port Fast enabled goes through the normal cycle of spanning-tree status changes when the switch is restarted. – Understanding Portfast

An NSSA autonomous system boundary router (ASBR) generates the Type 7 LSA so that the routes can be redistributed, and an NSSA area border router (ABR) translates the Type 7 LSA into a Type 5 LSA, which can be flooded throughout the whole OSPF routing domain. – Configuring OSPF NSSA