[c-nsp] MLPoFR issue (Paul A)

Paul A razor at meganet.net
Tue Feb 19 09:30:26 EST 2008


Osvaldo, thanks for the reply but unfortunately I tested this with an older
1600 we had laying around and it doesn’t support MFR.

Here's my original post in case anyone cares to read it.

I have 2 T1’s connected to a frame network, I have bonded these 2 t1’s and
it seems to be working great. 

Here is the setup I have:
(customer: router A)------(frame cloud)-----(isp: router B)

Router A config:

interface Multilink1
 bandwidth 3072
 ip address 1.2.3.1 255.255.255.252
 no ip directed-broadcast
 no cdp enable
 ppp multilink
 no ppp multilink fragmentation
 multilink-group 1
!
interface Virtual-Template1
 no ip address
 no ip directed-broadcast
 ppp multilink
 multilink-group 1
!
interface Serial0
 description bonded t3 - t1 1-2
 bandwidth 1536
 no ip address
 no ip directed-broadcast
 encapsulation frame-relay IETF
 no fair-queue
 frame-relay interface-dlci 500 ppp Virtual-Template1
 frame-relay lmi-type ansi
!
interface Serial1
 description bonded t3 - t1 2-2
 bandwidth 1536
 no ip address
 no ip directed-broadcast
 encapsulation frame-relay IETF
 no fair-queue
 frame-relay interface-dlci 500 ppp Virtual-Template1
 frame-relay lmi-type ansi

when I do a “show ppp multilink”  on Router A I get

Multilink1, bundle name is XXX
  150 lost fragments, 7055 reordered, 0 unassigned, sequence 0x719D/0x4D18
rcvd/sent
  0 discarded, 0 lost received, 1/255 load
  Member links: 2 active, 1 inactive (max not set, min not set)
    Virtual-Access1
    Virtual-Access2
    Virtual-Template1 (inactive)

It looks like the Virtual-Template interface is down on both routers A and B
but is there a reason why this interface shouldn’t show as being up or does
it not matter?

On router B (isp side) the router is complaining about MLPoFR not being
configured correctly.

Feb 15 12:07:22: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to
up Feb 15 12:07:24: %FR-3-MLPOFR_ERROR: MLPoFR not configured properly on
Link Virtual-Access2 Bundle Multilink1: AttachMate solutions Links
:Missing  service policy config in Virtual Template

Feb 15 12:08:22: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
up Feb 15 12:08:22: %FR-3-MLPOFR_ERROR: MLPoFR not configured properly on
Link Virtual-Access1 Bundle Multilink1: AttachMate solutions Links
:Missing  service policy config in Virtual Template

I have added a service policy to the downed virtual-template 1 interface
(router b) and it doesn’t seem to have fixed the issue.

Router B config (IOS (tm) 7200 Software (C7200-P-M), Version 12.2(17a),
RELEASE SOFTWARE (fc1)):

interface Multilink1
 bandwidth 3072
 ip address 1.2.3.2 255.255.255.252
 ppp multilink
 no ppp multilink fragmentation
 multilink-group 1

interface Virtual-Template1
 no ip address
 service-policy input bondedt3policy
 service-policy output bondedt3policy
 ppp multilink
 multilink-group 1


The weird thing is im getting almost a full 3 meg throughput so I know its
working but I’m wondering why the virtual-template is down on both ends and
why on router B isp side im seeing the MLPoFR error above if I added the
service policy to the virtual-template interface.

Thanks,
 
Paul


P.A > -----Original Message-----
P.A > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
P.A > bounces at puck.nether.net] On Behalf Of osvaldo osvaldo
P.A > Sent: Monday, February 18, 2008 10:53 PM
P.A > To: cisco-nsp at puck.nether.net
P.A > Subject: [c-nsp] MLPoFR issue (Paul A)
P.A > 
P.A > Have you try to configure Multilink-Frame-Relay. I have two sites
P.A > working running on 2821 routers. I had to coordinate everything with
P.A > the ISP since they have to support the feature on their backbone. They
P.A > will be doing the freagmentation on thier end.
P.A > 
P.A > ex
P.A > 
P.A > interface MFR1
P.A > 
P.A > 
P.A > 
P.A >  no ip address
P.A > 
P.A > 
P.A > 
P.A >  mls qos trust dscp
P.A > 
P.A > 
P.A > 
P.A >  frame-relay intf-type dce
P.A > 
P.A > 
P.A > 
P.A >  frame-relay multilink bid router1
P.A > 
P.A > 
P.A > 
P.A > !
P.A > 
P.A > 
P.A > 
P.A > interface MFR1.1 point-to-point
P.A > 
P.A > 
P.A > 
P.A >  ip address 10.0.1.1 255.255.255.0
P.A > 
P.A > 
P.A > 
P.A >  ip pim sparse-mode
P.A > 
P.A > 
P.A > 
P.A >  mls qos trust dscp
P.A > 
P.A > 
P.A > 
P.A >  frame-relay interface-dlci 100
P.A > 
P.A > 
P.A > 
P.A > 
P.A > 
P.A > 
P.A > interface Serial5/0
P.A > 
P.A > 
P.A > 
P.A >  encapsulation frame-relay MFR1
P.A > 
P.A > 
P.A > 
P.A >  frame-relay multilink lid first-link
P.A > 
P.A > 
P.A > 
P.A >  frame-relay multilink hello 9
P.A > 
P.A > 
P.A > 
P.A >  frame-relay multilink retry 3
P.A > 
P.A > 
P.A > 
P.A > 
P.A > 
P.A > 
P.A > interface Serial6/0
P.A > 
P.A > 
P.A > 
P.A >  encapsulation frame-relay MFR1
P.A > 
P.A > 
P.A > 
P.A >  frame-relay multilink ack 4
P.A > frame-relay multilink lid first-link
P.A > 
P.A > 
P.A > 
P.A >  frame-relay multilink hello 9
P.A > 
P.A > 
P.A > 
P.A >  frame-relay multilink retry 3
P.A > 
P.A > 
P.A > 
P.A > http://cisco.com/en/US/docs/ios/12_0s/feature/guide/17s_mfr.html
P.A > 
P.A > 
P.A > 
P.A > 
P.A > 
P.A > 
P.A > 
P.A > 
P.A > ______________________________________________________________________
P.A > ______________
P.A > Be a better friend, newshound, and
P.A > know-it-all with Yahoo! Mobile.  Try it now.
P.A > http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
P.A > _______________________________________________
P.A > cisco-nsp mailing list  cisco-nsp at puck.nether.net
P.A > https://puck.nether.net/mailman/listinfo/cisco-nsp
P.A > archive at http://puck.nether.net/pipermail/cisco-nsp/



More information about the cisco-nsp mailing list