Sunday 10 April 2011

Multilink Frame Relay (MFR) and Multilink PPP (ML-PPP)

This post is about non-etherchannel link bundling a way to increase bandwidth and resiliency with the layer 3 result appearing as a single Layer 3 link between nodes using multiple WAN links.







So lets start with Routers R4 and R7, each has 4 serial interfaces that are back to back (R4 s0/0 to R7 s0/0, R4 s0/1 to R7 s0/1, R4 s1/0 to R7 s1/0 and R4 s1/1 to R7 s1/1)

Start with a multilink frame relay (MFR) for the first two links (since we're not using a Frame Switch here so we're going to turn FR LMI off)






R4
hostname R4
int mfr 1
 no keepalive
 no shut
int s0/0
 shutdown
 encapsulation frame-relay mfr 1
 no shut
int s0/1
 shutdown
 encapsulation frame-relay mfr 1
 no shut
int mfr1.47 point-to-point
 ip address 47.47.47.4 255.255.255.0
 frame-relay interface-dlci 47


R7
hostname R7
int mfr 1
 no keepalive
 no shut
int s0/0
 shutdown
 encapsulation frame-relay mfr 1
 no shut
int s0/1
 shutdown
 encapsulation frame-relay mfr 1
 no shut
int mfr1.47 point-to-point
 ip address 47.47.47.7 255.255.255.0
 frame-relay interface-dlci 47


So lets check that is operating.

R4#sh frame pvc

PVC Statistics for interface MFR1 (Frame Relay DTE)

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

DLCI = 47, DLCI USAGE = LOCAL, PVC STATUS = STATIC, INTERFACE = MFR1.47

  input pkts 3             output pkts 3            in bytes 963
  out bytes 963            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 3         out bcast bytes 963
  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:28, last time pvc status changed 00:00:14
R4#ping 47.47.47.7

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 47.47.47.7, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/5/16 ms
R4#sh 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

Okay, so multilink frame relay is relatively straight forward to get going.  Lets park that for the moment and look at getting multilink PPP operational



R4
int mfr1.47 point-to-point
 no ip address
interface Multilink1
 ip address 47.47.47.4 255.255.255.0
 ppp multilink
 ppp multilink group 1
int s1/0
 shutdown
 encapsulation ppp
 ppp multilink
 ppp multilink group 1
 no shut
int s1/1
 shutdown
 encapsulation ppp
 ppp multilink
 ppp multilink group 1
 no shut

R7
int mfr1.47 point-to-point
 no ip address
interface Multilink1
 ip address 47.47.47.7 255.255.255.0
 ppp multilink
 ppp multilink group 1
int s1/0
 shutdown
 encapsulation ppp
 ppp multilink
 ppp multilink group 1
 no shut
int s1/1
 shutdown
 encapsulation ppp
 ppp multilink
 ppp multilink group 1
 no shut

So lets check that this is working.
 
R7#ping 47.47.47.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 47.47.47.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/9/24 ms
R7#sh ppp multi

Multilink1
  Bundle name: R4
  Remote Endpoint Discriminator: [1] R4
  Local Endpoint Discriminator: [1] R7
  Bundle up for 00:00:26, total bandwidth 3088, load 1/255
  Receive buffer limit 24000 bytes, frag timeout 1000 ms
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 7 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0xF received sequence, 0xD sent sequence
  Member links: 2 active, 0 inactive (max not set, min not set)
    Se1/0, since 00:00:21
    Se1/1, since 00:00:20
No inactive multilink interfaces

No problems, we can see that the bandwidth is 3088kbps (1544 kbps default per serial interface). Ok, so just for fun, how about including the Frame Relay links with this bundle?  It's certainly possible, we just need to put ppp over frame and include it in the multilink group.





R4/47
interface Virtual-Template1
 no ip address
 ppp multilink
 ppp multilink group 1
interface MFR1.47 point-to-point
 frame-relay interface-dlci 47 ppp Virtual-Template1

However it's not quite as simple as it seems to get it going..

*Mar  1 00:14:13.559: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up
*Mar  1 00:14:25.547: %FR-3-MLPOFR_ERROR: MLPoFR not configured properly on Link Virtual-Access2 Bundle Multilink1 :Frame Relay traffic shaping must be enabled
*Mar  1 00:14:26.539: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up

We need some traffic shaping on the FR (MFR1) interface - remember if we just turn traffic shaping on, all PVCs will be shaped at 56kbps.  For this example, we'll assume that there is 256kbps per PVC available

R4/47
map-class frame-relay MFR
 frame-relay traffic-rate 512000
interface MFR1
 frame-relay traffic-shaping
interface MFR1.47 point-to-point
 frame-relay interface-dlci 47 ppp Virtual-Template1
 class MFR

Lets bounce the link and see if it's happy this time round.

