«

I am using the following configuration for basic ppp multilink operation
on two synchronous serial dial lines (IOS 12.1(20) on a 2500 series):

interface Serial0
bandwidth 56
no ip address
encapsulation ppp
no ip mroute-cache
dialer in-band
dialer rotary-group 0
no fair-queue
pulse-time 1
compress stac
no cdp enable
!
interface Serial1
bandwidth 56
no ip address
encapsulation ppp
no ip mroute-cache
dialer in-band
dialer rotary-group 0
no fair-queue
pulse-time 1
compress stac
no cdp enable
!
interface Dialer0
ip address 1.2.3.4 255.255.255.128
ip access-group 100 in
ip accounting output-packets
ip pim dense-mode
encapsulation ppp
no ip mroute-cache
dialer in-band
dialer idle-timeout 2147483
dialer string 5551234
dialer-group 1
compress stac
no cdp enable
ppp chap hostname myname
ppp chap password mypassword
ppp multilink

This works fine (note that I left out the load threshold command so the
sample will bring up only one link) as far as the actual routing, though
a few things aren't quite right. The bundle virtual-access interface is
cloned from Dialer0, but the clone is flawed. At some level the system
believes that ip processing is disabled on the virtual-access interface
and thus "show ip int" cannot be used to look at, e.g., the PPP peer address.
Perhaps for similar reasons compression statistics are not available for
the virtual-access bundle interface with "show comp".

I thought that perhaps the virtual-access bundle interface was not cloning
the ip address from the dialer interface in order to avoid a duplicate, but
setting Dialer0 up as unnumbered made no difference.

I created a virtual-template with the same parameters as the dialer interface
and assigned it with "multilink virtual-template x". Interestingly, this
had no effect whatsoever, with debugging confirming that the virtual-access
bundle interface was still being cloned from the dialer interface. What
exactly does "multilink virtual-template" do? Is it perhaps for assigning
a template to projected links rather than bundles?

Next I assigned the virtual-template with "virtual-profile virtual-template x".
This worked in the sense that the virtual-access bundle interface was then
cloned from my template rather than from the dialer interface. Moreover,
"show ip int" and "show comp" did the right things. Unfortunately, the virtual
profile introduced a new problem in that the dialer interface was unwilling to
route packets from routes pointed directly to it (by, e.g., ip route 0.0.0.0
0.0.0.0 Dialer0), giving an error message like "vp up dropping non-broadcast
packet" (I forget the exact wording). Now I can fix the latter problem by
making the routes point to the peer address rather than the interface, but
I wonder if there is a better way. Also, it isn't clear which (if any) routes
are adjusted to point to the virtual-access bundle interface. Obviously my
static default route was not, but at some level the route that routed the
packet that triggered the dial-on-demand event in the first place has to be
redirected. Perhaps only the route-to-host that is installed when IPCP comes
up is redirected even though the it still shows up as pointing to "Dialer0"
in the table? Is there any detailed documentation on this? Or about the
exact semantics of the various commands that apply virtual templates? The
documentation mentions that it is critical to understand which templates are
used for what, but it doesn't do a very good job explaining this.

Dan Lanciani
ddl@danlan.*com

I'd get rid of all the virtual-template stuff and convert to
using a dialer profile. I.e. change the physical serial
interfaces to do "dialer pool-member 1" and then build a
dialer interface which uses "dialer pool 1".

Aaron

---

