Showing posts with label frame relay. Show all posts
Showing posts with label frame relay. Show all posts

Wednesday, May 25, 2011

notes: OSPF and Frame Relay

Keypoints:

1.  matches network types or interface types
      i.e. physical interface (multipoint) while IP OSPF type is point-to-point
      - timers wont match if the interface types are different.

2.  Remember that Broadcast & Non-Broadcast try to elect DR/BDR (hub must be the DR)

3.  "Broadcast" keyword statement if using frame maps
      - not running non-broadcast unicast fashion need a broadcast parameter.

4. Router ID
    - read first the LAB if there is requirement for RID same as BGP
      router ospf 1
      router-id 1.1.1.1 

5.  DR /BDR
     - the higher # the better
        first - highest priority
        2nd - highest RID

6.  DR @ Multipoint FR
     - multiple spokes connected to the hub router.
     - ensure all host has a direct connectivity to the hub.
note: OSPF packets have TTL of 1, so if you have a "frame-map" statement going from spoke to spoke still will not be able not talk to each other.

CCIE LAB:  Frame relay network by default will show up believing that other routers are DR.
          a.  you can use priority command on the interface  @ spoke set priority to 0.

7. Some network interface types requires neighbor command like non-broadcast and point-to-multipoint nonbroadcast. so it is important to look at network type using " show ip ospf interface"
       router ospf pid
       neighbor {ip} [priority {pri}] [cost {cost}]
              note: the cost  here are associated to the cost of the link.


Problem Areas in Frame Relay

Network Type:
connecting point-to-point/point-to-multipoint to physical interface:

to verify the network type:  show ip ospf interface

by default
physical interface network type is non-broadcast  with hello/dead  30/120 then must have DR.
on another side of the link (can be the hub) subinterface running in point-to-multipoint will have hello/dead of 30/120 and dont elect DR.

hub (point-to-multipoint)-----------------------(physical)spoke
bye default it will never peer-up

so carefully watch in the ccie lab if you are not allowed to hange the network type of a router.

Monday, May 23, 2011

LAB: PPP over Frame Relay

Requirements:  no router may use subinterface

==============================================
100.100.100.0/24

R2
int virtual-template 1
ip address 100.100.100.2 255.255.255.0 
bandwidth  64

int s0/1/0
encapsulation frame-relay
no frame-relay inverse-arp
frame-relay interface-dlci 204 ppp virtual-template 1
frame-relay interface-dlci 205 ppp virtual-template 1
frame-relay interface-dlci 206 ppp virtual-template 1

R4
int virtual-template 1
ip address 100.100.100.4 255.255.255.0 
bandwidth  64

int s0/0/0
encapsulation frame-relay
no frame-relay inverse-arp
frame-relay interface-dlci 402 ppp virtual-template 1

R5
int virtual-template 1
ip address 100.100.100.5 255.255.255.0
bandwidth  64

int s0/1/0
encapsulation frame-relay
no frame-relay inverse-arp
frame-relay interface-dlci 502 ppp virtual-template 1

R6
int virtual-template 1
ip address 100.100.100.6 255.255.255.0
bandwidth  64

int s0/1/0
encapsulation frame-relay
no frame-relay inverse-arp
frame-relay interface-dlci 602 ppp virtual-template 1

note:
- virtual access interface nos. issuing shut/no shut it will not assume always the same nos of virtual access interface.
- show ip route - will show /32 for virtual access. so might create problem on some dynamic routing.


==============================================
100.100.110.0/24


R2
int virtual-template2
ip address 100.100.110.2 255.255.255.0 
bandwidth  64

int s0/1/0
encapsulation frame-relay
no frame-relay inverse-arp
frame-relay interface-dlci 215 ppp virtual-template 2
frame-relay interface-dlci 216 ppp virtual-template 2


R5
int virtual-template 2
ip address 100.100.110.5 255.255.255.0
bandwidth  64

int s0/1/0
ip address 100.100.100.5 255.255.255.0
frame-relay interface-dlci 512 ppp virtual-template 2

R6
int virtual-template2
ip address 100.100.110.6 255.255.255.0

int s0/1/0
encapsulation frame-relay
no frame-relay inverse-arp
frame-relay interface-dlci 612 ppp virtual-template 2

