Re: Multiple interfaces using single external routers

Discussion in 'Cisco' started by Arjan, Nov 16, 2004.

  1. Arjan

    Arjan Guest

    -cnrc.gc.ca (Walter Roberson) wrote in message news:<cn1d9n$gn2$>...
    >
    > Not necessarily. It depends on how the lines share the data. If they
    > share based on source, destination, or a combination of source and
    > destination, then because you are always transferring between the same
    > two points, the traffic would all try to go down the same channel.
    > You need per-packet load balancing if you want to be able to reduce
    > the transfer time to 1/N by using N lines.
    >
    > I think you are going to need to turn multilink on to do what you
    > want to do.
    >
    > I have no practical experience with ISDN, so I cannot advise you
    > on how to configure per-packet load balancing in a multilink bundle.
    >
    > I wonder, though: with multilink turned off, you are not even bundling
    > your two B channels together, so all of your stats traffic might be going
    > over a single B channel?


    Thank you for your kind response.

    Let me explain a bit more. The interface that I use uses a single
    channel for each external location. I know this because when I ping
    the externals I cant ping more then 2 at the same time.
    I have one ISDN 2 line so the logical conclusion is that for a single
    connection
    I use a single B channel.

    So the idea to halve the time comes from adding 2 more B channels
    which means 4 single B channels.

    The problem is how do I program this, do i have to program only my
    central router or all the externals as well
     
    Arjan, Nov 16, 2004
    #1
    1. Advertising

  2. In article <>,
    Arjan <> wrote:
    :Let me explain a bit more. The interface that I use uses a single
    :channel for each external location. I know this because when I ping
    :the externals I cant ping more then 2 at the same time.
    :I have one ISDN 2 line so the logical conclusion is that for a single
    :connection
    :I use a single B channel.

    The above had me confused for days. I think I may have finally
    figured it out. Would I be correct in deducing that your central
    router is doing ISDN dialup to the external routers, and that
    each of the external sites has exactly one B channel, and
    that the reason you can only ping two of the external routers
    at any one time is that you only have two B channels at the
    central site to be be independantly dialed at one time?


    :So the idea to halve the time comes from adding 2 more B channels
    :which means 4 single B channels.

    If my deduction above is correct, then if you added 2 more B channels
    and didn't change anything else, then you would be able to transfer
    with up to 4 of the remote sites simultaneously.

    Earlier, you said that you only had a limited time window to fetch the
    statistics. If that time window is for the total time for -all- the
    sites [e.g., you have to polling all of them between 02:30 and 03:00]
    and if the process of fetching the statistics is I/O bound (data
    streaming back to your central site) and takes roughly the same time at
    each of the sites, then being able to access twice as many sites at the
    same time would indeed allow you to finish in about half of the time.
    In this scenario, you would only have to change your central router
    [and perhaps a minor change to the polling program], and would not have
    to change the external sites. You would add B channels at your central
    site but not at the external sites in this scenario.


    You might, though, have meant something quite different: you might
    have meant that for any one external site, once the connection starts,
    you only have a limited amount of time to finish the transfer. This
    would be the situation if, for example, your polling program
    started each connection by halting transactions on a database
    at the remote site, transfered the data and reenabled the database
    transactions, then you could be under pressure to keep the database
    down time to the minimum possible. In situations like these, the
    other sites keep running happily as long as you aren't connected
    to them, and there is no completely fixed time of that they will be
    down, and what you are looking for is to transfer each site as
    quickly as possible, but any other site could be left waiting until
    you happened to get around to it.

    If this is the situation, that you need to transfer each site as
    quickly as possible for the sake of the downtime at that site alone
    but without caring much about the elapsed time to do all the sites
    together, then you would have to get another B channel added to
    each of the other sites but *not* to the central site, and you
    would configure ppp multilink to be on at each of the locations.
    You would run through each of the sites in sequence, finishing one
    completely before starting on the next [otherwise you risk having
    the second B channel at the central site being used to dial out to
    a different site than the first: if the router decides that the
    traffic at the time is low enough that it would all fit in a single
    B channel, the router could decide to use the second B to dial a
    different site, possibly even hanging up on an active B channel
    [leaving the other one connected to that site] in order to do so.


    You could combine these techniques. If the traffic is fairly steady
    on any one connection once it gets started, then what you would want
    is for the central site to have the same number of channel -groups-
    as the number of sites you want to be able to connect to simultaneously,
    and each channel group would have the same number of B channels as
    you have B channels at each of the remote sites. For example, if you
    wanted to be able to connect to three sites simultaneously and you wanted
    two B channels bandwidth to each of them, then each of the remote
    sites would need two B channels, and the central site would need
    three [simultaneous] groups of two B channels for a total of 6 B
    channels at the central site.


    The more interesting case is the situation in which traffic is NOT
    fairly steady on any one connection once it gets started. For example,
    if fetching the statistics consisted of running a series of SQL queries
    where the remote systems has to "think" for a few minutes to prepare
    the data to transfer, then that time spent "thinking" is time that you
    could drop down to fewer channels and use one of the channels to dial a
    different site and tell it to start thinking. In this situation, the
    central site would not necessarily need as many channels as
    ( (simultaneous sessions) multiplied by (channels per session) ).
    Instead, the total number of channels at the remote site could
    be reduced by the extent to which you can overlap the "think" time
    of one site with the data transfer time of a different site.


    As an example, suppose that the "think" time for any one site was
    several times as long as the data transfer time, and suppose further
    that you needed to maintain an active connection with each site
    that was thinking (e.g., if it prints out a '.' every few seconds
    to tell you it's working on the query.) In this hypothetical
    situation, you could reduce the transfer time for several remote
    sites by having two B channels at each of the remote sites, but
    only one extra B channel at the central site. It could go like this,

    time 1: channel 1: idle/disconnected
    channel 2: tell A start query #1
    channel 3: idle/disconnected
    channel 4: idle/disconnected
    channel 5: idle/disconnected

    time 2: C 1: idle/dis
    C 2: wait for A #1
    C 3: B start Q #1
    C 4: idle/dis
    C 5: idle/dis

    time 3: C 1: idle/dis
    C 2: wait A #1
    C 3: wait B #1
    C 4: C start Q #1
    C 5: idle/dis

    time 4: C 1: receive from A answer #1
    C 2: receive from A answer #1
    C 3: wait B #1
    C 4: wait C #1
    C 5: D start Q #1

    time 5: C 1: rcv B #1
    C 2: A start Q #2
    C 3: rcv B #1
    C 4: wait C #1
    C 5: wait D #1

    time 6: C 1: rcv C #1
    C 2: wait A #2
    C 3: B start Q #2
    C 4: rcv C #1
    C 5: wait D #1

    time 7: C 1: rcv D #1
    C 2: wait A #2
    C 3: wait B #2
    C 4: C start Q #2
    C 5: rcv D #1

    time 8: C 1: rcv A #2
    C 2: rcv A #2
    C 3: wait B #2
    C 4: wait C #2
    C 5: D start #2

    time 9: C 1: rcv B #2
    C 2: A start Q #3
    C 3: rcv B #2
    C 4: wait C #2
    C 5: wait D #2

    and so on. Notice how only 5 channels at the central site
    were needed in order to be able to have four simultaneous sessions
    and yet still have two channels to receive each answer. In the above
    scenario, channels 2 through 4 stay connected to the same site all
    through, and channel 1 connects to the location that needs the bandwidth
    and then disconnects again.

    The above might sound far-fetched, but when you use multilink PPP,
    it can happen automatically as the router detects that one channel
    needs more bandwidth and the previously active dual channel connection
    is now low volume.
    --
    Whose posting was this .signature Google'd from?
     
    Walter Roberson, Nov 20, 2004
    #2
    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. mliu
    Replies:
    5
    Views:
    2,325
    Barry Margolin
    Jul 15, 2003
  2. Anonieko Ramos
    Replies:
    0
    Views:
    841
    Anonieko Ramos
    May 8, 2004
  3. Big Phil
    Replies:
    3
    Views:
    1,792
    NetExpert
    May 1, 2007
  4. Replies:
    1
    Views:
    377
    headsetadapter.com
    May 2, 2007
  5. RG
    Replies:
    0
    Views:
    597
Loading...

Share This Page