~ I am using the following configuration for basic ppp multilink operation
~ on two synchronous serial dial lines (IOS 12.1(20) on a 2500 series):
~
~ interface Serial0
~ bandwidth 56
~ no ip address
~ encapsulation ppp
~ no ip mroute-cache
~ dialer in-band
~ dialer rotary-group 0
~ no fair-queue
~ pulse-time 1
~ compress stac
~ no cdp enable
~ !
~ interface Serial1
~ bandwidth 56
~ no ip address
~ encapsulation ppp
~ no ip mroute-cache
~ dialer in-band
~ dialer rotary-group 0
~ no fair-queue
~ pulse-time 1
~ compress stac
~ no cdp enable
~ !
~ interface Dialer0
~ ip address 1.2.3.4 255.255.255.128
~ ip access-group 100 in
~ ip accounting output-packets
~ ip pim dense-mode
~ encapsulation ppp
~ no ip mroute-cache
~ dialer in-band
~ dialer idle-timeout 2147483
~ dialer string 5551234
~ dialer-group 1
~ compress stac
~ no cdp enable
~ ppp chap hostname myname
~ ppp chap password mypassword
~ ppp multilink
~
~ This works fine (note that I left out the load threshold command so the
~ sample will bring up only one link) as far as the actual routing, though
~ a few things aren't quite right. The bundle virtual-access interface is
~ cloned from Dialer0, but the clone is flawed. At some level the system
~ believes that ip processing is disabled on the virtual-access interface
~ and thus "show ip int" cannot be used to look at, e.g., the PPP peer address.
~ Perhaps for similar reasons compression statistics are not available for
~ the virtual-access bundle interface with "show comp".
~
~ I thought that perhaps the virtual-access bundle interface was not cloning
~ the ip address from the dialer interface in order to avoid a duplicate, but
~ setting Dialer0 up as unnumbered made no difference.
~
~ I created a virtual-template with the same parameters as the dialer interface
~ and assigned it with "multilink virtual-template x". Interestingly, this
~ had no effect whatsoever, with debugging confirming that the virtual-access
~ bundle interface was still being cloned from the dialer interface. What
~ exactly does "multilink virtual-template" do? Is it perhaps for assigning
~ a template to projected links rather than bundles?
~
~ Next I assigned the virtual-template with "virtual-profile virtual-template x".
~ This worked in the sense that the virtual-access bundle interface was then
~ cloned from my template rather than from the dialer interface. Moreover,
~ "show ip int" and "show comp" did the right things. Unfortunately, the virtual
~ profile introduced a new problem in that the dialer interface was unwilling to
~ route packets from routes pointed directly to it (by, e.g., ip route 0.0.0.0
~ 0.0.0.0 Dialer0), giving an error message like "vp up dropping non-broadcast
~ packet" (I forget the exact wording). Now I can fix the latter problem by
~ making the routes point to the peer address rather than the interface, but
~ I wonder if there is a better way. Also, it isn't clear which (if any) routes
~ are adjusted to point to the virtual-access bundle interface. Obviously my
~ static default route was not, but at some level the route that routed the
~ packet that triggered the dial-on-demand event in the first place has to be
~ redirected. Perhaps only the route-to-host that is installed when IPCP comes
~ up is redirected even though the it still shows up as pointing to "Dialer0"
~ in the table? Is there any detailed documentation on this? Or about the
~ exact semantics of the various commands that apply virtual templates? The
~ documentation mentions that it is critical to understand which templates are
~ used for what, but it doesn't do a very good job explaining this.
~
~ Dan Lanciani
~ ddl@danlan.*com

In article <>, (Aaron Leonard) writes:
| I'd get rid of all the virtual-template stuff and convert to
| using a dialer profile.

I don't understand your suggestion. What I have now is a dialer profile. It
doesn't work quite right (as described). I tried the various virtual templates
to improve the situation. As noted, they cause other issues. Can you tell me
what "multilink virtual-template" applies to exactly? And what about the route
re-pointing question?

| I.e. change the physical serial
| interfaces to do "dialer pool-member 1" and then build a
| dialer interface which uses "dialer pool 1".

Are you saying that grouping physical interfaces under a dialer interface
with the dialer pool-member command will produce different results from those
of using the dialer rotary-group command? What exactly is the difference?

