Some time ago I blogged briefly about MFR but only had it working with back-to-back routers because at the time, I couldn't work out how to get it to work through a Frame-Relay Switch. After catching this statement on CCO, I finally understood that the FR Switch actually had to be MFR enabled as well.
Because of this, you can do some interesting things.
This topology will have 3 devices (R1, R2 and a FrameSwitch)
R1==MFR==FRSW--FR--R2
My crude diagram above is meant to indicate that R1 has two physical links to FRSW and is using MFR, while R2 has a single physical link to FRSW using regular frame-relay.
Why might you do this? R1 could be a hub site serving multiple spokes like R2, and the Service Provider for whatever reason cant deliver big pipes to the hub site. As opposed to having R1 and FRSW having just two links with the spokes distributed across the interfaces, besides any bandwidth gains, MFR also enables some resiliency (losing a single physical link can still keep all spokes connected at diminished capacity)
These are the configurations:
R1
hostname R1
!
interface MFR1
no ip address
frame-relay multilink bid R1-MFR1
no frame-relay inverse-arp
!
interface MFR1.12 point-to-point
ip address 10.1.12.1 255.255.255.0
snmp trap link-status
frame-relay interface-dlci 102
!
interface Serial0/0
description FRSW S0/0
no ip address
encapsulation frame-relay MFR1
no arp frame-relay
frame-relay multilink lid R1-S0/0
!
interface Serial0/1
description FRSW S0/1
no ip address
encapsulation frame-relay MFR1
no arp frame-relay
frame-relay multilink lid R1-S0/1
FRSW
hostname FRSW
frame-relay switching
!
interface MFR1
no ip address
frame-relay multilink bid FRSW-MFR1
frame-relay intf-type dce
frame-relay route 102 interface Serial1/0 201
!
interface Serial0/0
description R1 S0/0
no ip address
encapsulation frame-relay MFR1
clock rate 2000000
no arp frame-relay
frame-relay multilink lid FRSW-S0/0
!
interface Serial0/1
description R1 S0/1
no ip address
encapsulation frame-relay MFR1
clock rate 2000000
no arp frame-relay
frame-relay multilink lid FRSW-S0/1
!
interface Serial1/0
description R2 S0/0
no ip address
encapsulation frame-relay
serial restart-delay 0
frame-relay intf-type dce
frame-relay route 201 interface MFR1 102
R2
hostname R2
!
interface Serial0/0
description FRSW S1/0
no ip address
encapsulation frame-relay
no fair-queue
no frame-relay inverse-arp
!
interface Serial0/0.21 point-to-point
ip address 10.1.12.2 255.255.255.0
frame-relay interface-dlci 201
!
Within the MFR configuration we have added some optional statements which identify the MFR bundle:
interface MFR
frame-relay multilink bid MFRBundleIDString
And the links which make up the bundle:
interface Serial
frame-relay multilink lid LinkIDString
This kind of thing can help with Layer 2 troubleshooting if you have a lot of peers.
R1#sh frame multi de | i BID|Peer|LID
BID = R1-MFR1
No. of bundle links = 2, Peer's bundle-id = FRSW-MFR1
Serial0/1, HW state = up, link state = Up, LID = R1-S0/1
Peer LID = FRSW-S0/1, RTT = 20 ms
Serial0/0, HW state = up, link state = Up, LID = R1-S0/0
Peer LID = FRSW-S0/0, RTT = 24 ms
BID = R1-MFR1
No. of bundle links = 2, Peer's bundle-id = FRSW-MFR1
Serial0/1, HW state = up, link state = Up, LID = R1-S0/1
Peer LID = FRSW-S0/1, RTT = 20 ms
Serial0/0, HW state = up, link state = Up, LID = R1-S0/0
Peer LID = FRSW-S0/0, RTT = 24 ms
BID = FRSW-MFR1
No. of bundle links = 2, Peer's bundle-id = R1-MFR1
Serial0/1, HW state = up, link state = Up, LID = FRSW-S0/1
Peer LID = R1-S0/1, RTT = 0 ms
Serial0/0, HW state = up, link state = Up, LID = FRSW-S0/0
Peer LID = R1-S0/0, RTT = 0 ms
So from above, we can see that that the bundle is up with both links and we appear to be connected to the right peer interfaces.
So lets see the PVC status on the Frame Switch:
FRSW#sh frame pvc
PVC Statistics for interface Serial1/0 (Frame Relay DCE)
Active Inactive Deleted Static
Local 0 0 0 0
Switched 1 0 0 0
Unused 0 0 0 0
DLCI = 201, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial1/0
input pkts 33 output pkts 29 in bytes 7428
out bytes 4708 dropped pkts 12 in pkts dropped 12
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
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
switched pkts 24
Detailed packet drop counters:
no out intf 0 out intf down 0 no out PVC 0
in PVC down 0 out PVC down 12 pkt too big 0
shaping Q full 0 pkt above DE 0 policing drop 0
pvc create time 00:10:17, last time pvc status changed 00:06:07
PVC Statistics for interface MFR1 (Frame Relay DCE)
Active Inactive Deleted Static
Local 0 0 0 0
Switched 1 0 0 0
Unused 0 0 0 0
DLCI = 102, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = MFR1
input pkts 30 output pkts 24 in bytes 5029
out bytes 4494 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
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
switched pkts 30
Detailed packet drop counters:
no out intf 0 out intf down 0 no out PVC 0
in PVC down 0 out PVC down 0 pkt too big 0
shaping Q full 0 pkt above DE 0 policing drop 0
pvc create time 00:06:14, last time pvc status changed 00:05:54
FRSW#sh frame route
Input Intf Input Dlci Output Intf Output Dlci Status
Serial1/0 201 MFR1 102 active
MFR1 102 Serial1/0 201 active
Looks good here, lets see what R1 and R2 have to say
R1#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 = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = MFR1.12
input pkts 12 output pkts 19 in bytes 2802
out bytes 3929 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 9 out bcast bytes 2889
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:08:34, last time pvc status changed 00:04:20
R1#sh frame map
MFR1.12 (up): point-to-point dlci, dlci 102(0x66,0x1860), broadcast
status defined, active
R2#sh frame pvc
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.21
input pkts 18 output pkts 22 in bytes 3608
out bytes 6062 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 17 out bcast bytes 5542
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:09:40, last time pvc status changed 00:05:30
R2#sh frame map
Serial0/0.21 (up): point-to-point dlci, dlci 201(0xC9,0x3090), broadcast
status defined, active
And lets verify layer 3 connectivity:
R2#ping 10.1.12.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/12/44 ms
There are more things you can do with MFR which include the specifying the method of using the bundles (variable bandwidth class support). By default, IOS will use bandwidth class a (the MFR will stay active with downed link members as long as a single link is up), other options include class b (all links must be active to keep the MFR interface up) or class c (a minimum threshold of links to keep the MFR interface up)
interface MFR
frame-relay multilink bandwidth-class BandwidthClass LinkThresholdForClassC
Load Balancing:
When the MFR interface is not using FIFO queuing, the router will simly pick the interface with the empty or shortest queue to send traffic to. If FIFO is being used then there is a default output-threshold of 300 bytes for each link, once this is exceeded, the next interface is selected. It is possible to modify this value to a different level (this is not FRF.12 frame-relay fragmentation)
interface MFR
frame-relay multilink output-threshold Threshold
No comments:
Post a Comment