Subject: Re: (usr-tc) 2 ARC's - one chassis

From: Aaron Nabil <[email-masked]>
Date: Tue, 17 Aug 1999 11:51:34 +0000

[email-masked] writes...
>The automated way to do this is with NMC chassis awareness, dynamic slot
>assignment and dsa idle rebalancing.
>
> . . .
>
>As far as IP pool assignment...the best way to get this to work with the
>above setup is to set each Arc with two ip pools and
>
>set:
>disable ip address_pool_round_robin
>
>Then set the first arc with pool 1 first, pool 2 second, and the second
>arc with pool 2 first and pool 1 second.

Unless you set these as no_aggregate, both ARC's will announce routes for
both pools.  And even if you do set them no_aggregate, replacing the failed
ARC will cause it start using addresses the other backup ARC had been 
assigning (assuming it used up all of it's first pool).

In any case, this doesn't sound like such a good idea.

The only obvious solution is to assign 2x the number of addresses to each 
ARC, or use some kind of radius-based IP address resource allocation.

-- 
Aaron Nabil

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: [email-masked]
Date: Tue, 17 Aug 1999 12:32:48 +0000

We are using Merit radius for our NAS's...  Is there something
that we need to do with the radius in order for it to use chap
authentication?

  Just shut down the rest of our analog lines and the server
authenticating them did CHAP...  I would assume there is a file that we
need to refer to for the radius.

==============================================================================
Phillip Ferraro				WorldNet Access, Inc
[email-masked]	Onslow County's PREMIER InterNet Service 
Voice (910) 346-0835		    824 Gumbranch Square, Suite R3
FAX   (910) 455-1933		     Jacksonville, Nc  28540-6269
==============================================================================

-

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 17 Aug 1999 12:37:40 +0000

Thus spake Aaron Nabil

>assigning (assuming it used up all of it's first pool).

Replacing the failed Arc is problematic, yeah...but there are ways to
work around that...ie, have a pool of addresses available total for this
situation (could use this one pool for all of your network, not just the
chassis)...then set this as the new pool on the new chassis that you're
using to replace the failed one.  As the dsa idle rebalancing moves
cards back over to the new chassis, this will free up the second pool on
the first Arc, which can then be added back to the replacement arc.  At
this point, you can also then add the primary pool on the other arc back
(again...make sure you have the round robin pool assignment disabled),
then delete the temporary pool from the replaced arc (note, you can do
this will addresses from that pool are still in use...the arcs are
intelligent about this) and it'll switch back to your original
situation.

>ARC, or use some kind of radius-based IP address resource allocation.

Ugh...I can't handle double the number of addresses...I think my
solution above should work (assuming your network uses at least RIP
routing for your IP pools), and drastically lowers the IP address
consumption....maybe not *quite* as easy to manage a switch over, but
should be transparent to end users and not as wasteful of IP addresses.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Aaron Nabil <[email-masked]>
Date: Tue, 17 Aug 1999 16:03:09 +0000

Jeff Mcadams writes...
>should be transparent to end users and not as wasteful of IP addresses.

Your plan requires to much manual intervention (ie, work) to
be practical for me. :)  I'd much rather just unplug or disable the
DSP's corresponding to the failed ARC until the replacement came
in than risk screwing with the pools.  Major potential recipe for
disaster.

Using Radius to handle this is probably the easiest, although the
version I use (Radiator) doesn't support any of the resource-management
extensions (at least I don't think it does).  A very simple work around
(and I think the latest version of Radiator supports this) is to map
each specific modem to it's own IP address.  OSPF should make this
much less painful.

-- 
Aaron Nabil

-

---

From: Tatai SV Krishnan <[email-masked]>
Date: Tue, 17 Aug 1999 16:17:14 +0000

> that we need to do with the radius in order for it to use chap

For chap first off all your user password list should be in a text format 
on the server.  You cannot use any database of unix passwords.

krish

-

---

From: Jamie Orzechowski <[email-masked]>
Date: Tue, 17 Aug 1999 16:20:40 +0000

I would just like to know if one ARC can even handle 14 DSP's or should I
use 2 ARCS?

-

---

From: Tatai SV Krishnan <[email-masked]>
Date: Tue, 17 Aug 1999 17:01:28 +0000

> I would just like to know if one ARC can even handle 14 DSP's or should I

A single ARC can handle 14 DSP as long as you are not using IPX.  With 
IPX enabled (IP and IPX both) we recommend only 7 DSP per ARC.

krish

-

---

From: [email-masked]
Date: Tue, 17 Aug 1999 17:17:59 +0000

On the Arcs...make sure neither are set as owners of any of the cards,
then do the following on both:

enable nmc chassis_awareness
enable nmc dynamic_slot_assignment
enable nmc dsa_idle_rebalancing

Then the Arc's (with the help of the NMC) should have worked out who
controls what modem cards (this is a slow process - have patience).  If one
of the Arcs fails the other Arc should pick up the modem assignments.

set:

I haven't tested all this out thoroughly...specifically not the ip pool
setup...but I
have done a bit of playing with the chassis_awareness, dsa and
dsa_idle_rebalancing...it worked...slowly (like 20 minutes for a failover).

Hope this helps,

FN

"Jamie Orzechowski" <[email-masked]> on 08/16/99 05:06:59 PM

Please respond to [email-masked]

Sent by:  "Jamie Orzechowski" <[email-masked]>

To:   [email-masked]
cc:    (Florin Neamtu/US/3Com)
Subject:  (usr-tc) 2 ARC's - one chassis

Could someone please give me a config to setup load balancing between 2
arc's

I will have 14 DSP's in one chassis with 2 ARC's controlling them.

-

-

---

From: Jason Kelton <[email-masked]>
Date: Tue, 17 Aug 1999 18:43:16 +0000

Aaron,

> ARC, or use some kind of radius-based IP address resource allocation.

Resource Assignement via Radius would appear to be more appropriate these
days in any case.  It means you handle the entire client-side's access and
IP Assignment from within Radius.

Seems to me like a more centralised approach!

- Jason.

-

---

From: Jim Johnson <[email-masked]>
Date: Wed, 18 Aug 1999 02:33:13 +0000

Maybe 3COM should look at the concept of a real Fault tolerant
configuration.

It could be as easy as put a second card in and identify it as a
BACKUP.  

    set chassis slot 2 ARC_Backup

The other ARC could mirror its config onto the backup automatically.  

If the primary failed, the backup takes over as a clone of the primary. 

Jim

-

---

From: John Verreault <[email-masked]>
Date: Wed, 18 Aug 1999 03:58:07 +0000

Are there any performance degradations with 1 ARC & 14 DSP's.
ie. What kind of performance hit do you take with this config as opposed to
2 ARC's & 14 DSP's.

Also, at what point does 1 ARC degrade in performance (6 DSP's, 10 DSP's
,....???)

This is assuming IP traffic only.

Thanks
John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Tatai SV Krishnan
> Sent: Tuesday, August 17, 1999 10:48 AM
> To: Jamie Orzechowski
> Cc: [email-masked]
> Subject: Re: (usr-tc) 2 ARC's - one chassis
>
>

-

---

From: Jamie Orzechowski <[email-masked]>
Date: Wed, 18 Aug 1999 05:29:55 +0000

DITTO!!

----- Original Message -----
From: Jim Johnson <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, August 18, 1999 8:29 AM
Subject: Re: (usr-tc) 2 ARC's - one chassis

-

---

From: Jason Kelton <[email-masked]>
Date: Wed, 18 Aug 1999 20:01:40 +0000

I have the feeling that true failover (without the loss of calls) could be a
hardware limitation of the chassis.  For true failover, you wouldn't have
everything run across the packetbus - you'd need to create a dual-bus to
pass redundant data to in the event the first arc should fail.  I mean, its
possible, but prolly not within a realistic timeframe...

- Jason...
----- Original Message -----
From: Jim Johnson <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, August 18, 1999 10:29 PM
Subject: Re: (usr-tc) 2 ARC's - one chassis

-

---

From: Jim Johnson <[email-masked]>
Date: Thu, 19 Aug 1999 02:39:49 +0000

True.  But I don't care about keeping the calls open, although that
would be great ;).  

I can live with having the backup card actually go through a reboot
cycle if it were necesarry.

Regards,

JIm

-