Real Time Ascend Maling List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(ASCEND) Re: ascend-users-digest V96 #1538
I want off this list...
-----Original Message-----
From: owner-ascend-users-digest@max.bungi.com
<owner-ascend-users-digest@max.bungi.com>
To: ascend-users-digest@max.bungi.com <ascend-users-digest@max.bungi.com>
Date: Sunday, March 14, 1999 7:02 PM
Subject: ascend-users-digest V96 #1538
>
>ascend-users-digest Saturday, 13 March 1999 Volume 96 : Number
1538
>
>In this issue:
>
>Re: (ASCEND) Port 80
>Re: (ASCEND) Port 80
>(ASCEND) Pipe 130, packet loss
>(ASCEND) Port reselling: TCP modem.
>(ASCEND) Max, ISDN, OSPF? Problems
>
>----------------------------------------------------------------------
>
>From: Lars Marowsky-Bree <lmb@teuto.net>
>Date: Sat, 13 Mar 1999 08:08:38 +0100
>Subject: Re: (ASCEND) Port 80
>
>On 1999-03-12T18:50:22,
> "Sam Hayes Merritt, III" <harter@feeding.frenzy.com> said:
>
>> > i.e. If I sell a user a mailbox, I do not want that
>> > customer to browse.
>> ip in forward tcp dstport = 25
>> ip in forward tcp dstport = 110
>> generic in drop 0 0 0
>
>You want something more like:
>
> Ascend-Data-Filter = "ip out forward 6 dstport = 25",
> Ascend-Data-Filter = "ip out forward 6 srcport = 25",
> Ascend-Data-Filter = "ip out forward 6 dstport = 53",
> Ascend-Data-Filter = "ip out forward 6 dstport = 53",
> Ascend-Data-Filter = "ip out forward 17 dstport = 53",
> Ascend-Data-Filter = "ip out forward 17 srcport = 53",
> Ascend-Data-Filter = "ip out forward 6 srcport = 110",
> Ascend-Data-Filter = "ip out forward 6 dstport = 110",
> Ascend-Data-Filter = "ip out drop",
>
>in their profiles. Surely you want them to be able to do DNS too ;-)
>
>Sincerely,
> Lars Marowsky-Brée
>
>- --
>Lars Marowsky-Brée
>Network Management
>
>teuto.net Netzdienste GmbH - DPN Verbund-Partner
>++ Ascend Users Mailing List ++
>To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
>To get FAQ'd: <http://www.nealis.net/ascend/faq>
>
>------------------------------
>
>From: Michiel Boland <boland@diva.nl>
>Date: Sat, 13 Mar 1999 15:41:08 +0100 (CET)
>Subject: Re: (ASCEND) Port 80
>
>On Fri, 12 Mar 1999, Sam Hayes Merritt, III wrote:
>
>> ip in forward tcp dstport = 25
>> ip in forward tcp dstport = 110
>> generic in drop 0 0 0
>>
>> (Assuming you want smtp and pop3)
>
>Don't for get to add
>
> ip in forward udp dstport = 53
>
>for DNS.
>
>Also, you don't need the 'generic in drop' at the end. If a packet falls
>through a set of filter rules, it is denied anyway.
>
>Cheers
>Michiel
>
>- --
>Michiel Boland <boland@diva.nl>
>Digital Valley Internet Professionals
>Duivendaal 4, Wageningen, The Netherlands
>Phone: +31 317 465555, Fax: +31 317 460276
>
>++ Ascend Users Mailing List ++
>To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
>To get FAQ'd: <http://www.nealis.net/ascend/faq>
>
>------------------------------
>
>From: Marcel Brown <marcel@marcelbrown.com>
>Date: Sat, 13 Mar 1999 11:46:37 -0600
>Subject: (ASCEND) Pipe 130, packet loss
>
>Has anyone experienced a Pipeline 130 showing some packet loss and/or slow
>traceroutes? Basically, things that would affect on-line gaming such as
>Half-life and Quake.
>
>I've already turned off STAC and VJ on the router. Any ideas would be
>appreciated.
>
>Also, what is the latest version of the Pipe's firmware that is considered
>stable?
>
>Thanks,
>Marcel
>
>
>++ Ascend Users Mailing List ++
>To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
>To get FAQ'd: <http://www.nealis.net/ascend/faq>
>
>------------------------------
>
>From: Will Pierce test acct <willp2@dreamscape.com>
>Date: Sat, 13 Mar 1999 14:10:45 -0500 (EST)
>Subject: (ASCEND) Port reselling: TCP modem.
>
>Howdy all,
>
>I haven't been on the list in a long time. Since there's been some recent
>flareups about Ascend's code quality and all, I'll share my own recent
>experiences.
>
>In the past year, our parent company has deployed two DMS 500 switches in
>our primary POP locations. We're up in Bell Atlantic (formerly Nynex)
>territory, where the cost of channelized T1's and PRI's is ridiculous.
>
>With our DMS 500's, we now take trunks directly from Bell Titantic and
>then feed them to our switches and then pull out PRI's to our base of Max
>40xx's.
>
>Let me say this: PRI's totally and completely blow channelized-T1's out of
>the water for speed and reliability of connections. Our percentage of
>disconnect codes has moved the code 45 percentage up to about 80%. (code
>45 means the user requested disconnect. I call it an "OK" in our call
>logs.) Speeds have also rose about 5% for everyone. People in the boonies
>who always got 26.4k now get 28.8 or 31.2k. The highest speeds we see are
>now 54.7k. And some people get 54.7k _every_ time without fail.
>
>Now for the gripes:
>
>7.0.3 is totally unstable for us. We use ISDN with NFAS to double-up two
>wan ports on one D-channel. When a clean (fclear,nvramclear in diag) max
>4048 with _no_ settings is configured for ISDN_NFAS to an NTI switch, the
>box reboots continuously. I have not had the same problem with 7.0.4, but
>I am understandably nervous about moving the ones at 7.0.1 to 7.0.4.
>
>We recently realized that we have had more max 40xx's go belly up due to
>power supply problems than we have had modem cards die. It's one reason
>we are extremely nervous to consider a TNT.
>
>Now for something _totally_ cool!
>
>TCP Modem is the most awesome thing I have overlooked.
>
>For the uninitiated: "TCP Modem" in the Max allows you to specify a TCP
>port that you can connect to and the connection is treated exactly the
>same as if you dialed in. Same PPP Delay, same login prompt, you can
>start up PPP over the TCP connection and it works beautifully.
>
>There was a somewhat obscure section in the RADIUS manual that I ran
>across recently where you do this:
>
>Set up a user to authenticate with DNIS (dialled number). For example,
>you have a single Max pool with PRI's (so you get DNIS on every call).
>You have one dialup number: 212-555-5656. Let's suppose you have a
>"sister" ISP in upstate New York whose access number is 315-555-1111.
>Both you and the "sister" ISP configure TCP modem on port 150 (or 6150 or
>whatever) on _all_ of your maxes.
>
>Then, the 212 area code ISP gets their switch to put in 212-555-1111 in as
>a new number that points at the huntgroup. Then you configure a
>connection profile to authenticate by DNIS _only_, and set it up to open a
>TCP-Clear connection to a max in area code 315 (over the internet) to port
>150.
>
>This means anyone dialing 212-555-1111 will be connected immediately to an
>Ascend Max in area code 315, but the packets are going over the internet--
>no long distance charges.
>
>Let's say the 315 area code ISP also sets up a connection profile and a
>number for 315-555-5656 to open a TCP-Clear connection to a max in area
>code 212 on port 150.
>
>This means that the ISP in 212 now has a dialup number in area code 315
>and the 315 ISP now has a dialup number in area code 212.
>
>This is beyond what iPass provides. Actually far beyond.
>
>Instead of having customers (with iPass) dial up another ISP, and use a
>slightly modified DUN entry, and a modified RADIUS authentication daemon
>which proxies out authentication on iPass calls-- this means that there is
>no iPass middle-man. Two ISPs in different geographic regions can provide
>dialup access to each other and be able to provide tech support for
>customers in those cities just the same as if they had dialed in locally.
>
>The benefits:
> * customers hitting a TCP-tunneled access number get the same IPs and
>RADIUS filters/idle timeouts/etc as if they hit a local number
> * because the TCP tunnel is from Max to Max, it is far easier to
>troubleshoot routing problems between ISPs. Assuming both ISPs are
>BGP-speakers, in a worst-case scenario, weights can be applied to the
>routes that provide the best round-trip-time, on both ends.
> * there is no equipment outlay for expanding, and no need to provide a
>POP for those cities.
>
>The downside:
> * the bandwidth of a caller who hits a "TCP tunneled" access number is
>weird: a customer who downloads 1 megabyte actually gets 1 megabyte from
>the internet connection of their real ISP. This 1 megabyte is then sent
>_outgoing_ from that ISP to the ISP that is providing the remote access
>number. So, instead of having to worry about bandwidth in mostly only one
>direction, any incoming bandwidth to a dialup customer on a
>remote-TCP-city (what the hell do you call this?) will actually be using
>roughly equal in/out bandwidth. (Assuming that they only surf and aren't
>getting their data primarily from their real ISP's servers.) This
>actually wouldn't be as much a consideration if all customers were proxied
>or there was a transparent cache somewhere at their real ISP.
> * Someone would have to figure out how to charge for this service.
> * You can't have more people connected to a max with TCP connections than
>you have IPs in your dialup pools.
> * A single max 40xx can handle 48 dialup callers just fine without CPU
>loading problems. How many additional TCP connections can it handle
>before running into loading problems? I don't know. The Max with a TCP
>Modem connection has to handle PPP encapsulation, MS-Stac compression
>(if enabled), any packet-filtering specified in the RADIUS profile, and of
>course it has to handle the packet-routing.
> * Don't even ask me if Multilink with Stacking will work over TCP Modem.
>I've got enough to think about. :)
> * Accounting for _who_ sent you a call by TCP-Modem can be difficult.
>If you had multiple people providing dialup->tcpmodem service, you'd have
>to receive the logs of connect start/end times and line it up with calls
>in your own log to verify calls. I'm still playing with how the RADIUS
>accounting would work between two providers. And how to turn this into
>something usable for possible billing purposes.
>
>Some ideas:
> * With DNS load-blancing, you could specify "tcpmax.domain.com" to
>resolve to each IP address of each Max that you want to accept TCP-Modem
>connections. Then on the remote ISP's connection profile, you specify a
>hostname of "tcpmax.domain.com" instead of an IP. This would balance the
>load of TCP-modem callers across a pool of Maxes. This would also be
>manageable by the right people- at domain.com instead of the remote ISP.
>(Sorry if this is real confusing.)
>
>Why do this?
>
> Well, it wouldn't make sense to use this as a way of _truly_ expanding
>into other markets in any kind of large or medium scale. If you have
>1,000 customers who all connect to you this way, you should get your own
>POP.
>
> It does make sense when two ISPs have customers who travel between their
>coverage areas. Or two ISPs that do not have plans to expand into each
>other's territories. If the two ISPs end up with many customers using
>these access methods, it might even make sense to bring up a Frame Relay
>link between the ISPs to handle the traffic between Maxes exclusively.
>
> If both ISPs are CLEC's and recip comp is a revenue source, then it
>makes more sense for two ISPs to collect each other's recip comp than to
>have their customers hang on to an AOL account for the times when they
>travel outside their ISPs coverage area.
>
> It may cost some ISPs to get additional phone numbers configured to hunt
>into their Maxes. This cost might be unbearable.
>
>
>If someone has had this idea before, or if it is already a developed
>system being used by many ISPs that I'm just ignorant of, please please
>please give me the pointers to the resources on the net.
>
>I'm a little uneasy just now about how the charges would be calculated.
>But I'd be very excited if there was a webpage where ISPs could advertise
>that they provide this service, including what areacode/exchanges for each
>city, and their own costs on setup and any per-hour costs. That would be
>under the assumption that there are no problems with CPU loading, and no
>problems with bandwidth that I've overlooked.
>
>There are probably many other ways to do this, involving RADIUS proxying,
>or encrypted tunnels that I haven't mentioned or thought of.
>
>- --
>Will Pierce
>System Administrator
>Dreamscape Online, LLC.
>willp@dreamscape.com
>
>++ Ascend Users Mailing List ++
>To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
>To get FAQ'd: <http://www.nealis.net/ascend/faq>
>
>------------------------------
>
>From: "Steven Martin" <steven.martin@cleanweb.net>
>Date: Sat, 13 Mar 1999 23:11:59 -0600
>Subject: (ASCEND) Max, ISDN, OSPF? Problems
>
>I have got some problems and cannot seem to track these problems down.
>
>Network Setup:
>Cisco 2501 - OSPF, RIP, BGP
>3 Max 4048 - Software version 6.1.7 - OSPF - Stacked
>
>The problem is one that is pretty unusual and hard to trace. When an ISDN
>customer dials up they are given a static subnet and it is routed via OSPF.
>This seems to be working fine. The problem is that when any kind of
>transmission is going on it acts pretty strange. Here are the symptoms and
>they do not happen on a regular interval that I can find.
>
>- - No mattter what happens you can always ping a remote host
>- - After browsing the web with no problems, all of the sudden you cannot
get
>anywhere. It will stop at "connecting to ___" and stop, after a minute or
>so it will start working again
>- - If making a connection with something like VNC, PCAnywhere, telnet it
will
>lose the connection
>
>All of this time the ISDN connection between the Pipeline (or other brands
>of routers) and MAX is never lost. The line is always up. Does anyone
have
>any ideas? It doesn't have to do anything necessarily to do with the
>Internet connection since it happens also with things on our local network.
>
>Thanks for the help in advance.
>
>steven martin.
>
>_______________________________________
>Steven Martin
>Director of Network Operations
>SouthWest Web Services and Cleanweb, Inc.
>Phone: 806.473.2922 Cell: 806.790.6266
>Fax: 806.473.2984
>smartin@swws.net
>_______________________________________
>
>++ Ascend Users Mailing List ++
>To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
>To get FAQ'd: <http://www.nealis.net/ascend/faq>
>
>------------------------------
>
>End of ascend-users-digest V96 #1538
>************************************
>
>++ Ascend Users Mailing List Digest++
>To unsubscribe:
>"echo unsubscribe | mail ascend-users-digest-request@bungi.com"
>To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
>or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>