verification
show int virtual access 2 - information inherited shows 100M link from virtual template
need to update the BW at virtual template

==============================================
100.100.120.0/24 128K 2 pvcs are active using 64k
note: there will be no load sharing / you can use multilink.

R2
int virtual-template 3
ip address 100.100.120.2 255.255.255.0 
bandwidth  64  
ppp multilink

int s0/1/0
encapsulation frame-relay
no frame-relay inverse-arp
frame-relay interface-dlci 224 ppp virtual-template 3
frame-relay interface-dlci 214 ppp virtual-template 3


R4
int virtual-template 3
ip address 100.100.120.4 255.255.255.0 
bandwidth  64  
ppp multilink

int s0/0/0
encapsulation frame-relay
no frame-relay inverse-arp
frame-relay interface-dlci 412 ppp virtual-template 3
frame-relay interface-dlci 422 ppp virtual-template 3


verification:

show ip route - there will one single set of /32 virutal access #
show int virtual-access # - will show only inherited 64k from virtual-template
show ppp multilink  - will show 2 member w total of 128K (definitive answer)

LAB: Frame Relay Back to Back with multilink


no rules on the to use frame-relay interface type.

R6 - providing the clockrate

int s0/2/0
encap frame mfr1
clockrate 128000
no shut
bandwidth 128
!
int s0/2/1

encap frame mfr1

clockrate 128000

no shut
bandwidth 128
!

int mfr 1
no keepalive
!
int mfr1.1 point-to-point
ip address 200.200.200.6 255.255.255.0
frame-relay interface-dlci 691
!
int mfr1.2 point-to-point
ip address 200.200.210.6 255.255.255.0
frame-relay interface-dlci 691
!
int mfr1.3 point-to-point
ip address 200.200.220.6 255.255.255.0
frame-relay interface-dlci 691



R9


int s0/2/0
encap frame mfr1

no shut
bandwidth 128
!

int s0/2/1
encap frame mfr1

no shut
bandwidth 128
!
int mfr 1
no keepalive
!
int mfr1.1 point-to-point
ip address 200.200.200.9 255.255.255.0
frame-relay interface-dlci 691

!
int mfr1.2 point-to-point
ip address 200.200.210.9 255.255.255.0
frame-relay interface-dlci 691
!
int mfr1.3 point-to-point
ip address 200.200.220.9 255.255.255.0
frame-relay interface-dlci 691

LAB: Frame Relay Multilink FRF.16


Requirements:  use multilink at R2
ISP FR - links at R2 can serve via s0/1/0 and s0/0/0 at spokes it is transparent.

from the previos labs the interface configs here are moved to MFR logical interfaces.
R2:

int s0/0/0
encapsulation frame mfr 1
no shut

int s0/1/0
encapsulation frame mfr 1
no shut

int mfr1
encapsulation frame-relay
no frame-relay inverse-arp
ip address 100.100.100.2 255.255.255.0
frame-relay map ip 100.100.100.4 204 broadcast
frame-relay map ip 100.100.100.5 205 broadcast
frame-relay map ip 100.100.100.6 206 broadcast
frame-relay map ip 100.100.100.2 204 broadcast -ping to its own int
!
int mfr1.110 multipoint
ip address 100.100.110.2 255.255.255.0
frame-relay map ip 100.100.110.5 215 broadcast
frame-relay map ip 100.100.110.6 216 broadcast
frame-relay map ip 100.100.110.2 215 broadcast -ping to its own int
!
int mfr2.120 point-to-point
ip address 100.100.120.2 255.255.255.0
frame-relay interface-dlci 214




verification

show frame multilink
show int mfr 1 - BW are automatically computed.
show frame map
debug ip packet

LAB: Frame Relay Back to Back

Requirements: 1 multipoint & total of 2 subinterfaces

R7
int s0/0/0
encapsulation frame
ip address 200.200.200.7 255.255.255.0
clockrate 128000
no shut

R8
int s0/0/0
encapsulation frame
ip address 200.200.200.8 255.255.255.0
no shut

note: on older version of software the interface is up/down, new version is up/up its already configured clockrate. i.e. not using the default clockratre 2000000

sho int s0/0/0
both sides up/down
looped at R7

show frame lmi

 important points: frame relay DTE on R7 eventhough we have a clockrate but DTE layer2 FR.
