EIGRP Authentication PPPoFR Virtual-template

Example of EIGRP authentication by using different passwords for each neighbor in frame relay network.

R1 - R2  
using md5 and CISCO12 as a password.
R1 - R3
using md5 and CISCO13 as a password.
Note
We are not allowed to use sub-interface at R1

Configuration

R1

key chain MY_KEY13
 key 1
   key-string CISCO13
!
key chain MY_KEY12
 key 1
   key-string CISCO12


interface Serial0/0
 ip address 192.168.1.1 255.255.255.0
 encapsulation frame-relay
 clock rate 2000000
 frame-relay interface-dlci 102 ppp Virtual-Template1
 frame-relay interface-dlci 103 ppp Virtual-Template2
 frame-relay lmi-type ansi
!

interface Virtual-Template1
 ip address 192.168.1.1 255.255.255.0
 ip authentication mode eigrp 1 md5
 ip authentication key-chain eigrp 1 MY_KEY12
!
interface Virtual-Template2
 ip address 192.168.1.1 255.255.255.0
 ip authentication mode eigrp 1 md5
 ip authentication key-chain eigrp 1 MY_KEY13
!
router eigrp 1
 network 0.0.0.0
 auto-summary

 

R2

key chain MY_KEY

 key 1

   key-string CISCO12

interface Serial0/0

 ip address 192.168.1.2 255.255.255.0

 encapsulation frame-relay

 clock rate 2000000

 frame-relay interface-dlci 201 ppp Virtual-Template1

!

!

interface Virtual-Template1

 ip address 192.168.1.2 255.255.255.0

 ip authentication mode eigrp 1 md5

 ip authentication key-chain eigrp 1 MY_KEY

!

router eigrp 1

 network 0.0.0.0

 auto-summary

R3

key chain MY_KEY

 key 1

   key-string CISCO13

!

!

!

interface Serial0/0

 ip address 192.168.1.3 255.255.255.0

 encapsulation frame-relay

 clock rate 2000000

 frame-relay interface-dlci 301 ppp Virtual-Template1

!

interface Virtual-Template1

 ip address 192.168.1.3 255.255.255.0

 ip authentication mode eigrp 1 md5

 ip authentication key-chain eigrp 1 MY_KEY

!

router eigrp 1

 network 0.0.0.0

 auto-summary

Multilink PPP

The point of Multilink PPP is to take multiple PPP links and “bond” them together to act as a single PPP link. These PPP links that are being bonded could be an ISDN BRI circuit, T1 circuits, or other types of PPP circuits. Also, with multilink PPP, it can breaks large packets into smaller pieces, and send them other multiple physical links simulataneously.

Configuration example

Multilink PPP over Frame Relay (MLPPPoFR)

Configuration
R1
interface Multilink1
 ip address 192.168.1.1 255.255.255.0
 ppp multilink
 ppp multilink interleave
 ppp multilink group 1
!
interface FastEthernet0/0
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 frame-relay map ip 192.168.1.2 102
 frame-relay interface-dlci 102 ppp Virtual-Template1
 no frame-relay inverse-arp
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface Serial0/1
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 frame-relay map ip 192.168.1.2 102
 frame-relay interface-dlci 102 ppp Virtual-Template1
!
interface Virtual-Template1
 ip address 192.168.1.1 255.255.255.0
 ppp multilink
 ppp multilink interleave
 ppp multilink group 1
!

R2

interface Multilink1
 ip address 192.168.1.2 255.255.255.0
 ppp multilink
 ppp multilink interleave
 ppp multilink group 1
!
interface FastEthernet0/0
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 frame-relay map ip 192.168.1.1 201
 frame-relay interface-dlci 201 ppp Virtual-Template1
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface Serial0/1
 no ip address
 encapsulation frame-relay
 shutdown
 clock rate 2000000
 frame-relay map ip 192.168.1.1 201
 frame-relay interface-dlci 201 ppp Virtual-Template1
!
interface Virtual-Template1
 no ip address
 ppp multilink
 ppp multilink interleave
 ppp multilink group 1

Verify Configuration

Router#show ppp multilink

