Continuing this sordid tale... >From: Peter Lalor <plalor at infoasis.com> >Date: Mon, 7 Aug 2000 09:38:26 -0700 > >A follow-up to my post of a couple weeks ago: > >>From: Peter Lalor <plalor at infoasis.com> >>Date: Wed, 26 Jul 2000 15:18:52 -0700 >> >>We have a DSL Terminator 100 that's acting up in new and creative >>ways. Whenever we make any change that affects the routing table, >>such as adding, removing, enabling or disabling a connection profile >>or route, the unit sends many routes to wanidle0 and the unit must be >>reset. >> >>As we also have several DSL Max 20s (and other Ascend gear) that >>don't exhibit this problem, we figured that we must have some error >>in a profile somewhere, and we did in fact find several profiles with >>errors, most notably some profiles that inadvertently had BIR enabled >>(the tech had copied a bridged account to make a routed account). We >>also found some typos in IP addresses and subnet masks. >> >>We fixed all that--and I mean _everything_--but the box is still very >>unhappy. I even found a route from a typo that had been corrected > >that would recur after every reset, even though the route appears > >nowhere in the config or RADIUS. I eventually copied an empty profile > >over the corrected profile and re-entered it from scratch, which >>finally removed that route but did not fix the problem of routes >>going to wanidle0. >> >>My guess at this point is that the unit needs an fclear, nvramclear > >and the configuration reloaded. > >Doing fclear, nvramclear and reloading the config made no difference. > >From: Peter Lalor <plalor at infoasis.com> >Date: Mon, 7 Aug 2000 11:18:46 -0700 > >Well, I've opened a ticket with Ascend. Try not to laugh. Or cry. Ascend's shocking, unpredictable (not!) response: > Suggest that you >fclear , >nvramclear the DSLT100 and >re-configure the unit from scratch manually. I know you have done this >step "We finally did an fclear, nvramclear and trestored the >configuration, but the problem persists. The unit is essentially >unusable as we cannot touch it without a restart". It maybe be quite >possible that the configuration settings itself may have been corrupted >and causing this problem. Please give us an update on this issue. As the config is merely a text file, I fail to see the difference between restoring it and typing it in by hand, except that I'll probably add some typos if I do it by hand. Several people here have been over the config and the RADIUS profiles with a fine-tooth comb and we can find nothing wrong whatsoever. Question: does anyone have any reason to believe that there is a problem with Ascend's trestore or Restore Cfg routines? Next, here's some examples of what happens to the routing table. In each section, the first line are Before, the second line(s) are After. To recap, we're doing ATM profiles using interface-based routing. 1. The client-side Ethernet address does not normally appear in the routing table (Suppress Host Routes), but goes to wanidle: 192.168.84.0/26 192.168.85.105 wan SG 120 7 192.168.84.64/26 192.168.85.85 wan SG 120 7 192.168.84.0/26 192.168.85.105 wan SG 120 7 192.168.84.1/32 192.168.85.105 wanidleSG 120 7 192.168.84.64/26 192.168.85.85 wan SG 120 7 192.168.84.65/32 192.168.85.85 wanidleSG 120 7 2. The local interface address becomes Multipath: 192.168.85.18/32 - local rT 0 0 192.168.85.18/32 - local CM 0 0 192.168.85.18/32 - local rTM 0 0 3. Some /25 RIP routes come and go (IN GOOD!): 192.168.0.0/16 192.168.85.1 wan RGT 100 11 192.168.26.0/28 192.168.85.1 wan RGT 100 4 192.168.26.32/28 192.168.85.1 wan RGT 100 6 192.168.26.112/29 192.168.85.1 wan RGT 100 6 192.168.26.128/27 192.168.85.1 wan RGT 100 4 192.168.0.0/16 192.168.85.1 wan RGT 100 11 192.168.26.0/25 192.168.85.1 wan RGT 100 4 192.168.26.0/28 192.168.85.1 wan RGT 100 4 192.168.26.32/28 192.168.85.1 wan RGT 100 6 192.168.26.112/29 192.168.85.1 wan RGT 100 6 192.168.26.128/25 192.168.85.1 wan RGT 100 4 192.168.26.128/27 192.168.85.1 wan RGT 100 6 4. Some RIP routes disappear: 192.168.26.224/27 192.168.85.1 wan RGT 100 6 192.168.58.0/24 192.168.85.1 wan RGT 100 4 192.168.58.0/29 192.168.85.1 wan RGT 100 4 192.168.26.224/27 192.168.85.1 wan RGT 100 6 192.168.58.0/29 192.168.85.1 wan RGT 100 4 To recap, we're doing ATM profiles using interface-based routing. We notice that BIR profiles continue to operate normally, as do some local profiles. Apparently, RADIUS is an issue, as our other Max 20s (same hardware) do not use RADIUS for authentication and are working fine. i may have to move all profiles locally, but that's a dead end. I'm about to configure a Max 20 to mock the whole damn thing up using FR T1 cross-connected to itself (using VRouters) to try to recreate the problem, as I don't happen to have a spare ATM DS-3 to test with and Ascend, well... Does any of this ring any bells for anyone? Rapidly graying... -- Peter Lalor Infoasis plalor at infoasis.com http://www.infoasis.com/ "Where's my burrito?" -- Homer ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request at bungi.com To get FAQ'd: <http://www.nealis.net/ascend/faq>