Re: (ASCEND) ISDN bonding over multiple MAXes

[Ted Olson <tolson@ocsnet.net>]

Thanks for the feedback Shane. Your suggestion makes sense, so we switched
on 'stacks' for all of our MAXes yesterday to give it a try, all with a
common name and UDP port (the default 5151). We wouldn't have too many
clients using this so no worries about the Ethernet overhead.

But - no change to the problem, we still lose routing through any channel
that gets assigned to any MAX other than where the client's class C is routed.

I still think this issue is related to routing (you're right, DNS was the
wrong choice of terms, the orig message copy below has been fixed for
posterity!) - IOW, if all ports on the primary MAX are full when an initial
incoming ISDN call is received it will be assigned to a different box,
which has a different IP address than that to which the client's class C is
routed and that which is configured in their Pipeline ... and routing will
then stall.

And so, if I understand correctly, enabling stacking only ensures that a
subsequent second channel would share that same IP address - and then both
would be wrong, with routing stalled on both. Here's an illustration:

Configuration:
-----------------------
Client's class C routes to nnn.nnn.nnn.1 (MAX-1)
Further MAXes in dialup hunt group (and stack) include MAX-2 (.2), MAX-3
(.3), and so on...
Client's router (P130) calls to nnn.nnn.nnn.1


This works fine:
-----------------------
ISDN Ch1: nnn.nnn.nnn.1
ISDN Ch2: nnn.nnn.nnn.1

These combinations all have a problem:
-----------------------
ISDN Ch1: nnn.nnn.nnn.1
ISDN Ch2: nnn.nnn.nnn.2

ISDN Ch1: nnn.nnn.nnn.2
ISDN Ch2: nnn.nnn.nnn.1

ISDN Ch1: nnn.nnn.nnn.2
ISDN Ch2: nnn.nnn.nnn.2 (this is what stacking enforces)

Still wondering how to best resolve this issue - any other suggestions?

Thanks much,
-Ted

At 07:30 PM 5/5/99 -0400, you wrote:
>I do not belive this is a DNS issue if you are trying to add a channel to a
>MP or a MPP connection, the 2 channels still need to appear as one IP, not 2
>IP's.
>
>To correctly use channels that are on different Max Boxes you need to enable
>stacking. This will make all max units be able to bond channels together by
>sending the linked channel over ethernet.
>
>Beware, large #'s of bonded channels on different max units can bring
>ethernet to its knees.
>
>Shane Newberg
>
>-----Original Message-----
>From: Ted Olson <tolson@ocsnet.net>
>To: ascend-users@max.bungi.com <ascend-users@max.bungi.com>
>Date: Wednesday, May 05, 1999 5:32 PM
>Subject: (ASCEND) ISDN bonding over multiple MAXes
>
>
>>We've discovered that when the primary MAX dialed by an ISDN account is
>>busy, it is possible that when the same account requests a second channel
>>that port could be opened on a different MAX further down the line in our
>>hunt group.
>>
>>This confuses routing, especially if the first channel drops off leaving
only
>>the second open - users then have a connection but can't see the Net since
>>their router (a P130) is pointed only to the IP addr of the first MAX while
>>their connection is now trying to route to a different box. The channels
>>seem to bond OK and the Pipeline indicates 128K with 2-channels up even
>>when each is on a different box - routing is the only issue.
>>
>>Is this kind of arrangement not recommended? What are the best solutions?
>>We've experimented with adding a route on the downstream MAXes to point
>>back to the primary, with no success. Should multi-channel accounts be
>>physically confined to the same box? Or should they be nailed (I could use
>>any how-to pointers if so).
>>
>>Thanks,
>>-Ted
>>OCS Software
>>
>>++ Ascend Users Mailing List ++
>>To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
>>To get FAQ'd: <http://www.nealis.net/ascend/faq>
>
>
++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.nealis.net/ascend/faq>