frame-relay DTE means it expects a frame relay DCE that provides clock but in this setup we are using FR back to back. 

1.  We need to turn off LMI by turning keep alives.
2.  After this still encapsulation failed. because there is no L2 to L3 resolution. frame map is needed.
3.  DLCI are locally significant, since R7 and R8 are directly connected, same DLCI must be used on both sides.


R7
int s0/0/0
encapsulation frame
ip address 200.200.200.7 255.255.255.0
clockrate 128000
no shut
no keepalive
frame-relay map ip 200.200.200.8 101 broadcast
frame-relay map ip 200.200.200.7 101

R8
int s0/0/0
encapsulation frame
ip address 200.200.200.8 255.255.255.0
no shut 
no keepalive
frame-relay map ip 200.200.200.7 101 broadcast
frame-relay map ip 200.200.200.8 101

================================================
200.200.210.0/24  multipoint



R7
int s0/0/0.210 multipoint
ip address 200.200.210.7 255.255.255.0
frame-relay map ip 200.200.210.8 111 broadcast
frame-relay map ip 200.200.210.7 111

R8
int s0/0/0 multipoint
ip address 200.200.210.8 255.255.255.0
frame-relay map ip 200.200.210.7 111 broadcast
frame-relay map ip 200.200.210.8 111




================================================
200.200.220.0/24 one point to point


R7
int s0/0/0.220 point-to-point
ip address 200.200.220.7 255.255.255.0
frame-relay interface-dlci 121

R8
int s0/0/0.220 point-to-point
ip address 200.200.220.8 255.255.255.0  
frame-relay interface-dlci 121

LAB: Frame Relay Interface type


Requirements:  Any router is only allowed to have 1 multipoint sub-interface

100.100.100.0/24 segment

R2:
int s0/1/0
ip address 100.100.100.2 255.255.255.0
frame-relay map ip 100.100.100.4 204 broadcast
frame-relay map ip 100.100.100.5 205 broadcast
frame-relay map ip 100.100.100.6 206 broadcast
frame-relay map ip 100.100.100.2 204 broadcast -ping to its own int

R4:
int s0/0/0
ip address 100.100.100.4 255.255.255.0
frame-relay map ip 100.100.100.2 402 broadcast
frame-relay map ip 100.100.100.5 402
frame-relay map ip 100.100.100.6 402
frame-relay map ip 100.100.100.4 402

R5:
int s0/1/0
ip address 100.100.100.5 255.255.255.0
frame-relay map ip 100.100.100.2 502 broadcast
frame-relay map ip 100.100.100.4 502
frame-relay map ip 100.100.100.6 502
frame-relay map ip 100.100.100.5 502

R6:
int s0/1/0
ip address 100.100.100.6 255.255.255.0

frame-relay map ip 100.100.100.2 602 broadcast

frame-relay map ip 100.100.100.4 602

frame-relay map ip 100.100.100.5 602

frame-relay map ip 100.100.100.6 602

================================================
100.100.110.0/24 segment  r2, r5 and r6 using subinterface everything should be map.

R2:
int s0/1/0.110 multipoint
ip address 100.100.110.2 255.255.255.0
frame-relay map ip 100.100.110.5 215 broadcast
frame-relay map ip 100.100.110.6 216 broadcast
frame-relay map ip 100.100.110.2 215 broadcast -ping to its own int

R5:
int s0/1/0.110 multipoint
ip address 100.100.110.5 255.255.255.0
frame-relay map ip 100.100.110.4 512 broadcast
frame-relay map ip 100.100.110.6 512
frame-relay map ip 100.100.110.5 512

R6:
int s0/1/0.110 multipoint
ip address 100.100.110.6 255.255.255.0

frame-relay map ip 100.100.110.2 612 broadcast

frame-relay map ip 100.100.110.5 612

frame-relay map ip 100.100.110.6 612


================================================
100.100.120.0/24 segment  r2, r4 ( each router nly have one multipoint)

R2:
int s0/1/0.120 point-to-point
ip address 100.100.120.2 255.255.255.0
frame-relay interface-dlci 214


R4:
int s0/0/0.120 multipoint
ip address 100.100.120.4 255.255.255.0
frame-relay map ip 100.100.120.2 412 broadcast
frame-relay map ip 100.100.120.4 412