Multilink1

  Bundle name: Router

  Remote Endpoint Discriminator: [1] Router

  Local Endpoint Discriminator: [1] Router

  Bundle up for 00:10:20, total bandwidth 100000, load 1/255

  Receive buffer limit 12000 bytes, frag timeout 1000 ms

  Interleaving disabled

    0/0 fragments/bytes in reassembly list

    0 lost fragments, 0 reordered

    0/0 discarded fragments/bytes, 0 lost received

    0xF received sequence, 0x16 sent sequence

  Member links: 1 active, 2 inactive (max not set, min not set)

    Vi3, since 00:10:20, 375000 weight, 1496 frag size

    Vi1 (inactive)

    Vt1 (inactive)

No inactive multilink interfaces

Router#

Reference

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/mlppp_over_fr_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1027188

Frame-Relay End-to-end Keepalive

Frame-Relay end to end keepalives provides status to verify that end-to-end communications are working and that traffic is getting through.

The Frame-Relay End-to-End keepalive feature can be configured in 4 modes
- biirectional mode 
    -  both the send side and receive side are enable
- request mode
    - only the send side in enabled, and the device sends out and waits for replies to its keepalives requests
- reply mode
    - only the receive side is enabled, and the device waits for and replies to keepalive request.
- passive reply mode
    -  the device only responds to keepalive requests, but does not set any timers or keep track of any events

Example Configuration 


interface Serial1/0
 ip address 192.168.1.1
 encapsulation frame-relay
 shutdown
 serial restart-delay 0
 frame-relay interface-dlci 101
  class END2END_KEEPALIVE
!
map-class frame-relay END2END_KEEPALIVE
 frame-relay end-to-end keepalive mode request
!

Verification
show frame-relay end-to-end keepalive

Legacy Frame Relay

Legacy FRTS has the following characteristics:

- Enabled with frame-relay traffic-shaping command at physical interface level
- Incompatible with GTS or MQC commands at subinterfaces or physical interface levels
- With FRTS you can enforce bitrate per-VC (VC-granular, unlike GTS), by applying a map-class to PVC
- When no map-class is explicitly applied to PVC, it’s CIR and Tc are set to 56K/125ms by default
- Shaping parameters are configured under map-class frame-relay configuration submode
- Allows to configure fancy-queueing (WFQ/PQ/CQ) or simple FIFO per-VC
- No option to configure fancy-queueing at interface level: interface queue is forced to FIFO (if no FRF.12 is configured)
- Allows for adaptive shaping (throttling down to minCIR) on BECN reception (just as GTS) and option to reflect incoming FECNs as BECNs
- Option to enable adaptive shaping which responds to interface congestion (non-empty interface queue)

Example


map-class frame-relay SHAPE_384K
 frame-relay cir 384000
 frame-relay bc 3840
 frame-relay be 0
 !
 ! Adaptive shaping: respond to BECNs and interface congestion
 !
 frame-relay adaptive-shaping becn
 frame-relay adaptive-shaping interface-congestion
 !
 ! Per-VC fancy-queueing
 !
 frame-relay fair-queue
!
interface Serial 0/0/0:0
 frame-relay traffic-shaping
!
interface Serial 0/0/0:0.1
 ip address 177.0.112.1 255.255.255.0
 frame-relay interface-dlci 112
  class SHAPE_384K


Reference
http://blog.ine.com/2008/01/22/legacy-frts/

Multicast over Frame Relay

Interesting Note.
http://www.cisco.com/en/US/docs/ios/solutions_docs/ip_multicast/White_papers/frmrlay.html

Voice Adaptive Traffic Shaping

Voice Adaptive Traffic Shaping is only acailable with MQC-based Frame-Relay traffic shaping, and only with LLQ enabled in sharper-queue. The goal of VATS is to throttle the PVC's sending rate once the system detected voice packets in the priority queue. The VATS feature is useful in the oversubscription scenaiio, where the customer sends traffic over the CIR. When the voice packet comes in the priority queue. the system will signal the shaper to slow its rate down to ensure router will never drop or delay any voice packets.

Command
policy-map class
shape fr-voice-adapt <deactivation N>
   where N = number of seconds to deactivate shaping after the last voice packet has been seen in the priority queue.

Referecence
CCIE R&S lab INE workbook I v5.0 

PPPoFR

Sample Configuration of PPPoFR

Configuration
R1 and R2 are connected via Frame relay network. We now configure PPPoFR with the network 192.168.1.0/24 as below.

R1
!
interface Serial1/0
 no ip address
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay interface-dlci 102 ppp Virtual-Template10
end
!

interface Virtual-Template10
 ip address 192.168.1.1 255.255.255.0

R2

interface Serial1/0

 no ip address

 encapsulation frame-relay

 no fair-queue

 serial restart-delay 0

 frame-relay interface-dlci 201 ppp Virtual-Template10