| Aaron
|
| ---
|
| ~ I am using the following configuration for basic ppp multilink operation
| ~ on two synchronous serial dial lines (IOS 12.1(20) on a 2500 series):
| ~
| ~ interface Serial0
| ~ bandwidth 56
| ~ no ip address
| ~ encapsulation ppp
| ~ no ip mroute-cache
| ~ dialer in-band
| ~ dialer rotary-group 0
| ~ no fair-queue
| ~ pulse-time 1
| ~ compress stac
| ~ no cdp enable
| ~ !
| ~ interface Serial1
| ~ bandwidth 56
| ~ no ip address
| ~ encapsulation ppp
| ~ no ip mroute-cache
| ~ dialer in-band
| ~ dialer rotary-group 0
| ~ no fair-queue
| ~ pulse-time 1
| ~ compress stac
| ~ no cdp enable
| ~ !
| ~ interface Dialer0
| ~ ip address 1.2.3.4 255.255.255.128
| ~ ip access-group 100 in
| ~ ip accounting output-packets
| ~ ip pim dense-mode
| ~ encapsulation ppp
| ~ no ip mroute-cache
| ~ dialer in-band
| ~ dialer idle-timeout 2147483
| ~ dialer string 5551234
| ~ dialer-group 1
| ~ compress stac
| ~ no cdp enable
| ~ ppp chap hostname myname
| ~ ppp chap password mypassword
| ~ ppp multilink
| ~
| ~ This works fine (note that I left out the load threshold command so the
| ~ sample will bring up only one link) as far as the actual routing, though
| ~ a few things aren't quite right. The bundle virtual-access interface is
| ~ cloned from Dialer0, but the clone is flawed. At some level the system
| ~ believes that ip processing is disabled on the virtual-access interface
| ~ and thus "show ip int" cannot be used to look at, e.g., the PPP peer address.
| ~ Perhaps for similar reasons compression statistics are not available for
| ~ the virtual-access bundle interface with "show comp".
| ~
| ~ I thought that perhaps the virtual-access bundle interface was not cloning
| ~ the ip address from the dialer interface in order to avoid a duplicate, but
| ~ setting Dialer0 up as unnumbered made no difference.
| ~
| ~ I created a virtual-template with the same parameters as the dialer interface
| ~ and assigned it with "multilink virtual-template x". Interestingly, this
| ~ had no effect whatsoever, with debugging confirming that the virtual-access
| ~ bundle interface was still being cloned from the dialer interface. What
| ~ exactly does "multilink virtual-template" do? Is it perhaps for assigning
| ~ a template to projected links rather than bundles?
| ~
| ~ Next I assigned the virtual-template with "virtual-profile virtual-template x".
| ~ This worked in the sense that the virtual-access bundle interface was then
| ~ cloned from my template rather than from the dialer interface. Moreover,
| ~ "show ip int" and "show comp" did the right things. Unfortunately, the virtual
| ~ profile introduced a new problem in that the dialer interface was unwilling to
| ~ route packets from routes pointed directly to it (by, e.g., ip route 0.0.0.0
| ~ 0.0.0.0 Dialer0), giving an error message like "vp up dropping non-broadcast
| ~ packet" (I forget the exact wording). Now I can fix the latter problem by
| ~ making the routes point to the peer address rather than the interface, but
| ~ I wonder if there is a better way. Also, it isn't clear which (if any) routes
| ~ are adjusted to point to the virtual-access bundle interface. Obviously my
| ~ static default route was not, but at some level the route that routed the
| ~ packet that triggered the dial-on-demand event in the first place has to be
| ~ redirected. Perhaps only the route-to-host that is installed when IPCP comes
| ~ up is redirected even though the it still shows up as pointing to "Dialer0"
| ~ in the table? Is there any detailed documentation on this? Or about the
| ~ exact semantics of the various commands that apply virtual templates? The
| ~ documentation mentions that it is critical to understand which templates are
| ~ used for what, but it doesn't do a very good job explaining this.
| ~
| ~ Dan Lanciani
| ~ ddl@danlan.*com

No, you don't have a dialer profile, you have legacy dialer.

Try my suggestion.

Note that virtual profiles trump legacy dialer but dialer profiles
trump virtual profiles. You don't want/need a virtual profile here,
so go with dialer profiles.

Aaron

---

