RE: [USR-TC] Forcing a default route for customer through radius
I was hoping to do it by Radius though. Isn't there a way to do it by framed-route or something like that? Brian Becker President, Poplar Bluff Internet, Inc. http://semo.net P.O. Box 190 | Poplar Bluff, MO 63902 | 573.686.9114 -----Original Message----- From: usr-tc-admin@mailman.xmission.com [mailto:usr-tc-admin@mailman.xmission.com] On Behalf Of Jeff Mcadams Sent: Tuesday, February 05, 2002 8:03 PM To: usr-tc@lists.xmission.com Subject: Re: [USR-TC] Forcing a default route for customer through radius Also sprach Brian Becker
Is there an attribute to force a default route other than the normal via radius for a particular customer?
Check into the Internet Equal Access (IEA) feature. Basically let's you set up per-user default routes. I've not used this feature personally, so I don't know how much help I can be on configuration issues, but I know that's what it does. :) Another option might be to configure the customer as a tunnel user and tunnel them to wherever you need to get their traffic, though there are, obviously, some complications from that. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 _______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc
Also sprach Brian Becker
I was hoping to do it by Radius though. Isn't there a way to do it by framed-route or something like that?
You can specify the IEA information in RADIUS. You have to enable the feature on the Arc first, I believe, but then all of the user configuration for it can be put in their RADIUS profile (3Com VSA's I believe, but in RADIUS nonetheless) You can also specify the tunnel parameters in RADIUS if you decide to go that route. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Brain, Are you trying to redirect them to a certain Website or something so that if they are late on a Bill they will see that page only? Because I am not sure what has been stated will do that. What would really be nice is to push a Popup to the customer... Something to make a box popup when the customer logs in and then again every so often. Once the account becomes more seriously overdue limit their surfing and still have the popup. -- Edgar D. Taylor President/CEO FIRST USA Inc. Voice: (800)716-6190 Email: ed@1st.net Web: www.1st.net -- -----Original Message----- From: usr-tc-admin@mailman.xmission.com [mailto:usr-tc-admin@mailman.xmission.com] On Behalf Of Brian Becker Sent: Tuesday, February 05, 2002 11:00 PM To: usr-tc@lists.xmission.com Subject: RE: [USR-TC] Forcing a default route for customer through radius I was hoping to do it by Radius though. Isn't there a way to do it by framed-route or something like that? Brian Becker President, Poplar Bluff Internet, Inc. http://semo.net P.O. Box 190 | Poplar Bluff, MO 63902 | 573.686.9114 -----Original Message----- From: usr-tc-admin@mailman.xmission.com [mailto:usr-tc-admin@mailman.xmission.com] On Behalf Of Jeff Mcadams Sent: Tuesday, February 05, 2002 8:03 PM To: usr-tc@lists.xmission.com Subject: Re: [USR-TC] Forcing a default route for customer through radius Also sprach Brian Becker
Is there an attribute to force a default route other than the normal via radius for a particular customer?
Check into the Internet Equal Access (IEA) feature. Basically let's you set up per-user default routes. I've not used this feature personally, so I don't know how much help I can be on configuration issues, but I know that's what it does. :) Another option might be to configure the customer as a tunnel user and tunnel them to wherever you need to get their traffic, though there are, obviously, some complications from that. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 _______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc _______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc
Ahhh... Wonder if someone can help with the issue that I mentioned :) -- Ed
I've been fighting this problem for a while so I don't recall the exact sequence of events, but from what I do recall, I rebooted my chassis which was running TCS 4.0. After it was rebooted it would no longer establish an OSPF session with one of our Cisco routers. It was able to establish a session with our other Cisco, our Foundry and our Lucent PM3 without a problem. Prior to this reboot I've been running OSPF sucessfully for many years. I did some research, talked to Cisco, searched the archives, searched 3Com knowledge base and everything came back with the same advice. It's a known issue with the Hiper Arc, simply reboot it. I rebooted it again, it still refused to talk to the one Cisco. The same article suggesting a reboot of the ARC also said that bug was fixed in a later version of the ARC software so I upgraded to TCS 4.5 and rebooted once again. The problem still persists. I have the priority set to 0 on the Arc, the PM3, and the Foundry. The Cisco's are 200 and 100. All routers exchange fine with each other except the Cisco with the priority of 200 and the Arc. Here's what the Cisco is reporting: (208.186.96.11 is the ARC) 5d01h: %OSPF-5-ADJCHG: Process 1, Nbr 208.186.96.11 on FastEthernet0/0 from EXST ART to DOWN, Neighbor Down: Too many retransmitionsig 5d01h: %OSPF-5-ADJCHG: Process 1, Nbr 208.186.96.11 on FastEthernet0/0 from DOWN to DOWN, Neighbor Down: Ignore timer expired DEBUG RESULTS: 5d01h: OSPF: Send DBD to 208.186.96.11 on FastEthernet0/0 seq 0xAA opt 0x42 flag 0x7 len 32 5d01h: OSPF: Retransmitting DBD to 208.186.96.11 on FastEthernet0/0 [5] 5d01h: OSPF: Send DBD to 208.186.96.11 on FastEthernet0/0 seq 0xAA opt 0x42 flag 0x7 len 32 5d01h: OSPF: Retransmitting DBD to 208.186.96.11 on FastEthernet0/0 [6] 5d01h: OSPF: Send DBD to 208.186.96.11 on FastEthernet0/0 seq 0xAA opt 0x42 flag 0x7 len 32 5d01h: OSPF: Retransmitting DBD to 208.186.96.11 on FastEthernet0/0 [7] 5d01h: OSPF: Send DBD to 208.186.96.11 on FastEthernet0/0 seq 0xAA opt 0x42 flag 0x7 len 32 5d01h: OSPF: Retransmitting DBD to 208.186.96.11 on FastEthernet0/0 [8] 5d01h: OSPF: Send DBD to 208.186.96.11 on FastEthernet0/0 seq 0xAA opt 0x42 flag 0x7 len 32 5d01h: OSPF: Retransmitting DBD to 208.186.96.11 on FastEthernet0/0 [9] You can see where the other OSPF sessions are fine. The ARC cycles from a EXSTART state to a DOWN state indefinitely. edge1.slc#sh ip ospf neig Neighbor ID Pri State Dead Time Address Interface 208.186.96.11 0 EXSTART/DROTHER 00:00:31 208.186.96.11 FastEthernet0/ 0 208.186.96.10 0 FULL/DROTHER 00:00:32 208.186.96.10 FastEthernet0/ 0 192.168.55.1 2 FULL/DROTHER 00:00:31 208.186.96.21 FastEthernet0/ 0 208.186.100.73 100 FULL/DR 00:00:36 208.186.96.15 FastEthernet0/ 0 Any advice would be greatly appreciated.
On Wed, 12 Feb 2003, Steve Coleman wrote:
I have the priority set to 0 on the Arc, the PM3, and the Foundry. The Cisco's are 200 and 100. All routers exchange fine with each other except the Cisco with the priority of 200 and the Arc.
What does the ARC see as the prefix length for the subnet that it talks with the other OSPF neighbors on? Ie. does the subnet match with the other routers?
All the routers have a /24 subnet. (208.186.96.0/24) However, doing a list ip route on the arc shows the following relevant routing entries 208.186.96.0/21 LOCAL 208.186.96.15 1 eth:1 208.186.96.11/H LOCAL 208.186.96.11 1 eth:1 I've run into the problem where OSPF won't negotiate because the subnet masks don't match. That's easy to troubleshoot because the debug on the Cisco will specifically say the netmasks don't match. I'm not having that problem this time. 208.186.96.0/21 is the aggregate address for that block. It's being redistributed into OSPF from BGP. ----- Original Message ----- From: "Antonio Querubin" <tony@lava.net> To: <usr-tc@mailman.xmission.com> Cc: <usr-tc@lists.xmission.com>; <mandrews@bit0.com> Sent: Wednesday, February 12, 2003 12:09 PM Subject: Re: [USR-TC] OSPF Adjaceny Problems
On Wed, 12 Feb 2003, Steve Coleman wrote:
I have the priority set to 0 on the Arc, the PM3, and the Foundry. The Cisco's are 200 and 100. All routers exchange fine with each other except the Cisco with the priority of 200 and the Arc.
What does the ARC see as the prefix length for the subnet that it talks with the other OSPF neighbors on? Ie. does the subnet match with the other routers?
_______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc
On Wed, 12 Feb 2003, Steve Coleman wrote:
All the routers have a /24 subnet. (208.186.96.0/24) However, doing a list ip route on the arc shows the following relevant routing entries
208.186.96.0/21 LOCAL 208.186.96.15 1 eth:1 208.186.96.11/H LOCAL 208.186.96.11 1 eth:1
I've run into the problem where OSPF won't negotiate because the subnet masks don't match. That's easy to troubleshoot because the debug on the Cisco will specifically say the netmasks don't match. I'm not having that problem this time.
208.186.96.0/21 is the aggregate address for that block. It's being redistributed into OSPF from BGP.
Would this be a null route for locking down the announcement of the aggregate perhaps? From some earlier notes from Mike Andrews (search the list archives for 'OSPF adjacency') this might be related to 3COM bug ID MR12019 which you may have already found in the archives.
We redistribute BGP into OSPF. That /21 is from an aggregate block in the BGP table. We don't use any "null0" routes. What's interesting is that every other router in the same area as the HiperArc is on the same IP subnet (208.186.96.0/24) and it's not having adjacency problems with any of those. ----- Original Message ----- From: "Antonio Querubin" <tony@lava.net> To: <usr-tc@mailman.xmission.com> Sent: Wednesday, February 12, 2003 5:43 PM Subject: Re: [USR-TC] OSPF Adjaceny Problems
On Wed, 12 Feb 2003, Steve Coleman wrote:
All the routers have a /24 subnet. (208.186.96.0/24) However, doing a list ip route on the arc shows the following relevant routing entries
208.186.96.0/21 LOCAL 208.186.96.15 1 eth:1 208.186.96.11/H LOCAL 208.186.96.11 1 eth:1
I've run into the problem where OSPF won't negotiate because the subnet masks don't match. That's easy to troubleshoot because the debug on the Cisco will specifically say the netmasks don't match. I'm not having that problem this time.
208.186.96.0/21 is the aggregate address for that block. It's being redistributed into OSPF from BGP.
Would this be a null route for locking down the announcement of the aggregate perhaps? From some earlier notes from Mike Andrews (search the list archives for 'OSPF adjacency') this might be related to 3COM bug ID MR12019 which you may have already found in the archives.
_______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc
Hello, Just wondering if anyone can think of any reason to change the "defaults" of most of these settings such as "Receiver Gain" or "Jitter Annenuation". Thanks for any info that you guys can give. Framing Mode dsx1ESF Line Coding Options dsx1B8ZS Circuit Identifier Loopback Configuration dsx1NoLoop Signal Mode robbedBit Transmit Clock Source loopTiming NIC Type longHaul Response to Remote Loopback ignore Jitter Attenuation attenJitterOnRcvr Transmit Line Build Out dB0pt0 Dial In Address noAddress Dial In/Out Trunk Start Signal Type wink Ack Wink On Dial In Address Info Received disabled Dial Out Address Delay 70 Dial In/Out Trunk Type eAndMTypeII Primary Switch Type priSw5ESS Idle Byte Pattern 254 Receiver Gain dB26 Tone Type dtmf Number of DTMF Tones 4 Send Code dsx1SendNoCode External Signaling Mode (will take effect next boot) none Overlap Receiving Mode disable Overlap Receiving Inbound Digits Expected 12 Overlap Receiving Timeout Delay 12 Wm. Roche Information Boulevard Internet Services Technical Support Manager http://www.infoblvd.net mailto:Support@infoblvd.net 1.877.463.6258 (Tech Support) 607.324.0810 607.324.6860 (Fax) ---
participants (6)
-
Antonio Querubin -
Brian Becker -
Ed Taylor -
Information Boulevard Support -
Jeff Mcadams -
Steve Coleman