R7(config-if)#int mfr1
R7(config-if)#shut
*Mar  1 00:22:30.247: %LINK-5-CHANGED: Interface MFR1, changed state to administratively down
*Mar  1 00:22:30.247: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to down
*Mar  1 00:22:31.247: %LINEPROTO-5-UPDOWN: Line protocol on Interface MFR1, changed state to down
*Mar  1 00:22:31.251: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to down
*Mar  1 00:22:33.255: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to down
*Mar  1 00:22:33.259: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to down
R7(config-if)#no shut
*Mar  1 00:22:46.619: %LINK-3-UPDOWN: Interface MFR1, changed state to down
*Mar  1 00:22:54.215: %LINK-3-UPDOWN: Interface MFR1, changed state to up
*Mar  1 00:22:54.263: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up
*Mar  1 00:22:55.207: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to up
*Mar  1 00:22:55.215: %LINEPROTO-5-UPDOWN: Line protocol on Interface MFR1, changed state to up
*Mar  1 00:22:55.219: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up
*Mar  1 00:22:55.263: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up

No complaints this time...

R7(config-if)#do ping 47.47.47.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 47.47.47.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/6/16 ms
R7(config-if)#do sh users
    Line       User       Host(s)              Idle       Location
*  0 con 0                idle                 00:00:00

  Interface    User               Mode         Idle     Peer Address
  Vi2                             PPPoFR       00:01:06
  Se1/0                           Sync PPP     00:00:05
  Se1/1                           Sync PPP     00:00:05
  Mu1                             Sync PPP     00:00:54 47.47.47.4

Looks good so far, lets confirm what the multilink PPP interface thinks its bandwidth is (it should be 1544 * 2 for the direct PPP links and 512 for the MFR link)

R7(config-if)#do sh ppp multi

Multilink1
  Bundle name: R4
  Remote Endpoint Discriminator: [1] R4
  Local Endpoint Discriminator: [1] R7
  Bundle up for 00:24:11, total bandwidth 3344, load 1/255
  Receive buffer limit 36000 bytes, frag timeout 1000 ms
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 13 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0x32 received sequence, 0x30 sent sequence
  Member links: 3 active, 1 inactive (max not set, min not set)
    Se1/0, since 00:24:06, 5790 weight, 1496 frag size
    Se1/1, since 00:24:05, 5790 weight, 1496 frag size
    Vi2, since 00:04:21, 960 weight, 950 frag size
    Vt1 (inactive)
No inactive multilink interfaces

We can see that the multilink interface thinks it has 3344 kbps of bandwidth and not 3600.

R7#sh int virtual-access 2
Virtual-Access2 is up, line protocol is up
  Hardware is Virtual Access interface
  MTU 1500 bytes, BW 256 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 Multilink1
  PPPoFR vaccess, cloned from Virtual-Template1
  Vaccess status 0x44
  Bound to MFR1.47 DLCI 47, Cloned from Virtual-Template1, loopback not set
  Keepalive set (10 sec)
  DTR is pulsed for 5 seconds on reset
  Last input 00:02:02, output never, output hang never
  Last clearing of "show interface" counters 00:20:59
  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
     253 packets input, 5890 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
     254 packets output, 5393 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

Virtual-Access2 believes that there is 256kbps of bandwidth available rather than the expected 512kbps.  Lets modify the bandwidth associated with Virtual-Template 1 (since the Virtual-Access interface inherits data from it) and see if that helps.

R7(config-if)#int virtual-template 1
R7(config-if)#bandwidth 512
R7(config-if)#int mfr1
R7(config-if)#shut
R7(config-if)#no shut
*Mar  1 00:40:48.283: %LINK-5-CHANGED: Interface MFR1, changed state to administratively down
*Mar  1 00:40:48.287: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to down
*Mar  1 00:40:49.295: %LINEPROTO-5-UPDOWN: Line protocol on Interface MFR1, changed state to down
*Mar  1 00:40:49.299: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to down
*Mar  1 00:40:49.647: %LINK-3-UPDOWN: Interface MFR1, changed state to down
*Mar  1 00:40:51.295: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to down
*Mar  1 00:40:51.299: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to down
*Mar  1 00:40:58.259: %LINK-3-UPDOWN: Interface MFR1, changed state to up
*Mar  1 00:40:58.311: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up
*Mar  1 00:40:59.251: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to up
*Mar  1 00:40:59.259: %LINEPROTO-5-UPDOWN: Line protocol on Interface MFR1, changed state to up
*Mar  1 00:40:59.267: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up
*Mar  1 00:40:59.311: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up
R7(config-if)#do sh ppp multi

Multilink1
  Bundle name: R4
  Remote Endpoint Discriminator: [1] R4
  Local Endpoint Discriminator: [1] R7
  Bundle up for 00:32:49, total bandwidth 3600, load 1/255
  Receive buffer limit 36000 bytes, frag timeout 1000 ms
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 13 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0x3A received sequence, 0x38 sent sequence
  Member links: 3 active, 1 inactive (max not set, min not set)
    Se1/0, since 00:32:44, 5790 weight, 1496 frag size
    Se1/1, since 00:32:43, 5790 weight, 1496 frag size
    Vi2, since 00:00:09, 1920 weight, 1496 frag size
    Vt1 (inactive)
No inactive multilink interfaces

Okay, repeat the same thing on R4 and that should be it.  Would anyone want to do this in the real world?  I certainly hope not!

No comments:

Post a Comment