!

interface Virtual-Template10

 ip address 192.168.1.2 255.255.255.0

!

Verify configuration



R1#sh ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            unassigned      YES unset  administratively down down
FastEthernet0/1            unassigned      YES unset  administratively down down
Serial1/0                  unassigned      YES unset  up                    up
Serial1/1                  unassigned      YES unset  administratively down down
Serial1/2                  unassigned      YES unset  administratively down down
Serial1/3                  unassigned      YES unset  administratively down down
Virtual-Access1            unassigned      YES unset  down                  down
Virtual-Access2            192.168.1.1     YES TFTP   up                    up
Virtual-Template10         192.168.1.1     YES manual down                  down

R1#sh int virtual-access2
Virtual-Access2 is up, line protocol is up
  Hardware is Virtual Access interface
  Internet address is 192.168.1.1/24
  MTU 1500 bytes, BW 100000 Kbit, DLY 100000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP Open
  Open: IPCP
  PPPoFR vaccess, cloned from Virtual-Template10
  Vaccess status 0x44
  Bound to Serial1/0 DLCI 102, Cloned from Virtual-Template10, loopback not set
  Keepalive set (10 sec)
  DTR is pulsed for 5 seconds on reset
  Last input 00:00:02, output never, output hang never
  Last clearing of "show interface" counters 00:04:53
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     23 packets input, 364 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     51 packets output, 582 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

R1# ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/70/108 ms
R1#

Troubleshooting Frame Relay (Layer 2)

Troubleshooting frame relay (layer2)

The basic command that we need to consider on every troubleshooting is "sh ip int brief". Consider status of Line and Protocol. Line means layer 1. and Protocol means layer 2.

For frame-relay.
If line is down, protocol is down.  =  physical layer issue
If line is up, protocol is down       =  layer 2 problem such as encapsulation, lmi type mismatch

These followings VC status helps you understand more about layer 2 frame-relay. So we can know exactly where the problem is.

VC information

ACTIVE       =  normal operation

INACTIVE   =  locally up but not end-to-end

DELETED     = Conflict in DLCI configured locally and Frame relay switch

STATIC        = LMI keepalive is disabled.

Example1
//the interface of the other end is shutdown. No comminication of LMI
R1 interface : encapsulation frame-relay
R1# show frame-relay pvc


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

              Active     Inactive      Deleted       Static
  Local          0            1            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = INACTIVE, INTERFACE = Serial1/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:00:07, last time pvc status changed 00:00:07
R1#

Example2

//interface dlci was configured incorrect. The PVC on frame-relay switch ad R1 does not match.

R1#sh frame-relay pvc

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

              Active     Inactive      Deleted       Static
  Local          0            0            2            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial1/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:03:10, last time pvc status changed 00:00:06


Example3
interface sub-command
no keepalive 
// Line and protocol will be forced to up. And PVC status is static.


R1#sh frame-relay pvc

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

              Active     Inactive      Deleted       Static
  Local          2            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = STATIC, INTERFACE = Serial1/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:07:05, last time pvc status changed 00:00:15

Frame Relay Multicast (RPF check failure)

Frame Relay Multicast 

When doing multicast in frame relay network, the very important thing we need to take a close look at is RPF check. Since in some types of Frame Relay network, it is not a full mesh topology. 

What is RPF? 

RPF is used to prevent multicast loop in the network. RPF uses routing table to check whether it prunes the interface or not. When it receives multicast traffic, it checks where the source of multicast traffic is and compare to its routing able and make sure that the received interface and the forwarding interface to the source is the same interface. 

For example, if router received the multicast packet on f0/0. It performs RPF check by looking at its routing table to see the forwarding interface back to the multicast source is the f0/0. If it is not, RPF is failed. If it is, RPF check is passed.

In the frame relay Hub and spoke network, RPF check will be failed since the multicast traffic is received from spoke by hub and forward out by hub to another spoke. Therefore we need a tunnel interface to help accomplished this.

Example

Configuration

R1

interface Serial1/0
 no ip address
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay lmi-type ansi
!
interface Serial1/0.1 multipoint
 ip address 192.168.1.1 255.255.255.0
 ip pim dense-mode
 ip igmp join-group 239.1.1.1
 ip ospf network point-to-multipoint
 snmp trap link-status
 frame-relay map ip 192.168.1.2 101 broadcast
 frame-relay map ip 192.168.1.3 102 broadcast
 no frame-relay inverse-arp