note:  Not really a problem of using both physical interface and sub interface.

Sunday, May 22, 2011

LAB: Frame Relay Address Resolution using inverse-arp


DLCIs

R2=205,206,215,216,225,226
R5=502,506,512,516,522,526
R6=602,605,612,615,622,625

LAB Requirements:  no DLCI indicated in the diagram: donot use PVC with 0 & 1 in the middle

R2,R5,R6

int s0/1/0
encapsulation frame-relay
 no shut
 ip address a.b.c.d

verify the DLCI

show frame-relay pvc | in ACT
show frame-relay pvc | in \ ACT
show frame-relay map

R2
no frame-relay inverse-arp ip 205
no frame-relay inverse-arp ip 206
no frame-relay inverse-arp ip 215
no frame-relay inverse-arp ip 216

R5

no frame-relay inverse-arp ip 502
no frame-relay inverse-arp ip 506
no frame-relay inverse-arp ip 512
no frame-relay inverse-arp ip 516


R6
no frame-relay inverse-arp ip 602

no frame-relay inverse-arp ip 605
no frame-relay inverse-arp ip 612
no frame-relay inverse-arp ip 615




note: you can issue the command below to clear some dynamic arps
clear frame-relay inarp

from R5 to reach R6 must add static mapping
frame-relay map ip 100.100.100.6 522

from R6 to reach R5
frame-relay map ip 100.100.100.5 622
frame-relay map ip 100.100.100.6 622  ===if u wan to ping urself

useful tool: to ensure that l2 to l3 mapping is ok, or if there is encapsulation failed
debug ip packet

extra: adding dynamic routing

R2, R5, R6
router ospf 1
passive interface default
network 0.0.0.0 0.0.0.0 area 0
no passive s0/1/0
!
int s0/1/0
ip ospf network broadcast

LAB: Frame Relay Fragmentation and Interleaving with MLPPP

Repost from INE blog by Petr Lapukhov, 4xCCIE/CCDE:


1) MLPPP uses fragmentation scheme where large packets are sliced in pieces and sequence numbers are added using special MLPPP headers
2) Small voice packets are interleaved with fragments of large packets using a special priority queue

We see that MLPPP was originally designed to work with multiple physical links at the same time. However, PPP Multilink Interleave only works with one physical link. The reason is that voice (small) packets are being sent without sequence numbers. If we were using multiple physical links, the receiving side may start accepting voice packets out of their original order (due to different physical link latencies). And since voice packets bear no fragmentation headers, there is no way to reorder them. In effect, packets may arrive to their final destination out of order, degrading voice quality.

To overcome this obstacle, Multiclass Multilink PPP (MCMLPPP or MCMLP) has been introduced in RFC 2886. Under this RFC, different “fragment streams” or classes are supported at sending and receiving sides, using independent sequence numbers. Therefore, with MCMLPPP voice packets may be sent using MLPPP header with separate sequence numbers space. In result, MCMPPP permits the use of fragmentation and interleaving over multiple physical links at time.

Now back to our MLPPPoFR example. Let’s imagine the situation where we have two routers (R1 and R2) connected via FR cloud, with physical ports clocked at 512Kpbs and PVC CIR values equal to 384Kbps (There is no ATM interworking in this example). We need to provide priority treatment to voice packets and enable PPP Multilink and Interleave to decrease serialization delays.

Topology:

[R1]---[DLCI 112]---[Frame-Relay]---[DLCI 211]---[R2] 
 
Qos Policy:R1
 
class-map match-all VOICE
 match ip dscp ef 
class-map match-all SIGNALING
 match ip dscp cs3 
!
!
policy-map CBWFQ
 class VOICE
  priority 48
 class SIGNALING
  bandwidth 8
 class class-default
  fair-queue
 
 Next create a Virtual-Template interface for PPPoFR. We need to 
calculate the fragment size for MLPPP. Since physical port speed is 
512Kpbs, and required serialization delay should not exceed 10ms 
(remember, fragment size is based on physical port speed!), the fragment
 size must be set to [512000/8]*0.01=640 bytes. How is the fragment size 
configured with MLPPP? By using command ppp multilink fragment delay
 – however, IOS CLI takes this delay value (in milliseconds) and 
