Re: pppml question

From: Kenneth Sacca (ksacca@xxxxxxxxx)
Date: Wed Sep 06 2000 - 16:07:07 GMT-3


   
So how would you configure a bandwidth of 3088 from
router 1 to router 2 and configure a bandwidth of
2400 from router 1 to router 3?

You can't do that based on your configs as far as
I can tell. You might have different configuration
requirements between router 1 and 2, than you will
between router 1 and 3.

You should be able to associate each serial interface
to a specific virtual-template to make the setup
flexible.

I presented the frame-relay setup configs to show how
flexibility is handled there.

Ken

Wojtek Iwanczyk wrote:
>
> The PPP multilink command on each interface associates that interface with th
e virtual-template, if you do a show int, you will also see a virtual-access in
terface created in the router .. In the CCO you can also find examples of MLPP
P across multiple access servers ...
>
> following are relevant config parameters ..
>
> multilink virtual-template 1
>
> interface Serial3/2:0
> no ip address
> encapsulation ppp
> no ip mroute-cache
> no logging event subif-link-status
> bandwidth 1544
> no fair-queue
> no cdp enable
> ppp multilink
> pulse-time 3
>
> interface Serial3/3:0
> no ip address
> encapsulation ppp
> no ip mroute-cache
> no logging event subif-link-status
> bandwidth 1544
> no fair-queue
> no cdp enable
> ppp multilink
> pulse-time 3
>
> interface Virtual-Template1
> ip address 192.168.254.6 255.255.255.252
> no ip mroute-cache
> no logging event subif-link-status
> bandwidth 3088
>
> Wojtek Iwanczyk
> Sr Support Engineer
> Exenet Technologies
> 15 E 26th Street
> New York, NY 10010
> (212) 684 7300
> wiwanczyk@exenet.com
>
> >>> Kenneth Sacca <ksacca@cisco.com> 09/06/00 01:55PM >>>
> Timur,
>
> On my current project I do it this way. I looked and can't figure
> out what command you would put on the primary serial interface to
> associate a virtual-template with it. Maybe someone else
> knows how to do this. Hope this is of some help.
>
> Ken
> Cisco IOS WAN Development
>
> R1:
> int s 1/1
> frame-relay encapsulation
>
> int s 1/1.1
> frame-relay interface-dlci 40 ppp virtual-template1
>
> int s 1/2
> frame-relay encapsulation
>
> int s 1/2.1
> frame-relay interface-dlci 50 ppp virtual-template2
>
> int virtual-template 1
> ip address 131.180.70.10 255.255.255.0
> ip mroute-cache
> ppp multilink
>
> int virtual-template 2
> ip address 131.180.60.10 255.255.255.0
> ip mroute-cache
> ppp multilink
>
> Timur.Mirza@Notes.airtouch.com wrote:
> >
> > in the following cfg, r1<----3 serial links--->r2....one of my colleagues h
ad a
> > question: if an "r3" is connected to r1 w/ a couple of serial links & you w
ant
> > to run pppml, how would r1 differentiate the 3 t1s to r2 from the two new t
1s to
> > r3, since there is nothing in the cfg that binds s3/5,6 & 7 to virtual-temp
late
> > 1? also, cisco tac said that virtual-template 1 in a down/down state when y
ou
> > issue a "sh ip in br" is normal?
> >
> > !on r1:
> > multilink virtual-template 1
> > !
> > interface Serial3/5
> > no ip address
> > encapsulation ppp
> > ppp multilink
> > !
> > !
> > interface Serial3/6
> > no ip address
> > encapsulation ppp
> > ppp multilink
> > !
> > interface Serial3/7
> > no ip address
> > encapsulation ppp
> > ppp multilink
> > !
> > interface Virtual-Template1
> > ip address 10.1.250.17 255.255.255.252
> > ppp multilink
> >
> > !on r2:
> > multilink virtual-template 1
> > !
> > interface Serial1/0
> > no ip address
> > encapsulation ppp
> > ppp multilink
> > !
> > !
> > interface Serial1/1
> > no ip address
> > encapsulation ppp
> > ppp multilink
> > !
> > interface Serial1/2
> > no ip address
> > encapsulation ppp
> > ppp multilink
> > !
> > interface Virtual-Template1
> > ip address 10.1.250.18 255.255.255.252
> > ppp multilink
> >
> > !note the following output on r1:
> >
> > r1#sh ip in br
> > Interface IP-Address OK? Method Status Pro
tocol
> > Serial3/5 unassigned YES unset up up
> > Serial3/6 unassigned YES unset up up
> > Serial3/7 unassigned YES unset up up
> > Virtual-Access1 10.1.250.17 YES TFTP up up
> > Virtual-Template1 10.1.250.17 YES NVRAM down dow
n
> >
> > !cisco confirmed that the virtual-template 1 is not really an interface & i
t
> > will always register as down/down (this is ok); the virtual-access interfac
e
> > must be in up/up mode & its across this interface where traffic flows, incl
uding
> > the formation of adjacencies in link state relationships, such as in ospf:
> >
> > r1#sh ip o n
> >
> > Neighbor ID Pri State Dead Time Address Interface
> > 1.1.1.2 1 FULL/ - 00:00:33 10.1.250.18
> > Virtual-Access1
> >



This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:24:53 GMT-3