Re: (usr-tc) 2 ARC's - one chassis
The automated way to do this is with NMC chassis awareness, dynamic slot assignment and dsa idle rebalancing. 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. 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. 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" <mhz@ripnet.com> on 08/16/99 05:06:59 PM Please respond to usr-tc@lists.xmission.com Sent by: "Jamie Orzechowski" <mhz@ripnet.com> To: usr-tc@lists.xmission.com 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. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Florin_Neamtu@3com.com 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 "majordomo@xmission.com" 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.
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 pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ============================================================================== - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
On Tue, 17 Aug 1999 pferraro@wna-linknet.com wrote:
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?
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
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 pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ==============================================================================
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Thus spake Aaron Nabil
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).
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.
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.
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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Jeff Mcadams writes...
Thus spake Aaron Nabil
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.
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.
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 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
I would just like to know if one ARC can even handle 14 DSP's or should I use 2 ARCS? - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
On Tue, 17 Aug 1999, Jamie Orzechowski wrote:
I would just like to know if one ARC can even handle 14 DSP's or should I use 2 ARCS?
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
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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: owner-usr-tc@lists.xmission.com [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan Sent: Tuesday, August 17, 1999 10:48 AM To: Jamie Orzechowski Cc: usr-tc@lists.xmission.com Subject: Re: (usr-tc) 2 ARC's - one chassis
On Tue, 17 Aug 1999, Jamie Orzechowski wrote:
I would just like to know if one ARC can even handle 14 DSP's or should I use 2 ARCS?
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
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Aaron,
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.
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. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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 Jason Kelton wrote:
Aaron,
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.
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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
DITTO!! ----- Original Message ----- From: Jim Johnson <jim@perigee.net> To: <usr-tc@lists.xmission.com> Sent: Wednesday, August 18, 1999 8:29 AM Subject: Re: (usr-tc) 2 ARC's - one chassis
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
Jason Kelton wrote:
Aaron,
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.
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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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 <jim@perigee.net> To: <usr-tc@lists.xmission.com> Sent: Wednesday, August 18, 1999 10:29 PM Subject: Re: (usr-tc) 2 ARC's - one chassis
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
Jason Kelton wrote:
Aaron,
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.
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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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 Jason Kelton wrote:
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 <jim@perigee.net> To: <usr-tc@lists.xmission.com> Sent: Wednesday, August 18, 1999 10:29 PM Subject: Re: (usr-tc) 2 ARC's - one chassis
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
Jason Kelton wrote:
Aaron,
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.
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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
participants (9)
-
Aaron Nabil -
Florin_Neamtu＠3com.com -
Jamie Orzechowski -
Jason Kelton -
Jeff Mcadams -
Jim Johnson -
John Verreault -
pferraro＠wna-linknet.com -
Tatai SV Krishnan