multiplies it by configured interface (virtual-template) bandwidth (in 
our case 384Kbps). We can actually change the virtual-template bandwidth
 to match the physical interface speed, but this would affect the CBWFQ 
weights! Therefore, we take the virtual-template bandwidth (384Kpbs) and
 adjust the delay to make sure the fragment size matches the physical 
interace rate is 512Kpbs. This way, the “effective” delay value would be
 set to “640*8/384 = 13ms” (Fragment_Size/CIR*8) to accomodate the 
physical and logical bandwidth discrepancy. (This may be unimportant if 
our physical port speed does not differ much from PVC CIR. However, if 
you have say PVC  CIR=384Kbps and port speed 768Kbps you may want to pay
 attention to this issue)
 
R1:
interface Loopback0
 ip address 177.1.101.1 255.255.255.255
!
interface Virtual-Template1
 bandwidth 384
 ip unnumbered Loopback0
 ppp multilink
 ppp multilink fragment delay 13
 ppp multilink interleave
 service-policy output CBWFQ
R2:
interface Loopback0
 ip address 177.1.102.1 255.255.255.255
!
interface Virtual-Template1
 bandwidth 384
 ip unnumbered Loopback0
 ppp multilink
 ppp multilink fragment delay 13
 ppp multilink interleave
 service-policy output CBWFQ
Next we configure PVC shaping settings by using legacy FRTS configuration. Note that Bc is set to CIR*10ms.
 
R1&R2
map-class frame-relay SHAPE_384K
 frame-relay cir 384000
 frame-relay bc 3840
 frame-relay be 0
 frame-relay mincir 384000
apply all the settings to the Frame-Relay interfaces:
 
R1:
interface Serial0/0
 no ip address
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay traffic-shaping
!
interface Serial0/0.1 point-to-point
 frame-relay interface-dlci 112 ppp Virtual-Template1
  class SHAPE_384K
R2:
interface Serial0/0
 no ip address
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay traffic-shaping
!
interface Serial0/0.1 point-to-point
 frame-relay interface-dlci 211 ppp Virtual-Template1
  class SHAPE_384K
 
Verification
 
R1#SHOW INT VIRtual-ACCess 2
Virtual-Access2 is up, line protocol is up
  Hardware is Virtual Access interface
  Interface is unnumbered. Using address of Loopback0 (177.1.101.1)
  MTU 1500 bytes, BW 384 Kbit/sec, DLY 100000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP Open, multilink Open
  Link is a member of Multilink bundle Virtual-Access3
  PPPoFR vaccess, cloned from Virtual-Template1
  Vaccess status 0x44
  Bound to Serial0/0.1 DLCI 112, Cloned from Virtual-Template1, loopback not set
  Keepalive set (10 sec)
  DTR is pulsed for 5 seconds on reset
  Last input 00:00:05, output never, output hang never
  Last clearing of "show interface" counters 00:48:42
  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
     572 packets input, 10084 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
     572 packets output, 8960 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
R1#
R1#
R1#SHOW INT VIRtual-ACCess 3
Virtual-Access3 is up, line protocol is up
  Hardware is Virtual Access interface
  Interface is unnumbered. Using address of Loopback0 (177.1.101.1)
  MTU 1500 bytes, BW 384 Kbit/sec, DLY 100000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP Open, multilink Open
  Open: IPCP
  MLP Bundle vaccess, cloned from Virtual-Template1
  Vaccess status 0x40, loopback not set
  Keepalive set (10 sec)
  DTR is pulsed for 5 seconds on reset
  Last input 00:37:26, output never, output hang never
  Last clearing of "show interface" counters 00:47:35
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: Class-based queueing
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/1/128 (active/max active/max total)
     Reserved Conversations 1/1 (allocated/max allocated)
     Available Bandwidth 232 kilobits/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     12 packets input, 1068 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
     12 packets output, 1134 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