R2

interface Serial1/0
 ip address 192.168.1.2 255.255.255.0
 ip pim dense-mode
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 serial restart-delay 0
 frame-relay map ip 192.168.1.3 202 broadcast
 frame-relay map ip 192.168.1.1 202 broadcast
 no frame-relay inverse-arp
!

R3

interface Serial1/0
 ip address 192.168.1.3 255.255.255.0
 ip pim dense-mode
 encapsulation frame-relay
 ip igmp join-group 239.1.1.1
 ip ospf network point-to-multipoint
 serial restart-delay 0
 frame-relay map ip 192.168.1.2 303 broadcast
 frame-relay map ip 192.168.1.1 303 broadcast
 no frame-relay inverse-arp
!
R4
A source of 239.1.1.1 multicast group

This configuration will not work in this case since it is a hub and spoke  network RPF check is failed. Therefore, we need to configure the tunnel interface  between R1 and  R3.

Building Tunnel interface

R1

interface Tunnel0
 ip address 1.1.1.1 255.255.255.0
 ip pim dense-mode
 tunnel source Serial1/0.1
 tunnel destination 192.168.1.3

R3

interface Tunnel0
 ip address 1.1.1.2 255.255.255.0
 ip pim dense-mode
 tunnel source Serial1/0
 tunnel destination 192.168.1.1

Now, multicast traffic is going through tunnel between R1 and R3. To pass the RPF check in R3 routing table should forward packet to source via Tunnel as well. However, R3 uses s1/0 at this time. To make it work, we require to add static multicast route to R3 as follow.

ip mroute 10.10.10.1 255.255.255.255 tunnel0



Then, we pass RPF check and  accomplish this task.

Frame Relay (Hub & Spoke)

Frame Relay Hub & Spoke

In this article, I will show you how to configure frame relay hub & spoke topology with the static ip map. In this scenario, 

•  R1 will be a hub. R2 and R3 will be spokes.The PVCs are assigned to each router as shown in the diagram. 
• We will use point-to-multipoint frame relay type. ( physical/logical interface )
• statically map ip to DLCI
• Establish a mesh connection between all of the routers

Hub configuration

Physical interface
I
R1
interface Serial1/0
 ip address 192.168.1.1 255.255.255.0
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay map ip 192.168.1.3 102 broadcast   // statically map ip to DLCI
 frame-relay map ip 192.168.1.2 101 broadcast
 frame-relay interface-dlci 101  
 frame-relay interface-dlci 102
 no frame-relay inverse-arp                                 // disable LMI dynamic DLCI learning 

------------------------------------------
II
Logical interface
interface Serial1/0
 no ip address
 encapsulation frame-relay
 serial restart-delay 0
!
interface Serial1/0.1 multipoint                           // in this scenario, we use point to multipoint
 ip address 192.168.1.1 255.255.255.0
 snmp trap link-status
 frame-relay map ip 192.168.1.3 102
 frame-relay map ip 192.168.1.2 101
 frame-relay interface-dlci 101
 frame-relay interface-dlci 102
 no frame-relay inverse-arp
!

Spokes configuration

R2

interface Serial1/0

 ip address 192.168.1.2 255.255.255.0

 encapsulation frame-relay

 serial restart-delay 0

 frame-relay map ip 192.168.1.3 202 broadcast

 frame-relay map ip 192.168.1.1 202 broadcast

 frame-relay interface-dlci 202

 no frame-relay inverse-arp

end

R3

interface Serial1/0

 ip address 192.168.1.3 255.255.255.0

 encapsulation frame-relay

 serial restart-delay 0

 frame-relay map ip 192.168.1.1 303 broadcast

 frame-relay map ip 192.168.1.2 303 broadcast

 frame-relay interface-dlci 303

 no frame-relay inverse-arp

end

Verify static ip and DLCI mapping

R1#show frame-relay map

Serial1/0 (up): ip 192.168.1.2 dlci 101(0x65,0x1850), static,

              broadcast,

              CISCO, status defined, active

Serial1/0 (up): ip 192.168.1.3 dlci 102(0x66,0x1860), static,

              broadcast,

              CISCO, status defined, active

R1#

Verify Frame Relay Mesh connectivity 

R2#ping 192.168.1.1

Type escape sequence to abort.

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

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 20/65/132 ms

R2#

R2#ping 192.168.1.3

Type escape sequence to abort.

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

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 44/103/260 ms

R2#