Subject: RE: [USR-TC] Forcing a default route for customer through radius

From: Brian Becker <[email-masked]>
Date: Wed, 06 Feb 2002 04:00:18 +0000

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: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeff Mcadams
Sent: Tuesday, February 05, 2002 8:03 PM
To: [email-masked]
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: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

_______________________________________________
USR-TC mailing list
[email-masked]
http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc

---

From: Jeff Mcadams <[email-masked]>
Date: Wed, 06 Feb 2002 12:52:18 +0000

Also sprach Brian Becker
>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: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

---

From: Ed Taylor <[email-masked]>
Date: Wed, 06 Feb 2002 17:10:25 +0000

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: [email-masked]
Web: www.1st.net
--

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Brian Becker
Sent: Tuesday, February 05, 2002 11:00 PM
To: [email-masked]
Subject: RE: [USR-TC] Forcing a default route for customer through
radius

Brian Becker

-----Original Message-----

Also sprach Brian Becker

---

From: Ed Taylor <[email-masked]>
Date: Thu, 07 Feb 2002 10:13:15 +0000

Ahhh... Wonder if someone can help with the issue that I mentioned :)

--
Ed

---

From: Steve Coleman <[email-masked]>
Date: Wed, 12 Feb 2003 18:07:32 +0000

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.

---

From: Antonio Querubin <[email-masked]>
Date: Wed, 12 Feb 2003 12:10:01 +0000

> 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?

---

From: Information Boulevard Support <[email-masked]>
Date: Wed, 12 Feb 2003 19:18:06 +0000

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:[email-masked]
1.877.463.6258 (Tech Support)
607.324.0810
607.324.6860 (Fax)

---

---

From: Steve Coleman <[email-masked]>
Date: Wed, 12 Feb 2003 19:54:12 +0000

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.

---

From: Antonio Querubin <[email-masked]>
Date: Thu, 13 Feb 2003 00:43:44 +0000

> 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.

---

From: Steve Coleman <[email-masked]>
Date: Thu, 13 Feb 2003 18:02:16 +0000

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.