R1#
R1#show policy-map inte
R1#show policy-map interface
 Virtual-Template1

  Service-policy output: CBWFQ

    Service policy content is displayed
                    for cloned interfaces only such as vaccess and
                    sessions
 Virtual-Access3

  Service-policy output: CBWFQ

    Class-map: VOICE (match-all)
      5 packets, 510 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip dscp ef (46)
      Queueing
        Strict Priority
        Output Queue: Conversation 136
        Bandwidth 48 (kbps) Burst 1200 (Bytes)
        (pkts matched/bytes matched) 5/510
        (total drops/bytes drops) 0/0

    Class-map: SIGNALING (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip dscp cs3 (24)
      Queueing
        Output Queue: Conversation 137
        Bandwidth 8 (kbps)Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: class-default (match-any)
      7 packets, 534 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
      Queueing
        Flow Based Fair Queueing
        Maximum Number of Hashed Queues 128
        (total queued/total drops/no-buffer drops) 0/0/0
 
R1# show ppp multilink 

Virtual-Access3, bundle name is R2
  Endpoint discriminator is R2
  Bundle up for 00:49:28, total bandwidth 384, load 1/255
  Receive buffer limit 12192 bytes, frag timeout 1000 ms
  Interleaving enabled
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 0 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0x7 received sequence, 0x7 sent sequence
  Member links: 1 (max not set, min not set)
    Vi2, since 00:49:28, 624 weight, 614 frag size
No inactive multilink interfaces
R1#
R1#
R1#
R1#sho int s0/0
Serial0/0 is up, line protocol is up 
  Hardware is M4T
  MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  Restart-Delay is 0 secs
  LMI enq sent  298, LMI stat recvd 299, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 0  LMI type is ANSI Annex D  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 49/0, interface broadcasts 0
  Last input 00:00:05, output 00:00:02, output hang never
  Last clearing of "show interface" counters 00:50:43
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: dual fifo
  Output queue: high size/max/dropped 0/256/0
  Output queue: 0/128 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     947 packets input, 31366 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
     946 packets output, 31062 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
     2 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up 

Saturday, May 21, 2011

LAB: Frame Relay Multilink PPP

 w / in the virtual template use PPP multilink in order to bond together.

in this example 2 x 2M of frame-relay  are bundled to have a total of 4M effective bandwidth.

    interface Serial0/0
    description Physical Interface 1
    bandwidth 2000
    no ip address
    encapsulation frame-relay
    frame-relay fragmentation voice-adaptive deactivation 15
    frame-relay traffic-shaping
    frame-relay interface-dlci 16 ppp Virtual-Template1
    frame-relay lmi-type ansi

    interface Serial0/1
    description Physical Interface 2
    bandwidth 2000
    no ip address
    encapsulation frame-relay
    frame-relay fragmentation voice-adaptive deactivation 15
    frame-relay traffic-shaping
    frame-relay interface-dlci 16 ppp Virtual-Template1
    frame-relay lmi-type ansi

    interface Virtual-Template1
    no ip address
    ppp multilink
    ppp multilink group 1

    interface Multilink1
    description Bundled Interface
    bandwidth 4000
    ip address 10.87.1.1 255.255.255.248
    ppp multilink
    ppp multilink group 1

notes: Frame Relay Auto installation Caveats

- if auto installation is used to grab the configuration file from a remote router.

below is a must for autoinstall to work.
1.  Inverse Arp to learn other end.
2.  frame-relay map to know the other end.
3.  config should be saved on a flash of other router.
4.  be serve w/  tftp-server cmd @ HUB.  ( you can use " no server config" to disable)

Thursday, March 31, 2011

notes: PPP over Frame-Relay (PPPoFR)

- Frame-relay does not natively support features such as authentication, link quality monitoring, or reliable transmission.
- By implementing PPPoFR, authentication of frame-relay PVCs can be implement, or multiple PVCs could be binded together using MLP.
- PPPoFR is configured through the use of a virtual-template interfaces.
- A virtual-template is a PPP encapsulated interface that is designed to spawn a “template” of configuration down to multiple member interfaces.
- When using a virtual-template interface it’s important to understand that a virtual-access “member” interface is cloned from the virtual-template interface when the PPP connection comes up, therefore the virtual-template interface itself will always be in the down/down state. This can affect certain network designs such as using the backup interface command
on a virtual-template.


note: the oly way to do authentication over FR is through PPP.

CONFIG-SET: PPP over frame-relay (PPPoFR) example
+---------------------------------------------------

STEP1: Create the virtual-template interface
- Configures all the logical options like a IP address
- Authentication is optional
NOTE: "encapsulation ppp" not needed as virtual-templates always runs PPP

interface virtual-template1
ip address 192.1.7.6 255.255.255.0
ppp chap hostname ROUTER6
ppp chap password 0 CISCO


STEP2: Configure the physical frame-relay interface and bind the virtual-template to the frame-relay PVC
Note that the order that these steps are performed are important

interface Serial0/0
encapsulation frame-relay
frame interface-dlci 201 ppp virtual-template1



verification:

sh ip interface brief | include 192.1.7.6
virtual-access1 192.1.7.6 YES TFTP up up
virtual-template1 192.1.7.6 YES manual down down

Sunday, February 27, 2011

notes: Frame Relay End-to-End Keepalives

Adds the ability to track status between DTE devices.
- Freek can be configured on a physical interface, but when the freek status goes down, freek will not bring down the physical interface, because it will not know when to bring it back up.
- For this reason it is recommended to configure freek on a sub-interface.

Freek Modes:

1. Bidirectional

- Both sides of the PVC can send and respond to keepalive requests.
- If one side is configured as bidirectional, the other end must be configured the same.
- Sets the timers and keeps track of error counters.

2. Request

- With Request mode only one side is enabled in send mode.
- If one side is configured as Request, the other end must be Reply or Passive-Reply.
- Sets the timers and keeps track of error counters.

3. Reply

- The device waits for, and replies to keepalive requests.
- If one side is configured as Reply, the other end must be Request.
- Sets the timers and keeps track of error counters.

4. Passive-reply
- The device waits for keepalive requests and responds to them.
- Sets the timers.

example:

configure end-to-end keepalives for the VC. if the routers have 3 errors within 4 events. the subinterface should transition into down state. and if they have 4 success events in a row, the sub-interface should transition into up state. ensure that keepalivs are exchanged every 20 seconds.

config-set:

map-class frame-relay TST14
frame-relay end-to-end keepalive mode bidirectional
frame-relay end-to-end keepalive timer send 30
frame-relay end-to-end keepalive timer recv 20
frame-relay end-to-end keepalive event-window send 5
frame-relay end-to-end keepalive event-window recv 5
frame-relay end-to-end keepalive error-threshold send 3
frame-relay end-to-end keepalive error-threshold recv 3
frame-relay end-to-end keepalive success-events send 4
frame-relay end-to-end keepalive success-events recv 4
!
interface Serial0/0.104 point-to-point
ip address 150.1.14.1 255.255.255.0
frame-relay interface-dlci 104
class TST14

Saturday, February 26, 2011

LAB: Frame Relay Back to Back with Multilink


R1

interface MFR1
no ip address
no keepalive
!
interface MFR1.102 point-to-point
ip address 150.1.102.1 255.255.255.0
frame-relay interface-dlci 102
!
interface Serial0/0
no ip address
encapsulation frame-relay MFR1
serial restart-delay 0
clock rate 128000
no arp frame-relay
!
interface Serial0/1
no ip address
encapsulation frame-relay MFR1
serial restart-delay 0
clock rate 128000
no arp frame-relay

R2

interface MFR1
no ip address
no keepalive
!
interface MFR1.201 point-to-point
ip address 150.1.102.2 255.255.255.0
frame-relay interface-dlci 102
!
interface Serial0/0
no ip address
encapsulation frame-relay MFR1
serial restart-delay 0
no arp frame-relay
!
interface Serial0/1
no ip address
encapsulation frame-relay MFR1
serial restart-delay 0
no arp frame-relay



VERIFICATION

MFR1 is up, line protocol is up
Hardware is Multilink Frame Relay bundle interface
MTU 1500 bytes, BW 3088 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation FRAME-RELAY, loopback not set
Keepalive not set
DTR is pulsed for 2 seconds on reset
FR SVC disabled, LAPF state down
Broadcast queue 0/64, broadcasts sent/dropped 15/0, interface broadcasts 0
Last input 00:00:10, output never, output hang never
Last clearing of "show interface" counters 00:17:36
Input queue: 0/75/6/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/120 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
15 packets input, 4605 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
15 packets output, 4635 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions

R1#show frame-relay multilink
Bundle: MFR1, State = up, class = A, fragmentation disabled
BID = MFR1
Bundle links:
Serial0/1, HW state = up, link state = Up, LID = Serial0/1
Serial0/0, HW state = up, link state = Up, LID = Serial0/0