multilink virtual-access bundle interface issues

Discussion in 'Cisco' started by Dan Lanciani, Jul 9, 2003.

  1. Dan Lanciani

    Dan Lanciani Guest

    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
     
    Dan Lanciani, Jul 9, 2003
    #1
    1. Advertising

  2. 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
     
    Aaron Leonard, Jul 10, 2003
    #2
    1. Advertising

  3. Dan Lanciani

    Dan Lanciani Guest

    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
     
    Dan Lanciani, Jul 10, 2003
    #3
  4. 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
    ~
     
    Aaron Leonard, Jul 10, 2003
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Buffalo
    Replies:
    0
    Views:
    552
    Buffalo
    May 5, 2009
  2. VanguardLH
    Replies:
    0
    Views:
    602
    VanguardLH
    May 5, 2009
  3. Centre Parting
    Replies:
    0
    Views:
    612
    Centre Parting
    May 5, 2009
  4. Tony
    Replies:
    1
    Views:
    760
    VanguardLH
    May 5, 2009
  5. Replies:
    0
    Views:
    632
Loading...

Share This Page