~ In article <>, (Aaron Leonard) writes:
~ | I'd get rid of all the virtual-template stuff and convert to
~ | using a dialer profile.
~
~ I don't understand your suggestion. What I have now is a dialer profile. It
~ doesn't work quite right (as described). I tried the various virtual templates
~ to improve the situation. As noted, they cause other issues. Can you tell me
~ what "multilink virtual-template" applies to exactly? And what about the route
~ re-pointing question?
~
~ | I.e. change the physical serial
~ | interfaces to do "dialer pool-member 1" and then build a
~ | dialer interface which uses "dialer pool 1".
~
~ Are you saying that grouping physical interfaces under a dialer interface
~ with the dialer pool-member command will produce different results from those
~ of using the dialer rotary-group command? What exactly is the difference?
~
~ | Aaron
~ |
~ | ---
~ |
~ | ~ I am using the following configuration for basic ppp multilink operation
~ | ~ on two synchronous serial dial lines (IOS 12.1(20) on a 2500 series):
~ | ~
~ | ~ interface Serial0
~ | ~ bandwidth 56
~ | ~ no ip address
~ | ~ encapsulation ppp
~ | ~ no ip mroute-cache
~ | ~ dialer in-band
~ | ~ dialer rotary-group 0
~ | ~ no fair-queue
~ | ~ pulse-time 1
~ | ~ compress stac
~ | ~ no cdp enable
~ | ~ !
~ | ~ interface Serial1
~ | ~ bandwidth 56
~ | ~ no ip address
~ | ~ encapsulation ppp
~ | ~ no ip mroute-cache
~ | ~ dialer in-band
~ | ~ dialer rotary-group 0
~ | ~ no fair-queue
~ | ~ pulse-time 1
~ | ~ compress stac
~ | ~ no cdp enable
~ | ~ !
~ | ~ interface Dialer0
~ | ~ ip address 1.2.3.4 255.255.255.128
~ | ~ ip access-group 100 in
~ | ~ ip accounting output-packets
~ | ~ ip pim dense-mode
~ | ~ encapsulation ppp
~ | ~ no ip mroute-cache
~ | ~ dialer in-band
~ | ~ dialer idle-timeout 2147483
~ | ~ dialer string 5551234
~ | ~ dialer-group 1
~ | ~ compress stac
~ | ~ no cdp enable
~ | ~ ppp chap hostname myname
~ | ~ ppp chap password mypassword
~ | ~ ppp multilink
~ | ~
~ | ~ This works fine (note that I left out the load threshold command so the
~ | ~ sample will bring up only one link) as far as the actual routing, though
~ | ~ a few things aren't quite right. The bundle virtual-access interface is
~ | ~ cloned from Dialer0, but the clone is flawed. At some level the system
~ | ~ believes that ip processing is disabled on the virtual-access interface
~ | ~ and thus "show ip int" cannot be used to look at, e.g., the PPP peer address.
~ | ~ Perhaps for similar reasons compression statistics are not available for
~ | ~ the virtual-access bundle interface with "show comp".
~ | ~
~ | ~ I thought that perhaps the virtual-access bundle interface was not cloning
~ | ~ the ip address from the dialer interface in order to avoid a duplicate, but
~ | ~ setting Dialer0 up as unnumbered made no difference.
~ | ~
~ | ~ I created a virtual-template with the same parameters as the dialer interface
~ | ~ and assigned it with "multilink virtual-template x". Interestingly, this
~ | ~ had no effect whatsoever, with debugging confirming that the virtual-access
~ | ~ bundle interface was still being cloned from the dialer interface. What
~ | ~ exactly does "multilink virtual-template" do? Is it perhaps for assigning
~ | ~ a template to projected links rather than bundles?
~ | ~
~ | ~ Next I assigned the virtual-template with "virtual-profile virtual-template x".
~ | ~ This worked in the sense that the virtual-access bundle interface was then
~ | ~ cloned from my template rather than from the dialer interface. Moreover,
~ | ~ "show ip int" and "show comp" did the right things. Unfortunately, the virtual
~ | ~ profile introduced a new problem in that the dialer interface was unwilling to
~ | ~ route packets from routes pointed directly to it (by, e.g., ip route 0.0.0.0
~ | ~ 0.0.0.0 Dialer0), giving an error message like "vp up dropping non-broadcast
~ | ~ packet" (I forget the exact wording). Now I can fix the latter problem by
~ | ~ making the routes point to the peer address rather than the interface, but
~ | ~ I wonder if there is a better way. Also, it isn't clear which (if any) routes
~ | ~ are adjusted to point to the virtual-access bundle interface. Obviously my
~ | ~ static default route was not, but at some level the route that routed the
~ | ~ packet that triggered the dial-on-demand event in the first place has to be
~ | ~ redirected. Perhaps only the route-to-host that is installed when IPCP comes
~ | ~ up is redirected even though the it still shows up as pointing to "Dialer0"
~ | ~ in the table? Is there any detailed documentation on this? Or about the
~ | ~ exact semantics of the various commands that apply virtual templates? The
~ | ~ documentation mentions that it is critical to understand which templates are
~ | ~ used for what, but it doesn't do a very good job explaining this.
~ | ~
~ | ~ Dan Lanciani
~ | ~ ddl@danlan.*com
~