From: Rich Kettelson (rkettelson@mn.rr.com)
Date: Sun Mar 13 2005 - 14:41:31 GMT-3
Tim,
A better comparison might be gre. Encapsulating one proto within another.
Regerding the virtual template, I cannot find any other way to configure
PPPoFR, so based on that, I would say that virtual templates are ALWAYS
required on both ends of the link when using PPPoFR. When configuring MLPPP
with multiple ppp interfaces, I have been able to create ML Bundles with
either a Multilink Interface OR Virtual template.
Another similar, loosely related topic is MLFR. FRF.15 works on an
end-to-end basis, like the scenario we're descibing. Only the endpoints need
to know about FRF.15, the SP network is oblivious.
FRF.16 works on the FR UNI between the DTE and the DCE devices. This allows
Multiple T1's to appear as a single link to the FR network, kinda like
another loosely related technology, ATM IMA..................
OK, it's back to ISDN for me :(
Rich
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
ccie2be
Sent: Sunday, March 13, 2005 9:31 AM
To: 'Rich Kettelson'; 'John Matus'; 'lab'
Subject: RE: virtual-template question
Rich,
I've also been going this topic lately.
I'm not sure if you're saying something different from this, but let me
highlight this point.
When using ppp multilink, there must be only 2 endpoints. I think of ppp
multilink as a WAN version of EtherChannel. So, if you have a hub and spoke
topology, you can't have the same ppp multilink connection between the hub
and both spokes. You can have a ppp multilink between the hub and 1 spoke
and a different ppp multilink connection between the hub and the other
spoke.
Regarding John's question of whether both sides must use a virtual-template
if one side is using a virtual-template - here's my thought:
As a practical matter, probably yes because the reason you're using
virtual-templates in the first place is to be able to use features like chap
authentication which isn't available without ppp over f/r.
But, upon further reflection, I'm going to change my answer to ALWAYS yes
regardless of what ppp features are used. It occurs to me that when ppp
over F/R is configured on one side what's going on is that the user data is
being encap'ed in ppp which is then encap'ed in f/r.
If ppp over f/r is NOT being used on both sides there will be an encap
mismatch and it won't work.
I haven't tested this so if I'm incorrect or missing a key point, please let
me know.
HTH, Tim
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Rich
Kettelson
Sent: Sunday, March 13, 2005 9:43 AM
To: 'John Matus'; 'lab'
Subject: RE: virtual-template question
John,
By default, links that use the same username are bundled together into the
same MP virtual connection. r4#sho ppp multilink
Virtual-Access2, bundle name is r6
Bundle up for 4d12h
0 lost fragments, 0 reordered, 0 unassigned
0 discarded, 0 lost received, 1/255 load
0x5 received sequence, 0x5 sent sequence
Member links: 2 (max not set, min not set)
Vi1, since 3d12h, no frags rcvd, 375000 weight, 1496 frag size !the
frame PVC
Se0/1, since 3d12h, no frags rcvd, 5790 weight, 1496 frag size !S0/1 ppp
int
To get this to "work" you would need to create a 2 PPPoFR links on the hub,
one to each spoke, and then you're right back where you started with the
PVC's :) Check out the Multilink section here:
http://www.cisco.com/pcgi-bin/Support/browse/psp_view.pl?>p=Technologies:PPP
&s=Implementation_and_Configuration#Samples_and_Tips
And the PPPoFR section here:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1830/products_feature_guid
e09186a008008744a.html
Hope this is helpful. I have been trying to increase my knowledge on this
subject over the last few days, so am by no means an expert. Feel free to
challenge me.
Rich
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of John
Matus
Sent: Saturday, March 12, 2005 8:33 PM
To: Rich Kettelson; 'lab'
Subject: Re: virtual-template question
i'm not sure i follow your config.....
i don't see where you have bound 2 interface to 1 virtual-template.
when you issue the command "frame-relay interface-dlci 304 ppp
Virtual-Template1" does this mean that the other end must be running ppp
over frame relay as well? (lightbulb goes on....!) so i'd have to create a
virtual-template on both the the hub and spokes for this to work....eh?
Regards,
John D. Matus
MCSE, CCNP
Office: 818-782-2061
Cell: 818-430-8372
jmatus@pacbell.net
----- Original Message -----
From: "Rich Kettelson" <rkettelson@mn.rr.com>
To: "'John Matus'" <jmatus@pacbell.net>; "'lab'" <ccielab@groupstudy.com>
Sent: Saturday, March 12, 2005 4:16 PM
Subject: RE: virtual-template question
I've been messing with this a bit. PPP (MLPPP) assumes 2 endpoints, and
fragments packets between the physical links in the ML Bundle, so if DLCI
304 and 305 both terminated to the same remote router it will work.
Here's a config snippet with MLPPP working over one PPP connection and one
frame connection (between the same 2 routers).
!
interface Serial0/0.1 point-to-point
frame-relay interface-dlci 406 ppp Virtual-Template1
class SOMECLASS
!
interface Serial0/1
no ip address
encapsulation ppp
ppp authentication chap
ppp multilink
!
interface Virtual-Template1
ip unnumbered Loopback1
service-policy output SOMEPOLICY
ppp multilink
ppp multilink interleave
!
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of John
Matus
Sent: Saturday, March 12, 2005 5:26 PM
To: lab
Subject: virtual-template question
if you have 3 routers in a hub and spoke topology, and on the hub you create
two p2p interfaces w/ dlci's, can you bind those p2p interfaces into a
virtual-template which acts like both p2p's are actually 1 multipoint
interface? i tried it and i can't seem to get it to work so i'm thinking
that perhaps there is some limitation on this:<??>
HUB
interface Serial1/0.34 point-to-point
frame-relay interface-dlci 304 ppp Virtual-Template1
!
interface Serial1/0.35 point-to-point
frame-relay interface-dlci 305 ppp Virtual-Template1
interface Virtual-Template1
ip address 164.1.0.3 255.255.255.0
Regards,
John D. Matus
MCSE, CCNP
Office: 818-782-2061
Cell: 818-430-8372
jmatus@pacbell.net
This archive was generated by hypermail 2.1.4 : Sun Apr 03 2005 - 17:56:45 GMT-3